Re: JPEG-XL as Content-Encoding?

Willy Tarreau <w@1wt.eu> Fri, 21 August 2020 21:14 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 876DF3A1320 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 21 Aug 2020 14:14:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.898
X-Spam-Level:
X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcpRKizJ5lVF for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 21 Aug 2020 14:14:49 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CF223A12D0 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 21 Aug 2020 14:14:47 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1k9EKW-0007m0-JD for ietf-http-wg-dist@listhub.w3.org; Fri, 21 Aug 2020 21:12:08 +0000
Resent-Date: Fri, 21 Aug 2020 21:12:08 +0000
Resent-Message-Id: <E1k9EKW-0007m0-JD@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <w@1wt.eu>) id 1k9EKU-0007kw-Um for ietf-http-wg@listhub.w3.org; Fri, 21 Aug 2020 21:12:06 +0000
Received: from wtarreau.pck.nerim.net ([62.212.114.60] helo=1wt.eu) by mimas.w3.org with esmtp (Exim 4.92) (envelope-from <w@1wt.eu>) id 1k9EKT-0006u6-9A for ietf-http-wg@w3.org; Fri, 21 Aug 2020 21:12:06 +0000
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 07LLBpW9025276; Fri, 21 Aug 2020 23:11:51 +0200
Date: Fri, 21 Aug 2020 23:11:51 +0200
From: Willy Tarreau <w@1wt.eu>
To: Alex Deymo <deymo@google.com>
Cc: ietf-http-wg@w3.org
Message-ID: <20200821211151.GA25272@1wt.eu>
References: <CACj=BEjdwH1OtS=uQXsgPN3XVJvVEUeisjeF5_iro1vg0omqWQ@mail.gmail.com> <20200820151401.GB21689@1wt.eu> <20200820183008.GA8086@lubuntu> <18159.1597960275@critter.freebsd.dk> <CADR0UcWkxb4ZtMgjqDeAv=m6G3ks2P75L-5pvt-ctz8WyJF29g@mail.gmail.com> <CAGd9gwhR5zTjsCugrZeSr7Yt_N6wxv7k5evrLBGW=dkKt257ZA@mail.gmail.com> <8f2e15c4-1b49-2ef9-3346-baf9bc610d14@gmx.de> <CAGd9gwjWriKCRNNDkjfx0ME0L8v5qT3mO=6X1U2tDNYyXLtZ9w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAGd9gwjWriKCRNNDkjfx0ME0L8v5qT3mO=6X1U2tDNYyXLtZ9w@mail.gmail.com>
User-Agent: Mutt/1.6.1 (2016-04-27)
Received-SPF: pass client-ip=62.212.114.60; envelope-from=w@1wt.eu; helo=1wt.eu
X-W3C-Hub-Spam-Status: No, score=-7.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1k9EKT-0006u6-9A 56a91481e4e9f8b6868b728935e5d1b6
X-Original-To: ietf-http-wg@w3.org
Subject: Re: JPEG-XL as Content-Encoding?
Archived-At: <https://www.w3.org/mid/20200821211151.GA25272@1wt.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37950
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

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