JP4323995B2

JP4323995B2 - データ処理装置及びその制御方法

Info

Publication number: JP4323995B2
Application number: JP2004090064A
Authority: JP
Inventors: 康史新倉; 善昭片平; 文雄庄司; 貴生生野; 正博大平; 徹藤野; 健治糟谷; 典嗣岡山
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2004-03-25
Filing date: 2004-03-25
Publication date: 2009-09-02
Anticipated expiration: 2024-03-25
Also published as: JP2005277938A; US20060117053A1; WO2005094057A1

Description

本発明は、データ処理装置及びデータ処理方法に関し、特に、複数データ形式のページデータを扱うマルチファンクションペリフェラル装置（以下ＭＦＰ装置）のページデータの管理方法に関する。

従来の、複数データ形式の画像データを扱うＭＦＰ装置において、読み取り、ＦＡＸ受信、ネットワーク受信など画像データ入力部は、入力インターフェースから入力されたページデータを装置固有のデータ形式（符号化形式）のページデータへ符号化・復号化を行い、このページデータを蓄積データとして装置内部に蓄積している。

また、記録、ＦＡＸ送信、ネットワーク送信など画像データ出力部は、装置固有のデータ形式で蓄積された蓄積データを、必要なデータ形式に変換し、出力インターフェースへ出力している。以上のように、入力部や出力部で生成され、利用される、異なるデータ形式（符号化形式）のページデータは、それぞれ別々に管理されている。

図１は、このような従来のＭＦＰ装置におけるページ管理レコードの構造を示している。つまり、例えば画像読取部（スキャナ）によって読み取られた画像（Ｒａｗデータ）はＭＦＰ装置固有の符号化形式であるＪＢＩＧに符号化され、ＪＢＩＧデータとしてメモリに格納される。そして、このＪＢＩＧデータを利用する場合には、使用する機能（例えば、ＦＡＸ送信機能）にとって必要なデータ形式（符号化形式）に変換してからデータを利用することになる。従って、従来のＭＦＰ装置では、取り扱われる各データは、例えばＪＢＩＧのように統一された符号化形式でデータを管理していることになる。図１で示されるように、ページ管理レコード１０ａ、ｂ・・・のそれぞれが管理しているのは、ＪＢＩＧページデータ２０ａ、ｂ・・・のみということになっている。なお、ＪＢＩＧデータはＪＢＩＧページデータによって管理されるメモリに格納されている。このようなページ管理方法の例としては特許文献１に記載されたものがある。
特開平７−００７６２３号公報

しかしながら上記従来のＭＦＰ装置では、共通のデータ形式（ＪＢＩＧ形式）でデータ管理し、データを蓄積しているので、生データを入力して直ぐにそれを出力（コピー）するようなときでもわざわざ生データ→ＪＢＩＧデータと変換して蓄積処理を行い、その後ＪＢＩＧデータ→生データと変換しなおしていたため、蓄積処理分の時間ロスが生じ、出力スピードが遅くなってしまうという問題がある。

また、従来のＭＦＰ装置では、例えば、１つのドキュメントにおいて１ページ目がＪＢＩＧデータで、２ページ目がＴＸＴデータで、３ページ目がＴＩＦＦデータであるような場合であっても、ページ管理レコードが装置固有の特定データ形式のページデータしか持つことができず、そのままの符号化形式で各ページを管理することができない。すると、画像データ出力部は、画像データ入力部で蓄積データへの符号化・復号化が終了し、ページデータが生成されるまで、ページデータを利用することができず、画像データの入力から出力まで処理時間がかかるという問題がある。

仮に、上述の従来のＭＦＰ装置によって様々異なるデータ形式（符号化形式）のデータに対応して管理しようとすると、図２Ａ乃至Ｃに示されるように、同じドキュメントにも拘わらず、それぞれ異なるデータ形式（符号化形式）のページデータを作成し、別々に管理されなければならない。つまり、データ形式の変換が必要な画像データ出力部（記録、ＦＡＸ送信、ネットワーク送信）で、その都度ページデータ変換用のページ管理レコード、および、ページデータを持つ必要があり、このように管理すると、メモリ使用量が多くなって装置のコストが高くなるという問題がある。

本発明は、かかる問題点を解消するためになされたもので、装置におけるメモリ使用量を最小限に抑えながらも、効率よく各画像処理機能に対応した符号処理を実現できるデータ処理装置を提供することを目的とするものである。

