ImageMagick の例 --
リサイズまたはスケーリング (一般的なテクニック)

目次
ImageMagick の例の序文と目次
画像のリサイズ
その他の特殊なリサイズ演算子
  • Geometry - 最後の画像のみリサイズする
  • Thumbnail - プロファイルを削除してリサイズする
  • Resample - 画像の解像度を変更する
  • Scale - ピクセル平均化で縮小する
  • Sample - 行/列の複製/削除によってリサイズする
  • Magnify - 「ピクセルスケーリング」で画像サイズを2倍にする
  • Adaptive Resize - ぼかしなしで小さくリサイズする
  • Interpolative Resize - 補間方法を使用してリサイズする
  • Liquid Rescale - シームカービングを使用してリサイズする
  • Distort Resizing - 自由形式のリサイズ
  • Distort vs Resize - 直交 vs 円筒
 
リサイズテクニック  
リサイズ/リサンプリングフィルタ (別のセクション)
Nicolas Robidoux によるリサンプリング (別のセクション)
ここでは、さまざまな方法で画像を拡大および縮小する方法について説明します。画像はそのまま残りますが、個々の色の点は、より小さい/大きいキャンバス領域を使用するためにマージまたは拡張されます。これは画像の解像度(実際の1インチあたりのピクセル数)に関連していますが、それは最終的に画像がどのように使用されるかの産物であり、直接画像処理の真の関心事ではありません。

画像のリサイズ

画像のサイズを変更する最も明白で一般的な方法は、画像をリサイズまたはスケーリングすることです。画像の内容は、目的のサイズに合わせて拡大されるか、より一般的には縮小されます。しかし、実際の画像のピクセルと色が変更されますが、画像によって表される内容は本質的に変更されません。ただし、画像のリサイズは難しい場合があります。画像を非常に有害な方法で変更する可能性があり、「最良の方法」はありません。最良の方法は、リサイズプロセスから実際に何を望むかによって主観的だからです。「最良」または「完璧」な方法がないため、検討したいオプションがたくさんあります。IMは常に、画像のリサイズにおいて最大限の制御範囲を提供するためのオプションを提供しようと努めてきました。何百もの可能性、スタイル、テクニックがあり、リサイズの専門家でさえ、画像のサイズを変更する新しい、異なる方法を常に模索しています。もちろん、ほとんどの人にとって、通常のデフォルトオプションで十分です。一般的な使用を念頭に置いて設計されているからです。リサイズ演算子は、現実世界の画像に対して非常に優れた結果を生成するように非常に注意深く設計されています。つまり、図や線画に使用できないということではありませんが、そのようなタイプの画像の場合、後で説明する高度なオプションの一部を使用する必要がある場合があります。
リサイズする画像を指定する際に最初に考慮すべきことは...
本当に画像を変更したいですか? リサイズすると画像が大幅に変更されるため、不要な「アーティファクト」を回避または最小限に抑えることが最も重要です。おそらく、エッジのわずかなシェーブ、またはより一般的なクロップの方が、画像の全体的なリサイズよりも優れた望ましい結果が得られます。一般的に見栄えが良くなり、残された領域は元の完全なコピーになります。画像をリサイズしない方が良い場合が多いため...
リサイズされた画像が同じサイズの場合、リサイズは何も実行しません。
この例外(常に例外があります)は、実際に "-filter" 設定を使用してリサンプリングフィルターを指定した場合です。その場合、通常の「画像がリサイズされない場合は何もしない」が無効になり、フィルターが適用されます。ただし、多くのフィルター(デフォルトのフィルターでさえ)は画像をわずかにぼかす可能性があります。それは彼らの性質の一部です。そのため、通常、このnoopリサイズの「ショートサーキット」は良いことです。リサイズ演算子の引数は、画像を合わせる領域です。この領域は、画像の最終的なサイズではなく、画像を合わせる領域の最大サイズです。つまり、IMは最終的なサイズよりも画像のアスペクト比を維持しようとするため( '!' フラグが指定されていない限り)、最終的な寸法の少なくとも1つ(両方ではない場合)は、指定された引数と一致する必要があります 画像。それでは、はっきりさせておきましょう...
リサイズは、画像を要求されたサイズに*合わせます*。
要求されたボックスサイズを*埋めません*。
アスペクト比は基本的に、入力画像の円が出力画像の円のままになるように維持されます。つまり、特に指示がない限り、画像は押しつぶされたり絞られたりすることはなく、リサイズされるだけです。たとえば、ここでは、2つのソース画像(1つの大きい画像と1つの小さい画像)を64x64ピクセルの正方形のボックスに収めようとします。

  magick dragon_sm.gif    -resize 64x64  resize_dragon.gif
  magick terminal_sm.gif  -resize 64x64  resize_terminal.gif
[IM Output] ==> [IM Output]  [IM Output] ==> [IM Output]
ご覧のとおり、64x64の正方形の画像は "-resize" では*生成されませんでした*。実際、画像は、指定されたサイズに最適に収まるように、拡大または縮小されただけです。 **アスペクト比を無視する( ' `!`' フラグ)**
必要に応じて、 "-resize" にアスペクト比を無視して画像を歪ませ、常に指定されたサイズとまったく同じ画像を生成するように強制することができます。これは、サイズに文字 ' `!`' を追加することによって行われます。残念ながら、この文字は、さまざまなUNIXコマンドラインシェルによって特別な目的で使用されることもあります。そのため、文字を保持するために何らかの方法でエスケープする必要がある場合があります。

  magick dragon_sm.gif    -resize 64x64\!  exact_dragon.gif
  magick terminal.gif  -resize 64x64\!  exact_terminal.gif
[IM Output] ==> [IM Output]  [IM Output] ==> [IM Output]
**大きい画像のみ縮小する( '`>`' フラグ)**
よく使用されるもう1つのオプションは、IMを制限して、指定されたサイズに収まるように画像を縮小することです。拡大はしません。これは '`>`' リサイズオプションです。指定されたサイズよりも「大きい」画像にのみリサイズを適用することを考えてください(少し直感に反します)。

  magick dragon_sm.gif    -resize 64x64\>  shrink_dragon.gif
  magick terminal.gif  -resize 64x64\>  shrink_terminal.gif
