ImageMagick 和 GraphicsMagick 有啥区别？

Posted 2023-03-15

技术标签:

【中文标题】ImageMagick 和 GraphicsMagick 有啥区别？【英文标题】：What is the difference between ImageMagick and GraphicsMagick?ImageMagick 和 GraphicsMagick 有什么区别？ 【发布时间】：2010-10-26 02:41:08 【问题描述】：

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

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

【问题讨论】：

【参考方案1】：

就像生活中的许多事情一样，不同的人对什么是最好的有不同的看法。如果你问一位在苏格兰山区雨中游荡的风景摄影师，哪一款是世界上最好的相机，他会告诉你一款轻便、防风雨的相机。询问工作室摄影师，他会告诉您具有最佳闪光同步速度的最高分辨率。如果你问体育摄影师，他会告诉你自动对焦速度最快、帧速率最高的那个。 ImageMagick 和 GraphicsMagick 也是如此。

在过去 5 年多的时间里，我在 ImageMagick 上回答了大约 2,000 个 *** 问题，我提出以下意见...

就人气而言...

ImageMagick 问题与 GraphicsMagick 问题的比例为 12:1（7,375 个问题，而 2019 年 5 月为 611 个），并且在 SO 上的 ImageMagick 追随者数量超过 GraphicsMagick 追随者 15:1（（387 追随者，而 2019 年 5 月为 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 中完全缺失。请参阅 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

使用此功能在处理绿屏（色键）图像时效果很好的 *** 答案是 here。

傅里叶（频域）分析

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

连接成分分析/标签/斑点分析

GM 中似乎没有“连接组件分析” - 也称为 “标签” 和 “Blob 分析”。请参阅-connected-components connectivity 了解 4 和 8 连接 blob 分析。

仅此功能就提供了 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的差异拉普拉斯算子索贝尔指南针普威特罗伯茨弗莱陈

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

Magick 持久寄存器 (MPR)

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

这是一个例子：

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

更广泛的色彩空间支持

IM 支持以下 GM 中没有的色彩空间：

CIELab 盐酸恒指学习管理系统其他。

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（Apple 的 iPhone 图像格式）、越来越常见的高动态范围格式（如 EXR）或任何其他格式的支持。其实对比一下两款产品（gm convert -list format和magick identify -list format）支持的文件格式会发现，IM支持261格式，GM支持192。

正如我所说，不同的人有不同的看法。选择您喜欢并喜欢使用的那个。

与往常一样，我要感谢 Anthony Thyssen 在 https://www.imagemagick.org/Usage/https://www.imagemagick.org/Usage/ 上对 ImageMagick 的出色见解和演讲，也感谢 Fred Weinhaus 提供的示例。

【讨论】：

今天，在 *** 上工作了 8 年后，我发现 GraphicsMagick 比 ImageMagick 做得更好。它可以在AlpineLinux上读取WMF格式文件！ ***.com/a/69095783/2836621【参考方案2】：

从我阅读的内容来看，GraphicsMagick 更稳定，速度更快。我做了一些不科学的测试，发现 gm 的速度是 im 的两倍（调整大小）。

【讨论】：

【参考方案3】：

我发现 ImageMagick 处理 TIFF group-4 图像（黑白文档图像）的速度非常慢，主要是因为它从每像素 1 位转换为 8 位，然后再转换回来以进行任何图像处理。 GraphicsMagick 小组在其 1.2 版中彻底检查了对 TIFF 格式的支持，它在处理这些类型的图像方面比原来的 ImageMagick 快得多。当前的 GraphicsMagick 稳定版本为 1.3.5。

【讨论】：

【参考方案4】：

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

【讨论】：

【参考方案5】：

历史

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

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

目标

图形魔术

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

imagemagick

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

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

CLI 界面设计

图形魔术

gm <command> <options> <file>

imagemagick

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

【讨论】：

从 v7 开始，ImageMagick 是一个名为 magick 的单个可执行文件，因此名称冲突的可能性很小。恕我直言，它还具有比 GraphicsMagick 更好的功能 - 特别是在括号表达式、克隆和一般控制方面。截至 2019 年 4 月，我认为 *** 上的 ImageMagick 问题比 GraphicsMagick 多 12 倍（7,375 个问题与611) 并且关注 ImageMagick 标记的人数是 GraphicsMagick 标记的 15 倍（387 位关注者与 25 位关注者）。我看不到依赖项数量的相关性，并认为如果您需要它们，它们很容易安装，并且证明了更强大的功能和覆盖范围。此外，如果您真的对性能或内存消耗感兴趣，您应该查看libvips ... github.com/jcupitt/libvips/wiki/Speed-and-memory-use 我再次不明白为什么您认为对 ImageMagicK 有偏见。 OP询问了“差异”。我给了我的。如果您认为我的部分回答不够充分。请对 OPs 问题有一个新的答案。这不是建设性的。加上添加到您的评论。 ImageMagicK 在 Wordpress 中使用，因此具有优越的数字。并不意味着它是最佳选择，它只是在 GM 和大型组织不为图像优化空间烦恼之前。我将不胜感激答案中的真相，而不是固执己见的观点。只是一个观察 - GraphicsMagick 显然无法“识别”我扔给它的大型 PDF 文件（约 150MB，包含 28 个扫描页面），放弃并声称它用完了磁盘空间（尽管在短暂运行期间磁盘使用没有变化）。更令人费解的是，为什么它甚至会在执行只读操作时“写入文件”！另一方面，ImageMagick 可以毫无问题地处理图像。【参考方案6】：

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

【讨论】：

【参考方案7】：

GraphicsMagick 是 Imagemagick 的早期分支。您可以在https://imagemagick.org/script/history.php 阅读有关 Imagemagick 的历史和对 GraphicsMagick 的分支的信息。似乎 Imagemagick 继续得到相当广泛的开发，而 GraphicsMagick 自分叉以来或多或少地停滞不前。