Messages

1

General / Re: Agisoft Metashape 1.7.0 pre-release

« on: December 14, 2020, 10:14:01 PM »

Alexey
The quality of dense point cloud that is generated in v1.7 and the filter by confidence tool is a major step forward for the underwater models that I work on. Top marks.
I have run into a bit of a dead end with a variation of the workflow I am using. I initially generated the DPC with no colour but calculating point confidence.  I then filtered by confidence to get rid of the noise.  Finally, I coloured the PDC. 
All is good except that I wanted to display the dense point cloud confidence with a view to getting rid of more noise but the point confidence appears to have been removed by colouring the dense point cloud. I have not been able to find a menu option to re-calculate point confidence.
Build 1.7.11539 standard edition on windows 10.

2

General / Re: Agisoft Metashape 1.7.0 pre-release

« on: December 01, 2020, 09:02:05 PM »

What's changed in the latest pre-release build 11539?  The change log does not look to have been updated.

Also, What are "connected components"?

There is a new "Components" level on the Workspace tree structure but there are no right click commands or other functions that seem to relate to "component" objects.  What is that all about?

3

Feature Requests / Feature Request : Logfile per Project

« on: November 18, 2020, 02:58:07 AM »

I'm often running processes on multiple metashape projects concurrently, consequently the logfile is very difficult to read as it contains entries from different projects interspersed with each other.

Could you implement a scheme where logfiles are written to a sub-directory with the name of the project file or some other means of keeping logfile entries for different projects separate from each other?

4

Feature Requests / Feature Request : Copy Cameras

« on: November 18, 2020, 12:52:07 AM »

Same as the "Move Cameras" except Copy.

I find myself identifying cameras that I want to duplicate to another chunk to provide overlap for use in the align chunks, align by cameras method.

5

Bug Reports / Re: 1.6.4 ERROR_DEVICE_LOST

« on: September 03, 2020, 07:10:45 PM »

Alexey

I provided the model to your support folks but have not heard how they got on.

Did they manage to replicate the problem?

Any idea if there will be a fix?

6

Bug Reports / 1.6.4 ERROR_DEVICE_LOST

« on: August 25, 2020, 12:14:09 AM »

I can't get the "Build Texture" stage to run.

Tail of log...

2020-08-24 21:07:36 Camera contribution estimated (in 39.16 sec)
2020-08-24 21:07:36 Avg camera fetch time: 5.77944e-06 sec
2020-08-24 21:07:36 Avg camera processing time: 0.00271025 sec
2020-08-24 21:07:38 estimating cameras resolution...
2020-08-24 21:07:42 Cannot use GPU. Reason: VK Error : VkResult is "ERROR_DEVICE_LOST" at line 245
2020-08-24 21:07:42 Performing blending on CPU...
2020-08-24 21:07:45 calculating mesh connectivity...

v1.6.4

Error is repeatable.

7

General / Re: Agisoft Metashape 1.6.0 pre-release

« on: January 24, 2020, 04:09:10 PM »

Hello Brian,

Thank you for sending the sample image. It appears that the presence of the alpha-channel in the images is causing the problem with the GPU-based texture blending.

We''\ll try to implement the fix for the issue in the next version update, but meanwhile you should either disable GPU for the texture blending process or remove alpha channel from the source images.

I can confirm that this issue is fixed in v1.6.1 build 10009

8

General / Re: Agisoft Metashape 1.6.0 pre-release

« on: January 22, 2020, 07:20:56 PM »

Hello BjFaeTorphins,

I think that something messed up with the access rights - for some reason the created files cannot be removed or rewritten. Do you observe any similar behavior when trying to export anything from Metashape to the new file or to the file with existing filename?

Alexey

After the error happens the model.tmp directory mentioned in the error message is gone.  I've not seen any permission errors and the project file can be saved after the error.

Hi Alexey

I think I've figured out what is causing these errors.

I'm using a Synology NAS to store my models.  I have a fast SSD drive on my desktop computer which is continuously synchronised to a Work in Progress folder on the NAS.  When I want to do work on a model i copy the files for the model to be worked on from the main folder structure on the NAS to the Work in Progress folder on the NAS which is then automatically synchronised to the SSD drive on the desktop.  The software that does this synchronisation between the NAS and the desktop is called Synology Drive.  I've been disabling this software when doing mesh from depth maps for about a week now and not had any more errors.  Whereas, I was getting the file errors at least 50% of the time previously.

