JP4748734B2 - 原稿読取装置 - Google Patents

Description

本発明は、原稿読取装置に関し、特に、ディジタル複写機やスキャナやMFP等において、原稿を読み取った画像データを符号化して蓄積する原稿読取装置に関する。

コピー機能やFAX機能やプリンタ機能やスキャナ機能等を備えた複合機であるカラーMFP機などでは、スキャナで原稿を読み取り、読み取った画像データを画像処理して符号化し、入力画像を得ている。このような技術の従来例として、特許文献１に開示された画像読取装置がある。これは、１スキャンで必要なデータを高速に得ることができるものである。読取原稿は、カラー原稿かモノクロ原稿である。カラー原稿のときはRGB多値データを出力し、モノクロ原稿のときはモノクロ２値データを出力する。

原稿の読取りが開始され、原稿読込みが終了すると、ACS（自動カラーセレクト）の結果を読み出す。読み取った原稿がカラー原稿であると判明した場合には、画像メモリに格納されたRGBの多値データを使用し、２値データは無効として捨てる。一方、読み取った原稿がモノクロ原稿と判明した場合は、画像メモリに格納されたＫ（黒）の２値データを選択して使用し、RGBの多値データは無効として捨てる。このことにより、Ｇ（緑）の多値データから２値データへの変換のためのソフトウエア処理が不要となり、高速化が可能となる。

図６〜図８を参照しながら、従来の画像処理装置について説明する。図６（ａ）に、従来の画像処理装置の機能ブロック図を示す。原稿を光学的に読み取る読取ユニット１は、原稿にランプ照射した反射光を、ミラーとレンズで受光素子に集光する。CCDなどの受光素子が、センサーボードユニット（SBU）２に搭載されている。CCDにおいて電気信号に変換された画像信号は、ディジタル信号に変換された後、SBU２から出力される。SBU２から出力される画像信号は、画像処理プロセッサ（IPU）３に転送される。スキャナ系における信号劣化、すなわち、光学系における信号劣化と、ディジタル信号への量子化に伴う信号劣化が補正されて、圧縮／伸張とデータインターフェース制御を行う画像データ制御部（CDIC）４に入力される。機能デバイス間とデータバス間における画像データの伝送は、CDIC４が全て制御する。CDIC４は、SBU２とパラレルバス10とIPU３間の画像データ転送を行い、全体制御を司るシステムコントローラ12とプロセスコントローラ22間で、画像データの通信を行う。

IPU３からCDIC４へ転送されたデータは、CDIC４からパラレルバス10を経由して画像メモリアクセス制御部（IMAC）11に送られる。IMAC11では、システムコントローラ12の制御に基づき、画像データとメモリ（MEM）14のアクセス制御と、ネットワーク15に接続された外部パソコンからのプリント用データの展開と、メモリ有効活用のための画像データの圧縮／伸張を行う。IMAC11へ送られたデータは、データ圧縮後、メモリ14へ蓄積される。蓄積データは必要に応じて読み出される。読み出されたデータは伸張されて、本来の画像データに戻され、IMAC11からパラレルバス10経由でCDIC４へ戻される。CDIC４からIPU３へ転送された後、IPU３により画質処理されて、ビデオデータ制御部（VDC）５でパルス制御され、作像ユニット６において転写紙上に再生画像が形成される。CDIC４の制御により、画像データがパラレルバス10を介して転送されて、MFPの機能が実現される。

コピーとスキャナとプリンタ出力の複数ジョブが並行に処理されるときに、システムコントローラ12とプロセスコントローラ22の制御により、読取ユニット１と作像ユニット６とパラレルバス10の使用権が、各ジョブに割り振られる。プロセスコントローラ22は、画像データの流れを制御する。システムコントローラ12は、システム全体を制御して各リソースの起動を管理する。操作パネル16によりMFPの機能を選択して、コピーやスキャンなどの処理内容を設定する。

システムコントローラ12とプロセスコントローラ22は、パラレルバス10とCDIC４とシリアルバス21を介して、相互に通信を行う。パラレルバス10とシリアルバス21との間のデータインターフェースのために、CDIC４内でデータフォーマット変換を行う。スキャナ機能では、読取ユニット１とセンサーボードユニット２で、原稿を読み取る。読み取られた原稿画像データは、IPU３で画質処理が行われ、CDIC４からパラレルバス10とIMAC11を介して、メモリ14あるいはハードディスク（HDD）13に格納される。必要に応じて、そこからネットワーク15を介してパソコンに原稿画像データが送られる。

図６（ｂ）に、IPU３の画像処理の概略を示す。読取画像は、SBU２を介してIPU３の入力I/Fからスキャナ画像処理部へ伝達される。スキャナ画像処理は、読取画像信号の劣化補正が目的であり、シェーディング補正やスキャナγ補正やMTF補正等が行われる。読取画像データの補正処理終了後、出力I/Fを介してCDIC４へ画像データが転送される。転写紙への出力の場合は、CDIC４からの画像データを入力I/Fで受けて、画質処理部において面積階調処理を行う。画質処理後のデータは、出力I/Fを介してVDC５へ出力される。面積階調処理には、濃度変換とディザ処理と誤差拡散処理等が有り、主に階調を面積で近似する処理をする。

スキャナ画像処理された画像データをメモリ14に蓄積しておけば、画質処理を変えることによって、種々の再生画像を生成して確認できる。例えば、再生画像の濃度を変えてみたり、ディザマトリクスの線数を変更してみたりすることで、再生画像の雰囲気を変更できる。この時、処理を変更する度に、画像を読取ユニットから読み込み直す必要はなく、メモリ14から格納画像を読み出せば、同一データに対して何度でも異なる処理を施すことができる。また、単体スキャナの場合、スキャナ画像処理と階調処理を合わせて施してCDIC４へ出力する。処理の切り替えや処理手順の変更等は、コマンド制御部で管理する。

