Re: JPEG-XL as Content-Encoding?

Alex Deymo <> Fri, 21 August 2020 12:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 07E8C3A08B3 for <>; Fri, 21 Aug 2020 05:05:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.498
X-Spam-Status: No, score=-10.498 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, 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 0wGGgpnGhdo4 for <>; Fri, 21 Aug 2020 05:05: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 567023A082D for <>; Fri, 21 Aug 2020 05:05:48 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1k95kM-0005DE-6p for; Fri, 21 Aug 2020 12:02:14 +0000
Resent-Date: Fri, 21 Aug 2020 12:02:14 +0000
Resent-Message-Id: <>
Received: from www-data by with local (Exim 4.92) (envelope-from <>) id 1k95kL-0005Ca-0W for; Fri, 21 Aug 2020 12:02:13 +0000
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1k95ix-0004qZ-LD for; Fri, 21 Aug 2020 12:00:47 +0000
Received: from ([2a00:1450:4864:20::62f]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1k95is-0007Wx-1H for; Fri, 21 Aug 2020 12:00:47 +0000
Received: by with SMTP id qc22so1980516ejb.4 for <>; Fri, 21 Aug 2020 05:00:41 -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:to; bh=jrx2YnHUKLmcmNFEQhhqd8R+zXLqxBWJ0E/LllkQomY=; b=CSmwulQCkQfJr3Z9BVYXqVyT5s3hVt+EEljnNNQhadzcDp8pGfzGIE3CJ4gcqVrIqX 3G7f07qI+2I6ZDsVZX71meWLa6KqWLJrb3ozBWMLFGRnidQ7VLrKPxP4vqaxcQ0xWGaA +5Vk4Pvvkh9FOooFcu+ME3myRGWEc5hCaYiadBwseMyAazFlZGrNaE4Kz/ngNeHuX+5R LBRH8PqCDDPvD2PtQSS0pOOwv6oNNCjilhb/IdJWzjLMxQ5/xgMJu4Vw5PtvKXz7gEb/ NuR7pziNKqFyBjFCgxf2f6O0hmnkQhwahTbmiYdRVeQyL0iFjR6U+b7XycPwc8BmjyhP CGmA==
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; bh=jrx2YnHUKLmcmNFEQhhqd8R+zXLqxBWJ0E/LllkQomY=; b=s8GkIbTah4pUlgSBtYncbLUWzopyPOeJ7sVPZXJQK/uP6g4NN8V+PZXc1u27pPy2GB 9PG+CEvYIDb0smk4br8VJUXo3vElW4UGU4Rb+LakXg52pLls+sON5z/rSHyCEjah28qb mH+W3gtFvtNqc+Q6qRey7CyIWXjZ/V+NjXVxIHj576L/7uO1qyk1acb6HzblJIlpiXxm 0Dgu7pbWyjXlLZidcSKKXyxwLETU7RLAkifwDSQkRsPt3EIJKg+487dIIobG1F91yWVL 7tkinbW6G/dSkp3q8ijmBJ3K29Ui0nsmhDZS66V5xzr2kD2D273MW8X+PJHkgx9P/cEl jLyQ==
X-Gm-Message-State: AOAM533OkvLawEMp6bAosTWPJfF95pnHIZJS8szWfXxJc71IQQojLyW1 8mcuNefQNp/cgxyvqtPdCYTWzGN2CebUXEliJuBgjPUGIoJbFw==
X-Google-Smtp-Source: ABdhPJx/pBdPiUx06nVQxdF5UPrRD4XPoj/rvOmAH+xN1guEo55REwUWFwatM7gAhc+OFZrED/ehRFh5uL5qvgLHRN4=
X-Received: by 2002:a17:906:3053:: with SMTP id d19mr967839ejd.190.1598011229907; Fri, 21 Aug 2020 05:00:29 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <20200820183008.GA8086@lubuntu> <> <>
In-Reply-To: <>
From: Alex Deymo <>
Date: Fri, 21 Aug 2020 14:00:18 +0200
Message-ID: <>
To: HTTP Working Group <>
Content-Type: multipart/alternative; boundary="000000000000b5247005ad61fbfc"
Received-SPF: pass client-ip=2a00:1450:4864:20::62f;;
X-W3C-Hub-Spam-Status: No, score=-16.6
X-W3C-Scan-Sig: 1k95is-0007Wx-1H 957e4588ef5070d9cfc8b18a72d69f7f
X-caa-id: 1f5bdc8f4f
Subject: Re: JPEG-XL as Content-Encoding?
Archived-At: <>
X-Mailing-List: <> archive/latest/37947
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

I'm Alex and I'm working in the JPEG XL project. The transcoding being
discussed for this is indeed the lossless recompression of JPEG files
feature in JXL.

JXL has many more features as a codec than what the lossless JPEG
recompression can offer, you would get a lot better compression density for
similar visual quality if you don't need to be able to reconstruct the
exact same original JPEG file (or if your original was not a JPEG to start
with but RAW data from a camera), so it makes a lot of sense to add jxl as
an image codec on its own.

However, on top of that, the lossless recompression of JPEG files allows
you to get this ~20% gain for existing files. When you deploy a new lossy
codec there is the question of what to do with the existing images. If you
have a website with photos and want to convert your already lossy JPEG
files to a new codec to save storage and bandwidth and you decide to decode
them to pixels and encode them back to the new format you will end up with
more artifacts or worse compression density trying to accurately represent
the JPEG artifacts in the new codec, whatever the codec is. It's
impractical to do this lossy transcoding to a new codec at large scale on
existing images, each application would need to evaluate whether they want
to do this for existing images. This story is different if you start with a
large and high quality image (like a JPEG from a camera) and want to encode
in a smaller form for the web, since there you already have a high quality

Instead, using jxl lossless recompression of JPEG files as content-encoding
gets you this ~20% benefit for existing files at large scale since you only
need browser support and webserver or intermediary support; you don't need
applications to evaluate whether the new codec fits their needs or if the
new kind of artifacts of a new codec are suitable for their use case. Think
about the JS developer who uses the hash of the file as a key somewhere and
needs to do some work to update their app to a new codec while still deal
with browsers that don't support the new codec. A CDN could decide to
deliver JPEG files encoded with the lossless recompression feature to
supporting browsers and take advantage of these gains today even if the
codec is not widely supported at the beginning like we see with many new
codecs without needing to modify the web application .

Regarding compatibility with browsers that don't support the
content-encoding and how to decide when to use the encoding, I personally
think that a reasonable way to implement that would be that for static
content you store the file already encoded with JXL to save that ~20% on
storage and decode it at serving time to browsers that don't support it,
and for dynamic content encode on the fly, however this would depend on the
cost model of the server/CDN.

I think the only shocking thing about a content-encoding for JPEGs is that
it can't encode any arbitrary file only JPEGs, but if you look at "general
purpose" compressors like Brotli they still can't compress to a smaller
file every file; many binary files that are already compressed like .zip or
even a JPEG files (unless they have a large ICC) won't compress to a
smaller file so you just don't do it even if Brotli is able to compress
them to a ~similar size file.

Let us know if you have any questions. We are happy to discuss ways to