YHK - yet another hacker news clone

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.

Overall I am getting that AVIF is better on the web...unless Lossless is needed, in that case better take 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)

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.

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

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

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.

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

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

It's hard to rigorously judge a codec from a handful images, especially given the large impact they would have (with a widely adopted codec encoding bazillions of images in the coming years).

* There are many intricate details that go into codecs and visual perception. For instance, our sensitivity to visual errors are dependent on colors (all of hue, saturation, and brightness), spatial frequency of artifacts, local contrast and texture presence, et cetera.

And like OP mentioned, perceptual error metrics (including SSIMULACRA2) aren't perfectly representative of human-evaluated visual quality. For instance, libjxl deliberately makes choices that hurt SSIMU2 scores, but improve human-rated quality.

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

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

(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

  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}

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.

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.

- 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

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

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.

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

)

That said, I last benchmarked over a year ago, maybe I should re-evaluate. My experience was that AVIF was too slow for on-the-fly encoding, while JXL was absolutely fine and JPEGLI was also pretty useful.

Amazing.

Have you tried encoding with JPEG XL’s modular mode? By default, libjxl only uses it for lossless and I haven’t tried with jixel, but in my experience, it often handles clean edges and smooth surfaces (the likes of which you might see in digital art) better.

> I'm a little nervous about this, because discourse around JPEG XL can get a little… weird.

As someone who’s been rooting for JPEG XL for years now, I also find the discourse a little upsetting. When first introduced, the format was very competitive with AVIF and steadily improving, until Google decided to single-handedly halt web adoption (de facto, because market share). No careful evaluation presented, no solid argumentation given.

My understanding is that the future of the format became uncertain at that point, because web adoption is regarded as crucial and no one wants to go all-in on a codec that may not end up filling the universal role it was designed for. Of course, AV1 encoders kept seeing lots of interest and improvement in the meantime, because everyone was already all-in on AV1 for video.

And now, when JPEG XL has finally painstakingly clawed its way back onto its original trajectory, now there are comparisons popping up showing how AVIF actually compresses better. People end up quoting them around social media, painting the picture that JPEG XL turned out to be the inferior format after all. It hasn’t, it just got a massive handicap.

Not that it’s a problem with your article. It’s informative, you compare the current state of available encoders for a specific use case, and you mention how they’re still evolving. It just sucks that we can’t really do a fair comparison of the formats at this point, yet that’s exactly what people will end up doing anyway, and it’ll really suck if it ends up hurting JPEG XL even more than Google already has.

JPEG XL can't be decoded in such a way, and tons of people still use JPG.