JP4117648B2 - 帳票、帳票処理方法、帳票処理プログラム、帳票処理プログラムを記録した記録媒体及び帳票処理装置 - Google Patents
帳票、帳票処理方法、帳票処理プログラム、帳票処理プログラムを記録した記録媒体及び帳票処理装置 Download PDFInfo
- Publication number
- JP4117648B2 JP4117648B2 JP2003165876A JP2003165876A JP4117648B2 JP 4117648 B2 JP4117648 B2 JP 4117648B2 JP 2003165876 A JP2003165876 A JP 2003165876A JP 2003165876 A JP2003165876 A JP 2003165876A JP 4117648 B2 JP4117648 B2 JP 4117648B2
- Authority
- JP
- Japan
- Prior art keywords
- code
- information
- data
- entry frame
- histogram
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Character Input (AREA)
Description
【発明の属する技術分野】
本発明は、帳票、帳票処理方法、帳票処理プログラム、帳票処理プログラムを記録した記録媒体及び帳票処理装置に係り、特に、窓口やオフィス等で利用される帳票読み取りに利用可能な、帳票側に処理方法が記述された帳票、その帳票を処理するための帳票処理方法、帳票処理プログラム、帳票処理プログラムを記録した記録媒体及び帳票処理装置に関する。
【0002】
【従来の技術】
従来、紙とコンピュータ処理の橋渡しとして、光学帳票読取り装置や、紙上の筆記から動的に運筆情報を読み取るタブレット、e−pen、Anoto penなどの装置が知られている。しかし、後者は、筆記時に特別なデバイスが必要となる。
また、帳票の記入枠から手書きを抽出するために、記入枠にドロップアウトカラーが用いられることがある。しかし、カラーの使用はコストを高め、現在広く使われているモノクロコピー、モノクロファックスが利用できなくなるという課題がある。印刷コストや読取り装置のコスト、モノクロファックスの利用などの理由から、ドロップアウトを用いた帳票は減少し、モノクロ帳票が主流になりつつある。また、レーザビームプリンタの高精度化や、PostScriptなどのページ記述言語の一般化により、微細なドットテクスチャからなる帳票を安価なプリンタで印刷することが可能になっている。さらに、帳票作成エディタを作成することにより、誰でも簡単に帳票をデザインすることができる。手書きの帳票は入力が容易で、かつ、証拠として残ることから、電子化が進んでもなくならず、その手軽な電子化のニーズは高まっている。
【0003】
なお、ドットで構成された記入枠を有する帳票に対する処理方法が提案されている(例えば、特許文献1、非特許文献3参照)。また、帳票に記入された文字を認識し、修正する方法が提案されている(例えば、特許文献2、3参照)。帳票側に処理を記載したアクティブ帳票システムが提案されている(例えば、特許文献1、非特許文献1、2参照)。
また、線や交点の検出から帳票構造を認識する方法が提案されている(例えば、非特許文献4、5参照)。
【0004】
【特許文献1】
国際公開 第01/93188号パンフレット
【特許文献2】
特開2001−052110号公報
【特許文献3】
特開2001−052111号公報
【非特許文献1】
島村太郎、朱碧蘭、増田厚司、小沼元輝、櫻田武嗣、黒沼靖、中川正樹、「アクティブ帳票システムの設計と試作」、信学技報、2002年12月、PRMU2002-132、Vol.102、No.531、pp.19-24.
【非特許文献2】
朱 碧蘭、島村 太郎、中川 正樹、「アクティブ帳票処理技術の試作」、電子情報通信学会、信学技報、2002年12月、PRMU2002、Vol.102、No.531、pp.25-30.
【非特許文献3】
前田陽二、中川正樹、「ペーパインタフェースによる文書編集方式」、情報処理学会論文誌、2000年、Vol.41、No.5、pp.1308-1316.
【非特許文献4】
T. Watanabe, Q. Luo, and N. Sugie, 「Layout recognition of multi-kinds of table form documents」, IEEE Trans. on Pattern Analysis and Machine Intelligence,1995, Vol. 17, No. 4, pp.432-334.
【非特許文献5】
L. Y. Tseng and R. C. Chen, 「Recognition and data extraction of form documents based on three types of line segments」, Pattern Recognition, 1998,Vol. 31, No. 10. pp.1525-1540.
【0005】
【発明が解決しようとする課題】
しかしながら、モノクロ帳票では、帳票記入枠と手書きの分離が困難な場合があった。例えば、手書き文字が記入枠と重なった場合や、帳票の汚れ及び読み取りノイズがある場合には、正確に分離できない場合があった。また、記入された文字は、文字認識することが可能となっているが、なお誤読が生じる場合がある。特に、メールアドレスの認識には文脈処理が使えず、また、その後の処理に大きな影響を与えることが想定される。
本発明は、以上の点に鑑み、窓口やオフィス等で利用される帳票読取りに利用可能で、帳票記入枠と記入文字の分離が容易な帳票及び帳票処理方法、帳票処理プログラム、そのプログラムを記録した記録媒体及び帳票処理装置を提供することを目的とする。また、本発明は、記入文字の認識率を高めることを目的とする。さらに、本発明は、装置側でなく帳票側に帳票それ自身の処理方法を記述し、読取装置として汎用機を用いることができ、及び、多種の帳票を一台で処理することを目的とする。
【0006】
また、本発明は、重畳する情報量を高めるためのドット形状を有する帳票及び帳票処理方法を提供することを目的とする。本発明は、手書きとの重なりや汚損から重畳情報を安定に読み取るためのコーディング方式及びデコーディング方式を提供することを目的とする。また、本発明は、特に誤読しやすい英数字記号などの補助記入方式を提供することを目的とする。さらに、本発明は、エディタで簡易に作成し、プリンタで印刷できる帳票を提供することも目的のひとつである。また、本発明は、記入枠の行間の画像をスキャンする手間を省略し、処理時間を短くすることも目的とする。
【0007】
【課題を解決するための手段】
本発明は、記入枠に微細なドットで構成されたドットテクスチャを用いることでモノクロ環境下でも手書きとの分離を容易にし、また、そこに手書き記入の属性や読取り後の指示情報を重畳することで完全に帳票側が処理を主導するアクティブ帳票において、次のことを提供する。
記入枠内に情報を重畳するためのコード形状として、ドットテクスチャにより安定かつ大量に情報を重畳できるように、ドット形状を提案する。
【0008】
また、コード図形の認識方法として、四方向のヒストグラムによる認識方法及び部分的な走査による認識方法を提案する。四方向のヒストグラムによる認識方法では、コードの画像に対し四方向のヒストグラムをとることによって、コードの形状特徴を判断しコードを認識する。部分的な走査による認識方法では、部分的にコード画像を走査することにより、コード図形中の線分があるべき位置ごとに順番に走査し、線分があれば対応の情報ビットを1とし、線分がなければ0とする。
【0009】
また、記入枠の安定な検出方法として、ドットテクスチャによる記入枠の検出を容易にするために、各ドットに膨張処理をしてから縦および横方向にヒストグラムを取ることで、安定に記入枠を検出する。
帳票内の記入枠の間には空白があるので、空白の処理時間を省いて高速化する。記入枠と手書きの分離をしなくても手書きを含んだままで記入枠の行検出は行えるので(行内の位置検出には手書きが邪魔になるが、行の検出には邪魔にならない)、手書きを分離する前に行検出を行い、一行ずつの画像だけに対してラベリングをすれば、行間でのラベリング処理が省ける。
【0010】
また、記入枠の境目を検出するときにノイズの影響を未然に防ぐ方法を提案する。縦あるいは横方向へのヒストグラムにより記入枠の位置を検出するとき、ノイズの妨げを避けるために、ヒストグラムの結果に対してある閾値以下の値を0と見なして、ノイズのある場所でも空白として無視する。こうすることにより、ノイズの影響を受けず、記入枠の位置を検出できる。しかし、閾値以下の値を0とみなしているため、記入枠の境のところで閾値以下の情報も無視されてしまい、記入枠の中に重畳した情報を読み取るには悪影響を与える。記入枠の位置を検出する時に、このような情報損失を防止するために、ヒストグラムで閾値以下のところで記入枠の位置を検出してから、さらに、この位置から記入枠の外側の方向にヒストグラムの値を辿って行き、ヒストグラムの値が0より大きい値から0になった位置、あるいは、始めの位置fから辿った長さがある閾値を超えてもヒストグラムの値が0にならない場合には始めの位置fから外側に閾値分だけずらした位置を記入枠の開始あるいは終了の位置とする。
【0011】
また、ドットテクスチャの文書が多少傾いてスキャンされてもコード図形を切り出す方法として、ドットテクスチャにおけるドットの行数はドットの列数にくらべて少なく、縦方向へのヒストグラムの重なりは小さいことを利用して、ドットテクスチャの画像に対して縦方向のヒストグラムにとり、情報バーの左から右へ列ごとに切り出す。次に、列ごとの画像に対して横方向のヒストグラムをとり、コードごとの図形を切り出す。
【0012】
手書きと重なって消された情報レコードを検出して読み飛ばす方法として、情報バーの画像において、左から右へ列ごとのコード図形を切り出していき、前の列と次の列の間隔が想定される幅より大きいときにコード図形と手書きが重なって手書きの分離処理によりコード図形が欠落したと判断して、この後のコード図形に対して、区切り記号が見つかるまで無視する。そうではない場合、列のコードを切り出して認識し処理を行う。
各コード図形に微小なノイズが付着して連結してしまったり微小なノイズをコード図形として処理してしまったりする誤りを防止する。例えば、切り出した図形の大きさが想定されるコード図形より小さい場合はノイズとして無視し、大きすぎる場合には、想定される大きさで分離して認識することにより、各コード図形に微小なノイズが付着して連結してしまったり微小なノイズをコード図形として処理してしまったりする誤りを防止する。
【0013】
また、情報バーの位置検出誤差への対応方法を提案する。記入枠の情報バーとそれ以外の部分との境界線は正しい情報バーの境界線から誤差を含んで検出される場合がある。この検出された情報バー境界線に従い、コード図形を切り出してデコーディングを行うと、情報バーからはみ出したコード図形の一部を除外して認識することになり、誤認識を招く危険がある。このことを避けるために、以下の(1)から(4)の処理を実行する。(1)検出した情報バー境界線に従い、情報バーの画像に対して縦方向のヒストグラムにより、左から右へコードの列ごとの位置を検出する。(2)列ごとのコード画像に対して、横方向のヒストグラムを走査し、コードごとを切り出す。記入枠の上側情報バーの切出し方向は上から下へ、下側情報バーの切出し方向は下から上へである。この段階から以後、境界線bの情報を利用しない。(3)一つのコードを切り出した後、この列において切り出したコード数と走査した長さLを調べる。情報バーのコード行数をNとする。もし、この列のコード数がすでにNに達しているか、あるいは、走査した長さLがNに応じた長さまで達していれば、コードの切出しを終了する。そうでなければ、続いてヒストグラムを走査し、コードの切出しを行う。ここで、走査した長さで終了を検出する目的は、コード図形が手書きと重なったりして欠落した場合に、情報バーの領域を越えてコードを探しに行かないようにするためである。(4)列ごとに対して、コードの切り出しが終了した時点で、そのコード数をチェックする。もしNに達してなければ、コード数のエラーと見なし、この後のコード図形に対して、区切り記号が見つかるまで無視する。
【0014】
また、メールアドレスの認識率を高める方法を提案する。メールアドレスに使われる文字は情報量の少ない英数字記号であり文字認識率が低く、また、意味のない文字列のために文脈処理が使えない。メールアドレス誤認識において、主な原因は類似文字への誤認識である。もし、この誤認識を避けることができれば、認識率を高めることができる。そこで、メールアドレスの文字種を限定するために、アクティブ帳票の中でメールアドレス記入枠の近くにもう一つの記入枠を設け、メールアドレスに対して対応するマスの文字種を簡単な記号で記入する。認識のしやすさと人の記入しやすさを考慮し、枠内の上や下、または両方に横線を枠に重なって記入できるようにする。
帳票は、複数の微小なドット(黒領域)又は線分を二次元に配置してなるドットテクスチャで文字入力枠が形成された文字入力用の帳票であって、2次元に配列されたドットの集まりで構成され、複数個のドットを含む幅のある線によるドットテクスチャで描かれた見出し文字と、2次元に配列されたドット又は線分の集まりで構成され、複数個のドット又は線分を含む幅のある線によるドットテクスチャで画成された記入枠とを有する。
【0015】
処理部が、文字が入力された前記帳票から、各ドットが手書きの黒領域より小さく設定されることから、ドットテクスチャを構成する各々のドットが収縮処理により文字画像より先に消えること、又は、定められた閾値より小さい連結成分を除去すること、のいずれかによって、ドットテクスチャによる記入枠画像を除去して、記入された文字の文字画像を検出するための前記帳票を対象とする。
本方式では、微小なドットで構成されたドットテクスチャからなる記入枠を使用することによって、モノクロ環境において、手書きが記入枠に重なっても容易に分離できる。また、記入枠の中に手書きの属性、文字種を埋め込むことで、切り出した手書き文字に対して認識率を高めることができる。手書き文字の内容を属性、見出しの情報と対応付ければ、帳票ごとの設定をなくすことができる。さらに、読取り後の手書きに対する処理方法を埋め込むことで、帳票を読み込ませるだけ帳票に応じた処理を帳票側で指示するシステムが実現できる。いままで処理システム側に必要とされていたプログラムを帳票側に埋め込むことで帳票がアクティブになる。これが「アクティブ帳票」の由縁である。
【0016】
本発明の第1の解決手段によると、
線分の傾斜又は複数の線分の組み合わせで情報が表現されるコードで構成される記入枠データと、記入された手書きデータとを含む帳票画像データを入力する帳票入力ステップと、
前記帳票入力ステップで入力された帳票画像データに基づき、記入枠データと手書きデータを分離し、及び、各記入枠データと、コードにより所定の情報が重畳された当該記入枠データ内の情報バーとを検出する記入枠検出ステップと、
検出された情報バーの各コードを切り出すステップと、
切り出されたコードの、縦方向と、横方向と、右斜め方向と、左斜め方向との四方向のヒストグラムを求めるステップと、
求められた四方向のヒストグラムに基づき、コードの形状特徴を判断し、コードを認識するコード認識ステップと
を含む帳票処理方法、これら各処理をコンピュータに実行させるための帳票処理プログラム及びそのプログラムを記録したコンピュータ読み取り可能な記録媒体が提供される。
【0017】
本発明の第2の解決手段によると、
ドットの幅又は線分の傾斜又は複数の線分の組み合わせで情報が表現されるコードで構成される記入枠データと、記入された手書きデータとを含む帳票画像データを入力する帳票入力ステップと、
前記帳票入力ステップで入力された帳票画像データに基づき、記入枠データと手書きデータを分離し、及び、各記入枠データと、コードにより所定の情報が重畳された当該記入枠データ内の情報バーとを検出する記入枠検出ステップと、
前記記入枠検出ステップで検出された情報バーの各コードを認識し重畳情報を抽出する重畳情報認識ステップと、
前記記入枠検出ステップで分離された手書きデータに対して、抽出された重畳情報が示す手書きデータの属性及び/又は文字種類に従い文字認識を行う文字認識ステップと、
前記文字認識ステップで認識された文字情報と、前記重畳情報認識ステップで抽出された重畳情報に基づき、他のアプリケーションシステムに所定の処理をさせるための命令書データを作成する命令書作成ステップと、
前記命令書作成ステップで作成された命令書データを出力する、及び/又は、前記帳票入力ステップで入力された帳票画像データと、当該命令書データとを対応させて記憶するステップと
を含む帳票処理方法、これら各処理をコンピュータに実行させるための帳票処理プログラム及びそのプログラムを記録したコンピュータ読み取り可能な記録媒体が提供される。
【0018】
また、本発明の第3の解決手段によると、
線分の傾斜又は複数の線分の組み合わせで情報が表現されるコードで構成される記入枠データと、記入された手書きデータとを含む帳票画像データを入力する帳票入力部と、
入力された帳票画像データの記入枠を検出し、及び、記入枠内のコードを認識する処理部と
を備え、
前記処理部は、
前記帳票入力部から帳票画像データを入力する手段と、
前記帳票入力部から入力された帳票画像データに基づき、記入枠データと手書きデータを分離し、及び、各記入枠データと、コードにより所定の情報が重畳された当該記入枠データ内の情報バーとを検出する記入枠検出手段と、
検出された情報バーの各コードを切り出す手段と、
切り出されたコードの、縦方向と、横方向と、右斜め方向と、左斜め方向との四方向のヒストグラムを求める手段と、
求められた四方向のヒストグラムに基づき、コードの形状特徴を判断してコードを認識するコード認識手段と
を有する帳票処理装置が提供される。
【0019】
本発明の第4の解決手段によると、
ドットの幅又は線分の傾斜又は複数の線分の組み合わせで情報が表現されるコードで構成される記入枠データと、記入された手書きデータとを含む帳票画像データを入力する帳票入力部と、
帳票画像データ及び/又は帳票画像データに基づき作成される命令書データが記憶される記憶部と、
入力された帳票画像データに記入された手書きの情報と、記入枠に重畳された情報を認識し、所定の処理を実行する処理部と、
を備え、
前記処理部は、
前記帳票入力部から帳票画像データを入力する手段と、
入力された帳票画像データに基づき、記入枠データと手書きデータを分離し、及び、各記入枠データと、コードにより所定の情報が重畳された当該記入枠データ内の情報バーとを検出する記入枠検出手段と、
前記記入枠検出手段で検出された情報バーの各コードを認識し重畳情報を抽出する重畳情報認識手段と、
前記記入枠検出手段で分離された手書きデータに対して、抽出された重畳情報が示す手書きデータの属性及び/又は文字種類に従い文字認識を行う文字認識手段と、
前記文字認識手段で認識された文字情報と、前記重畳情報認識手段で抽出された重畳情報に基づき、他のアプリケーションシステムに所定の処理をさせるための命令書データを作成する命令書作成手段と、
前記命令書作成手段で作成された命令書データを出力する、及び/又は、前記入力する手段で入力された帳票画像データと、当該命令書データとを対応させて前記記憶部に記憶する手段と
を有する帳票処理装置が提供される。
【0020】
また、本発明の解決手段のひとつでは、前記記入枠検出ステップ及び記入枠検出手段は、帳票画像データに対する横方向及び縦方向のヒストグラム又は線分検出並びに/若しくは交点検出に基づき、各記入枠データと、コードにより所定の情報が重畳された当該記入枠データ内の情報バーとを検出する。
【0021】
さらに、本発明の第5の解決手段によると、
ドットの幅又は線分の傾斜又は複数の線分の組み合わせで情報が表現されるコードにより、所定の情報が重畳された情報レコードが複数の行に渡り配置される情報バーを有し、該コードにより構成される記入枠と、
前記コードより構成され、帳票又は前記情報バーに関する情報を含む水平バーと
を備える帳票が提供される。
【0022】
【発明の実施の形態】
1.アクティブ帳票とその処理システムの概略
1.1 アクティブ帳票
図1は、アクティブ帳票の構成図である。
アクティブ帳票とは、記入枠に微細なドットで構成されたドットテクスチャを用いることで、モノクロ環境下でも記入枠と手書き文字の分離を可能にし、さらにドットを一様でないように分布させることで、記入文字の属性や読取り後の指示情報を記入枠に埋め込むことができる技術に基づいた帳票のことである。
帳票は、水平バー10と、情報バー30を有する記入枠20とを備える。帳票標題の下などに印刷する横線は水平バー10と呼ぶ。記入枠20と水平バー10はドットテクスチャで印刷される。記入枠のドットテクスチャには、記入される手書きの属性(例えば、人名、住所、メールアドレス、自由筆記など)、文字種(例えば、数字、漢字、英文など)、見出しやその処理方法(例えば、手書き文字を認識する、記載内容をメールで送信する、あるいはデータベースに保存するなど)を指示する情報(重畳情報)を記入枠上下側に重畳する。この情報が重畳される部分を情報バー30という。また、帳票の全体に対する情報を水平バー10に重畳する。また、記入枠の中で文字を一文字ごとに区切って記入してもらうための分割をマス40と呼ぶ。
【0023】
ドットテクスチャによる記入枠では、ドットを水平(行)方向および垂直(列)方向に並べてテクスチャを形成する。記入枠におけるドット行数は、水平バー10も含めて、すべて同一とすることにより、水平バー10のドット行数を求めれば、すべての記入枠のドット行数を容易に知ることができる。また、本実施の形態では、ドット以外に線分の傾斜又は線分の組み合わせで情報が表現されるコード図形に重畳情報を重畳することができる。この線分は、ドットを用いて構成してもよい。なお、以下の説明において、コード図形を単にドットと呼ぶ事もある。
【0024】
1.2 アクティブ帳票処理システム
図2は、アクティブ帳票処理システムのハード構成図である。
アクティブ帳票処理システムは、例えば、処理部1と、帳票入力部2と、出力部3と、記憶部5とを備える。また、アクティブ帳票処理システムは、適宜の入力部、表示部4を備えても良い。アクティブ帳票処理システムは、例えば、読み取ったアクティブ帳票の画像データから記載内容や重畳情報を抽出し、命令書に出力する。なお、処理部の処理の詳細については後述する。記憶部5は、帳票画像データ、帳票画像データに基づき作成される命令書データが記憶される。また、記憶部5には、例えば、コードが示す値と情報が対応したテーブルが予め記憶されている。なお、記憶部5は、例えば標準パタンの特徴値と、その標準パタンが示す情報が対応したテーブルを含むことができる。
【0025】
2. アクティブ帳票の詳細
2.1 情報重畳のためのコード形状
アクティブ帳票では、記入枠ごとにその中に記入される手書きの属性、文字種、見出し、処理方法を指示する情報をそのドットテクスチャの中に重畳する。ドットテクスチャに情報を埋め込む方法の一つとしてドットの形状を変化させる方法が考えられる。そこで、情報を表すいくつかのコード形状について述べる。
【0026】
図3は、大小2種類の図形を用いるコード(大小2種類コード)の構成図である。大きさの違う2種類のドットでバイナリビットの1と0を表し、これに情報を重畳する。2つコードの高さが同じでhとする。大きいドットの幅をLとする。コード間の隙間を考えコードを帳票に均等して配置するための領域をコードの配置エリアとする。各コードの配置エリアの大きさは同じで、コードをその中心に置く。各コードの配置エリアを碁盤の目のように縦横に隙間を空けずに配置すれば、コードとしては隙間を確保したドットテクスチャになる。後述する他の種別のコードも同様に、配置エリアの中心に置いて並べることにより、記入枠のドットテクスチャを生成する。
【0027】
図4は、8方向線分を用いるコード(8方向線分コード)の構成図である。8方向の線分により、0から7までの図4に示す8種類のコードを表すことができる。図4では、各コードの下に示した「000」、「001」などの番号は、これらのコードに対応する2進数の番号である。なお、各コードには、図に示す以外にも適宜の番号を対応させることができる。また、8方向以外にも、所定の角度傾斜した線分を用いた多方向とすることもできる。コードを描画するための同じ大きさの正方形領域を描画エリアと呼ぶ。
【0028】
図5に、描画エリアと配置エリアの関係を示す。描画エリアは配置エリアよりも小さく、配置エリアの中心に位置する。上述と同様に、配置エリアは、碁盤の目のように縦横に隙間を空けずに配置することで、各コードは隙間を確保して配置される。
図6は、212種類の図形を用いるコード(212種類コード)の構成図である。212種類コードは、図6に示すように、12種類の線分の組合せで構成される。大きさa×aの描画エリアを基準とし、これら12種類(12本)の線分の有無により212種類、すなわち、4096種類のコードを作る。
【0029】
図7は、28種類の図形を用いるコード(28種類コード)の構成図である。28種類コードは、図7に示すように、8種類の線分の組合せで構成される。大きさa×aの描画エリアを基準とし、これら8種類(8本)の線分の有無により28種類、すなわち、256種類のコードを作る。なお、28種類コード、212種類コード以外にも、適宜の線分の組み合わせにより2n種類コードを作成することができる。
【0030】
2.2 重畳情報のコーディング
ドットテクスチャの微小なドット形状を保証するため、PostScript言語で帳票を作り、PostScriptプリンタに帳票画像データを送り、帳票を印刷する。大小2種類コードと8方向線分コードのそれぞれのコーディングについて述べる。その他のコードは、基本的に後者のコーディングを同様に利用できる。
【0031】
2.2.1 大小2種類コードにおけるコーディング
図8は、重畳する情報レコードを示す図である。ドットテクスチャの記入枠ごとに図8に示す情報を重畳する。これを情報レコードと呼ぶ。例えば、情報レコードを8+8+8+16×4+8=96ビットの固定長で表す。情報レコードは、例えば、記入枠の上側に重畳することができる。
図9は、属性とコードが示す値の対応を示すテーブルである。属性とは、その記入枠の中に記入される手書きの属性で、記入枠の見出し文字をカテゴリごとに分類したものである。属性には、帳票の種類、用途に応じてさまざまな種類がある。図9は、実際に使用されている帳票36種類から見出し文字を抽出した属性の例である。図9に示すように、例えば、14種類の属性に分類しコーディングすることができる。ただし、属性は適宜のものを用いることができ、これらには限定されない。
【0032】
図10は、文字種類及び命令と、コードが示す値との対応を示すテーブルである。文字種類とは、その記入枠の中に記入された手書き文字の字種のことである。命令とは、その記入枠の中に記入された手書きに対する読取り後の処理方法のことである。文字種と命令は8ビットのフラグで表現することができる。例えば、図10に示すように、文字種類及び命令のそれぞれに対応したビット番号を立てる(例えば、1にする)。なお、文字種類及び命令は、これ以外にも適宜のものを用いることができる。例えば、「認識せよ」との命令は、「枠あり認識せよ」、「枠なし認識せよ」などとしてもよい。見出し文字には、例えば、その記入枠見出しの始り4文字のShift−JISコード(合計64ビット)を埋め込む。終端記号は、8ビットの0を埋め込む。なお、アクティブ帳票処理システムの記憶部5には、例えば、図9及び図10に示すようなテーブルが予め記憶されている。
【0033】
図11は、情報レコードのドット列へのコーディング方法を示す図である。
大小2種類コードを水平(行)に並べ、例えば上記の情報を記入枠の上側に重畳する。記入枠と手書き文字の重なりにより重畳情報が損失する危険があるため、同一の重畳情報を一行のドット並び内で可能な範囲で繰り返し、残りの部分には例えば0を示すドットを入れる。また、2行目以降、先頭に例えば0を示すドットを入れて2ドットずつずらし、上のドット行を繰り返す。つまり、96ビットの情報レコードを可能な長さだけつなげ、残りの部分には0を示すドットを入れる。これらの重畳情報の多数決をとることで、損失した情報を復元することができる。なお、各行でずらすドット数は、2ドット以外にも適宜のドット数ずらすことができる。また、図11に示すコーディング方法は、大小2種類コード以外にも、例えば8方向線分コードなどの他のコードに適用することもできる。
【0034】
2.2.2 8方向線分におけるコーディング
図12は、重畳する情報レコードを示す図である。8方向線分コードは、大小2種類コードの情報の重畳方法を発展して、もっと多くの情報を重畳でき、かつエラーの検出などの効率的な重畳方法を使用することができる。記入枠ごとに図12に示す情報レコードを重畳する。
属性は、大小2種類コードの重畳と同様とすることができる。なお、8方向線分コードの1符号の情報量が3ビットであるため、表現の都合から、例えば、図9に示した大小2種類コードの属性の末尾(又は先頭)に0をつけ、9ビットとする。文字種と命令は、9ビットのフラグで表現することができる。表現方法は、上述の図10と同様とすることができる。また、ビット番号9の文字種類として、メールアドレスの認識率を高めるために、そこに用いられる英数字、「@」、「.」などの字種を示す情報とすることもできる。見出し文字は、全角1文字から10文字までのShift−JISコードで表す。メールアドレスの認識率向上については後述する。図12の情報レコード(45〜207ビットの不定長)を3ビットごとに区切り、それを表現するコードに変換する。各コードを含む情報レコードを記入枠の上側と下側の情報バーに重畳する。
【0035】
図13は、8方向線分コードの重畳の例を示す。図13に示すように、例えば4行のドットテクスチャを考えると、列ごとに4つのコードを上から下に配置し、それを左から右へコーディングしていく。図13に示す例では、1、2、3、4、5、6の方向で線分を配置している。情報レコードの始めと終りには区切り記号をつけ、また、終りの前にパリティ符号を置いて、さらに2番目、3番目の情報レコードを繰り返す。これを可能な範囲で繰り返す。2番目以降の情報レコードは、1番目の情報レコードと同一であり、パリティでまずエラー混入があるかどうかを検査し、さらに、複数の情報レコードの多数決をとって、損失した情報を復元することができる。
【0036】
図14に、パリティ符号の設定方法の説明図を示す。区切り図形間の対応する位のビットの値を排他的論理和で0になるように、パリティ符号を付加する。例えば、図14に示すように、「000」、「001」、「010」を示すデータに対しては、各データの対応するビットの値の排他的論理和が0になるように、パリティ符号として「011」を示すコードを付加する。
図15に、区切り記号を表す図形を示す。区切り記号は、情報レコードごとの境を示す機能を持ち、例えば、図4に示した8方向線分コードの番号を引き継いで8の番号とする。なお、区切り記号は図15に示す形状以外にも、それと判別できる適宜の形状とすることができる。
【0037】
2.3 コード図形の認識方法
コードを認識するには、以下のいずれかの方法を用いることができる。
2.3.1 四方向のヒストグラムによる認識方法
図16は、四方向のヒストグラムによる認識方法の説明図である。コードの画像(データ)に対し四方向(例えば、縦、横、右斜め、左斜め)のヒストグラムをとることによって、コードの形状特徴を判断しコードを認識することができる。図16に示すようにコードによって四方向のヒストグラムがはっきり違う。
【0038】
2.3.2 マッチングによる認識方法
全ての種類のコードに対して、大量の画像サンプルを作り、各サンプルの特徴値を抽出する。コード種類ごとに平均特徴値を求め、各コードの標準パタンを作ることができる。標準パタンサンプルの特徴値の抽出と同じ方法で入力コードの特徴値を抽出し、各コードの標準パタンとマッチングし、一番特徴の近い標準パタンを求め、この標準パタンを認識の結果とする。
図17に、標準パタンサンプルと入力コードの特徴値の抽出の説明図を示す。特徴値の抽出方法としては、文字記号認識において一般的に用いられている方法を用いることができる。まず、線密度を計算し、線密度が均等になるように非線形正規化をし、文字画像のエッジのギザギザを消すための線の連結性を保つ平滑化を行う(図17の(1))。次に、正規化されたパタンに対して、横、縦と斜めの4つ方向の成分を抽出する(図17の(2))。それぞれを8×8の区画に分割し、各区画に含まれる方向成分の量を特徴として、それを64個並べ、さらに4つの方向成分を並べて、64×4=256次元の特徴ベクトルを得る(図17の(3))。
【0039】
図18に、標準パタンとマッチングすることによるコードの認識の説明図を示す。例えば、図18の右側に示すような標準パタンの特徴値と、その標準パタンが示す情報が予め記憶部に記憶され、図18の左側に示す読み取られたコードの特徴値を、標準パタンの特徴値と比較し、コードを認識することができる。
2.3.3 部分的な走査による認識方法
図19は、部分的な走査による認識方法の説明図である。部分的にコード画像を走査することによるコード図形を認識する。コード図形中の線分があるべき位置ごとに順番に走査し、線分があれば対応の情報ビットを1とし、線分がなければ0とする。図19に示す図は、28種類コードの例である。白い部分は線分のない部分、黒い部分は線分のある部分である。図19では、線分のない部分を見やすくするために背景を灰色にしているが、実際の帳票では、背景と線分のない部分は同色とすることができる。コードを構成する各線は、2ビット数の桁に対応する。これらの線分を順番に走査し、線分があれば対応の桁を1とし、線分がなければ0とする。走査する部分は、コードの描画エリア又は配置エリアが切り出せれば、これらのエリア内の所定位置を走査することができる。順次走査することによって、図19の例では、2ビットの数「10110110」が求まる。10進数に直すと「182」になる。この値が、このコードの値である。
【0040】
2.4 各コード形状についての検討
上述の各コードの大きさ及び各コードの認識実験結果について説明する。
【0041】
2.4.1 実験環境条件
各コードの作成及び認識に用いた処理装置は、Pentium(登録商標)4の2.26GHzのCPUと、1.00GBのメモリを備え、Windows(登録商標)XPをOSとして搭載した機種である。
プリント精度として、安価なレーザビームプリンタでも印刷できる1200dpiを採用した。上述のように、アクティブ帳票は、PostScript言語で帳票コードを作成し、PostScriptプリンタに帳票コードを送ることにより印刷することができる。プリント精度は高ければ高いほどよい。しかし、あまり高い精度を前提にすると装置コストが高くなる。実験の結果、1200dpiの精度でプリントできる丸いドットの最小直径は0.1mmである。
【0042】
スキャンの精度は、600dpiを採用した。帳票を読み取るスキャン精度は、高ければ高いほどいい。しかし、精度が高いと、読み込んだ帳票のサイズが大きくなり、帳票処理の時間が大きくなる。例えば、600dpiの精度でスキャンした場合、A4帳票のサイズは4924×6883の画素数となり、このサイズでの大小2種類コードの普通帳票に対しては、コンピュータの処理時間が2秒弱となる。
また、ドットテクスチャの小さいドットがスキャンにより連結しないようにするため、ドット同士の間に適切な間隔をあける必要がある。プリント時の印刷誤差及び帳票が傾いた状態でのスキャンや二値化等による誤差を含め、実験により600dpiのスキャンでは0.2mmのドット間の最小間隔があることが望ましい。このサイズは、プリント精度1200dpiで印刷可能である。また、この間隔は、帳票の見た目を損なわない。
【0043】
2.4.2 各コードの検討
図20は、大小2種類コード及び8方向線分コードにより作られたドットテクスチャの記入枠である。図20(a)に、大小2種類コードにより、作られたドットテクスチャの記入枠を示す。
1200dpiの精度でプリントできる最小サイズのドットが0.1mmであることにより、図3に示すコードの高さhは0.1mmとすることができる。大きいドットと小さいドットを区別するため、帳票が傾いた状態でのスキャンや二値化などの誤差を考慮し、図3に示す大きいドットの長さLは0.25mmとすることができる。スキャン精度で述べたように、ドット間の間隔を0.2mmにするため、図3に示した長方形の配置エリアの大きさは幅0.45×高さ0.3mmすることができる。図20(a)は、この大きさのコードにより作成されたドットテクスチャの記入枠の例である。この例では、記入枠の上側に情報を重畳している。
このコードは2種類だけなので、縦方向のヒストグラムをとってコードの幅を判別することによって簡易に識別することができる。上述の大きさの2種類コードの帳票1枚を認識処理してみた結果、修正インタフェースを呼び出すまでの処理時間は1782msである。また、識別誤りはなかった。
【0044】
図20(b)に、8方向線分コードにより作られたドットテクスチャの記入枠を示す。8方向線分コードの線を、1200dpiでプリントできる最小サイズである0.1mmの太さとする。600dpiのスキャンで0.1mmサイズのピクセル数は3画素である。図4に示す「100」を示すコードと「101」を示すコードを区別するためには、「101」のコードの幅(横方向)には4ピクセルが必要である。スキャンする前のサイズに換算すると0.168mmである。誤差などを考慮し、「101」のコードの幅を0.2mmとすることができる。この場合、描画エリアの正方形のサイズは0.4mmになる。ドット間の間隔を0.2mmに保証すると、配置エリアのサイズは0.6×0.6mmになる。図20(b)は、この大きさのコードにより作られた記入枠の例である。この例では、図20(a)と同様に、コードを横方向に各行2コードずつずらして記入枠の上側に情報を重畳している。
【0045】
四方向のヒストグラムをとることにより、簡易に8方向線分コードを識別することができる。比較するため、マッチングによる認識方法と四方向のヒストグラムによる認識方法についてコード認識の処理を試した。マッチングによる方法の標準パタンの辞書は、8種類のコードごとに20個ずつ合計160個の画像をPostScript言語で作り、1200dpiプリントと600dpiスキャンにより得た画像をサンプルとし、特徴をとることにより作成した。
図21に、四方向ヒストグラムとマッチングによる認識方法を試した結果を示す。認識率は、辞書の作成用に使った全てのサンプル画像に対しての認識率で、両方とも100%に達している。しかし、処理時間は、ヒストグラムによる認識方法の方が早い。なお、1枚の帳票に対する処理時間は、認識した文字を修正するための修正インタフェースを呼び出すまでの処理時間を示している。
【0046】
図22に、212種類コードにより作られたドットテクスチャの記入枠を示す。
このコード形状はかなり複雑になり、コード画像が小さいと組合せの線が接触してしまい、人でも識別できなくなる場合がある。組合せの線が接触しないで人が識別できるまでのサイズのものを作り、マッチングによるデコーディング方法で識別し、98%以上の認識率を保証できるサイズを見出した。このサイズの描画エリアは0.9×0.9mmである。最小符号間隔の0.2mmを考え、配置エリアは1.1×1.1mmである。なお、このサイズは、プリント精度、スキャナ精度を高精度にすれば、さらに小さくすることも可能である。図22は、この大きさのコードにより作られた記入枠の例である。この例では、記入枠の上側に情報を重畳している。
【0047】
このコード形状は、小さくて線がかなり集まっている場合、ヒストグラムによる認識方法では特徴を識別できなくなる。ヒストグラムによる方法により識別するには、上述のサイズのよりも大きなサイズのコードとする必要がある。仮に、コードのサイズを大きくすると帳票の見た目に影響するので、ヒストグラムによる方法を止め、本例では、マッチングによる認識方法と部分的な走査による認識方法を試した。マッチングのための標準パタンの辞書は、4、096種類のコードごとに17個ずつ合計69632個の画像をPostScript言語で作り、1200dpiプリントと600dpiスキャンにより得た画像をサンプルとし、特徴をとることにより作成した。
【0048】
図23に、コードの認識結果を示す。認識率は、辞書の作成用に使った全てのサンプルに対しての認識率である。また、1枚の帳票に対する処理時間は、修正インタフェースを呼び出すまでの処理時間である。処理時間と認識率ともに、部分的な走査による認識方法の方がよい。
【0049】
図24に、28種類コードにより作られたドットテクスチャの記入枠を示す。212種類コードと同じで、このコードも小さいと組合せの線が接触してしまい、人でも識別できなくなる。組合せの線が接触しないで人が識別できるまでのサイズを作り、マッチングによる認識方法で識別し、98%以上の認識率を保証できるサイズを見出した。このサイズの描画エリアは0.78×0.78mmである。最小符号間隔の0.2mmを考え、配置エリアは0.98×0.98mmである。なお、このサイズは、プリント精度、スキャナ精度を高精度にすれば、さらに小さくすることも可能である。図24は、この大きさのコード図形により作られた記入枠の例である。この例では、記入枠の上側に情報を重畳している。
【0050】
このコードもヒストグラムによる認識方法で特徴を識別するには、上述のサイズよりも大きくする必要がある。そこで、マッチングによる認識方法と部分的な走査による認識方法を試した。マッチングの標準パタンの辞書は、256種類の符号ごとに7個ずつ合計1792個の画像をPostScript言語で作り、1200dpiプリントと600dpiスキャンにより得た画像をサンプルとし、特徴をとることにより作成した。
図25に、認識実験結果を示す。1枚の帳票に対する処理時間は修正インタフェースを呼び出すまでの処理時間である。認識率は辞書の作成用に使った全てのサンプルに対しての認識率で、両方とも100%に達した。しかし、処理時間は部分的な走査による認識方法の方が早い。
【0051】
2.4.3 コード形状についての比較
図26は、各種のコード形状の認識結果の比較図である。1ビットあたりのデコード時間は、前に述べた各種コード形状に対する最速な認識方法によるデコーダエンジンに、記入枠の情報バーを渡してからデコードの結果が求まるまでの時間を、情報バーの中に埋め込んだ情報量で割った時間である。212種類と28種類のコードは、現実的な大きさではコードの切出しと認識において、他のコードに比べて困難である。また、この二方式のコード形状は大きくなると、人が形を識別できてコードらしくない点も他のコードとの違いである。さらに、後の節で述べる記入枠と手書きの分離方法のうち最高速であるラベリングの方法により、この二方式のコードで作った帳票を処理すると、小さい文字(句読点など)と分離できなくなり、文字と重なる場合に文字の認識に悪影響を与える。他の方法で記入枠と手書きを分離することも可能であるが、分離の処理時間が長くなる。一方、8方向線分コードは大小2種類コードより情報量とデコード速度ともに良い。また、大小2種類コードは簡単でシステムを作りやすい。
【0052】
3.アクティブ帳票処理のメインフローチャート
図27に、アクティブ帳票処理システムの流れ図を示す。以下に、図27の各処理について説明する。アクティブ帳票処理システムは、処理を開始すると、まずアクティブ帳票画像(データ)を読み込む(S101)。次に、アクティブ帳票処理システムは、記入枠と手書きを分離し、記入枠と例えば情報バーの位置などの記入枠構造とを検知する(S103)。アクティブ帳票処理システムは、情報バーの位置に従い、記入枠ごとに重畳された情報を読み取る(S105)。なお、ステップS103、S105の処理の詳細については後述する。また、アクティブ帳票処理システムは、検出した情報バーの位置、記入枠構造などのデータを適宜のタイミングで記憶部に記憶する。
【0053】
アクティブ帳票処理システムは、重畳情報の属性により記入された手書きが文字の場合、記入枠の手書き文字の画像に対して、手書き文字の属性と文字種に従いオフライン文字認識を行う(S107)。アクティブ帳票処理システムは、オフライン認識の結果を修正インタフェースを通して修正する(S109)。修正インタフェースは、認識した文字を修正するための処理を実行する。アクティブ帳票処理システムは、アクティブ帳票から抽出した記載内容や重畳情報を、例えば、CSVファイルの形で出力する(S111)。これを命令書と呼ぶ。また、帳票画像を命令書とを対応させて記憶部に保存する。アクティブ帳票処理システムは、アクティブ帳票処理を終了する。その後、他のアプリケーションシステムは、命令書に従いアクティブ帳票から抽出した情報に対して処理を行う。
【0054】
4.記入枠と手書きの分離及び記入枠と記入枠構造の検知の処理
4.1 処理の流れ
図28に、記入枠と手書きの分離、記入枠と記入枠構造の検知についてのフローチャートを示す。図28に示すフローチャートは、図27に示すフローチャートにおけるステップS103の詳細処理である。記入枠と手書きの分離をしなくても手書きを含んだままで記入枠の行検出は行えるので(行内の位置検出には手書きが邪魔になるが、行の検出には邪魔にならない)、手書きを分離する前に行検出を行い、一行ずつの画像だけに対してラベリングをすれば(アルゴリズム2とする)、行間でのラベリング処理を省くことができる。処理手順は次の通りである。
【0055】
まず、アクティブ帳票処理システムは、全帳票画像(データ)に対し横方向へのヒストグラムをとり、行ごとの画像を検出する(S201)。次に、アクティブ帳票処理システムは、行ごと画像に対してラベリング処理を適用し、記入枠と手書きを分離する(S203)。なお、ラベリング処理以外にもモルフォロジー、メディアンフィルタの手法いて、記入枠と手書きを分離することもできる。ラベリング等については、後述する。
さらに、アクティブ帳票処理システムは、行ごとの記入枠だけの画像に対し縦方向へのヒストグラムで記入枠の位置とマス位置を検出する(S205)。アクティブ帳票処理システムは、記入枠ごとの画像に対し横方向へのヒストグラムで記入枠の情報バーの位置を検出する(S207)。なお、アクティブ帳票処理システムは、行及び記入枠の検出の際に、予め定められた閾値以下の値を0と見なして、ノイズのある場所でも空白として無視してもよい。この場合、後述する記入枠検出時の情報損失防止処理を実行するようにしてもよい。
【0056】
4.2 記入枠と手書きの分離方法
4.2.1 ラベリングによる手法
ラベリングは、二値画像に対して連結している黒画素の連結成分に同じラベルをつけることをいう。ラベリングの手法には再帰関数を呼び出す方法と往復走査する方法がある。
【0057】
4.2.2 モルフォロジーの手法
帳票画像の収縮と膨張には、それぞれ以下の二つの方法がある。
収縮方法としては、(a)画像を走査し白画素にあったら、この画素の8近傍か4近傍の画素も白くする方法、(b)画像を走査し黒画素にあったら、この画素の8近傍か4近傍を調べ、8近傍か4近傍の画素の中で一つでも白であれば、この黒画素を白にする方法のいずれかを用いる事ができる。
膨張方法としては、(a)画像を走査し黒画素にあったら、この画素の8近傍か4近傍の画素も黒くする方法、(b)画像を走査し白画素にあったら、この画素の8近傍か4近傍を調べ、8近傍か4近傍の画素の中で一つでも黒であれば、この白画素を黒くする方法のいずれかを用いることができる。
【0058】
4.2.3 メディンアンフィルタの手法
メディンアンフィルタはよく画像の平滑化に用いられる手法である。メディンアンフィルタとは、領域内の濃度の中央値、すなわち3×3の領域であれば、9個の濃度値を低い(または高い)順番に並べ、5番目(中央)の濃度値を、その中心の新しい濃度値とするフィルタのことである。
図29に、メディアンフィルタの説明図を示す。中心にある目的画素の元の濃度値は22である。3×3の領域のメディアンフィルタを使う。そのフィルタ中にある9個の濃度値を低い順番に並べると、22、22、23、24、24、24、25、26、27という順番になる。中央値が5番目の値24なので、目的画素の新しい濃度値を24とする。2値画像の場合、メディアンフィルタの大きさの二分の一より小さい面積(黒画素数)の黒画素の連結成分では、この連結成分のどの黒画素にメディアンフィルタを適応しても、中央値が必ず白画素値である。したがって、この連結成分が消される。
【0059】
4.2.4 記入枠と手書きの分離
記入枠と手書きの分離方法では、ラベリングによる分離方法、収縮と膨張による分離方法、これらを組み合わせた分離方法、及び、メディアンフィルタによる分離方法が考えられる。
大小2種類コードによる帳票と8方向線分コードによる帳票に対し、記入枠と手書きを分離してみた。いくつかの記入枠と手書きの分離方法を比較するため、これらのサンプル帳票は普通の太さのペンで記入してもらっている。分離した結果では、収縮と膨張による分離方法で記入枠の画像に多量の手書きの跡が残った。きれいに記入枠と手書きを分離できるためには、もっと太めのペンで記入する必要がある。しかし、こうすると収縮と膨張による分離時間が長くなる。また、筆記具を制限することになる。
分離した結果によると、再帰関数を呼び出すラベリングによる分離方法が、一番高速で、かつ、手書きの太さと記入枠ドットの大きさに制限がかからない。したがって、記入枠と手書きの分離方法には再帰関数を呼び出すラベリングの方法が有効である。
図30に、記入枠と手書きが重なった場合における分離されたき記入枠と手書き文字を示す。記入枠と手書きが重なったことが手書き分離に影響していないことが確認できる。
【0060】
4.3 記入枠と記入枠構造の検出
記入枠を検出するためには、線分検出、交点検出による方法(後述する)、以下で述べるような縦および横方向へのヒストグラムを取る方法などがある。アクティブ帳票方式は、記入枠の検出方法に依存せずに有効である。ただし、以下では、ヒストグラムによる方法により、更なる技術開発を行ったので、ヒストグラムによる記入枠検出について述べる。
【0061】
4.3.1 ヒストグラムでの検出
図31に、ヒストグラムによる記入枠及び記入枠構造の検出の説明図を示す。図28に示す各処理を実行することにより、図31に示すようなヒストグラムが得られる。
まず、図31(a)に示すように、帳票画像全体に横方向へのヒストグラムを取り、得られたヒストグラムに従い一行ずつの記入枠を検出する(S201に対応)。次に、図31(b)に示すように、検出した行に対して縦方向へのヒストグラムを取り、得られたヒストグラムに従い記入枠の位置と記入枠のマスを検知する(S205に対応)。次に、図31(c)に示すように、検知された記入枠に対して横方向のヒストグラムを取り、得られたヒストグラムに従い記入枠の情報バー位置を検知する(S207に対応)。
【0062】
4.3.2 記入枠構造の検知方法についての検討
図32〜図34は、記入枠構造の検知方法についての説明図である。
図32に示すように、記入枠の高さと幅が十分に大きいとき、縦方向と横方向へのヒストグラムにより、記入枠の構造がはっきり区別できる。ヒストグラムの最大値と最小値の中間値を求め、この中間値を閾値とし、記入枠のマス位置や情報バーの位置を検出することができる。しかし、図33に示すように、記入枠の幅や高さが小さい場合、中間値を安定に求めることができない。なお、図32及び図33は、見やすさのため記入枠の大きさを拡大縮小して表示しているため、記入枠の大きさの違いが一目ではわかりづらいが、配置されたコードの数から記入枠の大きさの違いがわかる。さらに、図34に示すような手書きとの重なりにより消された記入枠は、そのままの状態で処理すると誤った結果になることがある。よって、記入枠の構造を識別する時、まず、図34に示すように記入枠のドットを膨張する。記入枠のドットが完全に接触するまで膨張するのは時間がかかるため、ドットのサイズに従いある程度膨張すればよい。膨張した記入枠に対して、ヒストグラムの中間値を求め、簡易に記入枠の構造を識別することができる。大小2種類コードによる記入枠は、ドットのサイズが小さいため、膨張処理を行わなくても構造を認識できる。8方向線分コードによる記入枠は、ドットのサイズと形状によりドットテクスチャがまばらになる。ヒストグラムにより記入枠構造を認識するには、膨張処理を行うことが好ましい。
【0063】
4.3.3 空白を考慮した処理時間短縮
図35は、6種類の大小2種類コードと8方向線分コードの帳票に対し、帳票の空白を考慮せずに処理する方法(アルゴリズム1)と、空白を考慮して処理する方法(アルゴリズム2)を適用した処理結果である。帳票内の記入枠の間には空白があるので、上述のフローチャートに示す処理では、ラベリングでの空白の処理時間を省き帳票の処理時間が早くしている。
アルゴリズム2の処理は、図28に示す本実施の形態に係る処理と同様である。アルゴリズム1の処理手順は以下の通りである。まず、全帳票画像に対しラベリングし記入枠と手書きを分離する。次に、記入枠だけの画像に対し横方向へのヒストグラムで行を検出する。さらに、行ごとの記入枠画像に対して縦方向へのヒストグラムで記入枠の位置とマス位置を検出する。行ごとの記入枠画像に対して横方向へのヒストグラムで記入枠の情報バー位置を検出する。アルゴリズム1では、全帳票に対してラベリングしているのに対し、アルゴリズム2では、検出された行に対してのみラベリングする点が異なる。記入枠の密度によらず、アルゴリズム2、すなわち行間の空白を考慮した方法のほうが高速である。なお、2つのアルゴリズムによる処理結果の精度は同じである。
【0064】
4.4 記入枠検出時の情報損失防止処理
図36に、記入枠検出時の情報損失防止処理の説明図を示す。
横あるいは縦方向へのヒストグラムにより記入枠の位置を検出するとき、ノイズの妨げを避けるために、ヒストグラムの結果に対して予め定められた閾値以下の値を0と見なして、ノイズのある場所でも空白として無視する。図36では、記入枠の上外側にたくさんのノイズがあるが、閾値処理をすることにより、ノイズの影響を受けず、記入枠の位置fを検出できる。しかし、閾値以下の値を0とみなしているため、記入枠の境のところで閾値以下の情報も無視されてしまい、記入枠の中に重畳した情報を読み取るには悪影響を与える。したがって、記入枠の位置を検出する時に、このような情報損失を防止するために、ヒストグラムで閾値以下のところで記入枠の位置fを検出してから、さらに、この位置fから記入枠の外側の方向(例えば、図36の例では上方向)にヒストグラムの値を辿って行き、ヒストグラムの値が0より大きい値から0になった位置、あるいは、始めの位置fから辿った長さがある閾値を超えてもヒストグラムの値が0にならない場合には始めの位置fから外側に閾値分だけずらした位置を記入枠の開始あるいは終了の位置とする。こうすることにより、正しく記入枠の開始あるいは終了の位置を検出することができるとともに、記入枠外のノイズを避けることもできる。なお、図36は、行の検出(上下に走査)の例であるが、列の検出(左右に走査)についても同様とすることができる。
【0065】
5.デコーディング
5.1 処理の流れ
次に、図27のステップS105の処理(デコーディング)について説明する。
図37に、大小2種類コードのデコーディングの流れ図を示す。図37に示すフローチャートは、情報レコードが情報バーの横方向に配置された帳票に対するデコーディングである。
まず、アクティブ帳票処理システムは、ステップS103で検知された記入枠の情報バーに対して、横と縦方向にヒストグラムをとり、行ごとのドットを切り出す(S301)。次に、アクティブ帳票処理システムは、切り出された各ドットの縦方向のヒストグラムに従い、ドットの長短を測り、ドットが示す情報が1か0かを求める。例えば、アクティブ帳票処理システムは、長いドットを1、短いドットを0とする。そして、アクティブ帳票処理システムは、所定ビット、例えば2ビットずつの行のずらしを戻す(S305)。アクティブ帳票処理システムは、記入枠の情報バーから大量の情報レコードを求める(S307)。例えば、アクティブ帳票処理システムは、記入枠の情報バーから可能な限りの情報レコードを求めることができる。また、アクティブ帳票処理システムは、予め定められた数の情報バーを求めるようにしても良い。アクティブ帳票処理システムは、情報レコードの値の多数決を取ることにより重畳情報レコードを求める(S309)。多数決を取ることにより、エラーを回復できる。なお、上述の説明では、大小2種類コードについて説明したが、横方向に配置された他のコードを有する帳票に対しても同様とすることができる。
【0066】
次に、8方向線分コードのデコーディングについて説明する。8方向線分コードの切出しにおいてはエラー防止と検出を行い、効率的なデコーディング方法を行う。なお、8方向線分コードの大きさは、上述のサイズとして説明する。また、実験により、描画領域が0.35×0.35mm、0.45×0.45mm、0.5×0.5mm、0.6×0.6mmのサイズにおいても、デコーディングが可能であることが確認済みである。コードの大きさは大きければ大きいほど認識率が高いが、小さければ小さいほど帳票の見た目がよい。8方向線分コードのデコーディングでは、ドット同士間の必要な間隔0.2mmをあけ、好きなコードサイズで帳票を作れるようにしたため、自動的にコードの大きさを検出しこの大きさに合わせたデコーディングを行う。また、8方向線分コードは区切り記号による不定長の情報レコードと情報レコードごとにパリティ符号を使うため、情報レコード長のエラーと情報レコードの内容のエラーを検出することができる。以下に、これらの処理の詳細について述べる。
【0067】
図38に、8方向線分コードのデコーディングの流れ図を示す。図38に示すフローチャートは、コードとパリティ符号と区切り記号とが情報バーの縦方向に配置された帳票に対するデコーディングである。
まず、アクティブ帳票処理システムは、情報レコードをセットする(37−01)。例えば、ステップS103で検出された情報バー又はその一部を記憶部から読み出す。次に、アクティブ帳票処理システムは、情報レコードの先頭の区切り記号を求める。具体的には、以下のステップ37−02〜37−06の処理を実行する。まず、アクティブ帳票処理システムは、画像の終端か判断する(37−02)。例えば、アクティブ帳票処理システムは、次に切り出す対象となる画像(データ)が存在するか判断する。アクティブ帳票処理システムは、画像の終端の場合(37−02)、ステップ37−17の処理へ移る。一方、アクティブ帳票処理システムは、画像の終端でない場合(37−02)、アクティブ帳票処理システムは、コードの図形を切り出す(37−03)。例えば、アクティブ帳票処理システムは、縦方向及び横方向のヒストグラムの区切れを判断し、その幅に基づきコードの図形を切り出す。アクティブ帳票処理システムは、切り出しエラーか判断する(37−04)。切り出しエラーとしては、例えば、手書きの重なりによりコードが消されるなどの理由によりコードが切り出せないことや、切り出したコードが所定の位置になく、他のコードが消されていることが考えられる。アクティブ帳票処理システムは、切り出しエラーの場合(37−04)、ステップ37−14の処理へ移る。一方、切り出しエラーではない場合(37−04)、切り出したコードの図形を認識する(37−05)。アクティブ帳票処理システムは、認識したコードが先頭区切り記号か判断する(37−06)。アクティブ帳票処理システムは、認識したコードが、先頭区切り記号の場合ステップ37−07の処理へ移り、先頭区切り記号ではない場合はエラーとみなし、ステップ37−14の処理へ移る。
【0068】
ステップ37−14〜37−16の処理では、次の終端区切り記号を見つける。まず、アクティブ帳票処理システムは、次のコードの図形を切り出す(37−14)。アクティブ帳票処理システムは、切り出したコードを認識する(37−15)。アクティブ帳票処理システムは、認識したコードが終端区切り記号か判断する(37−16)。なお、先頭区切り記号と終端区切り記号は、同じ記号を用いることもできる。アクティブ帳票処理システムは、認識したコードが終端区切り記号ではない場合、ステップ37−14に戻る。アクティブ帳票処理システムは、区切り記号を見つけるまで、ステップ37−14〜37−16を繰り返すことになる。一方、終端区切り記号の場合、ステップ37−01の処理へ移る。一方、アクティブ帳票処理システムは、ステップ37−06で認識したコードが先頭区切り記号の場合、情報レコードのデータを求める。具体的には、以下のステップ37−07〜37−13の処理を実行する。
【0069】
まず、アクティブ帳票処理システムは、画像の終端か判断する(37−07)。アクティブ帳票処理システムは、画像の終端の場合(37−07)、ステップS37−17の処理へ移る。一方、アクティブ帳票処理システムは、画像の終端でない場合(37−07)、次のコードの図形を切り出す(37−08)。アクティブ帳票処理システムは、切り出しエラーか判断する(37−09)。アクティブ帳票処理システムは、切り出しエラーの場合(37−09)、ステップ37−14の処理へ移る。一方、切り出しエラーではない場合(37−09)、切り出したコードの図形を認識する(37−10)。アクティブ帳票処理システムは、認識したコードが終端区切り記号か判断する(37−11)。アクティブ帳票処理システムは、認識したコードが終端区切り記号ではない場合(37−11)、セットした情報レコードと対応させて記憶部に認識結果を格納し(37−12)、ステップ37−07の処理へ戻る。アクティブ帳票処理システムは、37−07以降の処理を繰り返して、終端区切り記号を見つけるまでコードを認識し、情報レコードのデータを求める。一方、アクティブ帳票処理システムは、認識したコードが終端区切り記号である場合(37−11)、一つの情報レコードの処理を終了し(37−13)、ステップ37−01に戻り、さらに次の情報レコードに対する処理を実行する。
【0070】
ステップ37−17では、アクティブ帳票処理システムは、情報レコードに重畳され多情報を求める処理を終了し、ステップ37−18の処理へ移る。アクティブ帳票処理システムは、情報レコードの長さをチェックし、長さがあり得る範囲(例えば、図12に示す例では45〜207ビット)に入っていない情報レコードを削除する(37−18)。アクティブ帳票処理システムは、情報レコードの長さの多数決をとることにより情報レコードの長さを求める(37−19)。アクティブ帳票処理システムは、情報レコードの長さをチェックし、正しくない情報レコードを削除する(37−20)。アクティブ帳票処理システムは、情報レコードのパリティ符号をチェックし、正しくない情報レコードを削除する(37−21)。アクティブ帳票処理システムは、残った情報レコードの値の多数決を取ることにより、記入枠の重畳情報レコードを求める(37−22)。また、アクティブ帳票処理システムは、求めた情報レコードを適宜記憶部に記憶し、処理を終了する。
【0071】
5.2 コードの大きさと情報バーのコード行数の検出
図39は、描画エリアの大きさ算出の説明図である。図39に示す水平バーには、一例として4行のコードが配置されている。コードの切り出しを行うため、水平バーを使ってコードの大きさと情報バーのコード行数を検出する。
まず、水平バーに対して縦方向のヒストグラムをとり、図39に示すように、各コード図形列の中心位置を検知する。次に、各コード図形列の中心間の距離を求め、これらの距離に対して平均を求める。この結果はコード図形の配置エリア正方形の辺長である。配置エリアの辺長からドット間隔のサイズ0.2mm(600dpiスキャンで4画素)を引くと、描画エリア正方形の辺長が求まる。
【0072】
本実施の形態のおける帳票は、水平バーのコード行数が記入枠の情報バーのコード行数と同じであると設定しているため、水平バーに対してコード行数を検出することにより、記入枠の情報バーのコード行数を求めることができる。帳票に傾きがあると、コード行数の検出は水平バー全体に対して行うのは難しい。したがって、コードの大きさの検出時に水平バーに対して取った縦方向のヒストグラムに従い、何列かのコード図形だけに対して、横方向のヒストグラムを取ることにより、記入枠の情報バーのコード行数を検出することができる。なお、情報バーのコード行数は、水平バーのコード行数を検出することにより求める以外にも、水平バーを構成するコードにコード行数を示す情報を重畳し、そのコードを認識することにより求めるようにしてもよい。
【0073】
5.3 コード図形の切出し
次に、コード図形の切り出し(例えば、図38のステップ37−03、37−08、37−14)について説明する。
【0074】
5.3.1 ヒストグラムによるコード図形の切出し方法の必要性
図40は、コードの大きさによるコード切り出しの例である。
コードの大きさが検出できれば、コードの大きさを一定長としてコードを切り出す方法が考えられる。しかし、何らかの誤差(例えば、微少な誤差の累積)があるため、コードの大きさを一定長として正しくコード図形を切り出すことができない場合がある。図40に示すように、コードの大きさBCを一定長として列ごとのコードを切り出し、縦線を引いて切出しの結果をシミュレーションしてみると、始めの何列かは正しく切り出すことができるが、後ろの列になると誤差が大きくなるために正しく切り出すことができない場合がある。本実施の形態にかかるアクティブ帳票処理システムにおいては、コード図形の切出しは、コードの大きさを一定長としての切り出すのではなく、ヒストグラムによる切出しを行うことで、正確なコード切り出しを実現している。
【0075】
5.3.2 コード図形の切出し方向
まず、情報バーの画像に対して横方向のヒストグラムにとり、行ごとを切り出す。次に、行ごとの画像に対して縦方向のヒストグラムをとり、コードごとの図形を切り出す。傾きのない情報バーの場合、この切出し方向で容易にコード図形を切り出すことができる。しかし、図41に示すように、傾いてスキャンされた情報バーの場合、この切出し方向では容易にコード図形を切り出すことができない。しかし、このような場合でも、列数にくらべ行数が少なく縦方向へのヒストグラムの重なりが小さいことに注目し、この性質を利用して情報バーが多少傾いていても正しくコードごとの図形を切り出すことができる。例えば、アクティブ帳票処理システムは、まず、情報バーの画像に対して縦方向のヒストグラムにとり、情報バーの左から右へ列ごとを切り出す。次に、列ごとの画像に対して横方向のヒストグラムをとり、コードごとの図形を切り出す。
【0076】
5.3.3 手書きの重なった情報レコードの検出と処理
次に、切り出しエラー(図38の37−03、37−08、37−14に対応)について説明する。手書きと記入枠の重なりにより、分離した記入枠では手書きと重なる部分が消される。これを効率よく検出し、エラーのある情報レコードに対して、処理を行わない方法をとっている。図38の37−03と37−08のコード図形の切出しにおいて、切り出されたコードに対してこのようなエラーを検出し、図38の37−04と37−09から図38の37−14、37−15、37−16の繰返し処理に移り、次の区切り記号を見つけるまで、コードを読み飛ばす。つまり、エラーのある情報レコードに対して処理を行わない。情報バーの画像において、左から右へ列ごとのコード図形を切り出していき、前の列と次の列の間隔が想定される幅より大きいときにコード図形と手書きが重なって手書きの分離処理においてコード図形が欠落したと判断する。
【0077】
図42は、手書きの重なった情報レコードの検出と処理の説明図である。図42は記入の情報バーの最左部分であり、仮想的に小さい正方形でコードの描画エリアを表す。描画エリアを均一的に0.2mmの最小間隔(4画素)を空けて並べることで、情報バーのドットテクスチャを形成している。描画エリア正方形の辺長BBは上述の方法により水平バーから求められる。列の中心位置S+描画エリア辺長BB/2の位置を列の最大右位置R2とし、列の縦方向ヒストグラムの実際の右位置をR1とする。
【0078】
各列のコード図形を切り出す時、この列の右位置R1と基準aの距離dを求め、距離dに従い、手書きの重なりエラーの有無を判断する。まず、基準位置aの求め方について説明する。情報バーの画像において、左から右へ列ごとのコード図形を切り出していく。最初、基準位置aの初期位置は情報バーの最左の位置とする。列ごとのコード図形を切り出していく度に、基準位置aを更新していく。基準位置aの新しい位置は、切り出した列の中心位置S+描画エリア辺長BB/2である。つまり、基準位置aは、初期値以外は、いつもコード列の最大右位置R2を指している。基準位置aは列の中心位置を基準として変化していくので、始めの位置がノイズなどにより正しくなくても構わない。基準位置aに従う手書きの重なりエラーの検出の具体的処理を以下に示す。
【0079】
まず、アクティブ帳票処理システムは、新しいコード列を切り出すごとに、この列の右位置R1と基準aの距離dを求める(例えば、ステップ37−03に対応)。次に、アクティブ帳票処理システムは、距離dが描画エリア辺長BBより6画素(描画エリアの間隔4画素+マージンとしての2画素)以上大きい場合(例えば、ステップ37−04に対応)、手書きの重なりエラー(切出しエラー)と見なして、この後のコード図形に対して、区切り記号が見つかるまで無視する(ステップ37−14〜37−16に対応)。一方、アクティブ帳票処理システムは、距離dが描画エリア辺長BBより6画素以上大きくない場合、列のコードを切り出して認識する処理(例えば、ステップ37−05、37−10に対応)を行う。
【0080】
5.3.4 コード図形におけるエラー
図43は、コード図形におけるエラーの例を示す図である。
図43に示すように、ノイズによってコード図形が接触し、形や大きさが異常になる場合がある。例えば、横方向の連結によるコード図形横サイズエラー、縦方向の連結によるコード図形縦サイズエラー、ノイズによるコード図形縦横サイズエラー、情報バー位置誤差による横方向のコード図形横サイズエラーなどがある。これらの異常に対して、切り出した図形の大きさが想定されるコード図形より小さい場合はノイズとして無視し、大きすぎる場合には、想定される大きさで分離して認識することにより、各コード図形に微小なノイズが付着して連結してしまったり微小なノイズをコード図形として処理してしまったりする誤りを防止する。
【0081】
列ごとのコード図形を切り出す時、列の幅をチェックし、もし列の幅が描画エリア幅BB+4(画素)より大きければ、コード図形の横サイズエラーと判断し、基準位置aからBB+4の幅でこの列を分割して切り出す。8方向線分コードは線分で構成され、上述のように線の太さが0.1mm、600dpiスキャンでのサイズが約3画素である。誤差を考慮し、コードの線太さの閾値を、例えば5画素とする。コード図形を認識できるために、描画エリアの幅BBは必ず線の太さより大きい。したがって、コードの幅と高さが両方とも線太さの5画素より小さいことはあり得ない。コードごとの図形を切り出す時、コードの幅と長さをチェックし、もしコードの幅と長さの両方とも5画素以下であれば、コード図形の縦横サイズエラーと判断し、この図形を無視する。また、コード図形の長さが描画エリア幅BB+4より大きければ、コード図形の縦サイズエラーと判断し、この図形の最上からBB+4の幅で分割して切り出す。
【0082】
こうすることにより、各コード図形に微小なノイズが付着して連結してしまったり、微小なノイズをコード図形として処理してしまったりする誤りを防止できる。
5.3.5 情報バーの位置検出誤差によるコード図形損傷への対応
図44〜図46は、情報バーの位置検出誤差によるコード図形損傷への対応処理の説明図(1)〜(3)である。
記入枠の情報バーの位置を検出するとき、図44に示すように、例えば上述のステップS207で検出された情報バーとそれ以外の部分の境界線bは、正しい情報バーの境界線となんらかの誤差がある場合がある。この情報バー境界線bに従い、コード図形を切り出してデコーディングを行うと、情報バーからはみ出したコード図形の一部を除外して認識することになり、誤認識を招くおそれがある。このことを避けるために、アクティブ帳票処理システムは、以下のようにコードの切り出しの処理(図38のステップ37−03、37−08、37−14に対応)及び切り出しエラーの処理を実行することができる。
【0083】
アクティブ帳票処理システムは、検出した情報バー境界線bに従い、情報バーの画像に対して、例えば、最上のコードから境界線bまでのデータに対して、縦方向のヒストグラムにより、左から右へコードの列ごとの位置を検出する。次に、アクティブ帳票処理システムは、図45示すように、列ごとのコード画像に対して、横方向のヒストグラムを走査し、コードごとを切り出す。図45に示すように、記入枠の上側情報バーの切出し方向は上から下へ走査する。一方、下側情報バーの切出し方向は下から上へ走査する。この段階から以後、境界線bの情報を利用しない。
【0084】
アクティブ帳票処理システムは、列ごとに一つづつコードを切り出した後、この列において切り出したコード数と走査した長さLを調べる。水平バーから求められた情報バーのコード行数をNとすると、この列のコード数がすでにNに達しているか、及び/又は、走査した長さLがNに応じた長さまで達していれば、コードの切出しを終了する。そうでなければ、続いてヒストグラムを走査し、コードの切出しを行う。ここで、走査した長さで終了を検出する目的は、コード図形が手書きと重なったりして欠落した場合に、情報バーの領域を越えてコードを探しに行かないようにするためである。
アクティブ帳票処理システムは、列ごとに対して、コードの切り出しが終了した時点で、そのコード数をチェックする。もしNに達してなければ、コード数のエラー(図38に示す切出しエラー)と見なし、この後のコード図形に対して、区切り記号が見つかるまで無視する。
【0085】
コード図形の切り出し段階において境界線bを用いないことによって、検出した情報バー境界線からはみ出したコード図形を正しく認識することができる。この方法によりコード図形を切り出した結果を図46に示す。図46では、便宜上切り出されたコード枠をつけて表示している。記入枠上段の情報バーでは、境界線bの誤差の影響を受けずに、コードが正しく切り出されていることが示されている。
【0086】
5.4 8方向線分コードの認識
図47は、8方向線分コードの認識についての説明図である。
次に、コード図形の認識(図38の37−05、37−10、37−15に対応)について説明する。
コードの大きさが検出できれば、コードの大きさに合わせるデコーディング方法を行うことができる。コードの描画エリア正方形の辺長はBBである。コード図形に対して、四方向へのヒストグラムをとる。図47に示すように、四方向へのヒストグラムの幅を別々にl、x、s、hとする。エラーなどの誤差を考慮し、コードの線太さの閾値を5画素とする。
【0087】
図48は、コード認識のアルゴリズムである。また、図49に、コードを認識のプログラム例を示す。
まず、アクティブ帳票処理システムは、h≦5か判断する(S501)。アクティブ帳票処理システムは、yesのときコード=0とし、noのとき、h≧BB−2か判断する(S502)。アクティブ帳票処理システムは、yesの時ステップS503へ移り、noの時ステップS508へ移る。アクティブ帳票処理システムは、x≧BB−2か判断する(S503)。アクティブ帳票処理システムは、yesの時ステップS504へ移り、noの時ステップS506へ移る。アクティブ帳票処理システムは、s≦5か判断する(S504)。アクティブ帳票処理システムは、yesの時コード=2とし、noの時l≦5か判断する(S505)。アクティブ帳票処理システムは、yesの時コード=6とし、noの時コード=8とする。
【0088】
ステップ506では、アクティブ帳票処理システムは、x>5か判断する(S506)。アクティブ帳票処理システムは、noの時コード=4とし、yesの時s<BB−2か判断する(S507)。アクティブ帳票処理システムは、yesの時コード=3とし、noの時コード=5とする。
ステップ508では、アクティブ帳票処理システムは、s<BB−2か判断する(S508)。アクティブ帳票処理システムは、yesの時コード=1とし、noの時コード=7とする。
なお、上述の判断以外にも、コードの大きさ、線の太さに応じた適宜の判断をすることができる。また、四方向ヒストグラムを用いる以外にも、上述の部分的走査、マッチングによりコードを認識することもできる。
【0089】
5.5 情報レコード長エラーの検出とその処理
次に、情報レコード長エラーの検出とその処理(図38の37−18、37−19、37−20に対応)について説明する。
8方向線分コードは、区切り記号により、情報レコードの長さエラーの検出を行うことができる。上述のコーディング方法で述べたように、8方向線分コードの情報レコードの長さは不定長であるが、パリティの記号を含め、コード図形の数は16個から70個(情報レコードは、45〜207ビット)までの間にある。コード図形を認識する時、区切り記号の認識を間違うと、情報レコードの長さは16から70までの間になっていない場合がある。その場合、次の区切り記号までを読み飛ばして、これらの情報レコードを削除する(ステップ37−18)。
【0090】
また、情報バーの全部のコードに対して、処理し認識を終えたら、複数のレコードが求まる。これらのレコードの長さがすべて同じでない場合は、それぞれの長さの多数決をとり、最多のレコード長を正しい長さとする(ステップ37−19に対応)。また、情報レコードの長さをチェックし、その長さが多数決により求められた長さと異なる情報レコードを削除する。残った情報レコードに対して次のパリティチェックを行う。
【0091】
5.6 パリティ符号のチェック
情報レコードに対して、パリティ符号のチェックを行う(図38の37−21に対応)。例えば、情報レコードごとに、同じ位のビットでの1の数が偶数になっているかいないかをチェックする。なっていれば、この情報レコードが正しく、なっていなければ、正しくないと判断しこの情報レコードを削除する。
【0092】
5.7 記入枠の重畳情報レコードの取得
以上で述べた方法により求めた情報レコードに対して、ビットごとに多数決を取る(図38の37−22に対応)。こうすることにより、記入枠ごとに対して、確信度の強いデータを求めることができる。
【0093】
6.メールアドレス認識率を高める方法
図50は、メールアドレスの認識率を高めるための記入枠である。
メールサーバによってメールアドレスの表記法が違い、メールアドレスの文字種も違うが、一般的に使われるメールアドレス形式はドメインアドレス形式であり、その文字種は「@」、英数字、「.」(ピリオド)、「−」(ハイフン)、「_」(アンダーバー)である。アクティブ帳票処理では、記入枠に重畳した情報に従い、手書きの内容がメールアドレスの場合にはこれらの文字種に限定することによって認識率を高めることができる。
【0094】
しかし、これらの文字種は、オフライン文字認識においては一般に低い認識率となり、メールアドレスの認識率がこの認識率に左右されることになる。字種を限定しても、英文大文字、英文小文字と数字などの字種が互いに影響しあい、誤認識になる傾向がある。また、メールアドレスは意味の通じない文字列なので、認識率を高める文脈処理が行えない。これも、メールアドレス認識率を高められない原因である。しかし、帳票処理システムにとっては、メールアドレスの認識は間違うと大きい過ちを犯す危険性があるので、極めて重要なことである。メールアドレス誤認識において、主な原因は類似文字への誤認識である。もし、この誤認識を避けることができれば、認識率を高めることができる。
【0095】
図50に示すように、メールアドレスの文字種を限定するために、例えばアクティブ帳票の中でメールアドレス記入枠の下に、もう一つの記入枠を設ける。この記入枠の中で、上のメールアドレスに対して対応するマスの文字種を記入する。認識のしやすさと人の記入しやすさを考慮し、例えば、以下のような符号を記入する。
(1) ̄:英文大文字(枠に重なって記入できるようにする)
(2)_:英文小文字(枠に重なって記入できるようにする)
(3)=:数字(枠に重なって記入できるようにする)
(4)空白:その他
【0096】
縦方向および横方向へのヒストグラムをとること、あるいは、枠内で3種の記号をマッチングすることによりこれらの符号を容易に、かつ、確実に認識できる。こうすることにより、メールアドレスの文字種間の相互的な影響を避けることができ、認識率が高められる。図50に示すように、これらの記号を連続するマスにまたがって記入できるようにする。これにより、文字単位ではなく文字列単位に記入できるので指示が簡単になる。認識のためにはマスの中だけを見れば良い。なお、文字種を限定するための記入枠の情報レコードには、文字種類としてメールアドレスの認識を高めるための上述の符号が記入されることを示す適宜のデータを含むことができる。
【0097】
7.アクティブ帳票処理システムの試作
以上で述べた技術を使いアクティブ帳票処理システムを試作した。以下、その概略について述べる。
【0098】
7.1 開始と帳票読み込み
アクティブ帳票システムを立ち上げると、[imageScan]、[file]、[imageSize]、[設定]等のメニューと、実行ボタン等が表示される。例えば、アクティブ帳票処理システムは、[imageScan]メニューが操作されることにより、スキャナを通じて帳票を読め込む。また、アクティブ帳票処理システムは、[file]メニューから既存の帳票画像を開くこともできる。アクティブ帳票処理システムは、読み込んだ帳票画像を表示することができる。また、[imageSize]メニューを通じて、画像の表示サイズを変更可能である。[設定]メニューから帳票処理システムの終了後に呼び出すアプリケーション等の設定を行う。プログレスバーを通じ帳票処理の進行状況を表示する。画像を読み込み表示して、実行ボタンが押されると、アクティブ帳票処理システムは処理を開始する。
【0099】
7.2 記入枠と手書きの分離・記入枠位置と記入枠構造の検出
図51は、アクティブ帳票処理システムの処理の流れの例である。
アクティブ帳票処理システムは、帳票の読み取り後、記入枠と記入枠マス位置を検知し、記入枠と手書きを分離する(図51の52−1)。アクティブ帳票処理システムは、記入枠ごとの枠だけの画像と手書きだけの画像を求め、記入枠を空記入枠、水平バー、手書き済み記入枠、ノイズに分類する(図51の52−2)。例えば、記入枠の手書きだけの画像の黒画素数がある値以下であれば空記入枠と判断する。記入枠の枠だけの画像に対して縦方向のヒストグラムを取り、縦方向のヒストグラムでの変動が小さく、ある値以下であれば、水平バーと判断する。また、記入枠の幅と高さが小さく、ある値以下であれば、エラーと判断する。その以外の記入枠は手書き済み記入枠とする。次に、アクティブ帳票処理システムは、記入枠ごとの枠画像に対して横方向のヒストグラムをとり、手書文字の属性、文字種、命令、見出しなどの情報が埋め込まれている枠上部と下部の位置を検出する(図51の52−3)。
【0100】
7.3 重畳情報読取り
アクティブ帳票処理システムは、記入枠ごとに、情報が埋め込まれている枠上部と下部の位置情報を、重畳情報を認識するデコードエンジンに渡し、記入枠内の重畳情報を解読する(図51の52−4)。一つの記入枠に埋め込まれた手書きの属性には、例えば、住所、メールアドレス、組織名、人名、職名、金額、番号、日時曜日、印、自由筆記、チェック、図などの種類がある。
【0101】
7.4 文字ごとへの分離とオフライン文字認識
アクティブ帳票処理システムは、解読した重畳情報に含まれる手書きの属性により、記入枠をチェック、図・印、メールアドレス、他の手書き文字の種類に分類する(図51の52−5)。アクティブ帳票処理システムは、他の手書き文字に対して、文字ごとへ分離し、重畳情報に含まれる記入枠ごとの手書きの種類に従い、文字認識を行う(図51の52−9、52−10、52−12、52−13)。これにより文字認識率を高めることができる。アクティブ帳票処理システムは、他の手書き文字の場合、手書き文字の属性によって文脈処理を適用するかどうかを決める。属性が組織名、職名、自由筆記、住所の場合に文脈処理を行う(図51の52−11)。人名、金額、番号、日時曜日の場合は文脈処理を行わない。アクティブ帳票処理システムは、メールアドレスに対しては、文字ごとへ分離して文字ごとの種類を検知し、この種類に従って文字認識を行うことで文字認識率が高められる(図51の52−6、52−7、52−8)。
【0102】
7.5 手書き文字オフライン認識結果の修正
次に、アクティブ帳票処理システムは、オフライン認識の結果を、修正インタフェースを通して修正を行う。
【0103】
7.6 命令書作成・帳票画像保存と修了
アクティブ帳票処理システムは、オフライン認識の結果を修正し終わったら、アクティブ帳票から抽出した内容を、例えばCSVファイルの形で出力する。出力されるファイルを命令書(命令書データ)と呼ぶ。アクティブ帳票処理システムの終了後に呼び出すアプリケーションは、命令書に従い帳票に対しての処理を行う。また、帳票画像を命令書と同じフォルダに保存する。
図52は、出力ファイルのフォーマットである。命令書はコンマを区切りとして、記入枠ごとの情報レコードを一行ずつに表す。一行目は列ごとの内容を表す。[name]は見出し、[property]は属性、[contents]は手書きの内容、[action]は命令、[character]は文字種である。二行目以降は記入枠ごとの情報レコードを表す。記入枠に手書きを記入してない場合、[contents]の対応の列で「、、」のように何も出力しない。
【0104】
8.評価実験
8.1 実験対象データと実験環境
A4判大の大小2種類コードの帳票2枚と、8方向線分コードの帳票2枚を1200dpiでプリントし、10人に1枚ずつ書いてもらい、全部で20枚の大小2種類コードの帳票サンプルと20枚の8方向線分コードの帳票サンプルを収集した。これら帳票を600dpi、8ビットグレーレベルでスキャンし、アクティブ帳票処理システムの予備評価を行った。図53は、評価実験に用いた8方向線分コードによる帳票である。大小2種類コードの帳票も同様のものである。
【0105】
実験環境としては、Pentium(登録商標)4の2.26GHzのCPUを有するPCを用いた。オフライン枠なし手書き文字データ収集の場合、実験用のデータということで、オンライン枠なし手書き文字実験用データの収集方法を使用し、データの筆記に際して、次のような条件を設けた。(1)文字の大きさ・文字の間隔は自由とする。(2)文字と文字の間を続けるのは不可とする。
大小2種類コード帳票の場合は、システムを簡易に仕上げるため、枠あり文字認識だけを可能とし、さらに、メールアドレスの認識率を高めるための文字ごとの字種限定は設けてない。8方向線分コード帳票の場合は、枠なし文字認識も可能とし、メールアドレスに対して、文字ごとの字種限定も実現した。
【0106】
8.2 オフライン枠なし手書き文字認識の評価項目
枠なし認識は、手書きの文字列パタンを「文字列」として認識する処理である。しかし、「文字列」の認識率を評価する場合、評価の尺度を明確にしておく必要がある。例えば、一行20字ぐらいの文字列を認識した結果、「一文字だけ誤認識した」ケースと、「ほとんどの文字を誤認識した」ケースが生じた場合、単純に両者を一行の「認識失敗」と評価するのは公正ではない。この理由から、オンライン枠なし手書き文字認識の評価項目を使用し、以下のような評価項目を設ける。
【0107】
8.2.1 文字単位の認識率
次式で表される「文字単位の認識率」を評価項目として採用する。
文字単位の認識率=正認識文字数/正解文字数
図54は、文字単位の認識率の算出方法の説明図である。例えば、「明日は晴れ」という入力パタンに対して「日月昨晴わ」という結果が返ってきたとすると、この場合、正しく認識された文字は‘晴’の一文字だけである。正解の文字数は5であるので、文字単位の認識率は、1/5=0.20=20%と計算される。
【0108】
8.2.2 正分割率
さらに、文字分割の精度に関する評価項目(「正分割率」とする)も加える。正分割率を次式で定義する。
正分割率=1−(文字分割失敗箇所の数/正解文字数)
先の図54の例では、文字分割失敗箇所は、次の二個所である。(1)本来「明」となるところを、「月」と「日」に分けてしまった。(2)本来、「日」と「は」の二文字になるところを、一文字にくっつけてしまった。したがって、正分割率は、1−2/5=60%と計算される。
【0109】
8.3 実験結果
8.3.1 大小2種類コード
図55に、大小2種類コード帳票の実験結果を示す。平均処理時間は、帳票を認識し修正インタフェースを呼び出すまでの平均処理時間である。帳票サンプルの中で、書き間違った文字(20枚の帳票サンプル中で3文字)及び、オフライン認識辞書の4443個の字種に入ってない文字(20枚の帳票サンプル中で1文字)は評価の中に入れない。
切り出した手書文字に対して記入枠から読み取った手書文字の種類に従い、認識カテゴリの字種を限定することによって認識率が59.74%から93.72%へ33.98%向上した。手書き文字の認識率はメールアドレスの認識率も含めるため、メールアドレスの認識率に左右された。そのうえ、20枚の帳票の中で2枚の帳票は書き方が乱雑で、人でも識別できない文字があったため、文字認識率を低下させる原因になった。
【0110】
帳票を読み取って修正インタフェースに渡すまでの処理時間は、本実験環境において複雑な帳票では4秒弱、簡単な帳票では2秒弱である。本実験の範囲内では、記入枠位置の検知率は100%に達した。重畳情報レコードのデコード成功率は、情報量の少ない大小2種類コードと簡単なコード重畳方法を採用し、かつ、各デーコートエラーチェックを設けなかったため、100%の認識率は得られなかった。
【0111】
8.3.2 8方向線分コード
図56に、8方向線分コードの実験結果を示す。8方向線分コード帳票の場合、枠なし手書き文字認識とメールアドレスの文字ごとの字種限定を設けたため、手書き文字の認識率項目評価においては、メールアドレス以外の枠あり手書き文字、メールアドレス、そして、枠なし手書き文字という三つの分類で評価する。平均処理時間は、帳票を認識し修正インタフェースを呼び出すまでの平均処理時間である。
帳票サンプルの中で、書き間違った文字(20枚の帳票サンプル中で2文字)は評価の中に入れない。さらに、一枚の帳票の中で、スキャンにより帳票画像にエラーが付いたため、空き記入枠なのに文字のある枠として認識されてしまった。しかし、修正インタフェースにより修正を行ったため、これも手書き文字認識率の評価に入れない。
【0112】
記入枠から読み取った手書文字の種類に従い、認識カテゴリの字種を限定することにより、メールアドレス以外の枠あり手書き文字においては、認識率が86.78%から98.85%へ12.07%向上した。メールアドレスにおいては、文字ごとの字種を限定することにより、認識率が属性を利用した認識80.19%より97.15%へ16.96%向上した。メールアドレスの10位累積認識率は、文字類を限定してもしなくてもほぼ同じであるが、1位決定率は字種を限定しない場合に激しく低下した。これは、メールアドレス認識率低下の原因が類似文字の相互的な影響からと思われる。
【0113】
帳票を読み取って修正インタフェースに渡すまでの処理時間は、本実験環境において複雑な帳票Aでは4秒程度、帳票Bでは3秒程度である。本実験の範囲内では、記入枠位置の検知率は100%に達した。重畳レコードのデコード成功率は、情報量の多い8方向線分コードと効率的なコード重畳方法を採用し、かつ、各デーコートエラーチェックを設けたため、100%の認識率を得た。枠なし手書き文字の場合は、97.71%の文字単位の認識率と98.47%正分割率を得た。
【0114】
9.線分検出、交点検出
また、ヒストグラムを用いないで、線や交点の検出から帳票構造を認識する方法には例えば、非特許文献4、5に記載の方法がある。以下に、本実施の形態における線分検出及び交点検出の概略を示す。なお、以下の各処理は、アクティブ帳票処理システム(処理部)が実行する。
【0115】
9.1 帳票の表現モデル
殆どの帳票が3種類の線セグメント(水平、垂直、斜め)を含んでいるので、これらの3種類の線セグメントにより帳票構造を表現する。一つの線セグメントは始点と終点の座標により表現される。本実施の形態に係る帳票においては、記入枠、水平バー等はドット又はコード図形で構成され、これらドット等を膨張処理して連結させることにより線分を形成し、水平、垂直、斜めの線セグメントを求める。
また、水平の線セグメントに対して、一番左の始点の座標に従い上から下へ左から右への方向でソートを行う。つまり、まずこれらの始点のY座標に従い上から下への方向でソートする。そして、同じY座標の水平線セグメントに対して、始点のX座標に従い左から右への方向でソートする。類似的に垂直線セグメントに対しては、まず一番上の始点のX座標に従い左から右へソートし、そして、同じX座標始点の垂直セグメントに対してY座標に従い上から下への方向でソートする。斜めの線セグメントも水平線セグメントと同じであるが、一番左の始点を使う代わりに一番上の始点を使いソートする。なお、ソートの方向は適宜の方向とすることができる。
【0116】
なお、帳票の表現モデルは、例えば以下に示す五つの部分から構成される。
(1)(NH、NV、NS):NH、NV、NSはそれぞれ水平、垂直と斜めの線セグメント数を表す。(2)(SLH、SLV、SLS):SLH、SLV、SLSはそれぞれ水平、垂直と斜めの線セグメントのリストを表す。(3)[(Xmin、Ymin);(Xmax、Ymax)]:全ての線セグメントを含んだ正方領域の一番左上と一番右下の座標。(4)[(XD(i)min、YD(i)min);(XD(i)max、YD(i)max)]:第i番目記入枠の正方領域の一番左上と一番右下の座標。(5)[(XN(i)min、YN(i)min);(XN(i)max、YN(i)max)]:第i番目名前枠の正方領域の一番左上と一番右下の座標。
【0117】
9.2 線セグメントの抽出と調節
ここで、帳票画像(データ)から線セグメントを抽出するまでの処理について説明する。
まず、帳票画像(データ)を入力し、傾きの補正を行う。これは、水平に近いできるだけ長い線分を正確に水平になるように画像を回転する。なお、垂直線を用いても良い。また、1本だけに着目してもよいし、複数本に着目して、それらを平均して水平、あるいは垂直するように回転しても良い。
アクティブ帳票の帳票画像に対して記入枠と手書きを分離し、記入枠だけの画像を求める。なお、記入枠と手書き枠の分離については、ラベリング等の上述と同様の方法を用いることができる。記入枠だけの画像に対し小さいドットが連結するまで膨張処理を施す。そして、3種類の線セグメント(水平、垂直、斜め)を抽出する。
抽出した線セグメントに対して、水平の線セグメントは二つの端点のY座標が所定範囲内で異なる場合は同じになるように、垂直の線セグメントは二つの端点のX座標が所定範囲で異なる場合は同じになるように、各座標の平均を取り補正することができる。このように、例えばわずかな座標のずれがある場合は、斜めの線セグメントとして扱わず水平又は垂直の線セグメントとして扱うことができる。次に、上述のようにソートを行う。
【0118】
ソートした線セグメントに対して、例えば、以下に示すような補正を行うこともできる。
(1)切れた線セグメントの連結:線セグメントを抽出しソートした後、これら線セグメントを水平、垂直、斜めの三つのグループに分ける。スキャンなどにより切れた線セグメントに対して連結処理を行う。水平線セグメントのグループにおいて、Y座標がほぼ同じ二つの線セグメントが、例えば0.5cmより近ければ、この二つの線セグメントを連結する。垂直線セグメントと斜めの線セグメントも同じである。
(2)小さい線セグメントの削除:もし、水平線セグメントの長さは、例えば、垂直線セグメント間の最小距離の85%より短ければ、この水平線セグメントをストロークの線と見なし、削除する。垂直線セグメントの長さも、例えば、水平線セグメント間の最小距離の85%より短ければ、この垂直線セグメントをストロークの線と見なし、削除する。
(3)線セグメントの補正:もし、垂直線セグメントの末端点から水平線セグメントまでの距離が0.5cmより近ければ、この垂直線セグメントを水平線セグメントに接触するように補正する。水平線セグメントと斜め線セグメントも同じである。
なお、上述の判断に用いる数値は、適宜の数値とすることができる。
【0119】
9.3 名前枠と記入枠の検知
次に、抽出した線セグメントに基づき、名前枠、記入枠を検知する処理について説明する。
普通の帳票においては、記入枠、名前枠と混合枠を含んでいる。記入枠は、データを記入してもらうための枠である。名前枠は、説明とガイダンスなどのテキストを含んだ枠である。混合枠は、記入枠と名前枠の両方を兼ねるものである。以下に説明する枠検知アルゴリズムにおいて、入力データは、ソートされた水平と垂直の線セグメントリストSLHとSLVであり、出力データは、記入枠と名前枠/混合枠の正方領域データ(記入枠データ)である。
(ステップ1)水平と垂直の線セグメントについて、全ての接触点、交差点、末端点を検出する。各水平線に関して、この水平線に接触か交差する垂直線を検出し、これらの接触点、交差点の座標を計算する。もし、水平線の端点において接触点と交差の垂直線が一つもなければ、この水平線の端点を末端点とする。なお、枠が長方形のように閉じた図形で構成されている場合は、末端点は基本的には現れないが、例えば画像のエラー、ノイズなどにより枠を構成する線分が切れたりすることで、末端点が現れる場合がある。また、枠ではなく、線分の上側又は下側に文字等を記入させる帳票の場合もある。
【0120】
接触点か交差点の分離は意味がなく、それぞれの接触点、交差点、末端点を、水平線と垂直線の位置関係等に基づき、例えば図57に示すようなタイプ1〜4の4種類に分ける。タイプ1に示す3つの接触点及び交差点は、例えば、その点が枠の上側にあることを示している。タイプ2に示す点は、例えば枠の上側又は下側にあることを示している。タイプ3に示す点は、例えば枠の下側にあることを示している。また、タイプ4は、末端点を示す。これらタイプに従い、記入枠を検知する。例えば、タイプ1の2つの点(枠の上側の2頂点を示す)と、タイプ3の2つの点(枠の下側2頂点を示す)を適宜見つけることで、枠を検知することができる。
なお、全ての点は上から下へ、左から右への順番でソートされている。なぜならば、上述のように線セグメントがソートされているからである。まず、以下の処理で使用するポインターは、ソートされた最初の点に設定される。
【0121】
(ステップ2)ポインターの指している点Aと点Aの次の点Bを調べ、以下の処理を実行して枠を検知、登録(記憶)する。(1)もし、AとBのY座標が違えばステップ4に跳ぶ。(2)もし、AとBともタイプ4に属すれば、ABの線セグメントから上の方向へ、黒いピクセルの水平線セグメントか文字列が見つかるまで、スキャンする。もし、黒いピクセルが見つからなければ、画像のトップに到着する。どちらでも、AB線を底とする正方領域を求める。もし、この正方領域の高さが、例えば0.4cmより小さければ無視し、ステップ4へ跳ぶ。そうではなければ、一つの枠として登録(記憶)する。
(3)もし、AとBともタイプ1かタイプ2に属すれば、ソートされたリストの中でB以降から、タイプ2、3に属し正方形(又は長方形、以下同じ)ABCDを形成する最初の点C、Dを見出す。もし、C、D点を見つければ正方形ABCDを枠として登録する。そうではなければステップ4へ跳ぶ。(4)もし、Aはタイプ4に、Bはタイプ1かタイプ2に属すれば、類似的に点C、Dを見出す。Cはタイプ4に、Dはタイプ2かタイプ3に属し、かつ、ABCDが正方形であるような点である。もし、C、D点を見つければ正方形ABCDを枠として登録する。そうではなければステップ4へ跳ぶ。
(5)もし、Aはタイプ1かタイプ2に、Bはタイプ4に属すれば、類似的に点C、Dを見出す。Cはタイプ2かタイプ3に、Dはタイプ4に属し、かつ、ABCDが正方形であるような点である。もし、C、D点を見つければ正方形ABCDを枠として登録する。そうではなければステップ4へ跳ぶ。(6)もし、以上の条件は全て満足しなければ、ステップ4へ跳ぶ。
【0122】
(ステップ3)ステップ2で求めた枠の正方領域をスキャンする。もし、この正方領域の黒いピクセルの数が予め定められた閾値以上であれば、名前枠/混合枠の正方領域とラベルする。そうでなければ、記入枠とラベルする。
(ステップ4)ポインターを1プラスし、次の点を指す。もし、ポインターは最後の点を指せば処理を終了する。そうでなければステップ2に跳ぶ。
【0123】
【発明の効果】
本発明によると、窓口やオフィス等で利用される帳票読取りに利用可能で、帳票記入枠と記入文字の分離が容易な帳票及び帳票処理方法、帳票処理プログラム、そのプログラムを記録した記録媒体及び帳票処理装置を提供することができる。また、本発明によると、記入文字の認識率を高めることができる。さらに、本発明によると、装置側でなく帳票側に帳票それ自身の処理方法を記述し、読取装置として汎用機を用いることができ、及び、多種の帳票を一台で処理することができる。
また、本発明によると、重畳する情報量を高めるためのドット形状を有する帳票及び帳票処理方法を提供することができる。本発明によると、手書きとの重なりや汚損から重畳情報を安定に読み取るためのコーディング方式及びデコーディング方式を提供することができる。さらに、本発明によると、特に誤読しやすい英数字記号などの補助記入方式を提供することができる。また、本発明によると、エディタで簡易に作成し、プリンタで印刷できる帳票を提供することができる。また、本発明によると、記入枠の行間の画像をスキャンする手間を省略し、処理時間を短くすることができる。
【図面の簡単な説明】
【図1】アクティブ帳票の構成図。
【図2】アクティブ帳票処理システムのハード構成図。
【図3】大小2種類の図形を用いるコード(大小2種類コード)の構成図。
【図4】8方向線分を用いるコード(8方向線分コード)の構成図。
【図5】描画エリアと配置エリアの関係。
【図6】212種類の図形を用いるコード(212種類コード)の構成図。
【図7】28種類の図形を用いるコード(28種類コード)の構成図。
【図8】重畳する情報レコードを示す図。
【図9】属性とコードが示す値の対応を示すテーブル。
【図10】文字種類及び命令と、コードが示す値との対応を示すテーブル。
【図11】情報レコードのドット列へのコーディング方法を示す図。
【図12】重畳する情報レコードを示す図。
【図13】8方向線分コードの重畳の例。
【図14】パリティ符号の設定方法の説明図。
【図15】区切り記号を表す図形。
【図16】四方向のヒストグラムによる認識方法の説明図。
【図17】標準パタンサンプルと入力コードの特徴値の抽出の説明図。
【図18】標準パタンとマッチングすることによるコードの認識の説明図。
【図19】部分的な走査による認識方法の説明図。
【図20】大小2種類コード及び8方向線分コードにより作られたドットテクスチャの記入枠。
【図21】四方向ヒストグラムとマッチングによる認識方法を試した結果。
【図22】212種類コードにより作られたドットテクスチャの記入枠。
【図23】コードの認識結果。
【図24】28種類コードにより作られたドットテクスチャの記入枠。
【図25】認識実験結果。
【図26】各種のコード形状の認識結果の比較図。
【図27】アクティブ帳票処理システムの流れ図。
【図28】記入枠と手書きの分離及び記入枠と記入枠構造の検知についてのフローチャート。
【図29】メディアンフィルタの説明図。
【図30】記入枠と手書きが重なった場合における分離されたき記入枠と手書き文字。
【図31】ヒストグラムによる記入枠及び記入枠構造の検出の説明図。
【図32】記入枠構造の検知方法についての説明図(1)。
【図33】記入枠構造の検知方法についての説明図(2)。
【図34】記入枠構造の検知方法についての説明図(3)。
【図35】帳票の空白を考慮しない方法と、考慮した方法を適用した処理結果。
【図36】記入枠検出時の情報損失防止処理の説明図。
【図37】大小2種類コードのデコーディングの流れ図。
【図38】8方向線分コードのデコーディングの流れ図。
【図39】描画エリアの大きさ算出の説明図。
【図40】コードの大きさによるコード切り出しの例。
【図41】記入枠の情報バーからコードごとの図形を切り出す切出し方向の説明図。
【図42】手書きの重なった情報レコードの検出と処理の説明図。
【図43】コード図形におけるエラーの例を示す図。
【図44】情報バーの位置検出誤差によるコード図形損傷への対応処理の説明図(1)。
【図45】情報バーの位置検出誤差によるコード図形損傷への対応処理の説明図(2)。
【図46】情報バーの位置検出誤差によるコード図形損傷への対応処理の説明図(3)。
【図47】8方向線分コードの認識についての説明図。
【図48】コードを認識のアルゴリズム。
【図49】コードを認識のプログラム例。
【図50】メールアドレスの認識率を高めるための記入枠。
【図51】アクティブ帳票処理システムの処理の流れの例。
【図52】出力ファイルのフォーマット。
【図53】評価実験に用いた帳票。
【図54】文字単位の認識率の算出方法の説明図。
【図55】大小2種類コード帳票の実験結果。
【図56】8方向線分コードの実験結果。
【図57】接触点、交差点及び末端点の分類を示す図。
【符号の説明】
10 水平バー
20 記入枠
30 情報バー
40 マス
1 処理部
2 帳票入力部
3 出力部
4 表示部
5 記憶部
Claims (34)
- 線分の傾斜又は複数の線分の組み合わせで情報が表現されるコードで構成される記入枠データと、記入された手書きデータとを含む帳票画像データを入力する帳票入力ステップと、
前記帳票入力ステップで入力された帳票画像データに基づき、記入枠データと手書きデータを分離し、及び、各記入枠データと、コードにより所定の情報が重畳された当該記入枠データ内の情報バーとを検出する記入枠検出ステップと、
検出された情報バーの各コードを切り出すステップと、
切り出されたコードの、縦方向と、横方向と、右斜め方向と、左斜め方向との4方向のヒストグラムを求めるステップと、
求められた4方向のヒストグラムに基づき、コードの形状特徴を判断し、コードを認識するコード認識ステップと
を含む帳票処理方法。 - 線分の傾斜又は複数の線分の組み合わせで情報が表現されるコードで構成される記入枠データと、記入された手書きデータとを含む帳票画像データを入力する帳票入力ステップと、
前記帳票入力ステップで入力された帳票画像データに基づき、記入枠データと手書きデータを分離し、及び、帳票画像データに対する横方向及び縦方向のヒストグラム又は線分検出並びに/若しくは交点検出に基づき、各記入枠データと、コードにより所定の情報が重畳された当該記入枠データ内の情報バーとを検出する記入枠検出ステップと、
検出された情報バーの各コードを切り出すステップと、
切り出されたコードの、縦方向と、横方向と、右斜め方向と、左斜め方向との4方向のヒストグラムを求めるステップと、
求められた4方向のヒストグラムに基づき、コードの形状特徴を判断し、コードを認識するコード認識ステップと
を含む帳票処理方法。 - ドットの幅又は線分の傾斜又は複数の線分の組み合わせで情報が表現されるコードで構成される記入枠データと、記入された手書きデータとを含む帳票画像データを入力する帳票入力ステップと、
前記帳票入力ステップで入力された帳票画像データに基づき、記入枠データと手書きデータを分離し、及び、各記入枠データと、コードにより所定の情報が重畳された当該記入枠データ内の情報バーとを検出する記入枠検出ステップと、
前記記入枠検出ステップで検出された情報バーの各コードを認識し重畳情報を抽出する重畳情報認識ステップと、
前記記入枠検出ステップで分離された手書きデータに対して、抽出された重畳情報が示す手書きデータの属性及び/又は文字種類に従い文字認識を行う文字認識ステップと、
前記文字認識ステップで認識された文字情報と、前記重畳情報認識ステップで抽出された重畳情報に基づき、他のアプリケーションシステムに所定の処理をさせるための命令書データを作成する命令書作成ステップと、
前記命令書作成ステップで作成された命令書データを出力する、及び/又は、前記帳票入力ステップで入力された帳票画像データと、当該命令書データとを対応させて記憶するステップと
を含む帳票処理方法。 - ドットの幅又は線分の傾斜又は複数の線分の組み合わせで情報が表現されるコードで構成される記入枠データと、記入された手書きデータとを含む帳票画像データを入力する帳票入力ステップと、
前記帳票入力ステップで入力された帳票画像データに基づき、記入枠データと手書きデータを分離し、及び、帳票画像データに対する横方向及び縦方向のヒストグラム又は線分検出並びに/若しくは交点検出に基づき、各記入枠データと、コードにより所定の情報が重畳された当該記入枠データ内の情報バーとを検出する記入枠検出ステップと、
前記記入枠検出ステップで検出された情報バーの各コードを認識し重畳情報を抽出する重畳情報認識ステップと、
前記記入枠検出ステップで分離された手書きデータに対して、抽出された重畳情報が示す手書きデータの属性及び/又は文字種類に従い文字認識を行う文字認識ステップと、
前記文字認識ステップで認識された文字情報と、前記重畳情報認識ステップで抽出された重畳情報に基づき、他のアプリケーションシステムに所定の処理をさせるための命令書データを作成する命令書作成ステップと、
前記命令書作成ステップで作成された命令書データを出力する、及び/又は、前記帳票入力ステップで入力された帳票画像データと、当該命令書データとを対応させて記憶するステップと
を含む帳票処理方法。 - 前記記入枠検出ステップは、
入力された帳票画像データに対し横方向へのヒストグラムをとり、当該ヒストグラムに基づき行ごとの帳票画像データを検出する行検出ステップと、
検出された行ごとの帳票画像データについて、記入枠データと手書きデータを分離する分離ステップと、
分離された行ごとの記入枠データに対して縦方向へのヒストグラムをとり、当該ヒストグラムに基づき、ひとつ又は複数の記入枠データを検出するステップと、
検出された記入枠データに対し、横方向へのヒストグラムをとり、当該ヒストグラムに基づき、当該記入枠データの情報バーを検出するステップと
を含む請求項1乃至4のいずれかに記載の帳票処理方法。 - 前記記入枠検出ステップは、
連結している黒画素の連結成分に同じラベルをつけるラベリング処理、画像の収縮及び膨張を行うモルフォロジー、画像を平滑化する効果のあるメディアンフィルタのいずれかにより記入枠データと手書きデータを分離すること
を含む請求項1乃至5のいずれかに記載の帳票処理方法。 - 前記行検出ステップは、
当該ヒストグラムの値が予め定められた閾値以下の場合、その値を無視することによりノイズの影響を取り除くこと
を含む請求項5に記載の帳票処理方法。 - 前記記入枠検出ステップは、
入力された帳票画像データに対し、横方向のヒストグラム及び/又は縦方向のヒストグラムをとるステップと、
当該ヒストグラムの値が予め定められた閾値以下の場合、その値を無視することによりノイズの影響を取り除くステップと、
当該ヒストグラムを走査し、ヒストグラムの値が所定値以下から所定値以上になる位置、又は、所定値以上から所定値以下になる位置を検出するステップと、
検出された位置から、ヒストグラムを走査した方向と逆方向又は行若しくは列の外側の方向にヒストグラムの値を辿り、ヒストグラムの値がゼロ又は所定値以下になった位置、又は、検出された位置から辿った長さが予め定められた閾値を超えてもヒストグラムの値がゼロ又は所定値以下にならない場合には、検出された位置から走査した方向と逆方向又は行若しくは列の外側方向に当該閾値分だけずらした位置を記入枠の開始又は終了の位置とするステップと、
記入枠の縦方向の開始位置と終了位置、及び/又は、横方向の開始位置と終了位置に基づき、記入枠データを検出するステップと
を含む請求項1乃至5のいずれかに記載の帳票処理方法。 - 前記記入枠検出ステップは、
記入枠データのドットを膨張し、膨張した記入枠データに対してヒストグラムを求め、当該ヒストグラムに基づき各記入枠データ及び情報バーを検出することを含む請求項1乃至5のいずれかに記載の帳票処理方法。 - 前記重畳情報認識ステップは、
高さが同じで幅の異なるドットの列で構成された情報レコードが、複数の行に所定ドット数ずつずれて配置されている情報バーに対して、横方向及び/又は縦方向のヒストグラムをとり、当該ヒストグラムに基づき行ごとのドットを切り出すステップと、
切り出された行ごとのドットの縦方向のヒストグラムを取り、該ヒストグラムに従いドットの長短を測り、各ドットが示す情報を求めて情報レコードのデータを求めるステップと、
所定ドット数ずつの行のずらしを戻すステップと、
各情報レコードの値の多数決を取ることにより情報レコードのデータを決定するステップと
を含む請求項3又は4に記載の帳票処理方法。 - 前記重畳情報認識ステップは、
前記記入枠検出ステップで検出された情報バーのコードを切り出すコード切出ステップと、
切り出されたコードを認識するコード認識ステップと、
認識されたコードが先頭の区切り記号であるかを判断し、先頭の区切り記号を検索するステップと、
前記検索するステップで検索された先頭の区切り記号から、終端の区切り記号が認識されるまでのコードに基づき、所定の情報を含む情報レコードのデータを求めるステップと、
求められた情報レコードのデータの多数決を取ることにより、情報レコードのデータを決定するステップと、
を含む請求項3又は4に記載の帳票処理方法。 - 前記コード認識ステップは、
縦方向と、横方向と、右斜め方向と、左斜め方向との4方向のヒストグラムによりコードを認識する請求項11に記載の帳票処理方法。 - 前記コード認識ステップは、
切り出されたコードに対して、予め定められた位置を順次走査することでコードを認識すること、又は、切り出されたコードの特徴値データを抽出し、予め記憶されている各コードの標準パタンの特徴値データとマッチングすることでコードを認識する請求項11に記載の帳票処理方法。 - 前記重畳情報認識ステップは、
求められた各情報レコードの長さの多数決をとることにより、情報レコードの長さを決定するステップと、
各情報レコードの長さを求め、決定された長さと異なる情報レコード及び/又は長さが所定範囲に入っていない情報レコードを削除するステップと、
情報レコードのパリティ符号をチェックし、正しくない情報レコードを削除するステップと、
をさらに含み、
削除されていない情報レコードのデータを用いて多数決を取り、情報レコードのデータを決定する請求項11に記載の帳票処理方法。 - 前記コード切出ステップは、
情報バーの左から右へ又は右から左へ列ごとのコードを切り出し、前の列と切り出した列の間隔が所定の幅より大きいときに、区切り記号が見つかるまでこの後のコード図形を無視すること
を含む請求項11に記載の帳票処理方法。 - 入力された帳票画像データの横方向のヒストグラムに基づき、帳票画像データに含まれ、コードで構成される水平バーを検出するステップと、
検出された水平バーのコードの位置を検出し、該コードの位置に基づきコード間の距離を求めるステップと、
求められたコード間の距離に基づき、コードの大きさを求めるステップと
をさらに含み、
前記コード切出ステップは、
前記記入枠検出ステップで検出された情報バーのコードを切り出し、切り出されたコードの大きさが、求められた大きさより小さい場合はそのコードを無視し、一方、大きい場合は求められた大きさ又は予め定められた大きさで切り出されたコードを分離する請求項11に記載の帳票処理方法。 - 入力された帳票画像データの横方向のヒストグラムに基づき、コードが情報バーと同じ行数だけ配置された水平バーを検出するステップと、
検出された水平バーのコード行数を求めるステップと
をさらに含み、
前記コード切出ステップは、
前記記入枠検出ステップで検出された情報バーのコードを切り出し、この列において切り出したコード数と走査した長さを求め、該コード数が求められた水平バーのコード行数に達しているか、及び/又は、走査した長さが水平バーのコード行数に応じた長さまで達しているか判断し、達していると判断された場合に切り出し処理を終了する請求項11に記載の帳票処理方法。 - 前記文字認識ステップは、
前記重畳情報認識ステップで抽出された重畳情報が示す手書きデータの属性がメールアドレスである場合に、メールアドレスの文字種を限定するための文字種記入枠に記入された文字種情報を認識し、該文字種情報に従い文字認識を行う請求項3又は4に記載の帳票処理方法。 - 前記コードは、
定められた点を通る水平方向の線分、垂直方向の線分、及び、所定角度だけ傾斜した所定数の線分のいずれかで情報が表現される請求項1乃至4のいずれかに記載の帳票処理方法。 - 前記コードは、
定められた領域の中心を通る水平方向の線分と、垂直方向の線分と、所定角度だけ傾斜した6本の線分との8本の線分のいずれかで情報が表現される請求項1乃至4のいずれかに記載の帳票処理方法。 - 前記コードは、
n角形の各辺と、当該n角形の内部を通り傾斜の異なるm本の線分とを含み、各辺及び線分の有無により2の(n+m)乗ビットの情報を表現する請求項1乃至4のいずれかに記載の帳票処理方法。 - 前記コードは、
4角形の各辺と、当該4角形の中心を通り傾斜の異なる4本の線分とを含み、各辺及び線分の有無により2の8乗ビットの情報を表現するコード、又は、8角形の各辺と、当該8角形の中心を通り傾斜の異なる4本の線分とを含み、各辺及び線分の有無により2の12乗ビットの情報を表現するコードのいずれかで構成される請求項1乃至4のいずれかに記載の帳票処理方法。 - 線分の傾斜又は複数の線分の組み合わせで情報が表現されるコードで構成される記入枠データと、記入された手書きデータとを含む帳票画像データを入力する帳票入力ステップと、
前記帳票入力ステップで入力された帳票画像データに基づき、記入枠データと手書きデータを分離し、及び、各記入枠データと、コードにより所定の情報が重畳された当該記入枠データ内の情報バーとを検出する記入枠検出ステップと、
検出された情報バーの各コードを切り出すステップと、
切り出されたコードの、縦方向と、横方向と、右斜め方向と、左斜め方向との四方向のヒストグラムを求めるステップと、
求められた四方向のヒストグラムに基づき、コードの形状特徴を判断し、コードを認識するコード認識ステップと
をコンピュータに実行させるための帳票処理プログラム。 - ドットの幅又は線分の傾斜又は複数の線分の組み合わせで情報が表現されるコードで構成される記入枠データと、記入された手書きデータとを含む帳票画像データを入力する帳票入力ステップと、
前記帳票入力ステップで入力された帳票画像データに基づき、記入枠データと手書きデータを分離し、及び、各記入枠データと、コードにより所定の情報が重畳された当該記入枠データ内の情報バーとを検出する記入枠検出ステップと、
前記記入枠検出ステップで検出された情報バーの各コードを認識し重畳情報を抽出する重畳情報認識ステップと、
前記記入枠検出ステップで分離された手書きデータに対して、抽出された重畳情報が示す手書きデータの属性及び/又は文字種類に従い文字認識を行う文字認識ステップと、
前記文字認識ステップで認識された文字情報と、前記重畳情報認識ステップで抽出された重畳情報が示す情報とに基づき、他のアプリケーションシステムに所定の処理をさせるための命令書データを作成する命令書作成ステップと、
前記命令書作成ステップで作成された命令書データを出力する、及び/又は、前記帳票入力ステップで入力された帳票画像データと、当該命令書データとを対応させて記憶するステップと
をコンピュータに実行させるための帳票処理プログラム。 - 線分の傾斜又は複数の線分の組み合わせで情報が表現されるコードで構成される記入枠データと、記入された手書きデータとを含む帳票画像データを入力する帳票入力ステップと、
前記帳票入力ステップで入力された帳票画像データに基づき、記入枠データと手書きデータを分離し、及び、各記入枠データと、コードにより所定の情報が重畳された当該記入枠データ内の情報バーとを検出する記入枠検出ステップと、
検出された情報バーの各コードを切り出すステップと、
切り出されたコードの、縦方向と、横方向と、右斜め方向と、左斜め方向との四方向のヒストグラムを求めるステップと、
求められた四方向のヒストグラムに基づき、コードの形状特徴を判断し、コードを認識するコード認識ステップと
をコンピュータに実行させるための帳票処理プログラムを記録した記録媒体。 - ドットの幅又は線分の傾斜又は複数の線分の組み合わせで情報が表現されるコードで構成される記入枠データと、記入された手書きデータとを含む帳票画像データを入力する帳票入力ステップと、
前記帳票入力ステップで入力された帳票画像データに基づき、記入枠データと手書きデータを分離し、及び、各記入枠データと、コードにより所定の情報が重畳された当該記入枠データ内の情報バーとを検出する記入枠検出ステップと、
前記記入枠検出ステップで検出された情報バーの各コードを認識し重畳情報を抽出する重畳情報認識ステップと、
前記記入枠検出ステップで分離された手書きデータに対して、抽出された重畳情報が示す手書きデータの属性及び/又は文字種類に従い文字認識を行う文字認識ステップと、
前記文字認識ステップで認識された文字情報と、前記重畳情報認識ステップで抽出された重畳情報が示す情報とに基づき、他のアプリケーションシステムに所定の処理をさせるための命令書データを作成する命令書作成ステップと、
前記命令書作成ステップで作成された命令書データを出力する、及び/又は、前記帳票入力ステップで入力された帳票画像データと、当該命令書データとを対応させて記憶するステップと
をコンピュータに実行させるための帳票処理プログラムを記録した記録媒体。 - 線分の傾斜又は複数の線分の組み合わせで情報が表現されるコードで構成される記入枠データと、記入された手書きデータとを含む帳票画像データを入力するための帳票入力部と、
入力された帳票画像データの記入枠を検出し、及び、記入枠内のコードを認識する処理部と
を備え、
前記処理部は、
前記帳票入力部から入力された帳票画像データに基づき、記入枠データと手書きデータを分離し、及び、各記入枠データと、コードにより所定の情報が重畳された当該記入枠データ内の情報バーとを検出する記入枠検出手段と、
検出された情報バーの各コードを切り出す手段と、
切り出されたコードの、縦方向と、横方向と、右斜め方向と、左斜め方向との4方向のヒストグラムを求める手段と、
求められた4方向のヒストグラムに基づき、コードの形状特徴を判断してコードを認識するコード認識手段と
を有する帳票処理装置。 - ドットの幅又は線分の傾斜又は複数の線分の組み合わせで情報が表現されるコードで構成される記入枠データと、記入された手書きデータとを含む帳票画像データを入力するための帳票入力部と、
帳票画像データ及び/又は帳票画像データに基づき作成される命令書データが記憶される記憶部と、
入力された帳票画像データに記入された手書きの情報と、記入枠に重畳された情報を認識し、所定の処理を実行する処理部と、
を備え、
前記処理部は、
前記帳票入力部から入力された帳票画像データに基づき、記入枠データと手書きデータを分離し、及び、各記入枠データと、コードにより所定の情報が重畳された当該記入枠データ内の情報バーとを検出する記入枠検出手段と、
前記記入枠検出手段で検出された情報バーの各コードを認識し重畳情報を抽出する重畳情報認識手段と、
前記記入枠検出手段で分離された手書きデータに対して、抽出された重畳情報が示す手書きデータの属性及び/又は文字種類に従い文字認識を行う文字認識手段と、
前記文字認識手段で認識された文字情報と、前記重畳情報認識手段で抽出された重畳情報に基づき、他のアプリケーションシステムに所定の処理をさせるための命令書データを作成する命令書作成手段と、
前記命令書作成手段で作成された命令書データを出力する、及び/又は、前記入力する手段で入力された帳票画像データと、当該命令書データとを対応させて前記記憶部に記憶する手段と
を有する帳票処理装置。 - ドットの幅又は線分の傾斜又は複数の線分の組み合わせで情報が表現されるコードにより所定の情報が重畳された情報レコードが、複数の行に渡り配置される情報バーを有し、該コードにより構成される記入枠と、
前記コードより構成され、帳票又は前記情報バーに関する情報を含む水平バーと
を備える帳票。 - 前記コードは、高さが同じで幅の異なるドットであり、
情報が重畳された情報レコードが、複数の行に所定のドット数だけずれて配置される請求項29に記載の帳票。 - 前記コードは、
定められた点を通る水平方向の線分、垂直方向の線分、及び、所定角度だけ傾斜した所定数の線分のいずれかで情報が表現される請求項29に記載の帳票。 - 前記コードは、
定められた領域の中心を通る水平方向の線分と、垂直方向の線分と、所定角度だけ傾斜した6本の線分との8本の線分のいずれかで情報が表現される請求項29に記載の帳票。 - 前記コードは、
n角形の各辺と、当該n角形の内部を通り傾斜の異なるm本の線分とを含み、各辺及び線分の有無により2の(n+m)乗ビットの情報を表現する請求項29に記載の帳票。 - 前記コードは、
4角形の各辺と、当該4角形の中心を通り傾斜の異なる4本の線分とを含み、各辺及び線分の有無により2の8乗ビットの情報を表現するコード、又は、8角形の各辺と、当該8角形の中心を通り傾斜の異なる4本の線分とを含み、各辺及び線分の有無により2の12乗ビットの情報を表現するコードのいずれかで構成される請求項29に記載の帳票。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003165876A JP4117648B2 (ja) | 2003-06-11 | 2003-06-11 | 帳票、帳票処理方法、帳票処理プログラム、帳票処理プログラムを記録した記録媒体及び帳票処理装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003165876A JP4117648B2 (ja) | 2003-06-11 | 2003-06-11 | 帳票、帳票処理方法、帳票処理プログラム、帳票処理プログラムを記録した記録媒体及び帳票処理装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2005004395A JP2005004395A (ja) | 2005-01-06 |
JP4117648B2 true JP4117648B2 (ja) | 2008-07-16 |
Family
ID=34092184
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2003165876A Expired - Fee Related JP4117648B2 (ja) | 2003-06-11 | 2003-06-11 | 帳票、帳票処理方法、帳票処理プログラム、帳票処理プログラムを記録した記録媒体及び帳票処理装置 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP4117648B2 (ja) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2008084218A (ja) * | 2006-09-28 | 2008-04-10 | Toshiba Corp | バーコード読み取り装置、およびバーコード読み取り方法 |
JP6773400B2 (ja) * | 2014-09-30 | 2020-10-21 | メディア株式会社 | 帳票認識装置、帳票認識システム、帳票認識システムのプログラム、帳票認識システムの制御方法、帳票認識システムプログラムを搭載した記録媒体 |
JP6524900B2 (ja) * | 2015-12-07 | 2019-06-05 | 日亜化学工業株式会社 | 二次元コード及びこれを印字した印字対象物、半導体装置及び二次元コードの検出方法 |
CN113743336B (zh) * | 2021-09-08 | 2023-06-20 | 平安科技(深圳)有限公司 | 基于深度学习的***信息识别方法、装置和计算机设备 |
-
2003
- 2003-06-11 JP JP2003165876A patent/JP4117648B2/ja not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JP2005004395A (ja) | 2005-01-06 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11922318B2 (en) | System and method of character recognition using fully convolutional neural networks with attention | |
JP3294995B2 (ja) | 帳票読取装置 | |
KR100412317B1 (ko) | 문자인식/수정방법및장치 | |
JP3822277B2 (ja) | 文字テンプレートセット学習マシン動作方法 | |
US5410611A (en) | Method for identifying word bounding boxes in text | |
US20110280481A1 (en) | User correction of errors arising in a textual document undergoing optical character recognition (ocr) process | |
JP5357612B2 (ja) | 下線除去装置 | |
US6614929B1 (en) | Apparatus and method of detecting character writing area in document, and document format generating apparatus | |
JP3485020B2 (ja) | 文字認識方法及び装置ならびに記憶媒体 | |
CN115311666A (zh) | 图文识别方法、装置、计算机设备及存储介质 | |
US8989485B2 (en) | Detecting a junction in a text line of CJK characters | |
US20110097002A1 (en) | Apparatus and method of processing image including character string | |
JPH07105312A (ja) | 光学式文字読取装置における文字イメージのごみ除去方法及び装置 | |
JP4117648B2 (ja) | 帳票、帳票処理方法、帳票処理プログラム、帳票処理プログラムを記録した記録媒体及び帳票処理装置 | |
US7142733B1 (en) | Document processing method, recording medium recording document processing program and document processing device | |
JP4810853B2 (ja) | 文字画像切出装置、文字画像切出方法およびプログラム | |
JPH10154204A (ja) | パターン認識装置及びパターン認識方法 | |
Singh et al. | Development of a page segmentation technique for Bangla documents printed in italic style | |
JP2020119291A (ja) | 情報処理装置及びプログラム | |
JP2000082110A (ja) | 罫線消去装置および文字画像抽出装置および罫線消去方法および文字画像抽出方法および記録媒体 | |
Zhu et al. | Information encoding into and decoding from dot texture for active forms | |
JP2006092345A (ja) | 文字認識装置、文字認識方法および文字認識プログラム | |
Sahle | Segmentation of Real Life Amharic Documents for Improving Recognition | |
JPH09134404A (ja) | 棒グラフ認識装置 | |
JP2000207491A (ja) | 文字列読取方法及び装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060316 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20080327 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080408 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080411 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110502 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120502 Year of fee payment: 4 |
|
LAPS | Cancellation because of no payment of annual fees |