Nobody had asked what the camera's own automatic loops were doing
Every measurement this stack makes is computed on pixels — and every camera has automatic loops silently editing those pixels before any of them run. Reading the camera's own settings answered a question nobody had asked yet.
Detector confidence, XFeat inlier counts, a turbidity proxy, checkpoint bank references — every number this stack produces is computed on pixels, and until this pass, nobody had asked what the camera's own automatic control loops were doing to those pixels before any of them arrived. Read live off the running vehicle: white_balance_automatic=1, auto_exposure=3 (Aperture Priority, not manual), exposure_dynamic_framerate=1. Nothing in the vision stack touches white balance at all, and dynamic framerate silently lets the camera drop its own rate in dim water — which matters specifically because every rung of the tracking lock ladder is sized in seconds: halve the frame rate, and you've halved how many detections fit inside the same coast window without anyone changing a threshold.
The number that justified the question
Measured on a static scene, with the camera itself perfectly still: auto-exposure injected 15.5× more luma drift than fixed exposure — 2.42 peak-to-peak against 0.16. Every one of those descriptor-based measurements is intensity-derived, which means a reference image that never physically moved was still changing appearance from frame to frame, from a noise source none of the existing analysis accounted for.
The run also answered a different question than the one it was designed to ask.
R/B — the red-to-blue channel ratio used as a colour proxy — came back at exactly 1.0000, with zero variance, in both the auto and fixed arms. That means the forward camera is delivering a monochrome signal, full stop, and automatic white balance is moot on it: there is nothing to balance. That result is consistent with a separate, already-standing finding that this specific camera needs a colour hardware variant — but it also means the white-balance half of the original question can't be settled on current hardware. Not disproven. Unfalsifiable, on this camera, today.
Two honest limits close the finding rather than round it up. The 15.5× luma number comes from a static indoor scene — the easy case; a moving vehicle in changing water gives an auto-exposure loop far more to chase, and that harder version of the claim is still unmeasured. And the fixed-exposure arm itself read luma 59.55 against auto's 119.27 — under-exposed, because manual mode had inherited a stale exposure_time_absolute=157 rather than computing the correct value. The fix that ships from this has to actively set the right exposure, not merely switch a loop off — and the function that already computes that correct value, blur_capped_exposure(), was sitting in the codebase, unused, the whole time.