JPEG-XL provides the best migration path for image conversion from JPEG, with lossless recompression. It also supports arbitrary HDR bit depths (up to 32 bits per channel) unlike AVIF, and generally its HDR support is much better than AVIF. Other operating systems and applications were making strides towards adopting this format, but Google was up till now stubbornly holding the web back in their refusal to support JPEG-XL in favour of AVIF which they were pushing. I’m glad to hear they’re finally reconsidering. Let’s hope this leads to resources being dedicated to help build and maintain a performant and memory safe decoder (in Rust?).
It's not just Google, Mozilla has no desire to introduce a barely supported massive C++ decoder for marginal gains either:
https://github.com/mozilla/standards-positions/pull/1064
avif is just better for typical web image quality, it produces better looking images and its artifacts aren't as annoying (smoothing instead of blocking and ringing around sharp edges).
You also get it for basically free because it's just an av1 key frame. Every browser needs an av1 decoder already unless it's willing to forego users who would like to be able to watch Netflix and YouTube.
I don't understand what you're trying to say. Mozilla said over a year ago that they would support JXL as soon as there's a fast memory safe decoder that will be supported.
Google on the other hand never expressed any desire to support JXL at all, regardless of the implementation. Only just now after the PDF Association announced that PDF would be using JXL, did they decide to support JXL on the web.
> avif is just better for typical web image quality, it produces better looking images and its artifacts aren't as annoying (smoothing instead of blocking and ringing around sharp edges).
AVIF is certainly better for the level of quality that Google wants you to use, but in reality, images on the web are much higher quality than that.
And JXL is pretty good if you want smoothing, in fact libjxl's defaults have gotten so overly smooth recently that it's considered a problem which they're in the process of fixing.
I disagree about the image quality at typical sizes - I find JPEG-XL is generally similar or better than AVIF at any reasonable compression ratios for web images. See this for example: https://tonisagrista.com/blog/2023/jpegxl-vs-avif/
AVIF only comes out as superior at extreme compression ration at much lower bit rates than are typically used for web images, and the images generally look like smothered messes at those extreme ratios.
Not everything in the world is passive end-of-the-line presentation. JPEG-XL is the only one that tries to be a general-purpose image format.
If that's the case, let it be a feature of image editing packages that can output formats that are for the web. It's a web standard we're talking about here, not a general-purpose image format, so asking browsers to carry that big code load seems unreasonable when existing formats do most of what we need and want for the web.
People generally expect browsers to display general-purpose image formats. It's why they support formats like classical JPEG, instead of just GIF and PNG.
Turns out people really like being able to just drag-and-drop an image from their camera into a website - being forced to re-encode first it isn't exactly popular.
> Turns out people really like being able to just drag-and-drop an image from their camera into a website - being forced to re-encode first it isn't exactly popular.
That’s a function of the website, not the browser.
Can AVIF display 10 bit HDR with larger color gamut that any modern phone nowadays is capable of capturing?
if you actually read your parent comment: "typical web image quality"
Typical web image quality is like it is partly because of lack of support. It’s literally more difficult to show a static HDR photo than a whole video!
PNG supports HDR with up to 16 bits per channel, see https://www.w3.org/TR/png-3/ and the cICP, mDCV and cLLI chunks.
With incredibly bad compression ratios.
HDR should not be "typical web" anything. It's insane that websites are allowed to override my system brightness setting through HDR media. There's so much stuff out there that literally hurts my eyes if I've set my brightness such that pure white (SDR FFFFFF) is a comfortable light level.
I want JXL in web browsers, but without HDR support.
>avif is just better for typical web image quality,
What does "typical web image quality" even mean? I see lots of benchmarks with very low BPPs, like 0.5 or even lower, and that's where video-based image codecs shine.
However, I just visited CNN.com and these are the BPPs of the first 10 images my browser loaded: 1.40, 2.29, 1.88, 18.03 (PNG "CNN headlines" logo), 1.19, 2.01, 2.21, 2.32, 1.14, 2.45.
I believe people are underestimating the BPP values that are actually used on the web. I'm not saying that low-BPP images don't exist, but clearly it isn't hard to find examples of higher-quality images in the wild.
> (in Rust?)
Looks like that's the idea: https://issues.chromium.org/issues/462919304
Wanted to note https://issues.chromium.org/issues/40141863 on making the lossless JPEG recompression a Content-Encoding, which provides a way that, say, a CDN could deploy it in a way that's fully transparent to end users (if the user clicks Save it would save a .jpg).
(And: this is great! I think JPEG XL has chance of being adopted with the recompression "bridge" and fast decoding options, and things like progressive decoding for its VarDCT mode are practical advantages too.)
> and generally its HDR support is much better than AVIF
Not anymore. JPEG had the best HDR support with ISO 21496-1 weirdly enough, but AVIF also just recently got that capability with 1.2 ( https://aomedia.org/blog%20posts/Libavif-Improves-Support-fo... ).
The last discussion in libjxl about this was seemingly taking the stance it wasn't necessary since JXL has "native HDR" which completely fails to understand the problem space entirely.
The JXL spec already has gainmaps...
Also, just because there's a spec for using gainmaps with JPEG doesn't mean that it works well. With only 8 bits of precision, it really sucks for HDR, gainmap or no gainmap. You just get too much banding. JXL otoh is completely immune to banding, with or without gainmaps.