Agisoft Metashape 1.6.0 pre-release

[Iluvathar]

Thanks for the wonderful update !
it's wonderfull to be able to work with a perfectly smooth canvas with a 70 millons triangles model
 
however i have a problem concerning textured models as you can see on the picture not all the textures are displayed, why (unchecking VBO support is solving the issue) ? (last update, latest drivers 40000Mb vram allocated)

[BjFaeTorphins]

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.

[eltama]

I checked reuse deph map (ultra setting) and yes I have errors on both steps, now I had installed the latest version 9925, and build mesh without reuse depth maps with high quality.

I have some duplicated images, now deleted, runs as admin.
I noticed a strange behavior, even if I am admin, I can’t disable read only mode on files.

Best regards

Hello Alexey
I had this error, build mesh from a new deph map (didn't  check reuse map) my setting: quality high, face count high:
...
2020-01-02 23:31:24 finished treetop part #1013/1205: 433 treetop nodes, 73.5762 KB registry
2020-01-02 23:31:24 Creating treetop for part #1014/1205...
2020-01-02 23:31:31 finished treetop part #1014/1205: 433 treetop nodes, 73.5762 KB registry
2020-01-02 23:31:31 Creating treetop for part #1015/1205...
2020-01-02 23:31:39 Peak memory used: 17.92 GB at 2020-01-02 06:40:07
2020-01-02 23:31:39 deleting all temporary files...
2020-01-02 23:32:01 done in 22.855 s
2020-01-02 23:32:01 Finished processing in 171202 sec (exit code 0)
2020-01-02 23:32:01 Error: Assertion 239115764 failed at line 69!

[Alexey Pasumansky]

Hello eltama,

Can you please confirm that the same issue is observed in the release version 9925?

[Alexey Pasumansky]

Hello BjFaeTorphins,

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

[Alexey Pasumansky]

however i have a problem concerning textured models as you can see on the picture not all the textures are displayed, why (unchecking VBO support is solving the issue) ? (last update, latest drivers 40000Mb vram allocated)

Hello Iluvathar,

Can you please specify the GPU model and OS version that you are using? Additionally the texture atlas size, number of pages and bit depth.

Also please confirm that you are using 40 000 Mb of VRAM.

[BjFaeTorphins]

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.

[BjFaeTorphins]

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

[Alexey Pasumansky]

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).

[BjFaeTorphins]

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.

[Alexey Pasumansky]

Hello Brian,

Can you please send any sample image in this format to support@agisoft.com or as a download link via PM to me?

[Alexey Pasumansky]

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.

[eltama]

Hello eltama,

Can you please confirm that the same issue is observed in the release version 9925?

Hello Alexey

of course, I make new alignement in 9925 in highest mode without error, now I'm waiting for build mesh from deph map (no resume) in highest mode too, images are 61MP.
 

[Iluvathar]

however i have a problem concerning textured models as you can see on the picture not all the textures are displayed, why (unchecking VBO support is solving the issue) ? (last update, latest drivers 40000Mb vram allocated)

Hello Iluvathar,

Can you please specify the GPU model and OS version that you are using? Additionally the texture atlas size, number of pages and bit depth.

Also please confirm that you are using 40 000 Mb of VRAM.

Hello Alexey

The GPU model is a quadro RTX 8000, I use to build 16384 textures in one atlas, i also 8192x2, 4 bands, uint8,
The OS is windows 10
i also worked on an other computer, with a gtx1080, same issue with 16384 or 8192 VBO enabled,
note : when vbo is disabled the textures are coming back to normal
note 2 : when the model has lower complexity textures are displaying just fine with vbo enabled (less than 10-20mio poly and 16384 resolution textures)

[BjFaeTorphins]

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.