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

[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.0m. This completely breaks the SfM topology, leading to a flipped Z-axis, negative GSD, and single-line camera alignment. The exact same dataset processed perfectly in ODX 3.7.4.

Sample Image EXIF Context

GPS Status: RTK / RtkAlt

Absolute / Relative Altitude: +244.578m / +63.119m

Gimbal Pitch Degree: -90.00° (Nadir)

Log Comparison

ODX 3.7.4 (Successful Run):

[INFO] Altitude for orientation based matching 5118.677506227718
[INFO] Reconstruction 0: 74 images, 97232 points

ODX 3.8.0 (Failed Run):

[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 place.

Expected Behavior

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

Environment

OS: Linux 6.12.76-linuxkit (aarch64)

Hardware: 18 cores / 94.12GB RAM

Dataset: 74 DJI Nadir Images (-90° gimbal pitch)

[YanNoun]

@pierotofy normally, we use the Relative Altitude tags.

@PLSomebody can you share a dataset ?

[PLSomebody]

Sure. Here you have the dataset:
https://1drv.ms/f/c/5d2c9763428f912b/IgBRmpETOWkmTKrHfWYnt1PqAfAKyG3899cR9YECp6utZ80?e=gZVY01

[pierotofy]

I think ODX fails to account for OpenSfM/OpenSfM@b8fa6f7 since it does its own EXIF parsing.

And yes a dataset would help confirm the fix.

[pierotofy]

Although this should only affect pairs selection. The flipped-Z axis might be due to something else.

Did you process using the default settings?

My results with default: report.pdf

[PLSomebody]

I was trying to use Default, Buildings, Forest, Field - all with the same result - on 3.7.4 it works without problems. On 3.8.0 everything is broken.

[PLSomebody]

My result for default:
Siedlecka-17072026-Default-report.pdf
And console:
Siedlecka-17072026-Default-console.txt

[pierotofy]

Mm. correctly importing the relative altitude values does not fix the problem for ODX (docker), although it improves pairs selection.

Edit: can reproduce on Windows too.

[PLSomebody]

I'm working on Mac so Docker one.

[pierotofy]

I think it's due to the final alignment align_reconstruction --> compute_reconstruction_similarity --> detect_orientation_prior which relies on OPK angles, but I'm going to guess those are probably incorrect since extracting reliable OPK data is a nightmare.

[PLSomebody]

Any solution?

[YanNoun]

So, on current OpenSfM master, results are excellent :

report_good.pdf

So, I've de-activated the use of EXIF tags relative_latitude AND before the YPR fix of 2 weeks ago (OpenSfM/OpenSfM@b29b0f6). I can't repro either, alignment is decent, even with wrecked OPK :

When looking at the matching, it seems that the regression is caused by https://github.com/OpenSfM/OpenSfM/commit/b29b0f635afd144999d003b1c840bc8fe139d917) :
Before the fix (broken YPR in v1.0) :

2026-07-18 20:53:22,361 INFO: GPS split: 74 ref with GPS, 0 ref without GPS, 74 cand with GPS, 0 cand without GPS
2026-07-18 20:53:22,364 INFO: Minimum found at sampling altitude 1 with size 69721.72724072411
2026-07-18 20:53:22,364 INFO: Altitude extrema is at the boundary of search space. Using default altitude of 1.0
2026-07-18 20:53:22,364 INFO: Altitude for orientation based matching 1.0

After the fix :

2026-07-18 20:53:52,415 INFO: GPS split: 74 ref with GPS, 0 ref without GPS, 74 cand with GPS, 0 cand without GPS
2026-07-18 20:53:52,418 INFO: Minimum found at sampling altitude 6576 with size 69315.97195067041
2026-07-18 20:53:52,418 INFO: Refined altitude extrema at 6596.3345621454955

So the broken YPR is definitely at play here.

Here is the config.yaml I used (OpenSfM template) : https://github.com/OpenSfM/OpenSfM/blob/master/configs/aerial.yaml

And the corresponding EXIF I have (for DJI_20260717145432_0001_V.JPG.exif) :

{
    "make": "DJI",
    "model": "M4E",
    "width": 5280,
    "height": 3956,
    "projection_type": "brown",
    "focal_ratio": 0.7055211384469696,
    "orientation": 1,
    "capture_time": 1784300072.0,
    "gps": {
        "latitude": 52.17765569444444,
        "longitude": 22.072274611111112,
        "altitude": 244.578,
        "latitude_std": 0.00204,
        "longitude_std": 0.00309,
        "altitude_std": 0.00664
    },
    "relative_altitude": 63.119,
    "opk": {
        "omega": -5.186041339876311e-16,
        "phi": 3.4698129741664424e-15,
        "kappa": -81.4994005965235
    },
    "camera": "v2 dji m4e 5280 3956 brown 0.7055"
}

[PLSomebody]

How can I upgrade to SFM Master then?

[pierotofy]

I need to work on YPR normalization and build a serious database. Parsing of YPR values seems incorrect in ODX for this dataset.

DJI_20260717145432_0001_V

  "yaw": 81.7,
  "pitch": 0,
  "roll": 180,
  "omega": -180,
  "phi": 4.78193391133772e-15,
  "kappa": 149.62772528866068,

In the meanwhile, I've temporarily disabled fit_plane_from_opk and forced a fallback to estimate_ground_plane as part of #32 until I can get a better fix.

report.pdf

Ref #3

[pierotofy]

Like, why the f is drone-dji:GimbalRollDegree="+180.00" ? Upside down camera? 😆

It shouldn't even be possible according to DJI's specs:

DJI Matrice 4E
Gimbal Mechanical Limits:
Tilt: -140° to 50°
Roll: -52° to 52°
Pan: -65° to 65°
Soft Limits:
Tilt: -90° to 35°
Roll: -47° to 47°
Pan: -60° to 60°

Fun part is, I will find out that this only happens on certain firmware versions. Good luck normalizing that. Maybe I'll just start a list of models that cannot be trusted to have reliable YPR data.