libjxl's slow speed at efforts >7 is primarily due to an iterative evaluation-optimization loop of a perceptual error metric called Butteraugli (by tuning quantization weights). This, as well as some other computations in libjxl encoding, happen to be data-parallel and run faster on GPUs than multicore CPUs.

In case anyone is interested, I've been working on a GPU-accelerated libjxl port (supporting CUDA and Metal for now) that makes this much faster, closer to libjxl's normal speeds: https://github.com/yunho-c/gjxl - geared for encoding a large batch images into JPEG XL. It's also faster by around 2.9x at normal effort (7).

  ffmpeg -i {input_file} -filter_complex "[0:v]format=pix_fmts=yuva444p,split[color][alpha];[alpha]alphaextract[alpha_chan]" -map "[color]" -map "[alpha_chan]" -c:v libaom-av1 -crf 25 -cpu-used 3 -still-picture 1 -aom-params "sharpness=2:enable-chroma-deltaq=1:arnr-strength=0" -color_range pc -colorspace bt709 -color_primaries bt709 -color_trc bt709 {output_file}

https://github.com/aomediacodec/libavif

avifenc supports args like enable-chroma-deltaq. I've used those but recently stopped, and nothing substantial changed.

- The Firefox screenshot w/ lossless JXL at 66.9kB, when with a better encoder you get get it down to like 40.7kB (39% smaller) [1] (or 43kB if you need it to work with jxl-rs [2])

- The cat illustration w/ lossless JXL at 255.3kB, when with a better encoder you can get it down to 178kB (30% smaller) [3]

[1] https://www.linolevan.com/05-screenshot.jxl

[2] https://www.linolevan.com/05-screenshot-web.jxl

[3] https://www.linolevan.com/06-illustration.jxl

Curious what is the better encoder here referring to?

In full screen mode, the "hold for lossless" version "Firefox help"/"Submit feedback" are not underlined. In inline mode they are. Both modes seem to render a scaled down version of the image, which seems to cause these problems.

Granted, AVIF performs impressively for, say, a huge hero image for a blog where you're out to create an overall impression and people aren't going to look at it closely. It does not impress me when I am compressing photos I took with my mirrorless and I expect them to look like photos taken with a mirrorless and not cell phone snaps.

https://jakearchibald.com/2020/avif-has-landed/demos/compare...

I was talking about. He linked another one! Guess people finally realized that one sucks and now they have a new one. I screwed up.

That's what I noticed anyway, not a car or photo guy either.

You're looking at it in a browser that doesn't support JPEG XL, so it's falling back to a WASM renderer, and I think it handles resizing differently.

This is totally my bad. I thought I was doing a good thing by adding that fallback renderer, but it isn't identical and it's giving people the wrong impression.

The lossless version is JPEG XL, hence the difference to AVIF.

I also remember the big claims about WebP's superiority, which ended-up in practice, at equivalent file-size, mostly trading away some of the JPEG artifacts that we all know for some unusual new ones.

I don't think there's a large-enough margin in this space that a new format could chew into to make the general public care: image compression seems like a solved problem overall. The second best thing is to come-up with a format that can make the content producers not have to care either, i.e. be the best in class or close-enough in a variety of use-cases (lossy, lossless, fast, animated, hdr, progressive, …). My naive impression was that jxl is mostly interesting in that regard.

What improvement do you think is necessary for people to care?

Genuinely curious. Spoiler link with my answer to avoid any bias: https://lgms.nl/p/cau/?b64&ZVRNb9QwEL0j9T%2BMKqFtpe1Cqcq9qoT...

After reading this article, there's something to point to prove I'm not going crazy.

JPEG XL also has some big benefits for many use cases like lossless re-encoding and supporting higher resolution. AVIF images have a max size of 8192x4352 last I checked. That's not a problem for web images almost all of the time, but there's certainly uses where you might want more. I think AFIV might be limited to 12bit overall while JPEG XL can do 32bit. Again, is that something many will take advantage of on the web? No, but if it's something you care about it might be really meaningful to you.

Also, if you care about the 90% quality level, JPEG XL often outshines AVIF, but when I'm putting images on the web it's often well below that.

Some of it was bad information. I saw some people saying JPEG XL being way less computationally intensive (even less than WebP) and offering much better compression. Some of it was selective data - do you only test things at 95% quality level and declare a winner?

But I think the big thing is that a lot of people wanted the two formats to succeed or fail based on their merits. I think a lot of people don't like AVIF because it isn't well supported outside of browsers - and there can be a hope that the JPEG name would mean JPEG XL would get the kind of adoption JPEG did.

And it's hard to truly compare formats - or benchmark in general. As the article shows, different JPEG XL encoders offer vastly different performance. And when we're dealing with lossy compression, sometimes it can be a bit of personal preference. At some point, people started enjoying the way that MP3 garbled symbols (the instrument) and that was the sound they expected a symbol to make.

This isn't true btw. The format supports up to 64k x 64k, although browser decoders currently fail beyond 16k x 16k.

Not sure when you'd serve something like that on a web page though.

