Agisoft Metashape 1.5.0 pre-release

[Mak11]

Something seems definitely wrong with the depth map generation in the latest build. I'm reprocessing a project this time using the new meshing method (without re-using the old depth-maps so its creating new ones) and as you can see from the screenshots below it's going to take nearly twice as long as it took with a previous version of Metashape (it took 3h56 now it is past 4h with still 3hrs left..).

UPDATE: It took 5h10 to process the new depth maps compared to 3h54 with a previous build.

Mak

[Mak11]

Alexey,

I did some more testing:

Totatly uninstalled and ereased any trace of Metashape & Photoscan (deleted all registry entries etc) and re-installed the latest build of Metashape. Rolled back to the 18.5.1 Radeon driver after clean unstalled with DDU just in case the GPU was acting funny with the latest release.

Re-ran another set & generated depth maps via the new method to compare processing time with an older build of Metashape and as you can see in the screenshots below the latest build was 37mins slower (2h23). The newest depth maps are also different (maybe a bit more detailed).

Regards

Mak

[RHenriques]

The depth maps are very good in this version. In the latest ones they were not so good. For those that are using UAV surveys in evironments with bushes or trees, this version is probably the best ever. Mak11, I would not sacrifice this quality by processing speed. Try to lower one quality step if you do not mind to get speedier processing times sacrificing quality :-)

[Mak11]

RHenriques,