以上の課題を解決するために、本発明によるデータ処理装置は、原稿を光学的に読み取ってデータ形式がＲａｗ形式である第１画像データを生成するスキャナ処理部と、前記スキャナ処理部が前記原稿を読み取る際に行う要求に従い、前記第１画像データを管理するページ管理レコードを生成するメモリ管理部と、前記第１画像データから、Ｒａｗ形式とは異なる第２データ形式の第２画像データを生成する符号化部と、Ｒａｗ形式の画像データを用いて所定の処理を行う第１データ処理部と、前記第２データ形式の画像データを用いて所定の処理を行う第２データ処理部と、を備え、前記メモリ管理部は、前記第２画像データを前記第１画像データに関連付けて前記ページ管理レコードに管理させ、前記第１データ処理部及び前記第２データ処理部のうちの少なくとも一方から前記ページ管理レコードの削除要求を受信し、且つ、前記第１データ処理部及び前記第２データ処理部のいずれもが前記ページ管理レコードを参照していない場合に、前記ページ管理レコードを削除することを特徴とする。

また、本発明による制御方法は、データ処理装置の制御方法であって、スキャナ処理部が、原稿を光学的に読み取ってデータ形式がＲａｗ形式である第１画像データを生成するスキャナ処理工程と、メモリ管理部が、前記スキャナ処理部が前記原稿を読み取る際に行う要求に従い、前記第１画像データを管理するページ管理レコードを生成するメモリ管理工程と、符号化部が、前記第１画像データから、Ｒａｗ形式とは異なる第２データ形式の第２画像データを生成する符号化工程と、を備え、前記データ処理装置は、Ｒａｗ形式の画像データを用いて所定の処理を行う第１データ処理部と、前記第２データ形式の画像データを用いて所定の処理を行う第２データ処理部と、を備え、前記制御方法は、前記メモリ管理部が、前記第２画像データを前記第１画像データに関連付けて前記ページ管理レコードに管理させる工程と、前記メモリ管理部が、前記第１データ処理部及び前記第２データ処理部のうちの少なくとも一方から前記ページ管理レコードの削除要求を受信し、且つ、前記第１データ処理部及び前記第２データ処理部のいずれもが前記ページ管理レコードを参照していない場合に、前記ページ管理レコードを削除する工程と、を更に備えることを特徴とする。

なお、その他の本発明の特徴は、添付図面及び以下の発明を実施するための最良の形態の記載によっていっそう明らかになる。

本発明によれば、装置におけるメモリ使用量を最小限に抑えながらも、効率よく各画像処理機能に対応した符号処理を実現できる。

本発明に係るデータ処理装置に関し、ＭＦＰ（マルチ・ファンクション・ペリフェラル）装置を例に挙げて説明する。

＜ハードウエア構成＞
図３は、本発明の実施例である画像処理装置の構成を示すブロック図である。

図３において、画像処理装置１００は、ＣＰＵ１０１と、ＲＯＭ１０２と、ＲＡＭ１０３と、スキャナ１０４と、プリンタ１０５と、ＣＯＤＥＣ１０６と、操作部１０７と、回線Ｉ／Ｆ１０８と、ネットワークＩ／Ｆ１１０と、ＵＳＢＩ／Ｆ１１２とを有する。

ＣＰＵ１０１は、システム制御部であり、画像処理装置１００の全体を制御する。ＲＯＭ１０２は、ＣＰＵ１０１の制御プログラムを格納している。なお、上記制御プログラムは、以下に説明する上記実施例を実行する制御プログラムである。また、後述のメモリ管理部６１０（図９）によるメモリ管理プログラムもＲＯＭ１０２に格納されている。

ＲＡＭ１０３は、ＳＲＡＭ、ＤＲＡＭ等で構成され、プログラム制御変数等を格納するものである。また、データ通信装置１００の使用者が登録した設定値や、データ通信装置１００の管理データ等や、各種ワーク用バッファも、ＲＡＭ１０３に格納される。

また、本実施形態においては、ページ管理レコード２００やページデータ２１０も作成される度にＲＡＭ１０３に格納され、開放の処理がなされるとＲＡＭ１０３から削除される。

スキャナ１０４はＣＳイメージセンサ、原稿搬送機構などで構成され、原稿を光学的に読み取って電気的な画像データに変換するものである。

プリンタ１０５は受信画像やファイルデータを記録紙に記録する装置である。

