介绍
GraphicsMagick 是个图片处理库，是从ImageMagick 5.5.2分支出来的，但是现在他变得更稳定和更轻、更快一些
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，这里还要再啰嗦一遍，因为这里有个小坑，希望对大家有所帮助。
Mac 上安装 GraphicsMagick 有两种方式，brew 命令一键式安装虽然简单，但是它默认会加一些配置信息，导致我们没法使用 GraphicsMagick 的 OpenMP 功能，所以我们最好还是手动编译安装。
brew安装
Mac 可以使用 brew 命令：
brew install libpng
brew install libjpeg
#通过 brew 安装 GraphicsMagick（libpng 等依赖包会一并下载）
brew install graphicsmagick
// 删除命令
brew uninstall graphicsmagick
brew cleanup -s
查看 GraphicsMagick 的版本以及安装路径：
% gm -version
GraphicsMagick 1.3.38 2022-03-26 Q16 http://www.GraphicsMagick.org/
......
Configured using the command:
./configure '--prefix=/usr/local/Cellar/graphicsmagick/1.3.38_1' '--disable-dependency-tracking' '--disable-openmp' '--disable-static' '--enable-shared' '--with-modules' '--with-quantum-depth=16' '--without-lzma' '--without-x' '--without-gslib' '--with-gs-font-dir=/usr/local/share/ghostscript/fonts' '--without-wmf' 'CC=clang' 'CXX=clang++' 'PKG_CONFIG_PATH=/usr/local/opt/libpng/lib/pkgconfig:/usr/local/opt/freetype/lib/pkgconfig:/usr/local/opt/jpeg-turbo/lib/pkgconfig:/usr/local/opt/jasper/lib/pkgconfig:/usr/local/opt/libtiff/lib/pkgconfig:/usr/local/opt/little-cms2/lib/pkgconfig:/usr/local/opt/webp/lib/pkgconfig' 'PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig:/usr/local/Homebrew/Library/Homebrew/os/mac/pkgconfig/11'
.....
由上可知，brew 命令默认执行 ./configure 命令时，包含了“--disable-openmp”指令，该指令意味着完全禁用 OpenMP（自动多线程循环），会降低 GraphicsMagick 处理图片的性能。关于这点会在下文详细介绍。
手动编译安装
mkdir /usr/local/tools
tar -xvf GraphicsMagick-1.3.37.tar.gz -C /hresh/tool/
# 进入GraphicsMagick安装目录
./configure --prefix=/hresh/tool/GraphicsMagick-1.3.37 --enable-shared --enable-openmp-slow
make && make install
在 .bash_profile 文件中设置环境变量：
export GMAGICK_HOME="/hresh/tool/GraphicsMagick-1.3.37"
export PATH="GMAGICK_HOME/bin:PATH"
export LD_LIBRARY_PATH="$GMAGICK_HOME/lib/"
export OMP_NUM_THREADS=6
OMP_NUM_THREADS 环境变量，表示GM可使用的线程数。必须设置OMP_NUM_THREADS 环境变量才可以真正使用起多线程(openmp)。
查看 GraphicsMagick 的版本以及安装路径：
% gm -version
GraphicsMagick 1.3.37 20201226 Q16 http://www.GraphicsMagick.org/
Configured using the command:
./configure '--prefix=/hresh/tool/GraphicsMagick-1.3.37' '--enable-shared' '--enable-openmp-slow'
删除 GraphicsMagick
make distclean
make uninstall
OOM问题
我们在之前一篇文章中介绍过如何通过 Im4Java 给图片添加图片水印，代码如下所示：
public static void addImgWatermark(String srcImagePath, String destImagePath, String waterImgPath)
throws Exception {
// 原始图片信息
BufferedImage targetImg = ImageIO.read(new File(srcImagePath));
// 水印图片
BufferedImage watermarkImage = ImageIO.read(new File(waterImgPath));
int w = targetImg.getWidth();
int h = targetImg.getHeight();
IMOperation op = new IMOperation();
// 水印图片位置
op.geometry(watermarkImage.getWidth(), watermarkImage.getHeight(),
w - watermarkImage.getWidth() - 300, h - watermarkImage.getHeight() - 100);
// 水印透明度
op.dissolve(90);
// 水印
op.addImage(waterImgPath);
// 原图
op.addImage(srcImagePath);
// 目标
op.addImage(destImagePath);
ImageCommand cmd = getImageCommand(CommandType.imageWaterMark);
cmd.run(op);
}
当时只考虑基本功能实现了，并未注意细节问题，经同事提醒，发现 ImageIO.read()这种方式来获取原图片的宽高信息，会将整个图片流读取到内存，浪费了大量的空间并且还增加了 OOM 风险。
通过BufferedImage获取宽高
测试代码如下：
public static void addImgWatermark(String srcImagePath, String destImagePath,
String waterImgPath) {
System.out.println(Thread.currentThread().getName() + "开始生成图片水印。。。。。。。");
try {
// 原始图片信息
BufferedImage targetImg = ImageIO.read(new File(srcImagePath));
// 水印图片
BufferedImage watermarkImage = ImageIO.read(new File(waterImgPath));
int w = targetImg.getWidth();
int h = targetImg.getHeight();
int watermarkImageWidth = watermarkImage.getWidth();
int watermarkImageHeight = watermarkImage.getHeight();
IMOperation op2 = new IMOperation();
// 水印图片位置
op2.geometry(watermarkImageWidth, watermarkImageHeight,
w - watermarkImageWidth - 300, h - watermarkImageHeight - 100);
// 水印透明度
op2.dissolve(90);
// 水印
op2.addImage(waterImgPath);
// 原图
op2.addImage(srcImagePath);
// 目标
op2.addImage(destImagePath);
ImageCommand cmd2 = getImageCommand(CommandType.imageWaterMark);
cmd2.run(op2);
} catch (Exception e) {
e.printStackTrace();
}
System.out.println(Thread.currentThread().getName() + "成功生成图片水印。。。。。。。。。。");
}
public static void main(String[] args) throws Exception {
ExecutorService executorService = new ThreadPoolExecutor(20, 25, 30, TimeUnit.SECONDS,
new LinkedBlockingDeque<>(5),
Executors.defaultThreadFactory(),
new ThreadPoolExecutor.AbortPolicy());
try {
for (int i = 1; i <= 17; i++) {
executorService.execute(new ImageThread2());
}
} catch (Exception e) {
e.printStackTrace();
} finally {
executorService.shutdown();
}
}
class ImageThread2 implements Runnable {
@Override
public void run() {
String projectPath = System.getProperty("user.dir");
// 图片大小为7.9M
String srcImgPath = projectPath + "/src/main/resources/static/sky.png";
String waterImgPath = projectPath + "/src/main/resources/static/icon.png";
String path = projectPath + "/src/main/resources/static/out/concurrency/im4_image.jpg";
Im4JavaUtil.addImgWatermark(srcImgPath, path, waterImgPath);
}
}
控制台输出结果为：
可以看出，并发情况下 ImageIO.read()会引发 OOM 异常，这是为什么呢？
BufferedImage 对象中最重要的两个组件为 Raster 和 ColorModel，分别用于存储图像的像素数据与颜色数据。
Raster 表示像素矩形数组的类，封装存储样本值的 DataBuffer，以及描述如何在 DataBuffer 中定位给定样本值的 SampleModel。我们获取图片的宽高，就是从 raster 对象中拿到的。
每次生成 BufferedImage 对象，都要读取图片数据流到内存中，即生成 Raster 对象，最终导致 JVM 内存空间不足，引发 OOM 异常。
除了从源码层面分析外，还可以分析 GC 结果，首先在执行上述代码时配置如下 JVM 参数：
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps
在控制台可以看到不停的打印 GC 日志，截取一部分 GC 结果如下：
Heap
PSYoungGen total 282624K, used 138032K [0x000000076ab00000, 0x000000077c180000, 0x00000007c0000000)
eden space 280576K, 48% used [0x000000076ab00000,0x00000007730be518,0x000000077bd00000)
from space 2048K, 52% used [0x000000077bf00000,0x000000077c00dec8,0x000000077c100000)
to space 2048K, 0% used [0x000000077bd00000,0x000000077bd00000,0x000000077bf00000)
ParOldGen total 2796544K, used 2717164K [0x00000006c0000000, 0x000000076ab00000, 0x000000076ab00000)
object space 2796544K, 97% used [0x00000006c0000000,0x0000000765d7b378,0x000000076ab00000)
Metaspace used 6753K, capacity 6890K, committed 7040K, reserved 1056768K
class space used 749K, capacity 803K, committed 896K, reserved 1048576K
可以看到老年代内存占用比例极高，由此推荐因内存来不及回收，最终引发内存溢出。
此外我们还可以通过 VisualVM 工具的 “VisualGC” 插件直观的看到内存的占用情况，如下图所示：
通过ImageReader获取宽高
针对上述问题，我们可以替换掉 ImageIO.read()方法，代码修改如下：
int[] targetImgSize = getImgSize(srcImagePath);
int w = targetImgSize[0];
int h = targetImgSize[1];
int[] imgSize = getImgSize(waterImgPath);
int watermarkImageWidth = imgSize[0];
int watermarkImageHeight = imgSize[1];
public static int[] getImgSize(String filePath) throws Exception {
int[] size = new int[2];
try (ImageInputStream in = ImageIO.createImageInputStream(new File(filePath))) {
Iterator<ImageReader> readers = ImageIO.getImageReaders(in);
if (readers.hasNext()) {
ImageReader reader = readers.next();
try {
reader.setInput(in);
int width = reader.getWidth(0);
int height = reader.getHeight(0);
size[0] = width;
size[1] = height;
} finally {
reader.dispose();
}
}
}
return size;
}
开启同样多的线程，执行代码不会再抛出 OOM 异常，GC 日志如下：
Heap
PSYoungGen total 76288K, used 29601K [0x000000076ab00000, 0x0000000770000000, 0x00000007c0000000)
eden space 65536K, 37% used [0x000000076ab00000,0x000000076c3326d8,0x000000076eb00000)
from space 10752K, 44% used [0x000000076eb00000,0x000000076efb5e60,0x000000076f580000)
to space 10752K, 0% used [0x000000076f580000,0x000000076f580000,0x0000000770000000)
ParOldGen total 175104K, used 8K [0x00000006c0000000, 0x00000006cab00000, 0x000000076ab00000)
object space 175104K, 0% used [0x00000006c0000000,0x00000006c0002000,0x00000006cab00000)
Metaspace used 6326K, capacity 6552K, committed 6784K, reserved 1056768K
class space used 714K, capacity 790K, committed 896K, reserved 1048576K
内存占用直观图如下：
ImageReader性能更佳的原因
我们对比一下获取图片宽高的代码区别：
//通过BufferedImage获取图片宽高
BufferedImage targetImg = ImageIO.read(new File(srcImagePath));
BufferedImage watermarkImage = ImageIO.read(new File(waterImgPath));
int w = targetImg.getWidth();
int h = targetImg.getHeight();
int watermarkImageWidth = watermarkImage.getWidth();
int watermarkImageHeight = watermarkImage.getHeight();
// 通过ImageReader获取图片宽高
int[] targetImgSize = getImgSize(srcImagePath);
int w = targetImgSize[0];
int h = targetImgSize[1];
int[] imgSize = getImgSize(waterImgPath);
int watermarkImageWidth = imgSize[0];
int watermarkImageHeight = imgSize[1];
public static int[] getImgSize(String filePath) throws Exception {
int[] size = new int[2];
try (ImageInputStream in = ImageIO.createImageInputStream(new File(filePath))) {
Iterator<ImageReader> readers = ImageIO.getImageReaders(in);
if (readers.hasNext()) {
ImageReader reader = readers.next();
try {
reader.setInput(in);
int width = reader.getWidth(0);
int height = reader.getHeight(0);
size[0] = width;
size[1] = height;
} finally {
reader.dispose();
}
}
}
return size;
}
想要搞清楚 BufferedImage 和 ImageReader 的差异，还是深入源码探究一番。
关于 BufferedImage 对象的创建，核心代码如下所示：
// ImageIO
public static BufferedImage read(File input) throws IOException {
if (input == null) {
throw new IllegalArgumentException("input == null!");
}
if (!input.canRead()) {
throw new IIOException("Can't read input file!");
}
ImageInputStream stream = createImageInputStream(input);
if (stream == null) {
throw new IIOException("Can't create an ImageInputStream!");
}
BufferedImage bi = read(stream);
if (bi == null) {
stream.close();
}
return bi;
}
public static BufferedImage read(ImageInputStream stream)
throws IOException {
if (stream == null) {
throw new IllegalArgumentException("stream == null!");
}
Iterator iter = getImageReaders(stream);
if (!iter.hasNext()) {
return null;
}
ImageReader reader = (ImageReader)iter.next();
ImageReadParam param = reader.getDefaultReadParam();
reader.setInput(stream, true, true);
BufferedImage bi;
try {
bi = reader.read(0, param);
} finally {
reader.dispose();
stream.close();
}
return bi;
}
// com.sun.imageio.plugins.png.PNGImageReader
public BufferedImage read(int imageIndex, ImageReadParam param)
throws IIOException {
if (imageIndex != 0) {
throw new IndexOutOfBoundsException("imageIndex != 0!");
}
readImage(param);
return theImage;
}
private void readImage(ImageReadParam param) throws IIOException {
readMetadata();
// 这里拿到的宽高，后续
int width = metadata.IHDR_width;
int height = metadata.IHDR_height;
// Init default values
sourceXSubsampling = 1;
sourceYSubsampling = 1;
sourceMinProgressivePass = 0;
sourceMaxProgressivePass = 6;
sourceBands = null;
destinationBands = null;
destinationOffset = new Point(0, 0);
......
// 接下来准备生成 BufferedImage 对象，即theImage
}
// 通过readHeader()获取图片宽高
private void readMetadata() throws IIOException {
if (gotMetadata) {
return;
}
readHeader();
......
}
// javax.imageio.ImageTypeSpecifier
// 在该方法中创建BufferedImage对象
public BufferedImage createBufferedImage(int width, int height) {
try {
SampleModel sampleModel = getSampleModel(width, height);
WritableRaster raster =
Raster.createWritableRaster(sampleModel,
new Point(0, 0));
return new BufferedImage(colorModel, raster,
colorModel.isAlphaPremultiplied(),
new Hashtable());
} catch (NegativeArraySizeException e) {
// Exception most likely thrown from a DataBuffer constructor
throw new IllegalArgumentException
("Array size > Integer.MAX_VALUE!");
}
}
看完上述代码，有没有发现 ImageIO 文件中的 read()方法和我们写的 getImgSize()方法很相似，当获取到 ImageReader 对象后，我们的代码就直接获取图片宽高了，没有其他多余的操作。相关源码如下：
// com.sun.imageio.plugins.png.PNGImageReader
public int getWidth(int imageIndex) throws IIOException {
if (imageIndex != 0) {
throw new IndexOutOfBoundsException("imageIndex != 0!");
}
readHeader();
return metadata.IHDR_width;
}
对比两者的调用链路，可以发现通过 ImageReader 获取图片宽高的方式链路更短；除此之外，内存占用更少，所以更不容易产生内存问题。
OpenMP
一开始在 Mac 上尝试测试 OpenMP，反复鼓捣后还是失败了，归根结底是因为本机默认不支持 OpenMP，感兴趣的朋友可以参考在 macOS 平台上安装 OpenMP 库，试一试能否在 Mac 上测试 OpenMP。
所以这里我们基于阿里云的服务器进行测试，服务器只有 2核。
测试
gm benchmark [ 选项... ] 命令
benchmark **为一个或多个循环和/或指定的执行时间执行任意gm实用程序命令（例如convert ），并报告许多执行指标。对于使用 OpenMP 的构建，提供了一种模式以使用越来越多的线程执行基准测试，并提供加速和多线程执行效率的报告。如果基准测试**用于执行没有任何附加基准测试选项的命令，则该命令运行一次。
本次测试使用如下命令：
gm benchmark -iterations 100 -stepthreads 1 +原命令语句
-iterations 100 次数
-stepthreads 1 线程增长步长,1表示每次加1个线程，一直加到 OMP_NUM_THREADS 环境变量的值 ，必须设置 OMP_NUM_THREADS环境变量才可以真正使用起多线程(openmp)。
禁用OpenMP
进入 GraphicsMagick 安装目录，执行如下命令：
./configure --prefix=/hresh/tool/GraphicsMagick-1.3.37 --enable-shared --disable-openmp
make
make install
然后进入图片所在目录，执行下述命令：
# gm benchmark -iterations 100 -stepthreads 1 convert -resize 100x100 -quality 90 +profile "*" mountain-landscape.jpg 123.jpg
Results: 1 threads 100 iter 52.41s user 52.747874s total 1.896 iter/s 1.908 iter/cpu 1.00 speedup 1.000 karp-flatt
结果中各参数含义如下：
- threads- 使用的线程数。
- iter - 执行的命令迭代次数。
- user - 消耗的总用户时间。
- total - 消耗的总时间。
- iter/s - 每秒的命令迭代次数。
- iter/cpu - 每次迭代消耗的 CPU 时间。
- speedup - 与一个线程相比的加速。
- karp-flatt - 加速效率的 Karp-Flatt 度量。
根据结果可知，处理一张图片耗时 524ms。
启用OpenMP
重新执行编译命令：
./configure --prefix=/hresh/tool/GraphicsMagick-1.3.37 --enable-shared --enable-openmp-slow
make
make install
然后进入图片所在目录，执行下述命令：
# export OMP_NUM_THREADS=2
# gm benchmark -iterations 100 -stepthreads 1 convert -resize 100x100 -quality 90 +profile "*" mountain-landscape.jpg 123.jpg
Results: 1 threads 100 iter 47.84s user 48.102332s total 2.079 iter/s 2.090 iter/cpu 1.00 speedup 1.000 karp-flatt
Results: 2 threads 100 iter 48.95s user 36.630871s total 2.730 iter/s 2.043 iter/cpu 1.31 speedup 0.523 karp-flatt
根据结果可知，线程1处理一张图片耗时 478ms，线程2处理一张图片耗时 489ms。
OpenMP 作为 GraphicsMagick 的特色功能之一，为了获取最佳性能，可以将 OMP_NUM_THREADS 设置为等于可用 CPU 内核的数量，如果服务器具有多个内核且运行多个程序，将 OMP_NUM_THREADS 设置为比内核数小一点，以确保最佳的整体系统性能。另外 CPU 使用率会随着线程数的增加而增加，所以要根据实际情况进行调配参数。
GraphicsMagick与Graphics2D
解决掉上面存在的 OOM 问题后，突然冒出一个想法：比较一下 GraphicsMagick 与 Graphics2D 在多线程环境下生成图片水印谁更占优势？
前提：针对同一张图片添加图片水印，都使用 ImageIO.read。
GraphicsMagick 代码
public static void addImgWatermark(String srcImagePath, String destImagePath,
String waterImgPath) {
System.out.println(Thread.currentThread().getName() + "开始生成图片水印。。。。。。。");
try {
// 原始图片信息
BufferedImage targetImg = ImageIO.read(new File(srcImagePath));
// 水印图片
BufferedImage watermarkImage = ImageIO.read(new File(waterImgPath));
int w = targetImg.getWidth();
int h = targetImg.getHeight();
int watermarkImageWidth = watermarkImage.getWidth();
int watermarkImageHeight = watermarkImage.getHeight();
IMOperation op2 = new IMOperation();
// 水印图片位置
op2.geometry(watermarkImageWidth, watermarkImageHeight,
w - watermarkImageWidth - 300, h - watermarkImageHeight - 100);
// 水印透明度
op2.dissolve(90);
// 水印
op2.addImage(waterImgPath);
// 原图
op2.addImage(srcImagePath);
// 目标
op2.addImage(destImagePath);
ImageCommand cmd2 = getImageCommand(CommandType.imageWaterMark);
cmd2.run(op2);
} catch (Exception e) {
e.printStackTrace();
}
System.out.println(Thread.currentThread().getName() + "成功生成图片水印。。。。。。。。。。");
}
public static void main(String[] args) throws Exception {
ExecutorService executorService = new ThreadPoolExecutor(20, 25, 30, TimeUnit.SECONDS,
new LinkedBlockingDeque<>(5),
Executors.defaultThreadFactory(),
new ThreadPoolExecutor.AbortPolicy());
try {
for (int i = 1; i <= 16; i++) {
executorService.execute(new ImageThread2());
}
} catch (Exception e) {
e.printStackTrace();
} finally {
executorService.shutdown();
}
}
class ImageThread2 implements Runnable {
@Override
public void run() {
String projectPath = System.getProperty("user.dir");
// 图片大小为7.9M
String srcImgPath = projectPath + "/src/main/resources/static/sky.png";
String waterImgPath = projectPath + "/src/main/resources/static/icon.png";
String path = projectPath + "/src/main/resources/static/out/concurrency/im4_image.jpg";
Im4JavaUtil.addImgWatermark(srcImgPath, path, waterImgPath);
}
}
经过测试得出如下结果：GraphicsMagick 添加图片水印操作最多同时开启 16个线程。
Graphics2D 代码
public static void graphics2DDrawImg(String srcImgPath, String waterImgPath, String outPath) {
System.out.println(Thread.currentThread().getName() + "开始生成图片水印。。。。。。。");
try {
BufferedImage targetImg = ImageIO.read(new File(srcImgPath));
int imgWidth = targetImg.getWidth();
int imgHeight = targetImg.getHeight();
BufferedImage bufferedImage = new BufferedImage(imgWidth, imgHeight,
BufferedImage.TYPE_INT_BGR);
Graphics2D g = bufferedImage.createGraphics();
g.drawImage(targetImg, 0, 0, imgWidth, imgHeight, null);
g.setColor(Color.BLACK);
int imgLeftMargin = ICON_LEFT_MARGINS[0];
int imgTopMargin = 1000;
BufferedImage icon = ImageIO.read(new File(waterImgPath));
g.drawImage(icon, imgLeftMargin, imgTopMargin, icon.getWidth(),
icon.getHeight(), null);
FileOutputStream outImgStream = new FileOutputStream(outPath);
ImageIO.write(bufferedImage, "jpg", outImgStream);
g.dispose();
outImgStream.close();
} catch (IOException e) {
e.getStackTrace();
}
System.out.println(Thread.currentThread().getName() + "成功生成图片水印。。。。。。。。。。");
}
public static void main(String[] args) throws Exception {
ExecutorService executorService = new ThreadPoolExecutor(20, 25, 30, TimeUnit.SECONDS,
new LinkedBlockingDeque<>(5),
Executors.defaultThreadFactory(),
new ThreadPoolExecutor.AbortPolicy());
try {
for (int i = 1; i <= 8; i++) {
executorService.execute(new ImageThread());
}
} catch (Exception e) {
e.printStackTrace();
} finally {
executorService.shutdown();
}
}
class ImageThread implements Runnable {
@Override
public void run() {
String projectPath = System.getProperty("user.dir");
String srcImgPath = projectPath + "/src/main/resources/static/sky.png";
String waterImgPath = projectPath + "/src/main/resources/static/icon.png";
String path = projectPath + "/src/main/resources/static/out/concurrency/g2d_image.jpg";
Graphics2DUtil.graphics2DDrawImg(srcImgPath, waterImgPath, path);
}
}
测试结果显示，Graphics2D 添加图片水印操作最多开启 7个线程。抛出 OOM 异常时截图如下：
综合来看，Graphics2D 是 Java 自带的图像处理工具类，处理图像时，与内存交互的操作比较频繁，加之会受到 JVM 的内存限制，所以更容易产生 OOM 异常。而 GraphicsMagick 进行图片处理时是直接读取图片到物理内存，不受 JVM 管理，所以更加安全一些。
总结
目前市面上成熟的图像处理库：GraphicsMagick 和 OpenCV。上述两款图像处理库都可以做到跨平台，在多种编译器上执行，都可以很容易实现多进程模式，充分发挥多核 CPU 的优势。GraphicsMagick 是前段时间才接触使用，OpenCV 在学习 Python 时了解过，在 Python 中应用比较广泛。
目前我使用的是 Java 语言，而 JDK 自带的一套图片处理库——Graphics2D，它的特点是稳定简单，但是对图片处理来说，性能确实不好！不过 Java 方面也提供了类似 JNI 方式支持 GraphicsMagick+im4java 处理图像。但是要原生态支持 opencv 就比较繁琐了，要用 JNI 方式调用大量动态或静态库，存在如下两个问题：一个性能问题，二是如果出现内存问题也不好控制。
当然选用某一技术时要结合实际需要，性能好的不一定最好，合适自己的才是最好。就拿我遇到的项目来说，基本没有高并发的图片处理场景，加之使用 Graphics2D 实现起来比较简单，所以最终选择 Graphics2D，而非 GraphicsMagick+im4java。
最后感谢同事的指点，让我对 GraphicsMagick 有了更新的认识，因此才有了这篇文章，希望后续能与大家有更多技术上的交流。
参考文献
本文作者为hresh，转载请注明。