JPH10304158A - 画像処理装置 - Google Patents

Abstract

(57)【要約】 【課題】 バンドバッファの数が任意個数であっても待
ち時間を正確に求めて正確にオーバーランエラーを検出
する。 【解決手段】 バンド画像に対応するビットマップデー
タに展開するとともに、展開したビットマップデータ
を、バンドバッファ〜のいずれかに、予め作成され
たスケジュールにしたがった順番で格納する展開部３０
と、格納されたビットマップデータを、スケジュールに
したがった順番で読み出して、プリンタエンジン１００
に供給する転送部９０とを備える。レンダリング処理済
のバンドバッファの個数が「１」であって、経過時間が
「０」を超えている場合、あるいは、レンダリング処理
済のバンドバッファの個数が「０」以下であれば、オー
バーランエラー発生と検出する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、複数のバンドバッ
ファからビットマップデータを順番で読み出して画像出
力する画像処理装置に関する。

【０００２】

【従来の技術】一般に、ＰＤＬ（ページ記述言語）で記
述されたコード画像データを用いると、写真などのイメ
ージデータや、線図、表、文字などが混在した画像を、
異なった機種の端末において共通の出力装置で出力した
り、異なる出力装置において共通に出力することが可能
となる。このため、ＰＤＬは、画像出力を行なう場合に
広く用いられている。このようなコード画像データによ
って示される画像をページプリンタ等により出力する場
合、周知のように、当該コード画像データの内容を解釈
し、当該プリンタで要求される形式のビットマップデー
タに展開して、バッファに一旦格納した後（レンダリン
グ処理の後）、当該プリンタの出力動作（主走査動作と
副走査動作）に同期して供給する必要がある。ここで、
ビットマップデータに展開する方法としては、フレーム
バッファを用いる方法と、複数のバンドバッファを用い
る方法とがある。

【０００３】前者にかかるフレームバッファを用いる方
法は、ＰＤＬで記述されたコード画像データからビット
マップデータに直接展開して、当該フレームバッファに
１ページ分格納した後、格納したデータを読み出し、プ
リンタに供給して、当該データに基づいて画像出力を行
なうものである。ただし、この方法では、フレームバッ
ファに少なくとも１ページ分の容量が要求されるため、
コスト高を招致するといった欠点がある。さらに、複数
ページの画像を連続して出力する場合、各ページの出力
は、当該ページのビットマップデータがすべて展開され
てフレームバッファに格納されるまで待機する必要があ
るため、出力処理に時間がかかるといった欠点もある。

【０００４】このため、近年では、後者にかかるバンド
バッファを用いる方法が採用されている。このバンドバ
ッファを用いる方法は、出力画像を１ページ分の画像で
はなく、副走査方向に帯状に分割した画像（バンド画
像）で取り扱うものであり、詳細には、次の通りであ
る。すなわち、バンド画像を格納するバンドバッファを
複数用意するとともに、ＰＤＬで記述されたコード画像
データの内容を解釈して、バンド画像に対応するビット
マップデータを得るための中間コード画像データに一旦
変換した後、この中間コード画像データをバンド画像毎
に展開処理して、そのビットマップデータをバンドバッ
ファに格納する一方、格納したデータを、出力するバン
ド画像の順番で読み出し、プリンタに供給して、当該デ
ータに基づいて画像出力を行なう、という方法である。
すなわち、この方法では、ひとつのバンドバッファから
の読み出しと他のバンドバッファへの格納とが並行して
行なわれる。このようなバンドバッファを用いる方法で
は、バンドバッファの総容量を１ページ分よりも少なく
抑えられるので、コスト高となるのを防止でき、また、
ある程度のバンド画像に相当するビットマップデータが
得られた段階で、プリンタを起動できるので、出力処理
に要する時間をそれだけ短縮できるという利点もある。

【０００５】ところで、ＰＤＬは、ページを単位として
画像を扱うものであるため、ＰＤＬで記述されたコード
画像データから、ページを分割したバンド画像のビット
マップデータを直接得ることができない。このため、バ
ンドバッファを用いる方法では、ＰＤＬで記述されたコ
ード画像データから、一旦、バンド画像を単位とする中
間コード画像データに変換した後に、その中間コード画
像データを展開して、当該バンド画像のビットマップデ
ータを得なければならない。このため、バンドバッファ
を用いる方法では、次のような点を考慮しなければなら
ない。

【０００６】まず、バンド画像のレンダリング処理に要
する時間（すなわち、中間コード画像データの内容を解
釈してから、そのビットマップデータをバンドバッファ
に格納するまでに要する時間）は、そのバンド画像の内
容により大きく異なり、一般に複雑であればあるほど長
くかかる。このため、バンド画像の内容によっては（あ
るいは、プリンタの起動タイミングによっては）、ビッ
トマップデータの格納が完了していないうちに、当該バ
ンド画像の出力が始まってしまって、空のデータに基づ
いて画像出力されるという、いわゆる白抜けの状態（オ
ーバーランエラーとかアンダーフローとも呼ばれる）が
発生し得る。このためバンドバッファを用いる方法にお
いて、オーバーランエラーを防止する一方、もしオーバ
ーランエラーが発生した場合には、これを確実に検出す
る技術は、極めて重要である。

【０００７】このようなオーバーランエラーの原因とな
ったバンド画像を特定する技術としては、従来より例え
ば、特開平５−９６７９４号公報に記載の技術などがあ
る。この公報に記載の技術は、バンド画像に相当する量
のビットマップデータをバンドバッファからプリンタに
転送する毎に、その旨を示す転送終了信号を発するとと
もに、この転送終了信号が発せられたとき、次に転送す
べきバンドバッファの展開が完了しているか否かを判別
して、完了していなければ、当該バンド画像においてオ
ーバーランエラーが発生したと検出する技術である。す
なわち、ある１つのバンド画像を展開してそのビットマ
ップデータをバンドバッファに格納するのに要する時間
と、プリンタにおいて１つのバンド画像の出力に要する
時間（基準時間）とを比較して、前者が後者を超えれ
ば、オーバーランエラーと検出する技術である。

【０００８】ところで、一般に、バンドバッファの個数
は２個以上必要であるが、バンドバッファの個数が最低
限の２個であると、次のような不都合が生じる。すなわ
ち、バンドバッファの個数が２個の場合、一方のバンド
バッファからビットマップデータが読み出されてプリン
タに供給されている期間、他方のバンドバッファには、
展開されたビットマップデータが格納されるが、その格
納が早期に終了しても、一方のバンドバッファからビッ
トマップデータがすべて読み出されるまで、次のバンド
画像の展開処理を待機させる必要がある。このため、展
開処理が断続的となって効率が下がる、という不都合が
ある。そこで、展開処理の効率を向上させるため、バン
ドバッファの個数を３個以上とするのが主流となってい
る。

【０００９】ここで、バンドバッファの個数が３個以上
の場合において、オーバーランエラーを防止する技術と
しては、従来より例えば、特開平５−２０８５４０号公
報に記載の技術などがある。この公報に記載の技術は、
第１に、各バンド画像（ページストリップ）のレンダリ
ングに要する時間（ＲＥＴ）を決定し、第２に、選択さ
れたバンド画像のＲＥＴが、プリンタにおいてバンド画
像の出力に要する基準時間（ＰＳＲＴ）と、少なくとも
前のバンド画像までの余裕時間（ＩＳＲＴ：ＰＳＲＴか
ら前のバンド画像のＲＥＴを差し引いた時間）との合計
を超えるか否かを判定し、第３に、超える場合に、その
選択されたバンド画像については、オーバーランエラー
が発生すると検出する技術である。

【００１０】

【発明が解決しようとする課題】しかしながら、特開平
５−９６７９４号公報に記載の技術は、バンドバッファ
の個数が２個の場合には問題なく適用できるが、３個以
上の場合、安易には適用することができない。例えば、
バンドバッファが３個の場合、ある１つのバンド画像を
展開してそのビットマップデータを一のバンドバッファ
に格納するのに要した時間が、基準時間以上であって
も、その前後のいずれかのバンド画像のレンダリング処
理において、その超過時間を吸収できれば、問題なく画
像出力を継続できる。しかし、上記公報記載の技術で
は、オーバーランエラーとして検出してしまうのであ
る。

【００１１】また、例えば、バンドバッファの個数が３
個であって、すでにプリンタが起動されている場合につ
いて検討してみると、特開平５−２０８５４０号公報の
記載の技術においては、次のような問題もある。すなわ
ち、この技術では、一のバンドバッファからビットマッ
プデータが読み出されプリンタに供給されていることに
なるが、他の二つのバンドバッファについて、すでに展
開されたビットマップデータが格納されているのであれ
ば、空のバンドバッファが存在しないため、次のバンド
画像のレンダリング処理については、現時点におけるバ
ンド画像の出力が完了しその一のバンドバッファが解放
されるまで、待機させる必要がある。ここで、特開平５
−２０８５４０号公報の記載の技術においては、バンド
バッファが利用可能であるか否かを、実際にプリンタを
起動した後に判断している（同公報の図５において、そ
の判断を行なうステップ１４２は、プリンタの起動を示
すステップ１３５よりも後に実行される）ことから判る
ように、待ち状態が発生するか否かをプリンタ起動前に
おいては検出することができない。当然、その待ち状態
がどれだけの時間になるかについても検出することもで
きない。このため、同公報記載の技術では、プリンタ起
動前に、オーバーランエラーが発生するか否かを、待機
状態およびその時間を考慮して正確に予測することがで
きないのである。

【００１２】本発明は、上述した事情に鑑みてなされた
ものであり、その目的とするところは、レンダリング処
理をバンド画像毎に行なうものにおいて、プリンタ起動
前に待機状態およびその時間を正確に検出するととも
に、これらを考慮してオーバーランエラーを正確に検出
することが可能な画像処理装置を提供することにある。

【００１３】

【課題を解決するための手段】本発明は、上述した課題
を解決するために、１ページの画像を副走査方向に帯状
に分割したバンド画像に対応する画像データに展開する
展開手段と、前記展開手段によって展開された画像デー
タを格納するｎ（ｎは２以上の整数）個の緩衝記憶手段
と、前記展開手段によって展開されたバンド画像に対応
する画像データを、前記ｎ個の緩衝記憶手段のいずれか
に対して予め作成されたスケジュールの順番で格納する
格納手段と、前記ｎ個の緩衝記憶手段にそれぞれ格納さ
れた画像データを、前記スケジュールの順番で読み出し
て、画像を出力する出力手段に転送する読出制御手段と
を有する画像処理装置において、前記バンド画像に対応
する画像データが格納された緩衝記憶手段の個数を検出
する検出手段と、前記検出手段によって検出された個数
がｎであれば、前記展開手段による展開が待機状態にあ
ると判別する第１の判別手段とを具備することを特徴と
している。

【００１４】

【発明の実施の形態】以下、本発明による実施の形態に
ついて図面を参照して説明する。

【００１５】＜１：第１実施形態＞まず、本発明の第１
実施形態にかかる画像処理装置について説明する。本実
施形態にかかる画像処理装置は、画像出力する前に、後
述する条件をもとに、各バンド画像についてオーバーラ
ンエラーが発生するか否かを予測するとともに、発生を
予測した場合には、当該バンド画像にオーバーランエラ
ー防止策を施して、その発生がないことを確認した後
に、実際に画像出力を実行するものである。

【００１６】＜１−１：第１実施形態の構成＞図１は、
本実施形態にかかる画像処理装置１の構成を示すブロッ
ク図である。なお、本画像処理装置１においては、同図
に示すように、バンドバッファの個数を説明の便宜上
「４」とするが、本発明をこれに限定する趣旨ではな
い。この図において、上位処理部２０は、ホスト端末
や、パソコンなど（図示せず）から出力された（ＰＤＬ
で記述された）コード画像データを解釈して、バンド画
像のビットマップデータを作成するために必要な中間コ
ード画像データを、１ページを単位として生成するもの
である。このため、以下の各部においては、各処理を１
ページを単位として、各種の処理を実行するようになっ
ている。

【００１７】展開部３０は、中間コード画像データから
バンド画像に対応するビットマップデータに展開する処
理と、そのビットマップデータをバンドバッファ〜
のいずれかに格納する処理とを、スケジュール管理部４
０によって作成されスケジュールにしたがって実行する
ものである。このスケジュールは、展開部３０における
展開・格納の順番のほか、格納されたビットマップデー
タをバンドバッファから読み出す順番も規定するもので
ある。ここで、スケジュール管理部４０は、スケジュー
ルを作成するに際し、各バンド画像についてのレンダリ
ング処理に要する時間を知る必要があるが、これには、
主に次の方法がある。第１に、上位処理部２０において
中間コード画像データが生成される過程で採取した各種
情報、例えば、中間コード画像データの個数や、そのラ
ンレングス総数などのパラメータから、各バンド画像に
ついてレンダリング処理に要する時間を予測する方法が
ある。なお、この技術については、同じ発明者により既
に出願された特願平８−２３９３３７号が詳しい。第２
に、各バンド画像についてのレンダリング処理を実際に
行なって、実測する方法である。この場合、スケジュー
ル管理部４０が展開部３０に対し実際にレンダリング処
理を実行させ、この処理に要する時間を計測部５０が計
測することにより、各バンド画像についてレンダリング
処理に要する時間が得られる。本実施形態では、特に断
わりがなければ、上記第２の方法により、各バンド画像
についてのレンダリング処理に要する時間を得るものと
する。

