Hi all,
I’ve got ODM building using an Ubuntu 24.04 docker image. You can see the changes I’ve made here: 24.04 by NathanMOlson · Pull Request #1 · NathanMOlson/ODM · GitHub
Going through this migration effort, I noticed that ODM uses forked versions of several other open source projects. In several of these cases, changes I made to support the migration have already been made upstream.
Would this project be open to migrating to use upstream repositories for some/all of these dependencies? The amount of effort varies from project to project, from trivial (draco, untwine) to substantial (OpenSfM, entwine). I can help make progress in this direction if the maintainers are amenable.
I personally would love to use more upstream repositories (would save us the headaches of maintaining forks). In most cases, the reason we made a fork is because there was some tweak that was useful/necessary for ODM, but probably would not have been accepted upstream due to the specificity of the tweak. In some projects (like OpenSfM) we deviated significantly because we added new features and fixes (and Meta has showed little interest in accepting outside contributions).
There’s also the issue that in more than a few instances, upstream decided to yank releases or git tags, which caused our build to stop working, so I’ve found it sometimes easier to keep a fork and update our fork when we’re ready to update, but that’s been project dependent and thankfully most projects do not randomly yank releases.
If there are some projects (e.g. entwine, untwine) which can be migrated to using upstream, the first step would be to look at the changes (if any) that might have been added to our forks and port those upstream and we’d love help with that.
Welcome!
Echoing Piero, this would be amazing.
Also curious: did you notice any performance improvements by upgrading to 24.04 due to the newer Python version? I’ve heard that the newer versions should be faster, but a few people reported the opposite (for other applications at least). The opensfm stage would be the one most affected for benchmarking purposes.
Nice! I took the liberty of opening it as a pull request on a 24.04 branch on ODM, just to kick off a build and start testing on github once it’s conflict free. In the meantime, I’ll kick off a local build and start testing.
To echo Piero – some vendoring is going to be necessary, but a reduction in vendoring is most appreciated. In addition to what Piero has highlighted, if memory serves, there’s a fair amount of change in MVS-Texturing in addition to OpenSfM. So, now that ODM is building for you, it might be useful to look at the changes to those OpenDroneMap forks and port those changes to more recent versions where appropriate, whether those ports are things that are appreciated upstream or things we’ll need to continue to keep in our own repos.
More as I dive in.
It’s not apples-to-apples, given upstreaming to e.g. MVS-Texturing without some of the texturing mods, but given testing on odm_data_toledo and Brighton Beach, I would say no change in speed:
Brighton Beach, 24.04:
real 3m27.216s
user 0m0.088s
sys 0m0.101s
Brighton Beach, ODM Latest:
real 3m31.080s
user 0m0.080s
sys 0m0.115s
Toledo, 24.04:
real 22m11.890s
user 0m0.237s
sys 0m0.285s
Toledo, ODM Latest:
real 22m16.645s
user 0m0.282s
sys 0m0.228s
Unsurprisingly, missing MVS-Texturing features specific to orthophotos:
But a fairly functional 24.04 upgrade is no small feat. Thanks for starting this @NathanMOlson!
Now that a pull request is open on ODM, perhaps we continue the conversation there?
(Edit, looking at just OpenSfM stage we see the following:
Just OpenSfM: 4m02s for Toledo with 24.04 and 4m10s for ODM:latest)