JP2019194816A - 画像処理装置、画像処理方法およびコンピュータプログラム - Google Patents

Abstract

【課題】 画像処理装置における画像の形成に関する処理速度の向上と処理効率とを両立させることを目的とする。【解決手段】 受信した印刷のページから中間データを生成した後、該中間データから画像データを形成する画像処理装置であって、前記印刷のページの処理負荷を計算する計算手段と、前記計算手段の計算の結果に基づき、前記中間データの生成の動作モードとして、第一のモードと、前記第一のモードよりも低速かつ低い消費電力で前記中間データを生成する第二のモードとのいずれかを設定する制御手段と、を有することを特徴とする。【選択図】 図８

Description

本発明は、画像データを形成する画像処理装置、画像処理方法およびコンピュータプログラムに関するものである。

特許文献１、特許文献２には、図形を描画するために図形が持つ座標情報等から図形の輪郭情報（エッジ情報とも呼ぶ）を抽出し、該輪郭情報に基づいて画像を形成するレンダリング手法は一般に広く利用されている。輪郭情報は直線で表現されるが該直線を表現するための手法も提案されている。

また、これら印刷装置において消費電力を押さえるための技術はいくつか提案されている。例えば、特許文献３では、複数のＣＰＵを搭載するＰＤＬデータを処理可能なプリンタ装置において、求められる処理能力に応じて使用するＣＰＵを切り替える制御を行う手法等が提案されている。また特定のノードへジョブを集中的に割り振った場合に特に最近の高速なＣＰＵに対して処理を集中させると、該ノード内、または、一部のデバイスの温度が設計上の閾値を超えてしまう。そこで、特許文献４、特許文献５、特許文献６、特許文献７には、パフォーマンスを一時的にダウンさせる等の工夫を行い、一定期間は発熱を抑える等の工夫を行い、機器の正常動作を保証する技術が開示されている。

特開平０４−１７０６８６号公報 特開平０８−７２３１７号公報 特開２００７−１０５９１７２号公報 特開２００６―２７７６３７号公報 特開２００６−１４６６０５号公報 特開２０１２―１６９４９４号公報 特開２０１１−２２７７４７号公報

従来から、図形毎に処理の単位（スレッド）を割り当てることを特徴とする画像形成処理方法が提案されている。図形のデータが入力された後、各図形のエッジ抽出の処理、及び各抽出処理後のデータをマージする処理（データ合成）それぞれについて複数のスレッドを割り当てることが可能である。スレッドの処理はそれを実行するユニット（ＣＰＵコア）にマップされ各コアが時間独立に処理を実行することで並列動作を可能とする。しかしながら並列に動作するＣＰＵ等は消費電力も大きく、また連続で並列動作した場合にはＣＰＵデバイス等から発生する熱等が問題になるケースが出てきている。

情報処理装置の冷却装置に関して開示されている技術を俯瞰すると、特許文献４等に代表されるように、熱の発生状況に応じて冷却機構の工夫、または処理するノードの切り替え等が行われている。しかしながら、このような提案ではＣＰＵ処理装置の制御範囲が大まかに区切られているだけであり、例えば、ノード単位やＣＰＵユニットという単位であるために、ジョブの状況の変化に応じた制御が困難であった。そのため、装置の発熱量や消費電力等を効果的に削減することが難しかった。また、特許文献５に開示されている手法に関しては科学計算等の大規模なジョブを扱うケースでは意味があるかもしれないが、昨今のクラウドデータセンターのように実質的にＣＰＵのロードタスクが広く分散するような利用の形態等は想定がなされていない。

ＰＤＬデータの印刷処理（画像形成処理）が主たる対象となるようなケースでは、昨今の技術開発により並列処理を瞬時に実施するケースはよりクリティカルな性能が求められる。しかしながら、先の先行技術文献に提案されている手法等では、十分に効率的でかつ高パフォーマンスを実現する手法は実現出来ないという課題があった。

上記の課題を鑑みて、本発明は、画像処理装置における画像の形成に関する処理速度の向上と処理効率とを両立させることを目的とする。

上記の課題に鑑みて、本発明は、印刷装置における印刷速度の向上と処理効率の優れた印刷技術の提供を目的とする。

上記の目的を達成するために、本発明は、受信した印刷のページから中間データを生成した後、該中間データから画像データを形成する画像処理装置であって、前記印刷のページの処理負荷を計算する計算手段と、前記計算手段の計算の結果に基づき、前記中間データの生成の動作モードとして、第一のモードと、前記第一のモードよりも低速かつ低い消費電力で前記中間データを生成する第二のモードとのいずれかを設定する制御手段と、を有することを特徴とする。

