OpenDroneMap DEM Improvements


We have some remarkable improvements in the pipeline for digital elevation models. You can check out a teaser of these in this blog post:

Now we need your help! Throw some datasets at the proposed changed version and give us feedback on what works and doesn’t: The pull request for that can be found here:



Orthophoto and 3D distorted in 95% overlap dataset
Point cloud generation noisy

Will be testing in the upcoming days. :+1:

Who else will join the quest and earn eternal glory in the history of ODM?


Got time @adamsteer? :smiley:


yup - been flat out tidying up a workshop for release, and one more job I actually get paid for, then I’ll get into this later this week. MVE was actually on my list of things to hash together outside of ODM. Just reading the PR, I move soooo sloooowly compare to the ROW… :confused:


I built a docker image from @smathermather-cm’s branch, and tested it out briefly. There’s something awry with how PDAL works with the data - the original MVE ply file looks pretty good, but as soon as it’s turned to LAZ or georeferenced there are precision issues. Suspect it’s just a matter of using the correct scale factors - more as soon as my machine finished up a couple of big long jobs and I can throw more imagery at it…


Ok more playing, something is up with georeferencing - here’s a point cloud after the georeferencing step - looks like there’s still a scale or number size issue:


here is a clip from the untransformed PLY:


…compared to (a commercial package), it’s missing a lot of detail in the bushes - or even SMVS. It seems ‘sharper’ but not sure about ‘better’.

I’ll do some testing with ‘nicer’ image geometries. This dataset has a camera moving from overhead to ‘front on’ in one flight and isn’t very rigorous…


It’s the same in other opensource photogrammetry software :

High coordinates lose precision. Solution is to shift coordinates to temporary arbitrary coordinates system near to zero like a lot of softwares


That means we’re doing something wrong in PDAL: las and laz files have offsets in the specification specifically to address this.

@adamsteer, can you confirm whether you’re seeing this in the laz file or the ply?


It depends highly upon use case and context. Frankly, mve is much better for drone data in the testing I’ve done so far, but it may be worse (wrt completeness and other factors) for non-drone datasets.

And this may be the argument for keeping SMVS around – it runs faster and it might be more useful for non-drone datasets.


Make sure the software you are using to display the point cloud supports offsets. Not all of them do. The “stripes” are due to the UTM coordinates not being properly centered around the offset. Don’t use .PLY, use .LAZ or .LAS.


just had a giant facepalm moment - in CCompare, I haven’t been applying an offset to visualise points. sigh

I never screw up, but when I do it’s spectacular and public.


Here 's the same dataset after georeferencing, with the offset removed in cloudcompare:


I’m also processing another dataset - all overhead shots of trees - I’ll keep tinkering with both MVE and SMVS to see if I can capture the vegetation a bit better - and otherwise shut up for a while.

(btw this was a drone dataset, just with the ability to look upward with the camera also)


Cool. Well it would be great to know if we’re loosing a lot of vegetation by switching libraries. And we’ve all been there before with public posts!