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

StackOverflow https://stackoverflow.com/questions/862051

質問

私はこれらのライブラリの両方を評価していることに気づきました。GraphicsMagick の比較結果とは別に、ImageMagick にはまだアップデートがあり、この 2 つはほぼ同一であるようです。

私は C++ で基本的な画像操作を行おうとしているだけです (つまり、画像のロード、フィルター、表示);これらのライブラリを選択するときに注意すべき違いはありますか?

役に立ちましたか？

解決

私はGraphicsMagickのを読んだものからは、より安定しており、高速です。 私は非科学的なテストのカップルを行なったし、GMは二倍の速イム（サイズ変更を行う）などであることが判明します。

他のヒント

私はImageMagickのは、主として、それが任意の画像操作を行うために再び8に1ビット当たりの画素から変換しているという事実に、TIFFグループ4画像（白黒文書画像）を処理するための非常に遅いことが判明しました。 GraphicsMagickのグループは、彼らのバージョン1.2でTIFF形式のサポートをオーバーホールし、それが元のImageMagickがあったより画像のこれらのタイプを処理ではるかに高速です。現在GraphicsMagickの安定版リリースは1.3.5である。

速度が要因ではないとき、私はImageMagickのを使用しています。しかし、数十の画像の何千ものが毎日処理されているサーバ側、上、GraphicsMagickのはかなり著しく高速です！ - 速いベンチマークでは、いくつかの例では50％まで

人生の多くのことと同様、何が最善であるかについては、人によって考え方が異なります。雨の中、スコットランドの山々を歩き回る風景写真家に、世界で最高のカメラはどれかと尋ねたら、軽量で耐候性のカメラだと答えるでしょう。スタジオの写真家に尋ねれば、最高のフラッシュ同期速度を備えた最高の解像度のものを教えてくれます。スポーツ写真家に尋ねれば、オートフォーカスが最も速く、フレームレートが最も高いカメラを教えてくれるでしょう。ImageMagick や GraphicsMagick も同様です。

過去 5 年以上にわたり、ImageMagick に関する約 2,000 件の StackOverflow の質問に答えてきた私は、次のような観察をしています...

