Journey to JPEG XL: open-source experiments shaped the future of image coding(opensource.googleblog.com) |
Journey to JPEG XL: open-source experiments shaped the future of image coding(opensource.googleblog.com) |
The obvious AI headings, pointless genned image of people (I'm starting to think islam had a point with discouraging depictions of human figures), and especially the blurry, artifacted, distractingly skeuomorphic diagram, with random wire traces going everywhere... this is a technical blog, not an investor sales pitch! Every time I see one of these, I have to double-check for a second if I'm not on some phishing SEO site!
If even Google, previously a gold standard of technical writing, is falling prey to this kind of laziness, then I have nothing to worry about -- knowing how to write without a language model in the driver's seat is gonna be a top tier skill in the future...
A damn shame too, as I've been following the progress of JXL in the standardization pipeline for a few years now and was quite interested in the historical breakdown, but all that's gonna stick with me from this is the disrespect I felt as a reader.
This article is not about the entropy codes and predictors, memory bandwidth and decision trees, but about the long horizon planning in corporate-driven OSS efforts and being connected to both community and cross-industry.
I'm generally pretty pro-AI, but I find this icky. Of course, I wouldn't have noticed except the whiteboard drawing seemed not quite right, so I'll probably be fooled in the future.
The Nano Banana team should be pissed Google PR is distributing such a terrible photo. The poses are stilted, expressions frozen, even the eye-lines are off. Why couldn't they just use a Google Pixel phone to snap a photo of real Google engineers in a real Google office and upload it to Google Photos? Not Google enough?
This project led me to propose the Taft Test:
Does your page design improve when you replace every image with William Howard Taft?
If so, then, maybe all those images aren’t adding a lot to your article. At the very least, leave Taft there! You just admitted it looks better.
Android is the only mainstream OS that does not support JPEG XL right now.
I think the images might give a slop framing which is undue
Here's a blog post by him: https://cloudinary.com/blog/2026-the-year-of-jpeg-xl
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.
It's incontrovertible that Google did attempt to kill browser adoption of jxl at one point. Thankfully they seem to have reversed course.
This last January at FOSDEM there was a panel with representatives from different browser companies. During the panel Kadir Topal, a web platform product manager at Google, indicated that because of the interest they saw in JPEG XL through the Interop Project that they changed their course on supporting it.
https://github.com/web-platform-tests/interop
The video of the panel can be found at https://fosdem.org/2026/schedule/event/7E7387-browser_in_202... . He starts speaking on the issue at about 13:00
They literally tried to kill it - stating (nonsensical) reasons why it was obsolete and unneeded.
And since now the rest of the world have adopted it despite Google, they have crawled out of their slime pits praising themselves for its development with only a passing mention of cloudinary?
Sickening.
The JPEG XL team released a draft to try to work around this but couldn't avoid it for the official standard release.
Also, it is not a competition for the shortest specification. If it was, still good. Jpeg xl spec is about half the size of the original jpeg spec.
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
It was a perfect opportunity to announced AVIF with AV2, may be taking the chance to fix issues that JXL wins AV1. But that didn't happen.
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.
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 replacing regular jpeg and heif for photography. It offers 16 bit color rather than 8 from jpeg and HDR support along with a ton of extra features.
Every OS but Android supports it, safari supports it, chrome and Firefox have it behind a beta flag.
Speaking only for webp here. It is designed to balance download and decompression time to load faster than it's competitors. Compressed filesize isn't generally smaller and compression time is notoriously slow.
https://show.quicky.club/results/14/f8/f1/d8db84d57222d32db6...
Hence the workflow with least amount of man-splaining is to stick to what the non-technical people know. Let them create everything in PNG (or JPG) with absolutely no compression whatsoever. Then have the origin server for the CDN substitute every requested image for a webp variant, mashed down to acceptable compression levels for the product/customer.
Since browsers don't care about file extensions for images, the images can be served with '.jpg' or '.png' extensions but contain webp. The browser will be fine with this because of the internal header in the image file.
Note that if the customer/user right clicks to download one of these webp images pretending to be png/jpg they should get served the PNG or JPG original, rather than the compressed webp. Yes it requires the origin server to read the headers and the CDN to read the headers too, however, this can be setup to be transparent to the people that create the images and the people that see them.
If the images are overly compressed or not compressed enough, the CDN cache can be cleared.
Note that this approach could be used to support JPEG XL right now, serving JPEG XL to browsers that support it and webp to those with lesser browsers.
What I find amusing about JPEG is that it was optimised for analogue CRTs and slow CPUs. We now have digital screens and fast(er) CPUs. The Mozilla encoder is easy to retrofit and this makes JPEG images better suited to what we have now rather than what we had in the 1980s. Things like banding goes away and the file sizes are smaller. Yet nobody adds the Mozilla libjpeg to their /bin/local.
The third option is to just not, because an image of two people standing in front of a white board has little value even when the photo isn't staged and the white board content isn't generic.
But.. that image isn't your picture, is it? It's a gen AI simulacrum. It's 2026, the uncanny valley causes visceral, immediate rejection in some subset of people. People that recoil in disgust at the sight of that.. thing pretending to be real? Since 2022, it's like our world became an eternal black mirror episode
(a more serious problem would be the prose itself being AI generated, but honestly reading it I am not sure)
Gen AI (both images and text) does not help your technical writing stand out. It doesn't help to illustrate better the points made in the article. If anything it debases your work and your own image
That is the opposite of what parent comment says. It took offence on a generated photo of you. It would have been better to not have anything than a generated image.
Photos do not, cannot, demonstrate discussions except in the most superficial and pointless way.
There are two reasons to show a photo of anything: 1) To share the experience of having been in a particular place in a particular moment of time, 2) to share what something looks like. Your image does not share an experience of having been in a particular place in a particular moment of time, because the place and time depicted are fake. Nor does it share anything about the discussion itself, because the content depicted is fake.
Is the fact that google has white boards an important part of your story? The only thing you've shown is a demonstration of what standing in front of a white board looks like. Not even a real white board. Not even real you.
If you want people to know what you look like, show an actual photo of yourself, not AI slop.
> An actual whiteboard drawing from our day to day work would be very confusing
I think you've failed to know your audience.
What did ISO give the JPEG XL team that made paywalling the standard worth it? Did ISO pay them or something?
And in turns government choose format that is protected and safest to use. ISO is ( or was ) part of that equation.
The killing of JXL did push the ever-talented Jyrki to create jpegli, which was honestly a wonder.
Jpegli is still a hidden gem. People don't yet understand how great it is.
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.
* [0] https://github.com/mozilla/standards-positions/issues/522
* [1] https://github.com/mozilla/standards-positions/pull/1064
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).
Looks like by the end of the year we can expect Chrome and Firefox support.
And to make matter worst the publish the worst comparison document and benchmarks for AVIF against JXL.