Cloudinary: The 'dramatic' story of JPEG XL support so far
This is a guest post for the Computer Weekly Developer Network written by Jon Sneyers in his role as senior image researcher at Cloudinary, a company that helps engaging brands around the world create, manage and deliver visual experiences at scale.
Sneyers is also the co-chair of the JPEG XL ad hoc group and co-creator of the Free Lossless Image Format (FLIF) – and he writes as follows…
Serving up the right images on your web page, in optimal sizes and formats is important for so many reasons. Among them: producing high-quality end user experiences, boosting SEO and using resources, from data storage to CO2, as efficiently as possible.
That’s why, as a developer working on image processing and compression, I was so eager to get involved in the movement to create JPEG XL (think “to excel”, not “extra large”), a successor to JPEG. Bearing in mind that JPEG was created more than three decades ago in 1992, it is actually based on a lossy compression technique dating back to 1972. So it’s fair to say the standard was ripe for replacement.
But the story of JPEG XL has not been without its plot twists. I realised that the drama that’s unfolded around the standard since 2019 has followed a classic three-act plot structure.
Act I: setting up the problem
It’s hard to believe that when I first briefed Computer Weekly on JPEG XL in 2019, we had only recently formed the committee and issued its call for proposals. The FUIF format I developed for Cloudinary and Google’s PIK format were eventually chosen as the starting point for JPEG XL.
The most powerful way to explain why we set up the standard in the first place is to summarise JPEG XL’s current benefits.
Legacy friendly. Existing JPEG images can be converted to JPEG XL without any loss (no generation loss) — this cannot be done in any other new image format. JPEG XL files are 20% smaller and can be converted back to the exact same JPEG file.
Royalty-free. Good-quality, complete, free and open source reference implementation makes it relatively easy to add support for applications.
Supports lossless compression. This is done competently, even for non-photographic images where, currently, PNG is widely used.
Supports progressive decoding. An important feature for web delivery, this enables an image preview to be shown while it is still being transferred.
Supports high-fidelity lossy compression. This means the standard is fully prepared for the fidelity offered by cameras and display devices of today and of the future. JPEG XL supports a high dynamic range, wide colour gamut, high resolution and new kinds of sensor data like depth maps and thermal imagery. It offers up to 60% better compression than JPEG at the high fidelity end of the spectrum. Other new formats struggle to even match JPEG in that range as they are mostly optimised for the typical quality range of web video.
Relatively low computational cost. Images can be encoded quickly, with low energy consumption. This can add up to serious carbon reductions for companies that use a lot of online web images. Specifically, we’ve calculated that with JPEG XL, storage and transfer costs for photos could both be reduced by 60%.
In other words, JPEG XL is a very promising new format with potential for use across the entire workflow: from image capture and authoring to delivery and archiving.
When Chrome added preliminary support to the Chrome browser in April 2021, many web developers and companies like Adobe, Meta and Intel got really excited about finally having a worthy successor to JPEG – and then…
Act II: The Halloween 2022 frightmare!
Almost a year ago to this day, a major setback occurred when Chrome developers unceremoniously announced the removal of JPEG XL support. The reasons given were sufficiently woolly and debatable: flags should remain indefinitely; not enough interest; not enough incremental benefits. I won’t rehash my impassioned arguments against this decision but you can read them in my update to Computer Weekly last year.
Act III: The momentum returns
Then at Apple’s annual Worldwide Developers Conference (WWDC23) last June, something completely unexpected happened: JPEG XL was listed on a slide amongst new features of the Safari 17 browser. Not only that, Apple announced that new versions of iOS, iPadOS, macOS, watchOS and visionOS would also support JPEG XL.
None of the JPEG XL developers had anticipated that the first browser to support this format which was co-created by Google, would be Safari. This was, of course, great news for the adoption of JPEG XL.
Thanks in part to Apple’s announcement (*whisper it*) perhaps Google might reinstate JPEG XL support within Chrome. This would mean the momentum has well and truly returned. After all, even scary Halloween classics like The Shining had a happy ending.