コンピュータに画像はどう見えるのか? その2 縦っぽい線、横っぽい線

本日のお題画像:


前回、

次回は、この直線を理解することで、書籍電子化や新聞電子化の何の役に立つのか、ということを見て行きましょう。


http://d.hatena.ne.jp/denshikA/20100419

とは言ってみたものの、もうひとつ、お伝えした後でないと、先へ進めないことに気づきました。(かたじけありません))


昨日と同様、http://users.cs.cf.ac.uk/Paul.Rosin/CM0311/dual2/hough.htmlに行ってみましょう。


まず、縦っぽい線を描いてみましょう。縦っぽければ何でもよく、ちょっと傾いていても、多少ばらついていてもOKです。(意外と私は大雑把です。)


次に横っぽくしてみてください。


ここで、みなさん、お気づきですね。緑枠の中に、縦っぽい線を描くと、赤枠内の交点は左端*1にできます。緑枠の中に、横っぽい線を描くと、赤枠内の交点は、真ん中近辺にできます。これを第1法則とでも名づけておきましょう。


今度は、縦っぽい線の位置を変えてみましょう。


並べてみると分かりますが、縦っぽい線が緑枠内の中央線から離れれば離れるほど、赤枠内の交差点の位置が上になっていきます。


横っぽい線の位置も変えてみましょう。


並べてみると分かりますが、横っぽい線が緑枠内の中央線から離れれば離れるほど、赤枠内の交差点の位置が上になっていきます。これを第2法則と名づけておきましょう。


つまり、緑枠内の線の傾きと位置によって、赤枠内交差点の位置が異なってくるわけなんです。(ココ重要)


逆に言えば、赤枠内の交差点の位置だけで、緑枠内に線が、どのあたりに、どんな傾きであるのか、分かってしまう、ということですね。前回もお伝えしたとおり、コンピュータというのは、個々の点しか見えていませんので、(緑枠内の)画像を理解しようとするとき、コンピュータというのは、こんな感じで赤枠内の交差点を見ているんです。(まぁまぁ、すごいでしょ?)


そしたら、もう一度、本日のお題画像をみてましょう。緑枠の2本の線について、位置と傾きがくっきりと、赤枠に現れてるでしょう?


簡単にまとめますと、

  • 緑枠の中に線をいくつ描いてもよいですが、その線の数だけ、赤枠内に交差点ができます
  • 赤枠内の交差点の位置は、緑枠内の線の位置と傾きを教えてくれます


次回こそ、この直線の位置と傾きを理解することで、書籍電子化や新聞電子化の何の役に立つのか、ということを見て行きましょう。

*1:右端にもできるのですが、まぁ、そんなことは忘れてください。

コンピュータに画像はどう見えるのか? その1 Hough変換

本日のお題画像:


人間は、画像を見たときに、その中に写っている文字や形状を見ています。ところが、コンピュータは、画像を見たときに、その中に写っている文字や形状を見ていません。個々の点の色や明るさを見ているだけです。つまり、「木を見て森を見ず」なのです。


基本的に、コンピュータは画像の中の文字も読めませんし、線があるとか、円があるとかも理解できません。なので、

  • 文字を認識させるためには、OCRというテクノロジーを使う必要があります
  • 画像内の線や円を認識させるためには、それなりの診断ツールを使う必要があります。

OCRについては、6月くらいになったら、詳しく突っ込みますので、本日は、画像の中にある線について、考えてみましょう。


とりあえず、http://users.cs.cf.ac.uk/Paul.Rosin/CM0311/dual2/hough.htmlに行ってみましょう。(いずれ、技術的な解説はしますので、ここでは、なすがままに、身をゆだねてください。*1


こんな画面が出てきますね?


緑枠内をどこでも良いのでクリックしてください。


すると、赤枠内に、波が現れます。(このことを、「Hough変換」と呼ぶのですが、名前はどうでも良いです。)


消したいときは、右下の方にある「click here」というところをクリックしてみてください。(単に再表示させる、だけなんですが。)


次に、緑枠内をクリックした後、ボタンを押したまま、ドラッグしてみてください。赤枠内の波が、どんどん変化していくことでしょう。ちょうど、緑枠内で円を描くように動いてみると、波が波らしく動くでしょう。(って、ただ、それだけなのですが、ヒマな時、一人ウェーブをやって遊んでいます。)


