Some will blame Google for the demise of JPEG XL, but I think that's a red herring. JPEG XL includes Google technologies such as Pik and Guetzli/Brunsli. Some of the JXL developers are Google employees. Google doesn't have a profit motive to promote one format over another. Their upper management most likely isn't even aware that JPEG XL exists. It also doesn't explain why Mozilla and Apple are favoring AVIF too.<p>Nonetheless, there's no question that JPEG XL was sabotaged. AVIF was enabled by default in Chrome the day it was implemented, JXL had to go through an experimental period. At some point, Mozilla developers were told to stop working on improving their JXL implementation and they couldn't even merge already developed patches.[1]<p>Google's justifications for the removal were baffling. They said there's "not enough interest" despite all the hype, all the major companies requesting JXL support.[2] They claimed JXL doesn't bring "sufficient benefits", despite the numerous advantages, such as lossless JPEG recompression. They published their flawed[3] benchmarks <i>weeks</i> after they made the decision to remove JPEG XL.<p>BTW, the removal happened immediately after Adobe announced they are supporting JPEG XL in one of their products. Almost as if they realized that JXL may be gaining too much support and it's time to pull the plug.<p>So who's behind this if not Google? To me, the most likely suspect is AOM, the Alliance for Open Media. The people who are involved in AOM also the ones who make the decisions in the browsers. What are their motives? I don't know, pettiness? Maybe they just want <i>their</i> format to win.<p>[1] - <a href="https://phabricator.services.mozilla.com/D119700#3977128" rel="nofollow">https://phabricator.services.mozilla.com/D119700#3977128</a><p>[2] - <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c84" rel="nofollow">https://bugs.chromium.org/p/chromium/issues/detail?id=117805...</a><p>[3] - <a href="https://cloudinary.com/blog/contemplating-codec-comparisons" rel="nofollow">https://cloudinary.com/blog/contemplating-codec-comparisons</a>
Mozilla and Google dropping JPEG-XL support because "too much complexity". Software engineers using "too much complexity" as an excuse for something they don't want to do is such a classic move.<p>Browsers are already absurdly complex, and are constantly receiving HTML, CSS and JS features that significantly increase complexity. Are we really to believe that adding support for a certain image format, which is basically as modular as it gets (decode the file into a buffer), is too much complexity?<p>Obviously, this is a case of them showing favoritism toward codecs based on the IP owners of those codecs.
The Chromium dev who rejected JXL works on AOM code. The manager who commented on it also participated in some articles about the benefits of AV1.<p>JPEG XL could be twice as efficient as AVIF everywhere, and every blog on the internet could benchmark it, and I suspect it still wouldn't make a difference.
I recently tried out HIEF and AVIF to try and save high resolution panorama images to, and discovered that AVIF currently doesn't support images > 8K, despite saving the resolution in 32-bit ints, which is a bit disappointing in 2023. (Limits inherited from the fact it's basically a video codec).<p>Also annoying was the fact I actually had to debug libavif to work out what the problem was, as `avifEncoderAddImage()` would just return a generic error that wasn't helpful when the dimensions were too big, but `avifRGBImageAllocatePixels()` and `avifImageRGBToYUV()` didn't complain about the dimensions beforehand.
Note that AVIF is badly broken in Gimp. Save an image as AVIF, then load it again. Decompose the Luma and Chroma. You will see that the chroma is on a perfect 2x2 pixel grid, as if it was upscaled using <i>nearest neighbor</i> upscaling.<p>This does not happen for JPEG.
I did a small amount of eval work and was not impressed with AVIF when it came to compressing photos I took with my DSLR that I wanted to present as a "photo I took with my DSLR" that is the core of the content. That's a different scenario that a splash image for a landing page, but I was really quite disappointed.
Worth Pointing out again. According to Chrome Stats from Google ~80 to 85% of images served are above BPP 1.0 ( Bit per Pixel ). [1] Figure 1<p>>The number of transferred bytes is important because it affects the latency and hence the user experience. Using this estimate, we calculated that between June 1st and 28th, 2019, the average BPP (weighted by the number of bytes transmitted with that BPP) was 2.97, 2.24 and 2.03 for small, medium and large images, respectively. We confirmed that there was no considerable difference between mobile and desktop platforms. This data indicates that image compression algorithms should target rich images with a relatively high BPP values, aiming to produce 1 BPP images almost free of artefacts instead of 0.5 BPP images with artefacts that are not too intrusive.<p>It has been quite well know by now, at least to those who are familiar with JPEG XL that is doesn't do as well in Non-photographic photos. But it is still much better than WebP or JPEG.<p>I dont know if we could potentially further improve Non-photographic photos, but if you are look at the chart JPEG-XL has a perfect score at below BPP 1.0 already. Compared to AV1 encoder having many years of head start.<p>[1] <a href="https://www.spiedigitallibrary.org/conference-proceedings-of-spie/11137/111370K/JPEG-XL-next-generation-image-compression-architecture-and-coding-tools/10.1117/12.2529237.full?SSO=1" rel="nofollow">https://www.spiedigitallibrary.org/conference-proceedings-of...</a>
> The Chromium team shouldn't have the absolute authority to shoot down would-be standards like this<p>I’m not sure that “the Chromium team” is a real thing. Chromium is a cross-company project. People from different companies and different teams work on it together. Google has a Chrome team.<p>edit: I’m not familiar with the Google JPEG-XL situation, but generally speaking, it should be possible to ship a feature in Chromium without Google’s involvement because there are three non-Google Blink API owners (last time I checked).
Is there a patent, copyright, or royalty reason why JPEG-XL isn't championed for the web? It would be awful to have another format that can't be used in certain Linux distros or browsers.
I think the most interesting takeaway here is that while JXL continues to face unfair treatment from web browser vendors, jpegli is a really fascinating development that performs very closely to AVIF at high quality in the dataset. I'd like to test jpegli with the XYB colorspace in the future to see how much better it is compared to RGB, but even with the RGB handicap it still looks very promising.
If image types were implemented the way they are on the Amiga OS, we wouldn't be having this conversation about whether jpeg-xl will be supported in a web browser.<p>When you add a jpeg-xl.library, every app on the system instantly supports loading and saving that image format.