[IM Output] ==> [IM Output]  [IM Output] ==> [IM Output]
このオプションは、画像のディスク容量を節約する場合、またはサムネイル生成において、画像の拡大は一般的に「ぼやけた」拡大を生成する傾向があるため望ましくない場合に非常に重要です。
縮小のみフラグ( '`>`' フラグ)は、UNIXシェルとWindowsバッチスクリプトの両方で特殊文字であり、その文字をエスケープする必要があります(シェルではバックスラッシュ '`\`>'`'、Windowsバッチでは '`^>`' を使用)。また、HTML Webページでも特殊であるため、PHPスクリプトでも特別な処理が必要になる場合があります。
**小さい画像のみ拡大する( '`<`' フラグ)**
前のフラグの逆は '`<`' で、指定されたサイズよりも小さい画像のみを拡大します。これはめったに使用されません。最も注目すべき用途は、「`1x1<`」のような引数です。このリサイズ引数は、実際には画像をリサイズしません。言い換えれば、これはnoopであり、常に "-resize" を使用するプログラムやスクリプトでリサイズ操作をショートサーキットすることができます。それ以外の場合は、おそらくこの機能を実際に使用したくありません。この「ショートサーキット」引数を使用する例としては、 "-geometry" の " `magick montage` " 設定があります。詳細については、モンタージュとジオメトリ、注意が必要を参照してください。
拡大のみフラグ( '`<`' フラグ)は、UNIXシェルとWindowsバッチスクリプトの両方で特殊文字であり、その文字をエスケープする必要があります(シェルではバックスラッシュ '`\`<'`'、Windowsバッチでは '`^<`' を使用)。また、HTML Webページでも特殊であるため、PHPスクリプトでも特別な処理が必要になる場合があります。
**領域塗りつぶしフラグ( '`^`' フラグ)**
IM v6.3.8-3以降、IMには新しいジオメトリオプションフラグ '`^`' があります。これは、最小適合寸法に基づいて画像のサイズを変更するために使用されます。つまり、画像は指定されたピクセル領域を完全に塗りつぶす(そしてオーバーフローさえする)ようにサイズ変更されます。

  magick dragon_sm.gif    -resize 64x64^  fill_dragon.gif
  magick terminal.gif  -resize 64x64^  fill_terminal.gif
[IM Output] ==> [IM Output]  [IM Output] ==> [IM Output]
現状では、このオプションはあまり役に立たないように見えますが、中央揃え(または中央揃えなし)の "-crop" または "-extent" と組み合わせて画像の余分な部分を削除すると、指定された領域を完全に埋めるように画像を合わせることができます。リサイズと最終的な画像サイズの引数は、どちらも同じ値にする必要があります。 "-crop" が最も論理的ですが、仮想キャンバスレイヤー情報を削除するために追加の "+repage" が必要な場合があります。 "-extent" はこのクリーンアップを必要としませんが、配置には "-gravity" を使用できます。詳細については、切り取りと境界線を参照してください。

  magick dragon_sm.gif      -resize 64x64^ \
          -gravity center -extent 64x64  fill_crop_dragon.gif
  magick terminal.gif    -resize 64x64^ \
          -gravity center -extent 64x64  fill_crop_terminal.gif
[IM Output] ==> [IM Output]  [IM Output] ==> [IM Output]
また、 "-extent" を使用すると、通常のサイズ変更( "-background" 色設定を使用)を使用する画像を埋め込むことができます。このタイプの操作の詳細については、サムネイル、指定されたスペースの概要に合わせて合わせるを参照してください。
これを利用するには、IM v6.3.8-3以降が必要であることに注意してください。それ以外の場合は、以下の古い指定されたスペースを埋めるためのリサイズ手法を使用してください。
領域塗りつぶしフラグ( '`^`' フラグ)は、Windowsバッチスクリプトの特殊文字であり、その文字を2倍にすることでエスケープする必要があります。たとえば、「`^^`」のようにしないと機能しません。この問題やその他のウィンドウの問題については、Windowsバッチスクリプトを参照してください。
**パーセンテージリサイズ( '`%`' フラグ)**
"-resize" 引数にパーセント記号「%」を追加すると、指定された量だけ画像のサイズが変更されます。

  magick dragon_sm.gif    -resize 50%  half_dragon.gif
  magick terminal.gif  -resize 50%  half_terminal.gif
[IM Output] ==> [IM Output]  [IM Output] ==> [IM Output]
ただし、画像の最終的なピクセルサイズは最も近い整数に丸められることに注意してください。つまり、画像の端に部分的なピクセルは生成されません!その結果、実際のスケールは指定したスケーリング係数と正確に一致しない場合があり、X方向とY方向でわずかに異なる場合がありますが、非常に近くなります。(Distortを使用したリサイズを参照)。
最終サイズが部分ピクセルサイズの違いがあるように見えるように画像のサイズを変更する場合は、一般歪み演算子、特にスケール-回転-平行移動を使用できます(以下のDistortを使用したリサイズを参照)。
パーセントリサイズフラグ ('%' フラグ) は、Windows バッチスクリプトの特殊文字であり、この文字を二重にすることでエスケープする必要があります。たとえば、'%%' のように記述しないと機能しません。この問題やその他の Windows 特有の事項については、Windows バッチスクリプト を参照してください。
これらの「フラグ」オプション '!'、'<'、'>'、'^'、'%'、および '@' は、"-resize" 演算子の単なるオン/オフスイッチです。重要なのは、リサイズ引数にこれらの文字が存在する(または存在しない)ことであり、位置は関係ありません。引数の先頭または末尾、あるいは個々の数値の前または後(ただし、数値の途中ではない)に配置できます。

つまり、'%50' は '50%' とまったく同じ効果がありますが、後者は可読性のために推奨されます。また、'50%x30' は実際には '50%x30%' を意味し、想像されるような幅 50%、高さ 30 ピクセルを意味するわけではありません。

これは、「geometry」スタイル('WxH' または '+X+Y')の引数を使用するすべての IM 引数に当てはまります。ただし、'+X+Y' のようなオフセットは、パーセンテージとして扱われることはありません。
ピクセル数制限を使用したリサイズ ('@' フラグ)
最後の "-resize" オプションフラグがあります。「アットマーク」'@' は、画像を指定されたピクセル数以下にリサイズします。これは、たとえば、サイズが異なる画像のコレクションをほぼ同じサイズにするために使用できます。たとえば、ここでは両方の画像を約 64x64 サイズ、つまり 4096 ピクセルのサイズにリサイズします。

  magick dragon_sm.gif    -resize 4096@  pixel_dragon.gif
  magick terminal.gif  -resize 4096@  pixel_terminal.gif
[IM Output] ==> [IM Output]  [IM Output] ==> [IM Output]
最終的な画像サイズは、高さまたは幅が 64 ピクセルに制限されるわけではなく、IM が管理できる限りこのサイズに近い(ただし小さい)面積になります。つまり、一般的に一方の寸法は 64 ピクセルよりわずかに大きく、もう一方はわずかに小さくなります。ある意味では、これはサムネイル画像を作成するための理想的な妥協点です。サムネイルサイズの領域調整 を参照してください。また、 '>' フラグを追加して、計算されたピクセル数よりも大きい画像のみを縮小し、既にそのサイズよりも小さい画像はそのままにすることもできます。
残念ながら、'<' フラグ(小さい画像を拡大する)は、現在「領域リサイズ」を使用する場合には無視されます。

画像読み込み中のリサイズ
リサイズ演算子は、画像が読み込まれた直後、現在の画像シーケンスに追加され、次の画像が読み込まれる前に適用することもできます。こうすることで、多くの画像を読み込むために必要なメモリ量を最小限に抑えることができます。詳細については、画像読み込み修飾子 を参照してください。例えば...

  magick dragon_sm.gif'[64x64]'    read_dragon.gif
  magick terminal.gif'[64x64]'  read_terminal.gif
[IM Output] ==> [IM Output]  [IM Output] ==> [IM Output]
この手法の唯一の問題は、画像の読み込み処理中に特別なリサイズオプションを使用できないことです。
リサイズと透明度は、v6.2.4 より前の ImageMagick では問題があり、透明な明るい色のオブジェクトの周りに黒いハロー効果が生じていました。これは調査され、そのバージョン以降で最終的に修正されました。この古いバグの詳細については、リサイズハローバグ を参照してください。

その他のサイズ変更演算子

ジオメトリ - 最後の画像のみのサイズ変更

ジオメトリは非常に特殊なオプションです。この演算子は、すべての IM コマンドで、多くの場合、特殊で不思議な動作をします。この理由は、主に従来の使用法によるものであり、可能な限り避けるべきです。まず、"magick display" では、表示されている画像のウィンドウのサイズと位置を指定するために使用されます。これは、IM が最初に開始されたときの本来の使用法と意味でした。これにより、他の「リサイズ」機能が生まれました。"
montage" の場合、"-geometry" はすべての引数が読み込まれるまで保存される設定です。この時点で、最終的なタイル(セル)サイズを定義します(または "magick montage" が決定するようにします)。一方、位置引数はタイルセルを囲むスペースを指定するために使用されます。モンタージュ制御設定 を参照してください。"composite" では、"-geometry" も引数の最後まで保存されます。次に、オーバーレイ画像(指定された最初の画像)を背景画像(2 番目の画像)にオーバーレイする前に、サイズ変更と位置調整を行うために使用されます。たとえば、複数画像の合成 を参照してください。ご覧のとおり、ほとんどの IM コマンドでは「設定」として使用されますが、"magick" では、"-geometry" は特別な画像リサイズ演算子と位置設定の両方です。これは、現在の画像シーケンスの*最後*の画像のみを "-resize" します。これは、現在の画像シーケンスの 1 つの画像(最後の画像)にのみ影響を与えるように特別に設計された*唯一*の画像処理演算子です。この特殊なオプションをさらに複雑にするために、"-geometry" オプションの位置部分は、"composite" と同様に、"magick" コマンドによって保存されます。つまり、"-composite" によって後で「オーバーレイ」画像(現在の画像シーケンスの最後から 2 番目の画像)を「背景」画像(画像シーケンスの最初の画像)の上に配置するために、位置が保持されます。このため、"magick" コマンドで "-geometry" を使用するのは、"-composite" または "-layers composite" 操作の直前に限定する必要があります。要約すると、この演算子は、2 番目の画像を読み込んだり作成したりした後、何らかの種類の アルファ合成 を実行してそれらの画像を処理する直前にのみ役立ちます。"-geometry" を使用して画像のサイズ変更/位置調整を行う実際的な例については、複数画像の合成 を参照してください。

サムネイル - プロファイルの削除とサイズ変更

"
-thumbnail" 演算子は、非常に大きな画像を小さなサムネイルに縮小するために特別に設計された "-resize" のバリエーションです。まず、"-strip" を使用して、画像からすべてのプロファイルやその他の不要な情報を削除します。次に、"-sample" を使用して、画像を最終的な高さの 5 倍に縮小します。最後に、通常の "-resize" を実行して、画像を最終的なサイズに縮小します。これはすべて、基本的に非常に大きなファイルからのサムネイル生成を高速化するためです。ただし、JPEG 画像のサムネイルの場合、特別なオプション "-define jpeg:size={size}" 設定を使用して、ディスクから読み込まれる画像のサイズを制限できます。詳細については、JPEG 画像の読み込み を参照してください。そのため、この速度の向上は、JPEG のサムネイル生成にはめったに必要ありませんが、プロファイルの削除は依然として非常に重要です。TIFF などの他の画像形式では、プロファイルの削除と速度の向上の両方が依然として非常に重要です。そのため、サムネイル作成のために画像のサイズを変更する推奨される方法です。
IM v6.5.4-7 より前では、"-thumbnail" は ICC カラープロファイルを含む*すべて*のプロファイルを画像から削除していました。このバージョン以降、カラープロファイルは保持されます。カラープロファイルが不要な場合は、"-strip" ですべてのプロファイルを削除します。

リサンプル - 画像の解像度変更

前述の代替リサイズ演算子と同様に、 "
-resample" も通常の "-resize" 演算子のシンプルなラッパーです。しかし、その目的は、指定された解像度または密度で表示されたときに、画像が現実の世界と同じサイズに見えるように、画像内のピクセル数を調整することです。つまり、現実世界の単位での画像サイズは同じままで、ピクセル数に関しては、指定された画像は拡大または縮小されます。これは、特定の解像度または密度のプログラムまたはデバイスから読み込まれた、または書き込まれる画像に使用することを目的としています。これは、ディスプレイ、プリンター、特定の解像度のPostScriptまたはPDF画像形式など、特定のハードウェア出力デバイスに合わせて画像を調整する場合に特に重要です。画像の実際のサイズは変更されず、解像度と画像の表現に使用されるピクセル数のみが変更されることに注意してください。たとえば、300dpi(1インチあたりのドット数)でスキャンした画像があるとします。画像は、この解像度(密度)で保存されるか、IMに読み込むときに、"-density" を使用して300dpiの画像として指定します。ここで、解像度が90dpiの画面に表示することにしたので、"-resample 90" を実行します。IMは画像を90/300、つまり元の画像サイズの30%にリサイズし、画像の新しい密度を90dpiに設定します。画像は、使用されるピクセル数に関しては小さくなりましたが、90dpiのディスプレイに表示すると、スキャンした元の画像と同じ物理サイズで表示されます。つまり、90dpiのディスプレイに適した解像度になったため、元の現実世界のサイズでユーザーに表示されます。この演算子を正しく動作させるには、状況によっては "-units" 設定(引数 'PixelsPerInch' または 'PixelsPerCentimeter')が必要になる場合があります。この設定は、PostscriptおよびPDF画像ファイル形式への出力にも重要になる可能性があります。JPEG、PNG、TIFFなど、少数の画像ファイル形式のみが画像データとともに画像の解像度または密度を保存できることに注意してください。画像解像度をサポートしていない形式、またはマルチ解像度(ベクターベース)の画像形式の場合、画像の元の解像度は、読み込む前に "-density" 属性(密度画像メタデータを参照)を使用して指定する必要があります。密度属性が設定されていない場合、IMはデフォルトの密度を72dpiと見なします。このような画像を読み込んだ後に密度を設定すると、出力解像度にのみ影響し、ピクセル数で表される最終的なサイズには影響しません。

スケール - ピクセル平均による縮小

"
-scale" リサイズ演算子は、resizeコマンドの簡略化された高速な形式です。画像を拡大する場合、画像内のピクセルが複製されて、大きな長方形のカラーブロックが形成されます。これは、画像の鮮明でぼやけていない拡大表示に最適です。たとえば、これは組み込みのタイルパターンの1つの拡大図です...

  magick -size 8x8 pattern:CrossHatch30 -scale 800% scale_crosshatch.gif
[IM Output]
一般的に、100%の倍数である単一のパーセンテージ値が画像の拡大に使用され、すべてのピクセルが同じ量だけ拡大されるようにします。そうでない場合、異なるサイズのピクセル行と列が存在し、大規模なモアレパターンが発生する可能性があります。
たとえば、ここでは、元の画像サイズの倍数ではないサイズを使用して、滑らかに見える「50%グレーチェック」パターンを不適切にスケーリングしました。

  magick pattern:gray50 scale_gray_norm.gif
  magick pattern:gray50 -scale 36 scale_gray_mag.gif
[IM Output]
==>
[IM Output]
画像を縮小する場合、隣接するピクセルが平均化されて新しい色のピクセルが生成されます。たとえば、画像を元のサイズの50%にスケーリングすると、4ピクセルのブロックが効果的に平均化されて新しいピクセルが作成されます(画像サイズも2の倍数であると仮定)。ただし、スケールが縮小された画像では、新しい画像が正確な整数縮小(「ビニング」と呼ばれる手法)でない限り、モアレパターンも生成される可能性があるため、注意が必要です。これには、元の画像サイズが最終サイズの正確な整数倍であることも必要です。"-scale" を使用して大幅に縮小された実際の写真は、鋭いエッジに沿ってエイリアシング(「階段」)効果があり、オーバーレイシャープに見える傾向があります。"-scale" のピクセル平均化により、「ピクセル化」された画像を生成できます。基本的に、画像のサイズを縮小してピクセルを平均化し、元の画像サイズに戻します。

  magick rose: -scale 25%  -scale 70x46\!  rose_pixelated.gif
[IM Output] ==> [IM Output]
マスクを使用して、上記のピクセル化された画像を元の画像と組み合わせることで、元の画像に存在するはるかに小さい「いたずら」ビットを「非表示」にすることができます。この手法の使用例については、誰かの匿名性を保護するの例を参照してください。また、アルゴリズムはピクセルの行と列をループするように設計されており、これは "-resize" のアルゴリズムとは逆になっています。これにより、"-scale" は "mpc:" ディスクキャッシュされた画像をより適切に処理できるようになります。
IM v6.4.7までは、"-scale" には古いリサイズハローバグが含まれていました。

スケールの内部(ピクセルミキシング)...

多くの点で、
スケール演算子は通常のリサイズ演算子に似ていますが、「ボックスリサンプリングフィルターを使用しています。ただし、実際にはボックスフィルターで生成される結果よりもわずかに正確な、まったく異なるアルゴリズムを使用しています。ボックスフィルターの動作方法は、フィルターの「サポートウィンドウ」(フィルターサポートエキスパートコントロールを参照)内にあるピクセル(サンプル)を単純に平均化することです。これは、画像を非常に少量だけ縮小する場合、ボックスフィルター処理されたリサイズは、正確なピクセル値、または完全に平均化されたピクセル値のみを生成することを意味します。ただし、スケール演算子は、(より適切な名前がないため)ピクセルミキシングと呼ばれる別のアルゴリズムを使用します。「サポートウィンドウ」内の「ピクセルの平均」に基づいて色を生成するのではなく、サポートウィンドウ内のより正確な「ピクセルの領域」を使用します。たとえば、ここでは「チェッカーボード」ピクセルパターンを取得し、2ピクセル縮小して、スケールの結果と、非常に単純なボックスと三角形フィルターを使用したリサイズの結果を比較します。

  magick -size 10x10 pattern:gray50  checks.gif
  magick checks.gif  -filter box      -resize 8x8  checks_box.gif
  magick checks.gif                   -scale  8x8  checks_scale.gif
  magick checks.gif  -filter triangle -resize 8x8  checks_triangle.gif
[IM Output]
10ピクセルの「ハッシュ」
==> [IM Output]
ボックスフィルター済み
リサイズ
[IM Output]
ピクセルミキシング
スケール
[IM Output]
三角形フィルター
リサイズ
上記の画像は大幅に拡大されています
上記は、「純粋に平均化」された結果と、「ピクセル混合」された結果、および「線形補間」された結果を示しています。また、スケール演算子が実際には三角形フィルターに似ていることも示していますが、画像の非常に小さな縮小を行う場合のみです。他の場合(強い縮小、拡大、または正確な整数サイズ変更)では、ボックスフィルターの結果と同様の結果が生成されます。基本的には、画像の縮小サイズに応じて、ボックスフィルターと三角形フィルターの混合のようなものが生成されます。拡大するときにも同様の効果が見られます。

  magick -size 8x8 pattern:gray50  checks_sm.gif
  magick checks_sm.gif -filter box      -resize 10x10 checks_sm_box.gif
  magick checks_sm.gif                  -scale  10x10 checks_sm_scale.gif
  magick checks_sm.gif -filter triangle -resize 10x10 checks_sm_triangle.gif
[IM Output]
10ピクセルの「ハッシュ」
==> [IM Output]
ボックスフィルター済み
リサイズ
[IM Output]
ピクセルミキシング
スケール
[IM Output]
三角形フィルター
リサイズ
上記の画像は大幅に拡大されています
ボックスフィルターを拡大する場合、「平均化されたピクセル」は生成されず、ピクセル行/列の複製のみが生成されます。ただし、スケールは、三角形フィルターと非常によく似ていますが、まったく同じではない、エッジに沿って平均化されたカラーピクセルを生成します。もちろん、この効果は、小さく、整数ではない拡大に対してのみ実際に表示され、より大きなスケーリングでは、より一般的なケースでは1つまたは2つの平均化されたピクセルが得られる可能性のあるエッジに沿ってのみ表示されます。要約すると、スケールは、画像処理の要件がそれほど一般的ではないため、通常のリサイズ演算子よりもはるかに高速です。しかし、それはまったく異なるアルゴリズムでもあり、非整数スケールを使用して画像のサイズを変更するために使用すると、わずかに異なる結果が生成されます。詳細については、ピクセルミキシングページと、IMフォーラムディスカッションの線形に数ピクセルをアップスケーリングするを参照してください。上記の相違点を指摘してくれたフォーラムユーザーatnbuenoに特に感謝します。

サンプル - 行/列の複製/削除によるリサイズ

"
-sample" リサイズ演算子は、特に大規模な画像縮小において最速のリサイズ演算子です。実際、"-scale" 演算子よりもさらに高速です(上記を参照)。画像を拡大または拡大する場合、ピクセル複製のみを実行します(ボックスフィルターの場合と同様)。長方形の「ブロック」のピクセル色が生成されます。ただし、画像を縮小する場合、"-sample" は単にピクセルの行と列を削除します。ピクセルの行と列全体が単に追加または削除されるため、"-sample" は新しい色や追加の色を生成しません。この事実は、GIFアニメーションのリサイズなど、一部の画像処理手法にとって重要になる可能性があります。別の見方をすれば、画像は、画像全体に非常に均一な規則的なパターンでサンプリングされた単一の個々のピクセルを持っているということです。画像は領域の配列に分割されていると考えることができ、各領域から1つのピクセルが結果の画像用に選択されます。ただし、個々のピクセルを「サンプリング」する(または行/列をまとめて削除する)と、特にピクセルの幅が細い線を含む画像では、非常にひどい結果になる可能性があります。たとえば、ここでは線を描画しますが、画像サイズを縮小すると、点の線のみになります。

  magick -size 150x60 xc: -draw 'line 0,59 149,0' line_orig.gif
  magick line_orig.gif  -sample 50x20  line_sample.gif
[IM Output] ==> [IM Output]
これは画像サンプリングでよく見られる効果で、深刻なエイリアシング効果として知られています。

サンプリングされたピクセルのオフセット

IM v6.8.4-7以降、各サンプリングサブ領域でサンプリングされる正確なピクセルは、各領域の中点にあるピクセル(またはサブ領域のピクセル数が偶数の場合、左上の中央ピクセル)と定義されるようになりました。つまり、画像の単一ピクセルサンプルを作成すると、画像の中央ピクセルが取得されます。
IM v6.8.4-7より前は、選択されたピクセルは各領域の左上のピクセルでした。ただし、一部のバージョンでは右下だったという報告や、バグによりわずかに変動していた可能性もあるという報告があります。
この種の情報は、元の画像サイズの整数除算によって縮小される画像に特に役立ちます。ピクセル化された画像を作成またはサンプリングする場合や、
ビデオフレームをデインターレースする場合などです。また、このバージョン以降、define "sample:offset" を使用して、各サブ領域でどのピクセルを選択するかを正確に制御できます。これは、1つまたは2つのパーセンテージ値を取ります(デフォルトでは中点の場合は '50')。パーセンテージが使用されるのは、一般的なケースでは「サンプリングサブ領域」がピクセル境界に揃っていない可能性があるためです。つまり、「ピクセルオフセット」ではなくパーセンテージが必要な理由です。ただし、画像サイズがサンプル数で割り切れる場合は、各サブ領域からどのピクセルを取得するかを簡単に計算できます。たとえば、画像がサンプリングされて5ピクセルのサブ領域がある場合(たとえば、横100ピクセルの画像を20ピクセルのサンプルにサンプリングする場合)、サンプリングオフセットのパーセンテージを0〜19.9の範囲で使用して各領域の最初のピクセルを選択し、20.1〜39.9の範囲で2番目のピクセルを選択できます。つまり、10、30、50、70、90のパーセンテージ値を使用して、一定サイズのサンプリング領域からどのピクセルを取得するかを正確に指定できます。サンプリングオフセットの詳細については、IMフォーラムのディスカッションサンプルポイントを参照してください。

拡大- ピクセルスケーリング

"
-magnify" オプションは画像のサイズを2倍にしますが、Scale2Xアルゴリズムを使用して「ピクセルスケーリング」と呼ばれる手法を使用します。このアルゴリズムは、余分な色を追加することなく、拡大されるピクセルの角を滑らかにしようとします。そのため、非常に小さなピクセル化された画像は、元の色の「レトロなピクセルルック」を維持しながら、よりきれいに拡大されます。

  magick -size 8x8 pattern:CrossHatch30 -virtual-pixel tile \
          -magnify -magnify -magnify magnify_crosshatch.gif
[IM Output] ==> [IM Output]
仮想ピクセル設定を使用して、拡大がこの特定の画像が画像のエッジを「ラップアラウンド」することを理解していることを確認しました。
IM v6.8.4-10より前では、拡大は画像サイズを2倍にするためのresizeのラッパーに過ぎませんでした。あまり役に立たず、めったに使用されませんでした。「ピクセルスケーリング」を使用すると、このオプションがはるかに便利になります。詳細については、IMユーザーフォーラムのピクセルスケーリングを参照してください。
「Minify()」関数は、画像サイズを半分にするAPIでよく使用されますが、resizeのラッパーに過ぎません。ただし、"-minify" は、少なくともこの記事の執筆時点では、コマンドラインAPIからは使用できません。

アダプティブリサイズ- ぼかしのない小さなリサイズ

"
-adaptive-resize" 演算子は、特別なメッシュ補間メソッドを使用して画像のサイズを変更します。たとえば、ここでは単純な線のサイズを変更します。最初に通常の "-resize" を使用し、次に "-adaptive-resize" を使用します。

  magick -size 50x50 xc: -draw 'line 0,49 49,0'  line_orig2.gif
  magick line_orig2.gif           -resize 80x80  line_resize.gif
  magick line_orig2.gif  -adaptive-resize 80x80  line_adaptive.gif
[IM Output] ==> [IM Output] [IM Output]
2つの結果を拡大して見ると...
[IM Output] [IM Output]
右側のアダプティブリサイズされた画像は、通常の "-resize" 演算子を使用して生成された左側の画像よりもはるかにきれいで、ぼやけていないことがわかります。基本的に、この演算子は "-resize" 演算子で発生する可能性のある、急激な色の変化による過度のぼやけを回避します。これは、わずかな画像サイズの調整、特に拡大、そして特に色の変化が激しい画像に適しています。ただし、すべてのピクセル補間方法と同様に、画像が50%以上拡大または縮小されると、エイリアシングやモアレが発生します。"-filter point -interpolate mesh" オプションを指定したDistort Resize操作を使用しても、まったく同じ結果を生成できます。つまり、より複雑なリサンプリングフィルターではなく、単純なメッシュ補間ルックアップメソッドを使用して画像のサイズを変更します。

補間リサイズ- 補間メソッドを使用したリサイズ

"
-interpolative-resize" 演算子は、前のアダプティブリサイズ演算子と実質的に同じです。ただし、この演算子は、固定の「メッシュ」補間メソッドではなく、現在の "-interpolate" 設定を使用します。

"-interpolate" 設定に 'Nearest' を使用すると、本質的にサンプル演算子と同等のものが得られます。同様に、他の多くの単純な補間メソッドは、同等の補間リサイズフィルターを使用することと同じになります。ただし、メッシュなど、リサイズフィルターとして同等のものがない補間メソッドがいくつかあります。

これはスケールされていないリサイズでもあるため、拡大や小規模な縮小には最適ですが、50%以上縮小すると、上記の他の「サンプリングリサイズ演算子」に示されているように、深刻なエイリアシング効果が現れる可能性があります。

リキッドリサイズ- シームカービング

サンプリングで画像の列と行全体を直接削除または複製することで画像のサイズを変更するのと同じように、特別なIM演算子 "-liquid-rescale" も画像からピクセルの列と行を削除または複製して、画像を縮小/拡大します。違いは、よりインテリジェントな方法でそれを行おうとすることです。まず、単純なピクセル行を削除する代わりに、ピクセルの「シーム」を削除します。つまり、最大45度の角度で画像をジグザグに通過できる列(または行)です。次に、画像の内容に関して「重要度が最も低い」シームを削除しようとします。これをどのように選択するかは、画像のエネルギー、より簡単に言えば、特定の「シーム」に含まれる色の変化の量によって決まります。変更量が最も少ない「シーム」が最初に削除され、次にエネルギーの高いシームが削除され、画像が目的のサイズになるまで続きます。リキッドリサイズとシームカービングの詳細については、Wikipedia:シームカービングYouTubeビデオデモ、およびPDF論文:コンテンツに応じた画像リサイズのためのシームカービングを参照してください。たとえば、IMロゴをIM "-liquid-rescale" 演算子を使用して小さくリサイズした例を次に示します。

  magick logo: -resize 50% -trim +repage  logo_trimmed.jpg
  magick logo_trimmed.jpg  -liquid-rescale 75x100%\!  logo_lqr.jpg
  magick logo_trimmed.jpg  -sample 75x100%\!  logo_sample.jpg
[IM Output]
オリジナル
==> [IM Output]
リキッドリサイズ
[IM Output]
サンプリング
"-liquid-rescale" が複雑なウィザードを保持し、画像の星とタイトル部分はそれほど複雑ではないため圧縮していることに注目してください。また、ウィザードの右足をわずかに圧迫し、マントの端に少しギザギザを生成しました。これは、ウィザードの細くてシンプルな杖にも同じように行われました。一方、サンプルリサイズ画像は、等間隔のピクセル列を単純に削除したため、画像全体が均等に歪んでしまいました。星はそのまま保持されておらず、すべてのエッジには明確ですが均一なエイリアシング効果があります。基本的に、"-liquid-rescale" は、余分な「混色」や画像のぼやけを生成することなく、一般的に見栄えの良い「圧縮された」画像を生成します。ただし、画像全体に効果を広げるのではなく、1か所(この場合はウィザードの杖)にわずかながら局所的なエイリアシング効果が発生する可能性があります。また、画像内で検出されたシームを「2倍」にすることで、画像を拡大します。

  magick logo_trimmed.jpg  -liquid-rescale 130x100%\!  logo_lqr_expand.jpg
[IM Output] ==> [IM Output]
ご覧のとおり、最初にさまざまなオブジェクト間のスペースを(可能な限り)2倍にして、それらを広げようとします。ただし、この場合、最も左側の星と「m」は、これらの「低エネルギー」領域を通過する「シーム」がグループ化されるため、歪んでしまいます。ただし、各シームは1回だけ2倍になるため、画像が大きくなりすぎると、この手法はうまく機能しなくなります。より良い方法は、多くの場合、最初に画像を大きくリサイズしてから、リキッドリスケーリングを使用して目的のサイズに縮小することです。または、"-liquid-rescale" を複数の小さなステップで使用することです。"-liquid-rescale" の効果をよりよく示すために、同じ画像が非常に薄い画像にリサイズされ、再び拡大されるアニメーションを次に示します。このアニメーションは、シェルスクリプトanimate_lqrを使用して作成されました。
[IM Output]
画像がより小さな領域に圧縮されるにつれて、画像の最も複雑な部分がどのように保持されるか、もう一度注意してください。つまり、タイトルのスペースが最初に優先的に圧縮され、次にウィザードの腕、次にウィザードの右側が圧縮され、最後にウィザードの最も複雑な中央部分が圧縮されます。特に、リキッドリスケーリングで実装されているリサンプリングピクセル除去の影響を受ける前に、星がどのように押しつぶされるかを見てください。(次の問題を参照)リキッドリスケーリングは、スポンジのように画像を圧縮しようとするものと考えてください。開放領域が最初に圧縮され、かさばって構造化された部分は最後に残されます。シームカービングの問題リキッドリサイズ、またはシームカービングは、画像からピクセル全体を削除することによってのみ機能します。そのため、サンプリングと同様に、色は生成またはマージされず、画像内の直線やパターンは操作によって大きく歪む可能性があります。基本的に、何らかのスムージング方法も適用されない限り、深刻なエイリアシング効果が発生する可能性があります。ただし、一般的に、エイリアシング効果は、画像全体に広がるのではなく、画像の複雑度の低い領域にグループ化され、局所化されます。これがうまく機能する唯一の理由です!「シーム」は画像内をジグザグに進むことができるため、シームは複雑なオブジェクトの周囲を回り、オブジェクト自体を圧縮しようとする前にオブジェクト間のスペースを削除することがよくあります。たとえば、上記のデモでは、「Image」という言葉がタイトルの他の文字の下にあまり歪みなく押し込まれていることに注意してください。ただし、この左右の動きは45度の角度に制限されています。人の顔を含む写真など、「賑やかな」背景と「賑やかでない」前景オブジェクトを持つ画像の場合、エネルギー関数は、前景オブジェクトが背景よりも重要ではないと想定する可能性があります。これは、解決に人間の介入が必要になる可能性のある深刻な悪影響をもたらします。
リキッドリスケーリングは、現在、IM v6.3.8-4に追加された非常に実験的な操作です。動作するには、事前に「liblqr」デリゲートライブラリをインストールする必要があります。

現時点では、エキスパートユーザーコントロールは提供されていません。使用されるコンテンツエネルギー関数を変更したり、ユーザーが提供する保存/削除フィルターを使用したり(そのエネルギー関数を調整したり)、中間シームカービング画像やライブラリが提供する関数にアクセスしたりするためのコントロールなどです。ユーザーの要求に応じて、またライブラリ関数の内部制御が強化されるにつれて、将来的にはそのようなコントロールが提供される予定です。

警告 これが現在実装されているとおりに正確に維持されるとは期待しないでください。これは非常に実験的なものであり、機能が変更および拡張される予定です。

歪みリサイズ - フリーフォームリサイズ

上記のすべてのサイズ変更方法には、前述した1つの制限があります。新しい画像のサイズをピクセルの整数に丸め、古い画像のピクセルを新しいピクセル配列にマッピングします。これには2つの効果があります。まず、非常に小さいサイズにサイズ変更すると、結果の画像のXスケールとYスケールが正確に一致しない場合があります(アスペクト比がわずかに異なります)。この違いはわずかであり、非常に小さくない限り、通常は目立ちません。もう1つの効果は、部分ピクセルエッジを含む領域に合わせて画像のサイズを変更できないことです。これは、画像オーバーレイなどのさらなる処理において重要になる可能性があります。また、アルゴリズムでは簡単に実行できる場合でも、サイズ変更を使用して画像を右に半ピクセルだけシフト(移動)することはできません(実際のサイズ変更なし)。IM v6.3.6では、
一般歪み演算子-distort」を使用すると、スケール-回転-移動歪み方法を使用して、これ以上のことができます。また、コントロールポイントの動きに基づいてアフィン歪みを使用することもできます。ただし、画像のエッジには部分ピクセルが含まれる可能性があるため、最終的な画像は予想よりもおそらく2〜3ピクセル大きくなることに注意してください。余分な周囲のピクセルは、現在の仮想ピクセル設定に従って混合されます。これは通常、透明に設定します。たとえば、ここでは、バラの画像を元のサイズの90%(.9)にサイズ変更し、回転させずに(0)、画像の中心(指定されていない場合のデフォルトのコントロールポイント)を中心に縮小します...

  magick rose: -alpha set -virtual-pixel transparent \
          +distort SRT '.9,0' +repage  rose_distort_scale.png
[IM Output]
改善のように見えないかもしれません。実際、エッジがぼやけていますが、最終的な整数画像サイズを調整せずに正確なサイズ変更です。このため、ピクセルカラーがピクセルサイズの一部に広がり、整数全体に広がらないため、エッジがぼやけています。ここでは、「+distort」の「プラス」形式を使用して、この画像の処理演算子に仮想キャンバスの最終的な画像サイズとオフセットを正しく設定させ、さらなる処理とレイヤー化を可能にしています。このオフセットが不要な場合は、「+repage」演算子を使用して削除できます。ただし、そのままにしておくと、より大きなキャンバス上の実際の画像の位置が保持され、「ぼやけたエッジ」で画像を正確に配置できます。ここでは、左上隅(0,0)が右に.5ピクセル(.5,0)移動し、画像の残りの部分がそのコントロールポイントを中心にスケーリングされるようにサイズ変更しました...

  magick rose: -alpha set -virtual-pixel transparent \
          +distort SRT '0,0  .9  0  .5,0' +repage  rose_distort_shift.png
[IM Output]
上端は実際には動かなかったため、比較的シャープなままでしたが、他のすべてのエッジはぼやけていることに注意してください。これは、サブピクセルリサイズを提供するために歪みによって追加された透明性を示す、上隅のピクセル倍率です...

  magick rose_distort_shift.png -crop 15x15+0+0 +repage \
          -scale 600%   rose_distort_shift_mag.png
[IM Output]
上端はシャープなままでしたが、左端(および他のすべてのエッジ)が半透明になっていることがわかります。そしてそれがポイントです。サイズ変更と、結果の画像の最終的なサブピクセルの位置を正確に制御できます。サイズ変更された画像をピクセルの整数に量子化して合わせるだけではありません。つまり、歪みは画像の正確な再スケーリングと配置であり、ピクセルの一部に配置して、他の画像に正確に合わせることができます。これは、埋め込み画像の不正確なサイズ変更によって「ぎこちない」効果が生じる可能性のあるビデオ 작업を行う場合に特に重要になります。
技術的には、画像のサイズ変更は画像の歪みの簡略化された形式であり、どちらも画像リサンプリングの手法です。非常に高速な2パスフィルタリング手法は、直交して配置されたピクセルスケーリングと、最終結果のピクセル数が整数に制限されています。
アフィン、変換IM v6.4.2-8以降、古い「-affine」設定は、「-transform」または「-draw」演算子とともに使用され、同様のフリーフォームサイズ変更機能を提供します。ただし、実際には、「+distort」を「AffineProjection」歪み方法で呼び出すことと同じです。そのため、以前のすべての歪みに関する注意事項が適用されます。より多くの数学が必要となるため、一般的なユーザーが使用するのは困難です。一般に、適用するアフィン歪みを指定するためのさまざまな代替方法を提供する上記の歪み方法を使用する方が良いでしょう。

歪みとリサイズの比較

歪みリサイズの直接比較を実際に行う場合は、比較対象のリサイズ画像と正確に一致するように、画像の歪みを具体的に制限する必要があります。これは簡単な作業ではありません。これを容易にするために、IM v6.6.9-2に特別なリサイズ歪み方法が追加されました。たとえば、ここでは、高速なリサイズを使用して、組み込みの「rose:」を大幅に拡大し、次に歪みを使用します...

  magick rose: -filter Lanczos -resize 300x rose_resize.png

  magick rose: -filter Lanczos -distort Resize 300x rose_distort.png
[IM Text]
リサイズ(Lanczos - Sinc)
[IM Text]
歪み(Lanczos - Jinc)
バラの下端を見ると、歪み演算子は実際にはリサイズ演算子よりもきれいで良い結果を生み出していることがわかります。画像を拡大する際に一般的なブロッキングアーティファクトはほとんどありません。この下端以外、残りの画像は、「flicker_cmp」スクリプトを使用して比較した場合でも、事実上同じです。ただし、歪みは、リサイズが使用する2パス速度最適化を行わない、より直接的ではるかに複雑な領域リサンプリング手法を使用するため、リサイズよりもはるかに遅いことに注意してください。
上記の2つの画像の実際の違いは、歪み演算子が画像処理に2次元の楕円領域リサンプリングフィルター方法(円筒フィルタリングまたはリサンプリングとも呼ばれます)を使用することです。これは、このセクションに示されている他のすべてのサイズ変更方法で使用されている1次元、2パスリサンプリング方法よりも低速です。また、上記の拡大されたバラの画像の対角線の下端でより良い結果が得られた理由でもあります。水平および垂直フィルタリングのみに限定されません。

リンギングアーティファクトの例で、これがリンギングに与える影響を確認できます。



サイズ変更手法

色空間補正を使用したリサイズ

リサイズは非常にうまく機能しますが、ほとんどの人は正しく使用していません。私でさえ、通常は画像をそのまま直接リサイズするため、技術的には画像を間違ってリサイズしています。画像は通常、非線形の「sRGB」色空間、またはガンマ補正を使用して保存されます。詳細は人間の色の知覚を参照してください。しかし、リサイズ(他のほとんどの画像処理演算子と同様)は数学的に線形のプロセッサであり、画像値が線形の色の明るさを直接表していると想定しています。色空間「sRGB」は、基本的に約2.2のガンマ補正を含んでいます。実際には、2つの別々の曲線を含むため、それよりも複雑です。wikipedia、sRGBおよびW3org、インターネットのデフォルトの色空間であるsRGBを参照してください。バージョン6.7.5以降、ImageMagickはこの規則に従い、画像のデフォルトの色空間(少なくともほとんどの画像ファイル形式の場合)をsRGBとして定義しています。つまり、リサイズを行う前に、 "-colorspace"を使用して画像を線形空間に変換する必要があります。
低品質のQ8バージョンのIM(品質を参照)で色補正を使用することは、そのような低メモリ品質が提供する精度の損失があるためお勧めできません。
NASAの画像 "地球の都市の光" は、非線形の色空間効果が画像のリサイズ結果に大きな影響を与える非常に極端なケースです。ここでは、色空間補正なしで画像を直接リサイズします...

  magick earth_lights_4800.tif -resize 500 earth_lights_direct.png
[IM Text]
ここでは、非線形sRGBから線形RGBに変換し、リサイズしてから、再び元に戻します...

  magick earth_lights_4800.tif -colorspace RGB     -resize 500    \
          -colorspace sRGB  earth_lights_colorspace.png
[IM Text]
ご覧のとおり、画像の「光」は、ソース画像の非線形の色空間の影響をそれほど強く受けていないため、はるかに明るくなっています。ほとんどの画像では上記ほど大きな影響はありませんが、存在し、多くの影響を与える可能性があります。sRBGの非線形効果から見られる主な効果は、暗い色がはるかに暗い値として保存されることです(知覚的により関連性が高くなるように)。しかし、それらはより暗いため、数学的に正しく処理されず、結果として得られるsRGB画像は、RGB(またはLABまたはLUV)のような線形の色空間で処理された画像よりも暗くなります。実際の画像の色処理およびガンマと色空間補正を使用した描画も参照してください。同じ正しい色空間処理は、歪み(楕円フィルター)、画像のぼかしの使用にも適用され、画像の量子化、ディザリング、および順序付きディザリングに大きな影響を与える可能性があります。これは、リサンプリングフィルターで詳しく説明されています。警告:RGB色空間は、強い原色の変化(黒と白の間だけでなく)を含むエッジに沿ってクリッピングの問題を引き起こす可能性があります。次のセクションを参照してください。
デフォルトの入力色空間が「RGB」であったv6.7.5より前のバージョンのIMでは、「sRGB」色空間は実際には「sRGBから線形RGBに変換された」ことを意味していました。その結果、2つのラベルが入れ替わりました! _奇妙ですが本当です_。このため、古いバージョンのImageMagickでは、これらの色空間名を交換して上記の色空間補正を行う必要がありました。このように...

  magick earth_lights_4800.tif -colorspace sRGB \
          -resize 500  -colorspace RGB  earth_lights_colorspace.png
*** この例は非推奨です ***
-colorspace RGB」操作は実際には必要ありませんでした。PNG画像ファイル形式で保存すると自動的に実行されたためです。上記は、IMフォーラムのディスカッション正しいリサイズから開発されました。

ガンマ補正によるリサイズ

ガンマ補正のみを使用して画像を正しくリサイズする方法は次のとおりです。

  magick earth_lights_4800.tif   -gamma 0.454545 \
          -resize 500    -gamma 2.2  earth_lights_gamma.png
[IM Text]
ガンマ逆演算「-gamma 0.454545」の代わりに、「-evaluate POW 2.2」を使用できます。ガンマ補正は、画像をsRGB色空間との間で適切に変換するための概算にすぎませんが、色空間とガンマ補正の間に違いを見つけるのが難しいほど近いです。ガンマ補正は、IMv7 RGB / sRGB色空間設定をいじらないため、正確なバージョンが不明な場合に適している可能性があります。また、「-auto-gamma」演算子も参照してください。これは、画像を調整して、明るい領域と暗い領域を均等に生成しようとします(画像は線形の色空間にあると想定)。

LAB色空間でのリサイズ

リサイズまたはあらゆる種類の画像処理にsRGB、RGB、またはXYZ色空間を使用する際の1つの問題は、3つのカラーチャネルが色だけでなく強度または明るさも表すことです。つまり、1つのチャネルが歪むと(クリップされるなど)、ピクセルの色も歪み、奇妙に見える可能性があります。LAB色空間は線形の色空間であるだけでなく、強度(Lチャネル)が2つのカラーチャネル(A * およびB *チャネル)から分離されるように設計されています。つまり、いずれかのチャネルがクリップされても、色の歪みは発生しません。また、一般的に、純粋な白黒画像を具体的に扱わない限り、どのチャネルも実際にはクリップ制限に近いということはありません。これは、実際の画像では一般的ではありません。そのため、LAB色空間を使用して画像を処理することにより、実際に動作が向上し、RGBまたはXYZ色空間を使用する場合に発生する可能性のあるクリッピングと色の歪みが回避されます。
IM v6.7.8-2より前では、A *およびB *チャネルのLAB値は、符号付き整数を使用して格納され、符号なし整数メモリ空間に格納されていました。これにより、負の値と正の値の間に不連続性が生じ、通常の処理は機能せず、画像形式の変換のみが機能しました。

これは、古いバージョンのIMでは、LAB色空間での画像処理が機能しないことを意味していました。特に、正と負の両方の値を含む色が関係する場合です。それは、青-黄と赤-緑の間で変化する色を扱うときです。

このリリースの後、値は内部的に50%のバイアスを使用して格納され、その不連続性が解消されたため、線形演算が期待どおりに機能するようになりました。

「シャープニング」リサンプリングフィルター(非常に一般的に使用される)を含むリサイズの場合、Lab色空間を使用すると、極端な強度の変化が緩和され、原色のRGBカラーで過度に強い(および範囲がクリップされた)リンギングアーティファクトが発生する可能性があります。例えば...

  magick rose: -colorspace RGB  -filter Lanczos  -distort resize 300x \
          -colorspace sRGB rose_distort_rgb.png
  magick rose: -colorspace LAB  -filter Lanczos  -distort resize 300x \
          -colorspace sRGB rose_distort_lab.png
[IM Output]
オリジナル
==> [IM Output]
RGB色空間
[IM Output]
LAB色空間
ご覧のとおり、バラの端は線形RGB色空間でクリップされましたが、LAB色空間ではクリップされませんでした。RGB色空間では、バラの下端は、ほぼ純粋な白からほぼ純粋な赤への色の変化を確認し、「緑」チャネルと「青」チャネルに強い(負の)変化を引き起こします。これにより、非常に強い「負のローブ」リンギング効果が発生し、RGB色空間でクリップされます。最終的な結果は、フィルターのシャープニング効果による深刻な色の歪みです。LAB色空間では、白から赤へのシフトは、強度またはカラーチャネルのいずれにおいてもそれほど強くはなく、強度で良好なシャープニングが得られますが、強度もカラーチャネルもクリップされないため、色の歪みが回避されます。結果は、フィルターからのより適切なシャープニング効果を備えた、はるかに優れたリサイズ画像です。単に強度を色から分離するだけです。

LUV色空間を使用したリサイズ

IM v6.7.8-8以降、IMは密接に関連する色空間LUVも実装しています。どちらも知覚的に均一(線形)になるように設計されており、重要な強度「L」または「明度」チャネルの結果も同じですが、カラーチャネルの計算方法が異なります。主な違いは、LUVカラー軸が知覚的に等しいカラーデルタ(色の違い)を持つように調整されたことです。これにより、LAB色空間とはわずかに異なるカラースケールになりますが、強度は2つの間で同じままです。アダムス色価色空間を参照してください。LABとLUVのリサイズの結果は、事実上同じです。

  magick rose: -colorspace LUV  -filter Lanczos  -distort resize 300x \
          -colorspace sRGB  rose_distort_luv.png
[IM Output]
これら2つの色空間の詳細については、色空間を参照してください。

異なる色空間を使用したリサイズの概要
または、リサイズにLABまたはLUVを使用しないのはなぜですか?

sRGBと同様に、LABとLUVの色空間は非線形の知覚色空間であるためです!そして、数学は線形値にのみ適用されることを意図していました。たとえば、「地球の都市の光」画像を「Lab」色空間でリサイズした結果を次に示します。

  magick earth_lights_4800.tif -colorspace Lab     -resize 500    \
          -colorspace sRGB  earth_lights_lab.png
[IM Text]
結果は、知覚的sRGB色空間で直接リサイズした場合と事実上同じです。しかし、知覚色空間でのリサイズは本当に悪いことでしょうか?本当にそれは議論の余地のある点です。色の歪み(異なるカラーチャネルへの不均一な変化)はそれほど重要ではないようですが、カラーチャネルのクリッピングを回避しているようです。しかし、LABとLUVの画像は知覚的に線形です!そのため、線形知覚色空間で色をブレンドする(リサンプリングフィルターが実際に行うこと)ことは、実際には良いことかもしれません。最後に、sRGBは、原色の成分に沿って強度においてのみ知覚的に線形です。実際には色では知覚的に線形ではないため、あらゆる形式の画像リサイズを行うには不適切な色空間のままです。Nicolas Robidouxはそれをうまくまとめています...
一般に、線形光色空間(線形RGBおよびXYZ)は誇張された暗いハローを生成し、「知覚的」色空間(sRGB、LAB、LUV)は誇張された明るいハローを生成します。

少し考えてみれば、これは完全に理にかなっています。知覚色空間は、強度スペクトルの暗い端に多くのビットを詰め込み、HVS(人間の視覚システム)を模倣するために明るい端を「くり抜く」ためです。そのため、1単位の暗いオーバーシュートは、線形RGBよりもsRGBでは「遠く」まで到達しませんが、1単位の明るいオーバーシュートは、sRGBよりも線形RGBでは「遠く」まで到達しません。

シグモイド化(次を参照)は、暗いオーバーシュートと明るいオーバーシュートを均等に扱い、一般に両方の極端を弱めます。


シグモイド色空間を使用したリサイズ

ImageMagickディスカッションフォーラムでの lengthy な議論では、リサンプリングフィルターハローイングのシグモイド最小化。線形の色空間で画像をリサイズしようとするのではなく、シグモイドカラーモディファイア演算子-sigmoidal-contrast)を使用して、変更された色空間で画像をリサイズするという新しい手法が開発されました。これにより、非常に鋭いエッジに沿って発生する可能性のある極端なハローまたはリンギングアーティファクトのクリッピングを減らすことができます。たとえば、デジタル画像処理フォーラムで議論されてきた「改善された」リサイズ手法のシーケンスを次に示します...

  magick rose: -colorspace RGB  -filter Lanczos  -resize 200x \
          -colorspace sRGB rose_resize_RGB.png
  magick rose: -colorspace RGB  -filter Lanczos  -distort resize 200x \
          -colorspace sRGB rose_distort_RGB.png
  magick rose: -colorspace RGB   +sigmoidal-contrast 6.5,50% \
          -filter Lanczos  -distort resize 200x \
          -sigmoidal-contrast 6.5,50% -colorspace sRGB  rose_sigmoidal_RGB.png