図６（ｃ）に、CDIC４の概略の機能ブロック図を示す。IPU３でスキャナ画像補正されたデータが、画像データ入力制御部に入力される。パラレルバス10での転送効率を高めるために、入力データはデータ圧縮部で圧縮されて、パラレルデータI/Fを介してパラレルバス10へ送出される。パラレルバス10からパラレルデータI/Fを介して入力される画像データは、バス転送のために圧縮されており、データ伸張部で伸張される。伸張された画像データは、画像データ出力制御部でIPU３へ転送される。CDIC４は、パラレルデータとシリアルデータの変換機能を併せ持つ。システムコントローラ12は、パラレルバス10にデータを転送し、プロセスコントローラ22は、シリアルバス21にデータを転送する。２つのコントローラ間での通信のために、データ変換を行う。

図６（ｄ）に、VDC５の概略の機能ブロック図を示す。入力される画像データに対し、作像ユニットの特性に応じて、追加の処理を行う。エッジ平滑処理によるドットの再配置処理や、ドット形成のための画像信号のパルス制御を行う。画像データは、作像ユニットに出力される。画像データの変換とは別に、パラレルデータとシリアルデータのフォーマット変換機能を併せ持つ。VDC５単体でも、システムコントローラ12とプロセスコントローラ22との間の通信に対応できる。

図６（ｅ）に、画像メモリアクセス制御部（IMAC）11の概略の機能ブロック図を示す。パラレルデータI/F部は、パラレルバス10を介する画像データの入出力を管理する。構成的には、メモリ14への画像データの格納と読出しを行うものである。外部パソコンから入力されるコードデータを画像データへ展開する。入力されたコードデータは、ラインバッファに一旦格納される。ラインバッファに格納されたコードデータは、システムコントローラ12からシステムコントローラI/Fを介して入力された展開処理命令に基づき、ビデオ制御部で画像データに展開される。展開された画像データや、パラレルデータI/Fを介してパラレルバス10から入力された画像データは、メモリ14に格納される。このとき、格納対象となる画像データをデータ変換部で選択する。メモリ使用効率を上げるために、データ圧縮部でデータの２次圧縮を行う。メモリアクセス制御部で、メモリ14のアドレスを管理しながら、メモリ14に画像データを格納する。メモリ14に格納された画像データを読み出すときは、メモリアクセス制御部で読出先アドレスを制御して読み出し、読み出された画像データを、データ伸張部で伸張する。伸張された画像データは、パラレルデータI/Fを介してパラレルバス10へ転送される。

ここで、JPEG符号化について示す。なお、JPEGは規格化された汎用フォーマットであるため、詳細については省略する。図７（ａ）に、JEPG符号の処理を示す。まず、RGB画像データに色変換処理が施される。RGBの輝度信号が、色差信号から成るYCbCrフォーマットの信号に変換される。サブサンプリングにより色差信号が削減される。輝度信号と色差信号がDCT変換される。量子化処理と可変長符号化がされる。これらの信号の先頭にヘッダ等が追加され、JPEG符号として出力される。

図７（ｂ）は、JPEGの符号化データの内容を示したものである。基本的には、イメージとフレームとスキャンの３階層の構造になっている。ここでは、基本的なベースラインシステムについて示してある。１枚の画像は、SOIコードとEOIコードに挟まれた構成となっている。各略号の内容は、以下の通りである。SOI：画像開始マーカーであり、符号化される画像の開始を示す。DP：定義パラメータ群であり、ハフマンテーブルや量子化テーブルの指定など各パラメータ群を示す。EOI：画像終了マーカーであり、符号化される画像の終了を示す。SOF：フレーム開始マーカーであり、フレームヘッダの始まりを示し、フレームの先頭に配置される。SOS：スキャン開始マーカーであり、スキャンパラメータの始まりを示す。Data：画像データ符号を示す。RST0、RST1など：再同期符号を示す。

図７（ｃ）に、フレームヘッダの構造を示す。各略号の内容は以下の通りである。Lf：Lfを含む全てのパラメータのバイト数を示す。Ｐ：入力画像の１画素当たりのビット数を示す。ここでは８ビットとする。Ｙ：画像のライン数を示す。ライン数の範囲は、0〜65535ラインとなる。Ｘ：１ラインの画素数を示す。１〜65535画素となる。Nf：フレーム内の色成分数を示す。CSP：コンポーネントのパラメータ群を示す。成分番号、色成分の水平方向のサンプリング比、色成分の垂直方向のサンプリング比、色成分が用いる量子化テーブル番号等を示す。

図７（ｄ）に、A3用紙までのコピーとスキャンとプリントが可能な一般的なMFPの外観を示す。また、図７（ｅ）に、広幅複合機能ディジタル複写機の外観を示す。図７（ｄ）の複写機は概略、自動原稿送り装置(ADF)と、操作パネル(OPB)と、スキャナ(SCR)と、プリンタ(PTR)と、ステープラ及び作像された用紙を搭載可能なトレイ付きのフィニッシャと、給紙バンクの各ユニットで構成されている。画像データ処理装置は、LAN(Local Area Network)でパソコンと接続されている。プリンタでプリント済みの用紙は、排紙トレイ上またはフィニッシャに排出される。

図７（ｅ）の広幅MFPでは、定型サイズとしては、A0用紙までのコピーとスキャンとプリントが可能である。また、特殊サイズである長尺ものに対応しており、A0幅（841mm）で15ｍまでの長さのもののコピーとスキャンとプリントが可能である。図７（ｄ）のA3用MFPでは、自動原稿読取装置(ADF)に原稿をセットするとADF上に設置されたセンサーで原稿サイズを自動検知する。ところが、図７（ｅ）の広幅MFPでは、原稿が大きいため、センサーによる自動検知はできない。したがって、ユーザーが予め原稿サイズを操作パネル(OPB)上で指定するか、読み取った後に、入力された原稿サイズで判定する。広幅MFPでは、最大15ｍまでの様々なサイズの長尺原稿が読み込まれる。そのため、実際に読取った後に入力された原稿長を判断する場合が多い。

