中井技術工房
今なんぼ?
数字判定のからくり
(H23.3.15 改正)
トップ >
今なんぼ? >
ここ
●
基本原理と画像処理に対するスタンス
基本原理はノウハウなので詳しくは説明できませんが、概要だけ述べておきます。
画像処理はアイデアだけの勝負です。要はいかにケチった処理で判定できるアイデアにたどりつくかという話です。
やまかんスポーツのアーチェリーみたいだといつも思っています。
教科書通りの真っ向勝負は時間がかかり、現在のコンピュータでは実用的ではありません。
現実の画像ではハレーションとかゴミとか、いろいろ対処しなければならない問題があるからです。
●
ミクロ判定を捨てマクロ判定している
世の中の画像処理にはさまざまなタイプがあり、たとえば指紋認証はドットを線状にとらえて、渦まいていない、チョン切れている点をつかまえて、その頂点がつくる形状を3角形として判定しています。
これはミクロチェック+マクロ判定かな?
ミクロを捕らえるかマクロをとらえるかは、けっこう悩みましたが、後で述べるような崩れたフォントも取り扱う必要があり、フォントもさまざまあって、マクロチェック優先にすることにしました。
人間はきっとばくぜんと判定していると思ったからです。
ただ、数字の「2」右下とか「7」に左上のフォントの跳ね返りとかに結構なやまされ、試行錯誤の末に、判定の前処理を工夫しました。
結果、ミクロ処理+マクロチェックという方式になっています。
ここまで到達するのに数年を要しました。
変人なので、人と違うことをするには才能があると自負していましたが、やっぱ日本人!大したことねえ、と落ち込みそうじゃが。
●
処理手順
次の手順で一定インタバルにて処理します
- 安定画像取得。
- 画像補正(サイズの統一、明暗補正)
- フォント列の上下端検知
- フォント列の左右分割、以下数字ごとの処理
- 有効ドット検出と上下左右のノイズ取り
- 数字以外の除去
- 数字認識
- 数字の音声読み上げ
以下これらについて説明します。
●
安定画像取得
ネット上のマーケット情報はどんどん切り替え表示されます。
指定されたゾーン画像を繰り返しサンプリングし、切り替え中ならドットが安定していませんので捨て、複数回同じ画像が得られるまでサンプリングを繰り返します。
●
画像補正(サイズの統一、明暗補正)
まちまちな画像を取り扱うため、サイズの統一、明暗補正が必要です。
これは判定基準を統一し、単純化できるという重要な役割があります。
画像をそのままに、判定基準をそれに合わすという考え方もありますが、コーディングがめんどうですので、最初に画像の方を補正します。
このとき、極力画像のエッジがこわれないような変換手法を選ぶ必要があります。いいかげんにやるとフォントが崩れてしまい、判定に影響します。
●
フォント列の上下端検知
数字列は当然ながら横に並んでおり、0〜9とも上下端間にドットがつまっています。
画像全体の上下方向のドット分布を調べるとアンダーラインとか、上部のノイズなどは除去できます。
●
左右フォント分割とノイズ取り
まず数字認識候補のフォント(らしきもの)の左右方向の分割が必要ですが、これはけっこう悩まされました。
フォントが崩れていて、いったいどこが切れ目なんじゃ?
縦横比から2桁というのはわかるが。
数字判定をあいまいにしてゾーン判定のええかげんさを帳消しにして逃れることにしました。(毒をもって毒を制す、かな?)
4の右端のドットと9の左端有効ドットは横方向にはオーバーラップしていて、結局連結法を持ち込んで切れ目を確認しました。(やりすぎかも。)
1つの桁が1というのも悩みの種で、1だけは幅が狭く、文字幅を想定して分割するのが困難になります。
「1」というフォントも帽子があるやつ、足があるやつ、傾いているやつ、とかいろいろありました。
左右からけっこう「妨害」してきます。数字判定の前にこれらを除去します。
●
数字以外の除去
数字以外の「、」「.」「:」などを除きます。
これらはドット分布の2次モーメントや分散を求めれば数字と区別できます。
今のところ「+」「−」はゾーンに含めないという条件をつけていますが、「−」もこの方向で除去できます。
●
有効ドット検出と上下左右のノイズ取り
判定に悩まされたものの1つに、「2」の右下の跳ね上げ、「7」の左上の垂れ下がりなどの、「跳ね返り」があります。
これれらは有効ドット連結処理に工夫をこらして取り除くことにしました。
これでずいぶん判定が楽になりました。
●
数字判定
本ソフトの数字判定の基本は、マクロチェックです。
Fourier は一部使いましたが、他の数学的なチェックはせいぜいモーメント、分散までです。
上下の丸みを数学的にとらえようとしたこともありますが、いろんなフォントがあり処理時間の割りに精度は出ませんでした。
高級数学は時間がかかるのもいやでしたし、FFT などはドット数に制限をつける必要があり、これもいやでした。
結局採用したのは次のような基準です。
- 「0」−−上下対称分布。中央部が空いている。
- 「1」−−幅/高さ比が小さい。帽子と足の部分をのぞくと水平方向の分散がきわめて小さい。
- 「2」−−下端に水平線あり、左は下が空いている、右も下が空いている。
- 「3」−−ドットが右寄り、左側中央部が空。
- 「4」−−下の方へ行けば行くほどドットが増える。足があるのが特徴。
- 「5」−−上端に水平線あり、左は下が空いている、右は上が空いている。
- 「6」−−ドット分布が下寄り、右上が空いている。
- 「7」−−上端に水平線あり、その他は水平方向の分散が非常に小さく、上へ行くほと右寄り。
- 「8」−−上下対称分布。中央部がふさがっている。
- 「9」−−ドット分布が上寄り、左下が空いている。
こんなものでたいていの数字は正常に判定できますが、いろいろなフォントがあり、各数字とも2〜3種の特徴を判断するようにしています。
別な判断基準も適用しています、という意味です。
コーディングはまだやっていませんが、書き順をフォローして判定する、というのはあり、かなと思っています。
左上、もしくは右上のはじをとらえて、一筆書きをやる要領で有効ドットをフォローする、というやつ。
車で走っていて、前の車のナンバーを見ていて思いつきました。
だいたい、車のナンバーとか車検ステッカとか、車がらみの処理ばかりやってきたので、車に乗っているときにそういうことばかり
考えてあぶなくてしょうがない。
●
数字読み上げ
数字読み上げはWav ファイルを Windows API を使って実行します。
数字該当のWav ファイルをAPI に渡すだけですが、タイミング調整とかも必要です。
でも想像以上に簡単でした。
ここで設定条件により、前回読み上げ数字と同じ数字が判定されたときはパスする、とかします。
なお、Microsoft Agent は使い物になりませんでした。
トップ >
今なんぼ? >
頁トップ