The Float Epsilon Bug: How 2.2×10⁻¹⁶ Broke the Pixel Integrity Guarantee

This is the kind of bug that only becomes visible when a pipeline checks its own output against a hard constraint. Most video processing pipelines would have silently delivered the result and no one would have noticed.

The symptom

A 848×474 source video fails the pixel provenance verifier with match_rate=0.69 (threshold 0.90). The FFmpeg filter graph shows crop=265:473:313:1,scale=266:474:flags=lanczos — a scale step was inserted where there should have been none. Lanczos-scaled pixels are not source pixels. The verifier is correct. The pipeline is wrong.

The chain of causation

This required understanding three independent layers of the stack simultaneously:

• The STATIC effect produces a constant zoom array of all 1.0 values.
• gaussian_filter1d smooths the zoom array. Gaussian convolution of a constant array should return the same constant. It does — except for floating point summation error. The result is 1.0 + 2.2e-16 (machine epsilon).
• The renderer computes: eff_w = int(math.floor(crop_w / zoom)). With crop_w=266 and zoom=1.0+2.2e-16: floor(266 / (1.0 + 2.2e-16)) = floor(265.9999...) = 265.
• The renderer crops a 265×473 window then scales it to 266×474 output — introducing one Lanczos-interpolated pixel column and one row. These are not source pixels.
• The EDL rounds zoom_level to 4 decimal places: round(1.0 + 2.2e-16, 4) = 1.0. The EDL looks completely correct.

Why 848×474 and not 1920×1080?

At 1920×1080, crop_w=606, so floor(606 / (1.0 + 2.2e-16)) = 605. Same bug, but the scale ratio is 606/605 ≈ 1.0017 vs 266/265 ≈ 1.0038. Less resampling damage at 1080p. More likely to stay within the ±8 pixel tolerance. The 848×474 source is small enough that the scale ratio is large enough to reliably fail the verifier. At 1080p the bug existed but hid inside the tolerance band.

The fix

One line. After np.clip(zoom_arr, 1.0, ceiling) in the motion solver, snap any value within 1e-9 of 1.0 back to exactly 1.0:

zoom_arr[zoom_arr < 1.0 + 1e-9] = 1.0

Every float within 1e-9 of 1.0 is replaced with exactly 1.0 before it reaches the renderer. The scale step never happens.

The meta-lesson

Most video processing pipelines don't have a pixel provenance verifier. This bug would have been a permanent silent feature. The hard constraint — no output pixel that isn't a direct source sample — is not just a product integrity claim. It's a forcing function for a level of correctness that most pipelines never achieve.