Point cloud generation noisy


#1

From @KommandorKeen on Thu Aug 17 2017 07:38:18 GMT+0000 (UTC)

ODM on left colmap on the right.



Copied from original issue: https://github.com/OpenDroneMap/OpenDroneMap/issues/653


#2

I’m waking this up - finding the same thing, I’d call it ‘fuzzy’. I need to look deeper into intermediate products to see if i can find where the fuzz arrives.

OpenDroneMap roof:
05%20am

OpenDroneMap detail - this is a jetty deck, there are a few ’surfaces’ which are not real:

35%20am

In Pix4D, roof:
12%20am

…and jetty deck:
33%20am

notes - this imageset is from sensefly’s demo set (the norwegian lighthouse). I didn’t make the pix4D point cloud, so have no idea what optimisations were applied.

I see the same effects in ODM’s demo datasets. I’ll keep digging, but ideas are welcome!


#3

Keep the documentation coming. There’s work yet to do on the dense point cloud. I’m not clear yet on whether it’s an alignment issue (and therefore in need of greater accuracy in the SfM step that precedes dense point cloud calculation), a post-processing step that should align the different depthmaps, or some other optimization, but documenting the issues is definitely the first step.


#4

Just to verify – this is running the latest master branch or 0.4, correct?


#5

Using dockerised ODM:latest - which looks to be the same as tag 0.4.0:

https://hub.docker.com/r/opendronemap/opendronemap/tags/

(14 days old)


#6

Cool. A current issue then. Thanks!


#7

Is your camera in the lensfun database? If so, it would be interesting to see what a little pre-calibration would do to help reduce this. I don’t think it’s the only issue, but it would be interesting to know whether it has a discernable effect.


#8

If you’re interested in digging deeper, I have a hunch that it has to do with the layering of depth maps during the dense step of opensfm, although now we are running smvs which does things a bit differently. @adamsteer are you running the defaults or using the --use-opensfm-dense option?


#9

Could you share your ply and dem for testing purpose ?


#10

I just used default options:

docker run -it --rm -v $(pwd):/datasets/code opendronemap/opendronemap --project-path /datasets

…i now have an aircraft so I’ll collect some new data, repeat everything with more rigorous calibration and see…

@kikislater yes, I’ll share the data when the tests are done


#11

Point generation oddness happens before georeferencing - here’s a snapshot of the smvs-generated point cloud:

Screenshot%20from%202018-11-26%2007-31-31-smvs

I wonder if it’s a number precision issue - this next image is a bit clearer (from post-georeferencing, but the issue is the same) - with points being shifted onto planes where they might be better distributed (perhaps only in XY?).

Screenshot%20from%202018-11-26%2007-27-19

the source images are arriving here now: https://drive.google.com/open?id=1VBjsj27Vx1QaTqJtH2i4rcgtHU4T1x4n

…and the run command was:

docker run -ti --rm -v $(pwd):/datasets/code opendronemap/opendronemap --project-path /datasets --force-ccd 5.92 --end-with odm_georeferencing

HTH


#12

I’ve just run the calibration steps described here:

…but don’t see where to put the resulting matrix and distortions. ?? I’ll read agin, but pointers welcome!


#13

Interesting. If it is a precision issue, then I wonder if you strip out the exif tags, if you get a better point cloud. We minimize the precision issues by translating the dataset to local coordinates, but perhaps it’s not enough for SMVS.


#14

That would explain too why SMVS compares favorably to other techniques in the literature but seems to underperform in our use of it.


#15

no exif == better: same images, same run command, exif stripped

Screenshot%20from%202018-11-26%2016-34-28

still a kind of ‘thick’ surface (~2cm scatter afaict)


Orthophoto and 3D distorted in 95% overlap dataset
#16

Looks like precision is an issue. Just to double check – can you run with the original version with the following flag: --matcher-neighbors 30?

This will help establish what the effect is of the default matcher-neigbors (since you have 29 images, this will force everything into one model).


#17

Also, just to get a sense of the magnitude of the error in the better version: of you run through to orthophoto, what do you get for your GSD?


#18

@pierotofy – you might be interested in the above (likely) precision issues.


#19

OK, running with a new set of 99 images (same location), all the way to orthophoto. Results soon!


#20

Cool. It will be interesting to see that run the various ways, including matcher-neighbors at 99 (memory / processor time willing).