9 ms·

Google set to deprecate JPEG XL support in Chrome 110

146 points by berkut 4y ago

bragr 4y ago
This seems very odd given that the previous discussion [1] seemed like adoption was increasing. [1] https://bugs.chromium.org/p/chromium/issues/detail?id=1178058 https://bugs.chromium.org/p/chromium/issues/detail?id=117805...
- RobotToaster 4y ago
  Most likely they want to push their own "WebP" format.
  - VoxPelli 4y ago
    If anything it would be AVIF nowadays, which is a format that all big browser vendors stand behind, including Apple and Google
  - vetinari 4y ago
    WebP2 also got "demoted" (https://chromium.googlesource.com/codecs/libwebp2/+/1251ca748c17278961c0d0059b744595b35a4943%5E%21/ https://chromium.googlesource.com/codecs/libwebp2/+/1251ca74...): -WebP 2 is the successor of the WebP image format, currently in development. It -is not ready for general use, and the format is not finalized so changes to the -library can break compatibility with images encoded with previous versions. \ -USE AT YOU OWN RISK! +WebP 2 is an experimental image codec based on WebP. WebP 2 will not be released +as an image format but is used as a playground for image compression +experiments.
- Mindless2112 4y ago
  > - There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL Gee. Maybe there's no interest because nobody can use it yet because it's behind a feature flag.
- bawolff 4y ago
  I dont see why its so odd. Looks like it was behind a feature flag. I imagine the time came where someone had to make a go/no-go call, and they decided no-go. It wouldnt make sense to keep it as a feature flag forever, and once it is not a feature flag it becomes much harder to backout.
  - Avamander 4y ago
    > It wouldnt make sense to keep it as a feature flag forever, and once it is not a feature flag it becomes much harder to backout They didn't struggle with removing H2 PUSH though.
    - bawolff 4y ago
      I mean, you're still talking about it, now, much later. If it was really no struggle people would have forgot about it at this point. H2 push is also something that degrades much more gracefully if missing compared to an image codec. Nonetheless, people haved removed image codecs before (rip XBM). Harder is not the same as impossible.
      - Avamander 4y ago
        True, because I saw how it was just being added to software/frameworks. Some parts of the web move slower than Google expects, I have a feeling.
modeless 4y ago
Bummer, I liked jxl better than heic or avif. Guess avif will be the eventual winner then. At least I hope heic dies someday.
- alwillis 4y ago
  I hope heic dies someday Not anytime soon. Every picture taken with the stock iOS Camera app is saved in HEIC. That’s billions of HEIC files.
  - modeless 4y ago
    Yeah, it's unfortunate, but they are often converted before sharing.
plantain 4y ago
I really hope this is revisited - JXL seems to be faster and better compression than HEIC/AVIF.
- Cyberdog 4y ago
  Don't hold your breath. Big G would prefer you use WebP and their other nearly-proprietary formats nobody wanted but they are pushing into wide use through the might of operating the most widely used browser. But maybe if enough people finally stop using their spyware browser, there will be some hope.
  - kodah 4y ago
    > But maybe if enough people finally stop using their spyware browser, there will be some hope. Nearly every company I've worked for requires the use of Chrome because they can manage it.
    - shaky-carrousel 4y ago
      I'm so glad I've never worked in these kind of companies... It sounds like an awful workplace.
      - kodah 4y ago
        I have other things I judge companies for. I just assume I'm not allowed to do anything personal on a work laptop if they manage every aspect of it. I understand why they do it, however, the only thing I find unethical about it is how much companies have balked at explaining the depths to which they track internal employees.
  - vlovich123 4y ago
    What proprietary video/image formats does Google have? As far as I know all their image and video formats are open, including WebP. Heck, according to Wikipedia JPEG XL was also partly driven by Google.
VoxPelli 4y ago
JPEG XL apparently never shipped, so the title of this post is misleading. You can’t deprecate something that never shipped.
- deleted 4y ago
  [deleted]
- bertman 4y ago
  chrome://flags/#enable-jxl Since v91 or so.
- chrismorgan 4y ago
  It's not misleading, it's wrong. Deprecation means you can still use the thing. This is removal.
joecool1029 4y ago
Should be noted that it's also behind a feature flag in Firefox (only in nightly!) and while basic support is there(no color profile support), further development doesn't appear to be happening and it's low priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1539075 https://bugzilla.mozilla.org/show_bug.cgi?id=1539075 EDIT: Why the downvotes? This is the status on Mozilla's end for at least a year. If none of the browser developers care to push support, then the format is effectively dead.
- EbNar 4y ago
peppermint_gum 4y ago
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.
EMM_386 4y ago
This apparently goes nicely with the other article currently on the frontpage ... > I’d still recommend including JPEG XL versions of your images, because chances are that browser support will come eventually. https://jfhr.me/optimizing-images-with-the-html-picture-tag/ https://jfhr.me/optimizing-images-with-the-html-picture-tag/
watersb 4y ago
The images I've set up for web use are not very large. I don't have a RAW workflow. So maybe I'm missing something. I've found it very challenging to get better compression than optimized JPEG via Squoosh. https://squoosh.app/ https://squoosh.app/ Of course, JPEG XL has alpha channels, and I'm comparing a new format against a standard that's had 20 years of refinement in implementation. Are we cutting ourselves off from a similar future with JPEG XL?
dang 4y ago
We changed the URL from https://chromium-review.googlesource.com/c/chromium/src/+/3988999 https://chromium-review.googlesource.com/c/chromium/src/+/39... to an article that has (a bit) more background. (via https://news.ycombinator.com/item?id=33400436 https://news.ycombinator.com/item?id=33400436, but no comments there)
rektide 4y ago
Insufficient adoption is the cudgel that murders most good web work. Another fine effort given an order of magnitude less soak time & exploration time than it deserves. The web platform cannot be run like an app platform: hockeystick adoption in 18 months or death. But right now we rely on corporate patrons (browser makers) to invest in & support the vast vast majority of progress on the web. The time domains don't match up. Yet there are no examples of alternative ways we might support & fund such core vital human communications.
lifthrasiir 4y ago
There are actually good reasons for not shipping JPEG XL in web browsers, but the comment doesn't list one. In particular it compares JPEG XL with "existing formats", which seemingly include AVIF, but almost identical arguments could have been used to not ship AVIF in web browsers after all. Essentially it says that they happened to pick AVIF for no apparent reason and because of that they can't pick JPEG XL for no apparent reason again. The comment lacks substances, if not dishonest.
- bawolff 4y ago
  > Essentially it says that they happened to pick AVIF for no apparent reason and because of that they can't pick JPEG XL for no apparent reason again Sounds pretty valid to me. Sometimes you just have to pick a solution. Having every possible format supported does not make sense. If AVIF fills the usecase, no point having both.
  - lifthrasiir 4y ago
    If it was the case, it is enough to say that. They didn't.
    - google234123 4y ago
      Everyone else support the other format? No one supports JXL
- yboris 4y ago
  It would make sense for Chrome not to include JPEG XL in the first place with some list of explicit reasons. It does not make sense to implement it, hide behind a flag, and then remove, claiming there is not enough interest -- when there's no way to reliably gauge interest from this "experiment".
  - lifthrasiir 4y ago
    Indeed, the proper way to gauge the interest would be Origin Trial (OT), as noted by one of Blink API owners [1] who is also responsible for Edge at Microsoft. [1] https://twitter.com/slightlylate/status/1587030785197953024 https://twitter.com/slightlylate/status/1587030785197953024
Scaevolus 4y ago
How disappointing. JPEG XL is a much nicer format than AVIF, but Youtube forcing AV1 through meant AVIF is an easy ride-along.
zebracanevra 4y ago
Here's some of the features I am looking forward to in JXL. Better lossy compression than JPG, similar compression to AVIF. AVIF ekes out a little more quality at the very low end, and JXL excels at the very high end. Better lossless compression than PNG. Supports alpha channels. Supports parallel decoding. Significantly faster encoding than other formats like AVIF. Supports multiple colour spaces and formats, allowing for HDR images. The colour in JXL is stored in the XYB colour space. A dev states that this colour space gives more bits to darker colours, leading to better encoded dark skin at similar filesizes to other codecs [1]. Supports up to 4096 channels. A practical use of this is in 3D workflows with Physically Based Rendering textures, where a texture has channels for albedo, normal map, reflection, roughness, metalness, and others. They could be compressed into one JXL, much smaller than an EXR with the same channels. Supports losslessly recompressing existing JPGs into JXL to save space. Those files can also be losslessly (ie byte exact) converted back to JPGs. Supports progressive decoding. AVIF crucially does _not_ have this. Progressive decoding also allows for Responsive Images. No longer would you have to encode two images, like 1x or 2x. Encode the 2x image once – you can serve the 1x image _from the 2x image_. Huge feature if browsers were on board. Supports rudimentary animation (similar to MJPEG, ie only i-frames). Use AVIF for animations. Has frames/layers. This is a pretty cool feature for an image format. I can see two main uses of this: 1. Non-destructive editing. If you want to add an overlay to a JPG, you have to re-encode the image. JXL allows you to add another frame on-top of the other image, without touching the original. 2. Hybrid lossless/lossy images. For example, a screenshot of a UI that contains a photograph. The UI could be losslessly compressed, and the photo could be lossy-ly compressed. There is already an experimental program within the JXL source that does this. [1] https://mobile.twitter.com/jonsneyers/status/1550215859305586691 https://mobile.twitter.com/jonsneyers/status/155021585930558...
- jbverschoor 4y ago
  All good reasons. But the complexity/ decision on how to behave with certain features could be a compelling reason to stop supporting. In reality, they have webp which is enough for most of the use cases
- bawolff 4y ago
  > Supports progressive decoding. AVIF crucially does _not_ have this. How important is this in the modern world? Like, GIF, PNG, (progressive) JPG all support this, yet i dont think i have ever noticed this in practise in modern times unless artificially rate limiting my connection. It seems more like a relic from the time of dial up internet.
est31 4y ago
If one wants to speculate, timing wise, this correlates with the recent release of iOS 16 (September 2022) and macOS 13 (October 2022), which have added AVIF support to Safari. That event in turn means that now most browsers support AVIF.
- lifthrasiir 4y ago
  This is indeed one of "good reasons" that can prefer AVIF over JPEG XL (but not a good reason to not ship JPEG XL). Safari is the most difficult vendor to work with, so if Safari can be convinced there is no bigger obstacle waiting. But it should be noted that Safari still does not support AV1 on which AVIF is based and that fact didn't prevent other browsers from adding support for that video format anyway.
  - TingPing 4y ago
    WebKit supports JPEG XL behind a build flag.
cflat 4y ago
This is pure politics. The AOM want proof of loyalty and shipping a competing image format threatens that loyalty pact. It’s also incrementalism at its finest. “We already shipped av1, adding a single frame decode is minor overhead” is the likely rationale. But it misses the point that images are gazed at while video is moving and can get away with a lot of quality sins that you can’t with images. But worse is that av1 is full of optional features. Sure the client could implement it, but how can you know? Even the lauded animated avif is horribly broken across the ecosystem because of this optionality — and there isn’t any way to tell a priori if the browser can support animated avif. Or 444 avif. Or ycocg avif. It’s just down right broken as an image format falling to the lowest common denominator.
- mort96 4y ago
  - lifthrasiir 4y ago
    While I agree that it is too early to turn to a conspiracy theory, the supposed rationale against JPEG XL is also pretty unsubstantiated and it does feel that the Chrome team doesn't want to share the actual rationale for whatever reason.
    - mort96 4y ago
      Google's rationale is very weak, yes. But it makes no sense to say that this is the AOM pushing Google to do this as a proof of loyalty. Why wouldn't the same apply to Apple and Mozilla? In fact, if deprecating JPEG-XL is something the AOM wants, wouldn't you expect the browser vendors (all of whom are AOM founders) to all conspire to kill JPEG-XL? The right conspiracy theory here isn't even that AOM is forcing Google to do this as a proof of loyalty, the conspiracy theory which at least makes some semblance of sense is that Apple, Google and Mozilla are working to kill JPEG-XL to help their own image format win. But then it's just a group of companies acting in their own self interest and not some coercion, so I suppose that story isn't as sexy.
  - ksec 4y ago
kasabali 4y ago
Previous discussion: https://news.ycombinator.com/item?id=33383880 https://news.ycombinator.com/item?id=33383880 If I were a competitor browser vendor, I'd retaliate by removing Webp and AVIF support. But of course, who are we kidding? There are no competitors, only paint jobs and a dog on leash.
- mort96 4y ago
  Why? The other browser vendors don't ship JPEG-XL either, and all the other browser vendors are fully on board with AVIF. Why would it be in their interest to remove AVIF support?
  - kasabali 4y ago
    It wouldn't be in their interest, but wouldn't be in their disinterest, either. Thus why it'd be an appropriate retaliation... in a hypothetical competitive environment... which we don't have. Because as I said, only paint jobs and a leash dog.
    - mort96 4y ago
      It is in the entire web community's interest to have a good, non-patent-encumbered, open image (and video) encoding standard. Killing off the only shot we currently have at that seems to be in the disinterest of the minority browser vendors. People are speculating that this is in preparation of Google introducing their own Google-controlled replacement for JPEG-XL, or pushing WebP harder. I don't know if I buy that, but the more widespread AVIF is, the less power does Google have to unilaterally develop a replacement. And it's in the other vendors' disinterest to give Google unilateral control over even more of the web.
      - kasabali 4y ago
        JPEG-XL is a > good, non-patent-encumbered, open image encoding standard yet they won't be supporting it. Whether you want to buy it or not, de-facto format on the web is JPEG and only JPEG, thanks to the historical momentum. Even webp is still expendable, because Mozilla and Microsoft hold long enough. And AVIF isn't being used anywhere, yet. So no, it isn't in other vendors' disinterest to drop support for Webp and AVIF, because JPEG would continue to be de-facto in that case.
sandstrom 4y ago
We've been planning to move all our image storage (business SaaS) over to JPEG-XL internally, for a few reasons: - Technically a compelling format. - Parallel decoding. - Progressive decoding (no need for 'placeholder images'). - Lossless better than PNG and lossy better than JPG. - Better than AVIF in the 'high quality' end of the spectrum. - Lossless recompression of JPEG into JXL. - Fast enough for on-the-fly conversion to JPEG for backwards compatibility. People from Facebook, Shopify, Adobe, Intel and other huge companies have also voiced their support and said it's on various internal roadmaps. I hope this decision gets reverted. Seems like a huge mistake!
- bawolff 4y ago
  You planned to move your entire business to a feature that has thus far never been shipped by any browser?
  - zinekeller 4y ago
    Twenty years ago, PNG wasn't really supported by any popular browsers of the day, but it showed its capabilities (especially compared to GIF) and was eventually incorporated. I'm assuming that you'll also say to me "You planned to move your entire business to a feature that has thus far never been shipped by any browser?" In a more serious manner, JXL has features that both WebP and AVIF don't. Lossless images simply compress better with JXL than WebP (and if you in these circles you know to not bother with AVIF's lossless mode - even PNG beats AVIF in that arena). I know Google uses near-lossless images for their icons, but near-lossless wouldn't cut when it comes for medical diagnostics or meteorological uses. It has progressive loading, which WebP and AVIF don't really have. Speaking of near-lossless, WebP don't support 4:4:4 chroma subsampling while AVIF technically does but no encoder AFAIK focuses on it. Also, WebP only allows 16,384 pixels per side and AVIF only allows 65,536 pixels per side (which to be fair is the same as the original JPEG), while JXL allows 1,073,741,824 pixels per side (which is ludicrous, but considering that JPEG's 65,536 pixels per side was ludicrous at the time is good for future-proofing). There are also niche features which both WebP and AVIF don't have. While I think that someone at Google was thinking that since AVIF beats JXL on compression at low bitrates there is no demand for JXL, that is a very narrow way of thinking. Not everyone is looking for bandwidth savings, some are looking that current image formats simply don't represent the things that they need (especially that most large companies have focused on "squeeze up the quality for lower bits").
KingOfCoders 4y ago
The internet is what G tells you the internet is. So get in line.
- mekster 4y ago
  Screw that.
bricss 4y ago
Startup idea, WASM decoder for JXL format!
jakub_g 4y ago
While it seems JPEG XL is very nice, I think the comment 72 from Kornel Lesinski is spot on: https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c72 https://bugs.chromium.org/p/chromium/issues/detail?id=117805... > In terms of compression performance JPEG XL is really good, but I'm concerned that it does not have more than a single implementation. > W3C's bar for web standard recommendations is having at least two independent implementations. AVIF has multiple interoperable implementations in multiple languages. JPEG XL doesn't have yet. > Given the substantial complexity and scope of the JPEG XL format, I'd like to see a proof that a second implementation is possible, and that it's interoperable, so that the Web platform doesn't end needing bug-compatibility with a single C++ codebase.
- JyrkiAlakuijala 4y ago
  It is not entirely correct. There is a C (j40.c) and two C++ implementations (libjxl and libjxl-tiny). Kornel would love to see a Rust implementation I believe.
  - jakub_g 4y ago
    Thanks for clarification! Are those truly independent implementations? (i.e. not derived from each other? I'm not deep into the subject.)
    - lifthrasiir 4y ago
      I'm the author of J40 and it was intentionally developed from scratch exactly in order to remedy the situation where libjxl serves as a de facto specification as opposed to the actual specification.
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.
- niutech 4y ago
  Could you provide a link to this WASM implementation? I can find JXL-WASM decoder, which is 1.23 MB: https://unpkg.com/browse/jxl-wasm@0.7.0/lib/ https://unpkg.com/browse/jxl-wasm@0.7.0/lib/

146 points by berkut 4y ago

This seems very odd given that the previous discussion [1] seemed like adoption was increasing. [1] https://bugs.chromium.org/p/chromium/issues/detail?id=1178058 https://bugs.chromium.org/p/chromium/issues/detail?id=117805...

RobotToaster 4y ago
Most likely they want to push their own "WebP" format.
- VoxPelli 4y ago
  If anything it would be AVIF nowadays, which is a format that all big browser vendors stand behind, including Apple and Google
- vetinari 4y ago
  WebP2 also got "demoted" (https://chromium.googlesource.com/codecs/libwebp2/+/1251ca748c17278961c0d0059b744595b35a4943%5E%21/ https://chromium.googlesource.com/codecs/libwebp2/+/1251ca74...): -WebP 2 is the successor of the WebP image format, currently in development. It -is not ready for general use, and the format is not finalized so changes to the -library can break compatibility with images encoded with previous versions. \ -USE AT YOU OWN RISK! +WebP 2 is an experimental image codec based on WebP. WebP 2 will not be released +as an image format but is used as a playground for image compression +experiments.
Mindless2112 4y ago
> - There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL Gee. Maybe there's no interest because nobody can use it yet because it's behind a feature flag.
bawolff 4y ago
I dont see why its so odd. Looks like it was behind a feature flag. I imagine the time came where someone had to make a go/no-go call, and they decided no-go. It wouldnt make sense to keep it as a feature flag forever, and once it is not a feature flag it becomes much harder to backout.
- Avamander 4y ago
  > It wouldnt make sense to keep it as a feature flag forever, and once it is not a feature flag it becomes much harder to backout They didn't struggle with removing H2 PUSH though.
  - bawolff 4y ago
    I mean, you're still talking about it, now, much later. If it was really no struggle people would have forgot about it at this point. H2 push is also something that degrades much more gracefully if missing compared to an image codec. Nonetheless, people haved removed image codecs before (rip XBM). Harder is not the same as impossible.
    - Avamander 4y ago
      True, because I saw how it was just being added to software/frameworks. Some parts of the web move slower than Google expects, I have a feeling.

modeless 4y ago

Bummer, I liked jxl better than heic or avif. Guess avif will be the eventual winner then. At least I hope heic dies someday.

alwillis 4y ago
I hope heic dies someday Not anytime soon. Every picture taken with the stock iOS Camera app is saved in HEIC. That’s billions of HEIC files.
- modeless 4y ago
  Yeah, it's unfortunate, but they are often converted before sharing.

plantain 4y ago

I really hope this is revisited - JXL seems to be faster and better compression than HEIC/AVIF.

Cyberdog 4y ago
Don't hold your breath. Big G would prefer you use WebP and their other nearly-proprietary formats nobody wanted but they are pushing into wide use through the might of operating the most widely used browser. But maybe if enough people finally stop using their spyware browser, there will be some hope.
- kodah 4y ago
  > But maybe if enough people finally stop using their spyware browser, there will be some hope. Nearly every company I've worked for requires the use of Chrome because they can manage it.
  - shaky-carrousel 4y ago
    I'm so glad I've never worked in these kind of companies... It sounds like an awful workplace.
    - kodah 4y ago
      I have other things I judge companies for. I just assume I'm not allowed to do anything personal on a work laptop if they manage every aspect of it. I understand why they do it, however, the only thing I find unethical about it is how much companies have balked at explaining the depths to which they track internal employees.
- vlovich123 4y ago
  What proprietary video/image formats does Google have? As far as I know all their image and video formats are open, including WebP. Heck, according to Wikipedia JPEG XL was also partly driven by Google.

VoxPelli 4y ago

JPEG XL apparently never shipped, so the title of this post is misleading. You can’t deprecate something that never shipped.

deleted 4y ago
[deleted]
bertman 4y ago
chrome://flags/#enable-jxl Since v91 or so.
chrismorgan 4y ago
It's not misleading, it's wrong. Deprecation means you can still use the thing. This is removal.

joecool1029 4y ago

Should be noted that it's also behind a feature flag in Firefox (only in nightly!) and while basic support is there(no color profile support), further development doesn't appear to be happening and it's low priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1539075 https://bugzilla.mozilla.org/show_bug.cgi?id=1539075 EDIT: Why the downvotes? This is the status on Mozilla's end for at least a year. If none of the browser developers care to push support, then the format is effectively dead.

EbNar 4y ago

peppermint_gum 4y ago

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.

EMM_386 4y ago

This apparently goes nicely with the other article currently on the frontpage ... > I’d still recommend including JPEG XL versions of your images, because chances are that browser support will come eventually. https://jfhr.me/optimizing-images-with-the-html-picture-tag/ https://jfhr.me/optimizing-images-with-the-html-picture-tag/

watersb 4y ago

The images I've set up for web use are not very large. I don't have a RAW workflow. So maybe I'm missing something. I've found it very challenging to get better compression than optimized JPEG via Squoosh. https://squoosh.app/ https://squoosh.app/ Of course, JPEG XL has alpha channels, and I'm comparing a new format against a standard that's had 20 years of refinement in implementation. Are we cutting ourselves off from a similar future with JPEG XL?

dang 4y ago

We changed the URL from https://chromium-review.googlesource.com/c/chromium/src/+/3988999 https://chromium-review.googlesource.com/c/chromium/src/+/39... to an article that has (a bit) more background. (via https://news.ycombinator.com/item?id=33400436 https://news.ycombinator.com/item?id=33400436, but no comments there)

rektide 4y ago

Insufficient adoption is the cudgel that murders most good web work. Another fine effort given an order of magnitude less soak time & exploration time than it deserves. The web platform cannot be run like an app platform: hockeystick adoption in 18 months or death. But right now we rely on corporate patrons (browser makers) to invest in & support the vast vast majority of progress on the web. The time domains don't match up. Yet there are no examples of alternative ways we might support & fund such core vital human communications.

lifthrasiir 4y ago

There are actually good reasons for not shipping JPEG XL in web browsers, but the comment doesn't list one. In particular it compares JPEG XL with "existing formats", which seemingly include AVIF, but almost identical arguments could have been used to not ship AVIF in web browsers after all. Essentially it says that they happened to pick AVIF for no apparent reason and because of that they can't pick JPEG XL for no apparent reason again. The comment lacks substances, if not dishonest.

bawolff 4y ago
> Essentially it says that they happened to pick AVIF for no apparent reason and because of that they can't pick JPEG XL for no apparent reason again Sounds pretty valid to me. Sometimes you just have to pick a solution. Having every possible format supported does not make sense. If AVIF fills the usecase, no point having both.
- lifthrasiir 4y ago
  If it was the case, it is enough to say that. They didn't.
  - google234123 4y ago
    Everyone else support the other format? No one supports JXL
yboris 4y ago
It would make sense for Chrome not to include JPEG XL in the first place with some list of explicit reasons. It does not make sense to implement it, hide behind a flag, and then remove, claiming there is not enough interest -- when there's no way to reliably gauge interest from this "experiment".
- lifthrasiir 4y ago
  Indeed, the proper way to gauge the interest would be Origin Trial (OT), as noted by one of Blink API owners [1] who is also responsible for Edge at Microsoft. [1] https://twitter.com/slightlylate/status/1587030785197953024 https://twitter.com/slightlylate/status/1587030785197953024

Scaevolus 4y ago

How disappointing. JPEG XL is a much nicer format than AVIF, but Youtube forcing AV1 through meant AVIF is an easy ride-along.

zebracanevra 4y ago

Here's some of the features I am looking forward to in JXL. Better lossy compression than JPG, similar compression to AVIF. AVIF ekes out a little more quality at the very low end, and JXL excels at the very high end. Better lossless compression than PNG. Supports alpha channels. Supports parallel decoding. Significantly faster encoding than other formats like AVIF. Supports multiple colour spaces and formats, allowing for HDR images. The colour in JXL is stored in the XYB colour space. A dev states that this colour space gives more bits to darker colours, leading to better encoded dark skin at similar filesizes to other codecs [1]. Supports up to 4096 channels. A practical use of this is in 3D workflows with Physically Based Rendering textures, where a texture has channels for albedo, normal map, reflection, roughness, metalness, and others. They could be compressed into one JXL, much smaller than an EXR with the same channels. Supports losslessly recompressing existing JPGs into JXL to save space. Those files can also be losslessly (ie byte exact) converted back to JPGs. Supports progressive decoding. AVIF crucially does _not_ have this. Progressive decoding also allows for Responsive Images. No longer would you have to encode two images, like 1x or 2x. Encode the 2x image once – you can serve the 1x image _from the 2x image_. Huge feature if browsers were on board. Supports rudimentary animation (similar to MJPEG, ie only i-frames). Use AVIF for animations. Has frames/layers. This is a pretty cool feature for an image format. I can see two main uses of this: 1. Non-destructive editing. If you want to add an overlay to a JPG, you have to re-encode the image. JXL allows you to add another frame on-top of the other image, without touching the original. 2. Hybrid lossless/lossy images. For example, a screenshot of a UI that contains a photograph. The UI could be losslessly compressed, and the photo could be lossy-ly compressed. There is already an experimental program within the JXL source that does this. [1] https://mobile.twitter.com/jonsneyers/status/1550215859305586691 https://mobile.twitter.com/jonsneyers/status/155021585930558...

jbverschoor 4y ago
All good reasons. But the complexity/ decision on how to behave with certain features could be a compelling reason to stop supporting. In reality, they have webp which is enough for most of the use cases
bawolff 4y ago
> Supports progressive decoding. AVIF crucially does _not_ have this. How important is this in the modern world? Like, GIF, PNG, (progressive) JPG all support this, yet i dont think i have ever noticed this in practise in modern times unless artificially rate limiting my connection. It seems more like a relic from the time of dial up internet.

est31 4y ago

If one wants to speculate, timing wise, this correlates with the recent release of iOS 16 (September 2022) and macOS 13 (October 2022), which have added AVIF support to Safari. That event in turn means that now most browsers support AVIF.

lifthrasiir 4y ago
This is indeed one of "good reasons" that can prefer AVIF over JPEG XL (but not a good reason to not ship JPEG XL). Safari is the most difficult vendor to work with, so if Safari can be convinced there is no bigger obstacle waiting. But it should be noted that Safari still does not support AV1 on which AVIF is based and that fact didn't prevent other browsers from adding support for that video format anyway.
- TingPing 4y ago
  WebKit supports JPEG XL behind a build flag.

cflat 4y ago

This is pure politics. The AOM want proof of loyalty and shipping a competing image format threatens that loyalty pact. It’s also incrementalism at its finest. “We already shipped av1, adding a single frame decode is minor overhead” is the likely rationale. But it misses the point that images are gazed at while video is moving and can get away with a lot of quality sins that you can’t with images. But worse is that av1 is full of optional features. Sure the client could implement it, but how can you know? Even the lauded animated avif is horribly broken across the ecosystem because of this optionality — and there isn’t any way to tell a priori if the browser can support animated avif. Or 444 avif. Or ycocg avif. It’s just down right broken as an image format falling to the lowest common denominator.

mort96 4y ago
- lifthrasiir 4y ago
  While I agree that it is too early to turn to a conspiracy theory, the supposed rationale against JPEG XL is also pretty unsubstantiated and it does feel that the Chrome team doesn't want to share the actual rationale for whatever reason.
  - mort96 4y ago
    Google's rationale is very weak, yes. But it makes no sense to say that this is the AOM pushing Google to do this as a proof of loyalty. Why wouldn't the same apply to Apple and Mozilla? In fact, if deprecating JPEG-XL is something the AOM wants, wouldn't you expect the browser vendors (all of whom are AOM founders) to all conspire to kill JPEG-XL? The right conspiracy theory here isn't even that AOM is forcing Google to do this as a proof of loyalty, the conspiracy theory which at least makes some semblance of sense is that Apple, Google and Mozilla are working to kill JPEG-XL to help their own image format win. But then it's just a group of companies acting in their own self interest and not some coercion, so I suppose that story isn't as sexy.
- ksec 4y ago

kasabali 4y ago

Previous discussion: https://news.ycombinator.com/item?id=33383880 https://news.ycombinator.com/item?id=33383880 If I were a competitor browser vendor, I'd retaliate by removing Webp and AVIF support. But of course, who are we kidding? There are no competitors, only paint jobs and a dog on leash.

mort96 4y ago
Why? The other browser vendors don't ship JPEG-XL either, and all the other browser vendors are fully on board with AVIF. Why would it be in their interest to remove AVIF support?
- kasabali 4y ago
  It wouldn't be in their interest, but wouldn't be in their disinterest, either. Thus why it'd be an appropriate retaliation... in a hypothetical competitive environment... which we don't have. Because as I said, only paint jobs and a leash dog.
  - mort96 4y ago
    It is in the entire web community's interest to have a good, non-patent-encumbered, open image (and video) encoding standard. Killing off the only shot we currently have at that seems to be in the disinterest of the minority browser vendors. People are speculating that this is in preparation of Google introducing their own Google-controlled replacement for JPEG-XL, or pushing WebP harder. I don't know if I buy that, but the more widespread AVIF is, the less power does Google have to unilaterally develop a replacement. And it's in the other vendors' disinterest to give Google unilateral control over even more of the web.
    - kasabali 4y ago
      JPEG-XL is a > good, non-patent-encumbered, open image encoding standard yet they won't be supporting it. Whether you want to buy it or not, de-facto format on the web is JPEG and only JPEG, thanks to the historical momentum. Even webp is still expendable, because Mozilla and Microsoft hold long enough. And AVIF isn't being used anywhere, yet. So no, it isn't in other vendors' disinterest to drop support for Webp and AVIF, because JPEG would continue to be de-facto in that case.

sandstrom 4y ago

We've been planning to move all our image storage (business SaaS) over to JPEG-XL internally, for a few reasons: - Technically a compelling format. - Parallel decoding. - Progressive decoding (no need for 'placeholder images'). - Lossless better than PNG and lossy better than JPG. - Better than AVIF in the 'high quality' end of the spectrum. - Lossless recompression of JPEG into JXL. - Fast enough for on-the-fly conversion to JPEG for backwards compatibility. People from Facebook, Shopify, Adobe, Intel and other huge companies have also voiced their support and said it's on various internal roadmaps. I hope this decision gets reverted. Seems like a huge mistake!

bawolff 4y ago
You planned to move your entire business to a feature that has thus far never been shipped by any browser?
- zinekeller 4y ago
  Twenty years ago, PNG wasn't really supported by any popular browsers of the day, but it showed its capabilities (especially compared to GIF) and was eventually incorporated. I'm assuming that you'll also say to me "You planned to move your entire business to a feature that has thus far never been shipped by any browser?" In a more serious manner, JXL has features that both WebP and AVIF don't. Lossless images simply compress better with JXL than WebP (and if you in these circles you know to not bother with AVIF's lossless mode - even PNG beats AVIF in that arena). I know Google uses near-lossless images for their icons, but near-lossless wouldn't cut when it comes for medical diagnostics or meteorological uses. It has progressive loading, which WebP and AVIF don't really have. Speaking of near-lossless, WebP don't support 4:4:4 chroma subsampling while AVIF technically does but no encoder AFAIK focuses on it. Also, WebP only allows 16,384 pixels per side and AVIF only allows 65,536 pixels per side (which to be fair is the same as the original JPEG), while JXL allows 1,073,741,824 pixels per side (which is ludicrous, but considering that JPEG's 65,536 pixels per side was ludicrous at the time is good for future-proofing). There are also niche features which both WebP and AVIF don't have. While I think that someone at Google was thinking that since AVIF beats JXL on compression at low bitrates there is no demand for JXL, that is a very narrow way of thinking. Not everyone is looking for bandwidth savings, some are looking that current image formats simply don't represent the things that they need (especially that most large companies have focused on "squeeze up the quality for lower bits").

KingOfCoders 4y ago

The internet is what G tells you the internet is. So get in line.

mekster 4y ago
Screw that.

bricss 4y ago

Startup idea, WASM decoder for JXL format!

jakub_g 4y ago

While it seems JPEG XL is very nice, I think the comment 72 from Kornel Lesinski is spot on: https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c72 https://bugs.chromium.org/p/chromium/issues/detail?id=117805... > In terms of compression performance JPEG XL is really good, but I'm concerned that it does not have more than a single implementation. > W3C's bar for web standard recommendations is having at least two independent implementations. AVIF has multiple interoperable implementations in multiple languages. JPEG XL doesn't have yet. > Given the substantial complexity and scope of the JPEG XL format, I'd like to see a proof that a second implementation is possible, and that it's interoperable, so that the Web platform doesn't end needing bug-compatibility with a single C++ codebase.

JyrkiAlakuijala 4y ago
It is not entirely correct. There is a C (j40.c) and two C++ implementations (libjxl and libjxl-tiny). Kornel would love to see a Rust implementation I believe.
- jakub_g 4y ago
  Thanks for clarification! Are those truly independent implementations? (i.e. not derived from each other? I'm not deep into the subject.)
  - lifthrasiir 4y ago
    I'm the author of J40 and it was intentionally developed from scratch exactly in order to remedy the situation where libjxl serves as a de facto specification as opposed to the actual specification.

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.

niutech 4y ago
Could you provide a link to this WASM implementation? I can find JXL-WASM decoder, which is 1.23 MB: https://unpkg.com/browse/jxl-wasm@0.7.0/lib/ https://unpkg.com/browse/jxl-wasm@0.7.0/lib/