Problem and use case
Please add an orthophoto workflow that uses depth maps → DSM → orthophoto without constructing a fused dense photogrammetric point cloud.
My use case is aerial RGB mapping with a DJI Matrice 400 / Zenmuse L3: 1,940 images from its two RGB cameras (12288 × 8192 pixels), targeting a 3 cm/pixel orthophoto. I do not need a photogrammetric point-cloud deliverable. The scene includes buildings and vegetation, so a surface derived only from sparse tie points is not an equivalent replacement.
The request is to avoid the dense-cloud intermediate computation/storage, not merely hide its download. Depth estimation and multi-view consistency checks would still be needed. Reduced processing time, peak RAM and temporary disk usage are goals to benchmark, not assumed results.
Requested workflow
RGB images → feature extraction and matching → camera alignment / bundle adjustment → undistorted images + calibrated camera poses → depth-map estimation and consistency filtering → tiled fusion directly into a DSM / height field → image orthorectification, visibility selection and blending → georeferenced orthophoto (+ optional DSM).
No fused dense PLY/LAS/LAZ cloud should be required on this path. Sparse tie points and temporary per-tile 3D samples are compatible with the request; avoiding a persistent or full-scene dense cloud is the objective.
Current implementation context
The current ODX pipeline connects dense reconstruction, cloud-based surface generation and mesh-based orthophoto rendering:
I understand that most of the implementation would belong in ODX and its processing-node integration, with WebODM exposing the capability. Please transfer or link this request to the appropriate backend tracker if preferred.
Possible implementation approach — for discussion
-
Separate depth estimation from dense-cloud fusion. Retain reusable depth maps and their validity/consistency information. Investigate the bundled OpenMVS depth-map-only execution path rather than assuming that skipping cloud export alone removes fusion.
-
Add a tiled depth-map-to-DSM stage. Back-project valid depth pixels using the matching undistorted camera intrinsics, poses and depth convention, then accumulate observations directly into bounded-memory raster tiles. Handle local reconstruction coordinates, CRS transforms, offsets and vertical reference consistently. Use tile halos and deterministic overlap handling.
-
Resolve visibility and conflicting heights. Use cross-view consistency, support counts and confidence/geometry weights where available. Preserve the supported visible upper surface at roofs and canopy; avoid simply averaging across roofs and ground, or taking an unfiltered maximum. Retain NoData for unsupported regions and make hole filling explicit. This is a DSM, not a classified bare-earth DTM.
-
Reuse downstream rendering where practical. An initial implementation could convert the DSM directly to a gridded 2.5D mesh and reuse existing texturing/orthophoto rendering, without creating a dense cloud. A later direct raster orthorectifier could project DSM cells into the source images, reject occluded views and perform seam selection/blending. The RGB values must come from the photographs.
-
Make downstream stages cloud-optional. Adapt georeferencing, bounds, reports, postprocessing and asset discovery so they do not require point-cloud files or statistics. Preserve restart/caching semantics and split/merge alignment, including consistent transforms across submodels.
WebODM options and compatibility
Expose an explicit, opt-in surface-source choice when the node supports it, for example orthophoto-surface: depthmaps (illustrative name, not an existing option). Keep existing defaults unchanged.
Document how depth-map quality, DSM cell size and orthophoto pixel size interact. Keep this distinct from fast-orthophoto, which uses sparse reconstruction, and skip-3dmodel, which does not eliminate the dense-cloud intermediate.
Validate incompatible requests such as dense-cloud exports/classification and explain the supported alternative. Do not silently switch back to dense-cloud generation. External DSM import can remain a separate feature.
Validation / acceptance criteria
- Produce an orthophoto and optional DSM without generating a fused dense-cloud intermediate.
- Test roof edges, vegetation, flat terrain and overlapping images from two RGB cameras.
- Compare identical alignments and depth quality against the existing pipeline: elapsed time per stage, peak RAM/VRAM, temporary disk use, coverage/NoData, DSM height differences and orthophoto seam/edge displacement; use independent checkpoints where available.
- Verify reproducible tiled output, split/merge seams, correct georeferencing and restart after depth-map calculation.
- Keep the existing dense-cloud workflow working unchanged.
Submission context
This is a feature proposal, not an implemented or benchmarked patch. It has not yet been discussed in the community. AI assistance (Codex) was used to inspect the current source and draft/submit this issue at the user's explicit request; preparation took approximately 5–10 minutes, not instrumented.
Problem and use case
Please add an orthophoto workflow that uses depth maps → DSM → orthophoto without constructing a fused dense photogrammetric point cloud.
My use case is aerial RGB mapping with a DJI Matrice 400 / Zenmuse L3: 1,940 images from its two RGB cameras (12288 × 8192 pixels), targeting a 3 cm/pixel orthophoto. I do not need a photogrammetric point-cloud deliverable. The scene includes buildings and vegetation, so a surface derived only from sparse tie points is not an equivalent replacement.
The request is to avoid the dense-cloud intermediate computation/storage, not merely hide its download. Depth estimation and multi-view consistency checks would still be needed. Reduced processing time, peak RAM and temporary disk usage are goals to benchmark, not assumed results.
Requested workflow
RGB images → feature extraction and matching → camera alignment / bundle adjustment → undistorted images + calibrated camera poses → depth-map estimation and consistency filtering → tiled fusion directly into a DSM / height field → image orthorectification, visibility selection and blending → georeferenced orthophoto (+ optional DSM).
No fused dense PLY/LAS/LAZ cloud should be required on this path. Sparse tie points and temporary per-tile 3D samples are compatible with the request; avoiding a persistent or full-scene dense cloud is the objective.
Current implementation context
The current ODX pipeline connects dense reconstruction, cloud-based surface generation and mesh-based orthophoto rendering:
I understand that most of the implementation would belong in ODX and its processing-node integration, with WebODM exposing the capability. Please transfer or link this request to the appropriate backend tracker if preferred.
Possible implementation approach — for discussion
Separate depth estimation from dense-cloud fusion. Retain reusable depth maps and their validity/consistency information. Investigate the bundled OpenMVS depth-map-only execution path rather than assuming that skipping cloud export alone removes fusion.
Add a tiled depth-map-to-DSM stage. Back-project valid depth pixels using the matching undistorted camera intrinsics, poses and depth convention, then accumulate observations directly into bounded-memory raster tiles. Handle local reconstruction coordinates, CRS transforms, offsets and vertical reference consistently. Use tile halos and deterministic overlap handling.
Resolve visibility and conflicting heights. Use cross-view consistency, support counts and confidence/geometry weights where available. Preserve the supported visible upper surface at roofs and canopy; avoid simply averaging across roofs and ground, or taking an unfiltered maximum. Retain NoData for unsupported regions and make hole filling explicit. This is a DSM, not a classified bare-earth DTM.
Reuse downstream rendering where practical. An initial implementation could convert the DSM directly to a gridded 2.5D mesh and reuse existing texturing/orthophoto rendering, without creating a dense cloud. A later direct raster orthorectifier could project DSM cells into the source images, reject occluded views and perform seam selection/blending. The RGB values must come from the photographs.
Make downstream stages cloud-optional. Adapt georeferencing, bounds, reports, postprocessing and asset discovery so they do not require point-cloud files or statistics. Preserve restart/caching semantics and split/merge alignment, including consistent transforms across submodels.
WebODM options and compatibility
Expose an explicit, opt-in surface-source choice when the node supports it, for example orthophoto-surface: depthmaps (illustrative name, not an existing option). Keep existing defaults unchanged.
Document how depth-map quality, DSM cell size and orthophoto pixel size interact. Keep this distinct from fast-orthophoto, which uses sparse reconstruction, and skip-3dmodel, which does not eliminate the dense-cloud intermediate.
Validate incompatible requests such as dense-cloud exports/classification and explain the supported alternative. Do not silently switch back to dense-cloud generation. External DSM import can remain a separate feature.
Validation / acceptance criteria
Submission context
This is a feature proposal, not an implemented or benchmarked patch. It has not yet been discussed in the community. AI assistance (Codex) was used to inspect the current source and draft/submit this issue at the user's explicit request; preparation took approximately 5–10 minutes, not instrumented.