4 ms·

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

by 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.

by ck45 4y ago

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.