# Should ODM adopt COLMAP as an OpenSfM alternative?
**URL:** https://community.opendronemap.org/t/should-odm-adopt-colmap-as-an-opensfm-alternative/26826
**Category:** ODM
**Tags:** optimization
**Created:** [July 17, 2026, 4:24pm UTC](https://community.opendronemap.org/t/should-odm-adopt-colmap-as-an-opensfm-alternative/26826 "2026-07-17T16:24:06Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@spwoodcock](https://community.opendronemap.org/u/spwoodcock)
#### Post date: [July 17, 2026, 4:24pm UTC](https://community.opendronemap.org/t/should-odm-adopt-colmap-as-an-opensfm-alternative/26826/1 "2026-07-17T16:24:06Z")
Related threads:
> [@Question about using COLMAP's SfM in ODM pipeline](https://community.opendronemap.org/t/question-about-using-colmaps-sfm-in-odm-pipeline/23323):
>
> When I attempted to use COLMAP in ODM instead of OpenSfM, I performed undistortion on the reconstructed data and exported the undistorted reconstruction files to the NVM format. However, I noticed that the undistortion results differed from those of OpenSfM, and the final digital orthophoto map (DOM) was incorrect. Upon investigation, I realized that COLMAP’s undistorted camera model includes a principal point, whereas OpenSfM assumes the principal point to be the image center. To address this,…
> [@WebODM vs ColmapCL](https://community.opendronemap.org/t/webodm-vs-colmapcl/8846):
>
> Today I took many photos with my phone on a site, I ran them through WebODM and ColmapCL. WebODM’s result was really bad, points under ground and totally of. ColmapCL did really well here, very smooth. I wonder what they do differently, is it that WebODM is angled towards nadir images and ColmapCL isn’t?
> [@A new WebODM node. NodeCM](https://community.opendronemap.org/t/a-new-webodm-node-nodecm/4979):
>
> A GPU-enabled photogrammetry pipeline to generate georeferenced point clouds, orthophotos and elevation models from aerial images using COLMAP. Not ready for production and everyday use, but it’s a start… and it works! slight_smile I recommend building your docker images if you’re going to try it! I haven’t perfected the build process for all mainstream CPUs yet so the prebuilt image might not work well for your system.
## 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](https://community.opendronemap.org/t/opensfm-torch-passing/25781) , 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:
1. 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.
2. 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.
3. 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.
---
### Author:  [@spwoodcock](https://community.opendronemap.org/u/spwoodcock)
#### Post date: [July 18, 2026, 9:35am UTC](https://community.opendronemap.org/t/should-odm-adopt-colmap-as-an-opensfm-alternative/26826/2 "2026-07-18T09:35:34Z")
I think I have been a little out of the loop 😅
After posting this, I found:
> **[GitHub - OpenSfM/OpenSfM: Open source Structure-from-Motion pipeline and...](https://github.com/OpenSfM/OpenSfM)**
>
> Open source Structure-from-Motion pipeline and More
And also this post!
> [@OpenSfM 1.0](https://community.opendronemap.org/t/opensfm-1-0/26803):
>
> Upstream major changes to OpenSfM now landing. Release for OpenDroneMap timing to be announced: Very exciting times. I did some testing of the changes a couple days ago, just swapping out the OpenSfM changes to the structure from motion portion into the existing pipeline, and we see remarkably better camera pose estimations as shown by the extra detail we get in the dense output, check out the cross members we can now see in this pedestrian bridge now: [animated\_bridge]
Which suggests OpenSfM development is alive and well now! 🙌 Doh
The question still stands if we should support COLMAP at some point, but the case to push it forward is weakened by these recent OpenSfM developments.
---
### Author:  [@YanNoun](https://community.opendronemap.org/u/YanNoun)
#### Post date: [July 18, 2026, 7:39pm UTC](https://community.opendronemap.org/t/should-odm-adopt-colmap-as-an-opensfm-alternative/26826/3 "2026-07-18T19:39:19Z")
Yeah, OpenCL, Dense and 2.5D (ortho+dsm) under the same umbrella.
---
### Author:  [@spwoodcock](https://community.opendronemap.org/u/spwoodcock)
#### Post date: [July 18, 2026, 11:20pm UTC](https://community.opendronemap.org/t/should-odm-adopt-colmap-as-an-opensfm-alternative/26826/4 "2026-07-18T23:20:38Z")
Thanks for clarifying Yann! That’s really useful context 🙏
For those not as well versed in SfM pipelines (like me), I just wanted to elaborate on your points a little (building the case for OpenSfM vs COLMAP for this use case):
- **OpenCL** : alternative GPU acceleration to CUDA, giving support for AMD, Intel, and Nvidia GPUs (not NVIDIA-only).
- **Dense** : OpenSfM can be a single framework to handle both sparse and dense reconstruction (currently we need an additional tool, OpenMVS, for the dense).
- **2.5D** : orthophoto + digital surface model generation could also be handled by OpenSfM, instead of relying on ODM code to rasterise the dense cloud into a DSM + ortho.
This all makes a lot more sense to me now.
---
### Author:  [@Saijin\_Naib](https://community.opendronemap.org/u/Saijin_Naib)
#### Post date: [July 21, 2026, 6:48am UTC](https://community.opendronemap.org/t/should-odm-adopt-colmap-as-an-opensfm-alternative/26826/5 "2026-07-21T06:48:36Z")
> [@spwoodcock](#):
>
> - **OpenCL** : alternative GPU acceleration to CUDA, giving support for AMD, Intel, and Nvidia GPUs (not NVIDIA-only).
And critically, fallback to acceleration on CPU devices as well when a suitable GPU is not present.
---
### Author:  [@system](https://community.opendronemap.org/u/system)
#### Post date: [August 20, 2026, 6:49am UTC](https://community.opendronemap.org/t/should-odm-adopt-colmap-as-an-opensfm-alternative/26826/6 "2026-08-20T06:49:05Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.