> That's rich coming from the company that tried to kill it
This post is written by three of the authors of the JPEG XL spec, implementors of the reference and rust implementations of libjxl, and...longtime google employees.
Mozilla's position from when Chrome first dropped it to September 2024 was "the benefits it provides are not significant enough on their own to justify the cost of adding another raster image format to the Web" [0], which they say is a "neutral" stance. Then like Chrome they only agreed to try it with jxl-rs [1], which is still their present stance. They are a complete passenger in this whole affair, like all other standards, where they basically just copy one side or the other (usually the more conservative side).
It's really bizarre to me that this is presented as "killing the standard". Is Apple also killing mechanical keyboards and hobby electronics development because they're the only ones who don't support Web USB or Web Serial? I strongly prefer having JXL and Web USB/Serial in my browser (FF for the last 20 years), but come on. If we don't like how much power browsers have in software distribution, then maybe software distribution outside of browsers should get fixed.
> Is Apple also killing mechanical keyboards and hobby electronics development
Obviously not, but they are killing as web standards the things they omit. At present for something to be standard it needs support from safari and chrome. That's just the current state of the world.
If tomorrow safari removed support for png that would effectively kill it as a web standard (assuming it didn't lead to mass revolt ofc).
For context, Google initially refused to merge JpegXL as a strategy play to promote AVIF, which was in use by other teams (i think Photos?). Internally, chrome engineers were supportive of jxl but were overridden by leadership.
I guess today’s post represents a change.
I don’t have any public evidence to support my claim, sorry. Take it or leave it
We (Google) built JPEG XL (together with Cloudinary). The main photography mode and the JPEG compatibility mode is from Google.
Chrome decided not to be an early adopter for good reasons that they have publicly documented, but that did nothing to JPEG XL. Particularly, it did not kill JPEG XL. Others, DNG, DICOM, PDF, EPUB, iOS, Safari, etc. integrated it early regardless.
Yeah, but they left out that Chrome removed their own support for JPEG XL saying no one in the industry was in favour of it despite everyone seeing it was the future screaming for it and building support for it into their own products.
Chrome's blink was the only major browser engine not supporting it and that prevented it from becoming a web standard and they refused to acknowledge they were wrong.
Chrome only backtracked once jpeg-xl was subsumed into the PDF standard because if Chrome did not support jpeg-xl, they would by extension also not be supporting pdf.
jpeg xl is also now used for the latest version of the DNG raw image format, and the iphone now encodes raw images as jpeg xl in DNG. It's so clearly the future for photography that Google is holding back. Apple surprisingly has been the first with full support everywhere in their OSs and in Safari.
I just wanted to add the decision for JXL inside DNG was well known even before it happened and Chrome still said no. Adobe and Intel along with plenty of other players in the industry screams this is so good they are all adding support. But still Google said no.
And to make matter worst the publish the worst comparison document and benchmarks for AVIF against JXL.
This post is written by three of the authors of the JPEG XL spec, implementors of the reference and rust implementations of libjxl, and...longtime google employees.