ImageMagick 使用例 -- よく使われる画像フォーマット

ImageMagick 使用例 前書きと索引

よく使われる画像ファイルフォーマットの簡単なまとめ

GIF 画像ファイルフォーマット

• GIF の限られたカラーテーブル
• GIF の透明色
• GIF のブール透明度
• 単色背景の上の GIF
• 背景パターンの上の GIF
• 背景を特定しない GIF (透明度のディザリング)
• ImageMagick 以外による GIF 処理
• GIF オフセットの扱い

• 関連する GIF 出力フォーマット - GIF87

  JPEG 画像ファイルフォーマット

• JPEG 圧縮

• JPEG の透明度 - 不可
• JPEG の色の歪み
• JPEG 画像の読み込み
• JPEG 画像の書き出し
• 関連する JPEG 出力フォーマット (簡単なまとめ)
• ImageMagick 以外による JPEG 処理 (簡単なまとめ)

• ロスレス JPEG 処理

  PNG 画像ファイルフォーマット

• PNG 圧縮

• PNG のより良い圧縮
• PNG・Web ブラウザ・透明度
• PNG と仮想キャンバス
• PNG の解像度・密度・単位
• PNG サブフォーマット
• PNG 画像の書き出し制御

• ImageMagick 以外による PNG 処理

  画像プロファイル

• 画像の色空間を変える -- RGB <=> CMYK 変換

• IPTC プロファイル

  ベクター画像フォーマットについて一言 その他の画像ファイルフォーマット

  Postscript (PS), Encapsulated PS (EPS), PDF,
  PbmPlus/NetPBM (PBM, PGM, PPM, PNM, PAM),
  TIFF, BMP, ICO, RAW デジタル画像 (CRW,CR2,など),
  MPEG, M2V, AVI, MNG, Digital Picture Exchange (DPX),
  PSD, WMF, MacroMedia Flash (SWF),
  Web ページの HTML 変換, PCL 印刷フォーマット,
  Kodak PhotoCD フォーマット (PCD), Raw RGB データ, 画像ファイルフォーマットの多くには、そのフォーマットを使うときに頭に入れておくべき特有の事情があります。このページではそうした特別な事情と、それらのフォーマットで結果を改善する方法を扱います。

よく使われる画像ファイルフォーマットの簡単なまとめ

画像フォーマットの読み書きの入門については 画像ファイルフォーマット を参照してください。一方、ImageMagick のすべてのファイルフォーマットの一覧は IM 画像フォーマットのページ にあります。ここでは、最もよく使われる「普通の」画像ファイルフォーマットと、その一般的な長所・短所をごく手短にまとめます…

GIF

このフォーマットは非常に一般的で、あまりにも長く存在してきたため、すべての画像処理プログラムが理解できます。しかし限られた数の色(256 色のカラーテーブル)しか使えず、8 ビット品質でしか保存できません。とはいえ組み込みのランレングス符号化のおかげで、少数の色しか持たない画像を非常に効率良く保存できます。このフォーマットには透明度がありますが、ブール(オン/オフ)の透明度しか理解できないため、結果として「エイリアシング」や「ジャギー(ギザギザ)」に悩まされます。細い線を含むプレーンテキストは、透明 GIF 画像として保存するとひどい結果になります。この問題への唯一の解決策は、GIF 画像を、それが使われる Web ページの特定の背景に結び付けることです。GIF フォーマットは複数の画像を保存してアニメーションのシーケンスを作ることができ、この目的のために画像のキャンバスサイズとオフセット(ページ)情報も保存します。ただし負のオフセットはサポートされておらず、それを試みるとそのオフセットはゼロにリセットされます。アニメ風の絵、線画、小さなアイコンなど、色数が限られていて圧縮がよく効くような小さな画像に最適です。しかし PNG のような新しいフォーマットが使えるときには、その使用は避けるべきです。

JPEG