【００１８】バンドバッファ管理部６０は、スケジュー
ル管理部４０の指示にしたがって、バンドバッファ〜
を管理するものである。ここで、バンドバッファ〜
は、通常、システムメモリの一部が割り当てられる
が、バンドバッファ管理部６０により任意の個数に設定
可能である。エラー処理部７０は、後述する条件によっ
て、オーバーランエラー発生すると予測される場合に
は、その旨をユーザに告知するものである。転送部９０
は、スケジュール管理部４０によりスケジュールされた
順番で、バンドバッファ〜から順番にビットマップ
データをプリンタエンジン１００の動作に同期して読み
出して転送するものである。プリンタエンジン１００
は、１ページの画像出力を例えばＫＹＭＣの色成分の順
番で、面順次型でフルカラーの印刷出力を行なうもので
ある。なお、本画像処理装置１は、この他に、図示しな
い制御部を有して、全体の動作を統括させている。

【００１９】＜１−２：待ち時間とオーバーランエラー
＞ここで、本実施形態において、レンダリング処理の待
ち時間とオーバーランエラーとの検出方法について述べ
る。

【００２０】＜１−２−１：待ち時間の発生条件＞ま
ず、バンドバッファの個数が「４」である場合を例にと
って、レンダリング処理の待ち時間の発生条件につい
て、具体的に検討してみる。なお、ここでは、説明の便
宜上、バンドバッファの個数を「４」とするが、本発明
をこれに限定する趣旨ではない。

【００２１】図２（ａ）は、１ページにかかる各バンド
画像と、そのレンダリング処理に要する時間と、格納す
べきバンドバッファの順番との関係を示す図であり、い
わば、スケジュール管理部４０によるスケジュールの内
容を示すものである。この図に示すように、レンダリン
グ処理されたビットマップデータは、バンドバッファ
→→→→の順番で繰り返し格納されるものとす
る。また、一般に、レンダリング処理に要する時間は、
そのバンド画像の内容に依存して異なるため、この例に
おいても、図示のように各バンド画像毎に異なるものと
している。なお、時間の単位については、特に意識して
いない。次に、同図（ｂ）は、各バンド画像のレンダリ
ング処理と、プリンタのスキャン処理とを時系列的に示
した図である。図示の例において、プリレンダリング処
理の個数は「２」としている。ここで、プリレンダリン
グ処理とは、プリンタを起動する前に、レンダリング処
理することをいい、その個数は、処理にかかるバンド画
像の個数をいう。したがって、この例では、２個のバン
ド画像についてのレンダリング処理が完了した時点Ｂで
プリンタが起動されることを意味する。なお、一般に、
バンドバッファの個数がｎ（ｎは正の整数）個である場
合、プリレンダリング処理の個数は、１≦ｍ≦（ｎ−
１）を満たす整数である。したがって、バンドバッファ
の個数が「４」であれば、プリレンダリングの個数とし
ては、「１」、「２」、「３」を取り得るが、説明の便
宜上、図示の例では「２」とした。また、１つのバンド
画像について、プリンタのスキャン処理に要する時間
は、バンド画像の内容によらず一定（図示の例では「１
００」：基準時間）であり、その処理は、一度起動した
ら、そのページの出力が完了するまで、停止させること
ができない。

【００２２】次に、同図（ｂ）および同図（ｃ）を参照
して、バンドバッファの個数が「４」の場合における待
ち時間の発生条件について検討してみる。ここで、評価
のタイミングは、図に示すように、各バンド画像につい
てレンダリング処理が完了した時点Ａ〜Ｆであり、評価
の対象は、第１に、レンダリング処理の完了したバンド
バッファの個数からプリンタエンジン１００に転送が完
了したバンドバッファの個数を減じた個数（以後、「レ
ンダリング処理済のバンドバッファの個数」という。）
と、第２に、プリンタの起動後のレンダリング処理時間
から、その時点におけるプリンタのスキャン処理時間を
減じた時間（以後、「経過時間」という。）とである。

【００２３】まず、図示の例ではプリレンダリング処理
の個数を「２」としているから、図に示すように、２番
目のバンド画像にかかるレンダリング処理が完了した時
点Ｂでは、レンダリング処理済のバンドバッファの個数
は「２」であり、経過時間は「０」であって、いずれも
初期値というべきものである。なお、プリレンダリング
処理の個数を「３」とすると、レンダリング処理済のバ
ンドバッファの個数にかかる初期値も「３」となる。次
に、３番目のバンド画像にかかるレンダリング処理が完
了した時点Ｃについて検討してみる。このバンド画像の
レンダリング処理に要する時間は「５０」であり、１つ
のバンド画像に要するプリンタのスキャン処理に要する
基準時間「１００」よりも短い。したがって、時点Ｃで
は、プリンタにビットマップデータの転送が完了したバ
ンドバッファは発生していないから、レンダリング処理
済のバンドバッファの個数は、３番目のバンド画像を加
えた「３」となり、経過時間については、当該バンド画
像のレンダリング処理に要した時間の「５０」となる。

【００２４】続いて、４番目のバンド画像にかかるレン
ダリング処理が完了した時点Ｄについて検討してみる。
このバンド画像のレンダリング処理に要する時間は「６
０」であるため、時点Ｄは、プリンタの起動から、３番
目のバンド画像のレンダリング処理に要した時間「５
０」を加えた「１１０」を経過した時点である。この時
間では、プリンタにおいてスキャン処理が「１」のバン
ド画像について実行される。したがって、時点Ｄでは、
プリンタにビットマップデータの転送が完了したバンド
バッファが「１」だけ発生していることになり、レンダ
リング処理済のバンドバッファの個数は、４番目のバン
ド画像を加えた「４」から、その「１」だけ減じた
「３」となり、経過時間については、時点Ｄの「１１
０」から、基準時間「１００」を減じた「１０」とな
る。

