- Experimental flags and code should not remain indefinitely
- There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL
- The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default
- By removing the flag and the code in M110, it reduces the maintenance burden and allows us to focus on improving existing formats in Chrome
It's nonsense -- how can they claim "not enough interest" when we can't enable the feature on a public website (our visitors won't be able to see images).
It is literally the same people. I designed WebP lossless and had a lead role in Pik and JPEG XL (invented and implemented gaborish, xyb colorspace, adaptive quantization and block splitting heuristics, modulating epf with adaptive quantization, etc.)
From what I read Firefox is also just linking libjxl , so what kind of finishing should they have been doing? Google gave it, Google took it. If nobody fixes the monopoly, this will be the future of all web standards.
Come on, how often has Google been the first to enable new browser features forcing the hand of Mozilla and Apple? Google know they are the gatekeepers of web tech. This is just a way for them to kill the format
People complain to high heaven google shouldn't get to decide.
Great, so then convince the others, don't rely on Google to do it.
As for killing the format - Google maintains libjxl, the jpeg-xl reference impl, and has for years.
But like, if the people maintaining the reference impl for years really want to kill the format, maybe we should at least understand why?
They've been in the thick of it, after all.
Controlling an image format is basically worthless for a company like Google. Especially since they are always royalty free so far.
The cost to Google in bandwidth/storage/etc of images is much greater than than they could ever make off control.
There are two reasons why you would use a higher compressing image format.
(1) To save network bandwidth, (2) to save storage.
Adding AVIF, WebP, and JPEG XL to a JPG file help with (1). To help with (2) you have to be able to replace the JPG with something new. Supporting more than one new file format is counterproductive.
It took me years to decide WebP was well-supported enough to be worth using but until very recently it still got a major caveat
that "Safari 14.0 – 15.6 has full support of WebP, but requires macOS 11 Big Sur or later."
With new image formats Apple decides it is a reason why you should buy a new machine and decides not to add a decoder to the library that works with older processors.
None of the other browser vendors have implemented support for it and all the other browser vendors have supported the comparable AVIF format (which is live across the board except in Edge), so this seems pretty much a "noone is interested in this" type scenario.
Ecosystem doesn't mean a few fans on HN, in this context they mean "people building browsers".
Ok, people seem upset about this off by default support being removed. What is it that makes jpegxl valuable given that there’s already widespread adoption and support for av1, webp, etc?
Baring in mind that turning on jpegxl means exposing yet another image format parser to the web and the security track record of image formats has not been stellar.
Lossless transcoding is not a selling point IMO. It’s not relevant for new images (new devices aren’t producing jpegs), and I just don’t see people mass re-encoding their photo libraries.
Features that actually matter to normal users are what is important.
In that area progressive display seems like it would arguably be more useful, though I think it would still be dependent on what the image size is - websites now routinely require megs of JS to display anything at all, because net speeds are now fast enough that huge amounts of data are needed to get to a “noticeable” latency that would warrant display of incomplete data.
Just did a quick test comparing WEBP and JXL when saved at a file size equivalent to JPEG quality 90.
WEBP has blurry chroma, looking like it's subsampled then upscaled.
The chroma on JPEG-XL is trying to be full resolution, and if you look at the chroma in isolation, it looks a bit blocky, but it's not blurry at all.
The lossless recompression of existing .jpg content and faster software encoding for its native VarDCT format seem to provide immediate benefits in contexts where AVIF doesn't fit well now, either because AVIF encoding is slow or because AVIF would require a lossy reencoding of a lossily compressed source.
The comments on the bug are quite rude and condescending, as happens often when HN links to a "surprise" decision in chromium. Would hate to be on the other side of this, though perhaps being more transparent could make their argument sound better.
It's technically possible that, without all of JXL, they could implement the lossless JPEG1 recompressor part (Brunsli) as a Content-Encoding like gzip, which could save about 20% on all the JPEG content out there with no additional loss: https://bugs.chromium.org/p/chromium/issues/detail?id=110969...
Compared to all of JPEG XL, Brunsli is less code, and the adoption story is more compelling: you need CDNs/infra to support recompression, but don't need the entire ecosystem to change formats. Content-Encodings can be dropped if there isn't uptake--there's precedent with SDCH--so you could roll it out without a flag once it's well tested and give sites a reason to add support, avoiding a chicken and egg problem.
I don't think AVIF makes it irrelevant because 1) JPEG-to-Brunsli is a far smaller step than JPEG-to-AVIF, since Brunsli is far faster to encode than AVIF (especially in software) and adds no loss beyond the initial JPEG encode, and 2) even if AVIF and HEIC are widely adopted, there's a mind-boggling quantity of JPEGs (exabytes?) that won't go away. Dropping JXL as an image format makes the Content-Encoding more relevant, since the lossless recompression it provides is no longer going to be available by other means.
A star expressing interest in 1109698 couldn't hurt the chances (though I suspect they're slim). They haven't closed the bug, so I don't think they've officially said they'll never do it, though the current language does assume third_party/jpegxl exists.
Technically that's a fine idea, but practically - I think this will merely be a distraction and slow everything down. There's not a lot of point to brunsli if you've got jxl, and brunsli would make further non-transcoding improvements that jxl also enables harder to reach. It's also going to be yet another adoption problem (though given chromium's market share I guess they can just force brunsli into real-world usage without firefox or even webkit support). Finally, if jxl falls through permanently and brunsli succeeds - it's still probably time to look for a new codec; perhaps AVIF might succeed where jxl wont (I hear your concerns, but that might be acceptable or improvable). After all, there's a very good chance that given the presence of the AV1 decoder the extra complexity of AVIF in chromium might be very small, which seems to be one of their concerns. AVIF might render brunsli the kind of intermediate step that's not worth it.
I think voting up the issue is probably a quicker chance of getting a satisfactory resolution (simply supporting jxl). Alternately, perhaps a WASM based polyfill might be possible, and hope that if at least one other browser adopts it natively and a polyfill is available, that chrome will reconsider.
Worst case - if this turns out to be irreversible - even then I think it's more strategic to let the inevitable dust this will cause settle, and then start picking up the pieces afterwards - the discussions in the interim might reveal more of the chromium teams reason for blocking this, which might inform future steps.
I think the decision on JPEG XL as a whole is made; there were some statements in favor of adopting it on Chrome's and Mozilla's trackers before the decision from folks at Adobe, Facebook, Intel, and a newspaper, and some developers of it and natural advocates of it were inside Google; general-public comments seem less impactful than all that. If I had to guess, the trigger was Apple supporting AVIF and Chrome folks concluding AVIF "won." They might also have decided they think Apple is unlikely to ever do JXL, but they probably wouldn't comment publicly on what they think someone else will do.
The case for a Brunsli filter in the meantime is legacy JPEG content is never going away, and there will also be a long "meantime" where we know AVIF is the endpoint but it's still impractical for many because of SW encoding cost. Brunsli saves ~20%, so it's not nothing, and it's CPU-cheap.
A WASM polyfill would kind of be cool. Someone did it for Bellard's "BPG" (HEIC in a different container) in a ServiceWorker, and one just doing JPEG1 transcoding would be even lighter (and, unlike this PNG-making polyfill, would save reasonably small JPG files if the user right-clicks): https://sequentialread.com/better-portable-graphics-bpg-on-t...
I must admit I've heard of this format, but it seems good...
Although I do wonder how much value this would add for most sites. WEBP is pretty good and well supported today. Plus internet speeds are fast enough now that images tend to be much lighter than all the various tracking libraries and frontend frameworks that the browser needs to load anyway. Unless you run a very image heavy site the performance impact here would probably be negligible over WEBP and in many cases it might not even be worth the dev effort to switch to JPEG XL even if you're still using JPG.
That's not to say I think it should be removed, but just an acknowledgment that there's probably point of dismissing return here in which it doesn't make sense to support a slightly better image format, because the effort to support it exceeds the negligible benefits.
It's actually the other way around: WebP images are about the same size as JPEG encoded with mozjpeg -- compression is no better. WebP does have advantages for images with transparency. Google effectively abandoned webp more than five years ago now and began work on webp2. But they've now abandoned that as well.
JXL, AVIF and HEIC use next-gen compressors and are about half the size of JPEG and WebP at the same quality. HEIC has a range of terrible patent problems, so the current choice is AVIF vs JXL.
AVIF has wider industry support and is likely to get hardware decode. JXL is technically more interesting and more flexible, and far better CPU encode/decode performance.
Well, nevertheless we should all move forward to JPEG XL as the commonly agreed on next-gen image format, as soon as it becomes generally available with other major browsers.
(Google has demonstrably the code to render this. If they decide to stay outside for political reasons, well, so be it.)
(Webkit seems to have basic integration ready, but to be still working on color profile decoding and animations [1]; Firefox seems to be fairly complete. What other Chromium-based browsers are going to do, remains to be seen. I hope, they will decide to patch the code to support JPEG XL.)
P.S.: If this was meant as a snarky remark on market shares, well… (I'd be happy to see the bias towards Chrome somewhat diminishing, especially in developer communities. If folks would start developing in other browsers according to web standards and then test with Chrome, some common perceptions may shift.)
And this is why companies/open source maintainers hide their discussion from public. There does not seem to be any malicious intent behind this move, yet they are getting bashed because they removed it even though they are the only one with the implantation for it in the first place. Also every commentator with '@gmail.com' is certain that entire industry is supporting JPEG XL and they are sure it doesn't require any maintenance if it left in the codebase[0].
A Wasm implementation of JPEG XL is 174 kB, and a minimal implementation (reflecting the libjxl-tiny encoder) can be done in somewhere around 25-50 kB. Wasm is rather performant and can render both normal and HDR JPEG XL's in browsers.
(As I understand it – and this is not much –, libjxl returns a bitmap and an ICC profile, which then has to be matched against the color space of the display. How is this going to work in a WASM decoder inside the browser? Or does it just render in sRGB, hoping for the best?)
45 comments
[ 0.21 ms ] story [ 110 ms ] thread- Experimental flags and code should not remain indefinitely
- There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL
- The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default
- By removing the flag and the code in M110, it reduces the maintenance burden and allows us to focus on improving existing formats in Chrome
It's nonsense -- how can they claim "not enough interest" when we can't enable the feature on a public website (our visitors won't be able to see images).
That doesn't seem like a lot of interest as far as anyone can tell. The main interest has been from Facebook and Adobe, afaik.
If it's wrong it can be redone later. It isn't a blood oath never to reimplement it.
The way this gets fixed for real, at least to me, is to get mozilla/apple to have skin in the game.
As for killing the format - Google maintains libjxl, the jpeg-xl reference impl, and has for years.
But like, if the people maintaining the reference impl for years really want to kill the format, maybe we should at least understand why? They've been in the thick of it, after all.
Controlling an image format is basically worthless for a company like Google. Especially since they are always royalty free so far.
The cost to Google in bandwidth/storage/etc of images is much greater than than they could ever make off control.
(Unlike, say, Adobe or someone)
There are two reasons why you would use a higher compressing image format.
(1) To save network bandwidth, (2) to save storage.
Adding AVIF, WebP, and JPEG XL to a JPG file help with (1). To help with (2) you have to be able to replace the JPG with something new. Supporting more than one new file format is counterproductive.
It took me years to decide WebP was well-supported enough to be worth using but until very recently it still got a major caveat
https://caniuse.com/webp
that "Safari 14.0 – 15.6 has full support of WebP, but requires macOS 11 Big Sur or later."
With new image formats Apple decides it is a reason why you should buy a new machine and decides not to add a decoder to the library that works with older processors.
Ecosystem doesn't mean a few fans on HN, in this context they mean "people building browsers".
Arguably the best image format to come out since JPEG:
- High-fidelity lossy image compression
- Best lossless image compression
- Progressive decoding
- Lossless JPEG transcoding
The post’s linked ticket tracks the feature from when it was introduced to Chrome.
Baring in mind that turning on jpegxl means exposing yet another image format parser to the web and the security track record of image formats has not been stellar.
IMO the killer feature of JPEG XL is its ability to losslessly transcode already existing JPEG images.
See also these articles for a more detailed comparison:
https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_im...
https://cloudinary.com/blog/time_for_next_gen_codecs_to_deth...
(disclaimer: they were written by one of the authors of JPEG XL)
It's a nice transitory feature, but I think improved progressive decoding is even more worthwhile.
Features that actually matter to normal users are what is important.
In that area progressive display seems like it would arguably be more useful, though I think it would still be dependent on what the image size is - websites now routinely require megs of JS to display anything at all, because net speeds are now fast enough that huge amounts of data are needed to get to a “noticeable” latency that would warrant display of incomplete data.
WEBP has blurry chroma, looking like it's subsampled then upscaled. The chroma on JPEG-XL is trying to be full resolution, and if you look at the chroma in isolation, it looks a bit blocky, but it's not blurry at all.
The lossless recompression of existing .jpg content and faster software encoding for its native VarDCT format seem to provide immediate benefits in contexts where AVIF doesn't fit well now, either because AVIF encoding is slow or because AVIF would require a lossy reencoding of a lossily compressed source.
Compared to all of JPEG XL, Brunsli is less code, and the adoption story is more compelling: you need CDNs/infra to support recompression, but don't need the entire ecosystem to change formats. Content-Encodings can be dropped if there isn't uptake--there's precedent with SDCH--so you could roll it out without a flag once it's well tested and give sites a reason to add support, avoiding a chicken and egg problem.
I don't think AVIF makes it irrelevant because 1) JPEG-to-Brunsli is a far smaller step than JPEG-to-AVIF, since Brunsli is far faster to encode than AVIF (especially in software) and adds no loss beyond the initial JPEG encode, and 2) even if AVIF and HEIC are widely adopted, there's a mind-boggling quantity of JPEGs (exabytes?) that won't go away. Dropping JXL as an image format makes the Content-Encoding more relevant, since the lossless recompression it provides is no longer going to be available by other means.
A star expressing interest in 1109698 couldn't hurt the chances (though I suspect they're slim). They haven't closed the bug, so I don't think they've officially said they'll never do it, though the current language does assume third_party/jpegxl exists.
I think voting up the issue is probably a quicker chance of getting a satisfactory resolution (simply supporting jxl). Alternately, perhaps a WASM based polyfill might be possible, and hope that if at least one other browser adopts it natively and a polyfill is available, that chrome will reconsider.
Worst case - if this turns out to be irreversible - even then I think it's more strategic to let the inevitable dust this will cause settle, and then start picking up the pieces afterwards - the discussions in the interim might reveal more of the chromium teams reason for blocking this, which might inform future steps.
The case for a Brunsli filter in the meantime is legacy JPEG content is never going away, and there will also be a long "meantime" where we know AVIF is the endpoint but it's still impractical for many because of SW encoding cost. Brunsli saves ~20%, so it's not nothing, and it's CPU-cheap.
A WASM polyfill would kind of be cool. Someone did it for Bellard's "BPG" (HEIC in a different container) in a ServiceWorker, and one just doing JPEG1 transcoding would be even lighter (and, unlike this PNG-making polyfill, would save reasonably small JPG files if the user right-clicks): https://sequentialread.com/better-portable-graphics-bpg-on-t...
Although I do wonder how much value this would add for most sites. WEBP is pretty good and well supported today. Plus internet speeds are fast enough now that images tend to be much lighter than all the various tracking libraries and frontend frameworks that the browser needs to load anyway. Unless you run a very image heavy site the performance impact here would probably be negligible over WEBP and in many cases it might not even be worth the dev effort to switch to JPEG XL even if you're still using JPG.
That's not to say I think it should be removed, but just an acknowledgment that there's probably point of dismissing return here in which it doesn't make sense to support a slightly better image format, because the effort to support it exceeds the negligible benefits.
JXL, AVIF and HEIC use next-gen compressors and are about half the size of JPEG and WebP at the same quality. HEIC has a range of terrible patent problems, so the current choice is AVIF vs JXL.
AVIF has wider industry support and is likely to get hardware decode. JXL is technically more interesting and more flexible, and far better CPU encode/decode performance.
(Google has demonstrably the code to render this. If they decide to stay outside for political reasons, well, so be it.)
(Webkit seems to have basic integration ready, but to be still working on color profile decoding and animations [1]; Firefox seems to be fairly complete. What other Chromium-based browsers are going to do, remains to be seen. I hope, they will decide to patch the code to support JPEG XL.)
[1] Webkit has a quite dedicated declaration on its related ticket, "JPEG XL is the future of all image formats." https://bugs.webkit.org/show_bug.cgi?id=208235
----
P.S.: If this was meant as a snarky remark on market shares, well… (I'd be happy to see the bias towards Chrome somewhat diminishing, especially in developer communities. If folks would start developing in other browsers according to web standards and then test with Chrome, some common perceptions may shift.)
It was.
I'm a Firefox user, and web developer. Features live and die based on their caniuse profile.
I'd love to deploy JXL but I can't if Chrome Devs hold this attitude. Doesn't really matter what other browsers do at this point.
[0]: https://bugs.chromium.org/p/chromium/issues/detail?id=117805...
(As I understand it – and this is not much –, libjxl returns a bitmap and an ICC profile, which then has to be matched against the color space of the display. How is this going to work in a WASM decoder inside the browser? Or does it just render in sRGB, hoping for the best?)