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.

I was even more surprised & disappointed to see this dismissed as an ad for my company. Think about how fantastic JPEG XL would be for my company: an image codec with tons of fans and an extremely weak reference encoder? Sign me up. I'm writing this as someone who wants a better Internet.

If you're sensitive to tiling artifacts, you must deeply dislike the way JPEG XL images look. Every block of a JPEG XL image is effectively a small tile, because there is no deblocking loop filter (I talk about this in the article).

JPEG XL has two filters that are pretty much equivalents of what AVIF has, while AVIF has three; plus, tile boundaries are handled by the DLF. Your point doesn't really stand on two legs if it means to come to JPEG XL's defense here.

JPEG XL isn’t consistently better enough to justify it. If lossless is so important, maybe we should be campaigning for HALIC.

This comment reads like you summarized the post and didn’t read it

I expected one of these bad-faith readings, so I can address that Aperture is mentioned once and Iris-WebP is only shown in numbers, because I have access to these encoders and thus they cannot be ignored. The only encoders I heavily advertise here are the incredible open-source AV1 encoders, that I contributed to for free and I think people should use. Also, not sure where you infer that point about WebP; libwebp is a fine encoder.

AVIF does not have artifacts from tiling any more than JPEG XL has artifacts from being JPEG XL; if you read the details post at the bottom, you'd see there's a 0.5-1.0% BD-rate regression with tiles, which is effectively a rounding error.

For progressive, JXL shows a blurry mess for the majority of its decode, while AVIF shows a crisp image that clearly shows what is in the image. Go ahead and try the demo yourself! AVIF also supports more than one layer, but I used Team JXL's image on purpose to show that even there, AVIF looks better for 90% of the decode time. You need to watch what I'm showing you instead of adopting the most bad-faith reading because some things are mentioned.

I’ll just repeat another comment here:

“For progressive, I think it's better to show the user something that's obviously a preview, but still has enough detail to be able to know what the picture is of. If you're showing the user something that they may mistake for complete but poor quality, that's a bad experience.”

-jaffathecafe

There have been a number of experiments to use hardware decoders for images in browsers, all of which have fallen flat; not even Safari does it for AVIF or WebP. Thus, 4:4:4 AVIF is supported absolutely everywhere. Feel free to try it now. I can see how hwdec is compelling for JPEG XL in theory, given how slow decoding is.

I think libjxl's development is stalled because the format is hard to work with. It wasn't super hard to drive meaningful improvements to AVIF.

Yes, SVT-AV1 received and continues to receive development efforts from devs at big companies, but the number of core contributors has always been somewhat small. Definitely more resources, but the entirety of the original AVIF work was done by two people.

I'm able to utilize my experiences generally in image coding to work on my encoders. This should translate to JPEG XL, but I feel held back by how algorithmically complex compelling implementations of the coding tools would be, and how to make those implementations fast. I think if the JPEG XL spec was incredibly intuitive, community contributions would have gotten it a lot further. Heck, my own efforts may have gone to it instead of SVT-AV1-PSY's AVIF encoding.

x-axis is encoding speed, Y-axis is BD-rate where higher is better. aperture-alpha is an upcoming encoder from Halide Compression, no more details than that. libaom and SVT-AV1 are both for AVIF; libaom is the AV1 reference encoder.

In the post, I say "I think WebP was a bit too narrowly scoped"

This is not a coincidence, but I don't think it was that devs looked at WebP and thought "huh, the lack of 4:4:4 and 10-bit support makes this less compelling for our product despite being all over the internet" – I think it was just a matter of not keeping up. Except for Apple, not sure why they took so long to implement it.

It is getting its try, actively, in libjxl. People like to pretend AV1 got infinite resources; the reality is myself and one other contributor produced the vast majority of the image gains. I built Iris-WebP and aperture-alpha myself, from scratch. As a compression engineer, I think JXL is way, way harder to work with, and it would've taken me a lot longer. libjxl has community contributors, it is just an uphill battle with a codec like that. Same as WebP is an uphill battle due to its format restrictions.

Looking forward to a future where we can arbitrarily DoS anyone with a PDF that computes massive swaths of prime numbers.

Not sure if the difference is materially relevant to UX at all. JPEG XL achieves progressive rendering at a great cost to its selection of coding tools, so I side with AVIF's approach.

Lossy Modular isn't efficient enough to compete with even JPEG.

Also, look at the graphs – Iris-WebP beats JPEG XL.

I believe wholeheartedly that AVIF's approach is significantly better UX.

> But I do disagree with the last line, "I'm just not personally convinced we need it in browsers any time soon." I believe that if browser adoption is lacking, adoption of the format in places where it makes lots of sense (like cameras) will also be slow.

I'm not even personally convinced it is useful for cameras. Sally's situation isn't particularly bandwidth or feature-constrained, so JPEG or PNG work. Maybe JXL is solving problems that don't exist?

SVT-AV1-PSY was the first fork, and I created it. When the project matured, the maintainers reached out directly to get things merged – I can confirm it is a great project with great people who are very easy to work with.

Web publishers should definitely be stripping metadata at least, and transcoding isn't much harder. For anyone who cares about bandwidth, transcoding to efficient formats is non-negotiable; if you don't, then why do anything? Just ship PNG, who cares?

I think one of the compelling use cases for camera manufacturers would be an interoperable format for editors. Since JXL has support for so many channels, you could load your image into an editor, edit it, add layers, etc., and export as JXL, which could be used for other things.