Re: JPEG-XL as Content-Encoding?

On Thu, Aug 20, 2020 at 8:33 PM Dmitri Tikhonov <dtikhonov@litespeedtech.com>
wrote:

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

Yeah, this is what I referred to as "exposing JPXL as an image format", and
the way we typically ship new formats (e.g. webp).


>
>   - Dmitri.
>
>
>