ImageMagick or GraphicsMagick?
Nathan Willis 七月三日，2007年

ImageMagick(IM) 套装包含的命令行图形工具是一主要自由软件；Linux，其他类Unix操作系统，专有的操作系统像Windows支持IM差不多两个十年。但还是存在一个选择，称为GraphicsMagick(GM)，覆盖了大多数一样的功能。那你怎么知道哪一个是适合你的？

虽然IM把它的历史回到1987年，当它是一个内部的工具的时候，在 DuPont被开发，第一次公共的源代码发布是1990年。核心包是一系列分离的命令行的集合：animate，compare，display，identify，mogrify等等。

因为它的命令行接口暴露了这么些功能，IM有一段长时间被用在脚本，自动化处理。它处理服务器端图片操作，在web应用程序，像个人图片库，wikipedia一样变化。随着时间过去，接口支持许多流行的语言，把IM开放给程序员，像一个系统库。

从这些了解，问题开始了。IM并不是一个库—它是一套不连续的命令行执行程序。但是越来越多的编程者开始使用IM通过它的语言接口，库的概念逐渐进入。库需要考虑事情，比如应用程序二进制接口(ABI)，它的稳定性--但是交互的命令不需要。

多个核心IM开发者，对ABI的稳定性问题更感兴趣，产生的结果是有一个IM的分支，开始一个新的项目，提高优先级，在ABI方面和长期的稳定性上，相对增加新的特征而言。这个项目变为 GraphicsMagick，在2003年4月从 ImageMagick分离出来。

确实如它所说，GM增加了较少的特征，从它最初开始，相比IM同样的时间线上。GM提供了同样的重要的工具，在IM中的--IM只是在这些年增加了更多选项。

为了不覆盖IM提供的命令，GM封装所有的命令为一个：gm。同样的IM的名字作为它的第一个参数。例如，在IM用 convert photograph.jpg photograph.tiff，在GM中用 gm convert photograph.jpg photograph.tiff。

选择，选择...

这个决定在GM小组中意味GM和IM能友好地在一个系统中共存。所以你要使用哪一个？明智的做法是你使用IM处理交互任务，使用GM在脚本或服务器端安装。事实上，许多第三方应用和框架习惯只依赖IM的现在也支持GM—例子包含Gallery，Exhibit Engine，TYPO3，和RMagick。

但是实际上你并不喜欢体验ImageMagick的稳定性问题，在脚本或Web应用中。这些抱怨升级，在IM-GM产生的争论中，IM改变它的语法在成功发布的版本中。但是你要多经常去更新IM程序，在一个服务器上？ABI改变对你有些影响这还不够，特别地，当你考虑到90%的IM使用是限制在呆板的操作，像改变大小和比例。

在另一方面，如果你考虑你可能需要一个命令行工具操作图形，在X图形PC上，通常因为工具是一个选择，而GUI的图形编辑器并不支持，或者作为批处理节省时间的因素，在非常大的文件(特别高位深图片)。我常常发送数字图片给专业图片打印机，它需要特别设置颜色空间和嵌入的配置，在一些情况下，Linux下用IM转换文件给机器是唯一的选择。像GIMP，Krita，CinePaint支持的新的特征和格式经常是首先发送给IM。
如果你正在开发一个应用或工具，花一些时间去熟悉语言绑定，对于IM和GM；合适的绑定可能在其中一个，这样选择就明显了。除非你绝对不怀疑需要一些新的IM选项，而GM中无效，安全的投注是针对GM的特征集，并让你的应用可以和任何一个一起工作。

在过去一些年，GM的开发分支开始增加一些新的特征，IM的新的贡献者的注意力集中在稳定套件的语法，所以包之间的区别是狭小的。站在一个社区点的位置，是不想看到一个不友善的项目产生，即使是技术的原因。我并不建议某一天IM和GM项目合并，但是希望美好地看到他们能像植物交叉授粉，继续互相学习。