引自：http://co63oc.blog.51cto.com/904636/328997
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項目合並，但是希望美好地看到他們能像植物交叉授粉，繼續互相學習。