Re: JPEG-XL as Content-Encoding?

Hello Yoav, Willy:

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

I agree that this would be strange.

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

The transformation cost can be amortized over time by using a file
cache in the web server.

On Thu, Aug 20, 2020 at 05:14:01PM +0200, Willy Tarreau wrote:
> 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 subscribe here as well.  In my mind, the way to switch the response
from JPEG to JPXL is as follows:

    Request:

        GET /image.jpg
        Accept: image/jpxl

    Response:

        OK...
        Content-Type: image/jpxl
        Vary: accept

If 'Accept' does not specify image/jpxl, the server returns the original
JPEG image.  Note that there is still the white lie of the image's .jpg
extension, but this lie is smaller than the much more elaborate dance
with the Content-Encoding.

  - Dmitri.

Received on Thursday, 20 August 2020 18:30:39 UTC