6 ms·

Removing the JPEG XL code and flag from Chromium

60 points by yboris 4y ago

bricss 4y ago
G and bananas stuff as usual
yboris 4y ago
Rare opportunity to comment on the wrong decision Chrome is making.
- PaulHoule 4y ago
  What's up with this? What is their motivation?
  - yboris 4y ago
    They claim: - 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).
    - skyde 4y ago
      real reason is that it compete with WebP format :-)
      - delroth 4y ago
        JPEG XL is based on Google's Pik, and several of the top contributors to libjxl are on Google's payroll: https://github.com/libjxl/libjxl/graphs/contributors https://github.com/libjxl/libjxl/graphs/contributors
        JyrkiAlakuijala 4y ago
        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.)
        skyde 4y ago
        I was confusing JPEG XL with JPEG XR. If google want to kill JPEG XL, this is fine. Since no one is using it I beleive.
    - izacus 4y ago
      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".
    - DannyBee 4y ago
      Neither Mozilla nor Apple ever finished the implementations enough to even enable them, and they aren't being worked on. 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.
      - riedel 4y ago
        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.
        DannyBee 4y ago
        libjxl still exists, it's still available. The way this gets fixed for real, at least to me, is to get mozilla/apple to have skin in the game.
      - biftek 4y ago
        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
        DannyBee 4y ago
        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. (Unlike, say, Adobe or someone)
      - 4y ago
- deleted 4y ago
  [deleted]
yboris 4y ago
For the uninitiated https://jpegxl.info/ https://jpegxl.info/ ;) Arguably the best image format to come out since JPEG: - High-fidelity lossy image compression - Best lossless image compression - Progressive decoding - Lossless JPEG transcoding
lucasmullens 4y ago
This is from 2 years ago. Did something change recently?
- carl_dr 4y ago
  They announced 2 days ago that it will be removed in Chrome 110 : https://www.phoronix.com/news/Chrome-Deprecating-JPEG-XL https://www.phoronix.com/news/Chrome-Deprecating-JPEG-XL The post’s linked ticket tracks the feature from when it was introduced to Chrome.
olliej 4y ago
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.
- xeeeeeeeeeeenu 4y ago
  >What is it that makes jpegxl valuable given that there’s already widespread adoption and support for av1, webp, etc? 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_image_codecs https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_im... https://cloudinary.com/blog/time_for_next_gen_codecs_to_dethrone_jpeg https://cloudinary.com/blog/time_for_next_gen_codecs_to_deth... (disclaimer: they were written by one of the authors of JPEG XL)
  - chungy 4y ago
    > IMO the killer feature of JPEG XL is its ability to losslessly transcode already existing JPEG images. It's a nice transitory feature, but I think improved progressive decoding is even more worthwhile.
  - olliej 4y ago
    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.
- Dwedit 4y ago
  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.
darknoon 4y ago
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.
- deleted 4y ago
  [deleted]
- Minor49er 4y ago
  On the other hand, the ambiguity may be deliberate if they have no argument
sorenjan 4y ago
Previous discussion here: https://news.ycombinator.com/item?id=33399940 https://news.ycombinator.com/item?id=33399940
twotwotwo 4y ago
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=1109698 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.
- emn13 4y ago
  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.
kypro 4y ago
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.
- jcupitt 4y ago
  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.
masswerk 4y ago
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.)
- oliwarner 4y ago
  Other major browsers?
  - masswerk 4y ago
    https://jpegxl.io/articles/browser-support/ https://jpegxl.io/articles/browser-support/ (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 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.)
    - oliwarner 4y ago
      > If this was meant as a snarky remark on market share 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.
YetAnotherNick 4y ago
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]. [0]: https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c97 https://bugs.chromium.org/p/chromium/issues/detail?id=117805...
- jcupitt 4y ago
  Firefox and webkit also have JXL support. Like Chrome, the FF version is behind a flag. The webkit one is a build-time option.
deleted 4y ago
[deleted]
JyrkiAlakuijala 4y ago
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.
- twotwotwo 4y ago
  Someone implemented a BPG decoder as a WASM ServiceWorker returning PNG files, an approach that could work even better for Brunsli: https://sequentialread.com/better-portable-graphics-bpg-on-the-web-with-webassembly-wasm-and-serviceworker/ https://sequentialread.com/better-portable-graphics-bpg-on-t...