本発明によれば、画像処理装置における画像の形成に関する処理速度の向上と処理効率とを両立させることが出来る。

実施形態１の基本システム構成図 図形ごとに処理スレッドを割り当てる様子を示した図 各図形においてエッジ抽出処理を各々独立に適用した場合の図 図形に対してエッジ抽出処理を行う様子を示した図 システム上のＣＰＵコア数をＯＳ上で認識することを示す図 処理時間短縮の様子を示した図 実施形態１における複数コア適用時の処理時間短縮の様子を示した図 実施形態１におけるＲＩＰシステムの構成図 実施形態１におけるスプール数の変化を示した図 実施形態１における冷却機構を示した図 実施形態２のおける基本システム構成例の詳細説明図 冷却装置における能力及び電力の時間変動状況を示した図 実施形態２におけるスプール数の変化を示した図 ＲＩＰ制御部の動作パラメータを変更する際のフローチャート

（実施形態１）
図１は、画像処理装置１００のハードウェア構成の一例を示す図である。

図１において、ＣＰＵ１０１は、ＲＯＭ１０３又はハードディスク１１１からＲＡＭ１０２にロードされたＯＳや一般アプリケーション等のプログラムを実行し、後述するソフトウェアの機能及びフローチャートの処理を実現する。

ＲＡＭ１０２は、ＣＰＵ１０１の主メモリ、ワークエリア等として機能する。キーボードコントローラ（ＫＢＣ）１０５は、キーボード１０９や不図示のポインティングデバイスからのキー入力を制御する。ディスプレイコントローラ１０６は、ディスプレイ１１０の表示を制御する。ディスクコントローラ（ＤＫＣ）１０７は、ブートプログラム、種々のアプリケーション、フォントデータ、ユーザファイル等を記憶するハードディスク（ＨＤ）１１１やフレキシブルディスク（ＦＤ）等の外部メモリとのアクセスを制御する。

ＰＲＴＣ１０８は、接続された、媒体上に画像を形成して出力するプリンタエンジン部１１２との間の信号の交換を制御する。ＮＣ１１３は、ネットワークに接続されて、ネットワークに接続された他の機器との通信制御処理を実行する。なお、本実施形態では、以下に示す画像処理装置１００の機能は、ソフトウェアにより実現されるものと説明するが、各機能を専用のハードウェアで画像処理装置１００に実装するようにしても良い。なお、本実施形態のＣＰＵ１０１は、マルチコアのＣＰＵであるものとする。

図２は、各オブジェクトに対してエッジ抽出処理を各々独立に適用した場合の図である。ページ２０１上のオブジェクトごとにエッジ抽出処理を実施する様子を示している。オブジェクトごとにエッジ抽出処理のスレッド２１１〜スレッド２１３で抽出されたエッジ情報は再度ページ上の座標にマップされ合成処理がなされる。それぞれの処理は各々依存性がないために独立に実行することが出来る。つまり、オブジェクトのデータが入力された後、各オブジェクトのエッジ抽出の処理、及び各抽出処理後のデータをマージする処理（データ合成）それぞれについてスレッドを割り当てることが可能である。

スレッドの処理はそれを実行するユニット（ＣＰＵコア）にマップされ各コアが時間独立に処理を実行することで、並列で動作することが出来る。なおマージ処理はエッジ抽出が完了したオブジェクトに対して適用される。たとえば１のスレッド（すなわちコア）をマージ処理に割り当て、他をエッジ抽出に割り当てる。コアの数には制限があるため、ひとつのオブジェクトのエッジ抽出処理を完了したなら、当該コアは次のオブジェクトを対象としてエッジ抽出処理を行う。エッジ抽出を終えたオブジェクトはマージ処理の対象となる。抽出されたエッジは、マージによりページ内に再配置される。スレッドをコアに割り当てる処理は、例えばマージ処理を行うコアが行ってもよい。

マージされたエッジ抽出済みデータからは、ラスタライズ処理により、ラスタラインごとにエッジ間に画素が充填されたビットマップの画像データが生成される。

図３は、本実施形態の基本構成を示したレンダリングシステム（ＲＩＰシステム）の概説図である。レンダリングシステムは中間データ生成処理部３０１とスプール３０２、画像形成処理部３０３とを含む。図にあるようにＰＤＬデータは描画インターフェースを経由して、ＰＤＬインタープリタ３００からＲＩＰシステム（すなわちレンダラ）３０１に受け渡される。ＲＩＰシステム３０１では「データ受け取り」の処理ブロック３１１が図形、文字、画像等のＰＤＬオブジェクトを受け取り、不図示の内部スプーラに適時データを蓄えた後に後段の処理ユニットにデータを流すよう構成されている。