【００２５】次に、５番目のバンド画像にかかるレンダ
リング処理が完了した時点Ｅについて検討してみる。こ
のバンド画像のレンダリング処理に要する時間は「５
０」であるため、時点Ｅは、この時間に先の時点Ｄの
「１１０」を加えた「１６０」である。この時間では、
プリンタにおいて、先の時点Ｄから新たにスキャン処理
されたバンド画像は発生していない。したがって、時点
Ｅでは、レンダリング処理済のバンドバッファの個数
は、先の時点Ｄにおける「３」に５番目のバンド画像の
「１」を加えた「４」となる。この状態では、空きとな
っているバンドバッファが存在しないため、レンダリン
グ処理は、プリンタにおいて現時点のバンド画像にかか
るスキャン処理が完了して、そのバンドバッファが使用
可能となる時間「２００」まで、待ち状態となる。した
がって、この待ち時間は、バンドバッファが使用可能と
なる時間「２００」から、時点Ｅの「１６０」を減じた
「４０」として求められる。一方、時点Ｅの経過時間
は、「１６０」から、先ほどの時点Ｄと同様にして、基
準時間「１００」を減じた「６０」となる。待ち時間に
ついては、基準時間「１００」から、時点Ｅの経過時間
「６０」を減じることによっても求められる。

【００２６】次に、６番目のバンド画像にかかるレンダ
リング処理が完了した時点Ｆについて検討してみる。レ
ンダリング処理は、バンドバッファが新たに使用可能と
なる時間「２００」まで待ち状態となっていたので、時
間Ｆは、この時間に、当該バンド画像のレンダリング処
理に要する時間「７０」を加えた「２７０」である。こ
の時間では、プリンタにおいて、先の時点Ｅから、新た
にスキャン処理されたバンド画像は「１」だけ発生して
いる。したがって、時点Ｆでは、レンダリング処理済の
バンドバッファの個数は、先の時点Ｅにおける「４」か
らスキャン処理された分の「１」を減じ、さらに、６番
目のバンド画像の「１」を加えた「４」となる。この状
態では、先に述べたように、空きとなっているバンドバ
ッファが存在しないため、レンダリング処理は、プリン
タにおいて現時点のバンド画像にかかるスキャン処理が
完了して、そのバンドバッファが使用可能となる時間
「３００」まで、待ち状態となる。したがって、この待
ち時間は、バンドバッファが使用可能となる時間「３０
０」から、時点Ｆの「２７０」を減じた「３０」として
求められる。また、プリンタにおいて、先の時点Ｅから
新たにスキャン処理されたバンド画像が「１」だけ発生
している、ということは、プリンタの起動からスキャン
処理されたバンド画像の累計が「２」であるということ
を意味している。したがって、時点Ｆの経過時間は、
「２７０」から、「２」のバンド画像のスキャン処理に
要する時間「２００」を減じた「７０」となる。待ち時
間について、基準時間「１００」から、時点Ｆの経過時
間「７０」を減じることによっても求められるのは、同
様である。

【００２７】以上の検討から判るように、バンドバッフ
ァの個数が「４」である場合にレンダリング処理が待ち
時間が発生する条件は、各バンド画像にかかるレンダリ
ング処理が完了した時点において、レンダリング処理済
のバンドバッファの個数が「４」となっている、という
ものである。結局、一般的に、バンドバッファの個数が
「ｎ」である場合も、同様であり、レンダリング処理が
待ち時間が発生する条件は、各バンド画像にかかるレン
ダリング処理が完了する時点において、レンダリング処
理済のバンドバッファの個数が「ｎ」となっている、こ
とである。すなわち、待ち時間の発生条件は、バンドバ
ッファの個数を「ｎ」とすると、次のようになる。 ・レンダリング処理済のバンドバッファの個数＝「ｎ」の場合 ……（イ） そして、その待ち時間は、プリンタにおける「１」のバ
ンド画像のスキャン処理に要する基準時間から、その時
点の経過時間を減じることによって求められる。

【００２８】＜１−２−２：オーバーランエラーの発生
条件＞次に、オーバーランエラーの発生条件について、
図３を参照して検討する。この検討の前提は、図３
（ａ）に示す通りであり、評価のタイミング、および、
評価の対象も、待ち時間の発生条件と同様である。すな
わち、図示の例ではプリレンダリング処理の個数を
「２」としているから、図に示すように、２番目のバン
ド画像にかかるレンダリング処理が完了した時点Ｈで
は、レンダリング処理済のバンドバッファの個数は
「２」であり、経過時間は「０」であって、いずれも初
期値というべきものである。

【００２９】次に、３番目のバンド画像にかかるレンダ
リング処理が完了した時点Ｉについて検討してみる。こ
のバンド画像のレンダリング処理に要する時間は「８
０」であるから、基準時間「１００」よりも短い。した
がって、時点Ｉでは、プリンタにビットマップデータの
転送が完了したバンドバッファは発生していないから、
レンダリング処理済のバンドバッファの個数は、３番目
のバンド画像を加えた「３」となり、経過時間について
は、当該バンド画像のレンダリング処理に要した時間の
「８０」となる。

【００３０】続いて、４番目のバンド画像にかかるレン
ダリング処理が完了した時点Ｊについて検討してみる。
このバンド画像のレンダリング処理に要する時間は「１
２０」であるから、時点Ｊは、プリンタの起動から、３
番目のバンド画像のレンダリング処理に要した時間「８
０」を加えた「２００」を経過した時点である。この時
間では、プリンタにおいてスキャン処理が「２」のバン
ド画像について実行される。したがって、時点Ｊでは、
プリンタにビットマップデータの転送が完了したバンド
バッファが「２」だけ発生していることになり、レンダ
リング処理済のバンドバッファの個数は、４番目のバン
ド画像を加えた「４」から、その「２」だけ減じた
「２」となる。また、時点Ｊの経過時間については、そ
の「２００」から、プリンタにおいて２つのバンド画像
のスキャン処理に要する時間「２００」を減じた「０」
となる。

【００３１】次に、５番目のバンド画像にかかるレンダ
リング処理が完了した時点Ｋについて検討してみる。こ
のバンド画像のレンダリング処理に要する時間は「１１
０」であるから、時点Ｋは、この時間に先の時点Ｊの
「２００」を加えた「３１０」である。この時間では、
プリンタにおいて、先の時点Ｊから、新たにスキャン処
理されたバンド画像は「１」だけ発生している。したが
って、時点Ｋにおけるレンダリング処理済のバンドバッ
ファの個数は、先の時点Ｊにおける「２」に、６番目の
バンド画像の「１」を加え、さらに、スキャン処理され
た分の「１」を減じた「２」となる。また、時点Ｋの経
過時間については、その「３１０」から、プリンタにお
いて３つのバンド画像のスキャン処理に要する時間「３
００」を減じた「１０」となる。

