ImageMagick 和 GraphicsMagick 有什么区别？

Question

我发现自己正在评估这两个库。除了 GraphicsMagick 的比较之外，我发现 ImageMagick 仍然有更新，而且看起来两者几乎相同。

我只是想用 C++ 进行基本的图像处理（即图像加载、过滤器、显示）；在这些库之间进行选择时我应该注意什么差异吗？

Answer 1

这是我读GraphicsMagick工具更稳定，速度更快。 我做了几个不科学的测试，发现GM要快两倍，IM（做大小调整）。

Answer 2

我发现ImageMagick的是用于处理TIFF组-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（2019 年 5 月有 7,375 个问题 vs 611 个问题），并且
• SO 上的 ImageMagick 关注者数量比 GraphicsMagick 关注者数量多 15:1（（2019 年 5 月为 387 名关注者，而 25 名关注者）

在性能方面...

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

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

这里有一个非常明显的赢家 - ImageMagick。我的经验是，GraphicsMagick 中缺少许多功能，而 ImageMagick 中却有这些功能，我在下面列出了其中一些功能（排名不分先后）。

我坦率地承认，我对 GraphicsMagick 的熟悉度不如对 ImageMagick 的熟悉度，但我尽最大努力在最新的 GraphicsMagick 源代码中找到有关这些功能的任何提及。因此，对于 Canny Edge Detector，我在 GM 源代码上运行了以下命令：

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

但什么也没找到。

---

Canny 边缘检测器

这一点在 GM 中似乎完全缺失。看 -canny radiusxsigma{+lower-percent}{+upper-percent} 在即时通讯中。

参见示例 这里 以及 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 图像处理算子

即时通讯有 -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 中似乎没有提及前向或反向傅立叶分析，也没有提及通常需要支持它的高动态范围支持（见下文）。看 -fft 在即时通讯中。

---

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

似乎没有 《连通分量分析》 在 GM 中 - 也称为 “贴标签” 和 “斑点分析”. 。看 -connected-components connectivity 用于 4 连接和 8 连接的斑点分析。

仅此功能就提供了 60 多个答案 - 请参阅 这里.

---

霍夫线检测

GM 中似乎没有霍夫线检测。看 -hough-lines widthxheight{+threshold} 在即时通讯中。

查看功能描述 这里 以及以下检测到的行的示例：

---

时刻和感知哈希 (pHash)

GM 中似乎不支持图像矩计算（质心和高阶），也不支持感知哈希。看 -moments 在即时通讯中。

---

形态学

GM 中似乎不支持形态处理。IM 中提供了对以下方面的复杂支持：

• 扩张
• 侵蚀
• 形态学的开闭
• 骨架化
• 距离形态学
• 顶帽和底帽形态
• 命中和未命中形态 - 线端、线交汇处、峰、脊、凸包等

查看您可以执行的所有复杂处理 这个很棒的教程.

---

对比度有限自适应直方图均衡 - CLAHE

GM 中似乎不支持对比度受限自适应直方图均衡。看 -clahe widthxheight{%}{+}number-bins{+}clip-limit{!} 在即时通讯中。

---

HDRI - 高动态范围成像

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

---

卷积

ImageMagick 支持多种类型的卷积：

• 高斯 DoG 的差分
• 拉普拉斯算子
• 索贝尔
• 罗盘
• 普鲁伊特
• 罗伯茨
• 弗雷陈

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

---

Magick 持久寄存器 (MPR)

这是 ImageMagick 中的一个非常宝贵的功能，它允许您在处理过程中将中间处理结果写入指定的内存块，而无需写入磁盘的开销。例如，您可以准备纹理或图案，然后将其平铺在图像上，或者准备蒙版，然后更改它并稍后在相同的处理中应用它，而无需访问磁盘。

这是一个例子：

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

---

更广泛的色彩空间支持

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

• CIE实验室
• 盐酸
• 恒指
• 学习管理系统
• 其他的。

---

潘戈支持

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

• 字体、颜色、大小、粗细、斜体
• 下标、上标、删除线
• 理由

句子中间还有很多很多。有一个很好的例子 这里.

---

使用 JPEG 进行加载收缩

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

参见示例 这里.

---

写入时定义最大 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

参见应用示例 这里.

---

图像序列

ImageMagick 支持图像序列，因此，如果您有一组在高 ISO 下拍摄的噪声非常大的图像，您可以加载整个图像序列，例如，取所有图像的中值或平均值以减少噪声。请参阅 -evaluate-sequence 操作员。我并不是指单个图像中周围邻域的中值，而是指找到每个像素位置的所有图像的中值。

---

无论如何，上面的列表并不是详尽的列表，它们只是我在考虑这些差异时首先想到的几件事。我什至没有提到对 HEIC（Apple 的 iPhone 图像格式）、日益常见的高动态范围格式（例如 EXR）或任何其他格式的支持。事实上，如果比较两个产品支持的文件格式（gm convert -list format 和 magick identify -list format）你会发现IM支持261种格式，GM支持192种格式。

正如我所说，不同的人有不同的看法。选择您喜欢的一款并享受使用它的乐趣。

一如既往，我感谢 Anthony Thyssen 在 ImageMagick 上的出色见解和演讲 https://www.imagemagick.org/Usage/ 还要感谢 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

Answer 6

GraphicsMagick工具是从ImageMagick的早期叉。你可以阅读有关ImageMagick的历史和叉GraphicsMagick工具在 https://imagemagick.org/script/history。 PHP 。似乎ImageMagick的继续被广泛地发展，而同时GraphicsMagick工具已经由于叉或多或少保持停滞。