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.

Published November 2026⏱ 9 min readStatus Preliminary · automated analysisOpen data GitHub · Hugging Face · Kaggle
800 × 600 vs 1600 × 1200Calibration file vs videofile saved in every recording folderVerified (file contents)
4.3–5.1 pxResidual with that file, daily median2,834 samples over 4 days, no trendVerified (automated)
0.41–0.72 pxResidual with the mode-matched fileper 5-min file, central field (Field Note #16)Verified (automated)
1 lineCheck that would have caught itcalibration image size = decoded frame sizeProcess change

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.

Box plot by day of rectified vertical residual around 4 to 5 pixels, with a shaded band at 0.41 to 0.72 pixels
Figure 1. Rectified vertical residual per sample with the per-recording 800×600 file, by day. Green band: the mode-matched file over a full shift (Field Note #16).
Table 1. The file next to the video is not the file for the video
DaySamplesMedian (px)P10 (px)P90 (px)Matches per sample, median
2026-11-017564.322.889.58287
2026-11-025985.062.999.95199
2026-11-037684.322.998.36300
2026-11-047124.982.999.0237

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.

Original fisheye frame with the calibration principal point marked in the upper-left quarter, next to the same frame rectified with strongly curved edges
Figure 2. A: original frame with the file's principal point (red) and the true frame centre (green). B: the same frame after rectification with the 800×600 file.
Side-by-side rectified left and right images with horizontal guide lines and a strongly curved door frame circled in red
Figure 3. Left | right after rectification with the per-recording file. A straight door frame (circled) comes out curved.

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.

Table 2. Four checks that need no images
CheckCalibration fileVideoReading
Image size in the file800 × 6001600 × 1200 (decoded frames)Mismatch: factor 2
Principal point cx, cy (cam0)403.4, 306.3 px≈ 800, 600 px expected for this lensCentre 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 folderyes, 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?
The calibration made in the 1600×1200 recording mode, not the 800×600 file the rig saves into each recording folder. We ship the mode-matched file with every delivery.
Q02How do I know a calibration file matches my video?
Compare the image size stored in the file with the size of a decoded frame, and check that the principal point lies near the image centre. If either fails, do not use the file.
Q03Why did the wrong file look stable?
A wrong calibration gives the same large error every day. Our four daily medians were 4.3–5.1 px, a flat line that looks like stability but is far above the 0.41–0.72 px measured with the correct file.
Q04Does this affect earlier Origin Data Lab notes?
No. Field Notes #13 and #16 used the mode-matched calibration. This error was caught in internal analysis before any figures were published.
Q05Can the 800×600 file simply be scaled by 2?
Possibly, but we have not tested it yet. Until it is tested against the mode-matched file, we do not recommend it.

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.

Run the notebook on Kaggle

Licence: CC BY 4.0 (data and figures) · MIT (code)

Cite this note

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.