alt.hn

6/3/2026 at 9:55:23 PM

Journey to JPEG XL: open-source experiments shaped the future of image coding

 https://opensource.googleblog.com/2026/06/journey-to-jpeg-xl-how-open-source-experiments-shaped-the-future-of-image-coding.html

by ledoge

6/4/2026 at 8:48:08 AM

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.

by apt-get

6/4/2026 at 1:37:28 PM

I spent 10+ years in building JPEG XL and I'm proud of the result. It wasn't always easy times. It is not so bad people can see what I look like and take a peek what the process was to get there.

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.

by JyrkiAlakuijala

6/4/2026 at 2:38:23 PM

That doesn't sound like a denial to me. Your years working on JPEGXL are extremely admirable, and you deserve to be recognized for it, but the gratuitous use of genAI in this post is also insulting to humans. The world isn't improved by a fabricated photo of a fake setting with an actor looks like you but isn't standing in front of a white board that says basically nothing.

by BugsJustFindMe

6/4/2026 at 4:26:50 PM

I made that AI rendering and consider it demonstrates the conceptual discussions we had likely better than what an actual whiteboard drawing would look like. An actual whiteboard drawing from our day to day work would be very confusing without a lot of context and discussion. I have to admit that whiteboard drawings were somewhat rare in our real JPEG XL development, but it has been an intensively collaborative effort.

by JyrkiAlakuijala

6/4/2026 at 5:20:34 PM

> consider it demonstrates the conceptual discussions

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.

by BugsJustFindMe

6/4/2026 at 2:44:16 PM

And you addressed your parent comment... how exactly?

by pdimitar

6/4/2026 at 4:09:16 PM

Parent comment says I should not be known and my picture should not be on the blog post. I just want to disagree with that. In my opinion JPEG XL is a notable success and it is also ok to celebrate us, its makers.

by JyrkiAlakuijala

6/5/2026 at 8:54:04 PM

> I should not be known and my picture should not be on the blog post

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.

by smusamashah

6/5/2026 at 5:22:10 AM

Your technical achievements will help make the web a better platform (here hoping that browsers in general adopt JPEG XL sooner rather than latter). I've not seen anyone in the thread asking for you to not be credited for your work, or that you should not be known in general. Also, attaching your picture and some biographical info in that article is cool and expected, no problem there.

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

by nextaccountic

6/4/2026 at 4:11:09 PM

I think everyone on HN would easily agree with this. They take issue with the how i.e. AI-assisted images (and maybe text).

by pdimitar

6/4/2026 at 5:23:11 PM

That is not what the parent comment says at all. The parent comment says that an actual photo of yourself doing literally anything at all would have been better and less insulting to your readers than AI slop.

by BugsJustFindMe

6/3/2026 at 11:16:00 PM

> 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.

by Mindless2112

6/4/2026 at 3:10:04 AM

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?

by mrandish

6/4/2026 at 8:59:13 AM

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...

by arghwhat

6/4/2026 at 1:40:45 PM

True, no one can understand my whiteboard drawings the next day, not even I.

by JyrkiAlakuijala

6/4/2026 at 5:33:13 PM

Perfect operational security!

by mrandish

6/4/2026 at 8:37:37 AM

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?

by breppp

6/4/2026 at 5:42:13 PM

I actually didn't full-stop on it because I thought it was AI. For the first few seconds I thought it was a staged photo. I was nerd-sniped because it was staged so badly.

by mrandish

6/4/2026 at 5:43:13 AM

This is why we need smart glasses recording everything you see 24/7 to gather relevant real training data.

by threatripper

6/3/2026 at 11:24:36 PM

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.

by zerobees

6/4/2026 at 1:45:29 PM

This was not a factor. It was either staging the photograph or AI. Photographing inside the office can be a complex process with seeking appropriate permissions, and I didn't have an alternative space to do the photography. AI felt like an easier solution.

by JyrkiAlakuijala

6/4/2026 at 2:57:24 PM

> It was either staging the photograph or AI.

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.

by BugsJustFindMe

6/4/2026 at 1:39:34 PM

