22 ms·
Maybe think of it by analogy. Suppose my compression format (dibs, patent pending) is an uncompressed RGB pixel list, stored in a ZIP archive. Let's call that S
by tfm 11y ago
Maybe think of it by analogy. Suppose my compression format (dibs, patent pending) is an uncompressed RGB pixel list, stored in a ZIP archive. Let's call that SuperCompress Level 0.
I can improve the compression a little by rounding the pixel intensities in the pixmap, e.g. clearing all low bits. Call that SuperCompress Level 1. This operation is idempotent: you can't throw away the same data multiple times, so there's no generational loss. More importantly, the resulting data is completely compatible with SuperCompress Level 0, because the "lossy encoding" (rounding our numbers) is decoupled from the "lossless compression" (ZIPping!). This is effectively what FLIF and TruePNG/near_lossless-WebP are doing.
NOTE though that even our archetypal lossy JPEG image _can_ be re-encoded without generational loss: if you use the same quantisation tables and the same pixel alignment, and you haven't fiddled with the pixel intensities, then subsequent encodings don't throw away anything you haven't discarded already. If however you save it with a different quality each time then you'll find yourself with jarring Cubist-style artefacts. Proponents of lossless image formats are well-versed in this technique ;-)
Generational loss emerges from destructive changes that are not really related to the image format. If the only changes you're doing are cropping images on 8x8 pixel boundaries, then JPEG compression at a fixed quality is effectively "generationally lossless". Gamma/colour corrections applied to an image are at least a little bit lossy in any format, because there are rounding errors inherent in that process. Compositing image regions is also hugely destructive, but (assuming suitable alignment and encoder options) there will be generational loss around the boundaries of the regions while the interiors remain unchanged.
Realistically, most Egregious JPEG Artefacts result from resizing and/or cropping the image, then re-saving repeatedly. That's 90% of the internet, and probably another 9.9% if we throw in "adding a sassy caption in Impact Bold". This is unfortunate because it really plays to JPEG's weaknesses. If the "lossy preprocessing step" implemented in FLIF (or the other lossless formats) is robust against that particular abuse then it could be immensely useful.