ImageMagick和GraphicsMagick有什么区别？

Question

我发现自己正在评估这两个库.除了GraphicsMagick的比较说,我看到ImageMagick仍然有更新,似乎两者几乎相同.

我只是想在C++中进行基本的图像处理(即图像加载,滤镜,显示); 在这些库之间进行选择时,我应该注意哪些差异？

Answer 1

从我所看到的,GraphicsMagick更稳定,更快.我做了几个不科学的测试,发现gm的速度是im的两倍(做一个调整大小).

Answer 2

我发现ImageMagick在处理TIFF group-4图像(B&W文档图像)时非常慢,这主要是因为它从每像素1位转换为8并再次返回以进行任何图像处理.GraphicsMagick小组用他们的版本1.2修改了TIFF格式支持,并且处理这些类型的图像比原始ImageMagick快得多.目前的GraphicsMagick稳定版本为1.3.5.

Answer 3

当速度不是一个因素时我使用ImageMagick.然而,在服务器端,每天处理数万个图像,GraphicsMagick的速度明显更快 - 在某些情况下,基准测试速度提高了50%!

Answer 4

就像生活中的许多事情一样，不同的人对最好的事物有不同的想法。如果您问一位风景摄影师在苏格兰山区的雨中徘徊，这是世界上最好的相机，他将告诉您一台轻巧，天气密封的相机。询问摄影棚摄影师，他会告诉您分辨率最高，闪光灯同步速度最佳的照片。而且，如果您问体育摄影师，他会告诉您自动对焦速度最快和帧频最高的摄影师。ImageMagick和GraphicsMagick也是如此。

在过去5年多的时间里，在ImageMagick上回答了大约2,000个StackOverflow问题之后，我做了以下观察...

就受欢迎程度而言...

• SO上的ImageMagick问题比GraphicsMagick问题多12：1（7,375个问题与2019年5月的611个问题），以及
• SO上的ImageMagick关注者比GraphicsMagick关注者多15：1（（387关注者vs 2019年5月为25）

在性能方面...

我很高兴承认GraphicsMagick对于某些问题（但不是全部问题）可能会更快。但是，如果速度是您最重要的考虑因素，那么我认为您可能应该libvips在当今的多核CPU或OpenCV等经过SIMD优化（或GPU优化）的库中使用或并行代码。

在功能和灵活性方面...

这里有一个非常明显的赢家-ImageMagick。我的经验是，ImageMagick中存在GraphicsMagick缺少的许多功能，我在下面以特定顺序列出了其中的一些功能。

我自由地承认，我对GraphicsMagick的了解不如对ImageMagick的熟悉，但是我尽了最大的努力来找到有关GraphicsMagick最新源代码的功能。因此，对于Canny Edge Detector，我在GM源代码上运行了以下命令：

find . -type f -exec grep -i Canny {} \;

一无所获

坎尼边缘检测仪

通用汽车似乎完全没有这种情况。参见-canny radiusxsigma{+lower-percent}{+upper-percent}IM。

请参见此处的示例以及Lena图像上的边缘检测示例：

带括号的处理，复杂的重新排序

这是ImageMagick的杀手级功能，不得不使用GM时我经常会非常想念它。IM可以加载，创建或克隆整个系列的图像，并选择性地对特定图像进行不同的处理，然后非常简单，方便地对它们进行重新排序，复制和重新排序。简而言之，很难传达这给您带来的难以置信的灵活性。

想象一下，您想做一些相当简单的事情，例如加载图像A并对其进行模糊处理，加载图像B并使其成为灰度，然后将图像与图像B并排放置在左侧。使用ImageMagick看起来像这样：

magick imageA.png -blur x3 \( imageB.png -colorspace gray \) +swap +append result.png

您甚至无法开始使用GM，它将抱怨括号。如果删除它们，它将抱怨交换图像顺序。如果删除它，它将对所有图像应用灰度转换，因为它不理解括号，并在左侧放置了imageA。

请参阅IM中的以下排序命令：

• -swap
• -clone
• -duplicate
• -delete
• -insert
• -reverse

fx DIY图像处理运算符

IM的-fx运算符使您可以创建和尝试极其复杂的图像处理。您可以为图像中的每个像素评估功能。该函数可以任意复杂（如果需要，可以将其保存在文件中），并使用所有数学运算，三元样式if语句，甚至在其他图像中对像素的引用及其亮度或饱和度等。

以下是几个示例：

magick rose: -channel G -fx 'sin(pi*i/w)' -separate   fx_sine_gradient.gif

magick -size 80x80 xc: -channel G -fx  'sin((i-w/2)*(j-h/2)/w)/2+.5' -separate fx_2d_gradient.gif

使用此功能有很大的影响在处理绿屏（色度键控）图像时StackOverflow的答案是在这里。

傅立叶（频域）分析

似乎没有提到GM中的正向或反向傅立叶分析，也没有提及支持它通常需要的高动态范围支持（请参阅下文）。参见-fftIM。

连通成分分析/标记/斑点分析

GM中似乎没有“关联组件分析” -也称为“标签”和“斑点分析”。有关-connected-components connectivity4和8连接的斑点分析的信息，请参见。

仅此功能即可提供60多个答案-参见此处。

霍夫线检测

GM中似乎没有霍夫线检测。参见-hough-lines widthxheight{+threshold}IM。

请参阅此处的功能描述以及以下检测到的线路示例：

瞬间和知觉哈希（pHash）

似乎不支持图像矩计算（质心和高阶），也不支持GM中的感知散列。参见-momentsIM。

形态学

似乎不支持基因改造中的形态学处理。IM中对以下内容提供了完善的支持：