[IM Output]
リサイズ(通常の線形)
[IM Output]
歪み(円筒形)
[IM Output]
シグモイドバリエーション
上記の最後の例で行っていることは、本質的に、画像のコントラストを下げ、中間トーンのグレーをより狭い線形範囲に圧縮し、極値をクリッピングエッジからさらに遠ざけてから、サイズ変更を行うことです。その後、その変更を削除します。これは、色の歪みを減らすために、フィルターが中間トーンを線形に処理できるようにしながら、色の極端な影響を弱めます。多くの点で、これはデフォルトの非線形sRGB色空間で画像のサイズを変更することと似ていますが(これはあまりにも一般的な方法です)、明るいリンギングアーティファクトと暗いリンギングアーティファクトの両方で同様に機能します。つまり、色の値の全範囲にわたって対称的ですが、sRGB色空間でのサイズ変更は、色の範囲の暗い下端(上記の青と緑の値)からのみ機能します。つまり、はるかに制御された手法です。また、このシグモイド変動は拡大にのみ有効である可能性があるというコメントもあります。また、画像ごとにシグモイドコントラスト強度(上記では6.5)の異なる値を試してください。すべてのサイズ変更技術と同様に、結果は非常に主観的であり、すべての画像タイプに適しているとは限らないことに注意してください。
シグモイド変換は、本質的に、非線形知覚色空間(sRGB)を使用した場合に得られた以前の結果に基づいて構築された、特別なDIY非線形色空間を生成します。

