Maybe a lossless re-encoding of my website JPEGs to gain 20% size is not worth the 33% longer decode, and maybe the website doesn't need very high resolution images or more than 12 bits per channel. But my personal archives can definitely use that and it's great that such files can be viewed everywhere without specialized tooling, including served on the intranet and indeed the Web.

In summary JPEG XL easily beats AVIF on the not-so-long tail of use cases and having compatible viewers everywhere is quite useful. And with JPEG XL becoming part of PDF, it will soon be common use cases too.

As for the rest of the article: there are interesting points in the benchmark section but I think it's too early in the JPEG XL adoption cycle to draw conclusions. One thing bothers me though: There is a single picture comparison (with tag line "results speak for themselves") and I find it quite misleading: it's just picking one point on the "bytes received" line that looks best for AVIF compared to JPEG XL. Try it yourself and you'll see JPEG XL shows something already at 2KB while AVIF has nothing until 8KB, and JPEG XL looks better than AVIF after 100KB.

Also, good lossless compression absolutely does matter for the web as well. Lossy images just cannot be used in all circumstances - like when comparing compression quality (especially of videos), for example!

EDIT: To give an additional example, pixel art is an entire field of art (which is very much still active today) where both lossless compression is a must and where 4:2:0 would be absolutely catastrophic for quality.

Moreover, there are some methodological oddities. For example, JPEG XL decoding is tested in single-threaded mode when it's optimized for multi-threaded decoding (where AVIF has artifacts from tiling). Also, the tested command is "jxl_cli --speedtest", which means that the benchmarked time includes the warm-up procedure of the "--speedtest" flag, rather than the pure decoding time.

Another example of this is progressive rendering, where the comparison moment is chosen at a local maximum that favors AVIF. JPEG XL materializes a full frame much sooner than AVIF, and starting at, say, the 96,256 B mark, it looks better than AVIF until the full image is loaded.

This is a good paragraph. I see people forget to apply that last sentence all the time.

That considered, I don’t think it’s a fair comparison between the codecs. JPEG XL used to be far more impressive than AVIF; it’s great people (author included) have managed to push AVIF forward, but until similar efforts have been made for JPEG XL in earnest, I don’t feel like a comparison between their encoders says much about the codecs themselves. The author does take a guess on how much the JXL encoder could be improved, but that’s just that: a guess. It won’t be know until it’s been tried. And especially given the whole unfortunate history, I think JPEG XL really, really deserves a try.

It is, however, an incredibly cool demo of what the format is capable of. I'm not completely sure if an image format should be that flexible, but I'm impressed nonetheless.

I believe Web codecs should be purpose-built, efficient, and narrowly scoped to the needs of the Web.

The post downplays the usefulness of versatility. I disagree. I'd prefer not to play the "which image format is best for this image and this use case" game and having to transcode between them. For instance, it would be great if I could have an HTML gallery showing pictures of my files as I store them on harddisk. Today these are JPEG, because it's the lowest common denominator. WEBP, AVIF are not supported photography tools (e.g. https://support.captureone.com/hc/en-us/articles/36000262921...) and I don't expect support to ever be added since it is not formats intended for photography.

That said, I have converted my personal JPEGs to JPEG XL, because you can losslessly convert back and forth between the two for smaller filesize in JPEG XL with no quality loss, so I get free storage savings and can get the byte-for-byte original JPEG back if I need it.

1) AVIF has now been radically improved to the point where it's actually quite good in ways that previously it was not.

2) JXL will not be improved despite the fact that the performance of every other codec has always radically improved over time.

Everything else aside, including a few clear methodological errors, it's ahistorical and unsightly to be unwilling to imagine that future implementation effort will accomplish anything. Some might call it hypocritical.

Because of it, for the past couple of years, all new iPhones and almost all Android phones (mostly Samsungs) already contain a JPEG XL encoder / decoder (to generate these DNGs).

Normal people don't pick an image format based on whether it is suitable on the web or not. They want a format that works everywhere. If I download or upload a photo I don't want to have to do a lossy format conversion. If I'm writing an image processing tool it would be great if I can make it just support one input format that everyone uses, rather than "web" formats and "non-web" formats.

So I think a large part of the attraction of JXL is that it is a single format that works both for 10000x10000 lossless scientific images, and for 256x256 lossy web photos. You don't have to be an image format expert any more. Just always use JXL.

Definitely a shame about the technical flaws listed here though - especially decode time.

For Lossless: JPEG-XL wins, then WEBP, then PNG. (Sometimes lossless WEBP wins)

