Re: JPEG-XL as Content-Encoding?

Le ven. 21 août 2020 à 23:11, Willy Tarreau <w@1wt.eu> a écrit :

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


If you start with a JPEG file, you can convert it to a ~20% smaller JXL
file such that if you take that JXL file you get back the exact
byte-for-byte original JPEG file you started with, same data, same hash.
This is what lossless recompression of JPEG files is all about and what's
being proposed as a Content-Encoding.

My statement here was about the fact that there are other JXL files that
are not a lossless recompressed JPEG, which is fine, those simply won't
show up as payloads in a Content-Encoding context.