Re: JPEG-XL as Content-Encoding?

[Alex Deymo <[e-mail]>]

Hi,
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
file.

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