4 ms·

Your move, Chrome. https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c84 https://bugs.chromium.org/p/chromium/issues/detail?id=117805...

adzm 3y ago
To be honest I kind of understand where Google was coming from with dropping jxl. But now with Apple throwing their weight behind it, the situation has drastically changed. I really do hope they bring it back.
- yboris 3y ago
  I'm curious what there is to understand -- this just a selfish decision they are making, right? Not including JPEG XL is worse for users, developers, and the ecosystem.
  - jsnell 3y ago
    When it was removed, no other browser supported JPEG XL, and no other browser had expressed an intent to do it. The last thing the web needs is more image formats with limited support. (Could they even have supported it consistently across platforms due to the iOS limitation on all browsers needing to be implemented on WebKit?) Apple implementing JPEG XL in Safari changes that. Now it's a format with a real chance of being supported across the whole ecosystem.
    - zatarc 3y ago
      Not exactly. Firefox had JPEG XL support in its nightly versions until January(?) 2023.
      - jsnell 3y ago
        I thought it was flag-protected in Firefox, not actually supported?
        croes 3y ago
        Same was valid for Chrome, that's why it was ridiculous to claim lack of interest.
    - ksec 3y ago
      >(Could they even have supported it consistently across platforms due to the iOS limitation on all browsers needing to be implemented on WebKit?) They same is true to WebP and AVIF?
      - jsnell 3y ago
        Yes, it was true for WebP for like a decade. One of the many issues WebP had. Isn't it good to learn from the mistake of WebP, rather than repeat it? (AVIF was not supported by all browsers on day 1, obviously, but all the major browsers were governing members of the foundation developing it. So it was much more clear that the backing was there across the ecosystem.)
    - alwillis 3y ago
      > Apple implementing JPEG XL in Safari changes that. Now it's a format with a real chance of being supported across the whole ecosystem. As I’ve mentioned in other threads, I don’t believe the Chrome team didn’t know Apple was going to implement JPEG XL. There’s lots of communication between the Chrome and WebKit teams. It’s going to take more than just Apple shipping JPEG XL to perhaps change Google’s point of view; JPEG XL needs to be seen as a game changer that moves the needle.
  - jeffbee 3y ago
    They explicitly said they were disabling it because nobody cares and no industry players were behind in. Not some kind of conspiracy, an actual objective evaluation. With Apple behind it, perhaps the activation energy will exist.
    - xign 3y ago
      WebKit already added support for it if I remember correctly. It's just not on Safari so to speak since it uses the macOS stack for this, so it needs the OS itself to adopt it, but Apple was clearly interested in it. And web browsers aren't the industry. Adobe added support for it, for example, and it didn't really seem like Google did a good-faith discussion with actual industry players, who range from content creation software to OS makers to other web browsers. It's also not like there are people lining up to use AVIF right now and Google is still pushing for it.
    - chungy 3y ago
      It was a clearly false statement when they said it. Adobe added JPEG XL to its products. Along with them, Facebook, flickr, and a bunch of other services expressed their eagerness to support the new format (because it is vastly superior to all prior image format options). Google decided it conflicted with their competitor format AVIF and axed the experiment.
      - progbits 3y ago
        > Google decided it conflicted with their competitor format AVIF This is absolutely ridiculous take given JPEG XL is mainly authored by Google and Cloudinary, with AVIF coming from Netflix & alliance that includes Google. There is no "competitor" here. Just a format nobody else indicated interest in supporting (notably Apple which forces ~half of mobile marked to have no support, given their browser engine restrictions). Now that they added the support Chrome can easily bring it back.
        ksec 3y ago
        1. There is nothing ridiculous about cutting another format, whether it is authored by them or not. They took a stand and it was Pro AOM. 2. There has never been another image format that has the level of support or interest as JEPG XL since JPEG becomes the internet standard. And that was before the drama of Chrome dropping support for it.
- deleted 3y ago
  [deleted]
spookthesunset 3y ago
Ah the politics of web standards. At least they aren’t bickering about support for the <marquee> tag or something. Wonder what is happening behind closed doors in this squabble…
lostmsu 3y ago
In the meantime you can use a polyfill: https://github.com/niutech/jxl.js https://github.com/niutech/jxl.js
- CharlesW 3y ago
  Thank you for posting something pragmatic in this oddly-emotional thread!
wilg 3y ago
Would have been nice for somebody from Apple to chime in and say they intended to support it.
ksec 3y ago
Since Google has already established that JPEG XL is objectively inferior to AVIF [1], and some of its employees, speaking for themselves have also shown similar testing results on twitter. I would actually ask Google why would they be interested in supporting an inferior image codec? Unless they were wrong in the first place? [1] https://archive.is/MwJxy https://archive.is/MwJxy
- 112233 3y ago
  Great comparision! as you can see on the linked page: https://storage.googleapis.com/avif-comparison/verification-process.html https://storage.googleapis.com/avif-comparison/verification-... They are comparing production encoders of AVIF, JPEG and WEBP with the reference implementation of JPEG XL. If anything, it is amazing to see how fast the reference implementation is. Remember initial AV1 days-per-frame perfomance?
- illiac786 3y ago
  JXL can losslessly recompress the billions of JPEG images out there, which AVIF cannot. Also, from your link: "JPEG XL has better lossless compression compared to WebP, which has better lossless compression compared to AVIF for these images." I would then argue that the superiority of AVIF over JXL is a point of view at best.
  - ksec 3y ago
    Precisely.

