Related threads:
Context
- I recently had a call with someone who was worried about the future of OpenSfM and said “why not use COLMAP instead? It’s come on a long way from it’s research-focused origins, and has a big community”.
- Now if you haven’t seen OpenSfM torch passing , I would recommend reading it first for context. Yann has done some really excellent work keeping OpenSfM up to date & alive!
- COLMAP recently absorbed a separate project, GLOMAP, so global SfM now lives inside COLMAP itself (more on that below).
- Now take all that I say with a pinch of salt, as I probably don’t have all the context, and sparse point clouds are far from my area of expertise, but as far as I see it we should make a decision between (1) maintaining the OpenDroneMap fork of OpenSfM for our needs (2) integrating COLMAP as an alternative to OpenSfM in the pipeline.
What Exactly Can COLMAP Do?
- COLMAP is able to replace both OpenSfM (sparse/SfM) and OpenMVS (dense) in the OpenDroneMap pipeline (in theory), as it handles both.
- It has excellent support for GPUs via CUDA (+ Ceres + cuDSS).
- What looks like two primary maintainers, with many additional community members pitching in.
- Unfortunately the dense reconstruction part is CUDA-only (GPU), ruling it out for integration into OpenDroneMap (as an alternative to OpenMVS). So realistically this is only about COLMAP as an OpenSfM replacement (the SfM/sparse step) & we would still use OpenMVS for dense.
Comparing The Two
OpenSfM Fork
Pros:
- Fast, with a ~2× memory reduction: great for low-spec devices.
- Loads of drone-georeferencing work already built in: OPK angles, pyproj-based GCPs, non-UTM/EPSG support, and a revamped GCP weighting scheme (all from Yann).
Cons:
- The upstream is dead, meaning it lands on the OpenDroneMap team to maintain it going forward.
- The speed/memory gains are confirmed on Linux, but we aren’t sure about native Windows/Mac usage.
- No CUDA integration: Yann tried GPU matching (RAPIDS cuVS on a 5090) and got only ~20% over FLANN+24 cores, deeming it not worth it.
COLMAP
Pros:
- Healthy community, actively developed.
- Global SfM now built-in via
global_mapper. “Global” means it solves for all camera poses at once (rotation + position averaging) instead of adding images one at a time like the classic incremental mapper. In practice this scales far better and is dramatically faster on large image sets, where the incremental approach slows to a crawl. Global methods used to trade some accuracy/robustness for that speed, but GLOMAP’s main achievement closed most of the gap without sacrificing reliability. - Very robust and well tested, giving accurate results in difficult scenes. OpenSfM/ODM is tuned for nadir drone imagery, so COLMAP tends to do a bit better on oblique and awkward shots.
- Can really leverage GPU if enabled.
Cons:
- Some key technical barriers before this can be considered. See NOTE2 below.
- Higher peak memory on large areas due to global SfM. CPU-only pipeline is its weakest mode: needs benchmarking against OpenSfM fork.
- Integration effort into OpenDroneMap stack.
What Should We Do?
- I’m really interested to hear anyone in the community weigh in here
Especially @DodgySpaniard as the new maintainer (if any time to review this) - I hope it’s helpful! - I think we really need to evaluate the maintenance effort for our OpenSfM fork.
- If my opinion matters: one path we could opt for is (1) adopt the new OpenSfM fork right now as the primary approach (2) plan for COLMAP integration, as a possible successor to the OpenSfM fork.
NOTE1: while changes like this will modernise ODM, making it faster and more resource efficient, it will also likely break support for processing on very old hardware. Those devices would likely have to use ODM versions < v3.5.6.
NOTE2: technical limitations of COLMAP:
-
No native drone georeferencing: all the stuff Yann solved already. COLMAP is a general-purpose engine and probably won’t integrate this… so we need a solution there.
-
A key thing to work out related to the global pipeline, which estimates the camera parameters (focal length, lens distortion, etc) differently from the incremental pipeline. Practically, those numbers feed straight into the ortho and elevation model, so we can’t guarantee the same georeferenced/GCP accuracy as the OpenSfM pipeline for now. We would need to verify this all matches up nicely, or implement some fixes.
-
In the linked thread above, @StonerLing already tested swapping in COLMAP to ODM, but got a visibly wrong orthophoto, despite the reconstruction working fine. This was the result of COLMAP and OpenSfM not placing the image “centre” in the same place, and the rest of ODM assumed OpenSfM’s convention, so the final map came out distorted. We would need to adapt for this.
Doh