|
|
|
|
|
|
by astrange
1280 days 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. |
|
|
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).