ImageMagick和GraphicsMagick有什么区别？

Question

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

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

Answer 1

据我所知，GraphicsMagick更稳定，速度更快。 我做了几个不科学的测试，发现gm的速度是im的两倍（调整大小）。

Answer 2

我发现ImageMagick处理TIFF group-4图像（B＆amp; 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位粉丝与2019年5月的25位粉丝）

在性能方面……

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

在功能和灵活性方面……

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

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

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

一无所获。

---

Canny Edge检测器

这在GM中似乎完全消失了。请参阅IM中的-canny radiusxsigma{+lower-percent}{+upper-percent}。

请参见示例here和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答案是here。

---

傅立叶（频域）分析

似乎没有提到GM中的正向或反向傅立叶分析，也没有提到通常需要高动态范围支持来支持它。请参阅IM中的-fft。

---

连接组件分析/标记/斑点分析

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

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

---

霍夫线检测

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

请参阅功能here的说明以及以下检测到的行示例：

---

瞬间和知觉哈希（pHash）

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

---

形态学

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

• 膨胀
• 侵蚀
• 打开和关闭形态
• 骨骼化
• 距离形态
• 高顶礼帽和低顶礼帽形态
• 命中和小姐形态-线末端，线交界处，峰，山脊，凸包等

查看您可以使用this great tutorial完成的所有复杂处理。

---

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

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

---

HDRI-高动态范围成像

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

---

卷积

ImageMagick支持许多类型的卷积：

• 高斯DoG的差异
• 拉普拉斯语
• 索贝尔
• 指南针
• 威望
• 罗伯茨
• Frei-Chen

这些都没有在GM源代码中提及。

---

Magick永久寄存器（MPR）

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

这是一个例子：

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

---

更广泛的色彩空间支持

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

• CIELab
• HCL
• 恒指
• LMS
• 其他人。

---

Pango支持

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

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

句子中段等等。有一个很好的例子here。

---

使用JPEG压缩加载

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

请参见示例here。

---

定义写入时的最大JPEG大小

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

---

极坐标变换

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

请参阅应用程序here的示例。

---

图像序列

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

---

以上内容无论如何都不是详尽无遗的清单，它们只是我想到这些差异时想到的头几件事。我什至没有提到对HEIC（苹果用于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分叉。因此它们共享相同的代码库。

Ref：https://en.wikipedia.org/wiki/GraphicsMagick

目标

graphicsmagick

• 专注于简单，稳定和更清晰的代码库/体系结构

imagemagick

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

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

CLI界面设计

graphicsmagick

gm <command> <options> <file>

imagemagick

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

imho，与imagemagick相比，我更喜欢（实际上仅使用） graphicsmagick（gm），因为后者具有更高的工具名称冲突机会，这在找出某些工具为何被使用时会引起很多问题没有运行，尤其是在服务器端自动化任务期间。总而言之，graphicsmagick的设计要清晰得多。

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

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

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

note：从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

Answer 6

GraphicsMagick是Imagemagick的早期分支。您可以在https://imagemagick.org/script/history.php上了解Imagemagick的历史以及到GraphicsMagick的分支。自分叉以来，Imagemagick似乎一直在继续发展，而GraphicsMagick则或多或少停滞。

Answer 7

请注意，GraphicsMagick提供API和ABI稳定性，这不是ImageMagick保证的一部分。从长远来看，这很重要，除非您要出售所有依赖项。