computerbuster

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?

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.

Do you have performance numbers versus libwebp?

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.

Would love to help all implementations improve – would you be able to send Halide an email so we can take this offline? Happy to help if possible!

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.

Nice, I didn't know about this!

Why does that bias the comparison exactly?

Will do going forward, thanks for the feedback!

Well-put.

Luckily, 4:4:4 AVIF is supported in Firefox, Chrome, and Safari, right now. This won't ever regress.