This discussion happened in a chat window in reality, but is based on a real discussion between me and Luca, leading to reversing the order of "ac strategy" from splitting to joining.

by JyrkiAlakuijala

6/4/2026 at 5:34:32 PM

My favorite part of the drawing is where it talks about Variable Black Sizes.

by BugsJustFindMe

6/3/2026 at 11:34:01 PM

Came here to say the same thing. Why add this fake image?

by markdog12

6/4/2026 at 3:24:56 AM

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.
[0] (idlewords.com/talks/website_obesity): https://web.archive.org/web/20260421022440/https://idlewords...

by jazzyjackson

6/4/2026 at 1:48:35 PM

Two reasons: The people in the pic look more or less like our real ourselves. The synthesized photo shows the process of discussing highly conceptual approaches, which was our everyday for 10 years or so.

by JyrkiAlakuijala

6/4/2026 at 12:42:39 AM

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.

by Gigachad

6/4/2026 at 8:46:28 AM

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

by breppp

6/4/2026 at 1:28:37 AM

Not to mention those IMAGES. Slop diagrams hurt

by UnfitFootprint

6/3/2026 at 11:34:24 PM

Weird they don't name Jon Sneyers - a person pivotal in creation of JPEG XL

Here's a blog post by him: https://cloudinary.com/blog/2026-the-year-of-jpeg-xl

by yboris

6/4/2026 at 1:53:38 PM

No, it is normal. Similarly Jon's blog post does not name any of us by name.

by JyrkiAlakuijala

6/3/2026 at 9:59:58 PM

That's rich coming from the company that tried to kill it. The audacity...

by rowbin

6/3/2026 at 11:06:26 PM

> 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.

by magicalist

6/4/2026 at 6:10:48 AM

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.

by fc417fc802

6/4/2026 at 7:13:39 AM

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.

by qingcharles

6/4/2026 at 2:00:19 PM

Thank you.

Jpegli is still a hidden gem. People don't yet understand how great it is.

by JyrkiAlakuijala

6/4/2026 at 1:14:34 PM

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.

* [0] https://github.com/mozilla/standards-positions/issues/522

* [1] https://github.com/mozilla/standards-positions/pull/1064

by cyberrock

6/4/2026 at 8:20:34 PM

> 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).

by fc417fc802

6/4/2026 at 9:30:48 AM

Firefox isn't even enabling it

by PunchyHamster

6/4/2026 at 12:51:35 PM

They are working on it. It is in Firefox Nightly behind a flag.

by Tagbert

6/3/2026 at 11:19:23 PM

From what I can tell, it's written by Gemini

by orbital-decay

6/4/2026 at 10:56:56 AM

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

by gcr

6/4/2026 at 2:42:45 PM

I think it is quite the opposite. There were some support of JXL but leadership of Google, Android and Chrome all wanted AVIF.

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.

by ksec

6/3/2026 at 10:02:03 PM

> Safari (2023) led among major browsers, while Firefox and Chrome currently maintain experimental support.

by rowbin

6/4/2026 at 12:47:02 AM

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.

by spartanatreyu

6/4/2026 at 1:01:36 AM

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.

by Gigachad

6/4/2026 at 1:50:03 AM

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.

by Caspy7

6/4/2026 at 2:47:48 PM

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.

by ksec

6/4/2026 at 12:45:52 AM

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.

by Gigachad

6/4/2026 at 7:51:39 AM

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.

by halapro

6/4/2026 at 2:49:12 PM

Thank You I have nearly forgotten about that. At one point I was worried they might even remove AAC-LC support.

by ksec

6/4/2026 at 1:59:15 PM

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.

by JyrkiAlakuijala

6/3/2026 at 11:02:14 PM

[dead]

by theturtle

6/4/2026 at 1:47:36 AM

I'm behind -- did Chrome un-remove JXL support? Google is suddenly behind it again? Why/how did they change their minds?

by LoganDark

6/4/2026 at 1:58:49 AM

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.

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

by Caspy7

6/4/2026 at 3:04:39 PM

