6 ms·

Frankly, the official justification[1] for the deprecation is ridiculous. > There is not enough interest from the entire ecosystem to continue experimenting wi

Frankly, the official justification[1] for the deprecation is ridiculous. > There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL In the very same ticket that comment was made, the companies such as Adobe, Facebook, The Guardian and Shopify voiced their support for the format. In fact, Adobe has just added support for JPEG XL to Camera Raw[2]. Also, Cloudflare[3] and Flickr[4] endorsed JXL in Mozilla's bugtrackers. Plenty of open-source projects have implemented support for JXL images. For example: ExifTool[5], FFmpeg[6], GIMP[7], ImageMagick[8], Krita[9]. Is this really "not enough interest"? > The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default The ability to losslessly recompress already exisiting JPEG images is the killer feature of JPEG XL. It allows seamless transition to the new format by converting old images. AVIF can't do that. To be honest, their explanations feel like post-hoc rationalizations. It seems Google invested too much into an inferior format (AVIF) and now because of the sunk cost fallacy they can't pivot to JPEG XL. [1] - https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c84 https://bugs.chromium.org/p/chromium/issues/detail?id=117805... [2] - https://helpx.adobe.com/camera-raw/using/hdr-output.html https://helpx.adobe.com/camera-raw/using/hdr-output.html [3] - https://github.com/mozilla/standards-positions/issues/522#issuecomment-852891626 https://github.com/mozilla/standards-positions/issues/522#is... [4] - https://bugzilla.mozilla.org/show_bug.cgi?id=1539075#c23 https://bugzilla.mozilla.org/show_bug.cgi?id=1539075#c23 [5] - https://github.com/exiftool/exiftool/blob/master/Changes#L446 https://github.com/exiftool/exiftool/blob/master/Changes#L44... [6] - https://git.videolan.org/?p=ffmpeg.git;a=commit;h=0008c159562b877700cd9b7c96f941de4ee69af5 https://git.videolan.org/?p=ffmpeg.git;a=commit;h=0008c15956... [7] - https://www.gimp.org/news/2021/10/20/gimp-2-99-8-released/#improved-file-formats-support-jpeg-xl-psdpsb-and-more https://www.gimp.org/news/2021/10/20/gimp-2-99-8-released/#i... [8] - https://imagemagick.org/script/formats.php https://imagemagick.org/script/formats.php [9] - https://docs.krita.org/en/general_concepts/file_formats/file_jxl.html https://docs.krita.org/en/general_concepts/file_formats/file...

deleted 4y ago
[deleted]
alwillis 4y ago
In the very same ticket that comment was made, the companies such as Adobe, Facebook, The Guardian and Shopify voiced their support for the format. Notice that Apple and Mozilla are not on this list. Unless other browser makers are onboard, it’s probably not going to happen. Also, neither W3C or WHATWG, the web standards bodies are on the list. Also not a good sign. Of course, Google just ships what they feel like all the time; if they really wanted JPEG XL, they would just do it. But they obviously don’t feel that strongly about it.
- jonsneyers 4y ago
  If you want to wait for W3C to approve a new codec, good luck with that. Looking at https://www.w3.org/Graphics/ https://www.w3.org/Graphics/, I see only PNG, JPEG, GIF and SVG mentioned. For adding WebP and AVIF to Chrome this was not an issue. Regarding Mozilla: there is preliminary JXL support in Firefox, also behind a flag. So if Chrome would enable it, Firefox would likely follow quickly. But given their respective market shares, it is not surprising to me that Firefox does not have the audacity to push JXL when Chrome devs are clearly trying to block it. As for Apple/Safari: there is JXL support in WebKit behind a compile flag, so if Chrome would enable, they could also follow quickly. It does not surprise me that Apple is not taking any public position on this — they rarely announce their plans before they are ready to ship. In any case, if the list of supporters in that bugtracker is considered "insufficient", then I think Chrome devs have unreasonably high expectations. The issue is not that "the ecosystem" is not interested. The issue is that the Chrome decision makers don't want it to get traction, for whatever reasons they clearly don't really want to disclose but that can be guessed: The key Chrome decision maker on codec related things seems to be this person: https://www.linkedin.com/in/jimbankoski/ https://www.linkedin.com/in/jimbankoski/ This is the same person that was also heavily involved in VP8/WebP and AV1/AVIF: https://research.google/people/105284/ https://research.google/people/105284/ To me this looks like a rather obvious conflict of interest.
