Notably GCP is rolling this out to their DICOM store API, so you get the space savings of JXL but can transcode on the fly for applications that need to be served JPEG.
Only know this because we have tens of PBs in their DICOM store and stand to save a substantial amount of $ on an absurdly large annual bill.
Native browser support is on our wishlist and our contacts indicate the chrome team will get there eventually.
Also OP did say "transcode on the fly" to serve JPEG, not actually storing as JPEG.
PS: I'm a bit too sleepy to search for the original discussion. Apologies for not linking it here.
It's almost certainly due to the PDF Association adding JPEG XL as a supported image format to the ISO standard for PDFs; considering Google's 180 on JPEG XL support came just a few days after the PDF Association's announcement.
That this is working out is a combination of wishful thinking and getting lucky.
That's not to say that JXL is bad or going away. It currently has poor browser support, but it's now finding its footing in niche use cases (archival, prosumer photography, medical), and will eventually become ubiquitous enough to just be what the average person refers to as "JPEG" 10 years from now.
To address selected claims made in the post:
• "AVIF is 'homegrown'" – AVIF is an open, royalty-free AOMedia standard developed by the Alliance for Open Media (Google, Microsoft, Amazon, Netflix, Mozilla, etc.).
• "AVIF is 'inferior'" – AVIF is significantly better than JPEG/WebP in compression efficiency at comparable quality, and comparable with JXL in many scenarios.
• "AVIF is ridiculous in this aspect, capping at 8,193×4,320." — JXL's theoretical maximum image size is bigger. The author cites AVIF's Baseline profile (think embedded devices), but AVIF supports 16,384×8,704 per tile. It HEIF container format supports a grid of up to 65,535 tiles (so logical images sizes up to 1,073,725,440 wide or 283,111,200 tall).
So, JPEG XL is good. Yes, it's far behind AVIF in terms of adoption and ecosystem, but that will improve. AVIF is likely to erase any current JXL quality advantages with AV2, but both JXL and AV1/AV2 encoders will get better with time, so they're likely to be neck-and-neck in quality for the foreseeable future.
JXL not only has better compression rates at equivalent qualities for sane settings, it does so with faster encoding and decoding, while also supporting progressive decoding leveraging image saliency.
AV2 might bring it closer on par with JXL in compression but to suggest they're at all equal is a joke.
This is all fine and good until you actually try encoding such an image with libjxl. What an absolute garbage codebase. I'm sure it's gotten better since I've last used it, but it's impressive how unoptimized, memory hungry, and of course wildly unsafe/crashy it was. Many of the options just completely didn't work, either due to exponential performance, crashes, or weird special-casing that breaks the moment you encode anything that's dissimilar from the sample images used in the sham benchmark made by the libjxl creators. I don't even think a high resolution image had ever been successfully encoded on higher effort levels, since I doubt that anyone trying to do so had the terabytes of RAM required.
I was genuinely flabbergasted when there was mass support for reviving it a couple years ago. I don't think anyone advocating for it has actually used libjxl at all and were just internet hypemen. That seems to happen all too often nowadays.
This all being said, I'm mildly optimistic for a retry with jxl-rs. However, seeing much of the same contributors from libjxl on jxl-rs does make me quite cautious.
This might be the origin of the "competition" in the context of this Google decision/reversal.
I think Google are aiming to replace all of Chromiums decoders with memory-safe ones anyway, even for relatively simple formats.
It's not the format, it's the C / C++ unfortunate baggage.
At this point, in 2025, any substantial (non-degenerative) image processing written in C++ is a security issue waiting to happen. That's not specific to JPEG XL.
Nonetheless, we should really bear in mind how entrenched Cpp is. If you normalize CVEs by language popularity Java looks downright dangerous!
Why this quality poses security issues?
Google's position, on the other hand, has been a flat-out "no, we will not ship JXL". That's what has been met with criticism. Not an imagined reluctance to shipping a C++ JXL implementation.
Uncompressed: 3.5–7 exabytes Realistically compressed: Tens to hundreds of petabytes
Thats a serious high-res image
I do wonder if there are any DOS vectors that need to be considered if such a large image can be defined in relatively small byte space.
I was going to work out how many A4 pages that was to print, but google's magic calculator that worked really well has been replaced by Gemini which produces this trash:
Number of A4 pages=0.0625 square meters per A4 page * 784 square miles =13,200 A4 pages.
You can already DOS with SVG images. Usually, the browser tab crashes before worse things happen. Most sites therefore do not allow SVG uploads, except GitHub for some reason.
$ units
You have: (1073741823/(600/inch))**2 / A4paper
You want:
Definition: 3.312752e+10
Lets stick to old JPEG as it's easier to explain. The DCT takes the 8x8 pixels of a block and transforms it to 8x8 magnitudes of different frequency components. In one corner you have the DC component, ie zero frequency, which represents the average of all 8x8 pixels. Around it you have the lowest non-zero frequency components. You have three of those, one which has a non-zero x frequency, one with a non-zero y frequency, and one where both x and y are non-zero. The elements next to those are the next-higher frequency components.
To reconstruct the 8x8 pixels, you run the inverse discrete cosine transformation, which is lossless (to within rounding errors).
However, due to Nyquist[3], you don't need those higher-frequency components if you want a lower-resolution image. So if you instead strip away the highest-frequency components so you're left with a 7x7 block, you can run the inverse transform on that to get a 7x7 block of pixels which perfectly represents a 7/8 = 87.5% sized version of the original 8x8 block. And you can do this for each block in the image to get a 87.5% sized image.
Now, the pyramidal scheme takes advantage of this by rearranging how the elements in each transformed block is stored. First it stores the DC components of all the blocks the image. If you just used those, you'd get an image which perfectly represents a 1/8th-sized image.
Next it stores all the lowest-frequency components for all the blocks. Using the DC and those you have effectively 2x2 blocks, and can perfectly reconstruct a quarter-sized image.
Now, if the decoder knows the target size the image will be displayed at, it can then just stop reading when it has sufficiently large blocks to reconstruct the image near the target size.
Note that most good old JPEG decoders supports this already, however since the blocks are stored one after another it still requires reading the entire file from disk. If you have a fast disk and not too large images it can often be a win regardless. But if you have huge images which are often not used in their full resolution, then the pyramidal scheme is better.
[1]: https://en.wikipedia.org/wiki/Discrete_cosine_transform
[2]: https://eyy.co/tools/artifact-generator/ (artifact intensity 80 or above)
[3]: https://en.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_sampli...
One patch at low resolution is backed by four higher-resolution images, each of which is backed by four higher-resolution images, and so on... All on top of an index to fetch the right images for your zoom level and camera position.
No projection of a sphere on a rectangle can preserve both direction and area.
Chromium Team Re-Opens JPEG XL Feature Ticket https://news.ycombinator.com/item?id=46018994
FSF Slams Google over Dropping JPEG-XL in Chrome https://news.ycombinator.com/item?id=35589179
Google set to deprecate JPEG XL support in Chrome 110 https://news.ycombinator.com/item?id=33399940
Chromium jpegxl issue closed as won't fix https://news.ycombinator.com/item?id=40407475
Main recent discussion:
Google Revisits JPEG XL in Chromium After Earlier Removal
I am using .avif since some years; all my old .jpg and .png files have been pretty much replaced by .avif, in particular fotos. I am not saying .avif is perfect, but IMO it is much better than .jpg or .avif.
I could have gone .webp or perhaps jpeg-xl but at the end of the day, I am quite happy with .avif as it is.
As for JPEG XL - I think the problem here is ... Google. Google dictates de-facto web-standards onto us. This is really bad. I don't want a commercial entity control my digital life.
going crazy reading this sentence
More specifically, if I try a bunch of AVIF quantization options and manually pick the one that appears visually lossless, it beats jpegli, but if I select a quantization option that always looks visually lossless with AVIF, jpegli will win the average size, because I need to use some headroom for images that AVIF does less well on.
As in “I’ve done it” or “I’ve seen it”
It would not be used before a noun, in the context of ownership, as in “I have a meeting”
Even just reading "I've a train to catch" gives a British accent in my mind.
Another common tell: I wake up in the morning in the US/Pacific time zone, and see the European writers on HN using "I have ran" instead of "I have run".
Fixed that for you.
As is the destiny of any document format in wide spread use, PDF had flash, doc had ActiveX.
Also this text is formatted using a mark down language fully capable of embedding entire applications.
I think both Mozilla and Google are OK with this - if it is written in Rust in order to avoid that situation.
I know the linked post mentions this but isn't that the crux of the whole thing? The standard itself is clearly an improvement over what we've had since forever.
So at least if GP was talking about libjxl "100K+" would be more accurate.
By that metric, jpeg-xl is about 4x the size of the jpeg or png codebase.
> So at least if GP was talking about libjxl "100K+" would be more accurate.
M can mean thousands and I think it's common to use it used that way in finance and finance-adjacent areas: https://www.chicagomanualofstyle.org/qanda/data/faq/topics/A...:
> A. You’ve identified two commonly used conventions in finance, one derived from Greek and the other from Latin, but neither one is standard.
Starting with the second convention, M is used for amounts in the thousands and MM for amounts in the millions (usually without a space between the number and the abbreviation—e.g., $150M for $150,000 and $150MM for $150 million). This convention overlaps with the conventions for writing roman numerals, according to which a thousand is represented by M (from mille, the Latin word for “thousand”). Any similarity with roman numerals ends there, however, because MM in roman numerals means two thousand, not a thousand thousands, or one million, as in financial contexts...
https://www.accountingcoach.com/blog/what-does-m-and-mm-stan...:
> An expense of $60,000 could be written as $60M. Internet advertisers are familiar with CPM which is the cost per thousand impressions.
> The letter k is also used represent one thousand. For example, an annual salary of $60,000 might appear as $60k instead of $60M.
"What region?"
"Er, upstate New York."
"Really. Well, I'm from Utica and I've never heard anyone use the phrase '100M' to mean '100 thousand'"
"Oh, no, not in Utica. It's an Albany expression."
100MLOC for an image format would be bananas. You could fit the entire codebases of a couple of modern operating systems, a handful of AAA videogames, and still have room for several web apps and command line utilities in 100MLOC.
the decoder is something around 30 kloc
OP might have well have said "infinite lines of code" for JPEGXL and wouldn't have been much less accurate. Although I'm guessing they meant 100k.
The C++ JPEG XL decoder is ~30'000 lines, i.e., 3000x smaller than you claim. A non-multithreaded, non-simdified code would be much simpler, around 8000 to 10000 lines of code.
It is not difficult to measure from the repository. The compiled compressed binary for an APK is 5x smaller than that of full AVIF. The complete specification at under 100 pages is ~13x more compact than that of full AVIF.
This doesn't undermine your argument at all, but we should not be compressing native libs in APKs.
https://developer.android.com/guide/topics/manifest/applicat...
Seems like Google has created a memory-safe decoder for it in Rust or something.
Maybe it was hyperbole. But if it was it wasn't obvious to me, unfortunately.
I look forward to the next generation of rubes rewriting this all in some newer ""safe"" language in three decades.
It would need to be written in the Safe Rust subset to give safety assurances. It's an important distinction.
Well tbf, the only time I ever hear about JPEG XL is when people complain about Chrome not having it. I think that might be its only actual use case.
https://petapixel.com/2024/09/18/why-apple-uses-jpeg-xl-in-t...
Imagine how long it will take for JPEG XL that didn't even reach wide browsers support yet.
Side note - comparing JPEG XL and AVIF features wise is sort of pointless if AVIF will continue to evolve based on AV2 and etc.
It turns out some users wanted to embed moving pictures in Word documents, which you can only do with a GIF because it’s an image format that happens to move, so Word treats it as an image (by rendering it to the page). If it’s a video format, Word treats it as an attachment that you have to click on so it’ll open Media Player and show you.
Are you speaking just about technical books?
Because I can’t imagine anyone trying to read a novel in epub vs pdf on a phone or epub reader and going with the latter.
As for phones, screens nowadays are almost the same size as readers and with more resolution. E-ink is more comfortable for longer sessions, but if you find such a size unusable you might just have poor eyesight.
I have read many hundreds of books this way.
The problem with a tablet is that most tablets, especially the sort that are good for seeing entire as-printed pages at once, are too big for me to keep the entire screen in focus without wearing glasses. (with that said, foldables improve things here, since the aspect ratio bottleneck is typically width so being able to double the width on the fly makes such things more readable.
For novels I want and prefer epubs, but also non-novels if they were released in the last 5 years or so. PDF isn't magic, and there are bad pdfs out there too, scans of photo-copied books and other nonsense.
Only benefit is browsers have built-in support for the format.
PDFs have pretty excellent support for metadata. If the collection software doesn't support at least Dublin Core, that may be kind of their own fault...
Encoding and decoding JPEG XL file is: #djxl input.jxl output.png.
The insanity that the web platform is just "whatever Google's whims are" remains insane and mercurial. The web platform should not be as inconsistent as Google's own product strategies, wonder if XSLT will get unkilled in a few months.
Reading over the minutes for the last W3C WG session before WHATWG was announced, the end result seems obvious. The eventual WHATWG folks were pushing for investment in web-as-an-app-platform and everyone else was focused on in retrospect very unimportant stuff.
“Hey, we need to be able to build applications.”
“Ok, but first we need compound documents.”
There was one group who thought they needed to build the web as Microsoft Word and another that wanted to create the platform on which Microsoft Word could be built.
Apparently they failed. The web version of Word is still far from having feature parity. Of course doc is one of those everything and the kitchen sink formats, so implementing it on top of a platform that was originally intended to share static documents is kind of a tall order.
Who do you suppose should be in charge of web standards? I can’t imagine the train wreck of incompetence if standards were driven by bureaucrats instead of stakeholders.
Web authors? Maybe. WHATWG was created specifically because W3C wasn’t really listening to web authors though.
I don’t think there are a lot of scenarios where standards aren’t driven by implementers, though. USB, DRAM, WiFi, all this stuff is defined by implementers.
Rather: WHATWG was founded because the companies developing browsers (in particular Google) believed that what the W3C was working on for XHTML 2.0 was too academic, and went into a different direction than their (i.e. in particular Google's) vision for the web.
Google was not involved in the founding of WHATWG, though certainly the WHATWG vision was better aligned with Google than with what the W3C was doing.
But that's not very relevant actually. The WHATWG is more like a private arbitrator, not like a court or parliament.
Their mission is to document browser features and coordinate them in such a way that implementation between browsers doesn't diverge too much. It's NOT their mission to decide which features will or will not be implemented or even to design new features. That's left to the browser vendors.
And the most powerful browser vendor is Google.
“Oh, yeah? Well they paid Hickson’s salary. And the WHATWG doesn’t matter anyway. And also Google is really powerful.”
Um, ok.
WHATWG was founded in 2004 by Mozilla, Opera, and Apple. Google had no browser at that point and didn’t hire Ian Hickson until 2005.
Google is currently a WHATWG member and clearly wields a great deal of influence there. And yeah, the 4 trillion dollar internet giant is powerful. No argument there.
Mozilla, Opera and Apple. Google didn't have a browser then, hadn't even made the main hires who would start developing Chrome yet and hixie was still at Opera.
Users are a key information source but they don't know how to build a web engine, they don't know networks, and they don't know security; and therefore can't dictate the feature set.
Honestly, what's really funny here is how absolutely horrified people are by the suggestion a single company which has a monopoly shouldn't also define the web platform. I really think anyone who has any sort of confusion about what I commented here to take a long, hard look at their worldview.
Is your proposal essentially that Mozilla defines web standards Google is legally bound to implement them?
> what's really funny here is how absolutely horrified people are by the suggestion
Not horrified, but asking what the alternative is. I don’t think you’ve actually got a sensible proposal.
Cooperation in the WHATWG is voluntary. Even if there were some workable proposal for how to drive web standards without Google having any decision making power, they could (and presumably would) decline to participate in any structure that mandated what they have to build in Chrome. Absent legal force, no one can make Google cede their investment in web standards.
Requiring Google implement the standards as agreed by Apple, Mozilla, and Microsoft is not remotely outside the realm of the legal force that could be applied.
I feel like Mozilla would end up being a Google proxy in this case as they fear losing their funding and Apple and Microsoft would be incentivized to abuse their position to force Google not to do the best thing for the public but the best thing for Apple and Microsoft.
I would again agree Microsoft and Apple will heavily endorse their own interests, Microsoft much more so in terms of enterprise requirements and Apple much more so in terms of privacy-concerned consumers. The advertising firm influence will be significantly dimished and that is a darn shame.
They don't. In general browser specs are defined via various standards groups like WHATWG. As far as I know there is no standard for what image formats must be supported on a web browser,[0] which is why in this one case any browser can decide to support an image format or not.
[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
If only there was a way to detect which features a browser supports. Something maybe in the html, the css, javascript or the user agent. If only there was a way to do that, we would not be stuck in a world pretending that everything runs on IE6. /s
Okay, and do they align on every other web standard too?
SquareWheel implied that Mozilla doesn't count as an "other party" because they are aligned with Google on this specific topic.
My comment was pointing out that just because they are aligned on this doesn't mean they are aligned on everything, so Mozilla is an "other party".
And, as you have reinforced, Google and Mozilla are not always in alignment.
If Mozilla wanted Firefox to succeed, they would stop playing "copy Chrome" and support all sorts of things that the community wants, like JpegXL, XSLT, RSS/Atom, Gemini (protocol, not AI), ActivityPub, etc.
Not to mention a built-in ad-blocker...
No significant number of users chooses their browser based on support for image codecs. Especially not when no relevant website will ever use them until Safari and Chrome support them.
And websites which already do not bother supporting Firefox very much will bother even less if said browser by-default refuses to allow them to make revenue. They may in fact go even further and put more effort into trying to block said users unless they use a different browser.
Despite whatever HN thinks, Firefox lost marketshare on the basis of:
A) heavy marketing campaigns by Google including backdoor auto-installations via. crapware installers like free antivirus, Java and Adobe, and targeted popups on the largest websites on the planet (which are primarily google properties). The Chrome marketing budget alone nearly surpasses Mozilla's entire budget and that's not even accounting for the value of the aforementioned self-advertising.
B) being a slower, heavier browser at the time, largely because the extension model that HN loved so much and fought the removal of was an architectural anchor, and beyond that, XUL/XPCOM extensions were frequently the cause of the most egregious examples of bad performance, bloat and brokenness in the first place.
C) being "what their cellphone uses" and Google being otherwise synonymous with the internet, like IE was in the late 1990s and early 2000s. Their competitors (Apple, Microsoft, Google) all own their own OS platforms and can squeeze alternative browsers out by merely being good enough or integrated enough not to switch for the average person.
One possible way is doing things that Google and Chrome don't (can't).
Catering to niche audiences (and winning those niches) gives people a reason to use it. Maybe one of the niches takes off. Catering to advanced users not necessarily a bad way to compete.
Being a feature-for-feature copy of Chrome is not a winning strategy (IMHO).
Good thing they aren't? Firefox's detached video player feature is far superior to anything Chrome has that I'm aware of. Likewise for container tabs, Manifest V2 and anti-fingerprinting mode. And there are AI integrations that do make sense, like local-only AI translation & summaries, which could be a "niche feature" that people care about. But people complain about that stuff too.
But I'm agreeing with you! These features are important to you, an advanced user. The more advanced users for Firefox, the better.
What “community” is this? The typical consumer has no idea what any of this is.
If one of these advanced/niche technologies takes off, suddenly they will have a reason to use Firefox.
IE lost the lead to Firefox when IE basically just stopped development and stagnated. Firefox lost to Chrome when Firefox became too bloated and slow. Firefox simply will not win back that market until either Chrome screws up majorly or Firefox delivers some significant value that Google cannot immediately copy.
In a very real sense Google is currently stopping web authors from using JPEG XL.
Yeah, that’s what I said.
If the user agent does not support JPEG XL, then you cannot use it.
“Nobody is stopping you from using jpegxl” except Google.
From the jump, the article commits a logical error, suggesting that Google killed jpegxl because it favors avif, which is "homegrown". jpegxl, of course, was also written by Google, so this sentence isn't even internally consistent.
As for JPEG XL, of course they unkilled it. WEBP has been deprecated in favor of JPEG XL.
Can you point to somewhere that Google or anyone else indicated that they would support xslt once there’s a secure, supported version?
Who said this? I was never able to find any support among the browser devs for "keep XSLT with some more secure non-libxslt implementation".
Similarly, AVIF uses little more code than the AV1 keyframe decoder, so since every browser supports AV1, every browser also supports AVIF.
Otherwise, I love webp and use it for all my comics/manga.
For photographs, jpeg has really been optimized without reducing compatibility, and also in another less compatible way (incompatible viewers can display it without erroring out, but the colors are wrong) and there's such an encoder in the JPEG XL repo.