ImageMagick 使用例 -- リサイズまたはスケーリング（一般的な手法）

ここでは、画像をさまざまな方法で拡大・縮小する方法を見ていきます。画像は無傷のまま全体が保たれますが、個々の色の点が統合されたり拡張されたりして、より小さい/大きいキャンバス領域を埋めることになります。これは画像の解像度（実世界の長さあたりのピクセル数）と関連していますが、解像度はむしろ画像が最終的にどのように使われるかの結果であり、直接的な画像処理の真の関心事ではないことに注意してください。

画像のリサイズ 画像のサイズを変更する最も明白で一般的な方法は、画像をリサイズまたはスケーリングすることです。画像の内容は、目的のサイズに合わせて拡大されるか、より一般的には縮小されます。しかし、実際の画像のピクセルと色は変更されますが、画像が表現している内容は本質的に変わりません。とはいえ、画像のリサイズは厄介な問題になりうるものです。画像を非常に有害な形で変更してしまうことがあり、しかも「最良の方法」というものは存在しません。なぜなら、何が最良かは、リサイズ処理から実際に何を得たいかによって主観的に決まるからです。「最良」あるいは「完璧」な方法が存在しないため、検討すべきオプションが数多くあります。IM は常に、画像のリサイズにおいて最大限の制御範囲を提供しようと努めてきました。可能性、スタイル、手法は何百通りもあり、リサイズの専門家でさえ、画像サイズを変更する新しく異なる方法を絶えず探し求めています。もちろん、ほとんどの人にとっては、通常のデフォルトオプションで十分です。それらは一般的な用途を念頭に設計されているからです。リサイズ演算子は、実世界の画像に対して非常に良い結果を生み出すよう、慎重に設計されています。つまり、図やラインアートに使えないというわけではありませんが、その種の画像については、後で見るより高度なオプションのいくつかを使う必要があるかもしれません。
リサイズする画像を指定するときに、まず第一に考えるべきことは…
本当に画像を変更したいのか？ リサイズは画像に劇的な変化を引き起こすため、望ましくない「アーティファクト」を避けたり最小限に抑えたりすることが最も重要です。場合によっては、エッジを少しシェーブするか、あるいはもっと一般的に画像をクロップした方が、画像を丸ごとリサイズするよりも良く望ましい結果になることがあります。一般にその方が見栄えが良く、残された領域は元画像の完璧なコピーになります。画像をリサイズしない方が良いことが多いので…

リサイズ後の画像が同じサイズであれば、リサイズは何もしません。

