Skip to content

Parallelize the split-merge orthophoto blend loop (single-threaded; complements --merge-skip-blending) #2034

Description

@Chouffe

The split-merge orthophoto merge in opendm/orthophoto.py::merge() runs its block_windows() feather/cutline blending as a single-threaded numpy loop. On large-area surveys this dominates wall-clock while most cores sit idle. (Confirmed single-threaded on v3.5.6 and still on v3.6.0/master.)

Real-world evidence

A 1071-image / 18.7 GB survey at --orthophoto-resolution 1, split into 3 submodels:

Why it's parallelizable

block_windows() are independent output regions — each block reads its source windows, blends, and writes its own dst_window. The read+blend compute can be fanned out across a worker pool (e.g. concurrent.futures), with writes either serialized in the main thread or coordinated per-block (GDAL datasets aren't safe for concurrent writes to one handle). The block-based structure #1934 mentions is already in place.

Relation to #1934

--merge-skip-blending and the planned edge-only blending reduce how much blending happens; this issue is about parallelizing whatever blending remains. They compose. Happy to prototype a PR if there's interest in the approach.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions