JP2005208872A

JP2005208872A - 画像処理システム

Info

Publication number: JP2005208872A
Application number: JP2004013833A
Authority: JP
Inventors: Shigeo Fukuoka; 茂雄福岡
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2004-01-22
Filing date: 2004-01-22
Publication date: 2005-08-04

Abstract

【課題】ＭＦＰなどで読み取った画像データから、オリジナルの電子データを検索するシステムにおいて、電子データが存在しなかった場合に、再利用可能なデータ形式にスキャン画像を変換する。
【解決手段】読み込んだ画像内の文字のビットマップ画像からフォントデータを作成するときに、あらかじめユーザの所有フォントからマッチング辞書と埋め込み用データを作成しておく。文字認識の結果を使いフォント認識を行い、マッチした場合は作成済みのフォントデータを埋め込むことで、フォントデータへの変換処理を減らし処理の効率を良くする。
【選択図】図３３

Description

本願発明は、複写機などの画像処理装置で読み取った画像データを、Ｗｏｒｄ等の文書作成アプリケーションソフトで再利用可能なベクトルデータに変換する画像処理システムに関する。

近年、環境問題が叫ばれる中、オフィスでのペーパーレス化が急速に進んでいる。即ち、従来からバインダー等で蓄積された紙文書をスキャナーで読み取りポータブルドキュメントフォーマット（以降ＰＤＦと記す）に変換して画像記憶装置にデータベースとして蓄積し、文書管理システムを構築出来る。一方機能が拡張されたＭＦＰでは、予め画像を記録する際に、該画像ファイルが存在する画像記憶装置内のポインタ情報を該文書の表紙或いは記載情報中に付加情報として記録して置き、再度該文書を複写等再利用する際に、このポインタ情報からオリジナル電子ファイルの格納場所を検出し、該電子ファイルの元情報を直接用いる事で、紙文書全体の保存を削減する。このような技術は特許文献１、特許文献２等で開示されている。

しかしながら、前者は紙文書がコンパクトな情報量のＰＤＦファイルとして文書の保存が可能であるが、ファイル自体がイメージ情報であるので、該文書の一部のオブジェクトを再利用する事は出来ない。従って再利用する場合は、図、表等は新たにアプリケーションソフトを用いて再度作成しなければ成らない。又後者は自部門で作成した電子ファイルは直接元ファイルをアクセスできる為、容易に再利用出来るが、外部から入手した文書、あるいはオリジナルファイルの所在が不明な古い紙文書には対応が出来ない。

従って、本発明は上記従来例の欠点を解決するためいかなる紙文書に対しても再利用可能な電子ファイルとして扱える画像処理システムを提供する事を目的とする。
特開平１１−０８８６５９号公報特開平１１−２０５５５８号公報

本願出願人の過去の提案で、文字をベクトル化する場合、画像データとＯＣＲ結果の文字コードからベクトル化を行い、フォントデータを作成していた。しかし画像からフォントデータを作成する場合において、文字の大きさが小さい場合はＯＣＲを正しく行えるが、ベクトル化すると誤差が大きくなり正しくフォントデータが生成できない場合があった問題は、図３１に示すフローで処理することで解決できた。

『文字認識を行い、実ベクトルフォントへの置き換えを行う場合のベクトル化処理』
次に実ベクトルフォントから生成されたフォントデータを用いる場合を図３１で説明する。

登録フォント辞書は処理中の文書内でのみ有効な辞書であり、最初は空である。また登録フォント辞書の各文字は図３２のような形式で表現されている。

図３のステップ１２１で分割されたブロックからステップ１４０１により一つのブロックを取り出す処理を行う。ステップ１４０２はブロックが取り出せたかどうか判断し、取り出せた場合はステップ１４０３へ、取り出せなかった場合は全てのブロックの処理が終了したことになり終了する。ステップ１４０３は取り出されたブロックがテキストブロックであるかどうかを判断し、テキストブロックであればステップ１４０３へ、テキスト以外のブロックであればステップ１４１６へ処理を進める。ステップ１４０４は、１４０３で既に処理された当該ブロックのＯＣＲデータをすべて読出す。ステップ１４０５はステップ１４０４で処理されたＯＣＲデータから一つの文字矩形を取り出す処理を行う。ステップ１４０６は文字矩形が取り出されたかどうかの判断を行い、取り出せている場合はステップ１４０７へ、取り出せていない場合は、処理中のブロック内の文字が全て処理されたことになり、次のブロックへ処理を進めるためステップ１４０１へ処理を進める。ステップ１４０７は処理中の文字の文字コードを取り出す。ステップ１４０８はステップ１４０７で取り出された文字コードを用い、各実フォント辞書の同一文字コードのマッチング用特徴データを取り出し類似度を計算する。各文字種の類似度で一番良い値の類似度を、その文字のスコアとする。ここではスコアは大きいほどマッチング結果が良いことにする。ステップ１４０９はステップ１４０８で求められた文字のスコアとあらかじめ決めておいた定数Ｘを比較し、Ｘより大きければ、その文字が一番良い類似度を出した文字種であると決定しステップ１４１０へ、Ｘ以下であればステップ１４１１へ処理を進める。ステップ１４１０は、実フォント辞書からその文字コードのフォントデータを取り出しフォント変換結果とし、次の文字へ処理を進める。ステップ１４１１は、登録フォント辞書とのマッチングを行う。この辞書内には同じ文字コードのデータが複数現われるため、同一文字コードのマッチング用特徴データを取り出し類似度を計算し、一番良い値をその文字のスコアとして出す。ステップ１４１２はステップ１４１１で求められたスコアとあらかじめ決めておいた定数Ｙを比較し、Ｙより大きければ登録フォント辞書内の一番良い類似度の文字がとの文字と同一であるとしてステップ１４１３へ、Ｙ以下であればステップ１４１４へ処理を進める。ステップ１４１３は登録フォント辞書から該当文字のフォントデータを取り出しフォント変換結果とし、次の文字へ処理を進める。ステップ１４１４は、処理中の文字が新しく現われたフォントの文字であるということになるため、フォント変換処理を行う。ステップ１４１５は、ステップ１４０７で取得されたＯＣＲの文字コードと、ステップ１４１４で取得されたフォント変換結果と、１４０８内で取得されたフォントマッチング用の特徴データを使い、登録フォント辞書への文字の追加を行い、次の文字へ処理を進める。ステップ１４１６は文字以外のブロックのベクトル化処理であり、図３０のステップ１３０２と同じである。以上の処理を繰り返すことで画像内の全てのブロックがベクトル化できる。

実フォント辞書はユーザの所有する実際のベクトルフォントを利用し、各文字コードのベクトルデータを一定のサイズにレンダリングして画像データを作成し、その画像データからフォントマッチング用の文字の縦横比や重心位置、輪郭データのヒストグラムデータなどを抽出し特徴データとすることと、画像データから下記の『文字のベクトル化処理』を行うことであらかじめ作成しておく。形式は登録フォント辞書と同様であるが、同一コードのデータが複数含まれることはない。

ところが、ＯＣＲ結果の文字コードからベクトル化の処理を行うため、ＯＣＲの辞書にない文字は必ずベクトル化されることになっている。また誤認識している場合もベクトル化されることになる。

上記目的を達成するために、本発明は、原稿を読み取り走査する手段で得られたイメージ情報から、該原稿の電子ファイルを特定する特定手段を有し、該手段で上記イメージ情報に一致するオリジナルの電子ファイルが特定できれば、該電子ファイルを紙文書に記載された情報として扱い、前記特定手段で該原稿の電子ファイルが特定出来ない場合には、前記画像読み取り走査手段で得られるイメージ情報をベクトル化手段でベクトルデータに変換し、該変換されたベクトルデータを紙文書に記載された情報として変換するので、如何なる紙文書に対しても読み取ったイメージ情報を再利用可能な電子ファイルとして扱える。

また本発明は、原稿を読み取り走査する手段と、該手段で得られたイメージ情報から、該原稿の電子ファイルを特定する手段とを有し、前記特定手段で得られた該原稿の電子ファイルがイメージファイルやＰＤＦの様にオブジェクト単位で既存の文書作成ソフトウェアで扱えない場合にも前記画像読み取り走査手段で得られるイメージ情報をベクトル化手段でベクトルデータに変換する事を特徴とする為、イメージファイルに対しても再利用可能なベクトルデータに変換出来る。

請求項１記載の発明によれば、原稿を読み取り走査する手段で得られたイメージ情報から、該原稿の電子ファイルを特定する特定手段を有し、該手段で上記イメージ情報に一致するオリジナルの電子ファイルが特定できれば、該電子ファイルを紙文書に記載された情報として扱い、前記特定手段で該原稿の電子ファイルが特定出来ない場合には、前記画像読み取り走査手段で得られるイメージ情報をベクトル化手段でベクトルデータに変換し、該変換されたベクトルデータを紙文書に記載された情報として変換するので、如何なる紙文書に対しても読み取ったイメージ情報を再利用可能な電子ファイルとして扱える。

