65

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

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

4

7 回答 7

83

就像生活中的许多事情一样，不同的人对什么是最好的有不同的看法。如果你问一位风景摄影师在苏格兰山区的雨中四处游荡，这是世界上最好的相机，他会告诉你一款轻便、防风雨的相机。询问工作室摄影师，他会告诉您具有最佳闪光同步速度的最高分辨率。如果你问体育摄影师，他会告诉你自动对焦速度最快、帧速率最高的那个。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 对于某些问题可能更快，但不是所有问题。但是，如果速度是您最重要的考虑因素，我认为您可能应该libvips在当今的多核 CPU 或 OpenCV 等高度 SIMD 优化（或 GPU 优化）的库上使用并行代码或并行代码。

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

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

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

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

什么也没找到。

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中似乎没有“连接组件分析” ——也称为“标签”和“Blob 分析”。参见-connected-components connectivity4 和 8 连接的 blob 分析。

仅此功能就提供了 60 多个答案 - 请参见此处。

霍夫线检测

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

请参阅此处的功能描述和以下检测到的行示例：

在此处输入图像描述

矩和感知散列 (pHash)

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

形态学

似乎不支持 GM 中的形态处理。在 IM 中，对以下内容提供了复杂的支持：

  • 扩张
  • 侵蚀
  • 形态开闭
  • 骨架化
  • 距离形态
  • 顶帽和底帽形态
  • 命中和未命中形态 - 线端、线连接点、山峰、山脊、凸壳等

查看您可以使用此出色教程进行的所有复杂处理。

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

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

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 在https://www.imagemagick.org/Usage/上对 ImageMagick 的出色见解和论述，还要感谢 Fred Weinhaus 提供的示例。

于 2019-05-20T12:01:47.180 回答
33

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

于 2009-05-25T21:58:39.067 回答
14

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

于 2009-06-26T19:20:26.193 回答
13

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

于 2011-04-22T12:13:47.753 回答
9

历史

由于创始开发者之间的争议，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

于 2019-04-28T10:31:40.507 回答
3

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

于 2019-11-08T04:45:04.763 回答
1

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

于 2019-05-20T16:43:47.223 回答