Re: JPEG-XL as Content-Encoding?

On Fri, Aug 21, 2020 at 04:36:46PM +0200, Alex Deymo wrote:
> What's not true is the opposite statement, and maybe that's where the
> confusion is. Not every JXL is a losslessly-re-encoded JPEG, although you
> can always do stuff like decode any JXL to pixels and encode it back to
> JPEG but it would largely depend on how you encode back to JPEG what file
> you end up with. The lossless recompression feature limits the options when
> encoding the JXL and adds extra information to be able to deterministically
> produce a certain JPEG file.

So that means that you cannot reproduce the original JPEG byte-for-byte ?
So it's not an encoding, it's a different image format. Even if it *looks*
visually identical, just like a PNG may look like a JPG, you can't turn
one into the other and conversely and hope that the original SHA256 of
the delivered file that was announced along the object in a header will
validate once a client wants to verify it. When playing only with encoding
you can always recover the original bytes and verify them because only the
representation changes, not the contents. Thus here it definitely is a
different Content-Type and not a different Content-Encoding.

Willy

Received on Friday, 21 August 2020 21:12:07 UTC