JP2018047611A - 画像処理装置、画像処理方法、及びプログラム - Google Patents

Abstract

【課題】スキャンラインアルゴリズムとオブジェクト圧縮を併用したバンド並列レンダリングを行う場合において、描画不正の問題を回避する。
【解決手段】中間データ生成手段は、ページ内に複数の圧縮画像によるイメージのオブジェクトが含まれ、当該複数の圧縮画像が属するバンドの情報に基づいて、先に伸長される圧縮画像が後に伸長される圧縮画像によって上書きされないように各圧縮画像に対して共通のアドレスを指定し、レンダリング手段は、担当するバンドのみのビットマップ画像データを生成する複数のレンダリング処理手段と、いずれかのレンダリング処理手段からの伸長指示に基づいて、指定された共通のアドレスの伸長バッファに複数の圧縮画像を順次伸長する１個の伸長処理手段と、を有し、複数のレンダリング処理手段は、伸長処理手段による伸長結果を用いて、それぞれが担当するバンドのビットマップ画像データを生成する。
【選択図】図７

Description

本発明は、印刷データのバンド並列レンダリング技術に関する。

従来より、レンダリングを高速化するための様々な技術が提案されている。例えば特許文献１には、MFP（Multi Function Peripheral）内に複数のレンダラを有し、１ページ分の印刷データ（PDLデータ）をページより小さな領域サイズ毎に並列してレンダリング処理する技術がある。また、レンダリング技術の１つとしてスキャンラインアルゴリズムが一般的に知られている。スキャンラインアルゴリズムとは、PDLデータから中間データを作成して一度保持し、当該中間データに従って該当する画素の色値を決定しながら、スキャンライン単位で画像を形成するアルゴリズムである。また、レンダリングに必要なメモリを削減する手法として、オブジェクト圧縮が知られている。オブジェクト圧縮は、印刷データに含まれるPDL（Page Description Language）にて定義された画像を可逆あるいは非可逆圧縮した圧縮画像を作り、RIPで出力画像を形成する際には必要に応じて圧縮画像を伸長して描画画像とする手法である。

スキャンラインアルゴリズムとオブジェクト圧縮を併用する場合、スキャンライン上に存在する全ての描画画像を伸長しておく必要がある。圧縮画像を伸長する領域を有効活用する技術として、特許文献２が提案されている。具体的には、中間データを作る際に、ページ上部に登場する圧縮画像の伸長先バッファを、ページ下部に登場する圧縮画像の伸長先バッファとして使いまわせるよう、双方の圧縮画像に、同じ伸長バッファアドレス（メモリアドレス）を関連付けるというものである。

特開２０１２−１５８９５１号公報 特開２０１３−１１９２４２号公報

上記特許文献２の技術を特許文献１のバンド並列レンダリングに適用すると、次のような場面で描画不正の問題が起こり得た。描画不正の問題が生じ得る場面は、同じアドレスに関連付けられた2つの圧縮画像が中間データに含まれ、かつ、2つの圧縮画像それぞれが隣接する2つのバンド（上バンドと下バンド）別々に必要とされるような場面である。そして、このような場面で、第1のレンダラが上バンド内にある圧縮画像の伸長結果（RAW画像）を用いたレンダリング中に、第2のレンダラが下バンド内にある圧縮画像の伸長結果を用いたレンダリングを開始したとする。そうなると、第1のレンダラが処理中のRAW画像が、第2のレンダラが処理するRAW画像によって上書きされてしまい、不正描画となるわけである。

本発明は、スキャンラインアルゴリズムとオブジェクト圧縮を併用したバンド並列レンダリングを行う場合において、上述した描画不正の問題を回避することを目的とする。

本発明に係る画像処理装置は、印刷データを変換して中間データをページ単位で生成する中間データ生成手段と、生成された中間データに基づいて、ページよりも小さいバンド単位で並列にレンダリングを行い、ビットマップ画像データを生成するレンダリング手段と、を備えた画像処理装置であって、前記中間データ生成手段は、ページ内に複数の圧縮画像によるイメージのオブジェクトが含まれ、当該複数の圧縮画像を伸長するための伸長バッファのアドレスに同じアドレスを指定する場合、当該複数の圧縮画像が属するバンドの情報に基づいて、先に伸長される圧縮画像が後に伸長される圧縮画像によって上書きされないように各圧縮画像に対して共通のアドレスを指定し、前記レンダリング手段は、担当するバンドのみのビットマップ画像データを生成する複数のレンダリング処理手段と、前記複数のレンダリング処理手段のうちいずれかのレンダリング処理手段からの伸長指示に基づいて、前記指定された共通のアドレスの伸長バッファに前記複数の圧縮画像を順次伸長する１個の伸長処理手段と、を有し、前記複数のレンダリング処理手段は、前記伸長処理手段による伸長結果を用いて、それぞれが担当するバンドのビットマップ画像データを生成することを特徴とする。

本発明によれば、バンド並列レンダリングを行う場合において、上述した描画不正の問題を回避しつつ、メモリ領域を効率的に使いまわすことが出来る。

画像形成装置のハードウェア構成の一例を示す図である。 （ａ）は画像形成装置の印刷処理に関するソフトウェア構成を示すブロック図であり、（ｂ）は中間データ生成モジュールの内部構成を示す図である。 （ａ）はDLのデータ構造の一例を示す図、（ｂ）及び（ｃ）はそれぞれ圧縮画像伸長命令と描画命令の詳細を示す図である。 RIPのハードウェア構成例を示す図である。 印刷ジョブからマップ画像データが生成されるまでの流れを示すフローチャートである。 圧縮画像を含むページのPDLデータの一例を示す図である。 実施例１に係る、フィル情報生成処理の詳細を示すフローチャートである。 各イメージオブジェクトの画像サイズと位置関係を示すテーブルの一例である。 実施例１に係る、各イメージオブジェクトに割り当てられた伸長バッファのアドレスを示すテーブルの一例である。 実施例２に係る、フィル情報生成処理の詳細を示すフローチャートである。 実施例２に係る、各イメージオブジェクトに割り当てられた伸長バッファのアドレスを示すテーブルの一例である。 実施例２に係る、第１レンダリング処理部におけるレンダリング処理の流れを示すフローチャートである。 DLの一例を示す図である。 実施例２に係る、圧縮画像管理リストの一例を示す図である。 実施例２に係る、第２レンダリング処理部におけるレンダリング処理の流れを示すフローチャートである。

以下、添付の図面を参照して、本発明を実施する形態について説明する。なお、以下の実施例において示す構成は一例に過ぎず、本発明は図示された構成に限定されるものではない。

まず、本実施例に係る画像形成装置のハードウェア構成について説明する。図１は、画像形成装置のハードウェア構成の一例を示す図である。図１に示す画像形成装置１００は、ホストPC１３０とLAN１２０を介して接続されている。印刷を行いたいユーザは、ホストPC１３０において印刷対象の文書についての印刷ジョブを生成し、ホストPC１３０からLAN１２０を介して画像形成装置１００に対して送信する。印刷ジョブにはページ記述言語（Page Description Language）で記述された、文字、写真、図形といったオブジェクトをページ内にどのように配置するかを指定するデータ（PDLデータ）を含んでいる。そのため印刷ジョブは印刷データとも呼ばれる。そして、本実施例では、PDLデータのページ内に写真オブジェクトの圧縮画像を含んでいることが前提となる。なお、ここでの画像形成装置１００は、中間データに対しバンド単位の並列レンダリングを行なって印刷を行うSFP（Single Function Printer）を想定している。しかし、画像形成装置はコピーやFAXといった複数の機能を備えたMFPであってもよい。中間データに対してバンド単位の並列レンダリングによって印刷を行う機能（印刷手段）を有する装置であれば、本実施例の手法は幅広く適用可能である。以下、本実施例の画像形成装置１００を構成する各部について説明する。