adzm 3y ago

To be honest I kind of understand where Google was coming from with dropping jxl. But now with Apple throwing their weight behind it, the situation has drastically changed. I really do hope they bring it back.

yboris 3y ago
I'm curious what there is to understand -- this just a selfish decision they are making, right? Not including JPEG XL is worse for users, developers, and the ecosystem.
- jsnell 3y ago
  When it was removed, no other browser supported JPEG XL, and no other browser had expressed an intent to do it. The last thing the web needs is more image formats with limited support. (Could they even have supported it consistently across platforms due to the iOS limitation on all browsers needing to be implemented on WebKit?) Apple implementing JPEG XL in Safari changes that. Now it's a format with a real chance of being supported across the whole ecosystem.
  - zatarc 3y ago
    Not exactly. Firefox had JPEG XL support in its nightly versions until January(?) 2023.
    - jsnell 3y ago
      I thought it was flag-protected in Firefox, not actually supported?
      - croes 3y ago
        Same was valid for Chrome, that's why it was ridiculous to claim lack of interest.
  - ksec 3y ago
    >(Could they even have supported it consistently across platforms due to the iOS limitation on all browsers needing to be implemented on WebKit?) They same is true to WebP and AVIF?
    - jsnell 3y ago
      Yes, it was true for WebP for like a decade. One of the many issues WebP had. Isn't it good to learn from the mistake of WebP, rather than repeat it? (AVIF was not supported by all browsers on day 1, obviously, but all the major browsers were governing members of the foundation developing it. So it was much more clear that the backing was there across the ecosystem.)
  - alwillis 3y ago
    > Apple implementing JPEG XL in Safari changes that. Now it's a format with a real chance of being supported across the whole ecosystem. As I’ve mentioned in other threads, I don’t believe the Chrome team didn’t know Apple was going to implement JPEG XL. There’s lots of communication between the Chrome and WebKit teams. It’s going to take more than just Apple shipping JPEG XL to perhaps change Google’s point of view; JPEG XL needs to be seen as a game changer that moves the needle.
- jeffbee 3y ago
  They explicitly said they were disabling it because nobody cares and no industry players were behind in. Not some kind of conspiracy, an actual objective evaluation. With Apple behind it, perhaps the activation energy will exist.
  - xign 3y ago
    WebKit already added support for it if I remember correctly. It's just not on Safari so to speak since it uses the macOS stack for this, so it needs the OS itself to adopt it, but Apple was clearly interested in it. And web browsers aren't the industry. Adobe added support for it, for example, and it didn't really seem like Google did a good-faith discussion with actual industry players, who range from content creation software to OS makers to other web browsers. It's also not like there are people lining up to use AVIF right now and Google is still pushing for it.
  - chungy 3y ago
    It was a clearly false statement when they said it. Adobe added JPEG XL to its products. Along with them, Facebook, flickr, and a bunch of other services expressed their eagerness to support the new format (because it is vastly superior to all prior image format options). Google decided it conflicted with their competitor format AVIF and axed the experiment.
    - progbits 3y ago
      > Google decided it conflicted with their competitor format AVIF This is absolutely ridiculous take given JPEG XL is mainly authored by Google and Cloudinary, with AVIF coming from Netflix & alliance that includes Google. There is no "competitor" here. Just a format nobody else indicated interest in supporting (notably Apple which forces ~half of mobile marked to have no support, given their browser engine restrictions). Now that they added the support Chrome can easily bring it back.
      - ksec 3y ago
        1. There is nothing ridiculous about cutting another format, whether it is authored by them or not. They took a stand and it was Pro AOM. 2. There has never been another image format that has the level of support or interest as JEPG XL since JPEG becomes the internet standard. And that was before the drama of Chrome dropping support for it.
deleted 3y ago
[deleted]

spookthesunset 3y ago

Ah the politics of web standards. At least they aren’t bickering about support for the <marquee> tag or something. Wonder what is happening behind closed doors in this squabble…

lostmsu 3y ago

In the meantime you can use a polyfill: https://github.com/niutech/jxl.js https://github.com/niutech/jxl.js

CharlesW 3y ago
Thank you for posting something pragmatic in this oddly-emotional thread!

wilg 3y ago

Would have been nice for somebody from Apple to chime in and say they intended to support it.

ksec 3y ago

Since Google has already established that JPEG XL is objectively inferior to AVIF [1], and some of its employees, speaking for themselves have also shown similar testing results on twitter. I would actually ask Google why would they be interested in supporting an inferior image codec? Unless they were wrong in the first place? [1] https://archive.is/MwJxy https://archive.is/MwJxy

112233 3y ago
Great comparision! as you can see on the linked page: https://storage.googleapis.com/avif-comparison/verification-process.html https://storage.googleapis.com/avif-comparison/verification-... They are comparing production encoders of AVIF, JPEG and WEBP with the reference implementation of JPEG XL. If anything, it is amazing to see how fast the reference implementation is. Remember initial AV1 days-per-frame perfomance?
illiac786 3y ago
JXL can losslessly recompress the billions of JPEG images out there, which AVIF cannot. Also, from your link: "JPEG XL has better lossless compression compared to WebP, which has better lossless compression compared to AVIF for these images." I would then argue that the superiority of AVIF over JXL is a point of view at best.
- ksec 3y ago
  Precisely.