A couple of videos comparing progressive decoding of jpeg, jxl and avif: ▶ this video [link] There's more on the same channel, generation loss ones are really interesting.
in “JPEG XL and the Pareto Front” · View on HN
Progressive decoding: JPEG vs JPEG XL vs AVIF on HackerTube: recommended by 1 Hacker News commenter across 1 month, 2021–2026.
demo · intermediate · dated
A short side-by-side demo of a large image loading over a slow connection in JPEG, progressive mozjpeg, JPEG XL and AVIF. It shows how each codec renders partial data.
HN uses it as visual evidence that JPEG XL decodes progressively while AVIF shows nothing until fully loaded.
“AVIF only shows when it is 100% finished.”
5 Hacker News comments link this video. Each one links back to its thread.
A couple of videos comparing progressive decoding of jpeg, jxl and avif: ▶ this video [link] There's more on the same channel, generation loss ones are really interesting.
in “JPEG XL and the Pareto Front” · View on HN
Progressive decoding isn't expected to speed up decoding, it's expected to speed up displaying large image files, especially for downloads via slow mobile connections. Example: ▶ this video
in “Regressive JPEGs” · View on HN
High quality progressive decoding at reduced filesizes is a big positive for me. There is no other format that supports that. ▶ this video
in “First automatic JPEG-XL cloud service” · View on HN
Apart from limited resolution probably the biggest problem with AVIF: It doesn't support progressive decoding. Which could effectively cancel out its smaller file size for any web applications. AVIF only shows when it is 100% finished. See ▶ this video This comparison video is admittedly a little unfair though, because AVIF would have easily 30% lower file size than JPEG XL on ordinary images with medium quality.
in “JPEG XL: How It Started, How It’s Going” · View on HN
Some notable features of JPEG XL that don't show up in side-by-sides: 1) Progressive decoding. Like the original .jpg, .jxl can give you a low-quality image when a fraction of the file is loaded, then a decent-quality image, then the final image. This can give JPEG XL the edge in perceived load speed even when the full .avif is smaller than the full .jxl. (Old demo from a JXL contributor at ▶ this video ) 2) Fast conversion: JPEG XL encoding/decoding is fast without dedicated hardware. Facebook found encode/decode speed and progressive decoding to be points in favor of JPEG XL for their use: [link] 3) .jpg repacking: JPEG XL can pack a JPEG1 about 20% smaller without any additional loss; the original .jpg file can be recovered bit-for-bit. 4) Lossless mode. JXL's lossless mode is the successor to FLIF/FUIF, is really good, and also has progressive decoding. AVIF has a lossless mode too, but JPEG XL seems ahead here. (I know the parent comment is from a JXL contributor, I'm saying this for other folks.) I think those will give JPEG XL a niche on the Web. Meanwhile I suspect e.g. Android phone cameras will save .avif someday, like iPhones save .heic now. Phones want the encode hardware anyway for video, and you can crunch a zillion megapixels down to a smaller file with AVIF before attention-grabbing artifacts crop up--at low bitrates AVIF seems good at preserving sharp lines and mostly blurring low-contrast details (compare Tiny images). Finally, worth noting the codecs are differe
in “JPEG XL” · View on HN