GraphicsMagick 介绍及安装

cnmqw

浏览: 216216 次
性别:
来自: 深圳

最近访客更多访客>>

chuyule

wolfwolfgod

lijiejava

lf78204490

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

博客分类：

架构师-09-引用文集

引用说明：原文来自 http://paris8.org/a/bbs/redirect.php?tid=7499&goto=lastpost，为方便本人阅读，格式略有调整。

简单介绍：
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级的图片，更多的使用细节，只能在今后进一步研究了。

参考资料：
1、GraphicsMagick

2、gmagick

3、ImageMagick

4、OpenMP in GraphicsMagick
5、解决GraphicsMagick和ImageMagick冲突
6、Gmagick
7、Manipulating Images with PHP and GraphicsMagick
8、ImageMagick安装备忘

 http://www.cnblogs.com/cocowool/archive/2010/08/16/1800954.html

IM4JAVA+GraphicsMagick处理网站图片

现在做的网站需要保存用户上传的图片，同时需要进行压缩和图片切割等特殊效果的处理。

一开始我们用的是JMagick+ ImageMagick处理用户上传的图片，但是存在一个非常严重的问题，Tomcat在跑了大概10天左右后会crash掉，异常内容为：

Java代码
magick.MagickException: Unable to retrieve handle

从表象看，应该是没有释放ImageMagick的句柄导致的，查找API后发现程序中没有调用

Java代码
magick.MagickImage.destroyImages() Called by finalize to deallocate the image handle.
在程序加上本方法，情况有所改善，大概在40天左右后出现了一次tomcat进程crash。

似乎并没有从本质上找到问题的根本。。。
在JMagick的邮件列表中找到一份我认为有价值的邮件，http://sourceforge.net/mailarchive/message.php?msg_name=20cf28cd1002231148s33c99843q875f59906dd32b8b%40mail.gmail.com

里面讲到了JMagick作为应用服务的缺点，并建议可以使用IM4JAVA：
Java代码
The "JNI hazard" here is that if something you use (f.ex libtiff for reading
TIFF files) has a memory bug then it can make your whole JVM crash. Thats of
course frustrating and therefore its great to have im4java around, which
starts IM as an external process, so JVM crashes are avoided.
* *
Coolest thing would be if JMagick and im4java could have the same API so it
was easy to switch depending on luckyness. Ive asked the author of im4java
to attemt to be as compatible as possible, but as im4java is very much
different internally its limited how much can be done in that direction.

If you don't like the risk, stick to im4java. If your want optimal
performance give JMagick a try.

And, its not JMagick that is buggy, its what it depends on (hereunder IM)
that is not always (memory) bug free on long running processes.
I also have never seen a mismatch between JMagick binary and ImageMagick
binaries leading to crashes.

所以我把思路转向了IM4Java。
IM4Java的官网 http://im4java.sourceforge.net/index.html 。
在 Developer's Guide 中提到im4java支持ImageMagick和GraphicsMagick。GraphicsMagick是ImageMagick的一个分支，相对于ImageMagick而言，TA处理速度更快，消耗资源更少，并且大的图片处理网站，如 Flickr and Etsy  已经在使用TA了。
下载GraphicsMagick的Q8版本（还有Q16、Q32的，版本见的区别可以查看ImageMagick的官网，大致意思是每像素用多少bit来存储信息，16、32要比8消耗更多的内存^_^）。
下面这段话是在GraphicsMagick的邮件列表中找到的：
Java代码
> I've got question about IM Q16 & Q8. What's a difference between that  two versions?
I know, that Q16 version takes 2 times more memory than Q8.
But is that so great precision in algorithm is needed in converting  jpegs, gif or pngs
(I need IM for converting that types of formats)

& JPEG and GIF only have 8-bit versions, so there will almost certainly be no benefit to using Q16.
It is possible to have 16-bit PNGs, but if you have to ask, you probably don't have to worry about it
安装GraphicsMagick和IM4Java非常简单，按照官网做就ｏｋ了，下面是一个简单的例子：

Java代码
/**
   * 先缩放，后居中切割图片
   * @param srcPath 源图路径
   * @param desPath 目标图保存路径
   * @param rectw 待切割在宽度
   * @param recth 待切割在高度
   * @throws IM4JavaException
   * @throws InterruptedException
   * @throws IOException
   */
public static void cropImageCenter(String srcPath, String desPath, int rectw, int recth) throws IOException, InterruptedException, IM4JavaException
{
      IMOperation op = new IMOperation();

      op.addImage();
      op.resize(rectw, recth, '^').gravity("center").extent(rectw, recth);
      op.addImage();

      ConvertCmd convert = new ConvertCmd(true);
      //convert.createScript("e:\\test\\myscript.sh",op);
      convert.run(op, srcPath, desPath);

}
我的头像就是用这个方法压缩的，源图为:

原始尺寸为578＊800，大小为68.8KB，处理后为180*180，大小为 6.15KB

在我的机器上使用LoadRunner进行了压力测试，并发１０用户的情况下，每秒能处理１１张左右的图片。
我的机器配置为：
Inter(R) Pentium(R) D CPU2.80GHz, 2.00GB 内存，迈拓 6V160E0 7200rpm
操作系统为　Windows server2003 Enterprise Edition Service Pack 2

http://javantsky.iteye.com/blog/747807

下面我们就以GraphicsMagick为例，采用命令行的方式来看看如何使用缩略图功能：

先上一个原始图片（input.jpg：160x120），以后的各个例子都会用到它：

BTW：列位看官现在可以咽口水了。

缩略图1

gm convert input.jpg -thumbnail '100x100' output_1.jpg

实际生成的图片大小是：100x75，也就是说说按此命令，会保持图片比例不变生成缩略图。这样很不错，但是有一个潜在的问题：我们不能简单明了的知道图片的最终大小，结果是前端显示的时候，无法设置img标签的width和height属性，如果我没记错的话，一般是推荐设定width和height属性的，否则浏览器渲染起来可能会稍稍慢一点。

缩略图2

gm convert input.jpg -thumbnail '100x100!' output_2.jpg

这次实际生成的图片大小按定义来，但图片变形了，有时候这是不能接受的。

缩略图3

gm convert input.jpg -thumbnail '100x100^' \
-gravity center -extent 100x100 output_3.jpg

这次不仅保证了大小，还保证了比例。不过图片经过了裁剪。

缩略图4

gm convert input.jpg -thumbnail '100x100' \
-background gray -gravity center -extent 100x100 output_4.jpg

这次不仅保证了大小，还保证了比例，同时没有对图片进行任何裁剪，多余的部分按指定颜色进行填充。

缩略图5

gm convert input.jpg -thumbnail '10000@' \
-background gray -gravity center -extent 100x100 output_5.jpg

这次保证了大小和比例，其中的10000就是100x100的乘积，同时在填充和裁剪之间做了一个平衡。

明白了以上几个例子，缩略图基本就能通吃了，肯定有一种会适合你的需求。GraphicsMagick的资料非常少，但好消息是GraphicsMagick和ImageMagick的用法基本兼容，所以你可以通过ImageMagick的资料来套用。

补充：如果想让用户手动裁剪头片的话，是个好选择。