hirax.net::Keywords::「確率」のブログ

■Photohoの乱数プラグインを作成する　

　PhotShopはとても便利なソフトである。画像を取り扱うにはトップクラスと言っても良い。あえて、難を挙げるならば8Bit階調が基本という所である。もちろん、12bit階調なども扱えるのは知っているが、基本機能とは言えないと思う。
　しかし、PhotoShopで凝ったことをしようとすると、Pluginを作らざるを得ない。PhotoShopでPluginをつくるには2つのやり方がある。それは、

• Adobe提供のPlugin SftwareDevelopmentKitを使ってPluginを作る。
• FilterFactoryを使ってPluginを作成する。

　今回はランダムノイズをつくるためのプラグイン作成が目的である。その程度であれば、FilterFactoryを使うのが簡単で良い。

FilterFactoryを使う

まずは、FilterFactoryを使う。

Redのチャンネルに　(0...255)の乱数を与える。

たった、これだけである。 Redに乱数を与え、Green,Blueのチャンネルには0を与える。

　もうひとつ、各色に乱数を与えるプラグインのサンプル画像はこのようになる。

• Redのみ乱数を与えるプラグイン。
• 各色に乱数を与えるプラグイン。

　さて、試しに使ってみる。1000x1000ドットのランダムノイズ画像を作成してみる。その画像はここに載せるには大きすぎる。そのため、その一部を左下に示す。その画像に対して各領域10x10の100ドットで平均し、100x100に変換した画像を右に示す。詳しくは「2項分布を考える」を見て欲しいが、100ドットで平均したくらいではフラットにはならない。それどころか、有限のいくら広い範囲で平均しても正確にはフラットにはならない。もし、フラットになるのであれば、それはランダムな2項分布ではない。もちろん、PhotoShopの丸め誤差とかの話は別にしておく。また、「2項分布を考える」の際は1次元の1成分データであったが、今回は2次元3成分データである。そのため、人間にはよりフラットに見えにくい。相対的な色差に対しては人間の目は敏感だからである。

右が作成した1000x1000ドットのランダムノイズ画像の一部(137x90)、
左は作成した1000x1000ドットのランダムノイズ画像を各領域100ドット(10x10ドット)で平均することにより、100x100に変換したもの

■2項分布のムラについて考える　

　今回の目的を説明するために、少し準備を行う。
　まず、2048個の[ランダムに0から256の値を持つもの]からなる1次元データを作成する。以下の左図がそのデータである。ここで、X軸がデータの順番であり、1から2048までを示し、Y軸がデータの値である。Y軸の数値ラベルは0から256の値である。折れ線グラフの方が1次元データとして実感できるのだが、そうすると真っ黒になってしまうので、点プロットグラフにしてある。
　また、[0から256]のデータの出現頻度のグラフ(つまりヒストグラム)を右の図として示す。

作成した1次元データ(左図)、とそのヒストグラム(右図)

　今回の目的は、そのムラを考えることである。広い範囲で見たときには、どの程度フラットだろうか。例えば、最初の100個のデータの平均と、次の100個のデータの平均というのはどの程度同じだろうか。それが1000個ならどうだろうか。1000個平均してみても場所によって、平均値はばらついているだろうか。もし、ばらついているとしたら、2項分布の確率過程を導入すると、広い範囲で見てみても認識できるくらいのばらつきを導入していることになる。その「ばらつき=ムラ」を人間が感じないためには、どの程度まで平均しなければならないのか。そういったことである。

　ここで、先の2048個の1次元データは2048dpiの1次元画像データである、ということにしてみる。したがって、X軸の領域はトータル1inchを示すことになる。そして、以下の作業をする。

1. 2048dpiの1次元画像データを2値化(128でしきい値とした)したものを8個に分断する。
2. それぞれ、分断したデータ(256個)内で平均を取る。そなわち、8ppi(pixelper inch)の1次元データができる。

8ppiへと変換した1次元データ(左図)、そのヒストグラム(右図)

　すると、2048dpiの(1/2の確率で2値化された)データというものは、今回の目的である「ムラを感じないための条件」を満たしていないということになる。ここでは画像に例えているが、別に画像だけの話ではない。

　それでは、いくつか条件を振ってみたい。各々の条件下で示すグラフの領域は以下を示す。

2048dpi

オリジナルの1次元データ	左のヒストグラム
8ppiに変換したもの	左のヒストグラム

4096dpi

