JPEG XL vs. AVIF for web use-cases (jakearchibald.com)

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).

Text has lots of edges, hard transitions between bright and dark areas. So text requires lots of high-frequency detail, and JPEG adds a lot ringing as it bounces off all those lines and curves.

AVIF seems to follow contours, so it does a good job with line art.

Otherwise, it's hard to beat the Mozilla JPEG encoder.

JPEG XL can represent lossless images that exceed the limits of human vision. I don't expect it to replace FITS for astronomical images, but the future is weird.

(Super huge thanks to Jake Archibald for the SVGOMG web app. Which is also fantastic for line art.

https://jakearchibald.github.io/svgomg/

Squoosh is a web app front end to various image encoders

https://squoosh.app

)

  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}

- 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

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.

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.

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.

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

(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

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

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

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)

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.

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?

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.

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.)