|
|
|||||||||||||||||||||||||||||
|
10_Color_Quantization カラー量子化とディザリング |
H.Kamifuji . |
|
ここでは、ImageMagick6.x.x Examples of ImageMagick Usage(Examples_Legacy_Version_6) の Color_Quantization から ImageMagick7.x.x への移植について、掲載します。 Web で、日本語に翻訳した 10_Color_Quantization.pdf です。 従来は、UNIX 系の sh や windows の .bat コマンド・プロンプトを、利用していました。PowerShell 奮闘記 を、掲載したこともあり、PowerShell を、利用してみます。 現在(2024/10/22)では、PowerShell 7.4.5 が最新のようです。見直しをはじめましたが、 何と、" > パイプ問題(?)"が 解 消 されています。 パイプ関連事項を見直します。 |
色の数を減らしたり、特定の色を置き換えたりすることは、画像処理では非常に複雑で困難な手順であり、それがこのサンプル ページで取り上げられるトピックです。これには、使用する色の決定(色の量子化)、およびそれらの色を画像に配置する方法(ディザリング、パターニング)が含まれます。また、ビットマップまたは2つのカラーイメージの生成、さらにはブール(オン/オフ)透明度の処理も含まれています。 これは非常に重要であるため、色の減少や量子化はしばしば自動的に、そして舞台裏で行われますが、それはImageMagickが画像をあるファイル形式から GIF、XPixmap、XBitmap 形式などのカラフルでない形式に変換するという元の主要なタスクを実行できるようにするためです。これがどのように機能するかを知ることで、プロセスをより詳細に制御できるため、特定の画像ファイル形式で保存された結果の画像を改善することができます。 |
|
色を減らすことは、ImageMagick の非常に重要な側面です。たとえば、数百万色を含むJPEGまたはPNG画像を最大256色を含むGIF画像に変換するには、効率的かつ効果的な方法で色を減らすことができる必要があります。多くの場合、画像形式の変換中に、これは舞台裏で自動的に行われますが、これを手動で実行したい場合もあります。 画像内の色の数を減らすことは、典型的には3段階のプロセスであり、
基本的には、減色は舞台裏で自動的に処理されることが多いですが、少なくともそれが何が起こっているのか、そしてその影響がどうなるのかだけを知っておくと良いでしょう。 カラーサーベイ(Color Survey) これはおそらく最も重要ではなく、IM は調査を実行する方法を提供しますが、減色を目的としてユーザーが行うことはめったにありません。今後の議論は、関連するセクション "画像色の抽出" に残します。 色の選択(量子化)(Color Selection (Quantization)) 良い初期概要については、"ウィキペディア、色の量子化" を参照してください。 色の選択には4つの基本的な方法があります。 これらの4つのカラーコントロール方法: "量子化"、"定義済みカラーマップ"、"均一色"、および "しきい値"。あなたが見るように、すべてに限界があります。 これら4つの方法のそれぞれの例を次に示します...
#!/usr/bin/bash
convert colorwheel.png +dither -colors 32 color_quantize.gif
convert colorwheel.png +dither -remap colortable.gif color_predefined.gif
convert colorwheel.png +dither -posterize 3 color_uniform.gif
convert colorwheel.png \
-separate -threshold 50% -combine color_threshold.gif
#!/usr/bin/bash
magick convert colorwheel.png +dither -colors 32 color_quantize.gif
magick convert colorwheel.png +dither -remap colortable.gif color_predefined.gif
magick convert colorwheel.png +dither -posterize 3 color_uniform.gif
magick convert colorwheel.png `
-separate -threshold 50% -combine color_threshold.gif
|
||
|
最終的な各画像の色の数は代表的なセットにすぎませんが、それぞれのケースで約32色です(8しかないしきい値を除く)。このことから、あなたはそれらのそれぞれから何を期待できるかのアイデアを得ることができます。 他のすべてのメソッドには、カラーリダクションされるイメージに関係なく、(演算子引数に従って)色の修正セットがあります。 最初のメソッド( "-colors" )だけが、現在の画像の内容に基づいて実際に色を選択します。テスト画像は主に白であるため、多くの明るい色が選択されます。 これは、オクトツリーを使用した「適応空間サブディビジョン」と呼ばれる手法を使用して、画像内の色を調査します。次に、指定された制限内で、特定の画像に最も一致する特定の色のセットを選択しようとします。下記の "色の量子化演算子" 98 を参照してください。 "-remap" を使用すると、IM に独自 の定義済みカラーのセットを指定できます ( "ユーザー定義カラーマップ" を参照)。 上記で使用したカラーマップ "colortable.gif" は、古い "X ウィンドウアイコンライブラリ" で使用するために特別に選択された 32 色のセットで、漫画のようなアイコンを念頭に置いて設計されています。(詳細については、"AIcon ライブラリ、X アイコンの色の選択" を参照してください)。 "-posterize" を使用すると、各カラーチャンネルを数学的にカラーレベルまたは強度のセットに分割して、「均一なカラーマップ」を作成することもできます。これは、各チャンネルが一定の値または強度のセットに設定されたカラーマップです。 そして最後に、画像のすべてまたは特定のカラーチャンネルを "-threshold" することができ、本質的に各カラーチャンネルを純粋にブール型またはオン/オフにすることができます。つまり、各カラーチャンネルにはゼロまたは MaxRGB の値を与えることができます(IM 'Q'レベルに依存します)。ただし、これは約 8 色の最小セットしか生成しません。非常に限られたカラーセット。 しきい値は、2 つの色を選択する "-posterize" レベル '1' にも相当します。 カラーセットの適用(Applying a Color Set) 色のセットを作成したら、次の問題は、既存の色が選択した色のセットで置き換えられるように、その色を画像に適用することです。これは「ディザリング('Dithering')」として知られており、「これを選ぶべきか、それともあれを選ぶべきか」という性質のためにそのように名付けられています。 基本的に、ディザリングのアイデアは、異なる色のピクセルを互いに近くに配置して、実際に使用されているよりも多くの色を画像に見るように目を欺くことです。これは、人間の目が隣接する色 を「マージ」する方法のために、画像のその領域の色が画像の元の色とより密接に一致します。 ディザリングの最良の紹介の1つは "ウィキペディア" にありますが、最初に「オーディオディザリング」セクションをスキップする必要があります。これは、色のセットが限られている場合にピクセルのディザリングパターンを使用する利点の優れた例を示しています。 色の置換の基本的なスタイルは次のとおりです。
直接カラーマッピングが通常許容できると考えられるのは、ロゴ、シンボル、アイコン、および漫画のような画像の場合だけです。実際にはめったに選択肢ではありません。このため、画像内の色を直接マップしたくない場合は、通常、通常のディザリング方法をオフにする必要があります。 しかし、ディザーには独自の問題があります。画像がディザリングされると、色のパターンが画像の一部になります。このようなパターンが存在すると、削除することは非常に困難です。また、画像にディザリングを複数回再適用することは、画像が劣化するだけなので、一般的に悪い考えです。 このため、以下の量子化の例のほとんどは、一般的に、各手法のディザリングされていないバージョ ンを作成する方法を示しています。そのように行われるため、ディザリングによってその情報が隠される前に、どのような色の選択が行われているかを確認できます。 ランダムディザリングは、作成される最も単純なディザリング方法です。また、最悪のディザリング方法と見なされています。しかし、それはいくつかの特別な用途を持っています。IM 内では 2 色でのみ機能するため、通常は特殊なケースのビットマップ ディザリングに制限されます。詳細については、"しきい値が以下のランダムディザ" を参照してください。 エラー訂正ディザリングは、画像内の領域の元の色に最も近い近似値を生成するため、一般に、画像間で色を "ディザリング" する最良の一般的な方法と見なされます。また、現在、任意の色のセットをディザリングできる唯一の方法であるため、4 つの色 縮小技術すべてに使用できます。詳細については、以下の "E-Dithers の仕組み" を参照してください。 しかし、エラー訂正ディザリングには、特に画像のアニメーションに関して、いくつかの "深刻な問題" があります。 最後の 2 つのディザリングテクニックである "順序付き拡散ピクセル" と "デジタルハーフトーニング" も良い方法と見なされ、アニメーションに適していますが、現在は色のセットを使用できず、固定された均一な色のセットのみを使用します。 パターンを使用して画像に色を付ける手段を提供し、そうでなければ生成するのが簡単ではない興味深い効果を生み出すことを可能にします。 色縮小のこれらすべての側面は重要な手法であり、理解すれば、IM が提供する一般的な既定値を超えて、画像操作の結果を向上させることができます。それは勉強する価値があります。 |
||
|
使用される色の数や全体的な広がりなど、画像に関する情報は、使用する最適なテクニックを決定しようとしているプログラムやスクリプトにとって非常に重要です。ここでは、減色だけでなく、このタイプの情報を決定するために使用できる方法をいくつか見ていきます。 |
||
|
カラー表の抽出(Extracting the color table) 冗長な "identify" を使用して画像からカラーパレットを抽出し、基本的にすべてまったく同じことを行うこれらのメソッドのいずれかを使用します。 identify -verbose image.png convert image.png miff:- | identify -verbose - convert image.png -verbose -identify null: convert image.png -verbose info: |
||
![]() |
上記の詳細な識別のいずれかからの出力は、1024 色を超える場合、カラーテーブルまたはヒストグラムを返しません。大きなカラフルな画像の場合、これはヒットまたはミスの問題であり、推奨されませんが、それでも便利です。 |
|
しかし、より良い方法は、画像の "histogram:" を生成し、結果に含まれるコメントを抽出することです。 |
||
#!/usr/bin/bash convert tree.gif -format %c -depth 8 histogram:info:-
16: ( 0,128, 0) #008000 green
422: ( 0,255,255) #00FFFF cyan
126: ( 46,139, 87) #2E8B57 SeaGreen
381: ( 50,205, 50) #32CD32 LimeGreen
59: (160, 82, 45) #A0522D sienna
20: (255,255, 0) #FFFF00 yellow
|
![]() |
|
#!/usr/bin/bash magick convert tree.gif -format %c -depth 8 histogram:info:-
16: (0,128,0) #008000 green
422: (0,255,255) #00FFFF cyan
126: (46,139,87) #2E8B57 SeaGreen
381: (50,205,50) #32CD32 LimeGreen
59: (160,82,45) #A0522D sienna
20: (255,255,0) #FFFF00 yellow
|
![]() |
|
![]() |
"info:" 出力形式が IM v6.2.4 に追加されました。この使用前の IM バージョンの場合。convert tree.gif histogram:- | identify -depth 8 -format %c - |
|
これらのメソッドの問題は、色のプレーンテキスト出力が与えられ、自分のニーズに合わせて解析する必要があることです。 ただし、IM v6.2.8-8 以降では、"-unique-colors" 演算子は画像を、元の画像で見つかった一意の色ごとに 1 つのピクセルのみを含む小さな画像に変換します。 つまり、イメージをより単純なカラーテーブルイメージに変換して、存在する各カラーを一覧表示できます。画像の幅は色の数を返し、実際に色をリストする必要がある場合は、それを "txt:" 画像形式に出力することができます。 たとえば、ツリーイメージのカラーテーブルを次に示します。 |
||
#!/usr/bin/bash convert tree.gif -unique-colors -scale 1000% tree_colors.gif convert tree.gif -unique-colors -depth 16 txt:- # ImageMagick pixel enumeration: 6,1,65535,srgb 0,0: (41120,21074,11565) #A0A052522D2D sienna 1,0: (0,32896,0) #000080800000 green 2,0: (12850,52685,12850) #3232CDCD3232 LimeGreen 3,0: (11822,35723,22359) #2E2E8B8B5757 SeaGreen 4,0: (65535,65535,0) #FFFFFFFF0000 yellow 5,0: (0,65535,65535) #0000FFFFFFFF cyan |
![]() |
|
#!/usr/bin/bash magick convert tree.gif -unique-colors -scale 1000% tree_colors.gif magick convert tree.gif -unique-colors -depth 16 txt:- # ImageMagick pixel enumeration: 6,1,65535,srgb 0,0: (41120,21074,11565) #A0A052522D2D sienna 1,0: (0,32896,0) #000080800000 green 2,0: (12850,52685,12850) #3232CDCD3232 LimeGreen 3,0: (11822,35723,22359) #2E2E8B8B5757 SeaGreen 4,0: (65535,65535,0) #FFFFFFFF0000 yellow 5,0: (0,65535,65535) #0000FFFFFFFF cyan |
![]() |
|
|
この縮小カラーテーブルは、生成された色のカラーマップを非常に小さなファイルに格納する方法としても非常に重要です。このようなマップは、"-remap" 減色演算子にとって特に重要です。(下記の "定義済みカラーマップ" を参照してください) 画像内の色だけでなく、色数を含む画像を取得したい場合は、"IM フォーラムディスカッション" から開発されたカラーヒストグラムソリューションを1つ紹介します。
#!/usr/bin/bash
convert rose: -colors 256 -format %c histogram:info:- |
sed 's/:.*#/ #/' |
while read count color colorname; do
convert -size 1x$count xc:$color miff:-
done |
convert - -alpha set -gravity south -background none +append \
unique_color_histogram.png
Powershell 1.4.5 で、移植完了
PowerShell 7.4.5 で確認しました。パイプラインが正常に動作しました。PowerShell 7.4.5 で > パイプ問題が解消したようなのと、powershell では、stdout に上書き保存ができないようなので >> で、ファイル(__wwmiff.miff)経由にしました。
#!/usr/bin/bash
magick convert rose: -colors 256 -format %c histogram:info:- | `
sed 's/:.*#/,#/' | `
sed 's/:.*srgb/,srgb/' | `
ForEach-Object {
$ln = $_.Split(",")
$wk = $ln[0]
$count = [int]$wk
$color = $ln[1]
magick convert -size 1x$count xc:$color miff:- >> __wwmiff.miff
}
magick convert __wwmiff.miff -alpha set -gravity south -background none +append `
unique_color_histogram_2.png
rm __wwmiff.miff
|
||
|
組み込みの "rose:" 画像には 3020 のユニークな色が含まれているため、画像の色を減らす必要がありましたが、これには時間がかかり、非常に長い画像が生成されます。上記のバラのGIF画像には、同じ減色セットが含まれています。 結果の画像には、余分な透明なピクセルが埋め込まれていますが、同じ数のピクセルが含まれており、ご覧のとおり、緑がかった灰色、強い赤、および純粋な白の非常に強いピークが優勢です。 これは最良の一般的なカラーヒストグラム方法ではないかもしれませんが、この画像ではうまく機能します。 |
||
![]() |
"histogram:" 演算子と "-unique-colors" 演算子の両方の色の順序は未定義ですが、赤、緑、最後に青のチャンネル値で並べ替えられているように見えます。これは特定の画像にとって最良の方法ではないかもしれませんが、一般的に3次元の色を1次元の順序にソートすることは不可能です。 |
|
平均カラーの抽出 (Extracting the Average Color) 画像の平均色は、"-scale" を使用して画像を 1 ピクセルに縮小することで、非常に迅速に見つけることができます。たとえば、組み込みの "rose:" イメージの平均色を次に示します。変更せずに直接IMを使用できるカラー文字列を返す "FX エスケープフォーマット" を使用して色を出力します。 #!/usr/bin/bash convert rose: -scale 1x1\! -format '%[pixel:s]' info:- srgb(146,89,80) #!/usr/bin/bash magick convert rose: -scale 1x1`! -format '%[pixel:s]' info:- srgb(57.142%,35.0042%,31.5557%) |
||
|
"%[pixel:...]" "FX エスケープ" を使用する際の問題は、RGB 値の代わりに 'white' や 'silver' などの色名を返す可能性があることです。 ただし、3つの "FX エスケープ" を使用して実際のRGB値を必要なビット深度で返すことで、これをシミュレートできます。例えば。。。
#!/usr/bin/bash
convert rose: -scale 1x1\! \
-format '%[fx:int(255*r+.5)],%[fx:int(255*g+.5)],%[fx:int(255*b+.5)]' info:-
146,89,80
#!/usr/bin/bash
magick convert rose: -scale 1x1`! `
-format '%[fx:int(255*r+.5)],%[fx:int(255*g+.5)],%[fx:int(255*b+.5)]' info:-
146,89,80 |
||
|
IM v6.3.9 以降、詳細な "-format" または "identify" 出力を解析することなく、画像に関するより具体的な情報を抽出するのに役立つ新しい "info:" エスケープが多数あります。 たとえば、画像の "%[mean]" グレースケール値を取得することで、平均赤チャンネルの色、赤チャンネル画像を取得できます。 #!/usr/bin/bash convert rose: -channel R -separate -format '%[mean]' info: 37448 #!/usr/bin/bash magick convert rose: -channel R -separate -format '%[mean]' info: 37448 |
||
|
特定のカラーの抽出 (Extracting a Specific Color) コマンドラインから、画像から特定のピクセルカラーを抽出する 2 つの基本的な方法があります。特定のピクセル位置で "%[pixel:...]" や "%[fx:...]" (上記参照) などの "FX エスケープ" を使用します。.
#!/usr/bin/bash
convert rose: -format '%[pixel:p{40,30}]' info:-
srgb(232,54,58)
#!/usr/bin/bash
magick convert rose: -format '%[pixel:p{40,30}]' info:-
srgb(232,54,58) |
||
または、"-crop" を使用して関心のある 1 つのピクセルを切り取り、前述の方法のいずれかを使用して、画像を簡略化することもできます。例えば。。。
#!/usr/bin/bash convert rose: -crop 1x1+40+30 -depth 8 txt:- # ImageMagick pixel enumeration: 1,1,65535,srgb 0,0: (59624,13878,14906) #E8363A srgb(232,54,58) #!/usr/bin/bash magick convert rose: -crop 1x1+40+30 -depth 8 txt:- # ImageMagick pixel enumeration: 1,1,255,srgb 0,0: (232,54,58) #E8363A srgb(232,54,58) |
||
|
特定の(または近い)色のカウント (Counts of a Specific (or near) Color) これを使用して、特定の色のピクセル数またはパーセンテージを取得できます。 あなたがしていることは、その色ではないものを黒くしてから、その色を白にすることです。たとえば、 'tree' 画像の "yellow" 太陽の色の数を取得することができます。
#!/usr/bin/bash
convert tree.gif -fill black +opaque yellow \
-fill white -opaque yellow \
-print "yellow sun pixels = %[fx:w*h*mean]\n" null:
yellow sun pixels = 20
#!/usr/bin/bash
magick convert tree.gif -fill black +opaque yellow `
-fill white -opaque yellow `
-print "yellow sun pixels = %[fx:w*h*mean]\n" null:
yellow sun pixels = 20 |
||
|
キャバットが1つあり、テスト中の色自体が黒の場合、動作しません。黒(または非常に暗い色)を処理するには、塗りつぶしを入れ替えて黒以外の色を白にマップし、"結果を否定し" てすべての黒ピクセルの白いマスクを生成します。 "-print" オプションは "-format ... -write info:" の使用と同等であり、画像処理内の任意の場所で使用できることに注意してください。私はその後、特別な "null:" ファイル形式を使用して不要な画像をジャンクしました。また、画像を保存して、後の作業のためにマスクとして使用することもできます。 これは小さな画像ではうまくいきますが、はるかに大きな画像(高解像度のデジタル写真など)では、「平均」は正確なピクセル数を得るのに十分正確ではないことに注意してください! 基本的に、上記の「平均」の使用は、比率を生成するために利用可能ですが、正確なピクセル数についてはそうではありません。正確なピクセル数を取得するには、正確なピクセル数を持つヒストグラム「コメント」出力を使用する方が良いでしょう(上記参照)。 上記では、"-fuzz" 演算子の前に "ファジーファクタ" オプション "-opaque" を使用して、'near' 色を指定することもできます。 |
||
だからあなたは2つの特定の色を持っていて、それらを比較したいです。あなたは "比較" RMSE を取得する(標準エラーで)...#!/usr/bin/bash compare -metric RMSE xc:Navy xc:blue null: 18844.1 (0.287543) #!/usr/bin/bash magick compare -metric RMSE xc:Navy xc:blue null: 18844.1 (0.287543) |
||
|
これは、値の面で、そして黒から白までの距離の正規化されたパーセンテージとして、2つの色の間の距離を得るので良いです。 ただし、このメソッドは透明度を適切に処理しません。たとえば、「完全に透明な黒」と「完全に透明な白」を比較します。 #!/usr/bin/bash compare -metric RMSE xc:'#0000' xc:'#FFF0' null: 0 (0) #!/usr/bin/bash magick compare -metric RMSE xc:'#0000' xc:'#FFF0' null: 0 (0) |
||
|
Linux 版 IM v6.9.10 も Windows 版 IM v7.1.0 も意図した結果が得られない。 次のように書き直すと、それらしい結果が得られる。 |
||
#!/usr/bin/bash compare -metric RMSE xc:'#000000' xc:'#FFFF00' null: 53509.1 (0.816497) #!/usr/bin/bash magick compare -metric RMSE xc:'#000000' xc:'#FFFF00' null: 53509.1 (0.816497) |
||
|
透明色は、基になる色に関係なく完全に透明が同じであるため、実際には距離がゼロである必要があります。代わりに、4次元のハイパーキューブ距離を得ました)。そのため、上記の色距離の方法は、完全に不透明な色のみを比較する場合にのみ適しています。 実際の距離を取得するのではなく、"ファズ係数" を使用して2つの色が近いことを確認することもできます。 #!/usr/bin/bash compare -fuzz 20% -metric AE xc:Navy xc:Blue null: compare -fuzz 30% -metric AE xc:Navy xc:Blue null: 1 0 #!/usr/bin/bash magick compare -fuzz 20% -metric AE xc:Navy xc:Blue null: magick compare -fuzz 30% -metric AE xc:Navy xc:Blue null: 1 1Windows 版 IM v7.1.0 では、では、意図した結果が得られない。 |
||
ただし、ピクセルが一致しない場合(エラーピクセル数)の結果は "1" になることに注意してください。値を区切る実際の「ファジー」ファクタ距離を取得するには、「ファジー」メトリックを使用できます。#!/usr/bin/bash compare -metric FUZZ xc:Navy xc:Blue null: 18844.1 (0.287543) #!/usr/bin/bash magick compare -metric FUZZ xc:Navy xc:Blue null: 18844.1 (0.287543) |
||
|
「正規化された」値は、実際の距離が 28.7% であることを示しています。 "ファジー係数" の使用は、透明度が関係する場合の RMSE の計算とは異なります。これは、ファジー係数が、2 つの完全に透明な色が等しいものとして扱われるように設計されているためです。 そのような「完全に透明な黒」と「完全に透明な白」は正確に等しい(0またはエラーピクセルの値を生成する)... #!/usr/bin/bash compare -metric FUZZ xc:'#0000' xc:'#FFF0' null: 0 (0) #!/usr/bin/bash magick compare -metric FUZZ xc:'#0000' xc:'#FFF0' null: 0 (0) |
||
|
色を比較するもう 1 つの方法は、色を適切なファズ "ファズ係数" の割合に "置き換える" ことです。 例えば。。。 #!/usr/bin/bash convert xc:Navy -fuzz 20% -fill Blue -opaque Blue txt: # ImageMagick pixel enumeration: 1,1,65535,srgb 0,0: (0,0,32896) #000000008080 navy #!/usr/bin/bash magick convert xc:Navy -fuzz 20% -fill Blue -opaque Blue txt: # ImageMagick pixel enumeration: 1,1,65535,srgb 0,0: (0,0,32896) #000000008080 navy |
||
"Navy" は "Blue" に変化しなかったため、"Blue" とは 20%i 以上異なります。ここで、
#!/usr/bin/bash convert xc:Navy -fuzz 30% -fill Blue -opaque Blue txt: # ImageMagick pixel enumeration: 1,1,65535,srgb 0,0: (0,0,65535) #00000000FFFF blue #!/usr/bin/bash magick convert xc:Navy -fuzz 30% -fill Blue -opaque Blue txt: # ImageMagick pixel enumeration: 1,1,65535,srgb 0,0: (0,0,65535) #00000000FFFF blue |
||
|
これは色を 'Blue' に変更したので、今では 'Navy' が互いに 20% から 30% の距離にあることはわかりません。 スクリプトでこれを行うには、次のようなものを使用してください...
#!/usr/bin/bash
fuzz=%1
color1="red"
color2="#e00"
color2=`convert xc:"$color2" -format '%[pixel:s]' info:`
result=`convert xc:"$color1" -alpha set -channel RGBA -fuzz $fuzz \
-fill $color2 -opaque $color2 -format '%[pixel:s]' info:`
if [ "$result" = "$color2" ]; then
echo "Colors match according to Fuzz Factor"
else
echo "Colors DO NOT match"
fi
|
||
|
特別なオプション "-alpha set -channel RGBA" は、透明色と透明に近い色のあいまいなマッチングを可能にするために重要です。 |
||
|
色量子化の主な仕事馬であり、すべての自動減色に内部的に使用されているのは、"-colors" 演算子です。 これは「適応空間細分化」減色アルゴリズムを実装しており、非常に優れた減色アルゴリズムです。 ここに典型的な例があります、私は多くの色を含む「カラーホイール」画像の画像を持っています、そして我々は様々な "ディザリング方法" を使って、色の数だけを64色に減らすように IM に頼みます。
#!/usr/bin/bash
convert colorwheel.png -dither None -colors 64 colors_64_no.gif
convert colorwheel.png -dither Riemersma -colors 64 colors_64_rm.gif
convert colorwheel.png -dither FloydSteinberg \
-colors 64 colors_64_fs.gif
#!/usr/bin/bash
magick convert colorwheel.png -dither None -colors 64 colors_64_no.gif
magick convert colorwheel.png -dither Riemersma -colors 64 colors_64_rm.gif
magick convert colorwheel.png -dither FloydSteinberg `
-colors 64 colors_64_fs.gif
|
||
|
IM では、既定では "ディザー" を使用して画像上の色をシェーディングします。これにより、滑らかに変化するグラデーションに対する色の急激な変化を防ぐことができます。 ディザリング ( 'None' または "+dither" 設定を使用) をオフにすると、どの色 がマージされたかが明確にわかり、この特定の画像に最適な色のセットと見なされる IM が生成されます。また、ディザリングが行われなかった場合に色のグラデーションが生成する突然の色の変化も確認できます。 もちろん、この画像は、ほとんどの画像が使用するものよりもはるかに多くの色を使用します。そのため、64 色の制限は多くの画像で許容できることがよくありますが、この画像では完全に許容できません。言い換えれば、色の量子化は、特定の画像に最適な色 のセットを見つけようとします。 IM ロゴの一部の色量子化の例を次に示します。
#!/usr/bin/bash
convert logo: -resize 40% -crop 100x100+105+50\! -normalize logo.png
convert logo.png +dither -colors 8 colors_8_no.gif
convert logo.png -dither Riemersma -colors 8 colors_8_rm.gif
convert logo.png -dither FloydSteinberg \
-colors 8 colors_8_fs.gif
#!/usr/bin/bash
magick convert logo: -resize 40% -crop 100x100+105+50`! -normalize logo.png
magick convert logo.png +dither -colors 8 colors_8_no.gif
magick convert logo.png -dither Riemersma -colors 8 colors_8_rm.gif
magick convert logo.png -dither FloydSteinberg `
-colors 8 colors_8_fs.gif
|
||
それを組み込みの "rose:" 写真画像のいくつかの結果と比較してください。
#!/usr/bin/bash
convert rose: +dither -colors 16 colors_16_no.gif
convert rose: -dither Riemersma -colors 16 colors_16_rm.gif
convert rose: -dither FloydSteinberg \
-colors 16 colors_16_fs.gif
#!/usr/bin/bash
magick convert rose: +dither -colors 16 colors_16_no.gif
magick convert rose: -dither Riemersma -colors 16 colors_16_rm.gif
magick convert rose: -dither FloydSteinberg `
-colors 16 colors_16_fs.gif
|
||
|
ご覧のとおり、漫画のような画像は、合理的な結果を得るために実際の写真よりもはるかに少ない色しか必要としません。 |
||
![]() |
現在、IM に実装されている色量子化アルゴリズムは 1 つだけで、非常にうまく機能するため、他のアルゴリズムを追加する必要はほとんどありませんでした。しかし、フィードバックにより、このアルゴリズムは着実に改善されています。 ASIDE: 参考までに、"Gifsicle" プログラムは他の多くの色量子化メソッドをリストしています ( "--color-method" オプションを使用)。私は、これらの色の量子化方法が IM とどれほどよく比較されるのか分かりません。色の量子化のさまざまな方法への良い参照を見つけたら、私にメールしてください。 |
|
画像で使用する限られた数のカラーを選択するプロセスは、カラー量子化と呼ばれ、多くの要因を含む非常に複雑なプロセスです。その完全な技術的説明は、ImageMagick のウェブサイト "Color Reduction Algorithm" に記載されています。しかし、私はここでこれのより重要な側面のいくつかの例を挙げようとします。 おそらく最大の要因は、画像で使用されている実際の色です。その色に「近い」ピクセルが非常に少ない場合、画像の特定の色を選択するのは良いことではありません。そのため、色の選択は、画像で使用される色だけでなく、色に「近い」ピクセル数にも依存します。 私は2つの異なる2つのカラー画像を1つの共通の色 に減らすことで、これを非常に簡単に実証できます。
#!/usr/bin/bash
convert -size 4x1 xc:blue -draw 'fill red point 0,0' \
-scale 20 colors_rb.gif
convert -size 4x1 xc:red -draw 'fill blue point 3,0' \
-scale 20 colors_br.gif
convert colors_rb.gif -colors 1 colors_rb2.gif
convert colors_br.gif -colors 1 colors_br2.gif
#!/usr/bin/bash
magick convert -size 4x1 xc:blue -draw 'fill red point 0,0' `
-scale 20 colors_rb.gif
magick convert -size 4x1 xc:red -draw 'fill blue point 3,0' `
-scale 20 colors_br.gif
magick convert colors_rb.gif -colors 1 colors_rb2.gif
magick convert colors_br.gif -colors 1 colors_br2.gif
|
||
ご覧のとおり、単一の最終色は、存在する色だけでなく、画像内の各色の量にも依存します。#!/usr/bin/bash convert -size 20x640 gradient: -rotate 90 gradient.png convert gradient.png +dither -colors 5 colors_gradient.gif
#!/usr/bin/bash magick convert -size 20x640 gradient: -rotate 90 gradient.png magick convert gradient.png +dither -colors 5 colors_gradient.gif
|
||
|
色の量子化は、現在の色空間内で均一であることに注意してください。 FUTURE: Just what are the effects of the "-treedepth" setting?Mail me if you know |
||
|
どの色が選択されるかに関するもう1つの大きな影響は、「近い」または「近く」の色の意味を正確に定義することです。これは、量子化(色の選択)に使用される色空間によって定義され、(IM v6.2.8-6の時点で) "-quantize" 色空間設定によって制御されます。 "-quantize" 設定は、非常に少数の色が選択されている場合に特に重要になります。デモンストレーションのために、さまざまな異なる色空間を使用し、異なる「色距離」を定義する標準の "カラーホイール" 画像を減らしましょう。
#!/usr/bin/bash
for S in RGB CMY sRGB GRAY \
XYZ LAB LUV \
HSL HSB HWB \
YIQ YUV OHTA ; do \
convert colorwheel.png -quantize $S +dither -colors 16 \
-fill black -gravity SouthWest -annotate +2+2 $S \
colors_space_$S.gif; \
done
#!/usr/bin/bash
$dt = "RGB CMY sRGB GRAY XYZ LAB LUV HSL HSB HWB YIQ YUV OHTA".Split(" ")
for ( $i = 0 ; $i -lt $dt.length ; $i++ ) {
$S = $dt[$i]
magick convert colorwheel.png -quantize $S +dither -colors 16 `
-fill black -gravity SouthWest -annotate +2+2 $S `
colors_space_$S.gif
}
|
||
|
ご覧のとおり、選択する色は、色空間の構成に大きく依存します。sRGB(赤、緑、青)カラーキューブは、通常、少なくとも原色に近い色が選択されます。 sRGB 色空間は、画像やアイコンのような漫画の色を選ぶのに特に適していますが、実際には一般的な絵のような写真のための悪い色空間です。 CMY カラースペースはsRGBカラースペースとまったく同じで、カラーチャンネルは単にsRGBカラースペースとCMYカラースペースの間で変換するために否定されます。そのため、量子化色はほぼ同じ解になります。 |
||
![]() |
CMYK色空間(図示せず)も、同じですが、異なる理由で生成されます。内部 'K' チャンネルと画像 'カラーマップ' は同じデータ ポインター ( "パレット チャンネル" を参照) を使用するため、IM は量子化の前に CMY に変換し直します。 |
|
期待どおりの sRGB 色空間は、RGB として類似した結果を生成しますが、色空間内の黒に近い色の数を除去するためにワープされます。そのため、カラーホイールの中心から選択できる色が少なくなり、より大きな「それほど黒くない」スポットが生成されます。 XYZ 色空間も線形 RGB 色空間と非常によく似ています。ここでの大きな違いは、カラーホイールの色データがもう少し圧縮され、その結果、量子化がより広がるように見えるため、私たちが見ることができるすべての可能な色(そして通常は見ることができない色さえも)をよりよく含むように色軸がシフトしたことです。 LAB カラースペースと LUV カラースペースは、互いに異なるが類似したカラー軸に基づいています。その結果、色の量子化の配置が異なります。 HSL (色相彩度、明度)、HSL (色相、彩度、明るさ)、HWB (色相、白、黒)などの「色相」チャンネルを含む特別な色空間はすべて、色空間の一部として色の循環カラーホイール表現を持っています。実際には、このカラーホイールを生成するために使用された HSL 色空間を使用していました。"カラーホイールの生成" を参照してください。 |
||
![]() |
執筆時点では、IMが使用する色距離アルゴリズムは、色空間の「色相」の周期的性質を考慮に入れていない。このアルゴリズムは非常に異なっています。このため、「色相」が包み込まれる「赤」の経路に沿って強い不連続性が発生し、色の量子化プロセスで選択される赤色はほとんどありません。 |
|
YIQ、YUVは、微妙な色合い、特に肌の色調を含む現実世界の写真や画像にはるかに適した、より自然な「パステル」と「ミッドトーン」の色合いを生成するように設計されています。 Helmut Dersch 氏は "自身の Web サイト" で、歪みにLAB 色空間を使用することを検討すべきだと述べています。 |
||
![]() |
古いバージョンの IM (特に IM バージョン 5) では、量子化に使用された色空間は "-colorspace" オプションを使用して設定されていました。ただし、IM バージョン 6 では、この演算子はイメージがメモリに格納される方法を変更するために使用されるため、色の量子化の設定ではありません。 そのため、IM v6.2.8-6 では、このジョブを実行するために "-quantize" 設定が提供されました。ただし、それは "-colors"、色の量子化プロセスの設定としてのみです。"-remap" や "-posterize" などの演算子を使用した色の置換やディザリング、またはさまざまなディザリング手法については、何もしません。 |
|
使用可能な色空間の完全なリストについては、"-colorspace" 演算子を参照してください。 色選択に対する色空間の効果については、"単色のランダムスポット" の例を参照してください。そこでは、色の量子化は、さまざまな色空間を使用してランダム化された画像の色の数を減らすために使用されます。 |
||
|
掲載を省略します。本家のページを見て下さい。 |
||
|
ImageMagick はデフォルトで完全に不透明な色を生成するだけでなく、半透明の色も生成しようとします。このようにして、透明な影やその他のオーバーレイ効果を含む画像は、それらの効果を失うことはありません。 ただし、IM v6.2.6では、透明度を含む色の量子化が変更され、完全に透明なすべての色が同じ色として扱われました。これは線形の変更であるため、半分透明のカラーも、完全に不透明の場合よりも互いに近いと考えられています。 この変更により、IM カラー量子化では半透明の色が生成されますが、画像内の完全に透明な色には集中しなくなり、不透明な色に集中しなくなります。 たとえば、ここでは、画像の上部に完全に不透明で、上部に完全に透明の "色のレインボーグラデーション" を生成します。背景パターンに画像を表示して、画像がどれほど透明であるかがわかるようにしました。
#!/usr/bin/bash
convert xc:red xc:yellow xc:green1 xc:cyan xc:blue \
+append -filter Cubic -resize 100x100\! -size 100x100 \
gradient: +matte -compose CopyOpacity -composite alpha_gradient.png
convert alpha_gradient.png +dither -colors 256 alpha_colors_256.png
convert alpha_gradient.png +dither -colors 64 alpha_colors_64.png
convert alpha_gradient.png +dither -colors 15 alpha_colors_15.png
#!/usr/bin/bash
magick convert xc:red xc:yellow xc:green1 xc:cyan xc:blue `
+append -filter Cubic -resize 100x100`! -size 100x100 `
gradient: +matte -compose CopyOpacity -composite alpha_gradient.png
magick convert alpha_gradient.png +dither -colors 256 alpha_colors_256.png
magick convert alpha_gradient.png +dither -colors 64 alpha_colors_64.png
magick convert alpha_gradient.png +dither -colors 15 alpha_colors_15.png
3 行目の alpha_gradient.png が正しく生成されていないようなので、Linux 版 IM v6.9.10 で作成した alpha_gradient_1.png で +dither の機能を確認します。 #!/usr/bin/bash # magick convert xc:red xc:yellow xc:green1 xc:cyan xc:blue ` # +append -filter Cubic -resize 100x100`! -size 100x100 ` # gradient: +matte -compose CopyOpacity -composite alpha_gradient.png magick convert alpha_gradient_1.png +dither -colors 256 alpha_colors_256_1.png magick convert alpha_gradient_1.png +dither -colors 64 alpha_colors_64_1.png magick convert alpha_gradient_1.png +dither -colors 15 alpha_colors_15_1.png
|
||
|
ご覧のとおり、この画像に必要な色の数を減らすようにIMに依頼すると、不透明な色がはるかに多く作成され、半透明の部分には透明度の高い色が少なくなりました。その結果、特に色の数が非常に少ない場合に、選択された色の非常に良好な広がりが得られます。 しかし、私が上で指摘したように、原色が選ばれないだけでなく、完全に透明な色もまったく同じ理由で選ばれません。実際には、完全に不透明な色でさえ選ばれません!つまり、前の例のカラー量子化画像のすべての色は半透明です。 それだけを明確にしましょう。
透明度が関係する場合、IM カラー量子化では、 一部の画像には、煙や影の効果を含む画像など、多くの半透明の色が含まれる可能性があるため、試運転を行って、結果の画像に含めるために完全に透明な色が選択されていることを確認することをお勧めします。その後、最も透明な色を完全に透明にマップし、自分で "色を再マップ" できます。 結果の画像に完全に不透明な色と完全に透明な色の両方を取得することを本当に確認したい場合は、アルファチャンネルを "正規化またはコントラストストレッチ" することができます。 たとえば、ここでは、メインの色選択が "-contrast-stretch" を使用して不透明になるようにします。これはおそらくより正常な状況では少し重い手ですが。
#!/usr/bin/bash
convert alpha_gradient.png +dither -colors 15 \
-channel A -contrast-stretch 10% alpha_colors_15n.png
#!/usr/bin/bash
magick convert alpha_gradient_1.png +dither -colors 15 `
-channel A -contrast-stretch 10% alpha_colors_15n_1.png
|
||
|
これは、半透明の色を許可しないGIF画像、透明度を許可しない JPG、または適切に保存するために量子化を必要としないPNGでも問題ではありません。これは、半透明の色がたくさん関係しているときに画像の色縮小を強制する特別な場合にのみ問題になります。 GIF 形式は半透明の色を保存するのは役に立たない努力であることを忘れないでください。そのため、このような画像形式に対して色量子 化を自分で行う予定の場合は、縮小されたカラーセットを生成するときに画像の透明度を無視するようにIMに指示する必要があります。これを行うには、 '-quantize' の特別な "transparent" 色空間設定を使用します。
#!/usr/bin/bash
convert alpha_gradient.png -quantize transparent \
+dither -colors 15 alpha_colors_15qt.png
#!/usr/bin/bash
magick convert alpha_gradient_1.png -quantize transparent `
+dither -colors 15 alpha_colors_15qt_1.png
|
||
|
色の量子化が色の透明度を完全に無視し、画像のアルファチャンネルにまったく触れなかったことに注意してください。つまり、アルファチャンネルは、他の色 とは完全に別々に、画像に適した方法で処理できます。実際、 "-colors" を使用する前または後に問題なくこれを行うことができます。結果に違いはありません。 したがって、この量子化カラースペースは、GIF や XPM イメージフォーマットなど、ブール値または透明度のないフォーマットに保存する予定のイメージの色の数を減らす場合に推奨されます。 生成された色の数をカウントアップすると、要求された色の数を正確に生成したこともわかります。そのため、完全に透明な色(おそらく)が必要な場合は、 "-colors" の引数を少なくとも1つ減らして、画像の最終カラーテーブルにスペースを残す必要があります。 したがって、GIF ファイル形式の 256 カラーカラーテーブルの制限を処理するには、色を 256 ではなく 255 に減らし、"-transparent-color" 設定で定義されているように、完全に透明なカラーインデックス用の余分なスペースを残す必要があります。カラーテーブルのサイズを小さくするためにこれを調整します。 この量子化動作は、IM が GIF ファイル形式に保存すると自動的に行われますが、グローバルまたは共有カラー テーブルの生成中に自分で量子化を DIY する必要がある場合に重要です。 もちろん、半透明のピクセルを処理する必要があるため、画像の外観に合っています。 FUTURE: This last part will probably move to a new section on 'DitheringAlpha Channel' to be created in the near future. And a reference to thissection added here. アルファチャンネルだけをブール値またはオン/オフ設定だけにディザリングし、画像内の残りのカラーチャンネルに影響を与えない例をいくつか紹介します。
#!/usr/bin/bash
convert alpha_gradient.png \
-channel A -threshold 50% alpha_dither_threshold.gif
convert alpha_gradient.png \
-channel A -ordered-dither checks alpha_dither_checks.gif
convert alpha_gradient.png \
-channel A -ordered-dither o8x8 alpha_dither_ordered.gif
convert alpha_gradient.png \
-channel A -ordered-dither h8x8a alpha_dither_halftone.gif
convert alpha_gradient.png -channel RGBA -separate \
\( +clone -monochrome \) \
+swap +delete -combine alpha_dither_monochrome.gif
convert alpha_gradient.png -channel RGBA -separate \
\( +clone -dither FloydSteinberg -monochrome \) \
+swap +delete -combine alpha_dither_monochrome_fs.gif
convert alpha_gradient.png -channel RGBA -separate \
\( +clone -remap pattern:gray50 \) \
+swap +delete -combine alpha_dither_map.gif
convert alpha_gradient.png -channel RGBA -separate \
\( +clone -dither FloydSteinberg -remap pattern:gray50 \) \
+swap +delete -combine alpha_dither_map_fs.gif
#!/usr/bin/bash
magick convert alpha_gradient_1.png `
-channel A -threshold 50% alpha_dither_threshold_1.gif
magick convert alpha_gradient_1.png `
-channel A -ordered-dither checks alpha_dither_checks_1.gif
magick convert alpha_gradient_1.png `
-channel A -ordered-dither o8x8 alpha_dither_ordered_1.gif
magick convert alpha_gradient_1.png `
-channel A -ordered-dither h8x8a alpha_dither_halftone_1.gif
magick convert alpha_gradient_1.png -channel RGBA -separate `
`( +clone -monochrome `) `
+swap +delete -combine alpha_dither_monochrome_1.gif
magick convert alpha_gradient_1.png -channel RGBA -separate `
`( +clone -dither FloydSteinberg -monochrome `) `
+swap +delete -combine alpha_dither_monochrome_fs_1.gif
magick convert alpha_gradient_1.png -channel RGBA -separate `
`( +clone -remap pattern:gray50 `) `
+swap +delete -combine alpha_dither_map_1.gif
magick convert alpha_gradient_1.png -channel RGBA -separate `
`( +clone -dither FloydSteinberg -remap pattern:gray50 `) `
+swap +delete -combine alpha_dither_map_fs_1.gif
|
||
![]() |
アルファチャンネルのコピーをディザリングするときは、"-monochrome" または "-remap" のいずれかを使用してディザリングできるように、イメージが透明度を含むシェイプマスクではなく、純粋なグレースケールイメージであることを確認してください。そうしないと、アルファチャンネルからの非線形効果がまだ存在する可能性があります。 画像からアルファチャンネルを抽出して復元するには、グレースケールマスクとしてディザリングする方法はいくつかあります。上記では、これを行うために "チャネル分離" と "結合" を使用しています。他の方法は、"コピー不透明度コンポジション" による "アルファ抽出" を使用します。 |
|
|
序論で説明したように、エラー訂正ディザは、一般に、縮小されたカラーセットで元の画像の真の表現を生成するための最良の選択と見なされます。また、ユーザーが指定したものか、IM 色の量子化ルーチンによって決定されたかにかかわらず、定義済みの色パレットに制限されます。 このため、IM 演算子 "-colors" , "-remap" , "-posterize" および "-monochrome" によって提供される一般的な色下げの論理的な既定の選択です。 |
||
|
バージョン 6.4.2-9 以降、IM には複数の種類のディザリング スタイルまたはメソッドが用意されており、"-dither" 設定を使用して選択できるようになりました。このIM以前は、"リーメルスマ・ディザー(Riemersma Dither)"、または "ヒルベルト曲線ディザー(Hilbert Curve Dither)" のバリエーションに限定されていました。これは "-dither Riemersma" を使用して設定できます。 これで、"-dither FloydSteinberg" を使用してフロイド・シュタイバーグ・ディザーを選択することもできます。あなたのバージョンの IM に実装されているディザメソッドの種類は、"convert -list dither" で、検索できます。 #!/usr/bin/bash convert -list dither None FloydSteinberg Riemersma #!/usr/bin/bash magick convert -list dither None FloydSteinberg Riemersma |
||
たとえば、ここでは、さまざまなディザリング方法を使用してディザリングしたカラーホイールを示します。#!/usr/bin/bash convert colorwheel.png -dither Riemersma -colors 16 dither_riemersma.gif convert colorwheel.png -dither FloydSteinberg -colors 16 dither_floyd.gif
#!/usr/bin/bash magick convert colorwheel.png -dither Riemersma -colors 16 dither_riemersma.gif magick convert colorwheel.png -dither FloydSteinberg -colors 16 dither_floyd.gif
|
||
|
ご覧のとおり、フロイド・スタインバーグ・ディザは、デフォルトのリーマースマ・ディザよりもはるかに均一なディザパターンを生成します。それらの最大の違いは、それらのそれぞれが隣接するピクセル間で「カラーエラー」をどのように分配するかです。それでは、E-Dither がどのように機能するかを見てみましょう。 |
||
|
IMが一般的なディザリングに使用する具体的な方法は、「ヒルベルト曲線誤差補正ディザ」の変形例である。これは実際には非常に優れたディザリング技術であり、非常によく定義されており、合理的に高速です。完全な説明(および非常によく似たバリエーション)については、以下を参照してください... "リーメルスマ・ディザー"。 基本的に、画像内の各ピクセルは、"ヒルベルト曲線" と呼ばれる非常に複雑なパスで見られます。ピクセルには、そのピクセル値に最も近い色が割り当てられ、ピクセルの元の色と選択した色との差は、新しい色が再び選択される前に保存され、次のピクセルのカラー値(常に隣接するピクセル)に追加されます。このようにして、選択した色と画像の元の色との間のカラーバリエーションは、同じ領域内の他のピクセルに分配されます。その結果、特定の色のみが最終画像に割り当てられますが、その領域の同じ基本色が元の画像と密接に一致します。 たとえば、元の色を含まない一連の色を使用してIMにディザリングを依頼した小さな灰色の画像を次に示します。結果の画像は拡大され、割り当てられた個々の色付きピクセルを確認できます。
#!/usr/bin/bash
convert -size 10x10 xc:'#999999' -scale 80x80 dither_not.gif
convert -size 10x10 xc:'#999999' \
-remap colortable.gif -scale 80x80 dither.gif
#!/usr/bin/bash
magick convert -size 10x10 xc:'#999999' -scale 80x80 dither_not.gif
magick convert -size 10x10 xc:'#999999' `
-remap colortable.gif -scale 80x80 dither.gif
|
||
|
元の画像の色が指定されたカラーマップになかったため、元の色は、指定されたカラーテーブルにあった最も近い3つの色のパターンを使用して近似されます。 上記のディザパターンによって生成された色を平均化すると、 色 、これは画像の元の平均色に非常に近く、それが生成されたディザパターンの全体のポイントです。 しかし、色を割り当てるために使用される「パス」は複雑であるため(通常はローカルエリアに残りますが)、色の割り当ては本質的にランダムなパターンを生成します。 ただし、同じ画像が同じパターンを生成するため、技術的にランダムではありませんが、結果はランダム、または少なくとも擬似ランダムである可能性があります。 「F-S」ディザは、実際には1970年代初頭の創業以来開発されたいくつかの「ラスタライズドE-ディザー」の1つ(最初のもの)にすぎません。また、おそらく最も広く実装されていますが、最高のものとは見なされていません。このようなアルゴリズムのより完全な要約については、論文 "ディザリングアルゴリズム" を参照してください。 IM v6.4.3 以降では、IM でも直接利用でき、画像の上部から下部まで「蛇行」パスを 1 行ずつたどるように実装されています。
#!/usr/bin/bash
convert -size 10x10 xc:'#999999' -dither FloydSteinberg \
-remap colortable.gif -scale 80x80 dither_fs.gif
#!/usr/bin/bash
magick convert -size 10x10 xc:'#999999' -dither FloydSteinberg `
-remap colortable.gif -scale 80x80 dither_fs.gif
|
||
|
特に私が見つけた「フロイド・スティエンバーグ・ディザー」は、「ヒルベルト曲線ディザー」よりも「ハッシュ」のようなピクセルパターンを生成し、実際にそうするように設計されています。 このような規則的なパターンは、小さなカラーアイコン画像の低レベルの手動クリーンアップをはるかに簡単にすることができます。これは私が過去に "アンソニーのアイコンライブラリ" のためにたくさんやったことでしたが、おそらく小さなモノクロ画像を除いて、そのようなことはもはや頻繁には必要ありません。 |
||
|
エラー訂正ディザを使用するときに直面する最大の問題の 1 つは、本質的にランダムなピクセルパターンが得られることです。 たとえば、元のグレーの画像を取得し、1つのピクセルを別の色に置き換えてから、再度ディザリングします。その結果、ヒルベルト曲線ディザが続くパスに沿ってさらに進むすべてのピクセルのディザリングパターンが完全にシフトします。
#!/usr/bin/bash
convert -size 10x10 xc:'#999999' -draw 'fill #C28 point 2,2' \
-remap colortable.gif -scale 80x80 dither_modified.gif
compare dither.gif dither_modified.gif dither_difference.gif
#!/usr/bin/bash
magick convert -size 10x10 xc:'#999999' -draw 'fill #C28 point 2,2' `
-remap colortable.gif -scale 80x80 dither_modified.gif
magick compare dither.gif dither_modified.gif dither_difference.gif
|
||
|
ご覧のとおり、画像に1ピクセルを追加するだけで、ディザパターンが劇的に変化しました!画像の全体的な外観(拡大されていない場合)は基本的に同じですが(結局のところ、これは良いディザアルゴリズムの目的です)、結果の画像が異なるようになるのに1ビットの変更しかかかりません。 "compare" 画像は、ディザパターンの変化の程度も示しています。この場合、ピクセルの約 80% にまったく異なる色が割り当てられました。ヒルベルト曲線ディザでは、実際には1つのピクセル変更で、後で来るすべてのピクセルが異なる可能性があるため、ディザパターンの0?100% が異なる可能性があります。それは単に、複雑なヒルベルト曲線のどこで変化が起こったかに依存します。 しかし、フロイド・スタインバーグのディザは画像を通して一方向にしか進行しないため、1 つのピクセル変更ではパターンが変更の片側にのみ変更されます。
#!/usr/bin/bash
convert -size 10x10 xc:'#999999' -draw 'fill #C28 point 2,2' \
-dither FloydSteinberg -remap colortable.gif \
-scale 80x80 dither_fs_modified.gif
compare dither_fs.gif dither_fs_modified.gif dither_fs_difference.gif
#!/usr/bin/bash
magick convert -size 10x10 xc:'#999999' -draw 'fill #C28 point 2,2' `
-dither FloydSteinberg -remap colortable.gif `
-scale 80x80 dither_fs_modified.gif
magick compare dither_fs.gif dither_fs_modified.gif dither_fs_difference.gif
|
||
|
ご覧のとおり、まったく同じ問題があります。1 つのピクセル変更により、そのピクセルの後に処理されたイメージの領域のディザ パターンがほぼ完全に変化します。それはその行から下に向かっています。 単一の画像の場合、結果として得られるディザリングされた色のパターンは重要ではありません。パターンの平均色は、画像のその領域に適した色を画像に与える必要があります。しかし、1つの画像の後に他の非常によく似た画像が続くアニメーションがあり、色の広い領域がある場合、変化するディザパターンは非常に目立ち、低レベルの背景「ノイズ」として刺激的になります。 たとえば、ここでは、同じディザリングされた色 の3つの画像アニメーションを生成しますが、各フレームで 1 つのピクセル変更を行います。また、中央領域を拡大して、この変化するパターンをより明確に見ることができます。
#!/usr/bin/bash
convert -size 80x80 xc:'#999999' \
\( +clone -draw 'fill #C28 point 2,2' \) \
\( +clone -draw 'fill #28C point 2,2' \) \
-remap colortable.gif -set delay 50 -loop 0 dither_anim.gif
convert dither_anim.gif -crop 10x10+40+40 +repage \
-scale 80x80 dither_anim_magnify.gif
#!/usr/bin/bash
magick convert -size 80x80 xc:'#999999' `
`( +clone -draw 'fill #C28 point 2,2' `) `
`( +clone -draw 'fill #28C point 2,2' `) `
-remap colortable.gif -set delay 50 -loop 0 dither_anim.gif
magick convert dither_anim.gif -crop 10x10+40+40 +repage `
-scale 80x80 dither_anim_magnify.gif
|
||
|
ご覧のとおり、E-Ditherによって生成される擬似ランダム性によって引き起こされる、画像に一種のかき混ぜる背景が得られます。ほとんどの場合、使用される色は、この「ディザノイズ」を目にしないように十分に近接しています。しかし、ディザリングの色が目に見えて異なる場合(この場合はカラーマップの使用によって強制されます)、それは間違いなく問題になります。 この「ディザノイズ」を示すアニメーションのより実用的な例については、"ビデオカラーの最適化" を参照してください。 パターンの変化は、アニメーションの最適化にも問題を引き起こします。これは、単純なフレーム "最適化ではフレーム" オーバーレイのサイズを縮小できないことを意味する別のパターンです。1つの解決策については、"あいまいな色の最適化" を参照してくださいが、チャーンが非常によく似た色 を使用している場合にのみ機能します。 |
||
![]() |
他のディザリング方法( "しきい値(threshold)" や "順序付きディザ(ordered-dither)" など)とは異なり、"-channel" 設定は色の量子化や誤り訂正ディザには影響しません。基本的には、これらの画像操作がどのように機能するかには場所がありません。 |
|
順序付きディザには、変更の直接のローカル領域への変更を含む、これらの問題はありません。残念ながら、一般的に数学的に派生したカラーセットの使用に限定されています。( "均一なカラーマップを使用した順序付きディザ" を参照してください)。 |
||
|
E-Dithers のもう1つの問題は、そうでなければ色がかなり均一になる領域に時折奇妙な色のピクセルを生成することができることです。たとえば、時折緑色、グレースケール画像内のピクセル。または、以下の例のように、そうでなければ平らな平らな青色の領域における白色のピクセルである。 これは、多数の色を持つオブジェクトや、色の変化しないプレーンなソリッドの他の領域を含む大きな画像に特に当てはまります。これは、図や図面でよく見られるように、平らな色の背景にオーバーレイされた色付きのオブジェクトに特に一般的です。 このような奇妙な色のピクセルは、上記のテスト例の拡大で、小さな単一ピクセルの変更からかなり離れた余分な明るい紫色のピクセルが追加されていることがわかります。しかし、上記に追加された奇数色のピクセルは容易には見えず、カラーマップは画像をかなりうまくカバーしているため、奇数ピクセルは画像のディザリングに使用される通常の3色に合理的に近いです。 より極端な例として、ここではぼやけたグラデーションの背景があり、エラー訂正ディザに本当にストレスを与えるために64色に大幅に色を減らしました。 |
||
#!/usr/bin/bash
convert -size 100x60 xc:SkyBlue \
-fill DodgerBlue -draw 'circle 50,70 15,35' \
-fill RoyalBlue -draw 'circle 50,70 30,45' \
-blur 0x5 -colors 64 speckle_gradient.gif
|
![]() |
|
#!/usr/bin/bash
magick convert -size 100x60 xc:SkyBlue `
-fill DodgerBlue -draw 'circle 50,70 15,35' `
-fill RoyalBlue -draw 'circle 50,70 30,45' `
-blur 0x5 -colors 64 speckle_gradient.gif
|
![]() |
|
|
この大幅に縮小されたカラーマップでわかるように、エラー訂正ディザは元のグラデーションを表現するのに合理的に良い仕事をしました。 しかし、上記に真っ白のパッチを追加すると... |
||
#!/usr/bin/bash
convert -size 100x60 xc:SkyBlue \
-fill DodgerBlue -draw 'circle 50,70 15,35' \
-fill RoyalBlue -draw 'circle 50,70 30,45' -blur 0x5 \
-fill white -draw 'rectangle 40,40 60,55' \
-colors 64 speckle_problem.gif
|
![]() |
|
#!/usr/bin/bash
magick convert -size 100x60 xc:SkyBlue `
-fill DodgerBlue -draw 'circle 50,70 15,35' `
-fill RoyalBlue -draw 'circle 50,70 30,45' -blur 0x5 `
-fill white -draw 'rectangle 40,40 60,55' `
-colors 64 speckle_problem.gif
|
![]() |
|
|
E-ディザリングが突然、以前は何もなかった画像の上部に白いピクセルが散りばめられ始めたことがわかります。 ここでは、これらのピクセルをより明確に見ることができるように、小さなセクションを拡大しています... |
||
#!/usr/bin/bash
convert speckle_problem.gif -crop 15x15+75+0 +repage \
-scale 90x90 speckle_prob_mag.gif
|
![]() |
|
#!/usr/bin/bash
magick convert speckle_problem.gif -crop 15x15+75+0 +repage `
-scale 90x90 speckle_prob_mag.gif
|
![]() |
|
|
奇数色のピクセルは、2 つの要因によって引き起こされます。 まず、カラー量子 化では、単一の純粋な白色(ただし、他の白青アンチエイリアシング色は含まれない)を画像の最終的なカラーマップに含めることを余儀なくされたため、ディザリングプロセスでこの余分な色を使用できるようになりました。 しかし、E-Dithers は、特に上の画像の上部セクションのような極端な色の領域で、ゆっくりと誤差を蓄積します。最終的に、エラーは合計され、1つの追加の色が最も近い一致するのに十分な大きさの値になります。そのため、コントラストの高い白色 ピクセルが「エラーを修正する」ために、擬似ランダムな位置に出力されることがよくあります。 その結果、白いピクセルの非常に軽い斑点が生じます。誤差の蓄積が遅くなるほど、それらの白いピクセルはより広がり、より多くの、場違いに見えます。 最善の解決策は、限られたカラーテーブルを持たない他の画像形式に切り替えることです。たとえば、GIF 形式の画像を PNG に変換します。これにより、色の量子化(縮小)の必要性が回避され、したがって、縮小された色をディザリングする必要がなくなります。 次の解決策は、E-ディザリングの使用を、順序付きディザリングなどのエラーを「ローカライズ」する他の "ディザリング方法" に置き換えることです。 しかし、現時点ではIMに適用するのは簡単なことではありません。より一般的な方法が見つかるまで、そのような方法の1つについては、"より良い順序付けされたディザ結果" を参照してください。 別の画像形式に切り替えるか、別のディザリング方法を使用することが実用的でない場合(そしてしばしば実用的ではない場合)、その特定の画像の状況を修正しようとすることになります。 これに対する最善の修正は、E-Dither エラーの蓄積を引き起こしている大きな色のグループのすぐ外側に他の色があることを確認することです。ただし、通常の "カラー量子化" では、これは行われません。カラーグループを表す平均色のセットを選択する傾向があります。必要なのは、単純な平均色ではなく、大 きなカラーグループのエッジを「ピケットフェンス」する余分な色です。 たとえば、ここでは正方形ではなく円を使用したため、純粋な白色が追加されるだけでなく、多数の白青色も追加されました。これらは、円のエッジのアンチエイリアシングのために自動的に追加され、外観を滑らかにしました。 |
||
#!/usr/bin/bash
convert -size 100x60 xc:SkyBlue \
-fill DodgerBlue -draw 'circle 50,70 15,35' \
-fill RoyalBlue -draw 'circle 50,70 30,45' -blur 0x5 \
-fill white -draw 'circle 50,45 40,40' \
-colors 64 speckle_fixed.gif
|
![]() |
|
#!/usr/bin/bash
magick convert -size 100x60 xc:SkyBlue `
-fill DodgerBlue -draw 'circle 50,70 15,35' `
-fill RoyalBlue -draw 'circle 50,70 30,45' -blur 0x5 `
-fill white -draw 'circle 50,45 40,40' `
-colors 64 speckle_fixed.gif
|
![]() |
|
|
そして、以前と同じ面積の拡大率である。 |
||
#!/usr/bin/bash
convert speckle_fixed.gif -crop 15x15+85+0 +repage \
-scale 90x90 speckle_fix_mag.gif
|
![]() |
|
#!/usr/bin/bash
magick convert speckle_fixed.gif -crop 15x15+85+0 +repage `
-scale 90x90 speckle_fix_mag.gif
|
![]() |
|
|
ご覧のとおり、追加の色は、青 - シアンのグラデーションのすぐ外側に余分な色 を提供します。これらの余分な色は、実際のグラデーションで使用できる色が少ないことを意味しますが、累積誤差が大きくなりすぎる前に、Eディザがより迅速かつ頻繁に修正できるようにする他の青白色を提供します。 これは、Eディザリングの斑点を防止したということではなく、ディザアルゴリズムが動作するより良い色を提供しただけです。画像の拡大部分を調べると、スペックルパターンが引き続き表示されますが、色は背景色に近く、スペックルの広がりがより均一になります。 もう 1 つの方法は、生成された IM に基づいて独自のカラー テーブルを生成し、適切な色を追加してエラーの累積を防ぐことです。しかし、これは、特に3次元の色空間では、簡単なことではありません。 この特定の画像の例では、「斑点」を防ぐ1つの方法は、必要な色をわずかに少なくして背景を別々に生成してディザリングし、白いボックスとその追加の色をオーバーレイすることです。 |
||
#!/usr/bin/bash
convert -size 100x60 xc:SkyBlue \
-fill DodgerBlue -draw 'circle 50,70 15,35' \
-fill RoyalBlue -draw 'circle 50,70 30,45' -blur 0x5 \
-colors 63 \
-fill white -draw 'rectangle 40,40 60,55' speckle_perfect.gif
|
![]() |
|
#!/usr/bin/bash
magick convert -size 100x60 xc:SkyBlue `
-fill DodgerBlue -draw 'circle 50,70 15,35' `
-fill RoyalBlue -draw 'circle 50,70 30,45' -blur 0x5 `
-colors 63 `
-fill white -draw 'rectangle 40,40 60,55' speckle_perfect.gif
|
![]() |
|
|
これにより、画像に「白」の色が追加されますが、エラー訂正ディザを使用したときに白が利用できなかったため、背景には斑点効果はありません。 その結果、正確に64色の画像が作成され、斑点はまったくありません。しかし、これは画像とあなたが達成しようとしているものに大きく依存しているので、スペックング問題に対する一般的な解決策ではありません。 余分な色を追加するより一般的な代替手段は、最終的なディザリングされた画像から斑点を削除しようとすることです。それは何らかの方法で画像をクリーンアップすることです。 しかし、これは、通常のディザリングパターンの一部であるピクセルを削除するものではないため、それ自体がトリッキーな問題です。 私たちが必要とするのは、それを取り巻くすべての色と何らかの形で非常に異なるが、他のすべての同様の色からある程度の距離だけ十分に分離されているカラーピクセルを見つけることです。あなたはより良い画像フィルタソリューションを持っていますか? 概要 私にとって斑点は、特に非常に限られたカラーテーブルを使用するデスクトップアイコン画像の場合、非常に厄介な問題です。私自身は、小さな「アイコン」画像を編集して斑点を削除したり、垂直縞模様などの他のディザリング効果を修正したりすることがよくあります。 あなたが別のより良い解決策を知っているなら、私に知らせてください。 |
||
|
"-monochrome" 演算子は、ビットマップ イメージを生成するための "-colors" 演算子の両方の特殊な形式です。「ヒルベルト曲線ディザリング」だけでなく、色の選択を詳しく見ることも理想的な演算子です。 典型的な例を次に示します。 |
||
#!/usr/bin/bash convert logo.png -monochrome monochrome.gif |
![]() |
|
#!/usr/bin/bash magick convert logo.png -monochrome monochrome.gif |
![]() |
|
|
オペレータは、グレースケールの明るさの「強度」または「レベル」のみに基づいて画像をディザリングしましたが、グレースケール範囲全体を直接ディザリングするのではなく、最も極端な値を最大値にしきい値にします。 これは、IMにグラデーション画像をディザリングするように依頼することで確認できます。
#!/usr/bin/bash
convert -size 15x640 gradient: -rotate 90 \
-monochrome monochrome_gradient.gif
#!/usr/bin/bash
magick convert -size 15x640 gradient: -rotate 90 `
-monochrome monochrome_gradient.gif
|
||
|
ご覧のとおり、グラデーションには、その色の約50%しか "-monochrome" 演算子によってディザリングされていません。IM 作品のこの興味深い事実を指摘してくれた Ivanova<flamingivanova@punkass.com> に特別な感謝を申し上げます。 グレースケール範囲全体を使用してディザリングする場合は、純粋な白黒カラーマップ(組み込みのパターンイメージによって提供される)を使用して "-remap" 演算子を使用できます。 |
||
#!/usr/bin/bash
convert logo.png -remap pattern:gray50 mono_remap.gif
convert -size 15x640 gradient: -rotate 90 \
-remap pattern:gray50 mono_remap_gradient.gif
|
![]() |
|
#!/usr/bin/bash
magick convert logo.png -remap pattern:gray50 mono_remap.gif
magick convert -size 15x640 gradient: -rotate 90 `
-remap pattern:gray50 mono_remap_gradient.gif
|
![]() |
|
|
"-remap" を使用して色をより慎重に選択することで、"-monochrome" 演算子で使用されるのと同じ'しきい値' 範囲、または任意の他のしきい値範囲を効果的に生成できます。 |
||
#!/usr/bin/bash
convert xc:gray20 xc:white +append ctrl_colors.gif
convert logo.png -colorspace Gray \
-remap ctrl_colors.gif -normalize mono_remap_ctrl.gif
convert -size 15x640 gradient: -rotate 90 \
-remap ctrl_colors.gif -normalize mono_remap_grad_ctrl.gif
|
![]() |
|
#!/usr/bin/bash
magick convert xc:gray20 xc:white +append ctrl_colors.gif
magick convert logo.png -colorspace Gray `
-remap ctrl_colors.gif -normalize mono_remap_ctrl.gif
magick convert -size 15x640 gradient: -rotate 90 `
-remap ctrl_colors.gif -normalize mono_remap_grad_ctrl.gif
|
![]() |
|
|
"-monochrome" が実際に行うことは、最初に与えられた画像を最初にグレースケール画像に変換し、その後2色の "カラー量子化" を実行して、画像をディザリングするしきい値色を決定することです。これは、例の次のセクションで探求するものです。 |
||
![]() |
現在、"+dither" 設定は "-monochrome" の結果には影響しません。ただし、これは将来変更される可能性がありますので、この演算子を使用するときは、スクリプトでオフになっていないことを確認してください。 |
|
|
2 つのコントロールの色を自分で選択するのではなく、色の量子化を使用して、"-colors" 演算子を使用して画像内の最適な 2 つの色を選択できます。 |
||
#!/usr/bin/bash
convert logo.png -colors 2 -colorspace gray -normalize \
colors_monochrome.gif
|
![]() |
|
#!/usr/bin/bash
magick convert logo.png -colors 2 -colorspace gray -normalize `
colors_monochrome.gif
|
![]() |
|
|
ただし、最初に画像をグレースケールに変換しなかったため、結果は "-monochrome" を使用したのと同じではありません。 代わりに、選択した2つの非灰色カラー値の間で画像が直接ディザリングされました。これは、2つのグレースケールの輝度レベルではなく、画像をディザリングするために選択される最良の 2 色です。その結果、ほぼ同じグレースケールの「レベル」の色のみを使用する画像に対してより良い結果が得られます。 たとえば、赤と青のグラデーションで "-colors" ビットマップディザリング演算子と "-monochrome" を使用します。あなたができるように、あなたは結果が同じではないことがわかります。
#!/usr/bin/bash
convert -size 20x640 gradient:red-blue -rotate 90 gradient_rb.png
convert gradient_rb.png -colors 2 -colorspace gray \
-normalize colors_threshold.gif
convert gradient_rb.png -monochrome mono_threshold.gif
#!/usr/bin/bash
magick convert -size 20x640 gradient:red-blue -rotate 90 gradient_rb.png
magick convert gradient_rb.png -colors 2 -colorspace gray `
-normalize colors_threshold.gif
magick convert gradient_rb.png -monochrome mono_threshold.gif
|
||
|
上記の "-monochrome" 演算子は、青と赤の両方が非常にほぼ同じ強度であるため、ビットマップディザとの違いを見つけることができませんでした。しかし、"-colors" 量子化方法を使用しても、ディザリングする許容可能な色を見つけることに問題はありませんでした。 また、色の中央部分だけがディザリングされていることがわかります。これは、選択した2つの色の「クラスター」の途中で色を選択する色の量子化によるものです。したがって、選択した色の「外側」の色は、ディザリングなしでその色に直接効果的にしきい値が設定されます。 これは、量子化色空間の外側の色がディザリングされないことを示していますが、この事実を実用的な方法で利用することは困難です。 量子化の前に "-colorspace" をグレースケールに設定することで、"-monochrome" 演算子の内部操作を再現します。 |
||
#!/usr/bin/bash
convert logo.png -colorspace gray -colors 2 -normalize \
monochrome_equivelent.gif
|
![]() |
|
#!/usr/bin/bash
magick convert logo.png -colorspace gray -colors 2 -normalize `
monochrome_equivelent.gif
|
![]() |
|
|
最後に、ディザリングをオフにすることで、固定の "-threshold" 設定を使用して生 成するよりも、画像内の色をより自 動的に分離できます。 |
||
#!/usr/bin/bash
convert logo.png -colorspace gray +dither -colors 2 \
-normalize threshold_two_grays.gif
|
![]() |
|
#!/usr/bin/bash
magick convert logo.png -colorspace gray +dither `
-colors 2 -normalize threshold_two_grays.gif
|
![]() |
|
![]() |
"-monochrome" は現在 "+dither" 設定を無視しているため、その演算子を使用して「スマートしきい値」を実行することはできません。 |
|
画像処理のカラー量子化ステージの "-colorspace" を削除すると、その画像に対して可能な最良の色分解(グレースケールの色分解ではなく)に基づいて画像をしきい値にすることができます。 |
||
#!/usr/bin/bash
convert logo.png +dither -colors 2 \
-colorspace gray -normalize threshold_two_color.gif
|
![]() |
|
#!/usr/bin/bash
magick convert logo.png +dither -colors 2 `
-colorspace gray -normalize threshold_two_color.gif
|
![]() |
|
|
上記のように、 "-colors" は画像を表すのに最適な限られた色のセットを選択しようとします。"-remap" を使用すると、画像に使用する最終的な色のセットを IM に提供します(これらの色をディザリングするか、最も近い色に置き換えるだけか)。 引数は、使用したいすべての色を含む画像として与えられます。色の大きな画像を色のリストだけに減らす場合は、保存する前に "-unique-colors" を使用し、後で "-remap" で使用できるようにします。 |
||
![]() |
"-remap" 演算子は使用する画像を受け入れますが、この画像にはJPEG画像を使用しないでください。そうしないと、余分な色を生成する「非可逆圧縮」のために多くの余分な色が得られることに注意してください。 一方、JPEG を使用して余分な色を生成すると、以前に見た「斑点」の問題を解決するのに役立ちます! |
たとえば、ここでは、IMロゴで使用される色を、名前付きのXウィンドウ色の定義済みマップに制限します。デフォルトは 'Riemersma' ディザですが、IM v6.4.4 以降、"-dither" は 'FloydSteinberg' などの他のディザ メソッドを選択できるように拡張されました。もちろん、 "+dither" オプションを使用してディザリングをオフにすることができます。
#!/usr/bin/bash
convert logo.png -dither None -remap colortable.gif remap_logo_no.gif
convert logo.png -dither Riemersma -remap colortable.gif remap_logo_rm.gif
convert logo.png -dither FloydSteinberg \
-remap colortable.gif remap_logo_fs.gif
#!/usr/bin/bash
magick convert logo.png -dither None -remap colortable.gif remap_logo_no.gif
magick convert logo.png -dither Riemersma -remap colortable.gif remap_logo_rm.gif
magick convert logo.png -dither FloydSteinberg `
-remap colortable.gif remap_logo_fs.gif
|
||
|
ご覧のとおり、IMは指定された色だけを使用して画像を表現する合理的な仕事をしようとしましたが、IM が使用する色セットを選択できるようにした場合、結果は得られる画像ほど良くありません。 この "colortable.gif" 画像は、画像をディザリング用に設計したものではなく、古いより原始的な X ウィンドウカラーディスプレイ用の漫画のようなカラーアイコンを設計するためのカラーセットとして設計されました (詳細については、"Anthony の X ウィンドウアイコンライブラリ" と i"AIcons カラーセレクション" を参照してください)。 また、最終的な画像では、このマップで提供される 32 色すべてが使用されたわけではありませんが、マップ内の色の多くは、何らかの形式のディザリングが有効になっている場合 (および それぞれ)、オフにしたときよりも多く使用されます。 この最後の例は、適切なカラーマップを選択することがいかに重要であるかを示しています。このため、IM に "-colors" 演算子を使用して画像で使用される色の選択を最適化し、そうしない差し迫った理由がない限り、ニーズに合わせて変更することをお勧めします。 最後の1つは、 "-colors" が最適な色のセットを見つける色空間を指定できますが、現在、カラーマッピングまたはディザリングフェーズの色空間を定義することはできません。 私のすべての実験は、RGB 空間に基づいてカラーセット(誤り訂正ディザと最も近い色の置換の両方)が適用されていることを示しているようです。"-quantize" 色空間設定は、色の選択にのみ使用され、マッピングには使用されません。 カラーマップを使用することがそんなに悪い考えなら、なぜあなたはそれを使いたいのですか? 一般的な理由はいくつかありますが、通常は、画像で使用される特定の色のパレットをより詳細に制御する必要があるためです。別のユーザーはまた、カラーマップを分離して、リソグラフ(デジタル印刷システム)で使用できるようにしました。 あなたが私が以下に提示していない "-remap" 演算子を使用する別の理由を知っているなら - 私にメールしてください。 |
||
|
掲載を省略します。本家のページを見て下さい。 |
||
|
WWW が最初に作成されたとき、コンピュータのディスプレイは利用可能な色の範囲が限られており、Web ブラウザは通常、画像に単純な色のセットを使用していました。そのため、画像をこのカラーセットに変更し、両方を小さくし、ユーザーのブラウザで大丈夫に見えるようにするのが一般的でした。詳細については、"Web スタイル ガイド、ディザリング" を参照してください。 この IM を支援するために、"netscape:" と呼ばれる 216 色のこの特別なテーブルの組み込みカラーマップ画像を提供しました。それでは、これらの色を使用して古い Web ブラウザの表示のテストイメージがどのように見えるかを見てみましょう。 #!/usr/bin/bash convert logo.png -remap netscape: remap_netscape.gif convert logo.png +dither -remap netscape: remap_netscape_nd.gif
#!/usr/bin/bash magick convert logo.png -remap netscape: remap_netscape.gif magick convert logo.png +dither -remap netscape: remap_netscape_nd.gif
|
||
|
このカラーセットは、グラフィックアーティストではなくディスプレイやコンピュータのエンジニアによって設計された数学的に決定されたパレットであり、写真などの実際の画像には合理的にうまく機能するほど一般的ですが、ロゴ、背景、グラフなどのコンピュータ生成画像など、色の大きな平らな領域を含む画像には非常に悪いです。 そして漫画のようなイメージ。 基本的にこれは非常に可変色の領域で機能しますが、一定の色の大きなフラット領域では、IMロゴテスト画像(上記)のオフブルーシャツなど、3 色のディザリング(一般的に)が適用されます。 つまり、ウェブで使用する画像やロゴをデザインする場合、通常、このパレットの色を大きな平らな領域に使用し、色の色合いが異なる領域でのみディザリングされた色を使用するようにします。 上記のコマンドを使用すると、画像をテストして、より原始的なコンピュータディスプレイでどのように見えるかを確認し、これらの色を使用するように画像を編集して、うまく動作させることができます。これは、シンボルやナビゲーション画像では特に重要です。 もちろん、今日では、ゲームや Web ユーザーの要求のおかげで、ほとんどのユーザーが古い色 の制限のない最新のコンピュータディスプレイを持っていることをかなり確信できますが、この「Webセーフパレット」の使用は、画像圧縮などの他の利点があるため、まだ存在しています。 現代世界における Web セーフな色の使用に関する議論については、"Web セーフなカラーパレットの死" と、おそらくこのカラーマップを最初に特定したグラフィックデザイナー、"リンダ・ワインマン" によるより重要な見解を参照してください。 |
||
|
掲載を省略します。本家のページを見て下さい。 |
||
|
一般的に使用されるもう1つの均一なカラーマッピングは、「332 RGB カラーマップ」です。数値は、8 ビットのカラーインデックス内で各色を表すために使用 されるビット数を示します。それは赤の 3 ビット(または 8 レベル)、緑のための 3 ビット、青のための 2 ビット(または 4 色レベル)であり、私たちの目が青にうまく反応しないように見えます。これにより、3 + 3 + 2 ビットまたは 8 ビットのカラーインデックス、または 256 色が得られます。限られたGIFカラーテーブルに最適です。ただし、GIFの透明度の色やその他の特殊な使用色のためのスペースは残されません。 IM にこのカラーマップを生成させる方法の1つを次に示します... |
||
#!/usr/bin/bash
convert -size 16x16 xc: -channel R -fx '(i%8)/7' \
-channel G -fx '(j%8)/7' \
-channel B -fx '((i>>3&1)|(j>>2&2))/3' \
-scale 600% colormap_332.png
|
![]() |
|
#!/usr/bin/bash
magick convert -size 16x16 xc: -channel R -fx '(i%8)/7' `
-channel G -fx '(j%8)/7' `
-channel B -fx '((i>>3&1)|(j>>2&2))/3' `
-scale 600% colormap_332.png
|
![]() |
|
![]() |
ビットシフト演算子 '>>' と '<<' は、IM バージョン 6.2.9-2 までは "-fx" 演算子にありませんでした。 |
|
同じことをするより簡単な方法は、操作 "-ordered-dither threshold,8,8,4" を使用して "均一なカラーレベルを使用して順序付きディザ" を使用することです (その例の領域を参照)。上記の "DIYFX メソッド" よりもはるかに簡単で高速なテクニックで、他の組み込みのディザリングマップを使用してグラデーション処理を改善することもできます。 このマップの唯一の欠点は、実際には「灰色」の色をまったく提供しないことです。ただし、わずかな色の違いがグレースケールグラデーションの色境界変更の影響を軽減し、少しだけ見栄えが良くなるため、ディザリングを使用すると、この欠点はプラスになる可能性があります。 |
||
|
掲載を省略します。本家のページを見て下さい。 |
||
|
掲載を省略します。本家のページを見て下さい。 |
||
|
演算子の本来の目的( '2' の引数を使用)は、画像が基本色のみを使用してシンプルで安価なポスター印刷方法を使用して生成されたかのように、わずか8つの基本色を使用して画像を再着色することです。したがって、演算子はその名前を取得します。 "-posterize" 演算子とは、実際には、与えられた色の「レベル」の数に基づいてカラーマップを生成する特殊な減色演算子であり、画像内の各カラーチャンネルについて、誤り訂正ディザリングを用いて画像をディザリングする。 #!/usr/bin/bash convert netscape: -scale 50% +dither -posterize 2 posterize_2_ns.gif convert netscape: -scale 50% +dither -posterize 3 posterize_3_ns.gif convert netscape: -scale 50% +dither -posterize 6 posterize_6_ns.gif
#!/usr/bin/bash magick convert netscape: -scale 50% +dither -posterize 2 posterize_2_ns.gif magick convert netscape: -scale 50% +dither -posterize 3 posterize_3_ns.gif magick convert netscape: -scale 50% +dither -posterize 6 posterize_6_ns.gif
|
||
|
ご覧のとおり、'-posterize' の "2" 引数は、カラーチャンネルごとに 2 色のみを提供することを意味し、上記のような 3 チャンネルの RGB 画像に対してわずか 8 色のマップを生成します。基本的には、8色のしきい値セットを使用して画像の色を変更します。 '3' の引数は、中間調の色を含む 27 色のカラーマップに基づいてイメージの色をマップします。一方、'4' の引数は 64 色のカラーテーブルを生成し、 '5' は 125 色のカラーマップを生成します。もちろん、上記のように、 '6' の引数は、組み込みの "netscape:" イメージで提供されるのと同じ 216 色のセットを再現します。 '0' または '1' の "-posterize" 引数は無意味であり、最新の IM リリースでは画像を純粋な黒に変換するだけです (論理的ではありますが、まったく役に立たないことに注意してください)。 その結果、画像は数学的に派生したカラーマップまたは「均一な」カラーマップを使用して色が変更されました。 これはグラデーション画像でよりはっきりと見ることができ、ポスタライズされたグレーレベルの均一な分布が生成されます。 #!/usr/bin/bash convert -size 20x640 gradient: -rotate 90 gradient.png convert gradient.png +dither -posterize 5 posterize_gradient.gif
#!/usr/bin/bash magick convert -size 20x640 gradient: -rotate 90 gradient.png magick convert gradient.png +dither -posterize 5 posterize_gradient.gif
|
||
たとえば、IMロゴ画像をさまざまなレベルでポスタライズできます...#!/usr/bin/bash convert logo.png +dither -posterize 2 posterize_logo.gif convert logo.png -posterize 2 posterize_logo_dither.gif convert logo.png -posterize 6 posterize_6_logo.gif
#!/usr/bin/bash magick convert logo.png +dither -posterize 2 posterize_logo.gif magick convert logo.png -posterize 2 posterize_logo_dither.gif magick convert logo.png -posterize 6 posterize_6_logo.gif
|
||
より良いテストとして、陰影付きの "カラーホイール(colorwheel.png)" 画像をポーズすることができます。#!/usr/bin/bash convert colorwheel.png +dither -posterize 2 posterize_2_cw.gif convert colorwheel.png +dither -posterize 3 posterize_3_cw.gif convert colorwheel.png +dither -posterize 6 posterize_6_cw.gif
#!/usr/bin/bash magick convert colorwheel.png +dither -posterize 2 posterize_2_cw.gif magick convert colorwheel.png +dither -posterize 3 posterize_3_cw.gif magick convert colorwheel.png +dither -posterize 6 posterize_6_cw.gif
|
||
|
そして、ここでディザリングが有効になっているのと同じことです...
|
||
|
もちろん、次のセクションで説明するビットマップディザの多くは、さまざまな種類のディザスタイルを使用して、レベル2の順序付きディザを生成することもできます。しかし、より多くのグレーレベルを使用できる人はほとんどいません。 IM v6.2.9 の時点で "順序付けられたディザリング" は、統一されたカラーマップを使用したディザリングの現在の制限により、ポスタリゼーション方式でもあります。ただし、ディザパターンは "-posterize" によって生成される擬似ランダム化ディザよりも均一で、スタイルの選択が大きくなります。これらを上記のディザリングされた "-posterize" バージョンと比較してください。 #!/usr/bin/bash convert colorwheel.png -ordered-dither o8x8,2 posterize_2_od.gif convert colorwheel.png -ordered-dither o8x8,3 posterize_3_od.gif convert colorwheel.png -ordered-dither o8x8,6 posterize_6_od.gif
#!/usr/bin/bash magick convert colorwheel.png -ordered-dither o8x8,2 posterize_2_od.gif magick convert colorwheel.png -ordered-dither o8x8,3 posterize_3_od.gif magick convert colorwheel.png -ordered-dither o8x8,6 posterize_6_od.gif
|
||
|
'threshold' ディザマップ(上記で使用した 'o8x8' の代わりに)は、"-ordered-dither" を効果的にディザリングされていないポスタリゼーションメソッドに変換します。 最後に、"順序付きディザ" を使用すると、個々のカラーチャンネルごとに異なる数のカラーレベルを指定できます。"-posterize" 演算子が現在許可していないもの。 |
||
イメージを白黒ビットマップ (カラー) イメージに変換する最も簡単な方法は、"-threshold" を使用することです。これは実際にはカットオフ値を提供するだけの単純な数学演算子です。その値以下のものは黒になり、大きいものは白になります。#!/usr/bin/bash convert logo.png -threshold -1 threshold_0.gif convert logo.png -threshold 25% threshold_25.gif convert logo.png -threshold 50% threshold_50.gif convert logo.png -threshold 75% threshold_75.gif convert logo.png -threshold 100% threshold_100.gif
#!/usr/bin/bash magick convert logo.png -threshold -1 threshold_0.gif magick convert logo.png -threshold 25% threshold_25.gif magick convert logo.png -threshold 50% threshold_50.gif magick convert logo.png -threshold 75% threshold_75.gif magick convert logo.png -threshold 100% threshold_100.gif
|
||
|
ご覧のとおり、値 '-1' はすべての色を白に変換し、'100%' はすべての色を黒に変換します。もちろん、'50%' は最も一般的な値です。 値 '0' は、すべての非純粋な黒色を白に変える特殊なケースです。もちろん、画像に純粋な黒の色がない場合は、白の画像しか得られません! |
||
#!/usr/bin/bash convert logo.png -threshold 0 threshold_black.gif |
![]() |
|
#!/usr/bin/bash magick convert logo.png -threshold 0 threshold_black.gif |
![]() |
|
| 純粋でないすべての白色を実際に黒に変換する場合は、使用する適切なしきい値(IMの現在の「MaxRGB」より1つ小さい値)を計算するのではなく、"ネガティブ" 画像をしきい値設定することをお勧めします。 "品質または 'Q' " 設定での特定のIMのコンパイル時間に依存します。 | ||
#!/usr/bin/bash convert logo.png -negate -threshold 0 -negate threshold_white.gif |
![]() |
|
#!/usr/bin/bash magick convert logo.png -negate -threshold 0 -negate threshold_white.gif |
![]() |
|
|
"-threshold" 演算子は、究極の「コントラスト」演算子として分類でき、しきい値レベルによる色の違いを最大化します。ただし、これはグレースケール演算子であり、"-channel" 設定を使用して、演算子を適用するカラーチャンネルを調整できます。 たとえば、画像の個々のチャンネルのそれぞれをスレッショルドして、ディザリングされていないレベル 2 の "-posterize" 操作と同じ効果を生み出すことができます。 |
||
#!/usr/bin/bash
convert logo.png -channel R -threshold 50% \
-channel G -threshold 50% \
-channel B -threshold 50% \
threshold_posterize.gif
|
![]() |
|
#!/usr/bin/bash
magick convert logo.png -channel R -threshold 50% `
-channel G -threshold 50% `
-channel B -threshold 50% `
threshold_posterize.gif
|
![]() |
|
![]() |
"-threshold" は、画像内の透明度をアルファチャンネルではなくマットチャンネルとして扱います(IM内に内部的に保存されているのと同じように)。このような注意が必要なのは、この演算子をアルファチャネルに適用する場合です。詳しくは、"マットチャンネル" を参照してください。 |
|
より自動化されたしきい値化手法では、前に示した " 2 色の量子化" 手法を使用できます。 たとえば、これは、画像内で見つかった最良の2つの色に基づいて画像をしきい値にします。これらの色は、必ずしもグレースケールまたは反対である必要はなく、画像全体を最もよく表す2つの色だけです。次に、2 つの色が ( "-normalize" を使用して) 純粋な白黒にマップされます。 |
||
#!/usr/bin/bash
convert logo.png +dither -colors 2 \
-colorspace gray -normalize threshold_two_color.gif
|
![]() |
|
#!/usr/bin/bash
magick convert logo.png +dither -colors 2 `
-colorspace gray -normalize threshold_two_color.gif
|
![]() |
|
|
"-random-threshold" 演算子は、ビットマップ イメージ コンバータの特殊な形式です。この場合、非常に単純な「ランダムディザ」を使用して、特定のピクセルが白ピクセルになるか黒ピクセルになるかを判断します。 "-threshold" や "-monochrome" 演算子、あるいは前のセクションのバリエーションとは異なり、選択したチャンネル ( "-channels" で設定) は 1 つのグレースケールチャンネルにマージされず、1 つの単位としてディザリングされません。代わりに、 "-random-threshold" は選択された各チャンネルで互いに完全に独立して動作します。 もちろん、演算子を直接使用すると、ランダムなディザを使用して画像の2レベルのポスタリゼーションが行われます。 |
||
#!/usr/bin/bash
convert logo.png -random-threshold 0x100% \
random_posterize.gif
|
![]() |
|
#!/usr/bin/bash
magick convert logo.png -random-threshold 0x100% `
random_posterize.gif
|
![]() |
|
|
グレースケールに変換すると、画像内のすべてのチャンネルがディザリングされる前にイコライズされます。しかし、各チャンネルは互いに独立してランダムな方法でディザリングされるため、結果は期待どおりのビットマップイメージではありません。代わりに、特に中間調の色の場合、カラーピクセルのスプラッタが得られます。 |
||
#!/usr/bin/bash
convert logo.png -colorspace Gray \
-random-threshold 0x100% random_greyscale.gif
|
![]() |
|
#!/usr/bin/bash
magick convert logo.png -colorspace Gray `
-random-threshold 0x100% random_greyscale.gif
|
![]() |
|
|
適切なランダムなディザリングビットマップイメージを生成する正しい方法は次のとおりです。 |
||
#!/usr/bin/bash
convert logo.png -colorspace Gray -channel B \
-random-threshold 0x100% -separate random_monochome.gif
|
![]() |
|
#!/usr/bin/bash
magick convert logo.png -colorspace Gray -channel B `
-random-threshold 0x100% -separate random_monochome.gif
|
![]() |
|
|
Windows 版 IM v7.1.0 では、では、意図した結果が得られない。 |
||
|
基本的には、グレースケールの画像の1つのチャンネルだけをディザリングし、"-separate" チャンネル演算子を使用してそのチャンネルを最終的なビットマップイメージとして抽出することでした。トリッキーですが効果的です。 この演算子の特別な機能として、IM はビットマップ イメージが '-channels' の特別な "All" オプションで生成されるようにします。 |
||
#!/usr/bin/bash
convert logo.png -channel All \
-random-threshold 0x100% random_all.gif
|
![]() |
|
#!/usr/bin/bash
magick convert logo.png -channel All `
-random-threshold 0x100% random_all.gif
|
![]() |
|
|
Windows 版 IM v7.1.0 では、では、意図した結果が得られない。 |
||
|
ただし、この方法を使用するとアルファチャンネルは無視され、失われるため、通常は推奨されません。私自身は、ソースコードから偶然にこの古代の機能を発見しただけです。 演算子を使用してカラー画像からビットマップを正しく生成する方法がわかったので、引数がディザリングの範囲にどのように影響するかを見 てみましょう。これはまた、このディザが生成するピクセルの「塊」を明確に示 しています。
#!/usr/bin/bash
convert -size 20x640 gradient: -rotate 90 gradient.png
convert gradient.png -channel All \
-random-threshold 0x100% random_grad_0x100.gif
convert gradient.png -channel All \
-random-threshold 10x90% random_grad_10x90.gif
convert gradient.png -channel All \
-random-threshold 25x75% random_grad_25x75.gif
convert gradient.png -channel All \
-random-threshold 50x50% random_grad_50x50.gif
#!/usr/bin/bash
magick convert -size 20x640 gradient: -rotate 90 gradient.png
magick convert gradient.png -channel All `
-random-threshold 0x100% random_grad_0x100.gif
magick convert gradient.png -channel All `
-random-threshold 10x90% random_grad_10x90.gif
magick convert gradient.png -channel All `
-random-threshold 25x75% random_grad_25x75.gif
magick convert gradient.png -channel All `
-random-threshold 50x50% random_grad_50x50.gif
|
||
|
'-random-threshold' を "100%" に設定すると、画像の純粋に 'ランダム ディザ' が生成されます。2 つの境界が同じ値に設定されている場合(または互いに過ぎていても)、純粋な "-threshold" イメージが生成されます。 他の境界セット (通常はパーセンテージを使用して指定) を使用すると、指定された範囲外のビットマップがしきい値になり、指定された範囲内の値に対してランダムなディザ パターンが生成されます。 最良の結果は、"-monochrome" 演算子を使用する場合と同様に、わずかに小さい範囲を使用することで得られます。約 '30x80%' の値で、ほとんどの場合、おそらく最良の結果になります。 |
||
#!/usr/bin/bash
convert logo.png -channel All \
-random-threshold 30x80% random_30x80.gif
|
![]() |
|
#!/usr/bin/bash
magick convert logo.png -channel All `
-random-threshold 30x80% random_30x80.gif
|
![]() |
|
|
Windows 版 IM v7.1.0 では、では、意図した結果が得られない。 |
||
|
もちろん、結果はまだあまり良くありません。しかし、これはあなたが得ることができる最も簡単で最悪の形のディザリングです。 実際に起こるのは、ランダム化されたディザパターンは、滑らかなディザパターンではなく、ピクセルの「塊」を生成する傾向があるということです。これは、乱数発生器の高周波「ノイズ」によるものです。しかし、非常に高い解像度では、ランダムディザは、十 分にランダムであれば、非常に良い結果を生成することが示されています。IM は暗号化レベルのランダム性を使用するため、非常にランダムである可能性が高 くなりますが、このような方法で役立つほど高い解像度で画像が使用されることはめったにありません。 このディザの「修正」の1つは、ランダムな「ブルーノイズ」ジェネレータ(サウンドプロダクションで使用される低周波「ピンクノイズ」フィルタとは対照的に、高周波フィルタ)を使用することです。これにより、ピクセルの凝集が取り除かれますが、デジタルで実装することは非常に困難です。「ブルーノイズランダム化ディザ」の既知の実装は見つかっておらず、これまでに作成された可能性は低いです。 |
||
|
ランダムなディザはピクセルのランダムな塊を生成し、さまざまな誤り訂正ディザは本質的にランダムなドットのパターンを生成しますが、順序付きディザリングは基本的に逆です。これは、可能な限り数学的に決定論的であるように設計されています。決定論的であるため、画像のディザリングに使用するパターンを実際に指定する必要があります。 "-ordered-dither" 演算子は、画像内の選択された各 "-channels" を所定の定義済みパターンにディザリングします。引数は、使用するパターン (しきい値マップと呼ばれます) を定義します。 これらのしきい値マップは、3 つの基本的なスタイルに分類されます。"拡散ピクセルディザー" は、ピクセルが互いにできるだけ離れて配置され、「凝集」およびタイリングアーチファクトを回避する。または、"デジタルハーフトーニング" として知られる技術で、機械的に印刷しやすくするタイトなドットにまとめることもできます。また、これからも見ていく特殊な芸術的なしきい値マップもいくつかあり、独自のディザリング パターンやしきい値マップを設計することさえできます。 いずれの場合も、しきい値マップでオンまたはオフになっているピクセル数は、ビットマップにディザリングされるイメージ (または個々のカラー チャネル) のグレーレベルの強度によって異なります。 マップは一貫した方法でピクセルしきい値レベルを追加するため、ピクセルが特定の「しきい値」でオンになると、明るい灰色でもオンのままになります。この一貫性は非常に重要ですが、そうしないと、ディザパターンの変更の境界に沿ってアーティファクトが生成されます。 これに関する重要な点は、画像内の各ピクセルの結果が、画像内の他のピクセルとは無関係に純粋に数学的に決定されることです。そのため、上記のように、元の画像に小さな変更を加えても、"エラー訂正ディザー" が抱える問題である他の領域の画像にはまったく影響しません。 この点は、ビデオ画像と最適化されたアニメーションの一貫したディザリングに不可欠です。 |
||
|
順序付きディザリングの本来の目的と、順序付きディザリングを使用するときにほとんどのグラフィックプログラマーが期待するものは、より正確には「拡散ピクセル順序付きディザ」と呼ばれることがあります。 つまり、ピクセルはしきい値の強度が増加するにつれてタイル マップに追加されるため、ピクセルは互いに遠く離れ、可能な限り均等に分布します。これにより、非常に滑らかで、現代のほとんどのディスプレイでは見えないように見える、非常に一貫性のあるパターンが生成されます。 このようなパターンは、2 の累乗であるタイル サイズ、つまり 2、4、および 8 のタイル サイズについて考案されています。IM は、3 x 3のしきい値マップ タイルに妥当なしきい値パターンも提供しますが。 IM が現在提供している組み込みの順序付きディザの現在のセットを次に示します。引数は、順序付けられたディザのタイルサイズを反映していることに注意してください。 #!/usr/bin/bash convert logo.png -ordered-dither o2x2 logo_o2x2.gif convert logo.png -ordered-dither o3x3 logo_o3x3.gif convert logo.png -ordered-dither o4x4 logo_o4x4.gif convert logo.png -ordered-dither o8x8 logo_o8x8.gif
#!/usr/bin/bash magick convert logo.png -ordered-dither o2x2 logo_o2x2.gif magick convert logo.png -ordered-dither o3x3 logo_o3x3.gif magick convert logo.png -ordered-dither o4x4 logo_o4x4.gif magick convert logo.png -ordered-dither o8x8 logo_o8x8.gif
|
||
|
タイルサイズを大きくすると、より多くの「カラーレベル」をシミュレートできるだけでなく、特定のレベルでより顕著な欠陥やピクセルの長方形の配列を生成することに注意してください。 |
||
![]() |
'o8x8' 配列ディザリングは、長い間 IM コアコードの一部でしたが、使用されませんでした。 これは、IMExamples がこの演算子の使用法の詳細を説明し始めたときに "-ordered-dither" 演算子 IM v6.2.9 のオプションとしてのみ追加されました。 この時点で、マップにはより明確な名前が付けられ、"-ordered-dither" 演算子をさらに拡張できるようになりました。ただし、古い下位互換性のある「タイルサイズ」の名前は、新しい名前のエイリアスとして保持されていました。 また、'o3x3' と 'o4x4' を生成した「マップ」は、より優れた「拡散ピクセル」ディザパターンを生成するように完全に改訂されました。 これ以前は、マップはピクセルの明確な「塊」を生成していました。 修正される前の古いパターンの例、および IM v6.3.0 でのアップグレードの公式リリースの開発中に行われたその他の変更については、"配列ディザリングのアップグレードに関する注意事項" ページを参照してください。 |
もちろん、画像内のすべてのチャンネルの適切なビットマップを生成するには、最初に画像をグレースケールに変換する必要がありますが、プロセスはランダムではないため、"-random-threshold" 演算子で必要なように画像を後処理する必要はありません物事を非常に単純化します。#!/usr/bin/bash convert logo.png -colorspace Gray -ordered-dither o2x2 logo_bw_o2x2.gif convert logo.png -colorspace Gray -ordered-dither o3x3 logo_bw_o3x3.gif convert logo.png -colorspace Gray -ordered-dither o4x4 logo_bw_o4x4.gif convert logo.png -colorspace Gray -ordered-dither o8x8 logo_bw_o8x8.gif
#!/usr/bin/bash magick convert logo.png -colorspace Gray -ordered-dither o2x2 logo_bw_o2x2.gif magick convert logo.png -colorspace Gray -ordered-dither o3x3 logo_bw_o3x3.gif magick convert logo.png -colorspace Gray -ordered-dither o4x4 logo_bw_o4x4.gif magick convert logo.png -colorspace Gray -ordered-dither o8x8 logo_bw_o8x8.gif
|
||
ここでの参考として、グレースケールグラデーションに適用される "-ordered-dither" 「拡散ピクセル」パターンのそれぞれがあるので、それらがどのように見えるかを明確に見ることができます。#!/usr/bin/bash # Threshold Non-Dither / Minimal Checkerboard Dither convert gradient.png -ordered-dither threshold od_threshold.gif convert gradient.png -ordered-dither checks od_checks.gif # Diffused Pixel Dither convert gradient.png -ordered-dither o2x2 od_o2x2.gif convert gradient.png -ordered-dither o3x3 od_o3x3.gif convert gradient.png -ordered-dither o4x4 od_o4x4.gif convert gradient.png -ordered-dither o8x8 od_o8x8.gif
![]() ![]() ![]() ![]() #!/usr/bin/bash # Threshold Non-Dither / Minimal Checkerboard Dither magick convert gradient.png -ordered-dither threshold od_threshold.gif magick convert gradient.png -ordered-dither checks od_checks.gif # Diffused Pixel Dither magick convert gradient.png -ordered-dither o2x2 od_o2x2.gif magick convert gradient.png -ordered-dither o3x3 od_o3x3.gif magick convert gradient.png -ordered-dither o4x4 od_o4x4.gif magick convert gradient.png -ordered-dither o8x8 od_o8x8.gif
![]() ![]() ![]() ![]() |
||
|
特定の配列ディザリングによって生成される有効または疑似レベルのパターンの数は、通常(常にではありませんが)パターンのピクセル数に 1 を加えたものに等しくなります。 そのため、'o3x3' 配列ディザリングは、結果の画像でチャネルごとに 3 x 3 + 1 または 10 の有効なグレーレベル(黒、白、および 8 つの人工グレーパターン)を生成します。 上記には、2 つの特別な最小ディザしきい値マップも示されています。
|
||
|
IM v6.2.8-6 では、デジタルハーフトーンディザパターンのセットで "-ordered-dither" が拡張されました (Glenn Randers-Pehrson に感謝します)。これらは全て、単純な 45 度のドットパターンを生成するように設定した。IM v6.3.0 では、これは同様の大きなアングルなしハーフトーンのセットでさらに拡張されました。 |
||
![]() |
IM v6.3.0 のリリース前は、ハーフトーン画面は '{number}x1' という形式の引数を使用して選択されていました。"Ordered Dither の再開発" により、この制限は解除され、より良い名前が選択され、余分なハーフトーンスクリーン(直交形式)が追加されました(下記の引数例を参照)。 |
|
デジタルハーフトーンは厳密には真のハーフトーンスクリーンではなく、紙、厚紙、さらには金属などの媒体に機械的に堆積したインクの丸いドットを処理するように設計されています。このようなドットは、印刷プロセス中に重なり合って汚れる可能性があるため、非線形レベルの調整が必要です。これは、純粋にデジタルハーフトーンエフェクトを生成するためには必要ありません。このプロセスの詳細については、"ドキュメント「ディザリングとハーフトーン (PDF)" を参照してください。 つまり、"Ordered Dither" デジタルハーフトーンパターンは、新聞や安価に印刷された雑誌で見られるのと同じ基本的な効果を提供します。 #!/usr/bin/bash # Halftone Screen (45 degree angle) convert logo.png -ordered-dither h4x4a logo_h4x4a.gif convert logo.png -ordered-dither h6x6a logo_h6x6a.gif convert logo.png -ordered-dither h8x8a logo_h8x8a.gif # Halftone Screen (orthogonal) convert logo.png -ordered-dither h4x4o logo_h4x4o.gif convert logo.png -ordered-dither h6x6o logo_h6x6o.gif convert logo.png -ordered-dither h8x8o logo_h8x8o.gif
#!/usr/bin/bash # Halftone Screen (45 degree angle) magick convert logo.png -ordered-dither h4x4a logo_h4x4a.gif magick convert logo.png -ordered-dither h6x6a logo_h6x6a.gif magick convert logo.png -ordered-dither h8x8a logo_h8x8a.gif # Halftone Screen (orthogonal) magick convert logo.png -ordered-dither h4x4o logo_h4x4o.gif magick convert logo.png -ordered-dither h6x6o logo_h6x6o.gif magick convert logo.png -ordered-dither h8x8o logo_h8x8o.gif
|
||
ここでも "-colorspace" 演算子を使用して、イメージの真のビットマップディザを生成します。#!/usr/bin/bash # Halftone Screen (45 degree angle) convert logo.png -colorspace Gray -ordered-dither h4x4a logo_bw_h4x4a.gif convert logo.png -colorspace Gray -ordered-dither h6x6a logo_bw_h6x6a.gif convert logo.png -colorspace Gray -ordered-dither h8x8a logo_bw_h8x8a.gif # Halftone Screen (orthogonal) convert logo.png -colorspace Gray -ordered-dither h4x4o logo_bw_h4x4o.gif convert logo.png -colorspace Gray -ordered-dither h6x6o logo_bw_h6x6o.gif convert logo.png -colorspace Gray -ordered-dither h8x8o logo_bw_h8x8o.gif
#!/usr/bin/bash # Halftone Screen (45 degree angle) magick convert logo.png -colorspace Gray -ordered-dither h4x4a logo_bw_h4x4a.gif magick convert logo.png -colorspace Gray -ordered-dither h6x6a logo_bw_h6x6a.gif magick convert logo.png -colorspace Gray -ordered-dither h8x8a logo_bw_h8x8a.gif # Halftone Screen (orthogonal) magick convert logo.png -colorspace Gray -ordered-dither h4x4o logo_bw_h4x4o.gif magick convert logo.png -colorspace Gray -ordered-dither h6x6o logo_bw_h6x6o.gif magick convert logo.png -colorspace Gray -ordered-dither h8x8o logo_bw_h8x8o.gif
|
||
最後に、ハーフトーンディザパターンと、グレーレベルの変化に応じてディザパターン内のピクセルがどのように互いに成長するかを明確に示す別のグラデーション参照画像。#!/usr/bin/bash # Halftone Screen (45 degree angle) convert gradient.png -ordered-dither h4x4a od_h4x4a.gif convert gradient.png -ordered-dither h6x6a od_h6x6a.gif convert gradient.png -ordered-dither h8x8a od_h8x8a.gif # Halftone Screen (orthogonal) convert gradient.png -ordered-dither h4x4o od_h4x4o.gif convert gradient.png -ordered-dither h6x6o od_h6x6o.gif convert gradient.png -ordered-dither h8x8o od_h8x8o.gif convert gradient.png -ordered-dither h16x16o od_h16x16o.gif # Circle Halftones (black and white) convert gradient.png -ordered-dither c7x7b od_c7x7b.gif convert gradient.png -ordered-dither c7x7w od_c7x7w.gif
![]() ![]() ![]() ![]() ![]() ![]() #!/usr/bin/bash # Halftone Screen (45 degree angle) magick convert gradient.png -ordered-dither h4x4a od_h4x4a.gif magick convert gradient.png -ordered-dither h6x6a od_h6x6a.gif magick convert gradient.png -ordered-dither h8x8a od_h8x8a.gif # Halftone Screen (orthogonal) magick convert gradient.png -ordered-dither h4x4o od_h4x4o.gif magick convert gradient.png -ordered-dither h6x6o od_h6x6o.gif magick convert gradient.png -ordered-dither h8x8o od_h8x8o.gif magick convert gradient.png -ordered-dither h16x16o od_h16x16o.gif # Circle Halftones (black and white) magick convert gradient.png -ordered-dither c7x7b od_c7x7b.gif magick convert gradient.png -ordered-dither c7x7w od_c7x7w.gif
![]() ![]() ![]() ![]() ![]() ![]() |
||
|
ImageMagick バージョン 6.2.9 までは、上記のしきい値の順序付けられたディザマップはすべて、IM で可能なすべてでした。これは現在変更されており、ユーザーは独自のパターンを追加したり、IMコミュニティに貢献したりすることもできます。 「サークル」ハーフトーンしきい値は、Glenn Randers-Pehrson,IM v6.6.5-6 によって追加されました。 |
||
|
上記のハーフトーンディザの唯一の問題は、まったく同じしきい値マップ(タイル)がすべてのカラーチャンネルに同じ方法で適用されることです。つまり、同じ原色のセットが同じ「中心」を持つドットに配置されます。 「オフセット印刷」として知られているものを得るために、しきい値パターンは特定のパターンで回転され、色は小さなスケールの「ロゼットパターン」を形成し、そうでなければ開発できるより恐ろしい干渉(モアレ)パターンを破壊します。 この図は基本的にプロセスを説明しており、ウィキペディアのページ、"ハーフトーン" で非常に詳細に説明されています。
ここでは、小さな回転 2x2 ピクセルのチェッカーボードパターンを使用して、画像にオフセットハーフトーン印刷の外観を与える 1 つの方法があります。 |
||
#!/usr/bin/bash
convert colorwheel.png \
-set option:distort:viewport '%wx%h+0+0' \
-colorspace CMYK -separate null: \
\( -size 2x2 xc: \( +clone -negate \) \
+append \( +clone -negate \) -append \) \
-virtual-pixel tile -filter gaussian \
\( +clone -distort SRT 60 \) +swap \
\( +clone -distort SRT 30 \) +swap \
\( +clone -distort SRT 45 \) +swap \
\( +clone -distort SRT 0 \) +swap +delete \
-compose Overlay -layers composite \
-set colorspace CMYK -combine -colorspace RGB \
offset_colorwheel.png
|
![]() |
|
#!/usr/bin/bash
magick convert colorwheel.png `
-set option:distort:viewport '%wx%h+0+0' `
-colorspace CMYK -separate null: `
`( -size 2x2 xc: `( +clone -negate `) `
+append `( +clone -negate `) -append `) `
-virtual-pixel tile -filter gaussian `
`( +clone -distort SRT 60 `) +swap `
`( +clone -distort SRT 30 `) +swap `
`( +clone -distort SRT 45 `) +swap `
`( +clone -distort SRT 0 `) +swap +delete `
-compose Overlay -layers composite `
-set colorspace CMYK -combine -colorspace RGB `
offset_colorwheel.png
|
![]() |
|
|
4 つの回転した「スクリーン」が画像全体に適用されることに注意してください、それは実際にスクリーンされた画像から4つの異なるカラーチャンネルを抽出するのはCMYK色空間の "-combine" ステップだけです。 また、最後の「黒」チャンネルの「ノーオペレーション」歪みは、画面自体が回転していないにもかかわらず、回転中に他のチャンネルで使用されたガウスフィルタに従って入力チェッカーパターンをぼかすため重要です。 そしてここでは、回転したタイルを生成するために使用される "SRT Distort" のスケーリング機能を使用して、わずかに大きくてぼやけた「画面パターン」を作成します。
#!/usr/bin/bash
convert parrots_med.png \
-set option:distort:viewport '%wx%h+0+0' \
-colorspace CMYK -separate null: \
\( -size 2x2 xc: \( +clone -negate \) \
+append \( +clone -negate \) -append \) \
-virtual-pixel tile -filter gaussian \
\( +clone -distort SRT 2,60 \) +swap \
\( +clone -distort SRT 2,30 \) +swap \
\( +clone -distort SRT 2,45 \) +swap \
\( +clone -distort SRT 2,0 -blur 0x0.7 \) +swap +delete \
-compose Overlay -layers composite \
-set colorspace CMYK -combine -colorspace RGB \
offset_parrots.png
#!/usr/bin/bash
magick convert parrots_med.png `
-set option:distort:viewport '%wx%h+0+0' `
-colorspace CMYK -separate null: `
`( -size 2x2 xc: `( +clone -negate `) `
+append `( +clone -negate `) -append `) `
-virtual-pixel tile -filter gaussian `
`( +clone -distort SRT 2,60 `) +swap `
`( +clone -distort SRT 2,30 `) +swap `
`( +clone -distort SRT 2,45 `) +swap `
`( +clone -distort SRT 2,0 -blur 0x0.7 `) +swap +delete `
-compose Overlay -layers composite `
-set colorspace CMYK -combine -colorspace RGB `
offset_parrots.png
|
||
|
パターンは非常に「正方形のような」ままであり、特に他のすべてのものが由来する黒い画面であることに注意してください。 将来の提案可能性:上記の2ピクセルのチェックボードを「pattern:gray50」ピクセルレベルのチェッカーボードパターンに置き換えます。 ガウスフィルターオプションを使用して、スケーリングされたパターンのぼやけ具合を調整できます。または、パターンをぼかし拡大縮小してしきい値を設定して、丸いドットを作成することもできます。これを以前と同じように回転させて、4つのカラースクリーンを作成できます。 また、上記で使用したチェッカーボードパターンではなく、六角形のドットのパターンを使用した大きな画面を使用する方が良いでしょう。 これは実際には真のオフセット印刷のようなカラードットを生成するのではなく、カラースクリーンを元の画像に掛け合わせるだけで偽造していることに注意することが重要です。これは、緑色の背景に対する赤いオウムのエッジに沿った鋭い色の変化のために当てはまることがわかります。純粋な色のドットのみを使用した真のオフセット印刷では、ドットカラーの途中で変更されることはありません。ソース画像内のドットによって再生されたその領域の色の平均に応じて、純粋な色のドットのサイズを変更する必要があります。 適切なサイズの各カラーチャンネルに丸いドットのみを含む真のオフセット印刷画像を実際に生成するには、さらに多くの作業が必要になります。各カラーチャンネルにおける各ドットにおける平均色が決定されることになり、そこから適切な大きさの着色ドット(アンチエイリアス円)が生成される。誰もがそれを試してみたいですか? 上記は、IMフォーラムの議論 "CMYK ハーフトーンエフェクト" での議論からのもので、フォトショップがどのように「それを偽造する」のか、そしてImageMagickが同じ効果をどのように達成できるかを調べました。 この議論は、適切なサイズの実際のドットを使用して真のハーフトーンスクリーンを生成することを詳しく見ていく "B / Wハーフトーンディザ" にも関連しています。しかし、その議論はオフセット(回転)画面を使用する次のステップには至りませんでした。このような画面では、おそらく画像を回転させてドットを生成し、その特定のカラーチャンネルに対してドットパターンを再び回転させる必要があります。 |
||
|
IM バージョン 6.3.0 以降では、IM のソース コード (前述のとおり) に組み込まれた固定マップ セットを使用するのではなく、マップがプログラム自体の外部にある一連の XML データ ファイルから読み込まれるようになりました。 この変更の一環として、"-ordered-dither" 演算子が使用できる使用可能な 'しきい値マップ' を一覧表示できるようになりました。 #!/usr/bin/bash identify -list threshold Threshold Maps for Ordered Dither Operations Path: /etc/ImageMagick-6/thresholds.xml Map Alias Description ---------------------------------------------------- threshold 1x1 Threshold 1x1 (non-dither) checks 2x1 Checkerboard 2x1 (dither) o2x2 2x2 Ordered 2x2 (dispersed) o3x3 3x3 Ordered 3x3 (dispersed) o4x4 4x4 Ordered 4x4 (dispersed) o8x8 8x8 Ordered 8x8 (dispersed) h4x4a 4x1 Halftone 4x4 (angled) h6x6a 6x1 Halftone 6x6 (angled) h8x8a 8x1 Halftone 8x8 (angled) h4x4o Halftone 4x4 (orthogonal) h6x6o Halftone 6x6 (orthogonal) h8x8o Halftone 8x8 (orthogonal) h16x16o Halftone 16x16 (orthogonal) c5x5b c5x5 Circles 5x5 (black) c5x5w Circles 5x5 (white) c6x6b c6x6 Circles 6x6 (black) c6x6w Circles 6x6 (white) c7x7b c7x7 Circles 7x7 (black) c7x7w Circles 7x7 (white) #!/usr/bin/bash magick identify -list threshold Threshold Maps for Ordered Dither Operations Path: C:\Program Files\ImageMagick-7.1.0-Q16\thresholds.xml Map Alias Description ---------------------------------------------------- threshold 1x1 Threshold 1x1 (non-dither) checks 2x1 Checkerboard 2x1 (dither) o2x2 2x2 Ordered 2x2 (dispersed) o3x3 3x3 Ordered 3x3 (dispersed) o4x4 4x4 Ordered 4x4 (dispersed) o8x8 8x8 Ordered 8x8 (dispersed) h4x4a 4x1 Halftone 4x4 (angled) h6x6a 6x1 Halftone 6x6 (angled) h8x8a 8x1 Halftone 8x8 (angled) h4x4o Halftone 4x4 (orthogonal) h6x6o Halftone 6x6 (orthogonal) h8x8o Halftone 8x8 (orthogonal) h16x16o Halftone 16x16 (orthogonal) c5x5b c5x5 Circles 5x5 (black) c5x5w Circles 5x5 (white) c6x6b c6x6 Circles 6x6 (black) c6x6w Circles 6x6 (white) c7x7b c7x7 Circles 7x7 (black) c7x7w Circles 7x7 (white) |
||
|
上記のリストは、使用可能なしきい値マップだけでなく、下位互換性や代替命名のために提供された別名、および私自身の個人的な "thresholds.xml" XML データファイル (自宅(home)の ".magick" サブディレクトリに保存) で定義されているエイリアスも示しています。 "-ordered-dither" がマップを探しているときは、上記のリストで最初に見つかったマップが使用 されます。そのため、システム定義のしきい値パターンをオーバーライドすることはできません。 システムファイル "thresholds.xml" (上記の "-list" オプションでパスが指定されます) には、XML ファイルのフォーマットの完全な要約が含まれています。ユーザーが独自の順序付きディザしきい値マップを定義および作成できるほど単純な形式 (IM によるエラー チェックを含む)。 たとえば、ここに私の個人的な "threshold.xml" ファイルで定義した 'diag5x5' しきい値マップのコピーがあります。
<threshold map="diag5x5" alias="diag">
<description>Simple Diagonal Line Dither</description>
<levels width="5" height="5" divisor="6">
4 2 1 3 5
2 1 3 5 4
1 3 5 4 2
3 5 4 2 1
5 4 2 1 3
</levels>
</threshold>
あなたが見れば、それはしきい値レベルが上がるにつれて太くなる単一の対角線の単純な5x5マップを作成します。マップ内のレベル番号は 0 から 5 までで、カラーグラデーションを分割するために必要な「グレー」の数を宣言する除数より 1 つ小さくなります。この個人的なしきい値マップを使用してディザリングされたグラデーションを次に示します。 #!/usr/bin/bash convert gradient.png -ordered-dither diag od_diag.gif
#!/usr/bin/bash magick convert gradient.png -ordered-dither diag od_diag.gif
|
||
そして、このしきい値を使用して、単純な影付き画像のアルファチャンネルをディザリングする例を次に示します。
#!/usr/bin/bash
convert -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'" shadow.png
convert shadow.png -channel A -ordered-dither diag shadow_diag.gif
#!/usr/bin/bash
magick convert -size 70x60 xc:none -font Forte -pointsize 50 `
-fill black -annotate +10+45 'A' -channel RGBA -blur 0x5 `
-fill white -stroke black -draw "text 5,40 'A'" shadow.png
magick convert shadow.png -channel A -ordered-dither diag shadow_diag.gif
|
||
|
かなりクールねえ! アルファチャンネルのディザリングについては、後で詳しく説明します。まず、拡張された "i-ordered-dither" 演算子の色付け機能を使用する方法も示す必要があります。 |
||
|
IM v6.3.0 のリリースでは、"-ordered-dither" で使用されるしきい値マップが外部ファイルから読み取られるように変更されただけでなく、数学的に定義された「ポスタライズされた」カラーマップを使用できるように内部操作が強化されました。 つまり、「エラー訂正ディザリング」よりも決定論的な画像のディザリングを生成できます。これは、フレーム間の色の違いから問題が発生しないため、アニメーションを含むカラーリダクションでは特に重要です。 ポスタリゼーション・レベルは、使用するしきい値マップの名前に付加された数字のコンマ区切りリストを使用して、"-ordered-dither" 引数に渡されます。数値が指定されていない場合、オペレータは通常の 2色 (またはポスタリゼーション レベル 1) カラー マップにフォールバックします。 たとえば、'checks,6' の引数は、古典的な "Web セーフカラーマップ" (ポスタリゼーションレベル 6 )カラーマップ( "netscape:" 組み込みカラーマップイメージによっても定義されます)を使用します。ただし、'checks' の最小ディザマップが使用されると、6 つのカラー レベルのそれぞれの間に 1 つの追加レベルのディザリングが追加され、画像の各チャンネルに 11 の擬似レベルの色が作成されます。 つまり、チャンネルごとに6レベルのカラーしか使用されていない(6 ^ 3または216色を生成する)場合でも、レベル間の単一のディザパターンはディザを 11 レベルに増加させ、効果的な 11 レベル( 11 ^ 3 または1331色を生成する)にします。 たとえば、6 つのグレーレベルとさまざまなしきい値マップを使用してディザリングされたグレースケールのグラデーションを次に示します。最初のマップ 'threshold' は、特殊な非ディザリング順序ディザしきい値マップで、使用されている色のみを表示します。 #!/usr/bin/bash convert gradient.png -ordered-dither threshold,6 od_threshold_6.gif convert gradient.png -ordered-dither checks,6 od_checks_6.gif convert gradient.png -ordered-dither o2x2,6 od_o2x2_6.gif convert gradient.png -ordered-dither o4x4,6 od_o4x4_6.gif convert gradient.png -ordered-dither o8x8,6 od_o8x8_6.gif
#!/usr/bin/bash magick convert gradient.png -ordered-dither threshold,6 od_threshold_6.gif magick convert gradient.png -ordered-dither checks,6 od_checks_6.gif magick convert gradient.png -ordered-dither o2x2,6 od_o2x2_6.gif magick convert gradient.png -ordered-dither o4x4,6 od_o4x4_6.gif magick convert gradient.png -ordered-dither o8x8,6 od_o8x8_6.gif
|
||
|
ご覧のとおり、6 色しか使用されていませんが、順序付けされたディザリングを使用すると、グラデーションの定義に使用される色の有効数が増え、実際に使用 された色がどれほど少ないかに気付くのが難しいほどです! すべてのチャンネルのポスタリゼーションレベル数を定義できるだけでなく、"-posterize" エラー訂正ディザオプションとは異なり、各チャンネルのレベルを指定できます。番号は "-channels" 設定に従ってチャンネルに割り当てられます。 たとえば、ここでは、合計 256 色を定義する特別な 332 カラーマップ( 8 レベルまたは赤と緑、青の 4 )を使用してグラデーションをディザリングしました。 #!/usr/bin/bash convert gradient.png -ordered-dither o8x8,8,8,4 od_o8x8_884.gif
#!/usr/bin/bash magick convert gradient.png -ordered-dither o8x8,8,8,4 od_o8x8_884.gif
|
||
|
チャンネルごとにカラーレベルの数が異なるため、上記の画像には純粋なグレーの色だけでなく、青みがかったピクセルと黄色がかったピクセルが含まれており、互いに相殺して余分なレベルのグレーが生成されます。 次に、ポスタリゼーションレベル2と6、および「 332 カラーマップ」(赤と緑の8レベル、青の4レベル)を使用して、"O ディザリング" バージョンとエラー訂正ディザリングバージョンを比較します。 #!/usr/bin/bash convert logo.png -ordered-dither o8x8 logo_o8x8_2.gif convert logo.png -posterize 2 logo_posterize_2.gif convert logo.png -ordered-dither o8x8,6 logo_o8x8_6.gif convert logo.png -posterize 6 logo_posterize_6.gif convert logo.png -ordered-dither o8x8,8,8,4 logo_o8x8_332.gif convert logo.png -remap colormap_332.png logo_remap_332.gif
#!/usr/bin/bash magick convert logo.png -ordered-dither o8x8 logo_o8x8_2.gif magick convert logo.png -posterize 2 logo_posterize_2.gif magick convert logo.png -ordered-dither o8x8,6 logo_o8x8_6.gif magick convert logo.png -posterize 6 logo_posterize_6.gif magick convert logo.png -ordered-dither o8x8,8,8,4 logo_o8x8_332.gif magick convert logo.png -remap colormap_332.png logo_remap_332.gif
|
||
|
上記の各ペアの最初の画像は数学的に順序付けられたディザリングされ、2 番目 の画像は擬似ランダムに「エラー訂正」ディザリングされています。 最後のペアは特別な '332 カラーマップ' ( "カラーマップの生成" を参照) を使用しており、これはおそらく 256 色制限の一般的な画像に最適なポスタリゼーションカラーマップと見なされています。チャンネルレベルの奇妙な違いは、この漫画のような画像の色のわずかに良いシェーディングを生成します。 「 332 カラーマップ」を生産できるようにするために、"-ordered-dither" 演算子には、カラーチャンネルごとに別々のレベルを指定する機能が含まれていました。 |
||
先ほど生成したレベル 6 の "O-Dither" を詳しく見てみましょう。#!/usr/bin/bash convert logo.png -ordered-dither o8x8,6 -format %k info: 61 #!/usr/bin/bash magick convert logo.png -ordered-dither o8x8,6 -format %k info: 61 |
||
|
この画像でわかるように、GIF カラーテーブル( 256 の制限)を埋めることさえできませんでした。基本的に、画像は一般的に主に青色で構成されているため、レベル6の均一なカラーマップからの赤または緑の色の色合いもほとんど使用されていませんでした。 ただし、ポスタリゼーションレベルの数を増やすことで、GIF カラーテーブルをよりよく塗りつぶして、より良い "O ディザリング" 画像を生成することができます。 #!/usr/bin/bash convert logo.png -ordered-dither o8x8,13 -format %k info: 212 #!/usr/bin/bash magick convert logo.png -ordered-dither o8x8,13 -format %k info: 212 |
||
|
これにより、GIF カラーテーブルの制限よりわずかに小さくなるのに十分な色が生成されます。色の数が増えると、結果は単純な標準の均一なカラーマップの結果よりもはるかに良く見えます。 |
||
#!/usr/bin/bash convert logo.png -ordered-dither o8x8,13 logo_o8x8_13.gif |
![]() |
|
#!/usr/bin/bash magick convert logo.png -ordered-dither o8x8,13 logo_o8x8_13.gif |
![]() |
|
|
高い「レベル」値でわかるように、"-ordered-dither" は、色の量子化とエラー訂正ディザによって生成された特定の色の選択に匹敵する色の量子化に匹敵する画像を生成することができます。 これらの画像の主なポイントは、それらが高品質であるということではありません。結局のところ、"フルカラー量子化" は、画像のより良いカラーマップをより簡単に生成できます。しかし、画像内の低レベルのディザパターンは、発生する可能性のある小さな変更に関係なく固定されています。領域の変更のみが、順序付けられたディザリングイメージで変更されます。 つまり、GIFアニメーションの "フレーム最適化" に問題を引き起こす変更に対する "E ディザ感度" がありません。( "最適化問題" を参照) もちろん、アニメーションの場合は、実際に使用されている色の数を確認する前に、すべての画像を一緒に "-append" する必要があります。また、すでに減色とディザリングを実行していても、IMにすべての画像に対して「共通のグローバルカラーマップ」を生成するように強制するには、"+remap" を使用した後に特別な "-ordered-dither" オプションを使用する必要があります。 カラーレベルの数を決定するこの方法は、決定するのは簡単ではありませんが、機能します。私は、特にGIFアニメーションのために、IMが自動的に最高のレベルを決定する方法を考え出したいと考えています。 |
||
|
前に、新しい "-ordered-dithe" 演算子がユーザー定義のディザリング パターンを受け入れることができることを示しました。ここでは、独自のディザパターンを作成する方法を紹介します。具体的には、水平線からなる影を生成するのに便利な特別なパターンです。 |
||
|
最初に行う必要があるのは、作成するパターンを定義する一連のイメージを作成することです。パターンは、最初の画像(すべてのピクセルがオフ)として適切なサイズの黒の実画像から始まり、もう一方の端に白の実線の画像(すべてのピクセルがオン)で始まります。 次の画像は、中央の 50% グレーパターンで、達成しようとしているディザリングの基本的なスタイルを定義する必要があります。 たとえば、これが私の最初の DIY ディザパターンです。マルチイメージ GIF ファイル(GIF アニメーションではない)に保存します...
#!/usr/bin/bash
convert -size 2x2 xc:black \
\( +clone -draw 'fill white line 0,0 1,0' \) \
xc:white dpat_hlines2x2.gif
montage dpat_hlines2x2.gif -tile x1 -background none -frame 2 \
-filter box -geometry 32x32+5+0 dpat_hlines2x2_imgs.gif
#!/usr/bin/bash
magick convert -size 2x2 xc:black `
`( +clone -draw 'fill white line 0,0 1,0' `) `
xc:white dpat_hlines2x2.gif
magick montage dpat_hlines2x2.gif -tile x1 -background none -frame 2 `
-filter box -geometry 32x32+5+0 dpat_hlines2x2_imgs.gif
|
||
|
これは、取得できる最も単純なディザパターン画像のセットに関するもので、「チェック」または「チェッカーボードディザ」と非常によく似ていますが、チェッカーパターンではなく水平線があります。 このディザリングパターンがどのように見えるかを見ることができますが、ここでは、しきい値ディザリング画像セットを直接使用する、かなり単純なDIY順序付きディザリングです。
#!/usr/bin/bash
convert gradient.png dpat_hlines2x2.gif \
-virtual-pixel tile -fx 'u[floor((n-1)*u)+1]' dgrad_hlines2x2.gif
convert: no such image `u[floor((n-1.0*1)*u)+1]' @ error/fx.c/FxGetSymbol/1446.
#!/usr/bin/bash
magick convert gradient.png dpat_hlines2x2.gif `
-virtual-pixel tile -fx 'u[floor((n-1)*u)+1]' dgrad_hlines2x2.gif
|
||
|
ご覧のとおり、ディザパターンは空想的なものではありません。"-fx" 関数は、カラー ルックアップ テーブル関数のバリエーション、つまり "IM ディザ ルックアップ" パターンの型関数です。また、 'tile' の "-virtual-pixel" 設定では、関数は使用しているディザパターン画像のサイズを知る必要さえありません。 |
||
![]() |
このような計算されたインデックスを使用する "-fx" 演算子による "-virtual-pixel" の使用は、IM バージョン 6.2.9-2 より前には壊れていました。 |
このディザパターンセットをもう一度試してみましょうが、単純な影付きの画像を使用してください...
#!/usr/bin/bash
convert shadow.png dpat_hlines2x2.gif -channel A \
-virtual-pixel tile -fx 'u[floor((n-1)*u)+1].g' \
shadow_dpat_hlines2x2.gif
convert: no such image `u[floor((n-1.0*1)*u)+1].g' @ error/fx.c/FxGetSymbol/1446.
#!/usr/bin/bash
magick convert shadow.png dpat_hlines2x2.gif -channel A `
-virtual-pixel tile -fx 'u[floor((n-1)*u)+1].g' `
shadow_dpat_hlines2x2.gif
|
||
|
上記の DIY ディザパターンは、できるだけ単純なディザパターンであるため、高 速組み込みの "-ordered-dither" 演算子がそれを利用できるように、XML しきい値マップに直接変換できます。 これが最終的なXML定義で、私は自分の "$HOME"ディレクトリの私自身の個人的なしきい値マップファイル "~/.magick/thresholds.xml" に保存しました。
<threshold map="hlines2x2" alias="hlines2">
<description>Horizontal Lines 2x2</description>
<levels width="2" height="2" divisor="3">
1 1
2 2
</levels>
</threshold>
XML 形式は非常に単純で、2x2 ピクセルのマップを定義します。最初の黒い画像にはゼロの値が与えられ、ピクセルがないため、ゼロの値は存在しません。中央の画像でオンになっている (白くなっている) ピクセルは '1' に設定され、残りの画像または 2 番目の画像ピクセルには '2' の値が与えられます。'divisor=' は、このディザ パターンが表す画像の数、または疑似カラー レベル (偽のカラー レベル)を定義するため、値は '3' になります。ピクセル値を分割して、そのピクセルをオンにするカラーレベルを定義します。そのため、上の 2 つのピクセルは 1/3 より大きいカラーに対してオンになり、下の 2 つは 2/3 より大きいカラー値に対してオンになります。つまり、各ピクセル値は「しきい値」レベルを表し、ディザリングパターンがしきい値マップとも呼ばれる理由です。 定義の残りの部分では、順序付きディザ演算子のしきい値マップを参照できる名前 (およびオプションのエイリアス) を定義します。 だからそれを試してみましょう...
#!/usr/bin/bash
convert gradient.png -ordered-dither hlines2x2 od_hlines2x2.gif
convert shadow.png -channel A \
-ordered-dither hlines2x2 shadow_hlines2x2.gif
#!/usr/bin/bash
magick convert gradient.png -ordered-dither hlines2x2 od_hlines2x2.gif
magick convert shadow.png -channel A `
-ordered-dither hlines2x2 shadow_hlines2x2.gif
|
||
|
ご覧のとおり、結果は合理的に良いですが、結果を改善するために他のことをすることができます。 マップ内のしきい値を調整することで、境界を変更できるため、色空間を3つの等しい領域に分割しません...
<threshold map="hlines2x2a">
<description>Horizontal Lines 2x2 (bounds adjusted)</description>
<levels width="2" height="2" divisor="10">
3 3
9 9
</levels>
</threshold>
色レベルを 10 の等しいセクションに分割するために、除数を '10' に増やしたことに注意してください。次に、パターンが透明な端(黒)の 30% のしきい値から始まり、完全に不透明な(白)場合は 90% になるようにしきい値設定を変更しました。そして、ここにしきい値マップを変更した結果があります。
#!/usr/bin/bash
convert gradient.png -ordered-dither hlines2x2a od_hlines2x2a.gif
convert shadow.png -channel A \
-ordered-dither hlines2x2a shadow_hlines2x2a.gif
#!/usr/bin/bash
magick convert gradient.png -ordered-dither hlines2x2a od_hlines2x2a.gif
magick convert shadow.png -channel A `
-ordered-dither hlines2x2a shadow_hlines2x2a.gif
|
||
|
ご覧のとおり、これにより、純粋な水平線をディザパターンとして使用する半透明ピクセルの範囲が広がりました。これにより、より良い影の効果が得られますが、おそらくここで使用した例よりもあいまいさの少ない影でのみ使用する必要があります。 ただし、このタイプのしきい値の変更は非常にまれであることに注意してください。この場合、意図された使用のために正当化されますが。基本的には、グラデーションを適切に定義したり、パターンの明るい色合いと暗い色合いを許可したりしません。そのためには、より多くのピクセルとより多くのパターンを持つ、はるかに複雑なしきい値マップを作成する必要があります。 |
||
ここでは、上記で作成した単純な水平線のディザパターンを一連のパターンに拡張して、「オフ」から「オン」へのより滑らかなグラデーションを作成しました。これが結果でした。
#!/usr/bin/bash
montage dpat_hlines.gif -filter box -geometry 60x20+2+0 \
-tile x1 -background none -frame 2 dpat_hlines_images.gif
convert gradient.png dpat_hlines.gif \
-virtual-pixel tile -fx 'u[floor((n-1)*u)+1]' \
dgrad_dpat_hlines.gif
convert shadow.png dpat_hlines.gif -channel A \
-virtual-pixel tile -fx 'u[floor((n-1)*u)+1].g' \
shadow_dpat_hlines.gif
convert: no such image `u[floor((n-1.0*1)*u)+1]' @ error/fx.c/FxGetSymbol/1446. convert: no such image `u[floor((n-1.0*1)*u)+1].g' @ error/fx.c/FxGetSymbol/1446.
#!/usr/bin/bash
magick montage dpat_hlines.gif -filter box -geometry 60x20+2+0 `
-tile x1 -background none -frame 2 dpat_hlines_images.gif
magick convert gradient.png dpat_hlines.gif `
-virtual-pixel tile -fx 'u[floor((n-1)*u)+1]' `
dgrad_dpat_hlines.gif
magick convert shadow.png dpat_hlines.gif -channel A `
-virtual-pixel tile -fx 'u[floor((n-1)*u)+1].g' `
shadow_dpat_hlines.gif
|
||
|
ご覧のとおり、9、12x4 ピクセルの画像で構成されています。これは、使用できるすべてのピクセルパターンを表すわけではありませんが、これにより線の効果が向上します。また、線の隙間を適切にジッタリングするように高さを2倍にしました。 このディザパターンを使用する別の例を次に示します...
#!/usr/bin/bash
convert -size 120x55 xc:white -draw 'fill #777 ellipse 50,43 30,5 0,360' \
-motion-blur 0x15+180 -blur 0x2 sphere_shadow.png
convert sphere_shadow.png dpat_hlines.gif \
-virtual-pixel tile -fx 'u[floor((n-1)*u)+1]' \
sphere_shadow_dither.gif
convert sphere_shadow_dither.gif -fill red -stroke firebrick \
-draw 'circle 35,25 35,5' sphere_shadow_hlines.gif
convert: no such image `u[floor((n-1.0*1)*u)+1]' @ error/fx.c/FxGetSymbol/1446.
#!/usr/bin/bash
magick convert -size 120x55 xc:white -draw 'fill #777 ellipse 50,43 30,5 0,360' `
-motion-blur 0x15+180 -blur 0x2 sphere_shadow.png
magick convert sphere_shadow.png dpat_hlines.gif `
-virtual-pixel tile -fx 'u[floor((n-1)*u)+1]' `
sphere_shadow_dither.gif
magick convert sphere_shadow_dither.gif -fill red -stroke firebrick `
-draw 'circle 35,25 35,5' sphere_shadow_hlines.gif
convert: ImgNum 10 bad for ImgListLen 10 @ error/fx.c/ChkImgNum/3028. convert: Empty expression in parentheses at '*u)+1]' @ error/fx.c/GetOperand/2089. convert: For function 'floor' expected 1 arguments, found too few (0) at '*u)+1]' @ error/fx.c/GetFunction/1893. convert: For function 'u', arguments don't end with ']' at '*u)+1]' @ error/fx.c/GetFunction/1906. convert: Empty expression in parentheses at '*u)+1]' @ error/fx.c/GetOperand/2089. convert: For function 'floor' expected 1 arguments, found too few (0) at '*u)+1]' @ error/fx.c/GetFunction/1893. convert: For function 'u', arguments don't end with ']' at '*u)+1]' @ error/fx.c/GetFunction/1906. convert: Empty expression in parentheses at '*u)+1]' @ error/fx.c/GetOperand/2089. convert: For function 'floor' expected 1 arguments, found too few (0) at '*u)+1]' @ error/fx.c/GetFunction/1893. convert: For function 'u', arguments don't end with ']' at '*u)+1]' @ error/fx.c/GetFunction/1906. convert: Empty expression in parentheses at '*u)+1]' @ error/fx.c/GetOperand/2089. convert: For function 'floor' expected 1 arguments, found too few (0) at '*u)+1]' @ error/fx.c/GetFunction/1893. convert: For function 'u', arguments don't end with ']' at '*u)+1]' @ error/fx.c/GetFunction/1906. convert: Empty expression in parentheses at '*u)+1]' @ error/fx.c/GetOperand/2089. convert: For function 'floor' expected 1 arguments, found too few (0) at '*u)+1]' @ error/fx.c/GetFunction/1893. convert: For function 'u', arguments don't end with ']' at '*u)+1]' @ error/fx.c/GetFunction/1906. convert: Empty expression in parentheses at '*u)+1]' @ error/fx.c/GetOperand/2089. convert: For function 'floor' expected 1 arguments, found too few (0) at '*u)+1]' @ error/fx.c/GetFunction/1893. convert: For function 'u', arguments don't end with ']' at '*u)+1]' @ error/fx.c/GetFunction/1906. convert: Empty expression in parentheses at '*u)+1]' @ error/fx.c/GetOperand/2089. convert: For function 'floor' expected 1 arguments, found too few (0) at '*u)+1]' @ error/fx.c/GetFunction/1893. convert: For function 'u', arguments don't end with ']' at '*u)+1]' @ error/fx.c/GetFunction/1906. convert: Empty expression in parentheses at '*u)+1]' @ error/fx.c/GetOperand/2089. convert: For function 'floor' expected 1 arguments, found too few (0) at '*u)+1]' @ error/fx.c/GetFunction/1893. convert: For function 'u', arguments don't end with ']' at '*u)+1]' @ error/fx.c/GetFunction/1906. convert: Empty expression in parentheses at '*u)+1]' @ error/fx.c/GetOperand/2089. convert: For function 'floor' expected 1 arguments, found too few (0) at '*u)+1]' @ error/fx.c/GetFunction/1893. convert: For function 'u', arguments don't end with ']' at '*u)+1]' @ error/fx.c/GetFunction/1906. convert: Empty expression in parentheses at '*u)+1]' @ error/fx.c/GetOperand/2089. convert: For function 'floor' expected 1 arguments, found too few (0) at '*u)+1]' @ error/fx.c/GetFunction/1893. convert: For function 'u', arguments don't end with ']' at '*u)+1]' @ error/fx.c/GetFunction/1906. |
||
|
次のステップは、このディザ パターンのセットを、複数のイメージのセットではなく、単一のしきい値マップ イメージに変換することです。これは、いくつかの派手な画像操作を使用してすべての画像をマージすることによって実現されます。 |
||
#!/usr/bin/bash
convert -size 1x10 gradient: -flip -crop 1x1 \
+repage -delete 0,-1 \
-scale 12x4\! null: \( dpat_hlines.gif -delete 0 \) \
+matte -compose CopyOpacity -layers Composite \
-reverse -compose Over -flatten +matte dmap_hlines.png
|
![]() |
|
#!/usr/bin/bash
magick convert -size 1x10 gradient: -flip -crop 1x1 `
+repage -delete 0,-1 `
-scale 12x4`! null: `( dpat_hlines.gif -delete 0 `) `
+matte -compose CopyOpacity -layers Composite `
-reverse -compose Over -flatten +matte dmap_hlines.png
|
![]() |
|
|
Windows 版 IM v7.1.0 も意図した結果が得られない。 |
||
|
値 '10' はディザパターン内の画像の数より 1 つ多く、"-scale12x4\!" はしきい値マップに変換されるディザ パターンのサイズです。 その結果、純粋な黒や白の色のないグレースケールのマップが作成されます。ピクセルに使用されるグレーレベルは、カラーレベルがそのグレー値以上の場合、そのピクセルをオンにすることを意味します。つまり、各グレーレベルは、カラー値が黒から白になる「しきい値」レベルです。 画像を別の方法で見たい場合は、通常、暗いピクセルは、より多くのカラーレベルのためにそれらのピクセルがオンになります。明るいピクセルは、画像の色が非常に明るくなった場合にのみオンになります。これは、画像が実際にどのように見えるかのほとんど否定ですが、あなたがそれについて考えるならば、それは理にかなっています。 また、マップには GIF イメージではなく PNG イメージを使用しました。これは、保存する必要があるイメージが 1 つだけで、さらに重要なことに、しきい値に対して 16 ビットの品質レベルを維持しようとするためです。GIFは8ビットのカラーレベルしか処理できません。 これで、1つの画像と、各ピクセルのはるかに単純なしきい値をディザリングしきい値画像(またはマップ) と直接比較することで、画像をディザリングできます。
#!/usr/bin/bash
convert gradient.png dmap_hlines.png \
-virtual-pixel tile -fx 'u>=v' dgrad_dmap_hlines.gif
#!/usr/bin/bash
magick convert gradient.png dmap_hlines.png `
-virtual-pixel tile -fx 'u>=v' dgrad_dmap_hlines.gif
|
||
|
Windows 版 IM v7.1.0 も意図した結果が得られない。 |
||
|
しきい値マップがどれほど単純かを確認します。ディザリングされるチャンネルごとに、1 つの画像とピクセルごとに行う直接比較が 1 つしかありません。これにより、しきい値マップを使用したディザリングが非常に高速になります。フルカラー量子化よりもはるかに高速です。このシンプルさが、ImageMagick とほとんどのグラフィックス ソフトウェアがしきい値マップを使用してさまざまなディザ パターンを保持する理由です。 |
||
![]() |
より大きいか等しい ('>=') テストは、IM バージョン 6.2.9-2 まで "-fx" 演算子に追加されませんでした。これが問題になる場合は、上記の逆検定 'v<u' を使用してください。 |
|
ただし、このシンプルさは、ユーザーが複数のカラーレベルを使用してディザリングしたい場合、はるかに複雑になります。この概念実証は、IM コア関数に組み込まれる前に、"ポスタライズされた順序付きディザ" のページの例で最初に解決されました。 マージされたしきい値イメージができたので、次に、上記のイメージを XML しきい値マップに変換し、IM が直接読み取ることができ、"-ordered-dither" 演算子 が使用できるようにする必要があります。 これを行うには、画像を表す9つのグレーレベルを表す数値として画像を出力する必要があります。これは、"NetPBMまたはPBMplus" 画像フォーマットを使用して行うのが最善であり、深度調整は "NetPbm" 画像処理ソフトウェアを使用して行われます。このパッケージは一 般的に標準の Linux インストールなので、ほとんどの人はすでにそれを持っているか、そこから通常のソフトウェア配布物をインストールすることができます。 この場合も、"pnmdepth" 番号は、しきい値イメージに含まれるグレー レベルの数です。 convert dmap_hlines.png pgm:- | pnmdepth 9 | pnmnoraw > dmap_hlines.pgm P2 12 4 9 7 8 8 8 8 7 6 6 5 5 5 6 2 1 1 1 1 2 3 4 4 4 3 3 6 6 5 5 5 6 7 8 8 8 8 7 3 4 4 4 3 3 2 1 1 1 1 2上記のすべての数字( 'P2' イメージマジック識別子を除く)は、適切な「しきい値マップ」を生成するために必要な数字であり、個人の "thresholds.xml" ファイルに追加できます。たとえば、上記から作成された結果のしきい値マップエントリを次に示します。
<threshold map="hlines12x4" alias="hlines">
<description>Horizontal Lines 12x4</description>
<levels width="12" height="4" divisor="9">
7 8 8 8 8 7 6 6 5 5 5 6
2 1 1 1 1 2 3 4 4 4 3 3
6 6 5 5 5 6 7 8 8 8 8 7
3 4 4 4 3 3 2 1 1 1 1 2
</levels>
</threshold>
そして、このしきい値マップの使用例を次に示します。#!/usr/bin/bash convert shadow.png -channel A -ordered-dither hlines shadow_hlines.gif
#!/usr/bin/bash magick convert shadow.png -channel A -ordered-dither hlines shadow_hlines.gif
|
||
|
ほとんどのディザリング操作に設定されたマルチイメージパターンの代わりに、単一のしきい値マップまたはしきい値イメージを使用できますが、マルチイメージマップに独自の用途がないという意味ではありません。 一連のルックアップイメージを使用して、一度に 1 つずつではなく、複数の領域を一度に並べて表示 できます。たとえば、単純な画像を拡大 / 縮小し、画像内の各ピクセルを特定のシンボルに置き換えます。 たとえば、ここでは非常に小さな「目」画像を取得し、個々のピクセルをさまざまなシンボルに置き換えて、元の画像の各ピクセルに対してこのようなパターンを生成します。
#!/usr/bin/bash
montage dpat_symbols.gif -geometry +5+0 \
-tile x1 -background none -mattecolor blue -frame 3 \
dpat_syms_images.gif
convert eyes.gif -alpha off -colorspace sRGB -grayscale Average \
+matte -scale 1600% -negate \
dpat_symbols.gif -virtual-pixel tile -fx 'u[floor(15.9999*u)+1]' \
eyes_syms.gif
#!/usr/bin/bash
magick montage dpat_symbols.gif -geometry +5+0 `
-tile x1 -background none -mattecolor blue -frame 3 `
dpat_syms_images.gif
magick convert eyes.gif -alpha off -colorspace sRGB -grayscale Average `
+matte -scale 1600% -negate `
dpat_symbols.gif -virtual-pixel tile -fx 'u[floor(15.9999*u)+1]' `
eyes_syms.gif
|
||
|
"モンタージュ" は、マルチイメージ GIF イメージを拡張して、「アニメーション化」せずにコンテンツを表示できるようにするために使用されます。 通常の「Rec709Luminance」からより暗い「Rec709Luma」まで、使用する "-grayscale" 強度メソッドを調整するか、非線形の「sRGB」色空間または線形の「RGB」色空間の「平均」を使用できます。 。値の "-gamma" スケーリングを調整して、色の広がりを最適化することもできます。 可能性はたくさんあり、何が良いかは実際に選択した方法よりもシンボルの配置に依存します。上記の鍵は、入力画像の各色が一意のシンボルを生成することを何らかの方法で確認することです。これは、実現するのが非常に難しい場合があります。 この例は、趣味の人が従うことができるクロスステッチまたは編み物のガイドを作成するために使用でき、小さな通勤者の画像からより大きなスケールのアートワークを生成します。 この手法を使用して、一連のタイリングカラー画像でグレースケール画像をタイリングできます。結果は、多くの古いコンピューター戦争ゲームで見られる風景マップに少し似ています。
#!/usr/bin/bash
magick montage dpat_map.gif -geometry +5+0 -tile x1 -background none `
dpat_map_images.gif
magick convert -seed 100 `
-size 200x200 plasma:'gray(50%)-gray(50%)' -blur 0x15 `
-channel G -auto-level +channel -set colorspace sRGB `
dpat_map.gif -virtual-pixel tile -fx 'u[floor(5.999*u.g)+1]' `
map.gif
#!/usr/bin/bash
magick montage dpat_map.gif -geometry +5+0 -tile x1 -background none `
dpat_map_images.gif
magick convert -seed 100 `
-size 200x200 plasma:'gray(50%)-gray(50%)' -blur 0x15 `
-channel G -auto-level +channel -set colorspace sRGB `
dpat_map.gif -virtual-pixel tile -fx 'u[floor(5.999*u.g)+1]' `
map.gif
|
||
|
FX インデックスルックアップに使用されているのは実際には線形 RGB データですが、IM がグレースケール画像を(タイル画像と同様に)すでに最終的な sRGB 色空間にあると見なすようにする必要があることに注意してください。 これがないと、結果の「マップ」は樹木が茂った風景に偏り、水域の可能性はほとんどありません。 タイルには任意の画像セットを使用できることがわかるように、画像は互いに整列している必要はなく、同じサイズのタイルである必要もありません。 もちろん、3 つの青い「海」タイルの場合のように、タイルが同じサイズで互いに密接に関連している場合、タイルパターンは1つのタイル領域から別のタイル領域に「流れる」ことができます。 タイルを数字の画像に置き換えることで、数字ガイドによる一種のペイントを生成することもできます。 ただし、異なる領域に隣接するために、追加の処理が必要になる場合があります。 これは演習として残されており、ソリューションを私に郵送してください。この手法の作成者として、IM の例で自分の名前を使用できます。 |
||
|
工事中 |
||
|