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
【０００１】
【発明の属する技術分野】
本発明は、帳票、帳票処理方法、帳票処理プログラム、帳票処理プログラムを記録した記録媒体及び帳票処理装置に係り、特に、窓口やオフィス等で利用される帳票読み取りに利用可能な、帳票側に処理方法が記述された帳票、その帳票を処理するための帳票処理方法、帳票処理プログラム、帳票処理プログラムを記録した記録媒体及び帳票処理装置に関する。
【０００２】
【従来の技術】
従来、紙とコンピュータ処理の橋渡しとして、光学帳票読取り装置や、紙上の筆記から動的に運筆情報を読み取るタブレット、ｅ−ｐｅｎ、Ａｎｏｔｏ ｐｅｎなどの装置が知られている。しかし、後者は、筆記時に特別なデバイスが必要となる。
また、帳票の記入枠から手書きを抽出するために、記入枠にドロップアウトカラーが用いられることがある。しかし、カラーの使用はコストを高め、現在広く使われているモノクロコピー、モノクロファックスが利用できなくなるという課題がある。印刷コストや読取り装置のコスト、モノクロファックスの利用などの理由から、ドロップアウトを用いた帳票は減少し、モノクロ帳票が主流になりつつある。また、レーザビームプリンタの高精度化や、ＰｏｓｔＳｃｒｉｐｔなどのページ記述言語の一般化により、微細なドットテクスチャからなる帳票を安価なプリンタで印刷することが可能になっている。さらに、帳票作成エディタを作成することにより、誰でも簡単に帳票をデザインすることができる。手書きの帳票は入力が容易で、かつ、証拠として残ることから、電子化が進んでもなくならず、その手軽な電子化のニーズは高まっている。
【０００３】
なお、ドットで構成された記入枠を有する帳票に対する処理方法が提案されている（例えば、特許文献１、非特許文献３参照）。また、帳票に記入された文字を認識し、修正する方法が提案されている（例えば、特許文献２、３参照）。帳票側に処理を記載したアクティブ帳票システムが提案されている（例えば、特許文献１、非特許文献１、２参照）。
また、線や交点の検出から帳票構造を認識する方法が提案されている（例えば、非特許文献４、５参照）。
【０００４】
【特許文献１】
国際公開 第０１／９３１８８号パンフレット
【特許文献２】
特開２００１−０５２１１０号公報
【特許文献３】
特開２００１−０５２１１１号公報
【非特許文献１】
島村太郎、朱碧蘭、増田厚司、小沼元輝、櫻田武嗣、黒沼靖、中川正樹、「アクティブ帳票システムの設計と試作」、信学技報、2002年12月、PRMU2002-132、Vol.102、No.531、pp.19-24.
【非特許文献２】
朱 碧蘭、島村 太郎、中川 正樹、「アクティブ帳票処理技術の試作」、電子情報通信学会、信学技報、2002年12月、PRMU2002、Vol.102、No.531、pp.25-30.
【非特許文献３】
前田陽二、中川正樹、「ペーパインタフェースによる文書編集方式」、情報処理学会論文誌、2000年、Vol.41、No.5、pp.1308-1316.
【非特許文献４】
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.
【非特許文献５】
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.
【０００５】
【発明が解決しようとする課題】
しかしながら、モノクロ帳票では、帳票記入枠と手書きの分離が困難な場合があった。例えば、手書き文字が記入枠と重なった場合や、帳票の汚れ及び読み取りノイズがある場合には、正確に分離できない場合があった。また、記入された文字は、文字認識することが可能となっているが、なお誤読が生じる場合がある。特に、メールアドレスの認識には文脈処理が使えず、また、その後の処理に大きな影響を与えることが想定される。
本発明は、以上の点に鑑み、窓口やオフィス等で利用される帳票読取りに利用可能で、帳票記入枠と記入文字の分離が容易な帳票及び帳票処理方法、帳票処理プログラム、そのプログラムを記録した記録媒体及び帳票処理装置を提供することを目的とする。また、本発明は、記入文字の認識率を高めることを目的とする。さらに、本発明は、装置側でなく帳票側に帳票それ自身の処理方法を記述し、読取装置として汎用機を用いることができ、及び、多種の帳票を一台で処理することを目的とする。
【０００６】
また、本発明は、重畳する情報量を高めるためのドット形状を有する帳票及び帳票処理方法を提供することを目的とする。本発明は、手書きとの重なりや汚損から重畳情報を安定に読み取るためのコーディング方式及びデコーディング方式を提供することを目的とする。また、本発明は、特に誤読しやすい英数字記号などの補助記入方式を提供することを目的とする。さらに、本発明は、エディタで簡易に作成し、プリンタで印刷できる帳票を提供することも目的のひとつである。また、本発明は、記入枠の行間の画像をスキャンする手間を省略し、処理時間を短くすることも目的とする。
【０００７】
【課題を解決するための手段】
本発明は、記入枠に微細なドットで構成されたドットテクスチャを用いることでモノクロ環境下でも手書きとの分離を容易にし、また、そこに手書き記入の属性や読取り後の指示情報を重畳することで完全に帳票側が処理を主導するアクティブ帳票において、次のことを提供する。
記入枠内に情報を重畳するためのコード形状として、ドットテクスチャにより安定かつ大量に情報を重畳できるように、ドット形状を提案する。
【０００８】
また、コード図形の認識方法として、四方向のヒストグラムによる認識方法及び部分的な走査による認識方法を提案する。四方向のヒストグラムによる認識方法では、コードの画像に対し四方向のヒストグラムをとることによって、コードの形状特徴を判断しコードを認識する。部分的な走査による認識方法では、部分的にコード画像を走査することにより、コード図形中の線分があるべき位置ごとに順番に走査し、線分があれば対応の情報ビットを１とし、線分がなければ０とする。
【０００９】
また、記入枠の安定な検出方法として、ドットテクスチャによる記入枠の検出を容易にするために、各ドットに膨張処理をしてから縦および横方向にヒストグラムを取ることで、安定に記入枠を検出する。
帳票内の記入枠の間には空白があるので、空白の処理時間を省いて高速化する。記入枠と手書きの分離をしなくても手書きを含んだままで記入枠の行検出は行えるので（行内の位置検出には手書きが邪魔になるが、行の検出には邪魔にならない）、手書きを分離する前に行検出を行い、一行ずつの画像だけに対してラベリングをすれば、行間でのラベリング処理が省ける。
【００１０】
また、記入枠の境目を検出するときにノイズの影響を未然に防ぐ方法を提案する。縦あるいは横方向へのヒストグラムにより記入枠の位置を検出するとき、ノイズの妨げを避けるために、ヒストグラムの結果に対してある閾値以下の値を０と見なして、ノイズのある場所でも空白として無視する。こうすることにより、ノイズの影響を受けず、記入枠の位置を検出できる。しかし、閾値以下の値を０とみなしているため、記入枠の境のところで閾値以下の情報も無視されてしまい、記入枠の中に重畳した情報を読み取るには悪影響を与える。記入枠の位置を検出する時に、このような情報損失を防止するために、ヒストグラムで閾値以下のところで記入枠の位置を検出してから、さらに、この位置から記入枠の外側の方向にヒストグラムの値を辿って行き、ヒストグラムの値が０より大きい値から０になった位置、あるいは、始めの位置ｆから辿った長さがある閾値を超えてもヒストグラムの値が０にならない場合には始めの位置ｆから外側に閾値分だけずらした位置を記入枠の開始あるいは終了の位置とする。
【００１１】
また、ドットテクスチャの文書が多少傾いてスキャンされてもコード図形を切り出す方法として、ドットテクスチャにおけるドットの行数はドットの列数にくらべて少なく、縦方向へのヒストグラムの重なりは小さいことを利用して、ドットテクスチャの画像に対して縦方向のヒストグラムにとり、情報バーの左から右へ列ごとに切り出す。次に、列ごとの画像に対して横方向のヒストグラムをとり、コードごとの図形を切り出す。
【００１２】
手書きと重なって消された情報レコードを検出して読み飛ばす方法として、情報バーの画像において、左から右へ列ごとのコード図形を切り出していき、前の列と次の列の間隔が想定される幅より大きいときにコード図形と手書きが重なって手書きの分離処理によりコード図形が欠落したと判断して、この後のコード図形に対して、区切り記号が見つかるまで無視する。そうではない場合、列のコードを切り出して認識し処理を行う。
各コード図形に微小なノイズが付着して連結してしまったり微小なノイズをコード図形として処理してしまったりする誤りを防止する。例えば、切り出した図形の大きさが想定されるコード図形より小さい場合はノイズとして無視し、大きすぎる場合には、想定される大きさで分離して認識することにより、各コード図形に微小なノイズが付着して連結してしまったり微小なノイズをコード図形として処理してしまったりする誤りを防止する。
【００１３】
また、情報バーの位置検出誤差への対応方法を提案する。記入枠の情報バーとそれ以外の部分との境界線は正しい情報バーの境界線から誤差を含んで検出される場合がある。この検出された情報バー境界線に従い、コード図形を切り出してデコーディングを行うと、情報バーからはみ出したコード図形の一部を除外して認識することになり、誤認識を招く危険がある。このことを避けるために、以下の（１）から（４）の処理を実行する。（１）検出した情報バー境界線に従い、情報バーの画像に対して縦方向のヒストグラムにより、左から右へコードの列ごとの位置を検出する。（２）列ごとのコード画像に対して、横方向のヒストグラムを走査し、コードごとを切り出す。記入枠の上側情報バーの切出し方向は上から下へ、下側情報バーの切出し方向は下から上へである。この段階から以後、境界線ｂの情報を利用しない。（３）一つのコードを切り出した後、この列において切り出したコード数と走査した長さＬを調べる。情報バーのコード行数をＮとする。もし、この列のコード数がすでにＮに達しているか、あるいは、走査した長さＬがＮに応じた長さまで達していれば、コードの切出しを終了する。そうでなければ、続いてヒストグラムを走査し、コードの切出しを行う。ここで、走査した長さで終了を検出する目的は、コード図形が手書きと重なったりして欠落した場合に、情報バーの領域を越えてコードを探しに行かないようにするためである。（４）列ごとに対して、コードの切り出しが終了した時点で、そのコード数をチェックする。もしＮに達してなければ、コード数のエラーと見なし、この後のコード図形に対して、区切り記号が見つかるまで無視する。
【００１４】
また、メールアドレスの認識率を高める方法を提案する。メールアドレスに使われる文字は情報量の少ない英数字記号であり文字認識率が低く、また、意味のない文字列のために文脈処理が使えない。メールアドレス誤認識において、主な原因は類似文字への誤認識である。もし、この誤認識を避けることができれば、認識率を高めることができる。そこで、メールアドレスの文字種を限定するために、アクティブ帳票の中でメールアドレス記入枠の近くにもう一つの記入枠を設け、メールアドレスに対して対応するマスの文字種を簡単な記号で記入する。認識のしやすさと人の記入しやすさを考慮し、枠内の上や下、または両方に横線を枠に重なって記入できるようにする。
帳票は、複数の微小なドット（黒領域）又は線分を二次元に配置してなるドットテクスチャで文字入力枠が形成された文字入力用の帳票であって、２次元に配列されたドットの集まりで構成され、複数個のドットを含む幅のある線によるドットテクスチャで描かれた見出し文字と、２次元に配列されたドット又は線分の集まりで構成され、複数個のドット又は線分を含む幅のある線によるドットテクスチャで画成された記入枠とを有する。
【００１５】
処理部が、文字が入力された前記帳票から、各ドットが手書きの黒領域より小さく設定されることから、ドットテクスチャを構成する各々のドットが収縮処理により文字画像より先に消えること、又は、定められた閾値より小さい連結成分を除去すること、のいずれかによって、ドットテクスチャによる記入枠画像を除去して、記入された文字の文字画像を検出するための前記帳票を対象とする。
本方式では、微小なドットで構成されたドットテクスチャからなる記入枠を使用することによって、モノクロ環境において、手書きが記入枠に重なっても容易に分離できる。また、記入枠の中に手書きの属性、文字種を埋め込むことで、切り出した手書き文字に対して認識率を高めることができる。手書き文字の内容を属性、見出しの情報と対応付ければ、帳票ごとの設定をなくすことができる。さらに、読取り後の手書きに対する処理方法を埋め込むことで、帳票を読み込ませるだけ帳票に応じた処理を帳票側で指示するシステムが実現できる。いままで処理システム側に必要とされていたプログラムを帳票側に埋め込むことで帳票がアクティブになる。これが「アクティブ帳票」の由縁である。
【００１６】
本発明の第１の解決手段によると、
線分の傾斜又は複数の線分の組み合わせで情報が表現されるコードで構成される記入枠データと、記入された手書きデータとを含む帳票画像データを入力する帳票入力ステップと、
前記帳票入力ステップで入力された帳票画像データに基づき、記入枠データと手書きデータを分離し、及び、各記入枠データと、コードにより所定の情報が重畳された当該記入枠データ内の情報バーとを検出する記入枠検出ステップと、
検出された情報バーの各コードを切り出すステップと、
切り出されたコードの、縦方向と、横方向と、右斜め方向と、左斜め方向との四方向のヒストグラムを求めるステップと、
求められた四方向のヒストグラムに基づき、コードの形状特徴を判断し、コードを認識するコード認識ステップと
を含む帳票処理方法、これら各処理をコンピュータに実行させるための帳票処理プログラム及びそのプログラムを記録したコンピュータ読み取り可能な記録媒体が提供される。
【００１７】
本発明の第２の解決手段によると、
ドットの幅又は線分の傾斜又は複数の線分の組み合わせで情報が表現されるコードで構成される記入枠データと、記入された手書きデータとを含む帳票画像データを入力する帳票入力ステップと、
前記帳票入力ステップで入力された帳票画像データに基づき、記入枠データと手書きデータを分離し、及び、各記入枠データと、コードにより所定の情報が重畳された当該記入枠データ内の情報バーとを検出する記入枠検出ステップと、
前記記入枠検出ステップで検出された情報バーの各コードを認識し重畳情報を抽出する重畳情報認識ステップと、
前記記入枠検出ステップで分離された手書きデータに対して、抽出された重畳情報が示す手書きデータの属性及び／又は文字種類に従い文字認識を行う文字認識ステップと、
前記文字認識ステップで認識された文字情報と、前記重畳情報認識ステップで抽出された重畳情報に基づき、他のアプリケーションシステムに所定の処理をさせるための命令書データを作成する命令書作成ステップと、
前記命令書作成ステップで作成された命令書データを出力する、及び／又は、前記帳票入力ステップで入力された帳票画像データと、当該命令書データとを対応させて記憶するステップと
を含む帳票処理方法、これら各処理をコンピュータに実行させるための帳票処理プログラム及びそのプログラムを記録したコンピュータ読み取り可能な記録媒体が提供される。
【００１８】
また、本発明の第３の解決手段によると、
線分の傾斜又は複数の線分の組み合わせで情報が表現されるコードで構成される記入枠データと、記入された手書きデータとを含む帳票画像データを入力する帳票入力部と、
入力された帳票画像データの記入枠を検出し、及び、記入枠内のコードを認識する処理部と
を備え、
前記処理部は、
前記帳票入力部から帳票画像データを入力する手段と、
前記帳票入力部から入力された帳票画像データに基づき、記入枠データと手書きデータを分離し、及び、各記入枠データと、コードにより所定の情報が重畳された当該記入枠データ内の情報バーとを検出する記入枠検出手段と、
検出された情報バーの各コードを切り出す手段と、
切り出されたコードの、縦方向と、横方向と、右斜め方向と、左斜め方向との四方向のヒストグラムを求める手段と、
求められた四方向のヒストグラムに基づき、コードの形状特徴を判断してコードを認識するコード認識手段と
を有する帳票処理装置が提供される。
【００１９】
本発明の第４の解決手段によると、
ドットの幅又は線分の傾斜又は複数の線分の組み合わせで情報が表現されるコードで構成される記入枠データと、記入された手書きデータとを含む帳票画像データを入力する帳票入力部と、
帳票画像データ及び／又は帳票画像データに基づき作成される命令書データが記憶される記憶部と、
入力された帳票画像データに記入された手書きの情報と、記入枠に重畳された情報を認識し、所定の処理を実行する処理部と、
を備え、
前記処理部は、
前記帳票入力部から帳票画像データを入力する手段と、
入力された帳票画像データに基づき、記入枠データと手書きデータを分離し、及び、各記入枠データと、コードにより所定の情報が重畳された当該記入枠データ内の情報バーとを検出する記入枠検出手段と、
前記記入枠検出手段で検出された情報バーの各コードを認識し重畳情報を抽出する重畳情報認識手段と、
前記記入枠検出手段で分離された手書きデータに対して、抽出された重畳情報が示す手書きデータの属性及び／又は文字種類に従い文字認識を行う文字認識手段と、
前記文字認識手段で認識された文字情報と、前記重畳情報認識手段で抽出された重畳情報に基づき、他のアプリケーションシステムに所定の処理をさせるための命令書データを作成する命令書作成手段と、
前記命令書作成手段で作成された命令書データを出力する、及び／又は、前記入力する手段で入力された帳票画像データと、当該命令書データとを対応させて前記記憶部に記憶する手段と
を有する帳票処理装置が提供される。
【００２０】
また、本発明の解決手段のひとつでは、前記記入枠検出ステップ及び記入枠検出手段は、帳票画像データに対する横方向及び縦方向のヒストグラム又は線分検出並びに／若しくは交点検出に基づき、各記入枠データと、コードにより所定の情報が重畳された当該記入枠データ内の情報バーとを検出する。
【００２１】
さらに、本発明の第５の解決手段によると、
ドットの幅又は線分の傾斜又は複数の線分の組み合わせで情報が表現されるコードにより、所定の情報が重畳された情報レコードが複数の行に渡り配置される情報バーを有し、該コードにより構成される記入枠と、
前記コードより構成され、帳票又は前記情報バーに関する情報を含む水平バーと
を備える帳票が提供される。
【００２２】
【発明の実施の形態】
１．アクティブ帳票とその処理システムの概略
１．１ アクティブ帳票
図１は、アクティブ帳票の構成図である。
アクティブ帳票とは、記入枠に微細なドットで構成されたドットテクスチャを用いることで、モノクロ環境下でも記入枠と手書き文字の分離を可能にし、さらにドットを一様でないように分布させることで、記入文字の属性や読取り後の指示情報を記入枠に埋め込むことができる技術に基づいた帳票のことである。
帳票は、水平バー１０と、情報バー３０を有する記入枠２０とを備える。帳票標題の下などに印刷する横線は水平バー１０と呼ぶ。記入枠２０と水平バー１０はドットテクスチャで印刷される。記入枠のドットテクスチャには、記入される手書きの属性（例えば、人名、住所、メールアドレス、自由筆記など）、文字種（例えば、数字、漢字、英文など）、見出しやその処理方法（例えば、手書き文字を認識する、記載内容をメールで送信する、あるいはデータベースに保存するなど）を指示する情報（重畳情報）を記入枠上下側に重畳する。この情報が重畳される部分を情報バー３０という。また、帳票の全体に対する情報を水平バー１０に重畳する。また、記入枠の中で文字を一文字ごとに区切って記入してもらうための分割をマス４０と呼ぶ。
【００２３】
ドットテクスチャによる記入枠では、ドットを水平（行）方向および垂直（列）方向に並べてテクスチャを形成する。記入枠におけるドット行数は、水平バー１０も含めて、すべて同一とすることにより、水平バー１０のドット行数を求めれば、すべての記入枠のドット行数を容易に知ることができる。また、本実施の形態では、ドット以外に線分の傾斜又は線分の組み合わせで情報が表現されるコード図形に重畳情報を重畳することができる。この線分は、ドットを用いて構成してもよい。なお、以下の説明において、コード図形を単にドットと呼ぶ事もある。
【００２４】
１．２ アクティブ帳票処理システム
図２は、アクティブ帳票処理システムのハード構成図である。
アクティブ帳票処理システムは、例えば、処理部１と、帳票入力部２と、出力部３と、記憶部５とを備える。また、アクティブ帳票処理システムは、適宜の入力部、表示部４を備えても良い。アクティブ帳票処理システムは、例えば、読み取ったアクティブ帳票の画像データから記載内容や重畳情報を抽出し、命令書に出力する。なお、処理部の処理の詳細については後述する。記憶部５は、帳票画像データ、帳票画像データに基づき作成される命令書データが記憶される。また、記憶部５には、例えば、コードが示す値と情報が対応したテーブルが予め記憶されている。なお、記憶部５は、例えば標準パタンの特徴値と、その標準パタンが示す情報が対応したテーブルを含むことができる。
【００２５】
２． アクティブ帳票の詳細
２．１ 情報重畳のためのコード形状
アクティブ帳票では、記入枠ごとにその中に記入される手書きの属性、文字種、見出し、処理方法を指示する情報をそのドットテクスチャの中に重畳する。ドットテクスチャに情報を埋め込む方法の一つとしてドットの形状を変化させる方法が考えられる。そこで、情報を表すいくつかのコード形状について述べる。
【００２６】
図３は、大小２種類の図形を用いるコード（大小２種類コード）の構成図である。大きさの違う２種類のドットでバイナリビットの１と０を表し、これに情報を重畳する。２つコードの高さが同じでｈとする。大きいドットの幅をＬとする。コード間の隙間を考えコードを帳票に均等して配置するための領域をコードの配置エリアとする。各コードの配置エリアの大きさは同じで、コードをその中心に置く。各コードの配置エリアを碁盤の目のように縦横に隙間を空けずに配置すれば、コードとしては隙間を確保したドットテクスチャになる。後述する他の種別のコードも同様に、配置エリアの中心に置いて並べることにより、記入枠のドットテクスチャを生成する。
【００２７】
図４は、８方向線分を用いるコード（８方向線分コード）の構成図である。８方向の線分により、０から７までの図４に示す８種類のコードを表すことができる。図４では、各コードの下に示した「０００」、「００１」などの番号は、これらのコードに対応する２進数の番号である。なお、各コードには、図に示す以外にも適宜の番号を対応させることができる。また、８方向以外にも、所定の角度傾斜した線分を用いた多方向とすることもできる。コードを描画するための同じ大きさの正方形領域を描画エリアと呼ぶ。
【００２８】
図５に、描画エリアと配置エリアの関係を示す。描画エリアは配置エリアよりも小さく、配置エリアの中心に位置する。上述と同様に、配置エリアは、碁盤の目のように縦横に隙間を空けずに配置することで、各コードは隙間を確保して配置される。
図６は、２１２種類の図形を用いるコード（２１２種類コード）の構成図である。２１２種類コードは、図６に示すように、１２種類の線分の組合せで構成される。大きさａ×ａの描画エリアを基準とし、これら１２種類（１２本）の線分の有無により２１２種類、すなわち、４０９６種類のコードを作る。
【００２９】
図７は、２８種類の図形を用いるコード（２８種類コード）の構成図である。２８種類コードは、図７に示すように、８種類の線分の組合せで構成される。大きさａ×ａの描画エリアを基準とし、これら８種類（８本）の線分の有無により２８種類、すなわち、２５６種類のコードを作る。なお、２８種類コード、２１２種類コード以外にも、適宜の線分の組み合わせにより２ｎ種類コードを作成することができる。
【００３０】
２．２ 重畳情報のコーディング
ドットテクスチャの微小なドット形状を保証するため、ＰｏｓｔＳｃｒｉｐｔ言語で帳票を作り、ＰｏｓｔＳｃｒｉｐｔプリンタに帳票画像データを送り、帳票を印刷する。大小２種類コードと８方向線分コードのそれぞれのコーディングについて述べる。その他のコードは、基本的に後者のコーディングを同様に利用できる。
【００３１】
２．２．１ 大小２種類コードにおけるコーディング
図８は、重畳する情報レコードを示す図である。ドットテクスチャの記入枠ごとに図８に示す情報を重畳する。これを情報レコードと呼ぶ。例えば、情報レコードを８＋８＋８＋１６×４＋８＝９６ビットの固定長で表す。情報レコードは、例えば、記入枠の上側に重畳することができる。
図９は、属性とコードが示す値の対応を示すテーブルである。属性とは、その記入枠の中に記入される手書きの属性で、記入枠の見出し文字をカテゴリごとに分類したものである。属性には、帳票の種類、用途に応じてさまざまな種類がある。図９は、実際に使用されている帳票３６種類から見出し文字を抽出した属性の例である。図９に示すように、例えば、１４種類の属性に分類しコーディングすることができる。ただし、属性は適宜のものを用いることができ、これらには限定されない。
【００３２】
図１０は、文字種類及び命令と、コードが示す値との対応を示すテーブルである。文字種類とは、その記入枠の中に記入された手書き文字の字種のことである。命令とは、その記入枠の中に記入された手書きに対する読取り後の処理方法のことである。文字種と命令は８ビットのフラグで表現することができる。例えば、図１０に示すように、文字種類及び命令のそれぞれに対応したビット番号を立てる（例えば、１にする）。なお、文字種類及び命令は、これ以外にも適宜のものを用いることができる。例えば、「認識せよ」との命令は、「枠あり認識せよ」、「枠なし認識せよ」などとしてもよい。見出し文字には、例えば、その記入枠見出しの始り４文字のＳｈｉｆｔ−ＪＩＳコード（合計６４ビット）を埋め込む。終端記号は、８ビットの０を埋め込む。なお、アクティブ帳票処理システムの記憶部５には、例えば、図９及び図１０に示すようなテーブルが予め記憶されている。
【００３３】
図１１は、情報レコードのドット列へのコーディング方法を示す図である。
大小２種類コードを水平（行）に並べ、例えば上記の情報を記入枠の上側に重畳する。記入枠と手書き文字の重なりにより重畳情報が損失する危険があるため、同一の重畳情報を一行のドット並び内で可能な範囲で繰り返し、残りの部分には例えば０を示すドットを入れる。また、２行目以降、先頭に例えば０を示すドットを入れて２ドットずつずらし、上のドット行を繰り返す。つまり、９６ビットの情報レコードを可能な長さだけつなげ、残りの部分には０を示すドットを入れる。これらの重畳情報の多数決をとることで、損失した情報を復元することができる。なお、各行でずらすドット数は、２ドット以外にも適宜のドット数ずらすことができる。また、図１１に示すコーディング方法は、大小２種類コード以外にも、例えば８方向線分コードなどの他のコードに適用することもできる。
【００３４】
２．２．２ ８方向線分におけるコーディング
図１２は、重畳する情報レコードを示す図である。８方向線分コードは、大小２種類コードの情報の重畳方法を発展して、もっと多くの情報を重畳でき、かつエラーの検出などの効率的な重畳方法を使用することができる。記入枠ごとに図１２に示す情報レコードを重畳する。
属性は、大小２種類コードの重畳と同様とすることができる。なお、８方向線分コードの１符号の情報量が３ビットであるため、表現の都合から、例えば、図９に示した大小２種類コードの属性の末尾（又は先頭）に０をつけ、９ビットとする。文字種と命令は、９ビットのフラグで表現することができる。表現方法は、上述の図１０と同様とすることができる。また、ビット番号９の文字種類として、メールアドレスの認識率を高めるために、そこに用いられる英数字、「＠」、「．」などの字種を示す情報とすることもできる。見出し文字は、全角１文字から１０文字までのＳｈｉｆｔ−ＪＩＳコードで表す。メールアドレスの認識率向上については後述する。図１２の情報レコード（４５〜２０７ビットの不定長）を３ビットごとに区切り、それを表現するコードに変換する。各コードを含む情報レコードを記入枠の上側と下側の情報バーに重畳する。
【００３５】
図１３は、８方向線分コードの重畳の例を示す。図１３に示すように、例えば４行のドットテクスチャを考えると、列ごとに４つのコードを上から下に配置し、それを左から右へコーディングしていく。図１３に示す例では、１、２、３、４、５、６の方向で線分を配置している。情報レコードの始めと終りには区切り記号をつけ、また、終りの前にパリティ符号を置いて、さらに２番目、３番目の情報レコードを繰り返す。これを可能な範囲で繰り返す。２番目以降の情報レコードは、１番目の情報レコードと同一であり、パリティでまずエラー混入があるかどうかを検査し、さらに、複数の情報レコードの多数決をとって、損失した情報を復元することができる。
【００３６】
図１４に、パリティ符号の設定方法の説明図を示す。区切り図形間の対応する位のビットの値を排他的論理和で０になるように、パリティ符号を付加する。例えば、図１４に示すように、「０００」、「００１」、「０１０」を示すデータに対しては、各データの対応するビットの値の排他的論理和が０になるように、パリティ符号として「０１１」を示すコードを付加する。
図１５に、区切り記号を表す図形を示す。区切り記号は、情報レコードごとの境を示す機能を持ち、例えば、図４に示した８方向線分コードの番号を引き継いで８の番号とする。なお、区切り記号は図１５に示す形状以外にも、それと判別できる適宜の形状とすることができる。
【００３７】
２．３ コード図形の認識方法
コードを認識するには、以下のいずれかの方法を用いることができる。
２．３．１ 四方向のヒストグラムによる認識方法
図１６は、四方向のヒストグラムによる認識方法の説明図である。コードの画像（データ）に対し四方向（例えば、縦、横、右斜め、左斜め）のヒストグラムをとることによって、コードの形状特徴を判断しコードを認識することができる。図１６に示すようにコードによって四方向のヒストグラムがはっきり違う。
【００３８】
２．３．２ マッチングによる認識方法
全ての種類のコードに対して、大量の画像サンプルを作り、各サンプルの特徴値を抽出する。コード種類ごとに平均特徴値を求め、各コードの標準パタンを作ることができる。標準パタンサンプルの特徴値の抽出と同じ方法で入力コードの特徴値を抽出し、各コードの標準パタンとマッチングし、一番特徴の近い標準パタンを求め、この標準パタンを認識の結果とする。
図１７に、標準パタンサンプルと入力コードの特徴値の抽出の説明図を示す。特徴値の抽出方法としては、文字記号認識において一般的に用いられている方法を用いることができる。まず、線密度を計算し、線密度が均等になるように非線形正規化をし、文字画像のエッジのギザギザを消すための線の連結性を保つ平滑化を行う（図１７の（１））。次に、正規化されたパタンに対して、横、縦と斜めの４つ方向の成分を抽出する（図１７の（２））。それぞれを８×８の区画に分割し、各区画に含まれる方向成分の量を特徴として、それを６４個並べ、さらに４つの方向成分を並べて、６４×４＝２５６次元の特徴ベクトルを得る（図１７の（３））。
【００３９】
図１８に、標準パタンとマッチングすることによるコードの認識の説明図を示す。例えば、図１８の右側に示すような標準パタンの特徴値と、その標準パタンが示す情報が予め記憶部に記憶され、図１８の左側に示す読み取られたコードの特徴値を、標準パタンの特徴値と比較し、コードを認識することができる。
２．３．３ 部分的な走査による認識方法
図１９は、部分的な走査による認識方法の説明図である。部分的にコード画像を走査することによるコード図形を認識する。コード図形中の線分があるべき位置ごとに順番に走査し、線分があれば対応の情報ビットを１とし、線分がなければ０とする。図１９に示す図は、２８種類コードの例である。白い部分は線分のない部分、黒い部分は線分のある部分である。図１９では、線分のない部分を見やすくするために背景を灰色にしているが、実際の帳票では、背景と線分のない部分は同色とすることができる。コードを構成する各線は、２ビット数の桁に対応する。これらの線分を順番に走査し、線分があれば対応の桁を１とし、線分がなければ０とする。走査する部分は、コードの描画エリア又は配置エリアが切り出せれば、これらのエリア内の所定位置を走査することができる。順次走査することによって、図１９の例では、２ビットの数「１０１１０１１０」が求まる。１０進数に直すと「１８２」になる。この値が、このコードの値である。
【００４０】
２．４ 各コード形状についての検討
上述の各コードの大きさ及び各コードの認識実験結果について説明する。
【００４１】
２．４．１ 実験環境条件
各コードの作成及び認識に用いた処理装置は、Ｐｅｎｔｉｕｍ（登録商標）４の２．２６ＧＨｚのＣＰＵと、１．００ＧＢのメモリを備え、Ｗｉｎｄｏｗｓ（登録商標）ＸＰをＯＳとして搭載した機種である。
プリント精度として、安価なレーザビームプリンタでも印刷できる１２００ｄｐｉを採用した。上述のように、アクティブ帳票は、ＰｏｓｔＳｃｒｉｐｔ言語で帳票コードを作成し、ＰｏｓｔＳｃｒｉｐｔプリンタに帳票コードを送ることにより印刷することができる。プリント精度は高ければ高いほどよい。しかし、あまり高い精度を前提にすると装置コストが高くなる。実験の結果、１２００ｄｐｉの精度でプリントできる丸いドットの最小直径は０．１ｍｍである。
【００４２】
スキャンの精度は、６００ｄｐｉを採用した。帳票を読み取るスキャン精度は、高ければ高いほどいい。しかし、精度が高いと、読み込んだ帳票のサイズが大きくなり、帳票処理の時間が大きくなる。例えば、６００ｄｐｉの精度でスキャンした場合、Ａ４帳票のサイズは４９２４×６８８３の画素数となり、このサイズでの大小２種類コードの普通帳票に対しては、コンピュータの処理時間が２秒弱となる。
また、ドットテクスチャの小さいドットがスキャンにより連結しないようにするため、ドット同士の間に適切な間隔をあける必要がある。プリント時の印刷誤差及び帳票が傾いた状態でのスキャンや二値化等による誤差を含め、実験により６００ｄｐｉのスキャンでは０．２ｍｍのドット間の最小間隔があることが望ましい。このサイズは、プリント精度１２００ｄｐｉで印刷可能である。また、この間隔は、帳票の見た目を損なわない。
【００４３】
２．４．２ 各コードの検討
図２０は、大小２種類コード及び８方向線分コードにより作られたドットテクスチャの記入枠である。図２０（ａ）に、大小２種類コードにより、作られたドットテクスチャの記入枠を示す。
１２００ｄｐｉの精度でプリントできる最小サイズのドットが０．１ｍｍであることにより、図３に示すコードの高さｈは０．１ｍｍとすることができる。大きいドットと小さいドットを区別するため、帳票が傾いた状態でのスキャンや二値化などの誤差を考慮し、図３に示す大きいドットの長さＬは０．２５ｍｍとすることができる。スキャン精度で述べたように、ドット間の間隔を０．２ｍｍにするため、図３に示した長方形の配置エリアの大きさは幅０．４５×高さ０．３ｍｍすることができる。図２０（ａ）は、この大きさのコードにより作成されたドットテクスチャの記入枠の例である。この例では、記入枠の上側に情報を重畳している。
このコードは２種類だけなので、縦方向のヒストグラムをとってコードの幅を判別することによって簡易に識別することができる。上述の大きさの２種類コードの帳票１枚を認識処理してみた結果、修正インタフェースを呼び出すまでの処理時間は１７８２ｍｓである。また、識別誤りはなかった。
【００４４】
図２０（ｂ）に、８方向線分コードにより作られたドットテクスチャの記入枠を示す。８方向線分コードの線を、１２００ｄｐｉでプリントできる最小サイズである０．１ｍｍの太さとする。６００ｄｐｉのスキャンで０．１ｍｍサイズのピクセル数は３画素である。図４に示す「１００」を示すコードと「１０１」を示すコードを区別するためには、「１０１」のコードの幅（横方向）には４ピクセルが必要である。スキャンする前のサイズに換算すると０．１６８ｍｍである。誤差などを考慮し、「１０１」のコードの幅を０．２ｍｍとすることができる。この場合、描画エリアの正方形のサイズは０．４ｍｍになる。ドット間の間隔を０．２ｍｍに保証すると、配置エリアのサイズは０．６×０．６ｍｍになる。図２０（ｂ）は、この大きさのコードにより作られた記入枠の例である。この例では、図２０（ａ）と同様に、コードを横方向に各行２コードずつずらして記入枠の上側に情報を重畳している。
【００４５】
四方向のヒストグラムをとることにより、簡易に８方向線分コードを識別することができる。比較するため、マッチングによる認識方法と四方向のヒストグラムによる認識方法についてコード認識の処理を試した。マッチングによる方法の標準パタンの辞書は、８種類のコードごとに２０個ずつ合計１６０個の画像をＰｏｓｔＳｃｒｉｐｔ言語で作り、１２００ｄｐｉプリントと６００ｄｐｉスキャンにより得た画像をサンプルとし、特徴をとることにより作成した。
図２１に、四方向ヒストグラムとマッチングによる認識方法を試した結果を示す。認識率は、辞書の作成用に使った全てのサンプル画像に対しての認識率で、両方とも１００％に達している。しかし、処理時間は、ヒストグラムによる認識方法の方が早い。なお、１枚の帳票に対する処理時間は、認識した文字を修正するための修正インタフェースを呼び出すまでの処理時間を示している。
【００４６】
図２２に、２１２種類コードにより作られたドットテクスチャの記入枠を示す。
このコード形状はかなり複雑になり、コード画像が小さいと組合せの線が接触してしまい、人でも識別できなくなる場合がある。組合せの線が接触しないで人が識別できるまでのサイズのものを作り、マッチングによるデコーディング方法で識別し、９８％以上の認識率を保証できるサイズを見出した。このサイズの描画エリアは０．９×０．９ｍｍである。最小符号間隔の０．２ｍｍを考え、配置エリアは１．１×１．１ｍｍである。なお、このサイズは、プリント精度、スキャナ精度を高精度にすれば、さらに小さくすることも可能である。図２２は、この大きさのコードにより作られた記入枠の例である。この例では、記入枠の上側に情報を重畳している。
【００４７】
このコード形状は、小さくて線がかなり集まっている場合、ヒストグラムによる認識方法では特徴を識別できなくなる。ヒストグラムによる方法により識別するには、上述のサイズのよりも大きなサイズのコードとする必要がある。仮に、コードのサイズを大きくすると帳票の見た目に影響するので、ヒストグラムによる方法を止め、本例では、マッチングによる認識方法と部分的な走査による認識方法を試した。マッチングのための標準パタンの辞書は、４、０９６種類のコードごとに１７個ずつ合計６９６３２個の画像をＰｏｓｔＳｃｒｉｐｔ言語で作り、１２００ｄｐｉプリントと６００ｄｐｉスキャンにより得た画像をサンプルとし、特徴をとることにより作成した。
【００４８】
図２３に、コードの認識結果を示す。認識率は、辞書の作成用に使った全てのサンプルに対しての認識率である。また、１枚の帳票に対する処理時間は、修正インタフェースを呼び出すまでの処理時間である。処理時間と認識率ともに、部分的な走査による認識方法の方がよい。
【００４９】
図２４に、２８種類コードにより作られたドットテクスチャの記入枠を示す。２１２種類コードと同じで、このコードも小さいと組合せの線が接触してしまい、人でも識別できなくなる。組合せの線が接触しないで人が識別できるまでのサイズを作り、マッチングによる認識方法で識別し、９８％以上の認識率を保証できるサイズを見出した。このサイズの描画エリアは０．７８×０．７８ｍｍである。最小符号間隔の０．２ｍｍを考え、配置エリアは０．９８×０．９８ｍｍである。なお、このサイズは、プリント精度、スキャナ精度を高精度にすれば、さらに小さくすることも可能である。図２４は、この大きさのコード図形により作られた記入枠の例である。この例では、記入枠の上側に情報を重畳している。
【００５０】
このコードもヒストグラムによる認識方法で特徴を識別するには、上述のサイズよりも大きくする必要がある。そこで、マッチングによる認識方法と部分的な走査による認識方法を試した。マッチングの標準パタンの辞書は、２５６種類の符号ごとに７個ずつ合計１７９２個の画像をＰｏｓｔＳｃｒｉｐｔ言語で作り、１２００ｄｐｉプリントと６００ｄｐｉスキャンにより得た画像をサンプルとし、特徴をとることにより作成した。
図２５に、認識実験結果を示す。１枚の帳票に対する処理時間は修正インタフェースを呼び出すまでの処理時間である。認識率は辞書の作成用に使った全てのサンプルに対しての認識率で、両方とも１００％に達した。しかし、処理時間は部分的な走査による認識方法の方が早い。
【００５１】
２．４．３ コード形状についての比較
図２６は、各種のコード形状の認識結果の比較図である。１ビットあたりのデコード時間は、前に述べた各種コード形状に対する最速な認識方法によるデコーダエンジンに、記入枠の情報バーを渡してからデコードの結果が求まるまでの時間を、情報バーの中に埋め込んだ情報量で割った時間である。２１２種類と２８種類のコードは、現実的な大きさではコードの切出しと認識において、他のコードに比べて困難である。また、この二方式のコード形状は大きくなると、人が形を識別できてコードらしくない点も他のコードとの違いである。さらに、後の節で述べる記入枠と手書きの分離方法のうち最高速であるラベリングの方法により、この二方式のコードで作った帳票を処理すると、小さい文字（句読点など）と分離できなくなり、文字と重なる場合に文字の認識に悪影響を与える。他の方法で記入枠と手書きを分離することも可能であるが、分離の処理時間が長くなる。一方、８方向線分コードは大小２種類コードより情報量とデコード速度ともに良い。また、大小２種類コードは簡単でシステムを作りやすい。
【００５２】
３．アクティブ帳票処理のメインフローチャート
図２７に、アクティブ帳票処理システムの流れ図を示す。以下に、図２７の各処理について説明する。アクティブ帳票処理システムは、処理を開始すると、まずアクティブ帳票画像（データ）を読み込む（Ｓ１０１）。次に、アクティブ帳票処理システムは、記入枠と手書きを分離し、記入枠と例えば情報バーの位置などの記入枠構造とを検知する（Ｓ１０３）。アクティブ帳票処理システムは、情報バーの位置に従い、記入枠ごとに重畳された情報を読み取る（Ｓ１０５）。なお、ステップＳ１０３、Ｓ１０５の処理の詳細については後述する。また、アクティブ帳票処理システムは、検出した情報バーの位置、記入枠構造などのデータを適宜のタイミングで記憶部に記憶する。
【００５３】
アクティブ帳票処理システムは、重畳情報の属性により記入された手書きが文字の場合、記入枠の手書き文字の画像に対して、手書き文字の属性と文字種に従いオフライン文字認識を行う（Ｓ１０７）。アクティブ帳票処理システムは、オフライン認識の結果を修正インタフェースを通して修正する（Ｓ１０９）。修正インタフェースは、認識した文字を修正するための処理を実行する。アクティブ帳票処理システムは、アクティブ帳票から抽出した記載内容や重畳情報を、例えば、ＣＳＶファイルの形で出力する（Ｓ１１１）。これを命令書と呼ぶ。また、帳票画像を命令書とを対応させて記憶部に保存する。アクティブ帳票処理システムは、アクティブ帳票処理を終了する。その後、他のアプリケーションシステムは、命令書に従いアクティブ帳票から抽出した情報に対して処理を行う。
【００５４】
４．記入枠と手書きの分離及び記入枠と記入枠構造の検知の処理
４．１ 処理の流れ
図２８に、記入枠と手書きの分離、記入枠と記入枠構造の検知についてのフローチャートを示す。図２８に示すフローチャートは、図２７に示すフローチャートにおけるステップＳ１０３の詳細処理である。記入枠と手書きの分離をしなくても手書きを含んだままで記入枠の行検出は行えるので（行内の位置検出には手書きが邪魔になるが、行の検出には邪魔にならない）、手書きを分離する前に行検出を行い、一行ずつの画像だけに対してラベリングをすれば（アルゴリズム２とする）、行間でのラベリング処理を省くことができる。処理手順は次の通りである。
【００５５】
まず、アクティブ帳票処理システムは、全帳票画像（データ）に対し横方向へのヒストグラムをとり、行ごとの画像を検出する（Ｓ２０１）。次に、アクティブ帳票処理システムは、行ごと画像に対してラベリング処理を適用し、記入枠と手書きを分離する（Ｓ２０３）。なお、ラベリング処理以外にもモルフォロジー、メディアンフィルタの手法いて、記入枠と手書きを分離することもできる。ラベリング等については、後述する。
さらに、アクティブ帳票処理システムは、行ごとの記入枠だけの画像に対し縦方向へのヒストグラムで記入枠の位置とマス位置を検出する（Ｓ２０５）。アクティブ帳票処理システムは、記入枠ごとの画像に対し横方向へのヒストグラムで記入枠の情報バーの位置を検出する（Ｓ２０７）。なお、アクティブ帳票処理システムは、行及び記入枠の検出の際に、予め定められた閾値以下の値を０と見なして、ノイズのある場所でも空白として無視してもよい。この場合、後述する記入枠検出時の情報損失防止処理を実行するようにしてもよい。
【００５６】
４．２ 記入枠と手書きの分離方法
４．２．１ ラベリングによる手法
ラベリングは、二値画像に対して連結している黒画素の連結成分に同じラベルをつけることをいう。ラベリングの手法には再帰関数を呼び出す方法と往復走査する方法がある。
【００５７】
４．２．２ モルフォロジーの手法
帳票画像の収縮と膨張には、それぞれ以下の二つの方法がある。
収縮方法としては、（ａ）画像を走査し白画素にあったら、この画素の８近傍か４近傍の画素も白くする方法、（ｂ）画像を走査し黒画素にあったら、この画素の８近傍か４近傍を調べ、８近傍か４近傍の画素の中で一つでも白であれば、この黒画素を白にする方法のいずれかを用いる事ができる。
膨張方法としては、（ａ）画像を走査し黒画素にあったら、この画素の８近傍か４近傍の画素も黒くする方法、（ｂ）画像を走査し白画素にあったら、この画素の８近傍か４近傍を調べ、８近傍か４近傍の画素の中で一つでも黒であれば、この白画素を黒くする方法のいずれかを用いることができる。
【００５８】
４．２．３ メディンアンフィルタの手法
メディンアンフィルタはよく画像の平滑化に用いられる手法である。メディンアンフィルタとは、領域内の濃度の中央値、すなわち３×３の領域であれば、９個の濃度値を低い（または高い）順番に並べ、５番目（中央）の濃度値を、その中心の新しい濃度値とするフィルタのことである。
図２９に、メディアンフィルタの説明図を示す。中心にある目的画素の元の濃度値は２２である。３×３の領域のメディアンフィルタを使う。そのフィルタ中にある９個の濃度値を低い順番に並べると、２２、２２、２３、２４、２４、２４、２５、２６、２７という順番になる。中央値が５番目の値２４なので、目的画素の新しい濃度値を２４とする。２値画像の場合、メディアンフィルタの大きさの二分の一より小さい面積（黒画素数）の黒画素の連結成分では、この連結成分のどの黒画素にメディアンフィルタを適応しても、中央値が必ず白画素値である。したがって、この連結成分が消される。
【００５９】
４．２．４ 記入枠と手書きの分離
記入枠と手書きの分離方法では、ラベリングによる分離方法、収縮と膨張による分離方法、これらを組み合わせた分離方法、及び、メディアンフィルタによる分離方法が考えられる。
大小２種類コードによる帳票と８方向線分コードによる帳票に対し、記入枠と手書きを分離してみた。いくつかの記入枠と手書きの分離方法を比較するため、これらのサンプル帳票は普通の太さのペンで記入してもらっている。分離した結果では、収縮と膨張による分離方法で記入枠の画像に多量の手書きの跡が残った。きれいに記入枠と手書きを分離できるためには、もっと太めのペンで記入する必要がある。しかし、こうすると収縮と膨張による分離時間が長くなる。また、筆記具を制限することになる。
分離した結果によると、再帰関数を呼び出すラベリングによる分離方法が、一番高速で、かつ、手書きの太さと記入枠ドットの大きさに制限がかからない。したがって、記入枠と手書きの分離方法には再帰関数を呼び出すラベリングの方法が有効である。
図３０に、記入枠と手書きが重なった場合における分離されたき記入枠と手書き文字を示す。記入枠と手書きが重なったことが手書き分離に影響していないことが確認できる。
【００６０】
４．３ 記入枠と記入枠構造の検出
記入枠を検出するためには、線分検出、交点検出による方法（後述する）、以下で述べるような縦および横方向へのヒストグラムを取る方法などがある。アクティブ帳票方式は、記入枠の検出方法に依存せずに有効である。ただし、以下では、ヒストグラムによる方法により、更なる技術開発を行ったので、ヒストグラムによる記入枠検出について述べる。
【００６１】
４．３．１ ヒストグラムでの検出
図３１に、ヒストグラムによる記入枠及び記入枠構造の検出の説明図を示す。図２８に示す各処理を実行することにより、図３１に示すようなヒストグラムが得られる。
まず、図３１（ａ）に示すように、帳票画像全体に横方向へのヒストグラムを取り、得られたヒストグラムに従い一行ずつの記入枠を検出する（Ｓ２０１に対応）。次に、図３１（ｂ）に示すように、検出した行に対して縦方向へのヒストグラムを取り、得られたヒストグラムに従い記入枠の位置と記入枠のマスを検知する（Ｓ２０５に対応）。次に、図３１（ｃ）に示すように、検知された記入枠に対して横方向のヒストグラムを取り、得られたヒストグラムに従い記入枠の情報バー位置を検知する（Ｓ２０７に対応）。
【００６２】
４．３．２ 記入枠構造の検知方法についての検討
図３２〜図３４は、記入枠構造の検知方法についての説明図である。
図３２に示すように、記入枠の高さと幅が十分に大きいとき、縦方向と横方向へのヒストグラムにより、記入枠の構造がはっきり区別できる。ヒストグラムの最大値と最小値の中間値を求め、この中間値を閾値とし、記入枠のマス位置や情報バーの位置を検出することができる。しかし、図３３に示すように、記入枠の幅や高さが小さい場合、中間値を安定に求めることができない。なお、図３２及び図３３は、見やすさのため記入枠の大きさを拡大縮小して表示しているため、記入枠の大きさの違いが一目ではわかりづらいが、配置されたコードの数から記入枠の大きさの違いがわかる。さらに、図３４に示すような手書きとの重なりにより消された記入枠は、そのままの状態で処理すると誤った結果になることがある。よって、記入枠の構造を識別する時、まず、図３４に示すように記入枠のドットを膨張する。記入枠のドットが完全に接触するまで膨張するのは時間がかかるため、ドットのサイズに従いある程度膨張すればよい。膨張した記入枠に対して、ヒストグラムの中間値を求め、簡易に記入枠の構造を識別することができる。大小２種類コードによる記入枠は、ドットのサイズが小さいため、膨張処理を行わなくても構造を認識できる。８方向線分コードによる記入枠は、ドットのサイズと形状によりドットテクスチャがまばらになる。ヒストグラムにより記入枠構造を認識するには、膨張処理を行うことが好ましい。
【００６３】
４．３．３ 空白を考慮した処理時間短縮
図３５は、６種類の大小２種類コードと８方向線分コードの帳票に対し、帳票の空白を考慮せずに処理する方法（アルゴリズム１）と、空白を考慮して処理する方法（アルゴリズム２）を適用した処理結果である。帳票内の記入枠の間には空白があるので、上述のフローチャートに示す処理では、ラベリングでの空白の処理時間を省き帳票の処理時間が早くしている。
アルゴリズム２の処理は、図２８に示す本実施の形態に係る処理と同様である。アルゴリズム１の処理手順は以下の通りである。まず、全帳票画像に対しラベリングし記入枠と手書きを分離する。次に、記入枠だけの画像に対し横方向へのヒストグラムで行を検出する。さらに、行ごとの記入枠画像に対して縦方向へのヒストグラムで記入枠の位置とマス位置を検出する。行ごとの記入枠画像に対して横方向へのヒストグラムで記入枠の情報バー位置を検出する。アルゴリズム１では、全帳票に対してラベリングしているのに対し、アルゴリズム２では、検出された行に対してのみラベリングする点が異なる。記入枠の密度によらず、アルゴリズム２、すなわち行間の空白を考慮した方法のほうが高速である。なお、２つのアルゴリズムによる処理結果の精度は同じである。
【００６４】
４．４ 記入枠検出時の情報損失防止処理
図３６に、記入枠検出時の情報損失防止処理の説明図を示す。
横あるいは縦方向へのヒストグラムにより記入枠の位置を検出するとき、ノイズの妨げを避けるために、ヒストグラムの結果に対して予め定められた閾値以下の値を０と見なして、ノイズのある場所でも空白として無視する。図３６では、記入枠の上外側にたくさんのノイズがあるが、閾値処理をすることにより、ノイズの影響を受けず、記入枠の位置ｆを検出できる。しかし、閾値以下の値を０とみなしているため、記入枠の境のところで閾値以下の情報も無視されてしまい、記入枠の中に重畳した情報を読み取るには悪影響を与える。したがって、記入枠の位置を検出する時に、このような情報損失を防止するために、ヒストグラムで閾値以下のところで記入枠の位置ｆを検出してから、さらに、この位置ｆから記入枠の外側の方向（例えば、図３６の例では上方向）にヒストグラムの値を辿って行き、ヒストグラムの値が０より大きい値から０になった位置、あるいは、始めの位置ｆから辿った長さがある閾値を超えてもヒストグラムの値が０にならない場合には始めの位置ｆから外側に閾値分だけずらした位置を記入枠の開始あるいは終了の位置とする。こうすることにより、正しく記入枠の開始あるいは終了の位置を検出することができるとともに、記入枠外のノイズを避けることもできる。なお、図３６は、行の検出（上下に走査）の例であるが、列の検出（左右に走査）についても同様とすることができる。
【００６５】
５．デコーディング
５．１ 処理の流れ
次に、図２７のステップＳ１０５の処理（デコーディング）について説明する。
図３７に、大小２種類コードのデコーディングの流れ図を示す。図３７に示すフローチャートは、情報レコードが情報バーの横方向に配置された帳票に対するデコーディングである。
まず、アクティブ帳票処理システムは、ステップＳ１０３で検知された記入枠の情報バーに対して、横と縦方向にヒストグラムをとり、行ごとのドットを切り出す（Ｓ３０１）。次に、アクティブ帳票処理システムは、切り出された各ドットの縦方向のヒストグラムに従い、ドットの長短を測り、ドットが示す情報が１か０かを求める。例えば、アクティブ帳票処理システムは、長いドットを１、短いドットを０とする。そして、アクティブ帳票処理システムは、所定ビット、例えば２ビットずつの行のずらしを戻す（Ｓ３０５）。アクティブ帳票処理システムは、記入枠の情報バーから大量の情報レコードを求める（Ｓ３０７）。例えば、アクティブ帳票処理システムは、記入枠の情報バーから可能な限りの情報レコードを求めることができる。また、アクティブ帳票処理システムは、予め定められた数の情報バーを求めるようにしても良い。アクティブ帳票処理システムは、情報レコードの値の多数決を取ることにより重畳情報レコードを求める（Ｓ３０９）。多数決を取ることにより、エラーを回復できる。なお、上述の説明では、大小２種類コードについて説明したが、横方向に配置された他のコードを有する帳票に対しても同様とすることができる。
【００６６】
次に、８方向線分コードのデコーディングについて説明する。８方向線分コードの切出しにおいてはエラー防止と検出を行い、効率的なデコーディング方法を行う。なお、８方向線分コードの大きさは、上述のサイズとして説明する。また、実験により、描画領域が０．３５×０．３５ｍｍ、０．４５×０．４５ｍｍ、０．５×０．５ｍｍ、０．６×０．６ｍｍのサイズにおいても、デコーディングが可能であることが確認済みである。コードの大きさは大きければ大きいほど認識率が高いが、小さければ小さいほど帳票の見た目がよい。８方向線分コードのデコーディングでは、ドット同士間の必要な間隔０．２ｍｍをあけ、好きなコードサイズで帳票を作れるようにしたため、自動的にコードの大きさを検出しこの大きさに合わせたデコーディングを行う。また、８方向線分コードは区切り記号による不定長の情報レコードと情報レコードごとにパリティ符号を使うため、情報レコード長のエラーと情報レコードの内容のエラーを検出することができる。以下に、これらの処理の詳細について述べる。
【００６７】
図３８に、８方向線分コードのデコーディングの流れ図を示す。図３８に示すフローチャートは、コードとパリティ符号と区切り記号とが情報バーの縦方向に配置された帳票に対するデコーディングである。
まず、アクティブ帳票処理システムは、情報レコードをセットする（３７−０１）。例えば、ステップＳ１０３で検出された情報バー又はその一部を記憶部から読み出す。次に、アクティブ帳票処理システムは、情報レコードの先頭の区切り記号を求める。具体的には、以下のステップ３７−０２〜３７−０６の処理を実行する。まず、アクティブ帳票処理システムは、画像の終端か判断する（３７−０２）。例えば、アクティブ帳票処理システムは、次に切り出す対象となる画像（データ）が存在するか判断する。アクティブ帳票処理システムは、画像の終端の場合（３７−０２）、ステップ３７−１７の処理へ移る。一方、アクティブ帳票処理システムは、画像の終端でない場合（３７−０２）、アクティブ帳票処理システムは、コードの図形を切り出す（３７−０３）。例えば、アクティブ帳票処理システムは、縦方向及び横方向のヒストグラムの区切れを判断し、その幅に基づきコードの図形を切り出す。アクティブ帳票処理システムは、切り出しエラーか判断する（３７−０４）。切り出しエラーとしては、例えば、手書きの重なりによりコードが消されるなどの理由によりコードが切り出せないことや、切り出したコードが所定の位置になく、他のコードが消されていることが考えられる。アクティブ帳票処理システムは、切り出しエラーの場合（３７−０４）、ステップ３７−１４の処理へ移る。一方、切り出しエラーではない場合（３７−０４）、切り出したコードの図形を認識する（３７−０５）。アクティブ帳票処理システムは、認識したコードが先頭区切り記号か判断する（３７−０６）。アクティブ帳票処理システムは、認識したコードが、先頭区切り記号の場合ステップ３７−０７の処理へ移り、先頭区切り記号ではない場合はエラーとみなし、ステップ３７−１４の処理へ移る。
【００６８】
ステップ３７−１４〜３７−１６の処理では、次の終端区切り記号を見つける。まず、アクティブ帳票処理システムは、次のコードの図形を切り出す（３７−１４）。アクティブ帳票処理システムは、切り出したコードを認識する（３７−１５）。アクティブ帳票処理システムは、認識したコードが終端区切り記号か判断する（３７−１６）。なお、先頭区切り記号と終端区切り記号は、同じ記号を用いることもできる。アクティブ帳票処理システムは、認識したコードが終端区切り記号ではない場合、ステップ３７−１４に戻る。アクティブ帳票処理システムは、区切り記号を見つけるまで、ステップ３７−１４〜３７−１６を繰り返すことになる。一方、終端区切り記号の場合、ステップ３７−０１の処理へ移る。一方、アクティブ帳票処理システムは、ステップ３７−０６で認識したコードが先頭区切り記号の場合、情報レコードのデータを求める。具体的には、以下のステップ３７−０７〜３７−１３の処理を実行する。
【００６９】
まず、アクティブ帳票処理システムは、画像の終端か判断する（３７−０７）。アクティブ帳票処理システムは、画像の終端の場合（３７−０７）、ステップＳ３７−１７の処理へ移る。一方、アクティブ帳票処理システムは、画像の終端でない場合（３７−０７）、次のコードの図形を切り出す（３７−０８）。アクティブ帳票処理システムは、切り出しエラーか判断する（３７−０９）。アクティブ帳票処理システムは、切り出しエラーの場合（３７−０９）、ステップ３７−１４の処理へ移る。一方、切り出しエラーではない場合（３７−０９）、切り出したコードの図形を認識する（３７−１０）。アクティブ帳票処理システムは、認識したコードが終端区切り記号か判断する（３７−１１）。アクティブ帳票処理システムは、認識したコードが終端区切り記号ではない場合（３７−１１）、セットした情報レコードと対応させて記憶部に認識結果を格納し（３７−１２）、ステップ３７−０７の処理へ戻る。アクティブ帳票処理システムは、３７−０７以降の処理を繰り返して、終端区切り記号を見つけるまでコードを認識し、情報レコードのデータを求める。一方、アクティブ帳票処理システムは、認識したコードが終端区切り記号である場合（３７−１１）、一つの情報レコードの処理を終了し（３７−１３）、ステップ３７−０１に戻り、さらに次の情報レコードに対する処理を実行する。
【００７０】
ステップ３７−１７では、アクティブ帳票処理システムは、情報レコードに重畳され多情報を求める処理を終了し、ステップ３７−１８の処理へ移る。アクティブ帳票処理システムは、情報レコードの長さをチェックし、長さがあり得る範囲（例えば、図１２に示す例では４５〜２０７ビット）に入っていない情報レコードを削除する（３７−１８）。アクティブ帳票処理システムは、情報レコードの長さの多数決をとることにより情報レコードの長さを求める（３７−１９）。アクティブ帳票処理システムは、情報レコードの長さをチェックし、正しくない情報レコードを削除する（３７−２０）。アクティブ帳票処理システムは、情報レコードのパリティ符号をチェックし、正しくない情報レコードを削除する（３７−２１）。アクティブ帳票処理システムは、残った情報レコードの値の多数決を取ることにより、記入枠の重畳情報レコードを求める（３７−２２）。また、アクティブ帳票処理システムは、求めた情報レコードを適宜記憶部に記憶し、処理を終了する。
【００７１】
５．２ コードの大きさと情報バーのコード行数の検出
図３９は、描画エリアの大きさ算出の説明図である。図３９に示す水平バーには、一例として４行のコードが配置されている。コードの切り出しを行うため、水平バーを使ってコードの大きさと情報バーのコード行数を検出する。
まず、水平バーに対して縦方向のヒストグラムをとり、図３９に示すように、各コード図形列の中心位置を検知する。次に、各コード図形列の中心間の距離を求め、これらの距離に対して平均を求める。この結果はコード図形の配置エリア正方形の辺長である。配置エリアの辺長からドット間隔のサイズ０．２ｍｍ（６００ｄｐｉスキャンで４画素）を引くと、描画エリア正方形の辺長が求まる。
【００７２】
本実施の形態のおける帳票は、水平バーのコード行数が記入枠の情報バーのコード行数と同じであると設定しているため、水平バーに対してコード行数を検出することにより、記入枠の情報バーのコード行数を求めることができる。帳票に傾きがあると、コード行数の検出は水平バー全体に対して行うのは難しい。したがって、コードの大きさの検出時に水平バーに対して取った縦方向のヒストグラムに従い、何列かのコード図形だけに対して、横方向のヒストグラムを取ることにより、記入枠の情報バーのコード行数を検出することができる。なお、情報バーのコード行数は、水平バーのコード行数を検出することにより求める以外にも、水平バーを構成するコードにコード行数を示す情報を重畳し、そのコードを認識することにより求めるようにしてもよい。
【００７３】
５．３ コード図形の切出し
次に、コード図形の切り出し（例えば、図３８のステップ３７−０３、３７−０８、３７−１４）について説明する。
【００７４】
５．３．１ ヒストグラムによるコード図形の切出し方法の必要性
図４０は、コードの大きさによるコード切り出しの例である。
コードの大きさが検出できれば、コードの大きさを一定長としてコードを切り出す方法が考えられる。しかし、何らかの誤差（例えば、微少な誤差の累積）があるため、コードの大きさを一定長として正しくコード図形を切り出すことができない場合がある。図４０に示すように、コードの大きさＢＣを一定長として列ごとのコードを切り出し、縦線を引いて切出しの結果をシミュレーションしてみると、始めの何列かは正しく切り出すことができるが、後ろの列になると誤差が大きくなるために正しく切り出すことができない場合がある。本実施の形態にかかるアクティブ帳票処理システムにおいては、コード図形の切出しは、コードの大きさを一定長としての切り出すのではなく、ヒストグラムによる切出しを行うことで、正確なコード切り出しを実現している。
【００７５】
５．３．２ コード図形の切出し方向
まず、情報バーの画像に対して横方向のヒストグラムにとり、行ごとを切り出す。次に、行ごとの画像に対して縦方向のヒストグラムをとり、コードごとの図形を切り出す。傾きのない情報バーの場合、この切出し方向で容易にコード図形を切り出すことができる。しかし、図４１に示すように、傾いてスキャンされた情報バーの場合、この切出し方向では容易にコード図形を切り出すことができない。しかし、このような場合でも、列数にくらべ行数が少なく縦方向へのヒストグラムの重なりが小さいことに注目し、この性質を利用して情報バーが多少傾いていても正しくコードごとの図形を切り出すことができる。例えば、アクティブ帳票処理システムは、まず、情報バーの画像に対して縦方向のヒストグラムにとり、情報バーの左から右へ列ごとを切り出す。次に、列ごとの画像に対して横方向のヒストグラムをとり、コードごとの図形を切り出す。
【００７６】
５．３．３ 手書きの重なった情報レコードの検出と処理
次に、切り出しエラー（図３８の３７−０３、３７−０８、３７−１４に対応）について説明する。手書きと記入枠の重なりにより、分離した記入枠では手書きと重なる部分が消される。これを効率よく検出し、エラーのある情報レコードに対して、処理を行わない方法をとっている。図３８の３７−０３と３７−０８のコード図形の切出しにおいて、切り出されたコードに対してこのようなエラーを検出し、図３８の３７−０４と３７−０９から図３８の３７−１４、３７−１５、３７−１６の繰返し処理に移り、次の区切り記号を見つけるまで、コードを読み飛ばす。つまり、エラーのある情報レコードに対して処理を行わない。情報バーの画像において、左から右へ列ごとのコード図形を切り出していき、前の列と次の列の間隔が想定される幅より大きいときにコード図形と手書きが重なって手書きの分離処理においてコード図形が欠落したと判断する。
【００７７】
図４２は、手書きの重なった情報レコードの検出と処理の説明図である。図４２は記入の情報バーの最左部分であり、仮想的に小さい正方形でコードの描画エリアを表す。描画エリアを均一的に０．２ｍｍの最小間隔（４画素）を空けて並べることで、情報バーのドットテクスチャを形成している。描画エリア正方形の辺長ＢＢは上述の方法により水平バーから求められる。列の中心位置Ｓ＋描画エリア辺長ＢＢ／２の位置を列の最大右位置Ｒ２とし、列の縦方向ヒストグラムの実際の右位置をＲ１とする。
【００７８】
各列のコード図形を切り出す時、この列の右位置Ｒ１と基準ａの距離ｄを求め、距離ｄに従い、手書きの重なりエラーの有無を判断する。まず、基準位置ａの求め方について説明する。情報バーの画像において、左から右へ列ごとのコード図形を切り出していく。最初、基準位置ａの初期位置は情報バーの最左の位置とする。列ごとのコード図形を切り出していく度に、基準位置ａを更新していく。基準位置ａの新しい位置は、切り出した列の中心位置Ｓ＋描画エリア辺長ＢＢ／２である。つまり、基準位置ａは、初期値以外は、いつもコード列の最大右位置Ｒ２を指している。基準位置ａは列の中心位置を基準として変化していくので、始めの位置がノイズなどにより正しくなくても構わない。基準位置ａに従う手書きの重なりエラーの検出の具体的処理を以下に示す。
【００７９】
まず、アクティブ帳票処理システムは、新しいコード列を切り出すごとに、この列の右位置Ｒ１と基準ａの距離ｄを求める（例えば、ステップ３７−０３に対応）。次に、アクティブ帳票処理システムは、距離ｄが描画エリア辺長ＢＢより６画素（描画エリアの間隔４画素＋マージンとしての２画素）以上大きい場合（例えば、ステップ３７−０４に対応）、手書きの重なりエラー（切出しエラー）と見なして、この後のコード図形に対して、区切り記号が見つかるまで無視する（ステップ３７−１４〜３７−１６に対応）。一方、アクティブ帳票処理システムは、距離ｄが描画エリア辺長ＢＢより６画素以上大きくない場合、列のコードを切り出して認識する処理（例えば、ステップ３７−０５、３７−１０に対応）を行う。
【００８０】
５．３．４ コード図形におけるエラー
図４３は、コード図形におけるエラーの例を示す図である。
図４３に示すように、ノイズによってコード図形が接触し、形や大きさが異常になる場合がある。例えば、横方向の連結によるコード図形横サイズエラー、縦方向の連結によるコード図形縦サイズエラー、ノイズによるコード図形縦横サイズエラー、情報バー位置誤差による横方向のコード図形横サイズエラーなどがある。これらの異常に対して、切り出した図形の大きさが想定されるコード図形より小さい場合はノイズとして無視し、大きすぎる場合には、想定される大きさで分離して認識することにより、各コード図形に微小なノイズが付着して連結してしまったり微小なノイズをコード図形として処理してしまったりする誤りを防止する。
【００８１】
列ごとのコード図形を切り出す時、列の幅をチェックし、もし列の幅が描画エリア幅ＢＢ＋４（画素）より大きければ、コード図形の横サイズエラーと判断し、基準位置ａからＢＢ＋４の幅でこの列を分割して切り出す。８方向線分コードは線分で構成され、上述のように線の太さが０．１ｍｍ、６００ｄｐｉスキャンでのサイズが約３画素である。誤差を考慮し、コードの線太さの閾値を、例えば５画素とする。コード図形を認識できるために、描画エリアの幅ＢＢは必ず線の太さより大きい。したがって、コードの幅と高さが両方とも線太さの５画素より小さいことはあり得ない。コードごとの図形を切り出す時、コードの幅と長さをチェックし、もしコードの幅と長さの両方とも５画素以下であれば、コード図形の縦横サイズエラーと判断し、この図形を無視する。また、コード図形の長さが描画エリア幅ＢＢ＋４より大きければ、コード図形の縦サイズエラーと判断し、この図形の最上からＢＢ＋４の幅で分割して切り出す。
【００８２】
こうすることにより、各コード図形に微小なノイズが付着して連結してしまったり、微小なノイズをコード図形として処理してしまったりする誤りを防止できる。
５．３．５ 情報バーの位置検出誤差によるコード図形損傷への対応
図４４〜図４６は、情報バーの位置検出誤差によるコード図形損傷への対応処理の説明図（１）〜（３）である。
記入枠の情報バーの位置を検出するとき、図４４に示すように、例えば上述のステップＳ２０７で検出された情報バーとそれ以外の部分の境界線ｂは、正しい情報バーの境界線となんらかの誤差がある場合がある。この情報バー境界線ｂに従い、コード図形を切り出してデコーディングを行うと、情報バーからはみ出したコード図形の一部を除外して認識することになり、誤認識を招くおそれがある。このことを避けるために、アクティブ帳票処理システムは、以下のようにコードの切り出しの処理（図３８のステップ３７−０３、３７−０８、３７−１４に対応）及び切り出しエラーの処理を実行することができる。
【００８３】
アクティブ帳票処理システムは、検出した情報バー境界線ｂに従い、情報バーの画像に対して、例えば、最上のコードから境界線ｂまでのデータに対して、縦方向のヒストグラムにより、左から右へコードの列ごとの位置を検出する。次に、アクティブ帳票処理システムは、図４５示すように、列ごとのコード画像に対して、横方向のヒストグラムを走査し、コードごとを切り出す。図４５に示すように、記入枠の上側情報バーの切出し方向は上から下へ走査する。一方、下側情報バーの切出し方向は下から上へ走査する。この段階から以後、境界線ｂの情報を利用しない。
【００８４】
アクティブ帳票処理システムは、列ごとに一つづつコードを切り出した後、この列において切り出したコード数と走査した長さＬを調べる。水平バーから求められた情報バーのコード行数をＮとすると、この列のコード数がすでにＮに達しているか、及び／又は、走査した長さＬがＮに応じた長さまで達していれば、コードの切出しを終了する。そうでなければ、続いてヒストグラムを走査し、コードの切出しを行う。ここで、走査した長さで終了を検出する目的は、コード図形が手書きと重なったりして欠落した場合に、情報バーの領域を越えてコードを探しに行かないようにするためである。
アクティブ帳票処理システムは、列ごとに対して、コードの切り出しが終了した時点で、そのコード数をチェックする。もしＮに達してなければ、コード数のエラー（図３８に示す切出しエラー）と見なし、この後のコード図形に対して、区切り記号が見つかるまで無視する。
【００８５】
コード図形の切り出し段階において境界線ｂを用いないことによって、検出した情報バー境界線からはみ出したコード図形を正しく認識することができる。この方法によりコード図形を切り出した結果を図４６に示す。図４６では、便宜上切り出されたコード枠をつけて表示している。記入枠上段の情報バーでは、境界線ｂの誤差の影響を受けずに、コードが正しく切り出されていることが示されている。
【００８６】
５．４ ８方向線分コードの認識
図４７は、８方向線分コードの認識についての説明図である。
次に、コード図形の認識（図３８の３７−０５、３７−１０、３７−１５に対応）について説明する。
コードの大きさが検出できれば、コードの大きさに合わせるデコーディング方法を行うことができる。コードの描画エリア正方形の辺長はＢＢである。コード図形に対して、四方向へのヒストグラムをとる。図４７に示すように、四方向へのヒストグラムの幅を別々にｌ、ｘ、ｓ、ｈとする。エラーなどの誤差を考慮し、コードの線太さの閾値を５画素とする。
【００８７】
図４８は、コード認識のアルゴリズムである。また、図４９に、コードを認識のプログラム例を示す。
まず、アクティブ帳票処理システムは、ｈ≦５か判断する（Ｓ５０１）。アクティブ帳票処理システムは、ｙｅｓのときコード＝０とし、ｎｏのとき、ｈ≧ＢＢ−２か判断する（Ｓ５０２）。アクティブ帳票処理システムは、ｙｅｓの時ステップＳ５０３へ移り、ｎｏの時ステップＳ５０８へ移る。アクティブ帳票処理システムは、ｘ≧ＢＢ−２か判断する（Ｓ５０３）。アクティブ帳票処理システムは、ｙｅｓの時ステップＳ５０４へ移り、ｎｏの時ステップＳ５０６へ移る。アクティブ帳票処理システムは、ｓ≦５か判断する（Ｓ５０４）。アクティブ帳票処理システムは、ｙｅｓの時コード＝２とし、ｎｏの時ｌ≦５か判断する（Ｓ５０５）。アクティブ帳票処理システムは、ｙｅｓの時コード＝６とし、ｎｏの時コード＝８とする。
【００８８】
ステップ５０６では、アクティブ帳票処理システムは、ｘ＞５か判断する（Ｓ５０６）。アクティブ帳票処理システムは、ｎｏの時コード＝４とし、ｙｅｓの時ｓ＜ＢＢ−２か判断する（Ｓ５０７）。アクティブ帳票処理システムは、ｙｅｓの時コード＝３とし、ｎｏの時コード＝５とする。
ステップ５０８では、アクティブ帳票処理システムは、ｓ＜ＢＢ−２か判断する（Ｓ５０８）。アクティブ帳票処理システムは、ｙｅｓの時コード＝１とし、ｎｏの時コード＝７とする。
なお、上述の判断以外にも、コードの大きさ、線の太さに応じた適宜の判断をすることができる。また、四方向ヒストグラムを用いる以外にも、上述の部分的走査、マッチングによりコードを認識することもできる。
【００８９】
５．５ 情報レコード長エラーの検出とその処理
次に、情報レコード長エラーの検出とその処理（図３８の３７−１８、３７−１９、３７−２０に対応）について説明する。
８方向線分コードは、区切り記号により、情報レコードの長さエラーの検出を行うことができる。上述のコーディング方法で述べたように、８方向線分コードの情報レコードの長さは不定長であるが、パリティの記号を含め、コード図形の数は１６個から７０個（情報レコードは、４５〜２０７ビット）までの間にある。コード図形を認識する時、区切り記号の認識を間違うと、情報レコードの長さは１６から７０までの間になっていない場合がある。その場合、次の区切り記号までを読み飛ばして、これらの情報レコードを削除する（ステップ３７−１８）。
【００９０】
また、情報バーの全部のコードに対して、処理し認識を終えたら、複数のレコードが求まる。これらのレコードの長さがすべて同じでない場合は、それぞれの長さの多数決をとり、最多のレコード長を正しい長さとする（ステップ３７−１９に対応）。また、情報レコードの長さをチェックし、その長さが多数決により求められた長さと異なる情報レコードを削除する。残った情報レコードに対して次のパリティチェックを行う。
【００９１】
５．６ パリティ符号のチェック
情報レコードに対して、パリティ符号のチェックを行う（図３８の３７−２１に対応）。例えば、情報レコードごとに、同じ位のビットでの１の数が偶数になっているかいないかをチェックする。なっていれば、この情報レコードが正しく、なっていなければ、正しくないと判断しこの情報レコードを削除する。
【００９２】
５．７ 記入枠の重畳情報レコードの取得
以上で述べた方法により求めた情報レコードに対して、ビットごとに多数決を取る（図３８の３７−２２に対応）。こうすることにより、記入枠ごとに対して、確信度の強いデータを求めることができる。
【００９３】
６．メールアドレス認識率を高める方法
図５０は、メールアドレスの認識率を高めるための記入枠である。
メールサーバによってメールアドレスの表記法が違い、メールアドレスの文字種も違うが、一般的に使われるメールアドレス形式はドメインアドレス形式であり、その文字種は「＠」、英数字、「．」（ピリオド）、「−」（ハイフン）、「＿」（アンダーバー）である。アクティブ帳票処理では、記入枠に重畳した情報に従い、手書きの内容がメールアドレスの場合にはこれらの文字種に限定することによって認識率を高めることができる。
【００９４】
しかし、これらの文字種は、オフライン文字認識においては一般に低い認識率となり、メールアドレスの認識率がこの認識率に左右されることになる。字種を限定しても、英文大文字、英文小文字と数字などの字種が互いに影響しあい、誤認識になる傾向がある。また、メールアドレスは意味の通じない文字列なので、認識率を高める文脈処理が行えない。これも、メールアドレス認識率を高められない原因である。しかし、帳票処理システムにとっては、メールアドレスの認識は間違うと大きい過ちを犯す危険性があるので、極めて重要なことである。メールアドレス誤認識において、主な原因は類似文字への誤認識である。もし、この誤認識を避けることができれば、認識率を高めることができる。
【００９５】
図５０に示すように、メールアドレスの文字種を限定するために、例えばアクティブ帳票の中でメールアドレス記入枠の下に、もう一つの記入枠を設ける。この記入枠の中で、上のメールアドレスに対して対応するマスの文字種を記入する。認識のしやすさと人の記入しやすさを考慮し、例えば、以下のような符号を記入する。
（１）￣：英文大文字（枠に重なって記入できるようにする）
（２）＿：英文小文字（枠に重なって記入できるようにする）
（３）＝：数字（枠に重なって記入できるようにする）
（４）空白：その他
【００９６】
縦方向および横方向へのヒストグラムをとること、あるいは、枠内で３種の記号をマッチングすることによりこれらの符号を容易に、かつ、確実に認識できる。こうすることにより、メールアドレスの文字種間の相互的な影響を避けることができ、認識率が高められる。図５０に示すように、これらの記号を連続するマスにまたがって記入できるようにする。これにより、文字単位ではなく文字列単位に記入できるので指示が簡単になる。認識のためにはマスの中だけを見れば良い。なお、文字種を限定するための記入枠の情報レコードには、文字種類としてメールアドレスの認識を高めるための上述の符号が記入されることを示す適宜のデータを含むことができる。
【００９７】
７．アクティブ帳票処理システムの試作
以上で述べた技術を使いアクティブ帳票処理システムを試作した。以下、その概略について述べる。
【００９８】
７．１ 開始と帳票読み込み
アクティブ帳票システムを立ち上げると、［ｉｍａｇｅＳｃａｎ］、［ｆｉｌｅ］、［ｉｍａｇｅＳｉｚｅ］、［設定］等のメニューと、実行ボタン等が表示される。例えば、アクティブ帳票処理システムは、［ｉｍａｇｅＳｃａｎ］メニューが操作されることにより、スキャナを通じて帳票を読め込む。また、アクティブ帳票処理システムは、［ｆｉｌｅ］メニューから既存の帳票画像を開くこともできる。アクティブ帳票処理システムは、読み込んだ帳票画像を表示することができる。また、［ｉｍａｇｅＳｉｚｅ］メニューを通じて、画像の表示サイズを変更可能である。［設定］メニューから帳票処理システムの終了後に呼び出すアプリケーション等の設定を行う。プログレスバーを通じ帳票処理の進行状況を表示する。画像を読み込み表示して、実行ボタンが押されると、アクティブ帳票処理システムは処理を開始する。
【００９９】
７．２ 記入枠と手書きの分離・記入枠位置と記入枠構造の検出
図５１は、アクティブ帳票処理システムの処理の流れの例である。
アクティブ帳票処理システムは、帳票の読み取り後、記入枠と記入枠マス位置を検知し、記入枠と手書きを分離する（図５１の５２−１）。アクティブ帳票処理システムは、記入枠ごとの枠だけの画像と手書きだけの画像を求め、記入枠を空記入枠、水平バー、手書き済み記入枠、ノイズに分類する（図５１の５２−２）。例えば、記入枠の手書きだけの画像の黒画素数がある値以下であれば空記入枠と判断する。記入枠の枠だけの画像に対して縦方向のヒストグラムを取り、縦方向のヒストグラムでの変動が小さく、ある値以下であれば、水平バーと判断する。また、記入枠の幅と高さが小さく、ある値以下であれば、エラーと判断する。その以外の記入枠は手書き済み記入枠とする。次に、アクティブ帳票処理システムは、記入枠ごとの枠画像に対して横方向のヒストグラムをとり、手書文字の属性、文字種、命令、見出しなどの情報が埋め込まれている枠上部と下部の位置を検出する（図５１の５２−３）。
【０１００】
７．３ 重畳情報読取り
アクティブ帳票処理システムは、記入枠ごとに、情報が埋め込まれている枠上部と下部の位置情報を、重畳情報を認識するデコードエンジンに渡し、記入枠内の重畳情報を解読する（図５１の５２−４）。一つの記入枠に埋め込まれた手書きの属性には、例えば、住所、メールアドレス、組織名、人名、職名、金額、番号、日時曜日、印、自由筆記、チェック、図などの種類がある。
【０１０１】
７．４ 文字ごとへの分離とオフライン文字認識
アクティブ帳票処理システムは、解読した重畳情報に含まれる手書きの属性により、記入枠をチェック、図・印、メールアドレス、他の手書き文字の種類に分類する（図５１の５２−５）。アクティブ帳票処理システムは、他の手書き文字に対して、文字ごとへ分離し、重畳情報に含まれる記入枠ごとの手書きの種類に従い、文字認識を行う（図５１の５２−９、５２−１０、５２−１２、５２−１３）。これにより文字認識率を高めることができる。アクティブ帳票処理システムは、他の手書き文字の場合、手書き文字の属性によって文脈処理を適用するかどうかを決める。属性が組織名、職名、自由筆記、住所の場合に文脈処理を行う（図５１の５２−１１）。人名、金額、番号、日時曜日の場合は文脈処理を行わない。アクティブ帳票処理システムは、メールアドレスに対しては、文字ごとへ分離して文字ごとの種類を検知し、この種類に従って文字認識を行うことで文字認識率が高められる（図５１の５２−６、５２−７、５２−８）。
【０１０２】
７．５ 手書き文字オフライン認識結果の修正
次に、アクティブ帳票処理システムは、オフライン認識の結果を、修正インタフェースを通して修正を行う。
【０１０３】
７．６ 命令書作成・帳票画像保存と修了
アクティブ帳票処理システムは、オフライン認識の結果を修正し終わったら、アクティブ帳票から抽出した内容を、例えばＣＳＶファイルの形で出力する。出力されるファイルを命令書（命令書データ）と呼ぶ。アクティブ帳票処理システムの終了後に呼び出すアプリケーションは、命令書に従い帳票に対しての処理を行う。また、帳票画像を命令書と同じフォルダに保存する。
図５２は、出力ファイルのフォーマットである。命令書はコンマを区切りとして、記入枠ごとの情報レコードを一行ずつに表す。一行目は列ごとの内容を表す。［ｎａｍｅ］は見出し、［ｐｒｏｐｅｒｔｙ］は属性、［ｃｏｎｔｅｎｔｓ］は手書きの内容、［ａｃｔｉｏｎ］は命令、［ｃｈａｒａｃｔｅｒ］は文字種である。二行目以降は記入枠ごとの情報レコードを表す。記入枠に手書きを記入してない場合、［ｃｏｎｔｅｎｔｓ］の対応の列で「、、」のように何も出力しない。
【０１０４】
８．評価実験
８．１ 実験対象データと実験環境
Ａ４判大の大小２種類コードの帳票２枚と、８方向線分コードの帳票２枚を１２００ｄｐｉでプリントし、１０人に１枚ずつ書いてもらい、全部で２０枚の大小２種類コードの帳票サンプルと２０枚の８方向線分コードの帳票サンプルを収集した。これら帳票を６００ｄｐｉ、８ビットグレーレベルでスキャンし、アクティブ帳票処理システムの予備評価を行った。図５３は、評価実験に用いた８方向線分コードによる帳票である。大小２種類コードの帳票も同様のものである。
【０１０５】
実験環境としては、Ｐｅｎｔｉｕｍ（登録商標）４の２．２６ＧＨｚのＣＰＵを有するＰＣを用いた。オフライン枠なし手書き文字データ収集の場合、実験用のデータということで、オンライン枠なし手書き文字実験用データの収集方法を使用し、データの筆記に際して、次のような条件を設けた。（１）文字の大きさ・文字の間隔は自由とする。（２）文字と文字の間を続けるのは不可とする。
大小２種類コード帳票の場合は、システムを簡易に仕上げるため、枠あり文字認識だけを可能とし、さらに、メールアドレスの認識率を高めるための文字ごとの字種限定は設けてない。８方向線分コード帳票の場合は、枠なし文字認識も可能とし、メールアドレスに対して、文字ごとの字種限定も実現した。
【０１０６】
８．２ オフライン枠なし手書き文字認識の評価項目
枠なし認識は、手書きの文字列パタンを「文字列」として認識する処理である。しかし、「文字列」の認識率を評価する場合、評価の尺度を明確にしておく必要がある。例えば、一行２０字ぐらいの文字列を認識した結果、「一文字だけ誤認識した」ケースと、「ほとんどの文字を誤認識した」ケースが生じた場合、単純に両者を一行の「認識失敗」と評価するのは公正ではない。この理由から、オンライン枠なし手書き文字認識の評価項目を使用し、以下のような評価項目を設ける。
【０１０７】
８．２．１ 文字単位の認識率
次式で表される「文字単位の認識率」を評価項目として採用する。
文字単位の認識率＝正認識文字数／正解文字数
図５４は、文字単位の認識率の算出方法の説明図である。例えば、「明日は晴れ」という入力パタンに対して「日月昨晴わ」という結果が返ってきたとすると、この場合、正しく認識された文字は‘晴’の一文字だけである。正解の文字数は５であるので、文字単位の認識率は、１／５＝０．２０＝２０％と計算される。
【０１０８】
８．２．２ 正分割率
さらに、文字分割の精度に関する評価項目（「正分割率」とする）も加える。正分割率を次式で定義する。
正分割率＝１−（文字分割失敗箇所の数／正解文字数）
先の図５４の例では、文字分割失敗箇所は、次の二個所である。（１）本来「明」となるところを、「月」と「日」に分けてしまった。（２）本来、「日」と「は」の二文字になるところを、一文字にくっつけてしまった。したがって、正分割率は、１−２／５＝６０％と計算される。
【０１０９】
８．３ 実験結果
８．３．１ 大小２種類コード
図５５に、大小２種類コード帳票の実験結果を示す。平均処理時間は、帳票を認識し修正インタフェースを呼び出すまでの平均処理時間である。帳票サンプルの中で、書き間違った文字（２０枚の帳票サンプル中で３文字）及び、オフライン認識辞書の４４４３個の字種に入ってない文字（２０枚の帳票サンプル中で１文字）は評価の中に入れない。
切り出した手書文字に対して記入枠から読み取った手書文字の種類に従い、認識カテゴリの字種を限定することによって認識率が５９．７４％から９３．７２％へ３３．９８％向上した。手書き文字の認識率はメールアドレスの認識率も含めるため、メールアドレスの認識率に左右された。そのうえ、２０枚の帳票の中で２枚の帳票は書き方が乱雑で、人でも識別できない文字があったため、文字認識率を低下させる原因になった。
【０１１０】
帳票を読み取って修正インタフェースに渡すまでの処理時間は、本実験環境において複雑な帳票では４秒弱、簡単な帳票では２秒弱である。本実験の範囲内では、記入枠位置の検知率は１００％に達した。重畳情報レコードのデコード成功率は、情報量の少ない大小２種類コードと簡単なコード重畳方法を採用し、かつ、各デーコートエラーチェックを設けなかったため、１００％の認識率は得られなかった。
【０１１１】
８．３．２ ８方向線分コード
図５６に、８方向線分コードの実験結果を示す。８方向線分コード帳票の場合、枠なし手書き文字認識とメールアドレスの文字ごとの字種限定を設けたため、手書き文字の認識率項目評価においては、メールアドレス以外の枠あり手書き文字、メールアドレス、そして、枠なし手書き文字という三つの分類で評価する。平均処理時間は、帳票を認識し修正インタフェースを呼び出すまでの平均処理時間である。
帳票サンプルの中で、書き間違った文字（２０枚の帳票サンプル中で２文字）は評価の中に入れない。さらに、一枚の帳票の中で、スキャンにより帳票画像にエラーが付いたため、空き記入枠なのに文字のある枠として認識されてしまった。しかし、修正インタフェースにより修正を行ったため、これも手書き文字認識率の評価に入れない。
【０１１２】
記入枠から読み取った手書文字の種類に従い、認識カテゴリの字種を限定することにより、メールアドレス以外の枠あり手書き文字においては、認識率が８６．７８％から９８．８５％へ１２．０７％向上した。メールアドレスにおいては、文字ごとの字種を限定することにより、認識率が属性を利用した認識８０．１９％より９７．１５％へ１６．９６％向上した。メールアドレスの１０位累積認識率は、文字類を限定してもしなくてもほぼ同じであるが、１位決定率は字種を限定しない場合に激しく低下した。これは、メールアドレス認識率低下の原因が類似文字の相互的な影響からと思われる。
【０１１３】
帳票を読み取って修正インタフェースに渡すまでの処理時間は、本実験環境において複雑な帳票Ａでは４秒程度、帳票Ｂでは３秒程度である。本実験の範囲内では、記入枠位置の検知率は１００％に達した。重畳レコードのデコード成功率は、情報量の多い８方向線分コードと効率的なコード重畳方法を採用し、かつ、各デーコートエラーチェックを設けたため、１００％の認識率を得た。枠なし手書き文字の場合は、９７．７１％の文字単位の認識率と９８．４７％正分割率を得た。
【０１１４】
９．線分検出、交点検出
また、ヒストグラムを用いないで、線や交点の検出から帳票構造を認識する方法には例えば、非特許文献４、５に記載の方法がある。以下に、本実施の形態における線分検出及び交点検出の概略を示す。なお、以下の各処理は、アクティブ帳票処理システム（処理部）が実行する。
【０１１５】
９．１ 帳票の表現モデル
殆どの帳票が３種類の線セグメント（水平、垂直、斜め）を含んでいるので、これらの３種類の線セグメントにより帳票構造を表現する。一つの線セグメントは始点と終点の座標により表現される。本実施の形態に係る帳票においては、記入枠、水平バー等はドット又はコード図形で構成され、これらドット等を膨張処理して連結させることにより線分を形成し、水平、垂直、斜めの線セグメントを求める。
また、水平の線セグメントに対して、一番左の始点の座標に従い上から下へ左から右への方向でソートを行う。つまり、まずこれらの始点のＹ座標に従い上から下への方向でソートする。そして、同じＹ座標の水平線セグメントに対して、始点のＸ座標に従い左から右への方向でソートする。類似的に垂直線セグメントに対しては、まず一番上の始点のＸ座標に従い左から右へソートし、そして、同じＸ座標始点の垂直セグメントに対してＹ座標に従い上から下への方向でソートする。斜めの線セグメントも水平線セグメントと同じであるが、一番左の始点を使う代わりに一番上の始点を使いソートする。なお、ソートの方向は適宜の方向とすることができる。
【０１１６】
なお、帳票の表現モデルは、例えば以下に示す五つの部分から構成される。
（１）（ＮＨ、ＮＶ、ＮＳ）：ＮＨ、ＮＶ、ＮＳはそれぞれ水平、垂直と斜めの線セグメント数を表す。（２）（ＳＬＨ、ＳＬＶ、ＳＬＳ）：ＳＬＨ、ＳＬＶ、ＳＬＳはそれぞれ水平、垂直と斜めの線セグメントのリストを表す。（３）［（Ｘｍｉｎ、Ｙｍｉｎ）；（Ｘｍａｘ、Ｙｍａｘ）］：全ての線セグメントを含んだ正方領域の一番左上と一番右下の座標。（４）［（ＸＤ（ｉ）ｍｉｎ、ＹＤ（ｉ）ｍｉｎ）；（ＸＤ（ｉ）ｍａｘ、ＹＤ（ｉ）ｍａｘ）］：第ｉ番目記入枠の正方領域の一番左上と一番右下の座標。（５）［（ＸＮ（ｉ）ｍｉｎ、ＹＮ（ｉ）ｍｉｎ）；（ＸＮ（ｉ）ｍａｘ、ＹＮ（ｉ）ｍａｘ）］：第ｉ番目名前枠の正方領域の一番左上と一番右下の座標。
【０１１７】
９．２ 線セグメントの抽出と調節
ここで、帳票画像（データ）から線セグメントを抽出するまでの処理について説明する。
まず、帳票画像（データ）を入力し、傾きの補正を行う。これは、水平に近いできるだけ長い線分を正確に水平になるように画像を回転する。なお、垂直線を用いても良い。また、１本だけに着目してもよいし、複数本に着目して、それらを平均して水平、あるいは垂直するように回転しても良い。
アクティブ帳票の帳票画像に対して記入枠と手書きを分離し、記入枠だけの画像を求める。なお、記入枠と手書き枠の分離については、ラベリング等の上述と同様の方法を用いることができる。記入枠だけの画像に対し小さいドットが連結するまで膨張処理を施す。そして、３種類の線セグメント（水平、垂直、斜め）を抽出する。
抽出した線セグメントに対して、水平の線セグメントは二つの端点のＹ座標が所定範囲内で異なる場合は同じになるように、垂直の線セグメントは二つの端点のＸ座標が所定範囲で異なる場合は同じになるように、各座標の平均を取り補正することができる。このように、例えばわずかな座標のずれがある場合は、斜めの線セグメントとして扱わず水平又は垂直の線セグメントとして扱うことができる。次に、上述のようにソートを行う。
【０１１８】
ソートした線セグメントに対して、例えば、以下に示すような補正を行うこともできる。
（１）切れた線セグメントの連結：線セグメントを抽出しソートした後、これら線セグメントを水平、垂直、斜めの三つのグループに分ける。スキャンなどにより切れた線セグメントに対して連結処理を行う。水平線セグメントのグループにおいて、Ｙ座標がほぼ同じ二つの線セグメントが、例えば０．５ｃｍより近ければ、この二つの線セグメントを連結する。垂直線セグメントと斜めの線セグメントも同じである。
（２）小さい線セグメントの削除：もし、水平線セグメントの長さは、例えば、垂直線セグメント間の最小距離の８５％より短ければ、この水平線セグメントをストロークの線と見なし、削除する。垂直線セグメントの長さも、例えば、水平線セグメント間の最小距離の８５％より短ければ、この垂直線セグメントをストロークの線と見なし、削除する。
（３）線セグメントの補正：もし、垂直線セグメントの末端点から水平線セグメントまでの距離が０．５ｃｍより近ければ、この垂直線セグメントを水平線セグメントに接触するように補正する。水平線セグメントと斜め線セグメントも同じである。
なお、上述の判断に用いる数値は、適宜の数値とすることができる。
【０１１９】
９．３ 名前枠と記入枠の検知
次に、抽出した線セグメントに基づき、名前枠、記入枠を検知する処理について説明する。
普通の帳票においては、記入枠、名前枠と混合枠を含んでいる。記入枠は、データを記入してもらうための枠である。名前枠は、説明とガイダンスなどのテキストを含んだ枠である。混合枠は、記入枠と名前枠の両方を兼ねるものである。以下に説明する枠検知アルゴリズムにおいて、入力データは、ソートされた水平と垂直の線セグメントリストＳＬＨとＳＬＶであり、出力データは、記入枠と名前枠／混合枠の正方領域データ（記入枠データ）である。
（ステップ１）水平と垂直の線セグメントについて、全ての接触点、交差点、末端点を検出する。各水平線に関して、この水平線に接触か交差する垂直線を検出し、これらの接触点、交差点の座標を計算する。もし、水平線の端点において接触点と交差の垂直線が一つもなければ、この水平線の端点を末端点とする。なお、枠が長方形のように閉じた図形で構成されている場合は、末端点は基本的には現れないが、例えば画像のエラー、ノイズなどにより枠を構成する線分が切れたりすることで、末端点が現れる場合がある。また、枠ではなく、線分の上側又は下側に文字等を記入させる帳票の場合もある。
【０１２０】
接触点か交差点の分離は意味がなく、それぞれの接触点、交差点、末端点を、水平線と垂直線の位置関係等に基づき、例えば図５７に示すようなタイプ１〜４の４種類に分ける。タイプ１に示す３つの接触点及び交差点は、例えば、その点が枠の上側にあることを示している。タイプ２に示す点は、例えば枠の上側又は下側にあることを示している。タイプ３に示す点は、例えば枠の下側にあることを示している。また、タイプ４は、末端点を示す。これらタイプに従い、記入枠を検知する。例えば、タイプ１の２つの点（枠の上側の２頂点を示す）と、タイプ３の２つの点（枠の下側２頂点を示す）を適宜見つけることで、枠を検知することができる。
なお、全ての点は上から下へ、左から右への順番でソートされている。なぜならば、上述のように線セグメントがソートされているからである。まず、以下の処理で使用するポインターは、ソートされた最初の点に設定される。
【０１２１】
（ステップ２）ポインターの指している点Ａと点Ａの次の点Ｂを調べ、以下の処理を実行して枠を検知、登録（記憶）する。（１）もし、ＡとＢのＹ座標が違えばステップ４に跳ぶ。（２）もし、ＡとＢともタイプ４に属すれば、ＡＢの線セグメントから上の方向へ、黒いピクセルの水平線セグメントか文字列が見つかるまで、スキャンする。もし、黒いピクセルが見つからなければ、画像のトップに到着する。どちらでも、ＡＢ線を底とする正方領域を求める。もし、この正方領域の高さが、例えば０．４ｃｍより小さければ無視し、ステップ４へ跳ぶ。そうではなければ、一つの枠として登録（記憶）する。
（３）もし、ＡとＢともタイプ１かタイプ２に属すれば、ソートされたリストの中でＢ以降から、タイプ２、３に属し正方形（又は長方形、以下同じ）ＡＢＣＤを形成する最初の点Ｃ、Ｄを見出す。もし、Ｃ、Ｄ点を見つければ正方形ＡＢＣＤを枠として登録する。そうではなければステップ４へ跳ぶ。（４）もし、Ａはタイプ４に、Ｂはタイプ１かタイプ２に属すれば、類似的に点Ｃ、Ｄを見出す。Ｃはタイプ４に、Ｄはタイプ２かタイプ３に属し、かつ、ＡＢＣＤが正方形であるような点である。もし、Ｃ、Ｄ点を見つければ正方形ＡＢＣＤを枠として登録する。そうではなければステップ４へ跳ぶ。
（５）もし、Ａはタイプ１かタイプ２に、Ｂはタイプ４に属すれば、類似的に点Ｃ、Ｄを見出す。Ｃはタイプ２かタイプ３に、Ｄはタイプ４に属し、かつ、ＡＢＣＤが正方形であるような点である。もし、Ｃ、Ｄ点を見つければ正方形ＡＢＣＤを枠として登録する。そうではなければステップ４へ跳ぶ。（６）もし、以上の条件は全て満足しなければ、ステップ４へ跳ぶ。
【０１２２】
（ステップ３）ステップ２で求めた枠の正方領域をスキャンする。もし、この正方領域の黒いピクセルの数が予め定められた閾値以上であれば、名前枠／混合枠の正方領域とラベルする。そうでなければ、記入枠とラベルする。
（ステップ４）ポインターを１プラスし、次の点を指す。もし、ポインターは最後の点を指せば処理を終了する。そうでなければステップ２に跳ぶ。
【０１２３】
【発明の効果】
本発明によると、窓口やオフィス等で利用される帳票読取りに利用可能で、帳票記入枠と記入文字の分離が容易な帳票及び帳票処理方法、帳票処理プログラム、そのプログラムを記録した記録媒体及び帳票処理装置を提供することができる。また、本発明によると、記入文字の認識率を高めることができる。さらに、本発明によると、装置側でなく帳票側に帳票それ自身の処理方法を記述し、読取装置として汎用機を用いることができ、及び、多種の帳票を一台で処理することができる。
また、本発明によると、重畳する情報量を高めるためのドット形状を有する帳票及び帳票処理方法を提供することができる。本発明によると、手書きとの重なりや汚損から重畳情報を安定に読み取るためのコーディング方式及びデコーディング方式を提供することができる。さらに、本発明によると、特に誤読しやすい英数字記号などの補助記入方式を提供することができる。また、本発明によると、エディタで簡易に作成し、プリンタで印刷できる帳票を提供することができる。また、本発明によると、記入枠の行間の画像をスキャンする手間を省略し、処理時間を短くすることができる。
【図面の簡単な説明】
【図１】アクティブ帳票の構成図。
【図２】アクティブ帳票処理システムのハード構成図。
【図３】大小２種類の図形を用いるコード（大小２種類コード）の構成図。
【図４】８方向線分を用いるコード（８方向線分コード）の構成図。
【図５】描画エリアと配置エリアの関係。
【図６】２１２種類の図形を用いるコード（２１２種類コード）の構成図。
【図７】２８種類の図形を用いるコード（２８種類コード）の構成図。
【図８】重畳する情報レコードを示す図。
【図９】属性とコードが示す値の対応を示すテーブル。
【図１０】文字種類及び命令と、コードが示す値との対応を示すテーブル。
【図１１】情報レコードのドット列へのコーディング方法を示す図。
【図１２】重畳する情報レコードを示す図。
【図１３】８方向線分コードの重畳の例。
【図１４】パリティ符号の設定方法の説明図。
【図１５】区切り記号を表す図形。
【図１６】四方向のヒストグラムによる認識方法の説明図。
【図１７】標準パタンサンプルと入力コードの特徴値の抽出の説明図。
【図１８】標準パタンとマッチングすることによるコードの認識の説明図。
【図１９】部分的な走査による認識方法の説明図。
【図２０】大小２種類コード及び８方向線分コードにより作られたドットテクスチャの記入枠。
【図２１】四方向ヒストグラムとマッチングによる認識方法を試した結果。
【図２２】２１２種類コードにより作られたドットテクスチャの記入枠。
【図２３】コードの認識結果。
【図２４】２８種類コードにより作られたドットテクスチャの記入枠。
【図２５】認識実験結果。
【図２６】各種のコード形状の認識結果の比較図。
【図２７】アクティブ帳票処理システムの流れ図。
【図２８】記入枠と手書きの分離及び記入枠と記入枠構造の検知についてのフローチャート。
【図２９】メディアンフィルタの説明図。
【図３０】記入枠と手書きが重なった場合における分離されたき記入枠と手書き文字。
【図３１】ヒストグラムによる記入枠及び記入枠構造の検出の説明図。
【図３２】記入枠構造の検知方法についての説明図（１）。
【図３３】記入枠構造の検知方法についての説明図（２）。
【図３４】記入枠構造の検知方法についての説明図（３）。
【図３５】帳票の空白を考慮しない方法と、考慮した方法を適用した処理結果。
【図３６】記入枠検出時の情報損失防止処理の説明図。
【図３７】大小２種類コードのデコーディングの流れ図。
【図３８】８方向線分コードのデコーディングの流れ図。
【図３９】描画エリアの大きさ算出の説明図。
【図４０】コードの大きさによるコード切り出しの例。
【図４１】記入枠の情報バーからコードごとの図形を切り出す切出し方向の説明図。
【図４２】手書きの重なった情報レコードの検出と処理の説明図。
【図４３】コード図形におけるエラーの例を示す図。
【図４４】情報バーの位置検出誤差によるコード図形損傷への対応処理の説明図（１）。
【図４５】情報バーの位置検出誤差によるコード図形損傷への対応処理の説明図（２）。
【図４６】情報バーの位置検出誤差によるコード図形損傷への対応処理の説明図（３）。
【図４７】８方向線分コードの認識についての説明図。
【図４８】コードを認識のアルゴリズム。
【図４９】コードを認識のプログラム例。
【図５０】メールアドレスの認識率を高めるための記入枠。
【図５１】アクティブ帳票処理システムの処理の流れの例。
【図５２】出力ファイルのフォーマット。
【図５３】評価実験に用いた帳票。
【図５４】文字単位の認識率の算出方法の説明図。
【図５５】大小２種類コード帳票の実験結果。
【図５６】８方向線分コードの実験結果。
【図５７】接触点、交差点及び末端点の分類を示す図。
【符号の説明】
１０ 水平バー
２０ 記入枠
３０ 情報バー
４０ マス
１ 処理部
２ 帳票入力部
３ 出力部
４ 表示部
５ 記憶部
【発明の属する技術分野】
本発明は、帳票、帳票処理方法、帳票処理プログラム、帳票処理プログラムを記録した記録媒体及び帳票処理装置に係り、特に、窓口やオフィス等で利用される帳票読み取りに利用可能な、帳票側に処理方法が記述された帳票、その帳票を処理するための帳票処理方法、帳票処理プログラム、帳票処理プログラムを記録した記録媒体及び帳票処理装置に関する。
【０００２】
【従来の技術】
従来、紙とコンピュータ処理の橋渡しとして、光学帳票読取り装置や、紙上の筆記から動的に運筆情報を読み取るタブレット、ｅ−ｐｅｎ、Ａｎｏｔｏ ｐｅｎなどの装置が知られている。しかし、後者は、筆記時に特別なデバイスが必要となる。
また、帳票の記入枠から手書きを抽出するために、記入枠にドロップアウトカラーが用いられることがある。しかし、カラーの使用はコストを高め、現在広く使われているモノクロコピー、モノクロファックスが利用できなくなるという課題がある。印刷コストや読取り装置のコスト、モノクロファックスの利用などの理由から、ドロップアウトを用いた帳票は減少し、モノクロ帳票が主流になりつつある。また、レーザビームプリンタの高精度化や、ＰｏｓｔＳｃｒｉｐｔなどのページ記述言語の一般化により、微細なドットテクスチャからなる帳票を安価なプリンタで印刷することが可能になっている。さらに、帳票作成エディタを作成することにより、誰でも簡単に帳票をデザインすることができる。手書きの帳票は入力が容易で、かつ、証拠として残ることから、電子化が進んでもなくならず、その手軽な電子化のニーズは高まっている。
【０００３】
なお、ドットで構成された記入枠を有する帳票に対する処理方法が提案されている（例えば、特許文献１、非特許文献３参照）。また、帳票に記入された文字を認識し、修正する方法が提案されている（例えば、特許文献２、３参照）。帳票側に処理を記載したアクティブ帳票システムが提案されている（例えば、特許文献１、非特許文献１、２参照）。
また、線や交点の検出から帳票構造を認識する方法が提案されている（例えば、非特許文献４、５参照）。
【０００４】
【特許文献１】
国際公開 第０１／９３１８８号パンフレット
【特許文献２】
特開２００１−０５２１１０号公報
【特許文献３】
特開２００１−０５２１１１号公報
【非特許文献１】
島村太郎、朱碧蘭、増田厚司、小沼元輝、櫻田武嗣、黒沼靖、中川正樹、「アクティブ帳票システムの設計と試作」、信学技報、2002年12月、PRMU2002-132、Vol.102、No.531、pp.19-24.
【非特許文献２】
朱 碧蘭、島村 太郎、中川 正樹、「アクティブ帳票処理技術の試作」、電子情報通信学会、信学技報、2002年12月、PRMU2002、Vol.102、No.531、pp.25-30.
【非特許文献３】
前田陽二、中川正樹、「ペーパインタフェースによる文書編集方式」、情報処理学会論文誌、2000年、Vol.41、No.5、pp.1308-1316.
【非特許文献４】
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.
【非特許文献５】
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.
【０００５】
【発明が解決しようとする課題】
しかしながら、モノクロ帳票では、帳票記入枠と手書きの分離が困難な場合があった。例えば、手書き文字が記入枠と重なった場合や、帳票の汚れ及び読み取りノイズがある場合には、正確に分離できない場合があった。また、記入された文字は、文字認識することが可能となっているが、なお誤読が生じる場合がある。特に、メールアドレスの認識には文脈処理が使えず、また、その後の処理に大きな影響を与えることが想定される。
本発明は、以上の点に鑑み、窓口やオフィス等で利用される帳票読取りに利用可能で、帳票記入枠と記入文字の分離が容易な帳票及び帳票処理方法、帳票処理プログラム、そのプログラムを記録した記録媒体及び帳票処理装置を提供することを目的とする。また、本発明は、記入文字の認識率を高めることを目的とする。さらに、本発明は、装置側でなく帳票側に帳票それ自身の処理方法を記述し、読取装置として汎用機を用いることができ、及び、多種の帳票を一台で処理することを目的とする。
【０００６】
また、本発明は、重畳する情報量を高めるためのドット形状を有する帳票及び帳票処理方法を提供することを目的とする。本発明は、手書きとの重なりや汚損から重畳情報を安定に読み取るためのコーディング方式及びデコーディング方式を提供することを目的とする。また、本発明は、特に誤読しやすい英数字記号などの補助記入方式を提供することを目的とする。さらに、本発明は、エディタで簡易に作成し、プリンタで印刷できる帳票を提供することも目的のひとつである。また、本発明は、記入枠の行間の画像をスキャンする手間を省略し、処理時間を短くすることも目的とする。
【０００７】
【課題を解決するための手段】
本発明は、記入枠に微細なドットで構成されたドットテクスチャを用いることでモノクロ環境下でも手書きとの分離を容易にし、また、そこに手書き記入の属性や読取り後の指示情報を重畳することで完全に帳票側が処理を主導するアクティブ帳票において、次のことを提供する。
記入枠内に情報を重畳するためのコード形状として、ドットテクスチャにより安定かつ大量に情報を重畳できるように、ドット形状を提案する。
【０００８】
また、コード図形の認識方法として、四方向のヒストグラムによる認識方法及び部分的な走査による認識方法を提案する。四方向のヒストグラムによる認識方法では、コードの画像に対し四方向のヒストグラムをとることによって、コードの形状特徴を判断しコードを認識する。部分的な走査による認識方法では、部分的にコード画像を走査することにより、コード図形中の線分があるべき位置ごとに順番に走査し、線分があれば対応の情報ビットを１とし、線分がなければ０とする。
【０００９】
また、記入枠の安定な検出方法として、ドットテクスチャによる記入枠の検出を容易にするために、各ドットに膨張処理をしてから縦および横方向にヒストグラムを取ることで、安定に記入枠を検出する。
帳票内の記入枠の間には空白があるので、空白の処理時間を省いて高速化する。記入枠と手書きの分離をしなくても手書きを含んだままで記入枠の行検出は行えるので（行内の位置検出には手書きが邪魔になるが、行の検出には邪魔にならない）、手書きを分離する前に行検出を行い、一行ずつの画像だけに対してラベリングをすれば、行間でのラベリング処理が省ける。
【００１０】
また、記入枠の境目を検出するときにノイズの影響を未然に防ぐ方法を提案する。縦あるいは横方向へのヒストグラムにより記入枠の位置を検出するとき、ノイズの妨げを避けるために、ヒストグラムの結果に対してある閾値以下の値を０と見なして、ノイズのある場所でも空白として無視する。こうすることにより、ノイズの影響を受けず、記入枠の位置を検出できる。しかし、閾値以下の値を０とみなしているため、記入枠の境のところで閾値以下の情報も無視されてしまい、記入枠の中に重畳した情報を読み取るには悪影響を与える。記入枠の位置を検出する時に、このような情報損失を防止するために、ヒストグラムで閾値以下のところで記入枠の位置を検出してから、さらに、この位置から記入枠の外側の方向にヒストグラムの値を辿って行き、ヒストグラムの値が０より大きい値から０になった位置、あるいは、始めの位置ｆから辿った長さがある閾値を超えてもヒストグラムの値が０にならない場合には始めの位置ｆから外側に閾値分だけずらした位置を記入枠の開始あるいは終了の位置とする。
【００１１】
また、ドットテクスチャの文書が多少傾いてスキャンされてもコード図形を切り出す方法として、ドットテクスチャにおけるドットの行数はドットの列数にくらべて少なく、縦方向へのヒストグラムの重なりは小さいことを利用して、ドットテクスチャの画像に対して縦方向のヒストグラムにとり、情報バーの左から右へ列ごとに切り出す。次に、列ごとの画像に対して横方向のヒストグラムをとり、コードごとの図形を切り出す。
【００１２】
手書きと重なって消された情報レコードを検出して読み飛ばす方法として、情報バーの画像において、左から右へ列ごとのコード図形を切り出していき、前の列と次の列の間隔が想定される幅より大きいときにコード図形と手書きが重なって手書きの分離処理によりコード図形が欠落したと判断して、この後のコード図形に対して、区切り記号が見つかるまで無視する。そうではない場合、列のコードを切り出して認識し処理を行う。
各コード図形に微小なノイズが付着して連結してしまったり微小なノイズをコード図形として処理してしまったりする誤りを防止する。例えば、切り出した図形の大きさが想定されるコード図形より小さい場合はノイズとして無視し、大きすぎる場合には、想定される大きさで分離して認識することにより、各コード図形に微小なノイズが付着して連結してしまったり微小なノイズをコード図形として処理してしまったりする誤りを防止する。
【００１３】
また、情報バーの位置検出誤差への対応方法を提案する。記入枠の情報バーとそれ以外の部分との境界線は正しい情報バーの境界線から誤差を含んで検出される場合がある。この検出された情報バー境界線に従い、コード図形を切り出してデコーディングを行うと、情報バーからはみ出したコード図形の一部を除外して認識することになり、誤認識を招く危険がある。このことを避けるために、以下の（１）から（４）の処理を実行する。（１）検出した情報バー境界線に従い、情報バーの画像に対して縦方向のヒストグラムにより、左から右へコードの列ごとの位置を検出する。（２）列ごとのコード画像に対して、横方向のヒストグラムを走査し、コードごとを切り出す。記入枠の上側情報バーの切出し方向は上から下へ、下側情報バーの切出し方向は下から上へである。この段階から以後、境界線ｂの情報を利用しない。（３）一つのコードを切り出した後、この列において切り出したコード数と走査した長さＬを調べる。情報バーのコード行数をＮとする。もし、この列のコード数がすでにＮに達しているか、あるいは、走査した長さＬがＮに応じた長さまで達していれば、コードの切出しを終了する。そうでなければ、続いてヒストグラムを走査し、コードの切出しを行う。ここで、走査した長さで終了を検出する目的は、コード図形が手書きと重なったりして欠落した場合に、情報バーの領域を越えてコードを探しに行かないようにするためである。（４）列ごとに対して、コードの切り出しが終了した時点で、そのコード数をチェックする。もしＮに達してなければ、コード数のエラーと見なし、この後のコード図形に対して、区切り記号が見つかるまで無視する。
【００１４】
また、メールアドレスの認識率を高める方法を提案する。メールアドレスに使われる文字は情報量の少ない英数字記号であり文字認識率が低く、また、意味のない文字列のために文脈処理が使えない。メールアドレス誤認識において、主な原因は類似文字への誤認識である。もし、この誤認識を避けることができれば、認識率を高めることができる。そこで、メールアドレスの文字種を限定するために、アクティブ帳票の中でメールアドレス記入枠の近くにもう一つの記入枠を設け、メールアドレスに対して対応するマスの文字種を簡単な記号で記入する。認識のしやすさと人の記入しやすさを考慮し、枠内の上や下、または両方に横線を枠に重なって記入できるようにする。
帳票は、複数の微小なドット（黒領域）又は線分を二次元に配置してなるドットテクスチャで文字入力枠が形成された文字入力用の帳票であって、２次元に配列されたドットの集まりで構成され、複数個のドットを含む幅のある線によるドットテクスチャで描かれた見出し文字と、２次元に配列されたドット又は線分の集まりで構成され、複数個のドット又は線分を含む幅のある線によるドットテクスチャで画成された記入枠とを有する。
【００１５】
処理部が、文字が入力された前記帳票から、各ドットが手書きの黒領域より小さく設定されることから、ドットテクスチャを構成する各々のドットが収縮処理により文字画像より先に消えること、又は、定められた閾値より小さい連結成分を除去すること、のいずれかによって、ドットテクスチャによる記入枠画像を除去して、記入された文字の文字画像を検出するための前記帳票を対象とする。
本方式では、微小なドットで構成されたドットテクスチャからなる記入枠を使用することによって、モノクロ環境において、手書きが記入枠に重なっても容易に分離できる。また、記入枠の中に手書きの属性、文字種を埋め込むことで、切り出した手書き文字に対して認識率を高めることができる。手書き文字の内容を属性、見出しの情報と対応付ければ、帳票ごとの設定をなくすことができる。さらに、読取り後の手書きに対する処理方法を埋め込むことで、帳票を読み込ませるだけ帳票に応じた処理を帳票側で指示するシステムが実現できる。いままで処理システム側に必要とされていたプログラムを帳票側に埋め込むことで帳票がアクティブになる。これが「アクティブ帳票」の由縁である。
【００１６】
本発明の第１の解決手段によると、
線分の傾斜又は複数の線分の組み合わせで情報が表現されるコードで構成される記入枠データと、記入された手書きデータとを含む帳票画像データを入力する帳票入力ステップと、
前記帳票入力ステップで入力された帳票画像データに基づき、記入枠データと手書きデータを分離し、及び、各記入枠データと、コードにより所定の情報が重畳された当該記入枠データ内の情報バーとを検出する記入枠検出ステップと、
検出された情報バーの各コードを切り出すステップと、
切り出されたコードの、縦方向と、横方向と、右斜め方向と、左斜め方向との四方向のヒストグラムを求めるステップと、
求められた四方向のヒストグラムに基づき、コードの形状特徴を判断し、コードを認識するコード認識ステップと
を含む帳票処理方法、これら各処理をコンピュータに実行させるための帳票処理プログラム及びそのプログラムを記録したコンピュータ読み取り可能な記録媒体が提供される。
【００１７】
本発明の第２の解決手段によると、
ドットの幅又は線分の傾斜又は複数の線分の組み合わせで情報が表現されるコードで構成される記入枠データと、記入された手書きデータとを含む帳票画像データを入力する帳票入力ステップと、
前記帳票入力ステップで入力された帳票画像データに基づき、記入枠データと手書きデータを分離し、及び、各記入枠データと、コードにより所定の情報が重畳された当該記入枠データ内の情報バーとを検出する記入枠検出ステップと、
前記記入枠検出ステップで検出された情報バーの各コードを認識し重畳情報を抽出する重畳情報認識ステップと、
前記記入枠検出ステップで分離された手書きデータに対して、抽出された重畳情報が示す手書きデータの属性及び／又は文字種類に従い文字認識を行う文字認識ステップと、
前記文字認識ステップで認識された文字情報と、前記重畳情報認識ステップで抽出された重畳情報に基づき、他のアプリケーションシステムに所定の処理をさせるための命令書データを作成する命令書作成ステップと、
前記命令書作成ステップで作成された命令書データを出力する、及び／又は、前記帳票入力ステップで入力された帳票画像データと、当該命令書データとを対応させて記憶するステップと
を含む帳票処理方法、これら各処理をコンピュータに実行させるための帳票処理プログラム及びそのプログラムを記録したコンピュータ読み取り可能な記録媒体が提供される。
【００１８】
また、本発明の第３の解決手段によると、
線分の傾斜又は複数の線分の組み合わせで情報が表現されるコードで構成される記入枠データと、記入された手書きデータとを含む帳票画像データを入力する帳票入力部と、
入力された帳票画像データの記入枠を検出し、及び、記入枠内のコードを認識する処理部と
を備え、
前記処理部は、
前記帳票入力部から帳票画像データを入力する手段と、
前記帳票入力部から入力された帳票画像データに基づき、記入枠データと手書きデータを分離し、及び、各記入枠データと、コードにより所定の情報が重畳された当該記入枠データ内の情報バーとを検出する記入枠検出手段と、
検出された情報バーの各コードを切り出す手段と、
切り出されたコードの、縦方向と、横方向と、右斜め方向と、左斜め方向との四方向のヒストグラムを求める手段と、
求められた四方向のヒストグラムに基づき、コードの形状特徴を判断してコードを認識するコード認識手段と
を有する帳票処理装置が提供される。
【００１９】
本発明の第４の解決手段によると、
ドットの幅又は線分の傾斜又は複数の線分の組み合わせで情報が表現されるコードで構成される記入枠データと、記入された手書きデータとを含む帳票画像データを入力する帳票入力部と、
帳票画像データ及び／又は帳票画像データに基づき作成される命令書データが記憶される記憶部と、
入力された帳票画像データに記入された手書きの情報と、記入枠に重畳された情報を認識し、所定の処理を実行する処理部と、
を備え、
前記処理部は、
前記帳票入力部から帳票画像データを入力する手段と、
入力された帳票画像データに基づき、記入枠データと手書きデータを分離し、及び、各記入枠データと、コードにより所定の情報が重畳された当該記入枠データ内の情報バーとを検出する記入枠検出手段と、
前記記入枠検出手段で検出された情報バーの各コードを認識し重畳情報を抽出する重畳情報認識手段と、
前記記入枠検出手段で分離された手書きデータに対して、抽出された重畳情報が示す手書きデータの属性及び／又は文字種類に従い文字認識を行う文字認識手段と、
前記文字認識手段で認識された文字情報と、前記重畳情報認識手段で抽出された重畳情報に基づき、他のアプリケーションシステムに所定の処理をさせるための命令書データを作成する命令書作成手段と、
前記命令書作成手段で作成された命令書データを出力する、及び／又は、前記入力する手段で入力された帳票画像データと、当該命令書データとを対応させて前記記憶部に記憶する手段と
を有する帳票処理装置が提供される。
【００２０】
また、本発明の解決手段のひとつでは、前記記入枠検出ステップ及び記入枠検出手段は、帳票画像データに対する横方向及び縦方向のヒストグラム又は線分検出並びに／若しくは交点検出に基づき、各記入枠データと、コードにより所定の情報が重畳された当該記入枠データ内の情報バーとを検出する。
【００２１】
さらに、本発明の第５の解決手段によると、
ドットの幅又は線分の傾斜又は複数の線分の組み合わせで情報が表現されるコードにより、所定の情報が重畳された情報レコードが複数の行に渡り配置される情報バーを有し、該コードにより構成される記入枠と、
前記コードより構成され、帳票又は前記情報バーに関する情報を含む水平バーと
を備える帳票が提供される。
【００２２】
【発明の実施の形態】
１．アクティブ帳票とその処理システムの概略
１．１ アクティブ帳票
図１は、アクティブ帳票の構成図である。
アクティブ帳票とは、記入枠に微細なドットで構成されたドットテクスチャを用いることで、モノクロ環境下でも記入枠と手書き文字の分離を可能にし、さらにドットを一様でないように分布させることで、記入文字の属性や読取り後の指示情報を記入枠に埋め込むことができる技術に基づいた帳票のことである。
帳票は、水平バー１０と、情報バー３０を有する記入枠２０とを備える。帳票標題の下などに印刷する横線は水平バー１０と呼ぶ。記入枠２０と水平バー１０はドットテクスチャで印刷される。記入枠のドットテクスチャには、記入される手書きの属性（例えば、人名、住所、メールアドレス、自由筆記など）、文字種（例えば、数字、漢字、英文など）、見出しやその処理方法（例えば、手書き文字を認識する、記載内容をメールで送信する、あるいはデータベースに保存するなど）を指示する情報（重畳情報）を記入枠上下側に重畳する。この情報が重畳される部分を情報バー３０という。また、帳票の全体に対する情報を水平バー１０に重畳する。また、記入枠の中で文字を一文字ごとに区切って記入してもらうための分割をマス４０と呼ぶ。
【００２３】
ドットテクスチャによる記入枠では、ドットを水平（行）方向および垂直（列）方向に並べてテクスチャを形成する。記入枠におけるドット行数は、水平バー１０も含めて、すべて同一とすることにより、水平バー１０のドット行数を求めれば、すべての記入枠のドット行数を容易に知ることができる。また、本実施の形態では、ドット以外に線分の傾斜又は線分の組み合わせで情報が表現されるコード図形に重畳情報を重畳することができる。この線分は、ドットを用いて構成してもよい。なお、以下の説明において、コード図形を単にドットと呼ぶ事もある。
【００２４】
１．２ アクティブ帳票処理システム
図２は、アクティブ帳票処理システムのハード構成図である。
アクティブ帳票処理システムは、例えば、処理部１と、帳票入力部２と、出力部３と、記憶部５とを備える。また、アクティブ帳票処理システムは、適宜の入力部、表示部４を備えても良い。アクティブ帳票処理システムは、例えば、読み取ったアクティブ帳票の画像データから記載内容や重畳情報を抽出し、命令書に出力する。なお、処理部の処理の詳細については後述する。記憶部５は、帳票画像データ、帳票画像データに基づき作成される命令書データが記憶される。また、記憶部５には、例えば、コードが示す値と情報が対応したテーブルが予め記憶されている。なお、記憶部５は、例えば標準パタンの特徴値と、その標準パタンが示す情報が対応したテーブルを含むことができる。
【００２５】
２． アクティブ帳票の詳細
２．１ 情報重畳のためのコード形状
アクティブ帳票では、記入枠ごとにその中に記入される手書きの属性、文字種、見出し、処理方法を指示する情報をそのドットテクスチャの中に重畳する。ドットテクスチャに情報を埋め込む方法の一つとしてドットの形状を変化させる方法が考えられる。そこで、情報を表すいくつかのコード形状について述べる。
【００２６】
図３は、大小２種類の図形を用いるコード（大小２種類コード）の構成図である。大きさの違う２種類のドットでバイナリビットの１と０を表し、これに情報を重畳する。２つコードの高さが同じでｈとする。大きいドットの幅をＬとする。コード間の隙間を考えコードを帳票に均等して配置するための領域をコードの配置エリアとする。各コードの配置エリアの大きさは同じで、コードをその中心に置く。各コードの配置エリアを碁盤の目のように縦横に隙間を空けずに配置すれば、コードとしては隙間を確保したドットテクスチャになる。後述する他の種別のコードも同様に、配置エリアの中心に置いて並べることにより、記入枠のドットテクスチャを生成する。
【００２７】
図４は、８方向線分を用いるコード（８方向線分コード）の構成図である。８方向の線分により、０から７までの図４に示す８種類のコードを表すことができる。図４では、各コードの下に示した「０００」、「００１」などの番号は、これらのコードに対応する２進数の番号である。なお、各コードには、図に示す以外にも適宜の番号を対応させることができる。また、８方向以外にも、所定の角度傾斜した線分を用いた多方向とすることもできる。コードを描画するための同じ大きさの正方形領域を描画エリアと呼ぶ。
【００２８】
図５に、描画エリアと配置エリアの関係を示す。描画エリアは配置エリアよりも小さく、配置エリアの中心に位置する。上述と同様に、配置エリアは、碁盤の目のように縦横に隙間を空けずに配置することで、各コードは隙間を確保して配置される。
図６は、２１２種類の図形を用いるコード（２１２種類コード）の構成図である。２１２種類コードは、図６に示すように、１２種類の線分の組合せで構成される。大きさａ×ａの描画エリアを基準とし、これら１２種類（１２本）の線分の有無により２１２種類、すなわち、４０９６種類のコードを作る。
【００２９】
図７は、２８種類の図形を用いるコード（２８種類コード）の構成図である。２８種類コードは、図７に示すように、８種類の線分の組合せで構成される。大きさａ×ａの描画エリアを基準とし、これら８種類（８本）の線分の有無により２８種類、すなわち、２５６種類のコードを作る。なお、２８種類コード、２１２種類コード以外にも、適宜の線分の組み合わせにより２ｎ種類コードを作成することができる。
【００３０】
２．２ 重畳情報のコーディング
ドットテクスチャの微小なドット形状を保証するため、ＰｏｓｔＳｃｒｉｐｔ言語で帳票を作り、ＰｏｓｔＳｃｒｉｐｔプリンタに帳票画像データを送り、帳票を印刷する。大小２種類コードと８方向線分コードのそれぞれのコーディングについて述べる。その他のコードは、基本的に後者のコーディングを同様に利用できる。
【００３１】
２．２．１ 大小２種類コードにおけるコーディング
図８は、重畳する情報レコードを示す図である。ドットテクスチャの記入枠ごとに図８に示す情報を重畳する。これを情報レコードと呼ぶ。例えば、情報レコードを８＋８＋８＋１６×４＋８＝９６ビットの固定長で表す。情報レコードは、例えば、記入枠の上側に重畳することができる。
図９は、属性とコードが示す値の対応を示すテーブルである。属性とは、その記入枠の中に記入される手書きの属性で、記入枠の見出し文字をカテゴリごとに分類したものである。属性には、帳票の種類、用途に応じてさまざまな種類がある。図９は、実際に使用されている帳票３６種類から見出し文字を抽出した属性の例である。図９に示すように、例えば、１４種類の属性に分類しコーディングすることができる。ただし、属性は適宜のものを用いることができ、これらには限定されない。
【００３２】
図１０は、文字種類及び命令と、コードが示す値との対応を示すテーブルである。文字種類とは、その記入枠の中に記入された手書き文字の字種のことである。命令とは、その記入枠の中に記入された手書きに対する読取り後の処理方法のことである。文字種と命令は８ビットのフラグで表現することができる。例えば、図１０に示すように、文字種類及び命令のそれぞれに対応したビット番号を立てる（例えば、１にする）。なお、文字種類及び命令は、これ以外にも適宜のものを用いることができる。例えば、「認識せよ」との命令は、「枠あり認識せよ」、「枠なし認識せよ」などとしてもよい。見出し文字には、例えば、その記入枠見出しの始り４文字のＳｈｉｆｔ−ＪＩＳコード（合計６４ビット）を埋め込む。終端記号は、８ビットの０を埋め込む。なお、アクティブ帳票処理システムの記憶部５には、例えば、図９及び図１０に示すようなテーブルが予め記憶されている。
【００３３】
図１１は、情報レコードのドット列へのコーディング方法を示す図である。
大小２種類コードを水平（行）に並べ、例えば上記の情報を記入枠の上側に重畳する。記入枠と手書き文字の重なりにより重畳情報が損失する危険があるため、同一の重畳情報を一行のドット並び内で可能な範囲で繰り返し、残りの部分には例えば０を示すドットを入れる。また、２行目以降、先頭に例えば０を示すドットを入れて２ドットずつずらし、上のドット行を繰り返す。つまり、９６ビットの情報レコードを可能な長さだけつなげ、残りの部分には０を示すドットを入れる。これらの重畳情報の多数決をとることで、損失した情報を復元することができる。なお、各行でずらすドット数は、２ドット以外にも適宜のドット数ずらすことができる。また、図１１に示すコーディング方法は、大小２種類コード以外にも、例えば８方向線分コードなどの他のコードに適用することもできる。
【００３４】
２．２．２ ８方向線分におけるコーディング
図１２は、重畳する情報レコードを示す図である。８方向線分コードは、大小２種類コードの情報の重畳方法を発展して、もっと多くの情報を重畳でき、かつエラーの検出などの効率的な重畳方法を使用することができる。記入枠ごとに図１２に示す情報レコードを重畳する。
属性は、大小２種類コードの重畳と同様とすることができる。なお、８方向線分コードの１符号の情報量が３ビットであるため、表現の都合から、例えば、図９に示した大小２種類コードの属性の末尾（又は先頭）に０をつけ、９ビットとする。文字種と命令は、９ビットのフラグで表現することができる。表現方法は、上述の図１０と同様とすることができる。また、ビット番号９の文字種類として、メールアドレスの認識率を高めるために、そこに用いられる英数字、「＠」、「．」などの字種を示す情報とすることもできる。見出し文字は、全角１文字から１０文字までのＳｈｉｆｔ−ＪＩＳコードで表す。メールアドレスの認識率向上については後述する。図１２の情報レコード（４５〜２０７ビットの不定長）を３ビットごとに区切り、それを表現するコードに変換する。各コードを含む情報レコードを記入枠の上側と下側の情報バーに重畳する。
【００３５】
図１３は、８方向線分コードの重畳の例を示す。図１３に示すように、例えば４行のドットテクスチャを考えると、列ごとに４つのコードを上から下に配置し、それを左から右へコーディングしていく。図１３に示す例では、１、２、３、４、５、６の方向で線分を配置している。情報レコードの始めと終りには区切り記号をつけ、また、終りの前にパリティ符号を置いて、さらに２番目、３番目の情報レコードを繰り返す。これを可能な範囲で繰り返す。２番目以降の情報レコードは、１番目の情報レコードと同一であり、パリティでまずエラー混入があるかどうかを検査し、さらに、複数の情報レコードの多数決をとって、損失した情報を復元することができる。
【００３６】
図１４に、パリティ符号の設定方法の説明図を示す。区切り図形間の対応する位のビットの値を排他的論理和で０になるように、パリティ符号を付加する。例えば、図１４に示すように、「０００」、「００１」、「０１０」を示すデータに対しては、各データの対応するビットの値の排他的論理和が０になるように、パリティ符号として「０１１」を示すコードを付加する。
図１５に、区切り記号を表す図形を示す。区切り記号は、情報レコードごとの境を示す機能を持ち、例えば、図４に示した８方向線分コードの番号を引き継いで８の番号とする。なお、区切り記号は図１５に示す形状以外にも、それと判別できる適宜の形状とすることができる。
【００３７】
２．３ コード図形の認識方法
コードを認識するには、以下のいずれかの方法を用いることができる。
２．３．１ 四方向のヒストグラムによる認識方法
図１６は、四方向のヒストグラムによる認識方法の説明図である。コードの画像（データ）に対し四方向（例えば、縦、横、右斜め、左斜め）のヒストグラムをとることによって、コードの形状特徴を判断しコードを認識することができる。図１６に示すようにコードによって四方向のヒストグラムがはっきり違う。
【００３８】
２．３．２ マッチングによる認識方法
全ての種類のコードに対して、大量の画像サンプルを作り、各サンプルの特徴値を抽出する。コード種類ごとに平均特徴値を求め、各コードの標準パタンを作ることができる。標準パタンサンプルの特徴値の抽出と同じ方法で入力コードの特徴値を抽出し、各コードの標準パタンとマッチングし、一番特徴の近い標準パタンを求め、この標準パタンを認識の結果とする。
図１７に、標準パタンサンプルと入力コードの特徴値の抽出の説明図を示す。特徴値の抽出方法としては、文字記号認識において一般的に用いられている方法を用いることができる。まず、線密度を計算し、線密度が均等になるように非線形正規化をし、文字画像のエッジのギザギザを消すための線の連結性を保つ平滑化を行う（図１７の（１））。次に、正規化されたパタンに対して、横、縦と斜めの４つ方向の成分を抽出する（図１７の（２））。それぞれを８×８の区画に分割し、各区画に含まれる方向成分の量を特徴として、それを６４個並べ、さらに４つの方向成分を並べて、６４×４＝２５６次元の特徴ベクトルを得る（図１７の（３））。
【００３９】
図１８に、標準パタンとマッチングすることによるコードの認識の説明図を示す。例えば、図１８の右側に示すような標準パタンの特徴値と、その標準パタンが示す情報が予め記憶部に記憶され、図１８の左側に示す読み取られたコードの特徴値を、標準パタンの特徴値と比較し、コードを認識することができる。
２．３．３ 部分的な走査による認識方法
図１９は、部分的な走査による認識方法の説明図である。部分的にコード画像を走査することによるコード図形を認識する。コード図形中の線分があるべき位置ごとに順番に走査し、線分があれば対応の情報ビットを１とし、線分がなければ０とする。図１９に示す図は、２８種類コードの例である。白い部分は線分のない部分、黒い部分は線分のある部分である。図１９では、線分のない部分を見やすくするために背景を灰色にしているが、実際の帳票では、背景と線分のない部分は同色とすることができる。コードを構成する各線は、２ビット数の桁に対応する。これらの線分を順番に走査し、線分があれば対応の桁を１とし、線分がなければ０とする。走査する部分は、コードの描画エリア又は配置エリアが切り出せれば、これらのエリア内の所定位置を走査することができる。順次走査することによって、図１９の例では、２ビットの数「１０１１０１１０」が求まる。１０進数に直すと「１８２」になる。この値が、このコードの値である。
【００４０】
２．４ 各コード形状についての検討
上述の各コードの大きさ及び各コードの認識実験結果について説明する。
【００４１】
２．４．１ 実験環境条件
各コードの作成及び認識に用いた処理装置は、Ｐｅｎｔｉｕｍ（登録商標）４の２．２６ＧＨｚのＣＰＵと、１．００ＧＢのメモリを備え、Ｗｉｎｄｏｗｓ（登録商標）ＸＰをＯＳとして搭載した機種である。
プリント精度として、安価なレーザビームプリンタでも印刷できる１２００ｄｐｉを採用した。上述のように、アクティブ帳票は、ＰｏｓｔＳｃｒｉｐｔ言語で帳票コードを作成し、ＰｏｓｔＳｃｒｉｐｔプリンタに帳票コードを送ることにより印刷することができる。プリント精度は高ければ高いほどよい。しかし、あまり高い精度を前提にすると装置コストが高くなる。実験の結果、１２００ｄｐｉの精度でプリントできる丸いドットの最小直径は０．１ｍｍである。
【００４２】
スキャンの精度は、６００ｄｐｉを採用した。帳票を読み取るスキャン精度は、高ければ高いほどいい。しかし、精度が高いと、読み込んだ帳票のサイズが大きくなり、帳票処理の時間が大きくなる。例えば、６００ｄｐｉの精度でスキャンした場合、Ａ４帳票のサイズは４９２４×６８８３の画素数となり、このサイズでの大小２種類コードの普通帳票に対しては、コンピュータの処理時間が２秒弱となる。
また、ドットテクスチャの小さいドットがスキャンにより連結しないようにするため、ドット同士の間に適切な間隔をあける必要がある。プリント時の印刷誤差及び帳票が傾いた状態でのスキャンや二値化等による誤差を含め、実験により６００ｄｐｉのスキャンでは０．２ｍｍのドット間の最小間隔があることが望ましい。このサイズは、プリント精度１２００ｄｐｉで印刷可能である。また、この間隔は、帳票の見た目を損なわない。
【００４３】
２．４．２ 各コードの検討
図２０は、大小２種類コード及び８方向線分コードにより作られたドットテクスチャの記入枠である。図２０（ａ）に、大小２種類コードにより、作られたドットテクスチャの記入枠を示す。
１２００ｄｐｉの精度でプリントできる最小サイズのドットが０．１ｍｍであることにより、図３に示すコードの高さｈは０．１ｍｍとすることができる。大きいドットと小さいドットを区別するため、帳票が傾いた状態でのスキャンや二値化などの誤差を考慮し、図３に示す大きいドットの長さＬは０．２５ｍｍとすることができる。スキャン精度で述べたように、ドット間の間隔を０．２ｍｍにするため、図３に示した長方形の配置エリアの大きさは幅０．４５×高さ０．３ｍｍすることができる。図２０（ａ）は、この大きさのコードにより作成されたドットテクスチャの記入枠の例である。この例では、記入枠の上側に情報を重畳している。
このコードは２種類だけなので、縦方向のヒストグラムをとってコードの幅を判別することによって簡易に識別することができる。上述の大きさの２種類コードの帳票１枚を認識処理してみた結果、修正インタフェースを呼び出すまでの処理時間は１７８２ｍｓである。また、識別誤りはなかった。
【００４４】
図２０（ｂ）に、８方向線分コードにより作られたドットテクスチャの記入枠を示す。８方向線分コードの線を、１２００ｄｐｉでプリントできる最小サイズである０．１ｍｍの太さとする。６００ｄｐｉのスキャンで０．１ｍｍサイズのピクセル数は３画素である。図４に示す「１００」を示すコードと「１０１」を示すコードを区別するためには、「１０１」のコードの幅（横方向）には４ピクセルが必要である。スキャンする前のサイズに換算すると０．１６８ｍｍである。誤差などを考慮し、「１０１」のコードの幅を０．２ｍｍとすることができる。この場合、描画エリアの正方形のサイズは０．４ｍｍになる。ドット間の間隔を０．２ｍｍに保証すると、配置エリアのサイズは０．６×０．６ｍｍになる。図２０（ｂ）は、この大きさのコードにより作られた記入枠の例である。この例では、図２０（ａ）と同様に、コードを横方向に各行２コードずつずらして記入枠の上側に情報を重畳している。
【００４５】
四方向のヒストグラムをとることにより、簡易に８方向線分コードを識別することができる。比較するため、マッチングによる認識方法と四方向のヒストグラムによる認識方法についてコード認識の処理を試した。マッチングによる方法の標準パタンの辞書は、８種類のコードごとに２０個ずつ合計１６０個の画像をＰｏｓｔＳｃｒｉｐｔ言語で作り、１２００ｄｐｉプリントと６００ｄｐｉスキャンにより得た画像をサンプルとし、特徴をとることにより作成した。
図２１に、四方向ヒストグラムとマッチングによる認識方法を試した結果を示す。認識率は、辞書の作成用に使った全てのサンプル画像に対しての認識率で、両方とも１００％に達している。しかし、処理時間は、ヒストグラムによる認識方法の方が早い。なお、１枚の帳票に対する処理時間は、認識した文字を修正するための修正インタフェースを呼び出すまでの処理時間を示している。
【００４６】
図２２に、２１２種類コードにより作られたドットテクスチャの記入枠を示す。
このコード形状はかなり複雑になり、コード画像が小さいと組合せの線が接触してしまい、人でも識別できなくなる場合がある。組合せの線が接触しないで人が識別できるまでのサイズのものを作り、マッチングによるデコーディング方法で識別し、９８％以上の認識率を保証できるサイズを見出した。このサイズの描画エリアは０．９×０．９ｍｍである。最小符号間隔の０．２ｍｍを考え、配置エリアは１．１×１．１ｍｍである。なお、このサイズは、プリント精度、スキャナ精度を高精度にすれば、さらに小さくすることも可能である。図２２は、この大きさのコードにより作られた記入枠の例である。この例では、記入枠の上側に情報を重畳している。
【００４７】
このコード形状は、小さくて線がかなり集まっている場合、ヒストグラムによる認識方法では特徴を識別できなくなる。ヒストグラムによる方法により識別するには、上述のサイズのよりも大きなサイズのコードとする必要がある。仮に、コードのサイズを大きくすると帳票の見た目に影響するので、ヒストグラムによる方法を止め、本例では、マッチングによる認識方法と部分的な走査による認識方法を試した。マッチングのための標準パタンの辞書は、４、０９６種類のコードごとに１７個ずつ合計６９６３２個の画像をＰｏｓｔＳｃｒｉｐｔ言語で作り、１２００ｄｐｉプリントと６００ｄｐｉスキャンにより得た画像をサンプルとし、特徴をとることにより作成した。
【００４８】
図２３に、コードの認識結果を示す。認識率は、辞書の作成用に使った全てのサンプルに対しての認識率である。また、１枚の帳票に対する処理時間は、修正インタフェースを呼び出すまでの処理時間である。処理時間と認識率ともに、部分的な走査による認識方法の方がよい。
【００４９】
図２４に、２８種類コードにより作られたドットテクスチャの記入枠を示す。２１２種類コードと同じで、このコードも小さいと組合せの線が接触してしまい、人でも識別できなくなる。組合せの線が接触しないで人が識別できるまでのサイズを作り、マッチングによる認識方法で識別し、９８％以上の認識率を保証できるサイズを見出した。このサイズの描画エリアは０．７８×０．７８ｍｍである。最小符号間隔の０．２ｍｍを考え、配置エリアは０．９８×０．９８ｍｍである。なお、このサイズは、プリント精度、スキャナ精度を高精度にすれば、さらに小さくすることも可能である。図２４は、この大きさのコード図形により作られた記入枠の例である。この例では、記入枠の上側に情報を重畳している。
【００５０】
このコードもヒストグラムによる認識方法で特徴を識別するには、上述のサイズよりも大きくする必要がある。そこで、マッチングによる認識方法と部分的な走査による認識方法を試した。マッチングの標準パタンの辞書は、２５６種類の符号ごとに７個ずつ合計１７９２個の画像をＰｏｓｔＳｃｒｉｐｔ言語で作り、１２００ｄｐｉプリントと６００ｄｐｉスキャンにより得た画像をサンプルとし、特徴をとることにより作成した。
図２５に、認識実験結果を示す。１枚の帳票に対する処理時間は修正インタフェースを呼び出すまでの処理時間である。認識率は辞書の作成用に使った全てのサンプルに対しての認識率で、両方とも１００％に達した。しかし、処理時間は部分的な走査による認識方法の方が早い。
【００５１】
２．４．３ コード形状についての比較
図２６は、各種のコード形状の認識結果の比較図である。１ビットあたりのデコード時間は、前に述べた各種コード形状に対する最速な認識方法によるデコーダエンジンに、記入枠の情報バーを渡してからデコードの結果が求まるまでの時間を、情報バーの中に埋め込んだ情報量で割った時間である。２１２種類と２８種類のコードは、現実的な大きさではコードの切出しと認識において、他のコードに比べて困難である。また、この二方式のコード形状は大きくなると、人が形を識別できてコードらしくない点も他のコードとの違いである。さらに、後の節で述べる記入枠と手書きの分離方法のうち最高速であるラベリングの方法により、この二方式のコードで作った帳票を処理すると、小さい文字（句読点など）と分離できなくなり、文字と重なる場合に文字の認識に悪影響を与える。他の方法で記入枠と手書きを分離することも可能であるが、分離の処理時間が長くなる。一方、８方向線分コードは大小２種類コードより情報量とデコード速度ともに良い。また、大小２種類コードは簡単でシステムを作りやすい。
【００５２】
３．アクティブ帳票処理のメインフローチャート
図２７に、アクティブ帳票処理システムの流れ図を示す。以下に、図２７の各処理について説明する。アクティブ帳票処理システムは、処理を開始すると、まずアクティブ帳票画像（データ）を読み込む（Ｓ１０１）。次に、アクティブ帳票処理システムは、記入枠と手書きを分離し、記入枠と例えば情報バーの位置などの記入枠構造とを検知する（Ｓ１０３）。アクティブ帳票処理システムは、情報バーの位置に従い、記入枠ごとに重畳された情報を読み取る（Ｓ１０５）。なお、ステップＳ１０３、Ｓ１０５の処理の詳細については後述する。また、アクティブ帳票処理システムは、検出した情報バーの位置、記入枠構造などのデータを適宜のタイミングで記憶部に記憶する。
【００５３】
アクティブ帳票処理システムは、重畳情報の属性により記入された手書きが文字の場合、記入枠の手書き文字の画像に対して、手書き文字の属性と文字種に従いオフライン文字認識を行う（Ｓ１０７）。アクティブ帳票処理システムは、オフライン認識の結果を修正インタフェースを通して修正する（Ｓ１０９）。修正インタフェースは、認識した文字を修正するための処理を実行する。アクティブ帳票処理システムは、アクティブ帳票から抽出した記載内容や重畳情報を、例えば、ＣＳＶファイルの形で出力する（Ｓ１１１）。これを命令書と呼ぶ。また、帳票画像を命令書とを対応させて記憶部に保存する。アクティブ帳票処理システムは、アクティブ帳票処理を終了する。その後、他のアプリケーションシステムは、命令書に従いアクティブ帳票から抽出した情報に対して処理を行う。
【００５４】
４．記入枠と手書きの分離及び記入枠と記入枠構造の検知の処理
４．１ 処理の流れ
図２８に、記入枠と手書きの分離、記入枠と記入枠構造の検知についてのフローチャートを示す。図２８に示すフローチャートは、図２７に示すフローチャートにおけるステップＳ１０３の詳細処理である。記入枠と手書きの分離をしなくても手書きを含んだままで記入枠の行検出は行えるので（行内の位置検出には手書きが邪魔になるが、行の検出には邪魔にならない）、手書きを分離する前に行検出を行い、一行ずつの画像だけに対してラベリングをすれば（アルゴリズム２とする）、行間でのラベリング処理を省くことができる。処理手順は次の通りである。
【００５５】
まず、アクティブ帳票処理システムは、全帳票画像（データ）に対し横方向へのヒストグラムをとり、行ごとの画像を検出する（Ｓ２０１）。次に、アクティブ帳票処理システムは、行ごと画像に対してラベリング処理を適用し、記入枠と手書きを分離する（Ｓ２０３）。なお、ラベリング処理以外にもモルフォロジー、メディアンフィルタの手法いて、記入枠と手書きを分離することもできる。ラベリング等については、後述する。
さらに、アクティブ帳票処理システムは、行ごとの記入枠だけの画像に対し縦方向へのヒストグラムで記入枠の位置とマス位置を検出する（Ｓ２０５）。アクティブ帳票処理システムは、記入枠ごとの画像に対し横方向へのヒストグラムで記入枠の情報バーの位置を検出する（Ｓ２０７）。なお、アクティブ帳票処理システムは、行及び記入枠の検出の際に、予め定められた閾値以下の値を０と見なして、ノイズのある場所でも空白として無視してもよい。この場合、後述する記入枠検出時の情報損失防止処理を実行するようにしてもよい。
【００５６】
４．２ 記入枠と手書きの分離方法
４．２．１ ラベリングによる手法
ラベリングは、二値画像に対して連結している黒画素の連結成分に同じラベルをつけることをいう。ラベリングの手法には再帰関数を呼び出す方法と往復走査する方法がある。
【００５７】
４．２．２ モルフォロジーの手法
帳票画像の収縮と膨張には、それぞれ以下の二つの方法がある。
収縮方法としては、（ａ）画像を走査し白画素にあったら、この画素の８近傍か４近傍の画素も白くする方法、（ｂ）画像を走査し黒画素にあったら、この画素の８近傍か４近傍を調べ、８近傍か４近傍の画素の中で一つでも白であれば、この黒画素を白にする方法のいずれかを用いる事ができる。
膨張方法としては、（ａ）画像を走査し黒画素にあったら、この画素の８近傍か４近傍の画素も黒くする方法、（ｂ）画像を走査し白画素にあったら、この画素の８近傍か４近傍を調べ、８近傍か４近傍の画素の中で一つでも黒であれば、この白画素を黒くする方法のいずれかを用いることができる。
【００５８】
４．２．３ メディンアンフィルタの手法
メディンアンフィルタはよく画像の平滑化に用いられる手法である。メディンアンフィルタとは、領域内の濃度の中央値、すなわち３×３の領域であれば、９個の濃度値を低い（または高い）順番に並べ、５番目（中央）の濃度値を、その中心の新しい濃度値とするフィルタのことである。
図２９に、メディアンフィルタの説明図を示す。中心にある目的画素の元の濃度値は２２である。３×３の領域のメディアンフィルタを使う。そのフィルタ中にある９個の濃度値を低い順番に並べると、２２、２２、２３、２４、２４、２４、２５、２６、２７という順番になる。中央値が５番目の値２４なので、目的画素の新しい濃度値を２４とする。２値画像の場合、メディアンフィルタの大きさの二分の一より小さい面積（黒画素数）の黒画素の連結成分では、この連結成分のどの黒画素にメディアンフィルタを適応しても、中央値が必ず白画素値である。したがって、この連結成分が消される。
【００５９】
４．２．４ 記入枠と手書きの分離
記入枠と手書きの分離方法では、ラベリングによる分離方法、収縮と膨張による分離方法、これらを組み合わせた分離方法、及び、メディアンフィルタによる分離方法が考えられる。
大小２種類コードによる帳票と８方向線分コードによる帳票に対し、記入枠と手書きを分離してみた。いくつかの記入枠と手書きの分離方法を比較するため、これらのサンプル帳票は普通の太さのペンで記入してもらっている。分離した結果では、収縮と膨張による分離方法で記入枠の画像に多量の手書きの跡が残った。きれいに記入枠と手書きを分離できるためには、もっと太めのペンで記入する必要がある。しかし、こうすると収縮と膨張による分離時間が長くなる。また、筆記具を制限することになる。
分離した結果によると、再帰関数を呼び出すラベリングによる分離方法が、一番高速で、かつ、手書きの太さと記入枠ドットの大きさに制限がかからない。したがって、記入枠と手書きの分離方法には再帰関数を呼び出すラベリングの方法が有効である。
図３０に、記入枠と手書きが重なった場合における分離されたき記入枠と手書き文字を示す。記入枠と手書きが重なったことが手書き分離に影響していないことが確認できる。
【００６０】
４．３ 記入枠と記入枠構造の検出
記入枠を検出するためには、線分検出、交点検出による方法（後述する）、以下で述べるような縦および横方向へのヒストグラムを取る方法などがある。アクティブ帳票方式は、記入枠の検出方法に依存せずに有効である。ただし、以下では、ヒストグラムによる方法により、更なる技術開発を行ったので、ヒストグラムによる記入枠検出について述べる。
【００６１】
４．３．１ ヒストグラムでの検出
図３１に、ヒストグラムによる記入枠及び記入枠構造の検出の説明図を示す。図２８に示す各処理を実行することにより、図３１に示すようなヒストグラムが得られる。
まず、図３１（ａ）に示すように、帳票画像全体に横方向へのヒストグラムを取り、得られたヒストグラムに従い一行ずつの記入枠を検出する（Ｓ２０１に対応）。次に、図３１（ｂ）に示すように、検出した行に対して縦方向へのヒストグラムを取り、得られたヒストグラムに従い記入枠の位置と記入枠のマスを検知する（Ｓ２０５に対応）。次に、図３１（ｃ）に示すように、検知された記入枠に対して横方向のヒストグラムを取り、得られたヒストグラムに従い記入枠の情報バー位置を検知する（Ｓ２０７に対応）。
【００６２】
４．３．２ 記入枠構造の検知方法についての検討
図３２〜図３４は、記入枠構造の検知方法についての説明図である。
図３２に示すように、記入枠の高さと幅が十分に大きいとき、縦方向と横方向へのヒストグラムにより、記入枠の構造がはっきり区別できる。ヒストグラムの最大値と最小値の中間値を求め、この中間値を閾値とし、記入枠のマス位置や情報バーの位置を検出することができる。しかし、図３３に示すように、記入枠の幅や高さが小さい場合、中間値を安定に求めることができない。なお、図３２及び図３３は、見やすさのため記入枠の大きさを拡大縮小して表示しているため、記入枠の大きさの違いが一目ではわかりづらいが、配置されたコードの数から記入枠の大きさの違いがわかる。さらに、図３４に示すような手書きとの重なりにより消された記入枠は、そのままの状態で処理すると誤った結果になることがある。よって、記入枠の構造を識別する時、まず、図３４に示すように記入枠のドットを膨張する。記入枠のドットが完全に接触するまで膨張するのは時間がかかるため、ドットのサイズに従いある程度膨張すればよい。膨張した記入枠に対して、ヒストグラムの中間値を求め、簡易に記入枠の構造を識別することができる。大小２種類コードによる記入枠は、ドットのサイズが小さいため、膨張処理を行わなくても構造を認識できる。８方向線分コードによる記入枠は、ドットのサイズと形状によりドットテクスチャがまばらになる。ヒストグラムにより記入枠構造を認識するには、膨張処理を行うことが好ましい。
【００６３】
４．３．３ 空白を考慮した処理時間短縮
図３５は、６種類の大小２種類コードと８方向線分コードの帳票に対し、帳票の空白を考慮せずに処理する方法（アルゴリズム１）と、空白を考慮して処理する方法（アルゴリズム２）を適用した処理結果である。帳票内の記入枠の間には空白があるので、上述のフローチャートに示す処理では、ラベリングでの空白の処理時間を省き帳票の処理時間が早くしている。
アルゴリズム２の処理は、図２８に示す本実施の形態に係る処理と同様である。アルゴリズム１の処理手順は以下の通りである。まず、全帳票画像に対しラベリングし記入枠と手書きを分離する。次に、記入枠だけの画像に対し横方向へのヒストグラムで行を検出する。さらに、行ごとの記入枠画像に対して縦方向へのヒストグラムで記入枠の位置とマス位置を検出する。行ごとの記入枠画像に対して横方向へのヒストグラムで記入枠の情報バー位置を検出する。アルゴリズム１では、全帳票に対してラベリングしているのに対し、アルゴリズム２では、検出された行に対してのみラベリングする点が異なる。記入枠の密度によらず、アルゴリズム２、すなわち行間の空白を考慮した方法のほうが高速である。なお、２つのアルゴリズムによる処理結果の精度は同じである。
【００６４】
４．４ 記入枠検出時の情報損失防止処理
図３６に、記入枠検出時の情報損失防止処理の説明図を示す。
横あるいは縦方向へのヒストグラムにより記入枠の位置を検出するとき、ノイズの妨げを避けるために、ヒストグラムの結果に対して予め定められた閾値以下の値を０と見なして、ノイズのある場所でも空白として無視する。図３６では、記入枠の上外側にたくさんのノイズがあるが、閾値処理をすることにより、ノイズの影響を受けず、記入枠の位置ｆを検出できる。しかし、閾値以下の値を０とみなしているため、記入枠の境のところで閾値以下の情報も無視されてしまい、記入枠の中に重畳した情報を読み取るには悪影響を与える。したがって、記入枠の位置を検出する時に、このような情報損失を防止するために、ヒストグラムで閾値以下のところで記入枠の位置ｆを検出してから、さらに、この位置ｆから記入枠の外側の方向（例えば、図３６の例では上方向）にヒストグラムの値を辿って行き、ヒストグラムの値が０より大きい値から０になった位置、あるいは、始めの位置ｆから辿った長さがある閾値を超えてもヒストグラムの値が０にならない場合には始めの位置ｆから外側に閾値分だけずらした位置を記入枠の開始あるいは終了の位置とする。こうすることにより、正しく記入枠の開始あるいは終了の位置を検出することができるとともに、記入枠外のノイズを避けることもできる。なお、図３６は、行の検出（上下に走査）の例であるが、列の検出（左右に走査）についても同様とすることができる。
【００６５】
５．デコーディング
５．１ 処理の流れ
次に、図２７のステップＳ１０５の処理（デコーディング）について説明する。
図３７に、大小２種類コードのデコーディングの流れ図を示す。図３７に示すフローチャートは、情報レコードが情報バーの横方向に配置された帳票に対するデコーディングである。
まず、アクティブ帳票処理システムは、ステップＳ１０３で検知された記入枠の情報バーに対して、横と縦方向にヒストグラムをとり、行ごとのドットを切り出す（Ｓ３０１）。次に、アクティブ帳票処理システムは、切り出された各ドットの縦方向のヒストグラムに従い、ドットの長短を測り、ドットが示す情報が１か０かを求める。例えば、アクティブ帳票処理システムは、長いドットを１、短いドットを０とする。そして、アクティブ帳票処理システムは、所定ビット、例えば２ビットずつの行のずらしを戻す（Ｓ３０５）。アクティブ帳票処理システムは、記入枠の情報バーから大量の情報レコードを求める（Ｓ３０７）。例えば、アクティブ帳票処理システムは、記入枠の情報バーから可能な限りの情報レコードを求めることができる。また、アクティブ帳票処理システムは、予め定められた数の情報バーを求めるようにしても良い。アクティブ帳票処理システムは、情報レコードの値の多数決を取ることにより重畳情報レコードを求める（Ｓ３０９）。多数決を取ることにより、エラーを回復できる。なお、上述の説明では、大小２種類コードについて説明したが、横方向に配置された他のコードを有する帳票に対しても同様とすることができる。
【００６６】
次に、８方向線分コードのデコーディングについて説明する。８方向線分コードの切出しにおいてはエラー防止と検出を行い、効率的なデコーディング方法を行う。なお、８方向線分コードの大きさは、上述のサイズとして説明する。また、実験により、描画領域が０．３５×０．３５ｍｍ、０．４５×０．４５ｍｍ、０．５×０．５ｍｍ、０．６×０．６ｍｍのサイズにおいても、デコーディングが可能であることが確認済みである。コードの大きさは大きければ大きいほど認識率が高いが、小さければ小さいほど帳票の見た目がよい。８方向線分コードのデコーディングでは、ドット同士間の必要な間隔０．２ｍｍをあけ、好きなコードサイズで帳票を作れるようにしたため、自動的にコードの大きさを検出しこの大きさに合わせたデコーディングを行う。また、８方向線分コードは区切り記号による不定長の情報レコードと情報レコードごとにパリティ符号を使うため、情報レコード長のエラーと情報レコードの内容のエラーを検出することができる。以下に、これらの処理の詳細について述べる。
【００６７】
図３８に、８方向線分コードのデコーディングの流れ図を示す。図３８に示すフローチャートは、コードとパリティ符号と区切り記号とが情報バーの縦方向に配置された帳票に対するデコーディングである。
まず、アクティブ帳票処理システムは、情報レコードをセットする（３７−０１）。例えば、ステップＳ１０３で検出された情報バー又はその一部を記憶部から読み出す。次に、アクティブ帳票処理システムは、情報レコードの先頭の区切り記号を求める。具体的には、以下のステップ３７−０２〜３７−０６の処理を実行する。まず、アクティブ帳票処理システムは、画像の終端か判断する（３７−０２）。例えば、アクティブ帳票処理システムは、次に切り出す対象となる画像（データ）が存在するか判断する。アクティブ帳票処理システムは、画像の終端の場合（３７−０２）、ステップ３７−１７の処理へ移る。一方、アクティブ帳票処理システムは、画像の終端でない場合（３７−０２）、アクティブ帳票処理システムは、コードの図形を切り出す（３７−０３）。例えば、アクティブ帳票処理システムは、縦方向及び横方向のヒストグラムの区切れを判断し、その幅に基づきコードの図形を切り出す。アクティブ帳票処理システムは、切り出しエラーか判断する（３７−０４）。切り出しエラーとしては、例えば、手書きの重なりによりコードが消されるなどの理由によりコードが切り出せないことや、切り出したコードが所定の位置になく、他のコードが消されていることが考えられる。アクティブ帳票処理システムは、切り出しエラーの場合（３７−０４）、ステップ３７−１４の処理へ移る。一方、切り出しエラーではない場合（３７−０４）、切り出したコードの図形を認識する（３７−０５）。アクティブ帳票処理システムは、認識したコードが先頭区切り記号か判断する（３７−０６）。アクティブ帳票処理システムは、認識したコードが、先頭区切り記号の場合ステップ３７−０７の処理へ移り、先頭区切り記号ではない場合はエラーとみなし、ステップ３７−１４の処理へ移る。
【００６８】
ステップ３７−１４〜３７−１６の処理では、次の終端区切り記号を見つける。まず、アクティブ帳票処理システムは、次のコードの図形を切り出す（３７−１４）。アクティブ帳票処理システムは、切り出したコードを認識する（３７−１５）。アクティブ帳票処理システムは、認識したコードが終端区切り記号か判断する（３７−１６）。なお、先頭区切り記号と終端区切り記号は、同じ記号を用いることもできる。アクティブ帳票処理システムは、認識したコードが終端区切り記号ではない場合、ステップ３７−１４に戻る。アクティブ帳票処理システムは、区切り記号を見つけるまで、ステップ３７−１４〜３７−１６を繰り返すことになる。一方、終端区切り記号の場合、ステップ３７−０１の処理へ移る。一方、アクティブ帳票処理システムは、ステップ３７−０６で認識したコードが先頭区切り記号の場合、情報レコードのデータを求める。具体的には、以下のステップ３７−０７〜３７−１３の処理を実行する。
【００６９】
まず、アクティブ帳票処理システムは、画像の終端か判断する（３７−０７）。アクティブ帳票処理システムは、画像の終端の場合（３７−０７）、ステップＳ３７−１７の処理へ移る。一方、アクティブ帳票処理システムは、画像の終端でない場合（３７−０７）、次のコードの図形を切り出す（３７−０８）。アクティブ帳票処理システムは、切り出しエラーか判断する（３７−０９）。アクティブ帳票処理システムは、切り出しエラーの場合（３７−０９）、ステップ３７−１４の処理へ移る。一方、切り出しエラーではない場合（３７−０９）、切り出したコードの図形を認識する（３７−１０）。アクティブ帳票処理システムは、認識したコードが終端区切り記号か判断する（３７−１１）。アクティブ帳票処理システムは、認識したコードが終端区切り記号ではない場合（３７−１１）、セットした情報レコードと対応させて記憶部に認識結果を格納し（３７−１２）、ステップ３７−０７の処理へ戻る。アクティブ帳票処理システムは、３７−０７以降の処理を繰り返して、終端区切り記号を見つけるまでコードを認識し、情報レコードのデータを求める。一方、アクティブ帳票処理システムは、認識したコードが終端区切り記号である場合（３７−１１）、一つの情報レコードの処理を終了し（３７−１３）、ステップ３７−０１に戻り、さらに次の情報レコードに対する処理を実行する。
【００７０】
ステップ３７−１７では、アクティブ帳票処理システムは、情報レコードに重畳され多情報を求める処理を終了し、ステップ３７−１８の処理へ移る。アクティブ帳票処理システムは、情報レコードの長さをチェックし、長さがあり得る範囲（例えば、図１２に示す例では４５〜２０７ビット）に入っていない情報レコードを削除する（３７−１８）。アクティブ帳票処理システムは、情報レコードの長さの多数決をとることにより情報レコードの長さを求める（３７−１９）。アクティブ帳票処理システムは、情報レコードの長さをチェックし、正しくない情報レコードを削除する（３７−２０）。アクティブ帳票処理システムは、情報レコードのパリティ符号をチェックし、正しくない情報レコードを削除する（３７−２１）。アクティブ帳票処理システムは、残った情報レコードの値の多数決を取ることにより、記入枠の重畳情報レコードを求める（３７−２２）。また、アクティブ帳票処理システムは、求めた情報レコードを適宜記憶部に記憶し、処理を終了する。
【００７１】
５．２ コードの大きさと情報バーのコード行数の検出
図３９は、描画エリアの大きさ算出の説明図である。図３９に示す水平バーには、一例として４行のコードが配置されている。コードの切り出しを行うため、水平バーを使ってコードの大きさと情報バーのコード行数を検出する。
まず、水平バーに対して縦方向のヒストグラムをとり、図３９に示すように、各コード図形列の中心位置を検知する。次に、各コード図形列の中心間の距離を求め、これらの距離に対して平均を求める。この結果はコード図形の配置エリア正方形の辺長である。配置エリアの辺長からドット間隔のサイズ０．２ｍｍ（６００ｄｐｉスキャンで４画素）を引くと、描画エリア正方形の辺長が求まる。
【００７２】
本実施の形態のおける帳票は、水平バーのコード行数が記入枠の情報バーのコード行数と同じであると設定しているため、水平バーに対してコード行数を検出することにより、記入枠の情報バーのコード行数を求めることができる。帳票に傾きがあると、コード行数の検出は水平バー全体に対して行うのは難しい。したがって、コードの大きさの検出時に水平バーに対して取った縦方向のヒストグラムに従い、何列かのコード図形だけに対して、横方向のヒストグラムを取ることにより、記入枠の情報バーのコード行数を検出することができる。なお、情報バーのコード行数は、水平バーのコード行数を検出することにより求める以外にも、水平バーを構成するコードにコード行数を示す情報を重畳し、そのコードを認識することにより求めるようにしてもよい。
【００７３】
５．３ コード図形の切出し
次に、コード図形の切り出し（例えば、図３８のステップ３７−０３、３７−０８、３７−１４）について説明する。
【００７４】
５．３．１ ヒストグラムによるコード図形の切出し方法の必要性
図４０は、コードの大きさによるコード切り出しの例である。
コードの大きさが検出できれば、コードの大きさを一定長としてコードを切り出す方法が考えられる。しかし、何らかの誤差（例えば、微少な誤差の累積）があるため、コードの大きさを一定長として正しくコード図形を切り出すことができない場合がある。図４０に示すように、コードの大きさＢＣを一定長として列ごとのコードを切り出し、縦線を引いて切出しの結果をシミュレーションしてみると、始めの何列かは正しく切り出すことができるが、後ろの列になると誤差が大きくなるために正しく切り出すことができない場合がある。本実施の形態にかかるアクティブ帳票処理システムにおいては、コード図形の切出しは、コードの大きさを一定長としての切り出すのではなく、ヒストグラムによる切出しを行うことで、正確なコード切り出しを実現している。
【００７５】
５．３．２ コード図形の切出し方向
まず、情報バーの画像に対して横方向のヒストグラムにとり、行ごとを切り出す。次に、行ごとの画像に対して縦方向のヒストグラムをとり、コードごとの図形を切り出す。傾きのない情報バーの場合、この切出し方向で容易にコード図形を切り出すことができる。しかし、図４１に示すように、傾いてスキャンされた情報バーの場合、この切出し方向では容易にコード図形を切り出すことができない。しかし、このような場合でも、列数にくらべ行数が少なく縦方向へのヒストグラムの重なりが小さいことに注目し、この性質を利用して情報バーが多少傾いていても正しくコードごとの図形を切り出すことができる。例えば、アクティブ帳票処理システムは、まず、情報バーの画像に対して縦方向のヒストグラムにとり、情報バーの左から右へ列ごとを切り出す。次に、列ごとの画像に対して横方向のヒストグラムをとり、コードごとの図形を切り出す。
【００７６】
５．３．３ 手書きの重なった情報レコードの検出と処理
次に、切り出しエラー（図３８の３７−０３、３７−０８、３７−１４に対応）について説明する。手書きと記入枠の重なりにより、分離した記入枠では手書きと重なる部分が消される。これを効率よく検出し、エラーのある情報レコードに対して、処理を行わない方法をとっている。図３８の３７−０３と３７−０８のコード図形の切出しにおいて、切り出されたコードに対してこのようなエラーを検出し、図３８の３７−０４と３７−０９から図３８の３７−１４、３７−１５、３７−１６の繰返し処理に移り、次の区切り記号を見つけるまで、コードを読み飛ばす。つまり、エラーのある情報レコードに対して処理を行わない。情報バーの画像において、左から右へ列ごとのコード図形を切り出していき、前の列と次の列の間隔が想定される幅より大きいときにコード図形と手書きが重なって手書きの分離処理においてコード図形が欠落したと判断する。
【００７７】
図４２は、手書きの重なった情報レコードの検出と処理の説明図である。図４２は記入の情報バーの最左部分であり、仮想的に小さい正方形でコードの描画エリアを表す。描画エリアを均一的に０．２ｍｍの最小間隔（４画素）を空けて並べることで、情報バーのドットテクスチャを形成している。描画エリア正方形の辺長ＢＢは上述の方法により水平バーから求められる。列の中心位置Ｓ＋描画エリア辺長ＢＢ／２の位置を列の最大右位置Ｒ２とし、列の縦方向ヒストグラムの実際の右位置をＲ１とする。
【００７８】
各列のコード図形を切り出す時、この列の右位置Ｒ１と基準ａの距離ｄを求め、距離ｄに従い、手書きの重なりエラーの有無を判断する。まず、基準位置ａの求め方について説明する。情報バーの画像において、左から右へ列ごとのコード図形を切り出していく。最初、基準位置ａの初期位置は情報バーの最左の位置とする。列ごとのコード図形を切り出していく度に、基準位置ａを更新していく。基準位置ａの新しい位置は、切り出した列の中心位置Ｓ＋描画エリア辺長ＢＢ／２である。つまり、基準位置ａは、初期値以外は、いつもコード列の最大右位置Ｒ２を指している。基準位置ａは列の中心位置を基準として変化していくので、始めの位置がノイズなどにより正しくなくても構わない。基準位置ａに従う手書きの重なりエラーの検出の具体的処理を以下に示す。
【００７９】
まず、アクティブ帳票処理システムは、新しいコード列を切り出すごとに、この列の右位置Ｒ１と基準ａの距離ｄを求める（例えば、ステップ３７−０３に対応）。次に、アクティブ帳票処理システムは、距離ｄが描画エリア辺長ＢＢより６画素（描画エリアの間隔４画素＋マージンとしての２画素）以上大きい場合（例えば、ステップ３７−０４に対応）、手書きの重なりエラー（切出しエラー）と見なして、この後のコード図形に対して、区切り記号が見つかるまで無視する（ステップ３７−１４〜３７−１６に対応）。一方、アクティブ帳票処理システムは、距離ｄが描画エリア辺長ＢＢより６画素以上大きくない場合、列のコードを切り出して認識する処理（例えば、ステップ３７−０５、３７−１０に対応）を行う。
【００８０】
５．３．４ コード図形におけるエラー
図４３は、コード図形におけるエラーの例を示す図である。
図４３に示すように、ノイズによってコード図形が接触し、形や大きさが異常になる場合がある。例えば、横方向の連結によるコード図形横サイズエラー、縦方向の連結によるコード図形縦サイズエラー、ノイズによるコード図形縦横サイズエラー、情報バー位置誤差による横方向のコード図形横サイズエラーなどがある。これらの異常に対して、切り出した図形の大きさが想定されるコード図形より小さい場合はノイズとして無視し、大きすぎる場合には、想定される大きさで分離して認識することにより、各コード図形に微小なノイズが付着して連結してしまったり微小なノイズをコード図形として処理してしまったりする誤りを防止する。
【００８１】
列ごとのコード図形を切り出す時、列の幅をチェックし、もし列の幅が描画エリア幅ＢＢ＋４（画素）より大きければ、コード図形の横サイズエラーと判断し、基準位置ａからＢＢ＋４の幅でこの列を分割して切り出す。８方向線分コードは線分で構成され、上述のように線の太さが０．１ｍｍ、６００ｄｐｉスキャンでのサイズが約３画素である。誤差を考慮し、コードの線太さの閾値を、例えば５画素とする。コード図形を認識できるために、描画エリアの幅ＢＢは必ず線の太さより大きい。したがって、コードの幅と高さが両方とも線太さの５画素より小さいことはあり得ない。コードごとの図形を切り出す時、コードの幅と長さをチェックし、もしコードの幅と長さの両方とも５画素以下であれば、コード図形の縦横サイズエラーと判断し、この図形を無視する。また、コード図形の長さが描画エリア幅ＢＢ＋４より大きければ、コード図形の縦サイズエラーと判断し、この図形の最上からＢＢ＋４の幅で分割して切り出す。
【００８２】
こうすることにより、各コード図形に微小なノイズが付着して連結してしまったり、微小なノイズをコード図形として処理してしまったりする誤りを防止できる。
５．３．５ 情報バーの位置検出誤差によるコード図形損傷への対応
図４４〜図４６は、情報バーの位置検出誤差によるコード図形損傷への対応処理の説明図（１）〜（３）である。
記入枠の情報バーの位置を検出するとき、図４４に示すように、例えば上述のステップＳ２０７で検出された情報バーとそれ以外の部分の境界線ｂは、正しい情報バーの境界線となんらかの誤差がある場合がある。この情報バー境界線ｂに従い、コード図形を切り出してデコーディングを行うと、情報バーからはみ出したコード図形の一部を除外して認識することになり、誤認識を招くおそれがある。このことを避けるために、アクティブ帳票処理システムは、以下のようにコードの切り出しの処理（図３８のステップ３７−０３、３７−０８、３７−１４に対応）及び切り出しエラーの処理を実行することができる。
【００８３】
アクティブ帳票処理システムは、検出した情報バー境界線ｂに従い、情報バーの画像に対して、例えば、最上のコードから境界線ｂまでのデータに対して、縦方向のヒストグラムにより、左から右へコードの列ごとの位置を検出する。次に、アクティブ帳票処理システムは、図４５示すように、列ごとのコード画像に対して、横方向のヒストグラムを走査し、コードごとを切り出す。図４５に示すように、記入枠の上側情報バーの切出し方向は上から下へ走査する。一方、下側情報バーの切出し方向は下から上へ走査する。この段階から以後、境界線ｂの情報を利用しない。
【００８４】
アクティブ帳票処理システムは、列ごとに一つづつコードを切り出した後、この列において切り出したコード数と走査した長さＬを調べる。水平バーから求められた情報バーのコード行数をＮとすると、この列のコード数がすでにＮに達しているか、及び／又は、走査した長さＬがＮに応じた長さまで達していれば、コードの切出しを終了する。そうでなければ、続いてヒストグラムを走査し、コードの切出しを行う。ここで、走査した長さで終了を検出する目的は、コード図形が手書きと重なったりして欠落した場合に、情報バーの領域を越えてコードを探しに行かないようにするためである。
アクティブ帳票処理システムは、列ごとに対して、コードの切り出しが終了した時点で、そのコード数をチェックする。もしＮに達してなければ、コード数のエラー（図３８に示す切出しエラー）と見なし、この後のコード図形に対して、区切り記号が見つかるまで無視する。
【００８５】
コード図形の切り出し段階において境界線ｂを用いないことによって、検出した情報バー境界線からはみ出したコード図形を正しく認識することができる。この方法によりコード図形を切り出した結果を図４６に示す。図４６では、便宜上切り出されたコード枠をつけて表示している。記入枠上段の情報バーでは、境界線ｂの誤差の影響を受けずに、コードが正しく切り出されていることが示されている。
【００８６】
５．４ ８方向線分コードの認識
図４７は、８方向線分コードの認識についての説明図である。
次に、コード図形の認識（図３８の３７−０５、３７−１０、３７−１５に対応）について説明する。
コードの大きさが検出できれば、コードの大きさに合わせるデコーディング方法を行うことができる。コードの描画エリア正方形の辺長はＢＢである。コード図形に対して、四方向へのヒストグラムをとる。図４７に示すように、四方向へのヒストグラムの幅を別々にｌ、ｘ、ｓ、ｈとする。エラーなどの誤差を考慮し、コードの線太さの閾値を５画素とする。
【００８７】
図４８は、コード認識のアルゴリズムである。また、図４９に、コードを認識のプログラム例を示す。
まず、アクティブ帳票処理システムは、ｈ≦５か判断する（Ｓ５０１）。アクティブ帳票処理システムは、ｙｅｓのときコード＝０とし、ｎｏのとき、ｈ≧ＢＢ−２か判断する（Ｓ５０２）。アクティブ帳票処理システムは、ｙｅｓの時ステップＳ５０３へ移り、ｎｏの時ステップＳ５０８へ移る。アクティブ帳票処理システムは、ｘ≧ＢＢ−２か判断する（Ｓ５０３）。アクティブ帳票処理システムは、ｙｅｓの時ステップＳ５０４へ移り、ｎｏの時ステップＳ５０６へ移る。アクティブ帳票処理システムは、ｓ≦５か判断する（Ｓ５０４）。アクティブ帳票処理システムは、ｙｅｓの時コード＝２とし、ｎｏの時ｌ≦５か判断する（Ｓ５０５）。アクティブ帳票処理システムは、ｙｅｓの時コード＝６とし、ｎｏの時コード＝８とする。
【００８８】
ステップ５０６では、アクティブ帳票処理システムは、ｘ＞５か判断する（Ｓ５０６）。アクティブ帳票処理システムは、ｎｏの時コード＝４とし、ｙｅｓの時ｓ＜ＢＢ−２か判断する（Ｓ５０７）。アクティブ帳票処理システムは、ｙｅｓの時コード＝３とし、ｎｏの時コード＝５とする。
ステップ５０８では、アクティブ帳票処理システムは、ｓ＜ＢＢ−２か判断する（Ｓ５０８）。アクティブ帳票処理システムは、ｙｅｓの時コード＝１とし、ｎｏの時コード＝７とする。
なお、上述の判断以外にも、コードの大きさ、線の太さに応じた適宜の判断をすることができる。また、四方向ヒストグラムを用いる以外にも、上述の部分的走査、マッチングによりコードを認識することもできる。
【００８９】
５．５ 情報レコード長エラーの検出とその処理
次に、情報レコード長エラーの検出とその処理（図３８の３７−１８、３７−１９、３７−２０に対応）について説明する。
８方向線分コードは、区切り記号により、情報レコードの長さエラーの検出を行うことができる。上述のコーディング方法で述べたように、８方向線分コードの情報レコードの長さは不定長であるが、パリティの記号を含め、コード図形の数は１６個から７０個（情報レコードは、４５〜２０７ビット）までの間にある。コード図形を認識する時、区切り記号の認識を間違うと、情報レコードの長さは１６から７０までの間になっていない場合がある。その場合、次の区切り記号までを読み飛ばして、これらの情報レコードを削除する（ステップ３７−１８）。
【００９０】
また、情報バーの全部のコードに対して、処理し認識を終えたら、複数のレコードが求まる。これらのレコードの長さがすべて同じでない場合は、それぞれの長さの多数決をとり、最多のレコード長を正しい長さとする（ステップ３７−１９に対応）。また、情報レコードの長さをチェックし、その長さが多数決により求められた長さと異なる情報レコードを削除する。残った情報レコードに対して次のパリティチェックを行う。
【００９１】
５．６ パリティ符号のチェック
情報レコードに対して、パリティ符号のチェックを行う（図３８の３７−２１に対応）。例えば、情報レコードごとに、同じ位のビットでの１の数が偶数になっているかいないかをチェックする。なっていれば、この情報レコードが正しく、なっていなければ、正しくないと判断しこの情報レコードを削除する。
【００９２】
５．７ 記入枠の重畳情報レコードの取得
以上で述べた方法により求めた情報レコードに対して、ビットごとに多数決を取る（図３８の３７−２２に対応）。こうすることにより、記入枠ごとに対して、確信度の強いデータを求めることができる。
【００９３】
６．メールアドレス認識率を高める方法
図５０は、メールアドレスの認識率を高めるための記入枠である。
メールサーバによってメールアドレスの表記法が違い、メールアドレスの文字種も違うが、一般的に使われるメールアドレス形式はドメインアドレス形式であり、その文字種は「＠」、英数字、「．」（ピリオド）、「−」（ハイフン）、「＿」（アンダーバー）である。アクティブ帳票処理では、記入枠に重畳した情報に従い、手書きの内容がメールアドレスの場合にはこれらの文字種に限定することによって認識率を高めることができる。
【００９４】
しかし、これらの文字種は、オフライン文字認識においては一般に低い認識率となり、メールアドレスの認識率がこの認識率に左右されることになる。字種を限定しても、英文大文字、英文小文字と数字などの字種が互いに影響しあい、誤認識になる傾向がある。また、メールアドレスは意味の通じない文字列なので、認識率を高める文脈処理が行えない。これも、メールアドレス認識率を高められない原因である。しかし、帳票処理システムにとっては、メールアドレスの認識は間違うと大きい過ちを犯す危険性があるので、極めて重要なことである。メールアドレス誤認識において、主な原因は類似文字への誤認識である。もし、この誤認識を避けることができれば、認識率を高めることができる。
【００９５】
図５０に示すように、メールアドレスの文字種を限定するために、例えばアクティブ帳票の中でメールアドレス記入枠の下に、もう一つの記入枠を設ける。この記入枠の中で、上のメールアドレスに対して対応するマスの文字種を記入する。認識のしやすさと人の記入しやすさを考慮し、例えば、以下のような符号を記入する。
（１）￣：英文大文字（枠に重なって記入できるようにする）
（２）＿：英文小文字（枠に重なって記入できるようにする）
（３）＝：数字（枠に重なって記入できるようにする）
（４）空白：その他
【００９６】
縦方向および横方向へのヒストグラムをとること、あるいは、枠内で３種の記号をマッチングすることによりこれらの符号を容易に、かつ、確実に認識できる。こうすることにより、メールアドレスの文字種間の相互的な影響を避けることができ、認識率が高められる。図５０に示すように、これらの記号を連続するマスにまたがって記入できるようにする。これにより、文字単位ではなく文字列単位に記入できるので指示が簡単になる。認識のためにはマスの中だけを見れば良い。なお、文字種を限定するための記入枠の情報レコードには、文字種類としてメールアドレスの認識を高めるための上述の符号が記入されることを示す適宜のデータを含むことができる。
【００９７】
７．アクティブ帳票処理システムの試作
以上で述べた技術を使いアクティブ帳票処理システムを試作した。以下、その概略について述べる。
【００９８】
７．１ 開始と帳票読み込み
アクティブ帳票システムを立ち上げると、［ｉｍａｇｅＳｃａｎ］、［ｆｉｌｅ］、［ｉｍａｇｅＳｉｚｅ］、［設定］等のメニューと、実行ボタン等が表示される。例えば、アクティブ帳票処理システムは、［ｉｍａｇｅＳｃａｎ］メニューが操作されることにより、スキャナを通じて帳票を読め込む。また、アクティブ帳票処理システムは、［ｆｉｌｅ］メニューから既存の帳票画像を開くこともできる。アクティブ帳票処理システムは、読み込んだ帳票画像を表示することができる。また、［ｉｍａｇｅＳｉｚｅ］メニューを通じて、画像の表示サイズを変更可能である。［設定］メニューから帳票処理システムの終了後に呼び出すアプリケーション等の設定を行う。プログレスバーを通じ帳票処理の進行状況を表示する。画像を読み込み表示して、実行ボタンが押されると、アクティブ帳票処理システムは処理を開始する。
【００９９】
７．２ 記入枠と手書きの分離・記入枠位置と記入枠構造の検出
図５１は、アクティブ帳票処理システムの処理の流れの例である。
アクティブ帳票処理システムは、帳票の読み取り後、記入枠と記入枠マス位置を検知し、記入枠と手書きを分離する（図５１の５２−１）。アクティブ帳票処理システムは、記入枠ごとの枠だけの画像と手書きだけの画像を求め、記入枠を空記入枠、水平バー、手書き済み記入枠、ノイズに分類する（図５１の５２−２）。例えば、記入枠の手書きだけの画像の黒画素数がある値以下であれば空記入枠と判断する。記入枠の枠だけの画像に対して縦方向のヒストグラムを取り、縦方向のヒストグラムでの変動が小さく、ある値以下であれば、水平バーと判断する。また、記入枠の幅と高さが小さく、ある値以下であれば、エラーと判断する。その以外の記入枠は手書き済み記入枠とする。次に、アクティブ帳票処理システムは、記入枠ごとの枠画像に対して横方向のヒストグラムをとり、手書文字の属性、文字種、命令、見出しなどの情報が埋め込まれている枠上部と下部の位置を検出する（図５１の５２−３）。
【０１００】
７．３ 重畳情報読取り
アクティブ帳票処理システムは、記入枠ごとに、情報が埋め込まれている枠上部と下部の位置情報を、重畳情報を認識するデコードエンジンに渡し、記入枠内の重畳情報を解読する（図５１の５２−４）。一つの記入枠に埋め込まれた手書きの属性には、例えば、住所、メールアドレス、組織名、人名、職名、金額、番号、日時曜日、印、自由筆記、チェック、図などの種類がある。
【０１０１】
７．４ 文字ごとへの分離とオフライン文字認識
アクティブ帳票処理システムは、解読した重畳情報に含まれる手書きの属性により、記入枠をチェック、図・印、メールアドレス、他の手書き文字の種類に分類する（図５１の５２−５）。アクティブ帳票処理システムは、他の手書き文字に対して、文字ごとへ分離し、重畳情報に含まれる記入枠ごとの手書きの種類に従い、文字認識を行う（図５１の５２−９、５２−１０、５２−１２、５２−１３）。これにより文字認識率を高めることができる。アクティブ帳票処理システムは、他の手書き文字の場合、手書き文字の属性によって文脈処理を適用するかどうかを決める。属性が組織名、職名、自由筆記、住所の場合に文脈処理を行う（図５１の５２−１１）。人名、金額、番号、日時曜日の場合は文脈処理を行わない。アクティブ帳票処理システムは、メールアドレスに対しては、文字ごとへ分離して文字ごとの種類を検知し、この種類に従って文字認識を行うことで文字認識率が高められる（図５１の５２−６、５２−７、５２−８）。
【０１０２】
７．５ 手書き文字オフライン認識結果の修正
次に、アクティブ帳票処理システムは、オフライン認識の結果を、修正インタフェースを通して修正を行う。
【０１０３】
７．６ 命令書作成・帳票画像保存と修了
アクティブ帳票処理システムは、オフライン認識の結果を修正し終わったら、アクティブ帳票から抽出した内容を、例えばＣＳＶファイルの形で出力する。出力されるファイルを命令書（命令書データ）と呼ぶ。アクティブ帳票処理システムの終了後に呼び出すアプリケーションは、命令書に従い帳票に対しての処理を行う。また、帳票画像を命令書と同じフォルダに保存する。
図５２は、出力ファイルのフォーマットである。命令書はコンマを区切りとして、記入枠ごとの情報レコードを一行ずつに表す。一行目は列ごとの内容を表す。［ｎａｍｅ］は見出し、［ｐｒｏｐｅｒｔｙ］は属性、［ｃｏｎｔｅｎｔｓ］は手書きの内容、［ａｃｔｉｏｎ］は命令、［ｃｈａｒａｃｔｅｒ］は文字種である。二行目以降は記入枠ごとの情報レコードを表す。記入枠に手書きを記入してない場合、［ｃｏｎｔｅｎｔｓ］の対応の列で「、、」のように何も出力しない。
【０１０４】
８．評価実験
８．１ 実験対象データと実験環境
Ａ４判大の大小２種類コードの帳票２枚と、８方向線分コードの帳票２枚を１２００ｄｐｉでプリントし、１０人に１枚ずつ書いてもらい、全部で２０枚の大小２種類コードの帳票サンプルと２０枚の８方向線分コードの帳票サンプルを収集した。これら帳票を６００ｄｐｉ、８ビットグレーレベルでスキャンし、アクティブ帳票処理システムの予備評価を行った。図５３は、評価実験に用いた８方向線分コードによる帳票である。大小２種類コードの帳票も同様のものである。
【０１０５】
実験環境としては、Ｐｅｎｔｉｕｍ（登録商標）４の２．２６ＧＨｚのＣＰＵを有するＰＣを用いた。オフライン枠なし手書き文字データ収集の場合、実験用のデータということで、オンライン枠なし手書き文字実験用データの収集方法を使用し、データの筆記に際して、次のような条件を設けた。（１）文字の大きさ・文字の間隔は自由とする。（２）文字と文字の間を続けるのは不可とする。
大小２種類コード帳票の場合は、システムを簡易に仕上げるため、枠あり文字認識だけを可能とし、さらに、メールアドレスの認識率を高めるための文字ごとの字種限定は設けてない。８方向線分コード帳票の場合は、枠なし文字認識も可能とし、メールアドレスに対して、文字ごとの字種限定も実現した。
【０１０６】
８．２ オフライン枠なし手書き文字認識の評価項目
枠なし認識は、手書きの文字列パタンを「文字列」として認識する処理である。しかし、「文字列」の認識率を評価する場合、評価の尺度を明確にしておく必要がある。例えば、一行２０字ぐらいの文字列を認識した結果、「一文字だけ誤認識した」ケースと、「ほとんどの文字を誤認識した」ケースが生じた場合、単純に両者を一行の「認識失敗」と評価するのは公正ではない。この理由から、オンライン枠なし手書き文字認識の評価項目を使用し、以下のような評価項目を設ける。
【０１０７】
８．２．１ 文字単位の認識率
次式で表される「文字単位の認識率」を評価項目として採用する。
文字単位の認識率＝正認識文字数／正解文字数
図５４は、文字単位の認識率の算出方法の説明図である。例えば、「明日は晴れ」という入力パタンに対して「日月昨晴わ」という結果が返ってきたとすると、この場合、正しく認識された文字は‘晴’の一文字だけである。正解の文字数は５であるので、文字単位の認識率は、１／５＝０．２０＝２０％と計算される。
【０１０８】
８．２．２ 正分割率
さらに、文字分割の精度に関する評価項目（「正分割率」とする）も加える。正分割率を次式で定義する。
正分割率＝１−（文字分割失敗箇所の数／正解文字数）
先の図５４の例では、文字分割失敗箇所は、次の二個所である。（１）本来「明」となるところを、「月」と「日」に分けてしまった。（２）本来、「日」と「は」の二文字になるところを、一文字にくっつけてしまった。したがって、正分割率は、１−２／５＝６０％と計算される。
【０１０９】
８．３ 実験結果
８．３．１ 大小２種類コード
図５５に、大小２種類コード帳票の実験結果を示す。平均処理時間は、帳票を認識し修正インタフェースを呼び出すまでの平均処理時間である。帳票サンプルの中で、書き間違った文字（２０枚の帳票サンプル中で３文字）及び、オフライン認識辞書の４４４３個の字種に入ってない文字（２０枚の帳票サンプル中で１文字）は評価の中に入れない。
切り出した手書文字に対して記入枠から読み取った手書文字の種類に従い、認識カテゴリの字種を限定することによって認識率が５９．７４％から９３．７２％へ３３．９８％向上した。手書き文字の認識率はメールアドレスの認識率も含めるため、メールアドレスの認識率に左右された。そのうえ、２０枚の帳票の中で２枚の帳票は書き方が乱雑で、人でも識別できない文字があったため、文字認識率を低下させる原因になった。
【０１１０】
帳票を読み取って修正インタフェースに渡すまでの処理時間は、本実験環境において複雑な帳票では４秒弱、簡単な帳票では２秒弱である。本実験の範囲内では、記入枠位置の検知率は１００％に達した。重畳情報レコードのデコード成功率は、情報量の少ない大小２種類コードと簡単なコード重畳方法を採用し、かつ、各デーコートエラーチェックを設けなかったため、１００％の認識率は得られなかった。
【０１１１】
８．３．２ ８方向線分コード
図５６に、８方向線分コードの実験結果を示す。８方向線分コード帳票の場合、枠なし手書き文字認識とメールアドレスの文字ごとの字種限定を設けたため、手書き文字の認識率項目評価においては、メールアドレス以外の枠あり手書き文字、メールアドレス、そして、枠なし手書き文字という三つの分類で評価する。平均処理時間は、帳票を認識し修正インタフェースを呼び出すまでの平均処理時間である。
帳票サンプルの中で、書き間違った文字（２０枚の帳票サンプル中で２文字）は評価の中に入れない。さらに、一枚の帳票の中で、スキャンにより帳票画像にエラーが付いたため、空き記入枠なのに文字のある枠として認識されてしまった。しかし、修正インタフェースにより修正を行ったため、これも手書き文字認識率の評価に入れない。
【０１１２】
記入枠から読み取った手書文字の種類に従い、認識カテゴリの字種を限定することにより、メールアドレス以外の枠あり手書き文字においては、認識率が８６．７８％から９８．８５％へ１２．０７％向上した。メールアドレスにおいては、文字ごとの字種を限定することにより、認識率が属性を利用した認識８０．１９％より９７．１５％へ１６．９６％向上した。メールアドレスの１０位累積認識率は、文字類を限定してもしなくてもほぼ同じであるが、１位決定率は字種を限定しない場合に激しく低下した。これは、メールアドレス認識率低下の原因が類似文字の相互的な影響からと思われる。
【０１１３】
帳票を読み取って修正インタフェースに渡すまでの処理時間は、本実験環境において複雑な帳票Ａでは４秒程度、帳票Ｂでは３秒程度である。本実験の範囲内では、記入枠位置の検知率は１００％に達した。重畳レコードのデコード成功率は、情報量の多い８方向線分コードと効率的なコード重畳方法を採用し、かつ、各デーコートエラーチェックを設けたため、１００％の認識率を得た。枠なし手書き文字の場合は、９７．７１％の文字単位の認識率と９８．４７％正分割率を得た。
【０１１４】
９．線分検出、交点検出
また、ヒストグラムを用いないで、線や交点の検出から帳票構造を認識する方法には例えば、非特許文献４、５に記載の方法がある。以下に、本実施の形態における線分検出及び交点検出の概略を示す。なお、以下の各処理は、アクティブ帳票処理システム（処理部）が実行する。
【０１１５】
９．１ 帳票の表現モデル
殆どの帳票が３種類の線セグメント（水平、垂直、斜め）を含んでいるので、これらの３種類の線セグメントにより帳票構造を表現する。一つの線セグメントは始点と終点の座標により表現される。本実施の形態に係る帳票においては、記入枠、水平バー等はドット又はコード図形で構成され、これらドット等を膨張処理して連結させることにより線分を形成し、水平、垂直、斜めの線セグメントを求める。
また、水平の線セグメントに対して、一番左の始点の座標に従い上から下へ左から右への方向でソートを行う。つまり、まずこれらの始点のＹ座標に従い上から下への方向でソートする。そして、同じＹ座標の水平線セグメントに対して、始点のＸ座標に従い左から右への方向でソートする。類似的に垂直線セグメントに対しては、まず一番上の始点のＸ座標に従い左から右へソートし、そして、同じＸ座標始点の垂直セグメントに対してＹ座標に従い上から下への方向でソートする。斜めの線セグメントも水平線セグメントと同じであるが、一番左の始点を使う代わりに一番上の始点を使いソートする。なお、ソートの方向は適宜の方向とすることができる。
【０１１６】
なお、帳票の表現モデルは、例えば以下に示す五つの部分から構成される。
（１）（ＮＨ、ＮＶ、ＮＳ）：ＮＨ、ＮＶ、ＮＳはそれぞれ水平、垂直と斜めの線セグメント数を表す。（２）（ＳＬＨ、ＳＬＶ、ＳＬＳ）：ＳＬＨ、ＳＬＶ、ＳＬＳはそれぞれ水平、垂直と斜めの線セグメントのリストを表す。（３）［（Ｘｍｉｎ、Ｙｍｉｎ）；（Ｘｍａｘ、Ｙｍａｘ）］：全ての線セグメントを含んだ正方領域の一番左上と一番右下の座標。（４）［（ＸＤ（ｉ）ｍｉｎ、ＹＤ（ｉ）ｍｉｎ）；（ＸＤ（ｉ）ｍａｘ、ＹＤ（ｉ）ｍａｘ）］：第ｉ番目記入枠の正方領域の一番左上と一番右下の座標。（５）［（ＸＮ（ｉ）ｍｉｎ、ＹＮ（ｉ）ｍｉｎ）；（ＸＮ（ｉ）ｍａｘ、ＹＮ（ｉ）ｍａｘ）］：第ｉ番目名前枠の正方領域の一番左上と一番右下の座標。
【０１１７】
９．２ 線セグメントの抽出と調節
ここで、帳票画像（データ）から線セグメントを抽出するまでの処理について説明する。
まず、帳票画像（データ）を入力し、傾きの補正を行う。これは、水平に近いできるだけ長い線分を正確に水平になるように画像を回転する。なお、垂直線を用いても良い。また、１本だけに着目してもよいし、複数本に着目して、それらを平均して水平、あるいは垂直するように回転しても良い。
アクティブ帳票の帳票画像に対して記入枠と手書きを分離し、記入枠だけの画像を求める。なお、記入枠と手書き枠の分離については、ラベリング等の上述と同様の方法を用いることができる。記入枠だけの画像に対し小さいドットが連結するまで膨張処理を施す。そして、３種類の線セグメント（水平、垂直、斜め）を抽出する。
抽出した線セグメントに対して、水平の線セグメントは二つの端点のＹ座標が所定範囲内で異なる場合は同じになるように、垂直の線セグメントは二つの端点のＸ座標が所定範囲で異なる場合は同じになるように、各座標の平均を取り補正することができる。このように、例えばわずかな座標のずれがある場合は、斜めの線セグメントとして扱わず水平又は垂直の線セグメントとして扱うことができる。次に、上述のようにソートを行う。
【０１１８】
ソートした線セグメントに対して、例えば、以下に示すような補正を行うこともできる。
（１）切れた線セグメントの連結：線セグメントを抽出しソートした後、これら線セグメントを水平、垂直、斜めの三つのグループに分ける。スキャンなどにより切れた線セグメントに対して連結処理を行う。水平線セグメントのグループにおいて、Ｙ座標がほぼ同じ二つの線セグメントが、例えば０．５ｃｍより近ければ、この二つの線セグメントを連結する。垂直線セグメントと斜めの線セグメントも同じである。
（２）小さい線セグメントの削除：もし、水平線セグメントの長さは、例えば、垂直線セグメント間の最小距離の８５％より短ければ、この水平線セグメントをストロークの線と見なし、削除する。垂直線セグメントの長さも、例えば、水平線セグメント間の最小距離の８５％より短ければ、この垂直線セグメントをストロークの線と見なし、削除する。
（３）線セグメントの補正：もし、垂直線セグメントの末端点から水平線セグメントまでの距離が０．５ｃｍより近ければ、この垂直線セグメントを水平線セグメントに接触するように補正する。水平線セグメントと斜め線セグメントも同じである。
なお、上述の判断に用いる数値は、適宜の数値とすることができる。
【０１１９】
９．３ 名前枠と記入枠の検知
次に、抽出した線セグメントに基づき、名前枠、記入枠を検知する処理について説明する。
普通の帳票においては、記入枠、名前枠と混合枠を含んでいる。記入枠は、データを記入してもらうための枠である。名前枠は、説明とガイダンスなどのテキストを含んだ枠である。混合枠は、記入枠と名前枠の両方を兼ねるものである。以下に説明する枠検知アルゴリズムにおいて、入力データは、ソートされた水平と垂直の線セグメントリストＳＬＨとＳＬＶであり、出力データは、記入枠と名前枠／混合枠の正方領域データ（記入枠データ）である。
（ステップ１）水平と垂直の線セグメントについて、全ての接触点、交差点、末端点を検出する。各水平線に関して、この水平線に接触か交差する垂直線を検出し、これらの接触点、交差点の座標を計算する。もし、水平線の端点において接触点と交差の垂直線が一つもなければ、この水平線の端点を末端点とする。なお、枠が長方形のように閉じた図形で構成されている場合は、末端点は基本的には現れないが、例えば画像のエラー、ノイズなどにより枠を構成する線分が切れたりすることで、末端点が現れる場合がある。また、枠ではなく、線分の上側又は下側に文字等を記入させる帳票の場合もある。
【０１２０】
接触点か交差点の分離は意味がなく、それぞれの接触点、交差点、末端点を、水平線と垂直線の位置関係等に基づき、例えば図５７に示すようなタイプ１〜４の４種類に分ける。タイプ１に示す３つの接触点及び交差点は、例えば、その点が枠の上側にあることを示している。タイプ２に示す点は、例えば枠の上側又は下側にあることを示している。タイプ３に示す点は、例えば枠の下側にあることを示している。また、タイプ４は、末端点を示す。これらタイプに従い、記入枠を検知する。例えば、タイプ１の２つの点（枠の上側の２頂点を示す）と、タイプ３の２つの点（枠の下側２頂点を示す）を適宜見つけることで、枠を検知することができる。
なお、全ての点は上から下へ、左から右への順番でソートされている。なぜならば、上述のように線セグメントがソートされているからである。まず、以下の処理で使用するポインターは、ソートされた最初の点に設定される。
【０１２１】
（ステップ２）ポインターの指している点Ａと点Ａの次の点Ｂを調べ、以下の処理を実行して枠を検知、登録（記憶）する。（１）もし、ＡとＢのＹ座標が違えばステップ４に跳ぶ。（２）もし、ＡとＢともタイプ４に属すれば、ＡＢの線セグメントから上の方向へ、黒いピクセルの水平線セグメントか文字列が見つかるまで、スキャンする。もし、黒いピクセルが見つからなければ、画像のトップに到着する。どちらでも、ＡＢ線を底とする正方領域を求める。もし、この正方領域の高さが、例えば０．４ｃｍより小さければ無視し、ステップ４へ跳ぶ。そうではなければ、一つの枠として登録（記憶）する。
（３）もし、ＡとＢともタイプ１かタイプ２に属すれば、ソートされたリストの中でＢ以降から、タイプ２、３に属し正方形（又は長方形、以下同じ）ＡＢＣＤを形成する最初の点Ｃ、Ｄを見出す。もし、Ｃ、Ｄ点を見つければ正方形ＡＢＣＤを枠として登録する。そうではなければステップ４へ跳ぶ。（４）もし、Ａはタイプ４に、Ｂはタイプ１かタイプ２に属すれば、類似的に点Ｃ、Ｄを見出す。Ｃはタイプ４に、Ｄはタイプ２かタイプ３に属し、かつ、ＡＢＣＤが正方形であるような点である。もし、Ｃ、Ｄ点を見つければ正方形ＡＢＣＤを枠として登録する。そうではなければステップ４へ跳ぶ。
（５）もし、Ａはタイプ１かタイプ２に、Ｂはタイプ４に属すれば、類似的に点Ｃ、Ｄを見出す。Ｃはタイプ２かタイプ３に、Ｄはタイプ４に属し、かつ、ＡＢＣＤが正方形であるような点である。もし、Ｃ、Ｄ点を見つければ正方形ＡＢＣＤを枠として登録する。そうではなければステップ４へ跳ぶ。（６）もし、以上の条件は全て満足しなければ、ステップ４へ跳ぶ。
【０１２２】
（ステップ３）ステップ２で求めた枠の正方領域をスキャンする。もし、この正方領域の黒いピクセルの数が予め定められた閾値以上であれば、名前枠／混合枠の正方領域とラベルする。そうでなければ、記入枠とラベルする。
（ステップ４）ポインターを１プラスし、次の点を指す。もし、ポインターは最後の点を指せば処理を終了する。そうでなければステップ２に跳ぶ。
【０１２３】
【発明の効果】
本発明によると、窓口やオフィス等で利用される帳票読取りに利用可能で、帳票記入枠と記入文字の分離が容易な帳票及び帳票処理方法、帳票処理プログラム、そのプログラムを記録した記録媒体及び帳票処理装置を提供することができる。また、本発明によると、記入文字の認識率を高めることができる。さらに、本発明によると、装置側でなく帳票側に帳票それ自身の処理方法を記述し、読取装置として汎用機を用いることができ、及び、多種の帳票を一台で処理することができる。
また、本発明によると、重畳する情報量を高めるためのドット形状を有する帳票及び帳票処理方法を提供することができる。本発明によると、手書きとの重なりや汚損から重畳情報を安定に読み取るためのコーディング方式及びデコーディング方式を提供することができる。さらに、本発明によると、特に誤読しやすい英数字記号などの補助記入方式を提供することができる。また、本発明によると、エディタで簡易に作成し、プリンタで印刷できる帳票を提供することができる。また、本発明によると、記入枠の行間の画像をスキャンする手間を省略し、処理時間を短くすることができる。
【図面の簡単な説明】
【図１】アクティブ帳票の構成図。
【図２】アクティブ帳票処理システムのハード構成図。
【図３】大小２種類の図形を用いるコード（大小２種類コード）の構成図。
【図４】８方向線分を用いるコード（８方向線分コード）の構成図。
【図５】描画エリアと配置エリアの関係。
【図６】２１２種類の図形を用いるコード（２１２種類コード）の構成図。
【図７】２８種類の図形を用いるコード（２８種類コード）の構成図。
【図８】重畳する情報レコードを示す図。
【図９】属性とコードが示す値の対応を示すテーブル。
【図１０】文字種類及び命令と、コードが示す値との対応を示すテーブル。
【図１１】情報レコードのドット列へのコーディング方法を示す図。
【図１２】重畳する情報レコードを示す図。
【図１３】８方向線分コードの重畳の例。
【図１４】パリティ符号の設定方法の説明図。
【図１５】区切り記号を表す図形。
【図１６】四方向のヒストグラムによる認識方法の説明図。
【図１７】標準パタンサンプルと入力コードの特徴値の抽出の説明図。
【図１８】標準パタンとマッチングすることによるコードの認識の説明図。
【図１９】部分的な走査による認識方法の説明図。
【図２０】大小２種類コード及び８方向線分コードにより作られたドットテクスチャの記入枠。
【図２１】四方向ヒストグラムとマッチングによる認識方法を試した結果。
【図２２】２１２種類コードにより作られたドットテクスチャの記入枠。
【図２３】コードの認識結果。
【図２４】２８種類コードにより作られたドットテクスチャの記入枠。
【図２５】認識実験結果。
【図２６】各種のコード形状の認識結果の比較図。
【図２７】アクティブ帳票処理システムの流れ図。
【図２８】記入枠と手書きの分離及び記入枠と記入枠構造の検知についてのフローチャート。
【図２９】メディアンフィルタの説明図。
【図３０】記入枠と手書きが重なった場合における分離されたき記入枠と手書き文字。
【図３１】ヒストグラムによる記入枠及び記入枠構造の検出の説明図。
【図３２】記入枠構造の検知方法についての説明図（１）。
【図３３】記入枠構造の検知方法についての説明図（２）。
【図３４】記入枠構造の検知方法についての説明図（３）。
【図３５】帳票の空白を考慮しない方法と、考慮した方法を適用した処理結果。
【図３６】記入枠検出時の情報損失防止処理の説明図。
【図３７】大小２種類コードのデコーディングの流れ図。
【図３８】８方向線分コードのデコーディングの流れ図。
【図３９】描画エリアの大きさ算出の説明図。
【図４０】コードの大きさによるコード切り出しの例。
【図４１】記入枠の情報バーからコードごとの図形を切り出す切出し方向の説明図。
【図４２】手書きの重なった情報レコードの検出と処理の説明図。
【図４３】コード図形におけるエラーの例を示す図。
【図４４】情報バーの位置検出誤差によるコード図形損傷への対応処理の説明図（１）。
【図４５】情報バーの位置検出誤差によるコード図形損傷への対応処理の説明図（２）。
【図４６】情報バーの位置検出誤差によるコード図形損傷への対応処理の説明図（３）。
【図４７】８方向線分コードの認識についての説明図。
【図４８】コードを認識のアルゴリズム。
【図４９】コードを認識のプログラム例。
【図５０】メールアドレスの認識率を高めるための記入枠。
【図５１】アクティブ帳票処理システムの処理の流れの例。
【図５２】出力ファイルのフォーマット。
【図５３】評価実験に用いた帳票。
【図５４】文字単位の認識率の算出方法の説明図。
【図５５】大小２種類コード帳票の実験結果。
【図５６】８方向線分コードの実験結果。
【図５７】接触点、交差点及び末端点の分類を示す図。
【符号の説明】
１０ 水平バー
２０ 記入枠
３０ 情報バー
４０ マス
１ 処理部
２ 帳票入力部
３ 出力部
４ 表示部
５ 記憶部
Claims (34)
- 線分の傾斜又は複数の線分の組み合わせで情報が表現されるコードで構成される記入枠データと、記入された手書きデータとを含む帳票画像データを入力する帳票入力ステップと、
前記帳票入力ステップで入力された帳票画像データに基づき、記入枠データと手書きデータを分離し、及び、各記入枠データと、コードにより所定の情報が重畳された当該記入枠データ内の情報バーとを検出する記入枠検出ステップと、
検出された情報バーの各コードを切り出すステップと、
切り出されたコードの、縦方向と、横方向と、右斜め方向と、左斜め方向との４方向のヒストグラムを求めるステップと、
求められた４方向のヒストグラムに基づき、コードの形状特徴を判断し、コードを認識するコード認識ステップと
を含む帳票処理方法。 - 線分の傾斜又は複数の線分の組み合わせで情報が表現されるコードで構成される記入枠データと、記入された手書きデータとを含む帳票画像データを入力する帳票入力ステップと、
前記帳票入力ステップで入力された帳票画像データに基づき、記入枠データと手書きデータを分離し、及び、帳票画像データに対する横方向及び縦方向のヒストグラム又は線分検出並びに／若しくは交点検出に基づき、各記入枠データと、コードにより所定の情報が重畳された当該記入枠データ内の情報バーとを検出する記入枠検出ステップと、
検出された情報バーの各コードを切り出すステップと、
切り出されたコードの、縦方向と、横方向と、右斜め方向と、左斜め方向との４方向のヒストグラムを求めるステップと、
求められた４方向のヒストグラムに基づき、コードの形状特徴を判断し、コードを認識するコード認識ステップと
を含む帳票処理方法。 - ドットの幅又は線分の傾斜又は複数の線分の組み合わせで情報が表現されるコードで構成される記入枠データと、記入された手書きデータとを含む帳票画像データを入力する帳票入力ステップと、
前記帳票入力ステップで入力された帳票画像データに基づき、記入枠データと手書きデータを分離し、及び、各記入枠データと、コードにより所定の情報が重畳された当該記入枠データ内の情報バーとを検出する記入枠検出ステップと、
前記記入枠検出ステップで検出された情報バーの各コードを認識し重畳情報を抽出する重畳情報認識ステップと、
前記記入枠検出ステップで分離された手書きデータに対して、抽出された重畳情報が示す手書きデータの属性及び／又は文字種類に従い文字認識を行う文字認識ステップと、
前記文字認識ステップで認識された文字情報と、前記重畳情報認識ステップで抽出された重畳情報に基づき、他のアプリケーションシステムに所定の処理をさせるための命令書データを作成する命令書作成ステップと、
前記命令書作成ステップで作成された命令書データを出力する、及び／又は、前記帳票入力ステップで入力された帳票画像データと、当該命令書データとを対応させて記憶するステップと
を含む帳票処理方法。 - ドットの幅又は線分の傾斜又は複数の線分の組み合わせで情報が表現されるコードで構成される記入枠データと、記入された手書きデータとを含む帳票画像データを入力する帳票入力ステップと、
前記帳票入力ステップで入力された帳票画像データに基づき、記入枠データと手書きデータを分離し、及び、帳票画像データに対する横方向及び縦方向のヒストグラム又は線分検出並びに／若しくは交点検出に基づき、各記入枠データと、コードにより所定の情報が重畳された当該記入枠データ内の情報バーとを検出する記入枠検出ステップと、
前記記入枠検出ステップで検出された情報バーの各コードを認識し重畳情報を抽出する重畳情報認識ステップと、
前記記入枠検出ステップで分離された手書きデータに対して、抽出された重畳情報が示す手書きデータの属性及び／又は文字種類に従い文字認識を行う文字認識ステップと、
前記文字認識ステップで認識された文字情報と、前記重畳情報認識ステップで抽出された重畳情報に基づき、他のアプリケーションシステムに所定の処理をさせるための命令書データを作成する命令書作成ステップと、
前記命令書作成ステップで作成された命令書データを出力する、及び／又は、前記帳票入力ステップで入力された帳票画像データと、当該命令書データとを対応させて記憶するステップと
を含む帳票処理方法。 - 前記記入枠検出ステップは、
入力された帳票画像データに対し横方向へのヒストグラムをとり、当該ヒストグラムに基づき行ごとの帳票画像データを検出する行検出ステップと、
検出された行ごとの帳票画像データについて、記入枠データと手書きデータを分離する分離ステップと、
分離された行ごとの記入枠データに対して縦方向へのヒストグラムをとり、当該ヒストグラムに基づき、ひとつ又は複数の記入枠データを検出するステップと、
検出された記入枠データに対し、横方向へのヒストグラムをとり、当該ヒストグラムに基づき、当該記入枠データの情報バーを検出するステップと
を含む請求項１乃至４のいずれかに記載の帳票処理方法。 - 前記記入枠検出ステップは、
連結している黒画素の連結成分に同じラベルをつけるラベリング処理、画像の収縮及び膨張を行うモルフォロジー、画像を平滑化する効果のあるメディアンフィルタのいずれかにより記入枠データと手書きデータを分離すること
を含む請求項１乃至５のいずれかに記載の帳票処理方法。 - 前記行検出ステップは、
当該ヒストグラムの値が予め定められた閾値以下の場合、その値を無視することによりノイズの影響を取り除くこと
を含む請求項５に記載の帳票処理方法。 - 前記記入枠検出ステップは、
入力された帳票画像データに対し、横方向のヒストグラム及び／又は縦方向のヒストグラムをとるステップと、
当該ヒストグラムの値が予め定められた閾値以下の場合、その値を無視することによりノイズの影響を取り除くステップと、
当該ヒストグラムを走査し、ヒストグラムの値が所定値以下から所定値以上になる位置、又は、所定値以上から所定値以下になる位置を検出するステップと、
検出された位置から、ヒストグラムを走査した方向と逆方向又は行若しくは列の外側の方向にヒストグラムの値を辿り、ヒストグラムの値がゼロ又は所定値以下になった位置、又は、検出された位置から辿った長さが予め定められた閾値を超えてもヒストグラムの値がゼロ又は所定値以下にならない場合には、検出された位置から走査した方向と逆方向又は行若しくは列の外側方向に当該閾値分だけずらした位置を記入枠の開始又は終了の位置とするステップと、
記入枠の縦方向の開始位置と終了位置、及び／又は、横方向の開始位置と終了位置に基づき、記入枠データを検出するステップと
を含む請求項１乃至５のいずれかに記載の帳票処理方法。 - 前記記入枠検出ステップは、
記入枠データのドットを膨張し、膨張した記入枠データに対してヒストグラムを求め、当該ヒストグラムに基づき各記入枠データ及び情報バーを検出することを含む請求項１乃至５のいずれかに記載の帳票処理方法。 - 前記重畳情報認識ステップは、
高さが同じで幅の異なるドットの列で構成された情報レコードが、複数の行に所定ドット数ずつずれて配置されている情報バーに対して、横方向及び／又は縦方向のヒストグラムをとり、当該ヒストグラムに基づき行ごとのドットを切り出すステップと、
切り出された行ごとのドットの縦方向のヒストグラムを取り、該ヒストグラムに従いドットの長短を測り、各ドットが示す情報を求めて情報レコードのデータを求めるステップと、
所定ドット数ずつの行のずらしを戻すステップと、
各情報レコードの値の多数決を取ることにより情報レコードのデータを決定するステップと
を含む請求項３又は４に記載の帳票処理方法。 - 前記重畳情報認識ステップは、
前記記入枠検出ステップで検出された情報バーのコードを切り出すコード切出ステップと、
切り出されたコードを認識するコード認識ステップと、
認識されたコードが先頭の区切り記号であるかを判断し、先頭の区切り記号を検索するステップと、
前記検索するステップで検索された先頭の区切り記号から、終端の区切り記号が認識されるまでのコードに基づき、所定の情報を含む情報レコードのデータを求めるステップと、
求められた情報レコードのデータの多数決を取ることにより、情報レコードのデータを決定するステップと、
を含む請求項３又は４に記載の帳票処理方法。 - 前記コード認識ステップは、
縦方向と、横方向と、右斜め方向と、左斜め方向との４方向のヒストグラムによりコードを認識する請求項１１に記載の帳票処理方法。 - 前記コード認識ステップは、
切り出されたコードに対して、予め定められた位置を順次走査することでコードを認識すること、又は、切り出されたコードの特徴値データを抽出し、予め記憶されている各コードの標準パタンの特徴値データとマッチングすることでコードを認識する請求項１１に記載の帳票処理方法。 - 前記重畳情報認識ステップは、
求められた各情報レコードの長さの多数決をとることにより、情報レコードの長さを決定するステップと、
各情報レコードの長さを求め、決定された長さと異なる情報レコード及び／又は長さが所定範囲に入っていない情報レコードを削除するステップと、
情報レコードのパリティ符号をチェックし、正しくない情報レコードを削除するステップと、
をさらに含み、
削除されていない情報レコードのデータを用いて多数決を取り、情報レコードのデータを決定する請求項１１に記載の帳票処理方法。 - 前記コード切出ステップは、
情報バーの左から右へ又は右から左へ列ごとのコードを切り出し、前の列と切り出した列の間隔が所定の幅より大きいときに、区切り記号が見つかるまでこの後のコード図形を無視すること
を含む請求項１１に記載の帳票処理方法。 - 入力された帳票画像データの横方向のヒストグラムに基づき、帳票画像データに含まれ、コードで構成される水平バーを検出するステップと、
検出された水平バーのコードの位置を検出し、該コードの位置に基づきコード間の距離を求めるステップと、
求められたコード間の距離に基づき、コードの大きさを求めるステップと
をさらに含み、
前記コード切出ステップは、
前記記入枠検出ステップで検出された情報バーのコードを切り出し、切り出されたコードの大きさが、求められた大きさより小さい場合はそのコードを無視し、一方、大きい場合は求められた大きさ又は予め定められた大きさで切り出されたコードを分離する請求項１１に記載の帳票処理方法。 - 入力された帳票画像データの横方向のヒストグラムに基づき、コードが情報バーと同じ行数だけ配置された水平バーを検出するステップと、
検出された水平バーのコード行数を求めるステップと
をさらに含み、
前記コード切出ステップは、
前記記入枠検出ステップで検出された情報バーのコードを切り出し、この列において切り出したコード数と走査した長さを求め、該コード数が求められた水平バーのコード行数に達しているか、及び／又は、走査した長さが水平バーのコード行数に応じた長さまで達しているか判断し、達していると判断された場合に切り出し処理を終了する請求項１１に記載の帳票処理方法。 - 前記文字認識ステップは、
前記重畳情報認識ステップで抽出された重畳情報が示す手書きデータの属性がメールアドレスである場合に、メールアドレスの文字種を限定するための文字種記入枠に記入された文字種情報を認識し、該文字種情報に従い文字認識を行う請求項３又は４に記載の帳票処理方法。 - 前記コードは、
定められた点を通る水平方向の線分、垂直方向の線分、及び、所定角度だけ傾斜した所定数の線分のいずれかで情報が表現される請求項１乃至４のいずれかに記載の帳票処理方法。 - 前記コードは、
定められた領域の中心を通る水平方向の線分と、垂直方向の線分と、所定角度だけ傾斜した６本の線分との８本の線分のいずれかで情報が表現される請求項１乃至４のいずれかに記載の帳票処理方法。 - 前記コードは、
ｎ角形の各辺と、当該ｎ角形の内部を通り傾斜の異なるｍ本の線分とを含み、各辺及び線分の有無により２の（ｎ＋ｍ）乗ビットの情報を表現する請求項１乃至４のいずれかに記載の帳票処理方法。 - 前記コードは、
４角形の各辺と、当該４角形の中心を通り傾斜の異なる４本の線分とを含み、各辺及び線分の有無により２の８乗ビットの情報を表現するコード、又は、８角形の各辺と、当該８角形の中心を通り傾斜の異なる４本の線分とを含み、各辺及び線分の有無により２の１２乗ビットの情報を表現するコードのいずれかで構成される請求項１乃至４のいずれかに記載の帳票処理方法。 - 線分の傾斜又は複数の線分の組み合わせで情報が表現されるコードで構成される記入枠データと、記入された手書きデータとを含む帳票画像データを入力する帳票入力ステップと、
前記帳票入力ステップで入力された帳票画像データに基づき、記入枠データと手書きデータを分離し、及び、各記入枠データと、コードにより所定の情報が重畳された当該記入枠データ内の情報バーとを検出する記入枠検出ステップと、
検出された情報バーの各コードを切り出すステップと、
切り出されたコードの、縦方向と、横方向と、右斜め方向と、左斜め方向との四方向のヒストグラムを求めるステップと、
求められた四方向のヒストグラムに基づき、コードの形状特徴を判断し、コードを認識するコード認識ステップと
をコンピュータに実行させるための帳票処理プログラム。 - ドットの幅又は線分の傾斜又は複数の線分の組み合わせで情報が表現されるコードで構成される記入枠データと、記入された手書きデータとを含む帳票画像データを入力する帳票入力ステップと、
前記帳票入力ステップで入力された帳票画像データに基づき、記入枠データと手書きデータを分離し、及び、各記入枠データと、コードにより所定の情報が重畳された当該記入枠データ内の情報バーとを検出する記入枠検出ステップと、
前記記入枠検出ステップで検出された情報バーの各コードを認識し重畳情報を抽出する重畳情報認識ステップと、
前記記入枠検出ステップで分離された手書きデータに対して、抽出された重畳情報が示す手書きデータの属性及び／又は文字種類に従い文字認識を行う文字認識ステップと、
前記文字認識ステップで認識された文字情報と、前記重畳情報認識ステップで抽出された重畳情報が示す情報とに基づき、他のアプリケーションシステムに所定の処理をさせるための命令書データを作成する命令書作成ステップと、
前記命令書作成ステップで作成された命令書データを出力する、及び／又は、前記帳票入力ステップで入力された帳票画像データと、当該命令書データとを対応させて記憶するステップと
をコンピュータに実行させるための帳票処理プログラム。 - 線分の傾斜又は複数の線分の組み合わせで情報が表現されるコードで構成される記入枠データと、記入された手書きデータとを含む帳票画像データを入力する帳票入力ステップと、
前記帳票入力ステップで入力された帳票画像データに基づき、記入枠データと手書きデータを分離し、及び、各記入枠データと、コードにより所定の情報が重畳された当該記入枠データ内の情報バーとを検出する記入枠検出ステップと、
検出された情報バーの各コードを切り出すステップと、
切り出されたコードの、縦方向と、横方向と、右斜め方向と、左斜め方向との四方向のヒストグラムを求めるステップと、
求められた四方向のヒストグラムに基づき、コードの形状特徴を判断し、コードを認識するコード認識ステップと
をコンピュータに実行させるための帳票処理プログラムを記録した記録媒体。 - ドットの幅又は線分の傾斜又は複数の線分の組み合わせで情報が表現されるコードで構成される記入枠データと、記入された手書きデータとを含む帳票画像データを入力する帳票入力ステップと、
前記帳票入力ステップで入力された帳票画像データに基づき、記入枠データと手書きデータを分離し、及び、各記入枠データと、コードにより所定の情報が重畳された当該記入枠データ内の情報バーとを検出する記入枠検出ステップと、
前記記入枠検出ステップで検出された情報バーの各コードを認識し重畳情報を抽出する重畳情報認識ステップと、
前記記入枠検出ステップで分離された手書きデータに対して、抽出された重畳情報が示す手書きデータの属性及び／又は文字種類に従い文字認識を行う文字認識ステップと、
前記文字認識ステップで認識された文字情報と、前記重畳情報認識ステップで抽出された重畳情報が示す情報とに基づき、他のアプリケーションシステムに所定の処理をさせるための命令書データを作成する命令書作成ステップと、
前記命令書作成ステップで作成された命令書データを出力する、及び／又は、前記帳票入力ステップで入力された帳票画像データと、当該命令書データとを対応させて記憶するステップと
をコンピュータに実行させるための帳票処理プログラムを記録した記録媒体。 - 線分の傾斜又は複数の線分の組み合わせで情報が表現されるコードで構成される記入枠データと、記入された手書きデータとを含む帳票画像データを入力するための帳票入力部と、
入力された帳票画像データの記入枠を検出し、及び、記入枠内のコードを認識する処理部と
を備え、
前記処理部は、
前記帳票入力部から入力された帳票画像データに基づき、記入枠データと手書きデータを分離し、及び、各記入枠データと、コードにより所定の情報が重畳された当該記入枠データ内の情報バーとを検出する記入枠検出手段と、
検出された情報バーの各コードを切り出す手段と、
切り出されたコードの、縦方向と、横方向と、右斜め方向と、左斜め方向との４方向のヒストグラムを求める手段と、
求められた４方向のヒストグラムに基づき、コードの形状特徴を判断してコードを認識するコード認識手段と
を有する帳票処理装置。 - ドットの幅又は線分の傾斜又は複数の線分の組み合わせで情報が表現されるコードで構成される記入枠データと、記入された手書きデータとを含む帳票画像データを入力するための帳票入力部と、
帳票画像データ及び／又は帳票画像データに基づき作成される命令書データが記憶される記憶部と、
入力された帳票画像データに記入された手書きの情報と、記入枠に重畳された情報を認識し、所定の処理を実行する処理部と、
を備え、
前記処理部は、
前記帳票入力部から入力された帳票画像データに基づき、記入枠データと手書きデータを分離し、及び、各記入枠データと、コードにより所定の情報が重畳された当該記入枠データ内の情報バーとを検出する記入枠検出手段と、
前記記入枠検出手段で検出された情報バーの各コードを認識し重畳情報を抽出する重畳情報認識手段と、
前記記入枠検出手段で分離された手書きデータに対して、抽出された重畳情報が示す手書きデータの属性及び／又は文字種類に従い文字認識を行う文字認識手段と、
前記文字認識手段で認識された文字情報と、前記重畳情報認識手段で抽出された重畳情報に基づき、他のアプリケーションシステムに所定の処理をさせるための命令書データを作成する命令書作成手段と、
前記命令書作成手段で作成された命令書データを出力する、及び／又は、前記入力する手段で入力された帳票画像データと、当該命令書データとを対応させて前記記憶部に記憶する手段と
を有する帳票処理装置。 - ドットの幅又は線分の傾斜又は複数の線分の組み合わせで情報が表現されるコードにより所定の情報が重畳された情報レコードが、複数の行に渡り配置される情報バーを有し、該コードにより構成される記入枠と、
前記コードより構成され、帳票又は前記情報バーに関する情報を含む水平バーと
を備える帳票。 - 前記コードは、高さが同じで幅の異なるドットであり、
情報が重畳された情報レコードが、複数の行に所定のドット数だけずれて配置される請求項２９に記載の帳票。 - 前記コードは、
定められた点を通る水平方向の線分、垂直方向の線分、及び、所定角度だけ傾斜した所定数の線分のいずれかで情報が表現される請求項２９に記載の帳票。 - 前記コードは、
定められた領域の中心を通る水平方向の線分と、垂直方向の線分と、所定角度だけ傾斜した６本の線分との８本の線分のいずれかで情報が表現される請求項２９に記載の帳票。 - 前記コードは、
ｎ角形の各辺と、当該ｎ角形の内部を通り傾斜の異なるｍ本の線分とを含み、各辺及び線分の有無により２の（ｎ＋ｍ）乗ビットの情報を表現する請求項２９に記載の帳票。 - 前記コードは、
４角形の各辺と、当該４角形の中心を通り傾斜の異なる４本の線分とを含み、各辺及び線分の有無により２の８乗ビットの情報を表現するコード、又は、８角形の各辺と、当該８角形の中心を通り傾斜の異なる４本の線分とを含み、各辺及び線分の有無により２の１２乗ビットの情報を表現するコードのいずれかで構成される請求項２９に記載の帳票。
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 |