That is a very cherishable way to put it. In realty JXL has been on one of the highest request in Interop for at least 2 if not 3 years, and both Microsoft Edge and Safari have spoken about frustration of "certain features" not being implemented despite high number of votes.

by ksec

6/4/2026 at 1:58:37 AM

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.

by Gigachad

6/4/2026 at 6:14:20 AM

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"?

by taikahessu

6/4/2026 at 7:47:03 AM

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.

by Gigachad

6/4/2026 at 9:39:54 AM

> 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.

by Yokohiii

6/4/2026 at 6:55:09 AM

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:

https://show.quicky.club/results/14/f8/f1/d8db84d57222d32db6...

by gforce_de

6/4/2026 at 7:14:52 AM

Agree. JXL won't be baseline for at least three years.

by qingcharles

6/4/2026 at 11:34:43 AM

Part of the problem is that images are used by everybody, including the non-technical people. It is usually the non-technical people that make the images, so we can't confuse them with file formats.

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.

by Theodores

6/4/2026 at 11:23:52 AM

Conveniently forgetting how they removed the jpeg-xl support from the chrome codebase despite overwhelming developer backlash that they then proceeded to ignore for over a year.

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.

by supermatt

6/4/2026 at 4:41:03 AM

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.

by _HMCB_

6/4/2026 at 4:57:40 AM

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.

by mceachen

6/3/2026 at 11:03:14 PM

Out of experimental when?

by lousken

6/4/2026 at 12:40:59 AM

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.

by Gigachad

6/4/2026 at 2:12:03 AM

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.

by 201984

6/4/2026 at 6:42:08 AM

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.

by ZeroGravitas

6/4/2026 at 2:29:09 PM

Does anyone know why the JPEG XL team went through ISO instead of publishing it themselves?

by 201984

6/4/2026 at 3:07:39 PM

Because it is an international standard accepted by government and many other parties.

by ksec

6/4/2026 at 9:26:49 PM

I just don't get why an image format needs the ceremony from being an international standard accepted by governments. It's just an image format; governments shouldn't be involved in this at all.

What did ISO give the JPEG XL team that made paywalling the standard worth it? Did ISO pay them or something?

by 201984

6/6/2026 at 3:34:28 PM

I think you got it the other way around. It is JPEG XL has to pay for it to be published by ISO and certified. And the document will be edited and audited in part.

And in turns government choose format that is protected and safest to use. ISO is ( or was ) part of that equation.

by ksec

6/4/2026 at 2:26:11 AM

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.

by Gigachad

6/4/2026 at 3:06:41 AM

Seems "closed but royalty free" would be a more accurate description then.

by 201984

6/4/2026 at 3:21:57 AM

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.

by Gigachad

6/4/2026 at 3:13:51 PM

Before the world of internet, Open does not always mean free. They are two different concept. A proprietary codec isn't open, and you can't use it everywhere unless the owner allows you to or provided tools and support. Microsoft with their WMV and Realmedia with RVMB for example. H.263 and H.264 was called an open standard at the time, any body can buy and implement it.

by ksec

6/4/2026 at 4:01:46 AM

"Open Standard" means "Anybody is allowed to buy it"

by aidenn0

6/3/2026 at 11:16:06 PM

AI slop article

by neuroelectron

6/4/2026 at 2:04:51 PM

I wrote it, with some help from Gemini as my own English is clumsy and expensive to correct manually, and created the "photo" and the "chart". I am to blame. I thought the story of a 10+ year running OSS project with intermediate milestones would be fascinating for people.

by JyrkiAlakuijala

6/3/2026 at 11:51:52 PM

[flagged]

by xuzhenpeng

6/4/2026 at 1:34:39 AM

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.

by bnolsen

6/4/2026 at 2:07:38 PM

No it would not, qoi falls behind even my 2011 WebP lossless design.

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.

by JyrkiAlakuijala

6/4/2026 at 7:48:32 AM

QOI supports a VERY limited set of use cases compared to jpegXL.

by dimatura

6/4/2026 at 7:32:56 AM

QOI is cute as an experiment, but it is not a serious image format unless you work in extremely constrained environments.

by pezezin