Rendered at 11:07:31 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
apt-get 2 hours ago [-]
The sloppa in this article is... offending.
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.
Mindless2112 12 hours ago [-]
> In this Gemini-reconstructed scene, ...
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.
mrandish 8 hours ago [-]
Yep, I was totally nerd-sniped by the image. I've never seen an engineer draw a whiteboard diagram anywhere near that detailed and tidy. No acronyms, consistent title case, descenders on a baseline - everything about it is wrong. It's so counter to reality, I seriously wondered if it was a joke.
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?
arghwhat 2 hours ago [-]
I have seen such detailed and tidy whiteboard diagrams, but the catch is that they never occur in active discussion. It doesn't make room for scribbling, and stopping a discussion for 5-10 minutes to draw slowly and nicely doesn't make sense...
threatripper 5 hours ago [-]
This is why we need smart glasses recording everything you see 24/7 to gather relevant real training data.
breppp 2 hours ago [-]
I think the logic follows: If we are already staging a scene just for PR purposes as was usually done then why not generate it using AI?
zerobees 12 hours ago [-]
Based on what I've heard, Google is monitoring per-org usage and strongly / incessantly encouraging teams to experiment with the technology, so a lot of tokens get spent on pointless stuff like that. The preceding diagram, which is needlessly busy and blurry, appears to be AI-generated too.
markdog12 12 hours ago [-]
Came here to say the same thing. Why add this fake image?
jazzyjackson 8 hours ago [-]
Website Obesity mentioned ! [0]
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.
Huge fan of JXL, but this article feels pretty AI sloppy. Not much said here, coming from the google blog I was hoping for some news about how they are pushing the format forward by introducing decoders in to Android and enabling on Chrome.
Android is the only mainstream OS that does not support JPEG XL right now.
UnfitFootprint 10 hours ago [-]
Not to mention those IMAGES. Slop diagrams hurt
breppp 2 hours ago [-]
I initially read the articles without images (they don't load for an unrelated reason) and actually felt it gave a good summary of JPEGXL underlying technologies and history, I also learned some new stuff.
I think the images might give a slop framing which is undue
yboris 12 hours ago [-]
Weird they don't name Jon Sneyers - a person pivotal in creation of JPEG XL
That's rich coming from the company that tried to kill it. The audacity...
gcr 11 minutes ago [-]
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
magicalist 12 hours ago [-]
> 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.
fc417fc802 5 hours ago [-]
You say that as though Google isn't notorious for killing their own successful and well received products for seemingly no reason.
It's incontrovertible that Google did attempt to kill browser adoption of jxl at one point. Thankfully they seem to have reversed course.
qingcharles 4 hours ago [-]
They only reversed under pressure from the Safari and Firefox folks.
The killing of JXL did push the ever-talented Jyrki to create jpegli, which was honestly a wonder.
PunchyHamster 2 hours ago [-]
Firefox isn't even enabling it
orbital-decay 12 hours ago [-]
From what I can tell, it's written by Gemini
11 hours ago [-]
rowbin 13 hours ago [-]
> Safari (2023) led among major browsers, while Firefox and Chrome currently maintain experimental support.
spartanatreyu 10 hours ago [-]
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.
Gigachad 10 hours ago [-]
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.
Caspy7 9 hours ago [-]
Safari is currently lacking animation and progressive decoding - still ahead of everyone else currently.
Looks like by the end of the year we can expect Chrome and Firefox support.
Gigachad 10 hours ago [-]
Maintain in a sense. Google introduced it in Chrome as an experimental flag, then removed it with no real explanation, and only just brought it back.
halapro 3 hours ago [-]
Which it makes perfect since this it's the same company which "deprecated" MP4 support a long while ago in an effort to push to WebM.
theturtle 12 hours ago [-]
[dead]
taikahessu 5 hours ago [-]
Can someone explain where are we at the image processing world/timeline? Why do coding tools suggest to me .avif and .webp, and the support of these lags in Windows OS and then we have things like JpegXL and Jpeg2000 or whatever others are there flying around? Why is it so hard to find our next "jpg format"?
Gigachad 3 hours ago [-]
AVIF and webp kind of only exist for the web, they get used when you want to really crunch down on data as much as possible. They aren’t really used for files you’d save on your computer or get out of a camera.
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.
Yokohiii 1 hours ago [-]
> AVIF and webp kind of only exist for the web, they get used when you want to really crunch down on data as much as possible.
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.
gforce_de 4 hours ago [-]
It's all about licences. If you need the images for the web: go for jpegli, webp and avif - the distance to jpegxl or webp2 is not worth the hassle:
Agree. JXL won't be baseline for at least three years.
_HMCB_ 6 hours ago [-]
Google spearheaded this and yet their browser only has experimental support? While Safari shipped it in 2023? At least, that’s how I’m reading this.
mceachen 6 hours ago [-]
It's worse: Google added and then dropped even experimental support of jxl in 2021-2022. Several years later they adopted the rust jxl library, but have kept it behind experimental flags.
lousken 12 hours ago [-]
Out of experimental when?
Gigachad 10 hours ago [-]
Probably got some time to go. The new rust decoder likely needs more time to be proven reliable and safe, and Firefox doesn't even get the flag to turn it on until the next release 152.
201984 9 hours ago [-]
Mostly off topic, but why is the spec for JPEG and JPEG XL paywalled? I wouldn't call them open standards if they're not available free-of-charge to the public.
ZeroGravitas 4 hours ago [-]
It's a standard ISO Standard thing which could perhaps be justified when standards where printed on paper.
The JPEG XL team released a draft to try to work around this but couldn't avoid it for the official standard release.
Gigachad 9 hours ago [-]
It's an open standard because the concepts and reference implementation are free and open source even if the PDF is paywalled. Realistically you could just pirate the PDF and write a jpeg xl encoder/decoder and your code wouldn't be infringing on any patents.
201984 8 hours ago [-]
Seems "closed but royalty free" would be a more accurate description then.
Gigachad 8 hours ago [-]
Splitting hairs on terminology I guess. Very few people are interested in the PDF that specifies the format vs being able to include decoders in software and on devices without paying a royalty for every device. There are alternative documents and the last draft copy which are free legally. As well as the reference code.
aidenn0 7 hours ago [-]
"Open Standard" means "Anybody is allowed to buy it"
LoganDark 9 hours ago [-]
I'm behind -- did Chrome un-remove JXL support? Google is suddenly behind it again? Why/how did they change their minds?
Caspy7 9 hours ago [-]
Yes. They're adding it back to Chrome.
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.
They added it back as an experimental flag again. Likely the new rust based decoder and adoption in to other platforms and standards changed their decision.
neuroelectron 12 hours ago [-]
AI slop article
xuzhenpeng 11 hours ago [-]
[flagged]
bnolsen 10 hours ago [-]
I personally think something like the qok format is a better way to go. Make something that performs well and is dirt simple to implement.
pezezin 4 hours ago [-]
QOI is cute as an experiment, but it is not a serious image format unless you work in extremely constrained environments.
dimatura 3 hours ago [-]
QOI supports a VERY limited set of use cases compared to jpegXL.
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.
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?
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
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
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.
The killing of JXL did push the ever-talented Jyrki to create jpegli, which was honestly a wonder.
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.
Looks like by the end of the year we can expect Chrome and Firefox support.
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...
The JPEG XL team released a draft to try to work around this but couldn't avoid it for the official standard release.
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