Updated October 2026: This guide has been corrected. WebODM is a separate project from OpenDroneMap, and its processing options belong to ODX, its own engine (forked from ODM). We also corrected the matcher-type default (it’s now auto), dropped the deprecated depthmap-resolution option, noted that WebODM’s Default preset already builds a DSM, removed an unsourced GPU speedup claim, and replaced an unsourced claim that feature counts above 20000 add noise and hours of processing with guidance based on ODX’s own option description.
You just processed 400 images through WebODM with default settings. The orthophoto looks soft, the point cloud is sparse, and the DTM has holes where your client’s building pad should be. You ran the job overnight, waited eight hours, and the output is barely usable.
The defaults are a compromise. WebODM’s engine (ODX) ships settings that finish in reasonable time on modest hardware without crashing. That’s not the same as settings that produce deliverable-quality outputs. The difference between a mediocre result and a professional one lives in about a dozen parameters — and knowing when each one actually matters.
feature-quality, pc-quality, mesh-size, smrf-*, and the rest live. Screenshot from the WebODM project’s repository (now WebODM/WebODM), used under AGPL-3.0.How ODX Processing Works — The 60-Second Version
Before adjusting anything, understand the pipeline. ODX, WebODM’s engine (forked from ODM), processes images through a fixed sequence of stages:
- Feature extraction — identifies distinctive points in each image
- Feature matching — finds corresponding points across overlapping images
- Sparse reconstruction — builds a rough 3D point cloud from matched features
- Dense reconstruction — generates depth maps and a dense point cloud
- Meshing — creates a 3D surface mesh from the dense cloud
- Texturing — drapes imagery onto the mesh
- Georeferencing — applies coordinate reference system
- DEM generation — produces DSM and/or DTM rasters
- Orthophoto generation — creates the final orthorectified mosaic
Every parameter controls a specific stage. Cranking everything to “ultra” doesn’t make the output better — it makes stages 1-4 take 10 times longer while stages 7-9 produce identical results. Target the bottleneck, not the whole pipeline.
The Parameters That Actually Matter
feature-quality
What it does: Controls the resolution at which feature extraction runs. Options: ultra, high, medium, low, lowest. Default: high.
When to change it: Features are the anchor points that stitch your images together. If your dataset has poor overlap (below 70% frontal), bumping to ultra can recover matches that high misses. If overlap is solid (80%+), high is sufficient — ultra doubles memory consumption for marginal gains.
The real impact: Moving from high to ultra on a 500-image dataset adds 15-30 minutes of processing time. Moving from high to medium saves roughly the same. On well-flown missions with 80% frontal / 70% side overlap, I’ve never seen a measurable accuracy difference between high and ultra in the final orthophoto.
min-num-features
What it does: Sets the minimum number of features to extract per image. Default: 10000.
When to change it: Increase to 15000-20000 for featureless terrain — agricultural fields, water bodies, snow cover, dense uniform canopy. These landscapes don’t produce many natural keypoints, and the default extraction count may not find enough matches.
Leave it alone when: Your site has buildings, roads, varied vegetation, or any visual complexity. More features on already-rich imagery just increases matching time without improving alignment.
Common mistake: Setting this to 50000 because someone on a forum said “more is better.” ODX’s own help text for this option says more features can help find matches between images, and that more features also slow down processing. On imagery that already matches well, a very high value mostly buys you a longer run. For difficult terrain, try 15000-20000 first, and only go higher if a test run on a subset of your images shows better alignment.
matcher-type
What it does: Selects the algorithm for matching features across image pairs. Options: auto, flann, bow, bruteforce, hamming. Default: auto, which picks flann when your images carry GPS, bow when they don’t, and the GPU-only hamming matcher when ODX has an NVIDIA GPU and at least 32 images.
The tradeoffs:
| Matcher | Speed | Reliability | Best For |
|---|---|---|---|
| flann | Medium | High | General use — most datasets |
| bow | Fast | Medium | Large datasets (1,000+ images), quick previews |
| bruteforce | Very slow | Highest | Difficult scenes, low overlap, critical accuracy |
| hamming | Fast on large datasets | — | Requires a GPU; auto picks it on GPU machines |
When to change it: Switch to bow for datasets over 1,000 images where processing time matters more than squeezing out every match. Switch to bruteforce only when flann fails to reconstruct parts of your scene — you’ll know because chunks of your orthophoto will be missing or misaligned.
I use flann for 95% of jobs. The only time I switch to bruteforce is when a corridor mission (road, pipeline, power line) has alignment gaps — the linear geometry makes matching harder, and brute force recovers the missed connections.
pc-quality (Point Cloud Quality)
What it does: Controls the density of the dense point cloud reconstruction. Options: ultra, high, medium, low, lowest. Default: medium.
This is the single most impactful parameter for processing time. Each step up roughly quadruples computation time (ODX’s own option help says the same). A 500-image dataset that takes 2 hours at medium takes 8 hours at high and roughly 32 hours at ultra. Real-world jumps can be even steeper — one user reported 9.5 hours at high versus 81 hours at ultra on a 1,308-image dataset. That’s an 8.5x increase.
When to use each level:
- lowest/low: Quick site check, same-day turnaround, verifying coverage before leaving the field
- medium: Standard deliverable — orthophotos, volumetric calculations, general mapping. This is the sweet spot for 90% of commercial work
- high: Survey-grade point clouds, detailed 3D models, construction monitoring where you need to measure fine structures
- ultra: Photogrammetric research, cultural heritage documentation, sub-centimeter dense cloud requirements. Rarely justified for commercial projects
The uncomfortable truth: For orthophoto-only deliverables, medium and high produce visually identical results. The dense cloud gets projected down to a 2D mosaic — all that extra density gets averaged away. Save high and ultra for when the point cloud itself is the deliverable.
depthmap-resolution (deprecated)
What it does: Nothing anymore. ODX lists depthmap-resolution as deprecated: if you pass it, the log warns that it is no longer a valid argument and will be ignored. ODX now sets the depth map resolution from pc-quality.
What to do instead: If you want a denser point cloud, raise pc-quality. If you see this option in an old forum post or preset, delete it.
mesh-size
What it does: Sets the maximum vertex count of the 3D mesh. Default: 200000.
When to change it: Increase to 300000-600000 for urban scenes where you need accurate building and rooftop geometry in the 3D model. For rural terrain mapping where the mesh is just an intermediate step to the orthophoto, the default is fine.
Common mistake: Setting mesh-size to millions of vertices for a flat agricultural field. The mesh reconstruction will try to honor that vertex budget, creating unnecessary detail on flat ground while burning memory. Match the complexity to the terrain.
mesh-octree-depth
What it does: Controls the level of detail in 3D mesh reconstruction. Higher values produce finer detail. Default: 11. Range: 1-14.
When to change it: Increase to 12-13 for complex urban scenes or cultural heritage documentation where building edges and fine structures matter in the 3D model. Decrease to 9-10 for terrain-only work.
Each increment roughly doubles the face count. Going from 11 to 13 quadruples mesh complexity and the associated processing time.
DEM and Terrain Parameters
dsm and dtm Flags
What they do: --dsm generates a Digital Surface Model (includes buildings, trees, everything). --dtm generates a Digital Terrain Model (bare earth only). ODX builds neither unless you ask for it. In WebODM, the built-in Default preset already turns on dsm, but not dtm — add dtm yourself or pick the DSM + DTM preset.
Common mistake: Processing an entire dataset, realizing you forgot --dtm, and reprocessing from scratch. Use --rerun-from odm_georeferencing (in WebODM: Restart > From Georeferencing) instead. The DTM is built from ground-classified points, and ODX runs that SMRF classification in the georeferencing stage, not in odm_dem — so rerunning from odm_dem alone skips it. This still reuses the dense reconstruction and saves hours.
dem-resolution
What it does: Sets the output resolution of DEM rasters in cm/pixel. Default: 5 (5 cm/pixel). ODX caps this value at its own GSD estimate, so asking for finer than your GSD doesn’t get you finer output.
When to change it: For survey-grade topographic work, match this to your GSD or slightly coarser. If you flew at 2.5 cm GSD, a dem-resolution of 2.5-5 is appropriate. Forcing it below your GSD (with --ignore-gsd, which ODX’s own help tells you not to use) creates false precision — a smooth interpolation that looks detailed but contains no real elevation data below your capture resolution.
For volumetric calculations on stockpiles, 5 cm is typically sufficient. For grading plans and construction monitoring, 2-3 cm captures meaningful surface variation.
dem-gapfill-steps
What it does: Number of progressive DEM layers used to fill gaps. Default: 3.
When to change it: Increase to 4-5 for urban scenes where the SMRF filter removes buildings and leaves large holes that need interpolation. In forested areas, increasing this helps fill gaps beneath canopy where ground points are sparse.
smrf-scalar
What it does: Scaling value for the Simple Morphological Filter used to classify ground points for DTM generation. Default: 1.25.
When to change it: Increase for terrain with significant height variation — hilly sites, bluffs, steep slopes. A value of 1.5-2.0 handles moderate terrain; 2.5+ for mountainous areas. If your DTM has artificial plateaus where the filter clipped real terrain features, the scalar is too low.
smrf-slope
What it does: Slope tolerance (rise over run) for ground classification. Default: 0.15.
When to change it: Increase to 0.3-0.5 for steep terrain where the default rejects actual ground points on slopes. If your DTM shows jagged artifacts on hillsides, the slope tolerance is too tight.
smrf-threshold
What it does: Minimum height (in meters) expected for non-ground objects. Default: 0.5.
When to change it: Increase to 1.0-2.0 if low vegetation (shrubs, tall grass) is being classified as ground and creating bumpy DTM surfaces. Decrease to 0.3 for flat sites where even small objects (curbs, survey markers) should be filtered.
smrf-window
What it does: Window radius (in meters) corresponding to the largest feature to be removed. Default: 18.0.
When to change it: Increase to 25-30 for sites with large buildings or tree stands. If buildings are punching through your DTM as ground, the window is too small to capture their footprint.
| Terrain Type | smrf-scalar | smrf-slope | smrf-threshold | smrf-window |
|---|---|---|---|---|
| Flat open field | 1.25 | 0.15 | 0.5 | 18 |
| Gentle rolling hills | 1.5 | 0.25 | 0.5 | 18 |
| Urban with buildings | 1.25 | 0.15 | 1.0 | 25 |
| Steep forested terrain | 2.0 | 0.5 | 1.5 | 25 |
| Mountain / canyon | 2.5 | 0.8 | 2.0 | 30 |
Orthophoto Parameters
orthophoto-resolution
What it does: Sets the output orthophoto resolution in cm/pixel. Default: 5 (5 cm/pixel).
When to change it: Match this to your GSD. If you flew at 2 cm GSD, set orthophoto-resolution to 2. ODX caps this value at its GSD estimate, so a finer setting just comes back at roughly your GSD; forcing past the cap with --ignore-gsd creates upsampled pixels — sharper-looking but not more accurate. Setting it coarser than your GSD discards real data.
For deliverables: Most clients expect orthophotos at native GSD. Construction monitoring at 1-2 cm, general site mapping at 3-5 cm, large area surveys at 5-10 cm.
crop
What it does: Automatically crops the orthophoto by creating a boundary buffer shrunk by N meters from the dataset edge. Default: 3.
When to change it: Set to 0 to disable cropping if you need full edge-to-edge coverage. Increase to 5-10 if edge distortion is unacceptable — the periphery of any photogrammetric reconstruction is the weakest area, and cropping removes the worst of it.
fast-orthophoto
What it does: Skips dense reconstruction and 3D model generation entirely. Generates an orthophoto directly from the sparse reconstruction.
When to use it: Field verification — process on a laptop at the site to confirm coverage before packing up. Same-day client previews. Any scenario where you need a quick look and don’t need point clouds, meshes, or DEMs.
Processing time impact: 5-10x faster than a full pipeline run. A 400-image dataset that takes 3 hours normally finishes in 20-30 minutes.
What you lose: Point cloud, 3D mesh, DSM, DTM, and some orthophoto accuracy in areas with significant elevation change. The sparse reconstruction doesn’t correct for terrain displacement as well as the dense pipeline.
Three Presets for Real Work
Preset 1: Fast Preview
Use this at the field site on a laptop to verify coverage before you leave.
--fast-orthophoto
--feature-quality low
--orthophoto-resolution 10
--crop 0
Processing time: ~15-30 minutes for 400 images on a modern laptop. What you get: A rough orthophoto to confirm full coverage and check for obvious gaps. Not deliverable quality — just a sanity check before you drive two hours back to the office.
Preset 2: Standard Deliverable
This is what I run for 90% of commercial mapping jobs — orthophotos, volumetrics, site documentation.
--dsm
--dtm
--feature-quality high
--pc-quality medium
--orthophoto-resolution 2
--dem-resolution 5
--mesh-size 200000
--crop 3
Processing time: Rough estimate, not a benchmark: ~2-4 hours for 400 images on a workstation (32GB RAM, 8-core CPU). What you get: Clean orthophoto at native GSD, usable DSM/DTM, adequate point cloud for volumetric calculations. Professional quality for most client deliverables.
Preset 3: Maximum Accuracy Survey
For survey-grade work, construction monitoring with sub-centimeter requirements, or detailed 3D documentation.
--dsm
--dtm
--feature-quality ultra
--pc-quality high
--min-num-features 12000
--orthophoto-resolution 1.5
--dem-resolution 2
--mesh-size 600000
--mesh-octree-depth 12
--crop 5
Processing time: Rough estimate, not a benchmark: ~8-16 hours for 400 images on a workstation. What you get: Dense point cloud suitable for cross-sections and detailed measurement, high-resolution DEMs for grading analysis, sharp orthophoto. This is what goes to the surveyor or engineer.
Note: I don’t use pc-quality ultra in production. The jump from high to ultra adds 4-8x processing time for diminishing returns that rarely justify the overnight compute. If you need ultra-dense point clouds, consider whether LiDAR is the right tool instead.
Common Mistakes That Waste Time or Degrade Quality
Running ultra everything on a standard mapping job. The most common waste. pc-quality ultra with feature-quality ultra on a 500-image dataset can run for 3-4 days. The orthophoto won’t look meaningfully different from high/medium. Match parameters to deliverables.
Forgetting —dsm or —dtm. ODX doesn’t generate DEMs unless asked. WebODM’s Default preset turns on --dsm, but not --dtm. Discovering this after a 6-hour processing run means either reprocessing or using --rerun-from odm_georeferencing (for a forgotten --dtm, odm_dem is too late a starting point — ground classification happens in georeferencing) — which at least saves the dense reconstruction. Learn this once, remember it forever.
Forcing orthophoto-resolution finer than GSD. ODX caps orthophoto-resolution at its GSD estimate, so on a 3 cm flight a setting of 1 comes back at about 3 cm anyway. Override that with --ignore-gsd and you get a larger file with interpolated pixels. No additional detail. The camera captured 3 cm — the software can’t invent what isn’t there.
Ignoring SMRF parameters for DTM work. The defaults work for flat, open terrain. Anything with significant vegetation, buildings, or slope variation needs tuned SMRF values. A DTM full of artifacts is worse than no DTM — your client will measure wrong elevations from it.
Using —split on small datasets. The --split parameter divides large datasets into chunks for processing. On datasets under 500-800 images, splitting adds overhead and can create visible seam artifacts at chunk boundaries. Only use it when you need it — typically 1,000+ images or when memory is the constraint.
Not using —rerun-from when iterating. If you’re adjusting DEM or orthophoto parameters, you don’t need to reprocess the entire pipeline. --rerun-from odm_dem regenerates DEMs and orthophotos from the existing point cloud — enough for dem-resolution or dem-gapfill-steps changes. If you forgot --dtm or changed any smrf-* value, use --rerun-from odm_georeferencing: ODX classifies ground points there and skips reclassification on an odm_dem rerun. --rerun-from odm_meshing regenerates everything from the mesh stage forward. This turns a 4-hour reprocess into 20 minutes.
Hardware Considerations
Processing parameters don’t exist in isolation — they interact with your hardware. General guidelines (dataset sizes follow WebODM’s documented RAM estimates, which the docs call conservative):
| RAM | Max Comfortable pc-quality | Typical Dataset Size |
|---|---|---|
| 16 GB | medium | Up to 250 images |
| 32 GB | high | Up to 500 images |
| 64 GB | high | Up to 1,500 images |
| 128 GB | ultra | 2,000+ images |
GPU acceleration: ODX supports NVIDIA CUDA GPU acceleration. On Linux, start WebODM with ./webodm.sh start --gpu (or run the standalone webodm/odx:gpu image with --gpus all); Windows builds include GPU support by default. ODX doesn’t publish which stages speed up or by how much, so benchmark on your own data.
Storage: A single processing run with pc-quality high on 500 images generates 20-40 GB of intermediate files. Budget accordingly and clean up old runs.
ODX’s default settings are designed to finish without crashing on average hardware. They’re not designed to produce your best work. But “best” doesn’t mean cranking every slider to maximum — it means matching parameters to your deliverables, your terrain, and your hardware.
For most commercial mapping: feature-quality high, pc-quality medium, orthophoto and DEM resolution matched to your GSD, and properly tuned SMRF values if you need a DTM. That combination produces professional deliverables in 2-4 hours on a workstation.
Save the ultra settings for when the point cloud itself is the product. Save the fast preset for field verification. And always — always — use --rerun-from when you’re iterating on DEM or orthophoto parameters. The hours you save will pay for themselves by the end of the first week.