Linux.com

Though IM traces its own history back to 1987, when it was an internal tool developed at DuPont, the first public source code release was in 1990. The core package is a collection of roughly a dozen separate command-line tools: animate, compare, display, identify, mogrify, and so on.

Because its command-line interface exposes so much functionality, IM has long been employed in scripts and automated routines. It handles the server-side image manipulation duties in Web applications as diverse as personal photo galleries and Wikipedia. Over time, interfaces to many popular programming languages sprang up, opening up IM to programmers like a system library.

And in a sense, that was where the trouble began. IM is not a library -- it is a suite of discrete command-line executables. But as more and more programmers began to use IM through its language interfaces, library-like concerns crept in. Libraries have to worry about things like application binary interface (ABI) stability -- but interactive commands don't.

Several of the core IM developers who were more interested in the ABI stability question decided the answer was to make a fork of IM and start a new project that prioritized the ABI aspects and long-term stability above adding additional features. That project became GraphicsMagick, which split from ImageMagick in April 2003.

True to its word, GM has added far fewer features since its inception than IM has in the same timeframe. GM offers the same essential tools as IM -- IM has just added more options to them over the years.

To keep from overloading the commands supplied by IM, GM wraps them all into one command: gm. The names of the equivalent IM commands serve as the first argument to gm. For example, instead of running convert photograph.jpg photograph.tiff as you would with IM, you run gm convert photograph.jpg photograph.tiff.

Choices, choices ....

This decision on the GM team's part means that GM and IM can happily coexist on one system. So which do you use? The conventional wisdom is that you use IM for interactive tasks, and use GM in scripts or server-side installations. In fact, many third-party applications and frameworks that used to depend solely on IM now support GM as well -- examples include Gallery, Exhibit Engine, TYPO3, and RMagick.

But the truth is that you are highly unlikely to experience stability issues with ImageMagick in scripts or Web apps. The complaints leveled at IM during the high point of the IM-GM forking debate were that IM changed its syntax between successive releases. But how often are you going to upgrade the IM binary on a server? Not enough that the alleged ABI changes are going to bite you, particularly when you consider that 90% of IM usage is limited to pedestrian operations like resizing and scaling.

On the flip side, if you're wondering why you would ever need a command-line tool for manipulating graphics on an X-enabled PC, it's generally because the tool is the only option for some task none of the GUI image editors yet support, or as a time-saver for batch operations on very large files (particularly high-bit-depth images). I used to send digital images to a professional photo printer who demanded very specific settings for color space and embedded profiles, and in some cases converting the outgoing files to spec with IM was my only option in Linux. As great as the GIMP, Krita, and CinePaint are, support for new features and formats often makes it into IM first.

If you are developing an application or tool, take some time to pore over the language bindings for IM and for GM; availability of the right bindings on one but not the other would make the choice obvious. But unless you absolutely without-a-doubt need some new IM option not yet available in GM, the safe bet is to stick to GM's feature set, and write your app to work with either one.

In the past year, the development branch of GM has started adding more features, and new contributors to IM have focused their energy on stabilizing the suite's sometimes convoluted syntax, so the gulf between the packages may be narrowing. From a community standpoint, it is a shame to witness a less-than-amicable project fork, even when the technical reasons are real. I am not suggesting that we will someday see the IM and GM projects merge, but it is good to see that they can cross-pollinate and continue to learn from each other.

Share    Print    Comments