次に、図８を参照しながら、広幅MFPで原稿サイズをユーザーが指定して、予め原稿長がわかる場合のスキャン方法を説明する。スキャナアプリでは、画像をJPEGやTIFFなどの汎用フォーマットに符号化する。ここでは、カラー画像をJPEG符号化する。図８（ａ）は、図６（ａ）に示した構成でスキャンを実行する場合の画像データの流れを示したものである。図８（ｂ）は、この場合の処理フローである。パス〔１〕に示すように、原稿読取りが開始されると、読取ユニットで読み込まれた原稿画像のRGBデータは、SBU２とIPU３に送信され、IPU３でスキャナ補正される。その後、CDIC４とパラレルバス10とIMAC11に送られ、メモリ14に蓄積される。この動作は、原稿読取りが終了するまで続けられる。終了すると、パス〔２〕に示すように、システムコントローラ12の処理により、メモリ14に蓄積されたRGB画像をJPEG符号に変換する。原稿読取りが終了してからJPEG変換が行われるのは、ライン数が未知の場合の動作と合わせるためである。パス〔３〕で示すように、JPEG符号化が終了すると、HDD13に蓄積される。あるいは、ネットワーク15を介してPCに送信される場合もある。図８（ｂ）の処理フロー中の番号〔１〕〜〔３〕の処理は、図８（ａ）の画像パスと対応させてある。

次に、図９を参照しながら、長尺原稿など、予め原稿のライン数が指定できない場合のスキャン方法を説明する。図９（ａ）に、長尺原稿など、予め原稿のライン数が指定できない場合におけるスキャン時の画像パスを示す。図９（ｂ）に、処理フローを示す。パス〔１〕に示すように、原稿読取りが開始されると、読取ユニットで読み込まれた原稿画像のRGBデータは、SBU2とIPU３に送信され、IPU３でスキャナ補正される。その後、CDIC４とパラレルバス10とIMAC11に送られ、メモリ14に蓄積される。この動作は、原稿読取りが終了するまで続けられる。終了すると、パス〔２〕に示すように、入力されたライン数をCDIC４でカウントする。この情報を、プロセスコントローラ22が読み取る。パス〔３〕に示すように、このライン数を、システムコントローラ12に送信する。パス〔４〕に示すように、送られてきたライン数を使用し、システムコントローラ12の処理で、メモリ14に蓄積されたRGB画像をJPEG符号に変換する。パス〔５〕に示すように、JPEG符号化が終了すると、JPEG符号がメモリ14からHDD13に転送されて蓄積される。図９（ｂ）の処理フロー中の番号〔１〕〜〔５〕の処理は、図９（ａ）の画像パスと対応している。
特開2005-348170号公報

しかし、上記従来の広幅MFPでのスキャン方法では、次のような問題がある。まず、図９（ａ）のメモリ14の容量である。ここでは、A0原稿と長尺原稿の場合を考えるが、比較のために、A3MFP機の最大原稿サイズであるA3原稿も示す。600dpi（dot
per inch）の解像度で読み取る。１画素８ビットでのカラー原稿（RGB）とする。JPEG符号のライン数は、最大で65535ラインであるので、長尺原稿のライン数は、65535ラインとする。解像度600dpiでの65535ラインは、2774mmとなる。

原稿 サイズ(主走査×副走査) 画素数×ライン数 必要なメモリ容量
A3 297mm×420mm 7016×9921 199MB
A0 841mm×1189mm 19866×28087 1596MB(約1.6GB)
長尺 841mm×2774mm 19866×65535 3725MB(約3.7GB)

A3サイズ原稿では199MBと多くはないが、A0サイズ原稿では約1.6GB、JPEG符号化が可能な長尺原稿では、実に3.7GBとかなり多くなる。MFPのコントローラに搭載されているメモリ容量は、378MB〜２GBである。システムコントローラ(CPU)12のプログラムやデータ領域やワーク領域を確保すると、スキャナアプリに使用できるメモリ容量は１GBぐらいとなる。これでは、A0原稿も無理で、A0原稿の半分のA1サイズ原稿ぐらいが実現できる最大サイズとなる。

符号化実行時においては、原稿の読取りが終了し、原稿サイズが判明してから符号化を開始する。原稿読取り時間について述べる。広幅MFP機における原稿の読取り速度を、比較的高速な100mm/sとする。これは、広幅原稿を１秒間で100mm読むということである。
原稿 サイズ(主走査×副走査) 読取りに必要な時間
A3 297mm×420mm 4.2ｓ
A0 841mm×1189mm 11.9ｓ
長尺 841mm×2774mm 27.7ｓ

次に、X86プロセッサによる符号化(圧縮)速度を考える。例えば、X86プロセッサ(１GHz)による圧縮速度を約45MB/sとすると、以下のようになる。
原稿 サイズ(主走査×副走査) 画像容量 圧縮時間
A3 297mm×420mm 199MB 4.4ｓ
A0 841mm×1189mm 1596MB 35.5ｓ
長尺 841mm×2774mm 3725MB 82.8ｓ

次に、スキャナアプリの生産性について述べる。スキャナアプリの生産性は、１分間当たりの読取り枚数SPM（Scan Per Minute）で定義される。１枚の原稿を符号化するのに必要な時間は、読取り時間＋圧縮時間であるから、スキャナ生産性は以下の通りとなる。
原稿 サイズ(主走査×副走査) 読取り時間＋圧縮時間 スキャナ生産性
A3 297mm×420mm 8.6s 7.0SPM
A0 841mm×1189mm 47.4s 1.3SPM
長尺 841mm×2774mm 110.5s 0.5SPM

以上のことから、A3原稿では１分間当たりの生産性は7.0SPMとなる。ところが、A0原稿になると生産性は1.3SPMとなり、１分間に１枚強しか読み取れない。長尺原稿では生産性は0.5SPMとなり、１枚の処理に約２分間もかかる。ユーザーは、読取り原稿をセットしてから読み終わるまで、これだけの時間待たされることになり、甚だ使いづらくなる。以上は、原稿を600dpiで読み取る場合である。300dpiに解像度を落とすとデータ量が減るため、生産性は向上する。しかしながら、設計図面など細線で書かれた大きな原稿は、600dpiの高画質で読み込む必要があり、その場合、上記の問題が発生する。原稿サイズが指定されない未知サイズの原稿の場合に、読取りが終了しないとライン数が判明しないので、画像の符号化が開始できず、生産性が上がらない。

本発明の目的は、上記従来の問題を解決して、広幅MFP機において、スキャン時の符号化を高速化することである。

