以下、図面を参照して本発明の実施形態の一例を詳細に説明する。図1には、本発明に係るデータ処理装置を兼ねた画像処理装置として機能することが可能なコンピュータ10が示されている。なお、このコンピュータ10は、複写機、プリンタ、ファクシミリ装置、これらの機能を兼ね備えた複合機、スキャナ、写真プリンタ等のように内部で画像処理を行う必要のある任意の画像取扱機器に組み込まれていてもよいし、パーソナル・コンピュータ(PC)等の独立したコンピュータであってもよく、更にPDA(Personal Digital Assistant)や携帯電話機等の携帯機器に組み込まれたコンピュータであってもよい。
コンピュータ10はCPU12、メモリ14、表示部16、操作部18、記憶部20、画像データ供給部22及び画像出力部24を備えており、これらはバス26を介して互いに接続されている。コンピュータ10が上述した画像取扱機器に組み込まれている場合、表示部16や操作部18としては、画像取扱機器に設けられたLCD等から成る表示パネルやテンキー等を適用することができる。また、コンピュータ10が独立したコンピュータである場合、表示部16や操作部18としては、当該コンピュータに接続されたディスプレイやキーボード、マウス等を適用することができる。また、記憶部20としてはHDD(Hard Disk Drive)が好適であるが、これに代えてフラッシュメモリ等の他の不揮発性記憶手段を用いることも可能である。
また、画像データ供給部22は処理対象の画像データを供給できるものであればよく、例えば紙や写真フィルム等の記録材料に記録されている画像を読み取って画像データを出力する画像読取部、通信回線を介して外部から画像データを受信する受信部、画像データを記憶する画像記憶部(メモリ14又は記憶部20)等を適用することができる。また、画像出力部24は画像処理を経た画像データ又は該画像データが表す画像を出力するものであればよく、例えば画像データが表す画像を紙や感光材料等の記録材料に記録する画像記録部、画像データが表す画像をディスプレイ等に表示する表示部、画像データを記録メディアに書き込む書込装置、画像データを通信回線を介して送信する送信部を適用することができる。また、画像出力部24は画像処理を経た画像データを単に記憶する画像記憶部(メモリ14又は記憶部20)であっても構わない。
図1に示すように、記憶部20には、CPU12によって実行される各種のプログラムとして、メモリ14等のリソースの管理やCPU12によるプログラムの実行の管理、コンピュータ10と外部との通信等を司るオペレーティングシステム30のプログラム、コンピュータ10を画像処理装置として機能させるための画像処理プログラム群34、CPU12が上記画像処理プログラム群を実行することで実現される画像処理装置に対して所望の画像処理を行わせる各種のアプリケーション32のプログラム(図1ではアプリケーションプログラム群32と表記)が各々記憶されている。
画像処理プログラム群34は、前述した各種の画像取扱機器や携帯機器を開発する際の開発負荷を軽減したり、PC等で利用可能な画像処理プログラムを開発する際の開発負荷を軽減することを目的として、各種の画像取扱機器や携帯機器、PC等の各種機器(プラットフォーム)で共通に使用可能に開発されたプログラムである。画像処理プログラム群34によって実現される画像処理装置は、アプリケーション32からの構築指示に従い、アプリケーション32が指示した画像処理を行う画像処理部を構築し、アプリケーション32からの実行指示に従い、前記画像処理部によって画像処理を行うが(詳細は後述)、画像処理プログラム群34は、所望の画像処理を行う画像処理部(所望の構成の画像処理部)の構築を指示したり、構築された画像処理部による画像処理の実行を指示するためのインタフェースをアプリケーション32に提供している。このため、内部で画像処理を行う必要のある任意の機器を新規開発する等の場合にも、前記画像処理を行うプログラムの開発に関しては、当該機器で必要とされる画像処理を上記のインタフェースを利用して画像処理プログラム群34に行わせるアプリケーション32を開発するのみで済み、実際に画像処理を行うプログラムを新たに開発する必要が無くなるので、開発負荷を軽減することができる。
また、画像処理プログラム群34によって実現される画像処理装置は、前述のように、アプリケーション32からの構築指示に従い、アプリケーション32が指示した画像処理を行う画像処理部を構築し、構築した画像処理部によって画像処理を行うので、例えば画像処理対象の画像データの色空間や1画素当たりのビット数が不定であったり、実行すべき画像処理の内容や手順・パラメータ等が不定である場合にも、アプリケーション32が画像処理部の再構築を指示することで、画像処理装置(画像処理部)によって実行される画像処理を、処理対象の画像データ等に応じて柔軟に変更することができる。
以下、画像処理プログラム群34について説明する。図1に示すように、画像処理プログラム群34はモジュールライブラリ36と、処理構築部42のプログラムと、処理管理部ライブラリ47に大別される。詳細は後述するが、本実施形態に係る処理構築部42は、アプリケーションからの指示により、例として図3に示すように、予め定められた画像処理を行う複数の画像処理モジュール38と、個々の画像処理モジュール38の前段及び後段の少なくとも一方に配置され画像データを記憶するためのバッファを備えたバッファモジュール40と、がパイプライン形態又はDAG(Directed Acyclic Graph:有向非循環グラフ)形態で連結されて成る画像処理部50を構築する。画像処理部50を構成する個々の画像処理モジュールの実体はCPU12によって実行されCPU12で予め定められた画像処理を行わせるための第1プログラム、又は、CPU12によって実行されCPU12により図1に図示されていない外部の画像処理装置(例えば専用画像処理ボード等)に対する処理の実行を指示するための第2プログラムであり、上述したモジュールライブラリ36には、予め定められた互いに異なる画像処理(例えば入力処理やフィルタ処理、色変換処理、拡大・縮小処理、スキュー角検知処理、画像回転処理、画像合成処理、出力処理等)を行う複数種の画像処理モジュール38のプログラムが各々登録されている。以下では、説明を簡単にするために、画像処理部50を構成する個々の画像処理モジュールの実体が上記の第1プログラムであるものとして説明する。
個々の画像処理モジュール38は、例として図4(A)にも示すように、画像データに対する画像処理を予め定められた単位処理データ量ずつ行う画像処理エンジン38Aと、画像処理モジュール38の前段及び後段のモジュールとの画像データの入出力及び画像処理エンジン38Aの制御を行う制御部38Bから構成されている。個々の画像処理モジュール38における単位処理データ量は、画像の1ライン分、画像の複数ライン分、画像の1画素分、画像1面分等を含む任意のバイト数の中から、画像処理エンジン38Aが行う画像処理の種類等に応じて予め選択・設定されており、例えば色変換処理やフィルタ処理を行う画像処理モジュール38では単位処理データ量が1画素分とされ、拡大・縮小処理を行う画像処理モジュール38では単位処理データ量が画像の1ライン分又は画像の複数ライン分とされ、画像回転処理を行う画像処理モジュール38では単位処理データ量が画像1面分とされ、画像圧縮伸長処理を行う画像処理モジュール38では単位処理データ量が実行環境に依存するNバイトとされている。
また、モジュールライブラリ36には、画像処理エンジン38Aが実行する画像処理の種類が同一でかつ実行する画像処理の内容が異なる画像処理モジュール38も登録されている(図1では、この種の画像処理モジュールを「モジュール1」「モジュール2」と表記して示している)。例えば拡大・縮小処理を行う画像処理モジュール38については、入力された画像データを1画素おきに間引くことで50%に縮小する縮小処理を行う画像処理モジュール38、入力された画像データに対して指定された拡大・縮小率で拡大・縮小処理を行う画像処理モジュール38等の複数の画像処理モジュール38が各々用意されている。また、例えば色変換処理を行う画像処理モジュール38については、RGB色空間をCMY色空間へ変換する画像処理モジュール38やその逆へ変換する画像処理モジュール38、L*a*b*色空間等の他の色空間変換を行う画像処理モジュール38が各々用意されている。
また、画像処理モジュール38の制御部38Bは、画像処理エンジン38Aが単位処理データ量ずつ処理するために必要な画像データを入力するために、自モジュールの前段のモジュール(例えばバッファモジュール40)から画像データを単位読出データ量ずつ取得し、画像処理エンジン38Aから出力される画像データを単位書込データ量ずつ後段のモジュール(例えばバッファモジュール40)へ出力する(画像処理エンジン38Aで圧縮等のデータ量の増減を伴う画像処理が行われなければ単位書込データ量=単位処理データ量となる)か、画像処理エンジン38Aによる画像処理の結果を自モジュールの外部へ出力する(例えば画像処理エンジン38Aがスキュー角検知処理等の画像解析処理を行う場合、画像データに代えてスキュー角検知結果等の画像解析処理結果が出力されることがある)処理を行うが、モジュールライブラリ36には、画像処理エンジン38Aが実行する画像処理の種類及び内容が同一で、上記の単位処理データ量や単位読出データ量、単位書込データ量が異なる画像処理モジュール38も登録されている。例えば、画像回転処理を行う画像処理モジュール38についても、前述のように単位処理データ量が画像1面分の画像処理モジュール38のプログラム以外に、単位処理データ量が画像の1ライン分や画像の複数ライン分の画像処理モジュール38のプログラムがモジュールライブラリ36に登録されていても良い。
また、モジュールライブラリ36に登録されている個々の画像処理モジュール38のプログラムは、画像処理エンジン38Aに相当するプログラムと制御部38Bに相当するプログラムから構成されているが、制御部38Bに相当するプログラムは部品化されており、個々の画像処理モジュール38のうち単位読出データ量及び単位書込データ量が同一の画像処理モジュール38は、画像処理エンジン38Aで実行される画像処理の種類や内容に拘わらず、制御部38Bに相当するプログラムが共通化されている(制御部38Bに相当するプログラムとして同一のプログラムが用いられている)。これにより、画像処理モジュール38のプログラムの開発にあたっての開発負荷が軽減される。
なお、画像処理モジュール38の中には、入力される画像の属性が未知の状態では単位読出データ量及び単位書込データ量が確定しておらず、入力画像データの属性を取得し、取得した属性を予め定められた演算式に代入して演算することで単位読出データ量や単位書込データ量が確定するモジュールが存在しているが、この種の画像処理モジュール38については、単位読出データ量と単位書込データ量が互いに同一の演算式を用いて導出される画像処理モジュール38について、制御部38Bに相当するプログラムを共通化するようにすればよい。また、本実施形態に係る画像処理プログラム群34は、前述のように各種機器に実装可能であるが、画像処理プログラム群34のうちモジュールライブラリ36に登録する画像処理モジュール38の数や種類等については、画像処理プログラム群34を実装する各種機器で必要とされる画像処理に応じて、適宜追加・削除・入替等が可能であることは言うまでもない。
また、画像処理部50を構成する個々のバッファモジュール40は、例として図4(B)にも示すように、コンピュータ10に設けられたメモリ14からオペレーティングシステム30を通じて確保されたメモリ領域で構成されるバッファ40Aと、バッファモジュール40の前段及び後段のモジュールとの画像データの入出力及びバッファ40Aの管理を行うバッファ制御部40Bから構成されている。個々のバッファモジュール40のバッファ制御部40Bもその実体はCPU12によって実行されるプログラムであり、モジュールライブラリ36にはバッファ制御部40Bのプログラムも登録されている(図1ではバッファ制御部40Bのプログラムを「バッファモジュール」と表記して示している)。
なお、詳細は後述するが、画像処理部50における画像処理の処理方式としては、画像処理部50の個々の画像処理モジュール38で互いに並列に画像処理を行わせる並列処理方式と、画像処理部50の画像処理モジュール38のうちの常に単一の画像処理モジュール38で画像処理を行わせると共に、画像処理を行わせる画像処理モジュール38を逐次切り替える逐次処理方式があり、本実施形態では、並列処理方式で画像処理を行わせる場合には並列処理用の画像処理部50を構築し、逐次処理方式で画像処理を行わせる場合には逐次処理用の画像処理部50を構築することで、画像処理部50における画像処理の処理方式を切り替えるようになっている。
ここで、逐次処理方式では画像処理を行っている画像処理モジュール38の数が常に1であるので、バッファモジュール40のバッファ40Aに対しても常に単一の画像処理モジュール38のみがアクセスするのに対し、並列処理方式では全ての画像処理モジュール38が並列に画像処理を行うので、バッファモジュール40のバッファ40Aに対して複数の画像処理モジュール38が同時にアクセスする可能性があり、バッファ40Aへのアクセスに対して排他制御を行う必要がある。このため、本実施形態では、並列処理用として排他制御を行う機能が付加されたバッファモジュール40が、逐次処理用として排他制御を行う機能が付加されていないバッファモジュール40が各々用意され、モジュールライブラリ36には、排他制御を行う機能が付加されたバッファモジュール40のプログラムと排他制御を行う機能が付加されていないバッファモジュール40のプログラムが各々登録されている。
また、アプリケーション32からの指示に従って画像処理部50を構築する処理構築部42は、図1に示すように複数種のモジュール生成部44から構成されている。複数種のモジュール生成部44は互いに異なる画像処理に対応しており、アプリケーション32によって起動されることで、対応する画像処理を実現するための画像処理モジュール38及びバッファモジュール40から成るモジュール群を生成する処理を行う。なお、図1ではモジュール生成部44の一例として、モジュールライブラリ36に登録されている個々の画像処理モジュール38が実行する画像処理の種類に対応するモジュール生成部44を示しているが、個々のモジュール生成部44に対応する画像処理は、複数種の画像処理モジュール38によって実現される画像処理(例えばスキュー角検知処理と画像回転処理から成るスキュー補正処理)であってもよい。必要とされる画像処理が複数種の画像処理を組み合わせた処理である場合、アプリケーション32は複数種の画像処理の何れかに対応するモジュール生成部44を順次起動する。これにより、アプリケーション32によって順次起動されたモジュール生成部44により、必要とされる画像処理を行う画像処理部50が構築されることになる。
また図1に示すように、処理管理部ライブラリ47には、処理管理部46のプログラムが複数登録されている。個々の処理管理部46は、画像処理部50における画像処理の実行を制御するワークフロー管理部46A、画像処理部50の各モジュールによるメモリ14や各種のファイル等のコンピュータ10のリソースの使用を管理するリソース管理部46B、及び、画像処理部50で発生したエラーを管理するエラー管理部46Cを含んで構成される。処理管理部ライブラリ47にプログラムが登録されている処理管理部46は、並列処理用の画像処理部50(バッファモジュール40として排他制御機能付きのバッファモジュール40を適用した画像処理部50)を構築させ、構築させた画像処理部50で並列処理方式によって画像処理が行われるように制御する並列処理管理部と、逐次処理用の画像処理部50(バッファモジュール40として排他制御機能無しのバッファモジュール40を適用した画像処理部50)を構築させ、構築させた画像処理部50で逐次処理方式によって画像処理が行われるように制御する逐次処理管理部に大別される。
また、図1では並列処理管理部のプログラム及び逐次処理管理部のプログラムを各々1個のみ示しているが、処理管理部ライブラリ47には、並列処理管理部のプログラムとして、互いに内容の異なる並列処理を並列処理用の画像処理部50に行わせる複数種の並列処理管理部のプログラムを各々登録可能とされていると共に、逐次処理管理部のプログラムとして、互いに内容の異なる逐次処理を逐次処理用の画像処理部50に行わせる複数種の逐次処理管理部のプログラムを各々登録可能とされている。前述の処理構築部42は選択起動部45を備えており、選択起動部45は、アプリケーション32から画像処理部50の構築が指示された際に、処理管理部ライブラリ47に登録されている各処理管理部の中から何れかの処理管理部を選択的に起動する。
ここで、図2を参照しながら、選択起動部45の機能について説明する。図2は、選択起動部45の機能的な構成を示すブロック図である。選択機能部45は、並列度計算部45A、オーバーヘッド計算部45B、並列処理性能判定部45C、及び起動処理部45Dを備えている。
並列度計算部45Aは、並列処理方式の画像処理部50を構築して並列処理方式で画像処理を行う場合において少なくとも2つの画像処理モジュール38が並列に動作する度合いを表す値(以下、並列度)を計算する。より具体的には、並列度は、少なくとも2つの画像処理モジュール38が並列に動作する並列時間を表す値とすることができる。
オーバーヘッド計算部45Bは、逐次処理方式で画像処理が行われるように逐次制御する場合には必要ないが、並列処理方式で画像処理が行われるように並列制御する場合には必要な処理(オーバーヘッド)に要する制御時間を示す値(以下、オーバーヘッド値)を計算する。オーバーヘッドには、例えば排他制御やスレッドの起動制御などが含まれる。詳細は後述する。
なお、並列度やオーバーヘッド値は、必ずしもmsecや、μsec等の一般的な時間の単位で表される数値である必要はなく、その値が時間の長さを示す何らかの数値であればよい。また、本実施の形態では、並列度及びオーバーヘッド値の大小を比較して判定するため、並列度及びオーバーヘッド値の各々は、これらが同じ程度の時間を表す場合にその大きさが等しくなる値となるように計算される。なお、並列度及びオーバーヘッド値の大小を比較せず、各々独立に各々の閾値と比較して判定する場合には、両者が同じ程度の時間を表す場合にその大きさが等しくなる値となるように計算しなくてもよい。
並列処理性能判定部45Cは、並列度とオーバーヘッド値とに基づいて、画像処理部50における並列処理方式による画像処理が、逐次処理方式による画像処理より短い時間で終了するか否かを判定(以下、この判定を並列処理性能判定という)し、該判定結果を出力する。
起動処理部45Dは、並列処理性能判定部45Cから出力された判定結果に基づいて、
並列処理管理部又は逐次処理管理部を選択して起動し、並列処理方式又は逐次処理方式による画像処理が行われるように制御する。
例えば、画像処理部50の画像処理モジュール38が、図12(A)に示すように連結された場合には(なお、図12(A)及び(B)では、バッファモジュール40は図示が省略されている。)、分岐の数が多いため、排他制御も多くなる。排他制御が多くなるとオーバーヘッド値も大きくなる。また、ある画像処理モジュール38(ここでは画像処理モジュール38bと呼称する)において1ライン分の画像処理を実行する際に、当該画像処理モジュール38bの前段の画像処理モジュール38(ここでは画像処理モジュール38aと呼称する)において画像処理された後の画像データが1面分必要である場合には、並列処理方式を採用していたとしても、画像処理モジュール38aで画像データ1面分の処理が終了するまで、画像処理モジュール38bの処理を開始することができず、処理が止まってしまう。こうした場合には、処理の待ち合わせ度(後述)が大きくなって並列に動作する時間が短くなってしまう。
さらにまた、図12(B)に示すように、画像処理部50を構成する各画像処理モジュール38の処理の重さ(各画像処理モジュール38における単位処理データ量のデータに対する処理(単位処理)に要する時間)の各々が軽い(すなわち単位処理に要する時間が短い)場合も、並列で動作する期間が短くなるため、並列処理方式で処理しても並列度が大きくならない。また、この場合、オーバーヘッドによっては、かえって全体の処理時間が長くなる場合もある。
このように、並列処理方式での処理が可能であっても、並列処理方式に向かない画像処理部50や、画像処理モジュール38の組み合わせにより並列処理方式にしても性能が出ない(逐次処理方式に比べて処理時間が短くならない)場合がある。そこで、本実施の形態では、処理内容に基づいて(並列度とオーバーヘッド値とを比較して)、並列処理管理部または逐次処理管理部のいずれかを選択して起動させるようにしている。詳細は後述する。
次に本実施形態の作用を説明する。画像処理プログラム群34が実装されている機器において、何らかの画像処理を行う必要のある状況になると、この状況が特定のアプリケーション32によって検知される。なお、画像処理を行う必要のある状況としては、例えば画像データ供給部22としての画像読取部によって画像を読み取り、画像出力部24としての画像記録部により記録材料に画像として記録するか、画像出力部24としての表示部に画像として表示させるか、画像出力部24としての書込装置により画像データを記録メディアに書き込むか、画像出力部24としての送信部により画像データを送信するか、画像出力部24としての画像記憶部に記憶させるジョブの実行がユーザによって指示された場合、或いは、画像データ供給部22としての受信部によって受信されるか、画像データ供給部22としての画像記憶部に記憶されている画像データに対して、上記の記録材料への記録、表示部への表示、記録メディアへの書き込み、送信、画像記憶部への記憶の何れかを行うジョブの実行がユーザによって指示された場合が挙げられる。また、画像処理を行う必要のある状況は上記に限られるものではなく、例えばユーザからの指示に応じてアプリケーション32が実行可能な処理の名称等を表示部16に一覧表示している状態で、実行対象の処理がユーザによって選択された等の場合であってもよい。
上記のように、何らかの画像処理を行う必要のある状況になったことを検知すると、アプリケーション32は画像処理対象の画像データを供給する画像データ供給部22の種別を認識する(図11のステップ150も参照)。続いてアプリケーション32は、画像処理を行った画像データの出力先としての画像出力部24の種別を認識する(図11のステップ152も参照)。
次にアプリケーション32は、実行すべき画像処理の内容を認識し、実行すべき画像処理を、個々のモジュール生成部44に対応するレベルの画像処理の組み合わせに分解し、実行すべき画像処理を実現するために必要な画像処理の種類及び個々の画像処理の実行順序を判定する(図11のステップ154も参照)。なお、この判定は、例えば上記の画像処理の種類及び個々の画像処理の実行順序を、ユーザが実行を指示可能なジョブの種類と対応付けて予め情報として登録しておき、アプリケーション32は、実行が指示されたジョブの種類に対応する情報を読み出すことによって実現することができる。
次に、アプリケーション32は処理構築部42の選択起動部45を起動する(図11のステップ156も参照)。アプリケーション32によって起動された選択起動部45は、まず、並列度計算部45Aにより並列度を計算する(図11のステップ158も参照)。
ここでは、並列度を示す値を、各画像処理モジュール38の処理の重さ及び処理待ち係数に基づいて、次式により計算する。
並列度=各画像処理モジュール38の処理の重さを示す値の合計×処理待ち係数
本実施の形態において、画像処理モジュール38の「処理の重さ」は、各画像処理モジュール38毎に予め測定した負荷(単位処理に要する時間)を1から5までの5段階評価で表したものとする。数値が大きくなるに従って単位処理に要する時間が長くなる。なお、画像処理モジュール38の処理の重さを、各画像処理モジュール38の単位処理内の掛け算の回数に応じた値としてもよい。掛け算の回数が多いほど、処理の重さが重くなるためである。また、処理の重さを、掛け算及び加算の回数に応じた値としてもよい。処理の重さが重いほど(その値が大きいほど)、複数の画像処理モジュール38が並列に動作する時間が長くなる。なお、各画像処理モジュール38の処理の重さの情報は、予め記憶部20に記憶しておく。
例えば、図13に示す例から処理の重さを示す値の合計を計算すると、各画像処理モジュール38の処理の重さは、画像処理モジュール38の連結順序の上流側から下流側に向かって、1、1、3、1であるため、各画像処理モジュール38の処理の重さを示す値の合計は、1+1+3+1=6となる。
「処理待ち係数」は、各画像処理モジュール38の処理の待ち合わせ度を乗算した値である。また、各画像処理モジュール38の処理の待ち合わせ度は、前段の画像処理モジュール38の処理終了後のデータをどの程度必要とするか、言い換えれば前段の画像処理モジュール38の処理結果をどのくらい待つ必要があるか、を示す値である。ここで、各画像処理モジュール38の処理の待ち合わせ度は、次式により計算される。
各画像処理モジュール38の処理の待ち合わせ度
=1-{単位処理データ量/(処理対象の画像全体の画像データ量×2)}
なお、この処理待ち合わせ度の式で、処理対象の画像全体の画像データ量に2を乗算しているのは、画像処理モジュール38の単位処理データ量が画像1面である場合には、その画像処理モジュール38の位置でその前段の画像処理モジュール38での画像1面に対する処理が終了するまで処理が止まってしまう(その画像処理モジュール38の前段の画像処理モジュール38で処理対象の画像データに対する全処理が終了しないと、処理を開始することができなくなり、その位置においては処理が停止して並列処理にならない)ため、この場合には、並列度を小さくする必要がある。そこで、並列度が小さくなるように、ここでは調整値として2を乗算している。なお、調整値の大きさは、実験などにより経験的に定められる。
ここで、処理待ち係数の計算例を説明する。例えば、図13に示す例では、各画像処理モジュール38の単位処理データ量(図13では、「1回の処理ライン数」としてライン数単位で示した)は、画像処理モジュール38の連結順序の上流側から下流側に向かって、1ライン、100ライン、300ライン、1ラインであり、処理対象の画像全体の画像データ量(ここでは、ライン単位で表した画像全体の高さ)は300ラインである。従って、上流側から1番目の画像処理モジュール38の処理待ち合わせ度は、1−{1/(300×2)}=599/600となり、2番目、3番目、及び4番目の画像処理モジュール38の処理待ち合わせ度は、5/6、1/2、599/600となる。これにより、処理待ち係数は、(599/600)×(5/6)×(1/2)×(599/600)≒0.42となる。
以上から、図13に示す例では、並列度は、6×0.42≒2.5と計算される。
並列度が計算された後は、オーバーヘッド計算部45Bによりオーバーヘッド値が計算される(図11のステップ159も参照)。なお、画像処理モジュール38が増えるほどオーバーヘッドは増える。また、処理の分岐数が多いほど排他制御が増えてオーバーヘッドが増える。そこで、本実施の形態では、直列接続に対して1、並列接続に対して2の係数を設定し、連続する2つの画像処理モジュール38の接続形態に応じた係数を合成したものをオーバーヘッド値として計算する。なお、ここでは、着目する画像処理モジュール38と前段の画像処理モジュール38とが並列接続の関係にあれば、着目する画像処理モジュール38に2の係数を与えることとする。図13に示す例では、各画像処理モジュール38は、全て直列接続なので、1+1+1+1=4のオーバーヘッド値が求められる。
なお、ここでは、並列度の計算の後にオーバーヘッド値の計算を行うようにしたが、逆であってもよいし、これらの計算を並列に行っても良い。
次に、選択起動部45の並列処理性能判定部45Cは、計算された並列度及びオーバーヘッド値に基づいて、並列処理性能判定(画像処理部50における並列処理方式による画像処理が、逐次処理方式による画像処理より短い時間で終了するか否かの判定)を行う(図11のステップ160も参照。)。ここでは、並列度>オーバーヘッド値であれば、画像処理部50における並列処理方式による画像処理が、逐次処理方式による画像処理より短い時間で終了する、と判定し、並列度<オーバーヘッド値であれば、画像処理部50における並列処理方式による画像処理が、逐次処理方式による画像処理より長い時間で終了する、と判定する。なお、並列度=オーバーヘッド値の場合には、並列処理方式と逐次処理方式とで画像処理部50の画像処理に要する時間は等しいと判定する。なお、図13に示した例では、並列度:2.5、オーバーヘッド値:4であるため、並列度<オーバーヘッド値、となる。従って、並列処理方式による画像処理が、逐次処理方式による画像処理より長い時間で終了する、と判定される。並列処理性能判定部45Cは、該判定結果を起動処理部45Dに出力する。
ここで、図14を参照し、他の具体例を挙げて説明する。
図14(A)に示す画像処理部50の並列度及びオーバーヘッド値は、以下のように計算される。
並列度 = (5+5+5+5)×1 = 20
オーバーヘッド値 = 1+1+1+1 = 4
なお、ここでは、処理待ち係数は、(599/600)×(599/600)×(599/600)×(599/600)≒1としている。
この例では、並列度>オーバーヘッド値となるため、並列処理方式による画像処理の方が逐次処理方式に比べて短い時間で終了すると判定される。すなわち、並列処理方式により性能が出ると判定される。
図14(B)に示す画像処理部50の並列度及びオーバーヘッド値は、以下のように計算される。
並列度 = (2+3+3+3+2+3+1+1)×{(5/6)×(5/6)×(5/6)} =10.4
オーバーヘッド値 = 1+2+2+2+1+1+1+1= 11
なお、ここでは、1回の処理ライン数(単位処理データ量)が1ラインの画像処理モジュール38の処理待ち合わせ度を(599/600)≒1として計算している。
この例では、並列度<オーバーヘッド値となるため、並列処理方式による画像処理の方が逐次処理方式に比べて長い時間で終了すると判定される。すなわち、並列処理方式では性能が出ないと判定される。
図14(C)に示す画像処理部50の並列度及びオーバーヘッド値は、以下のように計算される。
並列度 = (2+3+3+5+3)×1/2=9.5
オーバーヘッド係数 = 1+2+2+1+1= 7
なお、ここでも、1回の処理ライン数(単位処理データ量)が1ラインの画像処理モジュール38の処理待ち合わせ度を(599/600)≒1として計算している。
この例では、並列度>オーバーヘッド値となるため、並列処理方式による画像処理の方が逐次処理方式に比べて短い時間で終了すると判定される。すなわち、並列処理方式により性能が出ると判定される。
起動処理部45Dは、並列処理性能判定部45Cから入力された判定結果に応じて、起動すべき処理管理部を選択し、起動する(図11のステップ166も参照)。ここでは、上記判定結果が、並列処理方式による画像処理が、逐次処理方式による画像処理より短い長い時間で終了する、という判定結果であった場合には、並列処理方式での画像処理が行われるように、並列処理管理部46を選択して起動する。また、上記判定結果が、並列処理方式による画像処理が、逐次処理方式による画像処理より長い時間で終了する、という判定結果であった場合には、逐次処理方式での画像処理が行われるように、逐次処理管理部46を選択して起動する。なお、並列処理方式と逐次処理方式とで画像処理部50の画像処理に要する時間は等しいとの判定結果であった場合には、どちらを選択して起動してもよい。従って、予めどちらを選択するかを設定しておき、該設定に応じて選択して起動する。
起動された処理管理部46は稼働状態となり、外部から何らかの要求や指示(後述するバッファモジュール生成要求や画像処理実行指示)が入力される迄待機する。
一方、アプリケーション32は選択起動部45の起動を完了すると、上記ステップ150で認識した画像データ供給元の種別がバッファ領域(メモリ14の一部領域)であった場合、アプリケーション32は、画像データ供給部22として指定されたバッファ領域を稼働中の処理管理部46へ通知し、画像データ供給部22として機能するバッファモジュール40の生成を処理管理部46へ要求する(図11では図示省略)。この場合、処理管理部46はバッファ制御部40BのプログラムをCPU12が実行可能なようにメモリ14にロードすると共に、通知されたバッファ領域(画像データ供給部22として指定されたバッファ領域)を既に確保されたバッファ40Aとしてバッファ制御部40Bに認識させるパラメータを設定することで、画像データ供給部22として機能するバッファモジュール40を生成し、アプリケーション32へ応答を返す。なお、稼働中の処理管理部46が並列処理管理部46である場合は、上記のバッファモジュール40として排他制御機能付きのバッファモジュール40が生成され、稼働中の処理管理部46が逐次処理管理部46である場合は、上記のバッファモジュール40として排他制御機能無しのバッファモジュール40が生成される。
また、上記ステップ152で認識した画像データ出力先の種別がバッファ領域(メモリ14の一部領域)であった場合、アプリケーション32は、画像出力部24として指定されたバッファ領域を稼働中の処理管理部46へ通知し、画像出力部24として指定されたバッファ領域を含むバッファモジュール40(画像出力部24として機能するバッファモジュール40)を処理管理部46によって生成させる(図11では図示省略)。このときも、稼働中の処理管理部46が並列処理管理部46であれば、上記のバッファモジュール40として排他制御機能付きのバッファモジュール40が生成され、稼働中の処理管理部46が逐次処理管理部46であれば、上記のバッファモジュール40として排他制御機能無しのバッファモジュール40が生成される。
更にアプリケーション32は、上記で判定した画像処理の種類及び実行順序に基づいて、特定の画像処理に対応するモジュール生成部44を起動し(図11のステップ168も参照)、起動したモジュール生成部44に対し、当該モジュール生成部44によるモジュール群の生成に必要な情報として、前記モジュール群に画像データを入力する入力モジュールを識別するための入力モジュール識別情報、前記モジュール群が画像データを出力する出力モジュールを識別するための出力モジュール識別情報、前記モジュール群に入力される入力画像データの属性を表す入力画像属性情報、実行すべき画像処理のパラメータを通知して対応するモジュール群の生成を指示する(図11のステップ170も参照)。また、必要とされる画像処理が複数種の画像処理を組み合わせた処理である場合、アプリケーション32は、指示したモジュール生成部44からモジュール群の生成完了が通知されると、個々の画像処理に対応する他のモジュール生成部44を起動してモジュール群の生成に必要な情報を通知する処理(図11のステップ168,170)を個々の画像処理の実行順序の昇順に繰り返す。
なお、上記の入力モジュールは、実行順序が1番目のモジュール群については画像データ供給部22が入力モジュールとなり、実行順序が2番目以降のモジュール群については前段のモジュール群の最終モジュール(通常はバッファモジュール40)が入力モジュールとなる。また、上記の出力モジュールについては、実行順序が最後のモジュール群では画像出力部24が出力モジュールとなるので、画像出力部24が出力モジュールとして指定されるが、その他のモジュール群では出力モジュールは未確定のためにアプリケーション32による指定は行われず、必要な場合はモジュール生成部44によって生成・設定される。また、入力画像属性や画像処理のパラメータについては、例えばユーザが実行を指示可能なジョブの種類と対応付けて予め情報として登録しておき、実行が指示されたジョブの種類に対応する情報を読み出すことでアプリケーション32が認識するようにしてもよいし、ユーザに指定させるようにしてもよい。
一方、モジュール生成部44は、アプリケーション32によって起動されるとモジュール生成処理(図11のステップ172も参照)を行う。モジュール生成処理では、まず生成対象の画像処理モジュール38に入力される入力画像データの属性を表す入力画像属性情報を取得する。なお、入力画像データの属性を取得する処理は、生成対象の画像処理モジュール38の前段にバッファモジュール40が存在している場合、当該バッファモジュール40に画像データの書き込みを行う更に前段の画像処理モジュール38から出力画像データの属性を取得することによって実現できる。
そして、取得した情報が表す入力画像データの属性に基づいて、生成対象の画像処理モジュール38の生成が必要か否か判定する。例えばモジュール生成部44が色変換処理を行うモジュール群を生成するモジュール生成部であり、画像処理のパラメータにより出力画像データの色空間としてCMY色空間がアプリケーション32から指定された場合、取得した入力画像属性情報に基づいて入力画像データがRGB色空間のデータであることが判明したときには、色空間処理を行う画像処理モジュール38としてRGB→CMYの色空間変換を行う画像処理モジュール38を生成する必要があるが、入力画像データがCMY色空間のデータであったときには、入力画像データの属性と出力画像データの属性が色空間に関して一致しているので、色空間変換処理を行う画像処理モジュール38は生成不要と判断する。
生成対象の画像処理モジュール38の生成が必要と判断した場合には、生成対象の画像処理モジュール38の後段にバッファモジュール40が必要が否かを判定する。この判定は、画像処理モジュールの後段が出力モジュール(画像出力部24)である場合(例えば図3(A)〜(C)に示す画像処理部50における最後段の画像処理モジュール38を参照)や、例として図3(B)に示す画像処理部50においてスキュー角検知処理を行う画像処理モジュール38のように、画像処理モジュールが、画像データに対して解析等の画像処理を行いその結果を他の画像処理モジュール38へ出力するモジュールである場合は否定されるが、上記以外の場合は判定が肯定され、稼働中の処理管理部46に対して画像処理モジュール38の後段に連結するバッファモジュール40を生成を要求する。
バッファモジュール40の生成が要求されると、処理管理部46はバッファ制御部40BのプログラムをCPU12が実行可能なようにメモリ14にロードすることで、バッファモジュール40を生成し(図11のステップ172も参照)、モジュール生成部44へ応答を返す。なお、稼働中の処理管理部46が並列処理管理部46であれば、上記のバッファモジュール40として排他制御機能付きのバッファモジュール40が生成され、稼働中の処理管理部46が逐次処理管理部46であれば、上記のバッファモジュール40として排他制御機能無しのバッファモジュール40が生成される。
続いてモジュール生成部44は、前段のモジュール(例えばバッファモジュール40)の情報、後段のバッファモジュール40の情報(後段にバッファモジュール40を生成した画像処理モジュール38のみ)、画像処理モジュール38に入力される入力画像データの属性、処理パラメータを与えて、モジュールライブラリ36に登録されており、画像処理モジュール38として利用可能な複数の候補モジュールの中から、先に取得した入力画像データの属性、及び、画像処理モジュール38で実行すべき処理パラメータに合致する画像処理モジュール38を選択し、選択した画像処理モジュール38のプログラムをCPU12が実行可能なようにメモリ14にロードすると共に、当該画像処理モジュール38の前段及び後段のモジュールを当該画像処理モジュール38の制御部38Bに認識させるパラメータを設定することで、画像処理モジュール38を生成する。
例えばモジュール生成部44が色変換処理を行うモジュール群を生成するモジュール生成部であり、処理パラメータにより出力画像データの色空間としてCMY色空間が指定され、更に入力画像データがRGB色空間のデータであった場合には、モジュールライブラリ36に登録されている各種の色空間処理を行う複数種の画像処理モジュール38の中から、RGB→CMYの色空間変換を行う画像処理モジュール38が選択・生成される。また、画像処理モジュールが拡大・縮小処理を行う画像処理モジュール38であり、指定された拡大縮小率が50%以外であれば、入力された画像データに対して指定された拡大・縮小率で拡大・縮小処理を行う画像処理モジュール38が選択・生成され、指定された拡大縮小率が50%であれば、拡大縮小率50%に特化した拡大縮小処理、すなわち入力された画像データを1画素おきに間引くことで50%に縮小する縮小処理を行う画像処理モジュール38が選択・生成される。
なお、画像処理モジュール38の選択は上記に限られるものではなく、例えば画像処理エンジン38Aによる画像処理における単位処理データ量が異なる画像処理モジュール38をモジュールライブラリ36に複数登録しておき、画像処理部50へ割当可能なメモリ領域のサイズ等の動作環境に応じて、適切な単位処理データ量の画像処理モジュール38を選択する(例えば上記サイズが小さくなるに従って単位処理データ量の小さい画像処理モジュール38を選択する等)ようにしてもよいし、アプリケーション32或いはユーザに選択させるようにしてもよい。
画像処理モジュール38の生成が完了すると、後段のバッファモジュール40のIDと生成した画像処理モジュール38のIDの組を稼働中の処理管理部46に通知する。このIDは、個々のモジュールを一意に判別できる情報であればよく、例えば個々のモジュールの生成順に付与した番号や、バッファモジュール40や画像処理モジュール38のオブジェクトのメモリ上でのアドレス等でも良い。またモジュール生成部44が、複数種の画像処理モジュール38によって実現される画像処理(例えばスキュー角検知処理を行う画像処理モジュール38と画像回転処理を行う画像処理モジュール38によって実現されるスキュー補正処理)を行うモジュール群を生成する場合には、上記処理が繰り返されて2個以上の画像処理モジュール38を含むモジュール群が生成される。アプリケーション32によって順次起動された個々のモジュール生成部44により、以上のモジュール生成処理が順次行われることで、例として図3(A)〜(C)に示すように、必要とされる画像処理を行う画像処理部50が構築される。
一方、アプリケーション32は、順次起動したモジュール生成部44によって前述のモジュール生成処理が順次行われることで、必要とされる画像処理を行う画像処理部50の構築が完了すると、稼働中の処理管理部46に対して画像処理部50による画像処理の実行を指示する(図11のステップ174も参照)。処理管理部46は、アプリケーション32から画像処理の実行が指示されると、メモリ14にロードした画像処理部50の各モジュールのプログラムを、オペレーティングシステム30を通じてスレッドとしてCPU12に実行させる。ここで、稼働中の処理管理部46が並列処理管理部である場合、処理管理部46は、画像処理部50の個々の画像処理モジュール38で互いに並列に画像処理を行わせるために、画像処理部50を構成する個々のモジュールのプログラムを互いに独立したスレッドとしてCPU12に実行させる。また、稼働中の処理管理部46が逐次処理管理部である場合、処理管理部46は、画像処理部50を構成する個々のモジュールのプログラムを単一のスレッドとしてCPU12に実行させる。なお、スレッドに代えて、プロセス又はオブジェクトとしてCPU12に実行させるようにしてもよい。
なお、前述した選択起動部46の動作説明において、複数の画像処理モジュール38が並列接続された場合に行われる排他制御がオーバーヘッドになると説明したが、排他制御以外にスレッドの起動制御もまたオーバーヘッドになる。すなわち、逐次処理方式では、前段の画像処理モジュール38から後段の画像処理モジュール38にその接続順に1つずつ起動させていけばよいが、並列処理方式では、並列動作をさせるために、次はどのスレッドを起動させるか等の判断処理が必要となる。これは逐次処理方式では必要のない処理であり、オーバーヘッドとなる。従って、上記例ではオーバーヘッド値を接続状態から計算して求めたが、このようにスレッドの起動制御も考慮する場合には、例えば、画像処理部50を構成する画像処理モジュール38の数等を、オーバーヘッド値を求めるパラメータとして用いてもよい。例えば、画像処理モジュール38の数が多くなるほどオーバーヘッド値が大きくなるようにしてもよい。
画像処理モジュール38のプログラムがスレッドとして実行されると、個々の画像処理モジュール38の制御部38Bは自モジュールの初期化を行う。画像処理モジュール38の初期化では、まずモジュール生成部44によって設定されたパラメータに基づいて自モジュールの前段のモジュールを判定する。自モジュールの前段にモジュールが存在していない場合には何ら処理を行わないが、前段のモジュールがバッファモジュール40以外、例えば画像データ供給部22や特定のファイル等である場合には、必要に応じてその初期化処理を行う。また、自モジュールの前段にバッファモジュール40が存在している場合には、前段のバッファモジュール40からの1回の画像データの読み出しによって取得する画像データのデータ量(単位読出データ量)を認識する。
この単位読出データ量は、自モジュールの前段のバッファモジュール40の数が1個であれば1個だけであるが、例えば図3(C)に示す画像処理部50において画像合成処理を行う画像処理モジュール38のように、前段のバッファモジュール40の数が複数で、複数のバッファモジュール40から各々取得した画像データを用いて画像処理エンジン38Aが画像処理を行う等の場合、前段の個々のバッファモジュール40に対応する単位読出データ量は、自モジュールの画像処理エンジン38Aが行う画像処理の種類や内容、前段のバッファモジュール40の数等に応じて定まる。そして、認識した単位読出データ量を、前段に存在している全てのバッファモジュール40へ通知することで、前段に存在している全てのバッファモジュール40に単位読出データ量を設定する(図4(A)の(1)も参照)。
次に、自モジュールの後段のモジュールを判定する。自モジュールの後段のモジュールがバッファモジュール40以外、例えば画像出力部24や特定のファイル等の場合には、必要に応じてその初期化処理(例えば後段のモジュールが画像出力部24であれば、単位書込データ量に相当するデータ量ずつ画像データを出力することを通知する処理等)を行う。また、後段のモジュールがバッファモジュール40であれば、1回の画像データの書き込みにおける画像データのデータ量(単位書込データ量)を認識し、後段のバッファモジュールに当該単位書込データ量を設定(図4(A)の(2)も参照)する。そして、当該画像処理モジュール38の初期化の完了を処理管理部46通知する。
また、バッファモジュール40(のバッファ制御部40B)のプログラムがスレッドとして実行されると、個々のバッファモジュール40のバッファ制御部40Bは自モジュールの初期化を行う。バッファモジュール40の初期化では、まず自モジュールの前段の画像処理モジュール38から単位書込データ量が通知されるか又は自モジュールの後段の画像処理モジュール38から単位読出データ量が通知される毎に、通知された単位書込データ量又は単位読出データ量を記憶する(図4(B)の(1),(2)も参照)。
自モジュールと連結されている全ての画像処理モジュール38から単位書込データ量又は単位読出データ量が通知されると、自モジュールと連結されている個々の画像処理モジュール38によって各々設定された単位書込データ量及び単位読出データ量に基づいて、自モジュールのバッファ40Aの管理単位である単位バッファ領域のサイズを決定し、決定した単位バッファ領域のサイズを記憶する。単位バッファ領域のサイズとしては、自モジュールに設定された単位書込データ量及び単位読出データ量のうちの最大値が好適であるが、単位書込データ量を設定してもよいし、単位読出データ量(自モジュールの後段に複数の画像処理モジュール38が連結されている場合は、個々の画像処理モジュール38によって各々設定された単位読出データ量の最大値)を設定してもよいし、単位書込データ量と単位読出データ量(の最大値)の最小公倍数を設定してもよいし、この最小公倍数が所定値未満であれば最小公倍数を、最小公倍数が所定値以上であれば別の値(例えば上述した単位書込データ量及び単位読出データ量のうちの最大値、単位書込データ量、単位読出データ量(の最大値)の何れか)を設定するようにしてもよい。
また、自モジュールが画像データ供給部22又は画像出力部24として機能するバッファモジュール40であった場合には、自モジュールのバッファ40Aとして用いるメモリ領域が既に存在しているので、先に決定した単位バッファ領域のサイズを、自モジュールのバッファ40Aとして用いる既設のメモリ領域のサイズに変更する。更に、自モジュールの後段の個々の画像処理モジュール38に対応する有効データポインタを各々生成し、生成した有効データポインタを初期化する。この有効データポインタは、自モジュールの前段の画像処理モジュールによって自モジュールのバッファ40Aに書き込まれた画像データのうち、対応する後段の画像処理モジュール38によって読み出されていない画像データ(有効データ)の先頭位置(次の読出開始位置)と末尾位置を各々指し示すポインタであり、初期化時には通常、有効データが存在していないことを意味する特定の情報が設定されるが、自モジュールが画像データ供給部22として機能するバッファモジュール40であれば、自モジュールのバッファ40Aとして用いるメモリ領域には既に画像処理対象の画像データが書き込まれていることがあり、この場合は当該画像データの先頭位置及び末尾位置が後段の個々の画像処理モジュール38に対応する有効データポインタに各々設定される。以上の処理によりバッファモジュール40の初期化が完了し、バッファ制御部40Bは初期化の完了を処理管理部46へ通知する。
処理管理部46は、画像処理部50を構成する全てのモジュールから初期化の完了が通知されると、ワークフロー管理部46Aのプログラムを実行するスレッド(又はプロセス又はオブジェクト)を起動し、ワークフロー管理部46Aに対して画像処理部50による画像処理の実行を指示する。ここで、処理管理部ライブラリ47にプログラムが登録されている個々の処理管理部46は、ワークフロー管理部46Aが行う処理が互いに異なっており、稼働中の処理管理部46が並列処理管理部である場合には、起動されたワークフロー管理部46Aにより、例えば図8に示す並列制御処理が行われ、稼働中の処理管理部46が逐次処理管理部である場合には、起動されたワークフロー管理部46Aにより、例えば図10に示すブロック単位逐次制御処理が行われる。これらの処理は、画像処理部50を構成する画像処理モジュール38に処理要求を入力することで、画像処理部50に画像処理を行わせるものであるが、以下では画像処理部50全体の動作説明に先立ち、個々のバッファモジュール40のバッファ制御部40Bによって行われる処理、個々の画像処理モジュール38の制御部38Bによって行われる処理について順に説明する。
本実施形態では、画像処理モジュール38が後段のバッファモジュール40に画像データを書き込む場合には、画像処理モジュール38からバッファモジュール40へ書込要求が入力され、画像処理モジュール38が前段のバッファモジュール40から画像データを読み出す場合には、画像処理モジュール38からバッファモジュール40へ読出要求が入力される。排他制御機能付きのバッファモジュール40に前段の画像処理モジュール38からの書込要求が入力された場合(及び、後述するタイマがタイムアウトした場合)は、以下で説明するデータ書込処理がバッファ制御部40Bによって実行される。
排他制御機能付きのバッファモジュール40のバッファ制御部40Bによって行われるデータ書込処理では、まず自モジュールのバッファ40Aが既にアクセス中か否か判定する。画像処理部50の個々の画像処理モジュール38が並列に画像処理を行う場合、バッファ40Aに対してデータの書き込みと非同期に読み出しも行われるので、バッファ40Aが既にアクセス中の場合は入力された書込要求情報をワークメモリ等に保管し、タイマをスタートさせてデータ書込処理を一旦終了する。なお、以降の処理では、入力された書込要求情報を処理対象の情報とするが、タイマがタイムアウトしてデータ書込処理が起動された場合には、過去に入力されてワークメモリ等に保管している書込要求情報をワークメモリ等から取り出し、取り出した書込要求情報を処理対象の情報として以降の処理を行う。
バッファ40Aがアクセス中でないと判定されると、続いてデータ書込処理では、確保すべきメモリ領域のサイズとして単位書込データ量をリソース管理部46Bに通知し、書込用として用いるメモリ領域(書込用バッファ領域:図5(B)も参照)を稼働中の処理管理部46のリソース管理部46Bを介して取得する。次に、自モジュールのバッファ40Aを構成する保管用の単位バッファ領域の中に、単位書込データ量以上の空き領域が有る単位バッファ領域(単位書込データ量の画像データを書き込み可能な単位バッファ領域)が存在しているか否か判定する。モジュール生成部44によって生成されたバッファモジュール40は、当初はバッファ40Aとして用いるメモリ領域(単位バッファ領域)が確保されておらず、メモリ領域の不足が生ずる度に単位バッファ領域を単位として確保されるので、バッファモジュール40に最初に書込要求が入力されたときにはバッファ40Aとして用いるメモリ領域(単位バッファ領域)が存在しておらず、この判定は否定される。また、後述する処理を経てバッファ40Aとして用いる単位バッファ領域が確保された後も、当該単位バッファ領域への画像データの書込に伴って当該単位バッファ領域内の空き領域が単位書込データ量未満になった場合にも上記判定は否定される。
単位書込データ量以上の空き領域が有る単位バッファ領域(単位書込データ量の画像データを書き込み可能な単位バッファ領域)が存在していないと判定された場合は、確保すべきメモリ領域のサイズ(単位バッファ領域のサイズ)をリソース管理部46Bに通知して、自モジュールのバッファ40Aとして用いるメモリ領域(画像データの保管に用いる単位バッファ領域)をリソース管理部46Bを介して取得する。そして、先に取得した書込用バッファ領域を書込領域として、当該書込領域の先頭アドレスを書込要求元の画像処理モジュール38へ通知すると共に、書込対象の画像データを通知した先頭アドレスから順に書き込むよう要請する。これにより、書込要求元の画像処理モジュール38は、先頭アドレスが通知された書込用バッファ領域に画像データを書き込む(図5(B)も参照)。
例えば単位バッファ領域のサイズが単位書込データ量の整数倍でない場合、バッファ40A(単位バッファ領域)への単位書込データ量の画像データの書込が繰り返されることで、例として図5(A)にも示すように、空き領域有りの単位バッファ領域における空き領域のサイズが単位書込データ量よりも小さい状態が生ずる。この場合、単位書込データ量の画像データが書き込まれる領域が複数の単位バッファ領域に跨ることになるが、本実施形態では、バッファ40Aとして用いるメモリ領域を単位バッファ領域を単位として確保するので、異なるタイミングで確保した単位バッファ領域が実メモリ(メモリ14)上で連続する領域であることは保証されない。これに対して本実施形態では、画像処理モジュール38による画像データの書き込みを、保管用の単位バッファ領域と別に確保した書込用バッファ領域に対して行わせ、図5(C)に示すように、書込用バッファ領域に一旦書き込まれた画像データを保管用の単一又は複数の単位バッファ領域へ複写するので、画像データが書き込まれる領域が複数の単位バッファ領域に跨るか否かに拘わらず、書込要求元の画像処理モジュール38への書込領域の通知は、上記のようにその先頭アドレスを通知するのみで済み、画像処理モジュール38とのインタフェースが簡単になる。
なお、自モジュールがアプリケーション32によって生成されたバッファモジュール40である場合、すなわちバッファ40Aとして用いるメモリ領域が既に確保されている場合には、既に確保されたメモリ領域のアドレスを画像処理モジュール38に書込領域のアドレスとして通知し、上記メモリ領域への画像データの書き込みを行わせる。前段の画像処理モジュール38による書込領域への画像データの書き込みが完了すると、書込用バッファ領域に書き込まれている画像データに属性情報を付加した後に、保管用バッファ領域にそのまま書き込む。なお、空き領域有りの単位バッファ領域における空き領域のサイズが単位書込データ量よりも小さい場合、書込用バッファ領域に書き込まれた画像データは、図5(C)に示すように、保管用の複数の単位バッファ領域へ分けて書き込まれることになる。
そして、自モジュールの後段の個々の画像処理モジュール38に対応する有効データポインタのうち有効データの末尾位置を表すポインタを、該ポインタが指し示す有効データの末尾位置が単位書込データ量分だけ後へ移動するように更新する(図5(C)も参照)と共に、先に書込用バッファ領域として確保したメモリ領域をリソース管理部46Bによって解放させ、データ書込処理を一旦終了する。なお、書込用バッファ領域はバッファモジュール40の初期化時に確保し、バッファモジュール40の消去時に解放するように構成してもよい。
上記で説明したデータ書込処理は、並列処理用の画像処理部50に組み込まれた排他制御機能付きのバッファモジュール40のバッファ制御部40Bによって行われるデータ書込処理であるが、逐次処理用の画像処理部50に組み込まれた排他制御機能無しのバッファモジュール40のバッファ制御部40Bによって行われるデータ書込処理は、排他制御に相当する処理、すなわちバッファ40Aが既にアクセス中か否かを判定し、アクセス中であれば書込要求情報を保管すると共にタイマをスタートさせ、タイマがタイムアウトするとバッファ40Aがアクセス中か否かを再度判定する処理を行わない点以外は上記で説明したデータ書込処理と同一である。排他制御機能無しのバッファモジュール40におけるデータ書込処理は、逐次処理では不要な排他制御に相当する処理が省略されていることで、処理効率を向上させることができる。
続いて、排他制御機能付きのバッファモジュール40に後段の画像処理モジュール38から読出要求が入力された場合(及び、後述するタイマがタイムアウトした場合)に、バッファモジュール40のバッファ制御部40Bによって実行されるデータ読出処理について説明する。
排他制御機能付きのバッファモジュール40のバッファ制御部40Bによって行われるデータ読出処理では、まず今回のデータ読出処理の起動要因が、後段の画像処理モジュールからの読出要求の入力による起動か否か判定し、判定が肯定された場合は後段の画像処理モジュールから入力された読出要求情報を読出用の待ち行列の末尾に登録する。次に、自モジュールのバッファ40Aが既にアクセス中か否か判定する。バッファ40Aがアクセス中であれば、読出用の待ち行列に読出要求情報が登録されているか否か判定し、読出要求情報が未登録であればそのままデータ読出処理を終了し、読出要求情報が登録されていればタイマをスタートさせた後にデータ読出処理を終了する。このタイマがタイムアウトするとデータ読出処理が再度起動され、読出用の待ち行列に登録されている未処理の読出要求(情報)が再度取り出され、当該読出要求に応じた処理が行われる。
データ読出処理及び前述のデータ書込処理における排他制御により、単一のバッファモジュール40に複数の要求が同時又は略同時に入力された場合の不都合の発生を回避できるので、コンピュータ10のCPU12が並列処理用の画像処理部50の個々のモジュールに対応するスレッドを並列に実行することが可能となる。
一方、自モジュールのバッファ40Aがアクセス中でなければ、読出用の待ち行列から先頭に登録されている読出要求情報を取り出し、取り出した読出要求情報に含まれる要求元識別情報に基づいて読出要求元の画像処理モジュール38を認識し、読出要求元の画像処理モジュール38によって設定された単位読出データ量を認識すると共に、読出要求元の画像処理モジュール38に対応する有効データポインタに基づいて、読出要求元の画像処理モジュール38に対応する有効データのバッファ40A上での先頭位置及び末尾位置を認識する。次に、認識した有効データの先頭位置及び末尾位置に基づいて、読出要求元の画像処理モジュール38に対応する有効データ(読出要求元の画像処理モジュール38が読出可能な画像データ)が単位読出データ量以上有るか否か判定する。
読出要求元の画像処理モジュール38に対応する有効データが単位読出データ量未満であれば、読出要求元の画像処理モジュール38が読出可能な有効データの末尾が処理対象の画像データの末尾か否か判定する。読出要求元の画像処理モジュール38に対応する有効データがバッファ40Aに単位読出データ量以上記憶されているか、又は、バッファ40Aに記憶されている読出要求元の画像処理モジュール38に対応する有効データが単位読出データ量未満であるものの、当該有効データの末尾が処理対象の画像データの末尾であった場合には、確保すべきメモリ領域のサイズとして読出要求元の画像処理モジュール38に対応する単位読出データ量をリソース管理部46Bに通知すると共に、読出に用いるメモリ領域(読出用バッファ領域:図6(B)も参照)の確保をリソース管理部46Bに要求し、リソース管理部46Bを介して読出用バッファ領域を取得する。
次に、読出対象の有効データをバッファ40Aから単位読出データ量分だけ読み出して読出用バッファ領域に書き込み、読出用バッファ領域の先頭アドレスを読出領域の先頭アドレスとして読出要求元の画像処理モジュール38へ通知すると共に、通知した先頭アドレスから画像データを順に読み出すよう要請する。これにより、読出要求元の画像処理モジュール38は、先頭アドレスが通知された読出領域(読出用バッファ領域)からの画像データの読み出しを行う。なお、読出対象の有効データが処理対象の画像データの末尾に相当するデータであった場合には、画像データの読出要求に際し、読出対象の画像データのサイズと共に、処理対象の画像データの末尾であることも読出要求元の画像処理モジュール38に通知する。また、自モジュールがアプリケーション32によって生成されたバッファモジュール40である場合は、バッファ40Aとして用いているメモリ領域(単位バッファ領域の集合体)は連続領域であるので、読出用バッファ領域の確保、読出対象の画像データの読出用バッファ領域への書き込みを省略し、後段の画像処理モジュール38が単位バッファ領域から直接画像データを読み出すようにしてもよい。
なお、例として図6(A)に示すように、有効データの先頭部分の画像データを記憶している単位バッファ領域に記憶されている有効データのデータ量が単位読出データ量未満であり、読出対象の有効データが複数の単位バッファ領域に跨っている場合には、今回の読出対象の有効データが実メモリ(メモリ14)上で連続する領域に記憶されているとは限らないが、上記のデータ読出処理では、図6(B),(C)に示すように、このような場合にも読出対象の画像データを読出用バッファ領域に一旦書き込んだ後に該読出用バッファ領域から画像データを読み出させるので、読出対象の画像データが複数の単位バッファ領域に跨って記憶されているか否かに拘わらず、読出要求元の画像処理モジュール38への読出領域の通知は、上記のようにその先頭アドレスを通知するのみで済み、画像処理モジュール38とのインタフェースが簡単になる。
読出要求元の画像処理モジュール38による読出領域からの画像データの読み出し完了が通知されると、読出用バッファ領域として確保したメモリ領域の先頭アドレス及びサイズをリソース管理部46Bへ通知して、当該メモリ領域をリソース管理部46Bによって解放させる。この読出用バッファ領域についても、バッファモジュール40の初期化時に確保しておき、バッファモジュール40が消去される時に解放するよう構成してもよい。また、読出要求元の画像処理モジュール38に対応する有効データポインタのうち有効データの先頭位置を表すポインタを、該ポインタが指し示す有効データの先頭位置を単位読出データ量分だけ後へ移動させることで更新する(図6(C)も参照)。
次に、後段の個々の画像処理モジュール38に対応する有効データポインタを各々参照し、先のポインタ更新により、バッファ40Aを構成する単位バッファ領域の中に、記憶している画像データの後段の各画像処理モジュール38による読み出しが全て完了した単位バッファ領域、すなわち有効データを記憶していない単位バッファ領域が出現したか否か判定する。判定が否定された場合は、前述した読出用の待ち行列のチェック処理(読出用の待ち行列に読出要求情報が登録されているか否かの判定)を経てデータ読出処理を終了するが、有効データを記憶していない単位バッファ領域が出現した場合は、当該単位バッファ領域をリソース管理部46Bによって解放させた後に読出用の待ち行列のチェック処理を経てデータ読出処理を終了する。
一方、バッファ40Aに記憶されており読出要求元の画像処理モジュール38が読出可能な有効データのデータ量が単位読出データ量未満であり、かつ読出可能な有効データの末尾が処理対象の画像データの末尾でない場合(図4(B)の(4)で読出可能な有効データ無が検知された場合)には、新たな画像データを要求するデータ要求をワークフロー管理部46Aへ出力し(図4(B)の(5)も参照)、読出用の待ち行列から取り出した読出要求情報を元の待ち行列(の先頭又は末尾)に再度登録した後に、読出用の待ち行列のチェック処理を経てデータ読出処理を終了する。この場合、ワークフロー管理部46Aにより、自モジュールの前段の画像処理モジュール38に処理要求が入力されることになる。これにより、読出可能な有効データのデータ量が単位読出データ量以上になるか、読出可能な有効データの末尾が処理対象の画像データの末尾であることが検知される迄の間、対応する読出要求情報は読出用の待ち行列に保存されると共に定期的に取り出されて要求された処理の実行が繰り返し試行されることになる。
詳細は後述するが、ワークフロー管理部46Aはバッファモジュール40からデータ要求が入力されると、データ要求元のバッファモジュール40の前段の画像処理モジュール38に処理要求を入力する(図4(B)の(6)も参照)。この処理要求の入力をトリガとして前段の画像処理モジュール38の制御部38Bで行われる処理により、前段の画像処理モジュール38がバッファモジュール40へ画像データを書込可能な状態になると、前段の画像処理モジュール38から書込要求が入力されることで前述したデータ書込処理が行われ、前段の画像処理モジュール38からバッファモジュール40のバッファ40Aに画像データが書き込まれる(図4(B)の(7),(8)も参照)。これにより、後段の画像処理モジュール38によるバッファ40Aからの画像データの読出が行われることになる(図4(B)の(9)も参照)。
なお、上記で説明したデータ読出処理は、並列処理用の画像処理部50に組み込まれた排他制御機能付きのバッファモジュール40のバッファ制御部40Bによって行われるデータ読出処理であるが、逐次処理用の画像処理部50に組み込まれた排他制御機能無しのバッファモジュール40のバッファ制御部40Bによって行われるデータ読出処理は、排他制御に相当する処理、すなわちバッファ40Aが既にアクセス中か否かを判定し、アクセス中でかつ待ち行列に読出要求情報が登録されている場合はタイマをスタートさせ、タイマがタイムアウトするとバッファ40Aがアクセス中か否かを再度判定すると共に、単一の読出要求に対する処理が終了した後に待ち行列に読出要求情報が残っているかをチェックする処理を行わない点以外は上記で説明したデータ読出処理と同一である。排他制御機能無しのバッファモジュール40におけるデータ読出処理は、逐次処理では不要な排他制御に相当する処理が省略されていることで、処理効率を向上させることができる。
続いて、画像処理部50を構成する個々の画像処理モジュール38に対してワークフロー管理部46Aから処理要求が入力される毎に、個々の画像処理モジュール38の制御部38Bによって各々行われる画像処理モジュール制御処理(図7)を説明する。なお、画像処理モジュール38の構成については、画像処理部50が並列処理用か逐次処理用かに拘わらず同一であり、以下では画像処理部50が並列処理用か逐次処理用かを区別することなく、画像処理モジュール制御処理を説明する。
画像処理モジュール制御処理では、まずステップ219において、自モジュールの画像処理エンジン38Aが行う画像処理の種類や内容等に基づき、自モジュールが使用するメモリのサイズ及び自モジュールが使用する他のリソースの有無を認識する。なお、画像処理モジュール38が使用するメモリは、画像処理エンジン38Aが画像処理を行うために必要なメモリが主であるが、前段のモジュールが画像データ供給部22である場合や後段のモジュールが画像出力部24である場合には、前段又は後段のモジュールとの画像データの送受に際して画像データを一時記憶するためのバッファ用のメモリが必要となることもある。また、処理パラメータにテーブル等の情報が含まれている場合には、それを保持するためのメモリ領域が必要となることもある。そして、認識したサイズのメモリ領域の確保をリソース管理部46Bへ要求し、リソース管理部46Bによって確保されたメモリ領域をリソース管理部46Bから取得する。また、自モジュール(の画像処理エンジン38A)がメモリ以外の他のリソースを必要としていると認識した場合には、上記他のリソースの確保をリソース管理部46Bへ要求し、上記他のリソースをリソース管理部46Bから取得する。
次のステップ220では、自モジュールの前段にモジュール(バッファモジュール40や画像データ供給部22、画像処理モジュール38等)が存在している場合に、当該前段のモジュールに対してデータ(画像データ又は解析等の画像処理の処理結果)を要求する。次のステップ222では前段のモジュールからデータが取得可能であるかを判定し、ステップ222の判定が否定された場合はステップ224で全体処理終了が通知されたか否かを判定する。ステップ224の判定が否定された場合はステップ222に戻り、前段のモジュールからデータを取得可能となる迄ステップ222,224を繰り返す。ステップ222の判定が肯定された場合には、ステップ226で前段のモジュールからデータを取得し、取得したデータをステップ219で取得したメモリ領域のうちデータの一時保管用のメモリ領域に書き込むデータ取得処理を行う。
ここで、自モジュールの前段のモジュールがバッファモジュール40である場合には、先のステップ220でデータを要求すると(読出要求)、読出可能な有効データがバッファモジュール40のバッファ40Aに単位読出データ量以上記憶されているか、読出可能な有効データの末尾が処理対象の画像データの末尾に一致している状態であれば直ちに、当該状態でなければ、当該バッファモジュール40の前段の画像処理モジュール38が当該バッファモジュール40のバッファ40Aに画像データを書き込んだことに伴って前記状態へ変化した後に、バッファモジュール40から読出領域の先頭アドレスが通知されて画像データの読出が要請される。これにより、ステップ222の判定が肯定されてステップ226へ移行し、前段のバッファモジュール40より先頭アドレスが通知された読出領域から単位読出データ量(又はそれ未満のデータ量)の画像データを読み出し、一時保管用のメモリ領域に書き込むデータ取得処理を行う(図3(A)の(3)も参照)。
また、自モジュールの前段のモジュールが画像データ供給部22であれば、先のステップ220でデータ要求を出力すると画像データを取得可能な状態であることが前段の画像データ供給部22から直ちに通知されることで、ステップ222の判定が肯定されてステップ226へ移行し、前段の画像データ供給部22から単位読出データ量の画像データを取得し、一時保管用のメモリ領域に書き込む画像データ取得処理を行う。また、自モジュールの前段のモジュールが画像処理モジュール38であれば、先のステップ220でデータ要求(処理要求)を出力すると、前段の画像処理モジュール38が画像処理を実行可能な状態であれば書込要求が入力されることでデータ(画像処理結果)を取得可能な状態であることが通知されるので、ステップ222の判定が肯定されてステップ226へ移行し、前段の画像処理モジュール38によってデータを書き込ませる一時保管用のメモリ領域のアドレスを通知して書込を要請することで、前段の画像処理モジュール38から出力されるデータを一時保管用のメモリ領域に書き込ませるデータ取得処理を行う。
次のステップ228では、自モジュールの前段に複数のモジュールが連結されているか否か判定する。判定が否定された場合には何ら処理を行うことなくステップ232へ移行するが、判定が肯定された場合はステップ230へ移行し、前段に連結されている全てのモジュールからデータを取得したか否か判定する。ステップ230の判定が否定された場合はステップ220に戻り、ステップ230の判定が肯定される迄ステップ220〜ステップ230を繰り返す。前段のモジュールから取得すべきデータが全て揃うと、ステップ228の判定が否定されるかステップ230の判定が肯定されてステップ232へ移行する。
次のステップ232では自モジュールの後段のモジュールに対してデータ出力用の領域を要求し、ステップ232でデータ出力領域が取得できる迄(データ出力領域の先頭アドレスが通知される迄)繰り返し判定を行う。なお、後段のモジュールがバッファモジュール40であれば、上記のデータ出力用領域の要求は当該バッファモジュール40に対して書込要求を出力することによって成される。データ出力領域(後段のモジュールがバッファモジュール40であれば当該バッファモジュール40から先頭アドレスが通知された書込領域)が取得できたら(図3(A)の(4)も参照)、次のステップ236において、先のデータ取得処理で取得したデータ、後段のモジュールから取得したデータ出力領域(の先頭アドレス)、先のステップ219で取得したメモリ領域のうち画像処理エンジンによる画像処理用のメモリ領域(の先頭アドレス及びサイズ)を画像処理エンジン38Aに入力し、入力したデータに対し画像処理用のメモリ領域を使用して予め定められた画像処理を行わせる(図3(A)の(5)も参照)と共に、処理後のデータをデータ出力領域に書き込ませる(図3(A)の(6)も参照)。画像処理エンジン38Aへの単位読出データ量のデータの入力が完了し、画像処理エンジン38Aから出力されたデータがデータ出力領域に全て書き込まれると、次のステップ238で出力が完了したことを後段のモジュールに通知する。
上記のステップ220〜ステップ238により画像処理モジュール38における単位処理データ量のデータに対する処理(単位処理)が完了するが、ワークフロー管理部46Aから画像処理モジュール38に入力される処理要求では、ワークフロー管理部46Aによって単位処理の実行回数が指定されることがある。このためステップ240では、単位処理の実行回数が、入力された処理要求によって指示された実行回数に達したか否か判定する。指示された単位処理の実行回数が1回の場合、この判定は無条件に肯定されるが、指示された単位処理の実行回数が2回以上の場合はステップ220に戻り、ステップ240の判定が肯定される迄ステップ220〜ステップ240を繰り返す。ステップ240の判定が肯定されるとステップ242へ移行し、ワークフロー管理部46Aへ処理完了通知を出力することで、入力された処理要求に対応する処理が完了したことをワークフロー管理部46Aへ通知し、画像処理モジュール制御処理を終了する。
また、ワークフロー管理部46Aから処理要求が入力される毎に上述した処理が繰り返されることで処理対象の画像データを末尾まで処理すると、前段のモジュールから処理対象の画像データの終了が通知されることで、ステップ224の判定が肯定されてステップ244へ移行し、処理対象の画像データ(なお、処理対象の画像データは1頁分の画像データであることが多いが、複数頁分の画像データであってもよい)に対する処理が終了したことを意味する全体処理終了通知をワークフロー管理部46A及び後段のモジュールへ各々出力する。また、次のステップ246では取得していた全てのリソースの解放を要求して自モジュールを消去する処理を行い、画像処理モジュール制御処理を終了する。
一方、稼働中の処理管理部46が並列処理管理部である場合、ワークフロー管理部46Aは、画像処理の実行が指示されると、図8(A)に示す並列制御処理1を行う。先にも述べたように、ワークフロー管理部46Aによる画像処理部50の個々の画像処理モジュール38への処理要求の入力では、単位処理の実行回数を指定可能とされているが、並列制御処理1のステップ500では、1回の処理要求で指定する単位処理の実行回数を個々の画像処理モジュール38毎に決定する。この処理要求1回当りの単位処理の実行回数は、例えば処理対象の画像データ全体を処理する間の個々の画像処理モジュール38への処理要求の入力回数が平均化されるように定めることができるが、他の基準に従って定めてもよい。そして次のステップ504において、画像処理部50のうち最後段の画像処理モジュール38に処理要求を入力し(図9の(1)も参照)、並列制御処理1を終了する。
ここで、図9に示す画像処理部50において、ワークフロー管理部46Aから最後段の画像処理モジュール384に処理要求が入力されると、画像処理モジュール384の制御部38Bは前段のバッファモジュール403に読出要求を入力する(図9の(2)参照)。このとき、バッファモジュール403のバッファ40Aには画像処理モジュール384が読出可能な有効データ(画像データ)が記憶されていないので、バッファモジュール403のバッファ制御部40Bはワークフロー管理部46Aにデータ要求を入力する(図9の(3)参照)。
並列処理管理部のワークフロー管理部46Aは、バッファモジュール40からデータ要求が入力される毎に、図8(B)に示す並列制御処理2を行う。この並列制御処理2では、ステップ510において、データ要求入力元のバッファモジュール40(ここではバッファモジュール403)の前段の画像処理モジュール38(ここでは画像処理モジュール383)を認識し、認識した前段の画像処理モジュール38に処理要求を入力(図9の(4)参照)して処理を終了する。
画像処理モジュール383の制御部38Bは、処理要求が入力されると前段のバッファモジュール402に読出要求を入力し(図9の(5)参照)、バッファモジュール402のバッファ40Aにも読出可能な画像データが記憶されていないので、バッファモジュール402のバッファ制御部40Bはワークフロー管理部46Aにデータ要求を入力する(図9の(6)参照)。ワークフロー管理部46Aは、バッファモジュール402からデータ要求が入力された場合も、前述の並列制御処理2を再度行うことで、その前段の画像処理モジュール382に処理要求を入力し(図9の(7)参照)、画像処理モジュール383の制御部38Bは前段のバッファモジュール401に読出要求を入力する(図9の(8)参照)。また、バッファモジュール401のバッファ40Aにも読出可能な画像データが記憶されていないので、バッファモジュール401のバッファ制御部40Bもワークフロー管理部46Aにデータ要求を入力し(図9の(9)参照)。ワークフロー管理部46Aは、バッファモジュール401からデータ要求が入力された場合も、前述の並列制御処理2を再度行うことで、その前段の画像処理モジュール381に処理要求を入力する(図9の(10)参照)。
ここで、画像処理モジュール381の前段のモジュールは画像データ供給部22であるので、画像処理モジュール381の制御部38Bは、画像データ供給部22にデータ要求を入力することで画像データ供給部22から単位読出データ量の画像データを取得し(図9の(11)参照)、取得した画像データに対して画像処理エンジン38Aが画像処理を行うことで得られた画像データを、後段のバッファモジュール401のバッファ40Aに書き込む(図9の(12)参照)。
また、バッファモジュール401のバッファ制御部40Bは、後段の画像処理モジュール382が読出可能な単位読出データ量以上の有効データが書き込まれると画像処理モジュール382に対して読出を要請し、これに伴い画像処理モジュール382の制御部38Bは、バッファモジュール401のバッファ40Aから単位読出データ量の画像データを読み出し(図9の(13)参照)、取得した画像データに対して画像処理エンジン38Aが画像処理を行うことで得られた画像データを、後段のバッファモジュール402のバッファ40Aに書き込む(図9の(14)参照)。バッファモジュール402のバッファ制御部40Bは、後段の画像処理モジュール383が読出可能な単位読出データ量以上の有効データが書き込まれると画像処理モジュール383へ読出を要請し、画像処理モジュール383の制御部38Bは、バッファモジュール402のバッファ40Aから単位読出データ量の画像データを読み出し(図9の(15)参照)、取得した画像データに対して画像処理エンジン38Aが画像処理を行うことで得られた画像データを、後段のバッファモジュール403のバッファ40Aに書き込む(図9の(16)参照)。
更に、バッファモジュール403のバッファ制御部40Bは、後段の画像処理モジュール384が読出可能な単位読出データ量以上の有効データが書き込まれると画像処理モジュール384に対して読出を要請し、これに伴い画像処理モジュール384の制御部38Bは、バッファモジュール403のバッファ40Aから単位読出データ量の画像データを読み出し(図9の(17)参照)、取得した画像データに対して画像処理エンジン38Aが画像処理を行うことで得られた画像データを、後段のモジュールである画像出力部24へ出力する(図9の(18)参照)。
また、個々の画像処理モジュール38の制御部38Bは、後段のバッファモジュール40のバッファ40Aへの画像データの書き込みを完了すると、ワークフロー管理部46Aへ処理完了通知を入力する。並列処理管理部のワークフロー管理部46Aは、画像処理モジュール38から処理完了通知が入力される毎に、図8(C)に示す並列制御処理3を行う。この並列制御処理3では、ステップ520で処理完了通知元の画像処理モジュール38に処理要求を再度入力して処理を終了する。
このように、並列処理管理部のワークフロー管理部46Aによる並列制御処理では、任意の画像処理モジュール38から処理完了が通知される毎に、処理完了通知元の画像処理モジュール38へ処理要求を再度入力することで、処理対象の画像データが前段側のモジュールから後段側のモジュールへ画像1面分よりも小さいサイズ(ブロック)を単位として順に引き渡されると共に、個々の画像処理モジュール38が互いに並列に画像処理を行う並列処理方式によって処理対象の画像データに対する画像処理が行われることになる。また、画像データ供給部22から供給される画像データが処理対象の画像データの末尾に達すると、個々の画像処理モジュール38からワークフロー管理部46Aへの全体処理終了通知の入力が、前段側の画像処理モジュール38から順次行われる。
並列処理管理部のワークフロー管理部46Aは、画像処理モジュール38から全体処理終了通知が入力される毎に、図8(D)に示す並列制御処理4を行う。この並列制御処理4では、ステップ540において、全体処理終了通知入力元の画像処理モジュール38が最後段の画像処理モジュール38か否か判定する。判定が否定された場合は何ら処理を行うことなく処理を終了するが、処理対象の画像データに対して必要な画像処理が行われた画像データが画像出力部24へ全て出力されることで、最後段の画像処理モジュール38から全体処理終了通知が入力された場合には、ステップ540の判定が肯定されてステップ542へ移行し、アプリケーション32に対して画像処理の完了を通知し(図11のステップ178も参照)、並列制御処理4を終了する。そして、画像処理の完了が通知されたアプリケーション32は、ユーザに対して画像処理の完了を通知する(図11のステップ180も参照)。
次に、稼働中の処理管理部46が逐次処理管理部である場合に、ワークフロー管理部46Aによって行われる処理を説明する。逐次処理管理部のワークフロー管理部46Aは、画像処理の実行が指示されると図10(A)に示すブロック単位逐次制御処理1を行い、バッファモジュール40からデータ要求が入力される毎に図10(B)に示すブロック単位逐次制御処理2を行い、画像処理モジュール38から処理完了通知が入力される毎に図10(C)に示すブロック単位逐次制御処理3を行い、画像処理モジュール38から全体処理終了通知が入力される毎に図10(D)に示すブロック単位逐次制御処理4を行うが、このうちブロック単位逐次制御処理1,2,4については、上記で説明した並列制御処理1,2,4と同一であるので説明を省略し、画像処理モジュール38から処理完了通知が入力される毎に行われるブロック単位逐次制御処理3について説明する。
このブロック単位逐次制御処理3では、まずステップ518において、処理完了通知元の画像処理モジュール38が最後段の画像処理モジュール38か否か判定する。判定が否定された場合は何ら処理を行うことなくブロック単位逐次制御処理3を終了する。また、判定が肯定された場合はステップ520へ移行し、処理完了通知元の画像処理モジュール38に処理要求を再度入力して処理を終了する。
従って、逐次処理管理部のワークフロー管理部46Aによるブロック単位逐次制御処理では、画像処理部50の最後段の画像処理モジュール38に入力された処理要求がより前段の画像処理モジュール38へ遡り、最前段の画像処理モジュール38に到達すると、画像1面分よりも小さいサイズ(ブロック)のデータに対する画像処理が最前段の画像処理モジュール38から逐次行われ(常に何れか1つの画像処理モジュール38でのみ画像処理が行われると共に、画像処理を行っている画像処理モジュール38が逐次切り替わり)、上記データに対する最後段の画像処理モジュール38による画像処理が終了すると、最後段の画像処理モジュール38に処理要求が再度入力されることが繰り返される逐次処理方式によって、処理対象の画像データに対する画像処理が行われることになる。
また、上記のように画像処理部50で並列処理方式又は逐次処理方式で画像処理が行われるようにワークフロー管理部46Aが制御を行っている間、処理管理部46のエラー管理部46Cも動作している。エラー管理部46Cは、画像処理部50の任意の画像処理モジュール38でエラーが発生した場合、エラーが発生した画像処理モジュール38からエラー発生通知が入力される。エラー管理部46Cは、エラー発生通知が入力されると、発生したエラーの種別等のエラー情報を取得し、画像処理プログラム群34がインストールされたコンピュータ10が組み込まれている機器の種別や構成等を表す装置環境情報を記憶部20等から取得し、取得した装置環境情報が表す装置環境に応じたエラー通知方法を判断し、判断したエラー通知方法でエラーの発生を通知するエラー通知処理を行う。
ここで、画像処理部50が逐次処理方式で画像処理を行っている場合には、常に何れか1つの画像処理モジュール38でのみ画像処理が行われるので、複数の画像処理モジュール38からエラー管理部46Cへ同時又はほぼ同時にエラー発生通知が入力されることはなく、また、画像処理部50を構成する個々のモジュールのプログラムが単一のスレッドとして実行されているので、何れかの画像処理モジュール38で重度のエラーが発生して画像処理を停止すると、これに伴って画像処理部50で行っている画像処理全体も停止することになるが、画像処理部50が並列処理方式で画像処理を行っている場合には、個々の画像処理モジュール38で並列に画像処理が行われるので、複数の画像処理モジュール38からエラー管理部46Cへ同時又はほぼ同時にエラー発生通知が入力される可能性があり、また、画像処理部50を構成する個々のモジュールのプログラムが互いに独立したスレッドとして実行されているので、何れかの画像処理モジュール38で重度のエラーが発生して画像処理を停止しても、画像処理部50の他の画像処理モジュール38では画像処理が継続されることになる。
このため、並列処理管理部46のエラー管理部46Cは、複数の画像処理モジュール38から同時又はほぼ同時にエラー発生通知が入力された場合に不都合が生じないように排他制御を行うと共に、何れかの画像処理モジュール38で重度のエラーが発生して画像処理が停止した場合に、画像処理部50の他の画像処理モジュール38へエラーの発生を通知して画像処理の実行を中止させ、画像処理部50の個々のモジュールに相当する全てのスレッドの実行を停止させる処理を行う。これにより、画像処理部50が並列処理方式で画像処理を行っている場合にも、エラー処理を支障なく行うことができる。
このように、並列処理管理部46には並列処理方式に適したエラー処理を行うエラー管理部46Cが設けられていると共に、逐次処理管理部46には逐次処理方式に適したエラー処理を行うエラー管理部46Cが設けられており、選択起動部45が並列処理管理部46と逐次処理管理部46を選択的に起動することに伴い、動作するエラー管理部46Cが自動的に切り替わるので、画像処理部50を並列処理方式で動作させるか逐次処理方式で動作させるかを切り替える際の処理が簡単になる。
また、画像処理部50を逐次並列処理方式で動作させる際のワークフロー管理部46Aの処理についても、図10に示したブロック単位逐次制御処理1〜4に限られるものではなく、例として図15に示す面単位逐次制御処理1,3,4を行うようにしてもよい。図15に示す面単位逐次制御処理では、画像処理の実行が指示されると、図15(A)に示す面単位逐次制御処理1において、まずステップ500で1回の処理要求で指定する単位処理の実行回数を個々の画像処理モジュール38毎に決定し、次のステップ505において、画像処理部50のうち最前段の画像処理モジュール38に処理要求を入力する。また、画像処理モジュール38から処理完了通知が入力される毎に、図15(B)に示す面単位逐次制御処理3において、ステップ520で処理完了通知元の画像処理モジュール38に処理要求を再度入力する。これにより、画像処理部50のうちの最前段の画像処理モジュール38にのみ処理要求が繰り返し入力されることになる。
また、画像処理モジュール38から全体処理終了通知が入力される毎に、図15(C)に示す面単位逐次制御処理4において、まずステップ540で全体処理終了通知入力元の画像処理モジュール38が最後段の画像処理モジュール38か否か判定する。判定が否定された場合はステップ544へ移行し、パイプライン形態又は有向非循環グラフ形態の連結形態における画像処理モジュール38の位置が、全体処理終了通知元の画像処理モジュール38の次段である画像処理モジュール38に処理要求を入力する。これにより、画像処理を実行している画像処理モジュール38が、処理対象の画像データに対する画像処理を終了し、当該画像処理モジュール38から全体処理終了通知が入力された後に、画像処理を実行する画像処理モジュール38が次段の画像処理モジュール38へ切り替わることになり、画像1面分のデータに対する画像処理が最前段の画像処理モジュール38から逐次行われる逐次処理方式によって、処理対象の画像データに対する画像処理が行われる。そして、最後段の画像処理モジュール38から全体処理終了通知が入力され、ステップ540の判定が肯定されると、ステップ542で画像処理の完了がアプリケーション32へ通知される。
また、上記では画像処理部50を並列処理方式で動作させる場合に、画像処理部50の個々のモジュールのプログラムを互いに独立したスレッドとして実行させる態様を説明したが、これに限定されるものではなく、画像処理部50を構成する個々のモジュールのプログラムを、各々複数のモジュールに対応する複数のスレッドとして実行させるようにしてもよい。図16は、4個の画像処理モジュール38と、画像処理モジュール38の間に設けられたバッファモジュール40をパイプライン形態で連結した構成において、最前段及び2段目の画像処理モジュール38とその間に設けられたバッファモジュール40をスレッドAとして実行させると共に、3段目及び最後段の画像処理モジュール38とその間に設けられたバッファモジュール40をスレッドBとしてスレッドAと並列に実行させる例を示しているが、このような場合、逐次動作する最前段の画像処理モジュール38と2段目の画像処理モジュール38の間に設けられたバッファモジュール40、及び、同じく逐次動作する3段目の画像処理モジュール38と最終段の画像処理モジュール38の間に設けられたバッファモジュール40については、排他制御無しのバッファモジュール40とし、並列に動作する2段目の画像処理モジュール38と3段目の画像処理モジュール38の間に設けられたバッファモジュール40については、排他制御有りのバッファモジュール40とすればよい。
また、上記では並列処理管理部及び逐次処理管理部として、各々単一の処理管理部のプログラムが処理管理部ライブラリ47に登録されている態様を説明したが、これに限定されるものではなく、画像処理部50の動作環境等に応じて、複数の並列処理管理部の中から単一の並列処理管理部を選択したり、複数の逐次処理管理部の中から単一の逐次処理管理部を選択するように構成することも可能である。例えばプログラム実行リソース(例えばCPU12等)の数が1なら逐次処理管理部を選択することで画像処理部50で逐次処理方式によって画像処理を行わせ、プログラム実行リソースの数が2以上、かつ画像処理部50を構成する画像処理モジュール38の数未満ならば、画像処理部50で図16に示した並列処理方式(スレッドの数を抑制した並列処理)によって画像処理を行わせる並列処理管理部を選択し、プログラム実行リソースの数が2以上、かつ画像処理部50を構成する画像処理モジュール38の数以上ならば、画像処理部50の個々のモジュールのプログラムを互いに独立したスレッドとして実行させる並列処理方式で画像処理部50における画像処理を行わせる並列処理管理部を選択するようにしてもよい。
また、画像処理部50の個々のモジュールのプログラムを互いに独立したスレッドとして実行させる並列処理方式は、プログラム実行リソースの数が画像処理モジュールの数に近ければ有効に機能する可能性が高いので、「プログラム実行リソースの数/画像処理モジュールの数」が閾値(例えば0.8等)以上であれば、画像処理部50の個々のモジュールのプログラムを互いに独立したスレッドとして実行させる並列処理方式で画像処理部50における画像処理を行わせる並列処理管理部を選択するようにしてもよい。
また、選択起動部45の機能構成は、図2に示した機能構成に限られるものではなく、例えば、図17に示すように構成してもよい。図17に示した選択起動部45は、図2に示した選択起動部45と同一名称の構成要素を有しているが、並列処理性能判定部45Cの判定結果の出力先は、起動処理部45Dではなく、表示部16や外部の表示装置等に判定結果を表示させるように表示制御を行うアプリケーションやOS等に出力されるように構成されている。また、起動処理部45Dは、例えば操作部18を介してユーザから並列処理方式の処理管理部を起動するのか逐次処理方式の処理管理部を起動するのかを示す起動指示が入力された場合に、該起動指示に応じて処理管理部を選択して起動するよう構成されている。
図18は、図17に示す起動処理部45により処理管理部を起動させる場合のシーケンス図の一例である。図18において、図11と同様の処理を行うステップには同一の符号を付して説明を省略する。ステップ150〜ステップ160までは、図11を用いて説明したように動作する。ステップ160で並列処理性能判定部45Cが並列処理性能判定を行った後は、並列処理性能判定部45Cは、その判定結果を表示制御を行うアプリケーション(或いはOS)に出力する(図18のステップ161も参照。)。判定結果を受け取ったアプリケーションは、表示部16等に判定結果を表示する。その後は、ユーザからの起動指示入力待ちとなる(図18のステップ162も参照。)。操作部18を介してユーザから起動指示が入力されると、アプリケーションは起動指示を受け付け(図18のステップ163も参照。)、該起動指示を選択起動部45の起動処理部45Dに入力する(図18のステップ164も参照。)。起動処理部45Dは、入力された起動指示に応じて並列処理方式又は逐次処理方式の処理管理部を選択して起動する(図18のステップ165も参照。)。
また、図17の構成において起動処理部45Dが設けられない装置に本発明を適用してもよい。すなわち、並列度計算部45A、オーバーヘッド部計算部45B、及び並列処理性能判定部45Cを有する装置であって、データ処理部(画像処理部50)を構築する装置とは独立に設けられ、並列処理性能判定を行い、該判定結果を外部に出力する装置としてもよい。
また、上記実施の形態では、並列度を計算するパラメータとして、処理の重さ、処理の待ち合わせ度を用いたが、これに限定されるものではない。例えば、処理の重さのばらつき等をパラメータとして用いて並列度を計算してもよい。例えば、ばらつきが大きいほど並列度が小さくなるように計算する。また、処理の重さ及び処理の待ち合わせ度のいずれか一方のみを用いて並列度を計算してもよい。さらにまた、処理の重さとして、画像処理モジュール38で行う処理に含まれる掛け算や加算の数が多いほど処理の重さが重くする例について説明したが、掛け算や加算に限らず、各処理に含まれる特定の演算の回数が多いほど処理の重さを重くなるようにしてもよい。また、各画像処理モジュール38の単位処理にかかる時間を予め測定しておき、この情報を登録したテーブルを予め記憶部20に記憶しておき、これを参照して並列度の計算に用いるようにしてもよい。また、各画像処理モジュール38のプログラムコードの行数の情報を記憶部20に記憶しておき(或いは計算の都度、行数をカウントして)、行数が多いほど処理の重さが重くなるように設定してもよい。
また、上記実施の形態では、各画像処理モジュール38の処理の待ち合わせ度を単位処理データ量に基づいて計算する例について説明したが、これに限定されず、例えば、画像処理モジュール38で行われる画像処理が、画像1面分のデータを処理するページ処理か、或いは画像1面分より少ないライン単位のデータを処理するライン処理かを示す情報を記憶部20の記憶領域に記憶しておき、これを参照するとともに、処理の待ち合わせ度をページ処理かライン処理かに応じて予め設定しておき、該設定値を用いて処理待ち係数を計算するようにしてもよい。
また、上記実施の形態では、接続形態や画像処理モジュール38の数によってオーバーヘッド値を求める例について説明したが、オーバーヘッド値を計算するために用いるパラメータはこれに限定されない。例えば、スレッドのロックの生じる割合に応じて、オーバーヘッド値を計算するようにしてもよい。すなわち、排他制御では、バッファモジュール40のバッファ40Aにデータを書き込む際、同時に複数のモジュールからの書き込みが生じないように、毎回ロックをかけて排他制御して書き込みさせるようにしているが、書き込み回数分ロックが生じるため、ロックの時間が大きくなると、並列に動作するオーバーヘッドが大きくなってしまう。従って、書き込み処理全体におけるロックの時間の割合を各画像処理モジュール38毎に予め測定して記憶部20に記憶しておき、この割合が大きいほどオーバーヘッド値が大きくなるように計算してもよい。また、処理の数、接続形態、及びスレッドのロックの生じる割合の少なくとも1つに基づいて、オーバーヘッド値を求めるようにしてもよい。なお、接続形態については、上記実施の形態では、直列接続か、並列接続かで係数を異ならせて計算したが、並列接続であっても、並列接続されている画像処理モジュール38の数等に応じてその係数を異ならせてもよい。
また、上記では並列度及びオーバーヘッド値の大小を比較して並列処理性能判定を行う例について説明したが、これに限定されない。例えば、「並列度−オーバーヘッド値>予め定められた閾値」である場合に、並列処理方式の方が短い時間で終了すると判定し、それ以外は、逐次処理方式の方が短い時間で終了すると判定してもよい。また、例えば、並列度と予め定められた第1の閾値とを比較した結果と、オーバーヘッド値と予め定められた第2の閾値とを比較した結果とに基づいて並列処理性能判定を行うようにしてもよい。具体的には、並列度が第1の閾値より大きく、且つオーバーヘッド値が第2の閾値より小さい場合に、逐次処理方式より並列処理方式の方が短い時間で終了すると判定し、それ以外は、逐次処理方式より並列処理方式の方が長い時間で終了すると判定するようにしてもよい。また、並列度が第1の閾値より小さく、オーバーヘッド値が第2の閾値より大きい場合には、逐次処理方式による処理と並列処理方式による処理とが等しくなると判定してもよい。
また、上記では、並列度を求めるパラメータとオーバーヘッド値を求めるパラメータとが異なる場合について説明したが、これに限定されず、共通のパラメータを用いて並列度とオーバーヘッド値の双方を求めることもできる。例えば、単位処理データ量が小さいほど並列度はアップするが、排他制御の数もその分増加するためオーバーヘッドも増える。また、処理の重さが重いほど、並列度が上がり、オーバーヘッドが減る。このように、並列度とオーバーヘッド値の双方に関連するパラメータを用いて、並列度及びオーバーヘッド値を各々計算するようにしてもよい。
また、並列度とオーバーヘッド値とを別々に計算して用いるのでなく、並列度とオーバーヘッド値の双方を示す値(或いはパラメータ)を予め定められた閾値と比較して並列処理性能判定を行うようにしてもよい。例えば、上記処理待ち係数は単位処理データ量に依存するが、前述のように、単位処理データ量が小さいほど処理待ち係数が大きくなって並列度が大きくなるものの、その分オーバーヘッドは大きくなる。すなわち、処理待ち係数(或いは単位処理データ量)は、並列度及びオーバーヘッド値の双方に影響するものといえる。そこで、閾値A<処理待ち係数<閾値B(閾値A<閾値Bとする)となる場合には、逐次処理方式より並列処理方式の方が短い時間で終了する、と判定し、それ以外は、逐次処理方式より並列処理方式の方が長い時間で終了する、と判定するようにしてもよい。また、処理待ち係数単独で判定せずに、処理の重さの合計も考慮して、閾値a<処理の重さの合計×処理待ち係数<閾値b(閾値a<閾値bとする)の場合に、逐次処理方式より並列処理方式の方が短い時間で終了する、と判定し、それ以外は、逐次処理方式より並列処理方式の方が長い時間で終了する、と判定するようにしてもよい。
また、処理管理部46のプログラムは、記憶部20の処理管理部ライブラリ47に固定的に記憶されている必要はなく、コンピュータ10の外部から、例えばUSBメモリ等の外部記憶装置や通信回線等を介して、新たな処理管理部(並列処理管理部や逐次処理管理部)のプログラムを追加したり、既登録の処理管理部のプログラムを上書き更新可能としてもよい。CPU12の新たなアーキテクチャの採用等に応じて、最適な並列化の手法が変わる事も考えられるし、また最適な処理管理部のプログラムを当初より提供することが困難な場合や、処理管理部のアルゴリズムとしてより高効率のアルゴリズムが今後新たに開発される可能性もある。このような場合を考慮し、記憶部20の処理管理部ライブラリ47は、処理管理部のプログラムの新規追加や上書き更新が可能に構成することが望ましい。
また、例えば当初は逐次処理用の処理管理部(逐次処理管理部)のみを提供し、画像処理部50で並列処理を行わせることによる画像処理の高速化を所望しているユーザに対しては、別途料金を支払ってもらうことで並列処理管理部のプログラムの新規追加等の処理管理部のプログラムの更新を許可したり、ユーザとの間で締結したメンテナンス契約により一定期間は処理管理部のプログラムの更新を許可するようにしてもよい。
また、上記では本発明に係るプログラムに対応する画像処理プログラム群34が記憶部20に予め記憶(インストール)されている態様を説明したが、本発明に係る画像処理プログラムは、CD−ROMやDVD−ROM等の記録媒体に記録されている形態で提供することも可能である。
また、上記実施の形態では、画像処理装置を例に挙げたが、これに限定されるものではない。例えば、画像データに限らず様々なデータを処理(例えば、演算処理等)するデータ処理装置を適用してもよい。
図19は、画像データ以外のデータを演算処理するデータ処理装置としてのコンピュータ600の概略構成を示すブロック図である。コンピュータ600はCPU612、メモリ614、表示部616、操作部618、記憶部620、データ供給部622及びデータ出力部624を備えており、これらはバス626を介して互いに接続されている。表示部16や操作部18は、当該コンピュータに接続されたディスプレイやキーボード、マウス等を適用することができる。また、記憶部620としてはHDD(Hard Disk Drive)が好適であるが、これに代えてフラッシュメモリ等の他の不揮発性記憶手段を用いることも可能である。
また、データ供給部622は処理対象のデータを供給できるものであればよく、外部メモリと接続するためのインタフェースや通信回線を介して外部からデータを受信する受信部、データを記憶するデータ記憶部(メモリ614又は記憶部620)等を適用することができる。また、データ出力部624は演算処理を経たデータを出力するものであればよく、例えばデータをディスプレイ等に表示する表示部、データを記録メディアに書き込む書込装置、データを通信回線を介して送信する送信部を適用することができる。また、データ出力部624は演算処理を経たデータを単に記憶する記憶部(メモリ614又は記憶部620)であっても構わない。
図19に示すように、記憶部620には、CPU612によって実行される各種のプログラムとして、メモリ614等のリソースの管理やCPU612によるプログラムの実行の管理、コンピュータ600と外部との通信等を司るオペレーティングシステムのプログラム(不図示)、コンピュータ600を本発明に係るデータ処理装置として機能させるための処理プログラム群634が各々記憶されている。
処理プログラム群634によって実現されるデータ処理装置は、不図示のアプリケーション或いは操作部618を介したユーザからの構築指示に従い、指示されたデータ処理(ここでは演算処理)を行うデータ処理部を構築し、アプリケーション或いはユーザからの実行指示に従い、データ処理部によって処理対象のデータの演算処理を行う。
以下、処理プログラム群634について説明する。図19に示すように、処理プログラム群634はモジュールライブラリ636と、処理構築部642のプログラムと、処理管理部ライブラリ647に大別される。この実施の形態に係るデータ処理装置も、前述した画像処理装置と同様に、アプリケーションからの指示等により、予め定められた演算処理を行う複数の演算モジュール638と、個々の演算モジュール638の前段及び後段の少なくとも一方に配置されデータを記憶するためのバッファを備えたバッファモジュール640と、がパイプライン形態又はDAG(Directed Acyclic Graph:有向非循環グラフ)形態で連結されて成るデータ処理部を構築する。演算モジュール638の各々には、処理の重さ及び単位処理データ量(本実施の形態では、単位処理データ量をデータの個数で表すため、以下では、単位処理データ数という)が予め設定されている。データ処理部の構築方法は、前述した画像処理部の構築方法と同様であるため、説明を省略する。また、各演算モジュール638は、上記図4(A)で示した画像処理モジュール38と同様に、制御部と演算処理エンジンから構成され、上記と同様に動作する。また、バッファモジュール640も、上記図4(B)で示したバッファモジュール40と同様に、バッファ制御部とバッファから構成され、上記バッファモジュール40と同様に動作する。
また、この実施の形態においても、データ処理部の個々の演算モジュール638で互いに並列に演算処理を行わせる並列処理方式と、データ処理部の演算モジュール638のうちの常に単一の演算モジュール638で演算処理を行わせると共に、演算処理を行わせる演算モジュール638を逐次切り替える逐次処理方式があり、本実施形態のデータ処理装置においても、並列処理方式で演算処理を行わせる場合には並列処理用のデータ処理部を構築し、逐次処理方式で演算処理を行わせる場合には逐次処理用のデータ処理部を構築することで、データ処理部における演算処理の処理方式を切り替えるようになっている。また、ここでも、並列処理用として排他制御を行う機能が付加されたバッファモジュール640、及び逐次処理用として排他制御を行う機能が付加されていないバッファモジュール640が各々用意され、モジュールライブラリ636には、排他制御を行う機能が付加されたバッファモジュール640のプログラムと排他制御を行う機能が付加されていないバッファモジュール640のプログラムが各々登録されている。
また図19に示すように、処理管理部ライブラリ647には、複数種のモジュール生成部644(図19では1つしか示されていない)が含まれている。複数種のモジュール生成部644は互いに異なる演算処理に対応しており、処理構築部642によって起動されることで、対応する演算処理を実現するための演算モジュール638及びバッファモジュール640から成るモジュール群を生成する処理を行う。
また、処理管理部ライブラリ647にプログラムが登録されている処理管理部646は、並列処理用のデータ処理部(バッファモジュール640として排他制御機能付きのバッファモジュール640を適用したデータ処理部)を構築させ、構築させたデータ処理部で並列処理方式によって演算処理が行われるように制御する並列処理管理部と、逐次処理用のデータ処理部(バッファモジュール640として排他制御機能無しのバッファモジュール640を適用したデータ処理部)を構築させ、構築させたデータ処理部で逐次処理方式によって演算処理が行われるように制御する逐次処理管理部に大別される。
個々の処理管理部646は、データ処理部における演算処理の実行を制御するワークフロー管理部、データ処理部の各モジュールによるメモリ614や各種のファイル等のコンピュータ600のリソースの使用を管理するリソース管理部、及び、データ処理部で発生したエラーを管理するエラー管理部を含んで構成される。これら処理管理部646の各構成要素の作用については、前述した画像処理装置における処理管理部と同様であるため、説明を省略する。
また、アプリケーション632等からの指示に従ってデータ処理部を構築する処理構築部642は、図19に示すように処理内容・順序判定部650、並列処理性能判定部652、及び選択起動部645を備えている。処理内容・順序判定部650は、実行すべき処理の内容を認識し、該処理を構成する各演算処理の順序を判定する。並列処理性能判定部652は、並列度及びオーバーヘッド値を計算し、該並列度及びオーバーヘッド値に基づいて、並列処理性能判定を行う。選択起動部645並列処理性能判定部652から出力された判定結果に基づいて、並列処理管理部又は逐次処理管理部を選択して起動し、並列処理方式又は逐次処理方式による演算処理が行われるように制御する。また、図19においても並列処理管理部のプログラム及び逐次処理管理部のプログラムを各々1個のみ示しているが、処理管理部ライブラリ647には、複数種の並列処理管理部のプログラム及び複数種の逐次処理管理部のプログラムを各々登録可能とされている。
次に図20〜図22を参照してデータ処理装置600の作用を説明する。ここでは、入力された金額を示すデータに対して、乗算処理や加算処理等の演算処理を施して出力するデータ処理部を構築する場合を例に挙げて説明する。図20は、データ処理部の構築から演算処理の実行に至る一連の処理を説明するためのシーケンス図である。また、図21及び図22は、並列処理性能判定の具体例を説明する説明図であり、図21のa、b、c、d、及び図22のe、f、g、hは、演算モジュール638の種類を示す。
なお、図21(A)(B)に示されたデータ処理部において、演算モジュールaは、入力された金額のデータから消費税計算を行い、演算モジュールbは、該計算された消費税に1000を加算し、演算モジュールcは、1000が加算された値に1/10を乗算して10%の値を求め、演算モジュールdは、演算モジュールcで演算された結果から50を減算する。
また、図22(A)(B)に示されたデータ処理部において、演算モジュールeは、入力された10個分の金額データの合計値を演算し、演算モジュールfは、演算モジュールeで演算された合計値に対する各金額データの割合を演算し、演算モジュールgは、演算モジュールfで演算された割合を項目別に合計し、演算モジュールhは、演算モジュールgで演算された項目別の合計に対して、各演算モジュールfで演算された値の割合を演算する。
演算処理の実行がユーザによって指示された場合等、何らかの演算処理を行う必要のある状況になると、処理構築部642の処理内容・順序判定部650は、実行すべき処理の内容を認識し、実行すべき処理を、個々のモジュール生成部644に対応するレベルの演算処理の組み合わせに分解し、実行すべき処理を実現するために必要な演算処理の種類及び個々の演算処理の実行順序を判定する(図20のステップ700も参照)。
次に、処理構築部642の並列処理性能判定部652は、並列処理性能判定を行うための値を計算する。ここでは、データ処理部を構成する各演算モジュール640の処理の重さの和と、処理待ち合わせ度と、データ処理部を構成する演算モジュール640の数とを計算する。
各演算モジュール638の「処理の重さ」は、前述の画像処理部50の並列度を計算したときに用いた処理の重さと同様に、各演算モジュール638毎に予め測定した負荷(単位処理に要する時間)を1から5までの5段階評価で表したものとする。処理の重さは、例えば、各演算モジュール638の単位処理内の加算及び乗算の回数に応じた値としてもよい。並列処理性能判定部652は、各演算モジュール638の処理の重さを加算して処理の重さの和を求める。
「処理待ち合わせ度」は、各演算モジュール638の単位処理データ数(前段のモジュールで処理されたデータを何個必要とするか、すなわち単位処理に必要なデータ数)に基づいて以下の式により計算される。
処理待ち合わせ度=演算モジュールの数/各演算モジュールの単位処理データ数
次に、各値を用いて並列処理性能判定を行う。ここでは、
各演算モジュールの重さの和×処理待ち合わせ度>演算モジュールの数
が成立した場合には、データ処理部における並列処理方式による演算処理が、逐次処理方式による演算処理より短い時間で終了すると判定する。
各演算モジュールの重さの和×処理待ち合わせ度<演算モジュールの数
が成立した場合には、データ処理部における並列処理方式による演算処理が、逐次処理方式による演算処理より長い時間で終了すると判定する。
各演算モジュールの重さの和×処理待ち合わせ度=演算モジュールの数
が成立した場合には、並列処理方式と逐次処理方式とでデータ処理部の演算処理に要する時間は等しいと判定する。
なお、上記3式における左辺の「各演算モジュールの重さの和×処理待ち合わせ度」は並列度を示し、右辺の「演算モジュールの数」はオーバーヘッド値を示す。
並列処理性能判定部652は、該判定結果を選択起動部645に出力する(図20のステップ702も参照。)。
ここで、図21に示す例では、図21(C)に示すように、各演算モジュール638の処理の重さの和は8となり、処理待ち合わせ度は1となり、演算モジュール638の個数は4であるため、8×1>4となり、データ処理部における並列処理方式による演算処理が、逐次処理方式による演算処理より短い時間で終了する(並列処理方式により性能が出る)、と判定される。一方、図22に示す例では、図22(C)に示すように、各演算モジュール638の処理の重さの和は8となり、処理待ち合わせ度は0.286となり、演算モジュール638の個数は4であるため、8×0.286<4となり、データ処理部における並列処理方式による演算処理が、逐次処理方式による演算処理より長い時間で終了する(並列処理方式では性能が出ない)、と判定される。
選択起動部645は、並列処理性能判定部652から入力された判定結果に応じて、起動すべき処理管理部を選択し、起動する(図20のステップ704も参照)。ここでは、上記判定結果が、並列処理方式による演算処理が、逐次処理方式による演算処理より短い長い時間で終了する、という判定結果であった場合には、並列処理方式での演算処理が行われるように、並列処理管理部646を選択して起動する。また、上記判定結果が、並列処理方式による演算処理が、逐次処理方式による演算処理より長い時間で終了する、という判定結果であった場合には、逐次処理方式での演算処理が行われるように、逐次処理管理部646を選択して起動する。なお、並列処理方式と逐次処理方式とでデータ処理部の演算処理に要する時間は等しいとの判定結果であった場合には、どちらを選択して起動してもよい。従って、予めどちらを選択するかを設定しておき、該設定に応じて選択して起動する。
起動された処理管理部が並列処理管理部646であれば、上記のバッファモジュール640として排他制御機能付きのバッファモジュール640が生成され、起動された処理管理部が逐次処理管理部646であれば、上記のバッファモジュール640として排他制御機能無しのバッファモジュール640が生成される(図20のステップ706も参照。)。更に、処理構築部642で、上記で判定した演算処理の種類及び実行順序に基づいて、特定の演算処理に対応する演算モジュール生成部644を起動し、起動した演算モジュール生成部644に対し、当該演算モジュール生成部644によるモジュール群の生成に必要な情報を与え、演算モジュールの生成を指示する(図20では不図示)。また、必要とされる演算処理が複数種ある場合には、個々の演算処理に対応する他のモジュール生成部644を起動してモジュール群の生成に必要な情報を通知し、個々の演算処理の実行順序の昇順に繰り返す。これにより、処理管理部644の演算モジュール生成部644は、演算モジュール638を生成する(図20のステップ708も参照。)。
一方、処理構築部642は、順次起動した演算モジュール生成部644によって前述のモジュール生成処理が順次行われることで、必要とされる演算処理を行うデータ処理部の構築が完了すると、稼働中の処理管理部646に対してデータ処理部による演算処理の実行を指示する(図20のステップ710も参照)。処理管理部646は、演算処理の実行が指示されると、メモリ614にロードしたデータ処理部の各モジュールのプログラムを、オペレーティングシステムを通じてスレッドとしてCPU612に実行させる(図20のステップ712も参照。)。ここで、稼働中の処理管理部646が並列処理管理部である場合、処理管理部646は、データ処理部の個々の演算モジュール638で互いに並列に演算処理を行わせるために、データ処理部を構成する個々のモジュールのプログラムを互いに独立したスレッドとしてCPU612に実行させる。また、稼働中の処理管理部646が逐次処理管理部である場合、処理管理部646は、データ処理部を構成する個々のモジュールのプログラムを単一のスレッドとしてCPU612に実行させる。なお、スレッドに代えて、プロセス又はオブジェクトとしてCPU612に実行させるようにしてもよい。
なお、データ処理部による一連の演算処理が完了した場合には、処理管理部646は、処理構築部642に対して演算処理の完了を通知し(図20のステップ714も参照)、並列制御処理(或いは逐次制御処理)を終了する。そして、演算処理の完了が通知された処理構築部642は、ユーザに対して演算処理の完了を通知する(図20のステップ716も参照)。
なお、データ処理装置の構成は、一例であって、上記例に限定されるものではないことはもちろんである。例えば、上記データ処理装置では、並列処理性能判定の結果に応じて並列処理管理部または逐次処理管理部を選択して起動するが、例えば、処理管理部を選択して起動する構成を含めずに、該判定結果を出力するだけの構成としてもよい。また、並列処理性能判定の方法も、上記説明した例にとどまらず、様々なパラメータを用いて並列度及びオーバーヘッド値を計算して判定可能である。
また、上記データ処理装置では、バッファモジュール640を演算モジュール638に連結してデータ処理部を構築する例について説明したが、例えば、前段から後段に受け渡すデータの大きさが小さい場合等においては、バッファモジュール640がないデータ処理部を構築してもよい。
また、処理方式を選択する際に、画像処理部50(或いはデータ処理部)の動作環境を考慮して選択するようにしてもよい。例えば、例えばコンピュータ10に設けられているプログラム実行リソース(例えばCPU等)の数を用いることができ、例えば「プログラム実行リソースの数がN個以上であって、上記並列処理性能判定結果で、並列処理方式のほうが処理時間が短いと判定された場合に並列処理管理部46を起動し、それ以外の場合には逐次処理管理部46を起動する」等の条件を設けてもよい。