For Lossy: AVIF wins, then JPEG-XL, then WEBP, then JPEG.

- it's first image is way earlier: 2KB vs 8KB

- from 8KB to 100KB it's blurrier than AVIF, but it's more pleasing to look at and less blocky than AVIF. I highly prefer it.

- from 100KB until finished 288KB it's actually ~4x sharper than AVIF

Overall JpegXL gives the much nicer experience.

^ tested with pokebowl (https://jpegxl.info/resources/progressive-loading-demo.html)

Browsers are new OSes.

There is no any «web» anymore. E-mail clients are web, news readers are web, image galleries are web, heck, even image editing software could be web (google:photopea).

And as such there should not be «web-optimized» formats anymore.

and narrowly scoped to the needs of the Web

it was hard enough to get widespread WebP adoption

That's not a coincidence! And because these newer codecs are better outside the Web, it's not really "the same hill"

  - dimensions
  - filetype 
  - minimum required decoder version
  - lossless: true/false
  - a list of alternative URLs and mimetypes to older image formats

Then any future image format is a simple drop-in without requiring complex processing on the server side or a lot of complexity in HTML (not to mention CSS)

It's very hard to beat the encoding performance of libjpegturbo, even with an asic.

What does it offer there that existing workflows can’t support? Do those advantages make up for the transcoding that every web publisher would need to do to make the outputs useful on the web?

Progressive rendering (which AVIF supports) decodes a low-fidelity rendition before the full image arrives. AVIF didn't support progressive rendering for a while, and during that time I believe it was deeply oversold. Now that libavif has implemented it (it was always possible), the conversation appears to be over.

This is false. AVIF does not support progressive decoding/rendering. What the author is referring to here is image layering. A lower resolution image layered below the full resolution image, which is loaded and rendered first. That is not progressive decoding/rendering. It is a thumbnail.

Unlike AVIF's false advertising, JXL truly supports progressive decoding/rendering. With JXL, you do not first load a thumbnail before loading the actual image. The lower-quality image that JXL shows while decoding is derived from the data of the actual, full-resolution image.

Ignoring AOM and AV1, I was the first few on HN apart from its author supporting JXL from the start, I would argue the biggest case against JPEG XL is JPEG li.

Jpegli offer enough quality improvement and advantage without introducing an entirely new codec. And all of a sudden the bar for next image codec now needs to be even higher.

[1] https://storage.googleapis.com/avif-comparison/index.html

only roughly 11.9% smaller than lossless WebP anyway

That’s huge, no?

I don't want an image to appear in any form until its loaded. I never need to see a blurry placeholder, and there is zero value in that even with bad connections, but the situation is farcical when everyone has ultra-fast connections everywhere.

This is similar to pages that use custom fonts but will happily show the text as quickly as it can, and then suddenly restyle/relayout the page when the custom font loads (Flash of Unstyled Text - FOUT). It looks terrible and is jarring. Progressive rendered images are the same.

Not to mention an additional compatibility headache now exists for anyone just trying to download an image from the Internet and use it somewhere – it was hard enough to get widespread WebP adoption, and I don't think it's worth doubling the pain by having to climb the same hill for AVIF and JPEG XL. Especially when JPEG XL doesn't appear to add anything to the Web platform.

It is very annoying downloading an image for the web and then trying to upload it somewhere else also on the web during these transition periods.

Because of Gianni's great post, I've decided to go full throttle on rewriting and finally publishing the JXL vs AVIF post after deciding to partially shelve it last year.

This should be especially interesting looking at the differences between my testing and Gianni's.

really strange article.

Computers should not be making images look worse than they were captured. It's not 1996 anymore. We don't need to be doing this at all.

Backwards compatibility is cool; stop the fucking churn! I have done this just within this past week, in fact, when I moved a JPG over to my Mac OS 7.6.1 machine (PowerBook 2400c!) to use as a new desktop wallpaper†.

† Via Décor https://macintoshgarden.org/apps/decor

This rules out JPEG XL's lossless advantage, which in practice is only roughly 11.9% smaller than lossless WebP anyway

It cannot be worth bringing a new image codec to browsers to save 12%

What? 12% is huge.

AVIF's "royalty-free" is under active legal attack (Dolby v. Snapchat). JXL has clean ISO commitments so no such suit would be possible. If "free" matters, JXL is safer.

Perceptive quality with the latest AV1 caught up, but that's a rigged timeline. Chrome supported JXL "late", then pulled it altogether. AVIF did improve further yes, it had web usage, it was behind when the race was meant to start. Why would JXL continue to optimize for web once the major browser refuses to support it.