請求項１の発明は、原稿画像を読み取る読取手段と、読み取った原稿画像から得られた画像データを符号化して符号化データを生成する符号化手段と、前記符号化データを格納する画像メモリと、前記原稿画像の読取りと符号化を制御するコントローラと、を具備する原稿読取装置であって、前記符号化手段は、原稿画像の原稿送り方向のサイズを示すライン数をカウントする手段と、原稿送り方向のサイズが未知の原稿の画像データを、仮のライン数で符号化する手段と、前記原稿画像の前記カウントしたライン数が予め設定されたライン数を超えた時点でその旨を前記コントローラに通知する手段と、原稿読取終了時にライン数を確定する手段と、を備え、前記コントローラは、確定したライン数で符号化データ中の仮のライン数を置き換える手段を備えることを特徴とする原稿読取装置である。
請求項２の発明は、前記符号化手段は、原稿画像のライン数が確定した時点で前記コントローラにライン数を通知する手段を備え、前記コントローラは、確定したライン数を含むヘッダ部を生成する手段を備えることを特徴とする請求項１記載の原稿読取装置である。
請求項３の発明は、前記符号化手段は、原稿画像のライン数が確定した時点で確定したライン数を含むヘッダ部を生成する手段と、前記ヘッダ部を前記コントローラに送信する手段とを備えることを特徴とする請求項１記載の原稿読取装置である。
請求項４の発明は、前記符号化手段は、前記画像メモリ中の仮のライン数を含むヘッダ部のアドレスを指定して前記コントローラにライン数を含むヘッダ部を送信する手段を備えることを特徴とする請求項３記載の原稿読取装置である。
請求項５の発明は、前記符号化手段は、原稿の画像データの符号化が間に合わなくなってバッファオーバフローが発生したことを検知する手段と、バッファオーバフロー発生を前記コントローラに通知する手段とを備えることを特徴とする請求項１記載の原稿読取装置である。
請求項６の発明は、前記コントローラは、バッファオーバフロー発生の通知の受信に応じて、原稿の読取解像度を落とすか圧縮率を上げる必要があることを表示するように操作パネルに通知する手段を備えることを特徴とする請求項５記載の原稿読取装置である。
請求項７の発明は、原稿画像を読み取る読取手段と、読み取った原稿画像から得られた画像データを符号化して符号化データを生成する符号化手段と、前記符号化データを格納する画像メモリと、前記原稿画像の読取りと符号化を制御するコントローラと、を具備する原稿読取装置における原稿読取方法であって、前記符号化手段で行う符号化工程において、原稿画像の原稿送り方向のサイズを示すライン数をカウントし、原稿送り方向のサイズが未知の原稿の画像データを、仮のライン数で符号化し、前記原稿画像の前記カウントしたライン数が予め設定されたライン数を超えた時点でその旨を前記コントローラに通知し、原稿読取終了時にライン数を確定し、前記コントローラで行う制御工程において、確定したライン数で符号化データ中の仮のライン数を置き換えることを特徴とする原稿読取方法である。
請求項８の発明は、前記符号化工程において、原稿画像のライン数が確定した時点で前記コントローラにライン数を通知し、前記制御工程において、確定したライン数を含むヘッダ部を生成することを特徴とする請求項７記載の原稿読取方法である。
請求項９の発明は、前記符号化工程において、原稿画像のライン数が確定した時点で確定したライン数を含むヘッダ部を生成し、前記ヘッダ部を前記コントローラに送信することを特徴とする請求項７記載の原稿読取方法である。
請求項１０の発明は、前記符号化工程において、前記画像メモリ中の仮のライン数を含むヘッダ部のアドレスを指定して前記コントローラにライン数を含むヘッダ部を送信することを特徴とする請求項９記載の原稿読取方法である。
請求項１１の発明は、前記符号化工程において、原稿の画像データの符号化が間に合わなくなってバッファオーバフローが発生したことを検知し、バッファオーバフロー発生を前記コントローラに通知することを特徴とする請求項７記載の原稿読取方法である。
請求項１２の発明は、前記制御工程において、バッファオーバフロー発生の通知の受信に応じて、原稿の読取解像度を落とすか圧縮率を上げる必要があることを表示するように操作パネルに通知することを特徴とする請求項１１記載の原稿読取方法である。

上記のように構成したことにより、原稿送り方向のサイズが未知の原稿画像の読取りと同時に符号化ができるので、必要なメモリ容量が削減でき、読取生産性も向上する。

以下、本発明を実施するための最良の形態について、図１〜図５を参照しながら詳細に説明する。

本発明の実施例は、サイズが未知の原稿を読み取りながら、画像データを仮のライン数で符号化して画像メモリに格納し、原稿読取終了時に、確定したライン数のヘッダで仮のライン数のヘッダを置き換える原稿読取装置である。

図１は、本発明の実施例における原稿読取装置を備えた画像処理システムの概念図である。基本的な構成は、図６（ａ）に示した従来のシステム構成と同様であるが、画像処理プロセッサIPU３と画像データ制御部（CDIC）４の間に、画像符号化モジュール（ICM）７とバッファメモリ（BMEM）８を設けた点が異なる。図１（ａ）は、画像処理システムの機能ブロック図である。図１（ｂ）は、画像符号化モジュール（ICM）の構成を示す機能ブロック図である。図１（ｃ）は、画像処理プロセッサ（IPU）から画像符号化モジュール（ICM）への入力信号を示す図である。図１（ｄ）は、タイミングチャートである。

図１において、読取ユニット１は、原稿を読み取るスキャナである。センサーボードユニット（SBU）２は、読取画像をアナログ信号からディジタル信号に変換する手段である。画像処理プロセッサ（IPU）３は、スキャナ画像の補正処理と画質処理を行う手段である。画像データ制御部（CDIC）４は、圧縮伸張とデータ変換を行う手段である。ビデオデータ制御部（VDC）５は、作像ユニットに応じた画像処理を行う手段である。作像ユニット６は、画像データを可視画像にするプリンタなどである。画像符号化モジュール（ICM）７は、画像データの符号化を行う手段である。バッファメモリ（BMEM）８は、画像データの一時記憶手段である。パラレルバス10は、画像データなどを並列転送する共通母線である。

