Comment by uyzstvqs

19 hours ago

JPEG XL is also good, but why not use AVIF? It's widely supported by browsers, and rivals JPEG XL in being the best lossy image format.

6 comments

uyzstvqs

Reply
judah  19 hours ago

Jake Archibald has an excellent post about progressive image rendering, including some metrics on JPEG XL compared to AVIF[0].

> "I was also surprised to see that, in Safari, JPEG XL takes 150% longer (as in 2.5x) to decode vs an equivalent AVIF. That's 17ms longer on my M4 Pro. Apple hardware tends to be high-end, but this could still be significant. This isn't related to progressive rendering; the decoder is just slow. There's some suggestion that the Apple implementation is running on a single core, so maybe there's room for improvement.

> JPEG XL support in Safari actually comes from the underlying OS rather than the browser. My guess is that Apple is considering using JPEG XL for iPhone photo storage rather than HEIC, and JPEG XL's inclusion in the browser is a bit of an afterthought. I'm just guessing though.

> The implementation that was in Chromium behind a flag did support progressive rendering to some degree, but it didn't render anything until ~60 kB (39% of the file). The rendering is similar to the initial JPEG rendering above, but takes much more image data to get there. This is a weakness in the decoder rather than the format itself. I'll dive into what JPEG XL is capable of shortly.

> I also tested the performance of the old behind-a-flag Chromium JPEG XL decoder, and it's over 500% slower (6x) to decode than AVIF. The old behind-a-flag Firefox JPEG XL decoder is about as slow as the Safari decoder. It's not fair to judge the performance of experimental unreleased things, but I was kinda hoping one of these would suggest that the Safari implementation was an outlier.

> I thought that "fast decoding" was one of the selling points of JPEG XL over AVIF, but now I'm not so sure.

> We have a Rust implementation of JPEG XL underway in Firefox, but performance needs to get a lot better before we can land it."

[0]: https://jakearchibald.com/2025/present-and-future-of-progres...

  • jomohke  12 hours ago

    Strange, as Cloudinary's test had the opposite conclusion -- jpegxl was significantly faster to decode than avif. Did the decoders change rapidly in a year, or was it a switch to new ones (the rust reimplementation)?

    https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front

    If decode speed is an issue, it's notable that avif varied a lot depending on encode settings in their test:

    > Interestingly, the decode speed of AVIF depends on how the image was encoded: it is faster when using the faster-but-slightly-worse multi-tile encoding, slower when using the default single-tile encoding.

  • quentindanjou  17 hours ago

    I am curious, isn't AVIF also taking advantage of the hardware decoding democratized by AV1?

    • michaelt  16 hours ago

      Taking advantage of hardware decoding is generally like pulling teeth.

      For video you can't avoid it, as people expect several hours of laptop battery life while playing video. But for static images - I'd avoid the pain.

F3nd0  19 hours ago

Because JPEG XL is the first format to actually bring significant improvements across the board. In some aspects AVIF comes close, in others it falls far behind, and in some it can’t even compete. There’s just nothing else like JPEG XL and I think it deserves to be supported everywhere as a truly universal image codec.