WebP support for images

Im looking into adding WebP support for one of our customers inside litium. Currently we are running a custom implementation of IImageResizer were we use ImageMagick. I wanted to expand that, and thought, this should be easy, just indicate in my call that i want the output format to be image/webp. But looking into the code i see that WebP is not among the possible ImageFormat values inside litium, which means that i cannot get that as the input paramter to my image resizer. And since the result of the image resizer is cached, i cannot simply check the readers of a request to see if its supported and switch the format (which would also be dirrty to quote aguilera, since the image resizer should not know about any HttpContext).

My idea of attacking this issue is to take the bits on the stream from the image resizer and convert them again in a controller based on what DownloadControllerBase does. This would be ok since we have a cdn infront that will prevent us from doing conversions all day. But is there another approach i can take, which would require less custom code?

Litium version: 7.4

WebP is little tricky to handle, the reason is that the request is exposed as a regular link to to the image and depend on the headers in the request. The server is sending back different images. If image is cached without validating the header then also the visitors that can not use WebP will be served the WebP image.

If you use a service like Fastly, they have possibility to turn on Image Optimization that will handle this directly out on the edge nodes.

Thanks for the answer.

I think image transformation too expensive for something that can be solved with imagemagick and some headers, at least the last time i saw number on how much it would cost if you have lots of requests.

I ended up implementing my own controller based off the BlobDownloadController(i might be mistaking the name?), where i transform the StorageBlobInfo stream into a webp stream for webp supported requests. The caching issue was solved with a Vary header and some VCL in fastly to create a custom header to point the Vary header at.

1 Like

BlobDownloadController is the correct controller for all new files that are uploaded. If you are using an upgraded solution you may also override the StorageDowloadController to get the same behavior on the files that was uploaded before the upgrade was done.

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.