Forum

Author Topic: Incomplete mesh in V1.71 where V1.65 was able to construct a closed mesh  (Read 17531 times)

Andreas1206

  • Newbie
  • *
  • Posts: 27
    • View Profile
Hello,

I am still experiencing the same issues of very unstable mesh reconstruction in the V 1.7.. versions as well.

Reducing the image count seems to prevent some reconstruction defects (see attached images) but of course this causes other areas of the mesh to be badly reconstructed as information is missing there.

Masking out defoucs areas also appears to help but the the "Mask defocus areas" option very often chooses the masked areas very unpredictably, masking out quite in focus areas and leaving completly blurry parts. Turning on the "Fix coverage" option pretty much just seems to create masks, that contain all the image parts used in the model - no matter whether they are in focus or not. Strangely enough defocus mask generation appears to be working much better, when creating the defocus masks based on a scaled mesh created in V 1.65 - so I assume, this has something to do with the new DM-generation process too?

It's too bad, the new DM-generation method causes so many problems, as it really is quite impressive, how much more detailed the meshes are in the areas, where the reconstruction works alright. But compared to earlier versions, V1.7.. at the moment is not reliable for my work (close-reange PG of cultural heritage) . This really is quite frustrating and taking up a lot of time testing, recalculating meshes, comparing them, using different versions, etc.

I really hope, this can soon be improved,
Andreas

RHenriques

  • Full Member
  • ***
  • Posts: 225
    • View Profile
After a few tests with jnb's complete set, I reinforce the suspicion that the problem is linked to overlap excess. Even if we use the old school (which I still prefer for UAV images) dense cloud generation, things clearly get worst with the complete 73 image set. If we lower to 37 images, the reconstruction is more reliable, with less holes in the problematic area. This happens no matter the quality we choose. I've tested from medium to ultrahigh and the problem is similar. Maybe there's the need that Agisoft use some sort of tweak to the reconstruction parameters depending on the overlap used. Excess overlap consistently increases the probability of holes in the mesh and noisy geometries.

Andreas1206

  • Newbie
  • *
  • Posts: 27
    • View Profile
Maybe there's the need that Agisoft use some sort of tweak to the reconstruction parameters depending on the overlap used. Excess overlap consistently increases the probability of holes in the mesh and noisy geometries.

wouldn't this just be this tweak suggested by Alexey in earlier threads - this limits the maximum amount of neighbors used in depth map creation right?

main/depth_pm_max_neighbors


RHenriques

  • Full Member
  • ***
  • Posts: 225
    • View Profile
Maybe there's the need that Agisoft use some sort of tweak to the reconstruction parameters depending on the overlap used. Excess overlap consistently increases the probability of holes in the mesh and noisy geometries.

wouldn't this just be this tweak suggested by Alexey in earlier threads - this limits the maximum amount of neighbors used in depth map creation right?

main/depth_pm_max_neighbors


Hi Andreas1206. Probably this is the one. My suggestion to Agisoft is that the parameter (this one or other) might adapt automatically, without user intervention, based on detected image overlap. If we tweak it by hand it will be a huge guess exercise.

Paulo

  • Hero Member
  • *****
  • Posts: 1301
    • View Profile
Hi Andreas,

I believe the correct syntax for the tweak is BuildDepthMaps/pm_max_neighbors   70

The above example would set max neighbors used in depth map generation pm to 70.

But I agree with RHenriques, it would be great if the program would set these tweaks according to type of imagery, overlap, resolution, CPU/GPU hardware so as to get optimised results of desired products (Mesh model, dense cloud,...).

This would avoid going about doing trial and error with various tweaks to find best result!

Hope support can look at this  :)
« Last Edit: April 06, 2021, 12:17:20 AM by Paulo »
Best Regards,
Paul Pelletier,
Surveyor

wojtek

  • Sr. Member
  • ****
  • Posts: 284
    • View Profile
Hi Andreas,

I believe the correct syntax for the tweak is BuildDepthMaps/pm_max_neighbors   70

The above example would set max neighbors used in depth map generation pm to 70.

But I agree with RHenriques, it would be great if the program would set these tweaks according to type of imagery, overlap, resolution, CPU/GPU hardware so as to get optimised results of desired products (Mesh model, dense cloud,...).

This would avoid going about doing trial and error with various tweaks to find best result!

Hope support can look at this  :)

That is dangerous though, I am on the contrary, more parameters should be exposed so that we can test things out (and ignore them if we dont need them).

jnb

  • Jr. Member
  • **
  • Posts: 60
    • View Profile
Unfortunately, this tweak as no impact on this issue. To my understanding, this is a valid tie point threshold, see Alexey post here : https://www.agisoft.com/forum/index.php?topic=13066.msg57974#msg57974
It seems to me that the new depth map method deals differently with low tie points areas, leading to no depth reconstruction in those.

