Re: JPEG-XL as Content-Encoding?

Tim Bray <> Fri, 21 August 2020 21:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8D6093A12AB for <>; Fri, 21 Aug 2020 14:31:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.896
X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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] 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 pdR-8nXwyX4M for <>; Fri, 21 Aug 2020 14:31:19 -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 1B0613A12A9 for <>; Fri, 21 Aug 2020 14:31:18 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1k9Ecp-0000vI-Fb for; Fri, 21 Aug 2020 21:31:03 +0000
Resent-Date: Fri, 21 Aug 2020 21:31:03 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1k9Ecn-0000tq-Hs for; Fri, 21 Aug 2020 21:31:01 +0000
Received: from ([2a00:1450:4864:20::22e]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1k9Ecl-0002Z6-Iz for; Fri, 21 Aug 2020 21:31:01 +0000
Received: by with SMTP id f26so3370871ljc.8 for <>; Fri, 21 Aug 2020 14:30:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1qD5xgCyYgP4eZoanxwD3pDjqgKzz6rbc/eKT3oPs20=; b=YZU736WIZe51A23lVBcmuhDgrq+Ck+K/Vp88pgy6jUnPFQJr5EPsjneSn1O/KUzbZM szOq8tEr9NHVvxla1kTwKBGV08BbS4JL4qhl/FHdP1ThQYFLTIZu5ZfEUxCiqhbx2n9M YQMWYvm3IrG1I2ZqZrs+MCp+NDqViU9h2lcHCjwquoimj0GpnTQ1AdIljKHpoPIEKkPQ WVueXt4xj4eGn0+ZFtJyD8aGaqEkXl93aDhWlw4cdApCHsVxBNdMToyyD0ZbbUVOJwbe 1yixNuvUQELbWMV5xY/zNzOFPCwTHnEjKKetUT9AM8VY5Pqa/1GVVjg1a0CbkQT1dHQb 1PXQ==
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:to:cc; bh=1qD5xgCyYgP4eZoanxwD3pDjqgKzz6rbc/eKT3oPs20=; b=sGS3l2cEHpQBuXQ/ooaYKWoSTzEOV7O1/0qlyyJ4WxqgsjQAX4Rxb+Ls4NR67fWgRg ZXtiyr///3dpLQtyX0lh+rjcyIzAavTW+PUckYVo0I9a6qzSqT/8oo+e4qSwM/aJ7tBQ r8ZCea221BpEs1yYCClMpk69jKeBCCHmg9qIdCEa2e0iiSnYl8YW8mPvASL6WnnUWPh8 6W4a5IwlfK2Gqq2V9Q7N0gs1PCq+xfRpYgbmA0UAcgvXCXWGZ7Yib9Feu7TKONkW74mz sahfL64P+GZMWIgL/JFZxz1qjuQurw0xmlx/gSxiiQFZeRNjWDnV65UPQjxw3EHKa/H/ I+HQ==
X-Gm-Message-State: AOAM5313pAhdfi4u55SldAdLmkwJQZRoMu3iIhj/AsX7uhEIuSCuFhRI rjBnwA4ehYMZtKM5dpQfH1rQ+0yxO7bAlNUHPKzRwg==
X-Google-Smtp-Source: ABdhPJxXXwk35Z0ZSLIlLOijGBT63QsoUGV27EXBrxFnFVC3yHOV44h3IfXmB7BMW6fbrECGodvePDCcidvoiwqGwq0=
X-Received: by 2002:a2e:8145:: with SMTP id t5mr2258898ljg.398.1598045445895; Fri, 21 Aug 2020 14:30:45 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <20200820183008.GA8086@lubuntu> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Tim Bray <>
Date: Fri, 21 Aug 2020 14:30:34 -0700
Message-ID: <>
To: Alex Deymo <>
Cc: HTTP Working Group <>
Content-Type: multipart/alternative; boundary="00000000000023a9a105ad69f302"
Received-SPF: pass client-ip=2a00:1450:4864:20::22e;;
X-W3C-Hub-Spam-Status: No, score=-8.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1k9Ecl-0002Z6-Iz 6db19a7b473326e2dcc81a696e511697
Subject: Re: JPEG-XL as Content-Encoding?
Archived-At: <>
X-Mailing-List: <> archive/latest/37952
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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 <> wrote:

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