前回までのおさらい

---

「フィルタ処理」と銘打ってはいますが，平均化フィルタ（モザイク化）しかできてません．これまでの記事の内容をおさらいすると，ウディタ上で画像に平均化フィルタをかけるためには，通常表示を用いる方法と加算表示を用いる方法の二つがありました．双方ともに不透明度を弄った画像を複数枚重ねることで，近傍領域の画素値の平均化（したように見える）処理を行うという流れは変わりません．詳しい処理内容は過去記事を参照していただくとして，ここでは簡単な利点と欠点だけ記しておきます．

【通常表示の利点と欠点】
・背面の状態に依存しない
・画像端が自然に仕上がる
・3x3の近傍画素のモザイク化が精一杯

【加算表示利点と欠点】
・通常表示よりも大きな領域の平均化が可能
・背面は真っ黒（理想的には（R,G,B）=（0,0,0））でなければならない．
・画像端が不自然になる可能性がある．

通常表示ver（3x3）	加算表示ver（3x3）

新しく画像を作り直すのが少し面倒だったので過去記事からの引用ですが，通常表示と加算表示によるモザイク化の比較が上の画像です．これだけを見ると，通常表示のほうが自然な仕上がりになっているように見えるので通常表示verだけ使えばいいかなぁなんて思いがちなんですが，上にも記したように3x3領域より広い領域をモザイク化しようとするとうまく働きません．

というのも，通常表示verでは画像をずらして重ねる際に，それぞれの不透明度を前回表示した画像の不透明度の半分にしているんです．つまりは

255→127→63→31→15→...

というような感じで不透明度が小さくなっていってるんですけど，特殊な処理を挟まずに1/2していくだけだとそもそも9枚目（3x3平均化の最後の画像）の不透明度が0になってしまうんですよね（数値の切り捨てを何とか回避しても9枚目が限界ですかね）．したがって，3x3以上の領域の平均化を行おうと引数を与えても，10枚目以降が表示できないので意味はない...と

その点加算表示verでは，とある画素の画素値はその画素に加算表示されている画像の画素値の総和（えげつないほど読みずらい），要は足し算になります．このとき各画像の不透明度は255/（重ねたい画像の枚数）となるため，特殊な操作を行わなくても16x16領域（画像の総枚数256枚）くらいまでならそれっぽく処理できます．

とはいえ画像をずらして加算表示しているため，背景が真っ黒でない限りは画像端が不自然に強調されてしまうんですね．（それが上の図の加算表示verからもわかる）

ここまでの話からそれぞれの利用先を考えると，通常表示verはマップチップやマップ内のオブジェクトのように背面が黒に固定しずらいものへ，加算表示verはノベルゲームの背景画像などの背面が黒でも問題なく，且つより広い領域のぼかしが必要なものへ...というのが妥当なところでしょうか．

しかし...マップチップへの平均化処理はたとえ3x3であっても常時実行ではかなり重いので，画面スクロールの無い（あるいはマップサイズが小さく一括で全画像を表示しても重くならない）時くらいしかゲームへの応用はできないですね...かなしい

加算型平均化フィルタ

---

何とか白飛びを軽減したい

ウディタ側に小数点以下の不透明度を設定できない以上，不透明度の最低値を1に固定したままでどうにか工夫できないでしょうか，ってことでやりました．

引き上げのみ　19x19 ~ 27x27	改良後　19x19 ~ 27x27

見た目こそ大きな変化がありますが，やったことは単純です．すべての不透明度が最低1あるせいで画像を重ねた際に白飛びしてしまうなら，オーバーしてしまう分ランダムで消せばいいんじゃない？みたいな．

例えば27x27の場合について考えると，処理上必要な画像の枚数は27x27で729枚です．計算上各画像が持つべき不透明度は0.35程度のところ，不透明度の最小値を1にしてしまっているため画素によっては白飛びが起こってしまうというわけなんですね．そこで，729枚のうちの474枚をランダムで選択して削除することで，疑似的に不透明度の総和を255に近づけ，白飛びのない平均化フィルタを実現する...という感じです．要は，本来周囲729画素の画素値の平均値をとるべきところ，その中の適当な255画素分の平均値で代用しているってこと．

ちなみに今回改良するついでに，不透明度の総和が255よりも少ない場合にも適当な画素の不透明度を少しずつ増やす処理も加えています．

しかしながら，ここまで来たらこれは完全に平均化フィルタではないような気がしてきました．16x16以降は使用している画像の枚数がほとんど変わらないのが（処理の重さを考えた時に）利点といえば利点ですが...改良した平均化処理を使って，さらに大きい領域の処理まで見てみましょうか

2x2 , 4x4 , 8x8 , ... , 64x64

64x64まで領域を増やしてみましたが，それなりには見えますね．下段はほとんど使用枚数が変化していないということを考えると，コスパはいいのかな...？

でも...気づいちゃったんですけど，これって...ということでおまけです．

平均化処理によって暗くなる画素について

平均化フィルタで本来やりたいことは，周囲の画素との平均をとること．のはずなんですけどどう考えても左上の紫っぽいとこ，途中から暗くなってませんか？？？

どこからだ～～と適当に探してきました．

改良前	改良後

すると，改良前では12x12あたりから，改良後では14x14あたりから暗くなり始めてました．で，いろいろ調べてみたんですけど，これもやっぱり不透明度がらみの問題でした．

（特に詳しく検証はしたわけではないのでここからは話半分で聞いてほしいんですが）

ウディタ上で表示される画像の画素値は，カラー補正を加えていなければ
（本来の画素値）×（不透明度）/ 255
で，その際の小数点以下の扱いは四捨五入のようでした．今回使用した画像の左上の紫部分の画素値は100程度（説明の簡略化のためRの輝度値で説明）なんですけど，この値って
100 ×（1）/ 255 ≒ 0.39　→ウディタ上では 0
100 ×（2）/ 255 ≒ 0.74　→ウディタ上では 1
って感じで，不透明度１だと画素値が0になってしまい，2だとぎりぎり除算後も画素値1としてカウントされるっていう微妙な値でした．つまり，不透明度の計算時に１となってしまった瞬間に画素値100程度の画素は無視されてしまうということなんですね（悲しいね）

処理にもよると思いますが，今回不透明度を計算するときに用いた式は
255 / （使用される画像数）
という単純なものなので，改良前では 11x11 と 12x12 の場合で
255 / 11^ ≒2.11　→ウディタ上では 2
255 / 12^ ≒1.77　→ウディタ上では 1
ってな感じでバッサリと不透明度が変わってしまうため，12x12以降ではうまくいかなかったと．じゃあなんで改良側はうまくいっているのよ..というと，上の方にさらっと書いてありますが全画像の不透明度の合計値が255に満たない時に，ランダムで何枚かの画像の不透明度を＋１しているからです．

特に13x13の場合は全画像数が169枚なのに対し，計算上各画像の不透明度は1となってしまうため，画像のうちのおよそ半数に対し不透明度を＋１しています．そのため改良後の処理では改良前には描画できなかった画素まで表示できている場合があるというわけです．

処理の改良（案を含む

---