ＰＤＬオブジェクトが図形等であった場合は、該図形オブジェクトのデータはエッジ抽出処理（スレッド）２１１〜２１３に受け渡される。一方、ＰＤＬオブジェクトがイメージであった場合は画像処理（スレッド）３１２にデータを受け渡す。

なお、前述したベクタライズ処理も必要に応じて行われるが、ここではその説明を省略する。これらのスレッドはこのスレッドに割り当てられたひとつのプロセッサコアにより実行される。オブジェクトが１ページに複数存在する場合は、それぞれのオブジェクトに対して独立したスレッドでエッジ抽出処理が割り当てられる。ただし、並列処理されるオブジェクトの数はプロセッサコアの数が上限となる。各オブジェクトのエッジ抽出処理を後段の独立したスレッド２１１〜２１３で実行させる。

各スレッドはそれぞれに割り当てた処理ユニット（プロセッサコア）により実行されるので、データ受け取り処理ブロック３１１は、各処理ユニットで実行されるエッジ抽出処理にスケジュールされたオブジェクトのデータを流すよう構成されている。なお一つのコアで時分割的に複数のスレッドを実行することも可能であるが、本例では少なくともエッジ抽出処理に関しては、各処理はそれぞれのコアで実行されるものとする。ただし、エッジ抽出処理とその他の処理、たとえばＰＤＬデータの分析等を一つのコアで時分割的に実行することはあり得る。それぞれのエッジ抽出処理で抽出されたエッジデータは適宜後段のデータ合成処理（スレッド）３１３に渡される。そして、ページ上に合成（重ね合わせの処理）がなされると同時にタイル状のデータにフォーマットされた上でスプーラ３０２にＲＩＰ中間データとして書きだすよう構成されている。該タイル上にフォーマットされたＲＩＰ中間データは更に後段の画像形成処理３０３で処理され、タイル処理（スレッド）３３１〜３３３により各タイルにおいてピクセルの展開処理が行われる。それぞれのタイルの処理は時間独立で実行がなされる。タイルはつなぎ合わされて例えばバンドとなり、ラスタ信号としてエンジン部１１２に提供される。図４は、図３（基本システム概説図）の処理の中で、「エッジ抽出処理」と抽出されたエッジのデータをマージする処理「データ合成」におけるデータの流れを説明した概説図である。図４にあるように図形１、２のデータは実体としては図形の種類を表す図形種情報とそれを構成する座標データの群で構成されている。これらデータは「エッジ抽出処理」によりエッジデータ（図形等の外郭線）が抽出される。図形１と図形２にはそれぞれ独立した別々のスレッドで処理がなされるために同時に２つの図形のエッジデータが抽出される。

これらの処理の過程において不図示である色情報抽出処理により図形の輪郭の中の塗り情報が同時に抽出されるよう構成されている。スレッド３ではスレッド１およびスレッド２により抽出されたエッジデータおよび色情報から「データ合成」処理を行う。

例えば、図形２が赤の単色（不透明）で塗られており図形１が青の単色（不透明）で塗られていて、図形１が図形２の上に描画されている場合、重なりの部分は上層の色である青が塗られることになる。この状態では色情報は２つ（すなわち、青と赤）が保存される。

一方でスレッド３が処理の対象とする領域においては図形１と図形２の該領域におけるエッジデータの合成（例えば重なった結果で不要になったエッジは消去される）が行われる。本提案の処理方式では、重なりの状況によって、該領域に関して保持すべき色情報の数が増えることもある。例えば図形１が赤の単色（不透明）で塗られており、図形２が青の単色（透過）で塗られている場合で、かつ図形２が図形１の上に重なっている場合は透過合成の計算により該重なっている領域の色が計算される。例えば、青と赤を合成すると紫となるため、スレッド３の処理においては赤、青、紫の色情報が保持される。

図５は、上述したようにシステム情報を得るためにＯＳ側がハードウェア情報を、その内部に格納している状況を説明した概説図である。図中ブロックＰ１１０１はシステムのＯＳが表示するシステムインフォメーション情報であり、現在のＣＰＵの負荷状況や、利用されているメモリ量等を表示するものである。ＯＳは起動時にハードウェア情報（該ハードウェア情報は設定されているＢＩＯＳの情報を反映したものとなっている）を取得しているので自身がどのようなＣＰＵ上で動作しているかを把握している。それらはＯＳの中のシステム情報として保存されている状態である。よってＯＳに対して、ＣＰＵの「コア数」を問い合わせれば、該システムで利用可能なコア数の情報が確実に得られるように構成されている。

