ggvaidya has asked for the wisdom of the Perl Monks concerning the following question:

Greetings fellow monks,

On my current project, we need to be able to accept a number of image formats from our users. The easiest way to achieve this is by using Image::Magick, which handles a very large number of input formats, and using it to convert the input file into a standard image format, such as LosslessJPEG.

The Image::Magick module is a very straightforward wrapper around the ImageMagick library, because of which it has lots of C-isms (not having thrown exceptions, methods returning complicated numbered error messages, and so on) as well as ImageMagick's own limitations (returning descriptive names instead of standard MIME types, for instance).

I've got two questions:

  1. Is ImageMagick still the best library for image conversion on Windows in Perl? Are there better libraries out there which I haven't heard about?
  2. Since I am going to be collating all my Image::Magick fixes into one module anyway, does it make sense to package this into an Image::Magick::Image module, which will encapsulate a single ImageMagick image? This module can then provide exceptions on input/output methods, make it easier to access image attributes, and generally fix up ImageMagick's more irritating warts. Do you think there is a need for such a module? Would it be worth the effort of packaging it for CPAN?

Thanks for your help!

Update: Removed reference to Image::Magick being procedural; this was just plain wrong. Thanks, mirod!

Update Oct 24, 2008: Matt Trout recommended that I use Image::Magick::Object (or my own variant on his suggestion, Image::Magick::Wrapper) as an overall package name. Individual images can then be wrapped by Image::Magick::Wrapper::Image, and we could wrap other IM objects as well - a path could be Image::Magick::Wrapper::Path, for instance. Much easier to extend functionality that way. My only worry is that names will get overly complicated. Any comments/suggestions?

Update Oct 24, 2008: It's going to take a couple of weeks at least to get my very small codebase released to CPAN. I've only got about three operations wrapped so far: Read(), Write(), and converting some of Image::Magick's inbuilt format names to standard MIME types. If anybody else feels like going ahead with this, please do! Otherwise, I'll make good my promise and make sure I get a very early release sometime in November. Once it's out under a good license, interested parties can get cracking on wrapping all of Image::Magick.

Replies are listed 'Best First'.
Re: Image::Magick: Still the best? Can it be improved?
by mirod (Canon) on Oct 13, 2008 at 07:07 UTC

    I would say "go for it". See Crap is Gold for the long version of why.

    You could also try working with the author of Image::Magick to improve the module, but I am not sure that's possible, depending on the extent of the changes you want to make. You be the judge of whether that's possible. BTW I don't quite understand your remark about Image::Magick being procedural. It is object-oriented.

      I think changes to Image::Magick would be a bad idea. It perfectly mirrors the ImageMagick library, making it very easy to pick up if you're already familiar with the API. Starting a new module will let people who want the usual Image::Magick semantics to use them, and those who want a simpler system to use Image::Magick::Image.

      I was really thinking of CGI::Simple when I posted this question - I can't imagine using anything other than, but people who don't want to have to learn's idiosyncracies will definitely appreciate CGI::Simple.

      You're right, it is object-oriented! I think of Image::Magick as procedural because everything is run by the same object - Image::Magick->Read() returns a new Image::Magick object; all Image::Magick methods can be applied to either to the images or the library itself. Arguably, though, there aren't any other objects you might want to call anyway - I'll correct the question now.

      Thanks for the encouragement, and the link to the presentation; I'd never seen it before, and it's very insightful.