This is extremely annoying to me as a photographer, because JPEG XL was clearly the best of the up-and-coming JPEG replacements, but had the disadvantage of a later start compared to AVIF. Google’s decision is probably the death knell for JPEG XL.
I can’t help wondering what Google’s real motivation for this is. Of the four points given, ‘not enough interest from the entire ecosystem’ is obviously false, as just about every company with any significant interest in image delivery (such as Meta and Shopify) has expressed strong interest, as commenters in the issue thread point out. The point about not having ‘sufficient incremental benefits over existing formats’ could basically be interpreted as ‘it’s not better enough than AVIF’, basically compounded by the fact that AVIF was the first to market.
The only point they make which seems to contain a real kernel of truth is the maintenance burden of having to keep experimental code hidden behind a flag working long-term. Specifically, libjxl still doesn’t have a stable API and still isn’t feature-complete afaik as of writing, and being the only codec story going, keeping up with changes in it is obviously something of a maintenance issue. Again, it looks like JPEG XL was just too slow off the ground, including in this case the reference implementation just being too slow to stabilize.
There’s also the theory mentioned in the issue thread, that Google might still be hoping to push a proprietary image format they control over open formats like JPEG XL. I still wouldn’t rule that out, alas.
I hope this isn’t the end for JPEG XL, and that we might see it re-introduced after libjxl stabilizes, but it’s long seemed to me that Mozilla was already on the fence about it, so this might inspire them to kill support for it too. Sigh.
Your regular reminder not to use Chrome. Google are bullies with effective monopoly control over Web platform standards. Use Firefox or Safari.
It took ~3 years for cameras to start utilizing JPEG after it’s standardization. It took ~2 years for the web to start utilizing JPEG after it’s standardization. JPEG XL was standardized less than a year ago. These things take time.
But cameras have been producing HEIC or what have you for a while now, jpeg-xl would have to be meaningfully superior to make shifting happen, and if it does happen Google can always re-add support. In the mean time having it sit around merely creates maintenance work and adds attack surface. So again there’s no reason to keep it around.
AFAIK HEIC is only produced in Apple devices. And this is 7 years after it got standardized. AVIF is the same. Professional cameras right now essentially give you the manufacturers choice of raw or JPEG. JPEG XL could realistically replace both use-cases, as it has both great lossless compression, and good lossy compression. And I do think that with time manufacturers will start adding JPEG XL as an option.
Essentially, it hasn’t been a year since the standard got released. The current amount of usage is honestly huge when compared to other codecs. It took more than a year for ffmpeg to get AV1 support. JPEG XL took 3 months to get into ffmpeg.
My Sony A7Siii can produce either JPEG or HEIF images (along with RAW, of course). This also gives the option of capturing in the BT.2020 colour gamut, and HLG gamma.
In terms of implementing these in ffmpeg, how much of this is ground up implementation vs embedding a library - noting that ffmpeg implementing something or not isn’t a measure of popularity, just of popularity among some very specific groups.
(Side note: is it possible to get the actual raw data from an iPhone camera?)
The Web platform hasn’t figured out how to remove anything yet. It’s a Katamari Damacy of code. Every new feature will have to be maintained forever. Every new feature will be bloating every web view, and you’ll be redownloading them endlessly with every update of every Electron app you have.
On a technical level, vendors are reluctant to add more code. It’s a maintenance cost. It’s a security risk. It may become a compat headache if they ever need to change it. What vendors actually add is somewhat complex and you could say “political” (sometimes their own interest for their main business, sometimes pressure from users and web standards, sometimes fire and motion play to make competitors look bad).
Adoption of the AV1 codec was a pressing need, so it easily overcame the reluctance. Video bandwidth is way larger, with major business involved, and the open web had no answer to the commercial H.265 taking over. Without AV1 we’d have another decade of paying MPEG-LA and true free software being screwed (free-as-in-you’re-the-product browsers can purchase the license, but free-as-in-freedom browsers can’t).
And with AV1 in, AVIF was relatively cheap and easy to add. AVIF images are pretty much just 1-frame videos.
Non-Chrome(ium) browser vendors were very reluctant to adopt WebP before (for good reasons IMHO — WebP settled on the VP8 codec before it was fully baked in VP9). To avoid delayed adoption again, especially from Apple’s side, AVIF has been designed for Apple. The spec is basically “take the HEIF you already have, and put AV1 in it instead”. And it worked — we have AVIF in macOS, iOS, and Safari in a relatively short time.
JPEG XL does compress a bit better and much faster, but that just wasn’t enough to convince all browser vendors to take on yet another C++ library they will never be able to remove, given that AVIF is already here. We’ve had JPEG 2000 and JPEG XR and a few other formats that were a bit better than the format before it, and they didn’t go anywhere on the Web. The Web is lagging behind on image compression. We still have 1989 GIF and Chrome refusing to support MP4 in all the places where GIF works! With AVIF in, satisfying the HDR and wide gamut use-cases that didn’t work well before, and miraculously being interoperable in all major browsers, there’s just little appetite to start over again for an incremental gain.
One idea the “we can’t add things because we can’t remove them” aspect raises for me: the JPEG1 recompressor (formerly Brunsli) could work as a Content-Encoding. You can drop Content-Encodings (sdch!), and it’s smaller than JXL as a whole. There are enough JPEGs out there, and will be for a while, that saving a fifth or so of the bandwidth spent on them is a real win, and recompression is so much cheaper than software AVIF encoding.
[After writing this, I said something similar in a comment on the Content-Encoding bug linked above; why not.]
I suspect, organizationally/“politically,” the decision not to adopt JXL means they’re going to focus on AVIF and other ideas are mostly dead. It’s still kind of a nice thought.
sdch got dropped easily only because it never got widely adopted. Once anything is supported by majority of browsers for a while, hyrum’s law will find a way to make it unremovable. For example, you can’t remove support for gzip content encoding, because there certainly are some servers that send it unconditionally (violating HTTP protocol), just because that happens to work.
Lossless JPEG recompression is a great feature.
It may be possible to find a way to adopt Web features temporarily. Maybe browsers should add new image formats, but refuse to decode them on Wednesdays, so that all sites have to maintain a working fallback, so that it never becomes unremovable.
Eventually that becomes true, though arguably if the jxl encoding gets widespread enough to have the gzip problem, your experiment has shown that the new codec is worthwhile. It’s mostly if it’s unadopted like sdch that you want to drop it like sdch. Doing the experiment in the open, versus behind a flag, helps with the chicken-and-egg problem of browsers and authors each not wanting to get ahead of the other.
On the “doesn’t work on Wednesdays” concept:
I could imagine browsers refusing to use a new format and issuing a diagnostic if the image doesn’t appear to have a fallback in a common format. Of course, that’s a hack: the fallback may not really work, or a <picture> might have an <img> fallback whose format can’t be guessed from the URL. But it might help keep reliance on new formats from being the path of least resistance.
Separately I wonder if there is some sort of natural condition where a new browser might make a reasonable choice to ask for the plain JPEG and so make it less attractive to be that noncompliant server that assumes it can always serve JXL. Like, maybe Brunsli’s not worth much on small-dimension images, or with slow enough CPUs or fast enough connections.
I mean more than just experimenting to see if it’s going to get used enough to be unremovable. I mean being able to remove it once it is widely used, because JXL2/AVIF2/WebP2 will come and one-up it, and we’ll be back with “why do browsers support only this older codec when the new one is better?”.
You have to grease the fallbacks with hard breakage. On the web scale, approximately nobody pays attention to warnings in the console, and perhaps not even always to pages being visibly broken (there’s a bunch of sites developed once and left to rot). The fallback problem gets brought up when people ask “why don’t browsers bundle jQuery, even from a well-known URL with subresource integrity” and the answer is that if the URL isn’t actually used, it will go down or out of sync, and devs won’t notice.
Huge bummer. JXL has things that are qualitatively different from AVIF: progressive decoding for better perceived load speed, .jpg recompression to save bandwidth on a ton of existing content out there while allowing bit-for-bit recovery of the original, a really good lossless mode, and a faster software encoder.
I think there’s a good case for having both around: JXL has everything above, but AVIF handles extreme photo compression really well and seems natural as (say) an Android phone camera’s next-gen codec, especially when phones have AV1 hardware for video already.
I wonder if, and on what timeframe, AVIF gets pickup outside of the highly-optimized pipelines that serve WebP and multiple resolutions now. Apple just added AVIF decoding to their OSes (making it work in Safari) and next-gen dGPUs are getting hardware AV1 encoders. Faster software encoding would help.
… this thread alone shows a great deal interest from some small time companies like adobe and intel, other smaller companies like facebook have expressed interest in it too.
I’ve been telling the folks I work with to follow the browser support, and once a browser has it out from under a flag, we would include the format into our pipeline. With the <picture> element, luckily we can support many types with fallbacks, regardless of support, but as an up-and-coming open image format with incremental benefits and behind flags in multiple browsers, this surely caught me off guard. Given the weight Google has to throw around in the browser space, I hope JPEG XL doesn’t become dead-on-arrival. At least AVIF seems to be gaining steam (and GPUs now marketing AV1 hardware encoding).
This “next generation JPEG standard with all the bells and whistles you could ever imagine and a bit better compression ratio that will be ready for mainstream adoption Soon™️” thing has been going on for many decades at this point, it’s getting a bit tiring.
The difference is that JPEG XL is actually really good and a big jump from what’s currently commonly used. Compression ratio jump is fairly significant, bells and whistles there for every step of production process, etc. The only thing that’s stopping it is the reference library being slow to be complete. If major browsers added support for it by default, I believe that within a year 10-20% of all images shown would be in JPEG XL.
The difference is that JPEG XL is actually really good and a big jump from what’s currently commonly used. Compression ratio jump is fairly significant, bells and whistles there for every step of production process, etc
I was told exactly the same things about JPEG 2000, and it was named when 2000 sounded futuristic.
Fair point. Difference is that JPEG XL is carrying 30 years of improvements instead on 8. To be fair, the encoding format has a lot of stuff that has good potential to improve compression ratio even more, but isn’t utilized by current encoders, I expect to see a fairly decent progress in compression ratio as encoders improve.
JPEG2000 definitely found its niches - just because your camera isn’t taking them doesn’t mean they aren’t in use. A lot of digital cinema is distributed as JPEG2000 frames, for example.
20 years ago, it was usable in browsers via plugins, but it was never integrated and browsers dropped plugin support. If your camera supports it then you need to transform images from wavelet to DCT compression for web publishing, which has been a problem for consumer use.
The fact that it’s a niche is largely my point though: in the late ‘90s, it was going to completely displace JPEG, now it’s ‘found it’s niches’. As far as I remember, wavelets turned out to be a patent minefield and license fees killed widespread adoption.
I dunno about “next generation JPEG” but I use WEBP for all the images on my site with low res JPEG fallbacks and don’t get any complaints about it. WEBP is pretty much here.
Yeah, WebP is pretty widely supported (I was surprised to see even WebKit supports it now!). I was specifically talking about JPEG standards though, meaning standards from the Joint Photographic Experts Group.
It took a long time before Mozilla gave into supporting it though. I don’t remember the reasons why, but I think there was a point where they were getting too many web compat issues and folks weren’t using the <picture> element to provide the necessary fallbacks and progressive enhancements.
This is extremely annoying to me as a photographer, because JPEG XL was clearly the best of the up-and-coming JPEG replacements, but had the disadvantage of a later start compared to AVIF. Google’s decision is probably the death knell for JPEG XL.
I can’t help wondering what Google’s real motivation for this is. Of the four points given, ‘not enough interest from the entire ecosystem’ is obviously false, as just about every company with any significant interest in image delivery (such as Meta and Shopify) has expressed strong interest, as commenters in the issue thread point out. The point about not having ‘sufficient incremental benefits over existing formats’ could basically be interpreted as ‘it’s not better enough than AVIF’, basically compounded by the fact that AVIF was the first to market.
The only point they make which seems to contain a real kernel of truth is the maintenance burden of having to keep experimental code hidden behind a flag working long-term. Specifically, libjxl still doesn’t have a stable API and still isn’t feature-complete afaik as of writing, and being the only codec story going, keeping up with changes in it is obviously something of a maintenance issue. Again, it looks like JPEG XL was just too slow off the ground, including in this case the reference implementation just being too slow to stabilize.
There’s also the theory mentioned in the issue thread, that Google might still be hoping to push a proprietary image format they control over open formats like JPEG XL. I still wouldn’t rule that out, alas.
I hope this isn’t the end for JPEG XL, and that we might see it re-introduced after libjxl stabilizes, but it’s long seemed to me that Mozilla was already on the fence about it, so this might inspire them to kill support for it too. Sigh.
Your regular reminder not to use Chrome. Google are bullies with effective monopoly control over Web platform standards. Use Firefox or Safari.
Do you know what the status is for JPEG XL within the big content creation toolkits like the ones Adobe makes?
I have to ask because my latest version of an Adobe product is Lightroom 6 and AFAIK it didn’t have XL support.
Not Adobe but if anyone is wondering about the FOSS space, these have (or can have) JPEG XL support: GIMP, darktable, ImageMagick, & ffmpeg
It has been recently added to Camera Raw for HDR exporting. I’d expect other tools to follow soon-ish.
Why would you expect this? Cameras aren’t producing jpegxl, and Adobe has had more than long enough to implement support if they wanted it.
It took ~3 years for cameras to start utilizing JPEG after it’s standardization. It took ~2 years for the web to start utilizing JPEG after it’s standardization. JPEG XL was standardized less than a year ago. These things take time.
But cameras have been producing HEIC or what have you for a while now, jpeg-xl would have to be meaningfully superior to make shifting happen, and if it does happen Google can always re-add support. In the mean time having it sit around merely creates maintenance work and adds attack surface. So again there’s no reason to keep it around.
AFAIK HEIC is only produced in Apple devices. And this is 7 years after it got standardized. AVIF is the same. Professional cameras right now essentially give you the manufacturers choice of raw or JPEG. JPEG XL could realistically replace both use-cases, as it has both great lossless compression, and good lossy compression. And I do think that with time manufacturers will start adding JPEG XL as an option.
Essentially, it hasn’t been a year since the standard got released. The current amount of usage is honestly huge when compared to other codecs. It took more than a year for ffmpeg to get AV1 support. JPEG XL took 3 months to get into ffmpeg.
My Sony A7Siii can produce either JPEG or HEIF images (along with RAW, of course). This also gives the option of capturing in the BT.2020 colour gamut, and HLG gamma.
How do android devices store HDR images?
In terms of implementing these in ffmpeg, how much of this is ground up implementation vs embedding a library - noting that ffmpeg implementing something or not isn’t a measure of popularity, just of popularity among some very specific groups.
(Side note: is it possible to get the actual raw data from an iPhone camera?)
JPEG XL was not first to market, offers no compelling benefits of avif based formats, and isn’t a format produced by any existing consumer product.
A few people in comment threads != real demand.
Demand = consumer products produce it.
The cost of jpegxl is a complex image parser that exposes a large attack surface in exchange for a feature no one is asking for.
Safari has had multiple vulnerabilities due to it exposing unneeded image formats to the web, so this is not some made up concern.
The Web platform hasn’t figured out how to remove anything yet. It’s a Katamari Damacy of code. Every new feature will have to be maintained forever. Every new feature will be bloating every web view, and you’ll be redownloading them endlessly with every update of every Electron app you have.
On a technical level, vendors are reluctant to add more code. It’s a maintenance cost. It’s a security risk. It may become a compat headache if they ever need to change it. What vendors actually add is somewhat complex and you could say “political” (sometimes their own interest for their main business, sometimes pressure from users and web standards, sometimes fire and motion play to make competitors look bad).
Adoption of the AV1 codec was a pressing need, so it easily overcame the reluctance. Video bandwidth is way larger, with major business involved, and the open web had no answer to the commercial H.265 taking over. Without AV1 we’d have another decade of paying MPEG-LA and true free software being screwed (free-as-in-you’re-the-product browsers can purchase the license, but free-as-in-freedom browsers can’t).
And with AV1 in, AVIF was relatively cheap and easy to add. AVIF images are pretty much just 1-frame videos.
Non-Chrome(ium) browser vendors were very reluctant to adopt WebP before (for good reasons IMHO — WebP settled on the VP8 codec before it was fully baked in VP9). To avoid delayed adoption again, especially from Apple’s side, AVIF has been designed for Apple. The spec is basically “take the HEIF you already have, and put AV1 in it instead”. And it worked — we have AVIF in macOS, iOS, and Safari in a relatively short time.
JPEG XL does compress a bit better and much faster, but that just wasn’t enough to convince all browser vendors to take on yet another C++ library they will never be able to remove, given that AVIF is already here. We’ve had JPEG 2000 and JPEG XR and a few other formats that were a bit better than the format before it, and they didn’t go anywhere on the Web. The Web is lagging behind on image compression. We still have 1989 GIF and Chrome refusing to support MP4 in all the places where GIF works! With AVIF in, satisfying the HDR and wide gamut use-cases that didn’t work well before, and miraculously being interoperable in all major browsers, there’s just little appetite to start over again for an incremental gain.
One idea the “we can’t add things because we can’t remove them” aspect raises for me: the JPEG1 recompressor (formerly Brunsli) could work as a Content-Encoding. You can drop Content-Encodings (sdch!), and it’s smaller than JXL as a whole. There are enough JPEGs out there, and will be for a while, that saving a fifth or so of the bandwidth spent on them is a real win, and recompression is so much cheaper than software AVIF encoding.
[After writing this, I said something similar in a comment on the Content-Encoding bug linked above; why not.]
I suspect, organizationally/“politically,” the decision not to adopt JXL means they’re going to focus on AVIF and other ideas are mostly dead. It’s still kind of a nice thought.
sdch got dropped easily only because it never got widely adopted. Once anything is supported by majority of browsers for a while, hyrum’s law will find a way to make it unremovable. For example, you can’t remove support for gzip content encoding, because there certainly are some servers that send it unconditionally (violating HTTP protocol), just because that happens to work.
Lossless JPEG recompression is a great feature.
It may be possible to find a way to adopt Web features temporarily. Maybe browsers should add new image formats, but refuse to decode them on Wednesdays, so that all sites have to maintain a working fallback, so that it never becomes unremovable.
Eventually that becomes true, though arguably if the jxl encoding gets widespread enough to have the gzip problem, your experiment has shown that the new codec is worthwhile. It’s mostly if it’s unadopted like sdch that you want to drop it like sdch. Doing the experiment in the open, versus behind a flag, helps with the chicken-and-egg problem of browsers and authors each not wanting to get ahead of the other.
On the “doesn’t work on Wednesdays” concept:
I could imagine browsers refusing to use a new format and issuing a diagnostic if the image doesn’t appear to have a fallback in a common format. Of course, that’s a hack: the fallback may not really work, or a
<picture>might have an<img>fallback whose format can’t be guessed from the URL. But it might help keep reliance on new formats from being the path of least resistance.Separately I wonder if there is some sort of natural condition where a new browser might make a reasonable choice to ask for the plain JPEG and so make it less attractive to be that noncompliant server that assumes it can always serve JXL. Like, maybe Brunsli’s not worth much on small-dimension images, or with slow enough CPUs or fast enough connections.
I mean more than just experimenting to see if it’s going to get used enough to be unremovable. I mean being able to remove it once it is widely used, because JXL2/AVIF2/WebP2 will come and one-up it, and we’ll be back with “why do browsers support only this older codec when the new one is better?”.
You have to grease the fallbacks with hard breakage. On the web scale, approximately nobody pays attention to warnings in the console, and perhaps not even always to pages being visibly broken (there’s a bunch of sites developed once and left to rot). The fallback problem gets brought up when people ask “why don’t browsers bundle jQuery, even from a well-known URL with subresource integrity” and the answer is that if the URL isn’t actually used, it will go down or out of sync, and devs won’t notice.
(Also, strong agree that a VP9-based WebP released around when VP9 came out would’ve been a much stronger contender.)
Huge bummer. JXL has things that are qualitatively different from AVIF: progressive decoding for better perceived load speed, .jpg recompression to save bandwidth on a ton of existing content out there while allowing bit-for-bit recovery of the original, a really good lossless mode, and a faster software encoder.
I think there’s a good case for having both around: JXL has everything above, but AVIF handles extreme photo compression really well and seems natural as (say) an Android phone camera’s next-gen codec, especially when phones have AV1 hardware for video already.
I wonder if, and on what timeframe, AVIF gets pickup outside of the highly-optimized pipelines that serve WebP and multiple resolutions now. Apple just added AVIF decoding to their OSes (making it work in Safari) and next-gen dGPUs are getting hardware AV1 encoders. Faster software encoding would help.
Of course, it’s all open source so you can always just add it back in. /s
Best comment in the tracker so far:
I thought this Meta burn was pretty good too:
I’ve been telling the folks I work with to follow the browser support, and once a browser has it out from under a flag, we would include the format into our pipeline. With the
<picture>element, luckily we can support many types with fallbacks, regardless of support, but as an up-and-coming open image format with incremental benefits and behind flags in multiple browsers, this surely caught me off guard. Given the weight Google has to throw around in the browser space, I hope JPEG XL doesn’t become dead-on-arrival. At least AVIF seems to be gaining steam (and GPUs now marketing AV1 hardware encoding).This “next generation JPEG standard with all the bells and whistles you could ever imagine and a bit better compression ratio that will be ready for mainstream adoption Soon™️” thing has been going on for many decades at this point, it’s getting a bit tiring.
The difference is that JPEG XL is actually really good and a big jump from what’s currently commonly used. Compression ratio jump is fairly significant, bells and whistles there for every step of production process, etc. The only thing that’s stopping it is the reference library being slow to be complete. If major browsers added support for it by default, I believe that within a year 10-20% of all images shown would be in JPEG XL.
I was told exactly the same things about JPEG 2000, and it was named when 2000 sounded futuristic.
Fair point. Difference is that JPEG XL is carrying 30 years of improvements instead on 8. To be fair, the encoding format has a lot of stuff that has good potential to improve compression ratio even more, but isn’t utilized by current encoders, I expect to see a fairly decent progress in compression ratio as encoders improve.
JPEG2000 definitely found its niches - just because your camera isn’t taking them doesn’t mean they aren’t in use. A lot of digital cinema is distributed as JPEG2000 frames, for example.
20 years ago, it was usable in browsers via plugins, but it was never integrated and browsers dropped plugin support. If your camera supports it then you need to transform images from wavelet to DCT compression for web publishing, which has been a problem for consumer use.
The fact that it’s a niche is largely my point though: in the late ‘90s, it was going to completely displace JPEG, now it’s ‘found it’s niches’. As far as I remember, wavelets turned out to be a patent minefield and license fees killed widespread adoption.
I dunno about “next generation JPEG” but I use WEBP for all the images on my site with low res JPEG fallbacks and don’t get any complaints about it. WEBP is pretty much here.
Yeah, WebP is pretty widely supported (I was surprised to see even WebKit supports it now!). I was specifically talking about JPEG standards though, meaning standards from the Joint Photographic Experts Group.
It took a long time before Mozilla gave into supporting it though. I don’t remember the reasons why, but I think there was a point where they were getting too many web compat issues and folks weren’t using the
<picture>element to provide the necessary fallbacks and progressive enhancements.