Re: JPEG-XL as Content-Encoding?

All that granted, If I send it to a browser or app or whatever in the
expectation that it's going to be rendered, image/jpxl seems like the right
choice.  Among other things, there are a lot of dumb HTTP clients out there
that just dispatch based on the Content-type value and in the case of
image/* probably don't even look at Content-encoding.



On Fri, Aug 21, 2020 at 2:24 PM Alex Deymo <deymo@google.com> wrote:

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