以下、本発明の実施の形態について図面を用いて詳細に説明する。
<実施形態1>
図1は本発明の実施形態1の画像処理システムの構成を示すブロック図である。
この画像処理システムは、オフィス10及びオフィス20とをインターネット等のネットワーク104で接続された環境で実現する。
オフィス10内に構築されたLAN107には、複数種類の機能(複写機能、印刷機能、送信機能等)を実現する複合機であるMFP(Multi Function Peripheral)100、MFP100を制御するマネージメントPC101、MFP100を利用するクライアントPC102、文書管理サーバ106及びそのデータベース105、及びプロキシサーバ103が接続されている。
オフィス20内に構築されたLAN108には、プロキシサーバ103、文書管理サーバ106及びそのデータベース105が接続されている。
オフィス10内のLAN107及びオフィス20内のLAN108は、それぞれのオフィスのプロキシサーバ103を介してネットワーク104に接続されている。
MFP100は、特に、原稿である紙文書を電子的に読み取る画像読取部と、画像読取部から得られる画像信号に対する画像処理を実行する画像処理部を有し、この画像信号はLAN109を介してマネージメントPC101に送信することができる。
マネージメントPC101は、通常のPC(パーソナルコンピュータ)であり、内部に画像記憶部、画像処理部、表示部、入力部等の各種構成要素を有するが、その構成要素の一部はMFP100に一体化して構成されている。
尚、図1の構成は一例であり、文書管理サーバ106を有するオフィス20がなくても、あるいはもっと複数存在してもよいし、あるいはオフィス10、オフィス20とが同一LAN上で接続されていても良い。
また、ネットワーク104は、典型的にはインターネットやLANやWANや電話回線、専用デジタル回線、ATMやフレームリレー回線、通信衛星回線、ケーブルテレビ回線、データ放送用無線回線等のいずれか、またはこれらの組み合わせにより実現されるいわゆる通信ネットワークであり、データの送受信が可能であれば良い。
また、マネージメントPC101、クライアントPC102、文書管理サーバ106等の各種端末はそれぞれ、汎用コンピュータに搭載される標準的な構成要素(例えば、CPU、RAM、ROM、ハードディスク、外部記憶装置、ネットワークインタフェース、ディスプレイ、キーボード、マウス等)を有している。
次に、MFP100の詳細構成について、図2を用いて説明する。
図2は本発明の実施形態1のMFPの詳細構成を示すブロック図である。
図2において、オートドキュメントフィーダ(ADF)を含む画像読取部110は、束状のあるいは1枚の原稿画像を光源(不図示)で照射し、原稿反射像をレンズで固体撮像素子上に結像し、固体撮像素子からラスタ状の画像読取信号を所定密度(600DPI等の)のラスター画像として得る。
また、MFP100は、画像読取信号に対応する画像を印刷部112で記録媒体に印刷する複写機能を有し、原稿画像を1つ複写する場合には、この画像読取信号をデータ処理部115で画像処理して記録信号を生成し、これを印刷部112によって記録媒体上に印刷させる。一方、原稿画像を複数複写する場合には、記憶部111に一旦一ページ分の記録信号を記憶保持させた後、これを印刷部112に順次出力して記録媒体上に印刷させる。
また、ネットワークI/F114を介する送信機能においては、画像読取部110から得られるラスター画像を、TIFFやJPEG等の圧縮画像ファイル形式、あるいはPDF等のベクトルデータファイル形式の画像ファイルへと変換し、ネットワークIF114から出力する。出力された画像ファイルは、LAN107を介して文書管理サーバ106へ送信されたり、更にネットワーク104経由で別の文書管理サーバ106やクライアントPC102に転送されたりする。
また、印刷部112による印刷機能においては、例えば、クライアントPC102から出力された印刷データをネットワークIF114経由でデータ処理部115が受信し、データ処理部115は、その印刷データを印刷部112で印刷可能なラスターデータに変換した後、印刷部112によって印刷媒体上に画像を形成する。
MFP100への操作者の指示は、MFP100に装備されたキー操作部とマネージメントPC101に接続されたキーボード及びマウスからなる入力部113から行われ、これら一連の動作はデータ処理部115内の制御部(不図示)で制御される。また、操作入力の状態表示及び処理中の画像データの表示は、表示部116で行われる。
記憶部111は、マネージメントPC101からも制御され、MFP100とマネージメントPC101とのデータの送受信及び制御は、ネットワークIF117及びLAN109を介して行われる。
これらMFP100とマネージメントPC101とのデータの授受及び制御は、LAN109が構成されている場合には、ネットワークI/F117を介してMFP100とマネージメントPC101を直結して実現するが、LAN109が構成されていない場合には、ネットワークI/F114に接続されるLAN102を介して実現する。
[処理概要]
次に、実施形態1の画像処理システムで実行する処理全体の概要を、図3を用いて説明する。
図3は本発明の実施形態1の画像処理システムで実行する処理全体の概要を示すフローチャートである。
まず、ステップS120で、MFP100の画像読取部110で、その原稿をラスタ状に走査して読み取り、例えば、600DPI−8ビットの画像信号を得る。この画像信号をデータ処理部115で前処理を施し、記憶部111に1ページ分の画像データ(イメージデータ)として保存する。
次に、ステップS121で、データ処理部115において、ブロックセレクション(BS)処理を行う。この処理は、マネージメントPC101の制御によって実行する。
具体的には、マネージメントPC101のCPUは、記憶部111に格納された処理対象の画像信号を、まず、文字/線画部分とハーフトーン画像部分とに領域分割し、文字/線画部分は更に段落で塊として纏まっているブロック毎に、あるいは線で構成された表、図形毎に分割する。
一方、ハーフトーン画像部分は、矩形に分離されたブロックの画像部分、背景部分等の、所謂ブロック毎に独立したオブジェクト(ブロック)に分割する。
また、詳細は後述するが、このBS処理によって生成された各ブロックには、それぞれのブロックに関する情報であるブロック情報が生成される。
次に、ステップS122で、原稿画像中に付加情報として記録された2次元バーコード、あるいはURL(あるいはURI(Uniform Resource Identifier))に該当するオブジェクト(ブロック)を検出する。付加情報がURL画像である場合は、そのURL画像をOCRで文字認識する。一方、付加情報が2次元バーコード画像である場合、その2次元バーコード画像をOMR(Optical Mark Recognition)でマーク解読を行う。
尚、ステップS122では、ステップS121のBS処理で得られた文字ブロックをOCRで文字認識する。
次に、ステップS123で、ステップS122の処理結果に基づいて、読取原稿画像のオリジナル電子ファイルが格納されている格納先を示すポインター情報を検出する。
次に、ステップS124で、ポインター情報の検出の有無を判定する。ポインター情報が検出されない場合(ステップS124でNO)、ステップS126に進む。一方、ポインター情報が検出された場合(ステップS124でYES)、ステップS125に進み、ポインター情報が示す格納先にオリジナル電子ファイルが存在するか否かを判定する。
尚、オリジナル電子ファイルは、例えば、図1のクライアントPC102内のハードディスク内、データベース105内、あるいはMFP100自体が有する記憶部111のいずれかに格納されており、ステップS123で検出したポインター情報に従って、これらの記憶装置内を検索する。
ステップS125において、オリジナル電子ファイルが検索されない場合(ステップS125でNO)、ステップS126に進む。一方、オリジナル電子ファイルが検索された場合(ステップS125でYES)、ステップS133に進む。
尚、ステップS125において、オリジナル電子ファイルが検索された場合でも、そのオリジナル電子ファイルが、PDFあるいはTIFFに代表されるイメージデータである場合は、ステップS126に進む。逆に、オリジナル電子ファイルが、以前に、本処理によって生成されたベクトルデータである場合には、ステップS133に進む。
ステップS126で、ステップS120で入力した読取原稿画像に基づいて、それに類似する電子ファイルを検索するファイル検索処理を実行する。
このファイル検索処理では、ステップS122で各文字ブロックに対して行ったOCR結果から単語を抽出して、その単語を有する電子ファイルを検索する全文検索を行う。あるいは、画像信号中の各ブロックの配列と各ブロックの属性(画像、文字等)で特定されるレイアウトを有する(あるいは類似する)電子ファイルを検索するレイアウト検索を行う。
次に、ステップS127で、ファイル検索処理の検索結果として得られる電子ファイル(群)を、読取原稿画像に対応する電子ファイル(あるいはそのサムネール画像(代表画像))の候補として表示部116に表示し、その候補から処理対象の電子ファイルの選択を受け付ける。
尚、候補が1つの場合、自動的に、ステップS128からステップS133に進む。
ステップS128で、表示部116に表示した電子ファイルの候補の中から電子ファイルが選択されたか否かを判定する。電子ファイルが選択された場合(ステップS128でYES)、ステップS133に進む。一方、電子ファイルが選択されない場合(ステップS128でNO)、ステップS129に進む。
尚、ステップS128において、電子ファイルが選択された場合でも、その電子ファイルが、PDFあるいはTIFFに代表されるイメージデータである場合は、ステップS129に進む。
ステップS129で、イメージデータ(ステップS120で入力された読取原稿画像(イメージデータ)あるいはステップS127で選択されたイメージデータの電子ファイル)をベクトルデータに変換するベクトル化処理を実行する。
このベクトル化処理では、まず、ステップS122でOCR処理された文字ブロックに対して、更に、文字のサイズ、スタイル、字体(フォント)を認識し、原稿を走査して得られる文字と可視的に忠実なフォントデータに変換する。
このとき、文字のサイズ、スタイル、字体の認識結果が悪く、誤認識の可能性がある場合は、文字ブロックの文字画像をアウトライン化し、外字のアウトラインフォントとしてベクトル化する。
特に、実施形態1では、文字データをアウトライン化するか否かの判定は、文字サイズに応じて決定する。例えば、文字サイズが所定サイズ以上の場合には、文字データをアウトライン化する。この構成によれば、文字画像をアウトライン化することで画質が劣化する可能性のある比較的文字サイズが小さい文字画像については、アウトライン化処理が実行されず、その文字画像そのもののイメージデータが保持されるので、その文字画像の画質を維持することができる。
また、後述する実施形態2では、文字画像をアウトライン化することで、アウトライン化後のデータ量がアウトライン化前のデータよりも増加する場合には、その文字画像をそのままイメージデータとして保持する。この構成によれば、文字画像に対応するデータのデータ量の増加を防止することができる。
また、この実施形態2の構成において、アウトライン化後のデータ量がアウトライン化前のデータよりも増加する場合とは、比較的文字サイズが小さい文字画像である場合であるため、実質的に、実施形態1の構成も考慮した構成となる。そのため、実施形態2の構成によれば、文字画像に対応するデータのデータ量の増加を防止しつつ、その画質を維持することができる。
一方、線で構成される表、図形ブロックに対しては、アウトライン化する。また、画像ブロックに対しては、イメージデータとして個別のJPEGファイルに変換する。
これらの各種ブロックに対するベクトル化処理は、各ブロック毎にそのブロック情報に基づいて行い、更に各ブロックのレイアウト情報を保存する。
次に、ステップS130で、ステップS129で得られたベクトルデータを、文書作成アプリケーションによって処理することが可能な、所定形式(例えば、rtf形式)のアプリケーションデータ(アプリデータ)に変換するアプリデータ変換処理を実行する。そして、ステップS131で、その生成されたアプリデータを、ステップS120で入力されたイメージデータに対応する電子ファイルとして、記憶部111あるいは文書管理サーバ106等に格納する。
次に、ステップS132で、以降、同様の処理を行う際に、読取原稿画像から直接、それに対応する電子ファイルとして検索できるようにするために、電子ファイルの検索用のインデックス情報を生成するインデックス生成処理を実行する。そして、生成されたインデックス情報は、例えば、記憶部111で管理されている検索用インデックスファイルに追加される。
ステップS133で、ステップS125で検索されたオリジナル電子ファイルの格納アドレス、あるいはステップS128で選択された電子ファイルの格納アドレス、あるいはステップS131で格納された電子ファイルの格納アドレスを、表示部111に通知する。
ステップS134で、入力部113からの操作指示が、読取原稿画像の登録指示であるか否かを判定する。登録指示でない場合(ステップS134でNO)、ステップS136に進む。一方、登録指示である場合(ステップS134でYES)、ステップS135に進む。
尚、ステップS134の処理は、ポインター情報が存在しない読取原稿画像を当該画像処理システムで再利用するために、その読取原稿画像のイメージ情報/ベクトルデータ/ステップS128で選択された電子ファイルを、オリジナル電子ファイルとしてユーザが登録したい場合の登録操作の実行指示の有無を判定するものである。
そのため、ポインター情報が存在する読取原稿画像の場合は、通常、この登録操作が実行されないことが想定される。但し、ポインター情報が存在していて、読取原稿画像に対応するオリジナル電子ファイルが既に存在している場合でも、用途や目的によっては、改めてこの読取原稿画像を登録したい場合が存在するので、この登録操作は、ポインター情報が存在しない読取原稿画像に対して実行するとは限らない。
また、登録操作ではなく、読取原稿画像の複写操作(印刷装置)が指示された場合には、オリジナル電子ファイルの登録を行うとともに、そのオリジナル電子ファイルを読取原稿画像に対する印刷物として複写(印刷)するようにしても良い。
ステップS135で、登録対象の読取原稿画像に対するポインター情報を生成して、その読取原稿画像に対応するオリジナル電子ファイルにイメージデータとして付加するポインター情報付加処理を実行する。そして、このポインター情報が付加されたオリジナル電子ファイルは、例えば、図1のクライアントPC102内のハードディスク内、データベース105内、あるいはMFP100自体が有する記憶部111のいずれかに格納される。また、この格納に併せて、そのオリジナル電子ファイルを印刷部112から印刷するようにしても良い。
ステップS136で、読取原稿画像に対応するオリジナル電子ファイルに対する各種処理(編集/蓄積/伝送(FAX送信、Eメール送信、ファイル送信)/印刷等)を実行するための、操作画面を表示部116に提示し、その操作画面を介して、オリジナル電子ファイルに対する各種処理を実行することができる。
ここで、各種処理として、例えば、印刷(複写)の場合には、各オブジェクトに最適な色処理、空間周波数補正等の画像処理が施された後、印刷部112より印刷される。また、蓄積の場合には、記憶部111に記憶保持される。また、伝送(ファイル送信)の場合には、汎用のファイル形式として、例えば、RTF(Rich Text Format)形式に変換したり、SVG形式に変換したりして、ファイル送信先で再利用可能なファイル形式にして変換して、ネットワークI/F114を介してファイル送信先(例えば、クライアントPC102)へファイル送信する。
このように、本画像処理システムでは、通常、読取原稿画像に対応するオリジナル電子ファイルとしてベクトルデータが管理され、そのベクトルデータを用いた各種処理を実行することができるので、処理対象のデータの情報量を削減でき、かつ蓄積効率が高まり、伝送時間を短縮でき、かつ出力(表示/印刷)する際には高品位な画像で出力することができる。
[各処理の詳細]
以下、各処理の詳細について説明する。
[ブロックセレクション処理]
まず、ステップS121のBS処理の詳細について説明する。
BS処理とは、例えば、図4(a)のラスター画像を、図4(b)のように、意味のあるブロック毎の塊として認識し、該ブロック各々の属性(文字(TEXT)/図画(PICTURE)/写真(PHOTO)/線(LINE)/表(TABLE)等)を判定し、異なる属性を持つブロックに分割する処理である。
BS処理の実施形態を以下に説明する。
まず、入力画像を白黒に二値化し、輪郭線追跡を行って黒画素輪郭で囲まれる画素の塊を抽出する。面積の大きい黒画素の塊については、内部にある白画素に対しても輪郭線追跡を行って白画素の塊を抽出、さらに一定面積以上の白画素の塊の内部からは再帰的に黒画素の塊を抽出する。
このようにして得られた黒画素の塊を、大きさ及び形状で分類し、異なる属性を持つブロックへ分類していく。例えば、縦横比が1に近く、大きさが一定の範囲のブロックは文字相当の画素塊とし、さらに近接する文字が整列良くグループ化可能な部分を文字ブロック、扁平な画素塊を線ブロック、一定大きさ以上でかつ矩形の白画素塊を整列よく内包する黒画素塊の占める範囲を表ブロック、不定形の画素塊が散在している領域を写真ブロック、それ以外の任意形状の画素塊を図画ブロックとする。
そして、BS処理では、各ブロックを特定するブロックIDを発行し、各ブロックの属性(画像、文字等)、サイズやオリジナル文書内の位置(座標)と各ブロックを関連付けて記憶部111にブロック情報として記憶する。また、これらのブロック情報は、以降に詳細を説明するステップS129のベクトル化処理や、ステップS132のインデックス生成処理で利用される。
ここで、ブロック情報の一例について、図5を用いて説明する。
図5は本発明の実施形態1のブロック情報の一例を示す図である。
図5に示すように、ブロック情報は、各ブロックの属性を示すブロック属性(1:テキスト、2:図画、3:表、4:線、5:写真)、ブロックの位置座標(X,Y)、ブロックの幅W及び高さH、ブロックのOCR情報(テキストデータ)の有無で構成されている。
ここで、ブロックの位置座標(X,Y)とは、例えば、原稿画像の左上角を原点(0,0)とした場合の位置座標である。また、幅W及び高さHは、例えば、画素数で表現される。また、このブロック情報に加えて、BS処理では、原稿画像(入力ファイル)に存在するブロック数Nを示す入力ファイル情報を生成する。図5の例の場合、入力ファイル情報はN=6となる。
[OCR/OMR処理(ポインター情報検出処理)]
次に、図3のステップS122の処理の詳細について、図6を用いて説明する。
図6は本発明の実施形態1のステップS122の処理の詳細を示すフローチャートである。
尚、図6では、例えば、図7に示すような原稿画像310中に付加された2次元バーコード(例えば、QRコードシンボル)311を復号して、データ文字列を出力する処理について説明する。
まず、ステップS300で、データ処理部115内のページメモリに格納された原稿画像310を表すイメージ画像をCPU(不図示)で走査して、上述のBS処理の処理結果に基づいて、所定の2次元バーコードシンボル311(ブロック)の位置を検出する。
特に、実施形態1の場合、2次元バーコードシンボル311であるQRコードの位置検出パターンは、2次元バーコードシンボル311の4隅の内の3隅に配置される同一の位置検出パターンから構成される。そのため、実施形態1では、この位置検出パターンを検出することで、2次元バーコードシンボル311の位置を検出する。
次に、ステップS301で、位置検出パターンに隣接する形式情報を復元し、シンボルに適用されている誤り訂正レベル及びマスクパターンを取得する。
次に、ステップS302で、2次元バーコードシンボル311を特定する型番を決定する。その後、ステップS303で、形式情報で取得されたマスクパターンを使って、符号化領域ビットパターンをXOR演算することによってマスク処理を解除する。
次に、ステップS304で、モデルに対応する配置規則に従い、シンボルキャラクタを読み取り、2次元バーコードシンボル311のデータコード語及び誤り訂正コード語を復元する。
次に、ステップS305で、復元された誤り訂正コード語上に、誤りがあるか否かを判定する。誤りがない場合(ステップS305でNO)、ステップS307に進む。一方、誤りがある場合(ステップS305でYES)、ステップS306に進み、誤りを訂正する。
ステップS307で、誤り訂正されたデータより、モード指示子および文字数指示子に基づいて、データコード語をセグメントに分割する。
最後に、ステップS308で、使用モードに基づいてデータ文字を復号し、その復号結果を出力する。
尚、2次元バーコード内に組み込まれた情報は、対応する電子ファイルのアドレス情報(ポインター情報)を示している。ここで、アドレス情報とは、URL(URI)や、サーバ名とディレクトリ、ファイル名からなる電子ファイルの格納先を示すフルパス情報である。
また、実施形態1では、ポインター情報が2次元バーコードとして付加された原稿画像310の例について説明したが、ポインター情報を直接文字列として原稿画像310に印刷するようにしても良い。この場合は、所定のルールに従った文字ブロックを、先のBS処理で検出し、ポインター情報を示す文字画像の各文字を文字認識することで、直接オリジナル電子ファイルのアドレス情報を得ることが可能である。
また、図7の原稿画像310の文字ブロック312、あるいは文字ブロック313に対して隣接する文字と文字の文字間隔に視認し難い程度の変調を加え、この文字間隔に情報を埋め込むことで、ポインター情報を原稿310に埋め込むようにしても良い。この場合、後述する文字認識処理を行う際に各文字の文字間隔を検出することで、ポインター情報を得ることが可能である。更には、自然画314の中に、電子透かし情報として、ポインター情報を付加することも可能である。
[検索処理]
次に、図3のステップS125における、ポインター情報によるオリジナル電子ファイルの検索処理について、図8のフローチャートを使用して説明する。
図8は本発明の実施形態1のオリジナル電子ファイルの検索処理を示すフローチャートである。
まず、ステップS400で、MFP100は、ポインター情報に含まれるアドレス情報に基づいて、電子ファイルの格納先となるファイルサーバを特定する。
ここで、ファイルサーバとは、クライアントPC102や、データベース105を管理する文書管理サーバ106、あるいは記憶部111を内蔵するMFP100自身を指すものである。
次に、ステップS401で、MFP100は、特定したファイルサーバに対してアドレス情報を転送する。
ステップS402で、ファイルサーバは、アドレス情報を受信すると、そのアドレス情報に対応するオリジナル電子ファイルを検索する。ステップS403で、オリジナル電子ファイルが存在するか否かを判定する。オリジナル電子ファイルが存在しない場合(ステップS403でNO)には、MFP100に対して、その旨を通知する。
一方、オリジナル電子ファイルが存在する場合(ステップS403でYES)、ステップS408に進み、オリジナル電子ファイルのアドレスを通知すると共に、そのオリジナル電子ファイルをMFP100に転送する。
尚、図8の処理において、よりセキュリティ性を向上させたい場合には、例えば、図9に示すように、オリジナル電子ファイルを要求するユーザの認証を行うようにしても良い。つまり、処理対象のオリジナル電子ファイルの中には、第3者による再利用を制限したいものがあり、図8の処理では、ファイルサーバに蓄積されたオリジナル電子ファイルは全て自由にアクセスでき、オリジナル電子ファイル全体、或いはその一部のオブジェクトは全て再利用が可能なことを前提にしている。
そこで、オリジナル電子ファイルへのアクセスをユーザ別に制限する場合の処理について、図9を用いて説明する。
図9は本発明の実施形態1のオリジナル電子ファイルの検索処理の応用例を示すフローチャートである。
尚、図9の処理において、図8の処理と同一の処理には、同一のステップS番号を付加して、その説明は省略する。
図9では、ステップS403で、オリジナル電子ファイルが存在する場合、ステップS404で、そのオリジナル電子ファイルにアクセス制限があるか否かを判定する。アクセス制限がない場合(ステップS404でNO)、ステップS408に進む。一方、アクセス制限がある場合(ステップS404でYES)、ステップS405に進み、MFP100は、表示部116に、パスワード入力画面を提示し、MFP100を操作するユーザにパスワードの入力を要求する。
ステップS406で、MFP100は、パスワードが入力されると、それをファイルサーバへ転送する。ステップS407で、パスワードに基づくファイルサーバによる認証が成功したか否かを判定する。認証が失敗した場合(ステップS407でNO)、ステップS405に戻る。一方、認証が成功した場合(ステップS407でYES)、ステップS408に進む。
尚、ステップS407において、認証が失敗した場合には、再度、パスワードの入力を要求する構成となっているが、その認証の失敗回数が所定回数を越えた場合には、不正なユーザによる操作と判断して、処理そのものを中止するようにしても良い。
また、ステップS407での認証方法は、パスワードを用いた認証方法に限定されず、例えば、指紋認証等の一般に広く用いられている生体認証、カードによる認証等のあらゆる全ての認証方法を用いて実現することができる。
また、この認証については、以下のファイル検索処理においても適用することが可能である。
更に、ファイルサーバ内からオリジナル電子ファイルを検索できない場合、即ち、図3のステップS129〜ステップS132の一連の処理に対しても、同様の認証を適用することが可能である。即ち、読取原稿画像に対してのアクセス権の制限の存在を検出した場合には、そのアクセス権の認証が成功した場合にのみ、ステップS129以降の処理を実行することで、ユーザ別や読取原稿画像別に画像処理システムで実現できる処理を制限でき、より機密性を高めることができる。
[ファイル検索処理]
次に、図3のステップS126の処理の詳細について、図5及び図10を用いて説明する。
図10は本発明の実施形態1のステップS126の処理の詳細を示すフローチャートである。
尚、ステップS126の処理は、ステップS124で読取原稿画像(入力ファイル)にポインター情報が存在しなかった場合、または、ポインター情報は存在するがオリジナル電子ファイルが見つからなかった場合、あるいはオリジナル電子ファイルがイメージファイルである場合に実行される。
また、ステップS126の処理は、ステップS122の処理によって得られたブロック情報及び入力ファイル情報を利用することになるが、ここでは、その具体例として、図5に示したブロック情報及び入力ファイル情報を用いて説明する。また、図5のブロック情報において、各ブロックは、X座標の小さい順、即ち、X1<X2<X3<X4<X5<X6に、ブロック1、ブロック2、ブロック3、ブロック4、ブロック5、ブロック6が管理されているとする。
以下、これらのブロック情報及び入力ファイル情報を使用して、ファイルサーバが管理するデータベース内から、入力ファイルに類似した電子ファイルを、レイアウト検索処理で検索する処理について、図10を用いて説明する。ここで、データベースで管理されている各電子ファイルには、図5と同様のファイル情報及びブロック情報が付与されていることを前提とする。また、レイアウト検索処理は、入力ファイルとデータベース中の電子ファイルを順次比較して実行される。
まず、ステップS510で、後述する類似率等を算出するための各種初期値の設定を行う。次に、ステップS511で、ブロック総数の比較を行う。ここで、入力ファイルの総ブロック数をn、データベース中の比較対象の電子ファイルの総ブロック数をN、誤差ΔNとすると、ここでの比較は、条件式N−ΔN<n<N+ΔNを満足するか否かを判定する。
ステップS511において、条件式を満足しない場合(ステップS511でNO)、ステップS526に進み、処理対象の電子ファイルを次の電子ファイルに設定して、ステップS510に戻る。一方、条件式を満足する場合(ステップS511でYES)、ステップS512以降の処理で、入力ファイルと比較対象の電子ファイル内のブロック情報に基づく比較を実行する。
まず、ステップS512で、ブロック情報に基づいて、入力ファイルと比較対象の電子ファイルそれぞれの処理対象のブロックのブロック属性を比較する。ブロック属性が不一致である場合、ステップS521に進み、比較対象の電子ファイルの総ブロック数N≧入力ファイルのブロック数nである場合には、処理対象のブロックとして、入力ファイルの次のブロックに設定する。一方、比較対象の電子ファイルの総ブロック数N<入力ファイルのブロック数nである場合には、処理対象のブロックとして、比較対象の電子ファイルの次のブロックに設定する。
一方、ステップS512において、ブロック属性が一致する場合、ステップS513に進み、属性類似率を算出して、その値を更新する。
ステップS514で、ブロック情報に基づいて、入力ファイルと比較対象の電子ファイルそれぞれの処理対象のブロックのサイズ(幅及び高さ)を比較する。ここで、入力ファイル中の処理対象のブロックの幅をw、高さをh、比較対象の電子ファイル中の処理対象のブロックの幅をW、その誤差ΔW、高さをH、その誤差ΔHとすると、ここでの比較は、条件式W−ΔW<w<W+ΔW及びH−ΔH<h<H+ΔHを満足するか否かを判定する。
尚、この条件式に加えて、ブロックの位置(X,Y)による比較を行うようにしても良い。
ステップS514において、条件式を満足しない場合(ステップS514でNO)、ステップS521に進む。一方、条件式を満足する場合(ステップS514でYES)、ステップS515に進み、サイズ類似率を算出して、その値を更新する。
ステップS516で、ブロック情報に基づいて、入力ファイルと比較対象の電子ファイルそれぞれの処理対象のブロックのOCR情報の有無を判定する。OCR情報がない場合(ステップS516でNO)、ステップS521に進む。一方、OCR情報がある場合(ステップS516でYES)、ステップS517に進み、OCR情報を比較する。
ステップS518で、OCR類似率を算出して、その値を更新する。ステップS519で、入力ファイルの中の全ブロックに対する比較処理が終了したか否かを判定する。比較処理が終了していない場合(ステップS519でNO)、ステップS520に進み、比較対象の電子ファイルの総ブロック数N≦入力ファイルのブロック数nである場合には、処理対象のブロックとして、入力ファイルの次のブロックに設定する。一方、比較対象の電子ファイルの総ブロック数N>入力ファイルのブロック数nである場合には、処理対象のブロックとして、比較対象の電子ファイルの次のブロックに設定する。
一方、ステップS519において、比較処理が終了している場合(ステップS519でYES)、ステップS522に進む。
ステップS522で、ステップS513、ステップS515、ステップS518で算出した各種類似率に基づいて、総合類似率を算出する。
尚、ステップS513、ステップS515、ステップS518の各種類似率の算出方法については、従来よりの公知の技術を用いて算出できるので、ここでは、その算出方法の詳細については省略する。
ステップS523で、総合類似率が所定閾値Thより大きいか否かを判定する。総合類似率が所定閾値Th未満である場合(ステップS523でNO)、ステップS526に進む。一方、総合類似率が所定閾値Thより大きい場合(ステップS523でYES)、ステップS524に進み、その電子ファイルを入力ファイルの類似候補として保存する。
次に、ステップS525で、データベース中の全電子ファイルに対する比較処理が終了したか否かを判定する。比較処理が終了していない場合(ステップS525でNO)、ステップS526に進む。一方、比較処理が終了している場合(ステップS525でYES)、処理を終了する。
以上の処理によって、総合類似度が閾値THより大きい電子ファイルが存在する場合、その電子ファイルは入力ファイルに類似する電子ファイル候補として確定する。そして、この電子ファイル候補を、図3のステップS127で出力することで、ユーザは所望する電子ファイルの選択を行うことができる。
[ベクトル化処理]
次に、図3のステップS129のベクトル化処理の詳細について説明する。
ベクトル化処理では、文字ブロック以外の図画あるいは線、表ブロックのベクトル化処理と、文字ブロックのベクトル化種類との2種類のベクトル化処理を実行し、その処理内容は大きく異なる。また、写真ブロックに対しては、そのままイメージデータとして、ベクトル化は実行しない。
そこで、まず、文字ブロック以外の図画あるいは線、表ブロックのベクトル化処理について、図11を用いて説明する。
図11は本発明の実施形態1の文字ブロック以外の図画あるいは線、表ブロックのベクトル化処理の詳細を示すフローチャートである。
文字ブロック以外の図画あるいは線、表ブロックのベクトル化処理では、まず、ステップS1001で、処理対象のブロックに対応するイメージデータに基づいて、そのブロックをアウトラインベクトルへ変換するアウトラインベクトル変換処理を実行する。
次に、ステップS1002で、得られるアウトラインデータから図形認識処理を実行する。
ここで、ステップS1001のアウトラインベクトル変換処理の詳細について説明する。
『アウトラインベクトル変換処理』
アウトラインベクトル変換処理では、文字ブロック以外の図画あるいは線、表ブロックについて、そのブロック中に対応するラスター画像データより抽出された画素塊の輪郭線(アウトライン)をベクトルデータに変換する。
具体的には、輪郭線(アウトライン)をなす画素の点列を角と看倣される点で区切って、各区間を部分的な直線あるいは曲線で近似する。角とは曲率が極大となる点であり、曲率が極大となる点は、図12に示すように、任意点Piに対し左右k個の離れた点Pi−k、Pi+kの間に弦を引いたとき、この弦とPIの距離が極大となる点として求められる。
また、Pi−k、Pi+k間の弦の長さ/弧の長さをRとし、Rの値が閾値以下である点を角とみなすことができる。角によって分割された後の各区間は、直線は点列に対する最小二乗法等の計算式を用いて、また、曲線は3次スプライン関数等の関数を用いてベクトル化することができる。
また、対象が内輪郭を持つ場合、BS処理で抽出した白画素輪郭の点列を用いて、同様に部分的直線あるいは曲線で近似する。
以上のように、輪郭の区分線近似を用いれば、任意形状の図形のアウトラインをベクトル化することができる。尚、原稿画像がカラー画像の場合は、そのカラー画像から図形の色を抽出してベクトルデータとともに記録する。
次に、ステップS1002の図形認識処理の詳細について説明する。
『図形認識処理』
図形認識処理では、ステップS1001で得られるアウトラインデータに対し、アウトラインから丸、楕円、四角、三角等の図形形状を認識して抽出する、もしくはアウトラインが構成している罫線、曲線等の図形形状を認識して抽出する。
具体的には、図13に示すように、ある区間で外輪郭と、内輪郭あるいは別の外輪郭が近接している場合、2つの輪郭線をひとまとめにし、太さを持った線として表現することができる。
そして、ある輪郭の各点Piから別輪郭上で最短距離となる点Qiまで線を引き、各距離PQiが平均的に一定長以下の場合、注目区間はPQi中点を点列として直線あるいは曲線で近似し、その太さはPQiの平均値とする。線や線の集合体である表罫線は、このような太さを持つ線の集合として効率よくベクトル表現することができる。
同様にして、点列の構成、また点と点とを結ぶ区分線の曲率から、丸、四角、三角等の図形形状を認識することができる。
次に、文字ブロックのベクトル化処理の詳細について、図14を用いて説明する。
図14は本発明の実施形態1の文字ブロックのベクトル化処理の詳細を示すフローチャートである。
まず、ステップS1011で、文字ブロックの文字認識処理を実行する。ステップS1012で、文字ブロックのフォント認識処理を実行する。ステップS1013で、文字ブロック中の文字画像のサイズに基づいて、文字ブロックをアウトライン化する文字ベクトル変換処理を実行する。ステップS1014で、文字ブロックに対してフォント化処理を実行する。
特に、実施形態1では、文字ブロック中の文字画像のサイズに基づいて、その文字画像をアウトラインベクトル化処理を実行することで、誤認識が生じやすい小さいサイズの文字画像は、一般的な線画と同じに扱い、文字認識ではなく、アウトラインベクトル変換する。
これにより、従来の文字認識処理で誤認識を起こす可能性のある文字が誤った文字にベクトル化されず、可視的にイメージデータに忠実なアウトライン化によるベクトル化を実現することができる。
ここで、ステップS1011の文字認識処理の詳細について説明する。
『文字認識処理』
文字認識処理では、文字ブロックから文字単位で切り出された文字画像に対し、パターンマッチの一手法を用いて文字認識を行い、対応する文字コードを取得する。特に、この文字認識処理は、文字画像から得られる特徴を数十次元の数値列に変換した観測特徴ベクトルと、あらかじめ字種毎に求められている辞書特徴ベクトルとを比較し、最も距離の近い字種を認識結果とする。
特徴ベクトルの抽出には種々の公知手法があり、例えば、文字をメッシュ状に分割し、各メッシュブロック内の文字線を方向別に線素としてカウントしたメッシュ数次元ベクトルを特徴とする方法がある。
そして、文字ブロックに対して文字認識処理を行う場合は、まず、該当文字ブロックに対し横書き/縦書きの判定を行い、各々対応する方向に文字列を切り出し、その後、文字列から文字を切り出して文字画像を取得する。
横書き/縦書きの判定は、該当文字ブロック内で画素値に対する水平/垂直の射影を取り、水平射影の分散が大きい場合は横書き、垂直射影の分散が大きい場合は縦書きと判定する。文字列及び文字への分解は、横書きの文字ブロックである場合には、その水平方向の射影を利用して行を切り出し、さらに切り出された行に対する垂直方向の射影から、文字を切り出すことで行う。一方、縦書きの文字ブロックに対しては、水平と垂直を逆にすれば良い。
尚、この文字認識処理によって、文字のサイズを検出することができる。
次に、ステップS1012のフォント認識処理の詳細について説明する。
『フォント認識処理』
フォント認識処理は、文字認識処理の際に用いる、字種数分の辞書特徴ベクトルを、文字形状種、即ち、フォント種に対して複数用意し、マッチングの際に文字コードとともにフォント種を出力することで、文字のフォントを認識する。
次に、ステップS1013の文字ベクトル変換処理の詳細について、図15を用いて説明する。
『文字ベクトル変換処理』
図15は本発明の実施形態1の文字ベクトル変換処理の詳細を示すフローチャートである。
尚、図15の処理単位は、文字認識処理により文字ブロックから分割された一文字分の文字画像とし、図15の処理では、文字ブロック内の全ての文字画像に対して実行する。但し、この処理は、一文字の画像画像毎に実行するのではなく、文字ブロック全体に対して実行するようにしても良い。
まず、ステップS1020で、文字認識処理及びフォント認識処理によって得られた処理結果の良否を判定する。処理結果が良の場合(ステップS1020でYES)、ステップS1024に進み、各文字画像に対応して予め用意されているフォントのアウトラインデータを用いて、文字部分のフォント情報を取得して、ベクトルデータに変換する。
一方、処理結果が否の場合(ステップS1020でNO)、ステップS1021に進み、文字サイズを検知する。
ステップS1022で、検知したサイズが設定された閾値未満であるか否かを判定する。閾値未満である場合(ステップS1022でNO)、その文字画像に対応するイメージデータを取得する。一方、閾値以上である場合(ステップS1022でNO)、ステップS1023に進み、その文字画像に対応するラスター画像データに基づいて、アウトラインベクトル変換処理を実行する。
尚、ステップS1021の文字サイズの検出については、ステップS1011の文字認識処理の際、文字サイズが検出されているため、これをそのまま使用してもよいが、より厳密に行うため、入力された文字画像のイメージデータより、縦サイズ、横サイズを抽出し、それを用いて、ステップS1022の処理を実行しても良い。
また、ステップ1023のアウトラインベクトル変換処理の詳細については、上述の文字ブロック以外の図画あるいは線、表ブロックに対するアウトラインベクトル変換処理と同様である。
また、処理対象の文字画像の文字サイズが閾値未満である場合に、アウトラインベクトル変換処理を実行せず、その文字画像のイメージデータを取得する理由は、文字サイズが小さい等の画像情報量が少ない場合には、その文字画像を直線、曲線近似することが困難となり、字形が歪む等の画質の劣化が生じてしまうからである。
そして、このような画質劣化を回避するために、文字サイズが閾値未満である場合には、アウトラインベクトル変換処理を実行せずに、処理対象の文字画像に対応するイメージ画像データを用いることにより画質の維持を実現することができる。
次に、ステップS1014のフォント化処理の詳細について説明する。
『フォント化処理』
フォント化処理では、文字ベクトル変換処理により得られたアウトラインベクトルデータ、もしくはイメージデータを用いて、各文字画像をフォントデータへ置換する。文字画像をフォントデータへ置換することで、文字ブロックは各文字が構成する文章として表現でき、編集可能となる。
具体的には、ステップS1024で得られたアウトラインベクトルデータはそのまま文字コード、フォント情報、文字サイズを用いてあらかじめ与えられているフォントへ置換することが可能である。また、ステップS1023で得られたアウトラインベクトルデータは、外字フォントのアウトラインフォントとして使用する。更に、文字サイズが閾値未満である場合のアウトラインベクトル変換されないイメージデータはそのまま、ラスターフォントとして使用する。
以上の処理により、細かな文章も含めた文字領域を含む文書でも、可視的にイメージデータに忠実であり、かつ編集可能なベクトルデータへ変換することが可能である。
また、ベクトル化対象の画像の画像サイズを検知し、その検知結果に応じてアウトラインベクトル変換処理の実行の可否を決定する構成は、文字画像のみに適用されるわけではなく、図画や線画等他の画像ブロックに対するアウトラインベクトル変換処理にも適用することが可能である。
つまり、画像サイズが閾値未満より小さくで、文字認識や図形認識の誤認識が生じる可能性のある画像ブロックに対しては、アウトラインベクトル変換処理を適用して、その画像ブロックの再現時の画質の劣化が生じることを防止することができる。
次に、図3のステップS130のアプリデータ変換処理の詳細について説明する。
[アプリデータ変換処理]
ここで、図3のステップS121のBS処理と、ステップS129のベクトル化処理の処理結果は、図16に示すような、中間データ形式のファイルとして変換されているが、このようなデータ形式は、ドキュメント・アナリシス・アウトプット・フォーマット(DAOF)と呼ばれる。
ここで、DAOFのデータ構造について、図16を用いて説明する。
図16は本発明の実施形態1のDAOFのデータ構造を示す図である。
図16において、Header791では、処理対象の原稿画像に関する情報が保持される。レイアウト記述データ部792では、原稿画像中のTEXT(文字)、TITLE(タイトル)、CAPTION(キャプション)、LINEART(線画)、PICTURE(自然画)、FRAME(枠)、TABLE(表)等の属性毎に認識された各ブロックの属性情報とその矩形アドレス情報を保持する。
文字認識記述データ部793では、TEXT、TITLE、CAPTION等のTEXTブロックを文字認識して得られる文字認識結果を保持する。
表記述データ部794では、TABLEブロックの構造の詳細を格納する。画像記述データ部795は、PICTUREやLINEART等のブロックのイメージデータを文書画像データから切り出して保持する。
このようなDAOFは、中間データとしてのみならず、それ自体がファイル化されて保存される場合もあるが、このファイルの状態では、所謂一般の文書作成アプリケーションで個々のオブジェクト(ブロック)を再利用することはできない。
そこで、実施形態1では、このDAOFから、文書作成アプリケーションで利用可能なアプリデータに変換するアプリデータ変換処理(ステップS130)の詳細について、図17を用いて説明する。
図17は本発明の実施形態1のステップS130の処理の詳細を示すフローチャートである。
まず、ステップS8000で、DAOFデータの入力を行う。次に、ステップS8002で、アプリデータの元となる文書構造ツリーを生成する。そして、ステップS8004で、文書構造ツリーを元に、DAOF内の実データを流し込み、実際のアプリデータを生成する。
次に、図17のステップS8002の処理の詳細について、図18及び図19を用いて説明する。
図18は本発明の実施形態1のステップS8002の処理の詳細を示すフローチャートである。また、図19は本発明の実施形態1の文書構造ツリーの説明図である。
尚、図18の処理において、全体制御の基本ルールとして、処理の流れは、ミクロブロック(単一ブロック)からマクロブロック(ブロックの集合体)へ移行する。
以後、ブロックとは、ミクロブロック及びマクロブロック全体を指す。
まず、ステップS8100で、ブロック単位で縦方向の関連性を元に再グループ化する。スタート直後は、ミクロブロック単位での判定となる。
ここで、関連性とは、距離が近い、ブロック幅(横方向の場合は高さ)がほぼ同一であることなどで定義することができる。また、距離、幅、高さなどの情報はDAOFを参照し、抽出する。
例えば、図19(a)は実際の原稿画像のページ構成、図19(b)はその文書構造ツリーである。ステップS8100の処理によって、ブロックT3、T4、T5が一つのグループV1、ブロックT6、T7が一つのグループV2が同階層グループとして、まず生成される。
ステップS8102で、縦方向のセパレータの有無をチェックする。セパレータとは、例えば、物理的にはDAOF中で線の属性を持つブロックである。また、論理的な意味としては、文書作成アプリケーション中で明示的にブロックを分割する要素である。ここでセパレータを検出した場合は、同じ階層で再分割する。
ステップS8104で、分割がこれ以上存在し得ないか否かを縦方向のグループ長を利用して判定する。具体的には、縦方向のグループ長が原稿画像のページ高さであるか否かを判定する。縦方向のグループ長がページ高さである場合(ステップS8104でYES)、処理を終了する。一方、縦方向のグループ長がページ高さでない場合(ステップS8104でNO)、ステップS8106に進む。
図19(a)の原稿画像の場合は、セパレータもなく、グループ長はページ高さではないので、ステップS8106に進む。
ステップS8106で、ブロック単位で横方向の関連性を元に再グループ化する。ここもスタート直後の第一回目はミクロブロック単位で判定を行うことになる。また、関連性、及びその判定情報の定義は、縦方向の場合と同じである。
図19(a)の原稿画像の場合は、ブロックT1、T2でグループH1、グループV1、V2でグループH2、グループV1、V2の階層の1つ上の同階層グループとして生成される。
ステップS8108で、横方向セパレータの有無をチェックする。図19(a)では、S1が横方向セパレータとなっているので、これを文書構造ツリーに登録し、H1、S1、H2という階層が生成される。
ステップS8110で、分割がこれ以上存在し得ないか否かを横方向のグループ長を利用して判定する。具体的には、横方向のグループ長がページ幅であるか否かを判定する。横方向のグループ長がページ幅である場合(ステップS8110でYES)、処理を終了する。一方、横方向のグループ長がページ幅でない場合(ステップS8110でNO)、ステップS8102に戻り、再びもう一段上の階層で、ステップS8100以降の処理を実行する。
図19の場合は、横方向のグループ長がページ幅となるので、ステップS8110で処理を終了し、最後に、ページ全体を表す最上位階層のV0が文書構造ツリーに付加される。
文書構造ツリーが完成した後、その文書構造ツリーに基づいて、図17のステップS8004で、アプリデータの生成を行う。
図19の場合は、具体的には、以下のようにして、アプリデータを生成する。
即ち、H1は横方向に2つのブロックT1とT2があるので、2カラムとして出力し、ブロックT1の内部情報(DAOFを参照、文字認識結果の文章、画像など)を出力し、その後、カラムを変え、ブロックT2の内部情報を出力、その後、S1を出力する。
次に、H2は横方向に2つのブロックV1とV2があるので、2カラムとして出力し、ブロックV1はT3、T4、T5の順にその内部情報を出力し、その後、カラムを変え、ブロックV2のT6、T7の内部情報を出力する。
以上のようにして、DAOFからアプリデータへの変換処理を実行する。
次に、図3のステップS135の処理の詳細について、図20を用いて説明する。
[ポインター情報付加処理]
図20は本発明の実施形態1のステップS135の処理の詳細を示すフローチャートである。
尚、図20では、例えば、ポインター情報としてのデータ文字列を、2次元バーコード(QRコードシンボル:JIS X0510)311にて符号化して、画像中に付加する処理について説明する。
また、2次元バーコード内に組み込むデータは、対応する電子ファイルのアドレス情報を表しており、例えば、ファイルサーバ名およびファイル名からなるパス情報で構成される。あるいは、対応する電子ファイルへのURL(URI)や、対応する電子ファイルの格納されているデータベース105内あるいはMFP100自体が有する記憶部111内で管理されるファイルID等で構成される。
まず、ステップS900で、符号化する種種の異なる文字を識別するため、入力データ列を分析する。また、誤り検出及び誤り訂正レベルを選択し、入力データが収容できる最小型番を選択する。
ステップS901で、入力データ列を所定のビット列に変換し、必要に応じてデータのモード(数字、英数字、8ビットバイト、漢字等)を表す指示子や、終端パターンを付加する。また、所定のビットコード語に変換する。
この時、誤り訂正を行うため、ステップS902で、コード語列を型番及び誤り訂正レベルに応じて所定のブロック数に分割し、各ブロック毎に誤り訂正コード語を生成し、データコード語列の後に付加する。
ステップS903で、ステップS902で得られた各ブロックのデータコード語を接続し、各ブロックの誤り訂正コード語、必要に応じて剰余コード語を後続する。
ステップS904で、マトリクスに位置検出パターン、分離パターン、タイミングパターン及び位置合わせパターン等とともにコード語モジュールを配置する。
ステップS905で、シンボルの符号化領域に対して最適なマスクパターンを選択して、マスク処理パターンをステップS904で得られたモジュールにXOR演算により変換するマスク処理を実行する。
ステップS906で、ステップS905で得られたモジュールに形式情報及び型番情報を生成して、2次元コードシンボルを完成する。
以上の処理によって、アドレス情報が組み込まれた2次元バーコードは、例えば、クライアントPC102から対応する電子ファイルをプリントデータとして印刷部112で印刷する場合に、データ処理部115内で記録可能なラスターデータに変換された後に、その電子ファイルのラスターデータ上の所定の個所に付加されて印刷される。ここで、2次元バーコード(ポインター情報)が印刷された印刷物(原稿)を、画像読取部110で読み取ることにより、そのポインター情報で特定されるオリジナル電子ファイルの格納場所を検出することができる。
尚、同様の目的で、ポインター情報を2次元バーコードで表現する以外に、例えば、直接文字列で電子ファイルに付加する方法、電子ファイル上の文字列、特に、文字と文字の間隔を変調して情報を埋め込む方法、電子ファイル中の中間調画像(サムネール画像)中に埋め込む方法等、一般に電子透かしと呼ばれる方法を適用することができる。
以上説明したように、実施形態1によれば、文字ブロックや線画ブロックのアウトライン化(アウトラインベクトル変換処理)に際して、処理対象のブロックのサイズに基づいて、アウトライン化するか否かを決定する。これにより、画像をアウトライン化することで画質が劣化する可能性のある比較的サイズが小さい画像については、アウトライン化処理の実行を禁止して、その画像そのもののイメージデータを保持するので、読取原稿画像に対応する電子データを管理する場合に、その画像の画質を維持することができる。
<実施形態2>
実施形態1では、アウトラインベクトル変換処理の実行の可否を、処理対象の画像のサイズに基づいて判定する構成としている。
一方、小さいサイズの文字画像等、元々情報量が少ないイメージデータでは、アウトラインベクトル変換することで、その変換後のベクトルデータが、元のイメージデータよりもそのデータ量が増える場合がある。
そこで、実施形態2では、変換前のイメージデータと、アウトラインベクトル変換処理後のベクトルデータとのデータ量を比較し、データ量が少ないデータ形式を、最終的に保存するデータとして選択することで、最終的に読取画像に対応する電子データを生成する際のデータ量の削減を図る構成について説明する。
この構成は、実施形態1のステップS129のベクトル化処理に対応し、以下、この実施形態2のステップS129のベクトル化処理の詳細について、図21を用いて説明する。
図21は本発明の実施形態2のステップS129の処理の詳細を示すフローチャートである。
尚、この処理は、BS処理によって得られたブロック毎に実行する。
まず、ステップS1031で、BS処理によって得られた処理対象のブロックに対し、アウトラインベクトル変換処理を実行する。
ステップS1032で、アウトラインベクトル変換処理前のブロックに対応するラスター画像データのデータ量が、アウトラインベクトル変換処理後のベクトルデータのデータ量以上であるか否かを判定する。
ラスター画像データのデータ量がベクトル画像データのデータ量以上である場合(ステップS1032でYES)、ステップS1034に進み、ステップS1031で生成したベクトルデータを選択する。一方、(1034)、ラスター画像データのデータ量がベクトル画像データのデータ量未満である場合(ステップS1032でNO)、ステップS1033に進み、アウトラインベクトル変換処理前のブロックに対応するラスター画像データを選択する。
尚、図21の処理は、実施形態2のステップS129の処理の詳細として説明したが、これに限定されない。例えば、実施形態1の図14のステップS1013の文字ベクトル変換処理として実行することも可能であるし、図11のステップS1001及び図15のステップS1023の少なくとも一方のアウトラインベクトル変換処理として実行することも可能である。
特に、アウトラインベクトル変換処理によるデータ量の増加は、文字サイズが小さい文字画像等の極めの細かい画像に発生し易いので、図21の処理を実行することで、読取原稿画像に対応する電子データを管理する場合に、その画質を維持したまま、データ量の増加を防止することができる。
以上説明したように、実施形態2によれば、文字ブロックや線画ブロックのアウトライン化(アウトラインベクトル変換処理)に際して、処理対象のブロックのアウトライン化後のデータ量に基づいて、アウトラインベクトルデータを使用するか、もしくはアウトラインデータを破棄して元のイメージデータを維持するかを判定する。これにより、画像をアウトライン化することで画像情報量が増加する可能性のある比較的サイズが小さい画像については、その画像そのもののイメージデータを保持するので、読取原稿画像に対応する電子データを管理する場合に、そのデータ量の増加を防止することができる。
また、イメージデータを保持する場合は、実施形態1と同様、サイズが小さい画像になる場合が多いので、実施形態1の効果を得ることができる。
以上説明した実施形態1や2で例示される本発明によれば、ベクトル化処理の処理対象の画像あるいは画像ブロックに関する情報(実施形態1の場合は画像サイズ、実施形態2の場合はデータ量)に基づいて、処理対象の画像のベクトル化処理の実行の是非を判定し、その判定結果に基づいて、処理対象の画像の電子データを、イメージデータとして保持するかベクトルデータとして保持するかを決定する。
これにより、特に、ベクトル化処理によって起因する画質の劣化やデータ量の増加を防止することができる。
以上、実施形態例を詳述したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
尚、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラム(実施形態では図に示すフローチャートに対応したプログラム)を、システムあるいは装置に直接あるいは遠隔から供給し、そのシステムあるいは装置のコンピュータが該供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。
従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、OSに供給するスクリプトデータ等の形態であっても良い。
プログラムを供給するための記録媒体としては、例えば、フロッピー(登録商標)ディスク、ハードディスク、光ディスク、光磁気ディスク、MO、CD−ROM、CD−R、CD−RW、磁気テープ、不揮発性のメモリカード、ROM、DVD(DVD−ROM,DVD−R)などがある。
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、該ホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるWWWサーバも、本発明に含まれるものである。
また、本発明のプログラムを暗号化してCD−ROM等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される他、そのプログラムの指示に基づき、コンピュータ上で稼動しているOSなどが、実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現され得る。
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるCPUなどが実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現される。