新規記事投稿

フォロー記事投稿

記事のキャンセル

この↓パワースペクトルについて、もう少し考えてみませう。






すでに気がついているかも知れないが、今回の手法では 128 ピクセル分の周期で、
パワースペクトルが得られるため、文字画像の周波数成分を知りたければ、律儀に
 1 ピクセルごとの濃度( 明るさ )を FFT に与えてやる必要はない。

つまり、128 ピクセル単位の水平方向、垂直方向の濃度であれば良いわけで、FFT 
の入力として、文字画像の濃度投影量が使えるわけだ( これについては、自己相関
特徴のところで、ちょこっと書いてる )。

実際、これまでの文字画像について試したところでも、1 ピクセル単位の場合と、
 128 ピクセル単位の場合とで、どちらも全く同じスペクトルが得られている。

# 同じだから、図は載せないよ〜〜ん


ピクセル濃度と違って、濃度投影量を入力とする場合には、 FFT 自体の計算量は
 1 / 128 に抑えられる。計算の負荷が軽いうえに、結果が同じであるため、応用
時には、この方法を用いると良いだろう。

# 理論に走るか、応用に走るか、ってなところだなぁ ... わしは気に入らんけど。



 MMX Pentium 200 MHz( 512 KB L2-キャッシュ )での実際の処理時間は、

   ピクセル毎の濃度を入力した場合、324 msec

   濃度投影量を入力とした場合、    1.3 msec

といったところで、濃度投影量を使う方が、圧倒的に速く計算できる。


※ 双方とも、画像特徴抽出( 濃度 ) + 入力正規化 + FFT + 出力正規化の処理
   時間だが、濃度投影量の方が、データが少ない分、一連の処理でキャッシュが
   有効に働くようだ。




文字の読み取りに必要な特徴量の計算が、とくにヤヤコシイ画像処理も必要とせず、
 1.3 msec などという速度でまわってしまう。

そのため、基準文字専用、欠け文字専用、汚れ文字専用、といった、それぞれに異
なる性格を持つ文字判定部を、一つのプログラムの中に実装することも可能だろう。

合議制で文字判断を行うような、イカす ! ソフトウェアを書ける時代は、既に来て
いる。



# こういうのが、まじめなプログラマの夢ってやつじゃないのかね？などと、風流を
# 満喫していると、必ず、現実に引き戻されたりもするのだなぁ。夏休みは終わって
# しまった .....