Re: JPEG-XL as Content-Encoding?

Willy Tarreau <> Fri, 21 August 2020 21:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 876DF3A1320 for <>; Fri, 21 Aug 2020 14:14:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.898
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PcpRKizJ5lVF for <>; Fri, 21 Aug 2020 14:14:49 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0CF223A12D0 for <>; Fri, 21 Aug 2020 14:14:47 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1k9EKW-0007m0-JD for; Fri, 21 Aug 2020 21:12:08 +0000
Resent-Date: Fri, 21 Aug 2020 21:12:08 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1k9EKU-0007kw-Um for; Fri, 21 Aug 2020 21:12:06 +0000
Received: from ([] by with esmtp (Exim 4.92) (envelope-from <>) id 1k9EKT-0006u6-9A for; 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 <>
To: Alex Deymo <>
Message-ID: <>
References: <> <> <20200820183008.GA8086@lubuntu> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.6.1 (2016-04-27)
Received-SPF: pass client-ip=;;
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: 1k9EKT-0006u6-9A 56a91481e4e9f8b6868b728935e5d1b6
Subject: Re: JPEG-XL as Content-Encoding?
Archived-At: <>
X-Mailing-List: <> archive/latest/37950
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-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.