JPEG-XL seems to be the best solution for storing and distributing high-quality images. For myself, I want high-quality images, so JPEG-XL is what matters, both for new images and for compressing the old archives of JPEG images.

While I have my own Web server, it is for private use and not for commercial purposes, so I have no interest in using AVIF to achieve the smallest image sizes, but at a lower quality than I want.

And the article supports what I have said.

Quotation from the article:

> But JPEG XL catches up at very high quality. Around SSIMULACRA2 85, libjxl's default matches AVIF's default, and at maximum efforts, jixel 'extraslow' is ~6% smaller than AVIF s0. jixel 'slow' is 10–13% smaller than AVIF's default from SSIMULACRA2 80 upwards.

ssimulacra2 85 is rather close to median quality in the internet

ssimulacra2 90-95 is rather close to high quality in the internet

ssimulacra2 98+ is close to camera quality

For a wide variety of usecases, not for every isolated usecase. Today, AVIF is better for showing people ads^W^W^W web content delivery. This article is titled “JPEG XL vs. AVIF for web use-cases”. The other article recently discussed¹ is subtitled “Investigating JPEG XL's place as a Web image codec” and ends:

> JPEG XL isn't useless; it is genuinely compelling technology for use cases beyond the Web.

¹ https://news.ycombinator.com/item?id=49690554

(Either way, can we agree to take webp out behind the barn?)

Think of it as zip compression that is specially designed for JPEG and putting the JPEG data in a different/better container.

JPEG XL has always been targeting high quality encoding metric first before the lower end low BPP images, which AV1 excels at with or without the last 6 years of improvements.

The current top comments about MP3 and LAME is again about how encoder extract maximum potential. JPEG XL was may be the best in 2021, but has been fighting for survival since then.

There a lot of different images that JPEG XL encode better. Screenshots with text is known to be not something they have optimised for or think it could be good at. Lossless mode may be better. Edit: As one of the other comment here proved my point.

Had all of these, even just a hint of AVIF improvement be told, may be the sentiments would have been a little different. But then again I am not one who would trust the same people who sold me WebP and AOM roadmaps.

But at least AV2 is coming. And JPEG XL is finally in every browser. Hopefully we can all have something even better in the future.

(also like the BPP size metric that is picture size-independent)

Wish that widget with improvements (that allows comparison of 3 pics with 3 buttons: original/codec1/codec2) were the widespread standard (also, "hold" is a rather unergonomic action)

Otherwise, seems like AVIF has had impressive gains in both speed and quality, wonder whether JXL could catch up

The images in the article max out at the maximum size I'd want them displayed.

This is something I've felt doesn't get enough attention when comparing JXL and AVIF. AVIF can be the replacement for GIF.

><video muted autoplay> is right there.

>No, I'm not adding a demo. I don't want it on my server. Use video formats for video.

I'm not sure if "Use video formats for video" is saying to use AVIF over JXL or saying to use AV1 over AVIF. If the latter, GIF-like animations have a different enough user expectation that it makes sense to have it as something different from regular videos. Even <video muted autoplay> doesn't encode the full expected behavior because GIFs are not expected to have controls like pause, play and scrub. And even if you hide the controls users will expect similar behavior when opening it in an image viewer or in a new tab. Images do not have controls so they fit better as an image, although maybe they need their own category.

Also, I didn't realize how good AVIF was at progressive rendering. I don't think I knew it could do that at all. I think AVIF is the clear winner for the web, although it is still nice to have JXL for lossless. Somehow I feel that AVIF still hasn't gained as much usage as it should, especially now that it is supported almost everywhere. I think I see more webp than AVIF, and JPEG is still everywhere. Maybe now that JXL is out, developers will take another look? AVIF is supported by 96.35%-98.83% of browsers according to caniuse whereas webp is 97.18%-99.68% and JPEG is 97.28%-99.78%.

I also didn't know there was a Rust JXL encoder named jixel.[0]

[0] https://github.com/awxkee/jixel

Though given the lagging speed in decoding, is there a faster tying JXL decoder planned?

Overall I am getting that AVIF is better on the web...unless Lossless is needed, in that case better take JPEGXL.

* https://caniuse.com/?search=avif

* https://caniuse.com/?search=jpegxl

IE never supported AVIF. Edge even shipped AVIF later than Chrome. One of the leaders of JPEG XL worked at Google until relatively recently. A massive amount of JPEG XL development has been done by a team at Google.

What optimizations are being added? I thought it was basically the exact same codec, but different packaging and usually some adjustment to how the encoder is tuned.

So, is animated AVIF only keyframes / p-frames, where each frame is independent from the other? I was under that impression, uncertain if there are any other capabilities it might have (like only updating part of the canvas when only parts change, like GIF supports)

It does seem like AVIFs win on small images, and JXL gives you progressive rendering, easy upgradability on JPEGs, and better lossless and high bitrate images.

2. Is it possible to encode AVIF with hardware acceleration?

When it comes to hardware encoders, the nicest thing you can say about them is they're fast. Software tends to do way better at quality. Hardware AV1 encoders will be tuned for video rather than stills.

