Intro to photogrammetry

How I ended up here

• I recently had a call with someone worried about the future of OpenSfM - the engine at the heart of OpenDroneMap (ODM), which turns drone photos into maps. Their idea: “why not use COLMAP instead? It’s come a long way and has a big community”.

• At the time I thought OpenSfM was essentially dead upstream, leaving the ODM team to maintain their fork forever. So I went digging into whether COLMAP could replace it.

• And in doing so, I got completely sucked into learning how photogrammetry actually works.

• Plot twist: OpenSfM turned out to be very much alive - a bunch of major upstream improvements started landing right as I began poking around. More on that later.

• But the exploration taught me a lot, so let’s dig in. This post is my attempt to demystify photogrammetry for the layperson (i.e. past-me), then weigh up COLMAP vs OpenSfM for drone mapping specifically.

What even is photogrammetry?

Photogrammetry is the art of turning a pile of overlapping 2D photos into a 3D reconstruction of the world.

In the context of aerial imagery, you can imagine it more like this:

• The trick is the same one your two eyes use for depth perception. Each eye sees a slightly different view, and your brain fuses them into a sense of distance.

• Photogrammetry does this with many “eyes” - dozens or thousands of photos spread out over space (in our case, snapped by a drone flying a grid).

• If the same physical point shows up in several photos taken from different positions, a bit of geometry lets us work out where that point sits in 3D, and where the camera was for each shot.

The pipeline splits into two big stages, worth understanding separately:

1. Sparse reconstruction (Structure-from-Motion): find the camera positions and a rough skeleton of 3D points.
2. Dense reconstruction (Multi-View Stereo): use those camera positions to fill in a detailed surface.

Then downstream tools turn that into the things we actually want: orthophotos (a flat, top-down, distortion-corrected map image) and elevation models. Let’s take each stage in turn.

Stage 1: Structure-from-Motion (the sparse bit)

We hand over a folder of photos; ideally we get back every camera’s position, its lens settings, and a sparse cloud of 3D points. It happens in three steps.

1. Feature detection - find distinctive little landmarks in each photo: corners, textures, anything recognisable again elsewhere. Think of spotting the same chimney or road marking in shot after shot.

2. Feature matching - work out which landmark in photo A is the same landmark in photos B, C, D… This is what links the photos together.

3. Triangulation & bundle adjustment - the big number-crunch. Here’s the catch22: to place a 3D point you need to know where the cameras were, but to know where the cameras were you need 3D points. So the software solves for everything at once - all camera positions and all 3D points together - nudging them until the whole scene is as consistent as possible.

The output is a sparse point cloud - the scene’s skeleton - plus every camera’s pose. Not pretty yet, but the difficult geometry is done.

Incremental vs global

Two strategies for this are available.

• Incremental - add photos one at a time, re-optimising as you go. Robust and accurate, but takes a long time on large image sets.
• Global - solve for all camera poses at once. Scales far better and is dramatically faster. It used to trade away some accuracy, but recent work (GLOMAP, now part of COLMAP) has mostly closed that gap.

COLMAP vs the OpenSfM fork

This was my original question. For drone mapping specifically:

OpenDroneMap’s OpenSfM fork

• 👍 Fast, with ~2× lower memory use - great for the low-spec devices our communities actually use.
• 👍 Loads of drone-specific georeferencing baked in: camera angles, Ground Control Points, flexible coordinate systems (huge credit to YanNoun).
• 👎 Looked dead upstream, meaning maintenance responsibility for the ODM team (since changed!).
• 👎 No real GPU acceleration at the time.

COLMAP

• 👍 Healthy, actively developed, well tested.
• 👍 Global SfM built in, and strong GPU support.
• 👍 Very robust in awkward scenes - ODM is tuned for nadir (straight-down) shots, so COLMAP does better on oblique angles.
• 👎 No native drone georeferencing - all the stuff Yann already solved.
• 👎 Its global pipeline estimates camera parameters differently, and those numbers feed straight into the final map’s accuracy.
• 👎 Real integration effort into the ODM stack.

Stage 2: Multi-View Stereo (the dense bit)

Once SfM has nailed the camera positions, dense reconstruction fills in the detail - going from a sparse skeleton to a dense, photorealistic surface.

Above is the the sparse skeleton from SfM with the dense result below.

In ODM this is currently a separate tool, OpenMVS.

After this, it’s rasterised into the final orthophoto and elevation model.

Could OpenMVS be replaced?

• The most exciting recent OpenSfM news: it’s growing its own dense reconstruction, plus direct orthophoto + elevation output. That could make OpenSfM a single framework for the whole chain - no separate OpenMVS step.
• It’s also gaining OpenCL GPU acceleration. Unlike CUDA, OpenCL supports AMD, Intel and Nvidia, with graceful fallback to CPU when there’s no GPU at all - which matters hugely for mixed, low-spec community hardware.

Where COLMAP falls down here

• COLMAP can also do the dense step, in theory replacing both tools at once.
• But its dense reconstruction is CUDA-only - useless if you don’t have an Nvidia GPU. That rules it out as a general ODM replacement.
• So even in a COLMAP world, it’d only ever replace the sparse step; we’d still need OpenMVS (or future-OpenSfM) for the dense.

Wrapping up: what’s best for what?

• For drone mapping in the ODM/HOTOSM world: the newly revived official OpenSfM is the right tool right now - the drone-specific georeferencing, low memory, CPU fallback, and renewed upstream momentum works across our community of mixed spec devices.
• For difficult, oblique, or non-drone scenes: COLMAP is genuinely excellent and battle-tested. Outside the drone-nadir sweet spot, I would definitely try it out.
• The COLMAP question isn’t dead, just weakened by OpenSfM’s revival. It could still be a future successor - once the georeferencing and camera-parameter issues above are solved. But honestly, I can’t see CUDA being replaced any time soon.

What to watch for

• OpenSfM’s dense + direct-ortho work maturing, potentially collapsing the whole sparse → dense → map chain into one framework.
• OpenCL acceleration landing properly - a big win for anyone without a fancy CUDA card.
• Old-hardware support - I initially worried that moving to pre-built packages would drop support for very old CPUs (no AVX/AVX2). A maintainer kindly set me straight: the Conda packages compile with -march=nocona (a ~2004 baseline, even older than ODM’s old nehalem target) plus -mtune=haswell, which lets newer chips grab some optimisations without breaking backwards compatibility. A couple of forked libs still cap the effective baseline at nehalem - the same as before. So very old hardware should keep working.