【００３２】次に、６番目のバンド画像にかかるレンダ
リング処理が完了した時点Ｌについて検討してみる。こ
のバンド画像のレンダリング処理に要する時間は「２０
０」であるから、時点Ｌは、この時間に先の時点Ｋの
「３１０」を加えた「５１０」である。この時間では、
プリンタにおいて、先の時点Ｋから、新たにスキャン処
理されたバンド画像は「２」だけ発生しているが、時点
Ｌにおいて、スキャン処理されているバンド画像は、６
番目のバンド画像（バンドバッファ）すなわち自分自
身にかかるものである。これは、６番目のバンド画像に
かかるスキャン処理が、そのレンダリング処理が完了す
る以前に、実行されていることを意味し、すでに、オー
バーランエラーが発生していることを示す。ここで、時
点Ｌにおけるレンダリング処理済のバンドバッファの個
数は、先の時点Ｋにおける「２」に、６番目のバンド画
像の「１」を加え、さらに、スキャン処理された分の
「２」を減じた「１」である。また、プリンタにおい
て、先の時点Ｋから新たにスキャン処理されたバンド画
像が「２」だけ発生している、ということは、プリンタ
の起動からスキャン処理されたバンド画像の累計が
「５」であるということを意味している。したがって、
時点Ｆの経過時間は、「５１０」から、５つのバンド画
像のスキャン処理に要する時間「５００」を減じた「１
０」となる。

【００３３】このようなオーバーランエラーが発生して
いる場合において、レンダリング処理済のバンドバッフ
ァの個数と、経過時間との関係について検討してみる。
まず、レンダリング処理済のバンドバッファの個数が
「１」であることは、その時点において、レンダリング
処理にかかるバンド画像（バンドバッファ）とプリンタ
のスキャン処理にかかるバンド画像（バンドバッファ）
とが同じであることを示す。また、経過時間が「０」を
超えていることは、その時点が、プリンタにおいて、あ
るバンド画像のスキャン処理が完了した後の状態である
ことを意味する。逆にいえば、経過時間が「０」である
ことは、その時点が、あるバンド画像のスキャン処理が
完了した時点であることを意味する。ここで、レンダリ
ング処理済のバンドバッファの個数が「１」であって
も、経過時間が「０」であれば、それは、あるバンド画
像にかかるレンダリング処理完了と、そのバンド画像に
かかるプリンタのスキャン処理開始とが同時であること
を意味する。このため、オーバーランエラーは発生しな
い。しかし、時点Ｌのように、レンダリング処理済のバ
ンドバッファの個数が「１」であって、経過時間が
「０」を超えていれば、それは、あるバンド画像にかか
るレンダリング処理完了が、そのバンド画像にかかるプ
リンタのスキャン処理開始よりも後であることを意味す
る。このため、オーバーランエラーが発生することにな
る。したがって、まず、レンダリング処理済のバンドバ
ッファの個数が「１」であって、かつ、経過時間が
「０」を超えていることが、オーバーランエラーが発生
する条件となる。この条件は、バンドバッファの個数
「ｎ」とは無関係に成立するのは明らかであろう。

【００３４】次に、図示の例ではないが、レンダリング
処理済のバンドバッファの個数が「０」以下であること
は、その時点において、プリンタのスキャン処理がレン
ダリング処理よりも進行している場合を示す。したがっ
て、この場合、明らかに、オーバーランエラーが発生し
ていることを示す。すなわち、レンダリング処理済のバ
ンドバッファの個数が「０」以下であることも、オーバ
ーランエラーが発生する条件となる。

【００３５】以上まとめると、オーバーランエラーの発
生条件は、次のいずれかの場合であり、バンドバッファ
の個数「ｎ」とは無関係であり、さらに、レンダリング
処理完了後の評価タイミングに限らず、いつでも成立す
る。 ・レンダリング処理済のバンドバッファの個数＝１、かつ、経過時間＞０の場合 ……（ロ） ・レンダリング処理済のバンドバッファの個数≦０の場合 ……（ハ）

【００３６】＜１−３：動作＞次に、本実施形態にかか
る画像処理装置１の動作について説明する。図４は、そ
の動作を示すフローチャートである。まず、スケジュー
ル管理部４０は、ステップＳ１において、展開部３０に
対して、プリレンダリング処理を実行させる。次に、ス
ケジュール管理部４０は、ステップＳ２において、レジ
スタｂａｎｄに、プリレンダリング処理したバンド画像
の個数をセットするとともに、レジスタｔｉｍｅをゼロ
にクリアする。ここで、レジスタｂａｎｄは、レンダリ
ング処理済のバンドバッファを示す値をセットするため
のものであり、ここではプリレンダリング処理直後であ
るため、その個数がセットされるのである。また、レジ
スタｔｉｍｅは、その時点の経過時間を示す値をセット
するためのものであり、ここではプリレンダリング処理
直後であるため、その内容がゼロにクリアされたのであ
る。

【００３７】次に、スケジュール管理部４０は、ステッ
プＳ３において、展開部３０に対し、引き続き、次のバ
ンド画像にかかるレンダリング処理を実行させる。な
お、実際に画像出力を実行する場合には、この時点で、
プリンタエンジン１００が起動される。また、各バンド
画像についてのレンダリング処理に要する時間を、上記
第１の方法により求める場合には、レンダリング処理の
替わりに、その処理に要する時間を得るものとする。そ
して、スケジュール管理部４０は、ステップＳ４におい
て、レンダリング処理の実行により、レンダリング処理
済のバンドバッファの個数が「１」増えたことに伴っ
て、レジスタｂａｎｄに、「１」を加算（インクリメン
ト）するとともに、レジスタｔｉｍｅに、そのレンダリ
ング処理に要した時間を加算する。引き続き、スケジュ
ール管理部４０は、ステップＳ５において、レジスタｂ
ａｎｄから、レンダリング処理中にプリンタのスキャン
処理が完了したバンド画像（バンドバッファ）の個数Ｐ
を減算する。したがって、この時点において、レジスタ
ｂａｎｄは、レンダリング処理済のバンドバッファを示
すことになる。また、スケジュール管理部４０は、ステ
ップＳ５において、レジスタｔｉｍｅから、バンド画像
（バンドバッファ）の個数Ｐと１つのバンド画像（バン
ドバッファ）についてプリンタのスキャン処理に要する
時間Ｓとの積を減算する。したがって、この時点におい
て、レジスタｔｉｍｅは、経過時間を示すことになる。