CPU１０１は各種演算処理を行なうプロセッサであり、画像形成装置１００全体の制御を司る。RAM１０２は、CPU１０１が動作するためのシステムワークメモリである。また、RAM１０２は、ホストPC１３０から受け取った印刷ジョブ内のPDLデータを解釈して生成される中間データを一時的に格納したり、中間データをレンダリング処理する際の作業領域でもある。ROM１０３は、システムのブートプログラムなどを格納する。大容量記憶部１０４は、例えばハードディスクドライブであり、各種処理のためのシステムソフトウェアやホストPC１３０から受信した印刷ジョブを格納する。

操作部１０５は、各種メニューや印刷データ情報等を表示するためのディスプレイ及びユーザが各種入力操作を行うためのボタンやキーを有し、操作部I/F１０６を介してシステムバス１０９と接続される。

ネットワークI/F１０７は、ＬＡＮ１２０を介してホストPC１３０を含む外部装置との間で各種データ・情報のやり取りを行うインタフェースである。これら各部は、システムバス１０８に接続されている。

イメージバスI/F１０９は、システムバス１０８と画像データを高速に転送するイメージバス１１０とを接続するインタフェースであって、データ構造を変換するバスブリッジである。イメージバス１１０には、RIP（Raster Image Processor）１１１とプリンタ部１１２が接続されている。

RIP１１１は、複数のプロセッサ、メモリ、伸長処理回路などで構成され、CPU１０１からの指示に基づき、PDLデータから生成された中間データであるDL（ディスプレイリスト）をラスタ形式の画像データ（ビットマップ画像データ）に変換する。プリンタ部１１２は、RIP１１１で生成されたビットマップ画像データをデバイスI/F１１３を介して受け取って、紙等の記録媒体に画像を形成して出力する。なお、本明細書において「レンダリング」とは、中間データであるDLからラスタ形式の画像データを生成することを意味し、いわゆるラスタライズと同義である。

図２（ａ）は、画像形成装置１００の印刷処理に関するソフトウェア構成を示すブロック図であり、PDLデータ解析モジュール２０１、中間データ生成モジュール２０２、レンダリングモジュール２０３で構成される。

PDLデータ解析モジュール２０１は、ホストPC１３０から入力された印刷ジョブに含まれるPDLデータを解析し、オブジェクト情報を取得する。オブジェクト情報は、さらに、属性情報、パス形状情報、オペランド情報、オペレータ情報で構成される。属性情報は、そのオブジェクトがイメージであるのか、グラフィックであるのか、テキストであるのかといったオブジェクトの属性を示す情報である。パス形状情報は、オブジェクトの描画範囲情報（Bounding Box）や、オブジェクトのアウトラインを点列で表現したパス点列情報等、オブジェクトの位置やアウトラインに関する情報である。オペランド情報は、オブジェクトのオペランド種別（例えば、ImageやFlatFill）、色情報、色空間（例えばRGB、Gray）といった、描画に関する情報である。オペレータ情報は、オブジェクトの階層（Raster Operation等）に関する情報である。取得したオブクジェト情報は、中間データ生成モジュール２０２に送られる。

中間データ生成モジュール２０２は、PDLデータ解析モジュール２０１から受け取ったページ情報及びオブジェクト情報に基づいて、中間データ（DL）を生成する。DLは、ディスプレイリストの略であり、その中にはエッジリストと呼ばれるオブジェクトのエッジに関する情報が含まれる。エッジリストは、オブジェクトの開始点やアウトライン等に関するエッジ情報、エッジ同士の上下関係等に関するレベル情報、オブイジェクトの色に関するフィル情報で構成される。さらに、フィル情報には、オブジェクトが圧縮画像である場合、当該圧縮画像の格納先となるメモリ領域のアドレスを示す情報と、当該圧縮画像の伸長先となる伸長バッファのアドレスを示す情報が含まれる。中間データ生成モジュール２０２は、ページ内の全オブジェクトをエッジリストへ変換し、スキャンライン順に処理できるようにエッジリストをソートし、スキャンライン毎に画像形成処理する為に必要な命令（圧縮画像伸長命令、描画命令等）を発行することでDLを生成する。図３（ａ）は、DLのデータ構造の一例を示す図である。描画開始命令３００は、そのページの描画開始を指示する命令である。圧縮画像伸長命令３１０は、皇族の描画命令３２０にて圧縮画像を描画する場合に、予めレンダラとしてのレンダリングモジュール２０３に対して圧縮画像の伸長を指示する命令である。この圧縮画像伸長命令３１０には、圧縮画像を格納するメモリ領域のアドレス情報と、その伸長先である伸長バッファのアドレス情報が含まれる。レンダリングモジュール２０３は、この命令を受けて、指定された伸長バッファへ圧縮画像を伸長する。描画命令３２０は、スキャンライン毎の描画指示命令である。描画命令３２０には上述したエッジ情報、レベル情報、フィル情報が含まれ、さらに圧縮画像がある場合は、その伸長先である伸長バッファのアドレス情報が含まれる。レンダリングモジュール２０３が描画命令を処理する時点では、圧縮画像伸長命令３１０の処理が完了している為、圧縮画像を伸長して得られたRAW画像が伸長バッファに格納されている。図３の（ｂ）及び（ｃ）は、それぞれ圧縮画像伸長命令３１０と描画命令３２０の詳細を示す図である。圧縮画像伸長命令３１０には、JPEG、PNG等の画像の圧縮形式、伸長前の圧縮画像のデータサイズ、圧縮画像の格納領域を特定するデータ先頭アドレス、圧縮画像の伸長先を特定する伸長先バッファアドレスの各情報が含まれる。描画命令３２０には、エッジの開始点を示す開始スキャンライン、エッジのアウトラインを示すパス点列、エッジ同士の上下関係等を示すレベル、フィルの種別を示すフィルタイプの各情報が含まれる。また、フィルタイプが圧縮画像である場合は、伸長後先頭アドレスの情報も含まれる。

レンダリングモジュール２０３は、生成された中間データに基づいて、バンド毎に並列でレンダリングを行い、ページ単位でビットマップ画像データを生成する。図４は、レンダリングモジュール２０３によるバンド毎の並列レンダリングを可能にする、本実施例に係るRIP１１１のハードウェア構成例を示す図である。RIP１１１は、第１レンダリング処理部４１１、第２レンダリング処理部４１２、及び、中間データに含まれる圧縮画像を第１レンダリング処理部４１１からの伸長指示に基づいて伸長する伸長処理部４１３で構成される。伸長処理部４１３で伸長された後のRAW画像データは、伸長画像格納用メモリ４２０に格納される。伸長画像格納メモリ４２０は第１レンダリング処理部４１１、第２レンダリング処理部４１２双方から参照可能であり、各々が必要とするタイミングで伸長画像格納メモリ４２０からRAW画像データを取得する。また、伸長処理部４１３は、内部にレジスタ（不図示）を有しており、受け取った伸長指示のうち伸長処理が完了した数（解凍された圧縮画像の数）を当該内部レジスタに記憶する。この内部レジスタに記憶される数値は、１ページ分の処理が終了する毎に“0”に初期化される。内部レジスタの値は、第１レンダリング処理部４１１、第２レンダリング処理部４１２双方から参照可能である。また、内部レジスタに代えて、伸長画像格納メモリ４２０の所定の領域に伸長処理が完了した数を格納する構成であってもよい。第１レンダリング処理部４１１、第２レンダリング処理部４１２は、DLに含まれる上述のエッジ情報とフィル情報から、各オブジェクトのビットマップ画像を生成する。

