I wrote "The Case Against JPEG XL". I still don't understand why this is a valuable addition to the Web, to be honest.
1. Lossy: AVIF is vastly more efficient at any fidelity target with reasonably modern encoders (libaom, SVT-AV1). Even proprietary WebP encoders are more efficient than libjxl. More efficient meaning better quality at the same size. This is provable even beyond modern metrics.
2. Lossless: JPEG XL is ~10-13% better than WebP here, but can be >6x slower to decode. What is the point of saving 10% bits when the client pays for it? There are lossless codecs more efficient than both that are faster to decode than both, too.
3. JPEG Recompression: Same deal, the increased decode time often erases the time-to-display gains (even on modern devices) - not just me either, this was proved empirically in the previous HN thread on a Pixel 9 Pro.
4. AVIF can have as many progressive decode passes as you like, and they aren't just "layers", they actually work together.
There are strengths, like 32-bit float precision and support for a lot of layers. I'm just lost on what the criteria for including a new codec in the Web is at this point. Google was heavily involved in JXL's development so I understand their incentives exist, and the "all-in-one" codec argument, but other than that, I'm a bit lost.
It's a philosophical difference I suspect. To quote from your site:
"I believe Web codecs should be purpose-built, efficient, and narrowly scoped to the needs of the Web.... [JPEG XL] is meant to be everything to everyone... Not to mention an additional compatibility headache now exists for anyone just trying to download an image from the Internet and use it somewhere"
Browsers aren't trying to be narrowly scoped anymore, nor made just for the web (Rust and LLMs must have improved their confidence regarding security). Other usecases (like PDFs and cameras) clearly benefit from JPEG XL. Once support was added, it was easy to just turn on for the web. After all, they need to consider the opposite case where someone creates a jxl image and tries to upload it to the Internet. They might even think that having a format that is everything to everyone is useful and eventually the (en)decorders will improve.
1. Not true before modern AV1 encoder got major improvements in the past 3 years. There is no reason why JPEG-XL can't be improved in the low bpp range. JPEG itself got improvement 20 years after its initial introduction. Not to mention the last time I check, JPEG XL is still better at high end fidelity.
2. JPEG XL lossless can be 10-13% or in some cases up to 50% better. Of course WebP could also be better in some cases. And again, JPEG-XL potential is far fully optimised. Both in encoder and decoder.
On another note, the AOM camp should really have played the AV2 card suggesting it to be better.
I talk about this in the article, but while I agree JXL can get a lot better (prob as good as current libaom) its coding tools are much harder to use – e.g. splines vs dir pred. And I think the sometimes better sometimes worse lossless argument is still not really a super compelling case?
The goal is to do everything good enough, and if possible almost as good as purpose-built. So yes, every other format is better when looking at specifics. But JPEG XL's goal is the best average.
1. Can be compiled without assembly, and I believe SIMD can be written safely if you think about what it is actually doing
2. The only dependency is zerocopy which is used in a lot of major projects considered to be safe
These are all valid points, and I think the wuffs project makes a lot of sense for certain use cases. But, I think when characterizing wpd, "we do SIMD via assembly in unsafe blocks" is a bit of a mischaracterization. wpd doesn't implement its decoder using Rust SIMD inside broad unsafe regions. Unsafe code is denied throughout the crate and allowed only in the dedicated assembly binding module; without assembly, the crate uses forbid(unsafe_code).
The handwritten SIMD kernels sit behind safe Rust wrappers that calculate or validate the exact slice bounds before producing raw pointers, and CPU-specific routines are only installed after runtime feature detection. wpd even has guard-page tests specifically checking that the assembly kernels don't read or write beyond those wrapper-established windows. Handwritten SIMD was valuable enough that we felt this was all worth it (see some of the dav1d talks for justifications, we share these views).
Wuffs does still have a stronger formal property in the fact that its compiler checks the loads & stores inside the SIMD implementation itself, but most of the interesting memory safety attack surface (parsing and decoding attacker-controlled structure) remains entirely in safe Rust in wpd anyway, so I think wpd is still safe and incontrovertibly a significant improvement over libwebp anyway.
P.S. you can disable wpd's assembly if you feel so inclined, and get similar performance to Wuffs with safety.
You can always compile to wasm, or ship a wasm decoder. You can even ship a JS decoder, but speed and resource consumption are important, ruling both out.
Thanks for the heads-up, I didn't know wuffs had a WebP decoder. Just benchmarked it (b2e6da3), and wpd is about 2-3x faster on lossy stills, 5-7x faster on lossy with alpha, and 7-8x faster on lossless on my M5 Pro (even single-threaded).
Also, wuffs is not bit-identical to libwebp, and animated WebP is completely unsupported, so I'm not sure it is a real option for WebP decoding.
We got a pull request (https://github.com/google/wuffs/pull/168) in February to add lossy WebP support. Lossless WebP (which in some sense is an entirely different format, just reusing the WebP "brand") has had a Wuffs implementation for a couple of years now.
Anyway, the PR included SIMD acceleration and performance was on par with libwebp (C code).
The PR's code was, as far as I could tell, somewhat or mostly AI assisted. While that's great in terms of features, I still have more confidence in hand-crafted code.
I have since been working to manually rewrite the PR. I'd also like to add animation support, and last month I landed some Wuffs tooling changes re animated PNG, to be better able to (as a comparison baseline) decode and test animated WebP.
A lot of that manual rewrite has been committed, but the SIMD parts haven't landed yet. So yes, for what's on the main branch (not the PR), performance is not as good as libwebp yet, but landing the SIMD parts should fix that.
> wuffs is not bit-identical to libwebp
That's news to me. PR 168 says it produces pixel-identical output to libwebp. And what's in the main branch aims to be pixel-identical, e.g. for YUV to RGB conversion, it implements libwebp's formulae, not libjpeg's formulae. Both use BT.601, but libwebp uses studio range and libjpeg uses full range.
Can you link to some example .webp images that are not bit-identical?
1. Lossy: AVIF is vastly more efficient at any fidelity target with reasonably modern encoders (libaom, SVT-AV1). Even proprietary WebP encoders are more efficient than libjxl. More efficient meaning better quality at the same size. This is provable even beyond modern metrics.
2. Lossless: JPEG XL is ~10-13% better than WebP here, but can be >6x slower to decode. What is the point of saving 10% bits when the client pays for it? There are lossless codecs more efficient than both that are faster to decode than both, too.
3. JPEG Recompression: Same deal, the increased decode time often erases the time-to-display gains (even on modern devices) - not just me either, this was proved empirically in the previous HN thread on a Pixel 9 Pro.
4. AVIF can have as many progressive decode passes as you like, and they aren't just "layers", they actually work together.
There are strengths, like 32-bit float precision and support for a lot of layers. I'm just lost on what the criteria for including a new codec in the Web is at this point. Google was heavily involved in JXL's development so I understand their incentives exist, and the "all-in-one" codec argument, but other than that, I'm a bit lost.