ＣＯＤＥＣ１０６は、ＪＢＩＧ、ＪＰＥＧ等の符号化、および、復号化を行うモジュールであり、所定の規格に準拠した画像データの圧縮、伸張処理を実行する処理部である。

操作表示部１０７はキーボード、タッチパネル、ＬＣＤ、ＬＥＤ等で構成され、装置使用者が各種操作を行ったり、また、装置使用者に対して表示通知を行うものである。

回線Ｉ／Ｆ１０８は、モデム（変復調装置）、ＮＣＵ（網制御装置）等により構成されるものであり、電話回線１０９を介してＦＡＸの送受信を行うものである。

ネットワークＩ／Ｆ１１０、ＵＳＢＩ／Ｆ１１２は、ネットワーク１１１、ＵＳＢ１１３を介して、接続された外部ＰＣとのインターフェース制御を行うものであり、これらインターフェースを介してＰＣからプリントジョブ、スキャンジョブ等のジョブ要求を受け付けることができる。

＜ページデータ管理方法について＞
図４乃至図７は、本発明におけるページデータの管理方法を示す概略図である。なお、ページ管理レコード２００ａ、ｂ、ｃ・・・は既にＲＡＭ１０３内に用意されているのではなく、必要がある場合に作成され、必要がなくなると削除されるものである。この動作については後述する。

まず、図４は、ページ管理レコード２００ａ、ｂ、ｃ、・・・の相互の関係と、１つのページ管理レコード（例えば２００ａ）とそれによって管理される符号化方式との関係を示す概略図である。

図４において、ページ管理レコードとは、各符号化方式に対応したページデータを管理するための管理データであり、ページデータに関する各種情報が格納されている（詳細な構造については後述する）。画像が複数ページからなる場合は、次ページのページ管理レコードへのポインタがページ管理レコードに保存され、各ページ管理レコード同士はツリー構造によってそれぞれ関連付けられている。

本実施形態において、ページ管理レコードは、必要に応じ、ＲａｗＭｏｎｏ、ＲａｗＣｏｌｏｒ、ＪＢＩＧ、ＪＰＥＧ、ＴＩＦＦ、ＴＥＸＴ等、異なる符号化形式（データ形式）のページデータを複数持つことができるように構成されている。

具体的には、図５に示されるように、それぞれのページデータへのポインタがページ管理レコードに保存される。例えば、１ページ目のページ管理レコード２００ａは、対応できる符号化形式のページデータのうちＲＡＷページデータ２２０とＪＢＩＧページデータ２３０とを管理している。各ページデータには、後述のように、関連付けて管理しているメモリブロックの所定のアドレス位置にＲＡＷデータやＪＢＩＧデータが格納されている。

そして同様に、２ページ目のページ管理レコード２００ｂはテキストデータに関するＴＸＴページデータ２４０を、３ページ目のページ管理レコード２００ｃはＴＩＦＦデータに関するＴＩＦＦページデータ及びＪＰＥＧデータに関するＪＰＥＧページデータを管理している。なお、これらの組み合わせは単なる例示であって、当然別の組み合わせでもよい。

図６は、ページ管理レコード２００の構造と、ページ管理レコード２００とＪＢＩＧページデータ２１０ｃ及びＲＡＷページデータ２１０ａ並びにＭｅｍｏｒｙ＿Ｂｌｏｃｋ３１０との関係を示す図である。このデータ形式（符号化形式）の組み合わせも単なる例示であり、別の組み合わせでも良い。

図６に示されるように、ページ管理レコード２００は、Ｎｅｘｔポイント、Ｐｒｅｖポインタ、Ｐａｇｅ＿Ｎｏ、Ｃｏｄｅ、Ｓｔａｔｕｓ、Ｌｉｎｋ＿Ｃｏｕｎｔ、Ｆｒｅｅ＿Ｆｌａｇ等から構成される。ここで、Ｎｅｘｔポインタは、次のページのページ管理レコードのポインタ（ＲＡＭ１０３のアドレス）を示し、次ページが無い場合にはここは「Ｎｕｌｌ」とされる。Ｐｒｅｖポインタは前ページのページ管理レコードのポインタを示し、前ページが無い場合（当該ページが先頭のページの場合）にはここは「Ｎｕｌｌ」とされる。

