Where 44 minutes goes: one flight, timed stage by stage

Seventy-seven photos, one 8-core machine, three engine settings. The stage-by-stage clock, the one same-dataset GPU number that exists, and what it takes to run the alternatives.

Every photogrammetry vendor says it is fast. Almost none say fast at what, on which images, on what hardware. So here is one dataset run seven times with a stopwatch on every stage, and the honest gaps left as gaps.

The flight

The public Aukerman set: 77 nadir photos at 18 MP, about 1,390 megapixels in total, GPS in the EXIF, no ground control, no RTK. It is the dataset the OpenDroneMap community uses for its own benchmark table, which is exactly why we chose it — it is the one flight where a same-engine, same-settings number from other hardware already exists.

Machine: one AWS r6i.2xlarge — 8 vCPU, no GPU — with 14 GiB allotted to the job, the plane every flight runs on today. Engine: OpenDroneMap 3.5.6, the same version as production. Timings are wall-clock per stage from the job log, in minutes.

Three settings, stage by stage

Full run is the production default: every deliverable, engine defaults. Fast, complete is the same five deliverables with the dense stage at low depth-map resolution, the geometric-consistency pass off and the mesh textured once — it needed 28 GiB to finish and its outputs are still being scored against the full run, so it is not a plan option yet. Ortho only skips dense reconstruction entirely and builds the orthophoto and elevation models from the sparse cloud: no point cloud, no real mesh, five times faster.

Read the first table column and one thing is obvious: dense reconstruction is 55% of the run and texturing is another 17%. Everything else together is under a quarter. Any speed claim in this industry is a claim about those two stages.

Then we gave it a card

Later the same day AWS granted the GPU quota, and the identical flight ran with identical settings on a g4dn.2xlarge: eight CPU cores and one NVIDIA T4. Nothing else changed except the engine build, which had to move from 3.5.6 to 3.6.2 because the GPU image only exists from 3.6.1.

Read the middle column against the right one and the story is exact. The dense stage fell six-fold, from 24 minutes to 4. Every other stage got slower, because the GPU machine's CPU cores are an older generation than the CPU plane's. The net is one and a half times faster at the same price per flight, and the GPU plane has been the production default since that afternoon.

We also tried the GPU feature detector, which takes four more minutes off. It is not shipped: its map sits about fifteen centimetres sideways from the baseline, because a different detector gives a different camera solve, and a map that no longer lines up with your previous flight is a worse product than one that takes four minutes longer.

Was the fast map the same map?

Speed measured on a different output is not a benchmark, so we compared the GPU elevation model against the CPU one over their 35 million overlapping pixels. Half agree within 6 centimetres and two thirds within 25, but a fifth differ by more than a metre, which looked alarming until we ran the control: two CPU-only runs of this flight with different settings disagree with each other by exactly the same amount. Those pixels are tree canopy and roof edges, which resolve differently on every run of any engine. The GPU output is in fact closer to the original than the CPU shortcut settings were.

The one same-dataset number that exists

The first two rows are from the community odm-benchmarks table, same images, same engine, same settings. A consumer RTX 3060 is a faster card than the T4 in a g4dn, and that desktop's CPU is faster than ours, so a further gap remains and it is hardware. Closing it is a matter of which instance we rent, and we will publish the number when we measure it.

What the alternatives need from you

We have not timed DJI Terra, PIX4Dmatic or Metashape on this flight, and no peer-reviewed study puts Terra and ODM on the same dataset. The published literature is consistent that desktop engines with a GPU finish sooner than CPU ODM, and on one 1,039-image set the ODM orthophoto was judged equal in quality. What can be stated exactly is what each one requires, from its own documentation and store on 8 September 2026.

DJI's photogrammetry licence is quoted on enquiry in most regions, so no figure is given rather than a guessed one. Prices are list, USD, before tax, and will drift; the requirement rows change less often.

The counterweight

Speed is not the whole story, and it would be dishonest to leave it there. In the one recent controlled comparison with surveyed checkpoints, ODM's absolute error came out roughly twice Metashape's — about 7 cm against 4 cm on nadir imagery. That is why the accuracy section of this site publishes no centimetre claim for a controlled flight, and why the measurement engine refuses to report a figure the data cannot support. Being fast is a graphics card. Being right about what you cannot know is the product.

Reproduce it: the Aukerman images are public, OpenDroneMap is free, and the three settings above are --fast-orthophoto, and --pc-quality low --skip-geometric --use-3dmesh, against defaults. If your numbers disagree with ours, we would like to hear it.