前回までで、テムジンの説明書1枚を相手にした作業は、かなり楽になりました。番号を入れてEnterを押せばその場所へ飛び、貼ったら済みのチェックを付ける。閉じて開けば、前回の続きです。
ところが、別のキットの説明書を開いたところで、つまずきました。
今回は、1.6.2から1.8.1までの記録です。テムジン以外の説明書へ広げたら、OCRの結果は思ったほど良くありませんでした。そこで、OCRを完璧に近づけるのではなく、直しやすくする方向へ切り替えました。第1回で「そこまで頻繁に使用する機能では無いと思う」と書いた修正の機能が、主役になる回です。
完成したWindows用ソフトは無料公開中です。→ ダウンロード・動作環境はこちら
別の説明書を開いたら、赤枠が出なかった
1.6.1で、手元にある別のキットの説明書を開きました。
画像とOCR結果の寸法が合わない、という警告です。OCR結果の寸法7783×6579は、テムジン600dpiの寸法そのものでした。
もしかして画像ごとじゃなくてアプリとして一組しかスキャン情報持ってない？
ここまでは、テムジンの読み取り結果を1組だけ用意して試していました。Codexへの1.6.2の指示書では、ここでも直し方より先に調べ方を書いています。
推測で修正せず、原因となったコード経路を報告してください。
原因は、画像ごとのデータがないときに、テムジンの読み取り結果を無条件で読み込む経路が残っていたことでした。1.6.2では、テムジンの原本と一致したときだけその結果を使い、それ以外の画像は「未解析」と表示するように直しました。
続く1.7.0では、データのない画像を開くと、その場でOCRを実行するようにしました。第1回で検証した方式を、そのまま呼び出す形です。進捗の表示は要らないが、待っている間は砂時計を出してほしい、と頼んでいます。
条件の悪い説明書を、あえて混ぜる
検証用に、手元にある6つのキットの説明書をスキャンして追加しました。テムジンの300dpiと600dpiを合わせて8枚です。わざと条件をばらつかせています。
背景白じゃなかったり完全モノクロだったり300dpi混ざってるし、あえてABCあいうあるのも突っ込んでみた
あとはドライデカールとマーキングの凡例違いで白抜き、黒抜きも混ざってる
8枚の中で一番条件が悪いと見ていたのが、このRGルージュです。背景が白ではなく、白い丸の番号と黒い丸の番号が混じっています。
1.7.0でOCRを走らせた結果、テムジン600dpiは181件読めました。一方で、ほかの説明書では3件から67件。説明文や図形を番号と間違えたり、桁が落ちたりする例も多く出ました。報告にも、汎用的な認識精度は足りないと書かれています。
誤検出は打ち替えるだけ、未検出は座標から
ここで、チャッピーと方針を考え直しました。私の見立ては、こうです。
正解率6～8割くらいで最初はLV活用でOCR修正フェーズ、んで綺麗になったところで貼りフェーズと割り切ってもいい。
OCRの結果を、最初から正しくしようとしない。まず一覧で直す作業をして、きれいになってから貼る作業に移る。2段階に分ければいい、という考えです。
では、直す作業で何が面倒なのか。
編集で誤検出は特定して打ち替えだけだからそんなに手間ではない。未検出が座標指定込みなのでやや面倒。どちらかというと○検出を詰めたい。
番号を読み違えていても、丸の位置さえ見つかっていれば、一覧で番号を打ち替えるだけで済みます。丸そのものを見落とされると、画像の上で位置を指定して番号を足す必要があります。だから、番号を正しく読むことより、丸を見落とさないことを優先する。
さらに、方針をこう決めました。
この方向で○検出、修正はごく希じゃなくて通常操作前提でUIUX改善させる方向でまずはここまでの内容で作ってもらおう
あわせて、番号は数字に限らず文字として扱い、ABCやあいうも手で入力できるようにする。丸ではないものを拾ったときのために、済みではなく削除できるようにする。第1回で「バージョン2」に回した英字・かなは、OCRで読むのではなく、手で直せるという形で入りました。
指示書の「開発目的」に、そのまま書いた
Codexへ渡した1.8.0の指示書は、冒頭の「開発目的」で、ソフトの使い方を2段階として定義しています。
Phase A：OCR結果の整備
画像を読み込んでOCRを実行し、検出結果をユーザーが確認・修正・追加・削除して正しい番号一覧を作る。
Phase B：デカール貼付作業
整備済みの番号一覧を利用し、検索・位置移動・貼付済みチェックを行う。
OCR修正は例外操作ではなく、通常の利用フローです。修正の操作回数と負担を減らすことを重視してください。
OCRの改善についても、優先順位を書きました。
数字の認識正解率より、番号を囲む○ラベルの検出率を優先してください。
理由として挙げたのは、チャッピーとの会話で出てきたことそのままです。番号の誤りは一覧から簡単に直せる。丸の見落としは座標の指定が要る。背景が白とは限らない。丸の中には、ほかの図形や文字はふつう重ならない。
番号を読めなかった丸も捨てずに、「?」として残すよう指定しています。丸の位置さえ残っていれば、あとは番号を入れるだけで済むからです。
1.8.0：見落としは56個から1個へ。誤検出は増えた
1.8.0では、丸の探し方を何通りか組み合わせるようにしました。黒い丸、色の付いた丸、背景が白でない丸も拾えるようにするためです。
8枚の説明書から評価用の範囲を選び、そこにある丸88個を、OCRを走らせる前に目で数えて記録しました。その88個で、1.7.0と1.8.0を比べた結果です。
| 項目 | 1.7.0 | 1.8.0 |
|---|---|---|
| 丸を見つけた | 32個 | 87個 |
| 丸を見落とした | 56個 | 1個 |
| 丸でないものを拾った | 8個 | 17個 |
見落としは、ほぼなくなりました。その代わり、丸でないものを丸として拾う誤検出が倍に増えています。OCRにかかる時間も、1枚あたり0.75〜2.04秒から2.19〜5.64秒に延びました。
全部の候補を選んで青い枠を出すと、番号の丸のほかに、頭部や胸のダクトの丸い形にも枠が付いています。
誤検出が増えることは、指示を出す前から覚悟していました。
誤検出増えるのはしゃーなしだとおもう。
チャッピーに、誤検出をもっと減らせないかとも聞いています。そのうえで、改めて方針を書きました。
繰り返しになるが、追加より削除が楽なので怪しいモノは残す方針は変わらない。その条件でベストエフォートだ
丸でないものを拾っても、削除すれば済みます。見落とした丸は、自分で探して座標を足さなければなりません。怪しいものは残しておいて、人が消す。この考え方は、このあとの画面づくりにも続きます。
枠の大きさがばらばら
1.8.0を使ってみて、もう一つ気になったことがあります。
丸全体を囲む枠と、数字だけを囲む小さな枠が混じっています。見た目がそろわないだけでなく、小さい枠はクリックで狙いにくい。
サイズが検出数字ギリのケースと○含むケースがバラバラだからその見た目およびヒットテストを統一したい。
ヒットテストは、クリックした位置にどの番号があるかを判定する処理です。
そこで、画像の中の丸の大きさから代表的なサイズを決め、枠をそろえることにしました。ただし、OCRが出した元の座標は書き換えません。
ヒットテストと表示は検出した○の中心優先でよいとおもう。ただOCR元座標は粛正するべきでは無いとも思う
1.8.1では、丸の大きさの中央値から±30%に入るものの平均を代表サイズにしました。表示とクリック判定にはこの大きさの枠を使い、OCRの元の枠と信頼度はそのまま残しています。
2パスで探す案は、採用しなかった
代表サイズを決めるなら、もう一つ試したいことがありました。
あと基準サイズ算出して2パス許容っていったのは単純に○を探すのではなく一定サイズ、ある程度許容、の○を探すに絞れば検出率よくなるとおもったのだがそういうわけでもない？
1回目で丸の大きさを調べ、2回目はその大きさに近い丸だけを、条件を緩めて探し直す。そうすれば、見落としがさらに減るのではないか、という案です。
Codexは実装して、同じ88個で比べました。結果は、見つけた丸が1個増える一方で、誤検出が5個増え、探す時間も延びました。報告は不採用です。チャッピーへの報告は、この一言から始まっています。
悲報：2パス不採用
自分で出した案でも、測って効果がなければ入れません。
1.8.1では、番号を読めなかった「?」だけを一覧に出す「未認識のみ表示」も足しました。全部選ぶと、枠の大きさはそろっています。ただ、一覧は「?」ばかりで、どれが本物の番号の丸で、どれが誤検出なのか、一覧からは分かりません。
次回：人の目で選び、キーで片付ける
誤検出を残す方針にした以上、残ったものを片付ける作業は速くなければいけません。
最終的には運用者の手数を減らすことだから検出率ではなくここでUIを詰めたい。
次回は、「?」の山を人の目で選り分ける操作と、棚卸モードができるまでの話です。
前の記事：左固定で十分、のはずだった。使ってから変わった画面【AF-DecalFinder 第2回】
コメント