3 ms·

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

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