RGB色空間で非線形カラーチャネルを持つ画像のサイズを変更(歪める)すると、各カラーチャネルでわずかに異なる結果になる可能性があることに注意してください。これは、わずかな色のずれにつながります(前に見たように色がクリッピングされるのとは対照的です)。

これは、sRGBやシグモイド色空間など、混合された色強度チャネルを持つ非線形色空間でのみ問題になります。


アンシャープマスキング(USM)-- Photoshopのサイズ変更技術

多くの場合、画像のサイズ変更(縮小または拡大)を行うと、画像にぼやけ(ぼかしアーティファクト)が追加されます。このため、多くの人はさまざまなフィルター(リサンプリングフィルターを参照)を試して、結果をよりシャープにしようとしています。しかし、これは画像の結果に他のサイズ変更アーティファクトを追加する可能性があります。一般的に使用される方法の1つは、サイズ変更後に画像をシャープにすることです。通常、これは、結果の品質を制御するためのさらに多くのコントロールを含む、特殊で奇妙な名前のアンシャープ操作を使用して行われます。たとえば、非常にぼやけた 'スプライン' フィルター画像の結果を「アンシャープ」してみましょう...

  magick logo: -filter spline -resize 150x logo_spline.png
  magick logo: -filter spline -resize 150x \
          -unsharp 0x1  logo_spline_unsharp.png