オリジナルの1次元データ	左のヒストグラム
8ppiに変換したもの	左のヒストグラム

8192dpi

オリジナルの1次元データ	左のヒストグラム
8ppiに変換したもの	左のヒストグラム

　上の右下で出ているようなヒストグラムが2項分布であることは、サンプルを多く(しかし、試行回数を少なく)すればよくわかる。例えば、このようになる。

　今回の話はあることの前準備なので、これだけでは話しが全く見えないかもしれない。というわけで、

■続々ACIIアートの秘密　

階調変換　その2

　前々回の

• ASCIIアートの秘密 - 画像をASCII文字に変換するソフトを作ろう- (1999/09/05)

• 清竹's　テキスト絵　HPリンク集　(http://www2.nkansai.ne.jp/users/kiyo/ )

「限られた出力階調を有効に利用するため、画像の濃度ヒストグラムの補正を行ないます。1パス目で、濃度ヒストグラムをカウントし、そこからヒストグラムが平坦になるような濃度変換関数を生成します。（ヒストグラムを平坦にするのは、情報のエントロピーをなるべく保存するためです。）」

• 続ASCIIアートの秘密 - 階調変換　その1 -(1999.09.08)

　Q02TEXTは「 .:|/(%YVO8D@0#$」の16階調を使用するテキストアート作成プログラムである。それに対して、「ASCIIアートの秘密」で作成したimage2asciiが使用可能な階調数は一定ではない。指定されたフォントを一旦出力してみて、その結果を計測することにより、出力可能な階調数を決定している。したがって、指定したフォントでしか階調の確かさは保証されない。その代わりに、指定されたフォントを使えば割に豊かな階調性を使用できることになる。
　また、得られる階調は一般的に滑らかではないので、Q02TEXTが使っているアルゴリズムとは少し違うものを導入している。

　通常ASCIIアートは色々な環境で見ることができるのがメリットの一つである。しかし、image2asciiはフォントを限定してしまっている。これは、目的が通常のASCIIアートとは異なるからである。私がimage2asciiを作った目的は、それを仮想的な出力デバイスとしてみたいからである。その出力で生じる様々な問題を調べたり、解決してみたいのである。

　さて、前回の最後に示した3種類の画像変換は

1. 単純な階調重視モデル
• オリジナルの0を出力画像の最小値に
• オリジナルの255を出力画像の最大値にする
2. 拡大した単純な階調重視モデル
• オリジナルの最小値を出力画像の最小値に
• オリジナルの最大値を出力画像の最大値にする
3. 情報量を最大にするモデル
1. エントロピーを最大にするための階調変換を行う

　これら3つの変換方法の違いにより出力画像にどのような違いが生じていたかを、まずはもう一度見てみる。まずは、オリジナル画像である。これは、「私の尊敬する」S大先生である。私は尊敬とともに「ロボコップSさん」あるいは、「ロボSさん」と呼ぶのだ。いや、本当に。

人物写真(ロボコップS氏)

　以下にオリジナル画像及びimage2asciiを用いて変換したものを示す。

オリジナルと変換後画像

オリジナル

(1)

(2)

(3)

• (1).単純な階調重視モデルが比較的白い個所では一番オリジナルに忠実な濃度であることはわかるだろう。ただし、黒い部分に関しての表現力は極めて低い。
• (2).階調性を少しだけ改善したものではそれより視認性が改善している。
• (3).視認度の高い画像ではあるが、オリジナルとは濃度などは異なる?

オリジナルと変換後画像のヒストグラム

オリジナル

(1)

(2)

(3)

ASCII ARTには濃度の表現領域には限度がある。そのため、(1),(2),(3)はいずれも濃度が最大を示す個所でもオリジナルよりかなり濃度が低い。また、(1),(2)はオリジナルとヒストグラムの形状も少しは「似ている」が、(3)においては、かなり異なっているのがわかると思う。(3)はヒストグラムの形状はかなり異なるにも関わらず、視認度は高くなっている。これが、エントロピーを最大化(すなわち情報量を最大化)しているおかげである。ヒストグラムがかなり平坦になっているのがわかるだろう。

　というならば、エントロピーの計算もしなければならないだろう。もちろんエントロピーと言えば、

• ハードディスクのエントロピーは増大するか?- デフラグと突然変異の共通点 - (1999.03.28)

　この前作成したMathematicaのNotebookを流用するために、オリジナルと3つの変換画像を合体させる。そして、そのヒストグラムを見てみよう。このヒストグラムが非常にわかりにくいと思うので、一応説明しておく。あるY軸の値で水平に1ライン抽出して、その部分のヒストグラムを右のグラフに示しているのである。

あるY軸方向の断面におけるヒストグラム

オリジナルと3つの変換画像を合体させたもの

ヒストグラム(横軸=濃度,縦軸=走査軸)

　例えば、オリジナルの画像では髪の毛がある辺り(Y軸で10から30位)では、ヒストグラムを見ればレベルが50位の黒い所が多いところがわかる。それに対して、変換後の画像では、一番濃度の高い所でも150前後であることがわかるだろう。

　それでは、それぞれ、Y軸でスライスしてその断面におけるエントロピーを計算したものを次に示してみる。

それぞれのY軸スライス断面におけるエントロピー

オリジナルと3つの変換画像を合体させたもの

エントロピー(縦軸=走査軸)

本来は、画像全面におけるエントロピーを計算するのが、望ましい。しかし、ここで使っているような、Y軸でスライスしてその断面におけるエントロピーでも、オリジナルの画像が一番エントロピーが高く、(3)の変換画像(つまり一番上)のものが次にエントロピーが高いのがわかると思う。つまり、情報量が高いのである。

　エントロピー量とあなたの感じる「視認度」とが相関があるかどうかは非常に興味があるところだ(私にとって)。エントロピーが多くても(すなわち情報量が多くても)オレはちっともいいと思わないよ、とか、おれは断然エントロピー派だね、とか色々な意見があったらぜひ私まで教えてほしい。

　 「お遊び」に見えるASCIIアートも、調べていくと実は奥が深いのだなぁ、とつくづく思う。といっても、もちろん本WEBはお遊びである。なかなか、奥までは辿りつかない(し、辿りつけない)と思うが、この「ASCIIアートの秘密」シリーズはまだまだ続くのである。

■バナー画像のエントロピー　

がんばれ、JPEG

　前回、

• バナー画像の情報量を探れ - 1文字辺りの情報量編- (1999.11.19)

• ハードディスクのエントロピーは増大するか?- デフラグと突然変異の共通点 - (1999.03.28)
• 続々ASCIIアートの秘密 - 階調変換　その2- (1999.10.15)

　そうそう、今回も「本ページは(変な解説付きの)リンクページであります」ということにしておく。他WEBのバナー画像を沢山貼っているが、それはこのページが「リンクページ」であるからだ。

　エントロピーを計算し、画像の圧縮度を調べる際に、今回はファイル先頭の400Byteにのみ注目した。ファイル全体で計算するのは面倒だったからである。各バナー画像でファイルサイズが異なるからだ。そこで、全て先頭400Byteに揃えてみた。

　行う作業は以下のようになる。

　まずは、画像ファイルの「先頭400Byteの可視化画像」を作成する。これは、各ファイル中の各Byteが8bitグレイ画像であると考えて、可視化したものである。以前書いたように、「てんでばらばらに見えるものは冗長性が低く、逆に同じ色が続くようなものは冗長性が高い」のである。もし、同じ色が続くとしたならば、「また、この色かい。どうせ、次もこの色なんだろ。」となってしまう。次の色の想像がつく、ということはすなわち、情報としては新鮮みのないものとなる。つまり、情報量が少ないのである。その逆に、情報量の多いものは、てんでばらばらで次の色(データ)の予想がつきづらいもの、となるわけである。まずは、そのてんでばらばら具合を「先頭400Byteの可視化画像」で確認する。

　次に、てんでばらばら具合をヒストグラムで確認する。各Byteが0から255のどの値をとることが多いかを調べるのである。てんでばらばらであれば、どの値をとる確率もほぼ同じであり、フラットなヒストグラムになるはずである。逆に、ヒストグラム上である値に偏っていれば、値の予想がつきやすく、情報量が少ないということになるわけだ。

　最後に、各Byteのデータを「8元無記憶情報源モデル」に基づいて計算したエントロピーを計算した。各Byteのエントロピー、すなわち、平均情報量は最大で8となる。当たり前である。1Byteは8bitであるから、最大限有効に使いきれば、情報量は8bitになる。

　それでは、青い「hirax.net できるかな?」バナーを例にして見てみる。

文字情報密度	ファイルサイズ(Bytes)	画像	先頭800Byteの可視化画像	ヒストグラム	エントロピー(bits/Byte)
35	662				7.1

　この画像ファイルはトータルで662Bytesであるが、その先頭400Bytesの可視化画像はけっこうばらばらである。それは、ヒストグラムをみても確認できる。少し、0近傍が突出しているが、それを除けば、かなり均等である。そして、エントロピー、すなわち、1Byte当たりの情報量は7.1bitである。満点で8bitであるから、7.1bitはなかなかのモノだろう。

　それでは、前回登場したバナー画像達に、同じ作業をかけてみる。

文字情報密度	ファイルサイズ(Bytes)	画像	先頭400Byteの可視化画像	ヒストグラム	エントロピー(bits/Byte)
31	874				6.7
34	648				7.2
35	662				7.1
40	763				7.1
44	1003				7.1
54	750				7.1
58	864				6.6
112	2472				3.8
124	2348				7.0
155	465				7.3
223	3116				7.0
294	881				6.6

　IntenetExplorer、RealPlayerといった、ヒストグラム上で突出している値がある画像はエントロピーが少ない。すなわち、平均情報量が少ない。大体、6bit台である。gooは0近傍の値が突出しているのが足を引っ張り、6.6bitとなっている。これらは、1Byteの8bit中の1bit強が無駄となっているわけである。

　最高点はMacの7.3bitである。8bit中で7.3bitの情報量を持っているのである。逆に言えば、0.7bitは無駄ということになる。しかし、8bit中7.3bit使い切っているのはなかなかのものである。

　それ以外は大体7bit台で拮抗している。しかし、それはいずれもGIF画像である。そう、唯一のJPEG画像である「今日の必ずトクする一言」が3.8bitと低い情報量であるのだ。しかし、これには、いろいろな理由があると思われる。例えば、ファイル全体ではなく先頭のみを見ているため、JPEGのヘッダー部分が入ってしまい、冗長性が高くなってしまっている、とかである。全体でなく、部分で評価しているのは非常にマズイだろう。また、GIFが情報圧縮していることもあるだろう。そのため、JPEG陣営にはかなり不利であったと思われる。

　そうそう、今回は情報圧縮度にだけ注目したから、JPEGに不利な結果になった。けれど、他のいろいろな理由を挙げれば、GIFは使いたくないという気持ちもあるのだけれどね。けど、便利なんだよね。

■サンタクロースを捜して　

Double Role on Christmas Eve

　クリスマスが近くなると子供達は「サンタクロースにお願い」をし始める。といっても、子供達がサンタクロースがどこに住んでいるのか知っているわけもないし、かといってサンタクロースへの伝言板があるわけでもない。これがゴッサムシティに住んでいるバットマンなら夜空にバットシグナルを照らし出せば良いし、シティハンターなら駅の伝言板に書き込みをすればちゃんとメッセージは伝わるだろう。

　だけど、サンタクロースに関してはそんなホットラインは残念ながら無いのである。子供達はサンタクロースに「自分が欲しいもの」をどうやって伝えれば良いのか実際のところ判らないのだ。じゃぁ、子供達はどうすれば良いのだろう？どうすればサンタクロースが何処にいるのか知ることができるだろう？サンタクロースを探すにはどうしたら良いのだろうか？

　これまでなら、子供達は身の周りの大人達、自分よりも色んなことを知ってそうな大人達に「サンタクロースは何処にいるの？」と聞いていたに違いない。だけど、色んなことを知ってるはずの両親や保母さんも「サンタクロースが何処にいるか」は何も教えてくれない。残念ながら、色んなことを教えてくれる大人達もサンタクロースのことに関しては何故か何も知らないようなそぶりを見せる。

　そんな風に、これまでなら子供達には他に調べる術もなかった。だけど、今なら違う。インターネット上に「検索サイト」がたくさんあるのだ。今の子供達は例えばGoogleで「サンタ」と入力して検索のボタンを押すだけで、なんと25300件もの情報(2000.12.24現在)を集めることができる。子供達は「インターネット上でサンタクロースを捜す」ことができるのだ。

　だけど、子供達にはそんなサンタを捜す手段はあるのだけど、それでもなかなか上手くサンタを見つけられないことだろう。まだまだ、上手く情報を選別できないこともあるだろう。そこで、今回はそんな子供達のために、インターネットで「サンタクロースを捜して」みた結果を書いてみたいと思う。サンタクロースが誰だか調べるテクニックとそのヒントをホンの少しだけ書いてみたい、と思うのだ。
 

　さて、それではサンタクロースを捜してみることにしよう。まずは、「関係者を調べて」みる。サンタクロースと誰が関係していて、誰が関係していないのかを調べてみるのである。と、いきなり言われても判りづらいだろうから、まずは例を出してみたい。例えば、どうみてもサンタクロースの関係者のハズの「トナカイ」を考えてみよう。まずは、「トナカイ」をGoogleで検索すると23500件の情報がある。そして次に、「トナカイAND サンタ」で検索すると、9060件の情報があることがわかる。トナカイの全ての目撃情報(Googleによる)が9060件であるのに対して、「サンタと一緒にいるトナカイ」の情報は9060件の目撃情報があるのだ。つまり、9060/23500= 38.6%もの高い確率でトナカイは「サンタと一緒にいる」のである。
 

トナカイとサンタの「関係」　→　どうみてもトナカイはサンタの関係者である

　この「トナカイとサンタの関係」を見せただけでは、少し疑問に思う人もいるだろう。そこで、次にサンタと無関係そうな白馬の場合で調べてみよう。果たして、白馬がサンタの関係者であるかを捜査してみるのだ。

　まずは、「白馬」単独で検索をすると108000件の目撃情報が見つかる。それでは、「白馬AND サンタ」で検索するとどうなるだろうか？なんと、795件しか見つからないのである。つまり、「サンタと一緒にいる白馬」は795/108000= 0.74%しかいないのだ。これは、どうみても白馬はサンタと無関係であることがわかるだろう。白馬に乗って現れるのはやはり「王子さま」であって、サンタではないのである。そしてまた、この検索方法の妥当性も納得して頂けることと思う。このやり方で検索を続けていけば、サンタの正体もいつか判るハズなのだ。
 

白馬とサンタの「関係」　→　どうみても白馬はサンタと無関係である

　これを読んでいる子供達がこの検索方法を使えば、きっとサンタをいつか見つけることができるだろう。あとは子供達が自分で捜すことだろうから、もう私が捜すのはここまでだ。

　だけど、ちょっと気になることがあるのでそれだけは調べておきたいと思う。それは、サンタと子供と大人の関係だ。何故なら、去年「サンタが街にやってくる」の中で私は「サンタクロースの巡回問題」を考えることで、「子供達が大人になって、そしてサンタになる」と推理してみた。じゃぁ、サンタと子供と大人の関係は一体どうなっているのだろう？それだけは、ちょっと調べてみたいのだ。子供達がサンタのことを訊いても、サンタのことを何も知らなさそうなそぶりを見せる大人達は本当にサンタと無関係なのだろうか？それだけは調べておきたいと思うのである。

　そこで、サンタと一緒に目撃された(Googleに)子供と大人の割合を調べてみた結果が次の表だ。
 

　これを眺めてみると、とても興味深いことがわかる。なんと、サンタと一緒に目撃された子供の割合は1.4%であるのに対して、サンタと一緒に目撃された大人の割合は0.018%しかないのである。二桁も違うのだ。もう、どうみてもサンタと無関係そうなプログラマーでさえ(プログラマーには実に失礼であるが)、0.57%もサンタと一緒に目撃されているのに、大人はそれより遙かにサンタと一緒には現れないのである。0.018%なんてほとんど0%だと言っても良いくらいだ。サンタと大人が一緒に目撃されることはもう全然無いのである。

　さっきのトナカイの場合なんか、38.6%もサンタと一緒に目撃されていて、「サンタがいるところにはトナカイがいる」と言っても良いくらいなのに、それとは全く正反対だ。「サンタがいるところには大人はいない」のである。「サンタと大人が一緒に現れる」ことはないのだ。だから、きっと大人とサンタは無関係なのだろう。子供達がサンタクロースのことを大人達に訊いても何も教えてくれなかったのも当たり前だ。大人達はサンタと出会ったことがないのだから、それはしょうがない。だから、実は大人達はサンタのことを何も教えることができないのだ。ただ、サンタのことを本当に知らないだけなのだ。

　サンタが現れているときには大人の姿は見えず、大人が現れているときにはサンタは現れない。だから、大人達はサンタのことを知らない。そう単純にそれだけのことだ。ただそれだけのことだ。　　　　だけど、もしかしたら本格ミステリー大好きの名探偵コナンのような子供であれば、そこに何かのトリックでも思いつくのかもしれない。　　　それでも、そんな名探偵コナンのような子供だってきっといつかは…