Chrome Doesn’t Support JPEG XL
Jim Bankoski (2022):
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.
Jon Sneyers (2023, via Hacker News):
In early April 2021, the Chrome browser added experimental support (behind a flag), even before the JPEG XL standard was officially published. (The final draft had been submitted to ISO, but it would still take until March 2022 before it was approved and published as the international standard ISO/IEC 18181.) Firefox followed suit quickly and added experimental support. Things were looking good.
Then, on Halloween 2022, Chrome developers suddenly announced that they would be removing JPEG XL support. This decision was quite unexpected and controversial. In my blog The Case for JPEG XL, I argued why this decision should be reversed. In December, Chrome developers provided test results that were used to justify the decision and invited feedback. I analyzed the results and pointed out several methodological flaws and oversights. So far, my feedback has been ignored.
Beyond browsers, adoption of JPEG XL continued, in particular in image authoring software like Serif Affinity, Adobe Camera Raw, GIMP, Krita, etc. Unfortunately, Chrome’s decision has slowed wider adoption in web browsers of JPEG XL.
Ernie Smith (via Hacker News):
The JPEG file format has served us well. It’s been difficult to remove the format from its perch. The JPEG 2000 format, for example, was intended to supplant it by offering more lossless options and better performance. The format is widely used by the Library of Congress and specialized sites like the Internet Archive, however, it is less popular as an end-user format.
Other image technologies have had somewhat more luck getting past the JPEG format. The Google-supported WebP is popular with website developers (and controversial with end users). Meanwhile, the formats AVIF and HEIC, each developed by standards bodies, have largely outpaced both JPEG and JPEG 2000.
JPEG XL seems better, but even Apple’s not supporting it everywhere yet.
Previously:
7 Comments RSS · Twitter · Mastodon
I tried converting a bunch of screenshots of macOS windows to lossless JPEG XL to find out if it was better than lossless WebP.
Some of the screenshots were a bit smaller than the corresponding WebP.
Some of the screenshots (with large areas of all the same color) were a bit larger than the corresponding WebP.
For what it's worth, Mozilla isn’t a huge fan of JPEG XL, either. From Wikipedia:
Mozilla expressed security concerns, as they feel that the rather bulky reference decoder would add a substantial amount of attack surface to Firefox. They expressed willingness to ship a decoder that meets their criteria if someone provides and integrates a suitable implementation. The JPEG XL team offered to write one for them in the memory-safe Rust language.
I don’t think Chromium has Rust anything in it now, so I doubt the existence of a JPEG XL decoder in Rust is going to change anything for them.
For anyone interested in using new image formats to optimise website performance, I actually just re-designed and re-launched my app's website yesterday:
As part of the redesign, I used a post-processing static website optimiser called Jampack (https://jampack.divriots.com).
This optimises all of the content and converts any JPG or PNG images to WebP format. I personally didn't have any particular affinity for using WebP, as I have found that JPGs and PNGs exported from Sketch seemed fine.
However, it was quite eye opening the impact that the conversion to WebP has made.
The overall website size, after optimisation, is only 40% of the original. Total website size went from 819MB to 335MB.
The majority of this came from the automated png->webp and jpg->webp conversions.
Jampack also inlines certain items and makes some lazy-loading changes, which I may revert, as they might actually detract from the site's UX. But overall it's a great example of what changing to more modern web image formats can achieve.
Yeah, modern image formats are pretty great. Running oxipng on my PNG images roughly halves their size, and then lossless WebP halves those again. I’ll probably never bother with Zopfli compression in oxipng from here on out.
macOS Tahoe supports writing AVIF. Can even use in save panel if you click option key on IKSaveOptions (in Preview)
(lldb) po CGImageDestinationCopyTypeIdentifiers()
(
public.jpeg,
public.png,
com.compuserve.gif,
public.tiff,
public.jpeg-2000,
com.apple.atx,
org.khronos.ktx,
org.khronos.ktx2,
org.khronos.astc,
com.microsoft.dds,
public.heic,
public.heics,
public.avif,
com.microsoft.ico,
com.microsoft.bmp,
com.apple.icns,
com.adobe.photoshop-image,
com.adobe.pdf,
com.truevision.tga-image,
com.ilm.openexr-image,
public.pbm,
public.pvr
)
As a regular old computer user, I really want JPEG-XL to "win". It seems to have features and performance on par with all of the competitors, but also the killer feature of being able to losslessly compress regular old JPEG files. There are a *lot* of regular old JPEG files in the world and being able to store them in a more efficient format that is easily reversible for legacy applications seems like a big win.
Converting to webp results in much smaller images so it makes sense why it’s popular for web. Better than converting to jpeg (regular don’t know anything about xl)
Would be great to get better support for webp in macOs. I convert to webp using google’s command line tool. Preview can open them but i don’t think you can export to webp. I think markup features are disabled if you open a webp in Preview until you convert it to something else
@Objc4life Yeah, WebP support in macOS is getting better but not quite there yet. And I don’t think Lightroom can read it yet, either.