[IM Output]
スプライン
==> [IM Output]
アンシャープ
ご覧のとおり、サイズ変更後に画像をシャープにすると、結果が向上します。特に星と帽子のディテールを見てください。エイリアシング、リンギング、または効果の減光さえもなしに、非常に鮮明な画像が得られます。スプラインフィルターは、特に優れたフィルターではありませんが、このシャープ化(実際には「アンシャープ」)方法は、どのフィルターでも機能します。また、結果を微調整するためのより多くのコントロールも提供します。実際、これは「photoshop」がサイズ変更された画像の品質を向上させるために行っていることですが、アンシャープ操作にどのような設定を使用しているかはわかりません。「GIMP」のデフォルト(半径= 6、量= 0.5、しきい値= 0)のアンシャープは、「-unsharp 12x6 + 0.5 + 0」と同等であり、これは正しいです(GIMPがハード半径を2倍のシグマに設定していることを無視します)。ただし、ImageMagickでカーネル半径を指定する必要はないため、「-unsharp 0x6 + 0.5 + 0」の値の方がうまく機能します。IMフォーラムのトピックGIMPのアンシャープパラメータも参照してください。投稿画像のサイズ変更では、「-unsharp 0x0.75 + 0.75 + 0.008」を500ピクセルを超える画像に適していると提案しています。Open Photography ForumのディスカッションImageMagickを使用したダウンサンプリングでは、「-unsharp 1.5x1 + 0.7 + 0.02」を提案しています。

