5 ms·

JPEG XL was not used anywhere which is why it got deprecated. It was never gonna be the future of anything.

ck45 4y ago
I linked https://cloudinary.com/blog/the-case-for-jpeg-xl https://cloudinary.com/blog/the-case-for-jpeg-xl in another comment which links to several big players requesting full JPEG XL support. It seems the reason why it wasn't adopted more broadly is that there was no full support for it in Chrome. I wouldn't even consider it a chicken and egg situation.
- iLoveOncall 4y ago
  Your link doesn't mention anyone asking for it. Also AVIF is more performant for most cases. Lossless is not what matters on the web.
  - ksec 4y ago
    >Also AVIF is more performant for most cases. Source? JPEG XL has already shown, over 10,000 sample size and over a wide variety of BPP to be better than AVIF, on latest JPEG And AVIF versions. AVIF, on the other hand, has yet to shown anything similar.
  - ck45 4y ago
    It contains 8 links to the Chromium bugtracker in this paragraph: However, if the enthusiastic support in the Chromium bugtracker from Facebook, Adobe, Intel and VESA, Krita, The Guardian, libvips, Cloudinary, and Shopify is any indication, it seems baffling to conclude that there would be insufficient ecosystem interest. That's why I assumed there was demand for JPEG XL.
  - pushrax 4y ago
    JPEG XL implements lossless image compression, but that's definitely not the most interesting feature. It also implements lossless JPEG recompression. So your existing JPEGs can be served with ~20% less bandwidth, without quality loss. Unlike AVIF, JPEG XL also has advanced progressive delivery features, which is useful for the web. And if you look at the testing described in the post, JPEG XL also achieved higher subjective quality per compressed bit, despite having a faster encoder.
    - 149764 4y ago
      JPEG XL supports lossless, lossy and lossless JPEG recompression. You can see lossless benchmarks against other formats here: https://docs.google.com/spreadsheets/d/1ju4q1WkaXT7WoxZINmQpf4ElgMD2VMlqeDN2DuZ6yJ8/ https://docs.google.com/spreadsheets/d/1ju4q1WkaXT7WoxZINmQp...
    - astrange 4y ago
      Lossless JPEG recompression, if it’s so good, can be done at the HTTP layer. If a new image format doesn’t have a hardware decoder it’s dead. The security surface of new formats is unacceptable if it’s going to be slow and power-hungry too. Only problem with JPEG is the lack of HDR.
      - JyrkiAlakuijala 4y ago
        JPEG XL as a HTTP Content Encoding: 1) transfer JPEG XL, 2) decode the JPEG XL to DCT coefficients, 3) encode a new JPEG1 file 4) decode the new JPEG1 file 5) render pixels JPEG XL as image format: 1) transfer JPEG XL 2) decode the JPEG XL to DCT coefficients 3) render pixels Two additional coding steps (3 and 4) are needed in the HTTP Content Encoding approach. If we want to transfer lossless JPEG1s, it is less computation and a faster approach to add JPEG XL as an image codec. If JPEG XL is too powerful and creates danger for AVIF, then one possibility is to remove features such as adaptive quantization, lossless encoding and larger (non-8x8) DCTs. This effectively makes JPEG XL as JPEG1 recompressor as an image codec. Also, JPEG XL's reference implementation (libjxl) has a more accurate JPEG1 decoder than any other existing implementation. Asking someone else to paint the pixels leads to worse quality (about 8 % worse).
  - JyrkiAlakuijala 4y ago
    Nope. In my eyes AVIF is not more performance. It makes photos suffer and become blurry, especially so in highly saturated areas, skin, marble, vegetation. Once beautiful things start to look like cheap plastic.
    - gjsman-1000 4y ago
      Check the file size - anything will look bad if you set the compression too high. If you see AVIF images with some artifacting, find a JPEG of the same image and compare file sizes. An AVIF the same size as a JPEG will be better than the JPEG - an AVIF only 50% of the size will probably be visually undetectable to most people. An AVIF only 20% of the size... you'll tell. Same for JXL - if I set my JXL to compress to only 15% of the size of the JPEG, it's hardly a fair comparison.
      - JyrkiAlakuijala 4y ago
        For my eyes: AVIF fails to deliver a consistent experience at 3+ BPP -- I'd hate to compress my family pictures at AVIF even at high BPP, some part is smudged in a weird way. libjpeg-turbo and mozjpeg does deliver a consistent experience at 4 BPP guetzli and jpegli delivers a consistent experience at 3 BPP JPEG XL delivers a consistent experience at 1.7 BPP
