JPEG-XL as Content-Encoding?

Hey HTTPers!

I was reviewing an intent to add JPEG-XL as a content-encoding
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
      - 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 :)

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