図６は、１ページの処理に８コアを割り当てる場合の処理時間の違いを説明したグラフである。従来の考え方では、どの領域のどのデータに対して何コアを割り当てても、処理するユニット（コア）の数に変わりはないので、結果的には速度に差異は出ないという見解が一般的であった。しかしながら、本願発明人の検討によれば、図にあるようにページを上下に分割しそれぞれに４コアを割り当てた場合の方が、１ページ全体に８コアを割り当てるよりも高速に処理が完了するということを見出した。ＣＰＵはデータを処理する際に、主メモリのデータにアクセスするがそれらは直接読み込まれるのではなく、バスやキャッシュを経由してデータが流れるようになっている。

実際のＣＰＵの構成は先の図５のＣＰＵの構成図のように８コアという構成であっても、必要なデータのアクセス経路が等距離にない、という状況が発生する。このことに考慮してコア割り当てのパターンを最適化しないとマルチコアＣＰＵを用いたシステムにおけるプログラムの処理速度を最大化することは出来ない。図６にあるように、グラフィックス画像を多く含むヘビーページを、１ページ全体に対して８コアのＣＰＵで処理した場合、１０５０ｍｓかかっている。しかし、下図にあるように２つの領域に分割してそれぞれに４コアを割り当てた場合は９００ｍｓで処理が完了しており、約１４．３％の高速化が達成出来る。

以上のように、８つのプロセッサコアを持つマルチコアＣＰＵを用いたレンダリングシステム（すなわち画像処理装置）によりレンダリングの処理負荷が高いヘビーページをレンダリングする場合には、ページを二つの領域に分割する。そして、それぞれの領域について、４つずつのコアでエッジ抽出をはじめとする処理を実行する。これによりコアの稼働率を向上させ、より短時間でレンダリング処理を完了することができる。

なお、本実施形態では、ヘビーページか否かに応じてエッジ抽出処理に割り当てるコアの数を変えているが、無条件に、ヘビーページに対するのと同様に、複数のプロセッサコアをエッジ抽出処理に割り当ててもよい。すなわち、図８のヘビーページ検出部８０２および１コア処理用モジュールを持たず、コアの数に応じて、スレッドにコアを割り当てる。

また、コアの数が８を超える場合にも、同様にしてページを２つの領域に分割し、コアを２つのグループに分けて、それぞれの領域に含まれたオブジェクトのエッジ抽出処理をはじめとするレンダリング処理をおこなってよい。さらに、たとえば１つの領域を処理するコアの数を所定数、例えば４とするようにコアをグループ分けし、そのグループに対応付けてページを分割し、分割した各領域を１つのコアグループでレンダリング処理してもよい。

図７は、実施形態１におけるシステム構成に関する概説図である。ここではシステム情報を得るためにＯＳ側がハードウェア情報を、その内部に格納しているものを利用する。このシステムは、４コアのプロセッサを４つ搭載したマルチＣＰＵ構成を有している。したがって、コアの数は合計で１６となる。しかしながら、図７で示されるように、実際の物理コアの数と、オペレーティングシステムが認識する論理コアの数とが異なっているシステムが存在する。

システム側はＣＰＵコア数を３２と認識しているが実際のボードには４コアのＣＰＵが４つ搭載されているだけなので、実際の物理コアは１６となっている。これは、１つのコアの計算資源は１つのコアの分だけしか用意されていないが、デコーダ等を複数用意し、レジスタやパイプラインの空き時間を利用してあたかも２つのコア（これが論理コアである）があるかのようにふるまう技術による。演算回路は１コアに１セットしか容易されていないため、２つの論理コアにより２つのスレッドを完全に並列実行できるわけではない。

この状況で、３２コアというオペレーティングシステムにより提供された情報を参照して、実施形態１と同様の手法でコアの割り当ての最適化を行っても処理速度が向上しないという自体が発生する。そこで本実施形態ではＯＳ側から提供されるシステム情報をそのまま利用するのではなくて、不図示のＵＩによりユーザーがＣＰＵの構成情報を与えるよう構成している。

本システムでは１６コアの物理コアが利用出来る状態であるので、ページを並列処理で高速化する場合には、１ページを１６コアで処理する、１ページを２分割して各領域を８コアで処理する等の割り当てが可能である。但し、同時に利用するコア数が多い為に発熱量は高くなることが想定される。これに対して、ページ処理を高速化するための並列コアの割り当ては全てのコア（１６コア）を割り当てるのではなく、その一部を割り当てることも可能である。例えば、１ページを２分割して各領域に２コアで処理（発熱量は比較的低い）するという選択も考えられる。

図８は、実施形態１におけるプリントシステムの概略ブロック図である。印刷ジョブが投入されるとサーバー（主にはクラウド上のサーバー）上で中間データが生成され、これが後段の画像形成処理ブロックに渡され画像（ピクセル）を生成する。該形成された画像はエンジンに転送され印刷出力を行うよう構成されている。