I have been using this arrangement for quite some time (since Photoscan v1.3.5) and not had the file errors before.  I suspect that it is something to do with the very high number and size of the temporary files that v1.6 mesh from depth maps out-of-core creates. 

I can live with this work-around but it would be more convenient if i didn't need to remember to switch off Synology Drive while running mesh from depth maps. Perhaps introducing a re-try of the file operation if i fails.

HTH
Brian.

Hi Alexey
I've changed my mind about the circumstances of these errors. 

I'm now quite sure its when .psx and .files are stored on the NAS mounted shared drive.  I checked and all of the errors that i've seen happen when those files are stored on the NAS and does not happen on my local SSD drive even if Synology Drive synchronisation is enabled.
HTH

Alexey

This problem still happens with 1.6.1 build 10009.

9

General / Re: Agisoft Metashape 1.6.0 pre-release

« on: January 16, 2020, 04:20:27 PM »

Hello BjFaeTorphins,

I think that something messed up with the access rights - for some reason the created files cannot be removed or rewritten. Do you observe any similar behavior when trying to export anything from Metashape to the new file or to the file with existing filename?

Alexey

After the error happens the model.tmp directory mentioned in the error message is gone.  I've not seen any permission errors and the project file can be saved after the error.

Hi Alexey

I think I've figured out what is causing these errors.

I'm using a Synology NAS to store my models.  I have a fast SSD drive on my desktop computer which is continuously synchronised to a Work in Progress folder on the NAS.  When I want to do work on a model i copy the files for the model to be worked on from the main folder structure on the NAS to the Work in Progress folder on the NAS which is then automatically synchronised to the SSD drive on the desktop.  The software that does this synchronisation between the NAS and the desktop is called Synology Drive.  I've been disabling this software when doing mesh from depth maps for about a week now and not had any more errors.  Whereas, I was getting the file errors at least 50% of the time previously.

I have been using this arrangement for quite some time (since Photoscan v1.3.5) and not had the file errors before.  I suspect that it is something to do with the very high number and size of the temporary files that v1.6 mesh from depth maps out-of-core creates. 

I can live with this work-around but it would be more convenient if i didn't need to remember to switch off Synology Drive while running mesh from depth maps. Perhaps introducing a re-try of the file operation if i fails.

HTH
Brian.

Hi Alexey
I've changed my mind about the circumstances of these errors. 

I'm now quite sure its when .psx and .files are stored on the NAS mounted shared drive.  I checked and all of the errors that i've seen happen when those files are stored on the NAS and does not happen on my local SSD drive even if Synology Drive synchronisation is enabled.
HTH

10

General / Incremental mesh from depth maps

« on: January 08, 2020, 07:48:38 PM »

Hi Alexey
I have a project with 16,000 aligned cameras. In order to get a quick(er) view of what the final model would look like I disabled three of every four cameras then ran the mesh from depth maps.  So now I have a colourised, shaded model made from 4,000 depth maps.  I can see some holes in the model so what I tried was to enable more cameras in the areas of the model where there are holes then I re-ran the mesh from depth maps checking the option to keep depth maps. 

I had hoped that this would incrementally generate depth maps for the images that I had enabled (in the same way that you can add extra images to the alignment) while keeping the depth maps it had from the first iteration.  It did not seem to do that, instead it went directly to the building the model stage. I stopped the process as soon as I saw it going directly to build model stage.  Can you confirm that I need to rebuild all the depth maps?  If it does not do that could you consider it for an enhancement to a future version?

11

General / Re: Agisoft Metashape 1.6.0 pre-release

« on: January 06, 2020, 09:07:38 PM »

Hello BjFaeTorphins,

I think that something messed up with the access rights - for some reason the created files cannot be removed or rewritten. Do you observe any similar behavior when trying to export anything from Metashape to the new file or to the file with existing filename?

Alexey

After the error happens the model.tmp directory mentioned in the error message is gone.  I've not seen any permission errors and the project file can be saved after the error.

Hi Alexey

I think I've figured out what is causing these errors.

