test(transcode): a fixture the WebP encoder cannot shrink
The transcode negative path — "the result came out larger, serve the original and remember that" — had no test because no synthetic image reaches it. Measured against the real encoder: flat colour goes 4780 → 186 bytes, a diagonal gradient 24852 → 102, and uniform RGBA noise still loses by ~242 bytes at every size, a margin constant in absolute terms and so one that never flips. Grayscale does not help either; WebP's subtract-green transform handles R=G=B. Two things have to be true at once and only real content does both. The encoder is the `image` crate's own minimal VP8L writer, not libwebp, so it wins only where redundancy is extreme enough for any encoder to find it. And the original has to be near PNG-optimal, which a screenshot from a real capture tool is: a 2x Retina UI is long identical runs, flat panels and sharp edges — precisely what PNG's scanline filters plus zlib were built for. So the fixture is a real OxiCloud screenshot (emails masked by overtyping rather than block-filling, which would have added back the flat redundancy the property depends on; re-verified negative after masking, 556180 -> 511124 bytes). `fixture_premise` pins both halves of what tests/api/transcode_cache.hurl will assume — this one negative, red-image.png positive. Without the guard a future encoder bump would silently turn the negative half of that scenario into a second positive test: still passing, no longer checking what it was written to check. Worth recording for whenever libwebp replaces this encoder: most of these screenshots would likely flip to positive, which leaves every stored negative row a stale verdict. An encoder change has to purge them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
BIN
Binary file not shown.
|
After Width: | Height: | Size: 499 KiB |
Reference in New Issue
Block a user