【００３８】ここで、スケジュール管理部４０は、ステ
ップＳ６において、レジスタｂａｎｄの値が、バンドバ
ッファの個数ｎと等しいか否か、すなわち、上記条件
（イ）を満たすか否かを判定して、待ち時間が発生する
か否かを予測（検出）する。この判別結果が「Ｎｏ」な
らば、スケジュール管理部４０は、ステップＳ７におい
て、レジスタｂａｎｄの値が「１」であって、かつ、レ
ジスタｔｉｍｅの値が「０」を超えているか否か、すな
わち、上記条件（ロ）を満たすか否かを判定する。この
判別結果も「Ｎｏ」であるならば、スケジュール管理部
４０は、ステップＳ８において、レジスタｂａｎｄの値
が「０」以下であるか否か、すなわち、すなわち、上記
条件（ハ）を満たすか否かを判定する。上記条件
（イ）、（ロ）あるいは（ハ）のいずれも満たさない場
合、この時点では、待ち時間もオーバーランエラーも発
生しないことを意味する。このため、スケジュール管理
部４０は、ステップＳ９において、処理すべき他のバン
ド画像が存在するか否かを判定し、「Ｙｅｓ」であれ
ば、そのバンド画像についてレンダリング処理すべく処
理手順をステップＳ３に戻す一方、「Ｎｏ」であれば、
続くステップＳ１０において、処理すべき他の色成分が
存在するか否かを判別する。この判別結果が「Ｙｅｓ」
であれば、当該他の色の成分についても同様にレンダリ
ング処理すべく処理手順をステップＳ３に戻す一方、
「Ｎｏ」であれば、すべてのバンド画像についてすべて
の色成分についてレンダリング処理が完了したことを意
味するから、この動作を終了する。

【００３９】ところで、ステップＳ６の判別結果が「Ｙ
ｅｓ」の場合、すなわち、上記条件（イ）を満たして、
待ち時間の発生が予測（検出）された場合、スケジュー
ル管理部４０は、待ち時間の発生に伴うレジスタｂａｎ
ｄとレジスタｔｉｍｅとの不整合を解消するため、ステ
ップＳ１１の処理を実行する。すなわち、スケジュール
管理部４０は、レジスタｂａｎｄに対し、「１」を減算
（デクリメント）する一方、レジスタｔｉｍｅに対し、
その待ち時間Ｗを加算した後、１つのバンド画像（バン
ドバッファ）についてプリンタのスキャン処理に要する
基準時間Ｓを減算する。この後、スケジュール管理部４
０は、処理すべき他のバンド画像や、他の色成分が存在
するか否かを判別すべく、処理手順をステップＳ９に戻
す。

【００４０】また、ステップＳ７またはＳ８の判別結果
が「Ｎｏ」の場合、すなわち、上記条件（ロ）または
（ハ）のいずれかを満たして、オーバーランエラーの発
生が予測（検出）された場合、スケジュール管理部４０
は、ステップＳ１２においてオーバーランエラーの対策
処理を指示した後、この動作を終了する。そして、対策
処理後においても、オーバーランエラーが発生するか否
かを確認すべく、また、オーバーランエラーにかかるバ
ンド画像以降においても、オーバーランエラーが発生す
るか否かを確認すべく、図に示す動作を再度実行し、オ
ーバーランエラーが発生しないと確認されるまで繰り返
す。

【００４１】ここで、ステップＳ１２におけるオーバー
ランエラーの対策処理としては、例えば、次のようなも
のがある。第１に、上位処理部２０または展開部３０
は、オーバーランエラーにかかるバンド画像に重畳図形
処理（描画オブジェクトの重なりを除去する処理）が実
行されていなければ、この処理を実行する。これによ
り、展開部３０は、重なる部分のレンダリング処理を重
複して実行する事態が回避されるので、処理に要する時
間が短縮され、オーバーランエラーの再発する可能性が
低下する。しかも当該バンド画像については、画質の劣
化が生じない。第２に、上位処理部２０または展開部３
０は、オーバーランエラーにかかるバンド画像につい
て、階調を低下させる色間引き処理、あるいは／およ
び、解像度を低下させる副走査線間引き処理を実行す
る。これにより、展開部３０にとって、レンダリング処
理の負担が軽減されるので、処理に要する時間が短縮さ
れ、オーバーランエラーの再発する可能性が低下する。
ただし、当該バンド画像については、画質の劣化が生じ
てしまう。第３に、スケジュール管理部４０はプリレン
ダリング処理の個数を増やしてスケジュールを作成し直
し、さらに、システムメモリに余裕がある場合には、バ
ンドバッファ管理部６０が、バンドバッファの個数を増
やす。これにより、レンダリング処理が、プリンタのス
キャン処理よりも先行して実行されることになるので、
その分、オーバーランエラーの再発する可能性が低下す
る。

【００４２】こうして、オーバーランエラーが発生しな
いと確認されると、再び、この図４に示す動作を繰り返
す。この際、スケジュール管理部４０は、実際に、プリ
レンダリング処理の後、プリンタエンジン１００を起動
するとともに、転送部９０がバンドバッファ〜のい
ずれかからビットマップデータをスケジュール管理部４
０のスケジュールにしたがってプリンタエンジン１００
に転送する。このような実施形態にかかる画像処理装置
によれば、事前にオーバーランエラーの発生が予測され
る場合には、その対策が施されてから、実際に画像出力
が行なわれる。しかも、この際、待ち時間の発生も考慮
するから、より正確に、オーバーランエラーの発生を予
測することが可能となる。

【００４３】＜２：第２実施形態＞次に、本発明の第２
実施形態にかかる画像処理装置について説明する。本実
施形態にかかる画像処理装置は、待ち時間が発生した場
合、レンダリング処理にかかるタスクの替わりに、他の
タスクを実行して処理全体のスループットを向上させる
ものである。さらに、本実施形態にかかる画像処理装置
は、展開部３０の処理能力がプリンタエンジン１００の
印刷能力よりも十分に高く、オーバーランエラーの発生
する可能性が低いものを想定し、第１実施形態のよう
に、事前にその発生を予測することなく、プリレンダリ
ング処理の後、プリンタエンジン１００を起動して、直
ちに画像出力を実行するものである。ただし、この構成
においても、オーバーランエラーを検出することは必要
である。

【００４４】図５は、本実施形態にかかる画像処理装置
の構成をブロック図である。この図に示す画像処理装置
２が、図１に示す第１実施形態の構成と相違する部分
は、待ち時間においてタスクを制御するタスク制御部１
１０を有する点である。このため、他については、その
説明を省略することとする。

【００４５】＜２−１：動作＞次に、本実施形態にかか
る画像処理装置の動作について説明する。まず、スケジ
ュール管理部４０は、画像出力に先だって、各バンド画
像にかかるレンダリング処理の予測時間を参照して、オ
ーバーランエラーが発生しないように、スケジュールを
作成する。このスケジュールにしたがって図４に示す動
作が実行される。なお、この動作は、先の第１実施形態
において説明済みなので説明を省略するが、プリレンダ
リング処理の後においてはプリンタエンジン１００が実
際に起動され、ビットマップデータがバンドバッファ
〜のいずれかからプリンタエンジン１００へと、スケ
ジュールにしたがって転送されて、画像出力が開始され
ることとなる。この際、計測部５０は、各バンド画像の
レンダリング処理に要した時間を実測する。

