> Jpeg xl covers several important domains that are not served by AVIF.
I'm not finding any. Mind listing them?
> Once jpeg xl is made available there is no reason to use jpeg1, WebP or AVIF anymore. Then we can simplify again.
Unfortunately, JPEG XL wasn't "better enough" to have a unique selling proposition. And AVIF is the format that actually simplifies things, because it uses the same compressed media format (AV1) as the next-gen video distribution format.
> While that most definitely is a consideration, AVIF lacks many features and much of the functionality offered by JPEG XL.
What features are these? You have not named a single concrete advantage. The places where AVIF out-performs JPEG XL are exactly where it make sense as an image format for the web: high fidelity images with bit rates at or below 1 bit/pixel. Nobody is browsing the web on a 16-bit panel and AVIF supports 12bpc images anyway.
Unfortunately, JPEG XL authors chose not include AVIF when they performed a subjective image comparison in 2020 under controlled viewing conditions (https://research.google/pubs/benchmarking-jpeg-xl-lossylossl...), but previous subjective studies showed AVIF outperforming PIK and FUIF over the evaluated bit-rates.
>We've evaluated AVIF and JPEG XL, with JXL coming out on top.
I would love to see blog post on it. ( Or against it even, we just need good discussions ) But as far as I am know, regardless of politics or ideology, JPEG XL is technically superior to AVIF. And its current reference implementation, isn't even tuned for the best case in many scenarios.
> I do find it hilarious that all the people who complained about Chrome supporting webp then went on to complain about Chrome not supporting JPEG XL.
They are different formats with different attributes, so it's reasonable to distinguish between them. JPEG XL is a general purpose image format. It's reasonable to want browsers to display it. WebP and AVIF are special-purpose formats, designed to leverage their corresponding video decoders, for delivery of ephemeral images to end-user devices. It's reasonable to object to limited formats that are manifestly crowding out general ones.
I don't think you need any kind of conspiracy here, AV1 is an open codec after all. The problem is more that (a) AVIF has been around for longer, (b) browsers have to implement most of the spec anyway because they need to have AV1 support, and (c) the hardware decoding story for AVIF is probably going to be better for quite a while, given its closeness to video. AV1 is still a great codec, and Opus is best-in-class for general purpose audio.
Also, I agree with you that optimizing an image codec for high quality use cases is the ideal, but a lot of casual users prefer blurred images with missing detail to noticeable artifacts.
In many categories of photos or images, JPEG XL [1] actually does better than AVIF in low bitrate settings. Which is the only advantage AVIF has over JPEG XL. And I am increasingly convinced that not losing details is the correct solution rather than smoothing things out in AVIF.
With progressive decoding, JPEG XL is also much a better fit for the web.
I just dont see how we continue to ignore JPEG XL and want to force AVIF adoption everywhere, when XL is technically superior, including encoding and decoding complexity. We literally have representatives from different companies and industries, most have been silent in the image / video codec format war begging for browser vendors to support JPEG XL.
But of course the cult and ideology somehow had people convinced the only accepted codec are AVIF, AV1 and Opus.
> if there is any advantage to JPEG XL over WebP or [AVIF]
Of course there is. Better compression than WebP, and unlike AVIF, it supports progressive decoding, which is super important for users on a slow network. Although AVIF can sometimes produce 50% smaller size files than WebP, many site owners will opt for WebP anyway because it has progressive image decoding, so their website will display something while an image is nothing rather than nothing until the whole image is loaded. With that said, JXL achieves comparable compression to AVIF, and it suffers way less from generation loss, too.
AVIF sort of makes sense in how easy it is to support with the support of AV1 in the first place, but it is one of a long line of still-image codecs based on video codecs (coming to mind immediately are WebP and BPG), and the domain of video is significantly different from that of still images. Individual frames don't need to be as optimal for viewing as the aggregate sequence, fine details often get lost. Progressive decoding basically doesn't exist. Presumably the upper pixel limit is drastically limited for what could be in a still image format.
JXL makes an entirely different set of tradeoffs that really should pit it as the winner for a better still image format. Better quality, wider colorspace support, smaller files, progressive decoding, et al.
Just look at some of the sample pages. To me, it's immediately obvious AVIF's downfalls in fine details versus JXL.
There are actually good reasons for not shipping JPEG XL in web browsers, but the comment doesn't list one. In particular it compares JPEG XL with "existing formats", which seemingly include AVIF, but almost identical arguments could have been used to not ship AVIF in web browsers after all. Essentially it says that they happened to pick AVIF for no apparent reason and because of that they can't pick JPEG XL for no apparent reason again. The comment lacks substances, if not dishonest.
No loss there, just slowdown and additional complexity for the web devs to deal with.
Jpeg xl covers several important domains that are not served by AVIF. Jpeg xl will anchor in these domains and where AVIF cannot provide sufficient quality or speed. Eventually it cannot be ignored any more and will be made available in browsers, too.
Once jpeg xl is made available there is no reason to use jpeg1, WebP or AVIF anymore. Then we can simplify again.
> The biggest problem (of many) was that, in order to read or write the format, you needed to use the Microsoft Structured Storage[1] library, which was a huge pig (at that time. I assume it's better, these days).
HEIC and AVIF are based on the QuickTime file format, which doesn't seem very svelte either. I can't find any reference on the JPEG XL container format so it's probably it's own thing.
> JPEG XL is intended for high quality images, so it is not optimized for this kind of extremely low bitrate (~0.1 bpp) usage.
It's better than AVIF at low bitrates. I did a comparison of the latest builds 3 months ago, and was amazed that JPEG XL has more detail than AVIF at 0.05-0.1 bpp (~120KB 1080p). It's a bit subtle, but I could see it. Once browsers ship full support (at least Firefox + Chrome), I'll be on board.
If it were people wouldn't be pushing for JPEG-XL.
I'm not going to repeat the advantages of JEPG-XL - plenty of posts on that already.
For some bizarre reason, Mozilla chooses to back the other format - release Firefox can display AVIF right now - while leaving JPEG-XL stuck behind a flag in a Nightly.
> WebP also isn't even comparable to JPEG XL: it's the "old next-gen" image format – it's between WebP and AVIF.
This is a nonsense statement of opinion.
AVIF is severely more computationally expensive than JPEG XL (over 100 times worse at high bitrates), limited to 4k resolution, has worse compression, and is missing desirable features like progressive decoding and lossless recompression.
> There is just no incentive for Google to push for WebP: they have nothing to gain by it.
They have complete control over the standard. No one else can make changes to it without their approval. JPEG XL is governed by ISO.
> Regardless of whether AVIF ends up being better than WebP, it’s clear that there are viable alternatives you can use today that are massive improvements over JPEG.
Friendly reminder that there is JPEG-XL which is arguably better for all cases than WebP and AVIF (and also supports progressive decoding!). Unfortunately Google (who have a vested interest in WebP and AVIF), are actively hostile towards supporting it and have outright lied about their reasoning (stating lack of interest despite thousands of developers and market-leading corps saying otherwise).
> AVIF tends to outperform JXL in most web use-cases
Matches my experience pretty well. AVIF can look quite good (for web purposes) at very low bitrates, while JXL falls apart. (JXL actually has two different modes of operation - modular mode is better at lower bitrates, but it's not considered to be JXL's main mode of operation.)
JPEG-XL seems to be designed to replace JPEG for high quality photographic images, and in my experience it's fantastic at this. I see much better results at higher bitrates (compared to AVIF), and JXL can also losslessly compress JPEGs to a smaller size.
There's a comparison between AVIF and JPEG-XL here https://afontenot.github.io/image-formats-comparison although JPEG-XL is rather fast moving target at the moment and the comparison hasn't been updated in quite a few months.
> I don't know what you mean by "unlocking anything new". You have identical images at a smaller size.
Yes exactly, nothing new is unlocked. So why would I use this format? Was the old size of the images preventing me from enjoying them in any way? No. Of all the old JPEGs out there that absolutely must be losslessly transcoded from the already lossy JPEG encoding, how many are prohibitively large? You can still look at both a JPEG and JPEG XL image locally. Most likely you'd be able to serve both images over HTTP, although the JPEG image may take a bit longer to load. And how many cases require the new and old images be exactly the same? My point is that, if the main selling point of your codec is that you can create the same thing as 30 years ago only smaller, then it's going to be a hard sell compared to other formats out there. If the choice was between JPEG and JPEG XL, then sure, let's use JPEG XL. But the choice is between JPEG XL and other formats with better features.
Other image formats like AVIF add new features that enhance images. Yes, the images are smaller, but also way more powerful. Image sequences, for instance, enable new features like "live images." Converting your old JPEG to a smaller JPEG isn't going to magically enable live images.
tldr: I'm looking for a reason to care that I can losslessly re-transcode my old JPEGs. Ok, the re-transcoded images are smaller and exactly the same as before, but what is a real world reason why I would need that vs. using the old JPEG directly or re-transcoding it to AVIF?
I'm not finding any. Mind listing them?
> Once jpeg xl is made available there is no reason to use jpeg1, WebP or AVIF anymore. Then we can simplify again.
Unfortunately, JPEG XL wasn't "better enough" to have a unique selling proposition. And AVIF is the format that actually simplifies things, because it uses the same compressed media format (AV1) as the next-gen video distribution format.
reply