なお、本実施例では、PDLデータ解析モジュール２０１と中間データ生成モジュール２０２は、CPU１０２が所定のプログラムに従いRAM１０２を用いて実現する構成を想定している。しかしながら、PDLデータを解析してビットマップ画像データを生成するまでのすべての工程をRIP１１１内の閉じた構成の中で行うようにしてもよい。また、本実施例では前述のRAM１０２を伸長画像格納用メモリ４２０として用いることを想定しているが、RAM１０２とは別個に伸長画像格納のための専用メモリを設けてもよい。また、本実施例では、バンド並列レンダリングを2個のレンダリング処理部で行う構成としているが、レンダリング処理部の数は3個以上でもよい。

＜用語の説明＞
ここで、本実施例のレンダリング処理で登場する、「エッジ」「スキャンライン」「スパン」「レベル」「フィル」「バンド」の各用語について確認しておく。

エッジとは、ページ内に存在するオブジェクト同士の境界、又はオブジェクトと背景の境目を指す。すなわち、エッジはオブジェクトのアウトラインである。

スキャンラインとは、画像形成処理において画像データが連続的にメモリ走査される主走査方向のラインである。スキャンラインの高さは１ピクセルとなっている。そして、複数のスキャンラインを束ねたものがバンドである。

スパンとは、単一のスキャンラインにおいて、エッジ間の区間を指す。この区間のことを閉領域とも呼ぶ。

レベルとは、ページ内に描画するオブジェクト同士の上下関係を示す情報であり、各オブジェクトには必ずそれぞれ異なるレベル番号が割り振られる。レベルは、Ｚオーダーとも呼ばれ、ページの背面から前面に向かう方向（ページの描画範囲をＸＹ平面で表現した際のＸＹ平面に直交する方向：Ｚ軸方向）に沿ったオブジェクトの並び順を表す。

フィルとは、スパンに対する塗り情報であり、ビットマップ画像データやシェーディングのように１ピクセル毎に異なる色値を持つフィルや、ベタ塗りのようにスパン中で色値の変化がないフィルが存在する。したがって、１つのスパン（閉領域）については、当該スパンに関連するオブジェクトの数だけレベルが存在し、レベルの数だけ異なるフィルを有することになる。

次に、中間データ生成モジュール２０２の詳細について説明する。図２（ｂ）は、中間データ生成モジュール２０２の内部構成を示す図である。中間データ生成モジュール２０２は、フィル生成モジュール２１１、レベル生成モジュール２１２、エッジ生成モジュール２１３、管理モジュール２１４の計４つのサブモジュールで構成される。

フィル生成モジュール２１１は、オペランド情報からフィル情報を生成する。フィル生成モジュール２１１は、印刷対象のページ内にあるイメージオブジェクトが圧縮画像である場合、レンダリング時にその圧縮画像を伸長するための伸長バッファを確保する。なお、従来技術では全ての圧縮画像に対して別々に伸長バッファを確保していた。本実施例では、レンダリングモジュール２０３の並列性を担保しつつ、一部の伸長バッファを使いまわすことにより、伸長バッファの省メモリ化を実現している。伸長バッファをどのように使いまわすかについては後述する。

レベル生成モジュール２１２は、オペレータ情報からレベル情報を生成する。レベル情報は、ページ内に配置されるオブジェクトをZオーダー量（X方向およびY方向に直交するZ方向での値）で表現した情報や、オブジェクト同士の重なりに関する情報である。例えば、レベル1のオブジェクトは、レベル0のオブジェクトより上に描かれることを示す。

エッジ生成モジュール２１３は、パス形状情報からエッジ情報を生成する。また、管理モジュール２１４は、フィル生成モジュール２１１、レベル生成モジュール２１２及びエッジ生成モジュール２１３で生成した各情報をDLに登録する。

続いて、印刷ジョブからビットマップ画像データを生成するまでの大まかな処理の流れを説明する。図５は、印刷ジョブからビットマップ画像データが生成されるまでの流れを示すフローチャートである。この一連の処理は、ROM１０３に記憶されたプログラムをRAM１０２に展開し、これをCPU１０１が実行することによって実現される。以下では、図６に示す、 “A”〜“F”のイメージオブジェクトが配されたページのPDLデータを含む印刷ジョブがホストPC１３０から送信されたものとして説明を行なうものとする。図６中の破線は、レンダリングモジュール２０３の処理単位であるバンド境界を示している。本実施例では、１ページの幅が220ピクセル、高さが300ピクセルとし、1バンドが60本のスキャンラインで構成されるものとする。なお、本実施例の場合、後述するステップ５０７におけるレンダリング処理を並列で行なうことを目的に、予め印刷ジョブのデータを分割するようなことは行わない。

ホストPC１３０から受信した印刷ジョブは、RAM１０２又は大容量記憶装置１０４にまず格納される。そして、ステップ５０１において、PDLデータ解析モジュール２０１は、格納された印刷ジョブに含まれるPDLデータの中から処理対象として注目するPDLコマンド（注目PDLコマンド）を読み出して解析し、前述のオブジェクト情報を取得する。

ステップ５０２において、中間データ生成モジュール２０２内のフィル情報生成モジュール２１１は、注目PDLコマンドについて取得されたオブジェクト情報からフィル情報を生成する。フィル情報生成処理の詳細については後述する。

ステップ５０３において、レベル生成モジュール２１２は、オペレータ情報からレベル情報を生成する。レベル情報は、オペレータ情報に含まれるROP（Raster Operation）情報等を考慮しながら、原則としてオブジェクトの処理順にレベルが決定される。

ステップ５０４において、エッジ生成モジュール２１３は、パス形状情報からエッジ情報を生成する。エッジ情報は、ステップ５０２で生成したフィル情報（圧縮画像の格納先及び伸長先のアドレス情報を含む）とステップ５０３で生成したレベル情報とのリンク構造で構成される。

ステップ５０５において、管理モジュール２１４は、ステップ５０３〜ステップ５０４で生成した各情報をエッジリストとして、DLに登録する。

そして、ステップ５０６では、受信したPDLデータにおけるPDLコマンドの終端に達したかどうかが判定される。終端に達していなければステップ５０１に戻って、未処理のPDLコマンドについての処理が繰り返される。こうして、ページ単位でDLが生成される。一方、終端に達していればステップ５０７に進む。

ステップ５０７において、レンダリングモジュール２０３は、RIP１１１を用いて、CPU１０１からの指示に基づき、生成されたページ単位のDLを解析し、ビットマップ画像データを生成する。このとき、RIP１１１では、第１レンダリング処理部４１１と第２レンダリング処理部４１２の夫々が並列に、処理対象ページのDLにおける自身が担当するバンドについてビットマップ画像データの生成を行う。

以上が、印刷ジョブからビットマップ画像データを生成するまでの大まかな流れである。

