DEM/mesh generation is orders of magnitude slower when outliers inflate the point-cloud extent

[yuiseki]

Thanks for ODM! I've been running a very cheap toy drone (Holy Stone HS156, 99 g) through the pipeline as part of UN Open GIS Initiative DWG7 (context: UNopenGIS/7#921) and hit a performance problem worth reporting.

How did you install ODM? (Docker, installer, natively, ...)?

Docker (opendronemap/odm:latest), reproduced on 3.6.2.

What is the problem?

create_dem() (opendm/dem/commands.py#L68) rasterizes the raw bounding box of the point cloud, so a few gross SfM/MVS outliers (common on weak-baseline / low-overlap / non-nadir captures) can inflate the raster by orders of magnitude. The cost scales with extent, not point count.

Real example (31 geotagged images, weak baseline): the filtered cloud spans 5431 × 6515 m although the real scene is ~76 × 79 m (1st to 99th percentile), giving a ~39-gigapixel DSM raster. On 3.6.2, create_dem takes ~604 s (gdal_translate 193 s + fastrasterfilter 324 s on the inflated raster; renderdem is 5.5 s on LAZ but 446 s on the PLY that odm_meshing actually uses). A comparable 25-image set (27 MP raster) finishes in seconds despite a near-identical point count.

renderdem's maxTiles guard is disabled for geotagged photos (odm_meshing.py#L63, odm_dem.py#L79). This looks like the same "weak reconstruction, untrustworthy scale" family as #2054, on the DEM/mesh side.

How can we reproduce this?

Self-contained script (uses only numpy/pdal/opendm from the image); it builds an 80 × 80 m scene plus a few flyers a couple of km away and runs the real create_dem() with and without them:

docker run --rm -v "$PWD":/w --entrypoint python3 \
    opendronemap/odm:latest /w/reproduce_dem_outlier_blowup.py

On 3.6.2: WITH flyers (0.015% of points) → 3321 MP, create_dem 69.7 s; WITHOUT → 2.6 MP, 0.6 s.

Script and a 3 MB real-cloud sample: http://z.yuiseki.net/static/tmp/github/odm/ (note: renderdem alone on LAS/LAZ skips empty tiles quickly, so drive the full create_dem chain).

What should be the expected behavior? ...

A few outliers should not blow up the raster.

Proposed fix: in create_dem(), crop the cloud to a robust percentile window before renderdem, but only when the raw extent is both far larger than the robust one and large in absolute terms (quickinfo is checked first, so normal data is never even sampled).

Measured: create_dem 604 → 3.5 s, odm_meshing 1225 → 27 s, output mesh essentially unchanged; no false positives on 800 m uniform / transect / L-shaped surveys.

Trade-off: two genuinely separate survey areas km apart could be cropped (guarded and warned; normally handled by --split).

Reference implementation with a unit test: yuiseki/ODM:fix/dem-outlier-safe-extent . Happy to open a PR.

AI disclosure

Per CONTRIBUTING (Use of AI): I used an AI coding assistant to help profile the pipeline, take the measurements above, and draft this report and the reference branch. I directed the investigation and verified the numbers and behavior myself. Happy to discuss.

[smathermather]

Thanks @yuiseki,

This is an ongoing challenge with some datasets for sure.

---

This might be better to fix upstream of the problem. I think the excess point cloud noise was introduced with this pull request:
https://github.com/OpenDroneMap/ODM/pull/1754/changes

If you patch stages/openmvs.py line 99 with

                f.write("Optimize = 7\nMin Views Filter = 2\n")

or

                f.write("Optimize = 7\n")

does that alleviate the issue for your test datasets?

---

On the possibility of a pull request and our AI policy, how much of the possible PR was AI-assisted? (check one)

• 0 - No AI at any point
• 1 - AI helped me think, but I wrote all the code myself
• 2 - I planned the change and decided the approach; AI helped write the code
• 3 - AI planned and wrote it; I checked and approved each step as it went
• 4 - I set the AI going and left it to it; I reviewed the finished result
• 5 - I set the AI going and left it to it; nobody has read the result - no review, or AI review only

(Thanks to @spwoodcock for the framing)

[spwoodcock]

I think I have also experienced similar. Does using the --boundary flag with a geojson constrained to the AOI solve it?

It would be pretty nice to solve this automatically though, as proposed, instead of relying on user knowledge / config

[yuiseki]

Thanks @smathermather @spwoodcock!

Tested both on the 31-image set (rerun from openmvs, 3.6.2, GPU), measuring the odm_filterpoints extent:

• Min Views Filter = 2: still ~6.4 x 9.9 km
• Optimize = 7 only (revert Use min views filter = 1 #1754): 3 runs gave 147 x 110 m, then 2528 x 2973 m, then 1172 x 781 m

So:

• densify is non-deterministic here; extent isn't reliably bounded
• the flyers look multi-view-consistent, not single-view noise
• reverting Use min views filter = 1 #1754 helps (less noise, often smaller) and seems worth doing
• but on its own it didn't prevent the blowup in my runs

A downstream guard still looks useful as a backstop: robust extent in create_dem, or stronger outlier removal in odm_filterpoints. Happy to go either way.

AI use: ~3 (I set the goal/approach and reviewed each step; the assistant wrote the code and ran the measurements).