透明度をまったく扱えません。画像は「[-alpha off](https://imagemagick.org/command-line-options/#alpha)」操作でアルファチャンネルを除去したものと等価であり、そのため画像生成に使った処理によっては、背景の透明部分は一般に黒になります。このフォーマットはまた「ロッシー(非可逆)」で、シャープな線や境界にエッジ効果を生じるため、途中の画像処理や、オリジナル画像の保存(すでにこのフォーマットだった場合を除く)には使うべきではありません。実写の写真を長期保存するのには適していますが、画像をさらに処理する予定がある場合や、画像に広い単色領域が含まれる場合には避けてください。

PNG

このフォーマットは、最終的に GIF や TIFF などの古いフォーマットを置き換えることを意図しています。16 ビット品質を 4 色チャンネルで扱える現代的なフォーマットで、半透明の色を完全に活用できます。膨大な数のロスレス画像圧縮オプションも含んでいます。最大の欠点は、まだ比較的新しいため、Microsoft IE (v6) Web ブラウザが自動的には正しく扱えないことです。しかしこの問題への修正は利用できます。このフォーマットはキャンバスサイズ情報を保存しません(GIF は保存します)が、キャンバスオフセットは保存し、負のオフセットすら保存します(GIF はしません)。ただし一部の Web ブラウザは負のオフセットが使われていると問題を起こすため、ブラウザで表示する最終画像にはおすすめしません。途中段階の「レイヤー」画像を保存する場合には、負のオフセットを保存できることが非常に重要なことがあり、キャンバスサイズ情報を保存しないことよりもしばしばずっと重要です。

MNG

これは PNG のマルチ画像フォーマットで、ムービー品質のレベルと速度のアニメーションを可能にします。MNG を使った簡単な例が欲しいので、お持ちでしたらメールしてください。 MNG アニメーションフォーマットは陳腐化しつつあるようで、FireFox などの一部の Web ブラウザでは見捨てられています。

TIFF

これは、まともな画像フォーマットがまだ存在しなかった時代に、高品質な画像をプログラム間で転送するために開発された画像交換フォーマットです。残念ながら、この出自のため、このフォーマットは無秩序な機能と圧縮スタイルの寄せ集めで改変され続けてきて、それらすべてを理解できるプログラムはありません。このフォーマットは今では実質的に Windows プラットフォーム上の「[Photoshop](http://www.adobe.com/products/photoshop/)」でしか使われておらず、それが TIFF 画像フォーマットについて何らかの標準的な参照を提供する唯一の出所です。TIFF ファイルは複数の画像を扱えますが、IM 以外でマルチ画像 TIFF を扱えるアプリケーションはほとんどありません。一般に、TIFF 画像の内部フォーマットを比較的基本的なものに保たない限り、あるプログラムが生成した TIFF ファイルが別のプログラム(IM や「[Photoshop](http://www.adobe.com/products/photoshop/)」自身を含む)で使えるという保証はありません。そのため、このフォーマットは断じておすすめしません! 特に画像を長期保存する場合は、TIFF (や JPEG) 以外の何か別のフォーマットを使うことをおすすめします。このフォーマットとその問題に関する私のわずかな覚え書きは、以下の その他のフォーマット, TIFF のセクションに掲載しています。これらの使用上の覚え書きは IM のメーリングリストやフォーラムで見つけたものです。私自身は TIFF を使わない、あるいは使う必要がないためです。

ビデオフォーマット

その他のムービー品質のアニメーションフォーマットは、一般にロッシー圧縮を使ってムービーのサイズ(と品質)を減らすことに基づいています。どちらのフォーマットも常に流動的で、改良やセキュリティ上の制限機能が加わるため、何らかの形の処理を難しくしています。最後に数えたときには、何らかの目的で一般に使われる 200 を超えるビデオフォーマット「コーデック」がありました。このため IM はこのフォーマットを直接扱わず、代わりに個々のフレームのアニメーションへの出し入れの処理を、他のソフトウェアパッケージに頼っています。これらの「デリゲート」プログラムには「mpeg2decode」「mpeg2encode」「mplayer」などがあります。下の MPEG, M2V, AVI を参照してください。

| 一部のシステム(ubuntu など)では、セキュリティポリシーを使って特定の画像ファイルフォーマットの使用を無効化しています。magick -list policy と入力すると、どのようなポリシーがあり、どこで設定されているかが分かります。
---|---

GIF 画像ファイルフォーマット

GIF フォーマットは非常に広く知られた画像ファイルフォーマットで、とてもとても長い間(1980 年代後半から)存在してきました。透明度や画像アニメーションを伴う、Web ページで表示する画像によく選ばれます。また、すべての Web ブラウザがほぼ普遍的に理解できる、ほとんど唯一のフォーマットでもあります。残念ながら、線画、図、ダイアグラム、アニメ風の絵以外には、あまり良いフォーマットではありません。なぜなら、最大 256 色に限られており、そのうち 1 色は通常透明としてフラグが立てられるからです。画像内の特定の 1 色を透明としてフラグ付けすることには、いくつかの欠点があります。透明にする色の選び方が悪いと、意図しない部分まで透明になってしまうことがあります。そうならないよう注意が必要です。さらに、透明度の能力は「ブール」、つまり基本的に完全にオンか完全にオフのどちらかです。半透明の色はまったく不可能で、もし存在すれば透明か不透明のどちらかにする必要があります。つまりこのフォーマットは、画像のエッジに何らかのアンチエイリアスを施すことができず、たいていひどい「ジャギー」を生じます。(アンチエイリアス を参照)。「GIF」画像フォーマットの色の制限は、特に ImageMagick のような高品質な画像処理パッケージから見ると、あまりに多くの問題を引き起こすので、まず初めにこう言っておきたいと思います…

可能な限り GIF フォーマットを避けてください。
どうしても使わなければならない場合は、最終ステップとしてのみ使ってください。

最後に、長い間、GIF が使う圧縮アルゴリズムは特許で保護されていました。そのため、ImageMagick のような多くの画像処理プログラムでは使えませんでした。したがって、非常に古い IM のプログラムは GIF フォーマット画像を非圧縮で出力するため、本来よりも多くのディスク容量を使っていました。これは「**[Gifsicle](http://www.lcdf.org/gifsicle/)**」や「**[InterGIF](http://utter.chaos.org.uk/~pdh/software/intergif.htm)**」のような GIF 一括圧縮プログラムを使って修正できます。しかし特許は 2004 年半ばに完全に失効したため、現在リリースの IM では GIF 画像圧縮が再び有効になっています。画像圧縮はかなり単純なもので、広い面積の変化しない単色領域を持つ画像で最もよく効きます。あるいは、順序付きディザリング(IM のデフォルトのディザではありません)で得られるような、同じ色の組の単純な繰り返しパターンに対しても効きます。最後に、GIF 画像は 1 つのファイルに複数の画像を保存できます。これは GIF アニメーション を生成するために使われ、この技法が非常に古い「Netscape」ブラウザで最初に導入されて以来、ほぼすべての Web ブラウザが理解します。まとめると GIF 画像ファイルフォーマットは、限られたカラーテーブル、ブール透明度、単純な圧縮(有効な場合)を持ち、サムネイル、とりわけ広い単色領域を持つ「アニメ風」のアイコン、ロゴ、シンボル画像のような小さな画像に理想的です。そのアニメーション能力により、World Wide Web のあちこちで目にする派手で人目を引くロゴや広告を生成するのにも理想的な方法となっています。それ以外のものについては、その制限のためお粗末な画像ファイルフォーマットであり、JPEG、PNG、あるいはビデオ画像フォーマットに移行したほうが良いかもしれません。

GIF の限られたカラーテーブル

FUTURE: color reduction examples -- reference basic color dithering
Ensuring that a specific color is present in the final GIF image
Map color tables to color reduce.
See [Color Quantization](quantize.html#colors).

ある範囲の色にわたる複数の画像を生成する例については、高度な 3-D 弾丸スクリプティング を参照してください。この技法は、画像を多数の異なる背景色やパターン向けに複数の画像へと自動変換するのにも使えます。

GIF の透明色

たとえばここでは、identify を使って、ある GIF 画像ファイルが透明度を表すために使っている透明色とカラーテーブルを抽出します。perl スクリプトは、関心のある特定のフィールド(複数行になり得る)だけを抽出します。 | |

  magick identify -verbose hand_point.gif |\
      perl -0777 -ne 's/^  //gm; \
            print $& while /^(Colors|Alpha|Colormap):.*?(?=^\S)/gms'

|

ご覧のとおり、この画像には透明な灰色 ('#CCCCCC00') が使われており、この色はカラーテーブル内に独自の別エントリを持っています。また、この画像は 5 色(うち 1 つは透明)しか使っていないのに、使われているカラーテーブルは 8 色分であることも分かります。それは、GIF ファイルフォーマットが 2 のべき乗のサイズのカラーテーブルしか使えないからです。つまりカラーテーブルは常に 2、4、8、16、32、64、128、256 色のいずれかのエントリ数になります。そのため、カラーテーブルの最後の 3 エントリは使われていません。実際には単に参照されていないだけです。場合によっては、これらの未使用エントリはカラーテーブルの最後の 3 つとは限らず、実際には任意の色値を含むことがあります。重複した色値を持つこともできますが、IM は画像を何らかの形で処理すると、通常そうした重複した色エントリを取り除きます。IM バージョン 6.2.9-2 以降(および一部の古いバージョン)では、IM は GIF 画像を読み込み・処理・書き出しするとき、カラーテーブル、より具体的には透明色の値を保持します。 | |

  magick hand_point.gif    -fill white -opaque wheat   hand_white.gif
  magick identify -verbose hand_white.gif |\
      perl -0777 -ne 's/^  //gm; \
            print $& while /^(Colors|Alpha|Colormap):.*?(?=^\S)/gms'

|

ご覧のとおり、画像が変更されても(すべての 'wheat' 色のピクセルが 'white' 色に置き換えられた)、使われていた透明色は保持されました。しかし、最終画像に透明度がない場合は、カラーテーブル内の透明色エントリ('Alpha:')は完全に取り除かれます。 | |

  magick hand_point.gif   -background white -flatten    hand_flatten.gif
  magick identify -verbose hand_flatten.gif |\
      perl -0777 -ne 's/^  //gm; \
            print $& while /^(Colors|Alpha|Colormap):.*?(?=^\S)/gms'

|

GIF ファイルフォーマットが使う透明色を変えたい場合は、「[-transparent-color](https://imagemagick.org/command-line-options/#transparent-color)」出力設定(IM v6.2.9-2 で追加)を使えます。たとえば… | |

  magick hand_point.gif -transparent-color wheat  hand_wheat.gif
  magick identify -verbose hand_wheat.gif |\
      perl -0777 -ne 's/^  //gm; \
            print $& while /^(Colors|Alpha|Colormap):.*?(?=^\S)/gms'

|

GIF のブール透明度

GIF フォーマットは半透明の色を理解せず、ImageMagick はデフォルトで通常の アンチエイリアス手法 の一環として半透明の色を生成するため、画像をこのフォーマットで保存すると、しばしばひどい見た目になります。たとえばここでは、透明な背景の上に単純な黒い円を描きます。また、何が起きているかを分かりやすくするため、画像のエッジを拡大表示したものも生成します。まず PNG フォーマットで出力します… |

  magick -size 60x60 xc:none -fill white -stroke black \
          -draw 'circle 30,30 5,20' circle.png
  magick circle.png -crop 10x10+40+3 +repage  -scale 600%  circle_mag.png

ご覧のとおり、左に描かれた円(PNG フォーマット)のエッジは、画像に対して非常にきれいな(少しぼやけてはいますが)エッジになっています。その拡大図で半透明のピクセルが見えます。では同じ画像を「GIF」画像フォーマットで出力してみましょう… |

  magick -size 60x60 xc:none -fill white -stroke black \
          -draw 'circle 30,30 5,20' circle.gif
  magick circle.gif -crop 10x10+40+3 +repage  -scale 600%  circle_mag.gif

その結果、円の外側のエッジに沿って非常に鋭い階段状の効果が生じ、一方で内側は適切にアンチエイリアスされたままです。基本的に PNG フォーマットは半透明のピクセル情報を保存できますが、GIF はできません。GIF 画像フォーマットは、単一の純粋な透明色しか保存できません。言い換えると…

GIF フォーマットはオン/オフ、つまりブールの透明度を持つ

結果の GIF をもっとよく見ると、半透明のピクセルが完全透明になったか完全不透明になったかのどちらかになっていることが分かります。 | _半透明のピクセルに対して ImageMagick が実際に何をするかは、使っている IM のバージョンによります。長い間それは適切に定義されておらず、あるバージョンの挙動は、ユーザーからのバグ報告によって適用された最後の「バグ修正」にしばしば依存していました。

v6.2.9-6 以降、ImageMagick はデフォルトで GIF と XPM の画像フォーマットの両方について、画像を 50% のレベルでしきい値処理するはずです。これは画像ハンドラで使われる受け入れられた標準となっていますが、GIF ファイルフォーマットの透明度の問題に対処する独自の方法を設定することもできます。
---|---
| _GIF の制限のため、IM は GIF ファイルフォーマットへ保存する前に、以下の一連の操作を行います…

_-channel A -threshold 50%
    (完全)透明なピクセルが存在する場合は、続いて…
      -quantize transparent -colors 255
    そうでなく透明なピクセルが存在しない場合は…
      -colors 256_

_-colors の量子化処理は、それ以上の色が画像に存在しない場合は自動的に何もしません。また、画像が(「+/-map」で割り当てられた)有効なカラーマップを持つ場合も何もしません。

これはまた、マルチ画像 GIF ファイルに対して共通のカラーマップを使おうとはしません。そのため、あるフレームから次のフレームへ色が大きく異なる場合は、GIF ファイルフォーマットに保存される個々の画像それぞれにローカルカラーテーブルが追加されることがあります。

また、上記で使われる設定は永続的ではなく、保存される画像に対する一時的なものです。つまり、「-write image.gif」を使った場合、その処理中に使われた設定は後続の操作に影響しません。_
---|---
しきい値処理を自分で行いたいこともあるでしょう。これは、どのバージョンの IM(特に古いバージョン)を使っているか定かでない場合におすすめです。 |

  magick -size 60x60 xc:none -fill white -stroke black \
          -draw 'circle 30,30 5,20' \
          -channel A -threshold 50%  circle_threshold.gif
  magick circle_threshold.gif -crop 10x10+40+3 +repage \
          -scale 600%   circle_threshold_mag.gif

上の例は、IM が今では自動的に行うのと同じ「[-threshold](https://imagemagick.org/command-line-options/#threshold) 50%」をアルファチャンネルに対して実行します。つまり、ピクセルが 50% より透明であれば完全透明にします(定義されていれば「[-transparent-color](https://imagemagick.org/command-line-options/#transparent-color)」設定で与えられた色を使います)。ただし、しきい値レベルを好きなように制御できます。アルファチャンネルを 50% でしきい値処理するのは、ほとんどの種類の画像、特に単純なエッジを持つ画像でうまく機能しますが、半透明ピクセルの広い領域を扱う必要がある場合には、この技法はかなりひどく破綻します。これがこれから続く GIF の扱いに関するほとんどの例で見ていくことです。たとえば、こうした ぼやけた半透明の影 を持つ画像(PNG フォーマット)を保存したいとします… |

  magick -size 70x60 xc:none -font Candice -pointsize 50 \
          -fill black -annotate +10+45 'A' -channel RGBA  -blur 0x5 \
          -fill white -stroke black -draw "text 5,40 'A'"   a.png

この文字を直接 GIF フォーマットに変換したり、ブール透明度を制御するために「[-threshold](https://imagemagick.org/command-line-options/#threshold)」操作を使ったりすると、ひどくがっかりすることになります。 |

  magick a.png  a.gif
  magick a.png -channel A -threshold 75%   a_threshold.gif

最初の画像は GIF フォーマットへの通常の保存で、ご覧のとおり半透明のピクセルを '50%' でしきい値処理しています。2 番目の画像は '75%' でしきい値処理し、より多くの半透明ピクセルが完全不透明(つまり可視)になるようにしています。すべての半透明ピクセル(例: 影)を取り除きたいだけなら、「-threshold 15%」のようなものを試して、ほぼすべての半透明ピクセルを取り除くことができます。 |

  magick a.png -channel A -threshold 15%   a_no_shadow.gif

GIF のブール透明度問題に対するその他のほとんどの解決策は、画像を、それが置かれる Web ページの背景色に分かちがたく結び付けることです。これを行う方法は複雑でやっかいで、これからそれを見ていきます。 単色背景の上の GIF 本当にしたいのは、半透明やアンチエイリアスされたピクセルの陰影を何とか保ちつつ、WWW 上できれいに表示することです。これを行うには、少し小細工が必要です。典型的な解決策は、画像を表示する予定の背景に画像を合わせることです。これは簡単で、GIF フォーマットに保存する前に、画像を適切な色の背景の上に重ねるだけです。これにより何らかの透明度の必要がなくなり、全体が問題にならなくなります。もちろん色数が限られていることは依然として問題ですが、しばしば大きな問題にはなりません。 |

  magick a.png -background LightSteelBlue -flatten  a_overlay.gif

ほぼ完璧でしょう! もちろんこの方法が正しく機能するには、画像が使われる背景色が正確に分かっている必要があります。また、終わったあとの画像は他のどんな背景でもあまり役に立ちません。大きな犠牲です。 背景パターンの上の GIF しかし、単純な単色ではなく、何らかのパターンを背景に使っている場合はどうでしょう? 結果の画像内のパターンが Web ページのパターンと一致するように、重ねた画像を背景パターンのコピーの上に配置してみることもできます。しかしそれには、画像内の背景を Web ページと一致させるのに、たくさんの試行錯誤が必要でしょう。また、特定のブラウザの、それも特定のバージョンでしか機能を保証できません。Web ページにとって良い考えではないので、試そうとさえしないでください。私は決してしません。背景パターンとの完璧な一致を試みる代わりに、少なくとも使う予定の背景に一致する色の上に画像を重ねましょう。たとえば、画像を「典型的な」泡のような背景パターンの上に重ねるとします。しかしまず、この背景の平均色を知る必要があります。この色を見つける簡単な方法は、画像を単一のピクセルまで 縮小 し、結果の色を読み取ることです。

  magick bg.gif -scale 1x1\! -depth 8 txt:-

   [![\[IM Text\]](../static/img/formats/bg_color_avg.txt.gif)](../static/img/formats/bg_color_avg.txt)

使われている特殊な「txt:」出力フォーマットについての詳細は、IM ピクセル列挙テキストフォーマット を参照してください。では「[-flatten](https://imagemagick.org/command-line-options/#flatten)」を使って画像の背景透明度を設定しましょう。 |

  magick a.png  -background '#BABBD7' -flatten  a_bg.gif

| |

その背景は画像自体の一部ではないにもかかわらず、画像をその背景の上に重ねるように Web ページを設定しました。使った背景色は背景パターンの全体的な色には一致しましたが、その周りには背景パターンを欠いた、非常に目立つ単色の矩形が依然として残っています。実用的な解決策の 1 つは、重ねた色を GIF 出力の「[-transparent](https://imagemagick.org/command-line-options/#transparent)」色として宣言することです。こうすることで、画像の「四角さ」を取り除きます。また、小さな ファズ係数 を加えると結果が改善し、上のしきい値処理と同じように、透明色が使う空間の量を調整できます。 |

  magick a.png  -background '#B9BBD6' -flatten \
          -fuzz 5%   -transparent '#B9BBD6'   a_bg_trans.gif

| |

これは通常、ほとんどの GIF 画像で透明度を扱うのに十分良い結果ですが、画像を特定の背景色に結び付けてしまいます。本質的に、これは真の透明度ではなく、画像に基本的な輪郭の形を与えるために透明度を使っています。重ねる色と GIF の透明度に背景パターンに一致する色を使うことで、画像がどこで終わって背景パターンがどこから始まるかが、もはや明確でなくなります。
ただし「[-fuzz](https://imagemagick.org/command-line-options/#fuzz)」設定には注意してください。大きすぎると、画像の外側だけでなくそれ以上が透明になってしまうことがあります! |

  magick a.png  -background '#B9BBD6' -flatten \
          -fuzz 25%  -transparent '#B9BBD6'   a_bg_overfuzz.gif

| |

画像自体の中に背景色に近い色を使った場合にも失敗します。そのため、この技法は一般的な画像には おすすめしません が、特定の場合にのみ使えます。この問題を解決するには、'[-alpha floodfill](draw.html#alpha)' を使って透明にしたい領域を設定します。 |

  magick a.png  -background '#B9BBD6' -flatten \
          -fuzz 25%  -draw 'fill none alpha 0,0 floodfill' a_bg_none.gif

| |

これで、画像の境界が「漏れ」ない限り、画像の内部に背景と似た色を使っても、「過剰なファズ」のためにそれらが透明になることはありません。もちろん、画像に「穴」がある場合は、その穴も処理する必要があります。その場合は、前の「ファズ付き透明度」のほうがうまく機能するかもしれません。GIF の透明色を扱うのは簡単だと言いましたっけ? とんでもない!
特にシャープなアンチエイリアスされたエッジを持つ画像向けの別の技法は、背景色の最小限のアウトラインを単に加えることです。アウトラインまたはハロー透明度 を参照してください。
背景色を取り除く… 既存の GIF 画像から特定の背景色を取り除こうとするのは簡単ではありません。重ねられた画像も背景色を含む場合は特に難しく、その場合どこが背景でどこがそうでないかが本当には分かりません。最良の解決策は、同じ GIF の重ね画像を、2 つの異なるよく分かった背景色の上に重ねたコピーを入手することです。そのような 2 つの画像があれば、元の重ね画像とそのすべての半透明ピクセルを完璧に復元できます。2 つの背景を使った背景除去 を参照してください。そのような 2 つの画像がない場合は、画像の半透明度を完璧には復元できませんが、完璧ではないものの妥当な仕事をする技法はあります。これについては 背景除去 の他のセクションを参照してください。
背景を特定しない GIF (または透明度のディザリング)

FUTURE: This will move into a more generalise (non-GIF specific), alpha
dithering section.

上記の最大の問題は、画像が使われる背景や背景パターンの色が正確に分かっている場合にしか機能しないことです。それが分からなくても、すべてが失われるわけではありません。上で見たように、しきい値処理は、ぼやけた影のような非常に広い透明領域を持つ画像ではうまく機能しません。しかし、ディザリングとして知られる別の技法はうまく機能し、しかも使われる背景についての知識を必要としません。基本的に、ディザリングは透明度をオン/オフの値に制限し、ピクセルのパターンを使って、より広い領域にわたる半透明の効果を作り出します。言い換えると、半透明を偽装します。この方法は、今では「オポッサムの例」として知られるもので示されました。残念ながら、これらの例では実際に使われたコマンドが示されていませんでした。完全を期すため、ここでもう一度それらを実演してみます。「[-monochrome](https://imagemagick.org/command-line-options/#monochrome)」演算子は、画像のすべての色を純粋な白黒の「フロイド-スタインバーグ誤差補正ディザ」に変換します。しかし、これはグレースケール画像を純粋な白黒の色だけに変換するので、画像からアルファチャンネルのマスクを抽出し、それをディザし、それを画像に戻す必要があります。 |

  magick a.png \( +clone -fx a -alpha off -monochrome \) \
          -compose CopyOpacity -composite   a_dither.gif

同様に、「[-channel](https://imagemagick.org/command-line-options/#channel)」設定を使ってアルファチャンネルだけに限定できる(「[-monochrome](https://imagemagick.org/command-line-options/#monochrome)」と違って)他のディザ演算子もいくつかあります。

  magick a.png -channel A -ordered-dither   o2x2   a_ordered_2x2.gif
  magick a.png -channel A -ordered-dither   o3x3   a_ordered_3x3.gif
  magick a.png -channel A -ordered-dither   o4x4   a_ordered_4x4.gif

  magick a.png -channel A -ordered-dither  checks  a_halftone_2.gif
  magick a.png -channel A -ordered-dither  h4x4a   a_halftone_4.gif
  magick a.png -channel A -ordered-dither  h6x6a   a_halftone_6.gif
  magick a.png -channel A -ordered-dither  h8x8a   a_halftone_8.gif


  magick a.png -channel A -random-threshold  5x95% a_random_5x95.gif

  magick a.png -channel A -random-threshold  5x70% a_random_5x60.gif

  magick a.png -channel A -random-threshold 50x95% a_random_50x95.gif

  magick a.png -channel A -random-threshold 45x55% a_random_45x55.gif
  magick a.png -channel A -random-threshold 50x50% a_random_50x50.gif

ご覧のとおり、「[-ordered-dither](https://imagemagick.org/command-line-options/#ordered-dither)」は、全体的な透明度を表すために透明と不透明の色のパターンを生成します。しかしこれは非常に目立つ規則的なパターンを生じます。とはいえ、通常の背景に似ているがそれより暗い影の色を使えば、このパターンをほぼ完全に見えなくできます。'checks' パターン(2 行目の最初の画像)は特に興味深く、非常にシンプルで、とてもきれいで整った 3 レベルのパターンです。 | _「[-ordered-dither](https://imagemagick.org/command-line-options/#ordered-dither)」は IM v6.2.8-6 で「ハーフトーン」ディザパターンが拡張されました。この演算子はその後 IM v6.3.0 で名前付きディザパターンとともに完全に改訂されました(完全なリストを見るには「[-list](https://imagemagick.org/command-line-options/#list) threshold」を使ってください)。他の特殊効果を生成するために、独自のディザパターンを生成することすらできます。詳細は 順序付きディザリングの例 と 順序付きディザのアップグレードに関する覚え書き を参照してください。

この再開発の前は、引数はジオメトリ文字列 '2x2'、'3x3'、'4x4'(これらは今でも機能します)しか使えませんでした。しかし、それ以外のものは「[-random-threshold](https://imagemagick.org/command-line-options/#random-threshold)」の引数として扱われ、たいてい悲惨な結果になりました。ごく古いバージョンの IM でこのオプションを使う場合は注意が必要です。
---|---
一方「[-random-threshold](https://imagemagick.org/command-line-options/#random-threshold)」は、実行のたびに異なる、非常に変動の大きいランダム化されたディザを生成します。しかし、このディザアルゴリズムの純粋にランダムな性質は、「フロイド-スタインバーグ」の「[-monochrome](https://imagemagick.org/command-line-options/#monochrome)」演算子が生成する、より滑らかでアルゴリズム的に配置されたディザリングよりも、ピクセルの大きな「塊」を生じがちです。しかし「[-random-threshold](https://imagemagick.org/command-line-options/#random-threshold)」の大きな利点は、提供される制限の制御です。パラメータを非常に厳しく(たとえば '50x50%')することで、「[-random-threshold](https://imagemagick.org/command-line-options/#random-threshold)」を単純な「[-threshold](https://imagemagick.org/command-line-options/#threshold)」演算子に変えられます。少しだけ制限を緩めることで、しきい値の限界のごく端だけをランダム化できます(たとえば '45x55%' を使う)。 | 「[-random-threshold](https://imagemagick.org/command-line-options/#random-threshold)」の引数は 'PxQ' で、P は最小しきい値、Q は最大('%' 記号は必須)です。つまり "5x95%" は、MaxRGB の 5% 未満なら 0 に設定し、95% を超えるなら MaxRGB に設定し、それ以外なら MaxRGB の 5% から 95% の間のランダムな値を、そのピクセルに使うしきい値レベルとして選ぶ、という意味です。"5x95%" という値が、ほとんどの状況でおそらく最良の値です。_
---|---
影の色に黒の代わりに、より暗い中間調の色(暗い灰色など)を使うことで、最終的な見た目を改善できます。こうすることで、色が背景により溶け込みがちになり、ディザが上で示したものよりも目立たなくなります。背景色がおおよそ分かっているなら、その色合いの暗めの色を使うことすらでき、特定の背景の色合いに縛られることなく、影を背景になじませられます。いわば 2 つの方法を少し混ぜて、全体的な結果を改善するわけです。基本的に、やりたいことに手間をかければかけるほど、結果は良くなります。

FUTURE: dither example with a dither color matching the light blue background
of this web page.

GIF 画像オフセットの扱い

GIF フォーマットは画像アニメーションの扱いの一環としてオフセット付きで画像を保存しますが、負のオフセットは保存しません。GIF 画像に負のオフセットを保存しようとすると、オフセットはゼロにリセットされます。これは GIF 画像アニメーションを設計する際に本当に困りものになり得ます。Internet Explorer Web ブラウザに、「ページオフセット」によって画像が「ページキャンバスサイズ」の外側のどこかに配置される GIF 画像が与えられると、それはページサイズとオフセットを無視し、そのようなオフセットがないかのように表示します。一方、古めかしい Mozilla Web ブラウザは、画像のキャンバスをただ表示し、画像にオフセットを適用します。これは、画像データが存在しない空のキャンバスが表示される結果になることがあり、それは正しいのですが、予想外のことがあります。どちらも、画像がそのページキャンバス上に完全に収まる場合は、適切なページオフセットとともにページキャンバスサイズを使って画像を表示します。

関連する GIF 出力フォーマット

GIF87: 画像を古い GIF 87a フォーマットで出力します。

「Mozilla」Web ブラウザがこの古いフォーマットを見ると、画像のページジオメトリを完全に無視し、より大きな「ページ」フレームを使ったり、画像とともに画像オフセットを使ったりしません。IM バージョン 6.0.4 以前は通常 GIF89a フォーマットを生成していました。しかし画像が GIF アニメーションで、+adjoin を使って個別の画像に分割された場合、IM は GIF87a を使い、Web ブラウザで表示すると一貫しない結果になりました。v6.0.4 より後の IM は、ユーザーが古い「`GIF87:`」出力フォーマットを明示的に要求しない限り、常に GIF 89a 画像フォーマットファイルを生成します。

JPEG 画像ファイルフォーマット

このフォーマットは上記の GIF フォーマット と同じくらい一般的です。しかし GIF が小さな単純な「アニメ風」の画像を念頭に置いて設計されているのに対し、JPEG は、写真のような、たくさんの異なる色や色の濃淡を持つ大きな実写画像向けに設計されています。JPEG ファイルフォーマットの主要な特徴はその圧縮で、画像を人間の目に許容できる状態に保ちつつ、画像サイズを減らします。これは非常に複雑な処理で、ここでの議論の範囲を超えています。この処理とその効果についての詳しい情報は、Jpeg 圧縮入門 を参照してください。また、YouTube ビデオ JPEG DCT, Discrete Cosine Transform (JPEG Pt2)- Computerphile には素晴らしく詳細な説明があります。残念ながら、画像をうまく圧縮するために、このアルゴリズムは意図的に情報を 失います。保存されるのは、メモリ内にあるのと同じ画像では ありません。画像内の特定のピクセルや領域の色は、一般に、保存された色とまったく同じ色には なりません。これは画像内のオブジェクトのエッジ付近で特に顕著です。そこで手短に警告しておくと…

IM は画像を変更するための汎用ラスター画像プロセッサです。
ロスレスな JPEG 変更は行いません。

ロスレスな扱いに興味があるなら、IM 以外による JPEG の扱い を参照してください。
このロッシーな挙動は、JPEG 画像が変更されて上端や左端の境界の変化量が 8 の倍数でなくなると、さらに目立つようになります。これが起きると、JPEG 圧縮の「ブロック」や「セル」が完全に変わり、最終的な画像の保存サイズが大きく増えることがあります。つまり、chop、trim、shave、border、frame、extent などの操作(切り出しと境界付けの操作 を参照)で、8 でないピクセルオフセットだけ画像データをずらすような操作です。詳細は IM フォーラムの議論 Cropping an image result in an unexpected increased file を参照してください。
通常、この JPEG データの ロッシー な性質はあまり目立ちません。しかし、JPEG 画像を複数回読み込んで保存したり、シャープな色変化を示す図に対して非常に低い品質を使ったりすると、目立つことがあります。とはいえ、JPEG 画像を何度も読み込んだり再利用したりしない(元の出所から操作を保ち適用する)限り、JPEG が特に得意でない画像タイプであっても、依然として良いファイルフォーマットです。この JPEG のロッシーな性質の例として、ここでは 2 つのグラデーションを連結した単純な画像を生成します。グラデーションは JPEG が非常にうまく扱う滑らかな色変化を提供しますが、2 つのグラデーション間のシャープな色変化はうまく扱われません。

  magick -size 5x10  gradient: gradient:blue-navy  +append jpg_lossy.gif
  magick jpg_lossy.gif                  jpg_lossy.jpg

最初の画像は、歪みのない GIF フォーマット版の画像を拡大表示したものです(画像をクリックすると拡大していない版を見たりダウンロードしたりできます)。これは 20 色しか含まないので、この場合 GIF フォーマットは画像を完璧に扱え、実際に非常に小さなファイルサイズを生成します(下の表を参照)。一方、画像の JPEG 版は、より良く圧縮できるように JPEG 圧縮が保存画像に加えた、明らかな色の歪みを示しています。歪みは青チャンネルで最も大きく、これは青が人間の目で解像されにくいことを考えれば驚くことではありません。つまり、人間の目は自然と青い色を「広げ」がちで、JPEG アルゴリズムは(内部的に YCbCr 色空間を使うことで)これを利用します。実際、上で使った拡大なしでは、この効果を見つけるのは困難でしょう。品質が画像に及ぼす効果を見てみましょう。

  magick jpg_lossy.gif   -quality 100%  jpg_lossy_100.jpg
  magick jpg_lossy.gif   -quality  80%  jpg_lossy_80.jpg
  magick jpg_lossy.gif   -quality  50%  jpg_lossy_50.jpg
  magick jpg_lossy.gif   -quality  20%  jpg_lossy_20.jpg
  magick jpg_lossy.gif   -quality   5%  jpg_lossy_5.jpg

上の結果のうち最初の画像、つまりテスト画像を '100%' すなわち最大品質で保存したものをよく見ると、それでもまだいくらかわずかな色の歪みがあります。見つけるのは非常に困難ですが、存在します。一方、JPEG 画像に対して徐々に低い「[-quality](https://imagemagick.org/command-line-options/#quality)」設定を使うと、この色の歪みはさらに大きく目立つようになります。それだけでなく、エッジの一種の「影付き」を作り出し、シャープなエッジから広がる色変化の「波」を生じます。一般に リンギングアーティファクト として知られる効果です。しかし圧縮を使う理由は、結果の画像のサイズが、少なくとも当初は、非常に劇的に小さくなるからです。以下は結果のファイル一覧とそのバイト単位のサイズです。

この場合 GIF 画像は非常に小さいことに注目してください。色の大きな「ブロック」は GIF で非常によく圧縮されるからです。JPEG の品質が低くなるにつれて、画像のサイズも小さくなります。JPEG 品質がユーザーまたは元画像フォーマットファイルのどちらからも設定されていないときのデフォルト品質設定は約 92% で、これは非常に高品質です。しかし '50%' より低い品質設定を使っても、画像のファイルサイズの面ではあまり小さくならず、画像がより一層劣化していくだけです。収穫逓減の過程です。まとめると…

JPEG は情報を失い、保存時に画像を劣化させます。
処理中の中間画像には他のフォーマットを使ってください。
JPEG フォーマットは最終画像にのみ使い、さらなる処理には使わないでください。

JPEG はまた、線画、図、アニメ風のアイコン、テキスト、シンボルのような、シャープな色変化を持つ人工的な画像には向いていません。色数の少ないそうした画像は、GIF や PNG8 のようなパレット画像フォーマットを使って保存したほうが良いです。Jpeg2000 という新しい JPEG 画像フォーマットが利用できるようになりつつあり、これはロスレスな JPEG 圧縮を可能にします。ただしこれには「JasPer」ライブラリもインストールされている必要があります。この特殊なフォーマットを使うには、IM が正しいライブラリを呼ぶように、「-compress jpeg2000」オプションを使うか、JP2 ファイルフォーマットに保存する必要もあります。

JPEG の透明度 - 不可

圧縮以外で、JPEG ユーザーが直面するもう 1 つの大きな問題は

JPEG は透明度を保存しない

ということです。したがって、画像を背景色やパターンの上に重ねて JPEG に保存することはできますが、JPEG 画像に自由な形の境界や透かし穴を与えることはできません。JPEG は実世界の画像を保存するために設計され、画像の一部を保存するためではなかったため、フォーマットが作られたとき透明度は関心事ではありませんでした。そのため設計者は、アルファチャンネルやその他の透明度情報をファイルフォーマットに含めることを決して気にかけませんでした。たとえば、上で使った透明度付きの PNG を直接 JPEG に変換してみましょう。

  magick a.png  a.jpg

ご覧のとおり、すべての透明部分はただ黒くなりました。しかし画像の出所(特に GIF 画像)によっては、透明領域は他のランダムな色や不適切な色になることもあり得ます。これが問題になり得る場合は、画像を JPEG 画像ファイルフォーマットに保存する前に、IM に アルファ透明度を除去 させるのが最良の考えです。

JPEG の色の歪み (テスト中)

上で述べたように、JPEG が使う圧縮アルゴリズムはロッシーです。画像はより良く圧縮できるように変更され、うまくいけばファイル容量を減らします。どれだけの色の歪みが起きるかは、使う品質設定によります。たとえば、IM 組み込みの「netscape:」画像にいくつの色があるか見てみましょう… | |

  magick identify -format "Colors: %k" netscape:

|

ご覧のとおり、この画像はデフォルトで、大きな矩形配列に 216 色を持っています。この種の画像は JPEG フォーマットに保存するのにあまり良い画像では ない ので、私たちの目的には理想的です。では、この画像の JPEG 保存がいくつの色を生成するか見てみましょう… | |

  magick netscape: JPG:- |\
     magick identify -format "Colors: %k\nFile Size: %b" -

|

つまり、デフォルトでは、保存された JPEG ファイルはほぼ 9 倍もの色を持っています! 結果は依然としてオリジナル画像のように見えるでしょうが、矩形領域のエッジには近くに色が加えられているはずです。最高品質設定で保存しても、色の歪みなしに画像を保存することは できません … | |

  magick netscape: -quality 100 JPG:- |\
     magick identify -format "Colors: %k\nFile Size: %b" -

|

ご覧のとおり、非常に高い品質設定では数色しか増えませんが、画像には依然としてわずかな(最小限の)色の歪みがあります。また、ファイルサイズが大きいことも分かります。ほとんど圧縮が効かないからです。では「ロスレス」を試してみましょう… | |

  magick netscape: -quality 100 -compress Lossless JPG:- |\
     magick identify -format "Colors: %k\nFile Size: %b" -

|

それでも色の歪みがあります! 明らかに、私の JPEG ライブラリはロスレス符号化のパッチが当たっていません。ただし、そのようなロスレス JPG 画像を読めるのは、同じくパッチの当たったライブラリだけであることを忘れないでください。代わりに、IM を JasPer ライブラリと新しい JP2 画像ファイルフォーマットを使うようにコンパイルすることをおすすめします。 | |

  magick netscape: JP2:- |\
     magick identify -format "Colors: %k\nFile Size: %b" -

|

ご覧のとおり、Jpeg2000 フォーマットは他の非ロッシーな画像圧縮方法に切り替え、デフォルトでは画像の色を歪めません。また、画像に対していくつかの非常に高い圧縮方法も行います。しかし、新しい JP2 フォーマットで低い品質を使うと、通常の JPEG 画像ファイルフォーマットと同じように、より小さな画像を生成するために再び色の歪みが入ります… | |

  magick netscape: -quality 50% JP2:- |\
     magick identify -format "Colors: %k\nFile Size: %b" -

|

JPEG2000 コーダの使用についての詳細は、JPEG2000 符号化パラメータのドキュメント を参照してください。

JPEG 読み込み制御オプション

-define jpeg:size={width}x{height} この設定は、入力 (JPEG) 画像ファイルから、与えられたサイズ(width × height)以上の画像を作るのにちょうど十分なだけを読み込むようにという、JPEG 画像ライブラリへのヒントです。入力画像が巨大な場合、IM が画像読み込みに必要とするメモリ量を大幅に減らせます。IM がその後より小さな画像を扱うことになるからです。これは、ひいては完全な操作の速度を劇的に上げられます。これは欲しい画像サイズのヒントにすぎず、このサイズが得られる保証はなく、そのサイズに近いがそれより大きい何かが得られるだけだということを忘れないでください。通常は、このサイズとその 2 倍の間の何かが得られ、画像のアスペクト比は保たれます。通常、サイズヒント付きで JPEG 画像を読み込んだあと、画像はすぐに最終的な「厳密な」サイズにリサイズされます。たいていは「[-thumbnail](https://imagemagick.org/command-line-options/#thumbnail)」を使って、画像プロファイルも取り除きます。たとえば…

    magick -define jpeg:size=64x64   jpeg_large.jpg jpeg_size_hint.jpg
    magick -define jpeg:size=128x128 jpeg_large.jpg \
                                   -thumbnail 64x64  jpeg_thumbnail.jpg

---

| _IM v6.5.6-0 より前は、このコーダ設定は「[-size](https://imagemagick.org/command-line-options/#size)」設定から抽出されていました。これは、ユーザーが画像作成のために「[-size](https://imagemagick.org/command-line-options/#size)」を使ったのに、JPEG 読み込みが予想外の結果を生じるという問題を引き起こしました。そのため、これは代わりに特別なコーダ設定に変更されました。

古いバージョンでは、JPEG 画像を読み込む前に「[+size](https://imagemagick.org/command-line-options/#size)」を使って「[-size](https://imagemagick.org/command-line-options/#size)」設定をリセットする必要があるかもしれません。さもないと、IM が JPEG 画像を完全に読まないことがあります。

---|---
この修飾子は、JPEG ライブラリにピクセルの列と行のまるごと全体を読み飛ばさせることに注意してください。そのため、強い エイリアシングアーティファクト を含め、サンプリングリサイズ演算子 によく似た効果を生じます。このため、この問題を避けるには、上の例で示したように、画像の最終的な「リサイズ」の少なくとも 2 倍を指定することをおすすめします。 | サムネイルリサイズ演算子 も、極めて大規模なリサイズ操作で同じサンプリング技法を使い、通常のリサイズ操作の前に素早く画像のサイズを減らすことに注意してください。ただし最終画像サイズの 2 倍ではなく 5 倍までです。サイズの違いは最終画像品質の問題です。
---|---
+profile '*' -strip デジタルカメラ、スキャンソフトウェア、そして「photoshop」のような他の画像処理ソフトウェアが保存する JPEG 画像には、しばしば「_プログラムコメント」の大きなプロファイルが追加されます。これらのオプションのいずれも、画像を読み込んだあとにそうしたプロファイルを画像から取り除きます。「[+profile](https://imagemagick.org/command-line-options/#profile)」演算子は画像からすべてのカラープロファイルを取り除き、一方「[-strip](https://imagemagick.org/command-line-options/#strip)」は画像が持つすべてのプロファイルとメタデータを取り除きます。また、「[-thumbnail](https://imagemagick.org/command-line-options/#thumbnail)」は「[-resize](https://imagemagick.org/command-line-options/#resize)」オプションで、同時に「[-strip](https://imagemagick.org/command-line-options/#strip)」も行うことに注意してください。サムネイルの作成 も参照してください。 -type TrueColorMatte JPEG は何らかの形の透明度を保存しないため、読み込まれるとき常に完全不透明で、メモリ内に「アルファ」チャンネルを持ちません。この設定は、このオプションのあとに読み込まれる JPEG 画像に、完全不透明な「アルファ」チャンネルをメモリ内の画像に追加するよう強制します。ただし、これを行うより良い方法は、画像を読み込んだあとに「[-alpha set](https://imagemagick.org/command-line-options/#alpha)」または「[-alpha](https://imagemagick.org/command-line-options/#alpha) set」を使うことです。そのほうが他の画像フォーマットの読み書きへの影響が少なくて済みます。詳細は 読み書き時の画像タイプ と アルファセット を参照してください。

JPEG 書き出し制御オプション

デフォルトでは、JPEG 画像を読み込んだときに見つかった「[-quality](https://imagemagick.org/command-line-options/#quality)」と「[-sampling-factor](https://imagemagick.org/command-line-options/#sampling-factor)」が、JPEG 画像に書き戻すときに使われます。ただしこれはディスク上で同じファイルサイズを生成するとは限らず、JPEG 画像の読み込みと再保存により、それでも常にさらなる画像品質の損失が生じます。ただし JPEG 量子化テーブルは保持されません。

-quality {percent} JPEG 画像を保存するときのおそらく最も重要なオプションです。これはディスクに保存するときに画像がどれだけ圧縮されるかを制御するからです。値はサイズのパーセンテージではなく、単なる品質値です。値が低いほど画像は小さくなり、より多くの画像情報が失われ、より多くのアーティファクトを生じ、画像が劣化します。

    FUTURE: VERY low quality example of a photo

注: '100%' という品質設定は、品質の損失なしに画像を保存することを保証するものではなく、最小限の損失にとどめるだけです。(次のオプションを参照) 注: 試行錯誤による以外、特定のファイルサイズを得るための品質を決めることはできません。「[-quality](https://imagemagick.org/command-line-options/#quality)」を 75% から始めて、結果のファイルサイズを確認してください。大きすぎる場合は品質を 10% 下げ、小さすぎる場合は上げます。品質の下限と上限が得られたら、二分探索を行って、希望のファイルサイズに最もよく合う品質を見つけます。合計 5、6 回の試行で十分でしょう。 -define jpeg:extent={size} IM v6.5.8-2 以降では、JPEG 画像の最大出力ファイルサイズを指定できます。サイズはサフィックス付きで指定します。たとえば「400kb」です。これは、JPEG 画像を多数のバージョン生成し、出力品質「[-quality](https://imagemagick.org/command-line-options/#quality)」設定の二分探索を行い、与えられたファイルサイズを超えないようにしつつできるだけそれに近づくまで動作します。これは画像を一時ファイルに繰り返し書き込み、適切な品質サイズが得られたら、最終画像を与えられた出力ファイル名へ一度だけ出力します。そのため、最終画像をパイプラインやネットワークへ直接出力する場合も、実ファイルだけでなくきちんと機能します。ただし、この処理は I/O 要件のため、あまり速くないと思ってください。おそらく 4 ～ 8 倍遅くなります。実際にタイミング比較をしたら、結果をメールしてください。 -compress LossLess '100%' という「[-quality](https://imagemagick.org/command-line-options/#quality)」設定でも、それでもわずかに異なる色を生成し得ます(依然として「ロッシー」です)が、「-compress LossLess」オプションは、JPEG ライブラリにデータの損失なしに画像を保存するよう求めます。そのため画像を再読み込みすれば、保存されたとおりに正確に復元されるはずです。警告: これは JPEG ライブラリが「ロスレス JPEG」符号化のパッチを当てられている場合にのみ機能しますが、JP2 ファイルフォーマットの使用がこれに取って代わったため、このオプションはもはやほとんど効果がありません。また、これが機能するには「-quality 100%」も 必ず 設定しなければなりません。直感的には「LossLess」で保存すれば自動的に 100% 品質を使うことになると思うでしょうが、そうではありません。これは、定義上ロッシーなフォーマットである JPEG 画像書き出しに、変わったパッチを継ぎ足した結果です。もちろん、生成されるファイルは通常の JPEG 画像よりおそらくずっと大きくなります。また、ロスレス圧縮された JPEG ができあがり、それは同様にパッチの当たった JPEG ライブラリ以外のどこでも読めません。そのため「ロスレス JPEG」は おすすめできず、代わりに他のフォーマット(PNG や JP2 など)を使うべきです。 -interlace Line 「プログレッシブ JPEG」スタイルを使うと、大きな JPEG 画像をまだ読み込み中でも見られます。下の、既存の JPEG をさらなる損失なしに再符号化する IM 以外の解決策も参照してください。 -sampling-factor {horizontal}x{vertical} クロマのダウンサンプリングのために JPEG ライブラリが使うサンプリング係数を調整します。MPEG-2 アニメーションファイルを作るには '2x1' に設定できます。「2x2, 1x1, 1x1」は IM の標準のサブサンプリング方法で、4:2:0 に相当します。Wikipedia, クロマサブサンプリング を参照してください。ただし「quality」が 90 以上のとき、チャンネルはサブサンプリングされません。基本的に、これは処理「ブロック」または「セル」のサイズを 8 ピクセルにするか 16 ピクセルにするかを定義します。 -density {Xdpi}x{Ydpi} density は結果の画像の出力ピクセルサイズには影響しませんが、上記の設定は JPEG 画像ファイルフォーマットの JFIF ヘッダに格納されます。残念ながら Photoshop のような一部のプログラムは、画像内に格納された特別な photoshop 固有プロファイル('8BIM')にも density が存在する場合、この設定を無視します。density が本当に重要なのは、プリンタやモニタのような出力デバイスが使われるときだけで、これらのデバイスが画像を実世界のサイズに合わせて拡大表示できるようにします。たとえば、スキャンした写真やページが正しいサイズで印刷されるようにするためです。density についての詳細は 画像 density メタデータ と リサンプルリサイズ を参照してください。 -type TrueColor IM は、グレースケール値だけを含む画像に対しては自動的にグレースケールの内部フォーマットを使います。この設定はこの挙動を上書きし、IM が常にグレースケールではなくカラーの JPEG 画像を生成するよう強制します。詳細は 読み書き時の画像タイプ を参照してください。 -define jpeg:optimize-coding=false この画像に対する最適なハフマン符号化テーブルの計算をオフにします。これはデフォルトでオンです。計算に必要な画像への余分なパスが 1 回必要ですが、これは最小限です。 -define jpeg:q-table={path} カスタムの JPEG 量子化テーブルを XML で含むファイルを定義します。サンプルテーブルは通常「/etc/ImageMagick/quantization-table.xml」にインストールされますが、ImageMagick に組み込まれているため通常は使われません。テーブル生成に関する多くの議論が Digital Image Processing Forum にあり、(執筆時点での)具体的な議論は JPEG Quantization Tables、Better JPEG quantization tables?、Stupid PET Trick qtable of one、JPEG luma quantization table にあります。このオプションは IM v6.5.7-8 で追加されました。

JPEG 品質とファイルサイズ

ある品質に対する JPEG ファイルの最終的なファイルサイズは不確定です。圧縮の処理全体が非常に複雑で、小さな変化が圧縮に大きく異なる変化を生じます。「バタフライ効果」です。同じ元画像で同じ品質でも、IM、JPEG ライブラリ、その他の画像処理プログラムのバージョンが異なれば、ファイルサイズと観察される品質に非常に大きな違いが出ます。品質設定は、特定の画像にどれだけの圧縮または視覚的品質を適用すべきかについての単なる「当て推量」として扱ったほうが良いでしょう。本質的に、与えられた画像と品質設定に対して最終的なファイルサイズを事前に決めることは、実際にやってみる以外、実質的に不可能です。ただし IM は、特殊な 'jpeg:extent' define を使うことで、特定のファイルサイズに使う最良の品質を発見する「試し実行」を行えます。上の JPEG 書き出し制御 を参照してください。これは極めて遅いですが、同様の自前の解決策よりは速いです。これを行うのはおすすめできませんが、それは遅いからというだけではありません。固定ファイルサイズ方式では、単純な画像が品質 90% で出てくるが 50k の不要なデータを含む一方、複雑な画像は品質 30% まで落とさざるを得ず、存在する詳細に対するデータ不足のため JPEG アーティファクトを示す(もっと技術的でなく言えば、ひどい見た目になる)、ということが起こり得ます。より良い考えは、自分の画像の妥当な選択に対して平均ファイルサイズ 100KB を生成する単一の品質設定を見つけることです。それでも、あまり詳細のない画像は 50k 程度にしかならないかもしれません。一方、込み入った詳細の多い画像は 150k になるかもしれませんが、どちらも許容できる見た目になります。JPEG 圧縮と品質の実用的なガイドについては、JPEG 圧縮設定の最適化 を参照してください。また、JPEG の内部詳細を見るには JPEG Compression, Quality and File Size を参照してください。Photoshop の豆知識: Photoshop は、プレビューとカラーマネジメント情報(プロファイル '8BIM')を保持するために、JPEG 画像に約 4 KB の余分な情報を追加します。その情報が不要なら、「Web 用に保存」機能を使ってください。この豆知識は Gernot Hoffmann による JPEG 圧縮に関する論文で見つけました。

関連する JPEG 出力フォーマット

PJEG: プログレッシブ読み込み JPEG 画像を書き出します。

高速なネットワークダウンロードが当たり前の今日ではあまり使われませんが、ダイヤルアップモデムが普通だった頃は非常によく使われました。基本的に、まず N 行ごとに書き、次にその間の 1 行、というように書くので、完全な画像のうちわずかな割合をダウンロードしただけでも画像を見られます。

JPEG2000: 新しい追加機能を持つ最新の JPEG フォーマット。

このフォーマットには「JasPer jp2」ライブラリがインストールされている必要があり、さもないとエラーになります…

"no encode delegate for this image format"

このフォーマットは、標準の JPEG DCT 方式の代わりにウェーブレット圧縮を使って画像を圧縮します。これにより、同じ画像品質に対してはるかに良い圧縮率が得られます。そのためディスク容量をさらに減らせます。残念ながら、まだ広く採用されていないので、少なくとも Web ブラウザやその他の画像ビューア・エディタがこのフォーマットを使い始めるまでは、外部の用途には使えません。このフォーマットで保存した画像は、このライブラリを持つユーザーだけが読め、おそらく利用者のかなりの割合がこのライブラリを使うようになるまでには長い時間がかかるでしょう。特に Windows ユーザーは、十分な数の人々が要求しない限り、Microsoft がおそらくこれを含めないからです。Quicktime の豆知識: Quicktime は jp2 フォーマットを使いますが、「[-depth](https://imagemagick.org/command-line-options/#depth) 8」で出力しなければなりません。

ImageMagick 以外による JPEG 処理 (簡単なまとめ)

この例については、この 具体的な議論 を参照してください。_
---|---
ご覧のとおり、これらのプログラムのほとんどは、JPEG 圧縮画像を再処理することなく JPEG 画像メタデータを処理するように設計されています。(次へ続く)

ロスレス JPEG 処理

JPEG 画像を復号して再符号化すると(ロスレス圧縮を使わない限り)画像品質が劣化するため、JPEG 画像ライブラリは、品質の損失なしに画像を操作できるいくつかの特別なプログラムを提供しています。これらのコマンドはまた、IM の同等品ほど画像の処理をする必要がないため、一般にずっと速くなります。JPEG 画像のコメントを変更するときは、より低レベルの JPEG ライブラリプログラム「rdjpgcom」「wrjpgcom」「jpegtran」を使えます。しかし、「[jhead](http://www.sentex.net/~mwandel/jhead/)」プログラムを使うことをおすすめします。これは画像内に存在する他のプロファイルや情報も保持するからです。「jpegtran」を使うとさらに進んで、90 度回転、切り出し、ドロップインなど、画像データを実際にロスレスで操作できます。混合品質の JPEG 画像を作成することすらできます。これの実演については、Nemo Thorx による JPEGhack ページを参照してください。(下記の覚え書きを参照) ただし、これらのコマンドは JPEG 画像のブロック境界(8 または 16 ビット)に限定されるため、一般的な用途には おすすめしません。つまり、実際のピクセルレベルではなく、JPEG 圧縮セルレベルでしか切り出し・回転・ドロップインができません。コメント… JPEG 写真の モンタージュサムネイル Web 索引ページ を作っていて、上記のプログラムを使って JPEG ファイルに追加したコメントを使いたい場合は、「magick montage」コマンドラインでファイル名を読む前に「-label '%c'」を使って、montage に「comment」フィールドを使うよう指示してください。そのコメントは、複雑なポラロイド変換、ポラロイドモンタージュ、あるいは何らかの画像の 注釈 でも使えます。「[jhead](http://www.sentex.net/~mwandel/jhead/)」プログラムは、JPEG 画像ファイルにコメントを追加・変更するのに使えます。ただし、「コメント編集」(「-ce」)オプションを使うのは、コメントの末尾に余分な改行を追加するので、それを行う良い方法ではないと分かりました。この余分な改行は、IM でのコマンド('%c' ラベル整形エスケープ)の使用を台無しにします。より良い方法は、「コメント入力」(「-ci」)を使って(末尾に改行のない)コメントを送り込むか、「コメントリテラル」(「-cl」)オプションを使うことで、これがずっと良い方法です…

  jhead -cl 'Photo of some stuff, by Joe Citizen'  image_of_stuff.jpg

サムネイル… Brian Jackson brian@brianjacksonphoto.com はまた、ほとんどのデジタルカメラ(彼のは Cannon 1D)が、生成する JPEG 画像のどこかに 12kb ～ 25kb 程度のサイズ(160x120 ピクセル)のサムネイルを埋め込むと報告しています。IM は次のようにしてこれらのサムネイルを抽出できます…

   magick image.jpg   thumbnail:thumb.jpg

ただし「[jhead](http://www.sentex.net/~mwandel/jhead/)」プログラムも、これらのサムネイルを抽出できます…

  mkdir thumbs
  jhead -st "thumbs/&i" *jpg

これは、画像を編集せず既存のデータを転送するだけなので、IM に比べて超高速です。しかし、サムネイルの品質は、IM が実画像から生成できるサムネイルほど良くなく、また正しく回転していないかもしれず、間違いなく欲しいサイズにはなりません。ExifTool を使う… Rob より。JPEG 画像ファイルに格納されたプロファイルを、「[jhead](http://www.sentex.net/~mwandel/jhead/)」が提供する以上に詳細に編集したい場合は、perl ベースの「[ExifTool](http://www.sno.phy.queensu.ca/~phil/exiftool/)」、その代替のコンパイル版「[ExifTool](http://www.dalibor.cz/minolta/exiftool.htm)」、Windows GUI の「[Exifer](http://www.exifer.friedemann.info/)」など、より EXIF 中心のアプリケーションを見てください。Image::ExifTool Perl モジュールをインストールすれば、これですべての JPEG メタデータをロスレスで除去できます。EXIF データを除去するコマンドライン方式と等価なものとして、以下が使えることが分かりました。今後興味のある人のために:

  use Image::ExifTool;
  $exifTool = new  Image::ExifTool;
  $exifTool->SetNewValue('*');  # delete  all...
  $exifTool->WriteInfo('original_image.jpg','modified_image.jpg');
  $errorMessage = $exifTool->GetValue('Error');
  print  $errorMessage;  # (if has value an error occurred)

分かるまで少しかかりました。というのも、まず SetNewValue を使って設定を割り当ててから、WriteInfo を使って同時に読み込みと保存をする必要があると判明したからです。JpegTrans を使った混合 JPEG 品質画像… Wolfgang Hugemann {Auto@Hugemann.de} は、JPEG 画像のエッジをまったく圧縮したくないと考えました。それが写真の扱いを台無しにするからです。このサイト を参照してください。Yuval Levy が提供した解決策は、「jpegtran」を使って低品質の JPG を高品質の JPEG に挿入することでした…

解決策: * ImageMagick で同じ画像の 2 つのバージョンを作る。1 つは高品質 100、もう 1 つは(サイズ削減のため)低品質 60。 * jpegtran を使って q60 を切り出し、各辺から 8 ピクセル削る。 * jpegtran を使って q60 を q100 の上にマージする。 * jpegtran を使って 1 本の帯にマージする。

Nemo Thorx jpeghack@nemo.house.cx は上記を読んで、混合 JPEG 品質の実装を試みました。彼は成功し、その結果を Wiki ページ JPEGhack で実演しています。基本的に、既存の画像内の JPEG ブロックを「切り出し」たり、新しい部分を「ドロップ」したりするようなロスレス JPEG 処理は、非常に可能です。

PNG 画像ファイルフォーマット

これは最も新しく現代的な画像フォーマットの 1 つで、アルファチャンネル透明度を含む 32 ビットの色をサポートしますが、GIF のような 8 ビットのインデックスカラー方式(256 色の制限)に最適化することもできます。そのため、画像情報の損失なしに画像処理を行う、優れた中間フォーマットになります。

PNG 圧縮

PNG 出力で使う場合、品質は 2 桁の数字 とみなされます。最初の桁(十の位)は zlib 圧縮レベル 1-9 です。ただし '0' の設定を使うと、'zlib' 圧縮ではなくハフマン圧縮になり、これはしばしばより良いです! 奇妙ですが本当です! 2 番目の桁は、(圧縮される前の)PNG データ符号化フィルタリングのタイプです。0 は none、1 は「sub」、2 は「up」、3 は「average」、4 は「Paeth」、5 は「adaptive」です。そのため、色の連続した塊を持つ画像には「none」フィルタ(-quality 00)が通常より良く、自然の風景の画像には「adaptive」フィルタリング(-quality 05)が一般により良いです。 | _PNG コーダは多くの作業を経てきており、正確な符号化と圧縮設定を制御するより良い方法は、通常 define 演算子 を使って設定します。

これらの define の詳細は、下の PNG 画像書き出し制御 を参照するか、PNG コーダファイル「coder/png.c」ソースコードのコメントを見てください。

_
---|---
バイナリ(オン/オフ)の透明度を持つ ImageMagick 画像があれば、PNG エンコーダは、完全なアルファチャンネルの代わりに tRNS チャンクを使って、効率的にそれを書き出します。しかし、0 または MaxRGB 以外の不透明度値が存在する場合は、アルファチャンネル付きの PNG を書き出します。この挙動は、「-type TruecolorMatte」画像読み込み設定を使うか、「PNG32:」フォーマットファイルを使って画像を保存することで強制できます。外部プログラム「[pngcrush](http://pmt.sourceforge.net/pngcrush/)」や新しいバージョンの「[OptiPNG](http://optipng.sourceforge.net/)」は、特定の PNG を利用可能な最良の圧縮で再圧縮しようとし、Web サイトに置く予定の画像におすすめです。別のプログラム「[pngnq](http://www.cybertherial.com/pngnq/pngnq.html)」は、画像を 256 色 8 ビット PNG に色量子化しますが、そのフォーマットで半透明の色をサポートするかどうかは不明です。

PNG のより良い圧縮

PNG 画像についての 1 つのポイントは、PNG 画像が完全透明なピクセルの色を保持することです。つまり、見えないとはいえ透明度は色を持ち、PNG はそのデータを保持します。これは、多くの場合、その「見えない色」を、以前の画像処理から残ったかもしれないゴミ色ではなく、静的な単色に置き換えることで、PNG をより良く圧縮できることを意味します。これに使える主要な方法は 2 つあり、アルファ背景演算子 を使って完全透明なピクセルだけを扱うか、透明度とのファズ係数 のような操作を使って、ほぼ半透明の色も完全透明な黒にマップします。たとえばここでは、上で生成したぼやけた影付きの「a.png」画像を取り、完全透明の 20% 以内にあるすべてのピクセルを置き換えます。

  magick a.png  -fuzz 10% -transparent none  a_compress.png

ご覧のとおり、画像サイズが大幅に改善されます(約 50%)。ただし、画像の影には鋭い切れ目が生じます。別の方法は、透明度チャンネルの レベル を調整して、影の効果を小さくするだけです。

  magick a.png  -channel A -level 20,100%,0.85 +channel \
          -background black -alpha background a_compress2.png

より少ない色数を使うことでも、圧縮アルゴリズムの結果、ひいては PNG 画像の最終サイズを改善できます。

  magick image.jpg -thumbnail 200x90 -colors 256 \
          -quality 90 -depth 8  thumbnail.png

ただしこれは、透明度を伴わない小さなサムネイル画像にのみ、そして非常に「ロッシー」な技法なので最終ステップとしてのみおすすめします。

PNG・Web ブラウザ・透明度

Microsoft Internet Explorer (IE バージョン 6 以前) は、何らかの透明度が関わる場合、PNG を正しく表示しません。これは PNG を完全にはサポートしない最もよく知られたブラウザですが、唯一のものではありません。PNG 透明度テスト と 別の PNG テスト のページで、お使いのブラウザをテストできます。これらは、表示された結果を生成するブラウザとバージョンも一覧表示しています。しかし、IE は(少なくとも執筆時点では)おそらく最も一般的なブラウザなので、この問題への多くの回避策を Web ページに追加できます。これについての情報は、私の WWW 実験ページ PNG with Transparency and IE を見てください。そこで私は、使っている「PNG in IE」解決策をテストし実演しています。他の解決策は、PNG を JPEG(適切な色の背景付き)または GIF フォーマットに変換することです。これらの方法は、背景の上の GIF 画像 で徹底的に議論しています。別の解決策は、画像を PNG に保存する前に、すべての完全透明な色の色を設定することです。PNG はその完全透明な色を保存しますが、ほぼ他のあらゆる IM 操作が完全透明を完全透明な黒に戻すことに注意してください(透明な色は問題にならないはずで、それが画像数学の動作の仕方だからです)。 たとえば、標準の IM 使用例テスト画像 は、完全透明なピクセルに完全透明な黒を使っています。これは、アルファチャンネルをオフにするか、JPEG として保存することで確認できます… |

  magick test.png test.jpg

ではこれを、すべての完全透明な色が完全透明な 'silver' 色に置き換えられるように保存しましょう(アルファ背景 演算子を参照)… |

  magick test.png   -background silver -alpha Background   test_silver.png

お使いのブラウザで透明度(またはページ上の特別な JAVA スクリプト)が機能していれば、画像は依然として正しく見えるはずです。 しかし(アルファを許可しない JPEG に保存することで)アルファチャンネルをオフにすると、PNG 画像が実際に完全透明なピクセルに「silver」色を使っていることが分かります。 |

  magick test_silver.png test_silver.jpg

ただし、これは半透明のピクセルを変更せず、それらは、ページ背景や完全透明に使った色とその色を混ぜることなく、通常の(非透明な)色のままになることに注意してください。半透明がもはや関わらないため、境界はギザギザ(エイリアス)に見えたり、明るい色のエッジに沿って「ハロー」効果が出たりすることがあります。たとえば、「ジャギー」エイリアシング効果を示す黒と白の円のエッジを見てください。ただし、グレーの置換色を使えば、完全透明に使った元の「黒」色ほど悪くはならないはずです。完全透明なピクセルの色を設定することのもう 1 つの利点は、データ圧縮の改善です。処理中、透明領域の下の色が保持されることがあります。これらは単色ほどよく圧縮されません。そのため、上で行ったように完全透明な色を設定すると、最終的なファイルサイズを良好に節約できます。ただし、多くの IM 画像処理操作が、画像内に存在する完全透明な色を完全透明な黒に戻すため、これは最終ステップとして行うべきです。これを行うことが知られている演算子の一覧については、アルファ背景 演算子を参照してください。PNG の表示問題に対する私の希望は、Microsoft が IE を修正することで、IE バージョン 7 でついに、あらゆる状況で完全に機能する PNG 透明度の扱いが実現するようです。

PNG と仮想キャンバス

通常、PNG は仮想キャンバスサイズ情報を保存しませんが、仮想キャンバスオフセット情報は保存し、それが存在する場合、IM はそのオフセットと画像サイズに適した「キャンバスサイズ」を生成しようとします。これは、操作や結果の一部として画像のキャンバスやページサイズを使う「[-crop](https://imagemagick.org/command-line-options/#crop)」「[-trim](https://imagemagick.org/command-line-options/#trim)」「[-flatten](https://imagemagick.org/command-line-options/#flatten)」などの一部の画像演算子で覚えておくと重要です。もちろん、「[-page](https://imagemagick.org/command-line-options/#page)」設定と「[-repage](https://imagemagick.org/command-line-options/#repage)」演算子を使って、仮想キャンバスサイズとオフセットを設定または除去できます。(ページ画像属性 を参照)。たとえば、2 番目の IM「magick」は、この PNG 画像に存在するオフセットを見て、画像が仮想キャンバス境界内で見えるように十分大きなキャンバスを定義します(IM v6.1.7 で追加)… |

  magick rose: -repage 0x0+40+30 png:- |\
      magick - -background LightBlue -flatten  png_offset_flattened.jpg

ただし、PNG フォーマットは通常キャンバスサイズ情報を保存しませんが、IM は PNG 画像に何らかの仮想キャンバスサイズメタデータを追加します。ただしこのデータは IM コマンドでしか使えず、他の PNG 画像フォーマットリーダには一般に無視されます。たとえば、2 番目の「magick」コマンドは何らかの仮想キャンバスサイズ情報を見ます… |

  magick rose: -repage 100x100+10+10 png:- |\
      magick - -background LightBlue -flatten  png_size_flattened.jpg

PNG が IM 以外のプログラムで処理されると、このキャンバスサイズメタデータはおそらく失われます。キャンバスサイズ情報は通常 PNG 画像ファイルフォーマットの一部ではないことを忘れないでください。もう 1 つ注意すべきは、「オフセット」情報が(GIF フォーマットと違って)負のオフセットを持つことができ、IM はこれを適切に扱うため、このフォーマットは途中段階の レイヤー画像 の保存に適していることです。 | 一部の Web ブラウザは負のオフセットをあまりうまく扱えず、奇妙な結果を生じます(ある firefox のバージョンにこの問題がありました)。Web ブラウザのような他のプログラムで使われるかもしれない画像では、負のオフセットを避けるのが最良です。
---|---

PNG の解像度・密度・単位

いくつかテストしたところ、PNG 画像ファイルフォーマットは 'PixelsPerInch' の「[-units](https://imagemagick.org/command-line-options/#units)」設定をサポートせず、'undefined' と 'PixelsPerCentimeter' だけをサポートするようです。このため、IM は与えられた density/unit 設定を 'PixelsPerCentimeter' の適切な値に変換します。この件についてはさらに後述します。

PNG サブフォーマット

  magick {input_image}  -type Palette  indexed.png

パレットインデックス画像ではなく、単一の 8 ビットグレースケールチャンネルの使用を強制するには…

  magick {input_image}  -type GrayScale -depth 8  gray.png

(IM v6.3.5-9 で追加)透明度チャンネル付きのグレースケールを出力することもできます。

  magick {input_image}  -type GrayscaleMatte  gray_with_transparency.png

そして、単純な 2 色画像には…

  magick {input_image}  -type BiLevel  bitmap.png

PNG24 画像には特別な場合があります。画像がブール透明度だけを含み、すべての透明な色が同じで、その色が透明度にのみ使われている場合、PNG コーダはその特定の色を透明として指定します。たとえば… |

  magick a.png -channel A -threshold 75% +channel \
          -background hotpink  -alpha background png24:a_png24_alpha.png

この画像はパレットを持ちませんが、いくらかのオン/オフのアルファを持ちます。アルファチャンネルの -threshold は、ブール(オン/オフ)透明度だけが存在することを保証し、一方 アルファ背景 オプションは、すべての完全透明なピクセルが特定の色であることを保証します。上記は、その色を持つ不透明なピクセルがないことを保証しないので、上記は依然として失敗し得ます。

PNG 画像の書き出し制御

PNG 画像の書き出しをよりよく制御するため、Glenn Randers-Pehrson は IM v6.5.2 向けに多くのコーダの「[グローバル設定 define](basics.html#define)」制御を改訂しました。これらには以下が含まれます…

-quality '{level}{filter}'

PNG 画像を保存するときの基本的な圧縮レベルとフィルタ。

-define png:compression-strategy=zs
-define png:compression-level=zl
-define png:compression-filter=fm

 書き出される PNG 画像に使われる圧縮システムを完全に定義します。[-quality](https://imagemagick.org/command-line-options/#quality) 設定は通常 _zl_ と _fm_ の値を設定しますが、_zs_ の設定は設定しません。

-depth

生成される画像の一般的な深度。通常 8 または 16 ビットに設定します。

-define png:bit-depth={depth}

結果の PNG 画像ファイルフォーマットの深度を正確に指定します。これは通常の IM「[-depth](https://imagemagick.org/command-line-options/#depth)」制御を上書きしますが、PNG 画像の書き出しのときだけ、そして損失なしで変更できる場合だけです。カラーマップ画像の場合、これは色サンプルの深度ではなく、カラーマップインデックスの深度です。

-define png:color-type={type}

書き出される PNG ファイルのタイプを正確に指定します。値は以下のいずれかです。 '0' | グレースケール用。'bit-depths' 2、3、4、8、16 を許可します。

---|---
'2' | RGB 用。'bit-depths' 8 または 16 を許可します。
'3' | インデックス用。'bit-depths' 1、2、4、8 を許可します。
'4' | グレー-マット用
'6' | RGB-マット用
「-define png:color-type='2'」は、画像データを sRGB 値ではなく RGB 値として格納するよう強制するのに特に役立つことに注意してください。ただし、同様の効果は、線形 RGB 画像に「-set colorspace sRGB」を使うことでも達成できます。とはいえ、プログラムが読み込み時にこの線形色空間を尊重するとは期待しないでください。これには ImageMagick も含まれます。

-profile PNG-chunk-{x}:{file}

{file} から位置 {x} に生の PNG プロファイルを追加します。{file} の最初の 4 バイトはチャンク名を含み、続いてコロン ':' 文字、その後にチャンクデータが続きます。{x} は、PLTE の前にプロファイルを置くなら 'b'、PLTE と IDAT の間なら 'm'、IDAT の後なら 'e' にできます。同じタイプの複数のチャンクを書きたい場合は、{x} の後に短い一意の文字列を追加して、後続のプロファイルが前のものを上書きするのを防いでください。たとえば…

-profile PNG-chunk-b01:file01 -profile PNG-chunk-b02:file02

+set date:create
+set date:modify

 これらは、ImageMagick がファイルを読み込むたびに作成する画像「プロパティ」です。これらは(それぞれ)画像ファイルの作成時刻(実際にはパーミッション/所有者/移動の変更時刻)と最終ファイル変更時刻を含みます。残念ながら、PNG 画像ファイルフォーマットはそうした画像データを PNG 画像ファイルフォーマットとともに書き込みがちで、このデータが異なれば、他に何も変わっていなくても、生成されるファイルも異なります。


 magick logo: logo.jpg magick logo.jpg
    logo1.png

  sleep 2; touch logo.jpg      # change the JPG file timestamp
  magick logo.jpg logo2.png

  diff -s logo1.png logo2.png
  magick compare -metric RMSE logo1.png logo2.png null:

上記の「diff」は次のメッセージを返します。

"Binary files logo1.png and logo2.png differ"

「magick compare」は、画像がまったく同じ画像データを持つことを示す「0 (0)」を返したにもかかわらずです。IM はこれらのプロパティを、今読み込んだ PNG ファイルの時刻で上書きするため、「magick identify」を使って PNG に記録された実際のプロパティ値を見ることはできないことに注意してください。解決策は、PNG 画像を「タイムスタンプ」なしで保存することです。

  magick logo: logo.jpg
  magick logo.jpg +set date:create +set date:modify logo1.png

  sleep 2; touch logo.jpg
  magick logo.jpg +set date:create +set date:modify logo2.png

  diff -s logo1.png logo2.png

今度は「diff」が報告しました…

"Files logo1.png and logo2.png are identical"

余談: バイナリ画像ファイルを比較するには、「cmp」「md5sum」「sha1sum」のような他の UNIX プログラムも使えます。後者 2 つのプログラムは保証されていませんが、実質的にだますことは不可能で、(チェックサムを使って)3 つ以上のファイルを比較するのにはより速いです。PNG 開発者の GlennRP による追加のおかげで、「-define png:exclude-chunk=date」を使って、PNG コーダに日付関連のテキストチャンクを書かないよう指示することもできるようになりました。

ImageMagick 以外による PNG 処理

画像プロファイル

写真品質の画像のプロファイルを扱うことは重要ですが、私の見るところ、これは非常に魔術的な技で、単純な事柄ではありません。すべてのフォーマットがプロファイルを使うわけではありませんが、ほとんどの現代的なフォーマットは使います。これには JPEG、PNG、TIFF、そして(IM v6.3.4-1 以降)GIF が含まれます。実際、多くのプログラムが画像内のカラープロファイルを理解すらせず、探しすらしないという事実によって、問題は悪化しています。Alan Gibson, 別名 Snibgo が、さまざまな Web ブラウザがさまざまなカラープロファイルをどう扱うかのまとめを、彼自身の Snibgo, ImageMagick Profiles ページにまとめています。一見の価値があります。画像にどのようなプロファイルが存在するかを一覧表示するには…

  magick identify -verbose image.tif | grep 'Profile-.*bytes'

よく使われるプロファイル(と私が持つ情報へのポインタ)には以下が含まれます…

 EXIF |  [デジタルカメラメタデータ](photos.html#exif)

---|---
ICC | 画像の色空間プロファイル
ICM | Microsoft カラーマネジメント (ICC に類似)
IPTC | 画像と著者の情報
8BIM | Photoshop メタデータプロファイル。クリップパスなどのデータを含みます… 他には?
XMP | Adobe の Extensible Metadata Platform (XMP) (adobe ページ を参照)
これらのよく使われるプロファイルは、IM がこの目的のために提供する特殊な出力フォーマットを使って抽出できます。たとえば…

  magick -define jpeg:size=64x64  image.jpg  iptc:profile.iptc
  magick -define jpeg:size=64x64  image.jpg  xmp:profile.xmp

上記の「[-define](https://imagemagick.org/command-line-options/#define)」オプションは、JPEG ライブラリがメモリに実際に読み込む画像データの量を減らし、実際には使うつもりのないデータの処理を大幅に省くための「ヒント」として使われます。任意のプロファイルを、好きな情報を含む「ブロブ」またはバイナリ文字列として挿入または再挿入することもできます。

  -profile '_profile_name_ :_data_file_ '

つまり、ファイル「data_file」が、プロファイル profile_name として「そのまま」画像に追加されます。IM や他のアプリケーションは、特にそれを知っている場合を除いて、そうしたプロファイルを無視します。

カラープロファイルの基礎

まず手短に一言…

カラーマネジメントは弱虫のためのもの -- それらをいじるな
プロファイルをいじると一般に事態は悪化する

ですから、色が良く見えるなら… そのままにしておいてください。IM フォーラムのユーザー fhoech(その後姿を消しました)が、画像で使われる色空間を変えるためにカラープロファイルを使う基本的な入門を、何度も投稿していました… RGB、sRGB、CMYK は色空間ではなく、カラーシステム(IM は「[-colorspace](https://imagemagick.org/command-line-options/#colorspace)」演算子を使ってこれを制御します)です。単一の RGB や CMYK 色空間というものは存在せず、文字どおり無限の数の異なる色空間が各カラーシステムで可能です。画像内の色を正確に特徴づける ICC(または ICM)プロファイルが必要です。通常、画像を記述する ICC プロファイルは画像自体に埋め込まれているべきで、さもないと「最良の推測」の試みを使うしかなく、それは回避策にすぎません。ICC 対応の画像エディタで画像を開き、自分の画像でうまく見えるものが見つかるまで、異なる ICC プロファイルを割り当てます(変換しないこと!)(モニタが校正されていて、色の良いプレビューが実際に得られる必要があります)。それから、プロファイルを埋め込んで画像を保存します。なぜ 2 つのプロファイルが必要かというと: ソースプロファイルは画像内の色を現在のまま記述します。デスティネーションプロファイルは変換後の出力画像の色を記述します。また、与えられたデスティネーションプロファイルに変換するときは細心の注意を払うべきです。たとえば、非塗工紙でのオフセット印刷を記述するプロファイルを使うつもりが、画像を塗工紙への印刷に使うつもりなら、もちろん良い結果は得られません。出力プロファイルは、意図する出力条件を正確に表現したものである必要があります。減法混色から加法混色へ(またはその逆)変換するとき、(変換の両ステップで)正しいプロファイルを使わないと、ほとんどの場合「正しい」色や明るさは得られません。ただし、運良く「たまたま」的中することはあるかもしれません。カラープロファイルは International Color Consortium からダウンロードできます。

プロファイルによる色空間の変更

このように単純に色空間を直接変換することもできますが…

  magick _cmyk_image.jpg_ -colorspace rgb _rgb_image.jpg_

CMYK を RGB JPEG に変換する最良の解決策は、「[-profile](https://imagemagick.org/command-line-options/#profile)」演算子でカラープロファイルを使うことです。Raf Lenaerts が、ImageMagick 内で「[-profile](https://imagemagick.org/command-line-options/#profile)」演算子を使う際の以下のルールを指摘しました…

埋め込みプロファイルがない場合、最初の「`[-profile](https://imagemagick.org/command-line-options/#profile)`」が入力プロファイルです。2 番目の「`[-profile](https://imagemagick.org/command-line-options/#profile)`」が出力プロファイルを定義します。
埋め込みプロファイルがある場合、単一の「`[-profile](https://imagemagick.org/command-line-options/#profile)`」演算子がただちに出力プロファイルを定義します。

まとめると…

• 「[-profile](https://imagemagick.org/command-line-options/#profile)」は入力ファイルと出力ファイルの間に置かなければなりません。
  これは実際、標準的な IM コマンドライン処理の慣行 です。
• 'icm' を伴う「[+profile](https://imagemagick.org/command-line-options/#profile)」を使って、存在する icc-profile を取り除きます。
• その後で与えられる最初の「[-profile](https://imagemagick.org/command-line-options/#profile)」が入力プロファイルです。
• 与えられる 2 番目の「[-profile](https://imagemagick.org/command-line-options/#profile)」が出力プロファイルです。

そのため、すべての画像にプロファイルを使うには、3 つの「[-profile](https://imagemagick.org/command-line-options/#profile)」操作、すなわち除去・入力・出力プロファイルのオプションが必要です。たとえば、入力画像がすでにカラープロファイルを持っている場合は、1 つだけで済みます。

  magick _rgb_image.jpg_ -profile USCoat.icm _cmyk_image.jpg_

しかし、画像が持っていない場合(またはそれが既存のプロファイルのない RGB 画像と分かっている場合)は、次のように使えます…

    magick _rgb_image.jpg_ +profile icm \
            -profile sRGB.icc  -profile USCoat.icm _cmyk_image.jpg_

これは結果の画像を CMYK の USCoat.icm プロファイルに設定します。別の CMYK プロファイルは SWOP.icm プロファイルです。逆向き(画像がすでにプロファイルを持つ)には、次を使います…

    magick _cmyk_image.jpg_ -profile sRGB.icc _rgb_image.jpg_

警告: 元画像がすでにプロファイル、たとえば CMYK プロファイルを含んでいる場合、2 つのプロファイル変換を与えるのは悪い考えです。たとえば

    magick _cmyk_image.jpg_ -profile "CMYK.icc" -profile "RGB.icc" \
                  _output_image.jpg_

は CMYK -> CMYK -> RGB 変換になります。しかし CMYK は対称でないため、余分な変換ステップが悲惨な色変換になり得ます。(IM フォーラムの議論 Question on ICC profile conversion behaviour を参照)

カラープロファイルの変更

変換したい画像はすべて ICC プロファイルが埋め込まれているべきです。そのため、画像を同じ CMYK ICC プロファイルで変換するには…

  magick _rgb_image.jpg_ -profile CMYK_PROFILE _cmyk_image.jpg_

これはデフォルトの知覚的インテントで変換します(レンダリングインテントの詳しい説明は 色空間変換 を参照)。知覚的インテントによる結果は、ICC プロファイルを作成するのに使われたソフトウェアによって大きく異なり得るため、「[-intent](https://imagemagick.org/command-line-options/#intent) relative」とともに「[-black-point-compensation](https://imagemagick.org/command-line-options/#black-point-compensation)」を使うと、予想に幾分近い結果が得られます。

  magick _rgb_image.jpg_  -intent relative -black-point-compensation \
          -profile CMYK_PROFILE     _cmyk_image.jpg_

| 「[-black-point-compensation](https://imagemagick.org/command-line-options/#black-point-compensation)」と「[-intent](https://imagemagick.org/command-line-options/#intent)」の設定は、効果があるためには「[-profile](https://imagemagick.org/command-line-options/#profile)」操作の前に指定する必要があります。
---|---
| 「[-black-point-compensation](https://imagemagick.org/command-line-options/#black-point-compensation)」オプションは IM v6.2.7-0 で追加されました。
---|---
カラープロファイルは International Color Consortium からダウンロードできます。

EXIF InterColorProfile

上記のカラープロファイルの扱いに加えて、多くのデジタルカメラは、EXIF プロファイル属性 'InterColorProfile' にカラープロファイル情報を保存します。文書「Colour Management and Adobe PhotoShop 7」によれば、この属性は「カラープロファイルが埋め込まれていない場合に想定される」ことを意図しています。

IPTC プロファイル

IPTC プロファイルは、キャプション、クレジット、著者、キーワードなど、画像の識別属性を画像に格納するために使われます。画像に IPTC プロファイルを追加したい場合は、単一の -profile が必要です。

  magick _image.jpg_ -profile iptc _iptc_image.jpg_

画像がプロファイルを含む場合、これでそれを保存できるので、そのプロファイルを他の似た画像に追加できます。

  magick _iptc_image.jpg_ iptcData.iptc

あるいは、編集できるテキスト版のプロファイルを抽出できます。

    magick _iptc_image.jpg_ IPTCTEXT:iptcData.pro

たとえば、ここに IM フォーラム で fcaserio が寄稿したプロファイルがあります。

このプロファイルは次のようにして画像に追加できます。

  magick _image.jpg_ +profile 8BIM -profile 8BIMTEXT:iptcData.pro \
          iptc_image.jpg

その画像は、IPTC プロファイルも含む、TIFF プレビュー付きの EPS (Encapsulated Postscript)(EPT)に変換できます。(Tee Tanne に感謝)。

  magick _itpc_image.jpg_  EPT:image.eps

XMP プロファイル

TIF 画像から XMP プロファイルを抽出します…

  magick picture.tif metadata.xmp

ベクター画像フォーマットについて一言

「ベクター画像」から「ベクター画像」への変換に ImageMagick を使うのは避けてください
例: PDF、PS、SVG のようなフォーマット間の変換

言い換えると、適切な仕事には適切な道具を使ってください。そしてこの状況では、ImageMagick は適切な道具ではありません。

とはいえ、IM がそうした変換に使えないわけではありません。結局、ほとんどのプリンタやモニタは、実際に紙への印刷のために自分で画像をラスタライズします。違いは、プリンタは使っているハードウェアに必要な解像度を知っていることです。ImageMagick は知りません。ベクター画像をラスターに変換する(そしてそうした変換を改善する)例については、例 Postscript/PDF の整形済みテキストとグラフィックスの入力 を、SVG やユーザー生成のベクター画像については SVG 画像の扱い を参照してください。特に描画テキストフォントに対する「[-density](https://imagemagick.org/command-line-options/#density)」の効果に関して、フォントサイズ・解像度・ポイントサイズ の情報も役立つかもしれません。

IM 以外の代替手段

ベクターフォーマット間の一般的な変換を本当に行う必要があるなら、UniConvertor, Sk1 Project(通常は標準の linux パッケージとして利用可能)と VectorSection を使って、画像を実際にラスタライズすることなくベクターからベクターへ変換できます。Postscript を他のベクターフォーマットへ一般的に変換するには、「[pstoedit](http://www.pstoedit.net/pstoedit)」を見てください。通常はシステムの追加パッケージリポジトリで利用できます。また、Comprehensive TeX Network (CTAN) の一部である「[epstopdf](http://www.ctan.org/tex-archive/support/epstopdf/)」も見てください。TeX と LaTeX は UNIX のドキュメント(書籍や科学論文)テキスト処理システムです。Postscript と PDF フォーマットに関する多くのツールがあります。SVG から PDF への変換について、Wolfgang Hugemann Auto@hugemann.de は、最も簡単なベクターからベクターへの変換は、SVG をブラウザ(Firefox)で表示し、PDF プリンタドライバを使って印刷することだと提案しています。ただし「Uniconvertor」も使えます。

その他の画像ファイルフォーマット

もちろん、IM が使い理解できる画像ファイルフォーマットは他にも膨大な数がありますが、これらのあまり「一般的」でないフォーマットの多くは、何らかの特定の目的に特化しており、思いどおりに機能させるには、しばしば何らかの微調整や他のオプションが必要です。これらのファイルフォーマットはおすすめせず、一般に私自身も使いません。しかし、IM メーリングリストや IM フォーラム で報告されたさまざまな覚え書き、技法、オプションを記録するようにしているので、他の人も収集した情報を使えます。覚え書きの多くは生の未整理な形式で、以下の覚え書きへのさらなる寄稿や書き直しを喜んで受け入れます。

Postscript (PS, EPS) と Adobe PDF

基本的な扱いについては Postscript テキストの扱い と ベクター画像フォーマット についての警告を参照してください。Postscript とその関連フォーマット(PDF など)の主要な問題は、それが複雑なページ整形言語であることです。つまり、このフォーマットはプログラムであって、本当は画像フォーマットではありません! それは、IM が、そのプログラムを「実行」して生成された画像を返すために、別の外部プログラム(またはデリゲート)に頼らざるを得ないことを意味します。

Encapsulated Postscript (EPS)

Encapsulated Postscript は、実際には通常の postscript(ベクター画像フォーマット)とまったく同じですが、単一ページの画像であり、画像が覆う正確な領域を定義する「Bounding Box」エントリが存在する点が異なります。このフォーマットは、それが定義する postscript を他の postscript 文書に挿入する際に、他のプログラムが画像を移動・拡大縮小できるように設計されました。IM は基本的に postscript と同じ方法でこれを扱います。(上記参照)。

  magick image.jpg -compress none eps2:image.eps

JPEG 圧縮された EPS ファイルを作るには「EPS2:」または「EPS3:」を使ってください。注: EPS 画像へのプロファイルの追加は「やることリスト」にありますが、現在はサポートされていません。

Postscript/PDF の入力

このフォーマットはベクター画像フォーマットなので、「[-page](https://imagemagick.org/command-line-options/#page)」や「[-density](https://imagemagick.org/command-line-options/#density)」のような設定の影響を受けます。Postscript の読み込み(EPS や PDF フォーマットでも同じです)の例は Postscript 整形済みテキスト で提供されており、まずこれを読むべきです。ただし、これらのフォーマットの読み込みは非常に複雑です。これらは、高品質なレーザープリンタで印刷ページを生成するために特別に設計された完全なコンピュータ言語だからです。これは ImageMagick の範囲をはるかに超えているため、Postscript と PDF のページをラスター画像に読み込み・変換するために、「ghostscript」として知られる専門のデリゲートプログラムに頼ります。1 つのポイント。 IM は Ghostscript を使って postscript ファイルを特定の解像度でラスタライズするため、postscript ファイル内のラスター画像は、そのラスター画像の正確な密度が分からない限り、しばしばぼやけたり歪んだりします。これはまた、postscript プログラム自体がラスター画像を回転させたり操作したりしないことを前提としています。実際、複数のデリゲートが存在し、状況に応じて IM が選択します。たとえば、'ps:color'('bmpsep8' ghostscript デバイスを使用)と 'ps:alpha'('pngalpha' を使用)は、「-channel RGBA」が設定されているかどうかに応じて選択されます。'pngalpha' ghostscript デバイスは 1 ページ/1 画像しかサポートせず、PDF は一般に複数ページなので、デフォルトでは 'ps:alpha' ではなく 'ps:color' デリゲートが使われます。'pngalpha' デリゲート方式を選ぶには、画像を読み込む前に「-channel RGBA」を使ってください。ページ数だけが欲しい場合は、ghostscript を使うほうがずっと速いことがあります。

  gs -q -sPDFname=document.pdf   pdfpagecount.ps
  %%Pages: 96

Windows と Ghostscript は少し複雑で、Windows レジストリの使用が必要です。

ImageMagick の特別な PDF 読み込みオプション

PDF の扱いに関する特別なオプション…

-units PixelsPerInch

PDF 文書を扱う(読み込みまたは作成する)ときに設定すべきです。これが何をするのか定かではありませんが、報告によれば、正しく動作するために設定すべきとのことです。

-define pdf:use-cropbox=true

Adobe 生成の PDF ファイルに従って、デフォルトの 'mediabox' ではなく 'cropbox' を使います。(基本的に、PDF 画像からの ghostscript 変換に「-dUseCropBox」を追加します。注: これは PDF が 1 ページしかない場合は機能しますが、複数ページの PDF の場合は正しく切り出されません。

-define pdf:use-trimbox=true

Adobe 生成の PDF ファイルに従って、デフォルトの 'mediabox' ではなく 'trimbox' を使います。

入力デリゲートの変更

システムデリゲートの変更は危険で、間違えると IM が postscript/PDF ファイルを読めなくなることがあります。また、セキュリティ(「ハッカー」)対策のため、システム定義のデリゲートを個人のデリゲートで置き換えることはできないので、管理者権限が必要かもしれません。デリゲート XML の構文と意味、および個人の入出力デリゲートの作成についての詳細は、画像フォーマットのデリゲートとコーダ を参照してください。フォーラムのトピック Convert EPS to JPG Unreliable では、システムの「delegates.xml」を編集して「-sDEVICE=bmpsep8」を「-sDEVICE=bmp16」に置き換えることが提案されました。他のユーザーは、これを「-sDEVICE=pnmraw」に変えるほうがうまく機能すると分かりました。私自身は試していないので、これについて、あるいはこれがどのバージョンの Ghostscript に当てはまるかについて、何の保証もできません。さらに情報があれば、教えてください。CMYK の postscript や PDF ファイルがある場合、Blog of John のページに、ghostscript がこの種の postscript を扱うようにデリゲートエントリを変更する方法(ghostscript の「-dUseCIEColor」オプションを追加)が詳しく書かれています。別の可能性は、pdftoppm を呼び出す個人の デリゲート を作ることです。たとえばタグを「pdfalt」と呼び、「xpdf」パッケージの「pdftoppm」や「pdfimage」プログラムを呼び出します。すると、あなたのストリームは次のようになります:

  magick pdfalt:image.pdf image.png

誰かデリゲート作成をやってみませんか? 教えてください! postscript ファイルを他のベクターフォーマットに変換したり、postscript を ImageMagick API に渡してビットマップに変換したりできる「pstoedit」を使ってみるのも良いでしょう。私はこれを実験もテストもしていないので、フィードバックが欲しいです。

PDF ラスター画像の抽出

PDF ページを特定のサイズや「密度」にレンダリングすることは、PDF が使うベクターグラフィックスの核心です。テキストや線画にはうまく機能します。しかしこれはまた、PDF 内のあらゆるラスター画像(ピクセル配列)がリサイズされなければならないことを意味します。しかしリサイズは「ロッシー」な操作で、そのラスター画像の元の密度を使わない限り、いくらかの画像劣化を生じます。その密度は PDF 内の画像ごとに異なり得ます! そのため、「密度」の参照なしに PDF からラスター画像を抽出できると有利です。ラスター画像は、poppler-utils または xpdf-utils ソフトウェアパッケージの一部である「pdfimages」プログラムを使って直接抽出できます。これらのソフトウェアパッケージには、PDF 処理に役立つ他の多くのツールも含まれています。Poppler for Windows と Xpdf Reader を参照してください。GhostScript の世話をしているのと同じ人々による「MuPDF」パッケージの「mutool」も見てください。テキストと画像を抽出するオンラインツールは Sumnotes(商用、限定された無料試用あり)です。より低レベルでは、Wolfgang Hugemann が、PDF(特にスキャナで生成された PDF)が含む画像を抽出できると言っています。基本的に、「stream」と「endstream」の間のバイト列を抽出し、別のファイルとして保存することによってです。

PDF テキストの抽出

GhostScript プログラム「ps2ascii」または「pstotext」を使えます。あるいは、テキストと画像の両方を扱う代替として、「pdftohtml」を見てください。これには XML 出力があり、Ross Presser は「段落の再構成がかなり得意」と報告しています。また、「pdftk」プログラムは、PDF を直接編集できるように「展開」したり、壊れた PDF を「修復」したりできます。

Postscript/PDF の出力オプション

以下の設定が、Postscript、Encapsulated Postscript、PDF 画像フォーマットの出力に影響することが知られています: 「[-page](https://imagemagick.org/command-line-options/#page)」「[-gravity](https://imagemagick.org/command-line-options/#gravity)」「[-compress](https://imagemagick.org/command-line-options/#compress)」「[-density](https://imagemagick.org/command-line-options/#density)」。デフォルトでは PDF 画像出力に圧縮が使われないため、PDF ファイルはしばしば必要以上に大きくなります。以下の表は、IM の圧縮モードと、結果として使われる Postscript の圧縮モードを対応させたものです。

PDF におすすめの圧縮は Zip (Deflate 圧縮) または Group4 (Fax) 圧縮です。

  magick image.gif -alpha off -monochrome -compress Zip -quality 100 \
          -units PixelsPerInch -density 600  image_deflate.pdf

  magick image.gif -alpha off -monochrome -compress Group4 -quality 100 \
          -units PixelsPerInch -density 600  image_group4.pdf

これら 2 つのコマンドは、白黒ページの直接変換よりもずっと小さな PDF ファイルを生成します。ただし、どちらが小さいかは画像により、結果のサイズを試してテストしないと判断できません。

Postscript/PDF の出力の代替手段

sam2p input.img output.pdf
sam2p_pdf_scale.pl 595 842 output.pdf

残念ながら、IM が作成したデフォルトの PDF では機能しません。-- Sebastian Krause、IM ユーザーメーリングリストより 複数ページの PDF 文書… perl を使って、IM とそのラスタライズ問題に頼ることなく、複数の PDF ファイルを結合できます…

#!/usr/bin/perl
#  Script   pdf-combiner.pl
use strict;
use warnings;
use PDF::Reuse;

prFile('combo.pdf'); # Output.
for (qw/a b c d/) # Inputs.
{
  prImage("result_$_.pdf");
  prPage();
}
prEnd();

JAVA ツールキットを使って、IM 生成の画像を PDF にマージし、IM が生成する単純なものよりも良い PDF を作ることもできます…

#!/bin/bash

for x in ./*.jpeg
do
    echo $x to ${x}.pdf
    magick $x -quality 75 ${x}.pdf
done

echo Merging...
java tool.pdf.Merge *.pdf

IM ディスカッションフォーラム の別のユーザーは、複数の PDF ページをマージするのに PDFjam を使うことも提案しました。

PbmPlus / NetPBM 画像ファイルフォーマット: PBM PGM PPM PNM PAM

PbmPlus または「NetPBM」画像操作フィルタ(unix コマンドライン)。これらの画像フォーマットには、「PBM」(ビットマップ)、「PGM」(グレースケール)、「PPM」(カラー)、「PFM」(浮動小数点、HDRI 用)、「PAM」(任意のフォーマット)、「PNM」(任意の NetPBM フォーマット)など、さまざまなスタイルがあります。これらのそれぞれ(「PAM」と「PFM」を除く)は、「生」のバイナリ形式(IM または NetPBM が書き出すときのデフォルト)か、プレーン ASCII テキスト形式(「[-compress](https://imagemagick.org/command-line-options/#compress) None」で設定)のどちらかにできます。もちろん IM はそのいずれも読めます。このフォーマットは「linear-RGB」色空間のみを使い、他のほとんどの画像ファイルフォーマットのように「sRGB」を使わないものとみなすべきです。ただし「linear-RGB」を使うときは深度 16 を使うべきで、深度 8 の画像で大きな丸め誤差を避けるよう注意が必要です。NetPBM フォーマットは通常、1 ファイルに 1 画像を保存します。ただし IM と他の多くの NetPBM ユーティリティは、複数の画像を単に連結したファイルを読み書きします。そのため、画像を書き出すときは、ファイルを書き出すときに適切な「[-/+adjoin](https://imagemagick.org/command-line-options/#adjoin)」設定をするのが良い考えかもしれません。(複数画像シーケンスの書き出し を参照)。PPM ファイルフォーマットは、実は ImageMagick にとって特に重要です。「ghostscript」デリゲートを介した Postscript と PDF 画像の変換中に使われる通信フォーマットだからです。また、「ffmpeg」コマンドからのようなビデオ画像処理の主要なフォーマットでもあります。入力には任意の「品質」または値域を使えます(16 ビットすなわち 65535「深度」まで)。たとえば、ここでは「ステップグラデーション」を生成するために、非常に珍しい値域 5 を使います。こんな奇妙な品質範囲を使える画像フォーマットを、私は他に知りません。 |

  echo "P2 6 1 5   0 1 2 3 4 5" | \
      magick - -scale 120x20  pgm_step_gradient.gif

リサイズされたグラデーション も見てください。そこでは NetPBM テキスト画像を使って非常に小さな(2 ～ 4 ピクセルの)画像を作っています。上記はまた、「ASCII」サブフォーマットがいかに役立つかも示しています。特に、シェルスクリプトに画像を追加する方法として、あるいは数値の配列から画像を生成する手段としてです。たとえば TXT: 列挙ピクセルフォーマット を参照してください。この使い方の一例は、ヒストグラム再分配の方法論 の例で示されています。

PbmPlus/NetPBM 対 ASCII データフォーマット

その ASCII 出力は、おそらく特定の画像から色値を抽出する最もきれいな方法で、これがまたスクリプトや単純な画像処理に理想的に適しています。

  magick -size 20x2 xc: +noise random -channel G -separate +channel \
          -depth 16  -compress none   pgm_random_values.pgm

出力がプレーンテキストのとき、行は画像の行の長さに揃うようには書かれないことに注意してください。しかし、さまざまな UNIX テキストユーティリティを使って出力を再整形できます。たとえば「tr」テキストユーティリティを使って、複数のカンマやスペースを単一の改行に置換・圧縮すると、すべての値を 1 行 1 値で配置でき、スクリプトで処理しやすくなります。また、IM では PGM と PPM の出力品質に深度 8 または 16 しか指定できません。一方、PbmPlus フォーマットは、その値に任意の「maxval」、2 のべき乗でないものすら使えます! ただし 16 ビット深度(maxval 65535)というハードリミットがあります。NetPBM 画像の実際の「maxval」をより細かく制御することは現在できませんが、将来、特別なコーダ設定を介して追加できるかもしれません。(要望があれば)。以下は、rose 組み込み画像から抽出した、0 から 255 までのグレースケール値の 9x9 配列を出力する別の例です。各ピクセル行の末尾に改行が来るように「pnmtopnm -plain」を使いました。

  magick rose:[9x9+0+0] -colorspace gray -transpose -depth 8 PGM:- |\
    pnmtopnm -plain

この NetPBM コマンドの古い変種には、「pnmtopnm -plain」と同じことをする「pnmnoraw」と「pnmtoplainpnm」があります。お使いの NetPBM パッケージの man ページを確認してください。開発者は、それをどう行うべきか心を決めかねているようです。これらの PbmPlus プログラムはいずれも「画像行」の末尾に改行を出力しますが、ImageMagick コーダはそれをしません。これにより、スクリプトでの画像処理がずっと簡単になります。以下は、非常に小さな ASCII PBM ビットマップを出力する例です。

  magick label:O pbm: | pnmtopnm -plain

PBM ビットマップは値の間にスペースを出力する必要すらないことに注意してください。ただし許可はされています(IM は出力し、PbmPlus ユーティリティは出力しません)。また、ビットマップでは白='0'(背景)、黒='1'(前景)であることに注意してください。これは XBM や PBM のようなビットマップフォーマットの標準で、ImageMagick はこの慣行を理解します。これが望ましくない場合は、画像を 反転 するか、色によるレベル化 を使ってビットマップ画像の希望の色を設定してください。

PbmPlus/NetPBM の深度制御

PGM と PPM 画像の深度をより細かく制御したいことがあります。たとえば、0 から 99 までのパーセンタイル範囲の値を使うなどです。1 つの方法は、NetPBM プログラム「pamdepth」を使うことです。これは画像を任意の範囲(内部限界 65335 まで)に変換できます。たとえば、以下は値の画像配列ですが、0 から 99 の出力値域を使っています。

  magick -size 9x9 radial-gradient: -depth 16 PGM:- |\
    pamdepth 99 | pnmtopnm -plain

以下は別の例ですが、今回は 反転レベル 演算子を使って出力値域を設定します。これにより値の変換をより細かく制御できますが、PGM 画像の「maxval」は画像の最大値に一致しません。

  magick -size 9x9 radial-gradient: +depth +level 0,99 PGM:- |\
    pnmtopnm -plain

上記コマンドの「[+depth](https://imagemagick.org/command-line-options/#depth)」は、画像ファイルの深度を IM の品質レベルと同じに設定するのに不可欠です。必要なのは、3 行目を '99' の値にリセット(または無視)し、必要なら画像を「生」のバイナリ NetPBM 画像フォーマットに圧縮し戻すだけです。ただし、PbmPlus/NetPBM は最大深度 65535(16 ビット)なので、これは IM の Q8 または Q16 バージョンでしか機能しません。

PbmPlus/NetPBM のコメント

IM は、PbmPlus/NetPBM ファイルフォーマットのヘッダ内の「コメント」行を読み書きし、保持します。たとえば…

  magick -size 2x2 xc:grey -set comment "by Anthony" -compress none PGM:-

ただし、PbmPlus 自身を含むほとんどのアプリケーションは、そうしたコメントを無視し、ファイルを処理するとそれらを失いさえします。

  magick -size 2x2 xc:grey -set comment "by Anthony" PGM:- | pnmtopnm -plain

PbmPlus/NetPBM 対 ImageMagick

PbmPlus/NetPBM 画像処理スイートは、かつてコマンドライン画像処理で ImageMagick の好敵手でしたが、画像の扱いと処理に、まったく異なる(より低レベルの)パイプラインフィルタリングの哲学を使います。これはシェルスクリプトでは使いやすいのですが、一般的なまたは非常に複雑な画像処理には使いにくくなります。また、画像が画像ファイルフォーマットへ/から変換される頻度がずっと高くなり、一般に多くの一時ファイルの使用を必要とします。PbmPlus/NetPBM 画像は一般に透明度を扱わず(新しい PAM フォーマットは扱います)、画像データとともに画像メタデータを渡す一般的な方法を提供しません。PbmPlus/NetPBM のすべてのフォーマット(ImageMagick の内部フォーマット、MIFF 画像ストリーミング を参照、と同様に)は、画像を単に連結または追加することで、複数の画像のストリームを扱えます。これにより、ビデオ処理のような、パイプライン化されたマルチ画像ストリーミングの画像処理方法に非常に適しています。ただし、一部の PbmPlus/NetPBM プログラムは単一の画像しか扱わず、複数画像のストリームを扱わないことに注意してください。とはいえ、より低レベルで ImageMagick より歴史が古いため、ビデオ画像の出力や扱いのような生の画像出力にしばしば選ばれます。PbmPlus 画像はまた科学データにもよく使われ、そのため画像は一般に、より一般的な非線形の「sRGB」色空間ではなく「linear-RGB」色空間で格納されます。注意が必要です。両方のパッケージは共存でき、私もいくつかの目的で ImageMagick の代わりに PbmPlus/NetPBM の実装を使うことがあります。たいていは、特定の低レベル画像処理を使うときや、画像形式で格納された値の配列を使ってスクリプトを書くときです。2 つのパッケージはうまく連携するので、本格的な画像作業には両方をインストールして使うことをおすすめします。 | _私は実は、そのソフトウェアの作業がほとんど行われていなかった時期に、1995 年の NetPBM の重要なパッチリリースを行った当人です。このため、PbmPlus ソフトウェアとそのシンプルな画像ファイルフォーマットをよく理解しています。

それ以来、それは異なる人々によって何度も再開発され、ついにきちんとしたオープンソースプロジェクトになったようです。さまざまなプログラムが成熟し、より良く連携し始めているようです。

しかし、その主な問題、すなわちメタデータの欠如と複雑さは残ったままです。しかし、ファイルフォーマットとしてのシンプルさが最大の利点で、非常に低レベルの画像とデータの操作に理想的です。

_
---|---

TIFF

  TIFF フォーマットは PhotoShop の独自フォーマットです。しかし、機能で膨れ上がり、
  使おうとしたほぼすべてのアプリケーションによって改変されてきたため、photoshop
  でさえもそのすべての変種を扱えるプログラムは存在しません。とはいえ Photoshop
  が最もよく読める見込みがあります。

  photoshop と特に作業しているのでない限り、あるいはアプリケーションが他の、より
  よく定義された画像ファイルフォーマットを受け付けないのでない限り、TIFF 画像ファイル
  フォーマットは避けるのが良いでしょう。

  私は TIFF 画像ファイルフォーマットも Photoshop も使いません。このフォーマットを IM
  で広範に使っているなら、所見をここに掲載できるよう私に提出してもらえませんか。
  そうすれば、あなたの仲間の TIFF ユーザーを助けられます。

  特定のソフトウェアパッケージが TIFF を読めるかどうかは、試してみるしかありません。
  それが、このフォーマットの問題です。



  TIFF と photoshop での density (解像度)…

  この問題の詳細と解決策については [Photoshop と density](basics.html#density_photoshop)
  を参照してください。



  JPEG から TIFF への変換…

    magick image.jpg image.tif

  これは、(JPEG 入力から継承した)JPEG 圧縮を使って TIFF ファイル内に画像を保存するか、
  あるいは次のようなエラーになります…

      Error: "JPEG compression support not configured"

  これは、TIFF ライブラリが JPEG 圧縮サポートを含んでいないことが原因です。

  いずれにせよ、これは良くありません。

  設定を変えて別の圧縮アルゴリズムを使うことで、この問題を回避できます:

      magick image.jpg -compress zip  image.tif
      magick image.jpg -compress lzw  image.tif
      magick image.jpg +compress      image.tif

  警告: TIFF で  -compress Group4  は機能しますが、画像からすべての透明・半透明ピクセル
  を除去した場合のみです。通常、上記の JPEG 画像と同じ方法で、最終保存の直前(最初のものは
  単一画像でのみ機能します)に
     -background {color} -alpha remove
  を使ってこれを確実に行えます。
  [画像からの透明度の除去](masking.html#remove) を参照してください。



  TIFF (と MIFF) の浮動小数点精度ファイル (IM v6.2.6-5 で追加)…

  これは(IM 自体が内部で浮動小数点を使う)HDRI 画像処理に特に良いです。

  単精度(float)には次を設定…
         -depth 32 -define quantum:format=floating-point
  倍精度(doubles)には次を設定…
         -depth 64 -define quantum:format=floating-point

  14 ビット TIFF 画像…
       magick logo: -sharpen 0x1 -depth 14 logo.tif

       tiffinfo logo.tif

       Image Width: 640 Image Length: 480
       Resolution: 72, 72 (unitless)
       Bits/Sample: 14
       Compression Scheme: LZW
       Photometric Interpretation: RGB color
       FillOrder: msb-to-lsb
       Orientation: row 0 top, col 0 lhs
       Samples/Pixel: 3
       Rows/Strip: 2
       Planar Configuration: single image plane
       DocumentName: logo.tif
       Software: ImageMagick 6.2.8 07/27/06 Q16 https://imagemagick.org

  12 ビット TIFF 画像…

  16 ビット TIFF 画像を 12 ビットに変換するには:
        magick image.tif -depth 12 image-12.tif

  純粋な白黒画像…

       magick image ...  -type truecolor -type bilevel   image.tiff

    通常の画像かつ最小のファイルサイズになり、Photoshop、Microsoft Windows
    Picture and Fax Viewer で正しい白黒の扱いになります。
       [TIFF の議論](https://magick.imagemagick.org/viewtopic.php?p=51723),
       _[RQuadling](https://magick.imagemagick.org/memberlist.php?mode=viewprofile&u=7913)_.


  エンディアンと fill-order
    TIFF データ値が格納される順序は、以下で制御されます。
       -endien                   バイトのグローバルな順序
       -define tiff:endian       Tiff フォーマットコンテナのエンディアン
       -define tiff:fill-order   バイト内のビット順序

    それぞれ MSB(デフォルト)または LSB の値を取りますが、
    "tiff:fill-order" は、"tiff:endian" が定義されていればその値に
    設定されます。ただしグローバルな endian の値からは設定されません。

    "tiff:endian" プロパティは画像コンテナのエンディアンです。"-endian"
    プロパティは画像ピクセルのエンディアンです。これらは異なることがあります。


  1 ストリップあたり 1 行だけで TIFF ファイルフォーマットを保存する

          -define tiff:rows-per-strip=1.
    1 ストライプあたりの行数を増やすには数値を増やします
          -define tiff:rows-per-strip=8
    フォーマット内のバイナリ整数の「エンディアン」順序も指定できます
          -endian MSB          -endian LSB

    (圧縮以外で)より小さな TIFF 画像にするには、  -depth 8  のようなオプションや
    設定を使って色品質を下げたり、  -alpha off  を使って画像からアルファ(透明度)
    チャンネルを除去したりすることも試せます。

    非グレースケールの色が存在しない場合、IM はグレースケール画像をグレースケール
    TIFF として保存します。次で非グレースケールとして保存するよう強制できます
          -depth 8  -type TrueColor


  IM 6.6.4-3 で追加
    「Software Creation:」メタデータ(プロパティ)を
    「Image Magick 6.**」以外のものに設定できます
        -set tiff:software "My Software"


  Windows Picture and Fax Viewer, Windows Explorer

    これらは、RGB など特定の Photometric Interpretation 値を持つ TIFF しか
    表示できません。IM のオプション…
        -compress LZW -type TrueColor

    photometric interpretation を切り替える (IM 6.3.2-10 で追加)
        -define quantum:polarity=min-is-black
        -define quantum:polarity=min-is-white


  複数ページ TIFF
    複数ページの TIFF を別々のページに分割したい場合、次のようなコマンドを
    使っても、IM は前のページを保持するために多くのメモリを使うので、問題が
    生じることがあります…
        magick "a.tif[i]" b%03d.tif

    これはバグ、あるいはおそらく将来の改善とみなせるかもしれません。

    より良い解決策は、IM 以外の「tiffsplit」プログラムかもしれません。


  TIFF と EXIF プロファイル

    Cristy の報告: libtiff デリゲートライブラリは EXIF プロファイルを
    サポートしますが、信頼性に欠け、あまりにも頻繁に障害を起こしたため、
    その呼び出しをコメントアウトしました。

    EXIF 属性を取得するには、これを試してください。

      magick identify -verbose -define tiff:exif=true image.tif

TIFF フォーマットは、クリップパスの形でビットマップマスクを持つことができ、「[-clip](https://imagemagick.org/command-line-options/#clip)」演算子を使って有効にできます。その「クリップ」マスクを使って、次のようにそのパスで画像をマスクできます…

  magick image_clip.tif  -clip \
          ...do_various_operations... \
          +clip-mask  image_masked.png

詳細は 書き込みマスクまたはクリップマスク を参照してください。

BMP, Windows ビットマップ

  Windows デスクトップアイコン画像フォーマット BMP(bit-mapped の略)は、
  非常に扱いにくい画像フォーマットで、可能なら避けたほうが良いでしょう。

  ImageMagick は 8、24、32 ビットの BMP 画像をサポートします。

  24 ビット BMP フォーマットではなく 8 ビットのカラーマップ BMP 画像を作るには、
  コマンドラインの末尾(出力画像ファイル名の前)に -colors 256 を追加します。
  回転やリサイズなどの操作を行ったあとに、画像に余分な色が追加されることがあります。
  -color についての詳細は Color Quantization を参照してください。

  何らかの透明度が存在するかどうかが、24 (RGB) または 32 ビット (RGBA) フォーマット
  の BMP 画像のどちらを使うかを制御します。"-alpha off" を使って画像の透明度を
  オフにできます。

  すべての色がグレースケールなら、'directcolor' グレースケール画像が生成されます。
  -type truecolor でこの挙動を止められると思います。


  ImageMagick が書き出すデフォルトの BMP4 画像を読めない古いプログラム(たとえば
  Windows の背景画像)がある場合は、次を使って BMP3 フォーマット画像の生成を強制できます…

       magick image BMP3:image.bmp

  このフォーマットは透明度を持たず、「印刷可能な画像」であるはずです。それが何を
  意味するにせよ。言い換えると「Windows」互換です。

  ただし、PNG 入力ファイルが使われ、それが gAMA と cHRM チャンク(ガンマと色度情報)を
  含む場合、そのいずれかが「magick」に BMP4 を書き出させます。BMP3 を得るには、その
  情報を取り除く必要があります。1 つの方法は、画像を PPM のような最小限の「画像データ
  のみ」の画像ファイルフォーマットを通してパイプし、BMP3 として再保存することです。
  面倒ですが、機能するはずです。

      magick image.png  ppm:- | magick - BMP3:image.bpm

  IM は深度 8 以外のレベルでは BMP を生成できません。ただし、NetPBM 画像処理セットを
  使って他の深度レベルへの最終変換を行えます(これには少なくとも IM の Q16 バージョン
  が必要です)…

       magick image -alpha off -colors 16 ppm:- |\
         pnmdepth 4 | ppm2bmp > image.bmp


  フォーマットの制限…

  BMP2: フォーマットのヘッダは、画像の幅・高さ・ビット深度(ピクセルあたりのビット数)
  の記述しか許しません。ビット深度は 1、4、8、24 のいずれかにできます。

  比較として、bmp3: フォーマットは 0、1、4、8、16、24、32 のビット深度を許し、x と y の
  解像度(メートルあたりのピクセル数)と画像データの圧縮を指定する追加フィールドを持ちます。

ICO

  複数解像度の ICO フォーマット画像を作るには、必要なすべての画像サイズを作り、
  それらをすべて同じ ICO ファイルに書き出すだけです。

    magick icon-16.bmp icon-32.bmp icon-64.bmp \
            icon-128.bmp icon-256.bmp   myicon.ico

  更新

    magick icon-256.png  \
            -define icon:auto-resize="256,128,96,64,48,32,16" \
            myicon.ico

これを Web ページに追加するには次を使います
  <LINK REL="shortcut icon" HREF="myicon.ico">

ただし、多くの Web ブラウザは今では ICO フォーマットだけでなく、ほとんどの画像
フォーマットを受け付けます。

RAW カメラ画像フォーマット (CRW,CR2,NEF,X3F,など)

ほとんどのデジタルカメラは、Sigma Foveon センサーと一部の Sony カメラを除いて、赤・緑・青のいずれか 1 つの特定の色の明るさを検出する何百万ものセンサーを使って、レンズが生成した画像をデジタルデータに変換します。カメラが人間の目とほぼ同じように色に反応するために、緑のセンサーは赤や青の 2 倍あります。私たちの目は緑の光にずっと敏感だからです。センサーは Bayer 配列と呼ばれるものに配置されます。この配置の説明と図については、たとえば デジタルカメラセンサーの理解 を参照してください。Bayer 配列のデータを、より馴染みのある RGB ピクセルに変換するには、デモザイクと呼ばれる処理が必要です。この操作を行っても、まだ表示する価値のある画像にはなりません。余分な緑のピクセルがあっても、カメラのセンサーは私たちが見るようには色を知覚しません。白い紙を 1 枚取り、明るい日光の下で見て、それから屋内で蛍光灯の下で見ると、どちらの条件でも白く見えます。しかし、同じ条件でデフォルトのカメラ設定を使ってその紙を撮影すると、画面に表示したときに紙はわずかに異なる色を示します。理由は、私たちの網膜の奥は、カメラと同じく紙から反射した同じ光を「見る」のですが、私たちの脳がその光を解釈してくれて、私たちは紙を白いと知覚するからです。カメラは単に紙から反射する赤・緑・青の光の量を測定し、蛍光灯の下では日光の下よりも青い光が多いので、その画像内の紙は日光の下で撮ったものよりも青く見えます。どちらも白い紙を示す画像を作るには、それらが「ホワイトバランス」される必要があります。これはグレーバランスやカラーバランスとも呼ばれます。ホワイトバランスについての詳細は ホワイトバランスの理解 を参照してください。raw ファイルには、正しいガンマの設定など、まだ他にも行わなければならない側面がありますが、これ以上詳細に立ち入らなくても、raw ファイルがモニタで見られる画像になる前に多くの処理が必要であることは明らかです。カメラの raw ファイルはしばしばデジタルネガと呼ばれます。写真を撮ってカメラに JPG 画像を生成させると、デモザイクとその他すべての調整が行われています。しかし、たとえば写真を撮る前にカメラで正しいホワイトバランスを設定し忘れた場合、JPG ではあまり修正できません。元画像についての多くの情報が失われているからです。一方、カメラから JPG ではなく raw ファイルを生成していれば、raw からの変換中に、他のパラメータとともに特定のホワイトバランス設定を選べ、結果の画像が正しく見えなければ、戻って設定を変え、正しく見えるまで再変換できます。これは、フィルムのネガからより多くのプリントを作る能力に似ています。フィルムのネガがなければ、フィルムが最初に現像されたときに得られる 4x6 のスナップショットの 1 つを 8x10 に引き伸ばすことはできません。ImageMagick はさまざまなフォーマットを扱えますが、raw カメラファイルを変換する方法は「知らない」ので、IM は「[dcraw](http://www.cybercom.net/~dcoffin/dcraw/)」プログラムをデリゲートプログラムとして使い、raw ファイルを、IM が理解するフォーマット、すなわち TIFF(「-T」フラグ付き)または PNM に変換します。これは raw カメラ 画像向けに設計されており、たとえばスキャナからのものではないことに注意してください。「[dcraw](http://www.cybercom.net/~dcoffin/dcraw/)」プログラムは、Canon、Fuji、Kodak、Nikon、Sony が製造したカメラのものを含め、多数の異なる raw フォーマットを扱えます。「dcraw」がお使いの raw ファイルを認識するかどうかは、サンプルを識別するよう求めることで判断できます。たとえば、コマンド:

  dcraw -i CRW_9641.CRW

は次を返します…

CRW_9641.CRW is a Canon EOS 10D image.

IM が デリゲート(「-list delegate」を使って一覧表示)を使って dcraw に変換させるとき、画像処理に影響する 2 つのフラグを指定します:

 dcraw -w -4 -O output_file input_file

'-w' フラグは、dcraw が raw ファイル内のホワイトバランス情報を、見つかれば使うことを意味します。情報が見つからない場合、dcraw は画像全体の平均をホワイトバランスの基準として使います。'-4' フラグは、dcraw が raw 写真をデモザイクしホワイトバランスするだけで、結果を 16 ビット線形画像(ピクセルあたり 48 ビット)として出力することを意味し、これはデフォルトの Q16 バージョンの IM に適しています。'-w' と '-4' が唯一指定された画像処理フラグなので、dcraw が使ういくつかのデフォルトがあります。出力色空間は sRGB になり、ICC プロファイリングは行われません(私のシステムでは、dcraw は LCMS ライブラリなしでコンパイルされているのでプロファイリングできません)。'-4' フラグが設定されているという事実は、レベル調整やガンマ補正を含む多くの処理ステップが省かれたことを意味し、そのため結果の画像は 暗く見えます。意図は、ユーザーが「Photoshop」「Paint Shop Pro」、あるいは「ImageMagick」のような画像エディタで画像を処理し、レベル、ガンマなどを自分で調整することです。この場合、画像は色あたり 16 ビットをサポートするフォーマット(たとえば TIFF)に出力すべきです。dcraw が 16 ビットファイルを生成するからといって、16 ビットすべてが有用なデータを含むわけではないことに 注意 してください。たとえば、Canon 10D デジタル一眼レフからの raw 画像は色あたり 10 ビットです。Canon や他のメーカーのより最近のカメラは色あたり 14 ビットです。raw 写真を完全に変換したい場合は、'-4' フラグを外して、dcraw がデモザイク、ホワイトバランス、明るさ・ガンマ補正などを行うようにする必要があります。この場合、dcraw は 8 ビットファイル(ピクセルあたり 24 ビット)を出力します。この画像をさらに処理する予定なら、PNG として出力し、JPEG 圧縮アーティファクト を避けるのが最良です。JPEG フォーマットは、実際の使用のための最終ステップとしてのみ使うべきです。実際、画像処理の中間ステップには、PNG(または IM の内部フォーマット MIFF)のようなロスレスフォーマットを使うのが常に良い考えです。「raw」カメラ画像フォーマットの読み込み方法を制御できる特別な DCRaw デリゲート を追加できます。さらなる情報は、DCRaw Web サイト、および dcraw のオプションフラグの多くについての情報やさまざまなフラグを使った raw 画像のヒストグラムを含む DCRaw チュートリアルサイト を参照してください。DCRaw by Example も参照してください。上記の覚え書きは、もともと jhfry による IM フォーラムのトピック Converting RAW images から抽出され、el_supremo によって大幅に書き直されました。

MPEG, M2V, AVI ムービー

  IM はムービーの作成があまり効率的ではありません。仕事はこなしますが、汚れ仕事の
  多くを行うために外部プログラム「mpeg2encode」が必要です。

  問題は、IM がビデオを扱うようには設計されておらず、静止画像や小さな画像シーケンス
  を扱うように設計されていることです。つまり、できないわけではありませんが、それは
  その目標ではありません。特に、IM は一般にすべての画像をメモリに読み込んでそこから
  処理します。大きなまたは長いビデオでは、これはあまり効率的ではありません。

  しかし、小さなフレームシーケンスの処理では、本当に右に出るものはありません。実際、
  ほぼすべての Linux ビデオ操作プログラムが、タイトル、しゃれたシーンチェンジ、その他の
  効果を生成して、より大きなビデオ開発の後処理を完成させるのに ImageMagick を使います。
  ただし、その処理は小さなビデオシーケンスに限られます。

  とはいえ、IM に何ができるか見てみましょう。

  **フレームからビデオへ**

  画像が正しいアスペクト比でないと、古い mpeg プレーヤーで失敗するという報告がいくつか
  あります。MPEG II 拡張 (m2v:) を代わりに使ってください。

  また、次を使うときに起こり得る重い圧縮ピクセル化を避けるために m2v を使ってください…

      magick *.jpg glacier.mpg

  たとえば代わりに次を使います…

      magick *.jpg m2v:glacier.mpg

  大きなアニメーションを行うには、多くの一時容量が必要かもしれません。通常の /tmp とは
  別のディレクトリを次のように指定できます…

      setenv MAGICK_TMPDIR /data
      magick -limit memory 0 -limit map 0 *.jpg image.m2v

代替手段…

  PNG 画像を MPEG2 ビデオストリームに変換するには、MNG マルチ PNG ファイルの代わりに、
  次のデリゲーションを使います…

       png2yuv -j file%08d.png -I p -f 25 -b 1 | \
         mpeg2enc -f 3 -q 3 -b 5000 -o out.m2v

  詳細は [mjpeg.sf.net](http://mjpeg.sf.net/) を参照してください。


  IM フォーラムで、オープンソースプロジェクト「[ffmpeg](http://ffmpeg.org/)」で
  まずまずの結果が報告されました。これはかなり標準的な linux パッケージのインストールの
  ようです。

     ffmpeg -f image2 -i %03d.jpg -vcodec mjpeg -y anim.mpg

  透明な背景の MVG を抽出する
      magick -background none -size 320x240 sample.mvg out.png


  Michael Lenh が書きました…
  ついに mplayer を使って非常にセクシーなビデオを作れました

    mencoder "mf://data/p*.png" -mf fps=40 -o particle.avi -ovc lavc

  結果は次で見られます…

    http://www.mathematik.uni-ulm.de/~lehn/particle.avi
    http://www.mathematik.uni-ulm.de/~lehn/temperature.avi


  [IM フォーラムの議論](https://magick.imagemagick.org/viewtopic.php?f=1&t=18724) で
  [mabu](https://magick.imagemagick.org/memberlist.php?mode=viewprofile&u=19117) は
  「_MENCODER を使え、わお、1000 倍くらい速くて実際に動く_」と言いました…

     mencoder -nosound mf://*.jpg -mf w=800:h=371:type=jpg:fps=15 -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=2160000:mbd=2:keyint=132:v4mv:vqmin=3:lumi_mask=0.07:dark_mask=0.2:mpeg_quant:scplx_mask=0.1:tcplx_mask=0.1:naq -o output.mpg

  おそらく不要な余分なオプションがありますが、.jpg ファイルから素敵なタイムラプスを
  作れます。


  Dean S. Messing は transcode を使っています…

     find . -type f -name '*.png' | sort > filelist
     transcode -x imlist,null\
            --use_rgb\
            -y raw,null\
            -f 60\
            -i filelist\
            -g 4096x2160 \
            -j 540,1024,540,1024\
            -o video.avi\
            -H 0

   -j (クリップウィンドウ) は不要なら省けます。-g は出力サイズです。

   Wolfgang Hugemann は、Windows Vista 下の 'VirtualDub' として知られる新しい代替手段を
   提案しています。これはビデオを実行したり、画像フレームのフォルダから直接変換したり
   できます。

   警告: 「mplayer」は 1 フレームだけの mpeg ファイルを好まないようです。一方
   「ffplay」は問題ないようです。


   **ビデオからフレームへ**

   「[mplayer](http://www.mplayerhq.hu/)」と「mencode」は、IM よりもビデオを一連の
   フレームに変換するのが効率的です。その上、ほぼあらゆるビデオ(と音声)コーデックを
   扱えます。

   たとえば、ビデオの 1 分 30 秒地点から 5 フレームを 320x240 に拡大縮小して取り出すには、
   次を使います…

      mplayer file.mov -vf scale=320x240 -ss 01:30 -ao null \
              -vo png:z=3 -frames 5

   その他の代替手段には「[ffmpeg](http://ffmpeg.org/)」オープンソースライブラリが
   ありますが、これも「[mplayer](http://www.mplayerhq.hu/)」の扱いの一部です。

MNG, Multiple-image Network Graphics

Example Ming Animation の議論より Barry Loo が寄稿。 MNG(ミングと発音)は PNG に基づくオープンフォーマットで、GIF などに代わるアニメーションビットマップを提供します。透明度(半透明と完全透明の両方)、圧縮(ロッシーとロスレスの両方)、最大 32 ビットの色深度を許します。この色深度の増加が、このフォーマットを他と本当に一線を画すものにしています。GIF は合計 256 色までしかサポートせず、多くのグラフィックには十分ですが、写真やグラデーションは劣化します。GIF アニメーションの作成で使えるほとんどのアニメーションオプションは、MNG の作成にも使えます。 |

magick -size 101x101 radial-gradient: \
        \( -clone 0 -level 00,100% +level-colors ,#F00 \) \
        \( -clone 0 -level 10,100% +level-colors ,#F12 \) \
        \( -clone 0 -level 20,100% +level-colors ,#F24 \) \
        \( -clone 0 -level 30,100% +level-colors ,#F36 \) \
        \( -clone 0 -level 40,100% +level-colors ,#F46 \) \
        -delete 0  -duplicate 1,-2-1 -set delay 1x30 -loop 0 pulsing.mng

上記コマンドは radial-gradient 画像を生成し、それをクローンして調整し、赤からより明るい赤オレンジへの脈動を作ります。これを複製して逆向きの パトロールサイクル を作ってから、30 秒のループ MNG アニメーションを作成します。残念ながら、ほとんどの Web ブラウザは現在 MNG をサポートせず、多くのビデオプレーヤーはループアニメーションを 1 周しか表示しません。上の欠けた画像フレームをクリックすると、アニメーションをダウンロードして IM Animate コマンド を使って見られます。MNG フォーマットの詳細は MNG Web サイト を参照してください。

DPX, Digital Picture Exchange フォーマット

このフォーマットは、広範なヘッダ情報と、RGB または YCbCr ピクセル記述を使ってさまざまなビット深度で高ダイナミックレンジと対数色値を扱えるフォーマットの柔軟性を、特に活用する映画・効果業界で使われます。これは Kodak の Cineon フォーマット(より映画特化のヘッダを持つ)に基づいていますが、それを大きく上回ります。その使用の一例は、後処理で使うためにフィルムをスキャンする場合です。各フレームは、2k(幅 2048 ピクセル)から 8k(幅 8192 ピクセル - IMAX フレーム用)まで、色成分あたり 8 ～ 64 ビットで、個別の .dpx ファイルとして格納されます。これらのシーケンスは、その後、合成ソフトウェアを使って処理され、色を変えたり視覚効果を加えたりします。完成したら、デジタルでテープに記録されたり、フィルムに投影し戻されたりします。各ピクセルの色値はしばしば対数的に格納され(特にシーケンスがフィルムに転送し戻される予定の場合)、これは元のフィルムのエマルジョンに色情報がどう格納されているかの濃度をより自然に反映します。変更なしで見ると、対数ファイルは非常に低コントラストに見えるため、対数画像を、画像がフィルムに転送し戻されて映画館で投影されたら見えるであろうものに似た何かに変換するために、「ルックアップテーブル」が必要です。画像を線形にし(ほとんどの典型的なコンピュータ画像のように)ガンマレベルを調整するほかに、このテーブルは黒点と白点がどこにあるかを設定します。色成分の値が 0 から 1023 までの 10 ビット対数画像の場合、黒点と白点は通常、黒が 95、白が 685 に設定されます。これが意味するのは、対数ファイルは、線形版が純粋な白として表示するものより明るく、純粋な黒として表示するものより暗い色値を格納するということです。この余分な情報は、画像が dpx ファイルとして格納されたあとに明るさを変えたい効果アーティストのために、利用可能なまま残ります。一例として、この情報が失われていた場合、画像の明るさを一様に下げるとハイライトが暗くなりますが、この余分な情報があれば、ハイライトは代わりにサイズが小さくなり、以前は明るすぎて見えなかった詳細を見せ始めます。後者は、現実世界で起こることにはるかに近いです。ヘッダには、制作に関連するフィルムおよび/またはテレビ固有のデータを含められます。たとえば、テレビヘッダには SMPTE タイムコードを含められるので、制作の編集から dpx シーケンスとして書き出されたショットを、何らかの効果が加えられたあとに簡単に置き換えられます。フィルムヘッダは、フレームが由来したフィルムリールについての情報や、撮影中に使われたさまざまなカメラ設定を保持します。これらの詳細はすべて、画像がポストプロダクション会社間で渡されるときに画像とともに残ります。

DPX ファイルへのタイムコードの追加

次を使って、任意の dpx ファイルにタイムコードを追加できます:

  magick -define dpx:television.time.code=10000215 \
          originalFile.00001.dpx    alteredFile.00001.dpx

フィルムやアニメーションのシーケンスを成す数千のファイルそれぞれに対してこのコマンドを実行するのは、明らかに非常に長い時間がかかります。単純なスクリプトを ImageMagick とともに使って、シーケンス内の各フレームのタイムコードを自動的にインクリメントできます。たとえば Perl スクリプト dpx_timecode.pl を参照してください。
上記のコピーは、IM のメインドキュメントの 映画フォーマット入門 に追加されました。上記は、DPX フォーマットに関する長い IM フォーラムの議論からの、Seth Dubieniec のご厚意によるものです。彼は現在 DPX アプリケーションを開発中なので、さらなる DPX 情報が今後来そうです。

**追加の覚え書き(未整形)…**

-depth 10  を追加すると、IM は 10 ビット DPX ファイルを出力します。
-- James Fancher


たとえば出力 DPX 画像でガンマを設定したい場合は…
     -define dpx:television.gamma=1.7

DPX 画像の色空間は、画像エレメント記述子と transfer-characteristic によって
定義されます。transfer characteristic が PrintingDensityColorimetric なら、
色空間を LogColorspace に設定します。色空間が Log の場合のみ、ガンマと黒点/白点を
適用して RGB 色空間に変換します。お使いのプログラムが SMPTE 標準に準拠していないか、
ImageMagick が標準を正しく解釈していない可能性があります。2 つの DPX 画像の URL を
投稿してもらえれば、ダウンロードして、ImageMagick にバグがあるのか、お使いの
プログラムにバグがあるのかを判断しようとします。

以下は ImageMagick 6.3.8-3 で機能します

  magick -colorspace log AfterEffectsFile.dpx -set gamma 0.5 \
          -set reference-black 95 -set reference-white 685 image.jpg

あるいは、SMTPE のドキュメントを見てください。
-- Cristy


次を使って dpx ファイルにテキストユーザーデータを追加できます

  magick image.dpx   -set dpx:userdata "some text"    new.dpx

-- Cristy

PSD

PSD 画像ファイルは Photoshop の作業画像ファイルフォーマットで、XCF が GIMP の作業ファイルフォーマット、MIFF が ImageMagick 自身の作業ファイルフォーマットであるのと同じです。これらは通常、複数の画像を含み、最初の画像は現在の作業画像を 1 つにまとめたものです。これにより、作業画像が現状どうなっているかを見るのに便利で、通常「サムネイル化」に使われます。マルチ画像ファイルフォーマット内の他のすべての画像は、その最初の合成画像を生成するのに使われる画像です。つまり、保存時にユーザーが作業していた個々の作業レイヤー画像です。ですから、「最終」画像だけが欲しい場合は、入力ファイル名に「 '[0]' 」を追加して作業画像を捨て、1 つにまとめた最初の画像だけを使うことをおすすめします。ただし、個々のレイヤー画像を扱う予定なら、「 '[1--1]' 」を使って最初の画像を飛ばしてください。追加のレイヤー画像が見つからない場合は、代わりに最初の画像が返されます。「-delete 0」を使うことはおすすめしません。最初の画像のあとにレイヤー画像が続かない場合、画像がまったく返されないからです。追加の覚え書き… さらに情報を提供できる、あるいはこのフォーマットでの IM の使用のまとめを提出したい場合は、ぜひどうぞ…

   CMYK 画像の PSD では、変換時に IM に正しいプロファイルを使わせる必要があるかも
   しれません(IM が LCMS デリゲートライブラリとともにインストールされていることを
   確認してください)…

     magick Test_CMYK.psd -strip -profile USWebCoatedSWOP.icc \
             -profile sRGB.icc Test_RGB.png

   詳細は上の [プロファイル](#profiles) を参照してください。


   PSD 画像が「プレビュー」画像を含む場合。この画像は 2 画像読み込みの最後の画像
   として返されます。

   IM が最後の画像を決して読まないようにするには、次を使います…
       magick test.psd[0--2] -flatten test.jpg
   つまり、最後を除くすべての画像を読みます。ただし最初は常に読みます。
   これは読み込み後に「-delete」を使って行うことはできません。

WMF

Microsoft Office 一連のプログラムで使われる、拡大縮小可能なクリップアートによく使われるもう 1 つのベクターフォーマットです。入力は、画像を読み込む前に「[-density](https://imagemagick.org/command-line-options/#density)」を変えることで拡大縮小できます。ベクター画像フォーマット も参照してください。

Flash アニメーション (SWF)

Flash アニメーションは現在 IM ではサポートされていません。ただ完全を期すために、Scott Bicknell は SWF Tool ユーティリティ「swfextract」が flash アニメーションから jpeg や png のフレームを抽出できると報告しています。Wolfgang Hugemann はまた、Windows フリーウェアツール「IrfanView」もこれを行えるかもしれないと考えています。良いデリゲート候補に聞こえます。

Web ページの画像への変換 (HTML)

IM が HTML を読み込むと、html を postscript に変換する html2ps を探し、それを画像としてレンダリングできます。これはあまりうまく機能しませんが、機能はします。完全な Web ブラウザを使うほうがずっと良い方法です。それはこのタスクを可能な限り最良の方法で行うように設計されているからです。ブラウザを使う最も単純な方法は、ページをブラウザに読み込んで、そのスクリーンショットを撮るだけです。これはページの完璧な画像を得ますが、ブラウザのウィンドウサイズに限られます。別のやり方は、IM に変換させるのではなく、ブラウザにページを postscript として出力させることです。これは Web サイトをより小さなページにかなりきれいにページ分割するはずです。LINUX では、Web サイト全体を表示するブラウザを実行するのに十分な大きさの仮想 X windows ディスプレイサーバーを起動できます。これは非常に縦長のディスプレイになり得ます。そのブラウザをその中で実行し、ディスプレイ全体を埋めるように設定します。Web サイトを読み込み、再びスクリーンショットを撮ります。このやっかいな処理全体を自動化できるスクリプトを見たことがあります。ただし、非常に縦長の画像になることがあります。また、ディスプレイをどれくらい大きくすればよいかを知るのも難しいです。基本的にこれは簡単では なく、最良の解決策は html から画像への生成ではなく、最終的な画像処理にのみ IM を使います。

PCL 印刷フォーマット

IM の PCL はデフォルトでバージョン 6 PCL です。バージョン 5 には、画像を白黒に変換する必要があります。たとえば…

  magick image.png -monochrome image.pcl

Kodak PhotoCD または ProPhotoCD (PCD)

Kodak PhotoCD ファイルはマルチ解像度の画像ファイルフォーマットです。つまり、各ファイルは同じ画像を 6 つの異なるサイズで含み、「ピラミッド画像」として知られるものを形成します。ファイル内の最初の画像は最低解像度(最小サイズ)で、最後が最高解像度(3072×2048 ピクセルの最大サイズ)です。ユーザーは通常、処理のために最大解像度の画像を求めるので、PCD 画像を JPG のような他のフォーマットに変換する方法は、画像ファイルから 6 番目(インデックス 5)を取り出すことです。たとえば…

  magick -colorspace RGB image.pcd[5] image.jpg

「-colorspace RGB」オプションは、色を正しくするために必要です。情報は Magick-Users メーリングリストからの Wolfgang Hugemann のご厚意によります。

Raw RGB とグレーデータ

Imagemagick には、生の画像データを扱うためのいくつかのファイルフォーマット、具体的には「RGB:」と「GRAY:」があります。また、そのデータを定義する設定も提供します。たとえば、RGB の生データを出力するには…

  magick image.jpg -depth 8  image.rgb

「[-depth](https://imagemagick.org/command-line-options/#depth)」設定は、書き出される(そして後で読み込まれる)整数のサイズを指定します。この場合、RGB の 1 ピクセルあたり 3 バイトの 8 ビット値(24 ビット画像)です。生の画像データを扱うときは、適切な深度を指定することが常におすすめです。16 ビットの「[-depth](https://imagemagick.org/command-line-options/#depth)」は値あたり 2 バイトを生成し、その場合、「[-endian](https://imagemagick.org/command-line-options/#endian)」つまりバイト順序を、'MSB'(最上位バイトが先)または 'LSB'(最下位バイトが先、デフォルト)のどちらかに指定する必要があるかもしれません。rgb は純粋に画像データであり、画像の幅と高さすら含まないことに注意してください! 一部のアプリケーションはデータが特定のサイズだと「想定」するので、データがこのサイズになるように IM を使う必要があるかもしれません。たとえば、これは画像を 512x512 ピクセルになるようにリサイズしパディングします。

  magick image.jpg -resize \>512x512 \
          -background black -gravity center -extent 512x512 \
          -depth 8  image.rgb

生の RGB(または GRAY)データを ImageMagick に読み込むときは、画像がどれくらいの大きさかを指定する必要があります。たとえば…

  magick -size 512x512 -depth 8 image.rgb    image.png

これは Imagemagick が読み込むデータ量を正確に定義します。生データに余分なヘッダ情報が付いていることがあります。IM がこの情報を読み飛ばせるようにするには、「[-size](https://imagemagick.org/command-line-options/#size)」設定で 'byte_offset' を指定できます。たとえば 48 バイトのヘッダを飛ばすには…

  magick -size 512x512+48 -depth 8 image.rgb    image.png

これは、IM が「[-size](https://imagemagick.org/command-line-options/#size)」設定で 3 番目の数を使うことを私が知る唯一の場合です。生の画像データ(グレースケール)の使用のさらなる例については、IM ディスカッションフォーラムのトピック How to convert raw image to compressed tif? を参照してください。

浮動小数点データ

正規化された浮動小数点数を使って RGB を読み(書き)することもできます。
ただしこれには特別なコーダの -define 設定の使用が必要です。
HDRI 浮動小数点ファイルフォーマットを参照してください
   https://usage.imagemagick.org/basics/#hdri_formats


C コードで生成した RGB 浮動小数点画像 (HDRI)…

   float red = 1.0f;
   float green = 1.0f;   /* appropriate data */
   float blue = 1.0f;

   /* for exach pixel in image... */
   fwrite (&red, sizeof(float), 1, file);
   fwrite (&green, sizeof(float), 1, file);
   fwrite (&blue, sizeof(float), 1, file);

読み込みオプション…

  magick -size 200x100 -depth 32 -define quantum:format=floating-point
          -define quantum:scale=65536.0   -endian lsb   input.rgb
          output.png

quantum:format はファイルから浮動小数点数を読むことを定義します。
一方 -depth は浮動小数点のサイズ(32 = floats、64 = doubles)を定義します。

quantum:scale は、浮動小数点数を、正規化された 0.0 ～ 1.0 の値から、私の Q16
バージョンの IM が必要とするメモリ内の 16 ビット品質レベルへどうスケールするかを
定義します。