ユーザーはＵＩ等により、３２の論理コアを提供しているシステムにおいて１６の物理コアを指定し、かつヘビーページの場合に２つのモードを用意し、それぞれの設定を行うよう構成されている。ヘビーページの場合の第一のモードは、１ページを２分割し、それぞれの領域に８コアを割り振る。また第二のモードは１ページを２分割し、それぞれの領域に２コアを割り振るように設定を行っている。

第一のモードは処理時間を優先させたい場合に利用する設定であり、ＣＰＵから発生する熱は増えるが高速に処理が出来るモードである。これに対し、第二のモードは第一のモードより低速であるが発熱量も抑えられる動作モードである。

図８にあるようにプリントシステムに印刷ジョブが入力されると、まずページが検査ブロックで検査される。ここでページがヘビーページであるか否かを判定される。ページがヘビーページでない場合（便宜上シンプルページとも呼ぶ）は、中間データ生成処理部は動作モードＡで動作し、ページがヘビーページの場合は、更に、スプーラの監視情報を参照し、スプール状況に余裕があるか否かを判断する。

ここでスプール状況（後述の図９で説明）に余裕がない場合は、中間データ生成処理部は動作モードＢ１（図８で説明の第一のモード）を選択する。一方で、スプール状況に余裕がある場合は、中間データ生成処理部は動作モードＢ２（同第二のモード）を選択するよう構成されている。コアの割り当ては、モードＡにおける処理は１ページ全体を１コアで処理するように構成されている。

一方、モードＢ１の処理ではページを２つの領域に分割し、それぞれに８つのコアを割り振り、モードＢ２の処理ではページを２つの領域に分割し、それぞれに２つのコアを割り振るよう構成している。

図９は、先の図８中のスプーラにおけるスプール数の変化を示す図であり、横軸は時間軸、縦軸はスプール数を示している。

時刻ｔ１では、スプール数は５０ページであり、スプール可能な最大数（スプール最大数）１５０ページに対してまだスプール可能な状態である。時刻ｔ１において、中間データ生成処理部は次のモードで動作する。このｔ１の時刻でシンプルページを処理する場合は、モードＡで処理を行う。しかし、ヘビーページを検出した場合はモードＡだと時間がかかり過ぎてしまう。時刻ｔ１の段階ではスプール数が５０ページでありスプール数は少ない。ヘビーページが大量に入力されると中間データ生成処理部から生成される単位時間あたりのページ数が減少し、その結果、スプールが空になってしまう可能性がある。そこで高速なモードで処理を行うように切り替えを行う。ここではモードＢ１でスプールデータの生成処理を行う。モードＢ１では８コア＋８コアの合計１６のコアを短時間の中で同時実行する。このモードＢ１はマルチコアのＣＰＵを利用するためにクラウドでＨＰＣ（高性能）インスタンスを利用するように割り当てる。利用するインスタンスについては、後述の図１０で詳説する。

時刻ｔ３では、スプール数は１５０ページであり、スプール最大数１５０に達した状態である。これ以降、中間データ生成処理部は、動作モードを高速モードから発熱を抑えたモードＡ（いわゆる省エネモードと同義）に切り替えてスプールデータの生成処理を行う。このモードＡを実行する環境としてはＨＰＣ（高性能）インスタンスよりも処理速度が遅く、より消費電力を抑えたインスタンスを選択するように構成する。モードＡはスプール数が、予め定められた下限数（本実施例では１００ページを想定）を下回るまで、中間データ生成処理部は、モードＡでスプールデータの生成処理を行う。

時刻ｔ３からｔ４のタイミングでインスタンスを切り替えなかった場合、ＨＰＣ（高性能）インスタンスを使い続けることになる。その結果、対象のノードの発熱によりＣＰＵ装置のクロック数が上がらない状況になる（または最悪の場合は逆にクロック数を下げて処理が行われる場合もある）。パフォーマンスアップが期待出来ない状況だと、時刻ｔ４では、スプール数は９０となり、中間データ生成処理部はスプールデータの生成処理をモードＡで続行することが出来なくなる。しかし、本実施形態１の例では、上述したように時刻ｔ３のタイミングで、動作モードをＢからＡへ切り替えているために発熱量が抑えられる。その結果、スプール数で１００ページを維持することが出来る（時刻ｔ５、ｔ６ともにモードＡで処理が続行される）。図１０は、本実施形態で想定しているデータセンターの空調設備を含めた構成概念図である。印刷ジョブはＷＡＮを経由してデータセンター（いわゆるクラウド）に送信され、そこで中間データ生成処理がなされる。該生成された中間データは再度ＷＡＮを経由して印刷拠点に転送された後、画像形成処理が行われる。該画像形成処理により生成された画像はプリンタエンジンに渡され印刷出力するように構成されている。