請求項２記載の発明によれば、電子ファイルを特定する手段が原稿に付加的に記録された電子ファイルの格納場所を示す付加情報を認識する手段であるのでイメージ情報から簡単にオリジナルの電子ファイルを特定出来る。

請求項３記載の発明によれば、電子ファイル特定手段が原稿中に記載された特定の情報を記憶手段で格納されたファイルの中から検索する手段を有し、検索の結果、特定情報の一致によって電子ファイルを特定する事で、付加情報が記録されていない文書に対しても容易にオリジナルの電子ファイルを特定出来る。

請求項４記載の発明によれば、ベクトル化手段は原稿中の文字領域を光学的文字認識するＯＣＲ手段によって文字部分を文字フォントデータにベクトル化するので文字部は高品位な画質でありデータ量も少なくてすむ。

請求項５記載の発明によれば、ベクトル化手段は原稿を複数のオブジェクトに分割し、各オブジェクトに対して独立にベクトル化する事を特徴とする為、ベクトル化されたオブジェクトは独立に扱う事が出来る。

請求項６記載の発明によれば、ベクトル化手段はベクトル化されたオブジェクトを既存の文書作成ソフトウェアで扱える例えばｒｔｆフォーマットに変換するので、ベクトル化したオブジェクトを既存の文書作成アプリソフト上で再利用出来る。

請求項７記載の発明によれば、ベクトル化手段でベクトル化されたベクトルデータを記憶する画像記憶手段と、該ベクトルデータに該データを格納する格納場所を付加情報として付加する情報付加手段を備えるので、該文書を再度原稿として画像読み取り手段で読み取った際には、この付加情報から電子ファイルを特定する事が可能になるのでより短時間にファイルを特定出来る。

請求項８記載の発明によれば、ファイル特定手段は、ポインタ情報から得られる該原稿の電子ファイルから、原稿中に記載された特定の情報が検索して得られる場合に限って該電子ファイルに特定する事を特徴とするので、単にポインタ情報から特定する場合に対してより確度の高い特定が可能に成る。

請求項９記載の発明によれば、原稿を読み取り走査する手段と、該手段で得られたイメージ情報から、該原稿の電子ファイルを特定する手段とを有し、前記特定手段で得られた該原稿の電子ファイルがイメージファイルやＰＤＦの様にオブジェクト単位で既存の文書作成ソフトウェアで扱えない場合にも前記画像読み取り走査手段で得られるイメージ情報をベクトル化手段でベクトルデータに変換する事を特徴とする為、イメージファイルに対しても再利用可能なベクトルデータに変換出来る。

請求項１０記載の発明によれば、ベクトル化手段は原稿を読み取り走査して得られるイメージ情報をオブジェクト毎に分割する手段と、該分割されたオブジェクト単位で記憶手段で格納されたファイルの中から一致するオブジェクトを検索する手段を有し、該検索手段で得られた情報を用いてベクトル化する事を特徴とする為、全てのオブジェクトに対するベクトル化が不要になり、処理の高速化、及び、高画質化が図られる。

請求項１１記載の発明によれば、分割されたオブジェクト単位で、そのオブジェクト種別毎に使用者が設定したベクトル化処理が行えるため、その使用者にとって必要のないベクトル化の処理を省略することができ、処理の高速化が図られる。

請求項１２記載の発明によれば、使用者が文字認識結果の文字コードを必要としていないが、文字はベクトル化を行いたい場合に無駄な文字認識処理を行わないで文字部を効率よくベクトル化することが可能となり、処理の高速化が図られる。

請求項１３記載の発明によれば、第１項記載の画像処理システムにおいて、該ＯＣＲ結果より文字矩形情報を出現順に呼び出す手段と、注目している文字矩形の文字コードを呼び出す手段と、文字コードを既に出現している文字コードと比較する手段と、比較手段の結果によりフォント変換、あるいは認識を行う手段と、フォント変換あるいは認識結果を文字コードと共に記憶する手段、とを有することを特徴とする為、負荷の大きいフォント変換、あるいは認識処理を１文字単位で行う必要は無くなり、大幅な処理速度の向上が期待される。

請求項１４記載の発明によれば、第１項記載の画像処理システムにおいて、フォント種別の特徴辞書を有し、該ＯＣＲ結果より文字矩形情報を出現順に呼び出す手段と、注目している文字矩形の文字コードを呼び出す手段と、文字矩形から文字画像を取り出し、フォント種別識別用の特徴抽出を行い各フォント種別辞書の同一文字コードの特徴と比較しフォント種別を決定する手段と、フォント種別決定手段によりあらかじめ作成しておいたフォントデータをフォント変換の結果とし、フォント変換あるいは認識結果を文字コードと共に記憶する手段とを有することを特徴とする。このため実ベクトルフォントから作成されたフォントデータが利用されるため大幅な画質の向上が見込まれる。また負荷の大きいフォント変換処理が減ることにもなり、大幅な処理速度の向上が期待される。

請求項１５記載の発明は、請求項１４記載の発明において、フォントの識別が出来なかった文字の前後のフォント種別より該文字のフォントを推定する手段と、推定されたフォントから作成したフォント識別用の辞書を使い再度の文字認識処理を行う手段と、文字認識結果の類似度により本来の文字認識結果を置き換える手段と有することを特徴とする。これにより原稿中に文字認識の候補とならない文字が含まれていた場合、従来は常にフォント変換処理が行われるだけではなく、間違った文字コードが文字認識結果となってしまっていたが、実フォントから作成された辞書を使い再度文字認識を行うことで文字コードを特定することができた場合は、正しい文字コードと実フォントから生成されたフォントデータが使用できるようになるため、さらなる画質の向上と文字コードの正しさが期待できる。

以下、本願を実施するのに好適な例を図面を用いて説明する。

本願発明の実施の形態について説明する。図１は本願発明にかかる画像処理システム構成例を示すブロック図である。この画像処理システムは、オフィス１０とオフィス２０とをインターネット１０４で接続された環境で実現する。オフィス１０内に構築されたＬＡＮ１０７には、ＭＦＰ１００、ＭＦＰ１００を制御するマネージメントＰＣ１０１、クライアントＰＣ（外部記憶手段）１０２、文書管理サーバ１０６、そのデータベース１０５、およびプロキシサーバ１０３が接続されている。ＬＡＮ１０７及びオフィス２０内のＬＡＮ１０８はプロキシサーバ１３を介してインターネット１０４に接続される。ＭＦＰ１００は本発明において紙文書の画像読み取り部と読み取った画像信号に対する画像処理の１部を担当し、画像信号はＬＡＮ１０９を用いてマネージメントＰＣ１０１に入力する。マネージメントＰＣは通常のＰＣであり、内部に画像記憶手段、画像処理手段、表示手段、入力手段を有するが、その一部をＭＦＰ１００に一体化して構成されている。

図２はＭＦＰ１００の構成図である。図２においてオートドキュメントフィーダー（以降ＡＤＦと記す）を含む画像読み取り部１１０は束状の或いは１枚の原稿画像を図示しない光源で照射し、原稿反射像をレンズで固体撮像素子上に結像し、固体撮像素子からラスター状の画像読み取り信号を６００ＤＰＩの密度のイメージ情報として得る。通常の複写機能はこの画像信号をデータ処理部１１５で記録信号へ画像処理し、複数毎複写の場合は記録装置１１１に一旦１ページ分の記録データを記憶保持した後、記録装置１１２に順次出力して紙上に画像を形成する。

一方クライアントＰＣ１０２から出力されるプリントデータはＬＡＮ１０７からネットワークＩＦ１１４を経てデータ処理装置１１５で記録可能なラスターデータに変換した後、前記記録装置で紙上に記録画像として形成される。

ＭＦＰ１００への操作者の指示はＭＦＰに装備されたキー操作部とマネージメントＰＣに入力されるキーボード、及び、マウスからなる入力装置１１３から行われ、これら一連の動作はデータ処理装置１１５内の図示しない制御部で制御される。

一方、操作入力の状態表示及び処理中の画像データの表示は表示装置１１６で行われる。尚記憶装置１１１はマネージメントＰＣからも制御され、これらＭＦＰとマネージメントＰＣとのデータの授受及び制御はネットワークＩＦ１１７および直結したＬＡＮ１０９を用いて行われる。

（処理概要）
次に本発明による画像処理全体の概要を図３を用いて説明する。