ＰａｇｅＮｏ．は、当該ページが処理すべきドキュメントの何ページ目かを示す情報である。Ｃｏｄｅは、管理するデータの符号化形式を示す情報であり、図６の例では、ＲＡＷ（生）データとＪＢＩＧデータが管理されることになっている。

Ｓｔａｔｕｓは、ページ管理レコード２００全体のステータスと各符号化形式毎のステータスの２種類の情報を管理している。ステータスとしては、作成中を示すＲＵＮと作成完了を示すＦＩＸである。例えば、このＳｔａｔｕｓがＪＢＩＧページデータ２１０ｃを作成中を示す場合（ＲＵＮ）には、プリント処理部やＦＡＸ処理部等の他の処理部はそのＪＢＩＧデータを用いることが出来ず、ＳｔａｔｕｓがＪＢＩＧページデータが完了した旨を示す（ＦＩＸ）まで待機しなければならない。

Ｌｉｎｋ＿Ｃｏｕｎｔは、当該ページ管理レコード２００を参照している処理部があるか否かを示している。つまり、ある処理部（プリント処理部でもＦＡＸ処理部でもよい）が当該ページ管理レコードを参照してそこで管理されている所定のデータを用いようとしている場合には、このＬｉｎｋ＿Ｃｏｕｎｔは参照している処理部の個数をカウントしている。そして、どの処理部も参照していない状態であれば、Ｌｉｎｋ＿Ｃｏｕｎｔは「０」となる。

Ｆｒｅｅ＿Ｆｌａｇは、処理部が当該ページ管理レコード２００を参照し終わり、ページ管理レコードを削除しても良い状態になると、フラグが「ＯＮ」となる。従って、Ｌｉｎｋ＿Ｃｏｕｎｔが「０」でＦｒｅｅ＿Ｆｌａｇが「ＯＮ」であれば、全ての処理部の参照が終了し、当該ページ管理レコード２００の消去が可能であることが判明する。

ここで、理解の容易のため、図７を用いてＳｔａｔｕｓ、Ｌｉｎｋ＿Ｃｏｕｎｔ、Ｆｒｅｅ＿Ｆｌａｇに関連した動作例について説明する。スキャナ処理部４１０によってドキュメントが読み取られると、ページ管理レコード作成要求が出される。この状態では、上記Ｓｔａｔｕｓはページ管理レコードが「ＲＵＮ」ということになる。そして、スキャナ処理部４１０によってデータが読み取られるに従って、ＲＡＷページデータが作成され、それに関連したメモリにデータが格納される。さらに、ＪＢＩＧページデータが生成され、そのＲＡＷデータは順にＪＢＩＧによって符号化されてメモリに格納される。これらページデータが生成されてデータが格納されるまでは、ＳｔａｔｕｓではＲＡＷページデータ「ＲＵＮ」またはＪＢＩＧデータ「ＲＵＮ」とされ、格納されれば、それぞれが「ＦＩＸ」とされる。

この場合に、プリンタ処理部４２０とＦＡＸ処理部４３０が当該ページ管理レコード２００を参照してＲＡＷデータ或いはＪＢＩＧデータを用いようとしているとすると、Ｌｉｎｋ＿Ｃｏｕｎｔは「２」を示す。そして、プリンタ処理部４２０もＦＡＸ処理部４３０も参照を終了すると、Ｌｉｎｋ＿Ｃｏｕｎｔは「０」となる。一方、プリンタ処理部４２０またはＦＡＸ処理部４３０が、それぞれ参照を終了させると、順に削除要求（解放要求）をページ管理レコード２００に対して発行し、その場合にはＦｒｅｅ＿Ｆｌａｇが「ＯＮ」となる。上述のように、Ｌｉｎｋ＿Ｃｏｕｎｔが「０」でＦｒｅｅ＿Ｆｌａｇが「ＯＮ」であれば、当該ページ管理レコード２００の役目は終了し、削除される。

再び図６に戻って、各ページデータとメモリブロック３１０の関係について説明する。上述のように、ページ管理レコード２００は、各符号化形式毎のページデータ２１０の作成およびその完了、削除等も管理している。図６では、ＲＡＷページデータとＪＢＩＧページデータが作成されている場合を例にしている。

各ページデータは、その構造として、Ｗｉｄｔｈ、Ｌｅｎｇｔｈ、Ｓｉｚｅ、Ｍｅｍｏｒｙ＿Ｂｌｏｃｋ等を備えている。ここで、Ｗｉｄｔｈは例えば読み取られた画像の主走査数を示し、Ｌｅｎｇｔｈはその画像の副走査数を示している。この２つにより画像のサイズ（何ドット×何ドットか）が分かる。

