ImageMagick/GraphicsMagick 图片裁剪为固定大小缩略图

图片裁剪,如果你想批量生成缩略图的时候,用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就可以使用了

ImageMagick/GraphicsMagick 图片裁剪为固定大小缩略图_第1张图片

与magickwand的比较

本文使用了20个大小不同的图片文件,分别使用gmagick和magickwand来完成打开图片、读取图片信息、关闭图片的操作,最后得出的结果如下:

ImageMagick/GraphicsMagick 图片裁剪为固定大小缩略图_第2张图片  总体上看,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)”

  1. Neekey on January 21st, 2011 10:31 pm

    最近需要使用PHP的图像库 做一个在线照片处理的应用(做一些风格效果),PHP提供了几个库:EXIF, GD, ImageMagick, Gmagick, Cairo

    请问哪个更适合呢?

  2. 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 图片裁剪为固定大小缩略图)