ImageMagick 和 GraphicsMagick 有什么区别？
我发现自己正在评估这两个库。 除了 GraphicsMagick 的比较之外，我发现 ImageMagick 仍然有更新，而且看起来两者几乎相同。
我只是想用 C++ 进行基本的图像操作（即图像加载、过滤器、显示）； 在这些库之间进行选择时我应该注意什么差异吗？
I've found myself evaluating both of these libs. Apart from what the GraphicsMagick comparison says, I see that ImageMagick still got updates and it seems that the two are almost identical.
I'm just looking to do basic image manipulation in C++ (i.e. image load, filters, display); are there any differences I should be aware of when choosing between these libraries?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
就像生活中的许多事情一样，不同的人对于什么是最好的有不同的想法。 如果你问一位在苏格兰山区雨中漫步的风景摄影师，世界上最好的相机是什么，他会告诉你一款重量轻、防风雨的相机。 询问工作室摄影师，他会告诉您具有最佳闪光同步速度的最高分辨率。 如果您问一位体育摄影师，他会告诉您自动对焦最快和帧速率最高的摄影师。 ImageMagick 和 GraphicsMagick 也是如此。
在过去 5 年多的时间里，我在 ImageMagick 上回答了大约 2,000 个 StackOverflow 问题，得出以下结论...
就受欢迎程度而言...
就性能而言......
我很高兴承认 GraphicsMagick 对于某些问题（但不是所有问题）可能更快。但是，如果速度是您最重要的考虑因素，我认为您可能应该使用
libvips或当今多核上的并行代码。 CPU 或经过高度 SIMD 优化（或 GPU 优化）的库（例如 OpenCV）在功能和灵活性方面...
这里有一个非常明显的赢家 - ImageMagick 我的经验是，它有很多功能。 GraphicsMagick 中缺少这些，而 ImageMagick 中存在这些，我在下面列出了其中一些，没有特定的顺序。
我坦率地承认，我对 GraphicsMagick 的熟悉度不如对 ImageMagick 的熟悉度，但我尽最大努力在最新的 GraphicsMagick 源代码中找到有关这些功能的任何提及。 因此，对于 Canny Edge Detector，我在 GM 源代码上运行了以下命令：
但没有发现任何结果。
Canny Edge 探测器
这似乎在 GM 中完全缺失。 请参阅 IM 中的
-canny radiusxsigma{+lower-percent}{+upper-percent}。请参阅此处的示例以及 Lena 上的边缘检测示例图片：
带括号的处理，复杂的重新排序
这是 ImageMagick 的一个杀手级功能，当我不得不使用 GM 时，我常常非常怀念它。 IM 可以加载、创建或克隆整个系列的图像，并对特定图像有选择地应用不同的处理，并对它们进行重新排序、复制和重新排序，非常简单方便。 很难用简短的回答来表达它所提供的令人难以置信的灵活性。
想象一下，您想做一些相当简单的事情，例如加载图像 A 并对其进行模糊处理，加载图像 B 并将其设为灰度，然后将图像与图像 B 并排放置在左侧。 使用 ImageMagick 看起来像这样：
你甚至无法开始使用 GM，它会抱怨括号。 如果删除它们，它会抱怨交换图像顺序。 如果删除它，它将对两个图像应用灰度转换，因为它不理解括号并将 imageA 放在左侧。
请参阅 IM 中的以下排序命令：
-swap-clone-duplicate-delete-insert< /code>-reversefx DIY 图像处理运算符
IM 具有
-fx运算符，可让您创建和试验极其复杂的图像处理。 您可以对图像中的每个像素进行功能评估。 该函数可以像您喜欢的那样复杂（如果您愿意，可以将其保存在文件中）并使用所有数学运算、三元样式if语句、对其他图像中的像素及其亮度或饱和度等。以下是几个示例：
StackOverflow 的答案是 此处。
傅里叶（频域）分析
GM 中似乎没有提及前向或反向傅里叶分析，也没有提及通常需要支持它的高动态范围支持（见下文）。 请参阅 IM 中的
-fft。连通分量分析/标签/斑点分析
GM 中似乎没有“连通分量分析” - 也称为“标签” 和“斑点分析”< /em>. 有关 4 连接和 8 连接的 Blob 分析，请参阅
-connected-components 连接性。仅此功能就提供了 60 多个答案 - 请参阅此处。
霍夫线检测
GM 中似乎没有霍夫线检测。 请参阅 IM 中的
-hough-lines widthxheight{+threshold}。请参阅此处的功能说明以及以下检测到的示例行：
矩和感知哈希 (pHash)
GM 中似乎不支持图像矩计算（质心和高阶），也不支持感知哈希。 请参阅 IM 中的
-moments。形态学
GM 中似乎不支持形态学处理。 在 IM 中，对以下内容提供了复杂的支持：
查看您可以使用的所有复杂处理这个很棒的教程。
对比度有限自适应直方图均衡 - CLAHE
GM 中似乎不支持对比度有限自适应直方图均衡。 请参阅 IM 中的
-clahe widthxheight{%}{+}number-bins{+}clip-limit{!}。HDRI - 高动态范围成像
GM 中似乎不支持高动态范围成像 - 仅支持 8、16 和 32 位整数类型。
卷积
ImageMagick 支持多种类型的卷积：
GM 源代码中均未提及。
Magick 持久寄存器 (MPR)
这是 ImageMagick 中的一个非常宝贵的功能，它允许您在处理期间将中间处理结果写入指定的内存块，而无需写入磁盘的开销。 例如，您可以准备纹理或图案，然后将其平铺在图像上，或者准备蒙版，然后更改它并稍后在相同的处理中应用它，而无需访问磁盘。
下面是一个示例：
更广泛的色彩空间支持
IM 支持 GM 中未找到的以下色彩空间：
Pango 支持
IM 支持类似于 HTML 的 Pango 文本标记语言，允许您使用可更改的文本来注释图像：
。 这里有一个很好的例子。
使用 JPEG 进行加载收缩
这个宝贵的功能允许库在从磁盘读取 JPEG 图像时收缩它们，这样就只读取必要的系数，从而减少了 I/O，并且内存消耗最小化。 缩小图像时，它可以极大地提高性能。
请参阅此处的示例。
写入 IM 时定义的最大 JPEG 大小
支持在写入 JPEG 文件时指定最大文件大小的广受请求的选项，例如
-define jpeg:extent=400KB。极坐标变换
IM 支持笛卡尔坐标和极坐标之间的转换，请参阅
-歪曲极坐标和-歪曲去极坐标。可自定义区域的统计和操作
通过其
-statistic MxN运算符，ImageMagick 可以生成许多有用的统计数据和效果。 例如，您可以将图像中的每个像素设置为其 5x3 邻域的渐变（最亮和最暗之间的差异）：或者您可以将每个像素设置为其 1x200 邻域的中值：
请参阅应用程序示例 此处。
图像序列
ImageMagick 支持图像序列，因此，如果您有一组在高 ISO 下拍摄的非常嘈杂的图像，您可以加载整个图像序列，例如，取中值或平均值所有图像以减少噪音。 请参阅
-evaluate-sequence运算符。 我并不是指单个图像中周围邻域的中值，而是指找到每个像素位置的所有图像的中值。无论如何，上面的列表并不是详尽的列表，它们只是我在考虑这些差异时首先想到的几件事。 我什至没有提到对 HEIC（Apple 的 iPhone 图像格式）、日益常见的高动态范围格式（例如 EXR）或任何其他格式的支持。 事实上，如果你比较一下这两个产品支持的文件格式（
gm Convert -list format和magick recognize -list format），你会发现 IM 支持 261 种格式， GM支持192。正如我所说，不同的人有不同的看法。 选择您喜欢的一款并享受使用它的乐趣。
一如既往，我感谢 Anthony Thyssen 在 https://www.imagemagick 上对 ImageMagick 的出色见解和演讲。 org/Usage/ 也感谢 Fred Weinhaus 提供的示例。
As with many things in life, different people have different ideas about what is best. If you ask a landscape photographer who wanders around in the rain in Scotland's mountains which is the best camera in the world, he's going to tell you a light-weight, weather-sealed camera. Ask a studio photographer, and he'll tell you the highest resolution one with the best flash sync speed. And if you ask a sports photographer he'll tell you the one with the fastest autofocus and highest frame rate. So it is with ImageMagick and GraphicsMagick.
Having answered around 2,000 StackOverflow questions on ImageMagick over the last 5+ years, I make the following observations...
In terms of popularity...
In terms of performance...
I am happy to concede that GraphicsMagick may be faster for some, but not all problems. However, if speed is your most important consideration, I think you should probably be using either
libvips, or parallel code on today's multi-core CPUs or heavily SIMD-optimised (or GPU-optimised) libraries like OpenCV.In terms of features and flexibility...
There is one very clear winner here - ImageMagick. My experience is that there are many features missing from GraphicsMagick which are present in ImageMagick and I list some of these below, in no particular order.
I freely admit I am not as familiar with GraphicsMagick as I am with ImageMagick, but I made my very best effort to find any mention of the features in the most recent GraphicsMagick source code. So, for Canny Edge Detector, I ran the following command on the GM source code:
and found nothing.
Canny Edge detector
This appears to be completely missing in GM. See
-canny radiusxsigma{+lower-percent}{+upper-percent}in IM.See example here and sample of edge-detection on Lena image:
Parenthesised processing, sophisticated re-sequencing
This is a killer feature of ImageMagick that I frequently sorely miss when having to use GM. IM can load, or create, or clone a whole series of images and apply different processing selectively to specific images and re-sequence, duplicate and re-order them very simply and conveniently. It is hard to convey the incredible flexibility this affords you in a short answer.
Imagine you want to do something fairly simple like load image A and blur it, load image B and make it greyscale and then place the images side-by-side with Image B on the left. That looks like this with ImageMagick:
You can't even get started with GM, it will complain about the parentheses. If you remove them, it will complain about swapping the image order. If you remove that it will apply the greyscale conversion to both images because it doesn't understand parentheses and place imageA on the left.
See the following sequencing commands in IM:
-swap-clone-duplicate-delete-insert-reversefx DIY Image Processing Operator
IM has the
-fxoperator which allows you to create and experiment with incredibly sophisticated image processing. You can have function evaluated for every single pixel in an image. The function can be as complicated as you like (save it in a file if you want to) and use all mathematical operations, ternary-styleifstatements, references to pixels even in other images and their brightness or saturation and so on.Here are a couple of examples:
A StackOverflow answer that uses this feature to great effect in processing green-screen (chroma-keyed) images is here.
Fourier (frequency domain) Analysis
There appears to be no mention of forward or reverse Fourier Analysis in GM, nor the High Dynamic Range support (see later) that is typically required to support it. See
-fftin IM.Connected Component Analysis / Labelling/ Blob Analysis
There appears to be no "Connected Component Analysis" in GM - also known as "labelling" and "Blob Analysis". See
-connected-components connectivityfor 4- and 8-connected blob analysis.This feature alone has provided 60+ answers - see here.
Hough Line Detection
There appears to be no Hough Line Detection in GM. See
-hough-lines widthxheight{+threshold}in IM.See description of the feature here and following example of detected lines:
Moments and Perceptual Hash (pHash)
There appears to be no support for image moments calculation (centroids and higher orders), nor Perceptual Hashing in GM. See
-momentsin IM.Morphology
There appears to be no support for Morphological processing in GM. In IM there is sophisticated support for:
See all the sophisticated processing you can do with this great tutorial.
Contrast Limited Adaptive Histogram Equalisation - CLAHE
There appears to be no support for Contrast Limited Adaptive Histogram Equalisation in GM. See
-clahe widthxheight{%}{+}number-bins{+}clip-limit{!}in IM.HDRI - High Dynamic Range Imaging
There appears to be no support for High Dynamic Range Imaging in GM - just 8, 16, and 32-bit integer types.
Convolution
ImageMagick supports many types of convolution:
None of these are mentioned in the GM source code.
Magick Persistent Register (MPR)
This is an invaluable feature present in ImageMagick that allows you to write intermediate processing results to named chunks of memory during processing without the overhead of writing to disk. For example, you can prepare a texture or pattern and then tile it over an image, or prepare a mask and then alter it and apply it later in the same processing without going to disk.
Here's an example:
Broader Colourspace Support
IM supports the following colourspaces not found in GM:
Pango Support
IM supports Pango Text Markup Language which is similar to HTML and allows you to annotate images with text that changes:
mid-sentence and much, much more. There is a great example here.
Shrink-on-load with JPEG
This invaluable feature allows the library to shrink JPEG images as they are read from disk, so that only the necessary coefficients are read, so the I/O is lessened, and the memory consumption is minimised. It can massively improve performance when down-scaling images.
See example here.
Defined maximum JPEG size when writing
IM supports the much-requested option to specify a maximum filesize when writing JPEG files,
-define jpeg:extent=400KBfor example.Polar coordinate transforms
IM supports conversion between cartesian and polar coordinates, see
-distort polarand-distort depolar.Statistics and operations on customisable areas
With its
-statistic MxNoperator, ImageMagick can generate many useful kinds of statistics and effects. For example, you can set each pixel in an image to the gradient (difference between brightest and darkest) of its 5x3 neighbourhood:Or you can set each pixel to the median of its 1x200 neighbourhood:
See example of application here.
Sequences of images
ImageMagick supports sequences of images, so if you have a set of very noisy images shot at high ISO, you can load up the entire sequence of images and, for example, take the median or average of all images to reduce noise. See the
-evaluate-sequenceoperator. I do not mean the median in a surrounding neighbourhood in a single image, I mean by finding the median of all images at each pixel position.The above is not an exhaustive list by any means, they are just the first few things that came to mind when I thought about the differences. I didn't even mention support for HEIC (Apple's format for iPhone images), increasingly common High Dynamic Range formats such as EXR, or any others. In fact, if you compare the file formats supported by the two products (
gm convert -list formatandmagick identify -list format) you will find that IM supports 261 formats and GM supports 192.As I said, different people have different opinions. Choose the one that you like and enjoy using it.
As always, I am indebted to Anthony Thyssen for his excellent insights and discourse on ImageMagick at https://www.imagemagick.org/Usage/ Thanks also to Fred Weinhaus for his examples.
据我了解，GraphicsMagick 更稳定且更快。
我做了一些不科学的测试，发现 gm 的速度是 im 的两倍（调整大小）。
From what I have read GraphicsMagick is more stable and is faster.
I did a couple of unscientific tests and found gm to be twice as fast as im (doing a resize).
历史
早在 2002 年，由于创始开发人员之间的争议，graphicsmagick 从 imagemagick 中分叉出来。 因此它们共享相同的代码库。
参考：https://en.wikipedia.org/wiki/GraphicsMagick
目标
graphicsmagick< /strong>
imagemagick
除了速度之外，imagemagick 还在终端 shell 中添加了许多 cli 工具，而graphicsmagick 则您可以调用的单个工具。
CLI界面设计
graphicsmagick
imagemagick
恕我直言，我更喜欢（事实上，只使用）graphicsmagick(gm)而不是imagemagick，因为后者有更高的机会工具名称冲突，这会导致在查找某些工具未运行的原因时出现很多问题，尤其是在服务器端自动化任务期间。 总之，graphicsmagick 的设计更加清晰。
想象一个项目中名为convert的二进制文件，它是imagemagick的convert还是您自己的项目中将被调用的滚动工具？
imagemagick 工具列表（包括转换、比较、显示）：https://imagemagick.org/ script/command-line-tools.php
graphicsmagick 命令列表：
http://www.graphicsmagick.org/utilities.html
注意：从 v7 开始正如 Mark S 所提到的，imagemagick 现在作为单个二进制文件分发，并且还支持较旧的 v6 命令。
性能
可以在此处找到简单的内存消耗测试：
https://coderwall.com/p/1l7h-a/imagemagick-bloat-graphicsmagick
依赖关系
GraphicsMagick 依赖于 36 个库，而 ImageMagick 需要 64 个库。参考：http://www. Graphicsmagick.org/1.3/FAQ.html
History
graphicsmagick was forked from imagemagick back in 2002 due to disputes between founding developers. thus they share the same codebase.
Ref : https://en.wikipedia.org/wiki/GraphicsMagick
Goal
graphicsmagick
imagemagick
Other than speed, imagemagick adds a number of cli tools to terminal shell whereas graphicsmagick is a single tool which you can call.
CLI interface design
graphicsmagick
imagemagick
imho, i prefer (in fact, only use) graphicsmagick(gm) over imagemagick as the latter has higher chance of tool name clash, which causes lots of issues in finding out why certain tools are not running, especially during server side automation tasks. in summary graphicsmagick has much clearer design.
imagine a binary called convert in a project and is it imagemagick's convert or your own rolled tool in project that will be called?
list of imagemagick tools (including convert, compare, display) : https://imagemagick.org/script/command-line-tools.php
list of graphicsmagick commands :
http://www.graphicsmagick.org/utilities.html
note : as of v7 as mentioned by Mark S, imagemagick is now distributed as single binary, and also supporting older v6 commands.
Performance
a simple memory consumption test can be found here :
https://coderwall.com/p/1l7h-a/imagemagick-bloat-graphicsmagick
Dependancies
GraphicsMagick depends on 36 libraries whereas ImageMagick requires 64. Ref : http://www.graphicsmagick.org/1.3/FAQ.html
我发现 ImageMagick 处理 TIFF group-4 图像（黑白文档图像）的速度非常慢，主要是因为它需要从每像素 1 位转换为 8 位，然后再转换回来以进行任何图像处理。 GraphicsMagick 小组在其 1.2 版本中彻底修改了 TIFF 格式支持，并且处理这些类型的图像比原始 ImageMagick 快得多。 当前的 GraphicsMagick 稳定版本为 1.3.5。
I found ImageMagick to be incredibly slow for processing TIFF group-4 images (B&W document images), mainly due to the fact that it converts from 1-bit-per-pixel to 8 and back again to do any image manipulation. The GraphicsMagick group overhauled the TIFF format support with their version 1.2, and it is much faster at processing these types of images than the original ImageMagick was. The current GraphicsMagick stable release is at 1.3.5.
当速度不是一个因素时，我使用 ImageMagick。 然而，在每天处理数万张图像的服务器端，GraphicsMagick 的速度明显更快 - 在某些情况下，基准测试速度快了 50%！
I use ImageMagick when speed isn't a factor. However on the server side, where tens of thousands of images are being processed daily, GraphicsMagick is quite noticeably faster - in some cases up to 50% faster in benchmarks!
请注意，GraphicsMagick 提供 API 和 ABI 稳定性，这不是 ImageMagick 保证的一部分。 从长远来看，这很重要，除非您要提供所有依赖项。
Note that GraphicsMagick provides API and ABI stability, which isn't part of the guarantee for ImageMagick. This would be important in the long run unless you are vendoring all your dependencies.
GraphicsMagick 是 Imagemagick 的早期分支。 您可以在 https://imagemagick.org/script/history 中了解 Imagemagick 的历史以及 GraphicsMagick 的分支。 php. Imagemagick 似乎继续得到相当广泛的开发，而 GraphicsMagick 自分叉以来或多或少保持停滞状态。
GraphicsMagick was an early fork from Imagemagick. You can read about Imagemagick's history and the fork to GraphicsMagick at https://imagemagick.org/script/history.php. It seems that Imagemagick has continued to be developed rather extensively, while GraphicsMagick has remained more or less stagnant since the fork.