- wpietri 4y ago
  Thanks for this. I looked through the big-player comments and the one I found most persuasive was from Shopify, who had specific, practical reasons for needing this: https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c79 https://bugs.chromium.org/p/chromium/issues/detail?id=117805...
  - flak48 4y ago
    The reply by the Chromium engineer (from Google? - I'm not sure) to a long thread of people from several companies quantifying the benefits of JPEG XL and requesting that it be supported is just sad: > Thank you everyone for your comments and feedback regarding JPEG XL. We will be removing the JPEG XL code and flag from Chromium for the following reasons: > - 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 increm ental 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 --- If I were to put on my tinfoil hat, I would imagine the people involved here are desperate to put 'Removed unused code and removed maintenance burden by X%' in there performance reviews for this year
    - arglebargle123 4y ago
      There's not much to tinfoil hat about here, Google is killing jxl in favor of a format they control: webp.
hmry 4y ago
It is supported by every image manipulation program I use on a regular basis. Photoshop, Krita, EOG, IrfanView. That's enough for me.
- iLoveOncall 4y ago
  This is irrelevant, what matters is the consumption of the format, not its production.
  - lajamerr 4y ago
    Can't really consume it if it's locked behind a flag. 99% of chrome users never touch the flags at all.
  - hmry 4y ago
    Isn't that circular reasoning? Chrome shouldn't support JPEG-XL because not enough consumers support it? Chrome is the number one consumer of images. If Chrome added support, suddenly 90% of people would be able to use the format. (Also EOG and IrfanView are image viewers, not production tools.)
    - wpietri 4y ago
      Yeah, to me this is another sign that Chrome's dominance is a menace to the open web. Whatever the best outcome is here, it's very concerning to me that a possibly important improvement can be blocked with so little meaningful explanation.
      - arglebargle123 4y ago
        The explanation is pretty plain: google controls the webp format, jxl competes with webp.
        quikee 4y ago
        In what way does Google control WebP? They have frozen the format and nothing will be added to it. WebP2 was abandoned. Google is also involved with JPEG XL - actually some developers that worked on WebP now work on JPEG XL. If someone controls something it is the Chromium/AOM/AVIF/AV1 team that controls and decides what multimedia formats go inside Chrome/Chromium thus controlling what is used on the web and ignoring what the web community has to say about it.
sitkack 4y ago
It isn't going to be used anywhere when it is behind a flag.
scorpio241 4y ago
Not used anywhere? E.g. Affinity Photo has support for JPEG XL, but not for AVIF. Not used in browsers because they are nearly controlled by Chromium, which is clearly biased toward AVIF. https://en.wikipedia.org/wiki/JPEG_XL#Official_support https://en.wikipedia.org/wiki/JPEG_XL#Official_support Official support: Squoosh – In-browser image converter[42] Adobe Camera Raw – Adobe Photoshop's import/export for digital camera images[43] Affinity Photo – raster graphics editor[44] Chasys Draw IES – raster graphics editor[45] Darktable – raw photo management application[46] ExifTool – metadata editor[47] FFmpeg – multimedia framework, via libjxl[48] GIMP – raster graphics editor[49] gThumb – image viewer and photo management application for Linux[50] ImageMagick – toolkit for raster graphics processing[51] IrfanView – image viewer and editor for Windows[52] KaOS – Linux distribution[53] Krita – raster graphics editor[54][55] libvips – image processing library[56][57] vipsdisp – high-performance ultra-high-resolution image viewer for Linux[58] Qt and KDE apps – via KImageFormats[59] XnView MP – viewer and editor of raster graphics[60] Pale Moon – web browser[61]
- gjsman-1000 4y ago
  There's only one issue with this list - many of these applications also support AVIF, and were "sitting on the fence" over the issue, which should not be interpreted as a sign of JXL's success. And the ones that don't are very likely to fall in line after the Chromium decision.
- masklinn 4y ago
  > Not used anywhere? E.g. Affinity Photo has support for JPEG XL, but not for AVIF. It also support PSDs. Should Chrome support PSDs? > Not used in browsers because they are nearly controlled by Chromium, which is clearly biased toward AVIF. Ah yes, Google, a major contributor to JXL, is "clearly biased towards AVIF". I'm sure you'll find your saviours at Apple (governing member of AOM, shipped AVIF this year), Mozilla (governing member of AOM, shipped AVIF in June 2020, default-enabled in October 2021), or Microsoft (governing member of AOM).
  - deleted 4y ago
    [deleted]
mort96 4y ago
JPEG XL was not used anywhere on the web because no browser shipped with JXL support. As soon as Google enabled it in Chrome, Mozilla in Firefox or Apple in Safari, we would've started to see adoption.
- JyrkiAlakuijala 4y ago
  Previously yes. Two browsers have now added support.
  - mort96 4y ago
    No? Every single browser on caniuse has either no JXL support at all or has it disabled by default: https://caniuse.com/jpegxl https://caniuse.com/jpegxl
    - lifthrasiir 4y ago
      I don't know another, but Pale Moon does support it so your original statement is just false. And it can be actually a good way to test a proposed patch to Gecko---many issues were found and fixed after it first got JPEG XL.
croes 4y ago
I wonder why nobody used a hidden feature that needed to be activated manually.
rhdunn 4y ago
It's not used anywhere because it is/was behind a feature flag so browsers didn't support it out of the box. IIUC, various companies like BBC, Facebook, and others were ready to deploy JPEG XL support. If you take your approach, nothing new (including the webp standard that Google/Chrome pushed) would be released on the web because nothing is using it.
- astrange 4y ago
  WebP should not have been released and no one should have used it. Google should stop letting individual employees invent new image formats as hobbies. (This happened _twice_. WebP lossless is a whole different codec from lossy.) AVIF is the first one that might be acceptable.
  - ksec 4y ago
    I am glad I am not the only one seeing it. While in extreme minorities, still happy to be this view is not some insanity as many claims to be.
  - JyrkiAlakuijala 4y ago
    Another take on this: AVIF is a Netflix engineer quick-hacking a video format as an image format -- without actual experience in codec design, image compression or psychovisual research, without consulting such people to get the design right. When size and memory limitations were noticed, a tiled approach was proposed where globally spanning artefacts through the image will emerge. No one has been able to propose a fix for this and other kludges yet. AVIF doesn't match WebP lossless in density, even given the 10 years more of compression research. AVIF doesn't even beat PNG at lossless, which itself was hacked together in a few months ~25 years earlier (primitive filtering, mixing filter bytes with image data, botched 16 bits compression, layering a primitive 1980's byte-compressor and filtering instead of designing a codec).
sb057 4y ago
WebM, VP8/9, WebP, and for that matter MP4, MP3, and the original JPEG weren't used anywhere until there was support for them.

ck45 4y ago

I linked https://cloudinary.com/blog/the-case-for-jpeg-xl https://cloudinary.com/blog/the-case-for-jpeg-xl in another comment which links to several big players requesting full JPEG XL support. It seems the reason why it wasn't adopted more broadly is that there was no full support for it in Chrome. I wouldn't even consider it a chicken and egg situation.

iLoveOncall 4y ago
Your link doesn't mention anyone asking for it. Also AVIF is more performant for most cases. Lossless is not what matters on the web.
- ksec 4y ago
  >Also AVIF is more performant for most cases. Source? JPEG XL has already shown, over 10,000 sample size and over a wide variety of BPP to be better than AVIF, on latest JPEG And AVIF versions. AVIF, on the other hand, has yet to shown anything similar.
- ck45 4y ago
  It contains 8 links to the Chromium bugtracker in this paragraph: However, if the enthusiastic support in the Chromium bugtracker from Facebook, Adobe, Intel and VESA, Krita, The Guardian, libvips, Cloudinary, and Shopify is any indication, it seems baffling to conclude that there would be insufficient ecosystem interest. That's why I assumed there was demand for JPEG XL.
- pushrax 4y ago
  JPEG XL implements lossless image compression, but that's definitely not the most interesting feature. It also implements lossless JPEG recompression. So your existing JPEGs can be served with ~20% less bandwidth, without quality loss. Unlike AVIF, JPEG XL also has advanced progressive delivery features, which is useful for the web. And if you look at the testing described in the post, JPEG XL also achieved higher subjective quality per compressed bit, despite having a faster encoder.
  - 149764 4y ago
    JPEG XL supports lossless, lossy and lossless JPEG recompression. You can see lossless benchmarks against other formats here: https://docs.google.com/spreadsheets/d/1ju4q1WkaXT7WoxZINmQpf4ElgMD2VMlqeDN2DuZ6yJ8/ https://docs.google.com/spreadsheets/d/1ju4q1WkaXT7WoxZINmQp...
  - astrange 4y ago
    Lossless JPEG recompression, if it’s so good, can be done at the HTTP layer. If a new image format doesn’t have a hardware decoder it’s dead. The security surface of new formats is unacceptable if it’s going to be slow and power-hungry too. Only problem with JPEG is the lack of HDR.
    - JyrkiAlakuijala 4y ago
      JPEG XL as a HTTP Content Encoding: 1) transfer JPEG XL, 2) decode the JPEG XL to DCT coefficients, 3) encode a new JPEG1 file 4) decode the new JPEG1 file 5) render pixels JPEG XL as image format: 1) transfer JPEG XL 2) decode the JPEG XL to DCT coefficients 3) render pixels Two additional coding steps (3 and 4) are needed in the HTTP Content Encoding approach. If we want to transfer lossless JPEG1s, it is less computation and a faster approach to add JPEG XL as an image codec. If JPEG XL is too powerful and creates danger for AVIF, then one possibility is to remove features such as adaptive quantization, lossless encoding and larger (non-8x8) DCTs. This effectively makes JPEG XL as JPEG1 recompressor as an image codec. Also, JPEG XL's reference implementation (libjxl) has a more accurate JPEG1 decoder than any other existing implementation. Asking someone else to paint the pixels leads to worse quality (about 8 % worse).
