[pushrax]

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]

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

[astrange]

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]

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