Avamander 4y ago
To be fair, if there's a need Mozilla and Apple could inplement JXL support and then Google would very likely follow. It doesn't have to be or should be Google to lead the adoption of something.
- jcupitt 4y ago
  Firefox has had basic support behind a flag for a good while, but it needs some work -- their code is missing things like transparency and colour profiles. Sadly mozilla have laid off a lot of their dev team and they don't have much capacity right now. Safari have support as a build-time option, apparently.
jcupitt 4y ago
libvips has had libjxl support for a couple of years now, including in our fuzzing and build systems. Everything is pretty much ready to roll, and would have brought support to downstream projects and users like sharp, ActiveRecord, imaginary, Shopify, etc. We've just been waiting for Chrome to flip the switch and start deployment, To have support pulled like this at the last second is extremely disappointing.
bartimus 4y ago
It so much amazes me. Our camera hardware supports HDR. RAW image formats support HDR. Our display devices support HDR. Videos support HDR. Smartphones can now record in HDR. All the hardware is there ready for the future. Yet due to software limitations we're still cutting off all the HDR data when saving our precious memories as JPEG. All whites become #fffff. The color of paper. The color of Word's document background color. The gamut of color has expanded and we need image standards to expand with it.

deleted 4y ago

[deleted]

alwillis 4y ago

In the very same ticket that comment was made, the companies such as Adobe, Facebook, The Guardian and Shopify voiced their support for the format. Notice that Apple and Mozilla are not on this list. Unless other browser makers are onboard, it’s probably not going to happen. Also, neither W3C or WHATWG, the web standards bodies are on the list. Also not a good sign. Of course, Google just ships what they feel like all the time; if they really wanted JPEG XL, they would just do it. But they obviously don’t feel that strongly about it.

jonsneyers 4y ago
If you want to wait for W3C to approve a new codec, good luck with that. Looking at https://www.w3.org/Graphics/ https://www.w3.org/Graphics/, I see only PNG, JPEG, GIF and SVG mentioned. For adding WebP and AVIF to Chrome this was not an issue. Regarding Mozilla: there is preliminary JXL support in Firefox, also behind a flag. So if Chrome would enable it, Firefox would likely follow quickly. But given their respective market shares, it is not surprising to me that Firefox does not have the audacity to push JXL when Chrome devs are clearly trying to block it. As for Apple/Safari: there is JXL support in WebKit behind a compile flag, so if Chrome would enable, they could also follow quickly. It does not surprise me that Apple is not taking any public position on this — they rarely announce their plans before they are ready to ship. In any case, if the list of supporters in that bugtracker is considered "insufficient", then I think Chrome devs have unreasonably high expectations. The issue is not that "the ecosystem" is not interested. The issue is that the Chrome decision makers don't want it to get traction, for whatever reasons they clearly don't really want to disclose but that can be guessed: The key Chrome decision maker on codec related things seems to be this person: https://www.linkedin.com/in/jimbankoski/ https://www.linkedin.com/in/jimbankoski/ This is the same person that was also heavily involved in VP8/WebP and AV1/AVIF: https://research.google/people/105284/ https://research.google/people/105284/ To me this looks like a rather obvious conflict of interest.

Avamander 4y ago

To be fair, if there's a need Mozilla and Apple could inplement JXL support and then Google would very likely follow. It doesn't have to be or should be Google to lead the adoption of something.

jcupitt 4y ago
Firefox has had basic support behind a flag for a good while, but it needs some work -- their code is missing things like transparency and colour profiles. Sadly mozilla have laid off a lot of their dev team and they don't have much capacity right now. Safari have support as a build-time option, apparently.

jcupitt 4y ago

libvips has had libjxl support for a couple of years now, including in our fuzzing and build systems. Everything is pretty much ready to roll, and would have brought support to downstream projects and users like sharp, ActiveRecord, imaginary, Shopify, etc. We've just been waiting for Chrome to flip the switch and start deployment, To have support pulled like this at the last second is extremely disappointing.

bartimus 4y ago

It so much amazes me. Our camera hardware supports HDR. RAW image formats support HDR. Our display devices support HDR. Videos support HDR. Smartphones can now record in HDR. All the hardware is there ready for the future. Yet due to software limitations we're still cutting off all the HDR data when saving our precious memories as JPEG. All whites become #fffff. The color of paper. The color of Word's document background color. The gamut of color has expanded and we need image standards to expand with it.