図３においてまず、ＭＦＰ１００の画像読み取り部１１０を動作させ１枚の原稿をラスター状に走査し、イメージ情報入力処理１２０で６００ＤＰＩ−８ビットの画像信号を得る。該画像信号をデータ処理部１１５で前処理を施し記憶装置１１１に１ページ分の画像データとして保存する。マネージメントＰＣ１０１のＣＰＵは該格納された画像信号から先ず、文字／線画部分とハーフトーンの画像部分とに領域を分離し、文字部は更に段落で塊として纏まっているブロック毎に、或いは線で構成された表、図形に分離し各々セグメント化する。一方ハーフトーンで表現される画像部分は、矩形に分離されたブロックの画像部分、背景部等、所謂ブロック毎に独立したオブジェクトに分割する（ステップ１２１）。

このとき原稿画像中に付加情報として記録された２次元バーコード、或いはＵＲＬに該当するオブジェクトを検出しＵＲＬはＯＣＲで文字認識し、或いは２次元バーコードなら該マークを解読して（ステップ１２２）該原稿のオリジナル電子ファイルが格納されている記憶装置内のポインタ情報を検出する（ステップ１２３）。尚、ポインタ情報を付加する手段は他に文字と文字の間隔に情報を埋め込む方法、ハーフトーンの画像に埋め込む方法等直接可視化されない所謂電子透かしによる方法も有る。

ポインタ情報が検出された場合、ステップ１２５に分岐し、ポインタで示されたアドレスから元の電子ファイルを検索する。電子ファイルは図１においてクライアントＰＣ内のハードディスク内、或いはオフィス１０或いは２０のＬＡＮに接続された文書管理サーバ１０５内のデータベース１０５内、或いはＭＦＰ１００自体が有する記憶装置１１１のいずれかに格納されており、ステップ１２３で得られたアドレス情報に従ってこれらの記憶装置内を検索する。ステップ１２５で電子ファイルが見つからなかった場合、見つかったがＰＤＦあるいはｔｉｆｆに代表される所謂イメージファイルであった場合、或いはポインタ情報自体が存在しなかった場合はステップ１２６に分岐する。

ステップ１２６は所謂文書検索処理ルーチンである。まずステップ１２２で各文字ブロックに対して行ったＯＣＲの結果から単語を抽出して全文検索、或いは各オブジェクトの配列と各オブジェクトの属性から所謂レイアウト検索を行う。検索の結果、類似度の高い電子ファイルが見つかった場合、サムネイル等を表示（ステップ１２７）し、複数の中から操作者の選択が必要なら操作者の入力操作よってファイルの特定を行う。尚、候補が１ファイルの場合、自動的にステップ１２８からステップ１３４に分岐し、格納アドレスを通知する。ステップ１２６の検索処理で電子ファイルが見つからなかった場合、或いは、見つかったがＰＤＦあるいはｔｉｆｆに代表される所謂イメージファイルであった場合、ステップ１２９に分岐する。

ステップ１２９は、ラスターイメージデータからベクトルデータへの変換処理部であり、オリジナル電子ファイルに近く、編集容易でかつ容量の小さい電子ファイルに変換する。詳細は下記（ベクトル化処理）で説明する。

以上説明したステップ１２９のベクトル化処理を各ブロックに対して行った後、更に文書のレイアウト情報を活用して例えば、ｒｔｆに変換（ステップ１２１０）して電子ファイルとして記憶装置１１１に格納（ステップ１２１１）する。

今ベクトル化した原稿画像は以降同様の処理を行う際に直接電子ファイルとして検索出来るように、先ずステップ１３２において検索の為のインデックス情報を生成して検索用インデックスファイルに追加する。更に、ステップ１３６で今、操作者が行いたい処理が記録であると判断されれば、ステップ１３３に分岐し、ポインタ情報をイメージデータとしてファイルに付加する。

検索処理で電子ファイルが特定できた場合も同様に以降からは直接電子ファイルを特定する為にステップ１２８からステップ１３４に分岐し、格納アドレスを操作者に通知すると共に、今紙に記録する場合は、同様にポインタ情報を電子ファイルに付加する。尚、ステップ１２５でポインタ情報から電子ファイルが特定できた場合、検索処理で電子ファイルが特定出来た場合、ベクトル化により電子ファイルに変換した場合、ステップ１３４において、該電子ファイルの格納アドレスを操作者に通知する。

尚、以上本発明によって得られた電子ファイル自体を用いて、例えば文書の加工、蓄積、伝送、記録をステップ１３５で行う事が可能になる。これらの処理はイメージデータを用いる場合に比べて、情報量が削減され、蓄積効率が高まり、伝送時間が短縮され、又記録表示する際には高品位なデータとして非常に優位となる。

以下各処理ブロックに対して詳細に説明する。

先ずステップ１２１で示すブロックセレクション処理について説明する。

（ブロックセレクション処理）
ブロックセレクション処理とは、図４の右に示すステップ１２０で読み取った一頁のイメージデータを左に示す様に、各オブジェクト毎の塊として認識し、該ブロック各々を文字／図画／写真／線／表等の属性に判定し、異なる属性を持つ領域に分割する処理である。

ブロックセレクション処理の実施例を以下に説明する。先ず、入力画像を白黒に二値化し、輪郭線追跡をおこなって黒画素輪郭で囲まれる画素の塊を抽出する。面積の大きい黒画素の塊については、内部にある白画素に対しても輪郭線追跡をおこない白画素の塊を抽出、さらに一定面積以上の白画素の塊の内部からは再帰的に黒画素の塊を抽出する。

このようにして得られた黒画素の塊を、大きさおよび形状で分類し、異なる属性を持つ領域へ分類していく。たとえば、縦横比が１に近く、大きさが一定の範囲のものを文字相当の画素塊とし、さらに近接する文字が整列良くグループ化可能な部分を文字領域、扁平な画素塊を線領域、一定大きさ以上でかつ四角系の白画素塊を整列よく内包する黒画素塊の占める範囲を表領域、不定形の画素塊が散在している領域を写真領域、それ以外の任意形状の画素塊を図画領域、などとする。

ブロックセレクション処理で得られた各ブロックに対するブロック情報を図５に示す。

これらのブロック毎の情報は以降に説明するベクトル化、或いは検索の為の情報として用いる。

（ポインタ情報の検出）
次に、ステップ１２２で示すファイルの格納位置をイメージ情報から抽出する為のＯＣＲ／ＯＭＲ処理について説明する。

図６は原稿画像中に付加された２次元バーコード（ＱＲコードシンボル）を復号して、データ文字列を出力する過程を示すフローチャートである。２次元バーコードの付加された原稿３１０の一例を図７に示す。

まず、データ処理装置１１５内のページメモリに格納された原稿３１０を表すイメージ画像をＣＰＵ（不図示）で走査して、先に説明したブロックセレクション処理の結果から所定の２次元バーコードシンボル３１１の位置を検出する。ＱＲコードの位置検出パターンは、シンボルの４隅のうちの３済みに配置される同一の位置検出要素パターンから構成される（ステップ３００）。

次に、位置検出パターンに隣接する形式情報を復元し、シンボルに適用されている誤り訂正レベルおよびマスクパターンを得る（ステップ３０１）。

シンボルの型番を決定した（ステップ３０２）後、形式情報で得られたマスクパターンを使って符号化領域ビットパターンをＸＯＲ演算することによってマスク処理を解除する（ステップ３０３）。

尚、モデルに対応する配置規則に従い、シンボルキャラクタを読取り、メッセージのデータ及び誤り訂正コード語を復元する（ステップ３０４）。

復元されたコード上に、誤りがあるかどうかの検出を行い（ステップ３０５）、誤りが検出された場合、ステップ３０６に分岐し、これを訂正する。

誤り訂正されたデータより、モード指示子および文字数指示子に基づいて、データコード語をセグメントに分割する（ステップ３０７）。

最後に、仕様モードに基づいてデータ文字を復号し、結果を出力する（ステップ３０８）。

尚、２次元バーコード内に組み込まれたデータは、対応するファイルのアドレス情報を表しており、例えばファイルサーバ名およびファイル名からなるパス情報で構成される。或いは、対応するファイルへのＵＲＬで構成される。

本実施例ではポインタ情報が２次元バーコードを用いて付与された原稿３１０について説明したが、直接文字列でポインタ情報が記録される場合は所定のルールに従った文字列のブロックを先のブロックセレクション処理で検出し、該、ポインタ情報を示す文字列の各文字を文字認識する事で、直接元ファイルのアドレス情報を得る事が可能である。

また或いは、図７の文書３１０の文字ブロック３１２、或いはテキスト領域３１３内の文字列に対して隣接する文字と文字の間隔等に視認し難い程度の変調を加え、該文字間隔に情報を埋め込むことでもポインタ情報を付与できる。該所謂透かし情報は、後述する文字認識処理を行う際に各文字の間隔を検出すれば、ポインタ情報が得られる。又画像領域３１４の画像中に電子透かしとしてポインタ情報を付加する事も可能である。

