(57)【要約】【課題】画像を所定サイズのブロックに分割し、各ブロックについて画像処理を行う画像処理装置において、所定サイズの各ブロックと所定サイズに満たない剰余部分とで画像処理を行う処理部を異ならせ、処理時間の短縮とメモリ領域の節約とを実現し得る手法を提供する。【解決手段】外部からの画像データを入力させる入力部と、入力されたデータを所定サイズのブロックに分割するブロック分割部と、前記画像データが所定サイズのブロックに剰余なく分割できるか否かを判定する剰余判定部と、剰余が生じる場合に剰余の部分を処理する第1処理部と、所定サイズの各ブロックを処理する第2処理部と、第1処理部または第2処理部で処理された各データを組み合わせて外部へ出力する出力部とを備えることを特徴とする画像処理装置。【選択図】図８
2009044547.tif 000002
【特許請求の範囲】
【請求項１】
外部からの画像データを入力させる入力部と、
入力されたデータを所定サイズのブロックに分割するブロック分割部と、
前記画像データが所定サイズのブロックに剰余なく分割できるか否かを判定する剰余判定部と、
剰余が生じる場合に剰余の部分を処理する第1処理部と、
所定サイズの各ブロックを処理する第2処理部と、
第1処理部または第2処理部で処理された各データを組み合わせて外部へ出力する出力部とを備えることを特徴とする画像処理装置。
【請求項２】
前記剰余判定部は、主走査方向の画素の並びからなる各ラインが所定画素数のブロックに剰余なく分割できるか否かを判定する請求項１記載の画像処理装置。
【請求項３】
前記剰余判定部は、主走査方向に直交する副走査方向において、各ラインが所定ライン数に剰余なく分割できるか否かをさらに判定する請求項２記載の画像処理装置。
【請求項４】
前記第１処理部は、ＣＰＵがプログラムを実行することにより剰余の部分を画像処理する画像処理部である請求項１〜３の何れか一つに記載の画像処理装置。
【請求項５】
前記第２処理部は、画像処理回路により各ブロックを画像処理する画像処理部である請求項１〜４の何れか一つに記載の画像処理装置。
【請求項６】
前記第1および第2画像処理部は、対象のデータを圧縮処理または伸張処理するものである請求項１〜５の何れか一つに記載の画像処理装置。
【請求項７】
前記圧縮処理または伸張処理の方式は、JPEG、JBIGまたはLZWの何れかの方式である請求項１〜６の何れか一つに記載の画像処理装置。
【請求項８】
外部からの画像データを入力させる工程部と、
入力されたデータを所定サイズのブロックに分割する工程と、
前記画像データが所定サイズのブロックに剰余なく分割できるか否かを判定する工程と、
剰余が生じる場合に剰余の部分を処理する第1の処理工程と、
所定サイズの各ブロックを処理する第2の処理工程と、
第1または第2の処理工程で処理された各ブロックを組み合わせて外部へ出力する工程とを備えることを特徴とする画像処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、画像データの圧縮および伸張を行う画像処理装置および画像処理方法に関する。
【背景技術】
【０００２】
画像をデジタルデータ（画像データ）に変換して処理する画像処理装置において、記憶容量を節約し、また、転送時間を短縮するために画像データを圧縮することが多い。圧縮された画像データを用いる際は、元の画像データに復元する処理、即ち伸張処理が行われる。画像データの圧縮および伸張（圧縮／伸張）処理の方式として、種々のものが知られている。例えば、主に２値静止画像に用いられるMH、MR、MMR、LZWおよびJBIG、主に多値静止画像に用いられるJPEGなどの方式が知られている。これらの圧縮／伸張処理は、ハードウェアで実現することもできるしソフトウェアで実現することもできる。一般に、ハードウェア処理はソフトウェア処理に比べて高速である。一方、ソフトウェア処理はパーソナルコンピュータ等本来的にCPUを備える機器で処理する場合にそのCPUを使用できる点でコストメリットがある。そこで、ハードウェア処理とソフトウェア処理は、用途や機器に応じて使い分けられている。
【０００３】
また、一つの機器でハードウェア処理とソフトウェア処理の両方を使い分けることも提案されている。例えば、ホストコンピュータ上でプリンタドライバ等に印刷用のページ記述言語をレンダリングさせて印刷を行う場合、ホストコンピュータ上にレンダリング機能を行う特別なハードウェア機能が存在した場合に前記ハードウェア機能と連携しながら効率よく処理を行う手法として、次のものが提案されている。即ち、記憶装置に対して管理されている第1のジョブをレンダリングする場合、ハードウエアレンダリング対象として記憶装置に記憶されている全ての第2のジョブのレンダリング終了時間と、ソフトウェアレンダリング対象として前記記憶装置に記憶されている全ての第3のジョブの終了時間をCPUが比較し、該比較された終了時間に基づいて、記憶装置に記憶された第1のジョブを第2のジョブあるいは第3のジョブとして登録制御するものである（例えば、特許文献１参照）。
【０００４】
また、一般的にハードウェアによる画像データの圧縮処理および伸張処理は、ソフトウェア処理に比べて高速であるといわれているが、いかなる場合でもハードウェア処理の方が速いという訳ではない。ハードウェア処理とソフトウェア処理はそれぞれ特性が異なる。
【０００５】
例えば、処理対象の画像データ量が小さい場合は、ソフトウェア処理のほうが早い場合がある。ハードウェア処理の場合、通常、そのハードウェアを動作させる前（あるいは前後）に動作条件を設定しなければならない。設定箇所が多かったり、設定値を求めるまでの処理が複雑であったりすると、動作条件の設定に要する処理時間が無視できなくなる。
【０００６】
また、準備されたハードウェアの数だけ処理が実行されると次の処理は使用中のハードウェア資源が空くまで待たざるを得ない。従って、ハードウェアの資源管理が必要となる。ハードウェア資源は、コストとの兼ね合いもあって冗長な数が用意されるわけではない。一方、マルチタスクなど並列処理可能な構造を有するソフトウェアの場合、ある程度動的に資源（処理タスク）の数を増減させることができ融通が利きやすいという特性がある。
【０００７】
従って、ハードウェアの動作条件設定や資源獲得に要する処理時間（いわゆるオーバーヘッド）を含めると、画像データ量がある程度以下になるとソフトウェア処理の方が速度的に有利になる。ただし、どの程度からソフトウェア処理が有利かについては、実際に処理が行われる際の負荷や各資源の数および能力に依存するので一概にはいえない。
【特許文献１】特開２００３−７６５１１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
画像データを所定サイズのブロック単位で処理するハードウェアを設け、前記ハードウェアを用いて画像データの処理を行い、ソフトウェア処理に比べて画像処理の高速化を図ろうとする画像処理装置が知られている。例えば、JPEG圧縮方式では8画素×8画素を１つのブロック（処理単位）として圧縮処理を行う。そこで、前記処理単位を対象とするハードウェアを用意し、そのハードウェアにブロック単位で画像データを転送することにより、ハードウェア的に圧縮／伸張処理を実現することができる。
【０００９】
しかしながら、処理対象の画像データの縦方向あるいは横方向の画素数は、8画素の倍数とは限らず、むしろそうでない方が通常である。その場合、画像の端部では、画素幅が処理単位の8画素に満たない剰余の部分（冗長領域）が存在する。冗長領域は、8画素×8画素を処理単位として設計されたハードウェアでは処理できない。
【００１０】
そこで、例えば、圧縮または伸張処理前に冗長領域の画素幅を8画素に拡張するように画素データを付加してハードウェアの圧縮器または伸張器へ転送し、前記画像データが付加された状態で画像の圧縮または伸張処理を行い、処理後の画像から付加した画素分を削除する（クリッピング処理）といった対処が行われている。ここで、冗長領域に付加する画素データは、画像の背景色に合わせ、白色背景であれば白色に対応する画素値（例えば、画素値ゼロ）を付加する必要がある。そうしなければ、その処理単位について好ましい結果は得られない。
【００１１】
なお、8画素×8画素を圧縮／伸張処理の単位とするのはJPEG方式に特有のものである。しかし、一般に、ハードウェア的に圧縮／伸張処理を行う場合は、圧縮器または伸張器へ所定サイズのデータを単位とした転送が行われる。そして、主走査方向の画素幅を転送可能な単位に丸める処理を行う。その観点から、この発明に係る画像データの分割処理はJPEG方式に限定されない。例えば、画像処理装置が64bit幅のバスで構成され、前記バスを介して1画素が8bitの画像データを転送する場合、データ転送の転送はバス幅の64bit、即ち8画素単位で行われる。ここで、主走査方向の1ラインの画素数が8画素の倍数でない場合、各ラインの末尾に画素データを付加し、各ラインの画素数を8の倍数にして転送する。あるいは、データの転送がDMA転送により行われる場合、1ラインの画素数が1バーストの倍数になるよう、各ラインの末尾に画素データを付加して圧縮器または伸張器へ転送する場合もある。各ラインと処理の単位を整合させることによって画像データを管理し易くするためである。
【００１２】
このようにして各ラインを転送単位の倍数に丸めた状態で圧縮／伸張処理されたデータは、圧縮器または伸張器から転送先として一時的に確保されたメモリ領域へ格納される。転送先メモリ領域のライン幅は、丸め処理後の幅である。その後、各ラインの末尾に付加された画素データに相当する部分のクリッピング処理を行う。
【００１３】
以上の説明から明らかなように、ハードウェアで圧縮／伸張処理を行う装置において、その内容を詳細に検討すると、ハードウェアによる圧縮／伸張機能を利用するための準備処理が行われる。通常、前記準備処理、即ち、資源管理、動作条件設定やクリッピング処理は、ソフトウェアで処理される。そして、それらの処理時間は、オーバーヘッドを生じさせる。さらに、画素データが付加された分だけ転送先メモリ領域が転送元データの容量より余分に占有される。
【００１４】
発明者は、冗長領域を従来のようにハードウェア的に圧縮または伸張処理を行うことが適切であるのかという点に疑問を感じ、ソフトウェア的に圧縮または伸張処理を行う場合との比較検討を行った。そして、本願の出願に至った。
【００１５】
この発明は、以上のような事情からなされたものであって、画像を所定サイズのブロックに分割し、各ブロックについて画像処理を行う画像処理装置において、所定サイズの各ブロックと所定サイズに満たない剰余部分とで画像処理を行う処理部を異ならせ、処理時間の短縮とメモリ領域の節約とを実現し得る手法を提供するものである。
【課題を解決するための手段】
【００１６】
この発明は、外部からの画像データを入力させる入力部と、入力されたデータを所定サイズのブロックに分割するブロック分割部と、前記画像データが所定サイズのブロックに剰余なく分割できるか否かを判定する剰余判定部と、剰余が生じる場合に剰余の部分を処理する第1処理部と、所定サイズの各ブロックを処理する第2処理部と、第1処理部または第2処理部で処理された各データを組み合わせて外部へ出力する出力部とを備えることを特徴とする画像処理装置を提供する。
【００１７】
また、異なる観点から、この発明は、外部からの画像データを入力させる工程部と、入力されたデータを所定サイズのブロックに分割する工程と、前記画像データが所定サイズのブロックに剰余なく分割できるか否かを判定する工程と、剰余が生じる場合に剰余の部分を処理する第1の処理工程と、所定サイズの各ブロックを処理する第2の処理工程と、第1または第2の処理工程で処理された各ブロックを組み合わせて外部へ出力する工程とを備えることを特徴とする画像処理方法を提供する。
【発明の効果】
【００１８】
この発明の画像処理装置は、前記画像データが所定サイズのブロックに剰余なく分割できるか否かを判定する剰余判定部と、剰余が生じる場合に剰余の部分を処理する第1処理部と、所定サイズの各ブロックを処理する第2処理部とので、所定サイズの各ブロックと所定サイズに満たない剰余部分とで画像処理を行う処理部を異ならせ、各ブロックの特性に応じた処理部に処理させることにより処理時間の短縮とメモリ領域の節約とを実現することができる。即ち、第1処理部は、所定サイズのデータを第2処理部に比べて短時間で処理できるように構成され、第2処理部は、対象の画像データによってサイズが変わる剰余部分を、第1処理部と並行して処理し得るように構成される。第2処理部は、種々のサイズに柔軟に対応でき、そのためのコスト的な負担あるいは処理時間の変動が第1処理部に比べて抑制されるように構成される。
【００１９】
以下、この発明の好ましい態様について説明する。
前記剰余判定部は、主走査方向の画素の並びからなる各ラインが所定画素数のブロックに剰余なく分割できるか否かを判定してもよい。
【００２０】
前記剰余判定部は、主走査方向に直交する副走査方向において、各ラインが所定ライン数に剰余なく分割できるか否かをさらに判定してもよい。
【００２１】
また、前記第１処理部は、ＣＰＵがプログラムを実行することにより剰余の部分を画像処理する画像処理部であってもよい。
【００２２】
さらにまた、前記第２処理部は、画像処理回路により各ブロックを画像処理する画像処理部であってもよい。
【００２３】
前記第1および第2画像処理部は、対象のデータを圧縮処理または伸張処理するものであってもよい。
【００２４】
また、前記圧縮処理または伸張処理の方式は、JPEG、JBIGまたはTIFFの何れかの方式であってもよい。
ここで示した種々の好ましい態様は、それら複数を組み合わせることもできる。
【発明を実施するための最良の形態】
【００２５】
以下、図面を用いてこの発明をさらに詳述する。なお、以下の説明は、すべての点で例示であって、この発明を限定するものと解されるべきではない。
【００２６】
図１は、この発明の画像処理装置の構成例を示すブロック図である。図１で、画像データ処理部は１１は、データ入力部２１から入力された画像データを処理し、データ出力部２３へ出力する。
画像データ処理部１１には、ＣＰＵ１７、メモリ１９、ハードウェア的に構成されたJPEG圧縮器１３およびハードウェア的に構成されたJPEG伸張器１５が含まれる。
【００２７】
メモリ１９は、ＲＡＭである。メモリ１９には、画像データ処理部１１の電源オン時、図示しない不揮発性記憶素子に格納された制御プログラムが展開される。また、データ入力部２１から入力された画像データを一時的に格納する。即ち、転送元データ領域を提供する。さらに、JPEG圧縮器１３あるいはJPEG伸張器１５から出力される処理後の画像データを一時的に格納する。即ち、転送先データ領域を提供する。さらに、ＣＰＵ１７が画像データ等の処理を行う際のワークエリアを提供する。
【００２８】
ＣＰＵ１７は、前記制御プログラムを実行することにより、画像データの処理を制御する。即ち、JPEG圧縮器１３、JPEG伸張器１５を動作させる際の動作条件設定を行う。また、JPEG圧縮器１３およびJPEG伸張器１５の資源管理を行う。さらに、ＣＰＵ１７は、データ入力部２１から入力された画像データをソフト的にJPEG圧縮およびJPEG伸張することができる。即ち、ソフトウェア的なJPEG圧縮器およびJPEG伸張器としての処理が可能である。ＣＰＵ１７は、入力部２１から入力された画像データの構成を判別する。そして、画像データを処理単位（ブロック）に分割した場合、冗長領域が存在するか否かを判別し、判別結果に応じて各ブロックの圧縮処理または伸張処理をハードウェアの圧縮器１３で行うか、あるいは、ソフトウェア的にＣＰＵ１７が処理するかを判断し、判断結果に応じて対象のブロックを処理するように制御する。この実施形態では、JPEG圧縮およびJPEG伸張の処理単位である8画素×8画素をブロックの単位として説明する。他の圧縮／伸張方式（周知のMH、MR、MMRなどの方式）の場合は主として転送処理の単位でブロック化されるが、この発明の本質はいずれの場合にも共通する。
【００２９】
この実施形態で、JPEG圧縮器１３およびJPEG伸張器１５は、ASIC（Application Specific Integrated Circuit、特定用途向けIC）として設計され提供されるものである。
データ入力部２１は、外部のユニットから画像データを取得するためのインターフェイス回路である。外部のユニットの一例は、原稿の画像を走査して読み取るイメージスキャナである。この実施形態において、データ入力部２１と外部のユニットとの間はデータバスで接続されており、画像データは外部のユニットからデータ入力部２１へDMA転送される。データ入力部２１は、バス・インターフェイス回路やDMAコントローラを含んでなる回路である。
【００３０】
データ出力部３１は、外部のユニットへ画像データを出力するためのインターフェイス回路である。ここで、前記ユニットは、通常、データ入力部へ画像データを提供するユニットとは異なるが、同一のユニットの場合もあり得る。前記ユニットの一例は画像を印刷する印刷装置である。他の一例は、圧縮処理後の画像データを格納する補助記憶装置、具体的にはハードディスクドライブ（HDD）である。なお、HDDに格納された画像データを伸張する場合、データ入力部21を介してHDDからの画像データを取得し、伸張処理する。この場合、デ―タ入力部に画像データを提供する外部のユニットは前記HDDである。この実施形態において、データ出力部２３と外部のユニットとの間はデータバスで接続されており、画像データは、データ出力部２３から外部のユニットへDMA転送される。データ出力部２３は、バス・インターフェイス回路やDMAコントローラを含んでなる回路である。
【００３１】
次に、この発明に係る圧縮／伸張処理の処理手順について説明する。ここで、この発明に係る処理手順の詳細を説明する前に、参考例として画像データをすべてハードウェア処理あるいはソフトウェア処理する際の手順について簡単に説明する。これにより、後述する本願発明の処理手順の特徴がより理解し易くなるであろう。
【００３２】
図８は、この発明の画像処理装置の機能的な構成を示すブロック図である。図８に示すように、画像処理装置１は、入力部２、剰余判定部３、ブロック分割部４、第1処理部５、第2処理部６および出力部７から構成される。
【００３３】
外部からの画像データは、入力部２を介して入力される。ブロック分割部４は、入力されたデータを所定サイズのブロックに分割する。剰余判定部３は、前記画像データが所定サイズのブロックに剰余なく分割できるか否かを判定する。第1処理部５は、分割されたデータに剰余が生じる場合、剰余の部分を処理する。第2処理部６は、所定サイズからなる各ブロックを処理する。第1処理部または第2処理部で処理された各データは、メモリ１９上で組み合わされ、処理後の画像データとして出力部７から外部へ出力される。なお、図８の画像処理装置１は、この発明に係るブロックを示すものである。従って、画像処理装置１が、図８に示しないブロックを含むことを排除するものではない。
【００３４】
図２は、参考例として、入力された画像データを無条件にハードウェアあるいはソフトウェアで圧縮／伸張処理する手順を示すフローチャートである。図２（ａ）は、ハードウェア処理の手順であり、図２（ｂ）は、ソフトウェア処理の手順である。画像処理装置の構成としては、ハードウェア処理の場合は図１の構成と同様であり、ソフトウェア処理の場合は、図１の構成から圧縮器１３、伸張器１５を除いたものを想定すればよい。図３は、図２の処理を行う際に使用されるメモリ領域を模式的に示す説明図である。図３（ａ）は、ハードウェア処理の場合を示し、図３（ｂ）は、ソフトウェア処理の場合を示す。以下に述べるように、ソフトウェア処理の場合は、処理後の画像データが格納される領域に冗長領域を確保する必要がない。
【００３５】
図２（ａ）のハードウェア処理の場合について説明する。なお、フロー開始時点で、資源としての圧縮器１３または伸張器１５が確保されているものとする。さらに、メモリ資源として転送元データ領域と転送先データ領域がメモリ１９上に確保されているものとする。
【００３６】
まず、ＣＰＵ１７は、圧縮器１３または伸張器１５の動作条件をレジスタに設定する（ステップS11）。前記設定には、転送元（図３（ａ）の転送元データ領域３１）のメモリアドレス、転送先（図３（ａ）の転送先データ領域３３）のメモリアドレスの指定が含まれる。
【００３７】
その後、圧縮／伸張処理が開始される。即ち、ＣＰＵ１７あるいは外部からデータ転送のトリガが与えられ、転送元データ領域３１の画像データが圧縮器１３または伸張器１５へ転送される。データが転送されると、圧縮器１３または伸張器１５は、転送されたデータを圧縮処理または伸張処理する（ステップS13）。圧縮処理または伸張処理後のデータは、転送先データ領域３３へ転送されて格納される。転送先データ領域３３に格納されるデータには、冗長領域が含まれる。圧縮器１３または伸張器１５は、8画素×8画素のサイズを単位としてデータを処理し、それを転送元データ領域３１へ格納するからである。
【００３８】
ＣＰＵ１７は、転送先データ領域３３に格納された画像データのうちの冗長領域に対して、画像背景と同じ画像データを書き込む。いわゆるゴミ消し処理である（ステップS15）。即ち、ゴミ消し処理は、ソフトウェア処理である。
【００３９】
ゴミ消し処理後、画像データは、データ出力部２３を介して外部へ出力される（ステップS17）。
【００４０】
次に、図２（ｂ）のソフトウェア処理の場合を説明する。フロー開始時点で、メモリ資源としての転送元データ領域３１と圧縮／伸張処理後のデータを格納する出力データ領域３５がメモリ上に確保されているものとする。ソフトウェア処理の場合、ＣＰＵが各ブロックの位置を認識して処理を行うので、出力データ領域３５中に冗長領域を確保する必要がない。即ち、出力データ領域３５の大きさは転送元データ領域３１と一致する。ＣＰＵ１７は、8画素×8画素以下の画素が処理対象であるブロックの場合、ワークエリア上でそのブロックに画素を付加して処理し、処理後のデータを出力データ領域に格納する際には不要な画素を格納しない。
【００４１】
ＣＰＵ１７は、圧縮／伸張処理に適用する各種パラメータを決定する（ステップS21）。次に、ＣＰＵ１７は、転送元データ領域３１中の8画素×8画素のブロックを対象に圧縮または伸張処理を行う（ステップS23）。そして、処理されたデータを出力データ領域３３へ格納する。次に、ＣＰＵ１７は、処理すべきブロックが残っているか否かを判断する（ステップS25）。処理すべきブロックが残っている場合、ルーチンはステップS23へ進み、次のブロックを対象に圧縮または伸張処理を行う。一方、処理すべきブロックが残っていない場合は、圧縮／伸張処理を終了する。
【００４２】
このように、ソフトウェア処理の場合、ＣＰＵ１７は、処理対象の各ブロックの画像データ中の位置を認識したうえで圧縮／伸張処理を行う。その認識に基づいてデータの格納を行うので出力データ領域３５に冗長領域を確保する必要がない。ハードウェア処理と比べて、冗長領域の分だけ少ないメモリ領域で圧縮／伸張処理を行うことが可能となる。しかし、画像データのサイズが大きくなると、ハードウェア処理と比較して処理時間を要するようになる。
【００４３】
以上、参考例によってハードウェア処理とソフトウェア処理の特性を説明した。次に、この発明に係る圧縮／伸張処理の手順を説明する。なお、処理開始時点で、資源としての圧縮器１３または伸張器１５が確保されているものとする。さらに、メモリ資源として転送元データ領域と出力データ領域がメモリ１９上に確保されているものとする。
【００４４】
図６は、この発明に係る圧縮／伸張処理の手順を示すフローチャートである。図７は、図６の処理において、ハードウェア処理を行う際に使用されるメモリ領域を模式的に示す説明図である。図７で、メモリ資源として確保された転送元データ領域を符号３１で、出力データ領域を符号４１で示している。
【００４５】
図６で、ＣＰＵ１７は、圧縮／伸張処理開始の指示を受領すると、処理対象となる画像データのデータ量を取得し（ステップS31）、所定のデータ量よりも大きいか否かを判断する（ステップS33）。ここで、データ量は、フロー開始に先立って転送元データ領域を確保するために算出された値を参照してもよい。
【００４６】
画像データのデータ量が所定のデータ量以下の場合は、ソフトウェアで圧縮／伸張処理を行うと決定する（ステップS35）。この場合、ソフトウェア処理の手順は、既に参考例として示した図２（ｂ）と同様である。
【００４７】
一方、処理容量が所定量を超える場合には、ハードウェアで圧縮／伸張処理を行うと決定する。それを前提に、ＣＰＵ１７は、画像データのサイズから冗長領域があるか、即ち、画像データの縦横の画素数がいずれも8の倍数であるか否かを判断する（ステップS37）。
【００４８】
判断の結果、縦横の画素数がいずれも8の倍数で冗長領域が無い場合は、画像データの全領域が8画素×8画素のブロックに分割できる。そこで、各ブロックをハードウェア処理の対象とするように圧縮器１３または伸張器１５の動作条件を設定する（ステップS41）。即ち、転送元データ領域の全領域が圧縮器１３または伸張器１５に転送されるように設定する。設定終了後、各ブロックの圧縮処理または伸張処理を開始する（ステップS43）。その後、ルーチンは後述するステップS51へ進む。なお、縦横の画素数がいずれも8の倍数であるので、転送先データ領域３３のメモリ容量は、転送元データ領域３１と一致する。
【００４９】
一方、前記判断の結果、冗長領域がある場合、ＣＰＵ１７は、転送元データ領域３１を各ブロックが8画素×8画素からなる基本領域３７（図７参照）とそれ以外の冗長領域３９とに分類する。そして、基本領域３７を対象にハードウェア処理を行い、冗長領域を対象にソフトウェア処理を行うように決定する。
【００５０】
まず、基本領域３７の各ブロックをハードウェア処理の対象とするように圧縮器１３または伸張器１５の動作条件を設定する（ステップS45）。即ち、転送元データ領域の全領域が圧縮器１３または伸張器１５に転送されるように設定する。設定終了後、基本領域３７の各ブロックの圧縮処理または伸張処理を開始する（ステップS47）。これによって、基本領域３７の各ブロックのデータが圧縮器１３または伸張器１５へ転送される。図７に示すように、処理された画像データの転送先は、出力データ領域４１中の領域４３である。領域４３は、基本領域３７に対応する。
ハードウェアによる基本領域３７の処理が開始された後、ＣＰＵ１７は、冗長領域３９の圧縮処理または伸張処理を実行する（ステップS49）。冗長領域３９に対するソフトウェア処理の手順は、既に参考例として示した図２（ｂ）と同様である。図７に示すように、処理された画像データの転送先は、出力データ領域４１中の領域４５である。領域４５は、冗長領域３９に対応する。
冗長領域３９のソフトウェア処理が終了したら、ＣＰＵ１７は、前記ステップS47で開始した基本領域３７ハードウェア処理が終了したか否かを確認し（ステップS51）、終了を待つ。
【００５１】
冗長領域３９と基本領域３７の両方の処理が終了したことが確認されたら、ＣＰＵ１７は、出力データ領域４１に格納された画像データをデータ出力部２３を介して出力する（ステップS53）。
【００５２】
ここで、図６のステップS47で開始されたハードウェア処理と、ステップS49のソフトウェア処理は並行して行われる。このように構成されているので、画像データを全てハードウェア処理する場合、あるいは全てソフトウェア処理する場合に比べて、画像データの処理時間の短縮することができる。
【００５３】
図７で、出力データ領域４１中の領域４５のメモリ容量は、冗長領域３９のメモリ容量と等しい。冗長領域３９がソフトウェア処理されるためである。また、出力データ領域４１中の領域４３のメモリ容量は、基本領域３７のメモリ容量と等しい。基本領域３７の各ブロックは、いずれも8画素×8画素からなるためである。従って、出力データ領域４１のメモリ容量は、転送元データ領域３１のメモリ容量と等しい。
【００５４】
先に、画像データ量がある程度以下になるとソフトウェア処理の方が速度的に有利になると述べた。その傾向を実証する参考値を以下に説明する。ただし、先にも述べたように、どの程度からソフトウェア処理が有利かについては結果に影響を与える種々の要因があり、一概にはいえない。
【００５５】
参考例として、１MBの画像データをすべてハードウェア処理した場合の全体の処理時間と、すべてソフトウェア処理した場合の処理時間の一例を挙げると、ハードウェア処理した場合は３５０ｍｓｅｃを要し、ソフトウェア処理した場合は６７０ｍｓｅｃを要した。
【００５６】
さらに、おなじ画像処理装置で150kBの画像データを処理した場合、すべてハードウェア処理した場合は３０ｍｓｅｃを要し、すべてソフトウェア処理した場合は２２ｍｓｅｃを要した。
【００５７】
図４および図５は、上記処理において、図２（ａ）のハードウェア処理の各ステップおよび図２（ｂ）のソフトウェア処理の各ステップが全体の処理時間に占める割合を示すグラフである。図４は1MBの画像データを処理したときの結果、図５は、1kBの画像データを処理したときの結果をそれぞれ示している。
【００５８】
図４（ａ）および図５（ａ）は、ハードウェア処理の場合を示している。「レジスタ設定」は図２（ａ）のステップS11に相当する処理時間を、「画像処理」は図２（ａ）のステップS13およびS15に相当する処理時間を、「データ転送」は図２（ａ）のステップS17に相当する処理時間をそれぞれ示している。
【００５９】
図４（ｂ）および図５（ｂ）は、ソフトウェア処理の場合を示している。「パラメータ設定」は図２（ｂ）のステップS21に相当する処理時間を、「画像処理」は図２（ｂ）のステップS23およびS25に相当する処理時間をそれぞれ示している。図４と図５とを比較すると、データ量が小さくなるといわゆるオーバーヘッドの処理時間の全体に占める割合が増えていることがわかる。その変化の割合がソフトウェア処理とハードウェア処理とで異なるために、データ量が小さい場合はソフトウェア処理の処理時間が全体としてハードウェア処理に比べて短縮されるといえる。
【００６０】
前述した実施の形態の他にも、この発明について種々の変形例があり得る。それらの変形例は、この発明の範囲に属さないと解されるべきものではない。この発明には、請求の範囲と均等の意味および前記範囲内でのすべての変形とが含まれるべきである。
【図面の簡単な説明】
【００６１】
【図１】この発明の画像処理装置の構成例を示すブロック図である。
【図２】参考例として、入力された画像データを無条件にハードウェアあるいはソフトウェアで圧縮／伸張処理する手順を示すフローチャートである。
【図３】参考例としての図２の処理を行う際に使用されるメモリ領域を模式的に示す説明図である。
【図４】参考例において、図２（ａ）のハードウェア処理の各ステップおよび図２（ｂ）のソフトウェア処理の各ステップが全体の処理時間に占める割合を示す第1のグラフである。
【図５】参考例において、図２（ａ）のハードウェア処理の各ステップおよび図２（ｂ）のソフトウェア処理の各ステップが全体の処理時間に占める割合を示す第2のグラフである。
【図６】この発明に係る圧縮／伸張処理の手順を示すフローチャートである。
【図７】この発明に係る圧縮／伸張処理において、ハードウェア処理を行う際に使用されるメモリ領域を模式的に示す説明図である。
【図８】この発明の画像処理装置の機能的な構成を示すブロック図である。
【符号の説明】
【００６２】
１：画像処理装置
２：入力部
３：剰余判定部
４：ブロック分割部
５：第1処理部
６：第2処理部
７：出力部
１１：画像データ処理部
１３：圧縮器（ハードウェア）
１５：伸張器（ハードウェア）
１７：ＣＰＵ
１９：メモリ
２１：データ入力部
２３：データ出力部
３１：転送元データ領域
３３：転送先データ領域（ハードウェア処理）
３５：出力データ領域（ソフトウェア処理）
３７：基本領域
３９：冗長領域
４１：出力データ領域（本願処理）
４３：基本領域対応部分
４５：冗長領域対応部分
【図１】
2009044547.tif 000003
【図２】
2009044547.tif 000004
【図３】
2009044547.tif 000005
【図４】
2009044547.tif 000006
【図５】
2009044547.tif 000007
【図６】
2009044547.tif 000008
【図７】
2009044547.tif 000009
【図８】
2009044547.tif 000010