続いて、本実施例の特徴である伸長バッファの割り当て方法について説明する。伸長バッファの割り当ては、フィル情報生成処理においてなされる。図７は、フィル情報生成処理の詳細を示すフローチャートである。

ステップ７０１では、オブジェクト情報内のオペランド情報から、注目PDLコマンドに係るオブジェクトのフィルが、FlatFill（ベタ塗り）なのか或いはイメージなのかが判定される。判定の結果、フィルがFlatFillであれば、ステップ７０２に進んで、FlatFillで指定された色値をフィル情報として設定し、本処理を終了する。一方、フィルがイメージであれば、ステップ７０３に進む。

ステップ７０３では、イメージが圧縮画像であるかどうかが判定される。判定の結果、圧縮されていないRAW画像である場合は、フィル情報にそのイメージを設定して本処理を終了する。一方、圧縮画像である場合は、ステップ７０４へ進む。図６のページの場合、6個のオブジェクトはすべて圧縮画像であるため、ステップ７０４へ移行することになる。

ステップ７０４では、取得済みの伸長バッファがあるかどうかが判定される。取得済みの伸長バッファがある場合はステップ７０５に進み、ない場合はステップ７０８に進む。

ステップ７０５では、取得済みの伸長バッファのサイズと、注目PDLコマンドに係る圧縮画像を伸長した際のサイズ（以下、「注目RAWサイズ」）とが比較される。取得済みの伸長バッファが複数ある場合には、各取得済み伸長バッファのサイズと、注目RAWサイズとがそれぞれ比較される。比較の結果、取得済み伸長バッファのサイズが、注目RAWサイズと等しい或いは大きい場合はステップ７０６に進む。一方、注目RAWサイズの方が取得済み伸長バッファのサイズよりも大きい場合は、ステップ７０７に進む。

ステップ７０６では、取得済み伸長バッファに対応する圧縮画像が属するバンドと、注目PDLコマンドに係る圧縮画像（以下、注目圧縮画像）が属するバンドとが重複又は隣接しているかどうか判定される。双方の圧縮画像が属するバンドが重複又は隣接している場合は、Ｓ７０７へ進む。一方、双方の圧縮画像が属するバンドが重複又は隣接していない場合は、ステップ７０９へ進む。

ステップ７０７では、未処理の取得済み伸長バッファがあるかどうかが判定される。未処理の取得済み伸長バッファがあれば、それを次の比較対象の取得済み伸長バッファとして、注目RAWサイズとの比較が繰り返される。未処理の取得済み伸長バッファがなければ、ステップ７０８へ進む。

ステップ７０８では、注目圧縮画像を伸長するためのメモリ領域が注目RAWサイズ分だけ確保され、当該確保されたメモリ領域のアドレスが、当該注目圧縮画像のための伸長バッファのアドレスとして指定される。

ステップ７０９では、ステップ７０６で重複も隣接もしないと判定された取得済み伸長バッファのアドレスと同一のアドレスが、注目圧縮画像を伸長するための伸長バッファのアドレスとして指定される。すなわち、2つの圧縮画像について同じメモリ領域が、共通の伸長バッファとして使いまわされることになる。

ここで、本実施例に係るフィル情報生成処理を、具体例を用いて説明する。図８は、図６に示すページにおける6個のイメージオブジェクト“A”〜“F”の画像サイズと位置関係を示すテーブルである。図８のテーブルにおいて、「圧縮サイズ」は、圧縮画像である各イメージオブジェクトのデータサイズであり、オペランド情報から得られる。「RAWサイズ」は当該圧縮画像の伸長後のデータサイズである。このRAWサイズは、伸長後の画像における幅高及び色空間（ビット数）から算出される。なお、各画像サイズの単位はKBである。「BoundingBox」は、オブジェクトの描画領域を示しており、パス形状情報から得られる。「バンド」は、BoundingBoxで特定される描画領域が属するバンドの番号を示している。例えば、オブジェクト“C”については、バンド1とバンド2の双方に跨っていることから、当該バンドの番号である1と2が記述されている。以下、説明の便宜上、各イメージオブジェクトを、“Obj_A”〜“Obj_F”で表すものとする。

まず、先頭のObj_Aについては、先行する他のイメージオブジェクトが存在しない為（ステップ７０４でNo）、そのRAWサイズ＝4.7KBのメモリ領域が新規に確保され、Obj_Aのための伸長バッファのアドレス（0x00010000）が指定される。

次に、Obj_Bについては、先行するObj_Aのための取得済み伸長バッファがあり（ステップ７０４でYes）、その伸長バッファサイズ（4.7KB）と、Obj_BのRAWサイズ＝3.5KBとが比較される（ステップ７０５）。比較の結果、取得済み伸長バッファのサイズの方が大きいため（ステップ７０５でYes）、取得済み伸長バッファに対応するObj_Aが属するバンドと、Obj_Bが属するバンドが重複又は隣接するかが判定される（ステップ７０６）。この場合、いずれのバンドもバンド1なので重複することになる（ステップ７０６でYes）。そして、未処理の取得済み伸長バッファも存在しないため（ステップ７０７でNo）、Obj_BのRAWサイズ＝3.5KBのメモリ領域が新たに取得され、Obj_Bのための伸長バッファのアドレス（0x00020000）が指定される（ステップ７０８）。

次に、Obj_Cについては、先行するObj_A及びObj_Bについて取得済み伸長バッファがあり（ステップ７０４でYes）、まず、Obj_Aの伸長バッファサイズ（4.7KB）と、Obj_CのRAWサイズ＝4.7KBとが比較される（ステップ７０５）。比較の結果、両サイズは等しいので（ステップ７０５でYes）、取得済みの伸長バッファに対応するObj_Aが属するバンドと、Obj_Cが属するバンドが重複又は隣接するかが判定される（ステップ７０６）。この場合、Obj_Cの一部もバンド1に属するので、重複することになる（ステップ７０６でYes）。そして、Obj_Bの取得済み伸長バッファが存在するため（ステップ７０７でYes）、改めてObj_Bの伸長バッファサイズ（3.5KB）と、Obj_CのRAWサイズ＝4.7KBとが比較される（ステップ７０５）。今度は、取得済み伸長バッファのサイズの方が小さいためステップ７０７に進むが、未処理の取得済み伸長バッファはもう存在しないので、ステップ７０８に進むことになる。そして、Obj_CのRAWサイズ＝4.7KBのメモリ領域が新たに確保され、Obj_Cのための伸長バッファのアドレス（0x00030000）が指定される。

次に、Obj_Dについては、先行するObj_A〜Obj_Cについて取得済みの伸長バッファがあり（ステップ７０４でYes）、まず、Obj_Aの伸長バッファサイズ（4.7KB）と、Obj_DのRAWサイズ＝4.7KBとが比較される（ステップ７０５）。比較の結果、両サイズは等しいので、ステップ７０６に進む（ステップ７０５でYes）。取得済みの伸長バッファに対応するObj_Aが属するバンド1と、Obj_Dが属するバンド2とは隣り合っており隣接するので、ステップ７０７に進む（ステップ７０６でYes）。そして、次に、未処理のObj_Bの伸長バッファサイズ（3.5KB）と、Obj_DのRAWサイズ＝4.7KBとが比較される（ステップ７０５）。この場合、取得済み伸長バッファのサイズの方が小さいため、ステップ７０７に進む（ステップ７０５でNo）。そして、次に、未処理のObj_Cの伸長バッファサイズ（4.7KB）と、Obj_DのRAWサイズ＝4.7KBとが比較される（ステップ７０５）。比較の結果、両サイズは等しいので、ステップ７０６に進む（ステップ７０５でYes）。この場合、Obj_Cの一部もバンド2に属するので、重複することになる（ステップ７０６でYes）。再びステップ７０７に進むが、未処理の取得済み伸長バッファはもう存在しないので、ステップ７０８に進むことになる。そして、Obj_DのRAWサイズ＝4.7KBのメモリ領域が新たに確保され、Obj_Dのための伸長バッファのアドレス（0x00040000）が指定される。