（ポインタ情報によるファイル検索）
次に、図３で先に説明したステップ１２５およびステップ１２８で示す、ポインタ情報からの電子ファイルの検索について図８のフローチャートを使用して説明する。まず、ポインタ情報に含まれるアドレスに基づいて，ファイルサーバを特定する（ステップ４００）。

ここでファイルサーバとは、クライアントＰＣ１０２や、データベース１０５を内蔵する文書管理サーバ１０６や、記憶装置１１１を内蔵するＭＦＰ１００自身を指す。

ここでアドレスとは、ＵＲＬや、サーバ名とファイル名からなるパス情報である。

ファイルサーバが特定できたら、ファイルサーバに対してアドレスを転送する（ステップ４０１）。ファイルサーバは，アドレスを受信すると，該当するファイルを検索する（ステップ４０２）。ファイルが存在しない場合（ステップ４０３−Ｎ）には、ＭＦＰに対してその旨通知する。

ファイルが存在した場合（ステップ４０３−Ｙ）には、図３で説明した様に、ファイルのアドレスを通知（ステップ１３４）すると共に、ユーザの希望する処理が画像ファイルデータの取得であれば、ＭＦＰに対してファイルを転送する（ステップ４０８）。

（ファイル検索処理）
次に、図３のステップ１２６で示すファイル検索処理の詳細について図５、図１０を使用して説明を行う。

ステップ１２６の処理は、前述したように、ステップ１２４で入力原稿（入力ファイル）にポインタ情報が存在しなかった場合、または、ポインタ情報は在るが電子ファイルが見つからなかった場合、或いは電子ファイルがイメージファイルであった場合に行われる。

ここでは、ステップ１２２の結果、抽出された各ブロック及び入力ファイルが、図５に示す情報（ブロック情報、入力ファイル情報）を備えるものとする。情報内容として、属性、座標位置、幅と高さのサイズ、ＯＣＲ情報有無を例としてあげる。属性は、文字、線、写真、絵、表その他に分類する。また簡単に説明を行うため、ブロックは座標Ｘの小さい順、即ち（例、Ｘ１＜Ｘ２＜Ｘ３＜Ｘ４＜Ｘ５＜Ｘ６）にブロック１、ブロック２、ブロック３、ブロック４、ブロック５、ブロック６と名前をつけている。ブロック総数は、入力ファイル中の全ブロック数であり、図１０の場合は、ブロック総数は６である。以下、これらの情報を使用して、データベース内から、入力ファイルに類似したファイルのレイアウト検索を行うフローチャートを図１０に示す。ここで、データベースファイルは、図５と同様の情報を備えることを前提とする。

フローチャートの流れは、入力ファイルとデータベース中のファイルを順次比較するものである。まず、ステップ５１０にて、後述する類似率などの初期化を行う。次に、ステップ５１１にてブロック総数の比較を行い、ここで、真の場合、さらにファイル内のブロックの情報を順次比較する。ブロックの情報比較では、ステップ５１３，５１５，５１８にて、属性類似率、サイズ類似率、ＯＣＲ類似率をそれぞれ算出し、ステップ５２２にてそれらをもとに総合類似率を算出する。各類似率の算出方法については、公知の技術が用いられるので説明を省略する。ステップ５２３にて総合類似率が、予め設定された閾値Ｔｈより高ければステップ５２４にてそのファイルを類似候補としてあげる。但し、図中のＮ、Ｗ、Ｈは、入力ファイルのブロック総数、各ブロック幅、各ブロック高さとし、ΔＮ、ΔＷ、ΔＨは、入力ファイルのブロック情報を基準として誤差を考慮したものである。ｎ、ｗ、ｈは、データベースファイルのブロック総数、各ブロック幅、各ブロック高さとする。また、不図示ではあるが、ステップ５１４にてサイズ比較時に、位置情報ＸＹの比較などを行ってもよい。

以上、検索の結果、類似度が閾値Ｔｈより高く、候補として保存されたデータベースファイル（ステップ５２４）をサムネイル等で表示（ステップ１２７）する。複数の中から操作者の選択が必要なら操作者の入力操作よってファイルの特定を行う。

（ベクトル化処理）
ファイルサーバに元ファイルが存在しない場合は、図４に示すイメージデータを各ブロック毎にベクトル化する。次に、ステップ１２９で示されるベクトル化について詳説する。

『ベクトル化処理設定のユーザーインターフェース』
オブジェクトの種別ごとに処理方法を設定するユーザーインターフェースを用い、ユーザの設定に応じたベクトル化処理を行う。

例えば、文字領域のブロックは、図２０のように「ベクトルデータ」、「二値画像」、「多値画像」の排他設定と「ＯＣＲ情報付加」のＯｎ／Ｏｆｆ設定を行うことができる。また「ベクトルデータ」の場合は、実ベクトルフォントへを使用するかどうかの設定を行う。

文字以外のブロックで線画領域のブロックや線のブロックは図２１、図２２に示すように「ベクトルデータ」、「画像」、「背景オブジェクトに含める」の排他設定できる。

表領域のブロックは、図２３に示すように「ベクトルデータ」、「二値画像」、「多値画像」、「背景オブジェクトに含める」の排他設定と「ＯＣＲ情報付加」のＯｎ／Ｏｆｆ設定を行うことができる。ただし背景オブジェクトに含める場合は、「ＯＣＲ情報付加」は常にＯｆｆとなる。

写真などの画像領域は、図２４に示すように「ベクトルデータ」、「画像」、「背景オブジェクトに含める」の排他設定できるようにしておく。

これらの設定は、ハードディスクなどの電源を切っても保持される領域に書き込んでおき、システムの起動時にはハードディスクなどから読み出し、自動的に設定する。

文字領域は、文字領域をどのように処理するかの設定を読み出し、設定にしたがって処理する。例えば、設定が「二値画像」又は「多値画像」でかつ「ＯＣＲ情報を付加する」がＯｆｆの場合、『文字認識』処理は行わず、画像データをベクトル化処理の結果とする。「二値画像」又は「多値画像」でかつ「ＯＣＲ情報を付加する」がＯｎの場合、『文字認識』処理を行い、認識結果の文字コード、文字の大きさ、位置と画像データをベクトル化結果とする。設定が「ベクトルデータ」、「ＯＣＲ情報を付加する」がＯｎ、「実ベクトルフォントを使用する」がＯｆｆの設定の場合、『文字認識を行い、実ベクトルフォントへの置き換えを行わない場合のベクトル化処理』のフローでベクトル化の処理が行われる。設定が「ベクトルデータ」、「ＯＣＲ情報を付加する」がＯｎ、「実ベクトルフォントを使用する」がＯｎの設定の場合、『文字認識を行い、実ベクトルフォントへの置き換えを行う場合のベクトル化処理』のフローでベクトル化の処理が行われる。設定が「ベクトルデータ」でかつ「ＯＣＲ情報を付加する」がＯｆｆの場合は、下記の『文字認識を行わない場合の文字のベクトル化』処理で文字をベクトルデータへ変換しベクトル化の結果とする。

『文字認識を行い、実ベクトルフォントへの置き換えを行わない場合のベクトル化処理』
図３のステップ１２１で分割されたブロックのうち、先頭（左上原点）に位置するブロックを入力し（ステップ１３００）、当該ブロックがテキストブロックの場合は、ステップ１２０２で既に処理された当該ブロックのＯＣＲデータをすべて読出し（ステップ１３０３）、先頭（左上原点）に位置する文字矩形に制御を移す（ステップ１３０４）。次に該当する文字矩形が存在することを確認し（ステップ１３０５）、文字矩形が存在する場合は、当該文字矩形に対応する文字コードを読出し（ステップ１３０６）、その結果、該当する文字矩形内の文字コードが既に変換済か否かを判別し（ステップ１３０７）、変換済であれば、次の文字矩形に制御を移行し（ステップ１３０８）、そうでなければ、すなわち過去に現れていない文字コードだった場合は、フォント認識／変換を行い、フォントデータの登録を行い（ステップ１３０９）、次の文字矩形に制御を移行する（ステップ１３０８）。ステップ１３０５では文字矩形がもはや存在しないと判定された場合、すなわち当該テキストブロック内の文字矩形全てに対して上記処理が終了した場合は、次のブロックに制御を移行させる（ステップ１３１０）。

一方ステップ１３０１で当該ブロックがテキストブロックでは無いと判断された場合は、所定のベクトル化処理を行い（ステップ１３０２）、次のブロックに制御を移行する（ステップ１３１０）。

ステップ１３１１では、該当するブロックの存在を確認し、まだ存在している場合は再び当該ブロックがテキストブロックか否かを判定する（ステップ１３０１）。そうでない場合はすべてのブロックの処理を終了したと判断し、処理を終了させる。

このような処理を行うことにより、文字矩形毎に必要であった処理の重いフォント認識／変換を最小限に抑え、効率よくベクトル化を行うことが出来る。

