JPEG XL is an industry standard, but Google likes a rival it helped develop called AVIF, and Apple iPhones shoot photos in yet another format, HEIC.
There’s more to like about JPEG XL than space savings. It’s tuned for photographic use, doing a better job at preserving fine details and textures than video-derived formats like AVIF and HEIC. JPEG XL also improves image quality through HDR support, one of the reasons that Adobe -- ordinarily conservative with new file format support -- endorsed it. Facebook praises JPEG XL’s speed, and Intel thinks JPEG XL is the best of the next-gen photo format options.
Google doesn’t have veto power over JPEG XL’s future, but as the maker of the world's most-used browser, it can effectively block its use on the web.
Stephen Shankland
Speaking of image formats and browser support, here’s another example of Google using Chrome’s dominance to favor its own interests on the web, in this case by refusing to support an industry standard on questionable grounds. From everything I’ve read about JPEG XL it’s superior in almost every way to both JPEG and AVIF. But hey, this is what happens when developers cheer on browser engine consolidation because it makes their lives easier; eventually the dominant player gets to veto which standards receive attention and which fade into oblivion.
The actual implementation of JPEG XL in Chrome is based on an integration of libjxl, which is itself not maintained by Chrome, though they do have to assess and possibly even mitigate — if the libjxl developers would not provide a timely response — potential security bugs that could get discovered in it, like with any ‘third party’ library integrated in Chrome. All the integration work has already been done, including what is needed to make alpha transparency, animation, color management including HDR, and progressive decoding work properly. The main remaining “burden” we are still talking about at this point essentially amounts to occasionally bumping up a version number in a build script, in case there is a new version of libjxl that brings improvements that are useful for Chrome. The Chrome team has not been working on improving libjxl in the past (and is also not expected to do that, to be clear), so it is not clear how removing the flag would make a difference in their ability to focus on other things.
Jon Sneyers
Technically, as Chromium is open-source, other companies could implement a new image standard without Google’s support. But since Google ultimately decides what ships in the stable version of Chrome, it could still deny this image format to the majority of people browsing the web. In the end, the issue boils down to economic incentives. Each major browser vendor is a large corporation (by that I mean Apple, Google, and Microsoft; I don’t see Mozilla as having enough relevance left in this space to make a difference); each bears some costs to maintain their browser, but only one is making significant revenues on the web – Google – and therefore has every reason to push its agenda forward and ignore ‘distractions’. I don’t see this dynamic changing without solid competition, which unfortunately is unlikely to arise from the other two large companies. Apple is focused on its mobile App Store to the point it would happily give up WebKit if that meant more App Store taxes without public blowback, and Microsoft abandoned its rendering engine and adopted Chromium, not wanting to compete in a field where it had little strategic interest.
Ironically, the Squoosh webapp developed by Google includes beta support for JPEG XL, so anyone can compare its compression with AVIF – although the lossy ‘Quality’ setting seems incompatible between the two, with AVIF using a non-standard range of 0 to 63.
Post a Comment