图片裁剪，如果你想批量生成缩略图的时候，用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
重新编译后正常.
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项目合并，但是希望美好地看到他们能像植物交叉授粉，继续互相学习。
4488
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