『文字認識を行い、実ベクトルフォントへの置き換えを行う場合のベクトル化処理』
次に実ベクトルフォントから生成されたフォントデータを用いる場合を図３３で説明する。

図３のステップ１２１で分割されたブロックからステップ１６０１により一つのブロックを取り出す処理を行う。ステップ１６０２はブロックが取り出せたかどうか判断し、取り出せた場合はステップ１６０３へ、取り出せなかった場合は全てのブロックの処理が終了したことになり終了する。ステップ１６０３は取り出されたブロックがテキストブロックであるかどうかを判断し、テキストブロックであればステップ１６０４へ、テキスト以外のブロックであればステップ１６２２へ処理を進める。ステップ１６０４は、１６０３で既に処理された当該ブロックのＯＣＲデータをすべて読出す。ステップ１６０５はステップ１６０４で処理されたＯＣＲデータから一つの文字矩形を取り出す処理を行う。ステップ１６０６は文字矩形が取り出されたかどうかの判断を行い、取り出せている場合はステップ１６０７へ、取り出せていない場合は、処理中のブロック内の文字が全て処理されたことになり、保留した文字を処理するためにステップ１６１５へ処理を進める。ステップ１６０７は処理中の文字の文字コードを取り出す。ステップ１６０８はステップ１６０７で取り出された文字コードを用い、各実フォント辞書の同一文字コードのマッチング用特徴データを取り出し類似度を計算する。各文字種の類似度で一番良い値の類似度を、その文字のスコアとする。ここではスコアは大きいほどマッチング結果が良いことにする。ステップ１６０９はステップ１６０８で求められた文字のスコアとあらかじめ決めておいた定数Ｘを比較し、Ｘより大きければ、その文字が一番良い類似度を出した文字種であると決定しステップ１６１０へ、Ｘ以下であればステップ１６１１へ処理を進める。ステップ１６１０は、実フォント辞書からその文字コードのフォントデータを取り出しフォント変換結果とし、次の文字へ処理を進める。ステップ１６１１は、登録フォント辞書とのマッチングを行う。この辞書内には同じ文字コードのデータが複数現われるため、同一文字コードのマッチング用特徴データを取り出し類似度を計算し、一番良い値をその文字のスコアとして出す。ステップ１６１２はステップ１６１１で求められたスコアとあらかじめ決めておいた定数Ｙを比較し、Ｙより大きければ登録フォント辞書内の一番良い類似度の文字がとの文字と同一であるとしてステップ１６１３へ、Ｙ以下であればステップ１６１４へ処理を進める。ステップ１６１３は登録フォント辞書から該当文字のフォントデータを取り出しフォント変換結果とし、次の文字へ処理を進める。ステップ１６１４は、処理中の文字が新しく現われたフォントの文字であったり、ＯＣＲで誤認識している文字であったり、ＯＣＲ結果の候補として現われない文字である可能性があるため処理中の文字を保留文字リストに追加する。ステップ１６１５は、保留文字リストから一文字を取り出す処理を行う。ステップ１６１６は、文字が取り出せかどうかの判定を行い、取り出せた場合は、ステップ１６１７へ、取り出せない場合は、全ての文字の処理が終了したことになり、次のブロックを処理するためステップ１６０１へ処理を進める。ステップ１６１７は、再文字認識を行う。ここでは、処理中の文字の前後（一文字ではなく、例えば後ろの文字が保留中であった場合は、その後の文字、さらに保留であればその後の文字と調べる）の文字のフォント種別を調べる。前後とも同一フォントであれば、そのフォント種のフォント識別辞書と全ての文字コードのマッチングを行う。前後で異なる場合は、両方のフォントとマッチングを行いよい類似度の方を採用する。また前後が登録フォントであった場合は、マッチングは行わないで類似度は０とする。ステップ１６１８はステップ１６０７で求められた文字の類似度とあらかじめ決めておいた定数Ｚを比較し、Ｚより大きければ、その文字が使用した実フォント辞書の一番良い類似度を出した文字コードの文字であると決定しステップ１６１９へ、Ｚ以下であればステップ１６２１へ処理を進める。ステップ１６１９は、ステップ１６１８の結果よりＯＣＲ結果を修正する。ステップ１６２０は、ステップ１６１０と同様の処理であり、終了後次の保留文字の処理を行う。ステップ１６２１は、処理中の文字が新しく現われたフォントの文字であるということになるため、フォント変換処理を行う。ステップ１６２２は、ステップ１６０７で取得されたＯＣＲの文字コードと、ステップ１６２１で取得されたフォント変換結果と、１６０８内で取得されたフォントマッチング用の特徴データを使い、登録フォント辞書への文字の追加を行い、次の文字へ処理を進める。ステップ１６２３は文字以外のブロックのベクトル化処理であり、図３０のステップ１３０２と同じである。以上の処理を繰り返すことで画像内の全てのブロックがベクトル化できる。

『文字認識を行わない場合の文字領域のベクトル化』
一つの原稿の処理開始時は空の辞書を用意する。ある文字ブロックのベクトル化を行う場合、文字ブロックから一文字取り出し文字の特徴抽出を行う。抽出された特徴と辞書とのマッチングを行い、マッチする文字が存在すれば辞書内の文字を参照する中間データを作成する。マッチしなかった場合は、文字の特徴抽出結果を辞書に登録し、登録した文字を参照する中間データを作成する。中間データは文字の画像内での位置と大きさと、辞書内の何番目の文字とマッチしているか表すもので構成され、例えば図２８のような構成である。ｘは文字矩形の左上のｘ座標値、ｙは文字矩形の左上のｙ座標値、ｗは文字矩形の幅のピクセル値、ｈは文字矩形の高さのピクセル値、ｎは辞書のｎ番目の文字とマッチしていることを意味する。一つの文字ブロックの処理が終了すると新たに登録された文字のベクトルデータへの変換処理を行い、中間データと文字のベクトルデータを合成することでその文字ブロックのベクトル化結果とする。原稿内の文字の処理が全て終了したら、辞書は削除する。

図２７は一つの文字ブロックの処理を表す図である。

処理開始時の辞書の登録文字数をＮｖ、処理中の辞書の登録文字数をＮで表すことにすると、開始時はＮｖ＝Ｎである。

１２０１の一文字抽出部は、入力された文字ブロックの画像データから一文字の領域を切り出す、文字切り出しの処理を行う。

１２０２は、１２０１の結果文字が抽出できたかどうか判断し、抽出できていれば１２０３へ、出来ていなければ１２０８へ処理を進める。

１２０３は、文字の特徴抽出を行う。文字の特徴とは、縦横比、重心位置、ＯＣＲで使われる輪郭データのヒストグラムベクトルなどである。

１２０４は、１２０３で抽出された文字の特徴と辞書に登録された文字のマッチングを行う。まず辞書の先頭の文字から縦横比と重心位置を比較し大きく異なっている文字は明らかに異なる文字であるため他の情報を使って比較することなく次の辞書中の文字へ比較対象を変更する。縦横比がほぼ等しい場合は、輪郭データのヒストグラムベクトルの比較を行う。ここでは通常のベクトル間の距離を計算し近ければ近いほどマッチングしていることになる。ここで距離があらかじめ決めておいた一定の値以下のものを候補文字としてピックアップしておく。このように辞書内の全ての文字とのマッチングを行う。

１２０５は１２０４の結果マッチした文字があるかどうか判定し、文字があれば１２０７へ、なければ１２０６へ処理を進める。

１２０６は、処理中の文字の特徴データを辞書へ登録する。辞書は図２９のような形式であり、辞書の最後に追加する。ここでＮ＝Ｎ＋１として辞書の文字数を増やす。

１２０７は、図２８のような形式のベクトル化の中間データを生成する。

１２０８は、文字ブロック内の全ての文字が辞書とのマッチング処理が終了すると行われる。開始時はＮｖ文字辞書にあり、終了時がＮとなっているため、Ｎ−Ｎｖ文字分の文字のベクトル化処理を行う。中間データＩＤが１０となっている場合、その文字は、中間データの１０番目の文字から特徴を抽出されたことを意味する。画像からベクトル化を行う時は中間データの１０番目の情報から画像中の文字の位置や大きさを取り出すことで、一文字の文字画像得る。

１２０９は、中間データと辞書に登録されている各文字のベクトルデータを合成する処理を行い、その結果を文字ブロックのベクトル化結果として出力する。

『文字認識』
文字認識部では、文字単位で切り出された画像に対し、パターンマッチの一手法を用いて認識を行い、対応する文字コードを得る。この認識処理は、文字画像から得られる特徴を数十次元の数値列に変換した観測特徴ベクトルと、あらかじめ字種毎に求められている辞書特徴ベクトルと比較し、最も距離の近い字種を認識結果とする処理である。特徴ベクトルの抽出には種々の公知手法があり、たとえば、文字をメッシュ状に分割し、各メッシュ内の文字線を方向別に線素としてカウントしたメッシュ数次元ベクトルを特徴とする方法がある。

