"Progressive image formats allow the decoder to create a partial rendering when only part of the image resource is available. Sometimes it's part of the image, and sometimes it's a low quality/resolution version of the image. I've been digging into it recently, and I think there are some common misconceptions, and I'd like to see a more pragmatic solution from AVIF."
"Trusty old JPEG can be encoded in a progressive way, which is the default in Squoosh. Here's a little web app that lets you test progressive rendering of any image, and here's the app ready-loaded with the JPEG version of the fox image. You get a top-to-bottom low resolution render that starts around 1.2 kB in, and it finishes its first pass at around 33 kB (21% of the file size). Interestingly, that looks different in Firefox and Chromium-based browsers compared to Safari:"
"With JPEG, progressive rendering seems to be free in terms of quality/size, but it isn't free in terms of decoding time. Here's another little web app, this one benchmarks image decoding in the browser. Comparing progressive JPEG with non-progressive JPEG, the progressive JPEG takes around 40% longer to decode, but on my M4 pro that's only about 1.3ms, which seems like a reasonable trade-off."
Progressive image formats create partial renderings from incomplete image data, either by showing part of the image or a low-quality/resolution version. A high-resolution AVIF fox image (1598x1753, 155 kB) was used to compare formats at similar file sizes. Progressive JPEG provides a top-to-bottom low-resolution render starting at ~1.2 kB and completes first pass at ~33 kB, rendering differently across Safari and Firefox/Chromium. Progressive JPEG increases decode time by ~40% versus baseline, adding ~1.3ms on an M4 Pro. AVIF currently lacks a pragmatic progressive rendering approach comparable to JPEG.
Read at Jakearchibald
Unable to calculate read time
Collection
[
|
...
]