image optimizer standalone
kentr - November 10, 2009 - 01:24
| Project: | CDN integration |
| Version: | 6.x-1.x-dev |
| Component: | Miscellaneous |
| Category: | support request |
| Priority: | minor |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Description
GitHub is having performance issues and won't let me even create an account. This is kinda drupal related anyway...
Does the image optimizer portion of file conveyor work as a standalone that can be used with imageapi for imagecache presets? I've been wanting to work up a smush.it like engine general drupal image uploads.

#1
More what I mean is: does it exist as an independent entity within the file conveyor package that could be repackaged to serve as a library for this functionality in calls from whatever imageapi module?
#2
Yes, that's perfectly possible.
All the truly required code is in this file: http://github.com/wimleers/fileconveyor/blob/master/code/processors/imag.... You could still use the daemon, but you could also just write a wrapper around that code, or a stand-alone daemon. There are many possible approaches to that.
Do you want a daemon to check for newly created images or do you want ImageAPI to call the image optimizer directly?
#3
I'm thinking ImageAPI direct call because it would be easier for the average Drupal user to install a regular Drupal module on a shared server (compared to a daemon) and would only run when required - when an image is uploaded. Of course, it wouldn't operate on FTP'd images this way, but I'm thinking simple use case where the theme graphics and other FTP'd images would remain pretty static and the only frequently added images would be uploaded via the standard Drupal file upload interfaces.
What do you think?
But a component I may be missing is the installation of the program itself. I (obviously) haven't looked at it, so apologies. I suppose it would have to be compiled for the specific machine. Does your code do this upon install?
#4
What you're saying makes sense.
It's indeed necessary to compile the image tools that are used (which I didn't write by the way, if that wasn't clear yet) it for a specific OS+CPU architecture combination. That can't be avoided obviously. Truly simple it would never be (although you could get it all transparent if you would write PHP code to detect the environment and then download the necessary files).
File Conveyor doesn't install them automatically. The user must install them. I do provide instructions though:
http://github.com/wimleers/fileconveyor/blob/master/code/INSTALL.txt.
Processor module: image_optimizer
---------------------------------
You only have to install these libraries if you don't have them already. This
processor only works on UNIX, at least for now.
- imagemagick
* homepage: http://imagemagick.org
* instructions:
- Debian/Ubuntu: already installed
- Other:
1. download the binary release from http://imagemagick.org/script/binary-releases.php
2. copy the executables from the "bin" directory to a directory that is referenced by $PATH
- pngcrush
* homepage: http://pmt.sourceforge.net/pngcrush/
* instructions:
- Debian/Ubuntu: sudo apt-get install pngcrush
- Other:
1. download the source
2. make
3. copy the executable into a directory that is referenced by $PATH
- jpegtran
* homepage: http://jpegclub.org/
* instructions: http://www.phpied.com/installing-jpegtran-mac-unix-linux/
- gifsicle
* homepage: http://www.lcdf.org/gifsicle/
* instructions:
- Debian/Ubuntu: sudo apt-get install gifsicle
- Other:
1. download the source
2. ./configure
3. make
4. make install
#5
Ok, cool. I suspected you were using these. I think I followed in your footsteps, taking the clues off the Smush.it FAQ about what utilities they were using and proceeding to install them on my own box :D.
Thanks for the feedback.
Knowing from personal experience that the process of compiling can be a bit daunting, I think it would be really cool to get some sort of facilitated install process, like a script that downloads & compiles them (example: for users on shared servers who don't have root access). Do you think this is feasible, or a can of worms?
#6
I'm no expert on this, but knowing that Ubuntu, Debian and Redhat are the most frequently used OSes for web servers, it sounds doable to at least support those. But then again, gcc won't be installed on every webserver. I'm sure it would be appreciated by many though :)
It *could* turn out to be a can of worms though …