人気という意味では…

  • SO に関する ImageMagick の質問は GraphicsMagick の質問を 12:1 倍上回っています (2019 年 5 月時点では 7,375 件の質問に対し 611 件)。
  • SO の ImageMagick フォロワー数は GraphicsMagick フォロワー数を 15:1 上回っています ((2019 年 5 月時点では 387 フォロワー対 25)

性能的には…

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

機能と柔軟性の面では...

ここには、ImageMagick という明確な勝者が 1 つあります。私の経験では、ImageMagick にはあるのに GraphicsMagick には欠けている機能がたくさんあります。その一部を順不同で以下にリストします。

私は、ImageMagick ほど GraphicsMagick に詳しくないことを率直に認めますが、最新の GraphicsMagick ソース コードにある機能についての言及を見つけるために最善の努力をしました。そこで、Canny Edge Detector の場合、GM ソース コードで次のコマンドを実行しました。

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

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

キャニーエッジ検出器

これはGMには完全に欠けているようです。見る -canny radiusxsigma{+lower-percent}{+upper-percent} IMで。

例を参照 ここ Lena 画像のエッジ検出のサンプル:

enter image description here

括弧内処理、高度な再シーケンス

これは ImageMagick のキラー機能ですが、GM を使用しなければならないときによく見逃してしまうのが残念です。IM は、一連の画像全体をロード、作成、またはクローン化し、特定の画像に選択的にさまざまな処理を適用し、それらを非常に簡単かつ便利に再シーケンス、複製、および再順序付けすることができます。これによって得られる驚くべき柔軟性を短い答えで伝えるのは困難です。

画像 A をロードしてぼかし、画像 B をロードしてグレースケールにして、画像を左側に画像 B と並べて配置するなど、非常に単純なことをしたいと想像してください。ImageMagick を使用すると次のようになります。

magick imageA.png -blur x3 \( imageB.png -colorspace gray \) +swap +append result.png

enter image description here

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

enter image description here

magick -size 80x80 xc: -channel G -fx  'sin((i-w/2)*(j-h/2)/w)/2+.5' -separate fx_2d_gradient.gif

enter image description here

この機能を使用してグリーン スクリーン (クロマキー) 画像の処理に大きな効果を発揮する StackOverflow の回答は次のとおりです。 ここ.

フーリエ（周波数領域）解析

GM における順フーリエ解析や逆フーリエ解析、またそれをサポートするために通常必要とされるハイ ダイナミック レンジのサポート (後述) については言及されていないようです。見る -fft IMで。

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

ないようです 「連結成分解析」 GM では、別名 "ラベリング" そして 「ブロブ分析」. 。見る -connected-components connectivity 4 接続および 8 接続ブロブ分析用。

この機能だけでも 60 以上の回答が提供されています - を参照してください。 ここ.

ハフ線検出

GM にはハフ ライン検出がないようです。見る -hough-lines widthxheight{+threshold} IMで。

機能の説明を参照してください ここ 検出された行の例は次のとおりです。

enter image description here

モーメントと知覚ハッシュ (pHash)

画像モーメントの計算 (セントロイドおよび高次) や GM の知覚ハッシュはサポートされていないようです。見る -moments IMで。

形態学

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

enter image description here

より広範な色空間のサポート

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

  • CIELab
  • HCL
  • HSI
  • LMS
  • その他。

パンゴのサポート

IM は、HTML に似た Pango Text Markup Language をサポートしており、変更されるテキストで画像に注釈を付けることができます。

  • フォント、色、サイズ、太さ、斜体
  • 下付き文字、上付き文字、取り消し線
  • 正当化

文の途中とか、それ以外にも。素晴らしい例があります ここ.

enter image description here

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

応用例を見る ここ.

enter image description here

一連の画像

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/使用法/ 例を挙げてくれた Fred Weinhaus にも感謝します。

歴史

graphicsmagick は、設立開発者間の紛争により、2002 年に imagemagick から分離されました。したがって、同じコードベースを共有します。

参照: https://en.wikipedia.org/wiki/GraphicsMagick

ゴール

グラフィックスマジック

  • シンプルで安定した、より明確なコードベース/アーキテクチャに重点を置いています

イメージマジック

  • 新機能の展開に重点を置き、より幅広いツールベースを拡張する

速度以外にも、imagemagick はターミナル シェルに多数の cli ツールを追加しますが、graphicsmagick は呼び出すことができる単一のツールです。

CLIインターフェイスの設計

グラフィックスマジック

gm <command> <options> <file>

イメージマジック

convert <options> <file>
compare <options> <file>

私は、私のほうが好きです (実際には使用するだけです) imagemagick よりも graphicsmagick(gm) を使用します。後者はツール名が競合する可能性が高く、特にサーバー側の自動化タスク中に、特定のツールが実行されない理由を見つける際に多くの問題が発生します。要約すると、graphicsmagick のデザインはより明確になっています。

プロジェクト内に Convert というバイナリがあると想像してください。呼び出されるのは、imagemagick の Convert ですか、それともプロジェクト内の独自のロールツールですか?

imagemagick ツールのリスト (変換、比較、表示を含む): https://imagemagick.org/script/command-line-tools.php

グラフィックスマジックコマンドのリスト: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

GraphicsMagickのは、ImageMagickのからの早期のフォークでした。あなたは https://imagemagick.org/script/historyではImageMagickの歴史とGraphicsMagickのにフォークについて読むことができます。 PHP に。 GraphicsMagickのフォーク以来、多かれ少なかれ低迷していながら、ImageMagickには、広範囲にかなり開発され続けているようだ。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top