圖片裁剪，如果你想批量生成縮略圖的時候，用ImageMagick/GraphicsMagick是非常方便的：

convert -resize 100x80 ? sample.jpg ? ?thumb.jpg

這樣一句命令，就可以把圖片裁剪為寬度不超過100px，高度不超過80px的縮略圖，但是，有時候，我們的頁面顯示需求是必須嚴格生成大小為 100x80的圖片，超過的部分希望裁剪掉。

ImageMagick 6.3.8以上的版本支持 參數寫成 widthXheight^，這樣的格式，命令：

convert -resize 100x80^ -gravity Center -crop 100x80+0+0 ? ? sample.jpg ? ?thumb.jpg

gravity 表示中心坐標，可選值為 Center , NorthWest(左上), NorthEast(右上), SouthWest(左下), SouthEast(右下) ，由Center參數即由中心開始向兩邊裁剪，+指定x軸向y軸向的偏移量。

這樣就可以了。有時候我們的系統ImageMagick是 6.3.7的，而且不好升級，那么可以安裝一個 GraphicsMagick，命令前加上 gm 其他完全一樣調用，GraphicsMagick的處理速度比ImageMagick還要快，而且bug更少。

gm ? convert -resize 100x80^ ? -gravity Center -crop 100x80+0+0 ? ? sample.jpg ? ?thumb.jpg

現在來一個批量生成縮略圖的shell腳本吧！，遍歷目錄下的 jpg圖片，生成到同目錄下，目錄結構不變，文件xxx.jpg生成當前目錄下的 xxx-thumb.jpg，如果有其他需求可自行修改，比如生成的文件需要覆蓋當前文件，則只需要使輸入輸出的文件名變量一樣即可。

?find . -iname "*.jpg" -type f | while read img ; do
? ? ? ? new_img=$(basename $img)
? ? ? ? ext=${new_img##*.} ? ? ? ?# 擴展名
? ? ? ? d=$(dirname $new_img) ? ?# 獲取目錄名
? ? ? ? new_img=$d/${new_img%.*}-thumb.$ext ?# 保存的名字為 xxx-thumb.jpg
? ? ? ? echo -n "Start converting $img ..."
? ? ? ? gm convert -size 120X80 -resize 160X150^ -gravity Center -crop 120x80+0+0 ?$img ?$new_img
? ? ? ? echo "...done" ;
? ? done

GraphicsMagick

當前穩定版本：1.3.12(發布日期2010-03-08)

簡單介紹：

GraphicsMagick號稱圖像處理領域的瑞士軍刀。 短小精悍的代碼卻提供了一個魯棒、高效的工具和庫集合，來處理圖像的讀取、寫入和操作，支持超過88中圖像格式，包括重要的DPX、GIF、JPEG、JPEG-2000、PNG、PDF、PNM和TIFF。

通過使用OpenMP可是利用多線程進行圖片處理，增強了通過擴展CPU提高處理能力。

GraphicsMagick可以再絕大多數的平臺上使用，Linux、Mac、Windows都沒有問題。

GraphicsMagick支持大圖片的處理，并且已經做過GB級別的圖像處理實驗。GraphicsMagick能夠動態的生成圖片，特別適用于互聯網的應用。可以用來處理調整尺寸、旋轉、加亮、顏色調整、增加特效等方面。GaphicsMagick不僅支持命令行的模式，同時也支持C、C++、Perl、PHP、Tcl、Ruby等的調用。事實上，GraphicsMagick是從?ImageMagick?5.5.2 分支出來的，但是現在他變得更穩定和優秀，下面就是兩個之間的一些比較。

GM更有效率（測評），能更快的完成處理工作

GM更小更容易安裝

GM已經被Flickr和Etsy使用，每天處理百萬計的圖片

GM與已經安裝的軟件不會發生沖突

GM幾乎沒有安全問題

GM的手冊非常豐富

…(無關痛癢的正確的廢話)

如何安裝：

GraphicsMagick可以使用源碼安裝在任何現代的Unix機器（Linux和MacOS X)和Windows上，這里只介紹Linux下的安裝，其他的安裝還需要參看這里。

