Skip to content

[Bug / Regression] OpenSfM altitude sampling defaults to 1.0m on DJI RTK nadir dataset in ODX 3.8.0, breaking SfM #2052

Description

@PLSomebody

Description

A critical regression in ODX 3.8.0 (OpenSfM) causes the altitude sampling grid search to hit a boundary on a standard DJI RTK nadir dataset (74 images), erroneously defaulting to 1.0mspan_0span_0span_1span_1. This completely breaks the SfM topology, leading to a flipped Z-axis, negative GSD, and single-line camera alignmentspan_2span_2span_3span_3. The exact same dataset processed perfectly in ODX 3.7.4span_4span_4.

Sample Image EXIF Context

Log Comparison

  • ODX 3.7.4 (Successful Run)span_8span_8:

    [INFO] Altitude for orientation based matching 5118.677506227718
    [INFO] Reconstruction 0: 74 images, 97232 points
    
  • ODX 3.8.0 (Failed Run)span_9span_9span_10span_10:

    [INFO] Minimum found at sampling altitude 1 with size 69315.9719507554
    [INFO] Altitude extrema is at the boundary of search space. Using default altitude of 1.0
    [INFO] Altitude for orientation based matching 1.0
    ...
    [WARNING] Shots and/or GCPs are aligned on a single-line. Using vertical prior
    [WARNING] Negative GSD estimated, this might indicate a flipped Z-axis.
    

Note: Activating --force-gps does not bypass this issue, as the error occurs during the initial feature matching stage, before georeferencing takes placespan_11span_11.

Expected Behavior

OpenSfM should use the accurate XMP/GPS altitude tags from RTK-enabled DJI drones to seed the orientation-based matching altitudespan_12span_12, rather than forcing an unrealistic 1.0m fallback when the grid search failsspan_13span_13span_14span_14.

Environment

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