ImageMagickとGraphicsMagickの違いは何ですか？

Question

私はこれらのライブラリの両方を評価していることに気づきました。 GraphicsMagickの比較によると、ImageMagickはまだ更新されており、2つはほぼ同じように見えます。

私はC++で基本的な画像操作（つまり、画像の読み込み、フィルター、表示）を実行しようとしています。これらのライブラリから選択するときに注意すべき違いはありますか？

Derek Ekins · Accepted Answer

私が読んだことから、GraphicsMagickはより安定していて、より高速です。私はいくつかの非科学的なテストを行い、gmがimの2倍速いことを発見しました（サイズ変更を行います）。

Mark Setchell · Answer

人生の多くのものと同様に、人によって、何が最善かについてさまざまな考えがあります。世界一のカメラであるスコットランドの山々で雨の中をさまよっている風景写真家に聞くと、彼は軽量で耐候性のあるカメラを教えてくれます。スタジオの写真家に聞いてみると、彼は最高のフラッシュシンクロ速度で最高の解像度のものを教えてくれます。また、スポーツ写真家に尋ねると、オートフォーカスが最も速く、フレームレートが最も高い写真家を教えてくれます。つまり、ImageMagickとGraphicsMagickを使用します。

過去5年以上にわたってImageMagickで約2,000のStackOverflowの質問に回答してきたので、次のことを観察します...

人気の観点から...

SO GraphicsMagickの質問の数が12：1の係数で多い（2019年5月の611に対して7,375の質問））に関するImageMagickの質問
SOのImageMagickフォロワー数はGraphicsMagickフォロワー数を15：1上回っています（（2019年5月の25人に対して387人のフォロワー）

パフォーマンスの観点から...

GraphicsMagickの方が速いかもしれませんが、すべての問題ではないことを認めてうれしく思います。ただし、速度が最も重要な考慮事項である場合は、おそらくlibvips、または今日のマルチコアCPUまたはOpenCVなどのSIMD最適化（またはGPU最適化）ライブラリで並列コードを使用する必要があると思います。

機能と柔軟性の観点から...

ここには非常に明確な勝者が1人います-ImageMagick。私の経験では、ImageMagickに存在するGraphicsMagickには多くの機能が欠けています。これらのいくつかを、順不同で以下にリストします。

私はImageMagickほどGraphicsMagickに精通していないことを自由に認めますが、最新のGraphicsMagickソースコードの機能についての言及を見つけるために最善を尽くしました。したがって、Canny Edge Detectorの場合、GMソースコードで次のコマンドを実行しました：

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

何も見つかりませんでした。

キャニーエッジ検出器

これはGMでは完全に欠落しているようです。 IMの-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

fxDIY画像処理オペレーター

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での順方向または逆方向のフーリエ解析についても、それをサポートするために通常必要とされる高ダイナミックレンジのサポート（後述）についても言及されていないようです。 IMの-fftを参照してください。

連結成分分析/ラベリング/ブロブ分析

"Connected Component Analysis" in GM-別名"labelling"および"BlobAnalysis "。4連結および8連結ブロブ分析については、-connected-components connectivityを参照してください。

この機能だけで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は多くのタイプの畳み込みをサポートしています：

GaussiansDoGの違い
ラプラシアン
Sobel
方位磁針
プレウィット
ロバーツ
フライチェン

これらのどれもGMソースコードには記載されていません。

Magick Persistent Register（MPR）

これはImageMagickに存在する非常に貴重な機能であり、ディスクへの書き込みのオーバーヘッドなしに、処理中に中間処理結果を名前付きのメモリチャンクに書き込むことができます。たとえば、テクスチャまたはパターンを準備してから画像上に並べて表示したり、マスクを準備してから変更して、後でディスクに移動せずに同じ処理で適用したりできます。

次に例を示します。

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

より広範なカラースペースサポート

IMは、GMにはない次の色空間をサポートしています。

CIELab
HCL
HSI
LMS
その他。

パンゴサポート

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などのますます一般的になっているハイダイナミックレンジフォーマットのサポートについても触れませんでした。実際、2つの製品（gm convert -list formatとmagick identify -list format）でサポートされているファイル形式を比較すると、IMは261の形式をサポートし、GMは192をサポートしていることがわかります。

私が言ったように、人によって意見は異なります。好きなものを選んで楽しんでください。

いつものように、私はAnthony ThyssenのImageMagickに関する優れた洞察と談話に感謝しています https://www.imagemagick.org/Usage/ 彼の例についてもFredWeinhausに感謝します。

E Brown · Answer

ImageMagickは、TIFFグループ4画像（白黒ドキュメント画像）の処理が非常に遅いことがわかりました。これは主に、1ピクセルあたり1ビットから8に変換し、画像操作を行うために元に戻すためです。 GraphicsMagickグループはバージョン1.2でTIFF形式のサポートを見直し、これらのタイプの画像の処理は元のImageMagickよりもはるかに高速です。現在のGraphicsMagickの安定版リリースは1.3.5です。

Roman Gaufman · Answer

速度が重要でない場合はImageMagickを使用します。ただし、毎日数万の画像が処理されているサーバー側では、GraphicsMagickは非常に高速です。ベンチマークでは最大50％高速な場合もあります。

fmw42 · Answer

GraphicsMagickはImagemagickの初期のフォークでした。 Imagemagickの歴史とGraphicsMagickへのフォークについては https://imagemagick.org/script/history.php で読むことができます。 Imagemagickはかなり広範囲に開発され続けているようですが、GraphicsMagickはフォーク以来多かれ少なかれ停滞しています。

Franklin Yu · Answer

GraphicsMagickはAPIとABIの安定性を提供しますが、これはImageMagickの保証の一部ではないことに注意してください。これは、すべての依存関係をベンダー化していない限り、長期的には重要です。

Jimmy M.G. Lim · Answer

歴史

graphicsmagickは、創設者間の論争のために2002年にimagemagickからフォークされました。したがって、それらは同じコードベースを共有します。

参照： 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のデザインははるかに明確です。

プロジェクトで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