画像メモリアクセス制御部（IMAC）11は、画像データを圧縮伸張して画像メモリにアクセスする手段である。システムコントローラ（CPU）12は、システム全体を制御して各リソースの起動を管理する手段である。ハードディスク（HDD）13は、画像データを蓄積するファイル装置である。メモリ（MEM）14は、画像データを記憶するメモリである。ネットワーク15は、LANやインターネットなどの通信網である。操作パネル16は、ユーザーが装置を操作するための入出力手段である。ROM17は、装置制御のためのプログラムやパラメータを格納した固定記憶装置である。シリアルバス21は、画像データなどを直列転送する共通母線である。プロセスコントローラ22は、画像データの流れを制御する手段である。RAM23は、画像データなどを一時的に記憶するメモリである。ROM24は、プログラムやパラメータを格納した固定記憶装置である。

画像データ入力制御部71は、画像データの入力インタフェースである。メモリアクセス制御部72は、バッファメモリとのインタフェースである。画像データ符号化部73は、画像データの符号化を行う手段である。セレクタ74は、符号化された画像データと入力画像データを選択する回路である。画像データ出力制御部75は、画像データの出力インタフェースである。コマンド制御部76は、画像データの入力状態をプロセスコントローラに通知する手段である。

図２は、原稿の読取りを説明する図である。図２（ａ）は、定型サイズの原稿を読み取るときのイメージである。図２（ｂ）は、長尺原稿を読み取るときのイメージである。図２（ｃ）は、入力制御を行う画像データ入力制御部の様子を示す図である。図２（ｄ）は、入力制御シーケンサの状態遷移図である。図３は、定型サイズ原稿の符号化方法の説明図である。図３（ａ）は、定型サイズ原稿を読み取って符号化する場合の画像データの流れを示す図である。図３（ｂ）は、そのフローチャートである。図４は、サイズ未知の原稿の符号化方法の説明図である。図４（ａ）は、サイズ未知原稿を読み取って符号化する場合の画像データの流れを示す図である。図４（ｂ）は、そのフローチャートである。図５は、サイズ未知の原稿の別の符号化方法の説明図である。図５（ａ）は、読取り終了後の符号生成を画像符号化モジュールで行う場合の画像データの流れを示す図である。図５（ｂ）は、そのフローチャートである。

上記のように構成された本発明の実施例における原稿読取装置の機能と動作を説明する。最初に、図１（ａ）を参照しながら、原稿読取装置の機能の概要を説明する。基本的な機能は従来の原稿読取装置と同じである。画像データの符号化に関する機能が従来と異なる。コントローラであるシステムコントローラ（CPU）12とプロセスコントローラ22で、原稿画像の読取りと符号化を制御する。読取ユニット１で、原稿画像をスキャンして読み取り、センサーボードユニット（SBU）２と画像処理プロセッサ（IPU）３を介して、画像符号化モジュール（ICM）７に画像データを送る。読取ユニット１とセンサーボードユニット（SBU）２と画像処理プロセッサ（IPU）３で、読取手段を構成している。

符号化手段である画像符号化モジュール（ICM）７とバッファメモリ（BMEM）８で、画像データを符号化して、符号化データを、画像メモリであるメモリ（MEM）14に格納する。このとき、原稿画像のライン数をカウントしながら、原稿送り方向のサイズが未知の原稿の画像データを、紙送り方向のサイズを示すライン数を仮のライン数として符号化する。原稿読取終了時にライン数が確定すると、確定したライン数のヘッダ部で、符号化データ中の仮のライン数のヘッダ部を置き換える。符号化した画像データを、画像メモリであるハードディスク（HDD）13に格納する。ライン数は、ヘッダ部以外にあってもよいが、ここでは代表してヘッダ部ということにする。

画像符号化モジュール（ICM）７は、原稿画像のライン数が確定した時点で、プロセスコントローラ22にライン数を通知する。システムコントローラ12は、確定したライン数を含むヘッダ部を生成する。または、確定ライン数を含むヘッダ部を、画像符号化モジュール（ICM）７で生成して、メモリ（MEM）14中の仮のライン数を含むヘッダ部のアドレスを指定して、システムコントローラ12に、ライン数を含むヘッダ部を送信する。画像符号化モジュール（ICM）７は、符号化データ量をカウントして、システムコントローラ12に通知する。予め設定された符号量を超えた時点で、その旨をシステムコントローラ12に通知する。また、原稿画像のライン数が予め設定されたライン数を超えた時点で、その旨をシステムコントローラ12に通知する。原稿の画像データの符号化が間に合わなくなって、バッファオーバフローが発生したことを検知すると、バッファオーバフロー発生をシステムコントローラ12に通知する。システムコントローラ12は、バッファオーバフロー発生の通知の受信に応じて、原稿の読取解像度を落とすか圧縮率を上げる必要があることを表示するように操作パネルに通知する。

次に、図１（ｂ）を参照しながら、画像符号化モジュール（ICM）の機能を説明する。画像データ入力制御部71は、入力されるRGB画像データの入力I/Fの機能を担うと共に、入力ライン数(NLINE)と原稿読取り終了(READ_END)を検知し、これらの情報をコマンド制御部76に送信し、図１（ａ）に示すプロセスコントローラ22に通知する。メモリアクセス制御部72は、画像データ入力制御部71から出力された画像データを外部のバッファメモリ８に書き込み、符号化開始時にバッファメモリから画像データを読み出し、画像データ符号化部73に出力する。画像データ符号化部73は、メモリアクセス制御部72から入力される画像データの符号化を行い、セレクタ74に出力する。符号化方式として一般的なJPEG符号化の場合は、処理フローは図３（ｂ）に示すようになる。符号構造は図７（ｂ）と（ｃ）に示した。

セレクタ74は、符号化時は、画像データ符号化部73からの符号化データを選択し、画像データ出力制御部75に出力する。符号化を行わない場合は、画像データ入力制御部71からの画像データを選択し、画像データ出力制御部75に出力する。画像データ出力制御部75は、セレクタ74から入力される画像データを出力するための制御を行う。

