Hello everyone, it’s been a while since my last post.
Issue
In my latest processing, I noticed something unusual.
While the GCP accuracy in the report and per-image view looks excellent, in QGIS I’m seeing about a 20 cm offset (as visible in the image below).
It does sound like the same issue reported in the pull request.
Having spent a lot of time fixing this on Lightning, the problem is two-fold:
The stats are generated in topocentric coordinates, but once rigidly transformed to UTM, the result can shift slightly over large areas.
No support for CRS other than UTM. Ideally everything should be in the same CRS as your GCP points.
If you can share your dataset I’d be happy to process this on Lightning to confirm that this is indeed the issue.
p.s. another possible source of error is the choice of vertical datum. ODM always expects ellipsoidal elevation values in meters. Survey equipment often uses a different vertical datum. Make sure your GCP Z values are in meters above the ellipsoid.
Did you also processed a pointcloud? If so, you could check where your gcp is located there… I sometimes experienced gcp-offset in the orthophoto compared to the report due to image-artefacts in areas of low overlap. But when checking the pointcloud data the gcp-center was actually at the right spot..
Here an example of measuring a 2m bar in orthophoto (measured in QGIS: 1.91 m long) and in a pointcloud (measured in CloudCompare: 1.9995m long) of the same dataset / processing run.
In the link Piero posts above we see the challenge with rigid transformations. As UTM is the only CRS supported in OpenSfM, any other CRS needs transformed to UTM and back, which I’d hazard creates some particular challenges with non-reversible transformation, especially since we use proj4 which doesn’t have the better transformations of current proj.
Quick question to better understand the next steps on this topic.
From what I understand, Lightning already includes a fix for the georeferencing / topocentric → UTM transformation issue. I also noticed there is a PR in “Draft” state on the ODM repository that seems related.
My doubt is: will the approach in that PR eventually bring the same improvements that Lightning currently has, or is it a different solution altogether? I’m asking because I’d like to test this more thoroughly on other datasets I have, especially since I currently process most of my work locally using NodeODM.
And just to be clear: I really appreciate all the work being done here. I know this is open-source and everyone is volunteering their time, so I’m not trying to “push” or ask for anything rushed. If there’s a way for me to help (testing datasets, validating results, documenting, or contributing in any small way), I’m more than happy to do that.
Sorry if I’m mixing things up between Lightning and ODM, just trying to understand how the pieces fit together.
Kind of, but not fully. There’s two part to the problem.
Processing in topocentric coordinates
Support for non-UTM coordinate systems
The PR has a draft for beginning to fix the first problem, but the more difficult part is the second. Fixing the first will start to improve results though, so it’s a good start.
And just to be clear: I really appreciate all the work being done here. I know this is open-source and everyone is volunteering their time, so I’m not trying to “push” or ask for anything rushed. If there’s a way for me to help (testing datasets, validating results, documenting, or contributing in any small way), I’m more than happy to do that.
You’ve done everything right and thanks for reporting the issue, providing a dataset and offering to help.
At this moment, it’s a matter of priorities. OpenDroneMap has/is a 501(c)(3) organization with the declared mission of “Enabling monitoring and observations of the world through free and open source geospatial and non-geospatial technology. OpenDroneMap develops and designs affordable, open, and locally sustainable technological solutions to measure, monitor and understand complex environmental processes and for scientific and educational purposes.” and it has (should have?) the revenue to directly fund these kind of improvements. But I don’t know what all the development priorities are, or what the budget looks like and if funds have been allocated to fix this issue. I’m not on the board, and there’s little/no publicly available information, aside from these topics, but it looks like it’s not on the radar.
Yeah, to properly solve the problem, I suppose there should be some bigger code structural change(which can be a lot of work), for example, other software usually stores everything in topocentric internally and only the export stage would generate the assets with the CRS user specified, in metashape, one must specify the CRS to export DSM/orthophoto to guarantee the correctness.
I can provide help and finish my PR(which I don’t know what’s the plan to move forward with it) with my free time, but I do think it’s better to have some discussions to design a proper plan before starting anything.
Thanks Piero, really appreciate the clarification and all the background you shared.
By the way, I’d be glad to get more involved on the developing side as well. I’m not a core developer, but I do have some basic/intermediate Python skills and have been using ODM/WebODM quite extensively for professional projects, so I’m familiar with the workflows and pain points.
If there’s anything where I could help (testing, validating, writing docs, reviewing behavior on different CRS scenarios, maybe helping with Python parts, etc.), I’d be more than happy to contribute a bit of my time. Also open to join discussions / planning if that helps move things forward.
Just let me know what the best way would be to start getting involved.
GCPs and mappings is made in EPSG:28992 )