次に、Obj_Eについては、先行するObj_A〜Obj_Dについて取得済みの伸長バッファがあり（ステップ７０４でYes）、まず、Obj_Aの伸長バッファサイズ（4.7KB）と、Obj_EのRAWサイズ＝4.7KBとが比較される（ステップ７０５）。比較の結果、両サイズは等しいので、ステップ７０６に進む（ステップ７０５でYes）。取得済みの伸長バッファに対応するObj_Aが属するバンド1と、Obj_Eが属するバンド3とは異なるバンドであり隣り合ってもいないので、ステップ７０９に進む（ステップ７０６でNo）。その結果、Obj_Eのための伸長バッファのアドレスに、Obj_Aのための伸長バッファと同一のアドレス（0x00010000）が指定される。

最後に、Obj_Fについては、先行するObj_A〜Obj_Eについて取得済みの伸長バッファがあり（ステップ７０４でYes）、まず、Obj_Aの伸長バッファサイズ（4.7KB）と、Obj_FのRAWサイズ＝7.0KBとが比較される（ステップ７０５）。比較の結果、Obj_FのRAWサイズの方が大きいため（ステップ７０５でNo）、ステップ７０７に進む。以降、残りのObj_B〜Obj_Eについて同様の処理を行うが、取得済みの伸長バッファサイズの中にObj_FのRAWサイズ以上のものはないため、ステップ７０８に進むことになる。そして、Obj_FのRAWサイズ＝7.0KBのメモリ領域が新たに確保され、Obj_Fのための伸長バッファのアドレス（0x00050000）が指定される。

以上の内容をまとめたものが、図９の表である。Obj_A〜Obj_D及びObj_Fについては新規に伸長バッファが確保されるものの、Obj_EについてはObj_Aの伸長バッファと同じアドレスが指定されており、共通のメモリ領域が使いまわされているのが分かる。

本実施例によれば、注目圧縮画像のための伸長バッファを、当該注目圧縮画像が属するバンドとは重複も隣接もしないバンドに属する他の圧縮画像のための伸長バッファと共通にする。これにより、複数のレンダリング処理部に競合による待ち合わせを発生させることなく、伸長バッファを最大限使いまわすことが出来る。

実施例１では、バンド並列レンダリングにおける並列性を最大限引き出しながら、使用する伸長バッファが最小で済む様な省メモリ手法について説明した。次に、バンド並列レンダリングにおける並列性を下げる代わりに、メモリ削減率を高める態様について実施例２として説明する。なお、実施例１と共通する内容については説明を省略ないしは簡略化し、以下では差異点を中心に説明するものとする。

本実施例では、レンダリングモジュール２０３で伸長タイミングを制御しながら伸長メモリを使いまわすことで、メモリ削減率を実施例１の手法よりも高める。画像形成装置１０のハードウェア及びソフトウェアの基本構成は実施例１と共通である。以下、本実施例の特徴であるフィル情報生成処理について、図１０のフローチャートを参照して詳しく説明する。

ステップ１００１〜ステップ１００５は、実施例１の図７のフローチャートにおけるステップ７０１〜ステップ７０５と同様である。ステップ１００５で、取得済みの伸長バッファのサイズが、注目RAWサイズと等しい或いは大きい場合はステップ１００６に進む。一方、注目RAWサイズの方が取得済み伸長バッファのサイズよりも大きい場合は、ステップ１００８に進む。

ステップ１００６では、取得済み伸長バッファに対応する圧縮画像と注目圧縮画像とが同一スキャンライン上に存在しないかが判定される。具体的には、それぞれの圧縮画像のBoundingBoxのY座標における最大値と最小値の値域に重複がないかを判定する。これは同一スキャンライン上に同じアドレスが指定された圧縮画像が存在すると、レンダリングモジュール２０３にて双方の圧縮画像についての伸長と読み込みが競合し、描画不正が生じてしまうことから、そのような事態の発生を防ぐためである。取得済み伸長バッファに対応する圧縮画像と注目圧縮画像とが同一スキャンライン上に存在しない場合は、ステップ１００７に進む。一方、取得済み伸長バッファに対応する圧縮画像と注目圧縮画像とが同一スキャンライン上に存在する場合は、ステップ１００８へ進む。

ステップ１００７では、注目圧縮画像がバンド境界を跨いで存在しているかが判定される。注目圧縮画像がバンド境界を跨いでいる場合、上下それぞれのバンドを担当するレンダリング処理部が異なる。そこで、バンド毎に異なる伸長バッファを指定することで、描画不正が生じないようにする。注目圧縮画像がバンド境界を跨いでいる場合は、ステップ１００８へ進む。一方、注目圧縮画像がバンド境界を跨いでいない場合は、ステップ１０１０へ進む。

ステップ１００８以降は、実施例１の図７のフローチャートにおけるステップ７０７以降と同様である。すなわち、未処理の取得済み伸長バッファがあれば、それを次の比較対象の取得済み伸長バッファとして、注目RAWサイズとの比較が繰り返される（ステップ１００８）。そして、ステップ１００９では、注目圧縮画像を伸長するためのメモリ領域が注目RAWサイズ分だけ確保され、当該確保されたメモリ領域のアドレスが、当該注目圧縮画像のための伸長バッファのアドレスとして指定される。また、ステップ１０１０では、ステップ１００５で比較を行った取得済み伸長バッファのアドレスと同一のアドレスが、注目圧縮画像を伸長するための伸長バッファのアドレスとして指定される。すなわち、同じメモリ領域が伸長バッファとして使いまわされることになる。

以下に、本実施例に係るフィル情報生成処理の具体例を、前述の図６に示すページの場合を例に説明する。

まず、先頭のObj_Aについては、先行する他のイメージオブジェクトが存在しない為（ステップ１００４でNo）、そのRAWサイズ＝4.7KBのメモリ領域が新規に確保され、Obj_Aのための伸長バッファのアドレス（0x00010000）が指定される。

次に、Obj_Bについては、先行するObj_Aのための取得済み伸長バッファがあり（ステップ１００４でYes）、その伸長バッファサイズ（4.7KB）と、Obj_BのRAWサイズ＝3.5KBとが比較される（ステップ１００５）。比較の結果、取得済み伸長バッファのサイズの方が大きいため（ステップ１００５でYes）、取得済み伸長バッファに対応するObj_Aが同一スキャンライン上に存在しないかが判定される。ここで、Obj_AのY座標の値域は“10〜40”であり、Obj_BのY座標の値域は“20〜50”である（前述の図８のテーブルを参照）。この場合、“20〜40”で値域が重複しているため、Obj_Aが同一スキャンライン上に存在すると判定される（ステップ１００６でYes）。未処理の取得済み伸長バッファは存在しないため（ステップ１００８でNo）、Obj_BのRAWサイズ＝3.5KBのメモリ領域が新たに確保され、Obj_Bのための伸長バッファのアドレス（0x00020000）が指定される（ステップ１００９）。