ブロックセレクション（ステップ１２１）で抽出された文字領域に対して文字認識を行う場合は、まず該当領域に対し横書き、縦書きの判定をおこない、各々対応する方向に行を切り出し、その後文字を切り出して文字画像を得る。横書き、縦書きの判定は、該当領域内で画素値に対する水平／垂直の射影を取り、水平射影の分散が大きい場合は横書き領域、垂直射影の分散が大きい場合は縦書き領域と判断すればよい。文字列および文字への分解は、横書きならば水平方向の射影を利用して行を切り出し、さらに切り出された行に対する垂直方向の射影から、文字を切り出すことでおこなう。縦書きの文字領域に対しては、水平と垂直を逆にすればよい。尚、この時文字のサイズが検出出来る。

『文字のベクトル化』
前記文字認識によって得られた、文字コードを用いて、各々あらかじめ用意されたアウトラインデータを用いて、文字部分の情報をベクトルデータに変換する。なお、元原稿がカラーの場合は、カラー画像から各文字の色を抽出してベクトルデータとともに記録する。

以上の処理により、文字ブロックに属するイメージ情報をほぼ形状、大きさ、色が忠実なベクトルデータに変換出来る。

『文字以外の領域のベクトル化』
線画、線領域も同様に設定を読み出し、その設定にしたがって処理する。

例えば、設定が「ベクトルデータ」の場合、そのブロックを下記『文字以外の部分のベクトル化』の処理を行い再利用可能なベクトルデータへ変換する。また、設定が「画像」の場合、その領域を一つの画像データとして取り出し、ベクトル化の結果とする。「背景オブジェクトに含める」の場合、ベクトル化の処理は行わず背景オブジェクトの一部と扱う。

表領域も同様に設定を読み出し、その設定にしたがって処理する。

例えば、設定が「ベクトルデータ」の場合、枠線などの文字以外の部分は『文字以外の部分のベクトル化』を行い、文字部分は文字のベクトル化と同様に処理を行う。

設定が「背景に含める」の場合は、ベクトル化の処理は行わず背景オブジェクトの一部として扱う。また、設定が「二値画像」又は「多値画像」でかつ「ＯＣＲ情報を付加する」がＯｎの場合は、『文字認識』処理を行い、認識結果の文字コード、文字の大きさ、位置と画像データをベクトル化結果とする。

ブロックセレクション処理（ステップ１２１）で、図画あるいは線、表領域とされた領域を対象に、中で抽出された画素塊の輪郭をベクトルデータに変換する。具体的には、輪郭をなす画素の点列を角と看倣される点で区切って、各区間を部分的な直線あるいは曲線で近似する。角とは曲率が極大となる点であり、曲率が極大となる点は、図１１に図示するように、任意点Ｐｉに対し左右ｋ個の離れた点Ｐｉ−ｋ，Ｐｉ＋ｋの間に弦を引いたとき、この弦とＰｉの距離が極大となる点として求められる。さらに、Ｐｉ−ｋ，Ｐｉ＋ｋ間の弦の長さ／弧の長さをＲとし、Ｒの値が閾値以下である点を角とみなすことができる。角によって分割された後の各区間は、直線は点列に対する最小二乗法など、曲線は３次スプライン関数などを用いてベクトル化することができる。

また、対象が内輪郭を持つ場合、ブロックセレクションで抽出した白画素輪郭の点列を用いて、同様に部分的直線あるいは曲線で近似する。

以上のように、輪郭の区分線近似を用いれば、任意形状の図形のアウトラインをベクトル化することができる。元原稿がカラーの場合は、カラー画像から図形の色を抽出してベクトルデータとともに記録する。

さらに、図１２に示す様に、ある区間で外輪郭と、内輪郭あるいは別の外輪郭が近接している場合、２つの輪郭線をひとまとめにし、太さを持った線として表現することができる。具体的には、ある輪郭の各点Ｐｉから別輪郭上で最短距離となる点Ｑｉまで線を引き、各距離ＰＱｉが平均的に一定長以下の場合、注目区間はＰＱｉ中点を点列として直線あるいは曲線で近似し、その太さはＰＱｉの平均値とする。線や線の集合体である表罫線は、前記のような太さを持つ線の集合として効率よくベクトル表現することができる。

尚、先に文字ブロックに対する文字認識処理を用いたベクトル化を説明したが、該文字認識処理の結果、辞書からの距離が最も近い文字を認識結果として用いるが、この距離が所定値以上の場合は、必ずしも本来の文字に一致せず、形状が類似する文字に誤認識している場合が多い。従って本発明では、この様な文字に対しては、上記した様に、一般的な線画と同じに扱い、該文字をアウトライン化する。即ち、従来文字認識処理で誤認識を起こす文字に対しても誤った文字にベクトル化されず、可視的にイメージデータに忠実なアウトライン化によるベクトル化が行える。

又、写真と判定されたブロックに対しては本発明では、ベクトル化出来ない為、イメージデータのままとする。

（図形認識）
上述したように任意形状の図形のアウトラインをベクトル化した後、これらベクトル化された区分線を図形オブジェクト毎にグループ化する処理について説明する。

図１３は、ベクトルデータを図形オブジェクト毎にグループ化するまでのフローチャートを示している。まず、各ベクトルデータの始点、終点を算出する（７００）。次に各ベクトルの始点、終点情報を用いて、図形要素を検出する（７０１）。図形要素の検出とは、区分線が構成している閉図形を検出することである。検出に際しては、閉形状を構成する各ベクトルはその両端にそれぞれ連結するベクトルを有しているという原理を応用し、検出を行う。次に図形要素内に存在する他の図形要素、もしくは区分線をグループ化し、一つの図形オブジェクトとする（７０２）。また、図形要素内に他の図形要素、区分線が存在しない場合は図形要素を図形オブジェクトとする。

図１４は，図形要素を検出するフローチャートを示している．先ず，ベクトルデータより両端に連結していない不要なベクトルを除去し、閉図形構成ベクトルを抽出する（７１０）。次に閉図形構成ベクトルの中から該ベクトルの始点を開始点とし、時計回りに順にベクトルを追っていく。開始点に戻るまで行い、通過したベクトルを全て一つの図形要素を構成する閉図形としてグループ化する（７１１）。また、閉図形内部にある閉図形構成ベクトルも全てグループ化する。さらにまだグループ化されていないベクトルの始点を開始点とし、同様の処理を繰り返す。最後に、７１０で除去された不要ベクトルのうち、７１１で閉図形としてグループ化されたベクトルに接合しているものを検出し一つの図形要素としてグループ化する（７１２）。

以上によって図形ブロックを個別に再利用可能な個別の図形オブジェクトとして扱う事が可能になる。

（アプリデータへの変換処理）
ところで、一頁分のイメージデータをブロックセレクション処理（１２１）し、ベクトル化処理（１２９）した結果は図１５に示す様な中間データ形式のファイルとして変換されているが、このようなデータ形式はドキュメント・アナリシス・アウトプット・フォーマット（ＤＡＯＦ）と呼ばれる。

図１５はＤＡＯＦのデータ構造を示す図である。図１５において、７９１はＨｅａｄｅｒであり、処理対象の文書画像データに関する情報が保持される。レイアウト記述データ部７９２では、文書画像データ中のＴＥＸＴ（文字）、ＴＩＴＬＥ（タイトル）、ＣＡＰＴＩＯＮ（キャプション）、ＬＩＮＥＡＲＴ（線画）、ＥＰＩＣＴＵＲＥ（自然画）、ＦＲＡＭＥ（枠）、ＴＡＢＬＥ（表）等の属性毎に認識された各ブロックの属性情報とその矩形アドレス情報を保持する。文字認識記述データ部７９３では、ＴＥＸＴ、ＴＩＴＬＥ、ＣＡＰＴＩＯＮ等のＴＥＸＴブロックを文字認識して得られる文字認識結果を保持する。表記述データ部７９４では、ＴＡＢＬＥブロックの構造の詳細を格納する。画像記述データ部７９５は、ＰＩＣＴＵＲＥやＬＩＮＥＡＲＴ等のブロックのイメージデータを文書画像データから切り出して保持する。

このようなＤＡＯＦは、中間データとしてのみならず、それ自体がファイル化されて保存される場合もあるが、このファイルの状態では、所謂一般の文書作成アプリケーションで個々のオブジェクトを再利用する事は出来ない。そこで次に、このＤＡＯＦからアプリデータに変換する処理１３０について詳説する。

図１６は、全体の概略フローである。

８０００は、ＤＡＯＦデータの入力を行う。

８００２は、アプリデータの元となる文書構造ツリー生成を行う。