Ｓｉｚｅは画像データのデータ量を示している。Ｍｅｍｏｒｙ＿Ｂｌｏｃｋは実際のデータが格納されている先頭のメモリブロック３１０のアドレスを示すものである。

図６では、例えば、スキャナ処理部４１０から画像データが読み取られて得られた生データは、生成されたＲＡＷページデータによって管理され、メモリブロック３１０に格納される。メモリブロック３１０は例えばＲＡＭ１０３を複数のメモリ領域に細分化することによって構成されている。１つのメモリブロック３１０で格納しきれないデータは別のメモリブロック３１０にも格納されており、それぞれのメモリブロックはポインタによって関連付けられている。Ｎｅｘｔポインタはデータが格納されている次のメモリブロックを示し、Ｐｒｅｖポインタはデータが格納されている１つ前のメモリブロックを示している。このように、データを格納する領域を細分化することにより、メモリを無駄なく効率よく用いることができるようになる。なお、図６ではメモリブロック３１０の領域に実際のデータが格納されている例が示されているが、データはさらに別のメモリ領域で管理し、メモリブロック３１０ではそのアドレスポインタのみを管理するようにしても良い。

＜ページデータ制御動作について＞
図８乃至図１３は、画像処理の例として白黒コピーを行った場合のページデータ制御動作を示すフローチャートである。なお、各フローチャートの動作はＣＰＵ１０１によって制御されている。

まず、図８を用いて、白黒コピーを行った場合の画像読み取り部のページデータ制御方法について説明する。

ステップＳ５０１において、スキャナ１０４（＝図７の４１０）によって読み取り開始要求があったと判断されると処理はステップＳ５０２に移行する。

ステップＳ５０２では、ページ管理レコード２００の獲得が実行される。図９はこの獲得動作の概略を示す図である。スキャナ処理部４１０によって画像の読み取りが開始され、１ページ目の画像の読み取り準備がなされる（６２０）と、メモリ管理部６１０にページ管理レコードを生成することを指示するリクエストが出される。このメモリ管理部６１０は、ＲＯＭ１０２に格納されるソフトウエアプログラムで構成され、ページ管理レコードが現在いくつあるのか、どのページ管理レコードが使われているか等を管理している。リクエストを受け取ったメモリ管理部６１０は、メモリマップ６３０のページ管理レコード領域にページ管理レコード２００を作成する。ページ管理レコード領域６４０では、各ページ管理レコード（＃１、＃２、＃３、・・・・）ごとに管理され、あるページ管理レコードを使い終われば、それはページ管理レコード領域６４０から解放（削除）され、その空領域は別のページ管理レコードのために用いられるようになっている。以上のようにしてまず１ページ目の画像のページ管理レコードが獲得される。

図８のフローチャートに戻り、ステップＳ５０３では、Ｒａｗページデータの獲得が行われる。ページ管理レコード獲得後、Ｒａｗページデータ生成のリクエストがスキャナ処理部４１０からメモリ管理部６１０に対して出され、ページ管理レコード生成時と同様な手順により、メモリマップ６３０のページデータ領域に１ページ目の画像データに対応するＲａｗページデータが作成される。

そして、ステップＳ５０４で読み取られた画像データ（１ページ目）は、ステップＳ５０５においてＲａｗページデータに関連付けられたメモリブロックに生データとして格納される。この段階で、ページ管理レコード及びＲａｗページデータは、それぞれ図１１の８１０及び８２０のように獲得される。

１ページの読み取りが終了すると、ステップＳ５０６においてページＦＩＸ通知がなされる。このとき、前述のＳｔａｔｕｓ（図６）では、ＲａｗデータについてはＲＵＮからＦＩＸに状態が変化したことになる。この状態になれば、他の処理部（プリンタ処理部やＦＡＸ処理部等）はこのＲａｗデータを使用することができる。

ステップＳ５０７において、ＪＢＩＧページデータの獲得が実行される。この概略が図１１の８３０に示されている。そして、ステップＳ５０８において、ステップＳ５０５で格納されたＲａｗページデータのＪＢＩＧ符号化を行い、続いてステップＳ５０９において、ステップＳ５０７で獲得されたＪＢＩＧページデータにＲａｗデータからＪＢＩＧ符号化して得られたＪＢＩＧデータが格納される（図１１、８４０）。このとき、ＪＢＩＧ符号化が終了したＲａｗページデータが他の処理部で参照していない場合には、Ｒａｗページデータを解放することができる（８５０）。

