W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2020

JPEG-XL as Content-Encoding?

From: Yoav Weiss <yoav@yoav.ws>
Date: Thu, 20 Aug 2020 16:11:54 +0200
Message-ID: <CACj=BEjdwH1OtS=uQXsgPN3XVJvVEUeisjeF5_iro1vg0omqWQ@mail.gmail.com>
To: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Hey HTTPers!

I was reviewing an intent to add JPEG-XL as a content-encoding
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACZPrBjS75%3D%2B%3DSexFkJ7ewkBXDOF6FhkpwQYBeWn6sT57n1-_w%40mail.gmail.com?utm_medium=email&utm_source=footer>
for JPEG images, and thought I'd get some feedback from y'all regarding it.

The team behind JPEG-XL think that since it can be used to
seamlessly transform JPEGs, it might be interesting to enable that
transformation to happen at the HTTP layer and get ~20% smaller images
*automagically*, as compression would be done by supporting web servers and
image compression providers.

I'm slightly more skeptical about how automatic that would be, and find it
somewhat strange to have image-specific content-encoding, while other image
formats are served as separate mime types and negotiated with `Accept`.

So, a few questions:

   - Would it make sense to have an image specific content-encoding?
   - Are web servers more likely to perform JPEG=>JPXL transformations if
   JPXL is a content encoding, compared to browser support for it as an image
   format?
      - Note that those transformations are CPU heavy, so will need to be
      cached, or done at "build" time.
   - Same question for CDNs
   - Finally for CDNs who already transform images - have you run into
   compatibility issues coming from web content manipulating raw image bytes
   directly, and failing to do that post-transformation?

I'd highly appreciate y'all's opinions!

Cheers :)
Yoav
Received on Thursday, 20 August 2020 14:12:26 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 20 August 2020 14:12:29 UTC