I'm using a Synology NAS to store my models.  I have a fast SSD drive on my desktop computer which is continuously synchronised to a Work in Progress folder on the NAS.  When I want to do work on a model i copy the files for the model to be worked on from the main folder structure on the NAS to the Work in Progress folder on the NAS which is then automatically synchronised to the SSD drive on the desktop.  The software that does this synchronisation between the NAS and the desktop is called Synology Drive.  I've been disabling this software when doing mesh from depth maps for about a week now and not had any more errors.  Whereas, I was getting the file errors at least 50% of the time previously.

I have been using this arrangement for quite some time (since Photoscan v1.3.5) and not had the file errors before.  I suspect that it is something to do with the very high number and size of the temporary files that v1.6 mesh from depth maps out-of-core creates. 

I can live with this work-around but it would be more convenient if i didn't need to remember to switch off Synology Drive while running mesh from depth maps. Perhaps introducing a re-try of the file operation if i fails.

HTH
Brian.

12

General / Re: Agisoft Metashape 1.6.0 pre-release

« on: January 04, 2020, 10:07:45 PM »

Hello Brian,

Are these 32 bit floating point data type or 32 bit integer?

If the issue is reproducible, please provide the corresponding log from the Console pane related to the texturing operation. Please also try to disable GPUs in the Preferences dialog and re-build the texture using Keep UV option. Let me know if the result is the same or different (correct).

Alexey

Thanks for the reply.

I don't know if it is 32bit floating point or integer.  Windows reports it as bit depth 32.  I'm using the same tool to extract TIFs from video as i have been for a couple of years without problems.  It's based on the FFmpeg library.

I disabled the GPUs and re-run the texture and that has fixed the problem.  i.e the texture looks right again.

13

General / Re: Agisoft Metashape 1.6.0 pre-release

« on: January 04, 2020, 02:01:05 AM »

Alexey

The problem I reported about silent crashes during mesh from depth maps is still happening with build 9925 but I think I understand the circumstances under which it happens.

With reference to the attached screenshot which shows one of the GPU tabs from Task Manager.  I've highlighted the "Shared GPU memory" number which is 29.7 out of 63.8GB.  The other GPU is also using ~30GB so a total of 60Gb out of 64Gb of Shared GPU memory is used at this point.

An instance of Metashape has just finished mesh from depth maps and it has used this 60Gb of shared GPU memory and when it finished it has not released the memory.  I've started up a 2nd instance of Metashape to process another different model and it starts to use GPU shared memory and shortly after the attached screen shot was taken the 2nd process failed silently.

To summarise: I think there is a memory leak in the mesh from depth maps process where it does not release shared GPU memory and eventually if Metashape is not restarted it either hits a handled error and produces the Not enough GPU memory or just fails silently.
HTH
Brian

14

General / Re: Agisoft Metashape 1.6.0 pre-release

« on: January 04, 2020, 01:44:21 AM »

Hello BjFaeTorphins,

What is the input data format - file type, bit depth? Was the texture blending performed on GPU?

TIF files, 4000x3000 pixels 32bit LZW Compression.  I tried to attached an example but at 17Mb its to big.  It's the same camera and settings I've been using for a long time. and still works wiht v1.3.5 and v1.5.5. A GoPro recording 4k video from which I extract frames.

How can I tell if the texture blending was performed on GPU?  I used the 9925 build and the two builds before hd the same problem.

15

General / Re: Agisoft Metashape 1.6.0 pre-release

« on: January 02, 2020, 05:27:38 PM »

Are you using the latest Nvidia Drivers?
What are the specs of your photos (JPG/PNG..16/24/32bit) ? Could be an issue the new GPU accelerate texture generation. One way to find out would be to disable it (Alexey could probably share the tweak to manually turn it off).

Mak

version 441.41 released 26 November so not that old.  There is a newer build released on 10 December which i'll download.

I've updated to the latest 441.66 20th December drivers and still get the issue.

I note if i go back into the build texture item on the workflow menu that the mapping mode is set to Keep UV,  I've tried setting this to Generic and re-running the texture build but the same happens.

Alexey
I've updated to the 9925 build and am still getting this weird looking almost greyscale texture.

Alexey

I went back to a model that i built using v1.3.5 and re did the texture process.  See the two attached images.