下載 .tar.gz 的源碼包，進行解壓

tar -xvzf GraphicsMagick-1.3.12.tar.gz

解壓后，原來在的gz文件就變成了tar文件，進入文件夾

cd GraphicsMagick-1.3.12

安裝之前，因為是圖片處理，所以需要系統中安裝了libpng和libjpeg的開發包，否則的話不會安裝這兩種文件的支持。

使用 configure 來進行自動的配置、build和安裝

./configure

當然，可以通過 –prefix=PATH 來指定參數，還可以指定其他編譯時的變量，這里使用了一個經過測試的 configure 配置，同時添加了 enable-sybol-prefix ，這樣就避免了和系統中已有的 ImageMagick 的沖突，下面是完成的配置參數：

./configure? '--build=i686-redhat-linux-gnu' '--host=i686-redhat-linux-gnu' '--target=i386-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr/local/sinasrv2' '--exec-prefix=/usr/local/sinasrv2' '--bindir=/usr/local/sinasrv2/bin' '--sbindir=/usr/local/sinasrv2/sbin' '--sysconfdir=/usr/local/sinasrv2/etc' '--datadir=/usr/local/sinasrv2/share' '--includedir=/usr/local/sinasrv2/include' '--libdir=/usr/local/sinasrv2/lib' '--libexecdir=/usr/local/sinasrv2/libexec' '--localstatedir=/usr/local/sinasrv2/var' '--sharedstatedir=/usr/local/sinasrv2/share/com' '--mandir=/usr/local/sinasrv2/share/man' '--infodir=/usr/local/sinasrv2/share/info' '--enable-libtool-verbose' '--with-included-ltdl' '--enable-shared' '--disable-static' '--with-modules' '--with-frozenpaths' '--without-perl' '--without-magick-plus-plus' '--with-quantum-depth=8' --enable-symbol-prefix

接下來就是安裝

make

make install

安裝gmaick：

安裝GraphicsMagick后，還需要安裝gmaick才能在PHP中使用，首先從PECL的網站上下載安裝包。然后解壓縮，進入到gmaick的目錄中

cd gmagick-1.0.7b1?

然后運行phpize

/usr/local/php/bin/phpize

完成后執行安裝過程

./configure --with-php-config=/usr/local/sinasrv2/bin/php-config? --with-gmagick=/usr/local/sinasrv2/

make

make install

在php.ini打開擴展后，重啟apache就可以使用了

與magickwand的比較：

本文使用了20個大小不同的圖片文件，分別使用gmagick和magickwand來完成打開圖片、讀取圖片信息、關閉圖片的操作，最后得出的結果如下：

? 總體上看，magickwand的效率要比GraphicsMagick差不少，但是效率的提升貌似與所處理的文件沒有明顯的線性關系，也許是圖片太小了，據說GraphicsMagick可以處理Gb級的圖片，更多的使用細節，只能在今后進一步研究了。

解決GraphicsMagick 和 ImageMagick沖突(PHP imagick and gmagick extension)

發現PHP imagick or magickwand無法正確加載. 經過測試發現是由于和gmagick沖突. 解決, 在編譯GraphicsMagick時候加入:

–enable-symbol-prefix

重新編譯后正常.

December 2, 2009 | Filed Under?PHP,?Technotes

Comments

2 Responses to “解決GraphicsMagick 和 ImageMagick沖突(PHP imagick and gmagick extension)”

Neekey on January 21st, 2011 10:31 pm

最近需要使用PHP的圖像庫 做一個在線照片處理的應用（做一些風格效果），PHP提供了幾個庫：EXIF, GD, ImageMagick, Gmagick, Cairo

請問哪個更適合呢？

nightsailer?on February 7th, 2011 1:30 pm

除了第一個和最后一個，中間都可以。GD大多數支持PHP的站點都內置。如果是自己的環境，可以考慮IM或GM。Cairo不適合做圖片處理，Exif只是讀取信息。

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項目合并，但是希望美好地看到他們能像植物交叉授粉，繼續互相學習。

總結

以上是生活随笔為你收集整理的ImageMagick/GraphicsMagick 图片裁剪为固定大小缩略图的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。