データセンター内のサーバーは、パフォーマンスが求められる処理系にはＨＰＣ系のサーバー群（ＨＰＣインスタンス）が用意されており、図１０中ではそれらはＨＰＣゾーンに区分されている。一方で処理パフォーマンスが問題にならない処理系では、いわゆるマイクロサーバーで構成されるスモールサーバー群（マイクロインスタンスとも呼ばれる）が用意されている。マイクロインスタンスは、クロック数は高くないが省電力で効率良く動作する。近年の集積技術の向上からＣＰＵパッケージそのものを含め高集積度な（ＣＰＵパッケージのサイズ、および本体サイズがコンパクトな）構成となっている。これらは図１０にあるように複数のＭＳゾーンに配置されている。

本実施形態では、図８の説明にあるモードＡのジョブは、基本的にマイクロインスタンス（ＭＳゾーン）で処理がなされ、モードＢのジョブはＨＰＣゾーンで実行されるよう構成されている。モードＡのジョブをマイクロインスタンス（ＭＳゾーン）に転送する場合は複数のマイクロインスタンスのゾーンが存在する。一般的にはＨＰＣゾーンからのネットワーク的な距離が近い箇所のＭＳゾーンを選択するのが最良であると考えられるが本発明の実施形ではネットワーク的に近くないＭＳゾーンのインスタンスもデータを転送する候補とすることを特徴とする。

以下、図１１のフローチャートを用いて上記処理を説明する。

図１１（ａ）のフローチャートにあるようにステップＳ１０１では処理対象のＰＤＬページを受信し不図示のブロックにより受信したページが処理の軽いページなのか、処理が重いページ（処理時間のかかるページ）を判断する。次に、ステップＳ１０２において現在の中間データを保持しているスプーラのスプール数を把握する（図８中の監視機能はこれが該当）。ステップＳ１０３においては該ステップＳ１０１，ステップＳ１０２の結果に基づいて利用するインスタンスを決定し、ＨＰＣインスタンスを利用する場合はステップＳ１０４へ、ＭＳインスタンスを利用する場合はステップＳ２００へ分岐するようになっている。分岐の条件としては、
（１）処理ページが軽いページの場合はＭＳインスタンスを選択する
（２）処理ページが重いページであり、かつスプーラ数が少ない場合はＨＰＣインスタンスを選択する（スプーラ数が多い場合は処理ページが重くてもＭＳインスタンスが選択される）
となっている。ステップＳ２００以降ではステップＳ２０１でスプール数の状況を確認し、スプール数に余力がある場合は、ステップＳ２０２に進み、複数のＭＳゾーンをデプロイする候補として選択出来るようにする。一方でステップＳ２０１の判定でスプール数に余裕がない場合は、ステップＳ２０３へ進み、ＭＳゾーンでもネットワーク的に最も近い距離にあるＭＳゾーンを選択するよう構成する。ここでネットワーク距離とは、ジョブを制御しているＲＩＰ制御部から目的のインスタンスの存在するノードまでのネットワーク距離を指す。例えば、要求確認信号に対する応答（レスポンスタイム）となる（ルーターを経由するホップ数を代わりの指標としても良い）。対象となるＭＳインスタンスを選択した後に、該インスタンスにてステップＳ２０４にある中間データ生成処理を実行しステップＳ２００の処理を終了する。ステップＳ１０４ではＨＰＣインスタンスにおける中間データ生成処理を実行した後にステップＳ１１１にて該生成された中間データを適宜転送するように構成されている。

（実施形態２）
図１２は、実施形態２におけるプリントシステムの概略ブロック図である。ユーザーはＵＩ等により、６４の論理コアを提供しているシステムにおいて３２の物理コアを指定し、かつヘビーページの場合に２つのモードを用意し、それぞれの設定を行うよう構成されている。ヘビーページの場合の第一のモード（モードＢ１）は、１ページを４分割し、それぞれの領域に８コアを割り振る。また第二のモード（モードＢ２）は１ページを２分割し、それぞれの領域に２コアを割り振るように設定を行っている。第一のモードは処理時間を優先させたい場合に利用する設定であり、ＣＰＵから発生する熱は増えるが高速に処理が出来るモードである。該モードＢ２はＨＰＣインスタンスを用いて処理する。これに対し、第二のモードは第一のモードより高速ではないが発熱量は第一のモードと比較して抑えられる動作モードである。該モードＢ２はＭＳインスタンスを用いて処理する。