【００４６】＜２−１−１：オーバーランエラーの発生
＞本実施形態において、オーバーランエラーが発生した
検出された場合、スケジュール管理部４０は、展開部３
０に対しレンダリング処理を中止させる一方、転送部９
０に対しビットマップデータの転送を中止させるととも
に、エラー処理部７０にその発生を通知する。これによ
り、ユーザは、オーバーランエラーの発生を知ることに
なる。オーバーランエラーの発生したページについて
は、再度出力する必要があるが、同じスケジュールでレ
ンダリング処理しても、同じ箇所でオーバーランエラー
が再発する可能性は極めて高い。このため、スケジュー
ル管理部４０は、第１に、各バンド画像について、元の
スケジュールを作成する際に用いたレンダリング処理の
予測時間と、計測部６０により計測された実測されたレ
ンダリング処理の実測時間とを比較し、第２に、その比
較結果に基づいて予測に用いたパラメータを変更し、第
３に、変更後のパラメータを用いて、各バンド画像にか
かるレンダリング処理に要する時間を予測し、第４に、
この予測時間に基づいてスケジュールを作成し直す。な
お、オーバーランエラーが発生することなく出力が完了
した場合にあっても、レンダリング処理の予測時間とレ
ンダリング処理の実測時間との差がしきい値以上であれ
ば、予測に用いたパラメータを変更することとしても良
い。これにより、以後、予測の確からしさが向上する。

【００４７】また、スケジュール管理部４０は、スケジ
ュールの再作成とともに、オーバーランエラーの対策処
理を実行する。この対策処理は、第１実施形態と同様
に、オーバーランエラーの原因となった、最後にレンダ
リング処理されたバンド画像に対する重畳図形処理や、
色間引き処理、走査線間引き処理などがあり、また、プ
リレンダリング処理の個数や、バンドバッファの個数を
増加する処理などがある。そして、このようなスケジュ
ールの再作成、および、オーバーランエラーの対策処理
によって、オーバーランエラーの再発が極力防止される
こととなる。

【００４８】＜２−１−２：待ち時間の検出＞次に、本
実施形態における待ち時間での処理について説明する。
スケジュール管理部４０は、画像出力に先だって実行さ
れるスケジュールの作成に際し、待ち時間の発生を検出
した場合、上述した方法によってその待ち時間を求めて
おく。そして、実際に画像出力の際に待ち時間が発生し
た場合、図４に示すステップＳ１００において、次のよ
うな別タスク処理が実行される。すなわち、スケジュー
ル管理部４０は、タスク制御部１１０に対しその待ち時
間を通知する。これを受けて、タスク制御部１１０は、
出力すべき次のページが存在するか否かを判別する。こ
こで、タスク制御部１１０は、次のページが存在しなけ
れば、タスクをスケジュール管理部４０から移行させ
ず、そのままとする一方、次のページが存在すれば、タ
スクをスケジュール管理部４０から上位処理部２０に移
行させた後、その待ち時間が経過したならば、再びタス
クをスケジュール管理部４０に戻す。これにより、その
待ち時間においては、上位処理部２０の解釈処理等が実
行されるとともに、待ち時間が解消すると、スケジュー
ル通りのレンダリング処理が展開部３０において再び実
行されることとなる。したがって、本実施形態によれ
ば、待ち時間において、レンダリング処理以外のタスク
が実行されるので、処理全体の効率を高めることが可能
となる。なお、本実施形態において、上位処理部２０に
おいて実行される処理を他のタスクの一例としたが、本
発明は、これに限られない。

【００４９】ここで、本実施形態のように、展開部３０
の処理能力がプリンタエンジン１００の印刷能力よりも
十分に高い場合、図６（ａ）に示すように、待ち時間が
頻発する可能性が高い。ここで、待ち時間が発生する毎
に画像処理のタスクを、タスク制御部１１０を介して上
位処理部２０に移行させた後、再び展開処理部３０に戻
す構成では、タスクの往来に要する時間が無視できない
場合、効率が悪い。一方、レンダリング処理は、そのバ
ンド画像についてプリンタのスキャン処理が開始される
までに完了していれば良い。そこで、実際の画像出力時
においては、検出された待ち時間がしきい値以上である
か否かを判別し、しきい値以上であれば、図６（ｂ）に
示すように、互いに隣接する２個以上の待ち時間を併合
しても良い。ただし、レンダリング処理がそのバンド画
像についてのスキャン処理が開始するまでに完了するこ
とが条件となる。この点についてはスケジュールの作成
時においても同様である。なお、図６（ｂ）に示す例に
おいては、バンドバッファへのレンダリング処理Ｐの
完了時と、そのプリンタスキャン処理の開始時とが同時
である場合を示す。また、バンドバッファへのレンダ
リング処理Ｑの完了時においては、その次のバンドバッ
ファについてスキャン処理が実行中のために解放され
ないので、そのレンダリング処理は「待ち」となる。こ
のように待ち時間を併合することにより、タスクの往来
が減少し、処理全体の効率をさらに高めることが可能と
なる。

【００５０】＜３：応用形態＞プリンタエンジン１００
の搬送系においては、その機械的構成により、プリレン
ダリング処理直後に起動を指示しても、直ちに画像形成
が開始されるわけではない。例えば、図７に示すよう
に、プリレンダリング処理の個数が「１」である場合に
おいて、バンドバッファへのレンダリング処理が完了
した直後に、プリンタエンジン１００に対して起動指示
しても、実際に画像の形成が開始されるまで、通常、時
間差を伴う。したがって、ビットマップデータを起動指
示直後に供給しなくても、実際にバンド画像の出力開始
時点までに供給すれば、オーバーランエラーとならずに
画像出力を続行できる。そこで、第１および第２実施形
態にかかるスケジュール管理部４０は、この時間差をも
考慮して、プリレンダリング処理の個数を決定すること
としても良い。