For me personally, AVIF is still better, for various reasons (not solely file size compression ratio as such, though this is my number one go-to objective; browser support is also useful but to me is not so important as it is).

I am keeping a close eye on JPEG-XL, but right now I am quite settled on .avif. All my local collection is in .avif, when before it was a mixture of .jpg, .png and a few animated .gifs. From my findings a few years ago, avif is superior to jpg, png and gifs on pretty much everything it matters. On very high compression, though, I also noticed artefacts, but we had that even more so with jpg, and for 1:1 comparable file size, avif beats jpg with both eyes closed.

By the way, great article. I hope he can do another review, based on that blog entry, in, say 3 years. Would be interesting to see how avif and jpeg-xl have improved. In all likelihood I will still keep on using avif, but if jpeg-xl is a real winner in some areas, I may use it. (Lossless is one area where jpeg-xl excels, but I don't need to store satellite data; I want to store old family pictures in an efficient manner, and here it seems avif is better.)

I am still on webp, thinking that I am on the bleeding edge in a world where artworkers are obsessed with pixels with JPG/PNG as the only formats they know, which is an advance on GIF.

Every browser advertises what formats it will accept and if it is in 'data-saving, low bandwidth mode', so I just configure the CDN to keep the names the same '.jpg' but to send the bestest format for the situation/browser, whether that be webp or AVIF, fetching super-high resolution files from the origin server, outputting them in 'retina' resolution with none of those 'picture' elements referencing half a dozen 'responsive' sizes.

In this way nobody has to care what image format is being served, and if it is deemed that everything is way too compressed, the CDN can be flushed of the cached images, quality increased, and cache rebuilt.

It looks like I will need to update my server configuration to use JPEG XL in the usual five years' time, given the lack of any revolutionary benefit.

I was at Google for 10 years, then went to Shopify for 2 years, but I missed the web. For most of the time I was at Google, it mostly did what was good for the web, rather than pushing Google's interests, but that started to change, which is one of things that led to me leaving. E.g. see what happened with the Prompt API.

But yes, you can see this with jixel, which I'm really impressed by, but it's so tuned to SSIMU2 that it looks really bad to human eyes in some cases compared to libjxl.

But that is correct and why any proper study should first train the participants on the type of artifacts and trade-offs. Like the reference to JXL choices: think its creator mentioned that AVIF might look nicer for faces because it was "smoothing" them but it was a worse representation of the original. So the study participants would need to be conscious of that trade off and be clear in terms of what they're asked to evaluate - whether the result looks nicer or whether it represents the original better.

Perhaps we can use clever experiment design to address it, like doing a "full-reference" evaluation (e.g., pick most similar two images, out of encoder A, encoder B, and original) rather than strictly A/B.

Maybe the first step to designing better encoders is to build an extremely accurate visuoperceptual error metric. Seems like ML's rapid progress haven't caught onto it just yet.

Seems like others were curious too, given the Wikipedia page on Guetzli mentions:

> Butteraugli. ... How the hundreds of parameters that model the properties of the human visual system were derived remains unexplained.

My rough understanding is its multi-scale convolution architecture was inspired by biological visual perception (perhaps how the layers of visual cortex gradually represent higher level features, ish), and involved some sort of empirical parameter tuning based on human evaluations. It'd also be a very nice resource for beginners wanting to learn more about image/video codecs (like me :)

JPEG XL doesn't have that benefit, while sites adoption is arguably a worse issue than browser adoption.

To demonstrate the point even for AVIF itself - it has been in the browsers for a while. Can you use it on common sites? Good luck if you can, even major sites like GitHub and GitLab have issues with it due to some site code depending on hardcoded list of known formats or other similar problems.

ISO-BMFF container is bloated and needlessly complicated. AVIF decoders didn't even want to reuse existing MP4 libraries for it due to all the baggage it brings, and implemented their own minimal parsers.

AVIF would have been better off with a simple wrapper similar to RIFF/PNG or extending AV1's own OBU header (which for inexplicable reason gets its data duplicated inside the HEIF container and then implementations are required to verify that both copies agree!)

I hope AVIF will skip AV2. We don't need yet another almost-identical format to migrate to.

Many other image formats are. AVIF uses HEIC, the same container that HEIF does.

> when AV2, AV3 etc. will come out, there won't be a need to go through another very difficult phase of sites adoption - it will still be AVIF just with newer codec inside, and it will be just up to browsers to catch up on newer versions and newer codecs will address technical needs as times goes.

Fingers crossed, but AV2-based AVIF specs haven't even been finalized, so who knows.

https://github.com/AOMediaCodec/av2-isobmff

With no codec for a new compression algorithm, it does not matter if the browser can read the container, you still see the "broken image" icon on your display.

You as user can then upload AVIF images to wherever images on the site are processed. And after that, let's say when newer codec inside AVIF will get a good browser coverage, you'll be able to start using it without waiting another decade for GitHub to pipe it through their site code.

For formats without a container, it's always a two step process. Browser coverage first, then another huge period of sites support catching up.

[1]: https://github.com/orgs/community/discussions/138164