| Brief introduction:
GraphicsMagick is known as the Swiss Army Knife in the field of image processing. The short and concise code provides a robust and efficient collection of tools and libraries to handle the reading, writing and manipulation of images, supporting more than 88 image formats, including the important DPX, GIF, JPEG, JPEG-2000, PNG , PDF, PNM and TIFF.
Through the use of OpenMP, multi-threading is used for image processing, which enhances the processing power by expanding the CPU.
GraphicsMagick can be used on most platforms, Linux, Mac, Windows are no problem.
GraphicsMagick supports the processing of large images, and has done GB-level image processing experiments. GraphicsMagick can dynamically generate pictures, especially for Internet applications. It can be used to handle resizing, rotating, highlighting, color adjustment, adding special effects, etc. GaphicsMagick not only supports the command line mode, but also supports calls of C, C++, Perl, PHP, Tcl, Ruby, etc. In fact, GraphicsMagick was forked from ImageMagick 5.5.2, but now it's more stable and better, here are some comparisons between the two.
GM is more efficient (evaluated) and can process jobs faster
GM is smaller and easier to install
GM is already used by Flickr and Etsy, processes millions of images per day
GM does not conflict with installed software
GM has little security Question
GM's manual is very rich
...(irrelevant correct nonsense)
How to install:
GraphicsMagick can be installed on any modern Unix machine (Linux and MacOS X) and Windows using source code, here only describes the installation under Linux, other installations are also Need to see here.
Download the source package of .tar.gz, decompress
tar -xvzf GraphicsMagick-1.3.12.tar.gz
After decompression, the original gz file becomes a tar file, enter the folder
cd GraphicsMagick-1.3.12
before installation, Because it is image processing, the development packages of libpng and libjpeg need to be installed in the system, otherwise the support of these two files will not be installed.
Use configure for automatic configuration, build and installation./configure
Of
course, parameters can be specified by --prefix=PATH, and other compile-time variables can also be specified. Here, a tested configure configuration is used, and enable- sybol-prefix, which avoids conflicts with the existing ImageMagick in the system, the following are the completed configuration parameters:
./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
The next step is to install
make
make install
to install gmaick:
After installing GraphicsMagick, you also need to install gmaick to use it in PHP. First, download the installation package from PECL's website. Then unzip it, go to the gmaick directory,
cd gmagick-1.0.7b1
and run phpize
/usr/local/php/bin/phpize
and execute the installation process./configure
--with-php-config=/usr/local/ sinasrv2/bin/php-config --with-gmagick=/usr/local/sinasrv2/
make
make install
After opening the extension in php.ini, restart apache to use it
. Comparison with magickwand:
This article uses 20 different sizes of For image files, gmagick and magickwand are used to open the image, read the image information, and close the image. The final result is as follows:
Generally speaking, the efficiency of magickwand is much worse than that of GraphicsMagick, but the improvement of efficiency seems to be the same as that of GraphicsMagick. There is no obvious linear relationship between the processed files. Maybe the picture is too small. It is said that GraphicsMagick can process Gb-level pictures. More details can only be further studied in the future.
References:
1. GraphicsMagick
2. gmagick
3.ImageMagick
4, OpenMP in GraphicsMagick
5, Resolving GraphicsMagick and ImageMagick Conflict
6, Gmagick
7, Manipulating Images with PHP and GraphicsMagick
8, ImageMagick Installation Notes
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的资料来套用。
补充：如果想让用户手动裁剪头片的话，是个好选择。 |