【００５１】また、各色成分毎に画像形成を行なう場
合、プリンタエンジン１００の構成（例えば面順次型）
によっては、各色成分の画像を形成するために、色成分
毎に感光ドラムを切り替える時間が必要となる。例え
ば、ＫＹＭＣの順番で画像形成を行なう場合において、
Ｋの色成分からＹの色成分へと画像出力を切り替える際
には、図８（ｃ）に示すように、感光ドラムを切り替え
るための切替時間が発生する。ここで、Ｙの色成分にお
けるビットマップデータの供給は、Ｋの色成分における
ビットマップデータを供給完了後、直ちに行なう必要は
なく、感光ドラムがＹの色成分に対応するものに切り替
わるまでに、展開して供給すれば、オーバーランエラー
とならずに画像出力を続行できる。そこで、第１および
第２実施形態にかかるスケジュール管理部４０は、待ち
時間とともに、この切替時間についても考慮して、スケ
ジュールを作成しても良い。これにより、正確なスケジ
ュールの作成ができるので、オーバーランエラーがより
確実に予測・検出することが可能となる。この際、ドラ
ム切替時間とそれに隣接する１以上の待ち時間とを併合
することとしても良い。さらに、上述した時間差を考慮
してプリレンダリング処理の個数を決定する構成とすれ
ば、より正確なスケジュールの作成も可能となる。な
お、図８（ｂ）に示す例においては、切替時間と待ち時
間とを併合した場合であって、バンドバッファへのレ
ンダリング処理Ｒの完了時と、そのプリンタスキャン処
理の開始時とが同時である場合を示す。また、バンドバ
ッファへのレンダリング処理Ｓの完了時においては、
その次のバンドバッファについてスキャン処理が実行
中のために解放されないので、そのレンダリング処理は
「待ち」となる。このように待ち時間を併合することに
より、タスクの往来が減少し、処理全体の効率をさらに
高めることが可能となる。

【００５２】なお、このような時間差やドラム切替時間
などは、通常、一定値として扱うことができるが、経年
変化や周辺環境などの要因によって多少なりとも変動す
る性質を有する。このため、必要に応じて、一定値とし
ての内容を更新する必要があるが、このような技術につ
いては、同じ発明者により既に出願された特願平８−３
３２３６８号が詳しい。

【００５３】＜４：変形例＞なお、上述した第１および
第２実施形態にあっては、図４に示す動作の主体がスケ
ジュール管理部４０であったが、バンドバッファ管理部
６０に負わせても良い。この場合、スケジュール管理部
４０のスケジュールと、展開部３０、転送部９０の進行
状態とを逐一比較しながら、レジスタｔｉｍｅ、ｂａｎ
ｄをセットすることになる。

【００５４】

【発明の効果】以上説明したように本発明によれば、バ
ンド画像毎に展開処理を行なうものにおいて、プリンタ
起動前に待機状態およびその時間を正確に検出するとと
もに、これらを考慮してオーバーランエラーを正確に検
出することが可能となる。

【図面の簡単な説明】

【図１】 本発明の第１実施形態にかかる画像処理装置
の構成を示すブロック図である。

【図２】 （ａ）は、バンド画像とそのレンダリング処
理との一例を示す図であり、（ｂ）は、そのレンダリン
グ処理とプリンタのスキャン処理との進行を時系列的に
示す図であり、（ｃ）は、各評価タイミングにおける評
価対象の結果を説明するための図である。

【図３】 （ａ）は、バンド画像とそのレンダリング処
理との一例を示す図であり、（ｂ）は、そのレンダリン
グ処理とプリンタのスキャン処理との進行を時系列的に
示す図であり、（ｃ）は、各評価タイミングにおける評
価対象の結果を説明するための図である。

【図４】 同実施形態にかかる画像処理装置の動作を示
すフローチャートである。

【図５】 本発明の第２実施形態にかかる画像処理装置
の構成を示すブロック図である。

【図６】 （ａ）は、待ち時間が頻発する場合を示す図
であり、（ｂ）は、これらを併合した場合を示す図であ
り、（ｃ）は、プリンタのスキャン処理を示す図であ
る。

【図７】 （ａ）および（ｂ）は、起動指示から実際に
画像出力が開始されるまでの時間差を示す図である。

【図８】 （ａ）および（ｂ）は、ドラムの切替時間を
示す図である。

【符号の説明】 〜……バンドバッファ（緩衝記憶手段）、 ２０……上位処理部、 ３０……展開部（展開手段、格納手段）、 ４０……スケジュール管理部（検出手段、第１および第
２の判別手段、第１および第２の算出手段）、 ５０……計測部、 ６０……バンドバッファ管理部、 ７０……エラー処理部、 ９０……転送部（読出制御手段）、 １００……プリンタエンジン（出力手段）、 １１０……タスク制御部（処理割当手段）

Claims (5)

【特許請求の範囲】
1. 【請求項１】 １ページの画像を副走査方向に帯状に分
   割したバンド画像に対応する画像データに展開する展開
   手段と、 前記展開手段によって展開された画像データを格納する
   ｎ（ｎは２以上の整数）個の緩衝記憶手段と、 前記展開手段によって展開されたバンド画像に対応する
   画像データを、前記ｎ個の緩衝記憶手段のいずれかに対
   して予め作成されたスケジュールの順番で格納する格納
   手段と、 前記ｎ個の緩衝記憶手段にそれぞれ格納された画像デー
   タを、前記スケジュールの順番で読み出して、画像を出
   力する出力手段に転送する読出制御手段とを有する画像
   処理装置において、 前記バンド画像に対応する画像データが格納された緩衝
   記憶手段の個数を検出する検出手段と、 前記検出手段によって検出された個数がｎであれば、前
   記展開手段による展開が待機状態にあると判別する第１
   の判別手段とを具備することを特徴とする画像処理装
   置。
2. 【請求項２】 請求項１記載の画像処理装置において、
   さらに、 画像出力を指示した後、前記バンド画像に対応する画像
   データへの展開に要する時間から、前記出力手段がその
   時点までに画像出力を完了するバンド画像について処理
   に要する時間を減じて、第１の時間（経過時間）として
   求める第１の算出手段と、 前記出力手段において「１」のバンド画像の出力に要す
   る時間から前記第１の時間を減じて、前記展開手段が待
   機状態となる時間として求める第２の算出手段とを具備
   することを特徴とする画像処理装置。
3. 【請求項３】 請求項２記載の画像処理装置において、
   さらに、 前記判別手段によって、前記展開手段が待機状態にある
   と判別された場合に、前記第２の算出手段によって算出
   された時間を、前記展開手段による展開以外の処理に割
   り当てる処理割当手段を備えることを特徴とする画像処
   理装置。
4. 【請求項４】 請求項２記載の画像処理装置において、
   さらに、 前記検出手段によって検出された個数が「１」であって
   かつ前記第１の時間が「０」を超えている場合、もしく
   は、前記検出手段によって検出された個数が「０」以下
   である場合、エラーと判別する第２の判別手段を備える
   ことを特徴とする画像処理装置。
5. 【請求項５】 請求項４記載の画像処理装置において、
   さらに、 前記第２の判別手段によりエラーと判別された場合に、
   エラーの対策処理を実行するエラー対策処理手段を備え
   ることを特徴とする画像処理装置。