プラモデルのデカール貼りには、地味に時間を食う作業があります。説明書から、番号を探すことです。
台紙から次に貼るデカールを選び、その番号が説明書のどこにあるかを探す。逆に、いま貼った場所の隣の番号を見て、台紙からそのデカールを探す。この往復を、1枚貼るたびに繰り返します。
そこで、番号を入れたら説明書の該当箇所を光らせるWindows用ソフトを作ることにしました。名前は「AF-DecalFinder」です。
先にお見せすると、5日後にはこうなりました。左が番号の一覧、中央が説明書の全体、右が拡大です。説明書の番号はOCR（画像から文字を読み取る技術）で読み取り、位置ごと覚えています。
ただし、最初からこの形を目指して作ったわけではありません。使っては直し、使っては直しを繰り返した結果です。この連載では、その途中の判断と、AIへの指示を順に紹介します。
第1回は、思い付いた夜から、最初に動いた1.1.0までです。画面を作る前に、まずOCRが本当に使えるのかを確かめました。
※Codexは、コードの実装やテストをAIに任せられるOpenAIの開発ツールです。制作環境は準備編にまとめています。
完成したWindows用ソフトは無料公開中です。→ ダウンロード・動作環境はこちら
デカールを貼りながら、ひらめいた
きっかけは、デカールを貼っている最中でした。そのときChatGPTに送ったのが、この一言です。私はChatGPTを「チャッピー」と呼んでいます。
デカール貼りやっててな、貼るデカールから番号チョイスするときと、隣接番号から貼る場所選ぶケースあるじゃんか。わしひらめいた。コイツをスキャンしてOCRって98番！っつったら98番強調表示してくれるアプリあれば楽ジャンカと
「コイツ」と言って一緒に送ったのが、手元でスキャンしていたテムジンのマーキング図です。
番号は160を超えます。小さな丸数字が引出線の先にびっしり並び、同じ番号が左右の脚などに何か所も出てきます。括弧付きの番号や「49＋118」のような組み合わせもあります。目で探すと、ここで手が止まります。
ちなみに98番は、背面図の左右の脚にあります。
画像生成AIは、きれいでも場所を間違える
話の途中で、試しに「102番ここ！」と示した画像をチャッピーに作ってもらいました。完成形のイメージを見たかったからです。2枚出てきました。
見た目は、作り直した2枚目の方がきれいです。でも、指している場所が違います。正しいのは1枚目でした。よく見ると2枚目は、元の図にない番号や形まで書き換わっています。
番号の位置が正確でなければ、このソフトは役に立ちません。図をきれいに描き直す必要はありません。欲しいのは、元の画像に一切手を加えず、読み取った番号の座標に枠を重ねることです。作る方向は、ここで定まりました。
なお、チャッピーへドラッグ＆ドロップした画像は、2048×1731pxに縮小されて届いていました。手元の600dpi原本は7783×6579pxです。ZIPに入れて渡すと、原本のまま受け取ってもらえました。
やらないことを先に決める
チャッピーとは、どこまで作るかも詰めました。決めたことのほとんどは、「やらないこと」です。
- 読み取るのは数字だけ。デカールには「あいう」や「ABC」もありますが、それは数字がうまくいったときの「バージョン2」に回す。
- 引出線をたどって部品を強調するところまではしない。番号の場所が分かれば十分。
- 検索した番号は、赤枠で全件を強調するだけ。同じ番号が何か所にあっても、まとめて光らせる。
当時の私の言葉です。
うん、線やそれを辿ってのパーツ強調まではいらないかな。100以上の数字をここ!してくれれば十分。ただ、同じ番号が複数の場所にあるケースもおおいからそれはまとめて強調したい
画面は、全体図と拡大図を横に並べる2ビューにしました。拡大図の倍率は100%を中心に、25%から200%まで選べるようにします。
読み取った結果は画像ごとに保存し、次に開いたときは一瞬で再利用する。保存がなければ解析する。ここまでは、この最初の相談の時点で決めています。
OCRが番号を読み違えたときの修正画面も考えました。ただ、このときの見込みはこうでした。
精度にもよるけどそこまで頻繁に使用する機能では無いと思う。
この見込みは、のちに大きく外れます。その話は第3回で書きます。
作るのはCodex、判定はチャッピー
仕様がまとまったところで、チャッピーに聞きました。最初のOCRの検証は、チャッピーと製造担当のどちらがやるのか。製造担当とは、実際にコードを書くCodexのことです。
チャッピーの答えは、実測は製造担当、検証の条件づくりと結果の判定はチャッピー、というものでした。後で同じ処理をWindows用ソフトへ組み込むので、検証のコードも製造担当が書いた方が再利用できます。そのうえで、こう付け加えていました。
製造担当に丸投げすると、検出数だけ報告して「認識成功！」となる危険がある（笑）。
そこで私は、作る順番をこう決めました。
おｋ。今回はCodexさんに頼むことにする。まずはテムジン300/600dpiを動作確認用として渡してOCRさせるに専念しよう。永続化やスプリッター、編集などは後回しで
Codexへ渡した最初の指示書は、「OCR技術検証 Phase 1」です。冒頭で、範囲をはっきり絞っています。
今回はOCRの認識精度と処理速度の評価に専念する。
アプリ本体の実装は行わない。
評価の方法にも、チャッピーの「認識成功！」への心配をそのまま反映しました。
検出数だけで成功と判断しない。
図面の複数領域から評価対象を選び、原本を目視確認して正解データを作成する。
評価の対象には、1桁から3桁の番号、同じ番号が複数ある箇所、括弧付きの番号、引出線が近い番号を含めるよう指定しています。OCRの数字だけを見て喜ばないための条件です。
ちなみに、このときの私はTesseractを知りませんでした。チャッピーに「TesseractってのがOCRのライブラリ？」と聞いています。画像から文字を読み取る、無料のOCRエンジンです。
300dpiを作り損ねて、Codexに指摘される
検証には、同じマーキング図を300dpiと600dpiでスキャンした2枚を渡しました。600dpiが正本です。
300dpiの方は、GIMPで下処理して作っていました。ところが、600dpiのちょうど半分の画素数になっていませんでした。300dpiが3549×3000px、600dpiが7783×6579pxで、比はおよそ2.19倍です。チャッピーには、こうこぼしています。
正確なリサイズじゃなくてCodexさんに怒られた。GIMPで下処理したんだが、dpiに300って打って画素数自動計算してくれなくて。
Codexは単純に2倍として扱わず、2枚の画像の対応する位置を照合して座標を合わせたうえで、同じ番号どうしを比べています。条件がずれたまま比べていたら、どちらの解像度が良いのか判断を誤るところでした。
600dpiなら、38件中33件
Codexは、8通りのOCRの設定を、300dpiと600dpiのそれぞれで3回ずつ実行して比べました。
分かったのは、説明書の画像をそのままOCRに渡しても、ほとんど読めないということです。画像全体を一度に読ませる方式では、正しく読めたのは38件中0〜6件でした。
成績が良かったのは、先に番号の丸を探し、丸の中を1つずつ読む方式です。
| 項目 | 300dpi | 600dpi |
|---|---|---|
| 正しく認識 | 12件 | 33件 |
| 番号の誤認識 | 5件 | 4件 |
| 検出漏れ | 21件 | 1件 |
| 処理時間（中央値） | 0.52秒 | 1.76秒 |
差が大きいのは検出漏れです。300dpiでは38件中21件で、番号の丸そのものを見つけられませんでした。600dpiでは漏れが1件になり、冒頭で触れた98番も、背面図の左右の脚の両方で読めています。
ただし、600dpiでも「77」を「7」、「1」を「4」と読むような誤りは残りました。
この33件は、私が目で確かめた38件での結果です。説明書全体の認識率ではありません。設定を選ぶのにも同じ38件を使っているので、ほかの説明書で同じ成績が出る保証もありません。報告書にも、そう明記されています。
それでも、使えるかどうかを判断するには十分でした。数字を完璧に読めなくても、だいたい読めて場所が分かれば、探す手間は大きく減ります。
1.1.0「うごくぞｗ」
次の指示では、検証した方式の結果を使い、番号を入れると赤枠を出す最小限のビューアを作ってもらいました。ここでも、OCRを組み込むところまではまだ進みません。画像の表示、番号の検索、赤枠の表示を確かめることだけに絞りました。
できたのが1.1.0です。
番号欄に「34」と入力すると、34番に赤枠が付きます。画面下には、OCRで読み取った結果が181件あると出ています。ホイールで拡大縮小し、ドラッグで画面を動かせます。
触ってみた感想を、チャッピーにそのまま送りました。
うごくぞｗ 適当に動作させて体感8割くらい正解
思い付いてから、ここまでで1時間半ほどです。
次回：使ってみたら、決めたことが変わっていく
動くものができると、次に欲しいものが見えてきます。
一覧から番号を選びたい。選んだ番号の場所へ画面を動かしてほしい。600dpiの画像を動かすと重い。
次回は、一度は「これで十分」と決めた画面の配置を、使ってみてから変えていく話です。
前の記事：ShareXの編集機能を、自分専用に作り直す。重すぎた1.0.0から毎日使えるAF-ImageEditor 1.3.0へ
コメント