次に、図１（ｃ）と（ｄ）を参照しながら、画像処理プロセッサ（IPU）３から画像符号化モジュール（ICM）７への入力信号を説明する。FGATEBは、原稿の紙送り方向のサイズを示す信号である。‘Ｌ’信号入力の期間が、原稿の画像データが転送されている期間を示す。LGATEBは、１ラインの信号の有効期間を示す。‘Ｌ’信号入力時に、ラインデータが転送されていることを示す。RD、GD、BD信号はそれぞれ、RGB信号のＲ(レッド)、Ｇ(グリーン)、Ｂ(ブルー)信号のデータを示す。LGATEBが‘Ｌ’（アサート）の時に、それぞれRGBのデータを転送していることを示す。図１（ｄ）に示すタイミングチャートで転送する。

次に、図２（ａ）を参照しながら、A4やA3、A1やA0といった定型サイズの原稿を読み取る方法を説明する。(a-1)で示す原稿を読み取る際のスキャナデータは、(a-2)で示すようなFGATEBの形状となり、副走査方向Ｙが紙送り方向となる。この副走査方向に直角な方向が主走査方向で、その大きさは１ラインの画素数を示すことになる。この定型サイズ原稿を読み取る際は、ユーザーが予め走査パネル上で原稿サイズを指定することもできるし、読取り時に副走査方向のライン数を検知することで原稿サイズを知ることもできる。

次に、図２（ｂ）を参照しながら、定型サイズ原稿ではなく、副走査方向が大きな長尺原稿の場合の原稿を読み取る方法を説明する。このような長尺原稿では、原稿サイズは定型ではなく不定型ということであるので、読取り時に副走査方向のライン数を検知することで、原稿サイズを知るようにすることが一般的である。このとき入力された原稿長を示すライン数は、図１（ｂ）で示す画像データ入力制御部71にてカウントされ、原稿の情報としてシステムコントローラ12に通知されることになる。

次に、図２（ｃ）と（ｄ）を参照しながら、これらの入力制御を行う画像データ入力制御部の動作を説明する。入力制御シーケンサは、ステートマシン等で構成され、カウンタ動作やデータ入出力制御を行う。ラインカウンタLCNTは、原稿読取り前に一度、リセット信号res_LCNTをアサートすることで、カウンタをリセットしておく。そして、スキャナデータの１ラインを取り込む毎に、カウンタインクリメント信号inc_LCNTがアサートされ、受信したスキャナデータのライン数がカウントされる。原稿ライン数レジスタNLINEは、原稿のライン数を格納するものである。原稿が読み取られ、フレームゲート信号FGATEBがネゲートし、原稿読取りが終了すると、原稿ライン数レジスタNLINEのロード信号ld_NLINEをアサートし、ラインカウンタLCNTの値を格納する。その後、エンジン側を制御するプロセスコントローラにより、NGLINEの値が読取られ、原稿のライン数、すなわち原稿長を知ることができる。

図２（ｄ）に、入力制御シーケンサであるステートマシンの状態遷移図を示す。ステートｓ０は、アイドルステートであり、このステートでラインカウンタLCNTのリセット信号res_LCNTをアサートし、リセットをかけている。この状態で原稿の読取りが開始され、フレームゲート信号FGATEBがアサートすると、ステートｓ１に遷移する。ステートｓ１では、原稿のスキャナデータが１ライン入力され、すなわちLGATEBがアサートされる毎に、ラインカウンタLCNTのインクリメント信号inc_LCNTをアサートし、入力されるスキャナデータのライン数をカウントする。原稿の読取りが終端にきたことを、フレームゲート信号のネゲート(FGATEB=‘Ｈ’)で知ると、ステートｓ１からステートｓ２に遷移する。ステートｓ２では、フレームゲート信号FGATEBがネゲートした際のラインカウンタLCNTの値を、FGATEBネゲート時のライン数格納レジスタNLINEにロードするためld_NLINEを出力し、ステートｓ３に遷移する。ステートｓ３では、原稿の読取りが終了し、スキャナデータの送信が終了したことを示す読取り終了信号READ_ENDをアサートする。

次に、図３を参照しながら、定型サイズ原稿を読み取って符号化する場合の処理手順を説明する。図１（ａ）に示すシステム構成において、定型サイズ原稿を読み取って符号化する場合の画像データの流れを図３（ａ）に示し、そのフローチャートを図３（ｂ）に示す。まず、画像パス〔１〕で示す画像フローについて説明する。原稿の読取りが開始されると、読取ユニット１で読取り原稿が紙送りされる。センサーボードユニット２で、読取画像がアナログ信号からディジタル信号に変換される。画像処理プロセッサ（IPU）３で、スキャナ補正処理が実行される。この後、画像符号化モジュール７に転送される。バッファメモリ８に一度蓄積された後、画像符号化モジュール７で、原稿画像データの符号化を行う。このとき、読取画像は、予め定型サイズと判明し、原稿のライン数は既知のため、符号化コードのヘッダには、このライン数を含めた符号化コードが生成される。その後、この符号データは、画像データ制御部（CDIC）４と、パラレルバス10と、画像メモリアクセス制御部（IMAC）11とを介して転送され、メモリ14に格納される。その後、画像パス〔２〕で示されるように、メモリ14から画像メモリアクセス制御部（IMAC）11を介して、ハードディスク（HDD）13に蓄積される。

次に、図４を参照しながら、画像サイズが未知の原稿を読み取って符号化する場合の処理手順を説明する。画像サイズが未知の原稿を読に取る際の画像フローを、図４（ａ）に示す。このときのフローチャートを、図４（ｂ）に示す。画像データパス〔１〕で示す画像フローは、図３（ａ）と同様であるが、異なるのは、原稿サイズが未知ということである。そこで、画像符号化モジュール７で符号化を行う際に、図７（ｃ）で示したライン数Ｙを示す符号化コードは、ダミーの仮のライン数(0〜65535)でコード生成を行い、コントローラ側のメモリ14に送信する。その後、画像パス〔２〕で示すように、原稿の読取りが終了すると、画像符号化モジュール７内の画像データ入力制御部のライン数カウント機能（図２（ｃ））により、読み取られた原稿のライン数NLINEが確定しているので、プロセスコントローラ22で読み出す。