８００４は、文書構造ツリーを元に、ＤＡＯＦ内の実データを流し込み、実際のアプリデータを生成する。

図１７は、８００２文書構造ツリー生成部の詳細フロー、図１８は、文書構造ツリーの説明図である。全体制御の基本ルールとして、処理の流れはミクロブロック（単一ブロック）からマクロブロック（ブロックの集合体）へ移行する。以後ブロックとは、ミクロブロック、及びマクロブロック全体を指す。

８１００は、ブロック単位で縦方向の関連性を元に再グループ化する。スタート直後はミクロブロック単位での判定となる。ここで、関連性とは、距離が近い、ブロック幅（横方向の場合は高さ）がほぼ同一であることなどで定義することができる。また、距離、幅、高さなどの情報はＧＡＯＦを参照し、抽出する。

図１８（ａ）は実際のページ構成、（ｂ）はその文書構造ツリーである。８１００の結果、Ｔ３，Ｔ４，Ｔ５が一つのグループＶ１，Ｔ６，Ｔ７が一つのグループＶ２が同じ階層のグループとしてまず生成される。

８１０２は、縦方向のセパレータの有無をチェックする。セパレータは、例えば物理的にはＤＡＯＦ中でライン属性を持つオブジェクトである。また論理的な意味としては、アプリ中で明示的にブロックを分割する要素である。ここでセパレータを検出した場合は、同じ階層で再分割する。

８１０４は、分割がこれ以上存在し得ないか否かをグループ長を利用して判定する。ここで、縦方向のグループ長がページ高さとなっている場合は、文書構造ツリー生成は終了する。

図１８の場合は、セパレータもなく、グループ高さはページ高さではないので、８１０６に進む。

８１０６は、ブロック単位で横方向の関連性を元に再グループ化する。ここもスタート直後の第一回目はミクロブロック単位で判定を行うことになる。関連性、及びその判定情報の定義は、縦方向の場合と同じである。

図１８の場合は、Ｔ１，Ｔ２でＨ１、Ｖ１，Ｖ２でＨ２がＶ１，Ｖ２の１つ上の同じ階層のグループとして生成される。

８１０８は、横方向セパレータの有無をチェックする。

図１８では、Ｓ１があるので、これをツリーに登録し、Ｈ１，Ｓ１，Ｈ２という階層が生成される。

８１１０は、分割がこれ以上存在し得ないか否かをグループ長を利用して判定する。ここで、横方向のグループ長がページ幅となっている場合は、文書構造ツリー生成は終了する。そうでない場合は、８１０２に戻り、再びもう一段上の階層で、縦方向の関連性チェックから繰り返す。

図１８の場合は、分割幅がページ幅になっているので、ここで終了し、最後にページ全体を表す最上位階層のＶ０が文書構造ツリーに付加される。文書構造ツリーが完成した後、その情報を元に８００６においてアプリデータの生成を行う。

図１８の場合は、具体的には、以下のようになる。

すなわち、Ｈ１は横方向に２つのブロックＴ１とＴ２があるので、２カラムとし、Ｔ１の内部情報（ＤＡＯＦを参照、文字認識結果の文章、画像など）を出力後、カラムを変え、Ｔ２の内部情報出力、その後Ｓ１を出力となる。

Ｈ２は横方向に２つのブロックＶ１とＶ２があるので、２カラムとして出力、Ｖ１はＴ３，Ｔ４，Ｔ５の順にその内部情報を出力、その後カラムを変え、Ｖ２のＴ６，Ｔ７の内部情報を出力する。以上によりアプリデータへの変換処理が行える。

（ポインタ情報の付加）
次に、ステップ１３３で示す、ポインタ情報付加処理について説明する。

今、処理すべき文書が検索処理で特定された場合、あるいはベクトル化によって元ファイルが再生できた場合において、該文書を記録処理する場合においては、紙への記録の際にポインタ情報を付与する事で、この文書を用いて再度各種処理を行う場合に簡単に元ファイルデータを取得できる。

図１９はポインタ情報としてのデータ文字列を２次元バーコード（ＱＲコードシンボル：ＪＩＳＸ０５１０）３１１にて符号化して画像中に付加する過程を示すフローチャートである。２次元バーコード内に組み込むデータは、対応するファイルのアドレス情報を表しており、例えばファイルサーバ名およびファイル名からなるパス情報で構成される。或いは、対応するファイルへのＵＲＬや、対応するファイルの格納されているデータベース１０５内あるいはＭＦＰ１００自体が有する記憶装置内で管理されるファイルＩＤ等で構成される。

まず、符号化する種種の異なる文字を識別するため、入力データ列を分析する。また、誤り検出及び誤り訂正レベルを選択し、入力データが収容できる最小型番を選択する（ステップ９００）。

次に、入力データ列を所定のビット列に変換し、必要に応じてデータのモード（数字、英数字、８ビットバイト、漢字等）を表す指示子や、終端パターンを付加する。さらに所定のビットコード語に変換する。（ステップ９０１）。

この時、誤り訂正を行うため、コード語列を型番および誤り訂正レベルに応じて所定のブロック数に分割し、各ブロック毎に誤り訂正コード語を生成し、データコード語列の後に付加する（ステップ９０２）。

該ステップ９０２で得られた各ブロックのデータコード語を接続し、各ブロックの誤り訂正コード語、必要に応じて剰余コード語を後続する（ステップ９０３）。

次に、マトリクスに位置検出パターン、分離パターン、タイミングパターンおよび位置合わせパターン等とともにコード語モジュールを配置する（ステップ９０４）。

更に、シンボルの符号化領域に対して最適なマスクパターンを選択して、マスク処理パターンをステップ９０４で得られたモジュールにＸＯＲ演算により変換する。（ステップ９０５）。

最後に、ステップ９０５で得られたモジュールに形式情報および型番情報を生成して、２次元コードシンボルを完成する。（ステップ９０６）。

上記に説明した、アドレス情報の組み込まれた２次元バーコードは、例えば、クライアントＰＣ１０２から電子ファイルをプリントデータとして記録装置１１２に紙上に記録画像として形成する場合に、データ処理装置１１５内で記録可能なラスターデータに変換された後にラスターデータ上の所定の個所に付加されて画像形成される。ここで画像形成された紙を配布されたユーザは、画像読取り部１１０で読み取ることにより、前述したステップ１２３にてポインタ情報からオリジナル電子ファイルの格納場所を検出することができる。

尚、同様の目的で付加情報を付与する手段は、本実施例で説明した２次元バーコードの他に、例えば、ポインタ情報を直接文字列で文書に付加する方法、文書内の文字列、特に文字と文字の間隔を変調して情報を埋め込む方法、文書中の中間調画像中に埋め込む方法等、一般に電子透かしと呼ばれる方法が適用出来る。

（ファイルアクセス権に関する別実施例）
我々が扱う文書ファイルの中には、第３者による再利用を制限すべき物がある。先の実施例ではファイルサーバに蓄積されたファイルは全て自由にアクセス出来、ファイル全体、或いはその一部のオブジェクトは全て再利用が可能な事を前提に説明した。そこで、先の実施例でポインタ情報からファイルを検索した際に、検索の結果、特定出来たファイルにアクセス権の制限が有る場合についての別実施例を図９を用いて説明する。ステップ４０３までは先の実施例と同様の為説明は省略する。ファイルが特定された場合ファイルサーバはそのファイルのアクセス権情報を調べ、アクセス制限がある場合（ステップ４０４）には、ＭＦＰに対してパスワードの送信を要求する。（ステップ４０５）ＭＦＰは操作者に対してパスワードの入力を促し、入力されたパスワードをファイルサーバに送信する。（ステップ４０６）
ファイルサーバは送信されたパスワードを照合し、一致した場合には（ステップ４０７）図３で説明した様に、ファイルのアドレスを通知（ステップ１３４）すると共に、ユーザの希望する処理が画像ファイルデータの取得であれば、ＭＦＰに対してファイルを転送する（ステップ４０８）。尚、アクセス権の制御を行う為の認証の方法は、ステップ４０５、４０６に示したパスワードによる方法に限定されず、例えば、指紋認証等の一般に広く用いられている生体認証、カードによる認証等、全ての認証手段を用いる事が出来る。

又、本別実施例では紙文書に付加的に付与されたポインタ情報によりファイルを特定した場合の実施例を示したが、図３ステップ１２６−１２８で示す所謂検索処理でファイルを特定した場合においても同様の制御が可能である。

一方、ファイルサーバ内からファイルを特定出来なかった場合、即ち図３のステップ１２９−１３２で説明したベクトル化処理に対しても、制限を加える事が出来る。即ち紙文書を走査して得られたイメージ情報から該文書に対してのアクセス権の制限の存在を検出した場合には、認証確認が取れた場合のみベクトル化処理を行う事で、機密性の高い文書の使用に制限をかける事が出来る。