• 扩张
• 侵蚀
• 形态开合
• 骨架化
• 距离形态
• 高顶礼帽和低顶礼帽形态
• 命中和缺失形态-线末端，线交界处，峰，山脊，凸包等

查看这个出色的教程可以完成的所有复杂处理。

对比度受限的自适应直方图均衡化-CLAHE

似乎在GM中不支持对比度受限的自适应直方图均衡。参见-clahe widthxheight{%}{+}number-bins{+}clip-limit{!}IM。

HDRI-高动态范围成像

GM中似乎不支持高动态范围成像-只有8位，16位和32位整数类型。

卷积

ImageMagick支持多种类型的卷积：

• 高斯犬的差异
• 拉普拉斯式
• 索贝尔
• 罗盘
• 普威特
• 罗伯茨
• 弗雷陈

GM源代码中没有提到这些。

Magick永久寄存器（MPR）

这是ImageMagick中的一项非常宝贵的功能，它使您可以在处理过程中将中间处理结果写入命名的内存块，而不会产生写入磁盘的开销。例如，您可以准备一个纹理或图案，然后将其平铺在图像上，或者准备一个遮罩，然后对其进行更改，然后在不经过磁盘处理的情况下，以相同的处理方法进行应用。

这是一个例子：

 magick tree.gif -flip -write mpr:tree +delete -size 64x64 tile:mpr:tree mpr_tile.gif

广泛的色彩空间支持

IM支持GM中找不到的以下色彩空间：

• 实验室
• 盐酸
• 恒指
• LMS
• 其他。

Pango支持

IM支持类似于HTML的Pango文本标记语言，并允许您使用更改后的文本注释图像：

• 字体，颜色，大小，重量，斜体
• 下标，上标，删除线
• 理由

中间句子等等。有一个很好的例子在这里。

JPEG压缩缩图

这项宝贵的功能允许库在从磁盘读取JPEG图像时缩小它们，从而仅读取必要的系数，从而减少了I / O并最大程度地减少了内存消耗。缩小图像时，它可以大大提高性能。

在这里查看示例。

写入时定义最大JPEG尺寸

IM支持很多要求的选项，-define jpeg:extent=400KB例如在写入JPEG文件时指定最大文件大小。

极坐标变换

IM支持在直角坐标和极坐标之间进行转换，请参见-distort polar和-distort depolar。

可定制区域的统计数据和操作

借助其-statistic MxN运算符，ImageMagick可以生成许多有用的统计信息和效果。例如，您可以将图像中的每个像素设置为其5x3邻域的梯度（最亮与最暗之间的差）：

magick image.png -statistic gradient 5x3 result.png

或者，您可以将每个像素设置为其1x200邻域的中位数：

magick image.png -statistic median 1x200 result.png

在这里查看应用示例。

图像序列

ImageMagick支持图像序列，因此，如果您有一组以高ISO拍摄的非常嘈杂的图像，则可以加载整个图像序列，例如，取所有图像的中值或平均值以减少噪点。见-evaluate-sequence接线员。我并不是指单个图像中周围邻域的中位数，而是要找到每个像素位置上所有图像的中位数。

上面无论如何都不是详尽无遗的清单，它们只是我想到差异时想到的头几件事。我什至没有提到对HEIC（Apple的iPhone图像格式）的支持，这种格式越来越普遍，例如EXR或其他格式。实际上，如果比较两种产品（gm convert -list format和magick identify -list format）支持的文件格式，您会发现IM支持261种格式，而GM支持192种格式。

正如我所说，不同的人有不同的意见。选择一个您喜欢的，并喜欢使用它。

与往常一样，我要感谢安东尼·蒂森（Anthony Thyssen）在https://www.imagemagick.org/Usage/上对ImageMagick的出色见解和论述，也要感谢弗雷德·温豪斯（Fred Weinhaus）的例子。

Answer 5

历史

由于创始开发人员之间的纠纷，graphicsmagick 于 2002 年从 imagemagick 分叉出来。因此它们共享相同的代码库。

参考：https : //en.wikipedia.org/wiki/GraphicsMagick

目标

图形魔术师

• 专注于简单、稳定、清晰的代码库/架构

图像魔术师

• 专注于推出新功能，扩展更广泛的工具库

除了速度之外，imagemagick 向终端 shell 添加了许多 cli 工具，而 graphicsmagick 是一个可以调用的单一工具。

CLI界面设计

图形魔术师

gm <command> <options> <file>

图像魔术师

convert <options> <file>
compare <options> <file>

恕我直言，我更喜欢（实际上，只使用） graphicsmagick(gm) 而不是 imagemagick，因为后者更容易发生工具名称冲突，这会导致在找出某些工具未运行的原因时出现很多问题，尤其是在服务器端自动化任务期间。总之 graphicsmagick 有更清晰的设计。

想象一个项目中有一个名为 convert 的二进制文件，它是 imagemagick 的 convert 还是您自己在项目中的滚动工具将被调用？

imagemagick 工具列表（包括转换、比较、显示）：https : //imagemagick.org/script/command-line-tools.php

graphicsmagick 命令列表：http : //www.graphicsmagick.org/utilities.html

注意：从 Mark S 提到的 v7 开始，imagemagick 现在作为单个二进制文件分发，并且还支持旧的 v6 命令。

表现

一个简单的内存消耗测试可以在这里找到：https : //coderwall.com/p/1l7h-a/imagemagick-bloat-graphicsmagick

依赖

GraphicsMagick 依赖 36 个库，而 ImageMagick 需要 64 个。参考：http : //www.graphicsmagick.org/1.3/FAQ.html