I’ve been experimenting with ODM in order to map a pixel I’ve selected within one of my source
images right through to a corresponding pixel in the orthophoto that ODM has produced from the
This has involved some coding to get OpenSfM to read the ‘reconstruction’ created by ODM. The code:
(1) computes a 3D ‘odm_texturing’ mesh coordinate for the selected pixel (the tricky bit).
(2) converts this 3D coordinate to a lat/long/alt with OpenSfM’s ‘to_lla’ function.
This process worked very well up to just after ODM v2.4.1 (specifically commit c87c21d); with an
accurate mapping from source pixel to orthophoto pixel.
Up until commit 602089d (just after release v2.4.1) everything seems fine, but a few commits later
(specifically a build at commit c87c21d) I run into difficulty. The mesh file that I have relied upon so
far (odm_texturing_25d/odm_textured_model.obj) is no longer produced by ODM. There is another
mesh file (odm_texturing_25d/odm_textured_model_geo.obj) which, pre ODM v2.4.1, I found did not
produce the correct (pixel<->mesh mapping through OpenSfM). I have tried to use this file again
since the other mesh file is now gone, and something has changed: in newer ODM releases I now get
the correct pixel<->mesh mapping from this file, but the lat/long/alt computed by OpenSfM for a
mesh coordinate is not correct. The error is in the order of a few meters.
The discrepancy is reproducible on the ‘Brighton Beach’ and the ‘Aukerman’ test data sets (see
GitHub - OpenDroneMap/ODMdata: Example data for OpenDroneMap: https://OpenDroneMap.org sourced from a variety of sources), where the error is around 1-2m. Also, the discrepancy
can be reproduced with the standard ODM command line given on the ODM web page.
I have plotted the error for a set of points across the orthophoto - it appears that there is a
rotation of the orthophoto in comparison with the underlying geographic information provided by
OpenSfM - so the extent of the error changes over the orthophoto.
My questions are:
(a) does this mean that the orthophoto produced since commit c87c21d has a slight geographic
(b) is there a workaround?
Steps to create the issue:
(1) Run ODM using default parameters on an test image set - such as ‘Brighton Beach’.
(2) Load the mesh odm_texturing_25d/odm_textured_model_geo.obj into a mesh viewer (I used CloudCompare). Now, identify some unique feature in the mesh and note its 3D coordinate (CloudCompare displays the coordinate when the left mouse button is double clicked to re-centre the rotation origin).
(3) Find the feature located in step 2 in one of the images given to ODM, making note of the image name.
(4) Write a python script to use OpenSfM to convert the 3D coordinate found in step 2 to a pixel coordinate for the image found in step 3. The code should use the ‘project’ method for the ‘shot’.
(5) Load the image found in step 3 into an image viewer (e.g. GIMP) and check that the pixel coordinate from step 4 agrees with the feature found in step 2. This shows that we have the correct 3D mesh coordinate to move to the next step.
(6) Write a simple python script to use OpenSfM to convert the 3D coordinate found in step 2 into a lat/long/alt. The code should use the ‘to_lla’ method on the ‘reference’.
(7) Load the ortho-photo produced by ODM into google-earth and add a marker for the lat/long from step 6. The marker is not placed accurately on the feature originally identified back in step 2. This is the error. Note: some imagery does not import well into google-earth gdallocationinfo may be a better alternative.