- masswerk 4y ago
  How does this work with color profiles? (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?)

60 points by yboris 4y ago

bricss 4y ago

G and bananas stuff as usual

yboris 4y ago

Rare opportunity to comment on the wrong decision Chrome is making.

PaulHoule 4y ago
What's up with this? What is their motivation?
- yboris 4y ago
  They claim: - 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).
  - skyde 4y ago
    real reason is that it compete with WebP format :-)
    - delroth 4y ago
      JPEG XL is based on Google's Pik, and several of the top contributors to libjxl are on Google's payroll: https://github.com/libjxl/libjxl/graphs/contributors https://github.com/libjxl/libjxl/graphs/contributors
      - JyrkiAlakuijala 4y ago
        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.)
      - skyde 4y ago
        I was confusing JPEG XL with JPEG XR. If google want to kill JPEG XL, this is fine. Since no one is using it I beleive.
  - izacus 4y ago
    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".
  - DannyBee 4y ago
    Neither Mozilla nor Apple ever finished the implementations enough to even enable them, and they aren't being worked on. 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.
    - riedel 4y ago
      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.
      - DannyBee 4y ago
        libjxl still exists, it's still available. The way this gets fixed for real, at least to me, is to get mozilla/apple to have skin in the game.
    - biftek 4y ago
      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
      - DannyBee 4y ago
        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. (Unlike, say, Adobe or someone)
    - 4y ago
deleted 4y ago
[deleted]

yboris 4y ago

For the uninitiated https://jpegxl.info/ https://jpegxl.info/ ;) Arguably the best image format to come out since JPEG: - High-fidelity lossy image compression - Best lossless image compression - Progressive decoding - Lossless JPEG transcoding

lucasmullens 4y ago

This is from 2 years ago. Did something change recently?

carl_dr 4y ago
They announced 2 days ago that it will be removed in Chrome 110 : https://www.phoronix.com/news/Chrome-Deprecating-JPEG-XL https://www.phoronix.com/news/Chrome-Deprecating-JPEG-XL The post’s linked ticket tracks the feature from when it was introduced to Chrome.

olliej 4y ago

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.

xeeeeeeeeeeenu 4y ago
>What is it that makes jpegxl valuable given that there’s already widespread adoption and support for av1, webp, etc? 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_image_codecs https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_im... https://cloudinary.com/blog/time_for_next_gen_codecs_to_dethrone_jpeg https://cloudinary.com/blog/time_for_next_gen_codecs_to_deth... (disclaimer: they were written by one of the authors of JPEG XL)
- chungy 4y ago
  > IMO the killer feature of JPEG XL is its ability to losslessly transcode already existing JPEG images. It's a nice transitory feature, but I think improved progressive decoding is even more worthwhile.
- olliej 4y ago
  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.
Dwedit 4y ago
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.

darknoon 4y ago

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.

deleted 4y ago
[deleted]
Minor49er 4y ago
On the other hand, the ambiguity may be deliberate if they have no argument

sorenjan 4y ago

Previous discussion here: https://news.ycombinator.com/item?id=33399940 https://news.ycombinator.com/item?id=33399940

twotwotwo 4y ago

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=1109698 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.

emn13 4y ago
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.

kypro 4y ago

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.

jcupitt 4y ago
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.

masswerk 4y ago

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.)

oliwarner 4y ago
Other major browsers?
- masswerk 4y ago
  https://jpegxl.io/articles/browser-support/ https://jpegxl.io/articles/browser-support/ (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 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.)
  - oliwarner 4y ago
    > If this was meant as a snarky remark on market share 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.

YetAnotherNick 4y ago

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]. [0]: https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c97 https://bugs.chromium.org/p/chromium/issues/detail?id=117805...

jcupitt 4y ago
Firefox and webkit also have JXL support. Like Chrome, the FF version is behind a flag. The webkit one is a build-time option.

deleted 4y ago

[deleted]

JyrkiAlakuijala 4y ago

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.

twotwotwo 4y ago
Someone implemented a BPG decoder as a WASM ServiceWorker returning PNG files, an approach that could work even better for Brunsli: https://sequentialread.com/better-portable-graphics-bpg-on-the-web-with-webassembly-wasm-and-serviceworker/ https://sequentialread.com/better-portable-graphics-bpg-on-t...
masswerk 4y ago
How does this work with color profiles? (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?)