ステップＳ５１０において、次ページがあると判断されると、処理はステップＳ５０２に戻り、次ページ以降の処理が同様に継続される。ステップＳ５１０において、次ページがないと判断されると、ステップＳ５０１に戻り、読み取り開始要求を待つことになる。以上、読み取られた画像が複数ページある場合には、メモリ管理部６１０によってそのページ数分のページ管理レコードが生成され、それぞれは図４のように関連付けられる。

図１０は、例として白黒コピーを行った場合のプリンタ部１０５（＝図７の４２０）のページデータ制御動作について説明するためのフローチャートである。

ステップＳ７０１において、プリント処理の指示がなされ、記録可能ページがあると判断されると、処理はステップＳ７０２に移行する。

ステップＳ７０２では、ＦＩＸされたＪＢＩＧページデータがあるかどうか判断される。つまり、通常のプリント動作の場合には、ＪＢＩＧデータを復号してＲａｗデータに変換して記録動作が実行されるため、ＪＢＩＧデータが存在するかがまず判断されるのである。

ステップＳ７０２において、ＦＩＸされたＪＢＩＧページデータがないと判断されると、ステップＳ７０３において、Ｒａｗページデータで管理されているＲａｗデータを記録出力してステップＳ７０１に処理が戻る。この現象が起こるのは、１ページ目のプリント処理がなされる場合である。１ページ目の画像について未だＪＢＩＧ符号化されていない段階でもＲａｗデータを用いてプリント処理を実行することができるので、ユーザに対してプリント処理が高速に実行されているという印象を与えることができる。なお、ここでプリンタへ記録出力が終了したＲａｗページデータは、他の処理部で参照していない場合には、解放することができる。この様子を示したのが、図１２である。つまり、Ｒａｗページデータで管理されているＲａｗデータのプリント処理がなされ、順次ＪＢＩＧ符号化される。このとき、ＪＢＩＧデータがＪＢＩＧページデータによって管理されたメモリブロックに全て格納され、かつ他の処理部（ＦＡＸ処理部等）によって参照されていなければ、９２０のようにＲａｗページデータが解放（対応するページ管理レコードから削除）される。

ステップＳ７０２において、ＦＩＸされたＪＢＩＧページデータがあると判断されると、ステップＳ７０４において、図１３に示すように、Ｒａｗページデータ１０１０を獲得する。この獲得動作については既に述べたのでここでは説明は省略する。

ステップＳ７０５において、ＪＢＩＧページデータによって管理されているＪＢＩＧデータを復号化し、Ｒａｗデータを生成する。

続いて、ステップＳ７０６において、復号化されたＲａｗデータが、ステップＳ７０４で獲得したＲａｗページデータに関連付けられたメモリブロックに格納される。

ステップＳ７０３では、Ｒａｗページデータに格納されたＲａｗデータが記録出力される。ここで、プリンタへ記録出力が終了したＲａｗデータに対応するＲａｗページデータが、他の処理部で参照していない場合には、Ｒａｗページデータを解放（対応するページ管理レコードから削除）することができる。

以上のような動作は、全ページについての記録出力処理が完了するまで続けられる。

＜実施形態の効果＞
以上説明したように本実施形態によれば、１つのページ管理レコードが、それぞれ異なる符号化形式で蓄積されたページデータを複数持つことが可能となるため、符号化形式の変換が必要な出力側で、展開用のページ管理レコード、および、ページデータを別に持つ必要がなく、メモリ流用性を上げメモリ使用量を減らすことができる。また、ページデータを利用している処理部は、符号化・復号化中であっても、既にＦＩＸされたページデータが存在すれば、それを使用することできるので、処理の高速化を図ることができる。

＜その他＞
本発明では、実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体をシステム或は装置に提供し、そのシステム或は装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても達成される。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フロッピィ（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ，ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどを用いることができる。

また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施の形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現される場合も含まれている。

さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書きこまれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現される場合も含む。

また、上記実施の形態の機能を実現するソフトウェアのプログラムコードがネットワークを介して配信されることにより、システム又は装置のハードディスクやメモリ等の記憶手段又はＣＤ-ＲＷ、ＣＤ-Ｒ等の記憶媒体に格納され、そのシステム又は装置のコンピュータ(又はＣＰＵやＭＰＵ)が当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行することによっても、達成されることは云うまでもない。

