The jpegtran program is a command-line tool to perform lossless compression on images. It can be found here:
http://jpegclub.org/jpegtran/

In my experience with Yahoo's smush.it (which calls jpegtran), it compressed my ImageCache jpegs by upwards of 90%. This is a huge potential savings on size and image delivery.

This is a feature request to enhance this module to allow a jpegtran action to be carried out as part of the ImageCache preset. Basically the idea would be to call this as the last action before saving the resized image. That way all of the ImageCache images are optimized to be as small as possible.

Thanks for the consideration.

Comments

dman’s picture

dman commented
Project: ImageCache Actions » ImageCache
Version: 6.x-1.x-dev » 6.x-2.x-dev

Hm.
It'll make sense in some situations, but I know from experience that support for getting folk to install a commandline tool on their servers is a huge overhead.
It probably could be thrown out there as a "You're on your own with installation" sorta thing, but that doesn't go too well.

Also, it's a special process that lives outside of the imagecache pipeline. It may have to be factored in differently from the others. imageapi_gd holds the image in memory until the process is entirely finished, then the file gets saved.
A commandline process would have to happen AFTER that.

It could be done by saving mem to a temp file, processing it, loading, and carrying on ... BUT gd would then save it again using its own algorithm.
So... I don't think this can be applied as a pipeline action.

I'll bounce the suggestion over to imagecache.module. Even if there is a way, it would require at least a patch of some sort to imagecache itself.

rjbrown99’s picture

rjbrown99 commented

My thinking in this regard is that ImageMagick is a command-line tool as well and it is a supported option. I agree that the installation requirements may not be met by all of the people that use Imagecache or Imagecache Actions. Perhaps something along the lines of an admin setting "here's my path to jpegtran" and if it exists and is detected, then allow the action to be enabled. Or perhaps it could only be used with ImageMagick and not GD? I hadn't thought about GD simply because I use ImageMagick for the conversions.

At any rate, I was astounded at the fact that smush.it suggested a 90%+ saving in filesize with no loss of image quality. I achieved the same result by manually running jpegtran on my files so that seems to be a nice enhancement that could save both storage size on converted files as well as bandwidth to serve them up.

FWIW, I already solved the problem on my end by using the CDN Integration module with File Conveyor. It processes all of the graphics before uploading to the CDN. The local files are still 'big' but the ones on the CDN have been jpegtran'd and are much smaller. Given the issue queue I think I may be one of very few people to have done this so I thought this had a more broad applicability and utility to the ImageCache/IC Actions community. Of course, if it was in ImageCache itself I would save some money on storage of the original files.

rjbrown99’s picture

rjbrown99 commented

If you want to evaluate the potential savings on your own site, run the Firefox YSlow plugin, then navigate to the Yslow tools tab, then click the "All Smush.it" button. It will send all of your graphics on that page to Yahoo and it will tell you how much you would save. After running jpegtran on the files smush.it says you would have no further savings so that's how I concluded that jpegtran was really the key action to reduce the filesizes.

dman’s picture

dman commented

I have no doubt it's a useful tool, and as an optional extra that just works if available is fine too. That CDN approach makes sense. I think "Media Mover" had this in mind at one time too.
Compression is good, yes. I support the concept.

It's just this process sits outside of the imagecache pipeline, even for imageMagick.

GD: [open file] ( [action on data] [action on data] [action on data] ) [save file]
IM: [prepare queue] ( [queue action] [queue action] [queue action] ) [construct IM command] [run command]

Both create the new file in the last step.

See, you can't *currently* do anything in the ( [actions] ) phase that will make something happen *after* the end.
If this is to be done, it's going to require an approach from outside of what is currently possible in imagecache_actions - that I can see. Though others may have inspiration.

fizk’s picture

fizk commented
Status: Active » Closed (won't fix)
payalord’s picture

payalord commented

Check this project: Image Optimize
It is decision of this problem.