一度、画面をクリアして、今度は、緑枠内に、2点を作って見ましょう。


ここで確認して欲しいのですが、2点を緑枠のどこに配置したとしても、赤枠の波2本は、1点で交わってますね。(ここがかなり重要です*2


つまり、ここまでを整理しておくと、

  1. 緑枠の1点は、赤枠の波1本となる
  2. 緑枠の2点は、赤枠内で2本の波となり、1点で交差する


さて、次に緑枠内に3点を作って見ましょう。まず、3角形っぽく

次に、一列に並べてみましょう。


以上のことより、薄々お気づきだと思いますが、このお題画像のように、

緑枠内に直線を描くと、赤枠内にはいくつかの波ができるのですが、それがたった1点で交差することになります。


というわけで、本日のところは、細かい点を抜きにして、実際に触ってみた肌感覚で理解していただきたいのですが、以下のようにまとめておきます。

  • コンピュータは、画像を見たとき、(緑枠内のように)個々の点しか理解できない
  • 緑枠内の点は、赤枠内の波として表現できる(これをHough変換といいます)
  • 緑枠内の直線は、赤枠内で、たった一つの交差点をつくる
  • なので、コンピュータは、画像内の直線を探す時、Hough変換された波線が交差する点を探している


次回は、この直線を理解することで、書籍電子化や新聞電子化の何の役に立つのか、ということを見て行きましょう。

*1:何が何でも早く技術的なもんを知りたい、という方は、http://codezine.jp/article/detail/153が良いと思いますよ

*2:ただし、1個だけ例外があるのですが、2点を縦に並べてみると、赤枠の左端と右端の2箇所で交差しちゃうんですが、そんな細かいことはどうでもいいです

大容量ファイルSSIM縛りJP2変換に関する雑感

おそらく、最初で最後でしょうが、雑感(私見)を述べてみようと思います。


最近、「SSIM JPEG2000」で検索する人が増えているようです。(と言っても、マニアな領域の話ですので、たかが知れてて、AKB48全員よりも少ないでしょう、きっと)


その理由は明らかなのですが、「SSIMとは何か? その1」でも書いたように、

いろんな公共機関が大規模な電子化プロジェクトの予算をつけて、

  1. 画像のフォーマットとして、JPEG 2000にすること、なおかつ、
  2. SSIMの値を一定水準以上にすること

という指定があったからです。


これまでも、JPEG 2000を採用しているプロジェクトはありました。しかし、これまでのプロジェクトは、「PSNRの値を一定水準以上にすること」という指定でした。それが今年[2009年ですね]あたりから、PSNRではなく、SSIMを基準とするようになってきた、ということです。


http://d.hatena.ne.jp/denshikA/20090921

ということです。


ただ、この時期、電子化業者が、かなり困ってることがあるはずです。あえて、具体的な言及はしませんが、おおよそ、

JPEG 2000変換にやたらと時間がかかって、かなわんわぃ


しかも、どうやって変換するのか、さえ、わからんわぃ

というようなことだと思います。


確かに、ここ最近の「仕様書」には難解な記述が多く、かつ、その仕様通りに変換できる市販ソフトは、高いか遅いか、その両方か、という状況だと思います。なので、普通に考えれば、お手上げな状況なのでしょう。全く、なんでこんな仕様になってしまったんでしょうね。


ところが、ここ最近の「仕様書」について、私は、とても良いことだな、と思うことがあります。


私が理解する範囲では、今回の仕様、特に大容量ファイルのSSIM縛りJP2変換に関する部分について言えば、市販ソフトを買ってきて、がんばって変換して、どうにかなるものではありません。つまり、適正な利潤を確保しながら、なおかつ、現実的な価格で変換を請け負うためには、電子化にまつわる全工程に関する深い理解を必要とし、「市販ソフトを買って頑張る」という次元を超えた創意工夫が必要なんです。


もうちょっとだけ具体的に言いましょう。(でも、あまり具体的に言えない事情もご理解くださーい)


SSIM縛りのJP2変換をする場合、与えられた元画像を、与えられたソフトで変換すると、おそらく、天文学的な金額になるでしょう。*1


ならば、どうするのか?


まず、第一に、SSIMの特性を理解して、画像を作成するスキャン段階から関与しなくてはいけません。どういう風にスキャンをすれば、後工程のJP2変換が早くなるのか、ということをちゃんと考えてくださいね。ここは、普段から、スキャンに実際に携わっているかどうか、が勝敗を決する部分です。スキャンなんて、スキャナを回すだけだろ、と思っちゃってる人は、かなりヤバいです。今回の仕様書で淘汰されちゃうかもしれません。


次に、市販ソフトを市販PCで走らせてちゃ、とてもじゃないですが、競争できません。まず、ソースをいじらないことには、今回の競争で、スタートラインにもつけないでしょう。つまり、予選落ちです。なので、ソースが公開されないようなソフト(って、普通そうなんですが)を買ってきても、太刀打ちできないと思います*2。さらに、PCも部品レベルでの交換が必要になってくるでしょう。メモリの増設以外で、PCのふたを開けたことがない人は、かなりヤバいです。今回の仕様書で淘汰されちゃうかもしれません。


というわけで、大容量ファイルのSSIM縛りJP2変換を適正な利潤と価格でやってのけるためには、「電子化にまつわる全工程に関する深い理解」を持ったパートナーを早く見つけることが重要です。私の理解では、「電子化にまつわる全工程に関する深い理解」を持った会社は、かなり少ないと思います。つまり、今回は、そのような会社の争奪戦になるわけですね。

*1:おおげさに言ってますので、実際は、「目玉が飛び出る」くらいです。

*2:唯一、市販ソフトを作ってる会社にあれこれお願いして改良してもらえばいいのですが、おそらく、足元を見られて、すごい請求書が届くでしょう。

なんでSSIMの計算では、ボケ画像を使うでしょうか?

本日のお題画像:
 


http://cvcl.mit.edu/hybrid_gallery/smile_angry.html


お題画像を見てください。ずいぶんと古い話ですが、かつて、この画像が話題になったのを覚えてますか?*1


目を細めてみたり、パソコンの画面から少し離れたところから見てみると、「状況が変わる」というトリック画像です。普通に見ると、左にちょっと怒った男性、右に普通にしてる女性がいるのですが、目を細めると、左右が入れ替わり、左に女性、右に男性となるわけです。


このトリックのタネについて、こちらの論文(http://cvcl.mit.edu/Papers/Schyns-Oliva99.pdf)を読むと分かるのですが、「高周波画像と低周波画像を合成している」ということです。


簡単に説明しておきますと、

高周波というのは「よーく見ないと見えないもの」で、逆に低周波というのは「ボケーっと見てると見えてるもの」です。

なので、「高周波画像と低周波画像を合成している」画像を近くで見たり、目を見開いて見ると、高周波画像が見えてくるわけです。逆に、遠くから見たり、目を細めたりすると、低周波画像が見えてくるわけです。ここで、女性を高周波画像として、男性を低周波画像としておけば、目を見開いて見れば「女性の画像」、目を細めれば「男性の画像」ということになるわけなんです*2


さて、この高周波/低周波というものは、みなさんがよくご存知のJPEGという圧縮技術や、マニアックなところでは電子透かし(wikipedia:電子透かし)という技術でも使われているタネなので、画像処理においてはちょっとした人気者です。


その人気者は、SSIMでも登場します。前回、前々回やっつけておいた「ガウシアン・フィルター」や「ディスタンス」が、それです。


「ガウシアン・フィルター」も、「ディスタンス」による「ダウンサンプリング」も、両方とも、画像をボケーっとさせる操作です。先ほどの話と関連させると、高周波を切り捨てて、低周波だけを見るようにする操作です。


先ほど確認したように、

高周波というのは「よーく見ないと見えないもの」で、逆に低周波というのは「ボケーっと見てると見えてるもの」です。


SSIMというのは、そもそも、「人間が目で見て、似てると感じる度合いを数値化したもの」です。このとき、「人間が目で見て」というのは、

目をおっぴろげて、重箱の隅を精査するように観察して、ちょっとでも違いがあれば、ダメじゃないかー

というような意味ではなく、

ジャージ姿でコーヒーでも飲みながら、気楽に二つを見比べてみると、なんか似てるって感じぃ〜

くらいの意味に近いわけです。


なので、SSIMを計算するときには、「ガウシアン・フィルター」や、「ディスタンス」による「ダウンサンプリング」により、画像をボケーっとさせてから、計算するんです。SSIMってのは、そーいうものなので、ちゃんと覚悟をして、電子化の仕様書に入れてくださいね。


ちなみに、PSNRというのは、

目をおっぴろげて、重箱の隅を精査するように観察して、ちょっとでも違いがあれば、ダメじゃないかー

というような計算方法を取りますので、人間の感覚とは異なる結果を生み出す可能性があるんですよ。

*1:日本語なら、http://sasapong.s41.xrea.com/diary/archives/001983.phpあたりを参考にしてください

*2:つまり、お題画像の右側のことですね

SSIMを計算する時に出てくるディスタンス

本日のお題画像:


これまでの流れを整理します。
まず、SSIMとPSNRの比較をし、

SSIMってのは、無限のバリエーションがあるので、SSIM値を指定して電子化発注をする場合、ちゃんと具体的な計算式を指定しないと、いけないよ

っぽいことを主張し、その無限のバリエーションが発生する原因は、様々なのですが、とりあえず、ガウシアンフィルターとディスタンスというものを例示しました。


そんで、前回は、ガウシアンフィルターをやっつけましたので、本日は、ディスタンスをやっつけに行きましょう、という流れです。*1


ディスタンスというのは、本名、「Viewing Distance」で、

画像を見ている人が、どんくらいの距離から見ているのか

ってことです。


SSIMの計算はコンピュータが行うので、「どんくらいの距離から見ているのか」というのは、あくまで比喩です。しかし、なかなかすばらしい比喩だと思います。


一般的に、近くから見ている場合、画像の詳細までくっきりと見えるわけですが、遠くから見ていると、画像の詳細までは分かりません(よね?)。


このことをSSIMの計算の中に入れ込みとすると、遠くから見る場合、距離に応じて、解像度を下げれば良いわけです。こういう操作のことを、ダウンサンプリングと言います。


つまり、

以下の右図が元画像だとして、どんどん離れていくにつれ、真ん中の画像のようになり、さらに遠ざかると、左のような画像になる(矢印は近づいていく方向ですが)

というカラクリです。


ラクリとしては、そんなに難しいことではないのですが、SSIMってのは、画質の指標であるはずなのに、なんで測定のときに、画像をわざわざボカしたりするのでしょうか?例えば、上の一番右の画像の測定をするのに、わざわざ一番左の画像に変換してから、SSIMを測定するとしたら、あなたは納得いきますか?次回あたりに、「なぜガウシアンフィルターを使うのか」という説明と一緒に書きますので、それまで、考えてみてください。


今日のところは、

なぜかは知らないけど、SSIMの測定の前に、ダウンサンプリングを行って画像をボカす慣習がある

と覚えておいてください。


さて、肝心のディスタンス(ボカし具合)は、どのようにして決まるのでしょうか?


SSIMといえば、Zhou Wangさんですので、長いですが、彼の言葉をそのまま引用します。

Suggested Usage

The above (ssim_index.m) is a single scale version of the SSIM indexing measure, which is most effective if used at the appropriate scale. The precisely “right” scale depends on both the image resolution and the viewing distance and is usually difficult to be obtained. In practice, we suggest to use the following empirical formula to determine the scale for images viewed from a typical distance (say 3〜5 times of the image height or width)


http://www.ece.uwaterloo.ca/~z70wang/research/ssim/

というわけで、

SSIMというのは、正しい「スケール」で測定しなくてはいけません。その正しい「スケール」というのは、解像度とディスタンスで決まってくるのですが、正しい「スケール」を見つけるのは容易ではありません。便宜上、画像の幅の3〜5倍のディスタンスから見た画像という想定をオススメします。

というようなことを言っています。


細かい部分はさておき、重要なのは、ディスタンスが「任意」だということです。


ディスタンスというのは、ダウンサンプリングと直結します。もう一度、以下の画像を見ていただくと、

こんなボカす変換が、任意に許されるわけです*2


というわけで、

SSIMってのは、無限のバリエーションがあるので、SSIM値を指定して電子化発注をする場合、ちゃんと具体的な計算式を指定しないと、いけないよ

という主張の意味をご理解いただけたでしょうか?計算式が何も指定されない場合、(少なくとも、)ガウシアンフィルターとディスタンスをイジクれば、SSIMの値を「味付け」することは簡単なんですよ。

*1:返り討ちにあわないように、注意してください。

*2:状況を分かりやすくするために、誇張していますので、ご注意あれ。

SSIMを計算する時に出てくるガウシアンフィルター

本日のお題: window = fspecial('gaussian', 11, 1.5)


昨日、SSIMとPSNRの比較をして、

SSIMってのは、無限のバリエーションがあるので、SSIM値を指定して電子化発注をする場合、ちゃんと具体的な計算式を指定しないと、いけないよ

っぽいことを主張しました。


無限のバリエーションが発生する原因は、様々なのですが、とりあえず、ガウシアンフィルターとディスタンスというものを例示しました。


そんで、本日はまず、ガウシアンフィルターをやっつけようと思います。


ガウシアンフィルターというのは、http://d.hatena.ne.jp/denshikA/20091211でもちょろっと紹介したような、「凸凹を滑らかにするような画像処理」です。なぜ、そんな処理をするのか、ということは、そのうち書きたいと思います。


ガウシアンフィルターについて、詳しく知りたい方は、Akiraさんの解説がよろしいかと思います。
http://imagingsolution.blog107.fc2.com/blog-entry-88.html
http://imagingsolution.blog107.fc2.com/blog-entry-165.html


ひとつだけ、皆さんが理解しやすいように補足しておきますと、Akiraさんが、http://imagingsolution.blog107.fc2.com/blog-entry-165.htmlで載せています以下の画像ですが、

オリジナル画像の
二次元フーリエ変換画像
ガウシアンフィルタ処理後の
二次元フーリエ変換画像

左側は全体的に散らばっている感じで、右側は外側が黒くなった感じですね。この「外側が黒くなった」感じが、「凸凹が滑らかになった」感じです。その観点で見れば、移動平均処理やメディアンフィルタ処理と比べて、ガウシアンフィルターがうまく「凸凹を滑らかにした」様子がわかると思います。


さて、ここまではガウシアンフィルターの一般的な話です。ここからは、SSIMの計算におけるガウシアンフィルターを確認してみましょう。ちょびっとマニアな領域です。


SSIMの計算例で具体的に説明しておきますと、ガウシアンフィルターは、http://www.ece.uwaterloo.ca/~z70wang/research/ssim/ssim_index.mにある、

window = fspecial('gaussian', 11, 1.5);

という部分で作成されて、

mu1 = filter2(window, img1, 'valid');
mu2 = filter2(window, img2, 'valid');

という部分で、フィルターをかけて、凸凹をならしています。
そして、先ほどの

window = fspecial('gaussian', 11, 1.5);

という部分の、11と1.5ですが、これがユーザーが勝手に決めちゃう部分なのです*1。11の部分は奇数じゃないといけないよ、というルールがありますが、それ以外なら、3でも257でも、とりあえずOKなんです。1.5の部分も何でもいいんですが、「凸凹を滑らかにする度合」を調整することができます. 菅谷さんによる下図が分かりやすいと思うのですが、青が1.0で、赤が2.0ですので、1.5というと、その中間くらいです。


http://teo.sourceforge.jp/doc/TeoProgrammingGuide/section5-2.html#fig:5.13


というわけで、本日は、ガウシアンフィルターが何なのか、そして、それがSSIMの計算の中でどのように出現して、どの部分がSSIM無限バリエーションを産んでいるのか、を足早に確認しました。


というわけで、しつこいようですが、SSIMというのは、それほど画一的な指標ではないんですよ、ということをご理解ください。

*1:なので、この部分があるので、SSIMの値は無限のバリエーションができるわけです。そして、この部分をいじることで、SSIMをある程度「演出」できちゃうんですよー。