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.
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/ This is the same person that was also heavily involved in VP8/WebP and AV1/AVIF: https://research.google/people/105284/ To me this looks like a rather obvious conflict of interest.
It doesn't have to be or should be Google to lead the adoption of something.
Safari have support as a build-time option, apparently.
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.
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.
> 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=117805...
[2] - https://helpx.adobe.com/camera-raw/using/hdr-output.html
[3] - https://github.com/mozilla/standards-positions/issues/522#is...
[4] - https://bugzilla.mozilla.org/show_bug.cgi?id=1539075#c23
[5] - https://github.com/exiftool/exiftool/blob/master/Changes#L44...
[6] - 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/#i...
[8] - https://imagemagick.org/script/formats.php
[9] - https://docs.krita.org/en/general_concepts/file_formats/file...