シンプルページを処理する場合に、モードＡで（１ページを分割しないで、かつ、１コアで）処理を行うのは実施形態１と同様である（第二のモードと同様にＭＳインスタンスを用いて処理を行う）。

実施形態１との対比では印刷ジョブがＲＩＰに投入される前にジョブスプーラに一旦スプールされる点が異なる。該スプーラに投入されたジョブはページ単位でヘビーページであるか否かを、図の先読み検査ブロックにより検査される。この検査の情報は図中の制御マネージャーに適宜、通知されるよう構成されている。

図１３は、先の図１１中のスプーラにおけるスプール数の変化を示す図であり、横軸は時間軸、縦軸はスプール数を示している。

時刻ｔ１では、スプール数は５０ページであり、スプール可能な最大数（スプール最大数）１５０ページに対してまだスプール可能な状態である。時刻ｔ１において、中間データ生成処理部は次のモードで動作する。このｔ１の時刻でシンプルページを処理する場合は、モードＡで処理を行う。しかし、ヘビーページを検出した場合はモードＡだと時間がかかり過ぎてしまう。時刻ｔ１の段階ではスプール数が５０ページでありスプール数は少ない。ヘビーページが大量に入力されると中間データ生成処理部から生成される単位時間あたりのページ数が減少し、その結果、スプールが空になってしまう可能性がある。そこで高速なモードで処理を行うように切り替えを行う。ここではモードＢ１でスプールデータの生成処理を行う。

但し、先読み処理ブロックにて、ｔ１以降の入力データにおいてヘビーページが連続で投入されることがないことがわかっている（予め設定した閾値で判定）場合は、モードＢ２で（切り替えて）処理を行うよう構成されている。

モードＢ１では８コアｘ４の合計３２のコアを短時間の中で同時実行するため、ＣＰＵ装置はかなりの熱を発生させてしまう。該当するページに関しては上述した先読み検査ブロックで検出されている。

時刻ｔ３では、スプール数は１５０ページであり、スプール最大数１５０に達した状態である。これ以降、中間データ生成処理部は、動作モードを高速モードから発熱を抑えたモードＡ（いわゆる省エネモードに該当する）に切り替えてスプールデータの生成処理を行う。スプール数が、予め定められた下限数（本実施例では１００ページを想定）を下回るまで、中間データ生成処理部は、モードＡでスプールデータの生成処理を行う。

適切なタイミングでモードＢ２からＢ１に切り替えを実施しなかった場合、発熱によりＣＰＵ装置のクロック数を上げられない状況になる（または最悪の場合は逆にクロック数を下げて処理が行われる場合もある）。パフォーマンスアップが期待出来ない状況だと、時刻ｔ４では、スプール数は想定以上に落ち込むことが考えられる。しかし、「先読み検査」処理によりＨＰＣゾーンを使わない状態を出来る限り長く保持するよう構成しているため、本当に必要な時に最大能力を発揮（クロックアップした状態で処理可能）出来る状態となる。図の例では時刻ｔ４において、スプール数の急激な落ち込みを防ぐことが出来るために、その結果スプール数で１２０ページを維持することが出来る（時刻ｔ５、ｔ６ともにモードＡで処理が続行される）。

（他の実施形態）
先の実施形２においては中間データ生成処理間にＰＤＬページの複雑さを予想してから動作の切り替えを行っている。ページが重いと判断された場合、該ページはヘビーページとしてマルチコアＣＰＵによる並列実行の対象となり、かつ、それらは基本的にＨＰＣインスタンスが選択され処理が実行される。但し、例外として、ヘビーページであったとしても、スプーラに余力がある場合は、ＭＳインスタンスに切り替えて動作するよう構成されている。このような構成のシステムを、実際の稼働状況をみてみると、該ヘビーページが（数十〜数百ページ）連続で実行される場合はパフォーマンス（処理時間）が想定した場合よりも遅くなることがしばしば観察される。そのような変化が起きている場合は、実施形態２の動作において、ＭＳインスタンスへの割り振りの動作を抑制する必要が出てくる。

図１４はＭＳインスタンスへの割り振りの動作を抑制するために、ＲＩＰ制御部の動作パラメータを変更する動作を説明した概略フローチャートである。

該フローチャートにあるようにステップＳ３０１では処理対象のＰＤＬページを受信し不図示のブロックにより受信したページが処理の軽いページなのか、処理が重いページ（処理時間のかかるページ）を判断する。次に、ステップＳ３０２において現在の中間データを保持しているスプーラのスプール数を把握する（図８中の監視機能はこれが該当）。ステップＳ３０３においては前記ステップＳ３０１，ステップ３１０２の結果に基づいて利用するインスタンスを決定し、ＨＰＣインスタンスを利用する場合はステップＳ３０４へ、ＭＳインスタンスを利用する場合はステップＳ２００へ分岐するようになっている。

