The "format" parameter, caching and file extensions

[roderik]

For the KunstmaanBundlesCMS we lean heavily on the LiipImagineBundle for everything image related. But we are currently locked on v0.20.2 because at some point the "format" parameter disappeared. I noticed it's back now in the latest 1.2.x releases, including awesome features we want like postprocessing and interlacing. Our WIP pull request to update with our configs etc can be found here

I've tried upgrading and have gotten it up and running, but i'm running into a small issue. I contacted @lsmith77 on twitter but this deserves a longer format.

Scenario:

A user uploads an image file in the admin interface of the CMS. This image could be anything ranging from an optimised jpg to a huge png, bmp, we have even seen 1200dpi tiffs...

In the frontend we pull everything through imagine filters to optimise and resize them. We have three default filters to get people started, an "optimjpg" filter that converts to a jpg file, an "optimpng" that does the same to png, and one "optim" that keeps the format.

Let's say the user uploads a png file and we run it though the "optimjpg" filter. The image get's converted, optimised and cached, but while the content is a jpg, the URL in the cache still has a .png. While most browsers handle this gracefully, it's not like it should be.

Question:

In v0.20.0 you could add the "formats" parameter and get the behaviour where the uploaded png was cached as jpg.

Upgrading is a must for us, but this is blocking it for now. What's the correct way to get this fixed? Do we need to configure something different, or do we need a custom cache implementation, or... ?

[makasim]

The format conversion on the fly looks strange to me. The origin path is used as an identity and an extension part too. You want to modify it but it changes the origin image id. And we have to find out how to map cached image to its origin. Things can become too complicated. Changing formats to guess origin image is a dangerous way.

Also what about images stored in database or on s3. The origin image may not have an extension at all!.

The most simplest solution is to convert the origin image on upload before you actually stored it to an internal format, let say jpeg, and then you can apply filters\post processing to that image.

[roderik]

Converting on upload is not an option, since we use an "image library" concept one image can be used in lots of ways, each requiring the best format for their use. e.g. use the high res PNG version in a PDF generator, but a low res jpg on a page.

Since the cache resolver redirects to the cached image that is served through the webserver (apache/nginx), and the webserver uses the extension to set the content type. Unless every file is always served via a controller, there is no way to override this.

Other option i see are:

• generating all formats you want in a site on upload (so test.png would actually have an jpg alternative) <- more diskspace
• doing something with url parameters: /cache/test.jpg?origin=test.png <- most acceptable i think?

[roderik]

Btw, found this issue that touched on the subject from a few years ago: #231

[roderik]

I made a little, very dirty proof of concept:

I know my problem exist if you are using a normal filesystem, and serve the cached files via a webserver without going through a controller to add logic. So i used WebPathResolver to fix the storing and resolving.

Since there was no way to get generateUrl() in CacheManager delegated somewhere where it's correct, i fixed it up there. Maybe this can also delegate to the Resolver?

I also quick hacked the $formats array, this should go back to the config in a real pull request.

Apart from the dirty hacks, is it discussable to get this back in? Or at least delegate the generateUrl() method to somewhere where i can put in my own implementation (ps. did not check if i can switch out the CacheManager)

[makasim]

I believe you can change an extension in the post resolve listener.

https://github.com/liip/LiipImagineBundle/blob/master/ImagineEvents.php

Could you try it out?

[lsmith77]

One thing to note here, CDN/browser sometimes act stupidly with images and GET parameters

[Bukashk0zzz]

So, what the best solution for now? We also have politics that one image can be used in lots of ways.

Maybe add new filter "convert" or similar to config not bad idea?

[makasim]

planned for 2.0 #686

[christianbaer]

@roderik did you find any solution yet? How to convert images in 1er-Version?

[robfrawley]

@christianbaer I do not know of a solution for 1.x It is on the currently active 2.x roadmap: https://github.com/liip/LiipImagineBundle/projects/1