Re: JPEG-XL as Content-Encoding?

Alex Deymo <> Fri, 21 August 2020 21:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7D2313A12A6 for <>; Fri, 21 Aug 2020 14:24:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.497
X-Spam-Status: No, score=-10.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FCTCpVjs-HGW for <>; Fri, 21 Aug 2020 14:24:46 -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 D09D73A12A3 for <>; Fri, 21 Aug 2020 14:24:46 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1k9EWW-0000Vp-4z for; Fri, 21 Aug 2020 21:24:32 +0000
Resent-Date: Fri, 21 Aug 2020 21:24:32 +0000
Resent-Message-Id: <>
Received: from www-data by with local (Exim 4.92) (envelope-from <>) id 1k9EWV-0000VB-Ep for; Fri, 21 Aug 2020 21:24:31 +0000
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1k9EUT-0000LP-OA for; Fri, 21 Aug 2020 21:22:25 +0000
Received: from ([2a00:1450:4864:20::635]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1k9EUS-0002PT-1Q for; Fri, 21 Aug 2020 21:22:25 +0000
Received: by with SMTP id d11so3873240ejt.13 for <>; Fri, 21 Aug 2020 14:22:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:cc; bh=K9HaPweJ2uRr5iXv0qUkPlJ5EYG+x+AmM8G6Kl2Ip34=; b=rQS+4nBhrfJrFRQ1jAYy/G00lyxrguGTzQF1pzFjvvcGewP35QkxmvjGyK8WnE5vln uNNCFQtKzZPBMmOW8/9iCNPciENcfGYsmsqwyph+YUS8Im8ncKSnVGbHmJ9fx7OhF2mO XyB1XhI2Y2fo+JFH7ytbddqNsX1L9FxWAqKKjh6zZrd+qGM9YsRAaZegvdpni/fZ92Xk 3inh+WDyKLt6kt63GEhd4oncc1xtpldXiF3Bza3ndGVm+heJ831eflGkbVhm+QcnVd6B PZwgjiHRmbIxVv7DxdWp+Y8l0qwTreNQZ4ScODm+wE8w8cdhGRT6i+7Ex07ZXwZh3I/+ O6tw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:cc; bh=K9HaPweJ2uRr5iXv0qUkPlJ5EYG+x+AmM8G6Kl2Ip34=; b=pwIpsTEH2FrGy49Fo7RQcc+Xx48aMXBYZKZXWo1hfpxkhrMDGaqEEaiJHwNE/Dcc1S yQGoOpqBTcvNZqLafePjZgFmO9X2Nx5Jj5/5PFDLwnrL5cS3wfATptpeZibaaxJaY/bZ vL8qLN2VKmQTEiyaZrVo9yHafTm9Gv48DYHXu2T/9GsEomq4NfgUfEhT9CRVN+XGTwPZ WUC5FhR1x3Y6zZTGYBlC9A2HzO4SSmfiyu86/DKmNMcd5rWxjxT2eXf3Kie3MDN0jvsl +iCL7CRvNTARN/7ndBu95UfmKGpvU1fc8brmfQAG4vQikmHVuAGeqfu94WrTjn+arCt9 lB/A==
X-Gm-Message-State: AOAM533ZGp/bLR8N83z2wzsf5jVJlG3OVXV3grh8JReR813IbSH2O/eF IAiI5nLsyVS07/YTA9s2zT+M5ExqEW/DMEs8GnMyM7rZ3hU=
X-Google-Smtp-Source: ABdhPJxwL6CHhMjW7KDkAb4NaN6pQ/8zdKTxJrWFyJrsnCvokwxsxf71rI1l5RwtCaqBXFUM3k/SQeTb+00ysM2wqb4=
X-Received: by 2002:a17:906:393:: with SMTP id b19mr3833586eja.268.1598044932014; Fri, 21 Aug 2020 14:22:12 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <20200820183008.GA8086@lubuntu> <> <> <> <> <> <>
In-Reply-To: <>
From: Alex Deymo <>
Date: Fri, 21 Aug 2020 23:22:00 +0200
Message-ID: <>
Cc: HTTP Working Group <>
Content-Type: multipart/alternative; boundary="000000000000825ff005ad69d470"
Received-SPF: pass client-ip=2a00:1450:4864:20::635;;
X-W3C-Hub-Spam-Status: No, score=-18.6
X-W3C-Scan-Sig: 1k9EUS-0002PT-1Q 7b35dd59042ea7cc28bee193711ab6f3
X-caa-id: 444c2a3d8b
Subject: Re: JPEG-XL as Content-Encoding?
Archived-At: <>
X-Mailing-List: <> archive/latest/37951
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Le ven. 21 août 2020 à 23:11, Willy Tarreau <> 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.