Back-porting the ImageMagick Drupal 7 Module
David Wilcox
different switches to be used for different Solution Packs, etc. This
makes it a pain to revise any existing commands because it's difficult
to track them all down and update them accordingly. It also leads to
image display inconsistencies across Islandora.
The advantages of containing the code within a module and just writing
dependancies to it are obvious. It may also push us one step close to
leveraging the use of Imagecache for derivative jpegs.
There is already a module in Drupal 7 that works very well with
ImageMagick & GraphicsMagick (3.2x faster than IM); it has good error
reporting, and it's very easy to use as a dependancy for exec calls to
IM within your own module (as a plus, it also works well with
Imagecache): http://drupal.org/project/imagemagick.
However, this module would need a back-ported to Drupal 6 for the
current version of Islandora. Does anyone in the Islandora developer
community have any thoughts on this? Is anyone interested in
back-porting the module to Drupal 6?
--
David Wilcox, BA, MLIS
Islandora Training/Support Coordinator
Robertson Library
University of Prince Edward Island
dwi...@upei.ca
Skype Name: david.wilcox82
902.620.5167
Daniel Yule
I had a look at the ImageMagick Module, and a backport looks pretty straightforward. There is very little in the way of Drupal 7 specific code (my cursory overview only found one function call -- which appeared fairly frequently-- which needed to be changed, but there could be other pieces as well.
However, it looks like the functionality you're looking for (generalized access to image manipulation) is available in the Drupal 7 Core (in the include file image.inc). All that the contributed module does is allow for use of ImageMagick as the toolkit in use for the image api.
However, in Drupal 6, the situation is different. The image manipulation was not in the core, so a contributed module (called ImageAPI by the same developer as the ImageMagick module) provides the same functionality, but most likely has a different interface. I suspect that the codebase for image manipulation between Islandora for Drupal 7 and Islandora for Drupal 6 will either have to be custom built for Islandora, and thus have a consistent interface across versions or else can use the Image module in the Drupal 7 core for Drupal 7 and continue current practices for Drupal 6.
At any rate, I haven't any time this week, but next week I would be interested in backporting some modules if you're looking for someone to take it on.
Daniel Yule
Web Developer II
Geoffrey R Weller Library
University of Northern British Columbia
Paul Pound
* thumbnails (from pdfs, jpegs, tiffs)
* derivitive sized jpegs
* compression & colorspace changes
* possible conversion to jpeg2000
Do you think it would be feasible to port the imagemagick module to drupal 6 and update it to call graphicsmagick instead of imagemagick (and fallback to im when gm is not supported). The actual calls to graphicsmagick are almost identical to the calls we would have to make to imagemagick.
Whatever solution we come up with we would eventually have to use in Drupal 7 as well.
Thanks,
Paul
Daniel Yule
Hi Paul,
I did a bit more research (including actually reading some of the code in Islandora that interacts with ImageMagick) and what I discovered is the following:
The functionality of the core module that David linked to (the ImageMagick module) is no different from the ImageAPI module, which Islandora for Drupal 6 is dependent on, with the small exception that it adds an option for using GraphicsMagick to the configuration interface. In particular, it supports the functions found on drupal’s page for image.inc .
However, the ImageMagick module ALSO ships with a so-called ‘advanced’ module, which adds support for some of the features you mention. The manner in which it does this is by adding more fields to the configuration page (items like color spaces and color profiles). Then, any image processed using the toolkit uses these settings. This means you can’t programmatically select which options you want to use at what time, you must use the same global settings for all images. Being not overly familiar with the image solution packs, I can’t say if that’s acceptable or not.
My two suggestion then (and I am willing to put work into either one) is to either backport the ImageMagick Module, both its core and advanced components to work with ImageAPI or to create your own image manipulation module that completely provides all of the services you need. Each has advantages and disadvantages.
If we backport the existing module, you’ll be able to use almost the same code for Drupal 6 and Drupal 7 (calls are prefixed with ‘imagepi’ for Drupal 6 and ‘image’ for Drupal 7), and it will be considerably less work. In addition, you’ll be using a supported module, which means that you won’t have to support it yourself. The downside is that if you want to add some functionality that isn’t exposed through the existing api, you’re pretty much stuck. You could write some custom functions to extend its functionality, but then you’ve lost the advantages of using a supported module, and in Drupal 7 you’re not working with the existing api.
If we write our own module then you have whatever flexibility you like in terms of functionality. The downside, of course, is that you have to support it yourself. This is probably the best approach. In fact, it’s possible that you don’t even need a drupal module, and what you need instead is a php imagemagick library. I had a look at phMagick, and it looks pretty ideal. It is basically a wrapper around command line imagemagick calls, which means it should be able to use graphicsmagick just as easily, since the parameters are the same.
Let me know what conclusions you all come to. I am also available to chat on Skype if you’re all interested in that.
