3 December 2021 02:50
I have been using ODM for two years for agricultural images stitching.
I often find an obvious shift on the output orthophoto, and I thought it was because the GPS information was inaccurate, so I always manually georeference the output tif files.
However, recently I found out that the GPS information was actually very accurate.
If I just rotate the images by their Yaw angle ( the drone was flying horizontally and the camera was set to take photos straight down, so I don’t need to worry about Roll and Pitch angles ) and resize them by their height so that each pixel was in their exact physical size on the map, and put them onto google map, I will find them locating on the exact place they should be, as the following two photos show:
So, what is the reason that ODM often tend to shift a bit? (By saying often, I mean sometimes it works well, by in most cases it will shift)
I was using a DJI Mavic 2, and I didn’t set any weird ODM parameters, I just chose fast-orthophoto.
I have found that my simple method always result in a better location accuracy.
If your GPS accuracy is good, try setting
0.1 (by default it’s
3 December 2021 04:48
Thanks! I will have a try.
Are you certain that Google Maps is 100% accurate in your location? It generally isn’t.
OpenSfM now supports SfM using direct-aerotriangulation given GPS and OPK angles (though EXIF reading remains to be added, for DJI drones for example).
Do you have a dataset to share for us to investigate why accuracy isn’t good with ODM (and potentially add OPK DJI readings to test with direct triangulation) ?
Wow, just tried running the triangulation algorithm and I’m really, really excited about the runtimes!
I’m going to add some code for reading the camera angles.
Does it really help the solution that much? That’s so cool!
Maybe I can close this soon thanks to Yann and Piero:
12:49AM - 07 Nov 20 UTC
Does OpenSFM take advantage of extra EXIF information such as GPS Img Direction,
… GPS Image Direction Ref, and User Comment (Yaw, Pitch, Roll) to help with the processing and reconstruction?
OpenCamera, for instance, can optionally write these parameters, which in addition to normal GPS EXIF for lat/long/elevation, you get heading and orientation as Yaw/Pitch/Roll.
Let's say you get those orientation values from the flight log of a sUAS, and join them to the images in pre-processing. Wouldn't that help with matching and reconstruction?
To me, this seems like a great bit of extra data to use.
Yep I think that can be closed; there’s support for omega/phi/kappa angles, I just need to tie it in in ODM. (Work in progress
sheffield cross processed in record times using the new triangulation algorithm:
27m57.882s (on my slow 4 core laptop) (from 173 images to orthophoto using
This is going to really help agricultural datasets.
I’ve added the OPK logic in ODM (we skip the
extract_metadata command in ODM since we create the
exif folder directly), but I’d be happy to port it to the
extract_metadata command in OpenSfM and open a PR if there’s interest (@YanNoun) ?
That is incredible! That’s a pretty hefty dataset depending upon settings!
This is awesome news ! OpenSfM would love to have few snippets of codes to get OPK angle in the EXIFs !
matching_graph_rounds combined with OPK usually provide dramatic speed-ups and excellent matching !
Any chance to share the dataset somewhere ?
If you mean that Sheffield’s Cross dataset Piero benched with, it is in our ODMDATA Repository:
13 January 2022 02:07
Hello, guys. I have tried reducing the --gps-accuracy parameter, and it did improve a bit, but still not as good as expected.
Here is the dataset : my coor shift dataset
I’m wondering if it is because the Mavic Zoom (FC2204) isn’t in upstream OpenSFM quite yet…
This is good, I have to make the sensor profile entry for another user anyway.
12 February 2022 03:18
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.