i really don't know if this is relavant, but lowering the threshold to 10 won't change the limiting neighbors to 40 parameter
Code: [Select]
filtering neighbors with too low common points, threshold=10...
avg neighbors before filtering: 72 (0% filtered out)
limiting neighbors to 40 best...

Paulo

  • Hero Member
  • *****
  • Posts: 1301
    • View Profile
That is dangerous though, I am on the contrary, more parameters should be exposed so that we can test things out (and ignore them if we dont need them).
Hi wojtek,

Good point. But I think both could be profitable. Let MS set the tweaks according to your particular case but still have these tweaks with their parameter values appear in an advanced list so that the user can look at changing some of them if he wants. But for this, it is important that a description of each tweak with their use is given. Because without this we are working pretty blinded....
Best Regards,
Paul Pelletier,
Surveyor

wojtek

  • Sr. Member
  • ****
  • Posts: 284
    • View Profile
That is dangerous though, I am on the contrary, more parameters should be exposed so that we can test things out (and ignore them if we dont need them).
Hi wojtek,

Good point. But I think both could be profitable. Let MS set the tweaks according to your particular case but still have these tweaks with their parameter values appear in an advanced list so that the user can look at changing some of them if he wants. But for this, it is important that a description of each tweak with their use is given. Because without this we are working pretty blinded....

Spot on.

Andreas1206

  • Newbie
  • *
  • Posts: 27
    • View Profile
Unfortunately, this tweak as no impact on this issue. To my understanding, this is a valid tie point threshold, see Alexey post here : https://www.agisoft.com/forum/index.php?topic=13066.msg57974#msg57974
It seems to me that the new depth map method deals differently with low tie points areas, leading to no depth reconstruction in those.

i really don't know if this is relavant, but lowering the threshold to 10 won't change the limiting neighbors to 40 parameter
Code: [Select]
filtering neighbors with too low common points, threshold=10...
avg neighbors before filtering: 72 (0% filtered out)
limiting neighbors to 40 best...

Hi jnb,

If I understood this correctly, those are different tweaks:

BuildDepthMaps/pm_point_threshold  --> This one is a tie point threshold for the minimum number of tie points needed between two neighbors in order for them to be used in DM creation. First I thought this was the reason for the bad mesh reconstruction in my case, since in my log it said, that many photos were not used because of too low common tie points. But then Alexey said, that this threshold did not change compared to V 1.65. And while lowering the threshold to fewer tie points did lead to more photos being used, the mesh quality did not improve.

BuildDepthMaps/pm_max_neighbors --> sorry for the outdated syntax in my earlier post, thanks Paulo. This one does change the maximum amount of neighbors used for DM creation - so I guess this should limit the overlapping images used. But strangely enough I just finished a series of reconstructions of the same area as in the image in my post above - once with 40, once with 20 and once with a 10 neighbors limit - all of them show more or less the same amount of mesh defects. Maybe this is because the total amount of Images/Depth Maps used for the mesh generation does not change with this tweak - what changes is only the amount of neighbors used for the DM-creation of each individual image. What definitely seems to improve mesh quality though is using less total images.

So neither of these tweaks appear to really improve the problem. I somehow can't imagine, this is a problem that can simply be solved by the user applying one of the few tweaks provided in this forum - this sounds a bit like guesswork with very limited understanding and tools to me. Of course I agree, that having more adjustable parameters in the reconstruction process would be useful, interesting and allow the user to optimize results. It would also make the whole photogrammetric reconstruction process with Metashape a bit less of a "Black Box". But I believe the issues we are experiencing clearly have to be resolved on the developer's side as they appear to be more fundamental than just experimentally playing around with some tweak settings.

Don't get me wrong - I'm very impressed by and grateful for this amazing Software - but right now there definitely seems to be an issue with the last version step, causing problems (at least in close range photogrammetry - which I do) that were simply not there in the previous 1.6 Versions.

best wishes,
Andreas

jnb

  • Jr. Member
  • **
  • Posts: 60
    • View Profile
Indeed, I read too fast the tweak...
For the rest, I couldn't agree more

Mak11

  • Sr. Member
  • ****
  • Posts: 374
    • View Profile
Alexey,

Can we get an official word on this issue from the team ? ETA ?

cheers

Mak

jnb

  • Jr. Member
  • **
  • Posts: 60
    • View Profile
Hello,

Unfortunately, the issue is still here in version 1.7.3 build 12473.
Bad mesh in difficult areas compared to 1.6 and and occasionally bad depth estimation for the depth maps.
See screenshots attached.

Mak11

  • Sr. Member
  • ****
  • Posts: 374
    • View Profile
I'm unfortunately not expecting a fix until v1.8 but hope that I'm wrong :(

Mak