I agree that having better depthmaps is a good thing.. But in my case (I don't do UAV projects) it's totally not worth it given the small difference in quality VS big performance penalty especially when the final mesh is not even better (it's actually worst in two projects I tested yesterday). Going down to High is not an option unfortunately as I need the highest detailed mesh possible for baking later.

Mak

[Alvaro L]

Quite happy with the new meshing based on depth maps, I get much more quality for a given calculation time and more importantly, for a given set of tie points and therefore still photographs, since re taking field work takes a lot of time, energy and money. I still think that there should be a thresold for generating very small detail based on displacement mapping on  subdivision surfaces, since Agisoft generates good meshes anyway. This way I could squeeze more render quality and diffuse consistency in pos rendering operations in 3D packages.

Also I would welcome more advanced operations and workflows with regions (Multiple regions, boolean logics, non destructive workflows, etc). Anyway Agisoft rocks, I just sampled a 17 hectares old city with Agisoft and it is delivering, compared to existing GIS data, xtremely good relative accuracy even without CGP points !!! Of course there is a good workflow involved but heck I am impressed.

[Mak11]

The new meshing method already greatly result in higher detail models with the "older" depthmaps and from my own testing the newer ones which are on average 30% slower to generate are not really improving things at all (in my particular use cases).

But I do admit that I'm probably in the minority.

Mak

[bisenberger]

I'm getting a lot of crashing when running Build Tiled Model with Quality set to Ultra high. Build 7492.

Here is a link to my log file:
http://www.digital-mapping.net/forums/Metashape/Jan2019_log.zip

[Alexey Pasumansky]

Hello bisenberger,

Does it seem similar to the following bug report:
https://www.agisoft.com/forum/index.php?topic=10222.0

However, in the log it seems that the tiled model generation procedure has been completed successfully.
Or are you referring to "clGetPlatformIDs failed: CL_UNKNOWN_ERROR_CODE_-1001" lines?

[bisenberger]

Hi Alexey,
It is crashing my computer (blue screen), so maybe it isn't saved to the log. When it crashes my computer the blue screen error code has been different each time.  The routine does complete sometimes, and that's probably what you see in the log.

I'll look at the info in the post you refer to.

The "clGetPlatformIDs failed: CL_UNKNOWN_ERROR_CODE_-1001" is something I reported earlier in the thread. My guess is, it has something to do with a graphics card that is no longer installed in the system. I have used the AMD cleanup utility, but the code is still there.

[bisenberger]

Forgot to mention that I don't have the problem when using the other quality settings. I only have the problem when the quality is set to Ultra High.

[james_AU]

Hi Alexey et al.,

I would like to make a point regarding visibility consistent mesh generation option. I have started running a couple of experiments using Agisoft Cloud.

There does not seem to be an option visible in my build (7492, Mac OS X) to set the depth filtering. When running as a non-batch process, interpolation and depth filtering options appear greyed out. Are they locked? I am not sure, as when I attempted to run mesh generation as a batch process from depth maps, the process failed (355 cameras, planar surface, highest quality). Depth maps were saved (see log: 'downloading 3.xxxGB'), but they came out with aggressive filtering. The reason for failure was not given, but when attempting to run the process again, the error 'null dense cloud' was returned. Obviously something has gone awry somewhere along the road....

Given I work with rock art, and the best images that I capture have little or no noise, it is important that small details are not discarded as outliers, which I have observed can occur when using filtering (smoothing options). There is also the additional benefit of reduced computational cost. Therefore, it is for these reasons I ask about filtering options that many do not completely disable as a matter of course. All this you may of course know already.

I can see the benefits of visibility mesh generation, and Diana Ovod  has previously recommended that I try out the method. Unfortunately, due to reasons beyond my control, I have not had the chance to test it on HPC until the launch of Agisoft Cloud. I am particularly interested if the method reduces RAM demands (although we unfortunately can't see performance readouts from EC2), which can be a problem for me, and hence Diana's recommendation.  There is also the time saving element through full exploitation of parallelism. I know there are some of our colleagues saying things are now taking longer, but lets see...

Regards,

James

[Alexey Pasumansky]

Hello James,

Currently depth maps based mesh generation option is creating the depth maps with the Mild Filtering by default and requires it on input, so depth maps calculated with the different filtering option cannot be re-used for this method (at least in the version 1.5.0). There's, however, a workaround how to make it possible to re-use aggressive and moderate depth maps - it's necessary to modify the meta information of the depth maps instance in the chunk, for example, using Python console:

Code: [Select]

Metashape.app.document.chunk.depth_maps.meta["depth/depth_filter_mode"] = "0"After that the available depth maps could be re-used. However, the Mild option tends to produce better results in most projects.

In the version 1.5.0 the depth maps generation procedure has been revised and optimized, so you shouldn't expect noise for mild filtering depth maps. Moreover, new meshing method should be good for internal noise suppression.

I can try to compare the processing time for some rock-art / stone carving projects that we have for dense cloud and depth maps based meshing methods (both for mild and aggressive filtering) and provide the comparison chart. the new meshing is exploiting GPU for reconstruction, so it can be accelerated with the good discrete GPU cards, whereas the dense cloud reconstruction (especially dense cloud filtering part) time is quite dependent on the image overlap, while the old meshing method could be very RAM demanding for large datasets (hundreds of photos) in High / Ultra quality.

As for the issues that you have been observing with the cloud, could you specify, when does it happen?

[james_AU]

Hello James,

Currently depth maps based mesh generation option is creating the depth maps with the Mild Filtering by default and requires it on input, so depth maps calculated with the different filtering option cannot be re-used for this method (at least in the version 1.5.0). There's, however, a workaround how to make it possible to re-use aggressive and moderate depth maps - it's necessary to modify the meta information of the depth maps instance in the chunk, for example, using Python console:

Code: [Select]

Metashape.app.document.chunk.depth_maps.meta["depth/depth_filter_mode"] = "0"After that the available depth maps could be re-used. However, the Mild option tends to produce better results in most projects.

In the version 1.5.0 the depth maps generation procedure has been revised and optimized, so you shouldn't expect noise for mild filtering depth maps. Moreover, new meshing method should be good for internal noise suppression.

I can try to compare the processing time for some rock-art / stone carving projects that we have for dense cloud and depth maps based meshing methods (both for mild and aggressive filtering) and provide the comparison chart. the new meshing is exploiting GPU for reconstruction, so it can be accelerated with the good discrete GPU cards, whereas the dense cloud reconstruction (especially dense cloud filtering part) time is quite dependent on the image overlap, while the old meshing method could be very RAM demanding for large datasets (hundreds of photos) in High / Ultra quality.

As for the issues that you have been observing with the cloud, could you specify, when does it happen?

Hi Alexey,

Thanks for the swift response. Perhaps it wasn't so clear in my message, but what I would like to do is to disable filtering. Just to reiterate, with well exposed, focused images, taken in strong light, I am able to process without any filtering because there is no noise evident in the dense surface reconstruction (though I note what you say and have observed myself that version 1.5 has revisions and optimisations in this regard).

Therefore, if I have generated the depth maps via the usual procedure without depth filtering, should the workaround in python work for depth maps generated without filtering too?

 In the meantime, to get an idea of the output I have set EC2 to work again with mild filtering, but not as a batch process.

As to when the error with the cloud happens... see the attached log. I think I forgot to attach it last time.

Regards,

James

[Alexey Pasumansky]

Hello James,

The workaround with Python would work for any depth maps filtering option, it just changes the meta information for the available depth maps to "Mild".

As for the "null dense cloud" problem, what were the processing parameters of the task that you have sent for processing in the cloud?

[james_AU]

Hello James,

The workaround with Python would work for any depth maps filtering option, it just changes the meta information for the available depth maps to "Mild".

As for the "null dense cloud" problem, what were the processing parameters of the task that you have sent for processing in the cloud?

Hi Alexey,

The processing parameters for the log previously supplied were according the attached screenshot. The process was then started and left to its own devices. When I synced the project, a set of depth maps with aggressive filtering were delivered back. There was not explanation why. I then tried to run the process again, just as you see, but with the reuse depth maps option checked. It was then that the "null dense cloud" error message was returned.

As you have pointed out, the program will have of course become confused, given the default settings in operation as you have previously outlined.

Regards,

James

P.S. Update. I have run the project with the default settings for visibility consistent mesh generation. The process still failed. Depth maps were generated in 1hr33min, with aggressive filtering, despite this not being specified. The project has then synced to the local machine, with no error message. I will now try specifying the set of  depth maps using python.