> This consolidates JPEG XL’s position as the best image codec currently available, for both lossless and lossy compression, across the quality range but in particular for high quality to visually lossless quality. It is Pareto-optimal across a wide range of speed settings.
Wow. Nice. Big improvement if JPEG and PNG can be replaced by one codec.
Disclaimer: As a manager I led the JPEG XL design, implementation and standardization effort at Google, and as an IC I was responsible for lossy format, encoding heuristics and image quality.
JPEG XL is not that massive.
JPEG XL spec is slightly less than 100 pages, about half the size of the JPEG1 spec.
A simple implementation in j40 was around 7000 lines of code last time I looked, not sure if it is 100 % complete however.
A simple encoder at libjxl-tiny is of similar size and very attractive to be used for expressing similar coding decisions in hardware intended for digital cameras.
A complex speed optimized C++ decoder implementation is ~35000 lines of code, but much of it is not due to the spec, but getting most out of SIMD-powered multi-core computers.
The binary size increase in Chromium on arm for adding (in the past) the C++ decoder was around 200 kB in APK size, possibly around 0.1 %.
This is probably impossible and also not needed. Choose security through compartmentalization (instead of security through correctness that never works), if you really care about security.
Do you daily drive Qubes? I'd be curious to hear about your experiences. I've been following the project from the sidelines for years, but haven't taken the leap.
Do you hate GPU acceleration? Do you hate using most hardware? Do you like using Xorg? Then Qubes is for you.
This is in jest, but those are my pain points - the AMD thinkpad I have can't run it, the Intel one melts yubikeys when decoding h264 video. The default lock screen can't read capital letters from the yubikeys static password entry. Qubes has a certain user that it caters to, I really wish they could get enough money to be able to cater to more use cases. It is not difficult to use it if it works for you.
Nobody uses "most hardware". You may be unlucky with your hardware, then it's a problem. Or you can specifically buy hardware working with the OS you want.
Yes, I daily drive Qubes. It's an amazing feeling to feel in full control over your computing and not being afraid to open any links or attachments. Here is my Qubes OS Elevator Pitch: https://forum.qubes-os.org/t/how-to-pitch-qubes-os/4499/15
Just FYI, there are some people that vastly exaggerate the security it provides. For the most part, you're just as safe using flatpak versions of applications.
Apart from the fact that this is extremely rare, the first vulnerability is not a complete escape. For example, any offline vault VM storing secrets stayed secure. This is just not happening with any other security approach.
Speculative sidechannel attacks have nothing to do with OS or compartmentalization technology, since they are the problem of CPUs. Nothing can help here, so this is irrelevant to this discussion. Except that Qubes Air will save you in the future: https://www.qubes-os.org/news/2018/01/22/qubes-air/
Qubes doesn't compartmentalize the image decoder in a web browser from the rest of the renderer, and if you're serving tracking pixels and can exploit image decoding, you can make serious mischief.
If you use Qubes correctly, then VM in which you go to untrusted websites is disposable and contains no personal information, so there is no mischief to make.
The web page you are visiting contains personal information, and that is where the mischief can be made. All that is required is for the website to incorrectly trust an image, either by not sanitizing a user-uploaded image or by embedding a third party image. Both trust bugs are rampant on the web, and both have caused problems in the past. Adding an improperly vetted image decoder is a sure-fire way to get exploit authors salivating.
> The web page you are visiting contains personal information, and that is where the mischief can be made.
This is a weird threat model. You trust some website with your personal information but you don't trust that images they embed are trusted and will not attack you. Nothing will save you here except switching off showing pictures, which you can also do on Qubes.
I would say, if they really embed malicious images, then they probably have other problems with security, which nothing you run can help with.
> Nothing will save you here except switching off showing pictures
Or having a trustable image decoder, which is what web browsers actually do. This is a basic requirement that you are proposing to do away with by instead not showing images at all.
The part I'm more excited for is all the image-like/bundle of image like data that until Jpeg-xl didn't have any good codecs (usually implemented as folders of images). One clear example of this is PBR in blender and friends. (e.g. a combo of normal map, roughness, color, metalness etc)
See https://devtalk.blender.org/t/jpeg-xl-as-an-intermediate-for.... TLDR is that one of the really interesting things JPEG-XL adds is the ability to have an arbitrary number of non-color channels. The current solution is generally to use separate grayscale images for each extra thing you want to store, which is inefficient since it loses the ability to compress the correlation between the separate channels. Another example usecase would be capturing images at 10 different wavelengths rather than the typical RGB.
That means that SSIMULACRA2 does not capture quality perfectly.
Note that in that figure the formats are compared at the same SSIMULACRA2 score, not at the same file size. In the "very low quality" category, JPEG uses ~0.4 bpp (bits per pixel), while JPEG-XL and AVIF use ~0.13 bpp and ~0.1 bpp, respectively, so JPEG is roughly given 4 times as much space to work with.
In the "med-low quality" category, JPEG-XL and AVIF use around 0.4 bpp, so perhaps you should compare the "very low quality" JPEG with "med-low quality" JPEG-XL and AVIF.
After reading your comment, I assumed you had missed the bpp difference. Please excuse me if I assumed incorrectly.
https://github.com/libjxl/jxl-rs jxl-rs is the underlying implementation. It's relatively new but Rust certainly calms security fears. This library wasn't really an option last time this came around in chromium.
Didn't Google refuse adding JpegXL because they claimed there wasn't enough interest? I don't think they refused out of security concerns but maybe I'm misremembering that.
Google argued that duplicating largely (I know JpegXL does support a bit more, but from most users' perspectives, they're largely right) what AVIF provided while being written in an unsafe language was not what they wanted in terms in increasing the attack surface.
And it really was the right move at the time, imo. JXL however now has better implementations and better momentum in the wider ecosystem and not just yet another image format that gets put into chrome and de facto becomes a standard.
I can confirm.
I found multiple problems in the "official" cjxl encoder back in 2023 contrary to the webp2 (cwp2) implementation where I could not find any bug or error.
If the encoder have obvious problems it is not a big deal, but it doesn't bode well for the decoder.
Google 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.
Do you have actual sources for this? Because the other people commenting about how the newer library removes most of the concerns explains this better than an unsubstantiated speculation about promoting AVIF.
> If you look at the issue tracker, the creator of Webp killed it because of untrue claims
I think for most modern software it's difficult to name the creator, but if you had to for webp, it would be hard to argue that it's anyone but Jyrki Alakuijala, who is in fact one of the co-creators of jpegxl and the person backing up the long-term support of the rust jxl-rs implementation, so I'm not even going to ask for a source here because it's just not true.
AFAIK Jyrki came after WebP was already announced to add lossless support; rather I’d consider Skal the creator inasmuch as it was originally just an image container for VP8 intra. He was working on WebP2 at the time Google rejected JPEG-XL and also was not involved in that decision.
I designed the lossless format and its initial encoder. Zoltán Szabadka wrote the initial lossless decoder.
On2 Technologies had designed the lossy format and its initial encoder/decoder. Skal improved on the encoder (rewriting it for better quality, inventing workarounds for the YUV420 sampling quality issues), but did not change the format's image-related aspects that On2 Technologies had come up with for VP8 video use.
In the end stage of lossless productization (around February 2012) Skal had minor impact on the lossless format:
1. He asked it to have the same size limitations (16383x16383 pixels) like lossy.
2. He wanted to remove some expressivity for easier time for hardware implementations, perhaps a 0.5 % hit on density.
Skal also took care of integrating the lossless format into the lossy as an alpha layer.
>so I'm not even going to ask for a source here because it's just not true.
Well it is up to you to decide. The link was submitted a dozen of times on HN and the whole thing was well reported. And Jyrki Alakuijala already classify its creator status.
That looks pretty good to me. Every `unsafe` function has clearly stated safety requirements, and every `unsafe` blocks justifies why the requirements are met.
So, I had no reason to use "unsafe" for a very long time, and had developed a bit of an aversion to it. Then I actually needed to use it, first to interface with some C code, and then to deal with a device's mmap'd memory as raw `&[u8]`s.
And my discovery (which basically anyone could have told me beforehand) was that ... "unsafe" rust is not really that different from regular rust. It lets you dereference pointers (which is not a particularly unusual operation in many other languages) and call some functions that need extra care. Usually the presence of "unsafe" really just means that you needed to interface with foreign functions or hardware or something.
This is all to say: implying that mere presence of an "unsafe" keyword is a sign that code is insecure is very, very silly.
No, memory safety is not security, Rust's memory guarantees eliminate some issues, but they also create a dangerous overconfidence, devs treat the compiler as a security audit and skip the hard work of threat modeling
A vigilant C programmer who manually validates everything and use available tools at its disposal is less risky than a complacent Rust programmer who blindly trust the language
> A vigilant C programmer who manually validates everything and use available tools at its disposal is less risky than a complacent Rust programmer who blindly trust the language
I agree with this. But for a component whose job is to parse data and produce pixels, the security worries I have are memory ones. It's not implementing a permissions model or anything where design and logic are really important. The security holes an image codec would introduce are the sort where it a buffer overun gave an execution primitive (etc.).
Rust programmers are far more likely to have the vigilant mindset than C programmers, or they wouldn't be using Rust.
You can get an awful lot done very quickly in C if you aren't bothered about security - and traditionally, most of the profession has done exactly that.
> A vigilant C programmer who manually validates everything and use available tools at its disposal is less risky than a complacent Rust programmer who blindly trust the language
What about against a vigilant Rust programmer who also manually validates everything and uses available tools at its disposal?
History shows that either vigilance of most C programmers is not enough, or they are not vigilant at all. C/C++ and RCE via some buffer overflow is like synonyms.
I’ve recently compared WebP and AVIF with the reference encoders (and rav1e for lossy AVIF), and for similar quality, WebP is almost instant while AVIF takes more than 20 seconds (1MP image).
JXL is not yet widely supported, so I cannot really use it (videogame maps), but I hope its performance is similar to WebP with better quality, for the future.
You have to adjust the CPU used parameter, not just quality, for AVIF. Though it can indeed be slow it should not be that slow, especially for a 1mp image. The defaults usually use a higher CPU setting for some reason. I have modest infrastructure that generates 2MP AVIF in a hundred ms or so.
I tested both WebP and AVIF with maximum CPU usage/effort. I have not tried the faster settings because I wanted the highest quality for small size, but for similar quality WebP blew AVIF out of the water.
I also have both compiled with -O3 and -march=znver2 in GCC (same for rav1e's RUSTFLAGS) through my Gentoo profile.
Maximum CPU between those two libs is not really comparable though. But quality is subjective and it sounds like webp worked best for you! Just saying though, there is little benefit in using the max CPU settings for avif. That's like comparing max CPU settings on zip vs xz!
I know, thats why I used max CPU settings. But when processing map tiles with a final total compressed size of half a terabyte, and each one is 200kB, taking 20s per tiles is prohibitively expensive.
For many relevant specs you can find "draft versions" that are essentially the final version without the official stamp on the open web so there isn't that much of a need.
Thanks, but just like WEBP I'll try to stick to regular JPEGs whenever possible. Not all programs I use accept these formats, and for a common user JPEG + PNG should mostly cover all needs. Maybe add GIF to the list for simple animations, while more complex ones can be videos instead of images.
Unfortunately being universal implies way more than just having good browser support. There are quite a few image processing programs without webp or jpeg-xl support. I'm using Windows 11 and the default image viewer can't even open webp... Also, keep in mind that due to subscription models there are many people stuck with older Photoshop versions too.
Thanks, I know about this and other workarounds. My point is, if it was truly universal you should not need anything! I bet most regular users will never even know this exists.
I never knew about this either and it's been very frustrating as I've been converting my Manga library over to webp (savings are insane) and doing any spot checking opens Edge.
Edit: After reading the comments, this doesn't seem to open in Photos App.
Webp can be really annoying once you hit certain encoding edge cases.
One customer of mine (fashion) has over 700k images in their DAM, and about 0.5% cannot be converted to webp at all using libwebp. They can without problem be converted to jpeg, png, and avif.
Just out of curiosity, what's the problem libwebp has with them? I wasn't aware of cases where any image format would just cross its arms and refuse point blank like that.
We have never been able to resolve it better than knowing this:
Certain pixel colour combinations in the source image appear to trip the algorithm to such a degree that the encoder will only produce a black image.
We know this because we have been able to encode the images by (in pure frustration) manually brute forcing moving a black square across the source image on different locations and then trying to encode again. Suddenly it will work.
Images are pretty much always exported from Adobe, often smaller than 3000x3000 pixels. Images from the same camera, same size, same photo session, same export batch will work and then suddenly one out of a few hundred may become black, and only the webp one not other formats, the rest of the photos will work for all formats.
A more mathematically inclined colleague tried to have a look at the implementation once, but was unable to figure it out because they could apparently not find a good written spec on how the encoder is supposed to work.
"JPEG XL" is a little bit of a misnomer as it's not just "JPEG with more bits". It supports lossless encoding of existing content at a smaller file size than PNG and allows you to transcode existing JPEGs recoverably for a 20% space savings, the lossy encoding doesn't look nearly as ugly and artifacted as JPEG, it supports wide gamut and HDR, and delivers images progressively so you get a decent preview with as little as 15% of the image loaded with no additional client-side effort (from https://jpegxl.info/).
It is at least a very good transcoding target for the web, but it genuinely replaces many other formats in a way where the original source file can more or less be regenerated.
Honestly, I don't like how webp and now jpegxl support both a lossless and lossy mode.
Let's say you want to store images lossless. This means you won't tolerate loss of data. Which means you don't want to risk it by using a codec that will compress the image lossy if you forget to enable a setting.
With PNG there is no way to accidentally make it lossy, which feels a lot safer for cases you want lossless compression.
PNG can and is often used in a lossy way. Reducing the number of colors so PNG8 can be used instead of PNG24/PNG32 is the most common way to do that. Tools like pngquant exist, and for example Photoshop when exporting to PNG also has an option to reduce the colors, to flatten the image (remove alpha), or to change the colorspace.
16-bit PNG files can easily accidentally be reduced to 8-bit, which is of course a lossy operation. Animated PNG files can easily get converted into a still image (keeping only the first frame). CMYK images will have to be converted to RGB when saving them as PNG, which is also a lossy operation. It can happen that an image gets created as or converted to JPEG and then gets saved as PNG - which of course is a bad and lossy workflow, but it does happen.
So I don't agree that with PNG there is no way to accidentally make it lossy.
In any case: lossless or lossy is not a property of a format, but of a workflow. For keeping track of provenance information and workflow history, I would recommend looking into JPEG Trust / C2PA, which is a way to embed as metadata what happened to an image since it was captured/generated. Relying on the choice of image format for this is fragile and doesn't allow expressing the nuances, since reality is more complicated than just a binary "lossless or lossy".
You can use too few bits of color depth to get lossyness in PNG. More generally, I can't find myself very sympathetic to "I don't want a format that can do X and Y, because I might accidentally select X when I want Y in my software". You might accidentally choose JPG when you want PNG too. Or accidentally resample the image. Or delete your files.
If you want a robust lossless workflow, PNG isn't the answer. Automating the fiddly parts and validating that the automation does what you want is the answer.
> Specifically for JPEG files, the default cjxl behavior is to apply lossless
recompression and the default djxl behavior is to reconstruct the original
JPEG file (when the extension of the output file is .jpg).
You're right, however, that you do need to be careful and use the reference codec package for this, as tools like ImageMagick create loss during the decoding of the JPEG into pixels (https://github.com/ImageMagick/ImageMagick/discussions/6046) and ImageMagick sets quality to 92 by default. But perhaps that's something we can change.
There's odd cases where it still has uses. When I was a teacher, some of the gamifying tools don't allow video embeds without a subscription, but I wanted to make some "what 3D operation is shown here" questions with various tools in Blender. GIF sizes were pretty comparable to video with largely static, less-than-a-second loops, and likely had slightly higher quality with care used to reduce color palette usage.
But I fully realize, there are vanishingly few cases with similar constraints.
If you need animated images in emails or text messages, GIF is the only supported format that will play the animation. Because of the size restrictions for these messaging systems the inefficient compression of GIFs is a major issue.
Videos and images are treated very differently by browsers and OS:es. I'm guessing the better suggestion would be to use apng or animated avif if you are looking for a proper gif alternative.
Yes, by using the <picture> element with <source> elements declaring the individual formats with the last one being a regular <img> with the gif.
Or you could use content-negotiation to only send avif when it's supported, but IMO the HTML way with <picture> is perhaps clearer for the client and end user.
I think the webp problem was due to browsers supporting webp but not supporting animation, transparency or other features, so content negotiation based on mime types (either via <picture> or HTTP content-negotiation) did not work properly. Safari 16.1-16.3 has the same problem with AVIF, but that is a smaller problem than it was with webp.
Affinity supports it. Photoshop supports it. Microsoft Photos supports it. Gimp supports it. Apple has had systemwide support for it since iOS 17+ / macOS 12+, including in Safari and basically any app that uses the system image functions.
Chromium isn't on the bleeding edge here. They actually were when it first came out, but then retreated and waited, and now they're back again.
Half the point of JPEG XL is support for HDR and higher than 8 bits per channel. Most of the apps you listed don’t support that fully, especially iOS, which converts everything to SDR or shows garbage — except for their own proprietary gain map encoding that their camera app produces.
Actually, in my recent vibe coding adventures I tested making a ProRAW converter app that also applied the included gain map to the image and encoded via libjxl on device. Surprisingly, Photos.app was able to display the converted image with HDR, but the HDR tag in the UI is only displayed for images with the proprietary gain map.
There seems to be some support there, though I tested on iOS 26.
That I of course didn't test. Yeah, I'd expect them reencoding images to save on bandwidth, and they're probably doing so naively for JXL (maybe even converting to HEIC).
I mean even Microsoft (that Titan of Lightning-Fast Development) has implemented a JPEG XL add-on, so now that Google's giving up the ghost, i think JPEG XL has a real chance.
I've been hearing about fights over JpegXL and WebP (and AVIF?) for years, but don't know much about it.
From a quick look at various "benchmarks" JpegXL seems just be flat out better than WebP in both compression speed and size, why has there been such reluctance from Chromium to adopt it? Are there WebP benefits I'm missing?
My only experience with WebP has been downloading what is nominally a `.png` file but then being told "WebP is not supported" by some software when I try to open it.
Most of the code in WebP and AVIF is shared with VP8/AV1, which means if your browser supports contemporary video codecs then it also gets pretty good lossy image codecs for free. JPEG-XL is a separate codebase, so it's far more effort to implement and merely providing better compression might not be worth it absent other considerations. The continued widespread use of JPEG is evidence that many web publishers don't care that much about squeezing out a few bytes.
Also from a security perspective the reference implementation of JPEG-XL isn't great. It's over a hundred kLoC of C++, and given the public support for memory safety by both Google and Mozilla it would be extremely embarrassing if a security vulnerability in libjxl lead to a zero-click zero-day in either Chrome or Firefox.
The timing is probably a sign that Chrome considers the Rust implementation of JPEG-XL to be mature enough (or at least heading in that direction) to start kicking the tires.
> The continued widespread use of JPEG is evidence that many web publishers don't care that much about squeezing out a few bytes.
I agree with the second part (useless hero images at the top of every post demonstrate it), but not necessarily the first. JPEG is supported pretty much everywhere images are, and it’s the de facto default format for pictures. Most people won’t even know what format they’re using, let alone that they could compress it or use another one. In the words of Hank Hill:
> Do I look like I know what a JPEG is? I just want a picture of a god dang hot dog.
I'm not (only) talking about the general population, but major sites. As a quick sanity check, the following sites are serving images with the `image/jpeg` content type:
* CNN (cnn.com): News-related photos on their front page
* Reddit (www.reddit.com): User-provided images uploaded to their internal image hosting
* Amazon (amazon.com): Product categories on the front page (product images are in WebP)
I wouldn't expect to see a lot of WebP on personal homepages or old-style forums, but if bandwidth costs were a meaningful budget line item then I would expect to see ~100% adoption of WebP or AVIF for any image that gets recompressed by a publishing pipeline.
And more importantly, an additional format is a commitment to maintain support forever, not only for you, but for future people who implement a web browser.
I can completely see why the default answer to "should we add x" should be no unless there is a really good reason.
It was an issue with the main JPEGXL library being unmaintained and possibly open for security flaws. Some people got together and wrote a new one in Rust which then became an acceptable choice for a secure browser.
> various "benchmarks" JpegXL seems just be flat out better than WebP
The decode speed benchmarks are misleading. WebP has been hardware accelerated since 2013 in Android and 2020 in Apple devices. Due to existing hardware capabilities, real users will _always_ experience better performance and battery life with webp.
JXL is more about future-proofing. Bit depth, Wide gamut HDR, Progressive decoding, Animation, Transparency, etc.
JXL does flat out beats AVIF (the image codec, not videos) today. AVIF also pretty much doesn't have hardware decoding in modern phones yet. It makes sense to invest NOW in JXL than on AVIF.
For what people use today - unfortunately there is no significant case to beat WebP with the existing momentum. The size vs perceptive quality tradeoffs are not significantly different. For users, things will get worse (worser decode speeds & battery life due to lack of hardware decode) before it gets better. That can take many years – because hey, more features in JXL also means translating that to hardware die space will take more time. Just the software side of things is only now picking up.
But for what we all need – it's really necessary to start the JXL journey now.
Where can I learn more about hardware acceleration of WebP on mobile OSes? I haven’t yet come across a resource that confirms this is actually the case. I know it should theoretically be possible using the VP8 hardware decoders but I thought those were expensive to warm up just for images
Google created webp and that is why they are giving it unjustified preferential treatment and has been trying to unreasonably force it down the throat of the internet.
WebP gave me alpha transparency with lossy images, which came in handy at the time. It was also not bogged down by patents and licensing. Plus like others said, if you support vp8 video, you pretty much already have a webp codec, same with AV1 and avif
a better argument might be that chrome protects their own vs a research group in google switzerland, however as other mentioned the security implications of another unsafe binary parser in a browser is hardly worth it
which only strengthens my argument, webp seemed like some ad-hoc pet project in chrome, and that ended like most unsafe binary parsers, with critical vulnerabilities
You're getting downvoted, but you're not wrong. If anyone else had come up with it, it would have been ignored completely. I don't think it's as bad as some people make it out to be, but it's not really that compelling for end users, either. As other folks in the thread have pointed out, WebP is basically the static image format that you get “for free” when you've already got a VP8 video decoder.
The funny thing is all the places where Google's own ecosystem has ignored WebP. E.g., the golang stdlib has a WebP decoder, but all of the encoders you'll find are CGo bindings to libwebp.
Why does the current design paradigm in image coding formats emphasise supporting as many features as possible in order to have “one image format to rule them all”? You do not see this in audio and does anybody think that Opus and FLAC should be combined into one format? Does the fact that Opus does not support lossless encoding make it worse?
Reading the feature list of JpegXL on Wiki, it includes some interesting stuff like arbitrary numbers of channels for multi-spectral imaging and multi page documents, which for both better and worse starts to sound a lot like TIFF.
Yes, but it's not recommended - it does not have inter-frame compression, so it is significantly less efficient than just having a regular video file and slapping 'gif' on it.
That's not strictly correct, it's rather that the current encoder does no inter-frame compression. Patches (and the frame system in general) does give tools to do some inter-frame compression (not as many as in video, but still quite expressive), just nobody stepped up to implement compression using them for animations yet.
Progressive decoding isn't a very useful video feature because you need to decode the whole frame before you decode the next frame for inter-frame coding methods anyway.
It is, however, a very useful image format feature, giving you most information from the spinner/sticker/emoji/sprite, and refinig the already playing loop as it loads. That's why animated jxl is a bad video format — it's not a video format, it is a separate kind of seemingly weird thing.
What, isn't this the cue for someone to explain that it's ironic webp is really a video format which is a bad image format, and now we have symmetry that JpegXL is a good image format which is bad video format? :-D
(I don't know if any of this is true, but it sounds funny...)
Unfortunately, with Chromium dropping support for manifest-v2 extensions, and through that dropping proper support for uBlock Origin, I'm moving away from it. Not that that's easy, of course...
With Chrome being by far the most popular browser, it gaining support is almost a precondition for jxl gaining traction on the web.
Few would bother converting their images for Safari (and when it becomes enabled without a flag Firefox).
So this is good news even for people who don't use Chromium.
https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front
Oldie goodie article with charts, comparing webp, jpegxl, avif, jpeg etc. avif is SLOW
> This consolidates JPEG XL’s position as the best image codec currently available, for both lossless and lossy compression, across the quality range but in particular for high quality to visually lossless quality. It is Pareto-optimal across a wide range of speed settings.
Wow. Nice. Big improvement if JPEG and PNG can be replaced by one codec.
And even better if someone can implement the whole massive spec securely...
Disclaimer: As a manager I led the JPEG XL design, implementation and standardization effort at Google, and as an IC I was responsible for lossy format, encoding heuristics and image quality.
JPEG XL is not that massive.
JPEG XL spec is slightly less than 100 pages, about half the size of the JPEG1 spec.
A simple implementation in j40 was around 7000 lines of code last time I looked, not sure if it is 100 % complete however.
A simple encoder at libjxl-tiny is of similar size and very attractive to be used for expressing similar coding decisions in hardware intended for digital cameras.
A complex speed optimized C++ decoder implementation is ~35000 lines of code, but much of it is not due to the spec, but getting most out of SIMD-powered multi-core computers.
The binary size increase in Chromium on arm for adding (in the past) the C++ decoder was around 200 kB in APK size, possibly around 0.1 %.
This is probably impossible and also not needed. Choose security through compartmentalization (instead of security through correctness that never works), if you really care about security.
Works for me with Qubes OS.
Do you daily drive Qubes? I'd be curious to hear about your experiences. I've been following the project from the sidelines for years, but haven't taken the leap.
Do you hate GPU acceleration? Do you hate using most hardware? Do you like using Xorg? Then Qubes is for you.
This is in jest, but those are my pain points - the AMD thinkpad I have can't run it, the Intel one melts yubikeys when decoding h264 video. The default lock screen can't read capital letters from the yubikeys static password entry. Qubes has a certain user that it caters to, I really wish they could get enough money to be able to cater to more use cases. It is not difficult to use it if it works for you.
GPU acceleration is coming: https://github.com/QubesOS/qubes-issues/issues/8552
> Do you hate using most hardware?
Nobody uses "most hardware". You may be unlucky with your hardware, then it's a problem. Or you can specifically buy hardware working with the OS you want.
> Do you like using Xorg?
What's wrong with Xorg?
> What's wrong with Xorg?
Lock screens that crash. Lock screens that can’t handle input from a yubikey?
There are no crashes on lock screen with Qubes. Concerning Yubikey, see this: https://doc.qubes-os.org/en/latest/user/security-in-qubes/mf...
Yes, I daily drive Qubes. It's an amazing feeling to feel in full control over your computing and not being afraid to open any links or attachments. Here is my Qubes OS Elevator Pitch: https://forum.qubes-os.org/t/how-to-pitch-qubes-os/4499/15
It's slow for tasks requiring GPU, but allowing GPU for chosen, trusted VMs is planned: https://github.com/QubesOS/qubes-issues/issues/8552
Just FYI, there are some people that vastly exaggerate the security it provides. For the most part, you're just as safe using flatpak versions of applications.
When was the last Flatpak escape? Last VM escape from VT-d virtualization, which Qubes uses by default, was found in 2006 by the Qubes founder, https://en.wikipedia.org/wiki/Blue_Pill_(software)
The most recent VM escape from VT-d virtualization was in 2022[0].
Escapes are not the only vulnerability. QSB-108 allows for reading the memory of other qubes running on the host[1].
[0] https://nvd.nist.gov/vuln/detail/CVE-2020-15565
[1] https://www.qubes-os.org/news/2025/07/11/qsb-108/
Apart from the fact that this is extremely rare, the first vulnerability is not a complete escape. For example, any offline vault VM storing secrets stayed secure. This is just not happening with any other security approach.
Speculative sidechannel attacks have nothing to do with OS or compartmentalization technology, since they are the problem of CPUs. Nothing can help here, so this is irrelevant to this discussion. Except that Qubes Air will save you in the future: https://www.qubes-os.org/news/2018/01/22/qubes-air/
Qubes doesn't compartmentalize the image decoder in a web browser from the rest of the renderer, and if you're serving tracking pixels and can exploit image decoding, you can make serious mischief.
If you use Qubes correctly, then VM in which you go to untrusted websites is disposable and contains no personal information, so there is no mischief to make.
The web page you are visiting contains personal information, and that is where the mischief can be made. All that is required is for the website to incorrectly trust an image, either by not sanitizing a user-uploaded image or by embedding a third party image. Both trust bugs are rampant on the web, and both have caused problems in the past. Adding an improperly vetted image decoder is a sure-fire way to get exploit authors salivating.
> The web page you are visiting contains personal information, and that is where the mischief can be made.
This is a weird threat model. You trust some website with your personal information but you don't trust that images they embed are trusted and will not attack you. Nothing will save you here except switching off showing pictures, which you can also do on Qubes.
I would say, if they really embed malicious images, then they probably have other problems with security, which nothing you run can help with.
> Nothing will save you here except switching off showing pictures
Or having a trustable image decoder, which is what web browsers actually do. This is a basic requirement that you are proposing to do away with by instead not showing images at all.
The part I'm more excited for is all the image-like/bundle of image like data that until Jpeg-xl didn't have any good codecs (usually implemented as folders of images). One clear example of this is PBR in blender and friends. (e.g. a combo of normal map, roughness, color, metalness etc)
This is new to me. Can you elaborate please? Perhaps a link to somewhere showcasing this (and contrasting this to other solutions).
See https://devtalk.blender.org/t/jpeg-xl-as-an-intermediate-for.... TLDR is that one of the really interesting things JPEG-XL adds is the ability to have an arbitrary number of non-color channels. The current solution is generally to use separate grayscale images for each extra thing you want to store, which is inefficient since it loses the ability to compress the correlation between the separate channels. Another example usecase would be capturing images at 10 different wavelengths rather than the typical RGB.
> Big improvement if JPEG and PNG can be replaced by one codec.
By one ? Ten maybe: webp, avif, ...
what exactly is this website trying to do? https://i.imgur.com/Q8JGYK3.png
I don't get any of that. Maybe you have a malicious extension installed?
Maybe some form of fingerprinting for ads?
JPEG at lowest quality looks much better here https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front#wha...
That means that SSIMULACRA2 does not capture quality perfectly.
Note that in that figure the formats are compared at the same SSIMULACRA2 score, not at the same file size. In the "very low quality" category, JPEG uses ~0.4 bpp (bits per pixel), while JPEG-XL and AVIF use ~0.13 bpp and ~0.1 bpp, respectively, so JPEG is roughly given 4 times as much space to work with. In the "med-low quality" category, JPEG-XL and AVIF use around 0.4 bpp, so perhaps you should compare the "very low quality" JPEG with "med-low quality" JPEG-XL and AVIF.
After reading your comment, I assumed you had missed the bpp difference. Please excuse me if I assumed incorrectly.
Keep in mind that lowest JPEG is 3-4x the size of the lowest JXL and AVIF - similar to the size of their "med-low" (top row).
Chromium is not using libjxl, which is the decoder that is evaluated in this article. The SVT encoder is much faster than the AOM encoder for AVIF.
This doesn't use hardware accelerated decoders and encoders.
https://github.com/libjxl/jxl-rs jxl-rs is the underlying implementation. It's relatively new but Rust certainly calms security fears. This library wasn't really an option last time this came around in chromium.
Didn't Google refuse adding JpegXL because they claimed there wasn't enough interest? I don't think they refused out of security concerns but maybe I'm misremembering that.
Google argued that duplicating largely (I know JpegXL does support a bit more, but from most users' perspectives, they're largely right) what AVIF provided while being written in an unsafe language was not what they wanted in terms in increasing the attack surface.
And it really was the right move at the time, imo. JXL however now has better implementations and better momentum in the wider ecosystem and not just yet another image format that gets put into chrome and de facto becomes a standard.
I can confirm. I found multiple problems in the "official" cjxl encoder back in 2023 contrary to the webp2 (cwp2) implementation where I could not find any bug or error.
If the encoder have obvious problems it is not a big deal, but it doesn't bode well for the decoder.
CVE-2023-0645 in libjxl that year too, and several since
It's also a horrible API. Will start working on the rust lib then. Hopefully it's better, because I really want to use it.
https://www.google.com/search?q=what+the+old+man+does+is+alw...
http://hca.gilead.org.il/old_man.html
Aviso: http
Hahaha perfect! Can't believe I never heard this story before.
Forcing other companies to override them is a way to prove momentum but it's not a good way to prove momentum.
> duplicating largely what AVIF provided
That's not a great bar since both of them showed up around the same time. And importantly JXL hits many use cases that AVIF doesn't.
> while being written in an unsafe language
They put little emphasis on that part when they were rejecting JXL. If they wanted to call for a safer implementation they could have done that.
Google 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.
Do you have actual sources for this? Because the other people commenting about how the newer library removes most of the concerns explains this better than an unsubstantiated speculation about promoting AVIF.
If you look at the issue tracker, the creator of Webp killed it because of untrue claims there was no interest or advantages over existing formats.
Concerns about the implementation only came up after years of pushback forced google ton reconsider.
> If you look at the issue tracker, the creator of Webp killed it because of untrue claims
I think for most modern software it's difficult to name the creator, but if you had to for webp, it would be hard to argue that it's anyone but Jyrki Alakuijala, who is in fact one of the co-creators of jpegxl and the person backing up the long-term support of the rust jxl-rs implementation, so I'm not even going to ask for a source here because it's just not true.
AFAIK Jyrki came after WebP was already announced to add lossless support; rather I’d consider Skal the creator inasmuch as it was originally just an image container for VP8 intra. He was working on WebP2 at the time Google rejected JPEG-XL and also was not involved in that decision.
I designed the lossless format and its initial encoder. Zoltán Szabadka wrote the initial lossless decoder.
On2 Technologies had designed the lossy format and its initial encoder/decoder. Skal improved on the encoder (rewriting it for better quality, inventing workarounds for the YUV420 sampling quality issues), but did not change the format's image-related aspects that On2 Technologies had come up with for VP8 video use.
In the end stage of lossless productization (around February 2012) Skal had minor impact on the lossless format:
1. He asked it to have the same size limitations (16383x16383 pixels) like lossy.
2. He wanted to remove some expressivity for easier time for hardware implementations, perhaps a 0.5 % hit on density.
Skal also took care of integrating the lossless format into the lossy as an alpha layer.
>so I'm not even going to ask for a source here because it's just not true.
Well it is up to you to decide. The link was submitted a dozen of times on HN and the whole thing was well reported. And Jyrki Alakuijala already classify its creator status.
It's been 3 years, I might have people mixed up, but that was the justification at the time.
>an unsubstantiated speculation about promoting AVIF.
They deliberately made up a flawed test to show AVIF is better than JPEG XL. When most evidences shows contrary.
Bug tracker where they lied about "not enough interest".
> It's relatively new but Rust certainly calms security fears.
https://github.com/search?q=repo%3Alibjxl%2Fjxl-rs%20unsafe&...
That looks pretty good to me. Every `unsafe` function has clearly stated safety requirements, and every `unsafe` blocks justifies why the requirements are met.
So, I had no reason to use "unsafe" for a very long time, and had developed a bit of an aversion to it. Then I actually needed to use it, first to interface with some C code, and then to deal with a device's mmap'd memory as raw `&[u8]`s.
And my discovery (which basically anyone could have told me beforehand) was that ... "unsafe" rust is not really that different from regular rust. It lets you dereference pointers (which is not a particularly unusual operation in many other languages) and call some functions that need extra care. Usually the presence of "unsafe" really just means that you needed to interface with foreign functions or hardware or something.
This is all to say: implying that mere presence of an "unsafe" keyword is a sign that code is insecure is very, very silly.
> Rust certainly calms security fears
No, memory safety is not security, Rust's memory guarantees eliminate some issues, but they also create a dangerous overconfidence, devs treat the compiler as a security audit and skip the hard work of threat modeling
A vigilant C programmer who manually validates everything and use available tools at its disposal is less risky than a complacent Rust programmer who blindly trust the language
> A vigilant C programmer who manually validates everything and use available tools at its disposal is less risky than a complacent Rust programmer who blindly trust the language
I agree with this. But for a component whose job is to parse data and produce pixels, the security worries I have are memory ones. It's not implementing a permissions model or anything where design and logic are really important. The security holes an image codec would introduce are the sort where it a buffer overun gave an execution primitive (etc.).
Rust programmers are far more likely to have the vigilant mindset than C programmers, or they wouldn't be using Rust.
You can get an awful lot done very quickly in C if you aren't bothered about security - and traditionally, most of the profession has done exactly that.
> A vigilant C programmer who manually validates everything and use available tools at its disposal is less risky than a complacent Rust programmer who blindly trust the language
What about against a vigilant Rust programmer who also manually validates everything and uses available tools at its disposal?
History shows that either vigilance of most C programmers is not enough, or they are not vigilant at all. C/C++ and RCE via some buffer overflow is like synonyms.
> A vigilant C programmer who manually validates everything
So, a fairy-tale character?
I can't believe someone is still using this argument. Is this sarcasm?
I’ve recently compared WebP and AVIF with the reference encoders (and rav1e for lossy AVIF), and for similar quality, WebP is almost instant while AVIF takes more than 20 seconds (1MP image).
JXL is not yet widely supported, so I cannot really use it (videogame maps), but I hope its performance is similar to WebP with better quality, for the future.
You have to adjust the CPU used parameter, not just quality, for AVIF. Though it can indeed be slow it should not be that slow, especially for a 1mp image. The defaults usually use a higher CPU setting for some reason. I have modest infrastructure that generates 2MP AVIF in a hundred ms or so.
I tested both WebP and AVIF with maximum CPU usage/effort. I have not tried the faster settings because I wanted the highest quality for small size, but for similar quality WebP blew AVIF out of the water.
I also have both compiled with -O3 and -march=znver2 in GCC (same for rav1e's RUSTFLAGS) through my Gentoo profile.
Maximum CPU between those two libs is not really comparable though. But quality is subjective and it sounds like webp worked best for you! Just saying though, there is little benefit in using the max CPU settings for avif. That's like comparing max CPU settings on zip vs xz!
rav1e has not had an actual update in performance or quality in years since funding got dropped. Use an encoder like aom, or svt-av1.
I tried both AOM and rav1e, same quality with rav1e producing 20% larger image, same performance more or less (too long)
Other comments here are good, but one thing that's worth pointing out:
Encoding time isn't as important as decoding time since encoding is generally a once-off operation.
Yeah, we all want faster encodes, but the decodes are the most important part (especially in the web domain).
I know, thats why I used max CPU settings. But when processing map tiles with a final total compressed size of half a terabyte, and each one is 200kB, taking 20s per tiles is prohibitively expensive.
It's a shame that JpegXL doesn't have a freely available spec.
You could also say it's a sham to have non-public standards
IIRC it doesn't have a freely available "Final" spec. The Final Draft is available for free.
In general terms, it is a shame that thousands of ISO, IEC etc specifications and documents are behind a paywall.
I'm surprised there hasn't been a Z-Lib/Anna's like movement for spec documents. Given how tech savvy the default audience of those documents are.
For many relevant specs you can find "draft versions" that are essentially the final version without the official stamp on the open web so there isn't that much of a need.
I mean anna's have most specs and if you know where to look there are IPFS and torrent sources for large portions of entire spec libraries.
Yes! The paywalled SQL documents are a big annoyance
From my (limited) understanding, there is still a lot shared between JPEG and JPEG-XL.
I wonder if this new implementation could be extended to incorporate support for the older JPEG format and if then total code size could be reduced.
Not sure why you’re being downvoted… there is an issue open on the JPEG-XL Rust repo for this very feature.
https://github.com/libjxl/jxl-rs/issues/513
Thanks, but just like WEBP I'll try to stick to regular JPEGs whenever possible. Not all programs I use accept these formats, and for a common user JPEG + PNG should mostly cover all needs. Maybe add GIF to the list for simple animations, while more complex ones can be videos instead of images.
You can really treat WebP as a universally available format in 2026. It is an old, boring, and safe format to use now.
Browser support for WebP is excellent now. The last browser to add it was Safari 14 in September 16, 2020: https://caniuse.com/webp
It got into Windows 10 1809 in October 2018. Into MacOS Big Sur in November 2020.
Wikipedia has a great list of popular software that supports it: https://en.wikipedia.org/wiki/WebP#Graphics_software
Unfortunately being universal implies way more than just having good browser support. There are quite a few image processing programs without webp or jpeg-xl support. I'm using Windows 11 and the default image viewer can't even open webp... Also, keep in mind that due to subscription models there are many people stuck with older Photoshop versions too.
You just need this: https://apps.microsoft.com/detail/9pg2dk419drg
Thanks, I know about this and other workarounds. My point is, if it was truly universal you should not need anything! I bet most regular users will never even know this exists.
I never knew about this either and it's been very frustrating as I've been converting my Manga library over to webp (savings are insane) and doing any spot checking opens Edge.
Edit: After reading the comments, this doesn't seem to open in Photos App.
Webp can be really annoying once you hit certain encoding edge cases.
One customer of mine (fashion) has over 700k images in their DAM, and about 0.5% cannot be converted to webp at all using libwebp. They can without problem be converted to jpeg, png, and avif.
Just out of curiosity, what's the problem libwebp has with them? I wasn't aware of cases where any image format would just cross its arms and refuse point blank like that.
We have never been able to resolve it better than knowing this:
Certain pixel colour combinations in the source image appear to trip the algorithm to such a degree that the encoder will only produce a black image.
We know this because we have been able to encode the images by (in pure frustration) manually brute forcing moving a black square across the source image on different locations and then trying to encode again. Suddenly it will work.
Images are pretty much always exported from Adobe, often smaller than 3000x3000 pixels. Images from the same camera, same size, same photo session, same export batch will work and then suddenly one out of a few hundred may become black, and only the webp one not other formats, the rest of the photos will work for all formats.
A more mathematically inclined colleague tried to have a look at the implementation once, but was unable to figure it out because they could apparently not find a good written spec on how the encoder is supposed to work.
Have you reported this bug? It sounds interesting what the authors would say.
No. Our experience with reporting issues in Skia and other such Google libraries has left a bitter impression, so we simply avoid it.
Webp has a maximum pixel dimension size of 16383 x 16383.[0]
[0] https://developers.google.com/speed/webp/faq#what_is_the_max...
"JPEG XL" is a little bit of a misnomer as it's not just "JPEG with more bits". It supports lossless encoding of existing content at a smaller file size than PNG and allows you to transcode existing JPEGs recoverably for a 20% space savings, the lossy encoding doesn't look nearly as ugly and artifacted as JPEG, it supports wide gamut and HDR, and delivers images progressively so you get a decent preview with as little as 15% of the image loaded with no additional client-side effort (from https://jpegxl.info/).
It is at least a very good transcoding target for the web, but it genuinely replaces many other formats in a way where the original source file can more or less be regenerated.
Honestly, I don't like how webp and now jpegxl support both a lossless and lossy mode.
Let's say you want to store images lossless. This means you won't tolerate loss of data. Which means you don't want to risk it by using a codec that will compress the image lossy if you forget to enable a setting.
With PNG there is no way to accidentally make it lossy, which feels a lot safer for cases you want lossless compression.
PNG can and is often used in a lossy way. Reducing the number of colors so PNG8 can be used instead of PNG24/PNG32 is the most common way to do that. Tools like pngquant exist, and for example Photoshop when exporting to PNG also has an option to reduce the colors, to flatten the image (remove alpha), or to change the colorspace.
16-bit PNG files can easily accidentally be reduced to 8-bit, which is of course a lossy operation. Animated PNG files can easily get converted into a still image (keeping only the first frame). CMYK images will have to be converted to RGB when saving them as PNG, which is also a lossy operation. It can happen that an image gets created as or converted to JPEG and then gets saved as PNG - which of course is a bad and lossy workflow, but it does happen.
So I don't agree that with PNG there is no way to accidentally make it lossy.
In any case: lossless or lossy is not a property of a format, but of a workflow. For keeping track of provenance information and workflow history, I would recommend looking into JPEG Trust / C2PA, which is a way to embed as metadata what happened to an image since it was captured/generated. Relying on the choice of image format for this is fragile and doesn't allow expressing the nuances, since reality is more complicated than just a binary "lossless or lossy".
You can use too few bits of color depth to get lossyness in PNG. More generally, I can't find myself very sympathetic to "I don't want a format that can do X and Y, because I might accidentally select X when I want Y in my software". You might accidentally choose JPG when you want PNG too. Or accidentally resample the image. Or delete your files.
If you want a robust lossless workflow, PNG isn't the answer. Automating the fiddly parts and validating that the automation does what you want is the answer.
Taking a look at the reference codec package at https://gitlab.com/wg1/jpeg-xl, they note:
> Specifically for JPEG files, the default cjxl behavior is to apply lossless recompression and the default djxl behavior is to reconstruct the original JPEG file (when the extension of the output file is .jpg).
You're right, however, that you do need to be careful and use the reference codec package for this, as tools like ImageMagick create loss during the decoding of the JPEG into pixels (https://github.com/ImageMagick/ImageMagick/discussions/6046) and ImageMagick sets quality to 92 by default. But perhaps that's something we can change.
You should never use GIF anymore, it is super inefficient. Just do video, it is 5x to 10x more efficient.
https://web.dev/articles/replace-gifs-with-videos
There's odd cases where it still has uses. When I was a teacher, some of the gamifying tools don't allow video embeds without a subscription, but I wanted to make some "what 3D operation is shown here" questions with various tools in Blender. GIF sizes were pretty comparable to video with largely static, less-than-a-second loops, and likely had slightly higher quality with care used to reduce color palette usage.
But I fully realize, there are vanishingly few cases with similar constraints.
For those you can often use animated WebP, or even APNG. They all have close to universal support and are usually much smaller.
If you need animated images in emails or text messages, GIF is the only supported format that will play the animation. Because of the size restrictions for these messaging systems the inefficient compression of GIFs is a major issue.
I am not sure "need" is the right word here.
AVIF works here also. Discord started supporting it for custom emoji.
Videos and images are treated very differently by browsers and OS:es. I'm guessing the better suggestion would be to use apng or animated avif if you are looking for a proper gif alternative.
Do browsers support progressive enhancement from gif to animated avif without javascript? The royally messed that up for animated webp.
Yes, by using the <picture> element with <source> elements declaring the individual formats with the last one being a regular <img> with the gif.
Or you could use content-negotiation to only send avif when it's supported, but IMO the HTML way with <picture> is perhaps clearer for the client and end user.
I think the webp problem was due to browsers supporting webp but not supporting animation, transparency or other features, so content negotiation based on mime types (either via <picture> or HTTP content-negotiation) did not work properly. Safari 16.1-16.3 has the same problem with AVIF, but that is a smaller problem than it was with webp.
So I guess that's a no - avif support does not necessarily mean animated avif support.
I covered this in my comment:
> Safari 16.1-16.3 has the same problem with AVIF, but that is a smaller problem than it was with webp.
Unfortunately browser vendors didn't want to support silent looping videos in <img> tags so gif stays relevant.
only if looping information is stored inside the container.
So is this another image format I'll download and be unable to use without converting because nothing supports it a la .webp?
What do you think doesn't support it?
Affinity supports it. Photoshop supports it. Microsoft Photos supports it. Gimp supports it. Apple has had systemwide support for it since iOS 17+ / macOS 12+, including in Safari and basically any app that uses the system image functions.
Chromium isn't on the bleeding edge here. They actually were when it first came out, but then retreated and waited, and now they're back again.
Half the point of JPEG XL is support for HDR and higher than 8 bits per channel. Most of the apps you listed don’t support that fully, especially iOS, which converts everything to SDR or shows garbage — except for their own proprietary gain map encoding that their camera app produces.
Actually, in my recent vibe coding adventures I tested making a ProRAW converter app that also applied the included gain map to the image and encoded via libjxl on device. Surprisingly, Photos.app was able to display the converted image with HDR, but the HDR tag in the UI is only displayed for images with the proprietary gain map.
There seems to be some support there, though I tested on iOS 26.
Yes, but you can't send that to anyone via iMessage. It corrupts the image.
That I of course didn't test. Yeah, I'd expect them reencoding images to save on bandwidth, and they're probably doing so naively for JXL (maybe even converting to HEIC).
> That I of course didn't test.
Neither did Apple, which is the problem!
Lots of stuft still doesn't support it, for example WhatsApp and Discord.
WhatsApp doesn't even support WebP though. Hopefully, if they ever get around to adding WebP, they'll throw JXL in, too.
Discord certainly supports it (on web and desktop client). I've been able to upload high resolution WebP images for at least a year now.
Yes, just like any new format, there's going to be an adoption period of about a decade before it reaches "ubiquitous-enough" support.
Use better software - ideally open source software so that in the worst case you can just add support yourself.
I mean even Microsoft (that Titan of Lightning-Fast Development) has implemented a JPEG XL add-on, so now that Google's giving up the ghost, i think JPEG XL has a real chance.
https://apps.microsoft.com/detail/9MZPRTH5C0TB?hl=en-us&gl=U...
Only for win11
I've been hearing about fights over JpegXL and WebP (and AVIF?) for years, but don't know much about it.
From a quick look at various "benchmarks" JpegXL seems just be flat out better than WebP in both compression speed and size, why has there been such reluctance from Chromium to adopt it? Are there WebP benefits I'm missing?
My only experience with WebP has been downloading what is nominally a `.png` file but then being told "WebP is not supported" by some software when I try to open it.
Most of the code in WebP and AVIF is shared with VP8/AV1, which means if your browser supports contemporary video codecs then it also gets pretty good lossy image codecs for free. JPEG-XL is a separate codebase, so it's far more effort to implement and merely providing better compression might not be worth it absent other considerations. The continued widespread use of JPEG is evidence that many web publishers don't care that much about squeezing out a few bytes.
Also from a security perspective the reference implementation of JPEG-XL isn't great. It's over a hundred kLoC of C++, and given the public support for memory safety by both Google and Mozilla it would be extremely embarrassing if a security vulnerability in libjxl lead to a zero-click zero-day in either Chrome or Firefox.
The timing is probably a sign that Chrome considers the Rust implementation of JPEG-XL to be mature enough (or at least heading in that direction) to start kicking the tires.
> The continued widespread use of JPEG is evidence that many web publishers don't care that much about squeezing out a few bytes.
I agree with the second part (useless hero images at the top of every post demonstrate it), but not necessarily the first. JPEG is supported pretty much everywhere images are, and it’s the de facto default format for pictures. Most people won’t even know what format they’re using, let alone that they could compress it or use another one. In the words of Hank Hill:
> Do I look like I know what a JPEG is? I just want a picture of a god dang hot dog.
https://www.youtube.com/watch?v=EvKTOHVGNbg
I'm not (only) talking about the general population, but major sites. As a quick sanity check, the following sites are serving images with the `image/jpeg` content type:
* CNN (cnn.com): News-related photos on their front page
* Reddit (www.reddit.com): User-provided images uploaded to their internal image hosting
* Amazon (amazon.com): Product categories on the front page (product images are in WebP)
I wouldn't expect to see a lot of WebP on personal homepages or old-style forums, but if bandwidth costs were a meaningful budget line item then I would expect to see ~100% adoption of WebP or AVIF for any image that gets recompressed by a publishing pipeline.
It’s subsidized by cheap CDN rates and dominated by video demand.
Any site that uses a frontend framework or CMS will probably serve WebP at the very least.
JpegXL and AVIF are comparable formats. Google argued you only needed one, and each additional format is a security vulnerability.
And more importantly, an additional format is a commitment to maintain support forever, not only for you, but for future people who implement a web browser.
I can completely see why the default answer to "should we add x" should be no unless there is a really good reason.
JPEG XL has progressive decoding
https://www.youtube.com/watch?v=UphN1_7nP8U
- avif is better at low bpp (low-quality images), terrible in lossless
- jxl is better at high bpp, best in lossless mode
It was an issue with the main JPEGXL library being unmaintained and possibly open for security flaws. Some people got together and wrote a new one in Rust which then became an acceptable choice for a secure browser.
Unmaintained? You must be mistaken, libjxl was getting a healthy stream of commits.
The issue was the use of C++ instead of Rust or WUFFS (that Chromium uses for a lot of formats).
It’s largely the same people.
> various "benchmarks" JpegXL seems just be flat out better than WebP
The decode speed benchmarks are misleading. WebP has been hardware accelerated since 2013 in Android and 2020 in Apple devices. Due to existing hardware capabilities, real users will _always_ experience better performance and battery life with webp.
JXL is more about future-proofing. Bit depth, Wide gamut HDR, Progressive decoding, Animation, Transparency, etc.
JXL does flat out beats AVIF (the image codec, not videos) today. AVIF also pretty much doesn't have hardware decoding in modern phones yet. It makes sense to invest NOW in JXL than on AVIF.
For what people use today - unfortunately there is no significant case to beat WebP with the existing momentum. The size vs perceptive quality tradeoffs are not significantly different. For users, things will get worse (worser decode speeds & battery life due to lack of hardware decode) before it gets better. That can take many years – because hey, more features in JXL also means translating that to hardware die space will take more time. Just the software side of things is only now picking up.
But for what we all need – it's really necessary to start the JXL journey now.
> Due to existing hardware capabilities, real users will _always_ experience better performance and battery life with webp.
Extra data transfer costs performance and battery life too.
Where can I learn more about hardware acceleration of WebP on mobile OSes? I haven’t yet come across a resource that confirms this is actually the case. I know it should theoretically be possible using the VP8 hardware decoders but I thought those were expensive to warm up just for images
1 black pixel of .webp is smaller than 1 black pixel of .jpegxl that is also smaller than 1 black pixel of .png
so webp > jpegxl > png
Google created webp and that is why they are giving it unjustified preferential treatment and has been trying to unreasonably force it down the throat of the internet.
WebP gave me alpha transparency with lossy images, which came in handy at the time. It was also not bogged down by patents and licensing. Plus like others said, if you support vp8 video, you pretty much already have a webp codec, same with AV1 and avif
Lossy PNGs exist with transparency.
PNG as a format is not lossy, it uses deflate.
What you’re referring to is pngquant which uses dithering/reduces colors to allow the PNG to compress to a smaller size.
So the “loss” is happening independent of the format.
Do you mean lossless? PNGs are not lossy. A large photo with alpha channel in a lossless png could easily be 20x the size of a lossy webp
PNG of course can be lossy. They aren’t great at it, but depending on the image can be good enough.
No I meant lossy. This is the library I use; https://pngquant.org/
Pre-processing does not a codec make (this is why .gif is considered lossless even though you lose all that 24-bit colour goodness)
Fair enough but it gets the job done well none the less.
unjustified preferential treatment over jpegxl a format google also had created
They helped create jpegXL but they are not the sole owner like they are with webp. There is a difference.
a better argument might be that chrome protects their own vs a research group in google switzerland, however as other mentioned the security implications of another unsafe binary parser in a browser is hardly worth it
Webp has had major vulnerabilities.
https://blog.cloudflare.com/uncovering-the-hidden-webp-vulne...
which only strengthens my argument, webp seemed like some ad-hoc pet project in chrome, and that ended like most unsafe binary parsers, with critical vulnerabilities
> webp seemed like some ad-hoc pet project in chrome
FWIW webp came from the same "research group in google switzerland" that later developed jpegxl.
You're getting downvoted, but you're not wrong. If anyone else had come up with it, it would have been ignored completely. I don't think it's as bad as some people make it out to be, but it's not really that compelling for end users, either. As other folks in the thread have pointed out, WebP is basically the static image format that you get “for free” when you've already got a VP8 video decoder.
The funny thing is all the places where Google's own ecosystem has ignored WebP. E.g., the golang stdlib has a WebP decoder, but all of the encoders you'll find are CGo bindings to libwebp.
I noticed Hacker news is more about feelings than facts lately which is a shame.
Why does the current design paradigm in image coding formats emphasise supporting as many features as possible in order to have “one image format to rule them all”? You do not see this in audio and does anybody think that Opus and FLAC should be combined into one format? Does the fact that Opus does not support lossless encoding make it worse?
From a user perspective it is nice to know that the person decoding will likely support a given format, both now and in the future.
More use cases for a single popular format makes this more likely.
Reading the feature list of JpegXL on Wiki, it includes some interesting stuff like arbitrary numbers of channels for multi-spectral imaging and multi page documents, which for both better and worse starts to sound a lot like TIFF.
Anyone knows if their implementation supports animations? This is a feature missing from Apple's
According to the chrome platform status page, yes! https://chromestatus.com/feature/5114042131808256
>>>
Yes, but it's not recommended - it does not have inter-frame compression, so it is significantly less efficient than just having a regular video file and slapping 'gif' on it.
That's not strictly correct, it's rather that the current encoder does no inter-frame compression. Patches (and the frame system in general) does give tools to do some inter-frame compression (not as many as in video, but still quite expressive), just nobody stepped up to implement compression using them for animations yet.
Video files are not supported in <img> tags.
Do you know of a video format that supports progressive decoding?
Progressive decoding isn't a very useful video feature because you need to decode the whole frame before you decode the next frame for inter-frame coding methods anyway.
It is, however, a very useful image format feature, giving you most information from the spinner/sticker/emoji/sprite, and refinig the already playing loop as it loads. That's why animated jxl is a bad video format — it's not a video format, it is a separate kind of seemingly weird thing.
It does, I just tried it in Canary and the jxl test page did also show animations
What, isn't this the cue for someone to explain that it's ironic webp is really a video format which is a bad image format, and now we have symmetry that JpegXL is a good image format which is bad video format? :-D
(I don't know if any of this is true, but it sounds funny...)
Webp is also an incredibly bad animation format since it drops most of the inter-frame compression features of the video codec it was derived from.
[dead]
Unfortunately, with Chromium dropping support for manifest-v2 extensions, and through that dropping proper support for uBlock Origin, I'm moving away from it. Not that that's easy, of course...
With Chrome being by far the most popular browser, it gaining support is almost a precondition for jxl gaining traction on the web. Few would bother converting their images for Safari (and when it becomes enabled without a flag Firefox). So this is good news even for people who don't use Chromium.
[dead]