指定されたスペースを埋めるためのサイズ変更

基本的に:大きな画像を特定の画像サイズに完全に収まるようにサイズ変更しますが、収まらない部分は切り取ります。
IM v6.3.8-3以降、新しいサイズ変更フラグ「^」を使用すると、これを単一のサイズ変更ステップとして直接実行できます。これらの例は、古いバージョンのIMのユーザーが使用できる代替方法を表しています。上記のサイズ変更の塗りつぶしフラグを参照してください。
解決策は非常にトリッキーです。画像のサイズを変更する際の通常のユーザー要件は、画像全体を特定のサイズに収めることだからです。画像のアスペクト比は維持されるため、塗りつぶそうとしている領域に余分な未使用のスペースが残ります。ここでは、画像を80x80のボックスに収まるようにサイズ変更しようとします。

  magick logo: -resize 80x80\> \
          -size 80x80 xc:blue +swap -gravity center  -composite \
          space_resize.jpg
[IM Output]
上記では、画像を塗りつぶしたいスペースを表示するために、サイズ変更ボックスの未使用部分に背景キャンバスを追加しましたが、画像のアスペクト比が維持されているため、塗りつぶされていませんでした。すべての画像が横長スタイル(縦よりも横が長い)の場合、もちろん、画像の高さと幅のいずれかに合わせてサイズを変更し、「-crop」を使用して画像を正確に収まるようにカットするだけです。

  magick logo:    -resize x80  \
          -gravity center  -crop 80x80+0+0 +repage   space_crop.jpg
