The article makes a good point: JPEG XL is amazing but not specifically for the typical Web use cases, compared to AVIF. But the conclusion doesn't follow. Having an excellent and versatile format supported by browsers is very useful!
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.
+1, this is super unfair to show the one point in time where AVIF progressive looks better - right after it receives its 'preview' (which as you say is 4x as big as JPEG XL's).
I value integrity, especially when communicating results. This is shameful.
“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.”
I note you made no response to the objection about representing a temporal sequence with a single, nonrepresentative and cherry-picked, screenshot.
As to bad experience, that seems like a legit personal preference, but disturbingly un-nuanced and absolutist if intended to apply to everyone.
When on a train with spotty wifi or frequent tunnels, I would actually prefer to see whatever arrived. Someone on prepaid data might want to truncate at ~100 KB, no matter what the website owner or browser PM thought.
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.
Depends on the user. Some users are more sensitive for flashing images. Some users have very slow or unreliable network connection. Some sites have bigger images. Some sites (such as ecommerce) have higher quality and resolution needs.
Some users have uncorrected astigmatism. In the general population, the average uncorrected astigmatism typically falls between 0.50 and 0.75 diopters (D), and ~15 % more than 1.0. The high astigmatism people will see images blurred in any case and don't benefit from the fine structural detail JPEG XL can give. People with glasses and the lucky ones with low astigmatism will see the details clearly.
Sometimes passionate ends of different quality of vision seem to have a discussion on what makes sense as the web quality, with one emphasizing quality 40 being more than enough and another requesting a quality of 95.
The same kind of individualism exist also in temporal cognition and perception.
The quality of the preview layer is somewhat under the control of the user though.
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)
It's an absolutely ridiculous point, and the guy you're responding to (who has commented almost 40 times in this discussion) has a hilariously slithery opinion that somehow always finds a way to hold every finding against JXL.
Personally I don't like progressive rendering at all, but it's interesting that this same guy claimed elsewhere that it's super important on a very bad connection to get an early hint of what an image is. When someone points out that the "the results speak for itself" cherry picked example is absurdly misleading, and in most cases JXL is vastly superior at that case, instantly their opinion changes such that it shouldn't look like a poor quality image but it's somehow also a win that AVIF takes longer to give you anything at all to look at.
Which is incredibly weird, given that AVIF also gives you a terrible quality image, it just takes longer to show it. So it sounds like they're completely against progressive rendering? Unless they think it gives AVIF a benefit?
But it's an amazing demonstration of someone with an agenda. Utterly bizarre.
I also called AV1 short-sighted for not including an alpha channel, and corrected someone who claimed jxl-rs was single-threaded. No agenda here - I'm just correcting misinformation and stating my opinions.
Agreed. Browsers should support general-purpose image formats. I'm not interested in another “web codec” that's not good for anything but passive delivery.
> Maybe re-encoding my website JPEGs to gain 20% size is not worth the 33% longer decode
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.
Sorry if that was confusing, I have edited my post to clarify a bit: That sentence was about a feature specific to JPEG XL, which is that if you have JPEG files you can re-encode then as JPEG XL to save space without any loss of quality. It's nice for peace of mind, you can bulk convert a large archive and you know you still have the same pixels everywhere (later you can even turn them back to JPEG without loss if you want). AVIF cannot do that. Now if you are OK with some loss in the conversion, you can also do much better than 20% with JPEG XL.
Worth mentioning that someone else in the comments converted their large library of JPEGs to JPEG XL for exactly this reason and only realized afterwards that they lost a ton of image metadata from the EXIF tags. This probably isn't what you would assume would happen for a bulk 'lossless conversion' so if you're going to do this then make sure you're validating the metadata too (if it matters to you).
It sounds like you lossily re-encoded lossy JPEGs to AVIF, am I reading that right? If so, you're automatically suffering from generational loss there, it can't be the basis of any coherent argument.
The entire article is extremely cherry picked, and it's notably that there are a couple of people leaving dozens of comments in here each (which is odd as normally HN gates that sort of gross overrepresentation). Like >10% of comments in this 300+ comment discussion is one single person, endlessly changing positions based upon what makes JXL worst.
It's bizarre. I've never seen a format see such ridiculous attacks.
>Maybe a lossless re-encoding of my website JPEGs to gain 20% size is not worth the 33%
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.
> Maybe a lossless re-encoding of my website JPEGs to gain 20% size is not worth the 33% longer decode,
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
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.
People really, really like to try to save up on the matches, so to speak. Sometimes literally: there was a short period of time during Khrushchev's rule in the USSR when the natural gas was made free for the populace. Well, the matches still cost money (1 kopeck for a box of 50 matches), so lots of people would just not turn the stove off, instead always having it burning the smallest possible flame when not in use.
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.
A potentially major issue I have with AVIF is that because it is based on a video format, any hardware decoding support AVIF will get is likely to be restrained to common video scenarios. This can result in eg. only 4:2:0 YUV being supported by hardware decoders, as that's the upper limit of AV1 Main Profile (and thus the limit of AVIF Baseline Profile). And 4:2:0 is just a poor fit for certain categories of images (like various kinds of illustrations, screenshots, etc). I would not be very happy about a web where lossy 4:4:4 image compression would be heavily discouraged with modern formats.
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.
> And 4:2:0 is just a poor fit for certain categories of images (like various kinds of illustrations, screenshots, etc).
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.
4:2:0 is the main reason why most games look like crud once they've passed through any mainstream video encoding pipeline. That being said, the bitrates used for streaming games and VoDs are so low everything looks like mush anyway and millions still watch that.
Browsers already fully support 4:4:4 AVIF and are not going to regress on this, as it would be a huge compat issue.
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.
Lossless AVIF encoding is inferior to JXL though, the article oddly dismisses lossless as a valid case for the web so it ignores the core argument that lossless is critical for some type of content.
I find the hardware support argument far more compelling that diminishing the value of lossless publishing.
> I think the need for lossless images within a web page is extremely niche.
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).
JPEG XL on the web does not arrive there ex nihilo: there is a production pipeline that creates and puts files on web servers and points to those files in HTML tags.
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").
There have been a number of experiments to use hardware decoders for images in browsers, all of which have fallen flat; not even Safari does it for AVIF or WebP. Thus, 4:4:4 AVIF is supported absolutely everywhere. Feel free to try it now. I can see how hwdec is compelling for JPEG XL in theory, given how slow decoding is.
In the modern age image decoders need to handle untrusted inputs, and the big players rarely use hardware image decoding, even when it's available, because it's so hard to rely on its memory safety.
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.
The factor is latency.
Software decoding takes milliseconds.
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.
Yes, I know the format supports it. The question is, will hardware decoders built primarily around video use cases? And if those kind of hardware decoders end up forming the majority of hardware decoders for AVIF, will we end up in a future where using the full range of the format is heavily discouraged because it won't be supported by hardware decoders?
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...
I'm not super familiar with AV1/AVIF but I do have extensive experience using h264 for desktop streaming, and all major implementations support 444 in hardware and software, and I doubt more advanced codecs/image formats have a limitation like this. Asked ChatGPT and it also claimed there's no problem with 444 and AVIF/AV1.
Then chatgpt missed an obvious issue, nvidia definitely have had shortcomings in the hardware implementation of coder/decoders only supporting 420 in nvenc/nvdec. One obvious problem with that was that it affected premiere.
> I'm not super familiar with AV1/AVIF but I do have extensive experience using h264 for desktop streaming, and all major implementations support 444 in hardware and software, and I doubt more advanced codecs/image formats have a limitation like this.
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.
Strange blog post. Given that it's from a developer of proprietary and paid commercial encoders, the inclusion of their upcoming "aperture-alpha" encoder on the charts that are purportedly about JPEG XL makes this feel like a marketing piece of some fashion. Certainly, they advertise their Iris-WebP encoder throughout the post, with an implication that if you haven't paid to the author for it, you're not using WebP correctly, I guess?
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.
I expected one of these bad-faith readings, so I can address that Aperture is mentioned once and Iris-WebP is only shown in numbers, because I have access to these encoders and thus they cannot be ignored. The only encoders I heavily advertise here are the incredible open-source AV1 encoders, that I contributed to for free and I think people should use. Also, not sure where you infer that point about WebP; libwebp is a fine encoder.
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.
> 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.
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).
Worth mentioning: their demo only uses two passes for progressive AVIF -- it's just their choice. You can have up to two more intermediate passes, so at 30% you can have something much closer to the original image.
Even still, the demo proves that AVIF can deliver a usable image with up to 3x as fewer bytes as JXL!
> their demo only uses two passes for progressive AVIF -- it's just their choice
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.
Well, the default in avifenc can always be changed. Do keep in mind there's no "one size fits all" implementation, as customers desire different loading tradeoffs. You might be surprised, but during testing (outside HN), we've seen people actually prefer "2 layer" loading.
I'm surprised HN likes progressive loading to be more granular, and use that to push back. I'm wondering if there are generational differences at play? Maybe it's the difference of being used to the blurhash vs. old-school JPEG loading experience.
Anyway, the more expressive mode in avifenc is `--layered` (yes, I know the name is weird).
> Usable for what?
Well, focusing on the "Poke bowl" example: with AVIF you can clearly tell apart each ingredient at 8kB. You can derive enough semantic understanding just from this base layer. Having decent edge preservation helps significantly here.
On the other hand, JXL is just too blurry at 8kB to make sense of the image -- only the egg and carrot are recognizable, maaybe the cucumber? IMO JXL needs the pass at ~28kB to make everything salient, including sprouts and beet. Yes, I know there are subjective effects at play and I'm sure we'll disagree on exact image thresholds, but recognizing objects within an image is so important in real-life use cases.
> Well, the default in avifenc can always be changed.
Sure, that was kind of my point, but I think it's important to point out it's the default. I had read somewhere else in the comments that they just "happened" to use 2 passes (that I now realized was also written by you), that I interpreted as them maybe making a bad decision in the comparison page, but I think it's very reasonable to use the default. I also usually prefer to use the default unless I have a good reason not to do so.
And I think that `--layered` is fine as a name, and I had realized that as the docs were right below the docs for `--progressive`, which do mention it encodes a "layered image", although it could use an example on how to use it effectively.
> I'm surprised HN likes progressive loading to be more granular, and use that to push back.
Not necessarily? Using more passes would probably help in specific the metric in the comment I was responding to, by making AVIF possibly look better on a larger fraction of the decoding time. I mostly interpreted your comment as saying that it would have been better if they used more passes, and that's on me.
The reason I was comparing the breakpoints in the decode time was because I was responding to an allegation that "even there, AVIF looks better for 90% of the decode time", and I decided to point out that's not not the case and chose some pretty clear breakpoints that are very hard to argue about. Very subjectively the actual breakpoints could be a lot earlier, for the Poke the AVIF only looks better (in the sense that you can figure out what's there better) in a 6% range (from 2 to 8%) or maybe 9% (from 2% to 11%) of the decode time. There are many (relatively big) seeds that are just not there on the AVIF side, but you can distinguish on the JXL side, even if they're blurry. Percentages used in reference to the JXL side.
> I'm wondering if there are generational differences at play? Maybe it's the difference of being used to the blurhash vs. old-school JPEG loading experience.
Hmmm I don't know, maybe. TBF with today's usual internet speeds progressive loading isn't as important as it was as more steps make less sense if you have a good connection.
> Well, focusing on the "Poke bowl" example: with AVIF you can clearly tell apart each ingredient at 8kB. You can derive enough semantic understanding just from this base layer. Having decent edge preservation helps significantly here.
Sure, I see what you mean, you can distinguish more image element in the AVIF example, that's true. I don't like the lack of consistency and some of the artifacts to the point where I'd prefer not using progressive encoding, so that's not what I'd call "usable", but that seems like a matter of taste. It surely does look closer to a "final image" than the JXL at that point.
As a note, I think what I'd prefer would be 2 passes, with the 1st pass being around how JXL looks at around 11% / 39 kB. You can get a rough idea of what's the image about and the elements on it, with roughly the right colors, but it's still clearly loading, so there's no confusion, and without many "artifacts" like the progressive AVIF in the example (no idea if AVIF is able to make progressive encoding in a way that's more "blurry"). The caveat is that more steps are better when it takes too long (more than a few seconds) so the user knows it's not stuck.
> Sure, that was kind of my point, but I think it's important to point out it's the default. I had read somewhere else in the comments that they just "happened" to use 2 passes (that I now realized was also written by you), that I interpreted as them maybe making a bad decision in the comparison page, but I think it's very reasonable to use the default.
Yeah, I can see that. By "happened" I meant that the default is good and serves a common use case, but also it can't be expected for a 2-pass AVIF to remotely match JXL's finely-incremental experience. The tricky thing is coming up with a good-enough compromise -- one extreme wants their first pass be more like a blurhash (quality 0, 1/8 scaling), while the other wants a medium quality image (quality 30-40, full scaling), and everybody else is in between.
For reference, `avifenc --progressive` is currently quality 10, 1/2 scaling.
> Hmmm I don't know, maybe. TBF with today's usual internet speeds progressive loading isn't as important as it was as more steps make less sense if you have a good connection.
Interestingly enough, I frequently get reminded of spotty internet connections -- turns out you just need to take the subway hah. This is why I'm so passionate about progressive image loading in general.
> As a note, I think what I'd prefer would be 2 passes, with the 1st pass being around how JXL looks at around 11% / 39 kB.
That sounds like you want your first pass be half scaling, around quality 25:
`image1.png` and `image2.png` can be the same source image. You can blur `image1.png` or even better: add a tiny "loading" icon to indicate the image is still downloading.
Oh, i left the wrong quotation whereas i intended to reply to another message. Throughout the blogpost you're quality matching and comparing encoders based on objective metrics whereas it'd be more telling to get the crowd subjective comparisons. I think it's pretty evident that most codecs benchmaxx to the point of objective metrics being useless.
Ah, no worries! I can't speak for Iris and Aperture, but both "tune IQ" modes in SVT-AV1 and libaom had extensive human evaluations to make sure they weren't accidentally being benchmaxxed at the expense of subjective quality.
- 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?
I was even more surprised & disappointed to see this dismissed as an ad for my company. Think about how fantastic JPEG XL would be for my company: an image codec with tons of fans and an extremely weak reference encoder? Sign me up. I'm writing this as someone who wants a better Internet.
If you're sensitive to tiling artifacts, you must deeply dislike the way JPEG XL images look. Every block of a JPEG XL image is effectively a small tile, because there is no deblocking loop filter (I talk about this in the article).
JPEG XL has two filters that are pretty much equivalents of what AVIF has, while AVIF has three; plus, tile boundaries are handled by the DLF. Your point doesn't really stand on two legs if it means to come to JPEG XL's defense here.
By "small", it's meant in a relative sense. JXL's coded blocks can be as big as 64x64, and block boundaries can create visible seams. Example: https://juliobbv.com/pics/photo.jxl
These seams are especially noticeable in the background, and align with coded block edges. You can tell the encoder is trying to conceal them as best as it can, but this cannot be properly mitigated without a proper deblocking filter.
For comparison, AV1 tiles normatively go through the deblocking filter.
I participated in the design of those filters, so no, I do not deeply dislike the way they look.
This gaslighting is not convincing. No matter how many filters AVIF has, I distinctly remember tile artifacts being particularly disturbing. More so than individual blocks, whose size and border effects differ; tiles are a straight line through the entire image.
JPEG XL does not have this problem because the design and codestream enables parallel decoding (thanks to per-group offsets encoded in the 'TOC'), hence does not require separate tiles.
Hi there! I'm Julio (co-developer of libaom and SVT-AV1's tune IQ). Here there are some points worth mentioning, because I'm catching a whiff of bad faith with your comment that honestly needs to be called out:
- 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.
"For non-photographic images, the argument that “they should be vector images” doesn't hold up because many images could be vector images but aren't, and they can't be vectorized perfectly. “The world should be different” is not a justifiable defense against optimizing for the way the world actually is."
This is a good paragraph. I see people forget to apply that last sentence all the time.
Agreed. JPG is the most popular format for photography. PNG, the lossless format is great for diagrams and stuff with sharp edges. It can be "compressed" via dithering and quantization.
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!
Gif is a weird one because it's silently been replaced while keeping the name around. Virtually every software using the term "gif" actually uses a h264/vp9 video with no sound.
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.
The major blunder here is browsers refusing to support silent videos in <img> tags etc. so we end up with all these hacks. Instead we got animated webp that you can't use for progressive enhancement because it doesn't have its own mime type and browsers reported support for image/webp before implementing animation support. And webp is also very limited when it comes to inter-frame compression for no good reason at all.
Gif doesn't mean "no sound" anymore. Gif is more or less "short video", which broke a lot of assumptions at first but we have pretty much passed that transition and it makes sense for what they are used for today.
Those are messaging/communication apps,sound in those apps can be quite disruptive so that doesn't surprise me at all. It has nothing to do with the original gif, it is just that gif is now synonymous with short clip (with or without sound) and sound in that context is disruptive.
Go to google.com, search for images and select image type gif and you will get mp4s with sound.
Telegram's usage of "GIF" (any short video without sound) is incredibly weird and frequently goes against users' expectations. I wouldn't treat that as definitive.
I ... what? I've never heard anyone conflate the two--not teenagers, non-technical adults, or software people. Most folks know that "GIF" means "moving image that can be easily shared but has no sound and usually crap quality", not a video/audio clip.
Reminds me of when Imgur started trying to push changing gifs over to gifv, which were just mp4 with a strange new file extension. I didn't like their approach but it really was such an improvement on file size and quality.
Not to mention if you for some odd reason wanted to do gif-style animations, you can also do it with apng or webp. You shouldn't, real video format makes more sense, but even if you did there is still no reason to use gif.
Perhaps the clue is in the past tense "supported". Nowadays browsers support many formats, but in the "olden days" gif was the only way to get animations in browsers without plugins like Macromedia Flash...
also, don't forget - actual video format is better for animated stuff. Current default approach is .webm which is standardized .mkv container + vp9 (or av1) video + opus audio (usually no audio to as a feature parity to gif). IMO animated picture formats like .avifs are very backwards and don't add much
One advantage to animated AVIF is that it supports an alpha channel, which AV1 doesn't. But I guess that just points to how short-sighted it was for AV1 to omit alpha channel support.
> Gif is a weird one because it's silently been replaced while keeping the name around. Virtually every software using the term "gif" actually uses a h264/vp9 video with no sound.
Then, long live the iMessage and Whatsup exploits, because SW developers are not able to do things right.
I began a dispute on the English Wikipedia which revealed that more than a few people use “GIF” to describe, not a file format, but a visual style of looping animation.
> PNG, the lossless format is great for diagrams and stuff with sharp edges.
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.
PNGs will persist because I know that they're lossless by looking at the filename. When I hit File > Save as .png, I don't have to inspect output metadata (that image viewers don't expose) or play around with exporter settings.
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.
Being lossless is a function of the whole pipeline from an input image to an output image. The last step being encode to PNG doesn't guarantee anything about losslessness.
I do not know whether this has anything to do with any limitation in the WebP format, because it is more likely that this is some kind of bias in the kind of authors of Web pages who choose the WebP image format, who might also choose more aggressive compression settings, but for me WebP is a synonym for "low-quality image".
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.
But supported by no browser today and software support in general is quite limited. If the PNG authors would just incorporate this possibility into PNG from start it would be interesting, but it's too late now.
Gif is still there because it's still often the only option for frictionless video embedding. Embedded videos usually come with a video player that hardly ever quite works out well, often not starting automatically, not looping, or showing video player UI elementa that shouldnt be shown.
But this is quite a different format than JPEG or better said the subset of JPEG that we know today as JPEG format and the JPEG encoder/decoders support. The whole JPEG format did have support for a lossless mode for JPEG (different one than JPEG LS), arithmetic coding and 12-bit images too, but those features just didn't make it into the implementations of the format (arithmetic coding initially did, but was removed from popular implementations because of patents).
Png is still being updated, just last year it was updated to support a wider color space than any other web format. This shipped in all browsers before the official spec was publicly so you’ve been seeing Png upgrades without even realizing it
Also it would be nice to have a good standard vector format that isn't the complete kitchen-sink that is SVG, but we don't have that. We needed "jpeg but for vector graphics" and instead we got "html but for vector graphics".
So anybody saying "we should use more vectors" has to remember what the state of open vector graphics standards is.
In the context of the world it's all hair splitting, you can have a big photographic picture in png, or 1% compressed jpeg, or 1% jpeg converted to png. No new format can change it.
It seems to me that AV1 (the codec used in AVIF) has seen a lot more development in recent years, by virtue of being widely adopted for video. JPEG XL has not seen comparably massive adoption, perhaps owing in large part to Chrome rejecting it on dubious grounds (in spite of eagerly forcing the adoption of both WebP and AVIF earlier on). The pace of the reference implementation’s development has grown very slow, and most of the modest attention it’s been getting seems to have recently moved to the new Rust decoder, once the browsers finally made up their mind that’s what they wanted from the devs.
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.
It is getting its try, actively, in libjxl. People like to pretend AV1 got infinite resources; the reality is myself and one other contributor produced the vast majority of the image gains. I built Iris-WebP and aperture-alpha myself, from scratch. As a compression engineer, I think JXL is way, way harder to work with, and it would've taken me a lot longer. libjxl has community contributors, it is just an uphill battle with a codec like that. Same as WebP is an uphill battle due to its format restrictions.
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)?
I think libjxl's development is stalled because the format is hard to work with. It wasn't super hard to drive meaningful improvements to AVIF.
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.
Wasn't that also basically one guy from the VLC/ffmpeg community that drove that effort? I think they got funding from Netflix to do it again on ARM after demonstrating the benefits on desktop.
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.
The stated reason for Chrome was not ‘we need a memory-safe implementation’. It was ‘there is not enough interest’ and ‘there is not enough improvement over AVIF’. At the time, there was interest and there was improvement over AVIF (which Google has decided to support regardless of memory safety, interest, or seemingly any deeper consideration).
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.
That JPEG XL prime computation is a pretty ugly DoS. Just selecting it in Finder, with the preview pane open, maxed out every core on my Mac inside a QuickLookSatellite that also ate 4GB of RAM while doing so - for a good 15 seconds. Not bad for a 2KB picture. It seems like Apple did not set sane limits on their JXL previewer.
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.
When a format has so much flexibility, the world will glom onto the first thing that it solves and put it into the wild to solve that problem. The rest of the capabilities fall by the way side, yet not removed from the format. They're just ignored. MP4 can do so much more than the typical deliverable of a video stream and an audio stream. The spec allows for multiple video streams, multiple audio streams, subtitles, Flash like interactivity to allow self contained DVD style programming of menus to allow for chapter navigation, audio/sub selection, multiangle, etc.
MPEG4 supports interactive 3D scenes (read: games!) via bit-encoded VRML which can include JavaScript. I don't know any software which support this features (even without interactivity), but it is here.
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.
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?
No? If mainstream software handles the features (which mpv, vlc, and ffmpeg do) I wouldn't consider them to have fallen by the wayside.
I agreed that three were rare (two I've never personally encountered in the wild) but the rest I consider common. Actually if multiangle is referring to 3D video then I've encountered that one too. It's just that 3D videos are themselves quite rare but I think most software supports them.
I mean "mild" bombs where the final output bytes looks normal, a regular sized image, but the decompressing steps takes unnecessarily long, eating CPU or/and RAM
Probably not; for PNG, the image size is declared in the header, so a decoder can decide immediately if it wants to decode the image or not. The output is bounded by the size of the image times the bit depth, and decompression runs in time proportional to output size. zlib bombs exist, but they don't affect png because a decoder can simply refuse to decompress past the size of the pixel buffer.
The infamous PIL DOS errors, rooting from the library refusing to process images larger than a hard limit. Does this mean though JXL does not have that data accesible quickly?
The problem is that JXL has a ridiculously versatile modular mode which enables high-complexity “prediction” computations. These were designed to encode reusable, custom predictors that could reduce the prediction error and thus the number of bits needed to encode the error. However, the predictors can be abused to perform very complex computations instead. The prime image is only 4kx2k, but encodes a very complex prediction algorithm that happens to generate prime numbers.
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.
The primary problem with that image is that is has over 60 channels, which means it'll take 20x more time to decode no matter what. Incidentally, the JXL spec suggests that web browsers shouldnt't decode images with so many layers. Jxl-rs will probably start enforcing such limits by default.
> I believe Web codecs should be purpose-built, efficient, and narrowly scoped to the needs of the Web.
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.
I got an impression JPEG XL is not a single format, but many formats put under one brand (same as webp), you still need to choose these formats and transcode between them.
I personally find AVIF more versatile. I just throw images at it, and it does a great job. As the article identifies, JPEG XL performs worse than AVIF in general, but it's particularly bad at things like illustrations and screenshots. With AVIF I don't need to worry about that.
I've always found it annoying how most cameras only let you save their photos as some combination of JPG/PNG/HEIC/RAW, often without any adjustable quality settings or option to save several copies in different formats.
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".
The camera's I've owned (Canon and, in more recent years, Olympus/OM System) all could do RAW, JPG, or RAW+JPG, or in some cases cRAW+JPG, with several quality settings available for the JPG side.
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.
Nobody has brought it up yet, but JPEG XL seems to be close in potential and flexibility to OpenEXR. It seems more a competitor to something like that--for use in image processing and digital art pipelines--than something like JPEG, WEBP, or PNG.
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.
I knew about the lossless JPEG to JPEG XL compression story before, but had no idea that it was a two-way road. That's truly f* impressive. Boggles my mind even more the fact this format hasn't been adopted widely yet.
JPEG is a lossy frequency-space compression stage followed by a lossless Huffman coding stage. The second stage is quite generic as such, essentially compressing a stream of bits.
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.
Do you? I just tried it locally, and decoding a 4.9MB, 6000×4000 JPEG with djpeg took about 400ms; decoding its losslessly-recompressed JXL (4.15MB) single-threaded with djxl took 300ms.
Well, I said “with djxl”, and Chrome/Firefox use jxl-rs which happens to apparently be currently somewhat slower for that use-case (but libjxl being faster shows it doesn’t have to intrinsically be the case), and Safari uses libjxl but multithreaded (so it’s 800 ms for the JPEG and 137 ms for the JXL).
That's fair, at really high resolution, the JXL decoders in browsers do better than JPEG decoders. I'm pretty sure this is a weakness in the JPEG decoder rather than the format, but it's still a meaningful result.
At smaller sizes (more typical on the web), the results are opposite, the JPEG decodes much faster.
jxl-rs will presumably get much faster in time. The work on it started much later than work on libjxl (because it took years for anyone to say they had vested interest in it), and if my understanding is correct, it hasn’t been production-ready until recently. Once it behaves correctly, speed improvements are next in line, presumably.
There is indeed an issue with the JPEG format that makes parallelization difficult: the lack of a 'table of contents' with offsets to tiles.
Various workarounds (for example RST markers or self-sychronizing properties of Huffman) have been proposed, but these are not great and do not work for all images.
JPEG XL ensures this information is always available.
I guess my surprise is mostly that it hasn't been adopted elsewhere. For instance, it still boggles my mind I can't store my JPEG XL images on Google Photos nor take photos as JPEG XL images directly on my Samsung smartphone, but can use HEIC for some fruity reason.
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.
It sounds like you don't recognize the relationship between text and subtext.
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.
Maybe you're just bad at reading text. Again, read the post carefully. Look around... nobody else had the same interpretation as you, so maybe that should clue you in something might be off with yours.
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!
I'll tell you what. In good faith, you should ask your friend to fix the numbers in the post specifically in relation to concerns that people have with the testing methodology in relation to threads and the speedtest flag instead of handwaving them and to be forthright about how significant codec optimization historically comes after adoption.
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.
Yes, he'll fix the speedtest flag thing (which BTW, several people were accidentally using it wrong because the feature is unergonomic AF, but it's convenient to blame the user for "holding it wrong" right?). No, single-threaded encoding/decoding is a valid use case and not a testing methodology flaw.
> ... to be forthright about how significant codec optimization historically comes after adoption.
Well, this trend has now been broken, so it's irrelevant to mention it. Codecs are now expected to be optimized well before adoption. Take the case of AV2: the AOM folks are currently improving the reference encoder, libavm. SVT-AV2 has just been announced. This is the reality we're now live in. The fact we're having this conversation is an instance of that trend change.
> "I have no reason to believe they'd be better anyway".
Why are you now selectively quoting fragments? That sentence goes "...and I have no reason to believe they'd be better *than dir-pred* anyway." The part you omitted makes the entire difference. Implementing splines will improve JXL's efficiency (again, this was never contested), but it IS unlikely that they'll fully compensate for the lack of dir-pred.
You know why? I *did* take a shot at writing an automated splines implementation for libjxl, and I failed. Not because I didn't know what I had to do, but because I couldn't find a quick way to generate high-quality spline candidates that improve overall quality while making up for their size and encode compute overhead. I'm sure that there's a hypothetical clever way to do it, but the point is that the equivalent tool (dir-pred) is dead easy to implement in comparison, done countless times independently, and it just works.
Efficiently leveraging JXL's splines into the encoding loop is legitimately a very hard problem. No, problems of this kind shouldn't be this hard, and it's healthy to call this stuff out instead of pretending that, some time in the future, the "potential" of "alien technology" coding tools will somehow be untapped.
> You see, any unfilled area is specifically mentioned only to dismiss it as meaningless.
Oh, you're still doing the weird "subtext" thing... you know what? I'm done. Have a nice day.
> Codecs are now expected to be optimized well before adoption.
Maybe I hallucinated, but I seem to recall that your very fine AVIF work happened only well after major browser adoption. "Rules for thee, not for me", I guess. Talk about trying to pull up the ladder.
> SVT-AV2 has just been announced
Best of luck to it and AV2. That's a non-sequitur.
> The part you omitted makes the entire difference.
It really does not. Because...
> Implementing splines will improve JXL's efficiency (again, this was never contested)
your given position is that it will never be improved enough. That is the problem. That your position is that it will never be improved enough to be better than AVIF (I mean again, though it was previously until quite recently) is entirely the problem.
You grip tight to this idea now that if JXL ever improves even one iota then you're vindicated in having graciously allowed it to improve, but you have not granted it the capacity to be improved any bit more than AVIF.
> than dir-pred
This is what I'm talking about.
> I *did* take a shot at writing an automated splines implementation for libjxl, and I failed.
I'm sure you're very good and very smart, and you've clearly done very good things. You're not the only very good and very smart person, of course. But you do have very strong opinions about what is and is not worthwhile for the world to pursue.
> Oh, you're still doing the weird "subtext" thing.
What can I say. I'm used to very good and very smart people knowing about subtext, so I guess I assumed you would.
I don't know why you are being condescending to Julio. His work has pushed AV1 forward significantly. His opinions (specifically about dir-pred) are shared by others who are in the encoding space because they're objectively true. If a breakthrough for splines is invented, we'd be elated, but as it stands, dir-pred is in virtually every video/image coding standard since the late 90s for a VERY good reason. Dir-pred also has two decades of iterative improvement and research behind it. The argument is that JXL's lack of this well-established coding tool is a serious handicap that will make it very hard - if not impossible - to compete with AVIF within a reasonable amount of time.
AVIF was performing better than JXL/WebP/JPEG for a long while, even before Julio and Gianni's tune IQ work happened. AVIF successfully met the bar, tune IQ further increased that efficiency gap.
AV2 needs optimized encoders and decoders because it now needs to justify its spot among AV1 and JXL on the web. That's why avm, svt-av1 and dav2d are well underway.
Note, that JPEG XL was added as a possible compression method for DNG files (Digital Negative - stores raw images with raw sensor data of a camera).
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).
Much like WEBP, JPEG-XL is two different codecs in one. There's VARDCT mode, and Modular Mode. Modular Mode is normally used for lossless, but it can also be used for lossy as well. When you use Lossy Modular Mode, you get different kinds of compression artifacts than what you'd see in a JPEG file.
For Lossless: JPEG-XL wins, then WEBP, then PNG. (Sometimes lossless WEBP wins)
For Lossy: AVIF wins, then JPEG-XL, then WEBP, then JPEG.
Sorry for the dumb question, but I don't understand something in these graphs. Since it's x=speed and y=bd-r, is this test done at a fixed target quality/size?
I feel like JPEG XL could be a good RAW format for mirrorless cameras... something with huge flexibility but with the perk of being easier to view casually on other devices. And then that in turn could make it a more useful web format? Camera vendors are of course notoriously proprietary/stubborn.
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).
PureRAW can now output linear DNG's compressed with JXL. It's amazing the first time you use it seeing 25mb RAW files go in, get made linear, and pop out 8mb or 9mb, then toss them in your RAW developer of choice and still find all the dynamic range and such you'd expect from the original RAW. I'd been doing that on my own with a script that called Adobe's DNG Converter, which has the same capability, to convert older versions of PureRAW's linear DNG to JXL-based DNG files, but that's no longer necessary.
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?
You are thinking of DNG which is more of a container format. It can use multiple image formats internally to record the actual image, one of them being JPEG-XL.
iPhone raw images are actually a jpeg xl inside the DNG.
True. I would love to have lossless images (and video) out of my devices still. Not as a replacement for RAW but as a middle ground between RAW and lossy JPEG.
Not for quality reasons primaily but because keeping the first stages of the processing pipeline and the archival branch lossless solves some headaches.
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.
"Web optimised" really means "internet transfer optimised". Eg, the benefits would also be there for native apps that are downloading images from the internet, and they're not the web.
In practice "web optimized" is a soft copyright control where the image is read-only to the extent the only readily available software that can open it is a web browser.
I'm sure this is right about all the technical things, but the stuff about the requirements of a format for the web misses the mark IMO.
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.
Professional web developers want to create a great experience for their users, so they go beyond simply serving whatever comes off a digital camera.
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.
In the post, I say "I think WebP was a bit too narrowly scoped"
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.
Wasn’t WebP pushed pretty hard by Google for several years, until the (ever shrinking) rest of the ecosystem sort of caved in? My impression was that there wasn’t much interest until it became more or less inevitable because of that.
Can whatever the next new image format for the web will be please have a JSON block at the start giving
- dimensions
- filetype
- minimum required decoder version
- lossless: true/false
- a list of alternative URLs and mimetypes to older image formats
And it doesn't have to be JSON, as long as it's in a fixed location (looking at you, AVIF and JPEG), extensible and can be decoded by just reading the first 8KB or 16KB.
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)
How ergonomic are the modern AVIF encoders? I like libjxl (and cjpegli) because they are really good at generating reasonably compact, high-quality images.
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).
Lossless was discounted due to webp, but doesn't webp lossless only use 8bit depth RGB? (I think it is important to have a separate file extension for lossless stuff anyway, otherwise it gets confusing quickly)
I'm active in many art communities on the web for whom being able to view and share lossless images are table stakes. Also many other communities for which being able to view and share lossless screen captures is fundamental.
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.
If you're counting by absolute numbers, 90% of the web is probably YouTube, Facebook, Instagram, Twitter, Bluesky, Reddit, TikTok and the other major silos. I don't think those should be able to define all the web technologies for everybody else.
> 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.
count .png-s in the web. There's a lot. And .jxl's lossless is much better than png's. Basically any image with sharp lines (screenshots, image of a button etc) or gradients should be lossless.
We could get better compression using a custom encoder, however with webp the browser decodes off the main thread, copies the resulting data to GPU memory and caches the images for us. All very useful on the web!
It may not be as widely used as lossy, but it does have valid uses that lossy just can’t substitute and the web needs to accomodate for. And the space savings offered by JPEG XL seem pretty great in that regard.
‘The average Web consumer’ may not need lossless, but a non-negligible minority very well might, hence why lossless should absolutely be on topic.
JPEG XL is an open format with a libre reference implementation, usually compresses better than WebP/PNG, and supposedly has plenty of room for improvement still (in said implementation). Add to that its versatility in other areas and the fact that it seems to have generated widespread interest (much unlike WebP in its time, from what I recall), and I think campaigning for it makes perfect sense.
I can tell you that I don't care if the AI slop used in everyone's AI generated blog is lossy compressed. In fact, expecting it to be of such import that lossless is required is pretty farcical.
I have a lot of basic questions about the CVVDP graph. Is the X axis encoding or decoding speed? Is higher better on the Y axis? What format is Aperture? I assume "aom" is AV1 but it wouldn't hurt to document it.
x-axis is encoding speed, Y-axis is BD-rate where higher is better. aperture-alpha is an upcoming encoder from Halide Compression, no more details than that. libaom and SVT-AV1 are both for AVIF; libaom is the AV1 reference encoder.
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.
SVT-AV1 is also more than just open source in name only; development and discussions happen in the open; with many community forks that’s now getting upstreamed/merged.
It is a true open source project; not just an open source license.
SVT-AV1-PSY was the first fork, and I created it. When the project matured, the maintainers reached out directly to get things merged – I can confirm it is a great project with great people who are very easy to work with.
I would argue that even if JPEG XL isn't the best choice for Web images, if browsers don't support it then that will widely hinder its adoption for its non-Web use cases. Would you agree?
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.
> I would argue that even if JPEG XL isn't the best choice for Web images, if browsers don't support it then that will widely hinder its adoption for its non-Web use cases.
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.
> 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.
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?
HDR is something many photography enthusiasts are interested in, and the ability to losslessly transcode from JPEG to JPEG XL (and back again if you have to) is actually IMHO the "killer app" for the format. Many people have years of irreplaceable family photos in JPEG format, and being told "you can fit 30% more photos on the same hard disk without any loss of quality" would certainly sell me on converting my photo library to JPEG XL. (The jpegxl.com site says "up to 60% smaller" so I'm going to guess that 30% is a safe average gain and it might be more).
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.
I think it is a potentially good camera format, good medical & scientific imaging format, good RAW compression format (Apple uses it in some newer iPhones for this), good media interchange formats for tools like Photoshop (think about storing all of your layers inside of one JPEG XL that's fully compatible with .psd files), and more. It is incredibly expressive and versatile, which is what makes it so risky on the Web.
What do you think about the fact that most perceptual quality improvements in SVT-AV1 have been almost only driven by external, non-paid enthusiasts such as yourself while the maintainers have been basically only targeting VoD and RTC?
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.
Thank you for an interesting article. You’ve helped AV1 come a long way!
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.)
It would be nice to see the actual R-D curves for the codecs instead of compressing them into a single number. Also, what is BD-rate computed with respect to, jpegli at p0?
those issues aren't real. they're nuicense suits by a patent troll. a couple companies will settle cause it's easier and cheaper, but if they ever try to go after someone big they'll fight it and get the patents invalidated for covering 30 year old work
I like how every time we have a codec fight no one seems to care very much about how long it takes to encode these files. Like I get it, the amortization schedule often works out, but there are scenarios where images need to be generated dynamically and will only ever be downloaded once.
It's very hard to beat the encoding performance of libjpegturbo, even with an asic.
> It's very hard to beat the encoding performance of libjpegturbo, even with an asic.
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.
If you want to move the bar to quality for your strawman, then libjpeg-turbo is not even close in image quality to plenty of encoders, such as jpegli crush it. For compression size it also loses to modern libs. There is no metric that libjepg-turbo wins at nowadays, not even speed.
Then, if you care to learn, there are extremely high quality, lkely far beyond old software like libjpeg-turbo, use in DoD projects, satellites, medical imaging systems, commercial cameras systems, and plenty of companies that sell such chips and IP to embed in ones own ASIC. There is zero technical problem taking an opensource project, turning that exact code into an ASIC or VHDL one can put into any ASIC, an so the best ideas are reused in hardware all the time.
Alma Technologies, CAST, intoPIX all sell such cores that are integrated throughout the industry, embedded everywhere, and can be bought with an ever improving host of features.
I kind of settled on avif. I am not at all implying avif is perfect, in particular at high compression I notice the quality isn't quite as good as often advertised. For similar size compared to jpeg, avif is divine; and I also found avid better than webp in my own tests, so I switched to it. I don't quite see JPEG XL being really significantly better though. I think a really big problem here, even aside from Google trying to force deadlock people into its evil monopoly structure, is that we have competing formats (avif, jpeg-xl, webp) and that's IMO not so great when we want to have "one format to rule them all" that's better than jpg or png or gif. JPEG-XL is kind of a late starter here; if it is not really significantly better than avif or webp then I do not see it will gain any real foothold in the coming years.
If JPEG XL doesn’t become useful on the web, is it really likely to become popular with camera manufacturers, professional image editing tools, etc?
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?
> If JPEG XL doesn’t become useful on the web, is it really likely to become popular with camera manufacturers, professional image editing tools, etc?
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.
You used to be able to DoS the user's browser by sticking thousands of tiny animated gifs on the same page. You can't do that any more (AFAIK) because that's a bug so the browser developers fixed it. This is the same thing.
It's odd that apple didn't proactively guard against such concerns when adding a new format.
Most people using dedicated cameras shoot in RAW, then use a program to process and export the photos afterwards. So camera manufacturer buy-in isn't super important.
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.
The second paragraph doesn’t follow from my question, because it assumes JPEG XL does become useful on the web. The author believes AVIF is too far ahead already.
I suspect the name alone will help drive adoption, especially from non-technical people. Heck, I'm reasonably technical myself (but not expert in image formats) and my first instinct on encountering AVIF was to say "AVIF? Does that stand for AVI File?" And I would have assumed that it's a video format, not an image format. Whereas JPEG XL would have everyone who has ever used a digital camera saying "Ah, it's got JPEG in the name, that means it's a photo 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).
For me, the name JPEG XL evoked a feeling of “this is going to be a lossy-only format with visible artifacts when used on raster images”, so I don’t think it’s a good name.
There’s also a migration path where jpeg can be converted to jpeg xl losslessly. You can convert a jpeg to jxl then back to jpeg and its byte for byte identical.
JXL is moments away from having almost universal web support. Safari supports it already, Chrome and Firefox are already set to turn the flag on by default in the next releases.
Web publishers should definitely be stripping metadata at least, and transcoding isn't much harder. For anyone who cares about bandwidth, transcoding to efficient formats is non-negotiable; if you don't, then why do anything? Just ship PNG, who cares?
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.
> Web publishers should definitely be stripping metadata at least
No, they shouldn't. Not blindly. Metadata can include copyright license information, such that stripping it violates the license to reproduce the image.
Had a lot of the content in this article came out 4 years ago I would have agreed. At least we finally don't have a fake Image Coding Comparisons [1] that tries to undermine JXL.
Ignoring AOM and AV1, I was the first few on HN apart from its author supporting JXL from the start, I would argue the biggest case against JPEG XL is JPEG li.
Jpegli offer enough quality improvement and advantage without introducing an entirely new codec. And all of a sudden the bar for next image codec now needs to be even higher.
We all know these aren't purely technical reasons, it's to break the monopoly of one Internet Company's decoder format portfolio. You can't let one Fruit Company's format be the thing either, so it's basically a L for engineering but a W for pleasing everyone TBF.
AVIF is royalty-free, with open-source implementations not developed by Google. Google's implementation is libaom; as you can see, SVT-AV1 beats it. SVT-AV1 is developed by a number of companies – historically Meta, Netflix, Intel, independent contractors, and others. I worked on SVT-AV1 myself. I don't see how this is a bad thing for everyone, even if Google drove standardization of AV1?
There were something like 40 companies involved in AV1 standardization. Quite a few technical contributions did not come from Google, and quite a few of Google's proposals were substantially modified by feedback from others before they were included (and not all of them were eventually included).
Source: I lead Mozilla's technical contributions to AV1.
It saddens me to see discourse on the internet about AV1's ancestry being focused on Google's VPx line of contributions, while diminishing those coming from Daala (entropy coder...) and Thor (QMs...), as well as inter-company collaborations (CDEF).
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.
You're welcome. That is what those image sets were for.
I was really happy Thomas Davies added quantization matrices to the spec, because if he hadn't, I would have had to. Fortunately, he did a good job. I am glad someone is finally using them. Don't sleep on per-segment quantizer deltas, either.
Me and a bunch of friends (mainly Clybius and Yiss/Uranite), after I was constantly saying daala was a great low complexity visual metric that should be added back to AV1 encoders, we decided to implement it into yet another svt-av1 encoder fork:
https://github.com/Uranite/svt-av1-tritium#from-svt-av1-hdr-...
It has been showing great performance overall and is quite nice.
It can work on CDEF, like it did in aomenc-av1 back in 2018/early 2019. It does so very well.
We've also implemented deeper controls, but that is still experimental.
Thank you so much for your work on daala stuff, as it's been one of my many inspirations in the field.
HEIF isn't an Apple owned format, most modern cameras have it as an option alongside JPEG now. The situation is JPEG is woefully outdated, lacking in HDR support and dated compression. HEIF is technically much better but patent encumbered.
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.)
These sorts of things always talk about progressive rendering. Who actually likes progressive decoding? Like...what year is it?
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 disagree with this. If I'm in a poor connectivity situation, a preview can help me quickly decide if an image is worth waiting for.
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.
You've left some 36 comments on this submission (which is honestly weird as HN usually rate limits to avoid that sort of aggressive participation), and your comments seem extremely...cherry picked. In another comment you dismissed the bandwidth savings of JXL because connections are so fast that eh, who cares, and in this case you herald the importance of progressive rendering because connections are so slow.
Are you the author of the submission? Literally never seen someone so motivated in a conversation before.
The chart showing jxl-rs taking 1209ms to decode a 5456x3632 image in a single thread is a little damning, but is there an equivalent benchmark showing multithreaded decode performance? Clients tend to have an abundance of threads these days.
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.
It’s a measurement error: the `hyperfine` command uses `jxl_cli --speedtest` which, by default, does a warmup run that ends up in hyperfine’s measured time.
The time would be less, but you still need to power those cores. Single thread performance can be a good indicator of what it'll do the battery on your phone.
CPU power is proportional to frequency^2. Running on 4-6 little/efficiency cores (which are widespread on mobile) is likely faster than one big core, and uses less energy.
jxl-rs is a relatively new implementation, not yet optimised for speed. It’s hard to say how much faster it’ll get, but I assume it would at least get near libjxl’s level.
I wasn't really sold on the argument initially, given they admit there's some real lossless usecases, but this is a good bit from the conclusion:
> 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.
There exist lossless use cases, for sure. I think most people would be well-served by high-fidelity lossy that saves a lot of bits while still looking perceptually identical. Whoever isn't served by that most likely doesn't care about size savings, and can stick with lossless PNG.
The problem with that is that the idea many stakeholders (especially big platforms) have of "perceptually lossless" is actually compressed to hell garbage. The only way you as a user can ever guarantee actually perceptually lossless is to use a fully lossless format.
Because of Gianni's great post, I've decided to go full throttle on rewriting and finally publishing the JXL vs AVIF post after deciding to partially shelve it last year.
This should be especially interesting looking at the differences between my testing and Gianni's.
Worth noting that this progressive AVIF, when viewed in Chrome, has only two states: a "base layer" which pops in around 8KB, and the full image which appears 270KB later. The comparison JXL continues to refine during most of the download, so it winds up looking substantially better than the AVIF at around 95KB loaded, and looks pretty good (almost as good as the full 280KB AVIF) by 175KB. I suspect that there are a lot of knobs to turn for both progressive modes, but this particular case could definitely be cherry-picked to favour either codec.
Progressive AVIF is very flexible: it supports up to four passes, at configurable quality and dimension scaling levels. You can have any given pass reference up to two previous ones for refinement (thanks to AV1's strong inter-encoding capabilities), and you add filters to non-final passes (like blurring) to achieve a desired loading aesthetic.
That JXL page happens to use two passes, but the knobs are there to customize the experience to fit the use case.
I find it misleading to call AVIF's "up to four passes" "very flexible".
It seems quite limited compared to the JPEG XL ability to truncate the bitstream anywhere, or send the progressive updates for salient regions first [1].
> I find it misleading to call AVIF's "up to four passes" "very flexible".
Wow, what a way to misquote me. Let me repeat what I actually said:
> Progressive AVIF is very flexible: it supports up to four passes, at configurable quality and dimension scaling levels. You can have any given pass reference up to two previous ones for refinement (thanks to AV1's strong inter-encoding capabilities), and you add filters to non-final passes (like blurring) to achieve a desired loading aesthetic.
So, I re-iterate progressive AVIF is flexible, because:
- Intermediate passes in AVIF can look as sharp or blurry as desired -- you don't have that kind of control with JXL
- Intermediate passes in AVIF can semantically be different from the final pass -- very useful if you want to add a "loading" mark to the non-final passes to inform the user the image is still loading
- The four pass limit is A GOOD THING, as you want an image format to have a reasonable worst-case upper bound on energy consumption due to sum of partial decoding + display refresh updates -- there's such a thing as having "too many passes", and uncapping the limit would be irresponsible
- You can absolutely do saliency encoding in AVIF, as AV1's inter-frame encoding naturally allows for it efficiently
Ah, an accusation of misquoting. I actually quoted your exact words minus "is" and "it supports".
I think we disagree on the degree of flexibility, for sure.
A cap on layers (under user/browser) absolutely makes sense, but 4 at the format level is quite limiting, especially if you want to spend some of them on salient regions.
I agree that's possible, but not that it's efficient. You'd waste a few KiB on encoding skip blocks - AVIF layers represent the whole image, whereas JPEG XL can efficiently encode and update at group level.
How flexible did Jake find AVIF progressive in 2025? [1]
"it seems pretty limited. Only particular scaling values are allowed, and 1/8 is the smallest. Supposedly, additional layers are possible[..], but whenever I tried this, the encoder would error out, or explode the file size to ~400 kB, even at lowest quality. I guess that's why it's marked 'experimental'."
> Intermediate passes in AVIF can semantically be different from the final pass
I'm not sure if you're aware of this or not but juliobbv is the developer that fixed progressive AVIF, he is fully aware of how it works and how AV1 works in general.
"You'd waste a few KiB on encoding skip blocks"
This tells me you don't know how codecs work... skip blocks are not expensive to code, they are very cheap.
Jake's blog post is outdated by the way, the progressive functionality is much more advanced than it was at that point in time because Julio worked on it.
My conservative estimate is that a few-MP image with all but a smallish region encoded using skip blocks will spend a few KiB on that. This is very expensive compared to sending only a bounding box, hence it is unattractive for purposes of updating small regions with a whole-image layer.
I am glad to hear AVIF progressive has improved. But note that my original comment was: I find it misleading to call AVIF's "up to four passes" "very flexible". I believe that stands: contrasting the flexibility of (purpose-built) JPEG XL vs. the fairly strict limitations (inherited from video) of AVIF, I am astonished anyone would still call the latter "very flexible" by comparison.
Hi, I'm the author of the article you're quoting. AVIF was limited at the time of writing, but has since seen massive improvements, including progressive support.
Sounds like some strong assumptions here, particularly a stable and non-metered connection.
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.
why? in jpeg xl i get an image quicker and i can see it getting better, so i know it's still loading while the avif one looks stuck for the majority of the time, which makes it look already done loading and just low quality to me.
What exactly is AVIF doing in this case that I can't do with two <img> tags at a smaller size? I can easily create a thumbnail that beats the AVIF quality in less than the 5KB delta between the static and progressive version in Squoosh.
The quick answer is: you can have up to four passes. With progressive AVIF, you let the browser avoid rendering previous passes if a subsequent one has already been downloaded. It's more efficient and saves battery.
Is there a way to have fast on-the-fly WebP encoding? When i checked it, it was unusably slow (multiple seconds for large images), but maybe that was the implementation. That alone made JXL far more interesting to us.
> Progressive rendering (which AVIF supports) decodes a low-fidelity rendition before the full image arrives. AVIF didn't support progressive rendering for a while, and during that time I believe it was deeply oversold. Now that libavif has implemented it (it was always possible), the conversation appears to be over.
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.
> A lower resolution image layered below the full resolution image, which is loaded and rendered first.
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.
> A lower resolution image layered below the full resolution image, which is loaded and rendered first.
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.
You're wrong. AVIF does support spatial layering where the full-resolution image is derived from the lower-resolution layer, and cannot be decoded independently.
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.
Not sure if the difference is materially relevant to UX at all. JPEG XL achieves progressive rendering at a great cost to its selection of coding tools, so I side with AVIF's approach.
Yes, if you look at the demo, the "progressive" AVIF loads a visible image at 8.5KB, and at that point, it looks better than the progressive JXL. However, that is ALL the AVIF shows until the image has fully loaded. At around 98KB, the JXL looks significantly better, and at around 240KB already looks really close to the final image, while the AVIF still looks terrible. At 280KB when the AVIF finally loads, they look identical.
BTW, you can configure the AVIF encoder to have another in-between pass or two so the quality jump isn't as big. The JXL folks just happened to go with only two total passes.
Thanks to AV1's inter encoding, overhead is overall minimal as each pass can refine on previous ones. Think of it as a mini-video. Because of this, in the case of images with a lot of repeated patterns, progressive AVIF encoding can actually result in more efficient images!
Looking at the demo linked in the blog post, I can make a similar quality thumbnail for a smaller size than the delta between the static and progressive AVIFs
The quick answer is: you can have up to four passes. With progressive AVIF, you let the browser avoid rendering previous passes if a subsequent one has already been downloaded. It's more efficient and saves battery.
I prefer the UX of the AVIF example here. I think it's better to have a progressive phase where the image is obviously "not ready", yet you can still determine important details like the subject of the image (unlike a blurhash), rather than a phase that you could mistake for complete, but looks bad in parts.
Progressive rendering is just a different way to layout the pixel data. Embedding a thumbnail is storing two distinct images. In other words, progressive rendering should be more efficient space and bandwidth-wise.
The DC coefficients in a progressive JPEG are literally an embedded thumbnail (a 1:64 copy of the original) right? Is the question if the second "layer" replaces the thumbnail or layers corrections on top of it? It wasn't clear to me which AVIF does.
According to this source [1], a second layer can progressively provide the rest of the image data:
> Note: AVIF supports two types of progressive decoding. Spatial scalability can be used to offer a lower resolution image for network constrained users and 'progressively' provide a higher resolution image by sending just the additional data required to fill in the high frequency details. Quality scalability offers a similar progression by steadily improving visual quality with each render.
That is totally not what I expected. Though it's not clear to me how exactly you achieve it.
AFAICT progressive AVIF is actually using the "spatial layers" feature of AV1, which was designed to embed multiple resolutions of a video in one bitstream. The limit on four spatial layers comes directly from AV1. The previously decoded layer/progressive-step becomes a reference frame that the next layer can draw from just like eg the temporally-previous frame can be referenced by interprediction.
Of course it does, with one you have to render twice and store two layers which costs you both compute and storage. With the other you can just take the image mid decode at a point and display it. Single decode operation, no layer mess.
You have to render twice and have 2 different layers in both scenarios. Writing to a buffer / layer is not an atomic operation so they need to be separated.
The difference matters, as it means that AVIF's "progressive decoding" serves no technical benefit and is only a minor ergonomic benefit: On a website, you could achieve the same effect simply by layering two <img> elements on top of each other, one with the thumbnail and one with the final image.
If layering to <img> elements is fine for your use case, then it simply means you have no need for progressive decoding.
How does progressive rendering actually that most OS GUIS are not multithreaded ?
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.
Thumbnailing happens in a background process and shouldn’t block the main thread; rather hangs are usually because fetching xattr over SMB is slow and Finder will block until it’s enumerated the metadata of every file in a folder.
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.
The form of JPEG-XL that can lossless convert to/from traditional JPEG is exciting tech that should be adopted universally. The non-backwards-compatible version of it seems redundant with AVIF.
Author entirely misses the case for what many people want it - re-compressing old JPEGs that they have no better sources for into JPEG XL with out decode-encode loss
> 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
"but strong mode-decision pipelines can pick the right mode for the job and save lots of bits" - citation needed. just a bit above author claims lossless is not useful for web, disregards modular jxl that uses nearby pixel predictors (even though it can be lossy, too), then produces this claim against vardct. spoiler - dct frequencies ARE using "nearby pixel values"
Depends on your location. While I have a decent internet connection at home, the mobile one is trash. Good for IM and not much else.
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.
Formats that aim to be web standards should try not to be patent encumbered. There was a lesson to be learned from the Unisys debacle in the 1990s. If you don't want to reencode for the web, use a device that captures in a format that can be shared on the web.
You should never transcode lossy source files because there is generation loss in quality.
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.
Well, JpegXL does have one really cool feature: you can transcode jpeg to jpegxl (and back) losslessly. For jpeg to jpegxl it'll save something like 15-20% in size.
Rather than AVIF or JPEG XL or WebP or HEIF or any of that stuff, my actual ideal choice that I wish everyone used is just good ol' JFIF. I like that I can take a file downloaded from the modern Web and open it on my '90s and 2000s computers. I emphatically do not care that it's some marginal percentage “““more efficient””” — more efficient for Google and Apple and Amazon and all the other silo providers who are moving more data every day than I will produce in my entire life. But why should I have to suffer backwards-incompatibility for their sake?
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†.
Lossless dismissed? 11% isn't nothing, that's trillions of images out there. Mozilla's own data shows JXL lossless beating AVIF and WebP. That's the one weakness of avif that bothers me, for lossy and speed it is brilliant. Companies may have another itch with the misleading licensing:
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.
I agree that the choice for JPEG XL is mostly politically motivated: it isn't Google. And its name is derived from JPEG, which is an IETF standard which gives it more clout.
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.
The article makes a good point: JPEG XL is amazing but not specifically for the typical Web use cases, compared to AVIF. But the conclusion doesn't follow. Having an excellent and versatile format supported by browsers is very useful!
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.
+1, this is super unfair to show the one point in time where AVIF progressive looks better - right after it receives its 'preview' (which as you say is 4x as big as JPEG XL's).
I value integrity, especially when communicating results. This is shameful.
(Disclosure: I worked on JPEG XL)
I’ll just repeat another comment here:
“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
I note you made no response to the objection about representing a temporal sequence with a single, nonrepresentative and cherry-picked, screenshot.
As to bad experience, that seems like a legit personal preference, but disturbingly un-nuanced and absolutist if intended to apply to everyone.
When on a train with spotty wifi or frequent tunnels, I would actually prefer to see whatever arrived. Someone on prepaid data might want to truncate at ~100 KB, no matter what the website owner or browser PM thought.
> that they may mistake for complete but poor quality
That's what UI is for - show an indicator that it's not complete and avoid the confusion, bringing back to the original issue
But also, that's not "obviously a preview", so you have the same potential confusion here
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.
Depends on the user. Some users are more sensitive for flashing images. Some users have very slow or unreliable network connection. Some sites have bigger images. Some sites (such as ecommerce) have higher quality and resolution needs.
Some users have uncorrected astigmatism. In the general population, the average uncorrected astigmatism typically falls between 0.50 and 0.75 diopters (D), and ~15 % more than 1.0. The high astigmatism people will see images blurred in any case and don't benefit from the fine structural detail JPEG XL can give. People with glasses and the lucky ones with low astigmatism will see the details clearly.
Sometimes passionate ends of different quality of vision seem to have a discussion on what makes sense as the web quality, with one emphasizing quality 40 being more than enough and another requesting a quality of 95.
The same kind of individualism exist also in temporal cognition and perception.
The quality of the preview layer is somewhat under the control of the user though.
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)
That's a good point.
It's an absolutely ridiculous point, and the guy you're responding to (who has commented almost 40 times in this discussion) has a hilariously slithery opinion that somehow always finds a way to hold every finding against JXL.
Personally I don't like progressive rendering at all, but it's interesting that this same guy claimed elsewhere that it's super important on a very bad connection to get an early hint of what an image is. When someone points out that the "the results speak for itself" cherry picked example is absurdly misleading, and in most cases JXL is vastly superior at that case, instantly their opinion changes such that it shouldn't look like a poor quality image but it's somehow also a win that AVIF takes longer to give you anything at all to look at.
Which is incredibly weird, given that AVIF also gives you a terrible quality image, it just takes longer to show it. So it sounds like they're completely against progressive rendering? Unless they think it gives AVIF a benefit?
But it's an amazing demonstration of someone with an agenda. Utterly bizarre.
I also called AV1 short-sighted for not including an alpha channel, and corrected someone who claimed jxl-rs was single-threaded. No agenda here - I'm just correcting misinformation and stating my opinions.
I'm not against progressive rendering - I fought for it to be part of the jxl-rs integration in browsers. I've written articles about it https://jakearchibald.com/2025/present-and-future-of-progres....
Just because someone has a different opinion to you doesn't make them part of some grand conspiracy.
Agreed. Browsers should support general-purpose image formats. I'm not interested in another “web codec” that's not good for anything but passive delivery.
> Maybe re-encoding my website JPEGs to gain 20% size is not worth the 33% longer decode
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.
Sorry if that was confusing, I have edited my post to clarify a bit: That sentence was about a feature specific to JPEG XL, which is that if you have JPEG files you can re-encode then as JPEG XL to save space without any loss of quality. It's nice for peace of mind, you can bulk convert a large archive and you know you still have the same pixels everywhere (later you can even turn them back to JPEG without loss if you want). AVIF cannot do that. Now if you are OK with some loss in the conversion, you can also do much better than 20% with JPEG XL.
Worth mentioning that someone else in the comments converted their large library of JPEGs to JPEG XL for exactly this reason and only realized afterwards that they lost a ton of image metadata from the EXIF tags. This probably isn't what you would assume would happen for a bulk 'lossless conversion' so if you're going to do this then make sure you're validating the metadata too (if it matters to you).
That's probably not the case. `cjxl` preserves metadata, but early on, some popular metadata extractors (exiftool, exiv2) silently ignored it.
I have no issue with EXIF here. Compressed JPEGs were reverted with zero data lost
That 20% gain is for the lossless re-encoding. It's not possible with .avif AFAIK. If you allow minor loss, jxl can save much more space.
It sounds like you lossily re-encoded lossy JPEGs to AVIF, am I reading that right? If so, you're automatically suffering from generational loss there, it can't be the basis of any coherent argument.
The entire article is extremely cherry picked, and it's notably that there are a couple of people leaving dozens of comments in here each (which is odd as normally HN gates that sort of gross overrepresentation). Like >10% of comments in this 300+ comment discussion is one single person, endlessly changing positions based upon what makes JXL worst.
It's bizarre. I've never seen a format see such ridiculous attacks.
If you're going to make claims of bad faith about other users like that you should link and quote.
>Maybe a lossless re-encoding of my website JPEGs to gain 20% size is not worth the 33%
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.
> Maybe a lossless re-encoding of my website JPEGs to gain 20% size is not worth the 33% longer decode,
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
Well it obviously depends on the connection, but at 3g speeds and higher, the decoding time outweighs the fairly minor bandwidth saving.
And if you're displaying a cached image, the bandwidth use is zero, but the decoding still happens.
> And if you're displaying a cached image, the bandwidth use is zero [...]
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.
I dont know how you calculate that, but for my phone I get the payoff (given a 30% size reduction) to be positive below anywhere from 30-43Mbps.
When on celular, even 5g, I am pretty often below that.
https://random-stuff.jakearchibald.com/apps/img-decode-bench...
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.
People really, really like to try to save up on the matches, so to speak. Sometimes literally: there was a short period of time during Khrushchev's rule in the USSR when the natural gas was made free for the populace. Well, the matches still cost money (1 kopeck for a box of 50 matches), so lots of people would just not turn the stove off, instead always having it burning the smallest possible flame when not in use.
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.
It depends on your network speed, how big the image is, the compression rate of the image, and how fast your hardware is.
A potentially major issue I have with AVIF is that because it is based on a video format, any hardware decoding support AVIF will get is likely to be restrained to common video scenarios. This can result in eg. only 4:2:0 YUV being supported by hardware decoders, as that's the upper limit of AV1 Main Profile (and thus the limit of AVIF Baseline Profile). And 4:2:0 is just a poor fit for certain categories of images (like various kinds of illustrations, screenshots, etc). I would not be very happy about a web where lossy 4:4:4 image compression would be heavily discouraged with modern formats.
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.
> And 4:2:0 is just a poor fit for certain categories of images (like various kinds of illustrations, screenshots, etc).
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.
4:2:0 is the main reason why most games look like crud once they've passed through any mainstream video encoding pipeline. That being said, the bitrates used for streaming games and VoDs are so low everything looks like mush anyway and millions still watch that.
Do you have an example comparison?
Luckily, 4:4:4 AVIF is supported in Firefox, Chrome, and Safari, right now. This won't ever regress.
Browsers already fully support 4:4:4 AVIF and are not going to regress on this, as it would be a huge compat issue.
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.
Lossless AVIF encoding is inferior to JXL though, the article oddly dismisses lossless as a valid case for the web so it ignores the core argument that lossless is critical for some type of content.
I find the hardware support argument far more compelling that diminishing the value of lossless publishing.
I think the need for lossless images within a web page is extremely niche. I've used them before when comparing image codecs, but that's about it.
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.
> I think the need for lossless images within a web page is extremely niche.
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).
This is a thread and article about JPEG XL on the web.
JPEG XL on the web does not arrive there ex nihilo: there is a production pipeline that creates and puts files on web servers and points to those files in HTML tags.
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").
There have been a number of experiments to use hardware decoders for images in browsers, all of which have fallen flat; not even Safari does it for AVIF or WebP. Thus, 4:4:4 AVIF is supported absolutely everywhere. Feel free to try it now. I can see how hwdec is compelling for JPEG XL in theory, given how slow decoding is.
In the modern age image decoders need to handle untrusted inputs, and the big players rarely use hardware image decoding, even when it's available, because it's so hard to rely on its memory safety.
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.
All Browsers do use hardware decoding for video though, I doubt safety is a major factor.
The factor is latency. Software decoding takes milliseconds.
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.
Isn't the same true for video decoders, though?
Wait, DAIZ!? I genuinely did not expect to see you here chiming in. Still appreciate much of your 10 bit anime advocacy from way back.
I don’t think hardware decoders are used for images. They are light enough you can do it in software.
AVIF's support for non-photographic images is covered in the article. It supports lossless.
Yes, I know the format supports it. The question is, will hardware decoders built primarily around video use cases? And if those kind of hardware decoders end up forming the majority of hardware decoders for AVIF, will we end up in a future where using the full range of the format is heavily discouraged because it won't be supported by hardware decoders?
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...
AFAIK WebP has never used hardware decoding and no browser uses it for AVIF now.
It's not lossless if you have to convert to YUV first.
You are correct. However, AVIF does not require this conversion. For lossless it supports an "identity" matrix coefficient, which means no conversion.
It isn't particularly efficient in terms of file size, but as others have said, lossless images within a web page is extremely niche.
It has YCgCo too, which should have the efficiency of YCbCr while being lossless.
I'm not super familiar with AV1/AVIF but I do have extensive experience using h264 for desktop streaming, and all major implementations support 444 in hardware and software, and I doubt more advanced codecs/image formats have a limitation like this. Asked ChatGPT and it also claimed there's no problem with 444 and AVIF/AV1.
Then chatgpt missed an obvious issue, nvidia definitely have had shortcomings in the hardware implementation of coder/decoders only supporting 420 in nvenc/nvdec. One obvious problem with that was that it affected premiere.
We have been using NVENC with 444 and h264 in production going back years and HW as old as Turing.
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.
> I'm not super familiar with AV1/AVIF but I do have extensive experience using h264 for desktop streaming, and all major implementations support 444 in hardware and software, and I doubt more advanced codecs/image formats have a limitation like this.
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.
I'm pretty sure 444 h264 fails to decode on iOS Safari due to poor support in the hardware decoder.
Strange blog post. Given that it's from a developer of proprietary and paid commercial encoders, the inclusion of their upcoming "aperture-alpha" encoder on the charts that are purportedly about JPEG XL makes this feel like a marketing piece of some fashion. Certainly, they advertise their Iris-WebP encoder throughout the post, with an implication that if you haven't paid to the author for it, you're not using WebP correctly, I guess?
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.
I expected one of these bad-faith readings, so I can address that Aperture is mentioned once and Iris-WebP is only shown in numbers, because I have access to these encoders and thus they cannot be ignored. The only encoders I heavily advertise here are the incredible open-source AV1 encoders, that I contributed to for free and I think people should use. Also, not sure where you infer that point about WebP; libwebp is a fine encoder.
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.
> 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.
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).
Worth mentioning: their demo only uses two passes for progressive AVIF -- it's just their choice. You can have up to two more intermediate passes, so at 30% you can have something much closer to the original image.
Even still, the demo proves that AVIF can deliver a usable image with up to 3x as fewer bytes as JXL!
> their demo only uses two passes for progressive AVIF -- it's just their choice
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.
> AFAIK "their choice" here is just the default
Well, the default in avifenc can always be changed. Do keep in mind there's no "one size fits all" implementation, as customers desire different loading tradeoffs. You might be surprised, but during testing (outside HN), we've seen people actually prefer "2 layer" loading.
I'm surprised HN likes progressive loading to be more granular, and use that to push back. I'm wondering if there are generational differences at play? Maybe it's the difference of being used to the blurhash vs. old-school JPEG loading experience.
Anyway, the more expressive mode in avifenc is `--layered` (yes, I know the name is weird).
> Usable for what?
Well, focusing on the "Poke bowl" example: with AVIF you can clearly tell apart each ingredient at 8kB. You can derive enough semantic understanding just from this base layer. Having decent edge preservation helps significantly here.
On the other hand, JXL is just too blurry at 8kB to make sense of the image -- only the egg and carrot are recognizable, maaybe the cucumber? IMO JXL needs the pass at ~28kB to make everything salient, including sprouts and beet. Yes, I know there are subjective effects at play and I'm sure we'll disagree on exact image thresholds, but recognizing objects within an image is so important in real-life use cases.
> Well, the default in avifenc can always be changed.
Sure, that was kind of my point, but I think it's important to point out it's the default. I had read somewhere else in the comments that they just "happened" to use 2 passes (that I now realized was also written by you), that I interpreted as them maybe making a bad decision in the comparison page, but I think it's very reasonable to use the default. I also usually prefer to use the default unless I have a good reason not to do so.
And I think that `--layered` is fine as a name, and I had realized that as the docs were right below the docs for `--progressive`, which do mention it encodes a "layered image", although it could use an example on how to use it effectively.
> I'm surprised HN likes progressive loading to be more granular, and use that to push back.
Not necessarily? Using more passes would probably help in specific the metric in the comment I was responding to, by making AVIF possibly look better on a larger fraction of the decoding time. I mostly interpreted your comment as saying that it would have been better if they used more passes, and that's on me.
The reason I was comparing the breakpoints in the decode time was because I was responding to an allegation that "even there, AVIF looks better for 90% of the decode time", and I decided to point out that's not not the case and chose some pretty clear breakpoints that are very hard to argue about. Very subjectively the actual breakpoints could be a lot earlier, for the Poke the AVIF only looks better (in the sense that you can figure out what's there better) in a 6% range (from 2 to 8%) or maybe 9% (from 2% to 11%) of the decode time. There are many (relatively big) seeds that are just not there on the AVIF side, but you can distinguish on the JXL side, even if they're blurry. Percentages used in reference to the JXL side.
> I'm wondering if there are generational differences at play? Maybe it's the difference of being used to the blurhash vs. old-school JPEG loading experience.
Hmmm I don't know, maybe. TBF with today's usual internet speeds progressive loading isn't as important as it was as more steps make less sense if you have a good connection.
> Well, focusing on the "Poke bowl" example: with AVIF you can clearly tell apart each ingredient at 8kB. You can derive enough semantic understanding just from this base layer. Having decent edge preservation helps significantly here.
Sure, I see what you mean, you can distinguish more image element in the AVIF example, that's true. I don't like the lack of consistency and some of the artifacts to the point where I'd prefer not using progressive encoding, so that's not what I'd call "usable", but that seems like a matter of taste. It surely does look closer to a "final image" than the JXL at that point.
As a note, I think what I'd prefer would be 2 passes, with the 1st pass being around how JXL looks at around 11% / 39 kB. You can get a rough idea of what's the image about and the elements on it, with roughly the right colors, but it's still clearly loading, so there's no confusion, and without many "artifacts" like the progressive AVIF in the example (no idea if AVIF is able to make progressive encoding in a way that's more "blurry"). The caveat is that more steps are better when it takes too long (more than a few seconds) so the user knows it's not stuck.
> Sure, that was kind of my point, but I think it's important to point out it's the default. I had read somewhere else in the comments that they just "happened" to use 2 passes (that I now realized was also written by you), that I interpreted as them maybe making a bad decision in the comparison page, but I think it's very reasonable to use the default.
Yeah, I can see that. By "happened" I meant that the default is good and serves a common use case, but also it can't be expected for a 2-pass AVIF to remotely match JXL's finely-incremental experience. The tricky thing is coming up with a good-enough compromise -- one extreme wants their first pass be more like a blurhash (quality 0, 1/8 scaling), while the other wants a medium quality image (quality 30-40, full scaling), and everybody else is in between.
For reference, `avifenc --progressive` is currently quality 10, 1/2 scaling.
> Hmmm I don't know, maybe. TBF with today's usual internet speeds progressive loading isn't as important as it was as more steps make less sense if you have a good connection.
Interestingly enough, I frequently get reminded of spotty internet connections -- turns out you just need to take the subway hah. This is why I'm so passionate about progressive image loading in general.
> As a note, I think what I'd prefer would be 2 passes, with the 1st pass being around how JXL looks at around 11% / 39 kB.
That sounds like you want your first pass be half scaling, around quality 25:
``` avifenc --layered -q 25 --scaling-mode 1/2 image1.png -q:u <quality> --scaling-mode:u 1 image2.png image.avif ```
`image1.png` and `image2.png` can be the same source image. You can blur `image1.png` or even better: add a tiny "loading" icon to indicate the image is still downloading.
Thanks for the detailed explanation and example!
>Even still, the demo proves that AVIF can deliver a usable image with up to 3x as fewer bytes as JXL!
I was taught to be skeptical of objective benchmarks; Why should we trust them when people are benchmaxxing?
https://habr.com/en/articles/700726/
I'm not following.... the demo involves you look at images as they get decoded. Objective benchmarks are beside the point here.
Oh, i left the wrong quotation whereas i intended to reply to another message. Throughout the blogpost you're quality matching and comparing encoders based on objective metrics whereas it'd be more telling to get the crowd subjective comparisons. I think it's pretty evident that most codecs benchmaxx to the point of objective metrics being useless.
Ah, no worries! I can't speak for Iris and Aperture, but both "tune IQ" modes in SVT-AV1 and libaom had extensive human evaluations to make sure they weren't accidentally being benchmaxxed at the expense of subjective quality.
Surprised and disappointed to hear "bad-faith reading".
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.
Let's be productive:
https://pengbins.github.io/aomanalyzer.io/
This takes 10 seconds.I was even more surprised & disappointed to see this dismissed as an ad for my company. Think about how fantastic JPEG XL would be for my company: an image codec with tons of fans and an extremely weak reference encoder? Sign me up. I'm writing this as someone who wants a better Internet.
If you're sensitive to tiling artifacts, you must deeply dislike the way JPEG XL images look. Every block of a JPEG XL image is effectively a small tile, because there is no deblocking loop filter (I talk about this in the article).
JPEG XL has two filters that are pretty much equivalents of what AVIF has, while AVIF has three; plus, tile boundaries are handled by the DLF. Your point doesn't really stand on two legs if it means to come to JPEG XL's defense here.
> Every block of a JPEG XL image is effectively a small tile,
Operative word here is "small", so it has different effect, thus doesn't imply same sensitivity trigger
By "small", it's meant in a relative sense. JXL's coded blocks can be as big as 64x64, and block boundaries can create visible seams. Example: https://juliobbv.com/pics/photo.jxl
These seams are especially noticeable in the background, and align with coded block edges. You can tell the encoder is trying to conceal them as best as it can, but this cannot be properly mitigated without a proper deblocking filter.
For comparison, AV1 tiles normatively go through the deblocking filter.
We can agree on wanting a better internet :)
I participated in the design of those filters, so no, I do not deeply dislike the way they look.
This gaslighting is not convincing. No matter how many filters AVIF has, I distinctly remember tile artifacts being particularly disturbing. More so than individual blocks, whose size and border effects differ; tiles are a straight line through the entire image.
JPEG XL does not have this problem because the design and codestream enables parallel decoding (thanks to per-group offsets encoded in the 'TOC'), hence does not require separate tiles.
It also compares the total time for jxl-rs's benchmark mode (which does a warmup and a test decode) for 16-bit RGB against 8-bit WebP to 4:2:0 YUV.
Hi there! I'm Julio (co-developer of libaom and SVT-AV1's tune IQ). Here there are some points worth mentioning, because I'm catching a whiff of bad faith with your comment that honestly needs to be called out:
- 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.
"For non-photographic images, the argument that “they should be vector images” doesn't hold up because many images could be vector images but aren't, and they can't be vectorized perfectly. “The world should be different” is not a justifiable defense against optimizing for the way the world actually is."
This is a good paragraph. I see people forget to apply that last sentence all the time.
Agreed. JPG is the most popular format for photography. PNG, the lossless format is great for diagrams and stuff with sharp edges. It can be "compressed" via dithering and quantization.
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.
Gif is a weird one because it's silently been replaced while keeping the name around. Virtually every software using the term "gif" actually uses a h264/vp9 video with no sound.
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.
The major blunder here is browsers refusing to support silent videos in <img> tags etc. so we end up with all these hacks. Instead we got animated webp that you can't use for progressive enhancement because it doesn't have its own mime type and browsers reported support for image/webp before implementing animation support. And webp is also very limited when it comes to inter-frame compression for no good reason at all.
Gif doesn't mean "no sound" anymore. Gif is more or less "short video", which broke a lot of assumptions at first but we have pretty much passed that transition and it makes sense for what they are used for today.
That ship has sailed.
Gif certainly does mean no sound. Look at discord, telegram or literally any app that says “gif” and it’s no sound video.
Those are messaging/communication apps,sound in those apps can be quite disruptive so that doesn't surprise me at all. It has nothing to do with the original gif, it is just that gif is now synonymous with short clip (with or without sound) and sound in that context is disruptive.
Go to google.com, search for images and select image type gif and you will get mp4s with sound.
Telegram's usage of "GIF" (any short video without sound) is incredibly weird and frequently goes against users' expectations. I wouldn't treat that as definitive.
I ... what? I've never heard anyone conflate the two--not teenagers, non-technical adults, or software people. Most folks know that "GIF" means "moving image that can be easily shared but has no sound and usually crap quality", not a video/audio clip.
Reminds me of when Imgur started trying to push changing gifs over to gifv, which were just mp4 with a strange new file extension. I didn't like their approach but it really was such an improvement on file size and quality.
Not to mention if you for some odd reason wanted to do gif-style animations, you can also do it with apng or webp. You shouldn't, real video format makes more sense, but even if you did there is still no reason to use gif.
Browsers only supported animated gif, not any other animated format
What do you mean? Most browsers support animated jpeg xl, avif, webp and apng just fine.
Perhaps the clue is in the past tense "supported". Nowadays browsers support many formats, but in the "olden days" gif was the only way to get animations in browsers without plugins like Macromedia Flash...
Support was added a decade ago (chrome 59 (2017), firefox 3 (2008)), so you have to go back quite a while.
also, don't forget - actual video format is better for animated stuff. Current default approach is .webm which is standardized .mkv container + vp9 (or av1) video + opus audio (usually no audio to as a feature parity to gif). IMO animated picture formats like .avifs are very backwards and don't add much
One advantage to animated AVIF is that it supports an alpha channel, which AV1 doesn't. But I guess that just points to how short-sighted it was for AV1 to omit alpha channel support.
I am sure that none of the `.gif` files on my computer have been silently replaced.
And there absolutely are cases where a lossless GIF is smaller than a lossy video format.
Precisely. Kind of reminds me of "Hoover" or "Kleenex". Coca cola even. It has brand equity which means it's not going away any time soon.
> Gif is a weird one because it's silently been replaced while keeping the name around. Virtually every software using the term "gif" actually uses a h264/vp9 video with no sound.
Then, long live the iMessage and Whatsup exploits, because SW developers are not able to do things right.
I began a dispute on the English Wikipedia which revealed that more than a few people use “GIF” to describe, not a file format, but a visual style of looping animation.
> PNG, the lossless format is great for diagrams and stuff with sharp edges.
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.
PNGs will persist because I know that they're lossless by looking at the filename. When I hit File > Save as .png, I don't have to inspect output metadata (that image viewers don't expose) or play around with exporter settings.
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.
Well, you should enable Adam7 interlacing for nicer progressive decoding!
I suppose it's not very useful nowadays as most any image will load fast, though.
Being lossless is a function of the whole pipeline from an input image to an output image. The last step being encode to PNG doesn't guarantee anything about losslessness.
Lossless means that the file encodes the exact same information that was given to the encoder. This is a property of the format.
Yes but people add pre-preprocessor steps to image formats, like blurring jpegs or lowering bit depth in PNGs to make them more compressible.
I do not know whether this has anything to do with any limitation in the WebP format, because it is more likely that this is some kind of bias in the kind of authors of Web pages who choose the WebP image format, who might also choose more aggressive compression settings, but for me WebP is a synonym for "low-quality image".
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.
Jpg, does not do text well, at its regular file size.And somewhat related it has no alpha channel.
JNG (jpeg network graphics) is essentially jpeg that support alpha channel.
But supported by no browser today and software support in general is quite limited. If the PNG authors would just incorporate this possibility into PNG from start it would be interesting, but it's too late now.
Gif is still there because it's still often the only option for frictionless video embedding. Embedded videos usually come with a video player that hardly ever quite works out well, often not starting automatically, not looping, or showing video player UI elementa that shouldnt be shown.
Jpeg LS do support lossless images.
But this is quite a different format than JPEG or better said the subset of JPEG that we know today as JPEG format and the JPEG encoder/decoders support. The whole JPEG format did have support for a lossless mode for JPEG (different one than JPEG LS), arithmetic coding and 12-bit images too, but those features just didn't make it into the implementations of the format (arithmetic coding initially did, but was removed from popular implementations because of patents).
PNG was once (win98 era) the sparkling new format that nothing supported yet. Operating systems shouldn't waste their time supporting it.
Png is still being updated, just last year it was updated to support a wider color space than any other web format. This shipped in all browsers before the official spec was publicly so you’ve been seeing Png upgrades without even realizing it
"These should just be vector images instead" is an argument made by someone who has never in their life attempted to create a vector image.
Also it would be nice to have a good standard vector format that isn't the complete kitchen-sink that is SVG, but we don't have that. We needed "jpeg but for vector graphics" and instead we got "html but for vector graphics".
So anybody saying "we should use more vectors" has to remember what the state of open vector graphics standards is.
In the context of the world it's all hair splitting, you can have a big photographic picture in png, or 1% compressed jpeg, or 1% jpeg converted to png. No new format can change it.
It seems to me that AV1 (the codec used in AVIF) has seen a lot more development in recent years, by virtue of being widely adopted for video. JPEG XL has not seen comparably massive adoption, perhaps owing in large part to Chrome rejecting it on dubious grounds (in spite of eagerly forcing the adoption of both WebP and AVIF earlier on). The pace of the reference implementation’s development has grown very slow, and most of the modest attention it’s been getting seems to have recently moved to the new Rust decoder, once the browsers finally made up their mind that’s what they wanted from the devs.
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.
It is getting its try, actively, in libjxl. People like to pretend AV1 got infinite resources; the reality is myself and one other contributor produced the vast majority of the image gains. I built Iris-WebP and aperture-alpha myself, from scratch. As a compression engineer, I think JXL is way, way harder to work with, and it would've taken me a lot longer. libjxl has community contributors, it is just an uphill battle with a codec like that. Same as WebP is an uphill battle due to its format restrictions.
> It is getting its try, actively, in libjxl.
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)?
I think libjxl's development is stalled because the format is hard to work with. It wasn't super hard to drive meaningful improvements to AVIF.
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.
Yes, but for speed which means a lot of SIMD plumbing, the larger workforce certainly benefited AV1 codecs!
Wasn't that also basically one guy from the VLC/ffmpeg community that drove that effort? I think they got funding from Netflix to do it again on ARM after demonstrating the benefits on desktop.
For decoding, yes, dav1d. But for encoding, a lot more SIMD kernels in libaom/SVT-AV1 written by other people.
(And lots of kernel shared between decoding and encoding, of course)
> It won’t be know until it’s been tried
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.
"We don't want to support another pile of security bug ridden C++ library" absolutely aren't "dubious grounds".
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.
The stated reason for Chrome was not ‘we need a memory-safe implementation’. It was ‘there is not enough interest’ and ‘there is not enough improvement over AVIF’. At the time, there was interest and there was improvement over AVIF (which Google has decided to support regardless of memory safety, interest, or seemingly any deeper consideration).
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.
> "We don't want to support another pile of security bug ridden C++ library" absolutely aren't "dubious grounds".
It is when that didn't stop them YOLO'ing in webp and then avif support.
If you have two toilets in your house, are you going to sign up to clean mine too, for free, because I demanded it from you?
Thought so.
That JPEG XL prime computation is a pretty ugly DoS. Just selecting it in Finder, with the preview pane open, maxed out every core on my Mac inside a QuickLookSatellite that also ate 4GB of RAM while doing so - for a good 15 seconds. Not bad for a 2KB picture. It seems like Apple did not set sane limits on their JXL previewer.
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.
When a format has so much flexibility, the world will glom onto the first thing that it solves and put it into the wild to solve that problem. The rest of the capabilities fall by the way side, yet not removed from the format. They're just ignored. MP4 can do so much more than the typical deliverable of a video stream and an audio stream. The spec allows for multiple video streams, multiple audio streams, subtitles, Flash like interactivity to allow self contained DVD style programming of menus to allow for chapter navigation, audio/sub selection, multiangle, etc.
MPEG4 supports interactive 3D scenes (read: games!) via bit-encoded VRML which can include JavaScript. I don't know any software which support this features (even without interactivity), but it is here.
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).
> MP4 can do so much more
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.
> None of that has fallen by the wayside though?
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?
No? If mainstream software handles the features (which mpv, vlc, and ffmpeg do) I wouldn't consider them to have fallen by the wayside.
I agreed that three were rare (two I've never personally encountered in the wild) but the rest I consider common. Actually if multiangle is referring to 3D video then I've encountered that one too. It's just that 3D videos are themselves quite rare but I think most software supports them.
I wonder if similar hacks apply to zlib and .png as well.
Zip and PNG bombs have been around for a while: https://github.com/0x48piraj/gz-bomb https://libpng.sourceforge.io/decompression_bombs.html
You can also have a zip that decompresses to itself: https://research.swtch.com/zip
I mean "mild" bombs where the final output bytes looks normal, a regular sized image, but the decompressing steps takes unnecessarily long, eating CPU or/and RAM
Probably not; for PNG, the image size is declared in the header, so a decoder can decide immediately if it wants to decode the image or not. The output is bounded by the size of the image times the bit depth, and decompression runs in time proportional to output size. zlib bombs exist, but they don't affect png because a decoder can simply refuse to decompress past the size of the pixel buffer.
The infamous PIL DOS errors, rooting from the library refusing to process images larger than a hard limit. Does this mean though JXL does not have that data accesible quickly?
The problem is that JXL has a ridiculously versatile modular mode which enables high-complexity “prediction” computations. These were designed to encode reusable, custom predictors that could reduce the prediction error and thus the number of bits needed to encode the error. However, the predictors can be abused to perform very complex computations instead. The prime image is only 4kx2k, but encodes a very complex prediction algorithm that happens to generate prime numbers.
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.
The primary problem with that image is that is has over 60 channels, which means it'll take 20x more time to decode no matter what. Incidentally, the JXL spec suggests that web browsers shouldnt't decode images with so many layers. Jxl-rs will probably start enforcing such limits by default.
> I believe Web codecs should be purpose-built, efficient, and narrowly scoped to the needs of the Web.
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.
I got an impression JPEG XL is not a single format, but many formats put under one brand (same as webp), you still need to choose these formats and transcode between them.
Well, anything that supports JPEG XL will support all of them, so you can just re-use the files an the web as-are.
I personally find AVIF more versatile. I just throw images at it, and it does a great job. As the article identifies, JPEG XL performs worse than AVIF in general, but it's particularly bad at things like illustrations and screenshots. With AVIF I don't need to worry about that.
I've always found it annoying how most cameras only let you save their photos as some combination of JPG/PNG/HEIC/RAW, often without any adjustable quality settings or option to save several copies in different formats.
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".
The camera's I've owned (Canon and, in more recent years, Olympus/OM System) all could do RAW, JPG, or RAW+JPG, or in some cases cRAW+JPG, with several quality settings available for the JPG side.
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.
Nobody has brought it up yet, but JPEG XL seems to be close in potential and flexibility to OpenEXR. It seems more a competitor to something like that--for use in image processing and digital art pipelines--than something like JPEG, WEBP, or PNG.
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.
I knew about the lossless JPEG to JPEG XL compression story before, but had no idea that it was a two-way road. That's truly f* impressive. Boggles my mind even more the fact this format hasn't been adopted widely yet.
JPEG is a lossy frequency-space compression stage followed by a lossless Huffman coding stage. The second stage is quite generic as such, essentially compressing a stream of bits.
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.
https://github.com/dropbox/lepton
byte-for-byte identical file actually. Not just imagery. You can basically save 30% without loosing ANY bit of the original file
Because what you save in terms of storage, you pay for in decode time, which is an important consideration on the web.
Do you? I just tried it locally, and decoding a 4.9MB, 6000×4000 JPEG with djpeg took about 400ms; decoding its losslessly-recompressed JXL (4.15MB) single-threaded with djxl took 300ms.
Cool. You're getting different results to everyone else. Do you see the same on https://random-stuff.jakearchibald.com/apps/img-decode-bench... (make sure you use a browser that supports JPEG XL)?
Well, I said “with djxl”, and Chrome/Firefox use jxl-rs which happens to apparently be currently somewhat slower for that use-case (but libjxl being faster shows it doesn’t have to intrinsically be the case), and Safari uses libjxl but multithreaded (so it’s 800 ms for the JPEG and 137 ms for the JXL).
That's fair, at really high resolution, the JXL decoders in browsers do better than JPEG decoders. I'm pretty sure this is a weakness in the JPEG decoder rather than the format, but it's still a meaningful result.
At smaller sizes (more typical on the web), the results are opposite, the JPEG decodes much faster.
jxl-rs will presumably get much faster in time. The work on it started much later than work on libjxl (because it took years for anyone to say they had vested interest in it), and if my understanding is correct, it hasn’t been production-ready until recently. Once it behaves correctly, speed improvements are next in line, presumably.
There is indeed an issue with the JPEG format that makes parallelization difficult: the lack of a 'table of contents' with offsets to tiles.
Various workarounds (for example RST markers or self-sychronizing properties of Huffman) have been proposed, but these are not great and do not work for all images.
JPEG XL ensures this information is always available.
I guess my surprise is mostly that it hasn't been adopted elsewhere. For instance, it still boggles my mind I can't store my JPEG XL images on Google Photos nor take photos as JPEG XL images directly on my Samsung smartphone, but can use HEIC for some fruity reason.
Google Photo teams wanted JXL too, but had to hold back due to Chromium not supporting them
The DoS thing would certainly make me worry about handling these images on my server.
You pay for decoding only when you view the image, whereas storage is a persistent cost.
This blog post makes two incompatible arguments:
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.
I invite you to re-read the post carefully, with the attention it deserves. Hint: at no point the blog post says JXL will not be improved.
It sounds like you don't recognize the relationship between text and subtext.
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.
Maybe you're just bad at reading text. Again, read the post carefully. Look around... nobody else had the same interpretation as you, so maybe that should clue you in something might be off with yours.
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!
I'll tell you what. In good faith, you should ask your friend to fix the numbers in the post specifically in relation to concerns that people have with the testing methodology in relation to threads and the speedtest flag instead of handwaving them and to be forthright about how significant codec optimization historically comes after adoption.
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.
Yes, he'll fix the speedtest flag thing (which BTW, several people were accidentally using it wrong because the feature is unergonomic AF, but it's convenient to blame the user for "holding it wrong" right?). No, single-threaded encoding/decoding is a valid use case and not a testing methodology flaw.
> ... to be forthright about how significant codec optimization historically comes after adoption.
Well, this trend has now been broken, so it's irrelevant to mention it. Codecs are now expected to be optimized well before adoption. Take the case of AV2: the AOM folks are currently improving the reference encoder, libavm. SVT-AV2 has just been announced. This is the reality we're now live in. The fact we're having this conversation is an instance of that trend change.
> "I have no reason to believe they'd be better anyway".
Why are you now selectively quoting fragments? That sentence goes "...and I have no reason to believe they'd be better *than dir-pred* anyway." The part you omitted makes the entire difference. Implementing splines will improve JXL's efficiency (again, this was never contested), but it IS unlikely that they'll fully compensate for the lack of dir-pred.
You know why? I *did* take a shot at writing an automated splines implementation for libjxl, and I failed. Not because I didn't know what I had to do, but because I couldn't find a quick way to generate high-quality spline candidates that improve overall quality while making up for their size and encode compute overhead. I'm sure that there's a hypothetical clever way to do it, but the point is that the equivalent tool (dir-pred) is dead easy to implement in comparison, done countless times independently, and it just works.
Efficiently leveraging JXL's splines into the encoding loop is legitimately a very hard problem. No, problems of this kind shouldn't be this hard, and it's healthy to call this stuff out instead of pretending that, some time in the future, the "potential" of "alien technology" coding tools will somehow be untapped.
> You see, any unfilled area is specifically mentioned only to dismiss it as meaningless.
Oh, you're still doing the weird "subtext" thing... you know what? I'm done. Have a nice day.
> Codecs are now expected to be optimized well before adoption.
Maybe I hallucinated, but I seem to recall that your very fine AVIF work happened only well after major browser adoption. "Rules for thee, not for me", I guess. Talk about trying to pull up the ladder.
> SVT-AV2 has just been announced
Best of luck to it and AV2. That's a non-sequitur.
> The part you omitted makes the entire difference.
It really does not. Because...
> Implementing splines will improve JXL's efficiency (again, this was never contested)
your given position is that it will never be improved enough. That is the problem. That your position is that it will never be improved enough to be better than AVIF (I mean again, though it was previously until quite recently) is entirely the problem.
You grip tight to this idea now that if JXL ever improves even one iota then you're vindicated in having graciously allowed it to improve, but you have not granted it the capacity to be improved any bit more than AVIF.
> than dir-pred
This is what I'm talking about.
> I *did* take a shot at writing an automated splines implementation for libjxl, and I failed.
I'm sure you're very good and very smart, and you've clearly done very good things. You're not the only very good and very smart person, of course. But you do have very strong opinions about what is and is not worthwhile for the world to pursue.
> Oh, you're still doing the weird "subtext" thing.
What can I say. I'm used to very good and very smart people knowing about subtext, so I guess I assumed you would.
I don't know why you are being condescending to Julio. His work has pushed AV1 forward significantly. His opinions (specifically about dir-pred) are shared by others who are in the encoding space because they're objectively true. If a breakthrough for splines is invented, we'd be elated, but as it stands, dir-pred is in virtually every video/image coding standard since the late 90s for a VERY good reason. Dir-pred also has two decades of iterative improvement and research behind it. The argument is that JXL's lack of this well-established coding tool is a serious handicap that will make it very hard - if not impossible - to compete with AVIF within a reasonable amount of time.
AVIF was performing better than JXL/WebP/JPEG for a long while, even before Julio and Gianni's tune IQ work happened. AVIF successfully met the bar, tune IQ further increased that efficiency gap.
AV2 needs optimized encoders and decoders because it now needs to justify its spot among AV1 and JXL on the web. That's why avm, svt-av1 and dav2d are well underway.
Well-put.
>nobody else had the same interpretation as you
I do. Even though it reads as trying to as fair as possible. But remember, your title is "The case against JPEG XL".
And the rest of the article is within the context of the title.
This comment reads like you summarized the post and didn’t read it
Believe whatever you want. :shrug:
Note, that JPEG XL was added as a possible compression method for DNG files (Digital Negative - stores raw images with raw sensor data of a camera).
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).
Much like WEBP, JPEG-XL is two different codecs in one. There's VARDCT mode, and Modular Mode. Modular Mode is normally used for lossless, but it can also be used for lossy as well. When you use Lossy Modular Mode, you get different kinds of compression artifacts than what you'd see in a JPEG file.
For Lossless: JPEG-XL wins, then WEBP, then PNG. (Sometimes lossless WEBP wins)
For Lossy: AVIF wins, then JPEG-XL, then WEBP, then JPEG.
Lossy Modular isn't efficient enough to compete with even JPEG.
Also, look at the graphs – Iris-WebP beats JPEG XL.
Sorry for the dumb question, but I don't understand something in these graphs. Since it's x=speed and y=bd-r, is this test done at a fixed target quality/size?
I feel like JPEG XL could be a good RAW format for mirrorless cameras... something with huge flexibility but with the perk of being easier to view casually on other devices. And then that in turn could make it a more useful web format? Camera vendors are of course notoriously proprietary/stubborn.
Just demosaiced JPEG XL? That's not raw.
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).
PureRAW can now output linear DNG's compressed with JXL. It's amazing the first time you use it seeing 25mb RAW files go in, get made linear, and pop out 8mb or 9mb, then toss them in your RAW developer of choice and still find all the dynamic range and such you'd expect from the original RAW. I'd been doing that on my own with a script that called Adobe's DNG Converter, which has the same capability, to convert older versions of PureRAW's linear DNG to JXL-based DNG files, but that's no longer necessary.
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
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?
Raw isn’t an image though, it’s pre-image. And we have an open raw format already. DNF I think. With pretty decent adoption.
You are thinking of DNG which is more of a container format. It can use multiple image formats internally to record the actual image, one of them being JPEG-XL.
iPhone raw images are actually a jpeg xl inside the DNG.
True. I would love to have lossless images (and video) out of my devices still. Not as a replacement for RAW but as a middle ground between RAW and lossy JPEG.
Not for quality reasons primaily but because keeping the first stages of the processing pipeline and the archival branch lossless solves some headaches.
it's even flexible enough to represent images pre de-bayering
JpegXL progressive decode is way better than AVIF:
- 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)
I think, whole idea of «web images» is silly now.
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.
"Web optimised" really means "internet transfer optimised". Eg, the benefits would also be there for native apps that are downloading images from the internet, and they're not the web.
In practice "web optimized" is a soft copyright control where the image is read-only to the extent the only readily available software that can open it is a web browser.
All the formats we are talking about here (JXL, AVIF and WebP) have FOSS royalty-free encoders and decoders.
I'm sure this is right about all the technical things, but the stuff about the requirements of a format for the web misses the mark IMO.
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.
Professional web developers want to create a great experience for their users, so they go beyond simply serving whatever comes off a digital camera.
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.
> Also, JPEG XL is two codecs bundled into one,
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.
> and narrowly scoped to the needs of the Web
> 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"
In the post, I say "I think WebP was a bit too narrowly scoped"
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.
Wasn’t WebP pushed pretty hard by Google for several years, until the (ever shrinking) rest of the ecosystem sort of caved in? My impression was that there wasn’t much interest until it became more or less inevitable because of that.
That's correct
Can whatever the next new image format for the web will be please have a JSON block at the start giving
And it doesn't have to be JSON, as long as it's in a fixed location (looking at you, AVIF and JPEG), extensible and can be decoded by just reading the first 8KB or 16KB.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)
I'm the author if anyone has questions – AMA
How ergonomic are the modern AVIF encoders? I like libjxl (and cjpegli) because they are really good at generating reasonably compact, high-quality images.
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).
Have you tried the latest AVIF encoder? It's quality setting seems much more stable.
I have not tried them; I thought that was clear from my wording.
Lossless was discounted due to webp, but doesn't webp lossless only use 8bit depth RGB? (I think it is important to have a separate file extension for lossless stuff anyway, otherwise it gets confusing quickly)
Lossless was discounted because lossless just isn't very useful on the Web
I'm active in many art communities on the web for whom being able to view and share lossless images are table stakes. Also many other communities for which being able to view and share lossless screen captures is fundamental.
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".
What percentage of the web is that 0.1% ? 0.01% ?
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.
If you're counting by absolute numbers, 90% of the web is probably YouTube, Facebook, Instagram, Twitter, Bluesky, Reddit, TikTok and the other major silos. I don't think those should be able to define all the web technologies for everybody else.
> 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.
count .png-s in the web. There's a lot. And .jxl's lossless is much better than png's. Basically any image with sharp lines (screenshots, image of a button etc) or gradients should be lossless.
This is outdated thinking. AVIF is really good at sharp lines & gradients. https://hacks.mozilla.org/2026/08/intent-to-ship-jpeg-xl/#:~...
Not at lossless, though.
Perhaps niche compared to the entire web, but we use lossless webp for gaussian splat data delivery for realtime rendering. (https://developer.playcanvas.com/user-manual/gaussian-splatt...).
Scenes often comprise gigabytes of lossless webp, some of which you can see at https://superspl.at.
We could get better compression using a custom encoder, however with webp the browser decodes off the main thread, copies the resulting data to GPU memory and caches the images for us. All very useful on the web!
It may not be as widely used as lossy, but it does have valid uses that lossy just can’t substitute and the web needs to accomodate for. And the space savings offered by JPEG XL seem pretty great in that regard.
‘The average Web consumer’ may not need lossless, but a non-negligible minority very well might, hence why lossless should absolutely be on topic.
JPEG XL isn’t consistently better enough to justify it. If lossless is so important, maybe we should be campaigning for HALIC.
Isn’t HALIC proprietary?
JPEG XL is an open format with a libre reference implementation, usually compresses better than WebP/PNG, and supposedly has plenty of room for improvement still (in said implementation). Add to that its versatility in other areas and the fact that it seems to have generated widespread interest (much unlike WebP in its time, from what I recall), and I think campaigning for it makes perfect sense.
I can tell you that I don't care if the AI slop used in everyone's AI generated blog is lossy compressed. In fact, expecting it to be of such import that lossless is required is pretty farcical.
I have a lot of basic questions about the CVVDP graph. Is the X axis encoding or decoding speed? Is higher better on the Y axis? What format is Aperture? I assume "aom" is AV1 but it wouldn't hurt to document it.
x-axis is encoding speed, Y-axis is BD-rate where higher is better. aperture-alpha is an upcoming encoder from Halide Compression, no more details than that. libaom and SVT-AV1 are both for AVIF; libaom is the AV1 reference encoder.
> where higher is better
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!
Wait... SVT-AV1 doesn't support anything else than 4:2:0, right? Kinda biases the comparison here.
We have to apply some weight to the fact that one is open, one isn't, right?
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.
AVIF is royalty-free, & SVT-AV1 and libaom are open source.
Edit: saw you corrected. Much appreciated!
SVT-AV1 is also more than just open source in name only; development and discussions happen in the open; with many community forks that’s now getting upstreamed/merged.
It is a true open source project; not just an open source license.
SVT-AV1-PSY was the first fork, and I created it. When the project matured, the maintainers reached out directly to get things merged – I can confirm it is a great project with great people who are very easy to work with.
AVIF _is_ AV1 in the HEIF container.
(.heif is sometimes used as a file extension generically, but HEIF is itself a container that can support various payloads.)
Both are open I think.
I would argue that even if JPEG XL isn't the best choice for Web images, if browsers don't support it then that will widely hinder its adoption for its non-Web use cases. Would you agree?
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?
> I would argue that even if JPEG XL isn't the best choice for Web images, if browsers don't support it then that will widely hinder its adoption for its non-Web use cases.
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/
> though their implementation doesn't support progressive images yet
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 terms of AVIF, only Chrome supports progressive decoding. In terms of JPEG XL, Firefox and Chrome support progressive decoding, Safari does not.
In all cases, the browsers are able to render the final image, they just don't show the intermediate stages.
> 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.
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?
HDR is something many photography enthusiasts are interested in, and the ability to losslessly transcode from JPEG to JPEG XL (and back again if you have to) is actually IMHO the "killer app" for the format. Many people have years of irreplaceable family photos in JPEG format, and being told "you can fit 30% more photos on the same hard disk without any loss of quality" would certainly sell me on converting my photo library to JPEG XL. (The jpegxl.com site says "up to 60% smaller" so I'm going to guess that 30% is a safe average gain and it might be more).
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.
What do you think the best use cases for jxl are? Where does it still have an advantage over other formats?
I think it is a potentially good camera format, good medical & scientific imaging format, good RAW compression format (Apple uses it in some newer iPhones for this), good media interchange formats for tools like Photoshop (think about storing all of your layers inside of one JPEG XL that's fully compatible with .psd files), and more. It is incredibly expressive and versatile, which is what makes it so risky on the Web.
It's a great option for 3D art texturing and compositing. I could see using it over OpenEXR, which I use a lot in Blender right now.
What do you think about the fact that most perceptual quality improvements in SVT-AV1 have been almost only driven by external, non-paid enthusiasts such as yourself while the maintainers have been basically only targeting VoD and RTC?
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.
Thank you for an interesting article. You’ve helped AV1 come a long way!
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.)
It would be nice to see the actual R-D curves for the codecs instead of compressing them into a single number. Also, what is BD-rate computed with respect to, jpegli at p0?
Very compelling and thoughtfully written article. Thank you!
What about the current AV1 patent issues, like Sisvel/Access Advance and Dolby vs Snap? Does that change the AVIF vs JXL comparison at all?
those issues aren't real. they're nuicense suits by a patent troll. a couple companies will settle cause it's easier and cheaper, but if they ever try to go after someone big they'll fight it and get the patents invalidated for covering 30 year old work
What format would you recommend for archiving photos if I don’t mind slight quality loss?
I like how every time we have a codec fight no one seems to care very much about how long it takes to encode these files. Like I get it, the amortization schedule often works out, but there are scenarios where images need to be generated dynamically and will only ever be downloaded once.
It's very hard to beat the encoding performance of libjpegturbo, even with an asic.
Encoding time is one of the things that JPEG XL has claimed over AVIF for years, but in the latest encoders, it doesn't seem to be the case.
> It's very hard to beat the encoding performance of libjpegturbo, even with an asic.
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.
Sure, if you ignore PQ completely.
Not that libjpeg-turbo is pinnacle of quality but hardware encoders, seriously?
If you want to move the bar to quality for your strawman, then libjpeg-turbo is not even close in image quality to plenty of encoders, such as jpegli crush it. For compression size it also loses to modern libs. There is no metric that libjepg-turbo wins at nowadays, not even speed.
Then, if you care to learn, there are extremely high quality, lkely far beyond old software like libjpeg-turbo, use in DoD projects, satellites, medical imaging systems, commercial cameras systems, and plenty of companies that sell such chips and IP to embed in ones own ASIC. There is zero technical problem taking an opensource project, turning that exact code into an ASIC or VHDL one can put into any ASIC, an so the best ideas are reused in hardware all the time.
Alma Technologies, CAST, intoPIX all sell such cores that are integrated throughout the industry, embedded everywhere, and can be bought with an ever improving host of features.
> there are scenarios where images need to be generated dynamically and will only ever be downloaded once
Those scenario amount to epsilon percent of scenarios, though, so it makes sense to ignore them most of the time.
I kind of settled on avif. I am not at all implying avif is perfect, in particular at high compression I notice the quality isn't quite as good as often advertised. For similar size compared to jpeg, avif is divine; and I also found avid better than webp in my own tests, so I switched to it. I don't quite see JPEG XL being really significantly better though. I think a really big problem here, even aside from Google trying to force deadlock people into its evil monopoly structure, is that we have competing formats (avif, jpeg-xl, webp) and that's IMO not so great when we want to have "one format to rule them all" that's better than jpg or png or gif. JPEG-XL is kind of a late starter here; if it is not really significantly better than avif or webp then I do not see it will gain any real foothold in the coming years.
If JPEG XL doesn’t become useful on the web, is it really likely to become popular with camera manufacturers, professional image editing tools, etc?
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?
> If JPEG XL doesn’t become useful on the web, is it really likely to become popular with camera manufacturers, professional image editing tools, etc?
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.
Looking forward to a future where we can arbitrarily DoS anyone with a PDF that computes massive swaths of prime numbers.
PDFs can already do arbitrary computation. You can even play tetris in them.
You used to be able to DoS the user's browser by sticking thousands of tiny animated gifs on the same page. You can't do that any more (AFAIK) because that's a bug so the browser developers fixed it. This is the same thing.
It's odd that apple didn't proactively guard against such concerns when adding a new format.
Can't that future adopt basic resource / complexity limits to defuse the DOS bomb?
Most people using dedicated cameras shoot in RAW, then use a program to process and export the photos afterwards. So camera manufacturer buy-in isn't super important.
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.
The second paragraph doesn’t follow from my question, because it assumes JPEG XL does become useful on the web. The author believes AVIF is too far ahead already.
I suspect the name alone will help drive adoption, especially from non-technical people. Heck, I'm reasonably technical myself (but not expert in image formats) and my first instinct on encountering AVIF was to say "AVIF? Does that stand for AVI File?" And I would have assumed that it's a video format, not an image format. Whereas JPEG XL would have everyone who has ever used a digital camera saying "Ah, it's got JPEG in the name, that means it's a photo 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).
For me, the name JPEG XL evoked a feeling of “this is going to be a lossy-only format with visible artifacts when used on raster images”, so I don’t think it’s a good name.
There’s also a migration path where jpeg can be converted to jpeg xl losslessly. You can convert a jpeg to jxl then back to jpeg and its byte for byte identical.
JXL is moments away from having almost universal web support. Safari supports it already, Chrome and Firefox are already set to turn the flag on by default in the next releases.
DNG added JPEG-XL as a format for both raw and compressed recently
The iPhone actually uses JPEG xl for its DNG raw files now.
[flagged]
I’ve been shooting with semipro to pro cameras for decades across brands, and I haven’t came across a single camera that supports shooting JPEG XL.
HEIF is what is getting support in recent models; but JPEG still rules supreme for its compatibility.
Web publishers should definitely be stripping metadata at least, and transcoding isn't much harder. For anyone who cares about bandwidth, transcoding to efficient formats is non-negotiable; if you don't, then why do anything? Just ship PNG, who cares?
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.
> Web publishers should definitely be stripping metadata at least
No, they shouldn't. Not blindly. Metadata can include copyright license information, such that stripping it violates the license to reproduce the image.
iPhones have been using it for its ProRAW format since 2024.
It has 3 options:
JPEG Lossless (most compatible)
JPEG-XL Losless
JPEG-XL Lossy
Had a lot of the content in this article came out 4 years ago I would have agreed. At least we finally don't have a fake Image Coding Comparisons [1] that tries to undermine JXL.
Ignoring AOM and AV1, I was the first few on HN apart from its author supporting JXL from the start, I would argue the biggest case against JPEG XL is JPEG li.
Jpegli offer enough quality improvement and advantage without introducing an entirely new codec. And all of a sudden the bar for next image codec now needs to be even higher.
[1] https://storage.googleapis.com/avif-comparison/index.html
> only roughly 11.9% smaller than lossless WebP anyway
That’s huge, no?
We all know these aren't purely technical reasons, it's to break the monopoly of one Internet Company's decoder format portfolio. You can't let one Fruit Company's format be the thing either, so it's basically a L for engineering but a W for pleasing everyone TBF.
AVIF is royalty-free, with open-source implementations not developed by Google. Google's implementation is libaom; as you can see, SVT-AV1 beats it. SVT-AV1 is developed by a number of companies – historically Meta, Netflix, Intel, independent contractors, and others. I worked on SVT-AV1 myself. I don't see how this is a bad thing for everyone, even if Google drove standardization of AV1?
There were something like 40 companies involved in AV1 standardization. Quite a few technical contributions did not come from Google, and quite a few of Google's proposals were substantially modified by feedback from others before they were included (and not all of them were eventually included).
Source: I lead Mozilla's technical contributions to AV1.
It saddens me to see discourse on the internet about AV1's ancestry being focused on Google's VPx line of contributions, while diminishing those coming from Daala (entropy coder...) and Thor (QMs...), as well as inter-company collaborations (CDEF).
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.
You're welcome. That is what those image sets were for.
I was really happy Thomas Davies added quantization matrices to the spec, because if he hadn't, I would have had to. Fortunately, he did a good job. I am glad someone is finally using them. Don't sleep on per-segment quantizer deltas, either.
Hello derf.
I think you might like this: https://github.com/Uranite/svt-av1-tritium#from-svt-av1-hdr-...
Me and a bunch of friends (mainly Clybius and Yiss/Uranite), after I was constantly saying daala was a great low complexity visual metric that should be added back to AV1 encoders, we decided to implement it into yet another svt-av1 encoder fork: https://github.com/Uranite/svt-av1-tritium#from-svt-av1-hdr-...
It has been showing great performance overall and is quite nice. It can work on CDEF, like it did in aomenc-av1 back in 2018/early 2019. It does so very well.
We've also implemented deeper controls, but that is still experimental.
Thank you so much for your work on daala stuff, as it's been one of my many inspirations in the field.
> You can't let one Fruit Company's format be the thing either, so it's basically a L for engineering but a W for pleasing everyone TBF.
What exactly is "Fruit Company's format"?
I'm guessing HEIC.
HEIF isn't an Apple owned format, most modern cameras have it as an option alongside JPEG now. The situation is JPEG is woefully outdated, lacking in HDR support and dated compression. HEIF is technically much better but patent encumbered.
JPEG-XL offers all the benefits of HEIF and more, while not being patent encumbered.
> HEIF isn't an Apple owned format […]
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.)
They support different variants of the format, though.
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
These sorts of things always talk about progressive rendering. Who actually likes progressive decoding? Like...what year is it?
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 disagree with this. If I'm in a poor connectivity situation, a preview can help me quickly decide if an image is worth waiting for.
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.
You've left some 36 comments on this submission (which is honestly weird as HN usually rate limits to avoid that sort of aggressive participation), and your comments seem extremely...cherry picked. In another comment you dismissed the bandwidth savings of JXL because connections are so fast that eh, who cares, and in this case you herald the importance of progressive rendering because connections are so slow.
Are you the author of the submission? Literally never seen someone so motivated in a conversation before.
I dismissed the bandwidth savings in another comment because the increased decode time undid the benefit.
I am not the author of the submission. I have experience in web performance, and my comments come from that experience.
The chart showing jxl-rs taking 1209ms to decode a 5456x3632 image in a single thread is a little damning, but is there an equivalent benchmark showing multithreaded decode performance? Clients tend to have an abundance of threads these days.
Something is fishy here.
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.
[1]: https://arxiv.org/pdf/2506.05987
It’s a measurement error: the `hyperfine` command uses `jxl_cli --speedtest` which, by default, does a warmup run that ends up in hyperfine’s measured time.
jxl-rs is single threaded. It may be not a good idea to use many threads per image as one page can have many images.
jxl-rs is not single threaded.
jxl-rs as it is used in Chrome is single-threaded.
The time would be less, but you still need to power those cores. Single thread performance can be a good indicator of what it'll do the battery on your phone.
Not at all.
CPU power is proportional to frequency^2. Running on 4-6 little/efficiency cores (which are widespread on mobile) is likely faster than one big core, and uses less energy.
jxl-rs is a relatively new implementation, not yet optimised for speed. It’s hard to say how much faster it’ll get, but I assume it would at least get near libjxl’s level.
I wasn't really sold on the argument initially, given they admit there's some real lossless usecases, but this is a good bit from the conclusion:
> 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.
There exist lossless use cases, for sure. I think most people would be well-served by high-fidelity lossy that saves a lot of bits while still looking perceptually identical. Whoever isn't served by that most likely doesn't care about size savings, and can stick with lossless PNG.
The problem with that is that the idea many stakeholders (especially big platforms) have of "perceptually lossless" is actually compressed to hell garbage. The only way you as a user can ever guarantee actually perceptually lossless is to use a fully lossless format.
Hello everyone.
Because of Gianni's great post, I've decided to go full throttle on rewriting and finally publishing the JXL vs AVIF post after deciding to partially shelve it last year.
This should be especially interesting looking at the differences between my testing and Gianni's.
I didn't realize progressive AVIF was a thing recently either; the comparison between that and jxl was pretty surprising.
Worth noting that this progressive AVIF, when viewed in Chrome, has only two states: a "base layer" which pops in around 8KB, and the full image which appears 270KB later. The comparison JXL continues to refine during most of the download, so it winds up looking substantially better than the AVIF at around 95KB loaded, and looks pretty good (almost as good as the full 280KB AVIF) by 175KB. I suspect that there are a lot of knobs to turn for both progressive modes, but this particular case could definitely be cherry-picked to favour either codec.
Progressive AVIF is very flexible: it supports up to four passes, at configurable quality and dimension scaling levels. You can have any given pass reference up to two previous ones for refinement (thanks to AV1's strong inter-encoding capabilities), and you add filters to non-final passes (like blurring) to achieve a desired loading aesthetic.
That JXL page happens to use two passes, but the knobs are there to customize the experience to fit the use case.
I find it misleading to call AVIF's "up to four passes" "very flexible".
It 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-...
> I find it misleading to call AVIF's "up to four passes" "very flexible".
Wow, what a way to misquote me. Let me repeat what I actually said:
> Progressive AVIF is very flexible: it supports up to four passes, at configurable quality and dimension scaling levels. You can have any given pass reference up to two previous ones for refinement (thanks to AV1's strong inter-encoding capabilities), and you add filters to non-final passes (like blurring) to achieve a desired loading aesthetic.
So, I re-iterate progressive AVIF is flexible, because:
- Intermediate passes in AVIF can look as sharp or blurry as desired -- you don't have that kind of control with JXL
- Intermediate passes in AVIF can semantically be different from the final pass -- very useful if you want to add a "loading" mark to the non-final passes to inform the user the image is still loading
- The four pass limit is A GOOD THING, as you want an image format to have a reasonable worst-case upper bound on energy consumption due to sum of partial decoding + display refresh updates -- there's such a thing as having "too many passes", and uncapping the limit would be irresponsible
- You can absolutely do saliency encoding in AVIF, as AV1's inter-frame encoding naturally allows for it efficiently
Ah, an accusation of misquoting. I actually quoted your exact words minus "is" and "it supports".
I think we disagree on the degree of flexibility, for sure.
A cap on layers (under user/browser) absolutely makes sense, but 4 at the format level is quite limiting, especially if you want to spend some of them on salient regions.
I agree that's possible, but not that it's efficient. You'd waste a few KiB on encoding skip blocks - AVIF layers represent the whole image, whereas JPEG XL can efficiently encode and update at group level.
How flexible did Jake find AVIF progressive in 2025? [1]
"it seems pretty limited. Only particular scaling values are allowed, and 1/8 is the smallest. Supposedly, additional layers are possible[..], but whenever I tried this, the encoder would error out, or explode the file size to ~400 kB, even at lowest quality. I guess that's why it's marked 'experimental'."
> Intermediate passes in AVIF can semantically be different from the final pass
Also true of JPEG XL - scans are additive.
[1]: https://jakearchibald.com/2025/present-and-future-of-progres...
I'm not sure if you're aware of this or not but juliobbv is the developer that fixed progressive AVIF, he is fully aware of how it works and how AV1 works in general.
"You'd waste a few KiB on encoding skip blocks" This tells me you don't know how codecs work... skip blocks are not expensive to code, they are very cheap.
Jake's blog post is outdated by the way, the progressive functionality is much more advanced than it was at that point in time because Julio worked on it.
> This tells me you don't know how codecs work
Laughable.
My conservative estimate is that a few-MP image with all but a smallish region encoded using skip blocks will spend a few KiB on that. This is very expensive compared to sending only a bounding box, hence it is unattractive for purposes of updating small regions with a whole-image layer.
I am glad to hear AVIF progressive has improved. But note that my original comment was: I find it misleading to call AVIF's "up to four passes" "very flexible". I believe that stands: contrasting the flexibility of (purpose-built) JPEG XL vs. the fairly strict limitations (inherited from video) of AVIF, I am astonished anyone would still call the latter "very flexible" by comparison.
Hi, I'm the author of the article you're quoting. AVIF was limited at the time of writing, but has since seen massive improvements, including progressive support.
I don't think the truncation thing is beneficial to the web. By the time the browser would terminate the connection, it has likely downloaded way more than it needs https://jakearchibald.com/2025/present-and-future-of-progres...
Sounds like some strong assumptions here, particularly a stable and non-metered connection.
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.
I believe wholeheartedly that AVIF's approach is significantly better UX.
why? in jpeg xl i get an image quicker and i can see it getting better, so i know it's still loading while the avif one looks stuck for the majority of the time, which makes it look already done loading and just low quality to me.
What exactly is AVIF doing in this case that I can't do with two <img> tags at a smaller size? I can easily create a thumbnail that beats the AVIF quality in less than the 5KB delta between the static and progressive version in Squoosh.
The quick answer is: you can have up to four passes. With progressive AVIF, you let the browser avoid rendering previous passes if a subsequent one has already been downloaded. It's more efficient and saves battery.
Perhaps it's just a bad example. I suppose avif can support multiple "scans" of progressive encoding as well.
Is there a way to have fast on-the-fly WebP encoding? When i checked it, it was unusably slow (multiple seconds for large images), but maybe that was the implementation. That alone made JXL far more interesting to us.
> Progressive rendering (which AVIF supports) decodes a low-fidelity rendition before the full image arrives. AVIF didn't support progressive rendering for a while, and during that time I believe it was deeply oversold. Now that libavif has implemented it (it was always possible), the conversation appears to be over.
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.
> A lower resolution image layered below the full resolution image, which is loaded and rendered first.
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.
> A lower resolution image layered below the full resolution image, which is loaded and rendered first.
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.
You're wrong. AVIF does support spatial layering where the full-resolution image is derived from the lower-resolution layer, and cannot be decoded independently.
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.
Jpeg2000 (and jpeg ls and jpeg xr) thankfully wasn’t implemented in any major way. Keep it simple, stupid.
Can a similar technique be employed in JPEG XL, or does the format not allow for it in any way?
Not sure if the difference is materially relevant to UX at all. JPEG XL achieves progressive rendering at a great cost to its selection of coding tools, so I side with AVIF's approach.
Does the difference matter?
Yes, if you look at the demo, the "progressive" AVIF loads a visible image at 8.5KB, and at that point, it looks better than the progressive JXL. However, that is ALL the AVIF shows until the image has fully loaded. At around 98KB, the JXL looks significantly better, and at around 240KB already looks really close to the final image, while the AVIF still looks terrible. At 280KB when the AVIF finally loads, they look identical.
BTW, you can configure the AVIF encoder to have another in-between pass or two so the quality jump isn't as big. The JXL folks just happened to go with only two total passes.
Won't that increase the total size of the image for each pass?
Thanks to AV1's inter encoding, overhead is overall minimal as each pass can refine on previous ones. Think of it as a mini-video. Because of this, in the case of images with a lot of repeated patterns, progressive AVIF encoding can actually result in more efficient images!
Looking at the demo linked in the blog post, I can make a similar quality thumbnail for a smaller size than the delta between the static and progressive AVIFs
The quick answer is: you can have up to four passes. With progressive AVIF, you let the browser avoid rendering previous passes if a subsequent one has already been downloaded. It's more efficient and saves battery.
Which sounds very useful if your connection is slow enough to make use of progressive image decoding. (Often enough the case for me.)
I prefer the UX of the AVIF example here. I think it's better to have a progressive phase where the image is obviously "not ready", yet you can still determine important details like the subject of the image (unlike a blurhash), rather than a phase that you could mistake for complete, but looks bad in parts.
Progressive rendering is just a different way to layout the pixel data. Embedding a thumbnail is storing two distinct images. In other words, progressive rendering should be more efficient space and bandwidth-wise.
The DC coefficients in a progressive JPEG are literally an embedded thumbnail (a 1:64 copy of the original) right? Is the question if the second "layer" replaces the thumbnail or layers corrections on top of it? It wasn't clear to me which AVIF does.
According to this source [1], a second layer can progressively provide the rest of the image data:
> Note: AVIF supports two types of progressive decoding. Spatial scalability can be used to offer a lower resolution image for network constrained users and 'progressively' provide a higher resolution image by sending just the additional data required to fill in the high frequency details. Quality scalability offers a similar progression by steadily improving visual quality with each render.
That is totally not what I expected. Though it's not clear to me how exactly you achieve it.
[1]: https://web.dev/articles/compress-images-avif
AFAICT progressive AVIF is actually using the "spatial layers" feature of AV1, which was designed to embed multiple resolutions of a video in one bitstream. The limit on four spatial layers comes directly from AV1. The previously decoded layer/progressive-step becomes a reference frame that the next layer can draw from just like eg the temporally-previous frame can be referenced by interprediction.
Of course it does, with one you have to render twice and store two layers which costs you both compute and storage. With the other you can just take the image mid decode at a point and display it. Single decode operation, no layer mess.
You have to render twice and have 2 different layers in both scenarios. Writing to a buffer / layer is not an atomic operation so they need to be separated.
The difference matters, as it means that AVIF's "progressive decoding" serves no technical benefit and is only a minor ergonomic benefit: On a website, you could achieve the same effect simply by layering two <img> elements on top of each other, one with the thumbnail and one with the final image.
If layering to <img> elements is fine for your use case, then it simply means you have no need for progressive decoding.
How does progressive rendering actually that most OS GUIS are not multithreaded ?
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.
Thumbnailing happens in a background process and shouldn’t block the main thread; rather hangs are usually because fetching xattr over SMB is slow and Finder will block until it’s enumerated the metadata of every file in a folder.
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.
Progressive rendering is intended for the Web and it does work.
The form of JPEG-XL that can lossless convert to/from traditional JPEG is exciting tech that should be adopted universally. The non-backwards-compatible version of it seems redundant with AVIF.
Author entirely misses the case for what many people want it - re-compressing old JPEGs that they have no better sources for into JPEG XL with out decode-encode loss
The author covers it:
> 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
TIL that AVIF supports progressive decoding, cool!
I guess we found the tenth dentist.
"but strong mode-decision pipelines can pick the right mode for the job and save lots of bits" - citation needed. just a bit above author claims lossless is not useful for web, disregards modular jxl that uses nearby pixel predictors (even though it can be lossy, too), then produces this claim against vardct. spoiler - dct frequencies ARE using "nearby pixel values"
really strange article.
I would argue that as of 2026, we have enough storage and bandwidth that lossless compression is justifiable in almost every use case.
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.
Depends on your location. While I have a decent internet connection at home, the mobile one is trash. Good for IM and not much else.
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.
Just to put some numbers to this, I looked at an image I recently took with my phone:
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.
A 2.5 MB download just isn't a problem in 2026. I would far rather see the lossless image than save a few MB.
Try traveling abroad with a prepaid data SIM (or limited roaming data allowance).
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.
If you're on a train, or a congested area, even 100 kB is a problem.
No wukkas, JPEG XL support in Chrome ships by the EOM \o/
All my photos are HEIC. Why not just use what I have and not translate?
HEIC has a very messy patent situation around it which limits what tools work with it.
E.g. for official Windows support by Microsoft you need to buy the codec from the Microsoft App Store for $0.99
Formats that aim to be web standards should try not to be patent encumbered. There was a lesson to be learned from the Unisys debacle in the 1990s. If you don't want to reencode for the web, use a device that captures in a format that can be shared on the web.
You should never transcode lossy source files because there is generation loss in quality.
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.
Well, JpegXL does have one really cool feature: you can transcode jpeg to jpegxl (and back) losslessly. For jpeg to jpegxl it'll save something like 15-20% in size.
This is probably going to be a key feature for web platforms. They can convert their massive backlogs to jxl for free space savings.
Because you'll be hounded by patent pools and sued into oblivion if you dare to use it in your own software and aren't Apple, Microsoft or Samsung.
Think about how many images large platforms deliver every day, and the benefits of saving bits on each of them.
Rather than AVIF or JPEG XL or WebP or HEIF or any of that stuff, my actual ideal choice that I wish everyone used is just good ol' JFIF. I like that I can take a file downloaded from the modern Web and open it on my '90s and 2000s computers. I emphatically do not care that it's some marginal percentage “““more efficient””” — more efficient for Google and Apple and Amazon and all the other silo providers who are moving more data every day than I will produce in my entire life. But why should I have to suffer backwards-incompatibility for their sake?
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
> This rules out JPEG XL's lossless advantage, which in practice is only roughly 11.9% smaller than lossless WebP anyway
> It cannot be worth bringing a new image codec to browsers to save 12%
What? 12% is huge.
Yes but the decode time is orders of magnitude more.
who cares, you're not displaying 60 of them per second
If the bandwidth saving gets you the image 10ms sooner, but due to the decoding time it takes 70ms longer to display, you're losing.
And in the cached cache, the bandwidth saving is gone, and you're still paying the decoding penality.
Right, so in that hypothetical scenario where your bandwidth is over ~40MB/s, the bandwidth saving isn’t so relevant. That sounds a bit tautological?
I'm not sure where you're getting those numbers from. But, in the cached case, the download time is very fast, yes.
And you might want the cache to either take up less space or hold more images.
Interesting.
Lossless dismissed? 11% isn't nothing, that's trillions of images out there. Mozilla's own data shows JXL lossless beating AVIF and WebP. That's the one weakness of avif that bothers me, for lossy and speed it is brilliant. Companies may have another itch with the misleading licensing:
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.
[flagged]
[dead]
I agree that the choice for JPEG XL is mostly politically motivated: it isn't Google. And its name is derived from JPEG, which is an IETF standard which gives it more clout.
>it isn't Google.
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
Yes, but unlike WebP it wasn't exclusively designed and developed by Google. That's a big difference.
AV1 wasn't also exclusively designed and developed by Google.
Chrome's team should be blamed for favoring AVIF over JPEG-XL, not Google entirely.
And Google also removed jxl support in Chrome in '22 (only to put it back in recently)
It was only ever supported behind a flag. Stuff behind a flag isn't 'supported', it's experimental. The experiment ended.
JPEG isn’t from IETF.