Technical Field Note #20 · November 2026
Stable is not the same as correct: the calibration file saved with every recording was for 800×600, the video is 1600×1200
Field Note #20 · A resolution mismatch between the per-recording calibration file and the video, and how to catch it (ODL-EGO S1)
When we ran a stereo-calibration consistency check over four days of real work, the result looked like good news: the rectified vertical residual was 4.3–5.1 px median on every day, with no drift. It was wrong. The analysis had loaded the calibration file that the rig saves into every recording folder, and that file describes an 800×600 image, while the video is recorded at 1600×1200. Applied to full-resolution frames, it bends straight lines and leaves a large, perfectly repeatable error; repeatable is exactly what made it look like stability. With the mode-matched 1600×1200 calibration, the same rig measures 0.41–0.72 px over a full shift (Field Note #16). This is the second time a calibration file that did not match the recording mode has reached our pipeline (Field Note #13), so the fix is now structural: every geometric step first checks that the calibration's image size equals the decoded frame size and stops if it does not.
Why this matters
A repeatable error looks like stability
A calibration consistency check over days usually asks one thing: did the number move? A wrong calibration does not move either. It produces the same large error every day, and a chart of that error is flat. Flat is easy to read as 'stable'.
This note documents how that happened in our own analysis, why the numbers were convincing, and the check that now prevents it. We publish it because the same file sits in every recording folder of this rig, so anyone processing these recordings can make the same mistake.
What happened
The file next to the video is not the file for the video
Our automated analysis (cloud batch over 2026-11-01 to 11-04, 20 sessions) loaded calibration/<serial>/calibration.yaml from each recording folder, rectified one left/right pair every 10 s, and measured the vertical offset of ORB feature matches. It reported 4.3–5.1 px median per day, very similar on all four days.

| Day | Samples | Median (px) | P10 (px) | P90 (px) | Matches per sample, median |
|---|---|---|---|---|---|
| 2026-11-01 | 756 | 4.32 | 2.88 | 9.58 | 287 |
| 2026-11-02 | 598 | 5.06 | 2.99 | 9.95 | 199 |
| 2026-11-03 | 768 | 4.32 | 2.99 | 8.36 | 300 |
| 2026-11-04 | 712 | 4.98 | 2.99 | 9.0 | 237 |
The flat result was the warning sign we missed at first: a calibration that was truly correct for the video would have given well under 1 px, as it does in Field Note #16.
Visual evidence
Straight lines come out bent
Rectification with a correct calibration turns straight edges into straight lines and puts the same point on the same image row in both eyes. With the 800×600 file applied to 1600×1200 frames, a straight door frame is strongly curved and features drift between rows.


File-level checks
Four checks that need no images
The mismatch is visible in the file itself. Each of these checks takes seconds and needs only the YAML file and one decoded frame.
| Check | Calibration file | Video | Reading |
|---|---|---|---|
| Image size in the file | 800 × 600 | 1600 × 1200 (decoded frames) | Mismatch: factor 2 |
| Principal point cx, cy (cam0) | 403.4, 306.3 px | ≈ 800, 600 px expected for this lens | Centre of an 800 × 600 image |
| Focal length fx, fy (cam0) | 241.2, 241.2 px | — | Plausible only for 800 × 600 |
| Same file in every recording folder | yes, identical on all 4 days | — | Not tied to the recording mode |
Working hypothesis, not yet tested: the file may be the same calibration at half resolution, in which case doubling fx, fy, cx and cy would approximate the 1600×1200 intrinsics. We will test this against the mode-matched file before relying on it; until then only the mode-matched file is used.
What we changed
Size check first, geometry second
Verified: the per-recording calibration file describes an 800×600 image, the recordings are 1600×1200, and using that file produces a stable but wrong 4–5 px residual.
Process: every geometric step in our pipeline (rectification, epipolar checks, depth) now asserts that the calibration image size equals the decoded frame size and stops with an error otherwise. Deliveries ship the mode-matched calibration file, name its recording mode, and include a validation run on the delivery's own frames, as introduced after Field Note #13.
SCOPE AND LIMITS
Limitations
What this note does not show, stated up front.
- The residual here uses ORB matches on one pair every 10 s; it is a consistency indicator, not a full calibration evaluation.
- The half-resolution hypothesis is untested.
- One rig and one firmware version; other units or firmware may save a different file.
- All checks are automated: AI/algorithm-only preliminary analysis; no human re-verification.
FAQ
Questions data buyers ask
Q01Which calibration file should I use for this rig's 1600×1200 recordings?
Q02How do I know a calibration file matches my video?
Q03Why did the wrong file look stable?
Q04Does this affect earlier Origin Data Lab notes?
Q05Can the 800×600 file simply be scaled by 2?
OPEN DATA AND CODE
Reproduce and inspect the evidence
Every number in this note can be checked: derived tables, analysis code, figures and a runnable notebook are public.
origin-data-lab/recording-folder-calibration-file-resolution-mismatchView repository origin-data-lab/recording-folder-calibration-file-resolution-mismatchOpen dataset origindatalab/odl-calibration-file-resolution-checkExplore on Kaggle Licence: CC BY 4.0 (data and figures) · MIT (code)
Origin Data Lab (2026). Technical Field Note #20: Stable is not the same as correct. https://origindatalab.io/technical-field-notes/recording-folder-calibration-file-resolution-mismatch.html
Want this measured on your data?
Origin Data Lab plans and runs egocentric, stereo+IMU and field video capture with documented QA, for physical AI and robotics teams.