Re: JPEG-XL as Content-Encoding?

Hi Yoav,

My personal .02 - 

The Intent to Prototype starts with the phrase 'JPEG XL is a next generation image format.' From the discussion, it seems like this is indeed a new format, and not a content encoding. If the proponents think that it will somehow ease the transition, that doesn't seem likely; it's more likely that they'll avoid well-understood problems introduced by format negotiation with brand-new problems related to format-specific content encoding. 

Just register a media type (or make it backwards-compatible to existing JPEGs).

Cheers,


> On 21 Aug 2020, at 12:11 am, Yoav Weiss <yoav@yoav.ws> wrote:
> 
> 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 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!
> 
> Cheers :)
> Yoav

--
Mark Nottingham   https://www.mnot.net/

Received on Monday, 24 August 2020 00:04:51 UTC