分岐の条件としては、
（１）処理ページが軽いページの場合はＭＳインスタンスを選択する
（２）処理ページが重いページであり、かつスプーラ数が少ない場合はＨＰＣインスタンスを選択する（スプーラ数が多い場合は処理ページが重くてもＭＳインスタンスが選択される。該当スプーラ数を判断するための閾値はＲＩＰ制御部の動作パラメータを切り替えることで実現する）
となっている。ステップＳ２００以降の動作は先の実施形態２と同様であるので詳細の説明は割愛する。

ステップＳ３０４では中間データ生成処理に要する時間を事前に予測しておく。次のステップＳ３０５にて中間データ生成処理を実行した後に、ステップＳ３０６において実際に処理に要した時間を記録する。ステップＳ３０７では、ステップＳ３０４とステップＳ３０６で取得した予測と実測値の比較を行う。ステップＳ３０８ではステップＳ３０７の結果に基づいて、ＲＩＰ制御部の動作パラメータの切り替えが必要か否かを判断するように構成されている。ステップＳ３０９では前記ステップＳ３０８の判断からＲＩＰ制御部の動作パラメータの切り替え処理を行う。

この切り替えは、例えば、スプール数に余力がない場合（定常値は８０ページ以下を余力がないとする）で、「先読み検査」処理により、後続の２０ページにヘビーページが含まれていない場合には、ＭＳインスタンスに割り振ると規定していたとする。その場合、パラメータを切り替える処理により、スプール数（余力の有無を判定する）閾値を８０から９０ページに変更し、また、後続ページにヘビーページが連続していないことを確認する数字を２０から３０へ変更するという動作になる。

また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

Claims (9)

1. 受信した印刷のページから中間データを生成した後、該中間データから画像データを形成する画像処理装置であって、
   前記印刷のページの処理負荷を計算する計算手段と、
   前記計算手段の計算の結果に基づき、前記中間データの生成の動作モードとして、第一のモードと、前記第一のモードよりも低速かつ低い消費電力で前記中間データを生成する第二のモードとのいずれかを設定する制御手段と、を有することを特徴とする画像処理装置。
2. 前記画像処理装置は、複数のサーバーから構成され、
   前記制御手段で第一のモードが設定された場合は、前記複数のサーバーの内、処理速度の速いサーバーで前記中間データの生成を行い、前記制御手段で第二のモードが設定された場合は、前記複数のサーバーの内、低い消費電力で動作するサーバーで前記中間データの生成を行うことを特徴とする請求項１に記載の画像処理装置。
3. 前記中間データを保持するスプーラを更に有し、
   前記制御手段は、
   前記スプーラに保持されたデータに応じて、前記第一のモードと前記第二のモードとのいずれかを設定することを特徴とする請求項１または請求項２に記載の画像処理装置。
4. 前記画像処理手段は、複数のプロセッサコアを有し、前記制御手段は、前記中間データの生成の動作モードに応じて、前記中間データの生成を行うプロセッサを変更することを特徴とする請求項１乃至３のいずれか１項に記載の画像処理装置。
5. 前記制御手段は、前記印刷のページを複数の領域に分け、それぞれの領域を前記複数のプロセッサそれぞれが行うように制御することを特徴とする請求項１乃至４のいずれか１項に記載の画像処理装置。
6. 前記低い消費電力で動作するサーバーは、マイクロインスタンスであることを特徴とする請求項２に記載の画像処理装置。
7. 前記画像データをプリンタエンジンに出力する出力手段を更に有することを特徴とする請求項１乃至６のいずれか１項に記載の画像処理装置。
8. 受信した印刷のページから中間データを生成した後、該中間データから画像データを形成する画像処理方法であって、
   計算手段が、前記印刷のページの処理負荷を計算する計算工程と、
   制御手段が、前記計算工程の計算の結果に基づき、前記中間データの生成の動作モードとして、第一のモードと、前記第一のモードよりも低速かつ低い消費電力で前記中間データを生成する第二のモードとのいずれかを設定する制御工程と、を有することを特徴とする画像処理方法。
9. コンピュータを、
   受信した印刷のページから中間データを生成した後、該中間データから画像データを形成する画像処理装置であって、
   前記印刷のページの処理負荷を計算する計算手段と、
   前記計算手段の計算の結果に基づき、前記中間データの生成の動作モードとして、第一のモードと、前記第一のモードよりも低速かつ低い消費電力で前記中間データを生成する第二のモードとのいずれかを設定する制御手段と、を有することを特徴とする画像処理装置として動作させるためのプログラム。

Images