Re: JPEG-XL as Content-Encoding?

On Thu, Aug 20, 2020 at 5:14 PM Willy Tarreau <w@1wt.eu> wrote:

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

I should've made that point clearer - JPEG-XL (in legacy mode, which is
what's discussed for Content-Encoding) can be losslessly transformed to
JPEG and vice-versa.


>
> Just my two cents,
> Willy
>