エントリー

国税連携とOCRの話

国税連携で配布される申告書の画像は200dpi(203dpi)ですが、税務署のOCRシステムが、この解像度の画像にOCR処理を掛けているとは思えません。OCR認識をさせるのであれば、少なくとも300dpiは欲しいと思います。またモノクロ2値画像では認識率も落ちますので、昨今はカラー画像で罫線消去を行うのがスタンダードですから、カラー画像処理を行っていると想像するわけです。

対して、自治体で処理する場合には、モノクロ2値の解像度の低い画像で処理を行わなければならないので、それだけでもハンディキャップがあるわけです。

昨日、思いもよらないエラーに遭遇しました。
認識した数字が、「83e2000」と言う文字列でした。本当は、「8302000」なのですが、83の次の0が歪んでいたために、eと誤認識してしまったのです。この数値を受け取る変数が倍精度実数だったために、10e±308迄の制限があったために、変換値を受け取れないエラーが出てしまいました。数字を数値に変換する関数は、10e±4096(拡張倍精度実数)まで対応していたので、変換エラーにはならずに、変数に入れる時点でオーバーフローするというものでした。(対策済み)

さて、今回サンプリングした画像データを見ていてある事に気がつきました。
それは、画像を連続で見ていくとOCRマークの位置が全くぶれていない事です。このことは、2年前にも確認していまして、その事で画像位置検出の精度が向上したと思っていたのです。
ところが、OCRマークの位置は動かないものの、申告書の表はぐらぐら動いていました。これはどういう事なのか?
税務署で画像を採取する際に、このOCRマークによって斜め補正、縦横縮尺、台形補正などを行っていると思いますが、同時に画像の矯正も行っている様です。その際に歪んでしまうOCRマークを改めて置きに行っていると考えられます。我々のOCR認識でもOCRマークにより、斜め補正、縮尺補正、台形補正処理を掛けていたのですが、なぜかパラメータが変移しないのは、このためだったのです。
実際にOCRマーク位置から算出したオフセットとゆがみ補正を掛けた後の読み取り位置の精度が向上しないのはこの為だったのです。

はてさて困りました。
困ってばかりもいられないので、一部のお客様向けに、読み取る場所の外枠線を認識し、その内側に認識処理を掛ける荒技ルーチンを実装してリリースを行いました。精度は期待以上に向上しています。処理時間とはトレードですが。
この処理が奏功するのであれば、2表の処理にも応用を検討しています。本年実装は無理ですが来年なら。
実は、初年度開始時に申告書の位置決めを行うために、この処理を行う基本ルーチンを実装し、検証も完了しておりました。OCR位置が正しく来るものだから、この機能は使う必要が無くなって、そのままお蔵入りしていました。
何事も捨てずに取って置くものだと感じました。

by 千田

ページ移動

ユーティリティ

カレンダー

2021年09月
- - - 1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 - -

検索

エントリー検索フォーム
キーワード

過去ログ

Feed