In my opinion, the case for JPEG XL is not its depth, it's its breadth.
JPEG XL has an alpha channel, image size up to 1B x 1B, bit depth up to 32 bit, progressive decoding, animation, lossy and lossless, up to 4096 extra channels (depth, spot, etc), lossless JPEG conversion.
JPEG XL is not the format you choose for hyper-optimizing your web image delivery. It's the format you choose as default for anything where spending dozens of hours measuring the perfect codec is overkill, and you just want a kick-ass generalist codec that's ready for everything you throw at it in the future. That's JPEG XL.
JPEG XL is a perfect interchange format, the one image format whose capabilities make it truly universal. If we could choose one codec to be supported everywhere - the spiritual successor of JPEG - it has to be JPEG XL.
By volume, there are very few use cases on the Web that aren't served by versatile lossy compression. The average Web consumer doesn't need lossless
I think this is a bad argument. A use case that affects 1% of web users is a requirement for more people than live in most European countries. The scale of the web means that appeals to averages are highly misleading. Having previews in one format and the final image that you download to go into some other flow in a different format is a problem because the artefacts will be different in the two formats, even if they’re both small in absolute terms.
The next line says that books and photos are part of an unrealistic data set. But photographers share their work with customers via the web. The most common format for eBooks is ePub, which is XHTML and is often rendered in a web view, or even a web app.
Why would an e-commerce site need lossless images at all though? It needs to be as small as possible to load as fast as possible with perceptual compression so that potential buyers can see the products well enough to make a purchasing decision. Lossless encoding is not necessary in that context at all.
Lossless recompression is not the same thing as usual lossless compression. Lossy compression always induces new artifacts. JXL as a special feature can take an already lossily encoded JPEG and shrink it by an average of 20% without introducing any new compression artifacts.
Image quality is very important in purchasing decisions. Poorly compressed images may make the product seem worse than it actually is. Shopping is arguably the sector that generally chooses quite high quality levels for image compression because of this, the sites that go for as small as possible are usually news sites and social media.
As a user, I dislike the notion that only lower quality range is worthwhile to support on the Web. And I dislike comparisons that plot a graph without showing example images up front so that the reader could see if the comparison is about no visible artifacts quality or about which visual artifacts are less bad.
I think it's valuable that the original JPEG works pretty much everywhere. It's also valuable that PNG also works pretty much everywhere, including the Web even though lossless is arguable always too much quality for optimized Web images. I think it's valuable to get a format that can do all the newer things and covers the space that JPEG and PNG together cover to the point where it works everywhere.
For that to happen, the new thing has to be supported on the Web, because the Web is part of "everywhere".
(On the flip side, one thing that has annoyed users about WebP is that when WebP is chosen for its Web delivery characteristis, it doesn't Just Work everywhere else, if you save the file from the Web.)
Notably, the original JPEG is used as a capture format in high-end cameras and it is used for Web delivery. Folks who specialize in optimizing load times of Web sites would most likely say that the 4:4:4 high-quality JPEGs out of a camera are inappropriate for Web delivery.
And, yet, there is value in being able to take a camera JPEG, put in onto an HTTP server, and send the URL to someone, and they can see the picture in their browser and can decide to save the picture for further processing even if the picture has too much quality and size to be used on e.g. a news site. It's good that with JPEG you can view the original photo from Flickr within browser even if most of the time you want the site to use a rescaled and recompressed image for delivery.
Also, arguably you shouldn't have metadata at all for optimized Web delivery, but for photo storage use cases, it's really nice that JPEG XL supports compressed EXIF and XMP and cjxl compresses EXIF and XMP by default. I hope AVIF2 adopts these ISOBMFF box types.
Similarly, it's really nice that cjxl, by default, replaces sRGB and Display P3 ICC with CICP. That's excellent compression for non-pixel data! Nothing prevents avifenc from doing the same, but a couple of years ago when I evaluated things for storing my own photos, avifenc didn't do this.
It's also really nice that cjxl can recompress the pixels of a JPEG XL image retaining the metadata. Nothing prevents avifenc from offering this for AVIF, but when I checked a couple of years ago, avifenc didn't support AVIF as an input format. (A quick Web search suggests that it still doesn't.)
I think the main advantage of JPEG XL is that a user with limited time can figure out a libjxl encoder config that can be trusted to compress reasonably and not to result in visible artifacts for any realistic input. This leaves bits on the table compared to manually tuning AVIF parameters on a per photo basis to the level of what visible artifacts are tolerable. However, even if one-time settings for never getting visible artifacts is arguable too much quality e.g. for news sites, I think it's reasonable to want that kind of quality level and confidence even for some Web-targeting workflows.
I think the main advantage of JPEG XL is that a user with limited time can figure out a libjxl encoder config that can be trusted to compress reasonably and not to result in visible artifacts for any realistic input.
I had never thought about "consistent encoding experience" being a feature, at least not explicitly. But that makes total sense! And it's not something that blog-post-style codec showdowns typically focus on.
(Though that would be an interesting post. "We compressed 100 different images with the same settings, here's the total file size, and here's the worst-looking one.")
I think the main advantage of JPEG XL is that a user with limited time can figure out a libjxl encoder config that can be trusted to compress reasonably and not to result in visible artifacts for any realistic input. This leaves bits on the table compared to manually tuning AVIF parameters on a per photo basis to the level of what visible artifacts are tolerable.
BTW, have you looked at recent devlopments in AVIF? Gone are the days of brute-forcing AVIF encoders to actually match a subjective quality target. Right now, AVIF encoders (libaom and SVT-AV1) offer better consistency vs. JXL!
The progressive decoding example seems very cherry-picked. I don’t think it’s fair to say that AVIF is superior to JXL in that respect. JXL shows a preview with fewer bytes than AVIF and refines the preview as more data arrives more gracefully than AVIF.
That being said, I think it would be fair to argue that AVIF is better suited for general web purposes. But JXL still deserves first class support in browsers and OSes. JXL is already being adopted in the photography world, and browsers should support viewing those images without requiring any conversion.
The progressive decoding example seems very cherry-picked. I don’t think it’s fair to say that AVIF is superior to JXL in that respect. JXL shows a preview with fewer bytes than AVIF and refines the preview as more data arrives more gracefully than AVIF.
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 point that was chosen for the screenshot is the exact point where AVIF starts showing anything. JXL shows stuff before that point, and has more progressive updates after that point.
JXL shows stuff before that point, and has more progressive passes after that point.
There's such a thing as "doing too many updates". Remember that modern devices try to save on power by reducing the number of buffer updates/screen refreshes. Having such a granular loading mechanism (many where the picture isn't even useful to look at) makes it for a very distracting experience, impacts battery, and further compounds the decode overhead JXL already has vs. other formats.
Furthermore, having passes where quality is too close to the final image is by itself an anti-pattern. This is because modern browsers don't give you an indication that a particular resource has fully loaded. If an image at a given time is a bit blurrier than expected, how can you tell you just need to wait for longer?
which avif could have, if the jpexl.info people had encoded the image that way.
Could it really? It's far from an efficient implementation of progressive images, and each additional step is manually defined and costly in decode time, while JXL gets the steps essentially for free because of how it's data is structured. If you can show something competitive in size, I'm interested to see, but I haven't seen anything like that yet. Right now, AVIF looks better for ~10% of the byte range, and I doubt you can improve that to more than 30%
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.
You're talking about a technical detail, not a "will it actually work". What's the file size with all 4 passes? (also, 4 is laughably few in comparison). Does those 4 passes allow it to look better across the majority of the byte range? Is this competitive in decode time? These are the questions that are important, not 'can it be done'.
I've never been after JPEG XL for it being "best in class", I've been after it because it's a format that works across the whole pipeline, which will never be the case for any of the formats that rely on being able to share code with a video codec. I don't need another image format designed for the web, I need an image format that happens to work on the web. Until JXL, that was either JPEG, or PNG.
Besides, despite what the metrics say, I find that JXL looks better than AVIF. What I assume is the deblocking filter removes too much detail. One could argue that as encoders started to be tuned based on perceptual metrics, they fell foul of Goodhart's law, and started getting optimized for what is measured, to the demerit of what isn't measured, even if those parts are important.
We had the same thought (see my above comment)! Yes, the working on the full pipeline is a strong argument. I started exporting images to JXL on my raw pipeline, and being available on web browsers (soon) is just a nice side-effect.
It is rarely mentioned, but a very strong argument in favour of JXL is that normal JPEGs can be 'repacked' into JXL with extremely low computational overhead (lossless recompression), while usually yielding 20-30% file size reductions. This is especially relevant if you have huge image libraries, where re-encoding is a considerable expense.
Those perceptual metrics, in my eyes, fall victim to Goodhart's law: They undermeasure higher-frequency losses, which to many (including me) are very perceptible. A picture can look pretty 'washed out' and 'waxy', but score favourably. Not to preach or anything, but AVIF, to my eyes, looks slightly worse than JXL in blind side-by-side comparisons, and you recognise the waxiness easily. So make sure to do your own side-by-side comparisons. To be fair, though, it is very close.
Generational loss: An underappreciated benchmark, but in my opinion very important, given images are constantly reused on the web for collages, memes ('deep frying' should be a familiar term for many), etc. The classical single-step benchmark of 'lossless source -> lossy format' doesn't reflect this well, and shows the weakness of using a video compression format for images. JXL has been designed to be stable under re-encoding, as evidenced in the video.
It is rarely mentioned, but a very strong argument in favour of JXL is that normal JPEGs can be 'repacked' into JXL with extremely low computational overhead (lossless recompression), while usually yielding 20-30% file size reductions.
It’s mentioned all the time, and covered in the article:
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. Modern consumer devices are powerful, but the argument that the savings come “for free” is misleading.
The article notes that recompression imposes a commensurate decode penalty:
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. Modern consumer devices are powerful, but the argument that the savings come “for free” is misleading.
Generational Loss would be a cool benchmark to set up.
The article notes that recompression imposes a commensurate decode penalty:
As far as I can tell, the article is incorrect. The default behavior in jxl-rs's CLI is to run a warmup and then run a timed decode. The author said on Discord that he was unaware of this and will need to correct the article. So I would assume that all times given for jxl-rs in this article should be halved.
"I have worked for 3 years on AVIF encoders while almost no work was done on JPEG XL encoders (because browsers demanded a rust decoder which for some reason no other format including AVIF needs), and so AVIF is now better and it's time to ignore JPEG XL" is certainly a take.
Yeah. There aren't very many people working on JXL right now, so there's a lot of low hanging fruit which hasn't been plucked. A huge portion of paid hours have gone into the safe Rust decoder, so there have been fewer hours of work going into the encoder. One of the developers working on the encoder (Jyrki) was laid off from Google.
Now that JXL will be supported across the web, I hope we see more interest in improving encoding. Awxkee has been working on a new encoder called Jixel, and it seems really promising, apparently better than libjxl in a lot of images already.
What do you mean? Modular mode is very much a mandatory thing for any JXL image, lossy or lossless. You could argue that there's some tools that modular has that aren't being made full use of, but it's certainly being used.
It's a compelling article, but in every comparison I've seen I've found JPEG-XL more faithful. How recent were these perceptual improvements? I may have to have another look at least to see if my feeling still holds.
I'm not sure if the points of poor performance on non-photographic images are relevant? Even if JXL is bad at that case, certainly there's no reason we can't have a codec on the web that's particularly good for photos, right? Even if AVIF is better in other cases, if JXL is good at photos, then there's immediately a ton of sites that can make use of it.
Similarly, I think the decoder performance issues might be something that we'll see improve over time now that the Rust decoder is being used in the major browsers. Poor worst-time performance is also an extremely solvable problem, even if by just stopping decoding past a certain absurd point of complexity; I definitely remember having similar issues with AVIF in its early days.
kangalio | 11 hours ago
In my opinion, the case for JPEG XL is not its depth, it's its breadth.
JPEG XL has an alpha channel, image size up to 1B x 1B, bit depth up to 32 bit, progressive decoding, animation, lossy and lossless, up to 4096 extra channels (depth, spot, etc), lossless JPEG conversion.
JPEG XL is not the format you choose for hyper-optimizing your web image delivery. It's the format you choose as default for anything where spending dozens of hours measuring the perfect codec is overkill, and you just want a kick-ass generalist codec that's ready for everything you throw at it in the future. That's JPEG XL.
JPEG XL is a perfect interchange format, the one image format whose capabilities make it truly universal. If we could choose one codec to be supported everywhere - the spiritual successor of JPEG - it has to be JPEG XL.
david_chisnall | 11 hours ago
I think this is a bad argument. A use case that affects 1% of web users is a requirement for more people than live in most European countries. The scale of the web means that appeals to averages are highly misleading. Having previews in one format and the final image that you download to go into some other flow in a different format is a problem because the artefacts will be different in the two formats, even if they’re both small in absolute terms.
The next line says that books and photos are part of an unrealistic data set. But photographers share their work with customers via the web. The most common format for eBooks is ePub, which is XHTML and is often rendered in a web view, or even a web app.
Diana | 9 hours ago
That plus
I can recompress my JPEG easily. Losslessly.
And yes, that is big for a lot of sites and ensure a quick path to actual use and deployment.
An e-commerce site is mostly image. Transparently reencoding it all to jxl is an easy win that gives instant adoption and benefits everyone.
It matters.
Pomax | 3 hours ago
Why would an e-commerce site need lossless images at all though? It needs to be as small as possible to load as fast as possible with perceptual compression so that potential buyers can see the products well enough to make a purchasing decision. Lossless encoding is not necessary in that context at all.
lonjil | 2 hours ago
Lossless recompression is not the same thing as usual lossless compression. Lossy compression always induces new artifacts. JXL as a special feature can take an already lossily encoded JPEG and shrink it by an average of 20% without introducing any new compression artifacts.
abhinav | 2 hours ago
I think what they mean is that the recompression from lossy JPEG -> JXL is lossless and reversible.
ignaloidas | 2 hours ago
Image quality is very important in purchasing decisions. Poorly compressed images may make the product seem worse than it actually is. Shopping is arguably the sector that generally chooses quite high quality levels for image compression because of this, the sites that go for as small as possible are usually news sites and social media.
markos | 8 hours ago
hsivonen | 10 hours ago
(Work hat explicitly off.)
As a user, I dislike the notion that only lower quality range is worthwhile to support on the Web. And I dislike comparisons that plot a graph without showing example images up front so that the reader could see if the comparison is about no visible artifacts quality or about which visual artifacts are less bad.
I think it's valuable that the original JPEG works pretty much everywhere. It's also valuable that PNG also works pretty much everywhere, including the Web even though lossless is arguable always too much quality for optimized Web images. I think it's valuable to get a format that can do all the newer things and covers the space that JPEG and PNG together cover to the point where it works everywhere.
For that to happen, the new thing has to be supported on the Web, because the Web is part of "everywhere".
(On the flip side, one thing that has annoyed users about WebP is that when WebP is chosen for its Web delivery characteristis, it doesn't Just Work everywhere else, if you save the file from the Web.)
Notably, the original JPEG is used as a capture format in high-end cameras and it is used for Web delivery. Folks who specialize in optimizing load times of Web sites would most likely say that the 4:4:4 high-quality JPEGs out of a camera are inappropriate for Web delivery.
And, yet, there is value in being able to take a camera JPEG, put in onto an HTTP server, and send the URL to someone, and they can see the picture in their browser and can decide to save the picture for further processing even if the picture has too much quality and size to be used on e.g. a news site. It's good that with JPEG you can view the original photo from Flickr within browser even if most of the time you want the site to use a rescaled and recompressed image for delivery.
Also, arguably you shouldn't have metadata at all for optimized Web delivery, but for photo storage use cases, it's really nice that JPEG XL supports compressed EXIF and XMP and cjxl compresses EXIF and XMP by default. I hope AVIF2 adopts these ISOBMFF box types.
Similarly, it's really nice that cjxl, by default, replaces sRGB and Display P3 ICC with CICP. That's excellent compression for non-pixel data! Nothing prevents avifenc from doing the same, but a couple of years ago when I evaluated things for storing my own photos, avifenc didn't do this.
It's also really nice that cjxl can recompress the pixels of a JPEG XL image retaining the metadata. Nothing prevents avifenc from offering this for AVIF, but when I checked a couple of years ago, avifenc didn't support AVIF as an input format. (A quick Web search suggests that it still doesn't.)
I think the main advantage of JPEG XL is that a user with limited time can figure out a libjxl encoder config that can be trusted to compress reasonably and not to result in visible artifacts for any realistic input. This leaves bits on the table compared to manually tuning AVIF parameters on a per photo basis to the level of what visible artifacts are tolerable. However, even if one-time settings for never getting visible artifacts is arguable too much quality e.g. for news sites, I think it's reasonable to want that kind of quality level and confidence even for some Web-targeting workflows.
bitshift | 53 minutes ago
I had never thought about "consistent encoding experience" being a feature, at least not explicitly. But that makes total sense! And it's not something that blog-post-style codec showdowns typically focus on.
(Though that would be an interesting post. "We compressed 100 different images with the same settings, here's the total file size, and here's the worst-looking one.")
juliobbv | 46 minutes ago
BTW, have you looked at recent devlopments in AVIF? Gone are the days of brute-forcing AVIF encoders to actually match a subjective quality target. Right now, AVIF encoders (libaom and SVT-AV1) offer better consistency vs. JXL!
Here's a good blog post to read up: https://aomedia.org/blog%20posts/Libavif_v1_4_0-Boasts-Major-Updates-to-Encoder-Technology/
lyall | 13 hours ago
The progressive decoding example seems very cherry-picked. I don’t think it’s fair to say that AVIF is superior to JXL in that respect. JXL shows a preview with fewer bytes than AVIF and refines the preview as more data arrives more gracefully than AVIF.
That being said, I think it would be fair to argue that AVIF is better suited for general web purposes. But JXL still deserves first class support in browsers and OSes. JXL is already being adopted in the photography world, and browsers should support viewing those images without requiring any conversion.
juliobbv | 44 minutes ago
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.
masklinn | 3 hours ago
by jxl proponents?
AVIF supports multiple levels of preview. The people at jpegxl.info decided to not use that.
ignaloidas | 3 hours ago
The point that was chosen for the screenshot is the exact point where AVIF starts showing anything. JXL shows stuff before that point, and has more progressive updates after that point.
juliobbv | 29 minutes ago
There's such a thing as "doing too many updates". Remember that modern devices try to save on power by reducing the number of buffer updates/screen refreshes. Having such a granular loading mechanism (many where the picture isn't even useful to look at) makes it for a very distracting experience, impacts battery, and further compounds the decode overhead JXL already has vs. other formats.
Furthermore, having passes where quality is too close to the final image is by itself an anti-pattern. This is because modern browsers don't give you an indication that a particular resource has fully loaded. If an image at a given time is a bit blurrier than expected, how can you tell you just need to wait for longer?
masklinn | 3 hours ago
That's true, it does show a blurrier and garbled-er mess before that.
which avif could have, if the jpexl.info people had encoded the image that way.
ignaloidas | 3 hours ago
Could it really? It's far from an efficient implementation of progressive images, and each additional step is manually defined and costly in decode time, while JXL gets the steps essentially for free because of how it's data is structured. If you can show something competitive in size, I'm interested to see, but I haven't seen anything like that yet. Right now, AVIF looks better for ~10% of the byte range, and I doubt you can improve that to more than 30%
masklinn | 2 hours ago
yes
ignaloidas | 2 hours ago
You're talking about a technical detail, not a "will it actually work". What's the file size with all 4 passes? (also, 4 is laughably few in comparison). Does those 4 passes allow it to look better across the majority of the byte range? Is this competitive in decode time? These are the questions that are important, not 'can it be done'.
markos | 2 hours ago
When is 4 not enough? What kind of image are you imagining pulling through which straw that you'd need more than that?
DustyFuzzy | 8 hours ago
I've never been after JPEG XL for it being "best in class", I've been after it because it's a format that works across the whole pipeline, which will never be the case for any of the formats that rely on being able to share code with a video codec. I don't need another image format designed for the web, I need an image format that happens to work on the web. Until JXL, that was either JPEG, or PNG.
Besides, despite what the metrics say, I find that JXL looks better than AVIF. What I assume is the deblocking filter removes too much detail. One could argue that as encoders started to be tuned based on perceptual metrics, they fell foul of Goodhart's law, and started getting optimized for what is measured, to the demerit of what isn't measured, even if those parts are important.
FRIGN | 5 hours ago
We had the same thought (see my above comment)! Yes, the working on the full pipeline is a strong argument. I started exporting images to JXL on my raw pipeline, and being available on web browsers (soon) is just a nice side-effect.
FRIGN | 5 hours ago
Three points.
masklinn | 3 hours ago
It’s mentioned all the time, and covered in the article:
pbronez | an hour ago
The article notes that recompression imposes a commensurate decode penalty:
Generational Loss would be a cool benchmark to set up.
lonjil | 23 minutes ago
As far as I can tell, the article is incorrect. The default behavior in jxl-rs's CLI is to run a warmup and then run a timed decode. The author said on Discord that he was unaware of this and will need to correct the article. So I would assume that all times given for jxl-rs in this article should be halved.
ignaloidas | 8 hours ago
"I have worked for 3 years on AVIF encoders while almost no work was done on JPEG XL encoders (because browsers demanded a rust decoder which for some reason no other format including AVIF needs), and so AVIF is now better and it's time to ignore JPEG XL" is certainly a take.
lonjil | 2 hours ago
Yeah. There aren't very many people working on JXL right now, so there's a lot of low hanging fruit which hasn't been plucked. A huge portion of paid hours have gone into the safe Rust decoder, so there have been fewer hours of work going into the encoder. One of the developers working on the encoder (Jyrki) was laid off from Google.
Now that JXL will be supported across the web, I hope we see more interest in improving encoding. Awxkee has been working on a new encoder called Jixel, and it seems really promising, apparently better than libjxl in a lot of images already.
FRIGN | 4 hours ago
Spot on, man. There are also things part of the JXL spec which haven't even been fully added to encoders yet, e.g. modular mode.
ignaloidas | 3 hours ago
What do you mean? Modular mode is very much a mandatory thing for any JXL image, lossy or lossless. You could argue that there's some tools that modular has that aren't being made full use of, but it's certainly being used.
kj | 14 hours ago
It's a compelling article, but in every comparison I've seen I've found JPEG-XL more faithful. How recent were these perceptual improvements? I may have to have another look at least to see if my feeling still holds.
paulirish | 11 hours ago
Something to keep in mind.. the SSIMULACRA 2 metric designer is the same as the author of JXL. (Not problematic, just an FYI..)
refi64 | 2 hours ago
I'm not sure if the points of poor performance on non-photographic images are relevant? Even if JXL is bad at that case, certainly there's no reason we can't have a codec on the web that's particularly good for photos, right? Even if AVIF is better in other cases, if JXL is good at photos, then there's immediately a ton of sites that can make use of it.
Similarly, I think the decoder performance issues might be something that we'll see improve over time now that the Rust decoder is being used in the major browsers. Poor worst-time performance is also an extremely solvable problem, even if by just stopping decoding past a certain absurd point of complexity; I definitely remember having similar issues with AVIF in its early days.