従来のＭＦＰ装置におけるページ管理レコードの構造を示す図である。従来のＭＦＰ装置によって様々異なるデータ形式（符号化形式）のデータに対応して管理しようとした場合のページデータの管理方法を示す概略図である。本発明に係る画像処理装置１００の構成を示すブロック図である。本発明に係るページ管理レコードの構造を示す図である。本発明に係るページ管理レコードによるページデータの管理方法の一例を示す概略図である。本発明に係るページ管理レコードによるページデータの管理方法の詳細例を示す図である。本発明に係るページ管理レコードと各ページデータ及び各処理部との関係を示す概略図である。本発明に係るページ管理レコードによるページデータ生成および管理の動作を説明するためのフローチャートである。データ読み取りからページ管理レコード生成までの一連の動作例を説明するための概念図である。本発明に係るページ管理レコードによるページデータ制御動作の一例を説明するためのフローチャートである。ページデータ制御動作の概念を示す図である。ページデータの他の制御動作の概念を示す図である。ページデータのさらに他の制御動作の概念を示す図である。

符号の説明

１００・・・画像処理装置
１０１・・・ＣＰＵ
１０２・・・ＲＯＭ
１０３・・・ＲＡＭ
１０４・・・スキャナ
１０５・・・プリンタ
１０６・・・ＣＯＤＥＣ
１０７・・・操作表示部
１０８・・・回線Ｉ／Ｆ
１０９・・・電話回線
１１０・・・ネットワークＩ／Ｆ
１１１・・・ネットワーク
１１２・・・ＵＳＢＩ／Ｆ
１１３・・・ＵＳＢ

Claims

原稿を光学的に読み取ってデータ形式がＲａｗ形式である第１画像データを生成するスキャナ処理部と、
前記スキャナ処理部が前記原稿を読み取る際に行う要求に従い、前記第１画像データを管理するページ管理レコードを生成するメモリ管理部と、
前記第１画像データから、Ｒａｗ形式とは異なる第２データ形式の第２画像データを生成する符号化部と、
Ｒａｗ形式の画像データを用いて所定の処理を行う第１データ処理部と、
前記第２データ形式の画像データを用いて所定の処理を行う第２データ処理部と、
を備え、
前記メモリ管理部は、
前記第２画像データを前記第１画像データに関連付けて前記ページ管理レコードに管理させ、
前記第１データ処理部及び前記第２データ処理部のうちの少なくとも一方から前記ページ管理レコードの削除要求を受信し、且つ、前記第１データ処理部及び前記第２データ処理部のいずれもが前記ページ管理レコードを参照していない場合に、前記ページ管理レコードを削除する
ことを特徴とするデータ処理装置。
前記第２データ形式は、ＪＢＩＧ形式又はＪＰＥＧ形式であることを特徴とする請求項１に記載のデータ処理装置。
データ処理装置の制御方法であって、
スキャナ処理部が、原稿を光学的に読み取ってデータ形式がＲａｗ形式である第１画像データを生成するスキャナ処理工程と、
メモリ管理部が、前記スキャナ処理部が前記原稿を読み取る際に行う要求に従い、前記第１画像データを管理するページ管理レコードを生成するメモリ管理工程と、
符号化部が、前記第１画像データから、Ｒａｗ形式とは異なる第２データ形式の第２画像データを生成する符号化工程と、
を備え、
前記データ処理装置は、
Ｒａｗ形式の画像データを用いて所定の処理を行う第１データ処理部と、
前記第２データ形式の画像データを用いて所定の処理を行う第２データ処理部と、
を備え、
前記制御方法は、
前記メモリ管理部が、前記第２画像データを前記第１画像データに関連付けて前記ページ管理レコードに管理させる工程と、
前記メモリ管理部が、前記第１データ処理部及び前記第２データ処理部のうちの少なくとも一方から前記ページ管理レコードの削除要求を受信し、且つ、前記第１データ処理部及び前記第２データ処理部のいずれもが前記ページ管理レコードを参照していない場合に、前記ページ管理レコードを削除する工程と、
を更に備える
ことを特徴とする制御方法。
前記第２データ形式は、ＪＢＩＧ形式又はＪＰＥＧ形式であることを特徴とする請求項３に記載の制御方法。