- JyrkiAlakuijala 4y ago
  Nope. In my eyes AVIF is not more performance. It makes photos suffer and become blurry, especially so in highly saturated areas, skin, marble, vegetation. Once beautiful things start to look like cheap plastic.
  - gjsman-1000 4y ago
    Check the file size - anything will look bad if you set the compression too high. If you see AVIF images with some artifacting, find a JPEG of the same image and compare file sizes. An AVIF the same size as a JPEG will be better than the JPEG - an AVIF only 50% of the size will probably be visually undetectable to most people. An AVIF only 20% of the size... you'll tell. Same for JXL - if I set my JXL to compress to only 15% of the size of the JPEG, it's hardly a fair comparison.
    - JyrkiAlakuijala 4y ago
      For my eyes: AVIF fails to deliver a consistent experience at 3+ BPP -- I'd hate to compress my family pictures at AVIF even at high BPP, some part is smudged in a weird way. libjpeg-turbo and mozjpeg does deliver a consistent experience at 4 BPP guetzli and jpegli delivers a consistent experience at 3 BPP JPEG XL delivers a consistent experience at 1.7 BPP
wpietri 4y ago
Thanks for this. I looked through the big-player comments and the one I found most persuasive was from Shopify, who had specific, practical reasons for needing this: https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c79 https://bugs.chromium.org/p/chromium/issues/detail?id=117805...
- flak48 4y ago
  The reply by the Chromium engineer (from Google? - I'm not sure) to a long thread of people from several companies quantifying the benefits of JPEG XL and requesting that it be supported is just sad: > Thank you everyone for your comments and feedback regarding JPEG XL. We will be removing the JPEG XL code and flag from Chromium for the following reasons: > - 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 increm ental 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 --- If I were to put on my tinfoil hat, I would imagine the people involved here are desperate to put 'Removed unused code and removed maintenance burden by X%' in there performance reviews for this year
  - arglebargle123 4y ago
    There's not much to tinfoil hat about here, Google is killing jxl in favor of a format they control: webp.

hmry 4y ago

It is supported by every image manipulation program I use on a regular basis. Photoshop, Krita, EOG, IrfanView. That's enough for me.

iLoveOncall 4y ago
This is irrelevant, what matters is the consumption of the format, not its production.
- lajamerr 4y ago
  Can't really consume it if it's locked behind a flag. 99% of chrome users never touch the flags at all.
- hmry 4y ago
  Isn't that circular reasoning? Chrome shouldn't support JPEG-XL because not enough consumers support it? Chrome is the number one consumer of images. If Chrome added support, suddenly 90% of people would be able to use the format. (Also EOG and IrfanView are image viewers, not production tools.)
  - wpietri 4y ago
    Yeah, to me this is another sign that Chrome's dominance is a menace to the open web. Whatever the best outcome is here, it's very concerning to me that a possibly important improvement can be blocked with so little meaningful explanation.
    - arglebargle123 4y ago
      The explanation is pretty plain: google controls the webp format, jxl competes with webp.
      - quikee 4y ago
        In what way does Google control WebP? They have frozen the format and nothing will be added to it. WebP2 was abandoned. Google is also involved with JPEG XL - actually some developers that worked on WebP now work on JPEG XL. If someone controls something it is the Chromium/AOM/AVIF/AV1 team that controls and decides what multimedia formats go inside Chrome/Chromium thus controlling what is used on the web and ignoring what the web community has to say about it.

sitkack 4y ago

It isn't going to be used anywhere when it is behind a flag.

scorpio241 4y ago

Not used anywhere? E.g. Affinity Photo has support for JPEG XL, but not for AVIF. Not used in browsers because they are nearly controlled by Chromium, which is clearly biased toward AVIF. https://en.wikipedia.org/wiki/JPEG_XL#Official_support https://en.wikipedia.org/wiki/JPEG_XL#Official_support Official support: Squoosh – In-browser image converter[42] Adobe Camera Raw – Adobe Photoshop's import/export for digital camera images[43] Affinity Photo – raster graphics editor[44] Chasys Draw IES – raster graphics editor[45] Darktable – raw photo management application[46] ExifTool – metadata editor[47] FFmpeg – multimedia framework, via libjxl[48] GIMP – raster graphics editor[49] gThumb – image viewer and photo management application for Linux[50] ImageMagick – toolkit for raster graphics processing[51] IrfanView – image viewer and editor for Windows[52] KaOS – Linux distribution[53] Krita – raster graphics editor[54][55] libvips – image processing library[56][57] vipsdisp – high-performance ultra-high-resolution image viewer for Linux[58] Qt and KDE apps – via KImageFormats[59] XnView MP – viewer and editor of raster graphics[60] Pale Moon – web browser[61]

gjsman-1000 4y ago
There's only one issue with this list - many of these applications also support AVIF, and were "sitting on the fence" over the issue, which should not be interpreted as a sign of JXL's success. And the ones that don't are very likely to fall in line after the Chromium decision.
masklinn 4y ago
> Not used anywhere? E.g. Affinity Photo has support for JPEG XL, but not for AVIF. It also support PSDs. Should Chrome support PSDs? > Not used in browsers because they are nearly controlled by Chromium, which is clearly biased toward AVIF. Ah yes, Google, a major contributor to JXL, is "clearly biased towards AVIF". I'm sure you'll find your saviours at Apple (governing member of AOM, shipped AVIF this year), Mozilla (governing member of AOM, shipped AVIF in June 2020, default-enabled in October 2021), or Microsoft (governing member of AOM).
- deleted 4y ago
  [deleted]

mort96 4y ago

JPEG XL was not used anywhere on the web because no browser shipped with JXL support. As soon as Google enabled it in Chrome, Mozilla in Firefox or Apple in Safari, we would've started to see adoption.

JyrkiAlakuijala 4y ago
Previously yes. Two browsers have now added support.
- mort96 4y ago
  No? Every single browser on caniuse has either no JXL support at all or has it disabled by default: https://caniuse.com/jpegxl https://caniuse.com/jpegxl
  - lifthrasiir 4y ago
    I don't know another, but Pale Moon does support it so your original statement is just false. And it can be actually a good way to test a proposed patch to Gecko---many issues were found and fixed after it first got JPEG XL.

croes 4y ago

I wonder why nobody used a hidden feature that needed to be activated manually.

rhdunn 4y ago

It's not used anywhere because it is/was behind a feature flag so browsers didn't support it out of the box. IIUC, various companies like BBC, Facebook, and others were ready to deploy JPEG XL support. If you take your approach, nothing new (including the webp standard that Google/Chrome pushed) would be released on the web because nothing is using it.

astrange 4y ago
WebP should not have been released and no one should have used it. Google should stop letting individual employees invent new image formats as hobbies. (This happened _twice_. WebP lossless is a whole different codec from lossy.) AVIF is the first one that might be acceptable.
- ksec 4y ago
  I am glad I am not the only one seeing it. While in extreme minorities, still happy to be this view is not some insanity as many claims to be.
- JyrkiAlakuijala 4y ago
  Another take on this: AVIF is a Netflix engineer quick-hacking a video format as an image format -- without actual experience in codec design, image compression or psychovisual research, without consulting such people to get the design right. When size and memory limitations were noticed, a tiled approach was proposed where globally spanning artefacts through the image will emerge. No one has been able to propose a fix for this and other kludges yet. AVIF doesn't match WebP lossless in density, even given the 10 years more of compression research. AVIF doesn't even beat PNG at lossless, which itself was hacked together in a few months ~25 years earlier (primitive filtering, mixing filter bytes with image data, botched 16 bits compression, layering a primitive 1980's byte-compressor and filtering instead of designing a codec).

sb057 4y ago

WebM, VP8/9, WebP, and for that matter MP4, MP3, and the original JPEG weren't used anywhere until there was support for them.