この原稿のライン数を、画像パス〔３〕で示すように、プロセスコントローラ22からシステムコントローラCPU12に送信する。次に、画像パス〔４〕で示すように、システムコントローラ12は、通知された原稿のライン数により、ライン数を含むフレームヘッダを生成し、予めダミーの仮のライン数で生成し、メモリ14に蓄積されているフレームヘッダを上書きして更新する。そして最後に、画像パス〔５〕で示すように、メモリ14に格納されている原稿の符号化データを、ハードディスクHDD13に蓄積する。

このように、原稿サイズ未知の原稿に対して、エンジン側で符号化を行うメリットは、以下にあげるように大きく２点ある。
（１）広幅MFP機などによるA0や長尺原稿に対する符号化が可能になる。あるいは、コントローラ側メモリの容量を著しく低減できる。
（２）読取り生産性を著しく向上できる。

符号化時に必要なコントローラ側メモリの容量は、符号化(圧縮)時の圧縮率に左右される。圧縮率は原稿の絵柄や画質設定で変わる。よく用いられる原稿では、２〜40程度である。圧縮率２は、最も圧縮率が低い場合である。圧縮率40は、最も圧縮率が高い場合である。これら原稿毎の平均をとり、設計に必要な代表値を求めると、圧縮率は約10となる。ここでは、この値を用いてメモリ容量を求め、さらにA1サイズ原稿の場合を追加すると、以下の通りとなる。なお、図１（ａ）に示したシステム構成のバッファメモリ８は、符号化に必要なフォーマットで画像符号化モジュール７に出力するためだけに使用するため、容量は少なくて済む。ここでは32MBとし、コントローラ側のメモリ14の容量に加えることで、必要メモリ量を算出する。

原稿 サイズ(主走査×副走査) 従来例 必要なメモリ容量
A3 297mm×420mm 199MB 32＋199/10＝51.9MB
A1 594mm×841mm 798MB 32＋798/10＝111.8MB
A0 841mm×1189mm 1596MB 32＋1596/10＝191.6MB
長尺 841mm×2774mm 3725MB 32＋3725/10＝404.5MB

以上より、必要とするメモリ容量は、従来方法よりも劇的に減らすことが可能となり、コスト低減に大きく寄与することになる。また、従来方法では、コントローラ側メモリ総容量は最大でも２GBぐらいである。このうち、スキャナ読取りに使用できる容量は、この半分の１GB程度である。この容量では、A1サイズまで600dpiで読取りが可能であるが、A0原稿や長尺原稿の読取りは不可能になる。しかし、エンジン側で符号化を行うことで、最大の長尺原稿でも、404.5MBで済み、広幅MFP機で長尺の原稿読取りが可能となる。

次に、読取り生産性の向上について説明する。本実施例では、原稿の読取りと同時に符号化を開始できるため、原稿を読み終えた時点で、符号化は終了する。符号化データは、コントローラ側メモリに格納されている。この後、ライン数をエンジン側からコントローラ側に通知する。このライン数の部分のみの符号化を行って更新する。この更新にかかる時間は、１秒未満である。ここでは、このライン数部分の符号化更新に１秒かかるとすると、読取時間にこの１秒を加算することで、スキャナ生産性は以下の通りとなる。なお、スキャナの読取速度は、従来例と同じ100mm/sとしている。

原稿 サイズ(主走査×副走査) 読取時間＋１秒 スキャナ生産性
A3 297mm×420mm 5.2ｓ 11.5SPM
A0 841mm×1189mm 12.9ｓ 4.7SPM
長尺 841mm×2774mm 28.7ｓ 2.1SPM

従来例では、A3の場合は7.0SPMであり、A0の場合は1.3SPMであり、長尺の場合は0.5SPMであったことを考慮すると、約２〜４倍の性能改善が実現できる。これにより、ユーザーが読取原稿をセットしてから、読取りが終了するまでの待時間をかなり縮小できる。そのため、ユーザーの操作性がかなり改善されることになる。

次に、図５を参照しながら、別の処理方法を説明する。図５（ａ）に、別の例として、読取り終了後のライン数を含む符号の生成を、エンジン側の画像符号化モジュール７で行い、既に送信済みの仮のライン数を含む符号部分を上書きすることで、更新を行う場合を示す。図５（ｂ）に、この場合のフローチャートを示す。原稿を読み取りながら画像符号化モジュールで符号化を行い、コントローラ側のメモリ14に符号データを格納する画像パス〔１〕は、図４（ａ）の場合と同じである。その後、画像パス〔２〕として、原稿読取り後、画像符号化モジュール７で入力ライン数を検知する。この値を使用して、ライン数を含む符号コードを生成し、コントローラ側のメモリ14に送信する。こうして、既に仮のライン数で生成して送付済みのコードを更新する。この後、画像パス〔３〕で示すように、メモリ14からハードディスク13に符号化データを蓄積する。

この場合のスキャナ生産性について考える。図４（ａ）では、ライン数をエンジン側からコントローラに送信し、符号コードをシステムコントローラ12で生成し直して更新していた。図５（ａ）では、ライン数を含む符号コードをハード的に生成し、送信時に上書きによる更新を行うので、ライン数更新にはほとんど時間を費やさない。したがって、原稿画像の符号化に必要な時間は、読取りにかかる時間と考えることができるため、以下のようになる。

原稿 サイズ(主走査×副走査) 読取時間 スキャナ生産性
A3 297mm×420mm 4.2ｓ 14.3SPM
A0 841mm×1189mm 11.9ｓ 5.0SPM
長尺 841mm×2774mm 27.7ｓ 2.2SPM

これらより、図４（ａ）で示した例よりも、若干の生産性向上が実現できる。さらに、ハード的にライン数を含む符号の更新を行うため、図４（ａ）の場合に比べ、制御が簡単化できるというメリットがある。

上記のように、本発明の実施例では、原稿読取装置を、サイズが未知の原稿を読み取りながら、画像データを仮のライン数で符号化して画像メモリに格納し、原稿読取終了時に、確定したライン数のヘッダで仮のライン数のヘッダを置き換える構成としたので、画像の読取りと同時に符号化でき、必要なメモリ容量が削減でき、読取生産性も向上する。

本発明の原稿読取装置は、原稿を読み取った画像データを蓄積するディジタル複写機やスキャナやMFP等の原稿読取装置として最適である。

