Change default point cloud to OpenSfM and remove PMVS from toolchain

[pulquero]

I would like to suggest that maybe pmvs shouldn't be fully removed just yet. Opensfm failed for me when I tried it on one of my datasets.

[dakotabenjamin]

@pulquero can you give more details? This is the first I have heard of opensfm failing in the depth mapping process.

[pulquero]

I'll re-run it and put the output here.

[pulquero]

Is there anyway to rerun from after the prematching? I've done a --use-opensfm-pointcloud -r opensfm, but it is tediously redoing all the matching again.

[pulquero]

One dataset worked fine, and gave better results. Second dataset just went quiet - no cpu/io activity for over 12 hours about half way through computing depthmaps. This seems to happen when using a 2 vcpu vm. With a single vcpu, I don't encounter any problems. The depth mapping has giving a lot more detail to the second dataset. An incidentally parked car is now a 3d object rather than just a flat texture. as with pmvs. On the downside, there are a few minor holes where as before there were none.

[dakotabenjamin]

@pulquero I'll look into adding the rerun option. Thanks for the feedback!

[pulquero]

I've re-ran it with more min-num-features, this removed some holes, but also created others. Overall, there are less holes. They seem to be the result of some sort of processing artifact - so it should be something that is fixable within opensfm. Alternatively, could add a hole-filling step before texturing.

[dakotabenjamin]

Is this not more a meshing step problem than opensfm?

I believe there is an way to fill holes using PCL, but I'm having trouble finding the method (their documentation is hard to navigate). Perhaps it wouldn't be hard to write something into the odm_meshing module.

Does increasing --odm_meshing-octreeDepth to 10 or 11 change anything?

[dakotabenjamin]

https://pdfs.semanticscholar.org/1b95/a4e90ef89a5bdf224ade07eac7cb0bd6f717.pdf

[dakotabenjamin]

I'm running into a similar issue as @pulquero where it's frozen at

2017-01-11 20:20:46,390 Cleaning depthmap for image DJI_0095.JPG
2017-01-11 20:20:47,669 Cleaning depthmap for image DJI_0093.JPG

It's currently 2017-01-12 10:52

[triceam]

Possibly related to the thread above, I'm getting out of memory errors using OpenSFM on a machine with 64 Gigs of RAM: https://github.com/OpenDroneMap/OpenDroneMap/issues/453

[pulquero]

Increasing octree depth has had an impact, nearly all those holes have gone, but now the majority of the mesh is covered with micro holes (I assume as a result of decimation?). Differences with before is that now I get "Initial residual too low" warnings, and the mesh is decimated. With the default of 9, no decimation occurs. So far if I try to increase maxVertexCount to avoid decimation with > 9, I get a seg fault during texturing. Maybe I can't have my cake and eat it :(

[triceam]

I have intermittently been seeing segmentation faults too. hadn't spent any time trying to track it down yet, but definitely happens after OpenSFM.

[pulquero]

I have tried with octree depth of 10, no decimation, then loaded the mesh into meshlab, removed any disconnected components, smoothed it, decimated to get a good looking mesh, no holes. Then ran this thru texturing and the rest of the pipeline. The textured mesh has holes in it. In fact, after all that, the final orthophoto had more holes than the original done with 9. So, I think some improvements can be made to meshing, also need to find the cause of the hole creation during texturing. Oh, I also double checked and decimation never caused any holes previously. It is all in the texturing step.

[dakotabenjamin]

I have randomly experienced segfaults during texturing, but long before we added the opensfm dense point cloud generator. So it's probably unrelated.

[dakotabenjamin]

The issues with mvs-texturing may have to be solved here -> https://github.com/nmoehrle/mvs-texturing

[dakotabenjamin]

Opensfm is now default