次に、Obj_Cについては、先行するObj_A及びObj_Bについて取得済み伸長バッファがあり（ステップ１００４でYes）、まず、Obj_Aの伸長バッファサイズ（4.7KB）と、Obj_CのRAWサイズ＝4.7KBとが比較される（ステップ１００５）。比較の結果、両サイズは等しいので（ステップ１００５でYes）、取得済み伸長バッファに対応するObj_Aが同一スキャンライン上に存在しないかが判定される。Obj_AのY座標の値域は“10〜40”であり、Obj_CのY座標の値域は“50〜80”である。この場合、値域が重複しておらず、Obj_Aが同一スキャンライン上に存在しないと判定され（ステップ１００６でNo）、ステップ１００７に進む。ステップ１００７では、Obj_Cがバンド境界を跨いで存在しているかが判定される。Obj_Cはバンド1とバンド2の境界を跨いで存在しているため（前述の図８のテーブルを参照）、ステップ１００８に進む（ステップ１００７でYes）。さらに未処理の取得済み伸長バッファは存在しないため（ステップ１００８でNo）、Obj_CのRAWサイズ＝4.7KBのメモリ領域が新たに確保され、Obj_Cのための伸長バッファのアドレス（0x00030000）が指定される（ステップ１００９）。

次に、Obj_Dについては、先行するObj_A〜Obj_Cについて取得済みの伸長バッファがあり（ステップ１００４でYes）、まず、Obj_Aの伸長バッファサイズ（4.7KB）と、Obj_DのRAWサイズ＝4.7KBとが比較される（ステップ１００５）。比較の結果、両サイズは等しいので（ステップ１００５でYes）、取得済み伸長バッファに対応するObj_Aが同一スキャンライン上に存在しないかが判定される。Obj_AのY座標の値域は“10〜40”であり、Obj_DのY座標の値域は“70〜100”である。この場合、値域が重複しておらず、Obj_Aが同一スキャンライン上に存在しないと判定され（ステップ１００６でNo）、ステップ１００７に進む。ステップ１００７では、Obj_Dがバンド境界を跨いで存在しているかが判定される。Obj_Dはバンド2のみに属しており（前述の図８のテーブルを参照）バンド境界を跨いでいないため（ステップ１００７でYes）、ステップ１０１０に進む。その結果、Obj_Dのための伸長バッファのアドレスに、Obj_Aのための伸長バッファと同一のアドレス（0x00010000）が指定される。

次に、Obj_Eについては、先行するObj_A〜Obj_Dについて取得済みの伸長バッファがあり（ステップ１００４でYes）、まず、Obj_Aの伸長バッファサイズ（4.7KB）と、Obj_EのRAWサイズ＝4.7KBとが比較される（ステップ１００５）。比較の結果、両サイズは等しいので（ステップ１００５でYes）、取得済み伸長バッファに対応するObj_Aが同一スキャンライン上に存在しないかが判定される。Obj_AのY座標の値域は“10〜40”であり、Obj_EのY座標の値域は“130〜160”である。この場合、値域が重複してしておらず、Obj_Aが同一スキャンライン上に存在しないと判定され（ステップ１００６でNo）、ステップ１００７に進む。ステップ１００７では、Obj_Eがバンド境界を跨いで存在しているかが判定される。Obj_Eはバンド3のみに属しており（前述の図８のテーブルを参照）バンド境界を跨いでいないため（ステップ１００７でYes）、ステップ１０１０に進む。その結果、Obj_Eのための伸長バッファのアドレスに、Obj_Aのための伸長バッファと同一のアドレス（0x00010000）が指定される。なお、この際の指定先アドレスは、Obj_Cのための伸長バッファのアドレス“0x00030000”と同一でも構わない。

最後に、Obj_Fについては、先行するObj_A〜Obj_Eについて取得済みの伸長バッファがあり（ステップ１００４でYes）、まず、Obj_Aの伸長バッファサイズ（4.7KB）と、Obj_FのRAWサイズ＝7.0KBとが比較される（ステップ１００５）。比較の結果、Obj_FのRAWサイズの方が大きいため（ステップ１００５でNo）、ステップ１００８に進む。以降、残りのObj_B〜Obj_Eについて同様の処理を行うが、取得済みの伸長バッファサイズの中にObj_FのRAWサイズ以上のものはないため、ステップ１００９に進むことになる。そして、Obj_FのRAWサイズ＝7.0KBのメモリ領域が新たに確保され、Obj_Fのための伸長バッファのアドレス（0x00040000）が指定される。

以上の内容をまとめたものが、図１１の表である。Obj_A〜Obj_C及びObj_Fについては新規に伸長バッファが確保されるものの、Obj_DとObj_EについてはObj_Aの伸長バッファと同じアドレスが指定されており、実施例1よりもさらに共通のメモリ領域が使いまわされているのが分かる。

次に、本実施例に係る、バンド並列レンダリング処理について説明する。前述の通り、レンダリングモジュール２０３は、RIP１１１を用いて、CPU１０１からの指示に基づき、生成されたページ分のDLを解析し、ビットマップ画像データを生成する。このとき、RIP１１１では、第１レンダリング処理部４１１と第２レンダリング処理部４１２の夫々が並列に、生成されたページ分のDLの自身が担当する領域についてビットマップ画像データの生成を行う（前述の図５のフローチャートのステップ５０７）。

レンダリングモジュール２０３は、RIP１１１を用いて、中間データ生成モジュール２０２によって生成された中間データ（DL）基づき、ページ上部からスキャンライン単位のビットマップ画像データを生成していく。この際、ページを所定の領域（バンド高）毎に分け、奇数バンド領域を第１レンダリング処理部４１１が担当し、偶数バンド領域を第２レンダリング処理部４１２が担当して、ビットマップ画像データが生成される。つまり、第１レンダリング処理部４１１と第２レンダリング処理部４１２は、共通の中間データを読み込みながら並列に動作し、割り当てられた領域をレンダリングする。

RIP１１１は、DLの圧縮画像伸長命令を読み込み、上述の図１０のフローで指定された伸長バッファアドレスに伸長する。この際の伸長処理は、伸長処理部４１３に接続する第１レンダリング処理部４１１からのみ行う。第２レンダリング処理部４１２は、第１レンダリング処理部４１１が伸長処理部４１３を用いて伸長した結果を、指定された伸長バッファアドレスを参照することで読み込む。したがって、第２レンダリング処理部４１２は、読み込み対象のRAW画像が所定の伸長バッファアドレスに伸長済みかどうかを確認する必要がある。また、第１レンダリング処理部４１１は、伸長指示を伸長処理部４１３に対して行う前に、所定の伸長バッファアドレスが第２レンダリング処理部４１２によって参照中（アクセス中）かどうかを確認する必要がある。本実施例では、上述の点を踏まえつつ、バンド並列レンダリング処理における並列性を下げる代わりにメモリの削減率を高めるものである。具体的には、レンダリングモジュール２０３によって、圧縮画像の伸長タイミングが以下のように制御される。

まずは、第１レンダリング処理部４１１が担当する第１のバンド（ここでは奇数バンド）についてのレンダリング処理について説明する。図１２は、本実施例に係る、第１レンダリング処理部４１１におけるレンダリング処理の流れを示すフローチャートである。

