With both Firefox and Chromium using jxl-rs (Rust-based), I wonder what Apple will do about the libjxl (C++) they already shipped. I know they're doing some memory-safety with Swift, but are they shipping any Rust in their platforms so far? I also wonder if anyone's done benchmark comparisons between both libs.
--
Also, I was under the impression that after backtracking, Chromium was relying on Mozilla to come up with a Rust port, but it seems it was the reverse. Good on Google Research.
> So, we laid down a challenge to the JPEG XL team at Google Research: Build a safe, performant, compact, and compatible JPEG XL decoder in Rust, and we’ll ship it. That challenge was met; Google Research built jxl-rs, and it’s the core of our JPEG XL support in Firefox.
Snafuh 1 days ago [-]
Luca Versari, one of the devs between both libraries, has a performance dashboard to compare performance between the two
https://jxl-rs-perf.lucaversari.it/
jxl-rs started to outperform the C++ library 2 months ago.
phire 1 days ago [-]
As much as I enjoy rust, there is no reason why a c++ library can’t be optimised to match the rust implementation.
It’s very rare that the actual performance benefits of rust implementations come from rust itself (though it does often push you to slightly better patterns). They usually come from the fact that rust implementations are usually a second (or 3rd, or 4th) iteration of the design, and the lessons learned help performance.
The other benefit of rust is that the stronger type system makes it easier to iterate and optimise without bugs creeping in. But once optimisations are implemented in rust, there isn’t that much pain to porting them back to c++, as long as someone cares enough to do so.
magicalist 1 days ago [-]
> As much as I enjoy rust, there is no reason why a c++ library can’t be optimised to match the rust implementation.
I don't think anyone is claiming that. I took the GP's point as what was desired was a "safe, performant, compact, and compatible JPEG XL decoder in Rust" and "performant" (as defined as the speed of the c++ version) was passed two months ago.
> They usually come from the fact that rust implementations are usually a second (or 3rd, or 4th) iteration of the design, and the lessons learned help performance.
Sure, and looking at the recent commit histories, the team is focusing on getting the rust version ready for this milestone for obvious reasons, and is less concerned about immediate parity in the c++ codebase.
jpgvm 1 days ago [-]
Usually what happens is you make the choice to do a Rust port or rewrite, you maintain the C++ for a while and then eventually the Rust port matches it on perf then the will to maintain the C++ version falls off a cliff.
Seeing this at $DAY_JOB already. I suspect soon at $DAY_JOB the only 2 low level languages approved for greenfield will be Rust and Ada/SPARK.
bawolff 1 days ago [-]
>As much as I enjoy rust, there is no reason why a c++ library can’t be optimised to match the rust implementation
but why would you bother? The rust library is the one that is being chosen to use. There is no point optimizing a library which is not going to be used.
bastawhiz 1 days ago [-]
> The other benefit of rust is that the stronger type system makes it easier to iterate and optimise without bugs creeping in. But once optimisations are implemented in rust, there isn’t that much pain to porting them back to c++
The obvious reason not to do this is that you lose the safety properties of it being written in Rust. What assurance do you have that there's not a memory error in the C++ version? It's similar but not purely a mechanical translation. Yes, you can port it back to C++, you can also port it to C or assembly or anything else you want. But why would you, especially for something like a codec?
pibaker 1 days ago [-]
I suspect the real reason is safety. Rust isn't bulletproof but it's certainly much better than C++ when it comes to defending against memory corruption related attacks. And when you are building a decoder for untrusted data sent over the internet, this kind of thing matters a lot more.
Lvl999Noob 21 hours ago [-]
For safety in decoding, isn't there WUFFS, also by Google, that's guaranteed safe and fast?
No one was saying this was some indictment of c++. I agree with you that with any of these low-level, manual memory, compiled languages (c, c++, rust, zig, etc) the achievable performance is basically identical. But it's relevant to note that one implementation has surpassed another.
hn92726819 1 days ago [-]
I don't understand why anyone would continue working on the c++ project once the rust one started beating it in performance
Snafuh 1 days ago [-]
jxl-rs (rust) is just a decoder while libjxl (C++) can also encode.
There is a rust encoder in active developing by someone outside the core JPEG XL devs.
BoingBoomTschak 23 hours ago [-]
To catch conformance issues by comparing two implementations. Perhaps to support obscure platforms only available through gcc.
rfgplk 1 days ago [-]
If he is one of the devs between both libraries, why is there a performance gap? Why not port the optimizations from one lib to the other? You can even create a pinned agent workflow that automatically translates optimizations between repos. Fairly trivial to implement actually.
AlotOfReading 1 days ago [-]
Just because you can theoretically write equivalent code in both languages doesn't mean two idiomatic implementations in each language will be 1:1 with each other. I haven't looked at the code in question, but some examples of common differences:
A C++ program might do template metaprogramming at compile time and the same thing at runtime in Rust, or vice versa. The C++ version might use virtual functions that rust wouldn't use. The Rust version might simply give more optimization information to the backend. The C++ version might use fairly awful parts of the stdlib like iostreams or shared_ptr that rust simply implements better. Etc.
Or maybe they're just focused on the rust implementation as they should be.
josephg 1 days ago [-]
Yep. Also:
The rust borrow checker makes it difficult to implement tree like structures with pointers like you would in C or C++. Safe rust trees are (imo) best written using vecs.
Rust makes function arguments noalias.
Rust adds runtime array bound checks.
Rust and C++ do iteration quite differently. Rust encourages map/filter/reduce. I suspect this results in different assembly.
Doing a “unity build” in rust is really easy (codegen-units=1). In C++, you need to make heavy modifications to your build system and sometimes your source too.
But with some time you could probably port the optimisations across. If anyone has some spare tokens, Claude can be quite good at doing this sort of work. Show it both repositories and tell it to make the C++ code just as fast as rust.
NewJazz 1 days ago [-]
Because developers of security critical code don't flippantly merge LLM changes for marginal performance gain, and their time is incredibly valuable.
saagarjha 1 days ago [-]
Shipping unsafe C++ is easier on Apple platforms than Rust. This seems unlikely to change anytime soon.
josephg 1 days ago [-]
Is it? I wrote a pure rust iOS app recently. It uses native controls, and looks and feels great. iOS and iOS-sim are both very well supported targets by the rust compiler.
saagarjha 1 days ago [-]
You’re not shipping code as part of Safari
josephg 1 days ago [-]
You're moving the goalposts. You said:
> Shipping unsafe C++ is easier on Apple platforms than Rust.
... Which seems false.
I can easily believe that apple might not have rust tooling in their Safari build system. But that doesn't mean rust has poor support for apple platforms.
saagarjha 19 hours ago [-]
No, you're reading what you want out of my comment. The context of this thread was very clearly browser support of JPEG XL, not your apps.
josephg 19 hours ago [-]
Chrome and Firefox are shipping lots of rust code today. They work great on Apple platforms. They’re even both planning to use rust for JPEG XL.
What is your claim, exactly? Because as far as I can tell, there’s nothing stopping safari from using rust if they wanted to.
saagarjha 18 hours ago [-]
My claim is that there is quite a bit stopping Safari from using Rust ;)
dlahoda 1 days ago [-]
I do not feel so.
Not only Rust does C API, but Objective-C the way it allows to call Apple platform and call Apple compatible functions back.
Also well integrated Rust programs(with platform calls and low level hardware access) are well compiled without Apple SDK.
3-4 kicking Rust solutions are easy findable in this area.
saagarjha 1 days ago [-]
Just because it is possible or even easy does not mean it will happen.
deadbunny 1 days ago [-]
Apple is gonna do what apple wants.
llm_nerd 1 days ago [-]
What a funny tangent to go off on.
JXL was dead. Apple is who brought it back to life[1], and the only reason Chrome resurrected JXL, and now Firefox followed their path, is because Apple pushed JXL support to a billion plus devices.
I know people like complaining about Apple, but there's a "read the room" kind of moment where people just seem to either not know the context or are just knee jerking.
[1] Worth noting that Apple used the reference implementation, libjxl, and that project still remains the reference implementation with the Rust port being experimental (and of course Apple deployed JXL support over a year before the Rust port even existed). Maybe they'll switch to it at some point, but it's a bit premature to complain about.
ChoosesBarbecue 1 days ago [-]
I believe Firefox was the first to put out a standards position about adopting jxl if a Rust implementation happened. Chromium only aligned their position this year I believe, prior to that, it was a complete rejection.
Which is to say, Chrome followed Firefox here.
(Yes, I know Google Research implemented jxl-rs, but then, they also implemented jxl. Chrome’s position appears independent of them.)
spartanatreyu 1 days ago [-]
> JXL was dead. Apple is who brought it back to life
No, it was actually the PDF Association.
They added JXL to the PDF standard.
If google wanted to maintain support for displaying PDFs, they would need to add support for JXL.
alwillis 1 days ago [-]
>> JXL was dead. Apple is who brought it back to life
> No, it was actually the PDF Association.
The PDF Association didn't adopt JPEG-XL until September 2025. By then, Apple had been shipping JPEG-XL in Safari for two years [1]. So there's that.
The PDF consortium added JXL to the PDF spec two years after Apple deployed support to billions of devices. To anyone ackchyually paying attention to the JXL spec, lamenting that this superior format wallowed in obscurity (largely, it should be noted, because Google dumped it, and so many others just follow the leader of Google), Apple actually completely changed the path of the format's adoption.
cbolton 21 hours ago [-]
To summarize the timeline:
2015-2021: Google and Cloudinary develop the technical foundations, work on standardization with the JPEG group and write the reference implementation
2021: Chrome and Firefox introduce experimental support
2022: The Chrome team decides to remove the experimental support, citing lack of interest in the ecosystem
2023: Apple surprises by shipping support in all their products
2024: Firefox says they don't want the attack surface of 100K lines of multithreaded C++ but they will ship support if Google implements a Rust version
September 2025: Google delivers jxl-rs v0.1.0 (a Rust implementation)
October 2025: The PDF Association announces they want to include the format in PDF, citing the need for HDR support in particular
November 2025: The Chrome team reverses its position, citing Safari support, Firefox's new stance, Interop proposals and the PDF announcement.
So while Google played the largest part by far in making JPEG-XL a thing, Apple probably played an outsize role in getting it adopted so fast. But its long-term fate? Who knows... The PDF Association might well have adopted JPEG-XL without Apple: they cited HDR support, wide-gamut, ultra-high resolution and channel number, not "works on iOS". And having it as the format for HDR in PDF would have forced Chrome's hand no matter what Apple did.
(Small heads up: the "anyone with a clue agrees with me" framing is more grating than useful.)
NewJazz 1 days ago [-]
* wanted to maintain support for displaying jxl images that are embedded in PDFs
cyberrock 16 hours ago [-]
Safari using the reference implementation is meaningless because they don't even seem to turn on all features in it. Mozilla and Chromium declared that progressive decoding was the main blocker, the authors added it to libjxl-rs earlier this year, then now they're shipping it. Safari hasn't enabled progressive decoding or animation even though it's been in libjxl since 2022. If I wasn't in the trenches of Cordova/React development a decade ago, I would say I'm baffled.
deadbunny 1 days ago [-]
[flagged]
concinds 1 days ago [-]
I don't see what this has to do with the topic, sorry.
wongarsu 1 days ago [-]
Their point is that Apple is the Nintendo of computing. They don't care what others do, they just do their own thing. Which produces some great things and some stupid things. They also don't care whether you think what they are doing is great or stupid, they just continue doing their thing
Which then tracks back to the beginning of the thread: the correct answer to whether apple will adopt jxl-rs or keep libjxl is "who knows, no point trying to predict them". Which is not a value judgement
How you square all of that with the iPhone regularly copying features Android had for years is your decision. Might be a symptom of the same, might be that this all was an entirely inaccurate description of Apple
_joel 1 days ago [-]
That useless strip could play lemmings and doom, it wasn't all bad
tombert 1 days ago [-]
> make a mouse you can't use while charging it
I'm not one to usually defend Apple-ism, but it always felt that this was such a nothing-burger. The mouse charges in like fifteen minutes and lasts for weeks. I don't have a work Macbook (or job :) ) right now, but when I did I would just occasionally plug it in while I went to the bathroom. It really was not nearly as annoying as everyone said it was.
spartanatreyu 1 days ago [-]
Remember all those times you needed to make a change to something a few minutes before it was submitted/presented?
Imagine if you couldn't, because you needed to charge your mouse first.
cute_boi 1 days ago [-]
[flagged]
arkon_hn 1 days ago [-]
Not to mention how updates are tied to OS updates...
dlahoda 1 days ago [-]
What Updates tied? App Store updates use same networking and storage as OS? Why it is bad?
flyingjoe 18 hours ago [-]
because updating a single app via the app store is faster than updating the whole OS. Having a security vulnerability in a browser could be fixed immediately, but having to ship out a whole new OS leaves it open for a while.
Especially with users generally being against/too lazy to do OS updates
arkon_hn 14 hours ago [-]
Exactly this. We so often see people still using iOS versions from ~4 years ago despite having options to update. Apple holds the ecosystem back.
kekdkrjfjjwfj 14 hours ago [-]
Except that they can and have pushed security updates that are not necessarily OS updates. Granted the process is still through the settings app, but the point still stands. They have a channel for pushing yellow and red alert updates. Anything else can easily wait a couple of months.
1 days ago [-]
Unai 21 hours ago [-]
A non-evergreen browser in 2026 should be publicly ridiculed any time its name is brought up.
account42 17 hours ago [-]
Web developers who think you need the latest and greatest features to build a hypertext document are the ones who should be ridiculed.
Unai 13 hours ago [-]
Thankfully, people with ridiculous opinions ridicule themselves. Like pretending the web is just documents, as if we were living three decades ago. Or pretending that "latest and greatest features" is the only reason to keep a browser updated. Or pretending that new features are somehow bad or not useful. Or defending poor Apple for wanting people to spend a grand on new hardware to update be able to update their browser.
tengwar2 1 days ago [-]
Hasn't been the case for some time.
spartanatreyu 1 days ago [-]
Not true.
MacOS releases a new version each year, the current MacOS landscape looks like:
- MacOS Sequoia (previous version, everything works as expected)
- MacOS Golden Gate (next version, fixes what was broken in Tahoe, comes out in a month)
I'm on MacOS Sequoia because I have things that can't be broken by updating to Tahoe.
I also cannot test how my websites/webapps will work in a month, because Safari's beta (called Safari Technology Preview) only works on Tahoe and Golden Gate.
I cannot wait a month to update to Golden Gate because Golden Gate drops support for my iMac.
And I can't test the new version of Safari on my Windows or Linux devices because Safari isn't available for them.
I can test the Webkit browser, but that doesn't include the Safari specific changes that apple makes which I need to be able to test.
---
So, I can't test Safari until I wait a month and purchase a new apple machine.
(Oh by the way, apple keeps cancelling orders for new machines)
alwillis 1 days ago [-]
> And I can't test the new version of Safari on my Windows or Linux devices because Safari isn't available for them.
You can download three Linux-compatible WebKit-based browsers from Apple's WebKit page:
There are subtle differences. From the top of my head, differences with osx include the font rendering and the tab order (which is broken for everything except form elements).
alwillis 14 hours ago [-]
I get it; when Safari was available for Windows, the font rendering was different from the Mac version.
dlahoda 1 days ago [-]
My wife, son and me not using Safari. Do not see how Safari relates to App Store.
We use App Store.
SR2Z 1 days ago [-]
The point of a PWA is that instead of downloading an actual binary app, you essentially get a webpage that runs like it was an app. They can be installed from anywhere and are safe by nature because they're really just webpages.
That was the original conception of iPhone apps, until Steve Jobs realized just how much money could be made from the app store. Now you get to pay Apple a 30% cut for the privilege of installing software on your own device!
kekdkrjfjjwfj 14 hours ago [-]
> Now you get to pay Apple a 30% cut for the privilege of installing software on your own device!
Kneejerk reactions everywhere! Wow. And to think HN commenters like to think themselves superior to other reddit/instagram/linkedin/social media users.
nchmy 1 days ago [-]
[flagged]
chuckadams 1 days ago [-]
Maybe because they don't want to see this thread dragged down into an open-ended gripe-fest against Apple, especially when it's concerning a feature Apple did ship before everyone else.
Nition 1 days ago [-]
I had assumed that JPEG XL was for JPEGs that are Xtra Large, since that's what XL means on clothing and pretty much everywhere else. But apparently not:
> 'The etymology of the name "XL" is as follows: JPEG has called all its new standards since j2k something that starts with an X: XR, XT, XS (S for speed, since it is very fast and ultra-low-latency), and now XL. The L is supposed to mean Long term, since the goal is to make something that can replace the legacy JPEG and last as long as it did.'[1]
You can refer to JPEG XL as its file extension `jxl` pronounced "jixel" ;)
kekdkrjfjjwfj 14 hours ago [-]
PNG is actually pronounced “ping” yet not a living soul goes that route.
Oh, and just so we don’t lose track of the one pronunciation that actually matters: it’s “JIF” not “GIF”.
TacticalCoder 20 hours ago [-]
> I had assumed that JPEG XL was for JPEGs that are Xtra Large, since that's what XL means on clothing and pretty much everywhere else.
Yup the name isn't the best pick indeed.
What most people don't know is that JPEG XL can be used to crush JPEG files by 15% to 25% without any single quality loss. And the resulting .jxl file can be used to then reproduce the original .jpg file bit-for-bit.
People can test this at the CLI for themselves.
cubefox 19 hours ago [-]
JPEG XL is also "extra large" in the sense that it covers many features of more specialized image formats. They tried to come up with a pretty universal solution.
> It supports wide colour gamut as well as high dynamic range and high bit depth images. JPEG XL further includes features such as animation, alpha channels, layers, thumbnails, lossless and progressive coding (...)
This is awesome! All it took was a Rust implementation I guess?
throw0101a 1 days ago [-]
> All it took was a Rust implementation I guess?
And Apple including support in their default graphics library so every iOS (and Mac) supported it. (I use Firefox, but let's not pretend like they'd move the market on JXL support.)
I'm curious how many HN people in 2026 have not yet heard of JPEG XL / jxl
etatoby 1 days ago [-]
I have only heard of it in passing. I wonder what it adds beyond Webp and Avif.
Macha 1 days ago [-]
The big feature over other new formats is compatibility with legacy JPEGs. You can (simplified) take the raw data from a legacy JPEG, reformat it as a JPEG XL, and achieve like 20-30% filesize savings without any actual re-encode, just better packaging of the same data. While converting them to AVIF or webp is a lossy re-encode, and so loses quality. I think it's really this feature that has people wanting it still despite the support for AVIF.
Also webp is IMO subjectively worse at the same file sizes than the other two. Dunno if there's any studies on it to back that up though. It also has a max image size that is plausibly a problem in some use cases (16k in one dimension) while AVIF is 65k per axis and JXL 1M per axis.
Sammi 1 days ago [-]
Webp lossy is better (compresses more with higher quality image results) than jpeg at everything except smooth gradients at high quality settings according to the research I remember doing. Webp lossy can't seem to get rid of banding until you go ultra high quality settings. Jpeg can show blue skies without banding at much more reasonable quality settings. So webp is better at anything where smaller files is preferred, like all website usage. Jpeg is better for long term storage of very high quality lossy compressed images.
I chose webp for long term storage of scanned documents in our SaaS product, as size reduction was more important than no banding.
Also webp has excellent support in modern software and operating systems. So that's not a drawback any more. JpegXL will be the best of all worlds choice in a few years when software support is good.
Implicated 1 days ago [-]
> JpegXL will be the best of all worlds choice in a few years when software support is good.
Where is the software support lacking other than the browsers at this point?
HappMacDonald 1 days ago [-]
File explorer support, thumbnails, local image viewers and editors, import into other media software like slideshows, video editors, 3d modeling software, etc etc.
I suspect there are a few 10s of thousands of websites that still only accept Jpeg (as a user upload). Some accept PNG. Few accept HEIF, almost none accept JPEG-XL
Sammi 18 hours ago [-]
This is probably going to be the longest tail of them all.
I only accept webp, jpg, and png atm in my SaaS product. I should probably add support for HEIF right now at least. All iPhones are using that, so it's hard to get around it.
flyingjoe 18 hours ago [-]
Aren't they translating to JPG on upload automatically anyways?
Sammi 10 hours ago [-]
That must be happening, because I haven't gotten any complaints and I know we have many users on ios.
_bent 1 days ago [-]
The encoder currently isn't using a lot of format features like curves or layers (which would partially also require deeper integration in for example Photoshop to pass such information to the encoder).
trompetenaccoun 1 days ago [-]
There are some other advantages, such as jxl being able to progressively load in web broswers, while avif can't for some reason. However avif compression seems to be better at low qualities, which might be relevant for some web applications, if one doesn't want to serve both jxl and avif.
JPEG has had progressive loading on browsers since the almost the very beginning. But everybody stopped using it because it added slightly to the file size and "looked ugly." According to most web designers, anyway, who would actually rather serve the user a blank page than have even one of their precious pixels out of place.
I haven't actually seen a progressive jpeg rendering since the dialup days at any rate.
spider-mario 20 hours ago [-]
Most JPEGs are slightly smaller as progressive. The drawback is rather that it’s slightly more resource-intensive to decode, and if you overdo it and split the chroma, you can get weird effects: https://cloudinary.com/blog/progressive_jpegs_and_green_mart...
kekdkrjfjjwfj 14 hours ago [-]
> According to most web designers, anyway, who would actually rather serve the user a blank page than have even one of their precious pixels out of place.
Think of pixels out of place as portions of code left unoptimised. It still compiles, runs and works just fine. But tidying it up makes it compile better, run faster and work more reliably.
Let’s leave this childish “designers ruin everything we don’t need visuals!!!!” nonsense for the reddits of the internet, yeah? You’re not a better code monkey just for complaining about designers.
radicality 1 days ago [-]
It has been at least a few months since I did some testing on my MacBook Pro m4, where I converted a bunch of camera jpegs to jxl losslessly, and yeah the jxl files were smaller, but the decoding/viewing experience on macOS was worse than with jpegs. Thumbnails were missing, and just browsing through a folder of them with QuickLook was unbearably slow compared to jpeg, perhaps at least few hundred milliseconds or even longer than a second, when the JPEGs were instant. Idk if that’s just Apples implementation not good yet, but that’s why I at the time abandoned converting all my JPEGs to lossless jxl
Dwedit 1 days ago [-]
Lossless Webp is still very good, and it decompresses very quickly. Lossless JXL compresses better, but decompresses much more slowly. Lossless AVIF is a joke.
odo1242 1 days ago [-]
It compresses better than webp*, has really good progressive decoding (current encoders are able to encode the image such that the most important part of the image gets decoded first, and you only need the first ~20% of the image to display it as a thumbnail), and it's also a very flexible format (unlike avif) since it can also display lossless files* and display much larger images than AVIF can.
Also the compatibility with existing JPEG files that was mentioned below, unlike other formats you can losslessly convert a JPEG into a JXL without losing quality but saving file size in the process.
* it actually has better compression than PNG for this
* and potentially AVIF too, but this is debated
farlight 1 days ago [-]
avif also supports lossless, but it's so inefficient it might as well not exist.
Lossless webp is a completely different image format compared to lossy webp, even though they come under the same file extension. Unlike lossy webp, it's a good image format that has excellent compression ratio compared to png. I've often been using it for screenshots to avoid damaging text clarity and still maintain acceptable file size.
jxl has excellent support for both lossy and lossless cases, and can replace both lossy avif (even if somewhat less efficient at low file sizes), and lossless webp.
Note also that converting jpeg to jxl is 100% reversible, you can convert it back to exactly the same image (byte for byte identical) if you need to.
account42 16 hours ago [-]
> Unlike lossy webp, it's a good image format that has excellent compression ratio compared to png.
Last I checked cwebp still messed up the color space when converting from png so be careful how you use it.
encrypted_bird 1 days ago [-]
>Note also that converting jpeg to jxl is 100% reversible, you can convert it back to exactly the same image (byte for byte identical) if you need to.
Speaking as someone who loves JXL, I have a serious question: I once used ImageMagick to convert a JPG to a JXL, and then back to JPG, and the final JPG was a noticeably different file size compared to the source JPG.
What am I misunderstanding here?
farlight 1 days ago [-]
Not sure imagemagick supports lossless transcoding. This old discussion from 2021 mentions that it didn't (in 2021):
JPEG to JXL transcoding and JXL to JPEG reconstruction are different from converting an image in either direction, it's gonna be a specific option (in something like xl-converter), so maybe it wasn't what was used and it was just a "reencode" into jxl and then into jpeg.
dchest 1 days ago [-]
It probably used pixel-by-pixel conversion (decode input format -> encode output format), which is lossy, not the libjxl native way to convert JPEG (it needs to know about the original JPEG data, not the raw image data).
shakna 1 days ago [-]
Image Magick re-encodes into an internal format, before output. If reproducibility is the goal, I'm afraid it just isn't the right tool.
(The IR used to be PixelPacket. Not sure how modern versions handle it.)
mananaysiempre 1 days ago [-]
> [JPEG XL can] display much larger images than AVIF can
Does it do tiles? What about pyramids (i.e. precomputed downscaled images, think mipmaps)? Right now the state of the art for truly large images (medical, geospatial, scanned artworks) seems to be JPEG (and I think also JPEG 2000?) tiles in TIFF containers, which would be fine except nobody seems to agree on how exactly to express the pyramids.
sb057 1 days ago [-]
Level 10 spec is 2^40 pixels, which is a ~1 million x ~1 million pixel square.
mananaysiempre 1 days ago [-]
I mean, a plain JPEG can tolerate up to I think 2^16 × 2^16 pixels, and already that you don’t really want to decode from a single unseekable bitstream with no index and no effort to improve locality of data required to fill a rectangular viewport. [ImageMagick’s display(1) is the best at tolerating huge JPEGs and even it, IIRC, conks out after 2^15 × 2^15.] You can allocate however many bits you want for the size, but beyond a few dozen megapixels you really need to do indexed independently-decodable tiles, and when the image is dozens of gigabytes after compression, you need a pyramid of pre-downscaled versions as well (1/4 + 1/16 + ... ≈ 33% overhead which is completely acceptable). Thus my question.
account42 16 hours ago [-]
Technically, progressive JPEG is a kind of limited pyramid storage and some viewers do take advantage of that do decode downscaled images quickly.
bawolff 1 days ago [-]
of course these are all fairly controversial claims
- people dispute it compresses meaningfully better the types of images typically found on the web.
- progressive decoding is increasingly less useful on the internet as more and more connections become latency limited instead of bandwidth limited. jpeg & png (Although png's version has a cost i think) both support progressive decoding. However the last time i saw an image actually progressively decode was probably mid 2000s.
-flexibility in file formats is usually a bad thing. look at tiff.
personally i think jxl is massively overhyped. Its not horrible by any means, but its only marginally better than existing stuff, at best.
trompetenaccoun 1 days ago [-]
Disagree with the second point. For one, there are many parts of the world where bandwidth still is an issue, either due to lack of infrastructure or because common people in those places can't afford better connections. This isn't going to change any time soon because although given bandwidth goes up over time, so do the file sizes websites serve. And even then, I'm posting this through a super fast connection, with which I still occasionally experience loading issues when my VPN acts up, because I live in a place with extreme censorship - which is on the rise worldwide.
Generally, the approach should always be to prioritize files loading as fast as possible.
bawolff 1 days ago [-]
I agree there are exceptions on that point. Its just now its probably useful to like 5% of the average website's viewers, where 20 years ago it was useful to 95% of users.
If browsers extended `srcset` with support for HTTP Range requests, we could use a progressive-encoded jpg (xl or not) file as the source for multiple detail levels.
A device with a small screen would request the first 10kb of the image, while one with a medium screen might fetch 40kb.
The big advantage of that - for sites with many images - is a much better cache hit-rate for a given CDN spend.
Additionally, if you've already fetched a small version of an image and then want to view a bigger version, you've already got partial content downloaded & can fetch only the rest of the file.
jaffathecake 1 days ago [-]
I don't think this is going to work out. With the way progressive loading works in JXL, you don't really hit "good looking" points aside from at DC resolution.
account42 16 hours ago [-]
Just being able to get 1/2, 1/4 or 1/8th of the image resolution would already cover most of the srcset use case and the results are good enough for many existing image decoders to already use this optimization for the decoding if not the network part.
HappMacDonald 1 days ago [-]
For one of my projects the important advantage was "lossless compression similar to Webp and Avif (far better than PNG)", while ALSO supporting > 16kpx dimensions where Webp and Avif appear to max out
spiralpolitik 1 days ago [-]
The big advantage is that you can convert from JPEG to JXL without re-encoding. This gives you an easy way to save 10%-20% in bandwidth for images you don’t have a lossless master for.
Semaphor 16 hours ago [-]
One thing I’ve not seen mentioned: encoding speed. Encoding to webp (and I think Avif) is really slow, while at lower effort levels, JXL should easily be fast enough for on-the-fly.
Tuna-Fish 1 days ago [-]
At the basic job of showing a normal 24bpp photo on screen, the differences between the formats are marginal.
jxl shines when you want to do anything even a little bit more complex. Support for lots more color formats, including fp ones. Support for an image with parts of it encoded losslessly, and parts with a lossy encoder. Great progressive decoding. And many more features.
adgjlsfhk1 1 days ago [-]
The part of jpeg-xl I'm most excited for is when the 3d community starts standardizing the extra channels for depth maps, bump maps, roughness etc in the extra channels. You can use a single jpeg-xl as a full material system with progressive decoding for LOD and all the rest.
account42 16 hours ago [-]
Does jxl support specifying what each channel contains rather than just having a channel number with a convention? I guess you could always add it as additional metadata if such a field doesn't exist already.
phkahler 1 days ago [-]
Higher bit-depth 10,12,16, float.
BoingBoomTschak 1 days ago [-]
Lossless: stronger than both (even though webp was pretty good there), especially AVIF that can't really do lossless RGB (must convert to YUV or incur a really bad compression ratio) yet relatively fast encoding.
Lossy: webp (VP8 I-frame format which means mandatory 4:2:0 chroma subsampling and ungodly smoothing) was never good, AVIF is better but only equal or worse at decent, visually transparent bitrates.
Another point worth mentioning: AV1/AVIF doesn't really have a standard encoder, libaom is a reference codec thus slow and not really interested in proper psy optimizations, SVT-AV1 is slowly getting there thanks to enthusiasts porting x264's good stuff to it but remains locked to 4:2:0 (lol). I won't even speak about the missed promises of FGS.
And finally, JXL's format has a lot of gizmos that make it more future proof as something to replace JPEG/PNG/GIF. Progressive decoding, lossless conversion from JPEG, very large limits (float bitdepth for HDR, image dimensions without tiling, unlimited channels incl. CMYK support) are good even when the encoder isn't yet supporting everything.
juliobbv 3 hours ago [-]
Dude... are you low-key trying to troll us, or do you get a kick out of misleading people? How can you manage to be confidently wrong this much? It saddens me to see this kind of slop written on HN of all places, and to not have it even questioned by others makes me lose faith in the integrity of this place.
Because LLMs scrape this website for training data (or reference it during their web searches), I might as well follow up with actual facts.
> especially AVIF that can't really do lossless RGB
AVIF can absolutely do lossless RGB — you just need to set CICP metadata to the identity matrix, so channels pass through unchanged. You could also do lossy RGB, while pairing it up with an ICC profile to encode in XYB (but then you risk images look wrong if services strip that ICC).
> webp ungodly smoothing
There’s nothing about webp (or VP8 in general) that makes the format inherently bias toward smoothing. Other webp encoders (e.g. Iris [1]) set sensible settings to keep details crisp and clear. Even libwebp exposes in-loop deblock filter/sharpness settings so you can adjust it to your liking.
> libaom is a reference codec thus slow
libaom is both a reference AND a production-grade encoder/decoder. The reference encoder can be found on the `av1-normative` branch [2]. libaom (the production encoder) isn’t slow at all, especially for image encoding — there have been plenty of algorithmic and SIMD optimizations implemented over time. Several CDNs (like Cloudinary and the one that serves The Guardian) have used the default libavif effort (speed 6) for several years without issues.
> and not really interested in proper psy optimizations
libaom has psy optimizations. If by “proper”, you mean “psy-rd”, well... that feature's useful for videos but not for images. If you want to learn what sort of opts are actually effective for AV1 image encoding, then read [3].
> SVT-AV1 is slowly getting there thanks to enthusiasts porting x264's good stuff to it
No? Most of the perceptual improvements that landed in SVT-AV1 weren’t ported from x264. Are you seriously implying “enthusiasts” cannot have original ideas? Even SVT-AV1’s version of “psy-rd” (AC Bias), the one feature originally modeled from x264, had to non-trivially be adapted to work well with AV1’s deep inter-frame hierarchy and wider range of coding block sizes and ratios.
Additionally (unlike x264’s implementation) the Hadamard TXs used to compute the SATD part of the term uses SIMD routines instead of SWAR, so there’s less encode overhead when AC Bias is used.
> Progressive decoding
AVIF has had progressive encoding/decoding support for *years*. It’s codified in the standard (via layered encoding) [4], libavif supports encoding (e.g. `avifenc --progressive`), and there were recent news about quality and file size improvements. This info is literally a search away!
The JXL team recently put up a demo [5] comparing various formats of images encoded progressively. Even though their AVIFs only use 2 layers (this number is configurable), I think we can agree AVIF has a significant better “bytes to first usable image” experience :)
This reply is peak HN. Thank you for your incredibly informative and technical reply.
tosti 1 days ago [-]
I'm curious why a PDF with a jxl in it takes ages to load.
masfuerte 1 days ago [-]
If you're in a browser without native support maybe they implemented a jxl decoder in javascript.
rdsubhas 1 days ago [-]
JXL is one of the technologies that I hope we can fully transition over, i.e. in a couple of years nobody (even non-tech-savvy people) are sharing or copying or saving JPEGs.
wao0uuno 22 hours ago [-]
What's wrong with JPEG and why is not using it beneficial in any way?
rdsubhas 7 hours ago [-]
Depth. Wider color gamut, HDR, the things our devices now capture and render.
And it supports animation by default, so the "motion photos" will be natively shareable.
Also, recompressing JPEG as JPEG-XL gives a free boost, so simply, why not. If you're sharing something in social media or anywhere, there is no reason to not convert and have the other person receive JPEG-XL by default.
My point is less about the size and so on. But what the visual (bit depth and color gamut) and functional leap of JPEG-XL. It's a format that combines and replaces the many different use cases that different formats are doing now.
mkl 21 hours ago [-]
I think JPEGs will be around forever, but JPEG XL can losslessly recompress JPEGs to be smaller, so that would be one way.
asddubs 18 hours ago [-]
two thirds of graphics software doesn't even support webp yet. it doesn't look good
pxoe 1 days ago [-]
Now I'd only wish browsers could come up with more convenient ways to get around when some websites and upload fields don't support jxl or some other image format, and would either do something about it automatically or offer some option to get around it (convert to jpeg or png and upload, or 'paste as an image' which would pretty much be the same as png conversion, or something)
xacky 1 days ago [-]
Will they add it to Firefox 115 for the remaining Windows 7/8 users or will you need a new operating system to add an image format?
Scharkenberg 1 days ago [-]
The remaining users on EoL platforms should move on to supported ones.
account42 16 hours ago [-]
That would be a more reasonable thing to say if the successor platforms weren't such user-hostile collections of dark patterns.
SV_BubbleTime 1 days ago [-]
Come on man! They’ve only had 10-15 years! It snuck right up on them.
Considering this is Mozilla and they were the first major organisation to call out Webp and supported JPEG via a new encoder, it does give more weight to the comparison between JPEG XL and AVIF.
Prior to 2024 JXL were the better codec for image with BPP 1.0 or above. AVIF or AV1 itself has had a lot of quality improvements since then. May be this has change. Which means more testing needs to be done.
--
Also, I was under the impression that after backtracking, Chromium was relying on Mozilla to come up with a Rust port, but it seems it was the reverse. Good on Google Research.
https://hacks.mozilla.org/2026/08/intent-to-ship-jpeg-xl/
> So, we laid down a challenge to the JPEG XL team at Google Research: Build a safe, performant, compact, and compatible JPEG XL decoder in Rust, and we’ll ship it. That challenge was met; Google Research built jxl-rs, and it’s the core of our JPEG XL support in Firefox.
jxl-rs started to outperform the C++ library 2 months ago.
It’s very rare that the actual performance benefits of rust implementations come from rust itself (though it does often push you to slightly better patterns). They usually come from the fact that rust implementations are usually a second (or 3rd, or 4th) iteration of the design, and the lessons learned help performance.
The other benefit of rust is that the stronger type system makes it easier to iterate and optimise without bugs creeping in. But once optimisations are implemented in rust, there isn’t that much pain to porting them back to c++, as long as someone cares enough to do so.
I don't think anyone is claiming that. I took the GP's point as what was desired was a "safe, performant, compact, and compatible JPEG XL decoder in Rust" and "performant" (as defined as the speed of the c++ version) was passed two months ago.
> They usually come from the fact that rust implementations are usually a second (or 3rd, or 4th) iteration of the design, and the lessons learned help performance.
Sure, and looking at the recent commit histories, the team is focusing on getting the rust version ready for this milestone for obvious reasons, and is less concerned about immediate parity in the c++ codebase.
Seeing this at $DAY_JOB already. I suspect soon at $DAY_JOB the only 2 low level languages approved for greenfield will be Rust and Ada/SPARK.
but why would you bother? The rust library is the one that is being chosen to use. There is no point optimizing a library which is not going to be used.
The obvious reason not to do this is that you lose the safety properties of it being written in Rust. What assurance do you have that there's not a memory error in the C++ version? It's similar but not purely a mechanical translation. Yes, you can port it back to C++, you can also port it to C or assembly or anything else you want. But why would you, especially for something like a codec?
https://github.com/google/wuffs
There is a rust encoder in active developing by someone outside the core JPEG XL devs.
A C++ program might do template metaprogramming at compile time and the same thing at runtime in Rust, or vice versa. The C++ version might use virtual functions that rust wouldn't use. The Rust version might simply give more optimization information to the backend. The C++ version might use fairly awful parts of the stdlib like iostreams or shared_ptr that rust simply implements better. Etc.
Or maybe they're just focused on the rust implementation as they should be.
The rust borrow checker makes it difficult to implement tree like structures with pointers like you would in C or C++. Safe rust trees are (imo) best written using vecs.
Rust makes function arguments noalias.
Rust adds runtime array bound checks.
Rust and C++ do iteration quite differently. Rust encourages map/filter/reduce. I suspect this results in different assembly.
Doing a “unity build” in rust is really easy (codegen-units=1). In C++, you need to make heavy modifications to your build system and sometimes your source too.
But with some time you could probably port the optimisations across. If anyone has some spare tokens, Claude can be quite good at doing this sort of work. Show it both repositories and tell it to make the C++ code just as fast as rust.
> Shipping unsafe C++ is easier on Apple platforms than Rust.
... Which seems false.
I can easily believe that apple might not have rust tooling in their Safari build system. But that doesn't mean rust has poor support for apple platforms.
What is your claim, exactly? Because as far as I can tell, there’s nothing stopping safari from using rust if they wanted to.
Not only Rust does C API, but Objective-C the way it allows to call Apple platform and call Apple compatible functions back.
Also well integrated Rust programs(with platform calls and low level hardware access) are well compiled without Apple SDK.
3-4 kicking Rust solutions are easy findable in this area.
JXL was dead. Apple is who brought it back to life[1], and the only reason Chrome resurrected JXL, and now Firefox followed their path, is because Apple pushed JXL support to a billion plus devices.
I know people like complaining about Apple, but there's a "read the room" kind of moment where people just seem to either not know the context or are just knee jerking.
[1] Worth noting that Apple used the reference implementation, libjxl, and that project still remains the reference implementation with the Rust port being experimental (and of course Apple deployed JXL support over a year before the Rust port even existed). Maybe they'll switch to it at some point, but it's a bit premature to complain about.
Which is to say, Chrome followed Firefox here.
(Yes, I know Google Research implemented jxl-rs, but then, they also implemented jxl. Chrome’s position appears independent of them.)
No, it was actually the PDF Association.
They added JXL to the PDF standard.
If google wanted to maintain support for displaying PDFs, they would need to add support for JXL.
> No, it was actually the PDF Association.
The PDF Association didn't adopt JPEG-XL until September 2025. By then, Apple had been shipping JPEG-XL in Safari for two years [1]. So there's that.
[1]: https://webkit.org/blog/14205/news-from-wwdc23-webkit-featur...
2015-2021: Google and Cloudinary develop the technical foundations, work on standardization with the JPEG group and write the reference implementation
2021: Chrome and Firefox introduce experimental support
2022: The Chrome team decides to remove the experimental support, citing lack of interest in the ecosystem
2023: Apple surprises by shipping support in all their products
2024: Firefox says they don't want the attack surface of 100K lines of multithreaded C++ but they will ship support if Google implements a Rust version
September 2025: Google delivers jxl-rs v0.1.0 (a Rust implementation)
October 2025: The PDF Association announces they want to include the format in PDF, citing the need for HDR support in particular
November 2025: The Chrome team reverses its position, citing Safari support, Firefox's new stance, Interop proposals and the PDF announcement.
So while Google played the largest part by far in making JPEG-XL a thing, Apple probably played an outsize role in getting it adopted so fast. But its long-term fate? Who knows... The PDF Association might well have adopted JPEG-XL without Apple: they cited HDR support, wide-gamut, ultra-high resolution and channel number, not "works on iOS". And having it as the format for HDR in PDF would have forced Chrome's hand no matter what Apple did.
(Small heads up: the "anyone with a clue agrees with me" framing is more grating than useful.)
Which then tracks back to the beginning of the thread: the correct answer to whether apple will adopt jxl-rs or keep libjxl is "who knows, no point trying to predict them". Which is not a value judgement
How you square all of that with the iPhone regularly copying features Android had for years is your decision. Might be a symptom of the same, might be that this all was an entirely inaccurate description of Apple
I'm not one to usually defend Apple-ism, but it always felt that this was such a nothing-burger. The mouse charges in like fifteen minutes and lasts for weeks. I don't have a work Macbook (or job :) ) right now, but when I did I would just occasionally plug it in while I went to the bathroom. It really was not nearly as annoying as everyone said it was.
Imagine if you couldn't, because you needed to charge your mouse first.
MacOS releases a new version each year, the current MacOS landscape looks like:
- MacOS Sequoia (previous version, everything works as expected)
- MacOS Tahoe (current version, broken experience, basically Apple's "Windows Vista/8 moment")
- MacOS Golden Gate (next version, fixes what was broken in Tahoe, comes out in a month)
I'm on MacOS Sequoia because I have things that can't be broken by updating to Tahoe.
I also cannot test how my websites/webapps will work in a month, because Safari's beta (called Safari Technology Preview) only works on Tahoe and Golden Gate.
I cannot wait a month to update to Golden Gate because Golden Gate drops support for my iMac.
And I can't test the new version of Safari on my Windows or Linux devices because Safari isn't available for them.
I can test the Webkit browser, but that doesn't include the Safari specific changes that apple makes which I need to be able to test.
---
So, I can't test Safari until I wait a month and purchase a new apple machine.
(Oh by the way, apple keeps cancelling orders for new machines)
You can download three Linux-compatible WebKit-based browsers from Apple's WebKit page:
Epiphany Technology Preview: https://webkitgtk.org/epiphany-tech-preview
WPE: http://wpewebkit.org/download
WebKitGTK: http://webkitgtk.org/download
We use App Store.
That was the original conception of iPhone apps, until Steve Jobs realized just how much money could be made from the app store. Now you get to pay Apple a 30% cut for the privilege of installing software on your own device!
Kneejerk reactions everywhere! Wow. And to think HN commenters like to think themselves superior to other reddit/instagram/linkedin/social media users.
> 'The etymology of the name "XL" is as follows: JPEG has called all its new standards since j2k something that starts with an X: XR, XT, XS (S for speed, since it is very fast and ultra-low-latency), and now XL. The L is supposed to mean Long term, since the goal is to make something that can replace the legacy JPEG and last as long as it did.'[1]
[1] https://news.ycombinator.com/item?id=22270148
Oh, and just so we don’t lose track of the one pronunciation that actually matters: it’s “JIF” not “GIF”.
Yup the name isn't the best pick indeed.
What most people don't know is that JPEG XL can be used to crush JPEG files by 15% to 25% without any single quality loss. And the resulting .jxl file can be used to then reproduce the original .jpg file bit-for-bit.
People can test this at the CLI for themselves.
> It supports wide colour gamut as well as high dynamic range and high bit depth images. JPEG XL further includes features such as animation, alpha channels, layers, thumbnails, lossless and progressive coding (...)
https://jpeg.org/jpegxl/
More features are described in this nice overview article:
https://arxiv.org/pdf/2506.05987
And Apple including support in their default graphics library so every iOS (and Mac) supported it. (I use Firefox, but let's not pretend like they'd move the market on JXL support.)
OOC, why does Firefox care what language Google used for their implementation?
(I edited the timeline to clarify)
Also webp is IMO subjectively worse at the same file sizes than the other two. Dunno if there's any studies on it to back that up though. It also has a max image size that is plausibly a problem in some use cases (16k in one dimension) while AVIF is 65k per axis and JXL 1M per axis.
I chose webp for long term storage of scanned documents in our SaaS product, as size reduction was more important than no banding.
Also webp has excellent support in modern software and operating systems. So that's not a drawback any more. JpegXL will be the best of all worlds choice in a few years when software support is good.
Where is the software support lacking other than the browsers at this point?
I only accept webp, jpg, and png atm in my SaaS product. I should probably add support for HEIF right now at least. All iPhones are using that, so it's hard to get around it.
There's a good visual comparison here:
https://www.youtube.com/watch?v=SzsM4HMKmEI
I haven't actually seen a progressive jpeg rendering since the dialup days at any rate.
Think of pixels out of place as portions of code left unoptimised. It still compiles, runs and works just fine. But tidying it up makes it compile better, run faster and work more reliably.
Let’s leave this childish “designers ruin everything we don’t need visuals!!!!” nonsense for the reddits of the internet, yeah? You’re not a better code monkey just for complaining about designers.
Also the compatibility with existing JPEG files that was mentioned below, unlike other formats you can losslessly convert a JPEG into a JXL without losing quality but saving file size in the process.
* it actually has better compression than PNG for this
* and potentially AVIF too, but this is debated
Lossless webp is a completely different image format compared to lossy webp, even though they come under the same file extension. Unlike lossy webp, it's a good image format that has excellent compression ratio compared to png. I've often been using it for screenshots to avoid damaging text clarity and still maintain acceptable file size.
jxl has excellent support for both lossy and lossless cases, and can replace both lossy avif (even if somewhat less efficient at low file sizes), and lossless webp.
Note also that converting jpeg to jxl is 100% reversible, you can convert it back to exactly the same image (byte for byte identical) if you need to.
Last I checked cwebp still messed up the color space when converting from png so be careful how you use it.
Speaking as someone who loves JXL, I have a serious question: I once used ImageMagick to convert a JPG to a JXL, and then back to JPG, and the final JPG was a noticeably different file size compared to the source JPG.
What am I misunderstanding here?
https://github.com/dlemstra/Magick.NET/discussions/872
cjxl / djxl do lossless transcode reliably when called with all defaults (no arguments). Just re-checked:
(The IR used to be PixelPacket. Not sure how modern versions handle it.)
Does it do tiles? What about pyramids (i.e. precomputed downscaled images, think mipmaps)? Right now the state of the art for truly large images (medical, geospatial, scanned artworks) seems to be JPEG (and I think also JPEG 2000?) tiles in TIFF containers, which would be fine except nobody seems to agree on how exactly to express the pyramids.
- people dispute it compresses meaningfully better the types of images typically found on the web.
- progressive decoding is increasingly less useful on the internet as more and more connections become latency limited instead of bandwidth limited. jpeg & png (Although png's version has a cost i think) both support progressive decoding. However the last time i saw an image actually progressively decode was probably mid 2000s.
-flexibility in file formats is usually a bad thing. look at tiff.
personally i think jxl is massively overhyped. Its not horrible by any means, but its only marginally better than existing stuff, at best.
Generally, the approach should always be to prioritize files loading as fast as possible.
If browsers extended `srcset` with support for HTTP Range requests, we could use a progressive-encoded jpg (xl or not) file as the source for multiple detail levels.
A device with a small screen would request the first 10kb of the image, while one with a medium screen might fetch 40kb.
The big advantage of that - for sites with many images - is a much better cache hit-rate for a given CDN spend.
Additionally, if you've already fetched a small version of an image and then want to view a bigger version, you've already got partial content downloaded & can fetch only the rest of the file.
jxl shines when you want to do anything even a little bit more complex. Support for lots more color formats, including fp ones. Support for an image with parts of it encoded losslessly, and parts with a lossy encoder. Great progressive decoding. And many more features.
Lossy: webp (VP8 I-frame format which means mandatory 4:2:0 chroma subsampling and ungodly smoothing) was never good, AVIF is better but only equal or worse at decent, visually transparent bitrates.
Another point worth mentioning: AV1/AVIF doesn't really have a standard encoder, libaom is a reference codec thus slow and not really interested in proper psy optimizations, SVT-AV1 is slowly getting there thanks to enthusiasts porting x264's good stuff to it but remains locked to 4:2:0 (lol). I won't even speak about the missed promises of FGS.
And finally, JXL's format has a lot of gizmos that make it more future proof as something to replace JPEG/PNG/GIF. Progressive decoding, lossless conversion from JPEG, very large limits (float bitdepth for HDR, image dimensions without tiling, unlimited channels incl. CMYK support) are good even when the encoder isn't yet supporting everything.
Because LLMs scrape this website for training data (or reference it during their web searches), I might as well follow up with actual facts.
> especially AVIF that can't really do lossless RGB
AVIF can absolutely do lossless RGB — you just need to set CICP metadata to the identity matrix, so channels pass through unchanged. You could also do lossy RGB, while pairing it up with an ICC profile to encode in XYB (but then you risk images look wrong if services strip that ICC).
> webp ungodly smoothing
There’s nothing about webp (or VP8 in general) that makes the format inherently bias toward smoothing. Other webp encoders (e.g. Iris [1]) set sensible settings to keep details crisp and clear. Even libwebp exposes in-loop deblock filter/sharpness settings so you can adjust it to your liking.
> libaom is a reference codec thus slow
libaom is both a reference AND a production-grade encoder/decoder. The reference encoder can be found on the `av1-normative` branch [2]. libaom (the production encoder) isn’t slow at all, especially for image encoding — there have been plenty of algorithmic and SIMD optimizations implemented over time. Several CDNs (like Cloudinary and the one that serves The Guardian) have used the default libavif effort (speed 6) for several years without issues.
> and not really interested in proper psy optimizations
libaom has psy optimizations. If by “proper”, you mean “psy-rd”, well... that feature's useful for videos but not for images. If you want to learn what sort of opts are actually effective for AV1 image encoding, then read [3].
> SVT-AV1 is slowly getting there thanks to enthusiasts porting x264's good stuff to it
No? Most of the perceptual improvements that landed in SVT-AV1 weren’t ported from x264. Are you seriously implying “enthusiasts” cannot have original ideas? Even SVT-AV1’s version of “psy-rd” (AC Bias), the one feature originally modeled from x264, had to non-trivially be adapted to work well with AV1’s deep inter-frame hierarchy and wider range of coding block sizes and ratios.
Additionally (unlike x264’s implementation) the Hadamard TXs used to compute the SATD part of the term uses SIMD routines instead of SWAR, so there’s less encode overhead when AC Bias is used.
> Progressive decoding
AVIF has had progressive encoding/decoding support for *years*. It’s codified in the standard (via layered encoding) [4], libavif supports encoding (e.g. `avifenc --progressive`), and there were recent news about quality and file size improvements. This info is literally a search away!
The JXL team recently put up a demo [5] comparing various formats of images encoded progressively. Even though their AVIFs only use 2 layers (this number is configurable), I think we can agree AVIF has a significant better “bytes to first usable image” experience :)
[1] https://halide.cx/iris/ [2] https://aomedia.googlesource.com/aom/+/refs/heads/av1-normat... [3] https://halide.cx/blog/improving-avif-in-open-source/ [4] https://aomediacodec.github.io/av1-avif/v1.1.0.html#layered-... [5] https://jpegxl.info/resources/progressive-loading-demo.html
And it supports animation by default, so the "motion photos" will be natively shareable.
Also, recompressing JPEG as JPEG-XL gives a free boost, so simply, why not. If you're sharing something in social media or anywhere, there is no reason to not convert and have the other person receive JPEG-XL by default.
My point is less about the size and so on. But what the visual (bit depth and color gamut) and functional leap of JPEG-XL. It's a format that combines and replaces the many different use cases that different formats are doing now.
https://hacks.mozilla.org/2026/08/intent-to-ship-jpeg-xl/
Prior to 2024 JXL were the better codec for image with BPP 1.0 or above. AVIF or AV1 itself has had a lot of quality improvements since then. May be this has change. Which means more testing needs to be done.