The case against JPEG XL(giannirosato.com) |
The case against JPEG XL(giannirosato.com) |
That JXL page happens to use two passes, but the knobs are there to customize the experience to fit the use case.
This is false. AVIF does not support progressive decoding/rendering. What the author is referring to here is image layering. A lower resolution image layered below the full resolution image, which is loaded and rendered first. That is not progressive decoding/rendering. It is a thumbnail.
Unlike AVIF's false advertising, JXL truly supports progressive decoding/rendering. With JXL, you do not first load a thumbnail before loading the actual image. The lower-quality image that JXL shows while decoding is derived from the data of the actual, full-resolution image.
I'm curious, where did you learn progressive AVIF works like this? Have you actually read the spec, or does your understanding comes from somewhere/someone else and never challenged the truthfulness of it? Progressive AVIF is truly "progressive" -- it never involves "loading a thumbnail" or "layering an image over another".
In reality, each pass (up to 4) can refine previous ones (thanks to AV1's inter-encoding toolset), avoiding storing redundant information between passes. The viewing environment doesn't need to render a given pass if a subsequent one has already been downloaded. Finally, scaling is configurable -- you can have your first pass already be at full res, just at a lower quality.
Hope this helps clarify how progressive AVIF actually works under the hood.
Unlike a thumbnail, higher-resolution layers can be predicted from the lower-resolution layer, so those bits are not wasted. That is not possible by layering <img> elements.
Yes, the format is not inherently progressive. But having the fine steps in progressive quality that JPEG-2000 and JPEG-XL have has less general usefulness than the amount of words complaining about it.
If layering to <img> elements is fine for your use case, then it simply means you have no need for progressive decoding.
The preview in finder is still going to block. Im saying this as a MAC user speaking of experience browsing mounted drives that sometimes are slow and it feels like the window freezes up.
Preview actually does use progressive rendering for large enough images, even from SSDs. You can tell because opening an image will be blurry for several seconds, even when the full size image could have been decoded in a quarter second or less.
Computers should not be making images look worse than they were captured. It's not 1996 anymore. We don't need to be doing this at all.
Most of the people I know only have the mobile connection, pay a lot for the privilege, and while speeds are generally good (LTE and up), the monthly cap for almost all of them is 10-20 GB.
Original image (JPEG): 3072×4080, 2.6 MB. Transcoded to JPEG XL: 2.1 MB.
To display at 2x density on my web page, it would be 1598×2122.
Lossless JPEG XL: 2.5 MB. Web-quality JPEG XL: 93 kB. Web-quality AVIF: 70 kB.
It still seems worth it.
Normal people don't pick an image format based on whether it is suitable on the web or not. They want a format that works everywhere. If I download or upload a photo I don't want to have to do a lossy format conversion. If I'm writing an image processing tool it would be great if I can make it just support one input format that everyone uses, rather than "web" formats and "non-web" formats.
So I think a large part of the attraction of JXL is that it is a single format that works both for 10000x10000 lossless scientific images, and for 256x256 lossy web photos. You don't have to be an image format expert any more. Just always use JXL.
Definitely a shame about the technical flaws listed here though - especially decode time.
As the article identifies, JPEG XL is kinda bad at certain types of images, whereas AVIF does well across the board, so if you feel compelled to pick a single format to use, AVIF would be a better choice, but it's definitely worth optimising your web images for the web.
Also, JPEG XL is two codecs bundled into one, VarDCT and Modular. So, even if you're picking JPEG XL as "the one codec", you're actually picking two, and you need to choose between them at encode time.
That's an internal detail that doesn't really matter to anyone outside library implementors, or when you're choosing encode settings though.
It's the same in Opus. Technically it's two formats, but as long as they're one entity that's either supported or not supported, everything is good.
AVIF does seem to have at least a couple of downsides compared to JXL like max 12-bit depth, no JPEG reencode and worse recompression stability. I think they probably could have added those though, and then we wouldn't have yet another format to support for eternity. Oh well, they had their chance.
Backwards compatibility is cool; stop the fucking churn! I have done this just within this past week, in fact, when I moved a JPG over to my Mac OS 7.6.1 machine (PowerBook 2400c!) to use as a new desktop wallpaper†.
† Via Décor https://macintoshgarden.org/apps/decor
E.g. for official Windows support by Microsoft you need to buy the codec from the Microsoft App Store for $0.99
There is still a lot of reason for Apple to switch from HEIC to JXL for photos going forward since HEIC is patent encumbered so it will never see widespread use.
I don't want an image to appear in any form until its loaded. I never need to see a blurry placeholder, and there is zero value in that even with bad connections, but the situation is farcical when everyone has ultra-fast connections everywhere.
This is similar to pages that use custom fonts but will happily show the text as quickly as it can, and then suddenly restyle/relayout the page when the custom font loads (Flash of Unstyled Text - FOUT). It looks terrible and is jarring. Progressive rendered images are the same.
I'm not talking about blurhash here - those are 'cute' at best. I'm talking about previews that let me determine the subject of an image.
I was on a train recently and an image preview X delivered to me was enough for me to tell that the image was a particular meme format, and thanks to context, I knew enough about the image, and didn't bother waiting for it to load.
Are you the author of the submission? Literally never seen someone so motivated in a conversation before.
> JPEG recompression is the ability to losslessly re-encode JPEGs as JXL images while saving bits; the oft-cited number is 20% savings. However, the user pays for this in decode time, as recompressed JPEGs take ~33% longer to decode
> It cannot be worth bringing a new image codec to browsers to save 12%
What? 12% is huge.
AVIF's "royalty-free" is under active legal attack (Dolby v. Snapchat). JXL has clean ISO commitments so no such suit would be possible. If "free" matters, JXL is safer.
Perceptive quality with the latest AV1 caught up, but that's a rigged timeline. Chrome supported JXL "late", then pulled it altogether. AVIF did improve further yes, it had web usage, it was behind when the race was meant to start. Why would JXL continue to optimize for web once the major browser refuses to support it.
It is Google. The JPEG XL standard evolved from a codec Google made, Google was involved in the standardization process, and Google heavily contributed to the reference implementation of JPEG XL.
https://ds.jpeg.org/whitepapers/jpeg-xl-whitepaper.pdf
Editors:
Jyrki Alakuijala – Google, Switzerland
Jon Sneyers – Cloudinary, Belgium
Luca Versari – Google, Switzerland
Jan Wassenberg – Google, SwitzerlandIt seems quite limited compared to the JPEG XL ability to truncate the bitstream anywhere, or send the progressive updates for salient regions first [1].
[1]: https://opensource.googleblog.com/2021/09/using-saliency-in-...
Imagine fast scroll across an image gallery on a slow connection (including cell handovers).
Or range requests, where a service worker only downloads the header+preview portion, and when clicking on the image, no need to re-download that.
Or even a browser that truncates all images, to protect users who might visit a page with huge background images that blows through their prepaid data plan.
JPEG XL anticipated, and accommodates, these use cases.
Plenty of websites already have comically huge pointless images (often then scaled down to tiny sizes for display). No need to make the problem worse.
I am not the author of the submission. I have experience in web performance, and my comments come from that experience.
Chrome's team should be blamed for favoring AVIF over JPEG-XL, not Google entirely.
And in the cached cache, the bandwidth saving is gone, and you're still paying the decoding penality.
Maybe a lossless re-encoding of my website JPEGs to gain 20% size is not worth the 33% longer decode, and maybe the website doesn't need very high resolution images or more than 12 bits per channel. But my personal archives can definitely use that and it's great that such files can be viewed everywhere without specialized tooling, including served on the intranet and indeed the Web.
In summary JPEG XL easily beats AVIF on the not-so-long tail of use cases and having compatible viewers everywhere is quite useful. And with JPEG XL becoming part of PDF, it will soon be common use cases too.
As for the rest of the article: there are interesting points in the benchmark section but I think it's too early in the JPEG XL adoption cycle to draw conclusions. One thing bothers me though: There is a single picture comparison (with tag line "results speak for themselves") and I find it quite misleading: it's just picking one point on the "bytes received" line that looks best for AVIF compared to JPEG XL. Try it yourself and you'll see JPEG XL shows something already at 2KB while AVIF has nothing until 8KB, and JPEG XL looks better than AVIF after 100KB.
I value integrity, especially when communicating results. This is shameful.
(Disclosure: I worked on JPEG XL)
“For progressive, I think it's better to show the user something that's obviously a preview, but still has enough detail to be able to know what the picture is of. If you're showing the user something that they may mistake for complete but poor quality, that's a bad experience.”
-jaffathecafe
If you're showing the user something that they may mistake for complete but poor quality, that's a bad experience.
And that comparison was made for a JPEG-XL focused site, and uses quite large images that are then scaled down dramatically (at least on mobile) for display which is probably not an ideal visual test anyway (but possibly necessary for there to be enough time to see any difference)
I was unpleasantly surprised when jxl's reference encoder dropped critical exif tags for no reason whatsoever from my personal archives. Turns out their lossless preset wasn't really lossless.
And then webp to JXL conversion also produced different viewing experience results as ffmpeg's webp decoder wasn't handling ICC correctly.
I'm now very cautious of any "lossless" re-encodes.
It's bizarre. I've never seen a format see such ridiculous attacks.
I changed all my .jpg files to .avif a few years ago. The benefit I get is much more than 20%. Now there is some loss when I use high compression with .avif, in particular via gimp - but other than that, I gained a lot of file size here, definitely much more than 20%. It also depends on the image at hand; I noticed that images with a ton of details, such as if you photograph a garden, takes more space. But for simpler images, I have easily gains of about 60% or 70% compared to jpeg, with no or almost no loss in quality. Whereas if I were to use jpeg compression, the quality loss would be insanely high. When I noticed this, I decided to abandon .jpg for my own use cases. I had to choose back then between avif and webp and while webp is fine, I found .avif was slightly better for the use cases I had.
I don't quite know how much jpeg xl performs, but you mentioned JPEG so I had to comment on that 20% statement as I found it way too low.
I also find the claim "longer decode" not correct. I have some photographs of gardens and the file size is huge, in JPG. When I compressed and changed these into .avif, the resulting page loads soooooooo much faster now when having used avif and a considerable but acceptable compression of it. It is just no comparison at all - avif beats jpg with its eyes closed.
And pray tell how much of the waiting for page is used on decoding image (vs transferring) and how much faster the image gets on the machine when it's 20% smaller on average connection?
My guess is that time saving from bandwidth decrease more than compensates for that
And if you're displaying a cached image, the bandwidth use is zero, but the decoding still happens.
Moreover, there are some methodological oddities. For example, JPEG XL decoding is tested in single-threaded mode when it's optimized for multi-threaded decoding (where AVIF has artifacts from tiling). Also, the tested command is "jxl_cli --speedtest", which means that the benchmarked time includes the warm-up procedure of the "--speedtest" flag, rather than the pure decoding time.
Another example of this is progressive rendering, where the comparison moment is chosen at a local maximum that favors AVIF. JPEG XL materializes a full frame much sooner than AVIF, and starting at, say, the 96,256 B mark, it looks better than AVIF until the full image is loaded.
Also, good lossless compression absolutely does matter for the web as well. Lossy images just cannot be used in all circumstances - like when comparing compression quality (especially of videos), for example!
EDIT: To give an additional example, pixel art is an entire field of art (which is very much still active today) where both lossless compression is a must and where 4:2:0 would be absolutely catastrophic for quality.
This is a good paragraph. I see people forget to apply that last sentence all the time.
It is, however, an incredibly cool demo of what the format is capable of. I'm not completely sure if an image format should be that flexible, but I'm impressed nonetheless.
That considered, I don’t think it’s a fair comparison between the codecs. JPEG XL used to be far more impressive than AVIF; it’s great people (author included) have managed to push AVIF forward, but until similar efforts have been made for JPEG XL in earnest, I don’t feel like a comparison between their encoders says much about the codecs themselves. The author does take a guess on how much the JXL encoder could be improved, but that’s just that: a guess. It won’t be know until it’s been tried. And especially given the whole unfortunate history, I think JPEG XL really, really deserves a try.
The post downplays the usefulness of versatility. I disagree. I'd prefer not to play the "which image format is best for this image and this use case" game and having to transcode between them. For instance, it would be great if I could have an HTML gallery showing pictures of my files as I store them on harddisk. Today these are JPEG, because it's the lowest common denominator. WEBP, AVIF are not supported photography tools (e.g. https://support.captureone.com/hc/en-us/articles/36000262921...) and I don't expect support to ever be added since it is not formats intended for photography.
It would be great if their behavior could be customized in a more modern web-friendly way, like "Save the original photo as a 95% quality AVIF in this folder, and also as an 70% quality resized WebP in this other folder".
1) AVIF has now been radically improved to the point where it's actually quite good in ways that previously it was not.
2) JXL will not be improved despite the fact that the performance of every other codec has always radically improved over time.
Everything else aside, including a few clear methodological errors, it's ahistorical and unsightly to be unwilling to imagine that future implementation effort will accomplish anything. Some might call it hypocritical.
The entire post amounts to saying "JXL in its first iterations was better than AVIF's more advanced state of development and support, but AVIF very recently got better only after several years of widespread adoption, and I don't think JXL would too".
The arguments given against JXL cannot be reconciled with the history of codec development.
That said, I have converted my personal JPEGs to JPEG XL, because you can losslessly convert back and forth between the two for smaller filesize in JPEG XL with no quality loss, so I get free storage savings and can get the byte-for-byte original JPEG back if I need it.
So you can relatively easily replace the second stage with something better. And since it's lossless you can easily go back.
Dropbox[1] and others have exploited this for reducing storage requirements, converting back on-demand so the client doesn't notice.
Because of it, for the past couple of years, all new iPhones and almost all Android phones (mostly Samsungs) already contain a JPEG XL encoder / decoder (to generate these DNGs).
- it's first image is way earlier: 2KB vs 8KB
- from 8KB to 100KB it's blurrier than AVIF, but it's more pleasing to look at and less blocky than AVIF. I highly prefer it.
- from 100KB until finished 288KB it's actually ~4x sharper than AVIF
Overall JpegXL gives the much nicer experience.
^ tested with pokebowl (https://jpegxl.info/resources/progressive-loading-demo.html)
For Lossless: JPEG-XL wins, then WEBP, then PNG. (Sometimes lossless WEBP wins)
For Lossy: AVIF wins, then JPEG-XL, then WEBP, then JPEG.
Also, look at the graphs – Iris-WebP beats JPEG XL.
Lossless JPEG XL is in the DNG spec since three years (v1.7). So, you can convert your proprietary camera raw files to smaller ISO standard compliant JPEG XL compressed DNG raw files (mosaiced, not linearized).
Unfortunately, at least as of perhaps a year ago, I couldn't find any other actively maintained software tooling that could reliably do what Adobe's DNG Converter was doing, and there's so much nuance to the world of RAW files that's not at all just a trivial one-shot prompt to Claude/Codex to roll your own.
Not linearized as in samples do not represent linear color space? I think that's untrue, as all sensor work I've done (a decent amount across many projects) are linear: double light = double photon count = 1 bit of sensor space. There are technically often some bends from physical and engineering effects (photon interaction with substrate has some variability, temperature affects things a bit).
Or is there some other meaning of "not linear" you mean?
- dimensions
- filetype
- minimum required decoder version
- lossless: true/false
- a list of alternative URLs and mimetypes to older image formats
Then any future image format is a simple drop-in without requiring complex processing on the server side or a lot of complexity in HTML (not to mention CSS)
Browsers are new OSes.
There is no any «web» anymore. E-mail clients are web, news readers are web, image galleries are web, heck, even image editing software could be web (google:photopea).
And as such there should not be «web-optimized» formats anymore.
> it was hard enough to get widespread WebP adoption
That's not a coincidence! And because these newer codecs are better outside the Web, it's not really "the same hill"
This is not a coincidence, but I don't think it was that devs looked at WebP and thought "huh, the lack of 4:4:4 and 10-bit support makes this less compelling for our product despite being all over the internet" – I think it was just a matter of not keeping up. Except for Apple, not sure why they took so long to implement it.
It's very hard to beat the encoding performance of libjpegturbo, even with an asic.
Those scenario amount to epsilon percent of scenarios, though, so it makes sense to ignore them most of the time.
Pretty much any platform with a hardware jpeg encoder beats libjpegturbo. So probably all smart phones, large scale CPUs, even tiny few $ microcontrollers like ESP32's have hardware encode/decode that outperforms libjpegturbo.
What does it offer there that existing workflows can’t support? Do those advantages make up for the transcoding that every web publisher would need to do to make the outputs useful on the web?
That’s huge, no?
The JPEG XL report [1] measured between 240-270 Megapixels/s on 6 cores using the C++ implementation (disclosure: I was responsible for its SIMD/threading), about twice as fast as the then-current libaom.
Measuring on a single core is deeply misleading because our code was designed to scale well. I believe AVIF requires tiling in order to parallelize, which causes artifacts at tile boundaries.
Source: I lead Mozilla's technical contributions to AV1.
What exactly is "Fruit Company's format"?
> Not to mention an additional compatibility headache now exists for anyone just trying to download an image from the Internet and use it somewhere – it was hard enough to get widespread WebP adoption, and I don't think it's worth doubling the pain by having to climb the same hill for AVIF and JPEG XL. Especially when JPEG XL doesn't appear to add anything to the Web platform.
It is very annoying downloading an image for the web and then trying to upload it somewhere else also on the web during these transition periods.
But then less stuff fits in my cache, so I'm transferring even more data.
Also, not everybody has unlimited/unthrottled data plans. I really wish websites would respect my resource tradeoff preferences at least somewhat.
When on celular, even 5g, I am pretty often below that.
Taking bike.jpg and bike-repackaged.jxl in that demo, on my Pixel 10 Pro in Firefox Nightly, the size and decoding times are:
bike.jpg - 147 kB - 10ms
bike-repackaged.jxl - 126 kB - 33ms
So, I save 21 kB, but pay 23ms.
That extra 21 kB isn't part of a new request, so when it comes to download performance, we're talking about an active response. At 3g speeds, in 23 ms you can download somewhere between 20-118 kB, so at best, it evens out.
If it's a lower end device, the decode delta increases. If it's a faster connection, the 21 kB saving matters less. If the image was cached, then I'm just paying the decode overhead.
All that to say, "I save 21 kB, but pay 23ms"? You'll save more if you stop sending your favourite web font over with your page and use the system fonts, and trim down your site's JS.
The post literally goes over known ways that JXL can be improved. The actual argument (and this is stated!) is whether those improvements will be enough to make JXL compelling to use for the web vs. other established formats (quality efficiency, encode/decode time, progressive loading, etc).
Also, don't assume AVIF or even WebP have maxxed out yet :) There are known ways to improve those two too!
Because it's understandable that you'd be defensive in the comments here, but you're not being honest about what's written.
> The post literally goes over known ways that JXL can be improved.
You think so? Let's name them, yes? Ok, I'll go first:
* Splines. Explicitly derided as "vastly more difficult" and "I have no reason to believe they'd be better anyway".
Now you point out the next one.
You see, any unfilled area is specifically mentioned only to dismiss it as meaningless. Meanwhile, out of the other side of your mouth, you say "don't assume AVIF or even WebP have maxxed out yet". Sure. I don't. I'm not the one doing that. I'm just the one pointing out the hypocrisy of approach.
The entire argument trajectory is "this path is good, that path is bad, this one will naturally get better, that one surely won't get better enough", and the primary evidence given is deceptively inapt.
A redeeming outcome is that with AVIF's new image tuning modes (both in libaom and SVT-AV1), Gianni and I managed to utilize as many AV1 coding tools as possible, including QMs that sorely needed a well-deserved spotlight.
Also, thanks for paving the way to the current state of multimedia compression! I'm a longtime fan of Xiph(ophorus) since the 1.0 beta/RC Vorbis days. We used your image sets a lot during our testing.
JPEG-XL offers all the benefits of HEIF and more, while not being patent encumbered.
I'm also thinking the OP meant HEIC, but I know that it is not proprietary (though as noted patented), and wanted to make sure, as a lot of people of all sorts of assumptions/misconceptions about Apple.
HEIF/HEIC is based on H.265, so not Apple-only as Android supports it. (Recent Sony, Canon, Nikon, etc cameras all support the format as well.)
https://www.dpreview.com/articles/8980170510/how-hdr-tvs-cou...
> HEIF/HEIC is a broad standard, and the files from Canon and Apple are not cross-compatible with one another
AVIF does not have artifacts from tiling any more than JPEG XL has artifacts from being JPEG XL; if you read the details post at the bottom, you'd see there's a 0.5-1.0% BD-rate regression with tiles, which is effectively a rounding error.
For progressive, JXL shows a blurry mess for the majority of its decode, while AVIF shows a crisp image that clearly shows what is in the image. Go ahead and try the demo yourself! AVIF also supports more than one layer, but I used Team JXL's image on purpose to show that even there, AVIF looks better for 90% of the decode time. You need to watch what I'm showing you instead of adopting the most bad-faith reading because some things are mentioned.
I'm not sure I agree? IMO after about 30% most images look better on JXL than on AVIF, the exceptions being the pigeon, which looks better on JXL after 43% (still less than half) and the sunflower, which looks better on 66% (but you can clearly see what's on the image a lot earlier). Also, blurry convey better the idea of loading and the AVIF version may have some weird artifacts / look weirder (although that's subjective), for example the Quechua woman's eyes are very distorted on the progressive AVIF and, on the Poke bowl, some of the seeds on top of one of the top radish pieces are kind of missing / look like a shadow (while other seeds of the same size appear). In contrast the JXL version is usually blurrier and less saturated at the beginning but is more "uniform/reliable" (distorts all of the "objects" more or less the same), and later it looks finished but actually isn't (which may be a problem on its own).
I have seen AVIF tiling artifacts myself. Hand-waving them away by appealing to a metric that averages across all image pixels is not convincing.
- The inclusion of his two proprietary encoders (Aperture and Iris) just serves to further support the argument that JXL encoder devs have work to do to perform at the frontier, while also proving you only need a person or two to do so. The two FOSS AV1 encoders in the compo (libaom and SVT-AV1) are enough to prove this. Given that blog posts often double up as a way to show-case projects, I think it's fair game to show off a bit. Also, keep in mind Gianni is just 21 and starting his career -- reporting such strong efficiency results across several image formats (AVIF, WebP, Aperture) is impressive and worthy of celebration by the community!
- Tiles in AV1 go through the deblocking filter, so there won't be any seams after decoding. In fact, AVIF encoding solutions (like libavif) enable tiling by default. If there were seams, people would've noticed those artifacts and yelled at the libavif maintainers.
- *Because* JXL doesn't have a deblocking filter, you could argue that JXL effectively decodes to numerous "mini-tiles" -- each one equaling the size of a coded block. And indeed, you WILL see those boundary artifacts when quality isn't high enough for EPF, Gaborish and/or LF smoothing to mitigate satisfactorily. This is what Gianni's post covers.
- AVIF scales very well under multithreaded decoding scenarios, thanks to the excellent work of the dav1d devs. The main conclusion wouldn't have changed -- AVIF is significantly faster to decode than JXL.
- In progressive decoding, a very valuable feature is "bytes to first usable image". That's what the comparison is focusing on -- it's not a cherry-picked point at all. By usable: you can tell the pass isn't a "blurhash", but you can actually discern each element in the picture with reasonable detail. You can play with the JXL demo yourself -- JXL roughly needs 3x as many bytes to get to where AVIF is in quality, and JXL is still a bit more blurry in general. This applies to every image in the demo, not just the poke bowl.
- The folks who coded the JXL demo happened to use two passes for progressive AVIF, but you can use up to four -- including adding an even lower-quality "blurhash" pass, and/or a medium quality pass. Yes, it's desirable to control the number of passes and quality at the encode stage.
I'd go even further and say that 4:2:0 is unsuitable for still images, period. Even for cases where it would be a suitable tradeoff for video. And even for video there's a significant chunk of content where it's undesirable.
In general I think we've come to accept some pretty gnarly limitations on image quality that really should not be such a given. 8 bits per channel is another one. You actually really do notice the banding with the naked eye in a fairly large range of situations, and if everything is 8 bits per channel then it gets really easy to exacerbate the problem on edit. Dithering in 8 bits per channel isn't really a solution because it's hard to do and it gets lost in compression quickly.
It isn't clear whether AVIF hardware decoding will ever be an advantage, but for video formats, Firefox and Chrome already pick between hardware and software decoders to ensure the content plays correctly. Safari is much flakier here, but again, for images, they're not going to regress on 4:4:4 AVIF support.
I find the hardware support argument far more compelling that diminishing the value of lossless publishing.
Several 'zero click exploits' have involved image/document format decoder bugs, as messaging apps and file browsers will often generate preview images the moment an image arrives.
For comparison, it was possible to do 10-bit video with H.264, but 10-bit video didn't see any mainstream adoption with it because hardware decoders generally didn't support 10-bit H.264 video. Only when newer formats came around and specced 10-bit support as a baseline necessity did we start to see wider adoption for it. And well, the baseline specs (main profile) for AV1, which AVIF is based on, are limited to 4:2:0...
This is a good helpful comment containing relevant information from personal experience.
> Asked ChatGPT and it also claimed there's no problem with 444 and AVIF/AV1.
This part is useless, there's no one who cares what a LLM thinks that can't just prompt it themselves.
GIF is there... because it will always be there because it's just a hit that will never go away. It's also lossless (when discounting colour depth).
The new formats are interesting webp, avif, JXL and so on.
Jpeg classic is the clear winner IMHO and will probably never be less relevant than the new fancier formats. JPG even does text and sharp edges, reds, and so on well if you tell your process to take into account chroma subsampling!
It's magic and it puts food on my table.
Modern video formats are so much better that they are a no brainer to use while the word gif just got used to refer to looping video without sound rater than the literal gif image format.
But also, like GIF, it's pointless when lossless WebP exists and is supported everywhere. It's more efficient. Lossy WebP does not make as much sense though since jpegli entered the game.
OP has made https://halide.cx/iris/ which could make lossy WebP make sense, but it's not open source or generally available.
> The new formats are interesting webp, avif, JXL and so on.
WebP was introduced 15 years ago. New relative to JPEG perhaps, but certainly not new.
So anybody saying "we should use more vectors" has to remember what the state of open vector graphics standards is.
I'd wrote reader for this bit encoding many years ago when company I'd been employed at made custom VRML engine for Samsung featurephones (project was dead on arrival as at this moment smartphones / Android become available and all this lineage of featurephones was killed).
None of that has fallen by the wayside though? I have seen examples of all of those in the wild except for interactive menus and multiangle. Multiple video streams is incredibly rare to encounter but I have run into it a few times.
The argument in favor of flexibility (and jxl) is that if you optimize things for the "average" web user (as the essay seems to be suggesting) then fairly mundane usecases require you to start juggling formats, support becomes spotty, and things start breaking. It's nice to have generous limits within which you can be confident that things will "just work" for the end user. Even just on my own system I'd much rather use a single format rather than dealing with app x not supporting format y.
tl;dr jxl is the mp4 of image formats and that's exactly why I like it.
The only things I agree with the essay about are progressive decoding and decoding speed. Particularly the latter badly needs to be improved.
That’s the thing, though: libjxl development hasn’t seemed all that active in recent years. The community contributors you mention seem quite far from driving the development, and some of them say that the usual devs have been busy with other projects (including jxl-rs as of recently).
> People like to pretend AV1 got infinite resources
I would not suggest that, but in another comment here you yourself say that SVT-AV1 (which you compare to JXL favourably in your article) has seen active involvement from ‘Meta, Netflix, Intel, independent contractors, and others’ – not to the community fork SVT-AV1-PSY and its successors contributing their improvements back upstream.
I can believe that JXL may very well be more difficult to work with, but am I wrong to assume you’ve been able to continuously focus on your own encoder (and apply your experiences from your earlier work on SVT-AV1)?
We can reevaluate when and if improvements are made. The problem with statements like this, is its really easy to miss the showstoppers when imagining what something could be. All plans are amazing until you have to actually do them in the real world.
As the saying goes: Never fall in love with potential.
You'd rip a new one to Google if there would be a CVE in a new C++ library in Chrome because of it.
Now that Rust library is available, they will continue adoption, as it should be.
Memory safety as a condition for adoption was brought up only years later, and by Mozilla rather than Google. The JPEG XL devs, who’d offered to work on it if there was interest, got to work as soon as interest was proclaimed. You might say it’s a good thing for Chrome to have held off adoption until then, but that’s completely incidental, not because they cared. Near-zero efforts to be fair and responsible were made.
It is when that didn't stop them YOLO'ing in webp and then avif support.
But remember, on a camera you're wanting to maximize battery life, image quality and certain key performance metrics. The OM-1 Mk II can burst up to 120fps of 20 megapixel images with locked focus or 50fps with continuous AF. Thats a huge amount of data to capture, process and write to media. I think we want cameras to optimize for that. It's trivial to dump the resulting files on your computer and then convert between formats to your hearts content.
iPhone raw images are actually a jpeg xl inside the DNG.
Not for quality reasons primaily but because keeping the first stages of the processing pipeline and the archival branch lossless solves some headaches.
For every other image encoder I used I couldn't find one setting that would make compact, high-quality images across the gamut of inputs (e.g. things like comics that have extremely visible high-frequency content would look terrible at quality settings that looked good for many photographs).
EDIT: Oh! Of course. AVIF is based on AV1. For some reason I was thinking HEIF the entire time I was reading the article. Man... withdrawn!
Really good read, btw. Very good points.
Edit: saw you corrected. Much appreciated!
(.heif is sometimes used as a file extension generically, but HEIF is itself a container that can support various payloads.)
The scenario I'm thinking of is sending a photograph by email. Let's say Sally has just had her second baby, and wants to send baby pictures to her mother, the baby's grandmother. Neither Sally nor her mother are computer professionals, and they don't want to care about image formats. Sally wants to upload a file from her camera, attach it to an email, and send it. Her mother wants to click on the email and see pictures of her new grandchild. Neither one of them wants to have to convert the image themselves.
Let's say it's a few years in the future and Sally's camera produces JPEG XL files by default. (Which I don't think would happen if browsers didn't support it, for exactly the reason I'm about to articulate). If Sally's mother's browser doesn't support displaying JPEG XL, then although Sally (who uses a different browser than her mother) sees the picture in the email when she sends it, her mother writes back an email saying "the picture didn't show up, can you resend it?" And they spend a few back-and-forth emails before finally getting tech support from a friend who helps Sally convert the picture to old-school JPEG so her mother can see it.
If that's the experience for end-users, cameras would hesitate to switch to JPEG XL as a default format. Because nobody wants a hostile review from a user saying "My mother couldn't load my baby pictures, what kind of lousy camera are you making?"
So even if it's not the best format for the Web, I'm still persuaded that having universal browser support for a format intended for photos is an important factor, and devices like cameras will not switch to it as a default format until manufacturers are certain that browser support (and OS support, and electronic photo frame support, and so on) is nearly universal.
None of that takes away from the argument "Other image formats are better for saving space on the Web", which is the main thrust of your post. But I do disagree with the last line, "I'm just not personally convinced we need it in browsers any time soon." I believe that if browser adoption is lacking, adoption of the format in places where it makes lots of sense (like cameras) will also be slow.
What are your thoughts on that argument?
Both Firefox and Chrome [1] have committed to shipping JPEG XL later this year. Safari has supported JPEG XL since 2023, though their implementation doesn't support progressive images yet.
So the major web browsers will support JPEG XL later this fall.
[1]: "Intent to Ship: JPEG XL" - https://hacks.mozilla.org/2026/08/intent-to-ship-jpeg-xl/
I'm not even personally convinced it is useful for cameras. Sally's situation isn't particularly bandwidth or feature-constrained, so JPEG or PNG work. Maybe JXL is solving problems that don't exist?
In the ‘Lossy Compression Efficiency’ section, you compare the codecs using various metrics, but I don’t think you say anywhere what quality the images were encoded for. Did you forget to mention that or am I just reading things wrong?
(I assume BD-rate tells us how similar the images look, but I also assume the values would change if the encoders were made to target different qualities, hence why the intended quality seems quite important to know.)
Compared to JXL (which admittedly has almost nobody working on except veluca these days...) which was focused on it since the beginning, I think it really matters.
I suspect that eventually, the browser makers that are reluctant to add JpegXL support will do so, even if reluctantly, and so it will eventually "become useful on the web".
The reason why is Adobe added JpegXL as a compression format for PDF's, and as every browser maker wants their browser to also be a "PDF viewer", this means they must include a JpegXL decoder to be able to support PDF's going forward. If they must have a JpegXL decoder anyway, it is not that difficult to also add it as another supported format for the <img> tag.
I've been exporting in JXL from Lightroom for a little while now, you get slightly smaller image sizes and HDR with no real downsides. On the web I imagine this will translate to higher quality images on social media since platforms can get more out of the same file size. It will also likely be the end of HEIF which is a pain to deal with due to patents.
HEIF is what is getting support in recent models; but JPEG still rules supreme for its compatibility.
I think one of the compelling use cases for camera manufacturers would be an interoperable format for editors. Since JXL has support for so many channels, you could load your image into an editor, edit it, add layers, etc., and export as JXL, which could be used for other things.
No, they shouldn't. Not blindly. Metadata can include copyright license information, such that stripping it violates the license to reproduce the image.
It has 3 options:
JPEG Lossless (most compatible)
JPEG-XL Losless
JPEG-XL Lossy
Even still, the demo proves that AVIF can deliver a usable image with up to 3x as fewer bytes as JXL!
Also worth mentioning: AFAIK "their choice" here is just the default, i.e. what `avifenc --progressive` outputs, so maybe if the default is suboptimal, it could be improved?
> Even still, the demo proves that AVIF can deliver a usable image with up to 3x as fewer bytes as JXL!
Usable for what? As a clearly loading image / placeholder, I personally like the JXL version better (as already indicated in my previous comment). As a final image I think both of them are unusable, and if that's the intention I think it would be better to encode both aiming for very low quality, maybe also reducing the resolution, without progressive loading, then compare. My understanding is that AVIF is usually better at very low bitrates, so it would probably be better, but I don't think this example "proves" that.
In cases where you need lossless, WebP is there. It's close to JPEG XL's performance, sometimes beats it, and is orders of magnitude faster to decode.
Sure, but if companies are going to put in the effort to support a format, you might as well work towards supporting the 'full capabilities' of it, that way it can be used in as many workflows as possible.
You want your camera, photo editing software, colour correction process, etc, to support lossless. One of your final outputs may be for the web where lossless is not important, but there may be others as well (e.g., as a graphic in a video production).
https://pengbins.github.io/aomanalyzer.io/
- Upload the problematic image to the AOM analyzer
- Press 'L' to show tiles view
- How many tiles (yellow rectangles) do you count?
- Are artifacts actually at those tile borders?
That production pipeline may also be used to generate images for things besides the web, so the creators have the choice of having one set of files used everywhere, or one set for the web and a second set for other things.
That JXL lossless is overkill for the web may be overridden by the fact that people don't want to deal with the hassle of multiple sub-sets of files (i.e., laziness or "efficiency").
Depending on CPU and the video/image resolution, performance drops means the eye perceives lags when the 50ms threshold is reached. For videos, especially at 60fps that matters.
For still images it doesn't.
If it ain't broke why fix it.
It isn't particularly efficient in terms of file size, but as others have said, lossless images within a web page is extremely niche.
But it turns out you are right, 444 decoding with H264 doesn't seem to be supported up until recently:
https://developer.nvidia.com/video-encode-decode-support-mat...
Never noticed, seems like a strange omission, but in any case doesn't seem to apply to newer codecs like AV1.
And then you go on to state that the use of said features is rare. How is that not fallen by the wayside? They features are still available and can be used. They have not be removed from the format. It's just nobody uses them. That's pretty much the very understanding of fallen by the wayside is it not?
In principle, a decoder could refuse to process images with predictors above a certain complexity limit, but it’s hard to know how to set such limits accurately.
Yes, SVT-AV1 received and continues to receive development efforts from devs at big companies, but the number of core contributors has always been somewhat small. Definitely more resources, but the entirety of the original AVIF work was done by two people.
I'm able to utilize my experiences generally in image coding to work on my encoders. This should translate to JPEG XL, but I feel held back by how algorithmically complex compelling implementations of the coding tools would be, and how to make those implementations fast. I think if the JPEG XL spec was incredibly intuitive, community contributions would have gotten it a lot further. Heck, my own efforts may have gone to it instead of SVT-AV1-PSY's AVIF encoding.
(And lots of kernel shared between decoding and encoding, of course)
Thought so.
Bit of a nit, but can you add that as a note to the legends/graphs in the future? As a layperson, it helps us to orient to graphs with unknown metrics.
Thanks for the article, btw!
It is a true open source project; not just an open source license.
It doesn't support progressive images or it doesn't support progressive decoding of images?
The former would be a massive compatibility issue, the latter would only be a quality of implementation issue.
In all cases, the browsers are able to render the final image, they just don't show the intermediate stages.
And nearly everyone who takes photos of their family ends storage-constrained on cameras at some point. Memory cards only holding so much is less of an issue than it used to be, but in my experience the only people with laptops that have more than 1 TB of disk space are the computer professionals I know; every non-computer professional I personally know has 1 TB or less, usually 512 GB. That's room for plenty of photos, but not an infinite amount, and the photo collection (plus videos of baby's first steps and so on) is competing with a lot of other things for storage space. So being able to shrink the collection size by 30% or more with no artifacting added is definitely going to be worth it for one of the biggest selling points for cameras. (Including the cameras on smartphones).
I wouldn't say that JXL is absolutely vital and the industry should switch right now. But I would say that it's likely to be the only image format that has a chance to displace JPEG among the average camera user. Having JPEG in the name is also going to be a major selling point; don't underestimate that. (And the JPEG <-> JPEG XL conversion being lossless will complete the selling point).
Since (if I'm right) it's going to end up ubiquitous, then even if another format would be technically better, it would be wise for everyone writing software that handles images — browsers, OS file explorers, and so on — to make sure their software can support it. Just on general principles of supporting every widely-used format and every format that looks likely to be widely-used in the future.
It's odd that apple didn't proactively guard against such concerns when adding a new format.
Never underestimate the power of a well-known brand name in communicating things to people who know nothing else about the subject. The name is a big part of why I suspect JPEG XL will take off in popularity. (The lossless conversion to and from classic JPEG format is the other main reason).
At smaller sizes (more typical on the web), the results are opposite, the JPEG decodes much faster.
That ship has sailed.
Go to google.com, search for images and select image type gif and you will get mp4s with sound.
And there absolutely are cases where a lossless GIF is smaller than a lossy video format.
Then, long live the iMessage and Whatsup exploits, because SW developers are not able to do things right.
It's unfortunate that we didn't give lossless webps a separate extension. Frankly I think even saving them as .png would've better than what we have now - people roughly understand that a .png is an image without artifacts, and any self-respecting image viewer will inspect magic bytes before opening a file anyways.
I suppose it's not very useful nowadays as most any image will load fast, though.
This means, that at least for the Web sites that I happen to access frequently, whenever I see PNG or JPEG images they typically have a better quality than when I see WebP images.
I do not know whether when browsing the Web I see frequently any AVIF images. They are either rare or they have a similar quality with JPEG images, so they did not stand out like WebP, where I perceived a degradation, so I noticed that the image format was different.
I do not care much about the speed of decoding Web images, because the speed of loading Web pages is determined mostly by the amount of junk JS that is included and not by the loading and decoding of the included images. So for me the quality of the included images is more important, thus WebP is something that I dislike, while JPEG is far too limited, so I would prefer JPEG XL images.
The arguments in TFA do not seem entirely honest, because the presented data confirms the low quality of WebP in comparison with JPEG XL, and because the 2 compared JPEG XL implementations differ in their performance by a factor more than 2, so it is likely that they are both immature and one could still accelerate the decoding of JPEG XL by at least 2 or 3 times in comparison with the best of them.
The only claim of TFA that seems valid, is that if AVIF is really as good as claimed, it could be sufficient for Web pages that want to show only highly-compressed images and good for replacing JPEG for such a use, while JPEG XL might be strictly required only for applications that need higher quality, i.e. for the processing and storing of photographic images.
I can accept a claim that JPEG-XL is not the best format for it, or that it is good, but not worth the complexity and extra surface area it introduces. I can not accept a claim that "lossless just isn't very useful on the web".
I think its correct to say a use case that is very niche on the web isn't super important to the web. Especially when there already exists a bunch of lossless formats. After all, the value proposition of jxl is to save some bytes. It would be different if the point was introducing images as a whole.
> Especially when there already exists a bunch of lossless formats.
Sure, but I'm not defending JXL here in particular, just arguing against the point that lossless images are unimportant on the web.
Scenes often comprise gigabytes of lossless webp, some of which you can see at https://superspl.at.
‘The average Web consumer’ may not need lossless, but a non-negligible minority very well might, hence why lossless should absolutely be on topic.