Re: JPEG-XL as Content-Encoding?

Hi Yoav,

On Thu, Aug 20, 2020 at 04:11:54PM +0200, Yoav Weiss wrote:
> 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!

Well, I don't know about this JPEG-XL but I'd argue that one very
important aspect of the content-coding is that it must absolutely
be possible to recover the original data by applying the inverse
transformation, as it's not supposed to transform the content but
only its representation. And intermediary might want to cache such
contents and use them to deliver the original image to clients not
compatible with this format, just as can be done with compressed
contents for example. I have no idea if this is the case here.
Otherwise I don't see how it could qualify as a content-encoding.

Just my two cents,
Willy

Received on Thursday, 20 August 2020 15:14:16 UTC