ステップ１２０１では、生成されたDLに含まれる命令を１つ読み込む。図１３は、前述の図６に示すページについて生成されたDLを示している。このDL１３００に含まれる命令のうちどれを読み込むのかはポインタによって管理され、先頭の命令（ここでは、描画開始命令３００に相当する描画フレーム設定命令１３０１）から順に読み込まれる。ポインタによって指し示された命令の読み込みが完了すると、ポインタは次の命令へと移行する。こうして、DLに含まれる命令が順次読み込まれる。以下、図１３で示すDL１３００に基づき説明を行う。

ステップ１２０２では、ステップ１２０１で読み込んだ命令がページ終了命令（描画終了命令３４０に相当）かどうか判定される。ここでは、読み込んだ命令がページ終了命令１３１３でない場合はステップ１２０３に進む。一方、読み込んだ命令がページ終了命令１３１３である場合は、本処理を終了する。

ステップ１２０３では、ステップ１２０１で読み込んだ命令が圧縮画像伸長命令かどうか判定される。読み込んだ命令が例えば圧縮画像伸長命令１３０３の場合はステップ１２０４に進み、それ以外の命令である場合はステップ１２０７に進む。

ステップ１２０４では、読み込んだ圧縮画像伸長命令に基づき圧縮画像管理リストが作成される。図１４（ａ）は、図１３のDLにおける圧縮画像伸長命令１３０３及び１３０４の読み込みに応じて作成された圧縮画像管理リスト（以下、単に「リスト」と呼ぶ。）の一例である。リスト内の「伸長番号」は、伸長処理部４１３に伸長指示を行う順番を示す。「伸長後のメモリサイズ」は、圧縮画像を伸長した後のRAW画像のデータサイズを示す。「伸長先バッファアドレス」は、DLに示される伸長バッファアドレスを示す。「第１レンダリング処理部参照状態」と「第２レンダリング処理部参照状態」は、それぞれのレンダリング処理部における、伸長されたRAW画像の参照の要否を表す情報が入る。具体的には、“参照する”と“参照しない”の2状態である。この場合において“参照しない”には、対象のRAW画像が担当領域（バンド）外にある場合と、既にビットマップ画像の生成が完了しており以降の処理で当該RAW画像を参照する必要がない場合の2通りの状態が含まれる。この参照状態の情報は、“参照する”であれば“0”、“参照しない”であれば“1”といった具合に、フラグ等によって保持される。なお、初期設定は“参照する（0）”である。

ステップ１２０５では、圧縮画像管理リストの情報を元に、読み込んだ圧縮画像伸長命令が処理可能であるか否かが判定される。次に続く命令を正常に処理し描画不正の発生を未然に防ぐためである。伸長処理の実行が可能になるまで、圧縮画像管理リストの監視が継続される。この監視処理については、第２レンダリング処理部４１２におけるレンダリング処理の説明において、具体例を示しつつ詳しく述べることとする。

ステップ１２０６では、圧縮画像を伸長画像格納メモリ４２０に伸長するように伸長処理部４１３に対し指示がなされる。当該伸長指示がなされると、次に続く命令を読み込むためにステップ１２０１に戻る。伸長指示を受けて伸長処理Ｈ部４１３は、圧縮画像の伸長処理を行い、処理が完了した伸長指示の数（＝伸長が完了した圧縮画像の数）を内部レジスタに格納する。この内部レジスタの初期値は“0”であり、本フローを終了する際にリセットされて再び“0”に戻る。

ステップ１２０７では、ステップ１２０１で読み込んだ命令が描画命令かどうか判定される。ここでは、読み込んだ命令が例えば描画命令１３０５の場合はステップ１２０９に進み、それ以外の命令である場合はステップ１２０８に進む。

ステップ１２０８では、読み込んだその他の命令、例えば描画フレーム設定命令１３０１や描画領域設定命令１３０２に従った処理が実行される。所定の処理の実行が完了した後は、ステップ１２０１に戻って次の命令を読み込む。

ステップ１２０９では、読み込んだ描画命令に係るオブジェクトの情報が取得される。具体的には、描画命令に含まれるパス点列の情報に従って、各スキャンライン上にあるエッジ（オブジェクトの輪郭）が算出され、さらにフィルタイプと伸長番号に基づき当該オブジェクトをどのビットマップ画像で塗りつぶすかが決定される。

ステップ１２１０では、読み込んだ描画命令において指定された伸長番号の伸長画像（RAW画像）が、参照可能な状態か否かが判定される。この判定は、上述の圧縮画像管理リスト内の伸長番号と伸長処理部４１３の内部レジスタの値に基づき行われる。具体的には、圧縮画像管理リストを参照し、伸長処理が完了した圧縮画像の数を示す内部レジスタの値が、読み込んだ描画命令で指定された伸長番号以上の値であれば、伸長処理が完了していると判定する。伸長処理が完了した圧縮画像の数を示す内部レジスタの値が、読み込んだ描画命令で指定された伸長番号より小さい場合は、値が等しくなるまで一定間隔毎に本ステップの判定処理を繰り返す。値が等しくなれば、ステップ１２１１に進む。

ステップ１２１１では、伸長画像格納用メモリ４２０内のRAW画像をフィル情報として用いて、処理対象バンドである奇数バンドについてのビットマップ画像が生成される。

ステップ１２１２では、圧縮画像管理リストが更新される。具体的には、ビットマップ画像の生成が完了した奇数バンドにおいて、以降の処理で参照しないRAW画像がある場合、当該RAW画像の参照状態を“参照する”から“参照しない”に変更する。例えば、前述の図１４（ａ）に示すリストは、描画命令１３０５及び１３０６に基づくビットマップ画像の生成処理が完了した時点で、図１４（ｂ）のように更新される。すなわち、「第1レンダリング処理部参照状態」の情報が、Obj_Aに対応する伸長番号1とObj_Bに対応する伸長番号 2の双方について、“参照する”から“参照しない（参照済み）”に変更される。リストの更新が完了するとステップ１２０１に戻り、次の命令を読み込む。

以上が、第１レンダリング処理部４１１によるレンダリング処理の内容である。

続いて、第２レンダリング処理部４１２が担当する第２のバンド（ここでは偶数バンド）についてのレンダリング処理について説明する。図１５は、本実施例に係る、第２レンダリング処理部４１２におけるレンダリング処理の流れを示すフローチャートである。図１２のフローで示した、第１レンダリング処理部４１１が行うレンダリング処理との違いは、ステップ１２０４〜ステップ１２０６に相当するステップが存在しない点である。すなわち、圧縮画像伸長命令に基づく伸長指示はすべて第１レンダリング処理部４１１が行い、第２レンダリング処理部４１２は第１レンダリング処理部４１１が行った伸長処理の結果を、ステップ１５０７以降で利用する。以下、本フローの特徴部分を中心に説明する。

ステップ１５０１〜ステップ１５０３は、前述のステップ１２０１〜１２０３に相当する。ステップ１５０１で読み込んだ命令が圧縮画像伸長命令の場合（ステップ１５０３でYES）、本フローでは、次の命令を処理するべくステップ１５０１に戻る。