（ファイル特定に関する別実施例）
先の実施例では原稿走査して得られるイメージ情報から元ファイルデータを特定する手段は、図３に示す様に、文書中に付与されたポインタ情報に従う手段か、或いは文書中に記載された各オブジェクト情報に従う検索手段のいずれかに依るが、より正確に元ファイルを特定するには、該両手段を併用すれば良い。即ち、原稿中から得られるポインタ情報から元ファイルの存在が検出出来たとしても、更に該文書中のオブジェクト情報を使って、例えば、レイアウト情報に従うレイアウト検索、文字認識されたキーワードによる全文検索を検出されたファイルに対して行い、高い一致が得られた場合に該検出したファイルを、正式に元ファイルであると特定する。これは、例えば、ポインタ情報の下位の部分が曖昧で有ったり、誤り訂正でも訂正できなかった場合に対して、検索の範囲を絞り込んでファイルを特定出来る為、より高速で、確度の高いファイル特定が行える。

（ベクトル化の別実施例）
先の実施例では検索手段で、元ファイルの特定が出来ない場合、イメージ画像全体に対してベクトル化処理を行うが、例えば、一般の文書の場合、文書中のオブジェクト全て新規に作成された物でなく、一部のオブジェクトは他のファイルから流用して作成される場合がある。例えば、背景オブジェクト（壁紙）は文書作成アプリケーションで幾つかのパターンを予め用意してあり、その中から選択して用いるのが通常である。従って、このようなオブジェクトは文書ファイルデータベースの中の他の文書ファイル中に存在している可能性が高く、又再利用可能なベクトルデータとして存在する可能性が高い。

従って、このような背景から、図３のベクトル化処理１２９の別実施例として、ブロックセレクション処理で個別のオブジェクトに分割された各オブジェクトに対して、該オブジェクト単位でデータベース中から該一致するオブジェクトを一部に含むファイルを検索し、一致したオブジェクトに対して、個別に該ファイルからオブジェクト単位でベクトルデータを取得する。これに依って、文書全体をベクトル化する必要が無くなり、より高速にベクトル化出来、更にベクトル化による画質劣化を防止出来る。

一方、図３において検索処理１２６−１２８で元ファイルがＰＤＦとして特定できた場合、該ＰＤＦがその文書の文字オブジェクトに対して既に文字認識された文字コードを付加ファイルとして有している場合がある。このようなＰＤＦファイルをベクトル化する際には、該文字コードファイルを用いれば、１２９以降のベクトル化処理の中の文字認識処理を省く事が出来る。即ちベクトル化処理をより高速に処理する事が可能に成る。

（ベクトル化の別実施例）
ファイルサーバに元ファイルが存在しない場合は、ベクトル化の処理が必要になる。このとき図２５のような現在の設定を確認するためのものを表示する。これば、図２０から図２４で設定されたもので、ハードディスクなどの記憶装置に保存してある設定である。ここで図２５の「変換」を押す操作をすることでベクトル化の処理が起動する。ここで「変更」を押す操作をすると、図２０から図２４のような設定画面が表示され、現在の設定を変更することができる。ただしこの場合の設定の変更はその一回のベクトル化において有効であり、設定の情報はハードディスクには書き込まない。このようにすることにより、ユーザの目的や処理する文書によってベクトル化の処理内容を変更することが可能になる。

また図２６のように「デフォルトにする」というボタンを用意することで、変更した設定の内容をハードディスクなどの記憶装置に書き出すことで次回からのベクトル化時に最初に表示される設定を変更できるようになる。このようにすることにより、さらにユーザの目的に応じたベクトル化処理が可能となる。

システム構成図ＭＦＰ構成図処理概要ブロックセレクション処理ブロック情報２次元バーコードを復号して文字列を出力する過程を示すフローチャート２次元バーコードが付加された原稿の一例ポインタ情報からの電子ファイルを検索する過程を示すフローチャートファイルアクセス権に関するフローチャートファイル検索処理の詳細な流れを示すフローチャート曲率が最大となる点二つの輪郭線を一つにまとめる例図形オブジェクト認識処理図形要素検出処理ＤＡＯＦアプリデータ変換文書構造ツリー生成文書構造ツリー説明図ポインタ情報としてのデータ文字列を２次元バーコードにて符号化して画像中に付加する過程を示すフローチャート設定画面例（文字）設定画面例（線画）設定画面例（線）設定画面例（表）設定画面例（写真）設定画面例設定画面例１つの文字ブロックの処理を表すフローチャートベクトル化の中間データ辞書ベクトル化処理概要ベクトル化処理概要２登録フォント辞書の１文字分のデータ新ベクトル化フロー

Claims

原稿を読み取り走査する手段と、該手段で得られたイメージ情報から、該原稿の電子ファイルを特定する特定手段と、前記特定手段で該原稿の電子ファイルが特定出来ない場合、前記画像読み取り走査手段で得られるイメージ情報をベクトル化手段でベクトルデータに変換する事を特徴とする画像処理システム。
前記特定手段は原稿に付加的に記録された電子ファイルの格納場所を認識する手段を含む事を特徴とする第１項記載の画像処理システム。
前記特定手段は原稿中に記載された特定の情報を記憶手段で格納されたファイルの中から検索する手段を有する事を特徴とする第１項記載の画像処理システム。
前記ベクトル化手段は原稿中の文字をＯＣＲするＯＣＲ手段を含む事を特徴とする第１項記載の画像処理システム。
前記ベクトル化手段は原稿を複数のオブジェクトに分割し、各オブジェクトに対して独立にベクトル化する事を特徴とする第１項記載の画像処理システム。
前記ベクトル化手段はベクトル化されたオブジェクトを既存の文書作成ソフトウェアで扱える既定フォーマットに変換するフォーマット変換手段を含む事を特徴とする第１項記載の画像処理システム。
前記ベクトル化手段でベクトル化されたベクトルデータを記憶する画像記憶手段と、該ベクトルデータに該データを格納する格納場所を付加情報として付加する情報付加手段を更に備える事を特徴とする第１項記載の画像処理システム。
前記ファイル特定手段は、原稿読み取り走査手段によって得られる該原稿の電子ファイルから、原稿中に記載された特定の情報が検索して得られる場合に限って該電子ファイルに特定する事を特徴とする第２項記載の画像処理システム。
原稿を読み取り走査する手段と、該手段で得られたイメージ情報から、該原稿の電子ファイルを特定する手段とを有し、前記特定手段で得られた該原稿の電子ファイルがオブジェクト単位で既存の文書作成ソフトウェアで扱えない場合、
前記画像読み取り走査手段で得られるイメージ情報をベクトル化手段でベクトルデータに変換する事を特徴とする画像処理システム。
前記ベクトル化手段は原稿を読み取り走査して得られるイメージ情報をオブジェクト毎に分割する手段と、該分割されたオブジェクト単位で記憶手段で格納されたファイルの中から一致するオブジェクトを検索する手段を有し、該検索手段で得られた情報を用いてベクトル化する事を特徴とする第１項記載の画像処理システム。
前記ベクトル化手段は、オブジェクトの種類によってベクトル化の方法を設定する手段を有し、オブジェクトのベクトル化を行う際に、設定されたベクトル化手段を用いることを特徴とする第１項記載の画像処理システム。
前記ベクトル化手段は、前記１１項のベクトル化方法の設定手段において文字認識結果を必要としないとなっている場合に、文字認識処理を行うことなく文字情報をベクトル化することを特徴とする第１項記載の画像処理システム。
前記ベクトル化手段は、該ＯＣＲ結果より文字矩形情報を出現順に呼び出す手段と、注目している文字矩形の文字コードを呼び出す手段と、文字コードを既に出現している文字コードと比較する手段と、比較手段の結果によりフォント変換、あるいは認識を行う手段と、フォント変換あるいは認識結果を文字コードと共に記憶する手段、とを有することを特徴とする第１項記載の画像処理システム。
前記ベクトル化手段は、フォント種別の特徴辞書を有し、該ＯＣＲ結果より文字矩形情報を出現順に呼び出す手段と、注目している文字矩形の文字コードを呼び出す手段と、文字矩形から文字画像を取り出し、フォント種別識別用の特徴抽出を行い各フォント種別辞書の同一文字コードの特徴と比較しフォント種別を決定する手段と、フォント種別決定手段によりあらかじめ作成しておいたフォントデータをフォント変換の結果とし、フォント変換あるいは認識結果を文字コードと共に記憶する手段、とを有することを特徴とする第１項記載の画像処理システム。
前記ベクトル化手段は、フォントの識別が出来なかった文字の前後のフォント種別より該文字のフォントを推定する手段と、推定されたフォントから作成したフォント識別用の辞書を使い再度の文字認識処理を行う手段と、文字認識結果の類似度により本来の文字認識結果を置き換える手段とを有することを特徴とする第１４項記載の画像処理システム。