これには例外（例外は常にあります）があり、「[-filter](https://imagemagick.org/command-line-options/#filter)」設定を使って実際にリサンプリングフィルタを指定した場合です。その場合、通常の「画像がリサイズされないなら何もしない」という挙動は上書きされ、フィルタが適用されます。しかし、多くのフィルタは（デフォルトのフィルタでさえ）画像をわずかにぼかすことがあります。それはフィルタの本質の一部です。ですから通常は、何も変わらないリサイズに対するこの「ショートカット」は良いことなのです。リサイズ演算子の引数は、画像を収めるべき領域です。この領域は画像の最終サイズ_ではなく_、画像を収める領域の最大サイズです。つまり、IM は（'!' フラグが与えられない限り）画像のアスペクト比を最終結果よりも優先して保とうとしますが、最終的な寸法の少なくとも一方（場合によっては両方）は、与えられた引数と一致します。明確に言うと…

リサイズは画像を要求されたサイズ_の中に収めます_。
要求されたボックスサイズを_埋めることはしません_。

アスペクト比は基本的に保たれます。これにより、入力画像中の円は出力画像でも円のままになります。つまり、指定しない限り、画像は押しつぶされたり引き伸ばされたりすることなく、リサイズされるだけです。たとえば、ここでは大きい画像と小さい画像の 2 つのソース画像を、64x64 ピクセルの正方形のボックスに収めようとしています。

  magick dragon_sm.gif    -resize 64x64  resize_dragon.gif
  magick terminal_sm.gif  -resize 64x64  resize_terminal.gif

ご覧のとおり、「[-resize](https://imagemagick.org/command-line-options/#resize)」は 64x64 の正方形画像を生成_しませんでした_。実際には、画像は与えられたサイズに最もよく収まるよう、ちょうど良い分だけ拡大または縮小されただけです。 アスペクト比を無視する（'!' フラグ）
必要であれば、「[-resize](https://imagemagick.org/command-line-options/#resize)」にアスペクト比を無視させて画像を歪ませ、常に指定したサイズちょうどの画像を生成させることができます。これはサイズに '!' の文字を加えることで行います。残念ながら、この文字はさまざまな UNIX のコマンドラインシェルで特別な用途にも使われることがあります。そのため、この文字を保持するために何らかのエスケープが必要になる場合があります。

  magick dragon_sm.gif    -resize 64x64\!  exact_dragon.gif
  magick terminal.gif  -resize 64x64\!  exact_terminal.gif

大きい画像だけを縮小する（'>' フラグ）
もう 1 つよく使われるオプションは、IM が与えられたサイズに収まるよう画像を縮小だけするように制限するものです。決して拡大はしません。これが '>' リサイズオプションです。与えられたサイズ「より大きい（greater than）」画像だけにリサイズを適用するもの、と考えてください（少し直感に反します）。

  magick dragon_sm.gif    -resize 64x64\>  shrink_dragon.gif
  magick terminal.gif  -resize 64x64\>  shrink_terminal.gif

  magick dragon_sm.gif    -resize 64x64^  fill_dragon.gif
  magick terminal.gif  -resize 64x64^  fill_terminal.gif

このままではこのオプションはあまり便利に見えませんが、中央寄せ（または中央寄せでない）の「[-crop](https://imagemagick.org/command-line-options/#crop)」や「[-extent](https://imagemagick.org/command-line-options/#extent)」と組み合わせて画像の余分な部分を取り除くことで、指定した領域を完全に埋めるように画像を収めることができます。リサイズと最終的な画像サイズの引数は、どちらも同じ値にすべきです。「[-crop](https://imagemagick.org/command-line-options/#crop)」が最も論理的ですが、仮想キャンバスのレイヤー情報を取り除くために追加の「[+repage](https://imagemagick.org/command-line-options/#repage)」が必要になる場合があります。「[-extent](https://imagemagick.org/command-line-options/#extent)」はこのクリーンアップを必要としませんが、位置決めのために「[-gravity](https://imagemagick.org/command-line-options/#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

  magick dragon_sm.gif    -resize 50%  half_dragon.gif
  magick terminal.gif  -resize 50%  half_terminal.gif

つまり、'%50' は '50%' とまったく同じ効果を持ちますが、読みやすさのため後者が好まれます。また、'50%x30' は実際には '50%x30%' を意味し、思われるかもしれない「幅 50%、高さ 30 ピクセル」では_ありません_。

これは「geometry」スタイル（'WxH' または '+X+Y'）の引数を使うすべての IM 引数に当てはまります。ただし、'+X+Y' のようなオフセットは決してパーセントとして扱われません。_
---|---
ピクセル面積カウント上限を使ったリサイズ（'@' フラグ）
「[-resize](https://imagemagick.org/command-line-options/#resize)」には最後にもう 1 つオプションフラグがあります。「アット」記号 '@' は、指定したピクセル数を超えないように画像をリサイズします。これはたとえば、さまざまなサイズの画像コレクションをおおよそ同じサイズにするために使えます。たとえば、ここでは両方の画像をおおよそ 64x64、つまり 4096 ピクセルのサイズにリサイズします。

  magick dragon_sm.gif    -resize 4096@  pixel_dragon.gif
  magick terminal.gif  -resize 4096@  pixel_terminal.gif

最終的な画像サイズは高さや幅が 64 ピクセルに制限されるわけではなく、IM が可能な限りこのサイズに近い（ただしそれより小さい）面積を持つことに注意してください。つまり、一方の寸法は一般に 64 ピクセルより少し大きくなり、もう一方は少し小さくなります。ある意味で、これは画像のサムネイル化にとって理想的な妥協点です。面積フィットのサムネイルサイズ を参照してください。'>' フラグを加えて、計算されたピクセル数を超える画像だけを縮小し、すでにそのサイズより小さい画像はそのままにすることもできます。 | _残念ながら、「面積リサイズ」を使う場合、'<'（小さい画像を拡大する）フラグは現在無視されます。

_
---|---
画像読み込み時のリサイズ
リサイズ演算子は、画像が読み込まれた直後、現在の画像シーケンスに追加されて次の画像が読み込まれる前に適用することもできます。そうすれば、多数の画像を読み込むのに最小限のメモリで済みます。詳しくは 画像読み込み修飾子 を参照してください。たとえば…

  magick dragon_sm.gif'[64x64]'    read_dragon.gif
  magick terminal.gif'[64x64]'  read_terminal.gif

  magick -size 8x8 pattern:CrossHatch30 -scale 800% scale_crosshatch.gif

一般に、画像拡大には 100% の倍数となる単一のパーセント値を使い、すべてのピクセルが同じ量だけ拡大されるようにします。そうしないと、ピクセルの行と列のサイズが異なってしまい、大規模なモアレパターンを生じることがあります。 たとえば、ここでは元画像のサイズの倍数ではないサイズを使って、滑らかに見える「50% グレーのチェック」パターンをひどくスケーリングしてみました。 |

  magick pattern:gray50 scale_gray_norm.gif
  magick pattern:gray50 -scale 36 scale_gray_mag.gif

画像を縮小するとき、隣接するピクセルが平均化されて新しい色のピクセルが生成されます。たとえば、画像を元のサイズの 50% にスケーリングすると、（画像サイズも 2 の倍数であると仮定して）4 ピクセルのブロックが効果的に平均化されて新しいピクセルが作られます。ただし注意が必要です。スケール縮小された画像も、新しい画像が正確な整数倍の縮小（「ビニング」として知られる手法）でない限り、モアレパターンを生じることがあります。これにはまた、元の画像サイズが最終サイズの正確な整数倍であることも必要です。また、「[-scale](https://imagemagick.org/command-line-options/#scale)」を使って実世界の写真を大幅に縮小すると、過度にシャープに見え、シャープなエッジに沿ってエイリアシング（「階段状」）効果が出る傾向があります。「[-scale](https://imagemagick.org/command-line-options/#scale)」のピクセル平均化により、「ピクセル化された」画像を生成できます。基本的には、画像のサイズを縮小してピクセルを平均化し、それから再び画像の元のサイズに拡大します。

  magick rose: -scale 25%  -scale 70x46\!  rose_pixelated.gif

  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

10 ピクセルの「ハッシュ」 | |
Box フィルタ
Resize |
ピクセルミキシング
Scale |
Triangle フィルタ
Resize
---|---|---|---|---
上の画像は大幅に拡大されています

上記は、「純粋な平均化」対「ピクセルミキシング」対「線形補間」で得られる結果を示しています。また、Scale 演算子が実際には Triangle フィルタ と似ているのは、画像をごく小さく縮小するときだけであることも示しています。それ以外の場合（強い縮小、拡大、または正確な整数サイズ指定）では、Box フィルタ のような結果を生み出します。基本的には、画像がどれだけサイズ縮小されるかに応じて、Box フィルタと Triangle フィルタの中間のようなものを生成します。拡大するときにも同様の効果が見られます。

  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

10 ピクセルの「ハッシュ」 | |
Box フィルタ
Resize |
ピクセルミキシング
Scale |
Triangle フィルタ
Resize
---|---|---|---|---
上の画像は大幅に拡大されています

拡大するとき、Box フィルタ は決して「平均化されたピクセル」を生成せず、ピクセルの行/列の複製だけを行います。しかし Scale はエッジに沿って平均化された色のピクセルを生成し、これも Triangle フィルタ によく似ていますが、まったく同じではありません。もちろんこの効果が実際に目に見えるのは、小さな非整数の拡大のときだけであり、より大きなスケーリングではエッジに沿って 1 つか 2 つの平均化されたピクセルが得られる、より典型的なケースになります。要約すると、Scale は通常のResize 演算子よりもはるかに高速です。画像処理の要件においてより汎用性が低いからです。しかし、これは完全に異なるアルゴリズムでもあり、非整数のスケールで画像をリサイズするのに使うとわずかに異なる結果を生み出します。より詳しくは ピクセルミキシング のページ、および IM フォーラムの議論 Upscaling a few pixels linearly を参照してください。上記の違いを指摘してくれたフォーラムユーザー atnbueno に特に感謝します。 Sample — 行/列の複製/削除によるリサイズ「-sample」リサイズ演算子は、特に大規模な画像縮小において、最も高速なリサイズ演算子です。実際、（上記の）「[-scale](https://imagemagick.org/command-line-options/#scale)」演算子よりもさらに高速です。画像を拡大または引き伸ばすとき、（Box フィルタ のように）ピクセルの複製だけを行い、ピクセルの色の矩形「ブロック」を生成します。しかし、画像を縮小するときは、「[-sample](https://imagemagick.org/command-line-options/#sample)」は単にピクセルの行と列を削除します。ピクセルの行と列を丸ごと追加または削除するだけなので、「[-sample](https://imagemagick.org/command-line-options/#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

  magick -size 8x8 pattern:CrossHatch30 -virtual-pixel tile \
          -magnify -magnify -magnify magnify_crosshatch.gif

  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

2 つの結果を拡大して見ると…

右側の Adaptive Resize された 画像は、左側の通常の「[-resize](https://imagemagick.org/command-line-options/#resize)」演算子を使って生成された画像よりもずっときれいに見え、ぼけが少ないことがわかります。基本的に、この演算子は、「[-resize](https://imagemagick.org/command-line-options/#resize)」演算子が急激な色の変化に対して生み出す過度のぼけを避けます。これは、わずかな画像サイズの調整、特に拡大に、そしてとりわけ急激な色の変化を含む画像に対してうまく機能します。ただし、すべてのピクセル補間法と同様に、画像が 50% を超えて拡大または縮小されると、エイリアシングやモアレ効果を生み出します。「-filter point -interpolate mesh」オプションを使った Distort リサイズ 操作でも、まったく同等の結果を生成できます。つまり、より複雑なリサンプリングフィルタではなく、単純な メッシュ補間 ルックアップ法を使って画像をリサイズするということです。 Interpolative Resize — 補間法を使ったリサイズ「-interpolative-resize」演算子は、前述の Adaptive Resize 演算子と実質的に同一です。ただし、この演算子は固定の 'Mesh' 補間法ではなく、現在の「[-interpolate](https://imagemagick.org/command-line-options/#interpolate)」設定を使います。

「[-interpolate](https://imagemagick.org/command-line-options/#interpolate)」設定に '[Nearest](misc.html#nearest)' を使うと、本質的に Sample 演算子 と同等のものが得られます。同様に、他の 単純な補間法 の多くは、同等の 補間リサイズフィルタ を使うのと等しくなります。しかし、Mesh のように、リサイズフィルタとして同等のものがない補間法もいくつかあります。

これもまたスケールされないリサイズです。つまり、拡大や小規模な縮小にはうまく機能しますが、50% を超えて縮小すると、上記の他の「サンプリングリサイズ演算子」で示したように、深刻な エイリアシング効果 が現れることがあります。 Liquid Rescale — シームカービング画像を サンプリング するリサイズが、画像から列と行を丸ごと直接削除または複製してリサイズするのと同じように、特別な IM 演算子「[-liquid-rescale](https://imagemagick.org/command-line-options/#liquid-rescale)」も画像からピクセルの列と行を削除または複製して画像を縮小/拡大します。違いは、それをよりインテリジェントな方法で行おうとする点です。まず、単純なピクセルの線を削除する代わりに、ピクセルの「シーム」を削除します。つまり、最大 45 度の角度で画像をジグザグに通り抜けることができる列（または行）です。次に、画像の内容の観点で「最も重要度が低い」シームを削除しようとします。どのように選択するかは、画像のエネルギー、より簡単に言えば、特定の「シーム」が関わる色の変化の量という観点です。変化量が最も少ない「シーム」が最初に削除され、続いてより高い「エネルギー」のシームが、画像が望みのサイズになるまで削除されます。リキッドリサイズとシームカービングについて、より詳しい情報は Wikipedia: シームカービング、YouTube ビデオデモ、および PDF 論文: Seam Carving for Content-Aware Image Resizing を参照してください。たとえば、ここでは IM ロゴが IM の「[-liquid-rescale](https://imagemagick.org/command-line-options/#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

オリジナル | |
リキッドリサイズ |
サンプリング
---|---|---|---

「[-liquid-rescale](https://imagemagick.org/command-line-options/#liquid-rescale)」が複雑なウィザードを保ちつつ、画像のあまり複雑でない星やタイトル部分を圧縮した様子に注目してください。また、ウィザードの右足もわずかに圧縮し、マントのエッジに少しギザギザを生じさせています。これは細いけれども単純なウィザードの杖に対して行ったのと同じです。一方、Sample リサイズ の画像は、単に等間隔のピクセル列を削除しただけで、その結果、画像全体が等しく歪んでしまいました。星は無傷で保たれず、すべてのエッジに明確だが一様な エイリアシング 効果が出ています。基本的に、「[-liquid-rescale](https://imagemagick.org/command-line-options/#liquid-rescale)」は、余分な「混合色」を生成したり画像をぼかしたりすることなく、一般により見栄えの良い「圧縮された」画像を生み出します。ただし、その効果を画像全体に広げるのではなく、1 か所（この場合はウィザードの杖）にわずかだが局所的なエイリアシング効果が出ることがあります。また、画像内で見つかったシームを「2 倍にする」ことで、画像を拡大することもできます。

  magick logo_trimmed.jpg  -liquid-rescale 130x100%\!  logo_lqr_expand.jpg

ご覧のとおり、まず（可能なところで）さまざまなオブジェクト間の空間を 2 倍にしようとし、それらを広げます。ただしこの場合、「低エネルギー」領域を通るシームがまとめられるため、最も左の星と「m」が歪みます。ただし、各シームは 1 回しか 2 倍にされないため、画像を拡大しすぎると、この手法は破綻し始めます。多くの場合、より良い方法は、まず画像を大きくリサイズしてから、リキッドリスケールを使って望みのサイズに縮小することです。あるいは「[-liquid-rescale](https://imagemagick.org/command-line-options/#liquid-rescale)」を複数の小さなステップで使うことです。「[-liquid-rescale](https://imagemagick.org/command-line-options/#liquid-rescale)」の効果をより良く示すために、ここに同じ画像が非常に細い画像まで縮小され、それから再び拡大されるアニメーションがあります。このアニメーションはシェルスクリプト animate_lqr を使って作成されました。

ここでも、画像がますます小さな領域に圧縮されるにつれて、画像の最も複雑な部分を保とうとする様子に注目してください。つまり、タイトルの空間が最初に優先的に圧縮され、次にウィザードの腕、それからウィザードの右側、そして最も複雑なウィザードの中央部分が一番最後に残されます。特に、星がリキッドリスケールが実装するリサンプリングのピクセル削除によって最終的に影響を受ける前に、押し合わされる様子に注目してください。（次の問題点を参照してください。）リキッドリスケールは、スポンジのように画像を圧縮しようとするもので、開けた領域が最初に圧縮され、かさばってより構造化された部分が最後に残される、と考えることができます。シームカービングの問題点 リキッドリサイズ、すなわちシームカービングは、画像からピクセルを丸ごと削除することだけで機能します。そのため、サンプリング と同様に、色を生成したり統合したりすることはなく、画像内の直線やパターンがこの操作によって大きく歪むことがあります。基本的に、何らかの平滑化の方法も適用しない限り、深刻な エイリアシング効果 を引き起こすことがあります。ただし一般に、エイリアシング効果は画像全体に広がるのではなく、画像のあまり複雑でない領域にまとめられ局所化されます。これこそがこの手法がうまく機能する唯一の理由です！「シーム」は画像をジグザグに通り抜けることができるので、シームは複雑なオブジェクトの周りを回り込むことができ、しばしばそう見えます。オブジェクト自体を圧縮しようとする前に、オブジェクト間の空間を削除するのです。たとえば、上記の実演で「Image」という単語が、あまり歪むことなく、タイトル内の他の文字の下に押し込まれているように見える様子に注目してください。ただし、この横方向の動きは 45 度の角度に制限されています。「にぎやかな」背景と、人の顔を含む写真のような「にぎやかでない」前景オブジェクトを持つ画像については、エネルギー関数が前景オブジェクトを背景より重要でないと見なすことがあります。これは深刻な有害な副作用を生じ、解決のために人間の介入が必要になる場合があります。 | _リキッドリスケールは、現在 IM v6.3.8-4 で追加された、非常に実験的な操作です。動作させるには、事前に「liblqr」デリゲートライブラリがインストールされている必要があります。

現時点では、専門ユーザー向けの制御は提供されていません。使用されるコンテンツエネルギー関数を変更する制御、ユーザー提供の保存/削除フィルタ（そのエネルギー関数を調整するもの）の使用、中間のシームカービングされた画像へのアクセス、ライブラリが提供する関数などです。そうした制御は、ユーザーが要求し、ライブラリ関数のより多くの内部制御が得られるにつれて、いずれ将来提供されるものと想定されます。

警告 これが現在実装されているとおりに残ると期待しないでください。これは非常に実験的であり、機能が変更・拡張されることが予想されます。_
---|---
Distort Resize — 自由形式のリサイズ上記のリサイズ法はすべて、先に触れた 1 つの制限を持っています。新しい画像のサイズを整数のピクセル数に丸め、それから古い画像のピクセルを新しいピクセル配列にマッピングするのです。これには 2 つの効果があります。第一に、非常に小さなサイズにリサイズするとき、結果画像の X スケールが Y スケールと正確には一致しないことがあります（アスペクト比がわずかに異なる）。この差は小さく、よほど小さくしない限り、通常は目立ちません。もう 1 つの効果は、部分的なピクセルエッジを含む領域に合わせて画像をリサイズできないことです。これは、画像オーバーレイなどのさらなる処理で重要になることがあります。また、アルゴリズムが簡単にできるにもかかわらず、（実際のリサイズなしに）画像を半ピクセルだけ右にシフト（平行移動）するためにリサイズを使うこともできないことを意味します。IM v6.3.6 では、汎用 Distort 演算子「[-distort](https://imagemagick.org/command-line-options/#distort)」が、その Scale-Rotate-Translate 歪み法を使って、これらおよびそれ以上のことを行えるようにします。制御点の移動に基づく Affine 歪みを使ってこれを行うこともできます。ただし、画像のエッジが部分的なピクセルを含むことができるため、最終画像はおそらく予想よりも 2〜3 ピクセル大きくなることに注意してください。周囲の余分なピクセルは、現在の 仮想ピクセル 設定に従って混合され、通常は透明に設定します。たとえば、ここではバラの画像を元のサイズの 90%（.9）に、回転なし（0）で、画像の中心（指定しない場合のデフォルトの制御点）を中心に縮小してリサイズします… |

  magick rose: -alpha set -virtual-pixel transparent \
          +distort SRT '.9,0' +repage  rose_distort_scale.png

改善に見えないかもしれませんし、実際エッジがぼやけていますが、これは最終的な整数画像サイズへの調整なしの、まさに要求どおりの正確なリサイズです。このため、ピクセルの色がピクセルサイズの端数にわたって広げられ、単に整数全体にではないので、エッジがぼやけています。「プラス」形式の「[+distort](https://imagemagick.org/command-line-options/#distort)」を使って、この画像の処理演算子が 仮想キャンバス 上の最終画像サイズとオフセットを、さらなる処理とレイヤー化のために正しく設定できるようにしたことに注意してください。このオフセットが不要であれば、「[+repage](https://imagemagick.org/command-line-options/#page)」演算子を使って削除できます。しかし、そのまま残しておくと、より大きなキャンバス上の画像の実際の位置が保持され、「ぼやけたエッジ」を持つ画像を正確に正しく位置決めできます。ここでは、左上の角（0,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

上端は実際には動かなかったので、比較的シャープなままであり、一方で他のすべてのエッジはぼやけたことに注意してください。ここに、サブピクセルリサイズを提供するために distort によって追加された透過を示す、上の角のピクセル拡大があります… |

  magick rose_distort_shift.png -crop 15x15+0+0 +repage \
          -scale 600%   rose_distort_shift_mag.png

上端はシャープなままで、左端（および他のすべてのエッジ）が今や半透明になっていることがわかります。そしてそれが要点です。リサイズと、結果画像の最終的なサブピクセル位置を正確に制御できるのです。リサイズされた画像を整数のピクセル数に量子化して合わせるだけではありません。つまり、distort は画像をピクセルの端数まで正確に再スケーリングして位置決めし、他の画像に正確に収められるようにします。これは、埋め込まれた画像の不正確なリサイズが「ガクガクした」効果を生み出しうるビデオ作業を行うときに、特に重要になることがあります。 | 技術的には、画像リサイズは画像歪みの簡略化された形式であり、どちらも画像リサンプリングの手法です。その非常に高速な 2 パスフィルタリング手法は、直交方向に揃ったピクセルスケーリングと、最終結果における整数のピクセル数に限定されます。
---|---
Affine、Transform IM v6.4.2-8 より、「[-transform](https://imagemagick.org/command-line-options/#transform)」または「[-draw](https://imagemagick.org/command-line-options/#draw)」演算子とともに使われる古い「[-affine](https://imagemagick.org/command-line-options/#affine)」設定も、同様の自由形式のリサイズ機能を提供します。しかし実際には、これは '[AffineProjection](distorts.html#affine_projection)' 歪み法を使って「[+distort](https://imagemagick.org/command-line-options/#distort)」を呼び出すことと同等です。そのため、前述の Distort の注意事項がすべて当てはまります。より多くの数学を必要とするため、一般的なユーザーには使いにくくなっています。一般的には、適用するアフィン歪みを指定するいくつかの代替手段を提供する上記の歪み法を使った方が良いでしょう。

Distort 対 Resize

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

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

  magick rose: -filter Lanczos -distort Resize 300x rose_distort.png

Resize（Lanczos - Sinc） |
Distort（Lanczos - Jinc）
---|---

バラの下端に沿って見ると、Distort 演算子 が実際に Resize 演算子 よりも良くきれいな結果を生み出したことがわかります。画像を拡大するときによく見られる ブロッキングアーティファクト がほとんどありません。この下端を除けば、画像の残りの部分は実質的に同一で、「[flicker_cmp](../static/img/scripts/flicker_cmp)」スクリプトを使って比較してもそうです。ただし、Distort は Resize よりもはるかに遅いことを覚えておいてください。resize が使う 2 パスの速度最適化なしに、より直接的だがはるかに複雑な 面積リサンプリング 手法を使うからです。 | _上記の 2 つの画像の本当の違いは、Distort 演算子 が画像処理に二次元の 楕円面積リサンプリング フィルタ法（円筒フィルタリングまたはリサンプリングとしても知られる）を使うことです。これは、このセクションで示した他のすべてのリサイズ法が使う一次元の 2 パスリサンプリング法よりも遅いです。上記の拡大されたバラ画像の斜めの下端に沿ってより良い結果を生み出したのも、これが理由です。これは水平・垂直のフィルタリングだけに限定されません。

これがリンギングに与える効果は、リンギングアーティファクト の例で見ることができます。

_
---|---

リサイズの手法

カラースペース補正を伴うリサイズ

  magick earth_lights_4800.tif -resize 500 earth_lights_direct.png

そしてここでは、非線形の sRGB から線形 RGB に変換し、それからリサイズし、再び変換し直します…

  magick earth_lights_4800.tif -colorspace RGB     -resize 500    \
          -colorspace sRGB  earth_lights_colorspace.png

ご覧のとおり、画像中の「ライト」がずっと明るくなっています。ソース画像の非線形カラースペースの影響をそれほど強く受けていないからです。ほとんどの画像は上記ほど大きな影響を受けませんが、それは存在しており、多くの効果を持ちえます。sRGB の非線形効果から見られる主な効果は、暗い色が（より知覚的に適切になるよう）はるかに暗い値として保存されることです。しかし、それらは暗いため、数学的に正しく処理されず、その結果、sRGB 画像は RGB（あるいは LAB や LUV）のような線形カラースペースで処理された画像よりも暗くなります。実画像の色処理 と ガンマとカラースペース補正を伴う描画 も参照してください。同じ正しいカラースペース処理は、distort（楕円フィルタ）の使用、画像のぼかしにも当てはまり、画像の量子化、ディザリング、順序付きディザリングに大きな効果を持ちえます。これはリサンプリングフィルタで詳しく見ていきます。警告: RGB カラースペースは、（黒と白の間だけでなく）強い原色の変化を伴うエッジに沿ってクリッピングの問題を生じることがあります。次のセクションを参照してください。 | |
---|---|---
v6.7.5 より古いバージョンの IM では、デフォルトの入力カラースペースは 'RGB' でした。'sRGB' カラースペースは実際には「sRGB から線形 RGB に変換された」を意味していました。その結果、2 つのラベルが入れ替わっていたのです！奇妙ですが本当です。このため、古いバージョンの ImageMagick では、上記のカラースペース補正を、それらのカラースペース名を入れ替えて行う必要がありました。このように… |

  magick earth_lights_4800.tif -colorspace sRGB \
          -resize 500  -colorspace RGB  earth_lights_colorspace.png

* この例は非推奨です ***

「-colorspace RGB」操作は実際には必要なかったことに注意してください。PNG 画像ファイル形式に保存するときに自動的に実行されたからです。上記は IM フォーラムの議論 Correct Resize から発展したものです。

ガンマ補正を伴うリサイズ

これは、ガンマ補正のみを使って画像を正しくリサイズする方法です。

  magick earth_lights_4800.tif   -gamma 0.454545 \
          -resize 500    -gamma 2.2  earth_lights_gamma.png

ガンマ逆操作「-gamma 0.454545」の代わりに「-evaluate POW 2.2」を使うこともできます。ガンマ補正は、画像を sRGB カラースペースに/から適切に変換するのに対して大まかな近似に過ぎないことに注意してください。しかし非常に近いので、カラースペース補正とガンマ補正の間で違いを見つけるのは困難でしょう。ガンマ補正は IMv7 の RGB/sRGB カラースペース設定をいじることもないので、正確なバージョンが不明な場合にはより良い選択かもしれません。「[-auto-gamma](https://imagemagick.org/command-line-options/#auto-gamma)」演算子も見てみるとよいでしょう。これは、（画像が線形カラースペースにあると仮定して）明るい領域と暗い領域が等量になるように画像を調整しようとします。

LAB カラースペースでのリサイズ

リサイズや何らかの画像処理に sRGB、RGB、あるいは XYZ カラースペースを使う場合の 1 つの問題は、3 つの色チャンネルが色だけでなく強度や明るさも表現していることです。つまり、もし 1 つのチャンネルが（クリッピングなどで）歪むと、ピクセルの色も歪み、おかしな見た目になることがあります。LAB カラースペースは線形カラースペースであるだけでなく、強度（L チャンネル）が 2 つの色チャンネル（A および B チャンネル）から分離されるよう設計されています。つまり、どれか 1 つのチャンネルがクリッピングされても、色のずれを生じません。また、純粋な白黒画像を特別に扱わない限り、一般にどのチャンネルも実際にクリップ限界に近づくことはないことも意味します。純粋な白黒画像は実生活の画像ではまれです。そのため、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

オリジナル | |
RGB カラースペース |
LAB カラースペース
---|---|---|---

ご覧のとおり、バラのエッジは線形 RGB カラースペースではクリッピングされましたが、LAB カラースペースではクリッピングされませんでした。RGB カラースペースでは、バラの下端でほぼ純白からほぼ純赤への色変化が見られ、「緑」と「青」のチャンネルに強い（負の）変化を引き起こします。これは非常に強い「負のローブ」のリンギング効果を生み、それが RGB カラースペースでクリッピングされます。最終結果は、フィルタのシャープ化効果による深刻な色の歪みです。LAB カラースペースでは、白から赤への移行は強度においても色チャンネルにおいてもそれほど強くないので、強度では良いシャープ化が得られますが、それも色チャンネルもクリッピングされず、色の歪みを避けられます。その結果、フィルタからのより適切なシャープ化効果を伴う、はるかに良いリサイズ画像が得られます。単に強度を色から分離するだけで。

LUV カラースペースを使ったリサイズ

IM v6.7.8-8 より、IM は密接に関連したカラースペース LUV も実装しています。両者とも知覚的に均一（線形）になるよう設計されており、重要な強度の 'L' または「明度」チャンネルの結果も共有していますが、色チャンネルの計算方法は異なります。主な違いは、LUV の色軸が知覚的に等しい色のデルタ（色の差）を持つように調整されていることです。その結果、LAB カラースペースとはわずかに異なる色のスケールになりますが、強度は両者で同じままです。Adams chromatic valence color space を参照してください。LAB と LUV の間のリサイズ結果は実質的に同一です。

  magick rose: -colorspace LUV  -filter Lanczos  -distort resize 300x \
          -colorspace sRGB  rose_distort_luv.png

これら 2 つのカラースペースについて詳しくは カラースペース を参照してください。

異なるカラースペースを使ったリサイズのまとめ

あるいはなぜリサイズに LAB や LUV を使わないのか？

なぜなら、sRGB と同様に、LAB と LUV カラースペースは非線形の知覚的カラースペースだからです！そして数学は線形の値にのみ適用されることを意図したものです。たとえば、ここに「Earth's City Lights」画像を 'Lab' カラースペースでリサイズした結果があります。

  magick earth_lights_4800.tif -colorspace Lab     -resize 500    \
          -colorspace sRGB  earth_lights_lab.png

結果は、知覚的な sRGB カラースペースで直接リサイズした場合に得られるものと実質的に同一です。しかし、知覚的カラースペースでのリサイズは本当に悪いことなのでしょうか？実のところ、これは議論の余地のある点です。色チャンネルのクリッピングを避けることは重要で、色のずれ（異なる色チャンネルへの不均等な変化）はそれほど重要でないように思えます。しかし、LAB と LUV の画像は知覚的に線形なのです！そのため、（リサンプリングフィルタが実際に行っていることである）色のブレンドを線形-知覚的カラースペースで行うことは、実際には良いことかもしれません。最後に 1 点だけ、sRGB は原色成分に沿った強度においてのみ知覚的に線形です。色においては実際には知覚的に線形ではないので、何らかの画像リサイズを行うには依然として悪いカラースペースのままです。Nicolas Robidoux がそれをうまくまとめてくれました… _一般に、線形光カラースペース（線形 RGB と XYZ）は誇張された暗いハローを生み、「知覚的」カラースペース（sRGB、LAB、LUV）は誇張された明るいハローを生みます。

少し考えてみれば、これは完全に理にかなっています。なぜなら、知覚的カラースペースは強度スペクトルの暗い端に多くのビットを詰め込み、明るい端を「空洞化」させて、HVS（人間の視覚システム）を模倣するからです。したがって、1 単位の暗いオーバーシュートは線形 RGB よりも sRGB の方が「遠くまで」行かず、1 単位の明るいオーバーシュートは sRGB よりも線形 RGB の方が「遠くまで」行きません。

シグモイダル化（次を参照）は、暗いオーバーシュートと明るいオーバーシュートを等しく扱い、一般に両者の極端を抑えます。

_

シグモイダルカラースペースを使ったリサイズ

ImageMagick ディスカッションフォーラムでの長い議論 Sigmoidal minimization of resampling filter haloing で、画像を線形カラースペースでリサイズしようとするのではなく、シグモイダル色修正演算子（[-sigmoidal-contrast](https://imagemagick.org/command-line-options/#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

Resize（通常の線形） |
Distort（円筒） |
シグモイダルの変種
---|---|---

本質的に、上記の最後の例が行っているのは、画像のコントラストを下げ、中間調のグレーをより狭い線形範囲に圧縮しつつ、極端な値をクリッピングのエッジからより遠ざけてから、リサイズすることです。それから後でその修正を取り除きます。これは順に、極端な色値の効果を弱める一方で、フィルタが中間調を線形的に処理できるようにし、色の歪みを減らします。多くの点で、これはデフォルトの非線形 sRGB カラースペースでの画像リサイズ（あまりにも一般的な慣行）と似ていますが、明るいリンギングアーティファクトと暗いリンギングアーティファクトの両方に対して等しくうまく機能します。つまり、色値の全範囲にわたって対称的です。一方、sRGB カラースペースでのリサイズは色範囲の暗い端側からのみ機能します（上記では青と緑の値）。つまり、はるかに制御された手法です。このシグモイダルの変種は拡大に対してのみうまく機能するかもしれないとも指摘されています。また、異なる画像については、シグモイダルコントラスト強度（上記では 6.5）の異なる値を試してみてください。すべてのリサイズ手法と同様に、結果は非常に主観的であり、すべての画像タイプに適しているとは限らないことを覚えておいてください。 | _シグモイダル変換は本質的に、非線形の知覚的カラースペース（sRGB）を使ったときに得られた以前の結果の上に構築される、特別な自作の非線形カラースペースを生成します。

RGB カラースペースで非線形の色チャンネルを持つ画像をリサイズ（歪み）すると、各色チャンネルでわずかに異なる結果になりうることに注意してください。これは（先に見たように色がクリッピングされるのとは対照的に）わずかな色のずれを生じます。

これは、sRGB やシグモイダルカラースペースのような、色と強度のチャンネルが混在した非線形カラースペースでのみ問題になります。

_
---|---

アンシャープリサイズ（USM）— Photoshop のリサイズ手法

画像をリサイズすると（縮小でも拡大でも）、しばしば画像にいくらかのぼやけ（ぼかしアーティファクト）が加わります。このため、多くの人はさまざまなフィルタ（リサンプリングフィルタを参照）をいじって、結果をよりシャープにしようとします。しかし、これは画像結果に他の リサイズアーティファクト を加えることがあります。よく使われる 1 つの方法は、リサイズ後に画像をシャープ化することです。通常これは、特別で奇妙な名前の アンシャープ操作 を使って行われ、結果の品質を制御するためのさらに多くの制御を含みます。たとえば、非常にぼやけた 'Spline' フィルタの画像の結果を「アンシャープ」してみましょう…

  magick logo: -filter spline -resize 150x logo_spline.png
  magick logo: -filter spline -resize 150x \
          -unsharp 0x1  logo_spline_unsharp.png

Spline | |
アンシャープ済み
---|---|---

ご覧のとおり、リサイズ後に画像をシャープ化すると結果が改善されます。特に星と帽子のディテールを見てください。エイリアシングやリンギング、効果の暗化さえもなく、非常に良いシャープな画像が得られます。Spline フィルタ はそもそもあまり良いフィルタではありませんが、このシャープ化（実際には「アンシャープ化」）の方法は、どんなフィルタに対しても機能します。また、結果を微調整するためのより多くの制御も提供します。実のところ、これは「photoshop」がリサイズ画像の品質を改善するために行っていることですが、アンシャープ操作 にどんな設定を使っているかは私にはわかりません。USM として知られる手法です。「GIMP」のアンシャープのデフォルト（radius=6、amount=0.5、threshold=0）は「-unsharp 12x6+0.5+0」と同等であり、これは正しいです（GIMP が半径をシグマの 2 倍にハード設定することを無視する点を除いて）。ただし、ImageMagick ではカーネルの半径を指定する必要は本当にないので、「-unsharp 0x6+0.5+0」の値の方がうまく機能します。IM フォーラムのトピック unsharp parameters in GIMP も参照してください。投稿 Image Resizing は、500 ピクセルより大きい画像に対して「-unsharp 0x0.75+0.75+0.008」を使うのが良いと提案しています。一方、Open Photography Forum の議論 Downsampling with ImageMagick は「-unsharp 1.5x1+0.7+0.02」を提案しています。

指定空間を埋めるリサイズ

  magick logo: -resize 80x80\> \
          -size 80x80 xc:blue +swap -gravity center  -composite \
          space_resize.jpg

上記では、画像に埋めてほしかった空間を示すために、リサイズボックスの未使用部分をパディングする背景キャンバスを追加しましたが、画像のアスペクト比が保たれたため、埋まりませんでした。さて、もしあなたの画像がすべて横長スタイル（高さよりも幅が広い）であれば、もちろん画像を領域の高さか幅のどちらかに合わせてリサイズし、それから「[-crop](https://imagemagick.org/command-line-options/#crop)」を使って画像をちょうど合うように切り取ることができます。 |

  magick logo:    -resize x80  \
          -gravity center  -crop 80x80+0+0 +repage   space_crop.jpg

問題は、上記が横長スタイルの画像しか扱えないことです。画像が縦長スタイル（幅よりも高さがある）の場合、ひどく失敗します。これはもちろん、スクリプトでまず画像の寸法を取得し、それから画像を必要な空間に収める正しい方法を選ぶことで解決できます。しかし、より良い解決策は、IM にすべての画像のすべての作業をさせることです。IM 内での解決策は、画像の各寸法を別々にリサイズして処理することです。そして 2 つの結果のうち大きい方の画像を選びます。これを容易にするため、resize 自体には、画像を大きくする場合にのみリサイズする組み込みのテストオプションがあります。これにより、私たちの問題に対する非常に巧妙な解決策が使えます。 |

  magick logo: \
          -resize x160 -resize '160x<'   -resize 50% \
          -gravity center  -crop 80x80+0+0 +repage  space_fill.jpg

上記では、一連のうち 2 番目のリサイズは、最初のリサイズで生成された幅が、埋めようとしている領域より小さい場合にのみリサイズします。リサイズの特定の順序（最初に高さ、それから幅）が選ばれたのは、ほとんどの画像が通常は横方向に長い写真だからです。上記の順序では、そのようなケースでは 2 番目のリサイズ操作がスキップされます。もしあなたの画像がより多く縦長画像（縦方向に長い）であれば、引数を変更して、まず高さ、それから幅で画像をリサイズしてください。たとえば… |

  magick logo: \
          -resize 160x -resize 'x160<'   -resize 50% \
          -gravity center  -crop 80x80+0+0 +repage   space_fill_2.jpg

これら 2 つの例の結果は非常に似ているはずで、コマンドは横長と縦長の両方のスタイルの画像で機能しますが、一方のスタイルに対してよりうまく機能します。この方法の最大の問題は、画像が今や 2〜3 回リサイズされ、最終結果に余分なぼけやその他の可能なアーティファクトを生じることです。これを減らすため、最初のリサイズは最終寸法の 2 倍で実行されます。これは、元画像が最終的な望みの結果の少なくとも 3 倍以上のサイズであることを前提としています。サムネイル制作では問題ありませんが、留意しておくべきことです。

ラインアートのリサイズ

細い線を含む画像を強くリサイズすると、大きな問題になることがあります… 画像を非常に小さなサムネイルにリサイズすると、わずか数ピクセル幅の細い線が薄れて背景に消えてしまいます。これがひどくなると、私はラインアートのサムネイルが完全に空白に見えるのを見たことがあります！つまり、元の図のすべてのディテールが「消え」、サムネイルがかなり使い物にならなくなったのです。これが問題なら、役立つ手法がいくつかあります…

• リサイズしてからコントラストを調整して線をより見やすくします。ただし、これは線をよりエイリアシング（階段状）させます。また、この手法をどこまで使えるかには限界があります。
• 画像をぼかして閾値処理します（モルフォロジーの「膨張」や「収縮」に非常によく似た方法）。これにより、単一ピクセルの線を約 300% 太くします。これで、1/3 にリサイズした後、画像は小さくなりますが、線は以前と同じくらい強く見えるままになります。
• 太線化モルフォロジー 手法を使って線を太くします。リサイズを段階的に行い、最終サイズに到達するまで一度に 50% ずつ画像を太くしてリサイズするとよいでしょう。ただし、線の間隔が縮むにつれて、ラインアートというよりも「塊」になってしまうことに気づくかもしれません。つまり、逆の問題が起きるかもしれません。しかし、太線化とリサイズの比率を調整すれば、許容できる結果が得られるはずです。
• 画像内の線の縁取りを単色の領域から分離し、それぞれを異なる方法でリサイズします（線は上記を使用）。その後、2 つの部分を再び統合し、画像の線の縁取りを保つことができます。これは実際、ベクター画像をリサイズするときによく得られる効果を再現します。
• 画像をベクター画像に変換してからリサイズします。これは厄介な場合がありますが、ラインアートのリサイズに対して、完璧なアンチエイリアス（シャープ）なエッジと鮮明な画像という、可能な限り最良の結果を生み出すこともできます。

ラインアートを効果的にリサイズする他の方法を思いついたり、上記の手法のいくつかを試したりしたら、私（および他の IM ユーザー）に教えてください。