Basically, AVIF won the OS-level support race by a landslide. JXL hasn't taken any victories in OS-level support yet. With the winner increasingly becoming obvious, time to cut the losses on JXL and run.
Part of this may be as well that AVIF is basically just an AV1 still. If you implement AV1, you've got 95% of your AVIF support already done.
JPEG XL's problem is that WebP has now existed for 10 years and has widespread support.
Instead, what happened was that WebP started to be used on the web and this broke websites for Firefox users.
Since Firefox is by no means dominant on the web, we had to follow suit or lose more users.
Mozilla didn't support WebP for years. I'm fairly certain one of the official reasons they gave for not doing it was that it wasn't a massive jump in quality over JPEG, which obviously would have been good for the web if it was true and motivation for them to support it sooner than they did.
Notably, when they did add it, Edge did so around the same time, which seems to me suggests some politics in the background, (not in a conspiracy sense, just an agreement based on interperability) which I suspect might apply this time too.
It was kind of an artificial split, much like text, alpha transparency or line drawing might be done as PNG, not because you wanted them to be "lossless" but because JPEG would mess them up due to a lack of tools for reproducing non-natural photo content.
See the lossless comparison here for more:
here, a better comparison: https://siipo.la/blog/whats-the-best-lossless-image-format-c...
this one is also good: https://www.reddit.com/r/AV1/comments/fjddcj/lossless_image_...
basically: JPEG XL does things right, WebP lossless is also not bad (14.8 % worse than JPEG XL), PNG is ok for its age (46.3 % worse), AVIF didn't focus on lossless (63.0 % worse)
If they invested the same resources into improving and promoting JPEG XL, we'd be using JPEG XL. I'm not saying the outcome is objectively worse, but ultimately, they did pick the winner here.
If you look at slide #14, you'll see Opera was an early adopter. Firefox published a "No" blog-post in 2013, and Safari removed WebP support from Sierra preview in 2016, eventually adding it back in 2020. Stuff happened.
And yes, when WebP was created there was a real, non-incremental, need for a Web-oriented image format. Nowadays, it's just incremental improvement on this idea for browsers.
(disclaimer: WebP initiator here)
> Helping the web to evolve is challenging, and it requires us to make difficult choices. We've also heard from our browser and device partners that every additional format adds costs (monetary or hardware), and we’re very much aware that these costs are borne by those outside of Google. When we evaluate new media formats, the first question we have to ask is whether the format works best for the web. With respect to new image formats such as JPEG XL, that means we have to look comprehensively at many factors: compression performance across a broad range of images; is the decoder fast, allowing for speedy rendering of smaller images; are there fast encoders, ideally with hardware support, that keep encoding costs reasonable for large users; can we optimize existing formats to meet any new use-cases, rather than adding support for an additional format; do other browsers and OSes support it?
> After weighing the data, we’ve decided to stop Chrome’s JPEG XL experiment and remove the code associated with the experiment. We'll work to publish data in the next couple of weeks.
> For those who want to use JPEG XL in Chrome, we believe a WebAssembly (Wasm) implementation is both performant and a great path forward.
> Jim