Hacker News Reader

Comment by iLoveOncall | Hacker News Reader

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.

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.

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.

JPEG XL supports lossless, lossy and lossless JPEG recompression.

You can see lossless benchmarks against other formats here:

https://docs.google.com/spreadsheets/d/1ju4q1WkaXT7WoxZINmQp...

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.

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

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.

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.

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

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

Reply on news.ycombinator.com