With Piero passing the torch for maintenance of the ODM repo in August, we’ve spend some time looking for an appropriate replacement, something I’ve been excited for the org to take on. I thought I could pinch-hit until we could find someone more qualified, especially with some of the great dependency upgrade pull requests we’ve gotten. But, while trying to do that upgrade work, we didn’t stop looking.
To that end, I had a good conversation this past week with Leonardo Urena-Fuentes and Yann Noutary on ODM and OpenSfM maintenance. Leo is willing to hop in on maintenance for both repos starting in the New Year. For context, OpenSfM is the core structure from motion library for ODM and one of the three main photogrammetry libraries that make so much of the magic possible. openMVS and MVS-Texturing being two of the others.
As a former mapillary/OpenSfM contributor, software generalist, and mapping enthusiast, bringing Leo on for this work in ODM is very exciting.
We discussed high-level needs for the project, from bugs and feature improvements including much needed work on GCPs, to performance on smaller machines and larger datasets, to a general need for growth of our testing infrastructure. I’ll also be interested to see what he identifies as challenges and opportunities as he dives in.
Great question! We would love the additional help. Take a look here first for an overview of expectations for contributors. From there, let’s get Leo up to speed shortly and then loop you in.
Quick update:
Spoke again with Leo and Yann yesterday reviewing some of Leo’s initial thoughts on what he sees in both the ODM and OpenSfM repos. @pierotofy – he expressed an interest in reaching out to go a level deeper on the technical side of the project, so expect an email shortly.
Yann reported back on his end-of-break feature-frenzy, looking at GCP corrections, OPK angle for DJI and similarly tagged images, optimizing for memory and speed (with the possibility of 10k images processing through OpenSfM on a 64g machine), quality report work, and possible review of split-merge.
He’ll be putting together a hand-off document for Leo to help with integration of these OpenSfM changes into ODM.
Next steps were a bit similar to the first conversation – find out where the known next needs are in the project, go deeper on the technical side, and start to outline a plan for the two types of testing that might help: basic tests for breaking changes and performance metrics across memory, quality, and speed across versions to aid in pre-testing pull requests.
Perhaps related to the discussion on transparency, I think technical discussions should happen by default on the forum, not behind closed doors via e-mail (unless for valid reasons, e.g. security-related). We have a channel here for this purpose: https://community.opendronemap.org/c/developers-chat/21
I think this applies to discussions for funding projects, research initiatives and roadmaps as well.
I mentioned that as a likely preferred platform for conversation, though something lower latency than forum (such as a call) might be beneficial as a start.