[IM Output]
問題は、上記は横長スタイルの画像にのみ対応することです。画像が縦長スタイル(横よりも縦が長い)の場合、ひどく失敗します。もちろん、最初に画像の寸法を取得し、次に必要なスペースに画像を収めるための適切な方法を選択することで、スクリプトでこれを解決できます。しかし、より良い解決策は、IMにすべての画像のすべての作業を行わせることです。IM内のソリューションは、画像の各次元を個別にサイズ変更することで画像を処理することです。次に、2つの結果のうち大きい方の画像を選択します。これを簡単にするために、サイズ変更自体に組み込みのテストオプションがあり、画像が大きくなる場合にのみサイズ変更します。これにより、私たちの問題に対する非常に気の利いた解決策を使用できます。

  magick logo: \
          -resize x160 -resize '160x<'   -resize 50% \
          -gravity center  -crop 80x80+0+0 +repage  space_fill.jpg
[IM Output]
上記では、シリーズの2回目のサイズ変更は、最初のサイズ変更によって生成された幅が、塗りつぶそうとしている領域よりも小さい場合にのみ実行されます。ほとんどの画像は通常水平方向に長い写真であるため、サイズ変更の特定の順序(最初に高さ、次に幅)が選択されました。上記の順序では、そのような場合、2回目のサイズ変更操作はスキップされます。画像がより頻繁に縦長画像(垂直方向に長い)である場合は、引数を変更して、最初に高さで、次に幅で画像のサイズを変更します。例えば...

  magick logo: \
          -resize 160x -resize 'x160<'   -resize 50% \
          -gravity center  -crop 80x80+0+0 +repage   space_fill_2.jpg
