Discrepancy between mesh coordinate conversion with "to_lla" in OpenSfM and the orthophoto geo


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
source images.

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.

1 Like

Probably related: coords.txt is in int, but opensfm reference is in lat,lon (float) · Issue #1244 · OpenDroneMap/ODM · GitHub

1 Like

Hi Piero

Thanks for your response. I have previously looked at issue #1244, but I have observed errors or more than 1 meter - could these be explained by this issue? Also, the error I’m observing is not a simple translation of the underlying geo that, perhaps naively, I’d expect from using a rounded reference point: the error is not constant throughout the orthophoto, but changes gradually over the orthophoto (and looks like a slight rotation of the geo).

1 Like

#1244 should be solved with Embed GCP information in outputs by pierotofy · Pull Request #1318 · OpenDroneMap/ODM · GitHub (just now), so perhaps try to update in a few hours and reprocess. We now set our own reference LLA, although the errors you’re seeing might be caused by other problems (are you using ground control points? If not, georeferencing errors are expected).

1 Like

Hi, Sorry for the delay in responding to the last post.

I am not using ground control points, so I really don’t expect the geographic information to be true at this point. What I’ve observed had appeared to be more of an internal inconsistency and unrelated to true geographic location. Having said this, I’m now starting to suspect I just need an additional transformation to the data in odm_texturing_geo.obj (which I hope ODM can provide) to correct the apparent issue.


In ODM 2.4.1 I could select a 3d point from viewing odm_texturing.obj and use OpenSfM to both (a) correctly find the point in a source image and, (b) obtain a lat/long (OpenSfM “to_lla”) for the point that agreed very well with the orthophoto produced by ODM. Since ODM 2.4.1, odm_texturing.obj is no longer produced and only odm_texturing_geo.obj is available. When using the 3d points in this “_geo” file, I no longer get lat/longs that agree with the orthophoto.

Patch #1318:

For small reconstructions, your patch seems to have reduced the inconsistency. Thank you.

For larger reconstructions (of around 1km across) the inconsistency largely remains, and looks very much like a rotation needs to be applied to the lat/longs I get from OpenSfM to match the orthophoto. (I have observed a set of points cutting East→West through the centre of my reconstruction. On the East side I get a 6m relative error (mapping pointcloud→orthophoto) to the North and on the West side a 6m relative error to the South. Further, there appears to be a linear relationship between Easting and the error in Northing, with an error close to zero at the reconstruction’s centre.)

I suspect the patch improved the geographic mapping for my smaller reconstructions because the point I pick is (necessarily) geographically close to the reconstruction’s centre - and is little effected by the rotation I have observed, as is close to the centre of the rotation.

Possible fix?:

I now suspect that OpenSfM’s “to_lla” method is only valid for points within “odm_orthophoto.obj” and not for “odm_orthophoto_geo.obj”, and that some transformation has occurred to create the “_geo” file of which OpenSfM is unawares. I hope that I could recover accurate pointcloud → orthophoto mapping if I could either
(a) obtain the details of the transformation from odm_orthophoto.obj→odb_orthophoto_geo.obj to invert it, or,
(b) obtain the odm_texturing.obj (as in ODM <= 2.4.1) file.

Is either (a) or (b) available somewhere, or is a fix possible to provide either? If you can point me at where in the code to start looking that would be great too.

Thanks again for all your help and let me know if you need any further help identifying the problem.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.