Re: JPEG-XL as Content-Encoding?

Tim Bray <tbray@textuality.com> Fri, 21 August 2020 21:31 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 8D6093A12AB for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 21 Aug 2020 14:31:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.896
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.20150623.gappssmtp.com
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 pdR-8nXwyX4M for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 21 Aug 2020 14:31:19 -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 1B0613A12A9 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 21 Aug 2020 14:31:18 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1k9Ecp-0000vI-Fb for ietf-http-wg-dist@listhub.w3.org; Fri, 21 Aug 2020 21:31:03 +0000
Resent-Date: Fri, 21 Aug 2020 21:31:03 +0000
Resent-Message-Id: <E1k9Ecp-0000vI-Fb@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <tbray@textuality.com>) id 1k9Ecn-0000tq-Hs for ietf-http-wg@listhub.w3.org; Fri, 21 Aug 2020 21:31:01 +0000
Received: from mail-lj1-x22e.google.com ([2a00:1450:4864:20::22e]) by titan.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <tbray@textuality.com>) id 1k9Ecl-0002Z6-Iz for ietf-http-wg@w3.org; Fri, 21 Aug 2020 21:31:01 +0000
Received: by mail-lj1-x22e.google.com with SMTP id f26so3370871ljc.8 for <ietf-http-wg@w3.org>; Fri, 21 Aug 2020 14:30:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; 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; d=1e100.net; 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: <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> <20200821211151.GA25272@1wt.eu> <CAGd9gwij_G1ESFxj-Nw1HteXQE977QzpAi5+1H1miLWY=rC9sg@mail.gmail.com>
In-Reply-To: <CAGd9gwij_G1ESFxj-Nw1HteXQE977QzpAi5+1H1miLWY=rC9sg@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
Date: Fri, 21 Aug 2020 14:30:34 -0700
Message-ID: <CAHBU6itV0i7MYk4oRkkBS2ND=KT9SsSkKS3go2z07ga9A4Razg@mail.gmail.com>
To: Alex Deymo <deymo@google.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="00000000000023a9a105ad69f302"
Received-SPF: pass client-ip=2a00:1450:4864:20::22e; envelope-from=tbray@textuality.com; helo=mail-lj1-x22e.google.com
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: titan.w3.org 1k9Ecl-0002Z6-Iz 6db19a7b473326e2dcc81a696e511697
X-Original-To: ietf-http-wg@w3.org
Subject: Re: JPEG-XL as Content-Encoding?
Archived-At: <https://www.w3.org/mid/CAHBU6itV0i7MYk4oRkkBS2ND=KT9SsSkKS3go2z07ga9A4Razg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37952
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>

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