ステップ１５０４〜ステップ１５０６は、前述のステップ１２０７〜ステップ１２１２と同じである。ステップ１５０８までの処理によって処理対象バンドである偶数バンドについてのビットマップ画像の生成処理が完了すると、ステップ１５０９では、圧縮画像管理リストが更新される。図１４（ｃ）は、第２レンダリング処理部４１２がバンド2を処理中であり、第１レンダリング処理部４１１がバンド1の処理が終わってバンド3の処理を開始する時点のリストを示している。この時点では、第１レンダリング処理部４１１はバンド3内に存在するObjの描画命令を読み込み済みであり、第２レンダリング処理部４１２はバンド2内に存在するObjの伸長されたRAW画像を参照している状態である。

ここで、バンド2内に存在するObj_Dの圧縮画像とバンド3内に存在するObj_Eの圧縮画像については、その伸長バッファアドレスとして同じ内容「0x00010000」が指定されている（図１１の表を参照）。したがって、第２レンダリング処理部４１２がObj_Dの伸長結果（RAW画像）を参照している最中に、第１レンダリング処理部４１１が伸長処理部４１３にObj_Eの圧縮画像の伸長指示を行うと、Obj_Dの伸長結果が上書きされてしまう。そこで、第１レンダリング処理部４１１は、前述のステップ１２０５において、これから伸長する圧縮画像と伸長先が共通する他の圧縮画像の有無を、リスト内の「第２レンダリング部参照状態」によって確認するようにしている。例えば、伸長番号5と伸長番号4は伸長バッファアドレスが同じであるため、第１レンダリング処理部４１１は、伸長番号4の「第２レンダリング処理部参照状態」が“参照しない”になるまで監視・待機することになる。

以上が、第２レンダリング処理部４１１によるレンダリング処理の内容である。

以上のとおり本実施例では、圧縮画像管理リストを用いて伸長結果の参照が完了したかどうかを管理することで、参照が完了していない状態でのメモリ上書きを防ぎつつ、参照が完了した伸長結果については速やかに破棄することが可能となる。こうして、バンド並列レンダリングにおける並列性を下げる代わりに、メモリ削減率を高めることができる。

＜その他の実施例＞
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

Claims (12)

1. 印刷データを変換して中間データをページ単位で生成する中間データ生成手段と、
   生成された中間データに基づいて、ページよりも小さいバンド単位で並列にレンダリングを行い、ビットマップ画像データを生成するレンダリング手段と、
   を備えた画像処理装置であって、
   前記中間データ生成手段は、ページ内に複数の圧縮画像によるイメージのオブジェクトが含まれ、当該複数の圧縮画像を伸長するための伸長バッファのアドレスに同じアドレスを指定する場合、当該複数の圧縮画像が属するバンドの情報に基づいて、先に伸長される圧縮画像が後に伸長される圧縮画像によって上書きされないように各圧縮画像に対して共通のアドレスを指定し、
   前記レンダリング手段は、
   担当するバンドのみのビットマップ画像データを生成する複数のレンダリング処理手段と、
   前記複数のレンダリング処理手段のうちいずれかのレンダリング処理手段からの伸長指示に基づいて、前記指定された共通のアドレスの伸長バッファに前記複数の圧縮画像を順次伸長する１個の伸長処理手段と、
   を有し、
   前記複数のレンダリング処理手段は、前記伸長処理手段による伸長結果を用いて、それぞれが担当するバンドのビットマップ画像データを生成する
   ことを特徴とする画像処理装置。
2. 前記中間データ生成手段は、伸長バッファを取得済みの圧縮画像が属するバンドと、これから伸長バッファを取得する圧縮画像が属するバンドとが、互いに重複も隣接もしていない場合に、各圧縮画像に対して共通のアドレスを指定することを特徴とする請求項１に記載の画像処理装置。
3. 前記中間データ生成手段は、伸長バッファを取得済みの圧縮画像と、これから伸長バッファを取得する圧縮画像とが、同一スキャンライン上に存在せず、かつ、前記これから伸長バッファを取得する圧縮画像がバンド境界を跨いで存在していない場合に、各圧縮画像に対して共通のアドレスを指定することを特徴とする請求項１に記載の画像処理装置。
4. 前記いずれかのレンダリング処理手段は、前記伸長処理手段に対し、前記後に伸長される圧縮画像の伸長指示を、前記先に伸長される圧縮画像の伸長結果の参照が完了したことを確認した後に行うことを特徴とする請求項３に記載の画像処理装置。
5. 前記いずれかのレンダリング処理手段は、前記複数の圧縮画像の伸長結果に関する参照の要否を表す情報を含む管理リストに基づいて、前記確認を行うことを特徴とする請求項４に記載の画像処理装置。
6. 前記複数のレンダリング処理手段のそれぞれは、自身が担当するバンドにおいて前記伸長結果を以降のレンダリングで参照する必要がなくなった時点で、前記管理リストにおける前記情報を、参照を要しないことを表す内容に更新することを特徴とする請求項５に記載の画像処理装置。
7. 前記伸長処理手段は、伸長が完了した圧縮画像の数を表す値を格納するレジスタを有し、
   前記管理リストには、前記中間データに含まれるすべての圧縮画像の伸長する順番を示す値が登録され、
   前記複数のレンダリング処理手段のそれぞれは、前記管理リストに基づき、前記レジスタの値が、前記中間データから読み込んだ描画命令で指定された前記伸長する順番を示す値以上であれば、伸長が完了していると判断して、担当するバンドのビットマップ画像データを生成する
   ことを特徴とする請求項５又は６に記載の画像処理装置。
8. 前記複数のレンダリング処理手段のそれぞれは、
   前記バンドを分割したブロック単位でビットマップ画像データを生成し、前記ブロック単位で前記複数の圧縮画像の伸長指示を行い、
   前記中間データから読み込んだ描画命令の描画エリアから、前記伸長結果が参照されるブロックの最大値を求め、当該求めた最大値の情報を前記管理リストに登録し、
   前記登録された最大値の情報に基づいて、前記確認を行う
   ことを特徴とする請求項５に記載の画像処理装置。
9. 前記印刷データは、ページ記述言語で記述されていることを特徴とする請求項１乃至８の何れか１項に記載の画像処理装置。
10. 前記生成されたビットマップ画像データに基づく画像を印刷する印刷手段をさらに有することを特徴とする請求項１乃至９の何れか１項に記載の画像処理装置。
11. 印刷データを変換して中間データをページ単位で生成する中間データ生成ステップと、
    生成された中間データに基づいて、ページよりも小さいバンド単位で並列にレンダリングを行い、ビットマップ画像データを生成するレンダリングステップと、
    を含む画像処理方法であって、
    前記中間データ生成ステップでは、ページ内に複数の圧縮画像によるイメージのオブジェクトが含まれ、当該複数の圧縮画像を伸長するための伸長バッファのアドレスに同じアドレスを指定する場合、当該複数の圧縮画像が属するバンドの情報に基づいて、先に伸長される圧縮画像が後に伸長される圧縮画像によって上書きされないように各圧縮画像に対して共通のアドレスが指定され、
    前記レンダリングステップでは、担当するバンドのみのビットマップ画像データを生成する複数のレンダリング処理手段のうちいずれかのレンダリング処理手段からの伸長指示に基づいて、１個の伸長処理手段が指定された前記共通のアドレスの伸長バッファに前記複数の圧縮画像を順次伸長し、前記複数のレンダリング処理手段が当該伸長結果を用いて、それぞれが担当するバンドのビットマップ画像データを生成する
    ことを特徴とする画像処理方法。
12. コンピュータを、請求項１乃至１０のいずれか１項に記載の画像処理装置として機能させるためのプログラム。

Images