imagecache.module has a TODO comment about improving the quality of processed images. I think I know what usually causes the images to look fuzzy.

There is a problem with how imagecache_cache() works with multiple actions when using JPEG images. Each time a new action is applied, the image is being compressed with JPEG compression, which is a destructive one. (The image is altered in different ways to make the file size smaller.) So if you have for example two actions you get double the destructive effect of the JPEG compression. Three or four actions would probably suffer a great deal.

To solve this, you'd have to change the calls to the image_xxxx() functions (row 104 and on) so that they don't use the same target file name as the source, but rather use a non-destructive image format as an intermediate format while doing the processing. Example:

Instead of doing image_resize('image.jpg', 'image.jpg') and then image_crop('image.jpg', 'image.jpg') we should be doing image_resize('image.jpg', 'image.tif') and then image_crop('image.tif', 'image.jpg'). Or something similar to that.

I'm not sure how this would be best implemented, but I wanted to check if people think this is a good idea and worth working on.

Comments

quicksketch’s picture

quicksketch
he/him
commented

This should improve with imagecache running as a component of transformer (think imagecache 2.0 if you will). The entire method of saving to the disk in between steps is flawed. Rather, the image should be read once and kept in memory ($resource = imagecreatefromjpeg()). Then all the actions are performed on the image resource, then finally saved back as the original format. This would significantly reduce disk load while creating new thumbnails.

We should look into using this method in transformer (I haven't yet looked into it). In the mean time you could simply set your JPEG compression quality higher (the default is 75%, pretty mediocre) => /admin/settings/image-toolkit.

zoo33’s picture

zoo33 commented

Yes, that would be a lot better. However, you wouldn't be able to use Drupal's built-in image manipulation functions, and you wouldn't be able to respect the image library setting if the user has chosen Imagemagick for instance. It would be a GD only module, but I guess that's fine since most people (basically everyone) have that in their PHP installation.

Component as I understand it actually sounds like something that should be in core (image.inc). One common image manipulation library would be better than if every module implemented their own. But then you should also consider adding support for plugged-in image libraries such as Imagemagick, which will make everything less elegant... Anyway, a framework like that as a contributed module is a good start!

(I know I can change the quality setting, but if I use 85% for instance, two actions will give me images that look like 75% or so anyway...)

zoo33’s picture

zoo33 commented

Darn, wrote Component when I meant Transformer. Where did that come from? :)

I might have a closer look at Transformer, sounds interesting!

billmurphy’s picture

billmurphy commented

+1 on the idea. Thanks for your great work!!

dopry’s picture

dopry commented
Version: 5.x-1.x-dev » 6.x-2.x-dev
Status: Active » Closed (fixed)

This is done in HEAD.