本発明の実施例における原稿読取装置を備えた画像処理システムの機能ブロック図と、画像符号化モジュールの機能ブロック図と、画像処理プロセッサから画像符号化モジュールへの入力信号を示す図と、そのタイミングチャートである。 本発明の実施例における原稿読取装置で、定型サイズの原稿を読み取るときのイメージ図と、長尺原稿を読み取るときのイメージ図と、画像データ入力制御部の機能ブロック図と、入力制御シーケンサの状態遷移図である。 本発明の実施例における原稿読取装置で、定型サイズ原稿を読み取って符号化する場合の画像データの流れを示す図と、そのフローチャートである。 本発明の実施例における原稿読取装置で、サイズ未知原稿を読み取って符号化する場合の画像データの流れを示す図と、そのフローチャートである。 本発明の実施例における原稿読取装置で、読取り終了後の符号生成を画像符号化モジュールで行う場合の画像データの流れを示す図と、そのフローチャートである。 従来の画像処理装置の機能ブロック図である。 従来の画像処理装置におけるJEPG符号化処理の説明図である。 従来の広幅MFPで、原稿サイズをユーザーが指定してスキャンする方法の説明図である。 従来の広幅MFPで、予め原稿のライン数が指定できない場合のスキャン方法を説明する図である。

符号の説明

１・・・読取ユニット、２・・・センサーボードユニット、３・・・画像処理プロセッサ、４・・・画像データ制御部、５・・・ビデオデータ制御部、６・・・作像ユニット、７・・・画像符号化モジュール、８・・・バッファメモリ、10・・・パラレルバス、11・・・画像メモリアクセス制御部、12・・・システムコントローラ、13・・・ハードディスク、14・・・メモリ、15・・・ネットワーク、16・・・操作パネル、17・・・ROM、21・・・シリアルバス、22・・・プロセスコントローラ、23・・・RAM、24・・・ROM、71・・・画像データ入力制御部、72・・・メモリアクセス制御部、73・・・画像データ符号化部、74・・・セレクタ、75・・・画像データ出力制御部、76・・・コマンド制御部。

Claims (12)

1. 原稿画像を読み取る読取手段と、読み取った原稿画像から得られた画像データを符号化して符号化データを生成する符号化手段と、前記符号化データを格納する画像メモリと、前記原稿画像の読取りと符号化を制御するコントローラと、を具備する原稿読取装置であって、
   前記符号化手段は、原稿画像の原稿送り方向のサイズを示すライン数をカウントする手段と、原稿送り方向のサイズが未知の原稿の画像データを、仮のライン数で符号化する手段と、
   前記原稿画像の前記カウントしたライン数が予め設定されたライン数を超えた時点でその旨を前記コントローラに通知する手段と、
   原稿読取終了時にライン数を確定する手段と、を備え、
   前記コントローラは、確定したライン数で符号化データ中の仮のライン数を置き換える手段を備えることを特徴とする原稿読取装置。
2. 前記符号化手段は、原稿画像のライン数が確定した時点で前記コントローラにライン数を通知する手段を備え、前記コントローラは、確定したライン数を含むヘッダ部を生成する手段を備えることを特徴とする請求項１記載の原稿読取装置。
3. 前記符号化手段は、原稿画像のライン数が確定した時点で確定したライン数を含むヘッダ部を生成する手段と、前記ヘッダ部を前記コントローラに送信する手段とを備えることを特徴とする請求項１記載の原稿読取装置。
4. 前記符号化手段は、前記画像メモリ中の仮のライン数を含むヘッダ部のアドレスを指定して前記コントローラにライン数を含むヘッダ部を送信する手段を備えることを特徴とする請求項３記載の原稿読取装置。
5. 前記符号化手段は、原稿の画像データの符号化が間に合わなくなってバッファオーバフローが発生したことを検知する手段と、バッファオーバフロー発生を前記コントローラに通知する手段とを備えることを特徴とする請求項１記載の原稿読取装置。
6. 前記コントローラは、バッファオーバフロー発生の通知の受信に応じて、原稿の読取解像度を落とすか圧縮率を上げる必要があることを表示するように操作パネルに通知する手段を備えることを特徴とする請求項５記載の原稿読取装置。
7. 原稿画像を読み取る読取手段と、読み取った原稿画像から得られた画像データを符号化して符号化データを生成する符号化手段と、前記符号化データを格納する画像メモリと、前記原稿画像の読取りと符号化を制御するコントローラと、を具備する原稿読取装置における原稿読取方法であって、
   前記符号化手段で行う符号化工程において、原稿画像の原稿送り方向のサイズを示すライン数をカウントし、原稿送り方向のサイズが未知の原稿の画像データを、仮のライン数で符号化し、前記原稿画像の前記カウントしたライン数が予め設定されたライン数を超えた時点でその旨を前記コントローラに通知し、原稿読取終了時にライン数を確定し、
   前記コントローラで行う制御工程において、確定したライン数で符号化データ中の仮のライン数を置き換えることを特徴とする原稿読取方法。
8. 前記符号化工程において、原稿画像のライン数が確定した時点で前記コントローラにライン数を通知し、前記制御工程において、確定したライン数を含むヘッダ部を生成することを特徴とする請求項７記載の原稿読取方法。
9. 前記符号化工程において、原稿画像のライン数が確定した時点で確定したライン数を含むヘッダ部を生成し、前記ヘッダ部を前記コントローラに送信することを特徴とする請求項７記載の原稿読取方法。
10. 前記符号化工程において、前記画像メモリ中の仮のライン数を含むヘッダ部のアドレスを指定して前記コントローラにライン数を含むヘッダ部を送信することを特徴とする請求項９記載の原稿読取方法。
11. 前記符号化工程において、原稿の画像データの符号化が間に合わなくなってバッファオーバフローが発生したことを検知し、バッファオーバフロー発生を前記コントローラに通知することを特徴とする請求項７記載の原稿読取方法。
12. 前記制御工程において、バッファオーバフロー発生の通知の受信に応じて、原稿の読取解像度を落とすか圧縮率を上げる必要があることを表示するように操作パネルに通知することを特徴とする請求項１１記載の原稿読取方法。
    

Images