[IM Output]
これらの両方の例の 결과 は非常に似ているはずであり、コマンドは横長と縦長の両方のスタイルの画像で機能しますが、一方のタイプの方がうまく機能します。この方法の最大の問題は、画像が2〜3回サイズ変更され、最終結果にぼやけやその他のアーティファクトが発生する可能性があることです。これを軽減するために、最初のサイズ変更は最終的な寸法の2倍で実行されます。これは、元の画像が最終的な望ましい結果のサイズの少なくとも3倍以上であると想定しています。サムネイルの作成には問題ありませんが、覚えておくべきことです。

線画のリサイズ

細い線を含む画像のサイズを大きく変更すると、大きな問題が発生する可能性があります...画像を非常に小さなサムネイルにサイズ変更すると、幅が数ピクセルしかない細い線が薄くなり、背景に消えてしまいます。これは非常にひどくなる可能性があり、線画のサムネイルが完全に空白に見えるのを見たことがあります!つまり、元の図面のすべてのディテールが「消えて」、サムネイルがかなり役に立たなくなりました。これが問題である場合、役立つ可能性のあるいくつかの手法があります...
  • サイズ変更してからコントラストを調整して、線をより見やすくします。ただし、これにより、線がよりエイリアス化(階段状)されます。また、この手法をどの程度まで使用できるかには限界があります。
  • 画像をぼかし、しきい値処理します(モルフォロジーの「拡張」または「収縮」と非常によく似た方法)。これにより、単一のピクセル線が約300%太くなります。1/3のサイズ変更後、画像は小さくなりますが、線は以前と同じくらい強く、目に見えるままになります。
  • 肥厚モルフォロジー技術を使用して線を太くします。最終サイズに達するまで、画像を段階的に50%ずつ厚くしてサイズ変更することができます。ただし、線の間隔が狭くなると、線画ではなく「ブロブ」になる可能性があります。つまり、逆の問題が発生する可能性があります。ただし、肥厚とサイズ変更の比率を調整することで、許容できる結果が得られるはずです。
  • 画像の線のエッジを単色の領域から分離し、それぞれを異なる方法でサイズ変更します(上記の線を使用)。その後、2つの部分を再びマージして、画像の線のエッジを保持できます。これは事実上、ベクター画像のサイズを変更するときにしばしば得られる効果を再現します。
  • 画像をベクター画像に変換してから、サイズを変更します。これは難しい場合がありますが、アンチエイリアス(シャープ)エッジと鮮明な画像を備えた線画のサイズ変更に最適な結果が得られる可能性があります。
線画を効果的にサイズ変更する他の方法を思いついたり、上記のテクニックを試した場合は、私(および他のIMユーザー)に知らせてください。