以下、図面を参照して本発明の実施形態の一例を詳細に説明する。図1には、本発明に係る画像処理装置として機能することが可能なコンピュータ10が示されている。なお、このコンピュータ10は、複写機、プリンタ、ファクシミリ装置、これらの機能を兼ね備えた複合機、スキャナ、写真プリンタ等のように内部で画像処理を行う必要のある任意の画像取扱機器に組み込まれていてもよいし、パーソナル・コンピュータ(PC)等の独立したコンピュータであってもよく、更にPDA(Personal Digital Assistant)や携帯電話機等の携帯機器に組み込まれたコンピュータであってもよい。
コンピュータ10は、第1制御部11、第2制御部51、表示部16、操作部18、記憶手段としての記憶部20、画像データ供給部22及び画像出力部24を備えており、これらはバス26を介して互いに接続されている。第1制御部11は、第1プロセッサとしてのCPU(Central Processing Unit)12と、第1メモリ14とを備えている。CPU12は、コンピュータ10のメインプロセッサとして動作する。第2制御部51は、第2プロセッサとしてのGPU(Graphics Processing Unit)52及び第2メモリ54を備えている。GPU52は画像処理を専門とするプロセッサである。なお、第2プロセッサをここでは、GPU52としたが、第2プロセッサはGPUに限定されず、例えば、CPUとしてもよい。なお、CPU12及びGPU52との間で行われる情報のやりとりは、例えば、周知のプロセッサ間通信により行われるように構成することもできる。
コンピュータ10が上述したような画像取扱機器に組み込まれている場合、表示部16や操作部18としては、画像取扱機器に設けられたLCD等から成る表示パネルやテンキー等を適用することができる。また、コンピュータ10が独立したコンピュータである場合、表示部16や操作部18としては、当該コンピュータに接続されたディスプレイやキーボード、マウス等を適用することができる。また、記憶部20としてはHDD(Hard Disk Drive)が好適であるが、これに代えてフラッシュメモリ等の他の不揮発性記憶手段を用いることも可能である。
また、画像データ供給部22は処理対象の画像データを供給できるものであればよく、例えば紙や写真フィルム等の記録材料に記録されている画像を読み取って画像データを出力する画像読取部、通信回線を介して外部から画像データを受信する受信部、画像データを記憶する画像記憶部(後述する第1メモリ14、第2メモリ54、又は記憶部20)等を適用することができる。また、画像出力部24は画像処理を経た画像データ又は該画像データが表す画像を出力するものであればよく、例えば画像データが表す画像を紙や感光材料等の記録材料に記録する画像記録部、画像データが表す画像をディスプレイ等に表示する表示部、画像データを記録メディアに書き込む書込装置、画像データを通信回線を介して送信する送信部を適用することができる。また、画像出力部24は画像処理を経た画像データを単に記憶する画像記憶部(後述する第1メモリ14、第2メモリ54又は記憶部20)であっても構わない。
図1に示すように、記憶部20には、CPU12によって実行される各種のプログラムとして、リソースの管理や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のプログラムと、処理管理手段に相当する処理管理部46のプログラムに大別される。詳細は後述するが、本実施形態に係る処理構築部42は、アプリケーションからの指示により、例として図5に示すように、予め定められた画像処理を行う1つ以上の画像処理モジュール38と、個々の画像処理モジュール38の前段及び後段の少なくとも一方に配置され画像データを記憶するためのバッファを備えたバッファモジュール40と、がパイプライン形態又はDAG(Directed Acyclic Graph:有向非循環グラフ)形態で連結されて成る画像処理部50を構築する。画像処理部50を構成する個々の画像処理モジュールの実体はCPU12によって実行されCPU12で所定の画像処理を行わせるための第1のプログラム、又は、CPU12によって実行されCPU12により他のプロセッサ(本実施形態ではGPU52)に対する処理の実行を指示するための第2のプログラム(すなわち、画像処理モジュール38自体はCPU12により動作するが、該画像処理モジュール38が実行する画像処理は第2プロセッサであるGPU52に依頼して実行させるためのプログラム)であり、上述したモジュールライブラリ36には、予め定められた互いに異なる画像処理(例えば入力処理やフィルタ処理、色変換処理、拡大・縮小処理、スキュー角検知処理、画像回転処理、画像合成処理、出力処理等)を行う複数種の画像処理モジュール38のプログラムが各々登録されている。
個々の画像処理モジュール38は、例として図15(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ライン分又は画像の複数ライン分であるものがモジュールライブラリ36に含まれていても良い。
また、モジュールライブラリ36に登録されている個々の画像処理モジュール38のプログラムは、画像処理エンジン38Aに相当するプログラムと制御部38Bに相当するプログラムから構成されているが、制御部38Bに相当するプログラムは部品化されており、個々の画像処理モジュール38のうち単位読出データ量及び単位書込データ量が同一の画像処理モジュール38は、画像処理エンジン38Aで実行される画像処理の種類や内容に拘わらず、制御部38Bに相当するプログラムが共通化されている(制御部38Bに相当するプログラムとして同一のプログラムが用いられている)。これにより、画像処理モジュール38のプログラムの開発にあたっての開発負荷が軽減される。
なお、画像処理モジュール38の中には、入力される画像の属性が未知の状態では単位読出データ量及び単位書込データ量が確定しておらず、入力画像データの属性を取得し、取得した属性を所定の演算式に代入して演算することで単位読出データ量や単位書込データ量が確定するモジュールが存在しているが、この種の画像処理モジュール38については、単位読出データ量と単位書込データ量が互いに同一の演算式を用いて導出される画像処理モジュール38について、制御部38Bに相当するプログラムを共通化するようにすればよい。また、本実施形態に係る画像処理プログラム群34は、前述のように各種機器に実装可能であるが、画像処理プログラム群34のうちモジュールライブラリ36に登録する画像処理モジュール38の数や種類等については、画像処理プログラム群34を実装する各種機器で必要とされる画像処理に応じて、適宜追加・削除・入替等が可能であることは言うまでもない。
また、画像処理部50を構成する個々のバッファモジュール40は、例として図15(B)にも示すように、コンピュータ10に設けられた第1メモリ14又は第2メモリ54からオペレーティングシステム30を通じて確保されたメモリ領域で構成されるバッファ40Aと、バッファモジュール40の前段及び後段のモジュールとの画像データの入出力及びバッファ40Aの管理を行うバッファ制御部40Bから構成されている。個々のバッファモジュール40のバッファ制御部40Bもその実体はCPU12によって実行されるプログラムであり、モジュールライブラリ36にはバッファ制御部40Bのプログラムも登録されている(図1ではバッファ制御部40Bのプログラムを「バッファモジュール」と表記して示している)。なお、バッファAは、前段の画像処理モジュールが画像処理に使用するプロセッサに対応して設けられたメモリ(使用するプロセッサがCPU12であれば、第1メモリ14、使用するプロセッサがGPU52であれば、第2メモリ54)に確保されたバッファであるものとする。
また、アプリケーション32からの指示に従って画像処理部50を構築する処理構築部42は、図1に示すように複数種のモジュール生成部44から構成されている。複数種のモジュール生成部44は互いに異なる画像処理に対応しており、アプリケーション32によって起動されることで、対応する画像処理を実現するための画像処理モジュール38及びバッファモジュール40から成るモジュール群を生成する処理を行う。
本実施形態において、アプリケーション32は、モジュール生成部44に対して、画像処理をCPU12及びGPU52の何れのプロセッサで行うのかを指定して、画像処理モジュール38の各々を生成させる。モジュール生成部44は、指定に応じて、該指定されたプロセッサを使用して画像処理を行う画像処理モジュール38を生成する。なお、第1プロセッサであるCPU12を使用して画像処理を行う画像処理モジュール38は、CPU12に対応して設けられた第1メモリ14のメモリ空間を使用する。また、第2プロセッサであるGPU52を使用して画像処理を行う画像処理モジュール38は、GPU52に対応して設けられた第2メモリ54のメモリ空間を使用する。なお、GPU52を使用して画像処理を行う後者の画像処理モジュール38であっても、画像処理モジュール38自体はメインプロセッサであるCPU12上で動作するが、画像処理についてはCPU12からGPU52に依頼して当該画像処理を実行させるものとする。
なお、図1ではモジュール生成部44の一例として、モジュールライブラリ36に登録されている個々の画像処理モジュール38が実行する画像処理の種類に対応するモジュール生成部44を示しているが、個々のモジュール生成部44に対応する画像処理は、複数種の画像処理モジュール38によって実現される画像処理(例えばスキュー角検知処理と画像回転処理から成るスキュー補正処理)であってもよい。必要とされる画像処理が複数種の画像処理を組み合わせた処理である場合、アプリケーション32は複数種の画像処理の何れかに対応するモジュール生成部44を順次起動する。これにより、アプリケーション32によって順次起動されたモジュール生成部44により、必要とされる画像処理を行う画像処理部50が構築されることになる。
また図1に示すように、処理管理部46は、ワークフロー管理部46A、リソース管理部46B、及びエラー管理部46Cを含んで構成されている。ここで、ワークフロー管理部46A、リソース管理部46B、及びエラー管理部46Cの何れのプログラムも、メインプロセッサであるCPU12により実行される。
ワークフロー管理部46Aは、画像処理部50における画像処理の実行を制御する。リソース管理部46Bは、画像処理部50の各モジュールによる第1メモリ14及び第2メモリ54の使用や、コンピュータ10のリソースの使用を管理する。エラー管理部46Cは、画像処理部50で発生したエラーを管理する。
なお、処理構築部42によって構築される画像処理部50は、画像処理部50を構成する個々の画像処理モジュール38が、画像1面分よりも小さいデータ量を単位として後段へ画像データを引き渡しながら並列に画像処理を行うように動作する(ブロック単位処理と称する)ことも、前段の画像処理モジュール38が画像1面分の画像データに対する画像処理を完了した後に、後段の画像処理モジュール38が画像1面分の画像データに対する画像処理を行うように動作する(面単位処理と称する)ことも可能とされており、ワークフロー管理部46Aのプログラムとして、画像処理部50にブロック単位処理を行わせるためのプログラムと、画像処理部50に面単位処理を行わせるためのプログラムが各々用意されている。
次に本実施形態の作用を説明する。本実施形態では、複数のプロセッサを使用して画像処理部を構築することから、仮に、単一のプロセッサ(メインプロセッサ)のみを使用して複数モジュールを連結した画像処理部を構築して画像処理するときの画像データの受け渡し手法を本実施形態においてそのまま適用すると、メインプロセッサのみを使用した画像処理部では想定されない問題が生じることがある。この問題について図21を参照して説明する。
使用するプロセッサがメインプロセッサ単一である場合には、各モジュールで使用されるメモリ空間も単一であるため、バッファモジュール40が画像データを保持するバッファ(メモリ領域)は、前後に連結されたモジュールが動作するプロセッサに対応するメモリ空間と同じメモリ空間上に確保される。従って、この場合、常にメインプロセッサに対応するメモリ空間を使用したデータの受け渡しが行われることとなる。
この単一のプロセッサを使用した画像処理部におけるデータ授受の手法を、2つのプロセッサ(第1プロセッサ及び第2プロセッサ)を使用した画像処理部に対してもそのまま適用すると、バッファモジュール40が保持するバッファは、常にメインプロセッサに対応するメモリ空間に確保される。例えば、メインプロセッサを第1プロセッサとすると、バッファモジュール40のバッファは、常に第1プロセッサに対応するメモリ空間である第1メモリにアロケート(確保)される。
一方、第2プロセッサを使用して画像処理を行う画像処理モジュール38は、第2プロセッサに対応する第2メモリに確保されたメモリ領域に画像処理後の画像データを書き出す。
このため、第2プロセッサを使用して画像処理を行う画像処理モジュール38が連続している場合であっても、該画像処理モジュール38が処理して第2メモリに書き込まれた画像データを、これらの画像処理モジュール38の間に連結されるバッファモジュール40のバッファ(第1メモリに確保されたバッファ)に一度書き出し、更にこれを第2メモリに書き戻さなければならない。これは、本来不要なデータ転送であり、処理速度低下の原因ともなる。
そこで、本実施形態において、モジュール生成部44により生成されるバッファモジュール40は、前段の画像処理モジュール38が処理した画像データの出力先となるバッファを前段の画像処理モジュール38が画像処理に使用するプロセッサに対応するメモリ空間に確保する。また、バッファモジュール40は、後段に前段の画像処理モジュール38が画像処理に使用するプロセッサと同じプロセッサを画像処理に使用する画像処理モジュール38が連結された場合には、画像処理モジュール38に上記確保したバッファのアドレスを渡す。また、バッファモジュール40は、後段に前段の画像処理モジュール38が画像処理に使用するプロセッサと異なるプロセッサを画像処理に使用する画像処理モジュール38が連結された場合には、該後段の画像処理モジュール38が前段から画像データを取得して使用することが可能となるように、後段の画像処理モジュール38が使用するプロセッサに対応するメモリに転送用のバッファを別途確保し、画像データを転送する処理を行う。バッファ(メモリ領域)の確保は、リソース管理部46Bを介して行われる。詳細は後述する。
本実施形態では、コンピュータ10の電源が投入されるとリソース管理部46Bが起動され、リソース管理部46Bにより図2(A)に示す初期化処理が行われる。
本実施形態では、リソース管理部46Bによるメモリ管理の方式として、画像処理部50の個々のモジュールからの要求の都度、第1メモリ14又は第2メモリ54から要求元のモジュールに割り当てるメモリ領域を確保する第1管理方式、各プロセッサに対応するメモリ空間から一定サイズのメモリ領域を事前に確保し、個々のモジュールからの要求があると、事前に確保したメモリ領域のうちの一部領域を要求元のモジュールに割り当てる第2管理方式、及び、各プロセッサに対応するメモリ空間から一定サイズのメモリ領域を事前に確保し、個々のモジュールからの要求があると、要求されたメモリ領域のサイズが閾値未満であれば事前に確保したメモリ領域のうちの一部領域を要求元のモジュールに割り当て、要求されたメモリ領域のサイズが閾値以上であれば要求元のモジュールに割り当てるメモリ領域を確保する第3管理方式、の3種類の管理方式が用意されており、何れの管理方式でメモリ管理を行うかを選択・設定可能とされている。なお、本発明はこれに限定されるものではなく、他のメモリ管理方式が含まれていても良い。
これらの各管理方式は、例えば次のように選択される。特にメモリ制限等の無いアプリケーションから使われ、かつ複雑なメモリ管理によるプログラムサイズの増加を抑えたい場合等には、第1管理方式が好適である。また、本発明による画像処理を行うアプリケーションの全体で使用可能なメモリ量が制限されており、その範囲で動作する必要がある場合には、第2管理方式が好適である。一方、メモリ確保や解放に要する処理時間を高速化する必要がある場合には、細かいメモリ領域の確保や解放にオペレーティングシステム30のメモリ確保/解放機能を使うとオーバーヘッドが大きくなることがあるので、第3管理方式が好適である。
図2(A)に示す初期化処理のステップ100では、選択・設定されているメモリ管理方式が第2管理方式又は第3管理方式か否か判定する。なお、メモリ管理方式の選択は、コンピュータ10に画像処理プログラム群34をインストールする際に選択・設定するようにしてもよいし、リソース管理部46Bがコンピュータ10のシステム環境(例えば第1メモリ14及び第2メモリ54のサイズや画像処理プログラム群34が実装されている機器の種別等)を取得し、取得したシステム環境に基づいて自動的に選択・設定するようにしてもよい。
メモリ管理方式が第1管理方式である場合は上記判定が否定されて初期化処理を終了するが、上記判定が肯定された場合はステップ102へ移行し、コンピュータ10に設けられている第1メモリ14或いは第2メモリ54から、オペレーティングシステム30を通じて所定サイズのメモリ領域(連続領域)を確保して終了する。なお、上記の所定サイズについても、システム環境等に応じて選択・設定してもよい。
ここで、メモリ管理方式が第1管理方式である場合には、その後に発生するメモリ確保要求に応答してオペレーティングシステム30を通じて要求されたメモリ領域を確保し、またメモリ解放要求に応答して同じくオペレーティングシステム30を通じてメモリ領域を解放する。これらの処理は、通常のプログラムで用いられているものと同様なので、説明を省略する。
また、メモリ管理方式が第2管理方式である場合には、その後に発生するメモリ確保要求に応答して、先のステップ102で事前に確保したメモリ領域のうち、状態が「未使用」の未使用領域から要求に対応するサイズのメモリ領域を探索して確保し、確保したメモリ領域の状態を「使用済み」に変更すると共に、確保したメモリ領域を要求元へ引き渡す。メモリ解放要求に対しては、解放が要求されたメモリ領域を事前に確保したメモリ領域のうちの未使用領域に編入すると共に、編入したメモリ領域の状態を「使用済み」から「未使用」に変更する処理を行う。メモリ領域の状態が未使用か使用済みかを表す情報は、例えばテーブルやリスト等で管理することができる。
次にメモリ管理方式が第3管理方式である場合を説明する。メモリ管理方式が第3管理方式である場合、メモリ確保要求が発生すると、リソース管理部46Bによって図2(B)に示すメモリ確保要求時処理が行われる。メモリ確保要求時処理では、まずステップ104でその要求サイズが予め定めた閾値以下か否かを判定する。要求サイズが閾値以下でない場合には、第1管理方式と同様に、ステップ106でオペレーティングシステム30を通じて要求サイズのメモリ領域を確保し、ステップ108で確保したメモリ領域の先頭アドレスをリソース管理部46B中のテーブルに登録する。なお、テーブルに代えてリストや連想配列等の他の手段を使っても良い。ステップ104において要求サイズが閾値以下と判定された場合には、第2管理方式と同様に、先のステップ102で事前に確保したメモリ領域のうちの未使用領域から要求サイズのメモリ領域を確保し(ステップ110)、確保した領域の状態を「使用済み」に変更する(ステップ112)。そしてステップ114で、確保したメモリ領域を要求元へ引き渡す。
また、メモリ管理方式が第3管理方式である場合、メモリ解放要求が発生すると、リソース管理部46Bによって図2(C)に示すメモリ解放要求時処理が行われる。メモリ解放要求時処理では、まずステップ116において、解放が要求されているメモリ領域の先頭アドレスが前述のテーブルに登録されているか否かを判定する。ステップ116の判定が肯定された場合、解放が要求されているメモリ領域はオペレーティングシステム30を通じて確保したメモリ領域であるので、ステップ118において解放が要求されたメモリ領域をオペレーティングシステム30を通じて解放し、次のステップ120で解放が要求されているメモリ領域の先頭アドレスを前述のテーブルから削除する。
また、ステップ116の判定が否定された場合、解放が要求されているメモリ領域は先のステップ102で事前に確保したメモリ領域から確保したメモリ領域であるので、ステップ122において、解放が要求されているメモリ領域を事前に確保したメモリ領域のうちの未使用領域に編入し、編入したメモリ領域の状態を次のステップ124で「未使用」に変更する。このような処理の後、ステップ126において要求されたメモリ領域の解放を要求元に通知してメモリ解放要求時処理を終了する。
次に、リソース管理部46Bに対してメモリ以外のリソース(例えば特定のファイル等)の確保・解放が要求された場合について説明する。
リソース確保要求が入力されると、リソース管理部46Bは図2(D)に示すリソース確保要求時処理を行う。リソース確保要求時処理では、まずステップ130において、確保が要求されたリソースをオペレーティングシステム30を通じて確保し、次のステップ132では確保したリソースのアドレスを要求元のモジュールを識別する情報と対応付けてリソース管理部46B中のテーブルに登録し、ステップ134で確保したリソースを要求元に引き渡して処理を終了する。
また、リソース解放要求が入力されると、リソース管理部46Bは図2(E)に示すリソース解放要求時処理を行う。リソース解放要求時処理では、まずステップ136において、要求元のモジュールを識別する情報と対応付けてリソース管理部46B中のテーブルに登録した情報(確保したリソースのアドレス)を読み出す。次のステップ138では読み出した情報が表すリソースをオペレーティングシステム30を通じて全て解放する。また、ステップ140では解放したリソースに対応する情報がテーブルから削除されるようにテーブルを更新し、次のステップ142でリソースの解放を要求元に通知して処理を終了する。
このように、メモリ以外のリソースの確保/解放では、確保したリソースを確保時にテーブルへ登録しておき、解放時にはテーブルに登録されているリソース(同一要求元からの要求に従って確保したリソース)を全て解放するので、リソース解放要求元が解放対象のリソースを指定して解放を要求する方式と比較して、リソースの解放漏れが生ずることを防止することができる。なお、これらメモリやリソースの確保/解放処理においては、リソースの不足等から処理に失敗する場合があり、その場合にはエラー管理部46Cに通知する等の処理が必要となるが、ここではそれらのエラー処理については説明を簡単にするために省略する。
一方、画像処理プログラム群34が実装されている機器において、何らかの画像処理を行う必要のある状況になると、この状況が特定のアプリケーション32によって検知され、当該アプリケーション32によって図3に示す処理が行われる。なお、画像処理を行う必要のある状況としては、例えば画像データ供給部22としての画像読取部によって画像を読み取り、画像出力部24としての画像記録部により記録材料に画像として記録するか、画像出力部24としての表示部に画像として表示させるか、画像出力部24としての書込装置により画像データを記録メディアに書き込むか、画像出力部24としての送信部により画像データを送信するか、画像出力部24としての画像記憶部に記憶させるジョブの実行がユーザによって指示された場合、或いは、画像データ供給部22としての受信部によって受信されるか、画像データ供給部22としての画像記憶部に記憶されている画像データに対して、上記の記録材料への記録、表示部への表示、記録メディアへの書き込み、送信、画像記憶部への記憶の何れかを行うジョブの実行がユーザによって指示された場合が挙げられる。また、画像処理を行う必要のある状況は上記に限られるものではなく、例えばユーザからの指示に応じてアプリケーション32が実行可能な処理の名称等を表示部16に一覧表示している状態で、実行対象の処理がユーザによって選択された等の場合であってもよい。
上記のように、何らかの画像処理を行う必要のある状況になったことを検知すると、アプリケーション32は、まず画像処理対象の画像データを供給する画像データ供給部22の種別を認識し(図3のステップ150も参照)、認識した種別がバッファ領域(第1メモリ14の一部領域)であった場合(図3のステップ152の判定が肯定された場合)には、画像データ供給部22として指定されたバッファ領域を含むバッファモジュール40を生成する(図3のステップ154も参照)。後述するバッファモジュール40の新規生成では、バッファモジュール40のバッファ制御部40Bのプログラムを実行するプロセス、スレッド又はオブジェクトを生成することでバッファ制御部40Bを生成し、生成されたバッファ制御部40Bによりバッファ40Aとして使用するメモリ領域が確保されることによって成されるが、このステップ154におけるバッファモジュール40の生成は、指定されたバッファ領域を既に確保されたバッファ40Aとして(バッファ制御部40Bに)認識させるパラメータを設定してバッファ制御部40Bを生成する処理を行うことによって成される。ここで生成されたバッファモジュール40は画像データ供給部22として機能する。
続いてアプリケーション32は、上記と同様に、画像処理を行った画像データの出力先としての画像出力部24の種別を認識し(図3のステップ156も参照)、認識した種別がバッファ領域(第1メモリ14の一部領域)であった場合(図3のステップ158の判定が肯定された場合)は、画像出力部24として指定されたバッファ領域を含むバッファモジュール40を上記と同様にして生成する(図3のステップ160も参照)。ここで生成されたバッファモジュール40は画像出力部24として機能する。更にまた、アプリケーション32は実行すべき画像処理の内容を認識し、実行すべき画像処理を、個々のモジュール生成部44に対応するレベルの画像処理の組み合わせに分解し、実行すべき画像処理を実現するために必要な画像処理の種類及び個々の画像処理の実行順序を判定する(図3のステップ162も参照)。なお、この判定は、例えば上記の画像処理の種類及び個々の画像処理の実行順序を、ユーザが実行を指示可能なジョブの種類と対応付けて予め情報として登録しておき、アプリケーション32は、実行が指示されたジョブの種類に対応する情報を読み出すことによって実現することができる。
そしてアプリケーション32は、上記で判定した画像処理の種類及び実行順序に基づいて、まず実行順序が1番の画像処理に対応するモジュール生成部44を起動(モジュール生成部44のプログラムを実行するプロセス、スレッド又はオブジェクトを生成)した後に(図3のステップ164も参照)、起動したモジュール生成部44に対し、当該モジュール生成部44によるモジュール群の生成に必要な情報として、生成する画像処理モジュール38の各々が画像処理に使用するプロセッサの指定情報、前記モジュール群に画像データを入力する入力モジュールを識別するための入力モジュール識別情報、前記モジュール群が画像データを出力する出力モジュールを識別するための出力モジュール識別情報、前記モジュール群に入力される入力画像データの属性を表す入力画像属性情報、実行すべき画像処理のパラメータを通知し、対応するモジュール群の生成を指示する(図3のステップ166も参照)。なお、モジュール生成部44のモジュール生成処理に使用するプロセッサは、メインプロセッサであるCPU12であるものとする。すなわち、個々のモジュール生成部44は、CPU12上で動作する。
なお、上記の入力モジュールは、実行順序が1番目のモジュール群については画像データ供給部22が入力モジュールとなり、実行順序が2番目以降のモジュール群については前段のモジュール群の最終モジュール(通常はバッファモジュール40)が入力モジュールとなる。また、上記の出力モジュールについては、実行順序が最後のモジュール群では画像出力部24が出力モジュールとなるので、画像出力部24が出力モジュールとして指定されるが、その他のモジュール群では出力モジュールは未確定のためにアプリケーション32による指定は行われず、必要な場合はモジュール生成部44によって生成・設定される。また、入力画像属性や画像処理のパラメータについては、例えばユーザが実行を指示可能なジョブの種類と対応付けて予め情報として登録しておき、実行が指示されたジョブの種類に対応する情報を読み出すことでアプリケーション32が認識するようにしてもよいし、ユーザに指定させるようにしてもよい。
一方、モジュール生成部44は、アプリケーション32によって起動されると図4(A)に示すモジュール生成処理を行う(図3のステップ168も参照)。モジュール生成処理では、まずステップ200において、このモジュール生成部44で次に生成すべき画像処理モジュール38が有るか否かを判定する。判定が否定された場合はモジュール生成処理を終了する。生成すべき画像処理モジュール38が有る場合には、ステップ202で生成すべき画像処理モジュール38に入力される入力画像データの属性を表す入力画像属性情報を取得し、次のステップ204では、ステップ202で取得した情報が表す入力画像データの属性に照らしても先のステップ200で生成すべきと判定した画像処理モジュール38の生成が必要か否かを判定する。
具体的には、例えば実行中のモジュール生成処理に対応するモジュール生成部44が色変換処理を行うモジュール群を生成するモジュール生成部であり、画像処理のパラメータにより出力画像データの色空間としてCMY色空間がアプリケーション32から指定された場合、ステップ202で取得した入力画像属性情報に基づいて入力画像データがRGB色空間のデータであることが判明した場合には、色空間処理を行う画像処理モジュール38としてRGB→CMYの色空間変換を行う画像処理モジュール38を生成する必要があるが、入力画像データがCMY色空間のデータであった場合には、入力画像データの属性と出力画像データの属性が色空間に関して一致しているので、色空間変換処理を行う画像処理モジュール38は生成不要と判断することができる。不要と判断された場合はステップ200に戻る。
なお、入力画像データの属性を取得する処理は、生成する画像処理モジュール38の前段にバッファモジュール40が存在している場合、当該バッファモジュール40に画像データの書き込みを行う更に前段の画像処理モジュール38から出力画像データの属性を取得することによって実現できる。
次のステップ206では、生成する画像処理モジュール38の後段にバッファモジュール40が必要か否かを判定する。この判定は、画像処理モジュールの後段が出力モジュール(画像出力部24)である場合(例えば図5(A)〜(C)に示す画像処理部50における最後段の画像処理モジュール38を参照)や、例として図5(B)に示す画像処理部50においてスキュー角検知処理を行う画像処理モジュール38のように、画像処理モジュールが、画像データに対して解析等の画像処理を行いその結果を他の画像処理モジュール38へ出力するモジュールである場合は否定され、バッファモジュール40の生成を行うことなくステップ210へ移行するが、上記以外の場合は判定が肯定されてステップ208へ移行し、バッファ制御部40Bを起動する(バッファ制御部40Bのプログラムを実行するプロセス、スレッド又はオブジェクトを生成する)ことで、画像処理モジュールの後段に連結するバッファモジュール40を生成する。バッファ制御部40Bは、モジュール生成部44(或いは前述したアプリケーション32)によって起動されると図6に示すバッファ制御処理を行う。このバッファ制御処理については後述する。
次のステップ210では、前段のモジュール(例えばバッファモジュール40)の情報と後段のバッファモジュール40の情報、画像処理モジュール38に入力される入力画像データの属性、処理パラメータを与えて、アプリケーション32から通知された指定情報が示すプロセッサを使用して画像処理を行う画像処理モジュール38を生成する。なお、ステップ206で後段のバッファモジュール40が不要と判断された画像処理モジュール38に対しては後段のバッファモジュール40の情報は与えられず、また例えば50%縮小処理のように処理内容が固定的で特別な画像処理パラメータが必要ない場合には処理パラメータは与えられない。
モジュール生成処理(ステップ210)では、モジュールライブラリ36に登録されており、画像処理モジュール38として利用可能な複数の候補モジュールの中から、ステップ202で取得した入力画像データの属性、及び、画像処理モジュール38で実行すべき処理パラメータに合致する画像処理モジュール38を選択する。例えば実行中のモジュール生成処理に対応するモジュール生成部44が色変換処理を行うモジュール群を生成するモジュール生成部であり、処理パラメータにより出力画像データの色空間としてCMY色空間がアプリケーション32から指定され、更に入力画像データがRGB色空間のデータであった場合には、モジュールライブラリ36に登録されている各種の色空間処理を行う複数種の画像処理モジュール38の中から、RGB→CMYの色空間変換を行う画像処理モジュール38が選択される。
また、画像処理モジュールが拡大・縮小処理を行う画像処理モジュール38であり、指定された拡大縮小率が50%以外であれば、入力された画像データに対して指定された拡大・縮小率で拡大・縮小処理を行う画像処理モジュール38が選択され、指定された拡大縮小率が50%であれば、拡大縮小率50%に特化した拡大縮小処理、すなわち入力された画像データを1画素おきに間引くことで50%に縮小する縮小処理を行う画像処理モジュール38が選択される。なお、画像処理モジュール38の選択は上記に限られるものではなく、例えば画像処理エンジン38Aによる画像処理における単位処理データ量が異なる画像処理モジュール38をモジュールライブラリ36に複数登録しておき、画像処理部50へ割当可能なメモリ領域のサイズ等の動作環境に応じて、適切な単位処理データ量の画像処理モジュール38を選択する(例えば上記サイズが小さくなるに従って単位処理データ量の小さい画像処理モジュール38を選択する等)ようにしてもよいし、アプリケーション32或いはユーザに選択させるようにしてもよい。
次のステップ212では、後段のバッファモジュール40のIDと生成した画像処理モジュール38のIDの組をワークフロー管理部46Aに通知する。このIDは、個々のモジュールを一意に判別できる情報であればよく、例えば個々のモジュールの生成順に付与した番号や、バッファモジュール40や画像処理モジュール38のオブジェクトのメモリ上でのアドレス等でも良い。ワークフロー管理部46Aに通知された情報は、例えば図4(B)に示すようなテーブル形式やリスト形式、連想配列形式等でワークフロー管理部46Aの内部に保持され、後の処理で使われる。ここではテーブル形式で保持するものとして説明を続ける。
なお、先程述べた後段のバッファモジュール40を持たない画像処理モジュール38の場合には、例えば下記の方法で処理を行う。図5(A)において出力処理を行う画像処理モジュール38のように、生成する画像処理モジュール38がパイプラインの終点又は有向非循環グラフの終点の一つである場合には、当該画像処理モジュール38をモジュール生成部44の出力として呼び出し元のアプリケーション32に戻す。また、図5(B)においてスキュー角検知処理を行う画像処理モジュール38のように、生成した画像処理モジュール38における画像処理の結果が他の画像処理モジュール(図5(B)では画像回転処理を行う画像処理モジュール38)で使われる場合、モジュール生成部44は、当該画像処理モジュール38に対して処理が終了するまで繰り返し処理実行を指示して、処理結果を取得する。
ステップ212の処理が終了すると、モジュール生成部44は制御をステップ200に戻して次に生成すべき画像処理モジュールがあるか否かを判定する。なお、個々のモジュール生成部44は、対応する一定の画像処理を行うモジュール群を生成するので、この判定は、個々のモジュール生成部44毎にどのような画像処理モジュールをどのような接続関係で生成するかに関する情報を予め登録して読み出すか、またはモジュール生成部44を動作させるプログラム中に記述しておくことでも実現できる。例えば実行中のモジュール生成処理に対応するモジュール生成部44が、複数種の画像処理モジュール38によって実現される画像処理(例えばスキュー角検知処理を行う画像処理モジュール38と画像回転処理を行う画像処理モジュール38によって実現されるスキュー補正処理)を行うモジュール群を生成する場合には、2個以上の画像処理モジュール38を含むモジュール群が生成される。
アプリケーション32は、モジュール群の生成を指示したモジュール生成部44から、上記のようにしてモジュール群の生成完了が通知されると、図3のステップ162における判定の結果に基づいて、必要とされる画像処理を実現するために他の画像処理を行うモジュール群も生成する必要があるか否か判断する。必要とされる画像処理が複数種の画像処理を組み合わせた処理である場合、アプリケーション32は、個々の画像処理に対応する他のモジュール生成部44を起動してモジュール群の生成に必要な情報を通知する処理を順次行う(図3のステップ170,172も参照)。そして、順次起動されたモジュール生成部44によって上述したモジュール生成処理(図4)が順次行われる(図3のステップ174も参照)ことで、例として図5(A)〜(C)に示すように、必要とされる画像処理を行う画像処理部50が構築されることになる。
なお、本実施形態では、特定の画像処理の実行頻度が高い等の場合に、アプリケーション32が、特定の画像処理を行う画像処理部50を生成するための複数種のモジュール生成部44に対し、特定の画像処理を行う画像処理部50を生成させた後も処理終了を指示しないことでプロセス、スレッド又はオブジェクトとして残しておき、特定の画像処理を行う必要が生ずる毎に、プロセス、スレッド又はオブジェクトとして残しておいた各モジュール生成部44に対してモジュール群の生成を順次指示することで、特定の画像処理を行う画像処理部50を再生成させることも可能とされている。これにより、特定の画像処理を行う必要が生ずる毎に対応する各モジュール生成部44を各々起動する処理が不要となり、特定の画像処理を行う画像処理部50を再生成するのに要する時間を短縮することができる。
ところで、画像処理モジュール38の制御部38Bは、モジュール生成部44によって起動されると図12に示す画像処理モジュール初期化処理を行う。この画像処理モジュール初期化処理では、まずステップ250において、モジュール生成部44がモジュール生成処理(図4)のステップ210の処理を行うことでモジュール生成部44から与えられた自モジュールの前段及び後段のモジュールの情報を記憶する。また、次のステップ252では、自モジュールの画像処理エンジン38Aが行う画像処理の種類や内容等に基づき、自モジュールが使用するメモリのサイズ及び自モジュールが使用する他のリソースを認識する。なお、自モジュールが使用するメモリは、画像処理エンジン38Aが画像処理を行うために必要なメモリが主であるが、前段のモジュールが画像データ供給部22である場合や後段のモジュールが画像出力部24である場合には、前段又は後段のモジュールとの画像データの送受に際して画像データを一時記憶するためのバッファ用のメモリが必要となることもある。また、処理パラメータにテーブル等の情報が含まれている場合には、それを保持するためのメモリ領域が必要となることもある。そしてステップ254では、ステップ252で認識したサイズをリソース管理部46Bへ通知すると共に、通知したサイズのメモリ領域の確保を、リソース管理部46Bへ要求する。ここで要求されるメモリ領域は、自モジュールが画像処理に使用するプロセッサに対応するメモリ空間のメモリ領域であるものとする。
図2に示すリソース管理処理(リソース管理部46B)では、画像処理モジュール38又はバッファモジュール40からメモリ領域の確保が要求されると、例えば選択・設定されているメモリ管理方式が第1管理方式である場合には、メモリ確保要求元のモジュールから通知されたサイズのメモリ領域(連続領域)をオペレーティングシステム30を通じて確保する。そして確保したメモリ領域の先頭アドレスをメモリ確保要求元のモジュールへ通知することで、確保したメモリ領域をメモリ確保要求元のモジュールに引き渡す。また、メモリ管理方式が第2管理方式であれば、事前に確保したメモリ領域のうちの未使用領域から通知されたサイズのメモリ領域(連続領域)を確保し、確保したメモリ領域を「使用済み」に変更すると共に、確保したメモリ領域をメモリ確保要求元へ引き渡す。また、選択・設定されているメモリ管理方式が第3管理方式であれば、前述したメモリ確保要求時処理(図2(B)参照)が実行されることで、通知されたサイズのメモリ領域の確保・引き渡しが行われる。
図12に示す画像処理モジュール初期化処理(画像処理モジュール38の制御部38B)では、上記の処理を経てリソース管理部46B経由で必要なメモリ領域を確保すると、次のステップ256において、先のステップ252の処理結果に基づき、メモリ以外の他のリソースを自モジュール(の画像処理エンジン38A)が必要としているか否か判定する。判定が否定された場合は何ら処理を行うことなくステップ262へ移行するが、判定が肯定された場合はステップ258へ移行し、自モジュールが必要としているメモリ以外の他のリソースの種類等をリソース管理部46Bへ通知すると共に、通知した他のリソースの確保をリソース管理部46Bへ要求して確保する。
次に、ステップ262では自モジュールの前段のモジュールを判定し、自モジュールの前段にモジュールが存在していない場合にはステップ272へ移行し、前段のモジュールがバッファモジュール40以外、例えば画像データ供給部22や特定のファイル等である場合には、必要に応じてステップ270でその初期化処理を行ってステップ272に移る。また、自モジュールの前段にモジュールが存在しており、当該前段のモジュールがバッファモジュール40であった場合には、ステップ262からステップ264へ移行し、前段のバッファモジュール40からの1回の画像データの読み出しによって取得する画像データのデータ量(単位読出データ量)を認識する。この単位読出データ量は、自モジュールの前段のバッファモジュール40の数が1個であれば1個だけであるが、例えば図5(C)に示す画像処理部50において画像合成処理を行う画像処理モジュール38のように、前段のバッファモジュール40の数が複数で、複数のバッファモジュール40から各々取得した画像データを用いて画像処理エンジン38Aが画像処理を行う等の場合、前段の個々のバッファモジュール40に対応する単位読出データ量は、自モジュールの画像処理エンジン38Aが行う画像処理の種類や内容、前段のバッファモジュール40の数等に応じて定まる。
ステップ266では、ステップ264で認識した単位読出データ量を前段の単一のバッファモジュール40へ通知することで、当該バッファモジュール40に対して単位読出データ量を設定する(図15(A)の(1)も参照)。次のステップ268では、自モジュールの前段の全てのバッファモジュール40に単位読出データ量を設定したか否か判定する。自モジュールの前段のバッファモジュール40の数が1個であれば当該判定は肯定されてステップ272へ移行するが、前段のバッファモジュール40の数が複数であればステップ268の判定が否定されてステップ266に戻り、ステップ268の判定が肯定される迄、ステップ266,268を繰り返す。これにより、前段の全てのバッファモジュール40に対して単位読出データ量が各々設定されることになる。
ステップ272では、自モジュールの後段のモジュールを判定し、自モジュールの後段のモジュールがバッファモジュール40以外、例えば画像出力部24や特定のファイル等の場合には、必要に応じてステップ278でその初期化処理を行ってステップ280に移る。例えば後段のモジュールが、画像記録部や表示部、書込装置、送信部の何れかから成る画像出力部24であれば、この画像出力部24に対し、上記の初期化処理として、単位書込データ量に相当するデータ量ずつ画像データを出力することを通知する処理等を行う。また、後段のモジュールがバッファモジュール40である場合には、ステップ274で1回の画像データの書き込みにおける画像データのデータ量(単位書込データ量)を認識し、ステップ276で後段のバッファモジュールに当該単位書込データ量を設定(図15(A)の(2)も参照)した後に、ステップ280に移る。ステップ280では、当該画像処理モジュール初期化処理の完了をモジュール生成部44に通知して、画像処理モジュール初期化処理を終了する。
一方、画像処理部50を構成する個々のバッファモジュール40のバッファ制御部40Bは、モジュール生成部44又はアプリケーション32によって起動されると図6に示すバッファ制御処理を行う。このバッファ制御処理では、モジュール生成部44又はアプリケーション32によって起動されてバッファモジュール40の生成が指示されると、ステップ356で待ち要求数を0に初期化する。また、次のステップ358では、自モジュールの前段の画像処理モジュール38から単位書込データ量が通知されるか又は自モジュールの後段の画像処理モジュール38から単位読出データ量が通知されたか否か判定する。判定が否定された場合はステップ362へ移行し、自モジュールと連結されている全ての画像処理モジュール38から単位書込データ量又は単位読出データ量が通知されたか否か判定する。判定が否定された場合はステップ358に戻り、ステップ358又はステップ362の判定が肯定される迄ステップ358,362を繰り返す。
自モジュールと連結されている特定の画像処理モジュール38から単位書込データ量又は単位読出データ量が通知されると、ステップ358の判定が肯定されてステップ360へ移行し、通知された単位書込データ量又は単位読出データ量を記憶した後にステップ358に戻る。従って、自モジュールと連結されている個々の画像処理モジュール38の制御部38Bによって画像処理モジュール初期化処理(図12)のステップ266又はステップ276の処理が行われることで、前記個々の画像処理モジュール38から単位書込データ量又は単位読出データ量が通知される毎に、通知された単位書込データ量又は単位読出データ量が記憶されることで、通知された単位書込データ量又は単位読出データ量がバッファモジュール40に設定される(図15(B)の(1),(2)も参照)。
自モジュールと連結されている全ての画像処理モジュール38から単位書込データ量又は単位読出データ量が通知され、通知された単位書込データ量及び単位読出データ量が各々設定されると、ステップ362の判定が肯定されてステップ364へ移行し、自モジュールと連結されている個々の画像処理モジュール38によって各々設定された単位書込データ量及び単位読出データ量に基づいて、自モジュールのバッファ40Aの管理単位である単位バッファ領域のサイズを決定し、決定した単位バッファ領域のサイズを記憶する。単位バッファ領域のサイズとしては、自モジュールに設定された単位書込データ量及び単位読出データ量のうちの最大値が好適であるが、単位書込データ量を設定してもよいし、単位読出データ量(自モジュールの後段に複数の画像処理モジュール38が連結されている場合は、個々の画像処理モジュール38によって各々設定された単位読出データ量の最大値)を設定してもよいし、単位書込データ量と単位読出データ量(の最大値)の最小公倍数を設定してもよいし、この最小公倍数が所定値未満であれば最小公倍数を、最小公倍数が所定値以上であれば別の値(例えば上述した単位書込データ量及び単位読出データ量のうちの最大値、単位書込データ量、単位読出データ量(の最大値)の何れか)を設定するようにしてもよい。
次のステップ366では、自モジュールのバッファ40Aとして用いるメモリ領域が既に設けられているか否か判定する。この判定は、自モジュールがモジュール生成部44によって生成された場合には否定され、ステップ368でバッファフラグに0を設定した後にステップ374へ移行する。また、自モジュールがアプリケーション32によって生成され、画像データ供給部22又は画像出力部24として機能するバッファモジュール40であった場合には、自モジュールのバッファ40Aとして用いるメモリ領域が既に存在しているので、ステップ366の判定が肯定されてステップ370へ移行し、先程ステップ364で決定した単位バッファ領域のサイズを、自モジュールのバッファ40Aとして用いる既設のメモリ領域のサイズに変更する。また、次のステップ372でバッファフラグに1を設定した後にステップ374へ移行する。
更に、ステップ374では自モジュールの後段の個々の画像処理モジュール38に対応する有効データポインタを各々生成し、生成した有効データポインタを各々初期化する。この有効データポインタは、自モジュールの前段の画像処理モジュールによって自モジュールのバッファ40Aに書き込まれた画像データのうち、対応する後段の画像処理モジュール38によって読み出されていない画像データ(有効データ)について、その先頭位置(次の読出開始位置)と末尾位置を各々指し示すポインタであり、ステップ374の初期化処理では通常、有効データが存在していないことを意味する特定の情報が設定されるが、自モジュールがアプリケーション32によって生成され、画像データ供給部22として機能するバッファモジュール40であれば、自モジュールのバッファ40Aとして用いるメモリ領域には既に画像処理対象の画像データが書き込まれている場合があり、この場合には当該画像データの先頭位置及び末尾位置が後段の個々の画像処理モジュール38に対応する有効データポインタに各々設定される。
以上の処理によりバッファモジュール40における初期化処理が完了し、次のステップ376では初期化処理の完了をワークフロー管理部46Aへ通知する。また、ステップ378では、先のステップ356で初期設定を行った待ち要求数に0よりも大きい値が設定されているか否か判定する。判定が否定された場合はステップ380へ移行し、自モジュールの前段又は後段に連結されている画像処理モジュール38から、当該画像処理モジュール38を消去する処理を行うことを通知する消去通知を受信したか否か判定する。この判定も否定された場合はステップ378に戻り、何れかの判定が肯定される迄ステップ378,380を繰り返す。
一方、アプリケーション32は、順次起動したモジュール生成部44によって前述のモジュール生成処理(図4)が順次行われることで、必要とされる画像処理を行う画像処理部50の構築が完了すると、実行が指示されている画像処理の実行形態がブロック単位処理か面単位処理かを判断し、判断した実行形態に対応するワークフロー管理部46Aのプログラムを実行するプロセス、スレッド又はオブジェクトを起動することで、ワークフロー管理部46Aに対して画像処理部50による画像処理の実行を指示する(図3のステップ176も参照)。
処理管理部46のワークフロー管理部46Aは、画像処理の実行形態に応じて異なるプログラムが起動されることで、画像処理の実行形態がブロック単位処理である場合は図16に示すブロック単位制御処理を、画像処理の実行形態が面単位処理である場合は図17に示す面単位制御処理を行う。なお、このブロック単位処理及び面単位制御処理は、図3のステップ178に示す画像処理部制御処理に各々対応している。ワークフロー管理部46Aはブロック単位処理又は面単位制御処理において、画像処理部50を構成する画像処理モジュール38のうちの所定の画像処理モジュール38に処理要求を入力することで、画像処理部50による画像処理をブロック単位又は面単位の実行形態で行わせるが、以下では画像処理部50全体の動作説明に先立ち、個々のバッファモジュール40のバッファ制御部40Bによって行われる初期化処理完了以降の処理、個々の画像処理モジュール38の制御部38Bによって行われる画像処理モジュール制御処理について順に説明する。
本実施形態では、画像処理モジュール38が後段のバッファモジュール40に画像データを書き込む場合には、画像処理モジュール38からバッファモジュール40へ書込要求が入力され、画像処理モジュール38が前段のバッファモジュール40から画像データを読み出す場合には、画像処理モジュール38からバッファモジュール40へ読出要求が入力される。このため、バッファモジュール40のバッファ制御部40Bは、自モジュールの前段の画像処理モジュール38から書込要求が入力されるか、又は自モジュールの後段の画像処理モジュール38からデータ要求が入力されると、割込が発生することで図7に示す要求受信割込処理を行う。なお、以下では割込発生を前提に説明するが、通常のプログラムのように関数やメソッドの呼び出しで処理が始まっても良い。その場合には、以下で説明するように要求を待ち行列にキューイングするのではなく、要求毎に処理が行われるよう構成しても良い。
この要求受信割込処理では、まずステップ400において、自モジュールに書込要求又はデータ要求を入力した要求元を識別する要求元識別情報と要求の種別(書込か読出か)を表す要求種別情報を要求情報として待ち行列の末尾に登録する。この待ち行列は、個々のバッファモジュール40に割り当てられたメモリ上に各々形成される。また、次のステップ402では待ち要求数を1だけインクリメントし、要求受信割込処理を終了する。この要求受信割込処理により、特定のバッファモジュール40の前段又は後段の画像処理モジュールから特定のバッファモジュール40に書込要求又は読出要求が入力される毎に、入力された書込要求又は読出要求に対応する要求情報が特定のバッファモジュール40に対応する待ち行列に順次登録されると共に、待ち要求数が1ずつインクリメントされることになる。
また、上記の要求受信割込処理が実行されることで待ち要求数が1以上の値になると、バッファ制御処理(図6)のステップ378の判定が肯定されてステップ382へ移行し、待ち行列の先頭から要求情報を取り出す。次のステップ384では、ステップ382で取り出した要求情報に含まれる要求種別情報に基づいて、取り出した要求情報に対応する要求の種別(書込か読出か)を判定し、判定結果に応じて分岐する。要求の種別が読出であった場合には、ステップ384からステップ386へ移行し、図8に示すデータ書込処理を行う。
データ書込処理では、まずステップ410において、バッファフラグに1が設定されているか否か、すなわち自モジュールがアプリケーション32によって生成されたバッファモジュール40か否か判定する。この判定が肯定された場合は、バッファ40Aとして用いるメモリ領域が既に確保されているので、何ら処理を行うことなくステップ422へ移行する。また、ステップ410の判定が否定された場合、すなわち自モジュールがモジュール生成部44によって生成されたバッファモジュール40であった場合にはステップ412へ移行し、自モジュールのバッファ40Aを構成する単位バッファ領域の中に、空き領域が有る単位バッファ領域(画像データが末尾まで書き込まれていない単位バッファ領域)が存在しているか否か判定する。
モジュール生成部44によって生成されたバッファモジュール40は、当初はバッファ40Aとして用いるメモリ領域(単位バッファ領域)が確保されておらず、メモリ領域の不足が生ずる度に単位バッファ領域を単位として確保されるので、バッファモジュール40に最初に書込要求が入力されたときにはバッファ40Aとして用いるメモリ領域(単位バッファ領域)が存在しておらず、この判定は否定される。また、後述する処理を経てバッファ40Aとして用いる単位バッファ領域が確保された後も、当該単位バッファ領域への画像データの書込に伴って当該単位バッファ領域が丁度満杯になった場合には上記判定は否定される。
ステップ412の判定が否定された場合はステップ414へ移行し、待ち行列から取り出した要求情報に含まれる要求元識別情報に基づいて書込要求元の画像処理モジュール38を認識し、書込要求元の画像処理モジュール38によって設定された単位書込データ量を認識した後に、認識した単位書込データ量が、先のステップ364(図6)で決定した単位バッファ領域のサイズよりも大きいか否か判定する。この判定は、単位バッファ領域のサイズとして、自モジュールに設定された単位書込データ量及び単位読出データ量のうちの最大値、或いは自モジュールに設定された単位書込データ量を採用した場合には常に否定されてステップ420へ移行し、確保すべきメモリ領域のサイズ(単位バッファ領域のサイズ)をリソース管理部46Bに通知すると共に、自モジュールのバッファ40Aとして用いるメモリ領域(画像データの保管に用いる単位バッファ領域)の確保をリソース管理部46Bに要求する。ここでは、第1メモリ14又は第2メモリ54のうち、前段の画像処理モジュール38が画像処理に使用するプロセッサに対応するメモリに対してメモリ領域を確保するようリソース管理部46Bに要求する。これにより、リソース管理部46Bによって前述の図2に示す処理が行われることで単位バッファ領域が確保される。
また、自モジュールのバッファ40Aを構成する単位バッファ領域の中に、空き領域有りの単位バッファ領域が存在していた場合には、ステップ412の判定が肯定されてステップ416へ移行し、前述したステップ414と同様にして書込要求元の画像処理モジュール38によって設定された単位書込データ量を認識した後に、空き領域有りの単位バッファ領域における空き領域のサイズが認識した単位書込データ量以上か否か判定する。判定が肯定された場合は、自モジュールのバッファ40Aとして用いる単位バッファ領域を新たに確保する必要は無いので、何ら処理を行うことなくステップ422へ移行する。
単位バッファ領域のサイズが単位書込データ量の整数倍である場合には、自モジュールの前段の画像処理モジュール38から書込要求が入力される毎に、上記のようにステップ412,414の判定が各々否定されるか又はステップ412,416の判定が各々肯定され、バッファ40Aとして用いる単位バッファ領域のみが必要に応じて確保される。
一方、単位バッファ領域のサイズが単位書込データ量の整数倍でない場合には、バッファ40A(単位バッファ領域)への単位書込データ量の画像データの書込が繰り返されることで、例として図9(A)にも示すように、空き領域有りの単位バッファ領域における空き領域のサイズが単位書込データ量よりも小さい状態が生ずる(ステップ416の判定が肯定される)。また本実施形態では、単位バッファ領域のサイズとして、自モジュールに設定された単位読出データ量(又はその最大値)を採用することも可能であるが、そのサイズが単位書込データ量よりも小さい場合(ステップ414の判定が肯定される場合)には、書込要求が入力されたときに常に上記の状態が生じていることになる。
上記のように、空き領域有りの単位バッファ領域における空き領域のサイズが単位書込データ量よりも小さい場合、単位書込データ量の画像データが書き込まれる領域が複数の単位バッファ領域に跨ることになるが、本実施形態では、バッファ40Aとして用いるメモリ領域を単位バッファ領域を単位として確保するので、異なるタイミングで確保した単位バッファ領域が実メモリ(第1メモリ14)上で連続する領域であることは保証されない。このため、画像データが書き込まれる領域が複数の単位バッファ領域に跨る場合、すなわち、ステップ416の判定が否定されるかステップ414の判定が肯定された場合にはステップ418へ移行し、確保すべきメモリ領域のサイズとして単位書込データ量をリソース管理部46Bに通知すると共に、書込用に用いるメモリ領域(書込用バッファ領域:図9(B)も参照)の確保をリソース管理部46Bに要求する。ここでは、第1メモリ14又は第2メモリ54のうち、前段の画像処理モジュール38が画像処理に使用するプロセッサに対応するメモリに対してメモリ領域を確保するようリソース管理部46Bに要求する。そして、書込用バッファ領域を確保すると、次のステップ420でバッファ40Aとして用いる単位バッファ領域の確保を行う。
ステップ422では、空き領域有りの単位バッファ領域における空き領域のサイズが単位書込データ量以上の場合は当該空き領域を書込領域とする一方、空き領域有りの単位バッファ領域における空き領域のサイズが単位書込データ量よりも小さい場合には、新たに確保した書込用バッファ領域を書込領域として、当該書込領域の先頭アドレスを書込要求元の画像処理モジュール38へ通知すると共に、書込対象の画像データを通知した先頭アドレスから順に書き込むよう要請する。これにより、書込要求元の画像処理モジュール38は、先頭アドレスが通知された書込領域(単位バッファ領域又は書込用バッファ領域)に画像データを書き込む(図9(B)も参照)。前述したように、画像データが書き込まれる領域が複数の単位バッファ領域に跨る場合は書込用バッファ領域を別途確保するので、画像データが書き込まれる領域が複数の単位バッファ領域に跨るか否かに拘わらず、書込要求元の画像処理モジュール38への書込領域の通知は、上記のようにその先頭アドレスを通知するのみで済み、画像処理モジュール38とのインタフェースが簡単になる。
次のステップ424では、前段の画像処理モジュール38による書込領域への画像データの書き込みが完了したか否か判定し、判定が肯定される迄ステップ424を繰り返す。前段の画像処理モジュール38から書込完了が通知されると、ステップ424の判定が肯定されてステップ426へ移行し、上記の書込処理における書込領域が、先のステップ416で確保した書込用バッファ領域か否か判定する。判定が否定された場合は何ら処理を行うことなくステップ432へ移行するが、ステップ426の判定が肯定された場合はステップ428へ移行し、例として図9(C)に示すように、書込用バッファ領域に書き込まれた画像データを、空き領域有りの単位バッファ領域と、先のステップ422で確保した新たな単位バッファ領域に分けて複写する。またステップ430では、先のステップ418で書込用バッファ領域として確保したメモリ領域の先頭アドレスをリソース管理部46Bへ通知して、当該メモリ領域の解放をリソース管理部46Bに要求する。
なお、ここでは必要な時に書込用バッファ領域を確保して、不要になったら直ぐに解放する態様を説明したが、保管用単位バッファ領域のサイズが単位書込データ量の整数倍になっていない場合には、書込用バッファ領域は必ず必要となるので、初期化時に確保しておき、バッファモジュール40が消去される時に解放するよう構成しても良い。
リソース管理部46Bは、画像処理モジュール38又はバッファモジュール40からメモリ領域の解放が要求されると、選択・設定されているメモリ管理方式に応じたメモリ解放の処理を行う。例えばメモリ管理方式が第3管理方式であれば図2(C)のメモリ解放要求時処理(示す処理)を行ってメモリ領域の解放を行う。
データ書込処理(図8)において、ステップ426の判定が否定されるか、又はステップ430でメモリ領域の解放を要求した後にリソース管理部46Bから解放完了が通知されるとステップ432へ移行し、自モジュールの後段の個々の画像処理モジュール38に対応する有効データポインタのうち、有効データの末尾位置を表すポインタを各々更新する(図9(C)も参照)。なお、上記のポインタ更新は、ポインタが指し示す有効データの末尾位置を単位書込データ量分だけ後へ移動させることによって成されるが、自モジュールの前段の画像処理モジュール38によって今回書き込まれた画像データが処理対象の画像データの末尾に相当するデータであった場合には、前段の画像処理モジュール38による書込処理完了時に、処理対象の画像データが終了したことを表す全体処理終了通知と共に、書き込んだ画像データのサイズが前段の画像処理モジュール38から入力されるので、書込処理完了時に前段の画像処理モジュール38から全体処理終了通知が入力された場合には、同時に通知されたサイズ分だけ有効データの末尾位置を後へ移動させることでポインタ更新が行われる。
次のステップ434では、書込処理完了時に全体処理終了通知が入力されたか否かに基づいて、バッファ40Aへの処理対象の画像データの書込が終了したか否か判定する。判定が否定された場合は何ら処理を行うことなくステップ438へ移行するが、判定が肯定された場合はステップ436へ移行し、ステップ432で更新したポインタ(自モジュールの後段の個々の画像処理モジュール38に対応する有効データポインタのうち有効データの末尾位置を表すポインタ)に対し、処理対象の画像データの末尾であることを表すデータ最終位置情報を付加した後にステップ438へ移行する。そしてステップ438では待ち要求数を1だけデクリメントし、データ書込処理を終了してバッファ制御処理(図6)のステップ378に戻る。
またバッファ制御処理(図6)において、ステップ382で取り出した要求情報に対応する要求の種別が読出であった場合には、ステップ384からステップ388へ移行し、図10に示すデータ読込処理を行う。データ読出処理では、まずステップ450において、待ち行列から取り出した要求情報に含まれる要求元識別情報に基づいて読出要求元の画像処理モジュール38を認識し、読出要求元の画像処理モジュール38によって設定された単位読出データ量を認識すると共に、読出要求元の画像処理モジュール38に対応する有効データポインタに基づいて、読出要求元の画像処理モジュール38に対応する有効データのバッファ40A上での先頭位置及び末尾位置を認識する。次のステップ452では、ステップ450で認識した有効データの先頭位置及び末尾位置に基づいて、読出要求元の画像処理モジュール38に対応する有効データ(読出要求元の画像処理モジュール38が読出可能な画像データ)が単位読出データ量以上有るか否か判定する。
判定が否定された場合はステップ454へ移行し、バッファ40Aに記憶されており読出要求元の画像処理モジュール38が読出可能な有効データの末尾が処理対象の画像データの末尾か否か判定する。読出要求元の画像処理モジュール38に対応する有効データがバッファ40Aに単位読出データ量以上記憶されているか、又は、バッファ40Aに記憶されている読出要求元の画像処理モジュール38に対応する有効データが単位読出データ量未満であるものの、当該有効データの末尾が処理対象の画像データの末尾であった場合には、ステップ452又はステップ454の判定が肯定されてステップ455へ移行する。ステップ455では、読出要求元のモジュールが使用するプロセッサが、前段の画像処理モジュール38が画像処理に使用するプロセッサと同じであるか否か判定する。ステップ455で肯定判定した場合には、ステップ456へ移行する。ステップ456では、先のステップ450で認識した有効データの先頭位置に基づいて、有効データの先頭部分の画像データを記憶している単位バッファ領域を認識し、認識した単位バッファ領域に記憶されている有効データのデータ量がステップ450で認識した単位読出データ量以上か否かを判断することで、今回の読出対象の有効データが複数の単位バッファ領域に跨っているか否か判定する。
ステップ456の判定が否定された場合は何ら処理を行うことなくステップ462へ移行するが、例として図11(A)に示すように、有効データの先頭部分の画像データを記憶している単位バッファ領域に記憶されている有効データのデータ量が単位読出データ量未満であり、今回の読出対象の有効データが複数の単位バッファ領域に跨っている場合、今回の読出対象の有効データが実メモリ(第1メモリ14)上で連続する領域に記憶されているとは限らない。このため、ステップ456の判定が肯定された場合はステップ460へ移行し、確保すべきメモリ領域のサイズとして読出要求元の画像処理モジュール38に対応する単位読出データ量をリソース管理部46Bに通知すると共に、読出に用いるメモリ領域(読出用バッファ領域:図9(B)も参照)の確保をリソース管理部46Bに要求する。また、読出用バッファ領域を確保すると、次のステップ460で複数の単位バッファ領域に跨って記憶されている読出対象の有効データを、ステップ458で確保した読出用バッファ領域に複写する(図11(B)も参照)。
ステップ462では、読出対象の有効データが単一の単位バッファ領域に記憶されている場合は、当該単位バッファ領域のうち読出対象の有効データが記憶されている領域を読出領域とする一方、読出対象の有効データが複数の単位バッファ領域に跨って記憶されている場合には読出用バッファ領域を読出領域とし、当該読出領域の先頭アドレスを読出要求元の画像処理モジュール38へ通知すると共に、通知した先頭アドレスから画像データを順に読み出すよう要請する。これにより、読出要求元の画像処理モジュール38は、先頭アドレスが通知された読出領域(単位バッファ領域又は読出用バッファ領域)からの画像データの読み出しを行う(図11(C)も参照)。なお、読出対象の有効データが処理対象の画像データの末尾に相当するデータであった場合(読出対象の有効データの末尾位置が、読出要求元の画像処理モジュール38に対応する有効データポインタが指し示す有効データの末尾位置に一致しており、かつ前記ポインタにデータ最終位置情報が付加されていた場合)には、画像データの読出要請に際し、読出対象の有効データのサイズと共に、処理対象の画像データの末尾であることも読出要求元の画像処理モジュール38に通知する。
前述したように、読出対象の有効データが複数の単位バッファ領域に跨って記憶されている場合は、別途確保した読出用バッファ領域に読出対象の有効データを複写するので、読出対象の有効データが複数の単位バッファ領域に跨って記憶されているか否かに拘わらず、読出要求元の画像処理モジュール38への読出領域の通知は、上記のようにその先頭アドレスを通知するのみで済み、画像処理モジュール38とのインタフェースが簡単になる。なお、自モジュールがアプリケーション32によって生成されたバッファモジュール40である場合は、バッファ40Aとして用いているメモリ領域(単位バッファ領域の集合体)は連続領域であるので、ステップ456の判定を行う前にバッファフラグが1か否か判定し、判定が肯定された場合は読出対象の有効データが複数の単位バッファ領域に跨って記憶されているか否かに拘わらずステップ462へ移行するようにしてもよい。
次のステップ464では、読出要求元の画像処理モジュール38による読出領域からの画像データの読み出しが完了したか否か判定し、判定が肯定される迄ステップ464を繰り返す。読出要求元の画像処理モジュール38から読出完了が通知されると、ステップ464の判定が肯定されてステップ467へ移行し、上記の読出処理における読出領域が、先のステップ458で確保した読出用バッファ領域又は転送用バッファ領域か否か判定する。判定が否定された場合は何ら処理を行うことなくステップ470へ移行するが、ステップ467の判定が肯定された場合はステップ469へ移行し、上記読出用バッファ領域又は転送用バッファ領域として確保したメモリ領域の先頭アドレス及びサイズをリソース管理部46Bへ通知して、当該メモリ領域の解放をリソース管理部46Bに要求する。この読出用バッファ領域についても書込用バッファ領域と同様に、保管用単位バッファ領域のサイズが単位読出データ量の整数倍になっていない場合には、読出用バッファ領域は必ず必要となるので、初期化時に確保しておき、バッファモジュール40が消去される時に解放するよう構成しても良い。
次のステップ470では、読出要求元の画像処理モジュール38に対応する有効データポインタのうち、有効データの先頭位置を表すポインタを更新する(図11(C)も参照)。なお、上記のポインタ更新は、ポインタが指し示す有効データの先頭位置を単位読出データ量分だけ後へ移動させることによって成されるが、今回の読出対象の有効データが処理対象の画像データの末尾に相当するデータであった場合には、読出要求元の画像処理モジュール38へも通知した今回の読出対象の有効データのサイズ分だけ有効データの先頭位置を後へ移動させることでポインタ更新が行われる。
ステップ472では、後段の個々の画像処理モジュール38に対応する有効データポインタを各々参照し、ステップ470のポインタ更新により、バッファ40Aを構成する単位バッファ領域の中に、記憶している画像データの後段の各画像処理モジュール38による読み出しが全て完了した単位バッファ領域、すなわち有効データを記憶していない単位バッファ領域が出現したか否か判定する。判定が否定された場合は何ら処理を行うことなくステップ478へ移行するが、判定が肯定された場合はステップ474へ移行し、バッファフラグが1か否か判定する。自モジュールがモジュール生成部44によって生成されたバッファモジュール40である場合は判定が否定されてステップ476へ移行し、有効データを記憶していない単位バッファ領域の解放をリソース管理部46Bに要求する。
なお、自モジュールがアプリケーション32によって生成されたバッファモジュール40である場合にはステップ474の判定が肯定され、何ら処理を行うことなくステップ478へ移行する。従って、ユーザによって指定されたバッファ領域(メモリ領域)をバッファ40Aとして用いている場合には、前記バッファ領域は解放されることなく保存されることになる。そしてステップ478では待ち要求数を1だけデクリメントし、データ読み出し処理を終了してバッファ制御処理(図6)のステップ378に戻る。
一方、バッファ40Aに記憶されており読出要求元の画像処理モジュール38が読出可能な有効データのデータ量が単位読出データ量未満であり、かつ読出可能な有効データの末尾が処理対象の画像データの末尾でない場合(図15(B)の(4)で読出可能な有効データ無が検知された場合)には、ステップ452,454の判定が各々否定されてステップ480へ移行し、新たな画像データを要求するデータ要求をワークフロー管理部46Aへ出力する(図15(B)の(5)も参照)。この場合、ワークフロー管理部46Aにより、自モジュールの前段の画像処理モジュール38に処理要求が入力されることになる。またステップ482では、先のステップ382(図6)で待ち行列から取り出した要求情報を元の待ち行列の末尾に再度登録し、データ読出処理を終了する。
図6に示すように、データ読出処理を終了するとステップ378(図6)に戻るので、この場合、待ち行列の末尾に再度登録された要求情報は、待ち行列に他の要求情報が登録されていなければ直ちに、待ち行列に他の要求情報が登録されていれば他の要求情報が取り出されてこの要求情報に応じた処理が行われた後に、待ち行列から再度取り出され、図10のデータ読出処理が再度実行される。従って、後段の画像処理モジュール38から読出要求が入力されたものの、読出要求元の画像処理モジュール38が読出可能な有効データのデータ量が単位読出データ量未満であり、かつ読出可能な有効データの末尾が処理対象の画像データの末尾でない場合には、読出可能な有効データのデータ量が単位読出データ量以上になるか、読出可能な有効データの末尾が処理対象の画像データの末尾であることが検知される迄(ステップ452又はステップ454の判定が肯定される迄)、対応する要求情報が保存されてデータ読出処理が繰り返し実行されることになる。
また、ステップ455が否定判定された場合には、ステップ484へ移行する。ステップ484では、メモリの確保をリソース管理部46Bに要求する。ここでは、読出要求元が画像処理に使用するプロセッサに対応するメモリ空間に転送用バッファ領域を確保するよう、リソース管理部46Bに要求する。該要求を受けたリソース管理部46Bは、図2(B)等を参照して説明したように、読出要求元が画像処理に使用するプロセッサに対応するメモリ空間に転送用バッファ領域を確保する。なお、本実施形態では、転送用バッファ領域は、単位読出しデータ量以上のサイズを有し、複数の領域に跨って確保されないものとする。
ステップ486では、転送処理を行う。ここでは、単位バッファ領域のうち読出対象の有効データが記憶されている領域から画像データを読み出して、順次、確保された転送用バッファ領域に転送する。読出対象の有効データが複数の単位バッファ領域に跨っている場合には、該複数の単位バッファ領域から順次画像データを読み出して転送用バッファ領域に転送する。転送が終了すると、読出要求元の画像処理モジュール38に対応する有効データポインタを前述と同様に更新する。なお、転送処理は、DMA(Direct Memory Access)コントローラ等が設けられDMA転送が可能に構成されている場合には、プロセッサからDMAコントローラにDMA転送命令を出力して、その後はプロセッサを介さずに行ってもよい。
次に、ステップ462へ移行する。ステップ462が、ステップ455が否定判定されて、ステップ484及びステップ486の後に実行された場合には、読出領域のアドレスとして、転送用バッファ領域の先頭アドレスを読出要求元へ通知して、通知した先頭アドレスから画像データを順に読み出すよう要請する。これにより、読出要求元は、自身が使用するプロセッサに対応するメモリ空間から画像データを読み出して画像処理に用いることができる。
転送処理について図22を参照して説明する。図22(A)に示すように、ここでは、バッファモジュール40の前段の画像処理モジュール38が、第1プロセッサ(CPU12)を使用してバッファ制御処理を行うモジュールであって、読出対象の有効データが単一の単位バッファ領域に記憶されているものとして説明する。後段の画像処理モジュール38が第2プロセッサ(GPU52)を使用する場合、図22(B)に示すように、転送用バッファ領域を第2メモリ54に確保する。次に、当該単位バッファ領域から有効データを読み出して、転送用バッファ領域に転送する。後段のモジュールは、自身が使用するメモリ空間に確保された転送用バッファの先頭アドレスから有効データを読み出して画像処理に用いることができる。
図23は、本実施形態に係る画像データの受け渡し方法を模式的に示した図である。図23(A)には、前段の画像処理モジュール38(以下、符号をM1とする)と、後段の画像処理モジュール38(以下、符号をM2とする)の使用するプロセッサが異なる場合の処理が模式的に示されている。画像処理モジュールM1は、第1プロセッサ(CPU12)を使用し、画像処理モジュールM2は、第2プロセッサ(GPU52)を使用する。このとき。画像処理モジュールM1と画像処理モジュールM2の間に連結されたバッファモジュール40(以下、符号をB1とする)は、第2メモリ54に転送用バッファを確保して、第1メモリ14に確保されたバッファ40A(単位バッファ領域)に書き込まれた画像データを転送用バッファ領域に転送する。画像処理モジュールM2は、転送用バッファ領域に書き込まれた画像データを読み出して画像処理を行う。
図23(B)には、前段の画像処理モジュールM1と、後段の画像処理モジュールM2の使用するプロセッサが同じ場合の処理が模式的に示されている。この場合には、バッファモジュールB1は、何ら転送用バッファ領域を確保することなく、後段の画像処理モジュールM2に、第1メモリ14に確保されたバッファ40Aの有効データが記憶された記憶領域の先頭アドレスを通知する。後段の画像処理モジュールM2は、通知された先頭アドレスから順に画像データを読み出して画像処理を行う。
これにより、余計な転送処理は発生せず、画像処理部が効率的に画像処理を行うことができる。
なお、詳細は後述するが、ワークフロー管理部46Aはバッファモジュール40からデータ要求が入力されると、データ要求元のバッファモジュール40の前段の画像処理モジュール38に処理要求を入力する(図15(B)の(6)も参照)。この処理要求の入力をトリガとして前段の画像処理モジュール38の制御部38Bで行われる処理により、前段の画像処理モジュール38がバッファモジュール40へ画像データを書込可能な状態になると、前段の画像処理モジュール38から書込要求が入力されることで前述したデータ書込処理(図8)が行われ、前段の画像処理モジュール38からバッファモジュール40のバッファ40Aに画像データが書き込まれる(図15(B)の(7),(8)も参照)。これにより、後段の画像処理モジュール38によるバッファ40Aからの画像データの読出が行われることになる(図15(B)の(9)も参照)。
また、図15(B)では図示を省略したが、上記のように転送用バッファ領域が別途確保された場合には、バッファ40Aのバッファ領域から転送用バッファ領域への画像データの転送が行われ、後段の画像処理モジュール38による画転送用バッファから画像データの読出が行われることになる。
上述したように、本実施形態に係るバッファ制御処理では、前段の画像処理モジュール38から書込要求が入力されるか、又は後段の画像処理モジュールから読出要求が入力される毎に、入力された要求を要求情報として待ち行列に登録し、待ち行列から要求情報を1つずつ取り出して処理するので、データ書込処理の実行中に読出要求が入力されたり、データ読出処理の実行中に書込要求が入力された場合にも、実行中の処理が完了し入力された要求に対応する処理を実行可能な状態となる迄、入力された要求に対応する処理の実行を停止する排他制御が行われる。これにより、コンピュータ10のCPU12が画像処理部50を構成する個々のモジュールに対応するプロセス又はスレッドを並列に実行しても、単一のバッファモジュール40に複数の要求が同時又は略同時に入力されることによる不都合の発生を回避できるので、コンピュータ10のCPU12が個々のモジュールに対応するプロセス又はスレッドを並列に実行することができる。もちろん、バッファモジュールを通常のプログラムまたはオブジェクトとして実現しても良い。
続いて、画像処理部50を構成する個々の画像処理モジュール38に対してワークフロー管理部46Aから処理要求が入力される毎に、個々の画像処理モジュール38の制御部38Bによって各々行われる画像処理モジュール制御処理(図13)を説明する。なお、ここでは、画像データ供給部22がモジュールである場合には、該画像データ供給部22の直後に連結される画像処理モジュール38が使用するプロセッサは、画像データ供給部22が使用するプロセッサと同じであるものとし、画像出力部24がモジュールである場合には、画像出力部24の直前に連結される画像処理モジュール38が使用するプロセッサは、画像出力部24が使用するプロセッサと同じであるものとする。
画像処理モジュール制御処理では、まずステップ284において、自モジュールの前段にモジュール(バッファモジュール40や画像データ供給部22、画像処理モジュール38等)が存在している場合に、当該前段のモジュールに対してデータ(画像データ又は解析等の画像処理の処理結果)を要求する。なお、前段モジュールがバッファモジュール40であって画像データを要求する場合には、自モジュールが画像処理に使用するプロセッサを識別する識別情報を該要求と共に通知する。次のステップ286では、前段のモジュールからデータが取得可能であるかを判定する。判定が否定された場合は、ステップ288で全体処理終了が通知されたか否かを判定する。ステップ288の判定が否定された場合はステップ286に戻り、前段のモジュールからデータを取得可能となる迄ステップ286,288を繰り返す。ステップ286の判定が肯定された場合には、ステップ290で前段のモジュールからデータを取得するデータ取得処理を行う。
ここで、自モジュールの前段のモジュールがバッファモジュール40である場合には、先のステップ284でデータを要求する(読出要求)と共に自身が使用するプロセッサを通知すると、読出可能な有効データがバッファモジュール40のバッファ40Aに単位読出データ量以上記憶されているか、読出可能な有効データの末尾が処理対象の画像データの末尾に一致している状態であれば直ちに、当該状態でなければ、当該バッファモジュール40の前段の画像処理モジュール38が当該バッファモジュール40のバッファ40Aに画像データを書き込んだことに伴って前記状態へ変化した後に、バッファモジュール40から読出領域の先頭アドレスが通知されて(転送用バッファ領域が確保された場合には、該転送用バッファ領域の先頭アドレスが通知されて)画像データの読出が要請される(図10のステップ462も参照)。これにより、ステップ286の判定が肯定されてステップ290へ移行し、前段のバッファモジュール40より先頭アドレスが通知された読出領域から単位読出データ量(又はそれ未満のデータ量)の画像データを読み出すデータ取得処理を行う(図15(A)の(3)も参照)。
また、自モジュールの前段のモジュールが画像データ供給部22であれば、先のステップ284でデータ要求を出力すると画像データを取得可能な状態であることが前段の画像データ供給部22から直ちに通知されることで、ステップ286の判定が肯定されてステップ290へ移行し、前段の画像データ供給部22から単位読出データ量の画像データを取得する画像データ取得処理を行う。また、自モジュールの前段のモジュールが画像処理モジュール38であれば、先のステップ284でデータ要求(処理要求)を出力すると、前段の画像処理モジュール38が画像処理を実行可能な状態であれば書込要求が入力されることでデータ(画像処理結果)を取得可能な状態であることが通知されるので、ステップ286の判定が肯定されてステップ290へ移行し、前段の画像処理モジュール38によってデータを書き込ませるバッファ領域のアドレスを通知して書込を要請することで、前段の画像処理モジュール38から出力されるデータを前記バッファに書き込ませるデータ取得処理を行う。
次のステップ292では、自モジュールの前段に複数のモジュールが連結されているか否か判定する。判定が否定された場合には何ら処理を行うことなくステップ296へ移行するが、判定が肯定された場合はステップ294へ移行し、前段に連結されている全てのモジュールからデータを取得したか否か判定する。ステップ294の判定が否定された場合はステップ284に戻り、ステップ294の判定が肯定される迄ステップ284〜ステップ294を繰り返す。前段のモジュールから取得すべきデータが全て揃うと、ステップ292の判定が否定されるかステップ294の判定が肯定されてステップ296へ移行する。
次に、ステップ296で自モジュールの後段のモジュールに対してデータ出力用の領域を要求し、ステップ298でデータ出力領域が取得できる迄(データ出力領域の先頭アドレスが通知される迄)繰り返し判定を行う。なお、後段のモジュールがバッファモジュール40であれば、上記のデータ出力用領域の要求は当該バッファモジュール40に対して書込要求を出力することによって成される。データ出力領域(後段のモジュールがバッファモジュール40であれば当該バッファモジュール40から先頭アドレスが通知された書込領域)が取得できたら(図15(A)の(4)も参照)、次のステップ300において、先のデータ取得処理で取得したデータと後段のモジュールから取得したデータ出力領域(の先頭アドレス)を画像処理エンジン38Aに入力し、入力したデータに対して所定の画像処理を行わせる(図15(A)の(5)も参照)と共に、処理後のデータをデータ出力領域に書き込ませる(図15(A)の(6)も参照)。画像処理エンジン38Aへの単位読出データ量のデータの入力が完了し、画像処理エンジン38Aから出力されたデータがデータ出力領域に全て書き込まれると、次のステップ302で出力が完了したことを後段のモジュールに通知する。
上記のステップ284〜ステップ302により画像処理モジュール38における単位処理データ量のデータに対する処理(単位処理)が完了するが、ワークフロー管理部46Aから画像処理モジュール38に入力される処理要求では、ワークフロー管理部46Aによって単位処理の実行回数が指定されることがある。このためステップ304では、単位処理の実行回数が、入力された処理要求によって指示された実行回数に達したか否か判定する。指示された単位処理の実行回数が1回の場合、この判定は無条件に肯定されるが、指示された単位処理の実行回数が2回以上の場合はステップ284に戻り、ステップ304の判定が肯定される迄ステップ284〜ステップ304を繰り返す。ステップ304の判定が肯定されるとステップ306へ移行し、ワークフロー管理部46Aへ処理完了通知を出力することで、入力された処理要求に対応する処理が完了したことをワークフロー管理部46Aへ通知し、画像処理モジュール制御処理を終了する。
また、ワークフロー管理部46Aから処理要求が入力される毎に上述した処理が繰り返されることで処理対象の画像データを末尾まで処理すると、前段のモジュールから処理対象の画像データの終了が通知されることで、ステップ288の判定が肯定されてステップ308へ移行し、処理対象の画像データに対する処理が終了したことを意味する全体処理終了通知をワークフロー管理部46A及び後段のモジュールへ各々出力する。また、次のステップ310では自モジュール消去処理(後述)を行い、画像処理モジュール制御処理を終了する。
なお、スキュー角検知処理等の画像解析処理を行う画像処理エンジン38Aは、単位読出データ量単位では画像処理結果が出力されず、処理対象の画像データ全体が入力された後に画像処理結果が出力される構成であることが多いが、このような画像処理エンジン38Aを備えた画像処理モジュール38の制御部38Bでは、画像処理モジュール制御処理(図13)のステップ296,298及びステップ300における後段のモジュールへのデータの出力を行わず、処理対象の画像データを末尾まで処理することでステップ288の判定が肯定されると、画像処理エンジン38Aから出力されたデータ(画像処理結果)を自モジュールの外部(ワークフロー管理部46A又はアプリケーション32)へ出力する。そして、上記の画像処理結果を必要としている別の画像処理モジュール38(例えばスキュー角検知処理の結果に基づいて画像回転処理を行う画像処理モジュール38等)があれば、ワークフロー管理部46A又はアプリケーション32から当該画像処理モジュール38へ上記の画像処理結果が入力される。
一方、画像処理の実行形態としてブロック単位処理が指定された場合、ワークフロー管理部46Aは、アプリケーション32によって起動されると、図16(A)に示すブロック単位制御処理1を行う。先にも述べたように、ワークフロー管理部46Aによる画像処理部50の個々の画像処理モジュール38への処理要求の入力では、単位処理の実行回数を指定可能とされているが、ブロック単位制御処理1のステップ500では、1回の処理要求で指定する単位処理の実行回数を個々の画像処理モジュール38毎に決定する。この処理要求1回当りの単位処理の実行回数は、例えば処理対象の画像データ全体を処理する間の個々の画像処理モジュール38への処理要求の入力回数が平均化されるように定めることができるが、他の基準に従って定めてもよい。そして次のステップ502において、画像処理部50のうち最後段の画像処理モジュール38に処理要求を入力し(図18の(1)も参照)、ブロック単位制御処理1を終了する。
ここで、図18に示す画像処理部50において、ワークフロー管理部46Aから最後段の画像処理モジュール384に処理要求が入力されると、画像処理モジュール384の制御部38Bは前段のバッファモジュール403に読出要求を入力する(図18の(2)参照)。このとき、バッファモジュール403のバッファ40Aには画像処理モジュール384が読出可能な有効データ(画像データ)が記憶されていないので、バッファモジュール403のバッファ制御部40Bはワークフロー管理部46Aにデータ要求を入力する(図18の(3)参照)。
ワークフロー管理部46Aは、画像処理の実行形態がブロック単位処理である場合、バッファモジュール40からデータ要求が入力される毎に、図16(B)に示すブロック単位制御処理2を行う。このブロック単位制御処理2では、ステップ504において、図4(B)に示したテーブルに登録されている情報に基づいて、データ要求入力元のバッファモジュール40(ここではバッファモジュール403)の前段の画像処理モジュール38(ここでは画像処理モジュール383)を認識し、認識した前段の画像処理モジュール38に処理要求を入力(図18の(4)参照)して処理を終了する。
画像処理モジュール383の制御部38Bは、処理要求が入力されると前段のバッファモジュール402に読出要求を入力し(図18の(5)参照)、バッファモジュール402のバッファ40Aにも読出可能な画像データが記憶されていないので、バッファモジュール402のバッファ制御部40Bはワークフロー管理部46Aにデータ要求を入力する(図18の(6)参照)。ワークフロー管理部46Aは、バッファモジュール402からデータ要求が入力された場合も、前述のブロック単位制御処理2を再度行うことで、その前段の画像処理モジュール382に処理要求を入力し(図18の(7)参照)、画像処理モジュール383の制御部38Bは前段のバッファモジュール401に読出要求を入力する(図18の(8)参照)。また、バッファモジュール401のバッファ40Aにも読出可能な画像データが記憶されていないので、バッファモジュール401のバッファ制御部40Bもワークフロー管理部46Aにデータ要求を入力し(図18の(9)参照)。ワークフロー管理部46Aは、バッファモジュール401からデータ要求が入力された場合も、前述のブロック単位制御処理2を再度行うことで、その前段の画像処理モジュール381に処理要求を入力する(図18の(10)参照)。
ここで、画像処理モジュール381の前段のモジュールは画像データ供給部22であるので、画像処理モジュール381の制御部38Bは、画像データ供給部22にデータ要求を入力することで画像データ供給部22から単位読出データ量の画像データを取得し(図18の(11)参照)、取得した画像データに対して画像処理エンジン38Aが画像処理を行うことで得られた画像データを、後段のバッファモジュール401のバッファ40Aに書き込む(図18の(12)参照)。なお、画像処理モジュール381の制御部38Bは後段のバッファモジュール401のバッファ40Aへの画像データの書き込みを完了すると、ワークフロー管理部46Aへ処理完了通知を入力する。
ワークフロー管理部46Aは、画像処理の実行形態がブロック単位処理である場合、画像処理モジュール38から処理完了通知が入力される毎に、図16(C)に示すブロック単位制御処理3を行う。このブロック単位制御処理3では、ステップ506において、処理完了通知元が画像処理部50の最後段の画像処理モジュール38か否か判定する。この場合は判定が否定され、何ら処理を行うことなく処理を終了する(画像処理モジュール382,383から処理完了通知が入力された場合についても同様)。
また、バッファモジュール401のバッファ制御部40Bは、後段の画像処理モジュール382が読出可能な単位読出データ量以上の有効データが書き込まれると画像処理モジュール382に対して読出を要請し、これに伴い画像処理モジュール382の制御部38Bは、バッファモジュール401のバッファ40Aから単位読出データ量の画像データを読み出し(図18の(13)参照)、取得した画像データに対して画像処理エンジン38Aが画像処理を行うことで得られた画像データを、後段のバッファモジュール402のバッファ40Aに書き込む(図18の(14)参照)。バッファモジュール402のバッファ制御部40Bは、後段の画像処理モジュール383が読出可能な単位読出データ量以上の有効データが書き込まれると画像処理モジュール383へ読出を要請し、画像処理モジュール383の制御部38Bは、バッファモジュール402のバッファ40Aから単位読出データ量の画像データを読み出し(図18の(15)参照)、取得した画像データに対して画像処理エンジン38Aが画像処理を行うことで得られた画像データを、後段のバッファモジュール403のバッファ40Aに書き込む(図18の(16)参照)。
更に、バッファモジュール403のバッファ制御部40Bは、後段の画像処理モジュール384が読出可能な単位読出データ量以上の有効データが書き込まれると、必要な場合にはバッファ40Aから転送用バッファへの転送処理を行って、画像処理モジュール384に対して読出を要請し、これに伴い画像処理モジュール384の制御部38Bは、バッファモジュール403のバッファ40A(或いは転送処理後の転送用バッファ)から単位読出データ量の画像データを読み出し(図18の(17)参照)、取得した画像データに対して画像処理エンジン38Aが画像処理を行うことで得られた画像データを、後段のモジュールである画像出力部24へ出力する(図18の(18)参照)。また、画像処理モジュール384の制御部38Bは後段の画像出力部24への画像データの書き込みを完了すると、ワークフロー管理部46Aへ処理完了通知を入力する(図18の(19)参照)が、この場合は前述のブロック単位制御処理3のステップ506の判定が肯定されてステップ508へ移行し、最後段の画像処理モジュール38である画像処理モジュール384に処理要求を再度入力した後に処理を終了する。
この最後段の画像処理モジュール384への処理要求の再入力により、上述した処理シーケンスが再度繰り返され、処理対象の画像データに対し、ブロック単位の実行形態での画像処理が順次行われることになる。画像データ供給部22から供給される画像データが処理対象の画像データの末尾に達すると、個々の画像処理モジュール38からワークフロー管理部46Aへの全体処理終了通知の入力が、前段側の画像処理モジュール38から順次行われる。
ワークフロー管理部46Aは、画像処理の実行形態がブロック単位処理である場合、画像処理モジュール38から全体処理終了通知が入力される毎に、図16(D)に示すブロック単位制御処理4を行う。このブロック単位制御処理4では、ステップ510において、全体処理終了通知入力元の画像処理モジュール38が最後段の画像処理モジュール38か否か判定する。判定が否定された場合は何ら処理を行うことなく処理を終了するが、処理対象の画像データに対して必要な画像処理が行われた画像データが画像出力部24へ全て出力されることで、最後段の画像処理モジュール38から全体処理終了通知が入力された場合には、ステップ510の判定が肯定されてステップ512へ移行し、アプリケーション32に対して画像処理の完了を通知し(図3のステップ180も参照)、ブロック単位制御処理を終了する。そして、画像処理の完了が通知されたアプリケーション32は、ユーザに対して画像処理の完了を通知する(図3のステップ182も参照)。
このように、ブロック単位処理では、最後段の画像処理モジュール38に入力された処理要求がより前段の画像処理モジュール38へ遡り、最前段の画像処理モジュール38に到達すると、最前段の画像処理モジュール38で画像処理が行われて後段のバッファモジュール40にデータが書き込まれ、それでデータが足りるようならば処理が後段のモジュールへ進んで行くという流れで一連の画像処理が行われる。
また、画像処理の実行形態として面単位処理が指定された場合、ワークフロー管理部46Aは、アプリケーション32によって起動されると、図17(A)に示す面単位制御処理1を行う。面単位制御処理1では、前述のブロック単位制御処理1(図16(A))と同様に、1回の処理要求で指定する単位処理の実行回数を個々の画像処理モジュール38毎に決定し(ステップ540)、次のステップ542において、画像処理部50のうち最後段の画像処理モジュール38に処理要求を入力し(図18の(1)参照)、処理を終了する。また、ワークフロー管理部46Aは、画像処理の実行形態が面単位処理である場合、バッファモジュール40からデータ要求が入力される毎に、図17(B)に示す面単位制御処理2を行う。面単位制御処理2では、前述のブロック単位制御処理2(図16(B))と同様に、ステップ544において、図4(B)に示したテーブルに登録されている情報に基づいて、データ要求入力元のバッファモジュール40の前段の画像処理モジュール38を認識し、認識した前段の画像処理モジュール38に処理要求を入力して処理を終了する。
このように、画像処理の実行形態が面単位処理であっても、アプリケーション32によって起動された場合にワークフロー管理部46Aが行う処理及びバッファモジュール40からデータ要求が入力される毎にワークフロー管理部46Aが行う処理は、画像処理の実行形態がブロック単位処理のときと同一であるので、面単位処理においても、ワークフロー管理部46Aから画像処理部50の最後段の画像処理モジュール38に処理要求が入力された後は、図18の(2)〜(10)に示すように、処理要求が入力された画像処理モジュール38から前段のバッファモジュール40へのデータ要求の入力、データ要求が入力されたバッファモジュール40からワークフロー管理部46Aへのデータ要求の入力に伴うワークフロー管理部46Aから上記バッファモジュール40の前段の画像処理モジュールへの処理要求の入力が、画像処理部50の最後段の画像処理モジュール38から画像処理部50の最前段の画像処理モジュール38へ向けて順次進んでいくことになる。
また、画像処理部50の最前段の画像処理モジュール381は、ワークフロー管理部46Aから処理要求が入力されると、画像データ供給部22から単位読出データ量の画像データを取得し(図18の(11)参照)、取得した画像データに対して画像処理エンジン38Aが画像処理を行うことで得られた画像データを、後段のバッファモジュール401のバッファ40Aに書き込み(図18の(12)参照)、ワークフロー管理部46Aへ処理完了通知を入力するが、ワークフロー管理部46Aは、画像処理の実行形態が面単位処理である場合、画像処理モジュール38から処理完了通知が入力される毎に、図17(C)に示す面単位制御処理3を行う。この面単位制御処理3では、ステップ546において、処理完了通知元の画像処理モジュール38に処理要求を再度入力し、処理を終了する。このように、面単位制御処理では、ワークフロー管理部46Aに処理完了通知を入力した特定の画像処理モジュール38が処理対象の画像データに対する画像処理を完了する迄の間、前記特定の画像処理モジュール38から処理完了通知が入力される毎に、前記特定の画像処理モジュール38に対してのみ処理要求が繰り返し入力される。
画像処理モジュール381が処理対象の画像データに対する画像処理を完了し、画像処理モジュール381における画像処理を経た処理対象の画像データがバッファモジュール401のバッファ40Aに全て記憶されると、画像処理モジュール381からワークフロー管理部46Aに全体処理終了通知が入力される。ワークフロー管理部46Aは、画像処理の実行形態が面単位処理である場合、画像処理モジュール38から全体処理終了通知が入力される毎に、図17(D)に示す面単位制御処理4を行う。この面単位制御処理4では、ステップ548において、全体処理終了通知元が画像処理部50の最後段の画像処理モジュール38か否か判定する。判定が否定された場合はステップ550へ移行し、図4(B)に示したテーブルに登録されている情報に基づいて、全体処理終了通知元の画像処理モジュール38の次の画像処理モジュール38を認識し、認識した次の画像処理モジュール38に処理要求を入力して処理を終了する。
このように、面単位制御処理では、最後段の画像処理モジュール38に入力された処理要求がより前段の画像処理モジュール38へ遡り、最前段の画像処理モジュール38に到達した後は、最前段の画像処理モジュール38に対してのみ処理要求を繰り返し入力し、当該画像処理モジュール38における処理対象の画像データ全体に対する画像処理が完了すると、次の画像処理モジュール38で処理対象の画像データ全体に対する画像処理を行わせ、この処理を後段の画像処理モジュール38に対して順に進めていくことで、一連の画像処理が行われる。そして、処理対象の画像データに対して必要な画像処理が行われた画像データが画像出力部24へ全て出力されることで、最後段の画像処理モジュール38から全体処理終了通知が入力されると、面単位制御処理4(図17(D))のステップ548の判定が肯定されてステップ552へ移行し、アプリケーション32に対して画像処理の完了を通知し(図3のステップ180も参照)、面単位制御処理を終了する。そして、画像処理の完了が通知されたアプリケーション32は、ユーザに対して画像処理の完了を通知する(図3のステップ182も参照)。
なお、図17に示した面単位制御処理では、画像処理モジュールから全体処理終了通知が入力されたことを契機として、処理要求を繰り返し入力する画像処理モジュール38を切り替えていたが、これに限定されるものではなく、異なる画像処理モジュール38から処理完了通知が入力されたことを契機として、処理要求を繰り返し入力する画像処理モジュール38を切り替えるように構成することも可能である。
また、上記では最後段の画像処理モジュール38への処理要求の入力はワークフロー管理部46Aが行うものとして説明したが、本発明はこれに限定されるものではなく、パイプラインの最後段又は有向非循環グラフの複数の終点に位置するモジュールをワークフロー管理部46Aが保持して処理要求を行っても、またはアプリケーション32が保持して処理要求を行っても良い。或いは、前述した図5(B)の例のように、モジュール生成部44の内部で、スキュー角検知処理を行う画像処理モジュールと、画像回転処理を行う画像処理モジュールとを組み合わせて、スキュー補正処理モジュールとするような場合には、画像回転処理モジュールの生成時に処理パラメータとしてスキュー角情報が必要なので、スキュー補正モジュール生成部の内部で、スキュー角検知処理モジュールに処理要求を繰り返し行って画像全体を処理し、その結果得られるスキュー角情報を画像回転処理モジュールに処理パラメータとして与えるといった方式も存在する。
続いて、処理対象の画像データに対する画像処理を完了した後に行われる画像処理部50の消去について説明する。個々の画像処理モジュール38の制御部38Bは、画像処理モジュール制御処理(図13)のステップ308で、ワークフロー管理部46A及び後段のモジュールへ全体処理終了通知を出力した後に、次のステップ310において自モジュール消去処理を行う。
図14に示すように、自モジュール消去処理では、まずステップ320において、先のステップ254(図12)で確保したメモリ領域の解放をリソース管理部46Bへ要求する。これにより、リソース管理部46Bでメモリ解放要求時処理(図2(C)))が行われることで、上記のメモリ領域が解放される。次のステップ322では、リソース管理部46Bを通じて自モジュールが確保したメモリ以外のリソースが有るか否か判定する。判定が否定された場合は何ら処理を行うことなくステップ326へ移行するが、判定が肯定された場合はステップ324へ移行し、自モジュールの識別情報をリソース管理部46Bへ通知し、自モジュールが確保したメモリ以外のリソースの解放を要求する。これにより、リソース管理部46Bでリソース解放要求時処理(図2(E)))が行われることで、上記のリソースが解放される。
自モジュール消去処理(図14)では、ステップ322の判定が否定されるか、ステップ324でメモリ以外のリソースの解放をリソース管理部46Bに要求した後に、リソース管理部46Bからリソースの解放完了が通知されると、ステップ326へ移行して自モジュールの前段のモジュール、後段のモジュール及びワークフロー管理部46Aに対し、自モジュールを消去する処理を行うことを通知するための消去通知を入力する。そしてステップ328では自モジュールを消去する処理を行い、図14の自モジュール消去処理(すなわち図13のステップ310)を終了する。なお、自モジュールを消去することは、自モジュールに対応するプロセス、スレッドを終了するか、又はオブジェクトを削除することで実現することができる。
なお、バッファモジュール40のバッファ制御部40Bによって行われるバッファ制御処理(図6)では、自モジュールの前段又は後段の画像処理モジュール38から消去通知が入力されると、ステップ380の判定が肯定されてステップ390へ移行し、消去通知入力元のモジュールを記憶した後に、自モジュールの前段及び後段の全てのモジュールから消去通知が入力されたか否か判定する。判定が否定された場合はステップ378へ戻り、先にも説明したようにステップ378,380を繰り返す。また、自モジュールの前段及び後段の全てのモジュールから消去通知が入力されると、ステップ390の判定が肯定されてステップ392へ移行し、ワークフロー管理部46Aに対して消去通知を入力することで、自モジュールを消去する処理を行うことを通知する。そして次のステップ394で自モジュールを消去する処理を行ってバッファ制御処理(図6)を終了する。
最後に、画像処理部50が画像処理を実行している途中でエラーが発生した場合の処理について説明する。処理管理部46のエラー管理部46Cは、画像処理部50が画像処理を実行している途中でエラーが発生すると、割込が発生することで図19に示すエラー発生割込処理を行う。このエラー発生割込処理では、まずステップ570において、発生したエラーの種別・発生箇所等のエラー情報を取得する。また本実施形態では、画像処理プログラム群34がインストールされたコンピュータ10が組み込まれている機器の種別や構成等を表す装置環境情報が記憶部20に記憶されており、次のステップ572では上記の装置環境情報を記憶部20等から取得し、取得した装置環境情報が表す装置環境に応じたエラー通知方法を判断する。
例えばコンピュータ10がPC等の独立したコンピュータであれば、表示部16として種々の情報を一度に表示可能なディスプレイが設けられているため、エラー通知方法として、ステップ570で取得したエラー情報の内容をポップアップウインドウ等によって表示部16に全て表示させる等のエラー通知方法を選択する。また、例えばコンピュータ10が組まれている機器が複写機、プリンタ、ファクシミリ装置、複合機、スキャナ、写真プリンタ等の機器であれば、表示部16に一度に表示可能な情報量が限られている一方でブザー等が設けられているため、ブザーを鳴らすことでエラーの発生を通知すると共に、ステップ570で取得したエラー情報のうちエラーの種別のみを表示部16に表示させる等の通知方法を選択する。そしてステップ574では、ステップ572で判断したエラー通知方法でエラーの発生を通知し、エラー発生割込処理を終了する。
このように、本実施形態に係るエラー発生割込処理では、複数種のエラー通知方法の中から装置環境に応じたエラー通知方法を選択し、選択したエラー通知方法でエラーの発生を通知するので、本発明に係る画像処理プログラム群34を種々の構成のコンピュータ10にインストールして本発明を適用することが可能になり、汎用性が向上すると共に、画像処理プログラム群34をインストールするコンピュータ10の構成(独立したコンピュータか、各種機器の何れに組み込まれたコンピュータか等)に応じてエラー発生時の処理を切り替える等の設定変更作業を行う必要がなくなるので、インストール時の作業負荷も軽減される。
なお、ここではエラー処理を割込を前提に説明したが、割込処理でなくてもよい。例えばエラーが起きた際には、当該モジュールはエラー管理部46Cにエラー情報を通知し、その後の処理指示に対しては処理できない事を示す状態コードを返す。その情報を受け取った処理管理部46は、その情報をアプリケーション32に返し、アプリケーション32は処理管理部46のエラー管理部46Cからエラー情報を受け取り、それに基づいて自身で表示やブザー等の処理を行うように構成しても良い。
なお、上記では、前段の画像処理モジュール38が使用するプロセッサと後段の画像処理モジュール38が使用するプロセッサとが異なる場合に、該画像処理モジュール38の間に連結されたバッファモジュール40が転送用バッファ領域を確保して、転送処理を行い、後段のモジュールに読出を行わせるようにしたが、これに限定されない。例えば、この転送処理を、後段の画像処理モジュール38が行うようにしてもよい。この場合には、バッファモジュール40のバッファ制御部40Bは、図10に示すデータ読出処理に代えて、図24に示すデータ読出処理を実行する。ここで、図24における図10と同様の処理を行うステップについては図10と同一のステップ番号を付する。
図24に示すデータ読出処理では、ステップ455、484、486の処理は省略され、ステップ452で肯定判定された場合、或いはステップ454で肯定判定された場合には、直ちに、ステップ456の処理が実行される。また、ステップ462において、通知する読出領域のアドレスが転送用バッファ領域のアドレスとなることはない。更に、ステップ464の後は、ステップ467及びステップ469処理に代えて、ステップ466及びステップ468の処理を実行する。ステップ466では、読出処理における読出領域が、先のステップ458で確保した読出用バッファ領域か否か判定する。判定が否定された場合は何ら処理を行うことなくステップ470へ移行するが、ステップ466の判定が肯定された場合はステップ468へ移行し、先のステップ458で読出用バッファ領域として確保したメモリ領域の先頭アドレス及びサイズをリソース管理部46Bへ通知して、当該メモリ領域の解放をリソース管理部46Bに要求する。図24のデータ読出処理において上記以外のステップの処理は、図10で説明した読出処理と同様であるため、説明を省略する。
また、画像処理モジュール38の制御部38Bは、図13に示す画像処理モジュール制御処理に代えて、図25に示す画像処理モジュール制御処理を実行する。ここで、図25における図13と同様の処理を行うステップについては図13と同一のステップ番号を付する。
図25に示すように、図13に示す画像処理モジュール制御処理に対して、ステップ289(1)〜ステップ289(3)の3つの処理、及びステップ303の処理が追加されている。
ステップ286で肯定判定された後は、直ちにステップ290に移行するのではなく、まず、ステップ289(1)の処理を実行する。ステップ289(1)では、前段にバッファモジュール40が連結されている場合に、該前段のバッファモジュール40の前段の画像処理モジュール38が画像処理に使用するプロセッサが、自身が画像処理に使用するプロセッサと同じであるか否か判定する。ステップ289(1)で肯定判定した場合には、ステップ289(2)で、メモリの確保をリソース管理部46Bに要求する。ここでは、自身が画像処理に使用するプロセッサに対応するメモリ空間(例えば、自身がCPU12を使用している場合には第1メモリ14)に転送用バッファ領域を確保するよう、リソース管理部46Bに要求する。該要求を受けたリソース管理部46Bは、図2(B)等を参照して説明したように、転送用バッファ領域を確保して、その先頭アドレスを要求元の画像処理モジュール38に渡す。なお、本実施形態では、転送用バッファ領域は、単位読出しデータ量以上のサイズを有し、複数の領域に跨って確保されないものとする。
ステップ289(3)では、データ取得及び転送処理を行う。ここでは、まず、前段のバッファモジュール40から通知された読出領域のアドレスから画像データを順次読出して取得し、該読み出した画像データを上記確保した転送用バッファ領域に転送する(書き込む)。バッファモジュール40から通知された読出領域は、自身が使用するプロセッサとは異なるプロセッサに対応するメモリ空間にある。従って、転送処理は、自身のプロセッサと読出領域のメモリに対応するプロセッサとが通信して行われるが、DMA転送が可能に構成されている場合には、DMA転送命令を出力して、その後はプロセッサを介さずに行ってもよい。画像処理モジュール38は、該転送用バッファに転送された画像データに対して画像処理を行う。
一方、ステップ289(1)で否定判定した場合には、ステップ290へ移行する。ステップ290では、図13で説明したように、前段のバッファモジュール40から通知された読出領域のアドレスから画像データを読み出して、画像データを取得する。ここで取得された画像データが画像処理に用いられる。
ステップ289(3)の後は、ステップ292に移行する。ステップ292以降は、上記図13を用いて説明したように動作するが、ステップ289(3)を実行した場合には、ステップ302の後に、ステップ303の処理を実行してからステップ304に進む。ステップ303では、上記確保した転送用バッファの解放をリソース管理部46Bに要求し、ステップ289(3)を実行しなかった場合には、ステップ302の後ステップ303を実行せずにステップ304に進む。図25の画像処理モジュール制御処理において上記以外のステップの処理は、図13で説明した画像処理モジュール制御処理と同様であるため、説明を省略する。
このように、画像処理モジュール38がプロセッサの異同を判断して転送処理を行うようにする場合も、余計な転送処理は発生せず、画像処理部が効率的に画像処理を行うことができる。
なお、上記では、後段の画像処理モジュール38からバッファモジュール40に読出要求が入力されたものの、読出要求元の画像処理モジュール38が読出可能な有効データのデータ量が単位読出データ量未満であり、かつ読出可能な有効データの末尾が処理対象の画像データの末尾でない場合に、読出可能な有効データのデータ量が単位読出データ量以上になるか、読出可能な有効データの末尾が処理対象の画像データの末尾であることが検知される迄、バッファモジュール40からワークフロー管理部46Aへデータ要求が繰り返し入力される例を説明したが、これに限定されるものではなく、上記場合にバッファモジュール40はワークフロー管理部46Aへデータ要求を1回のみ入力すると共に、読出可能な有効データのデータ量が単位読出データ量以上になるか、読出可能な有効データの末尾が処理対象の画像データの末尾であることが検知されるとワークフロー管理部46Aへ蓄積完了通知を入力し、ワークフロー管理部46Aはバッファモジュール40からデータ要求が入力されてから蓄積完了通知が入力される迄の間、前記バッファモジュール40の前段の画像処理モジュール38へ処理要求を繰り返し入力するようにしてもよい。
また、上記ではバッファモジュール40において、後段の画像処理モジュール38から読出要求が入力され、読出要求元の画像処理モジュール38が読出可能な有効データが自モジュールのバッファ40Aに記憶されていなかった場合に、バッファ制御部40Bがワークフロー管理部46Aへデータ要求を入力する態様を例に説明したが、これに限定されるものではなく、上記場合にバッファ制御部40Bが前段の画像処理モジュール38へデータ要求を直接入力するようにしてもよい。この態様で画像処理の実行形態がブロック単位処理の場合の処理シーケンスを図20に示す。図20からも明らかなように、この態様において、ワークフロー管理部46Aは画像処理部50のうち最後段の画像処理モジュール38についてのみ処理要求を入力すれば済むので、ワークフロー管理部46Aにおける処理が簡単になる。
また、上記ではブロック単位の画像処理の一例として、まずワークフロー管理部46Aが画像処理部50の最後段の画像処理モジュール38へ処理要求を入力し、この処理要求がデータ要求又は処理要求として順次前段のモジュールへ伝達される態様を説明したが、これに限定されるものではなく、処理要求又はデータ要求を前段のモジュールから後段のモジュールへ順次伝達させてブロック単位の画像処理を行わせることも可能である。これは、例えばバッファモジュール40のバッファ制御部40Bを、自モジュールの前段の画像処理モジュール38によってバッファ40Aに画像データが書き込まれる毎に、後段の画像処理モジュール38が読出可能な有効データのデータ量が単位読出データ量未満で、かつ読出可能な有効データの末尾が処理対象の画像データの末尾でなければワークフロー管理部46Aへデータ要求を入力する一方、読出可能な有効データのデータ量が単位読出データ量以上になるか、読出可能な有効データの末尾が処理対象の画像データの末尾であることが検知されるとワークフロー管理部46Aへ蓄積完了通知を入力するように構成すると共に、ワークフロー管理部46Aを、画像処理部50の最後段の画像処理モジュール38へ処理要求を入力した後に、任意のバッファモジュール50からデータ要求が入力される毎に、データ要求元のバッファモジュール40の前段の画像処理モジュール38に処理要求を入力し、任意のバッファモジュール40から蓄積完了通知が入力される毎に、当該バッファモジュール40の後段の画像処理モジュール38に処理要求を入力するように構成することで実現することができる。また、上記において、バッファモジュール40からのデータ要求を当該バッファモジュール40の前段の画像処理モジュール38へ処理要求として直接入力させると共に、バッファモジュール40からの蓄積完了通知を当該バッファモジュール40の後段の画像処理モジュール38へ処理要求として直接入力させるようにしてもよい。
更に、上記ではバッファモジュール40に対し、前段の画像処理モジュール38からは単位書込データ量が、後段の画像処理モジュールからは単位読出データ量が事前に設定される態様を説明したが、これに限定されるものではなく、バッファモジュール40へのデータの書込やバッファモジュール40からのデータの読出の都度、書込又は読出のデータ量が画像処理モジュール38から通知されるようにしてもよい。
また、上記では、バッファモジュール40に書込要求又は読出要求が入力される毎に、入力された要求を要求情報として待ち行列に登録し、待ち行列から要求情報を1つずつ取り出して処理することで、書込要求入力時にバッファ40Aからのデータの読出を実行中であれば、このデータ読出が完了した後に前記書込要求に対応するデータ書込処理を行うと共に、読出要求入力時にバッファ40Aへのデータの書込を実行中であれば、このデータ書込が完了した後に前記読出要求に対応するデータ読出処理を行う排他制御を実現していたが、これに限定されるものではなく、例えば単位バッファ領域を単位とする排他制御、すなわち書込要求入力時に、バッファ40Aのうち当該書込要求における書込対象の単位バッファ領域に対してデータの読出を実行中であれば、このデータ読出が完了した後に前記書込要求に対応するデータ書込処理を行うと共に、読出要求入力時に、バッファ40Aのうち当該読出要求における読出対象の単位バッファ領域に対してデータの書込を実行中であれば、このデータ書込が完了した後に前記読出要求に対応するデータ読出処理を行うようにしてもよい。単位バッファ領域を単位とする排他制御は、例えば個々の単位バッファ領域毎に待ち行列を設けて排他制御を行う等により実現することができる。
また、上記では、モジュールライブラリ36にプログラムが登録されている個々の画像処理モジュール38のうち、単位読出データ量及び単位書込データ量が同一の画像処理モジュール38の制御部38Bに相当するプログラムを共通化した例を説明したが、これに限定されるものではなく、例えば制御部38Bに相当するプログラムを、前段のモジュールから画像データを取得して画像処理エンジン38Aに入力する第1制御部に相当するプログラム、画像処理エンジン38Aから出力されたデータを前段のモジュールへ出力する第2制御部に相当するプログラム、単位読出データ量や単位処理データ量、単位書込データ量に依存しない制御(例えばワークフロー管理部46Aとの通信等)を行う共通制御部に相当するプログラムに分割し、全ての画像処理モジュールについて、共通制御部に相当するプログラムを共通化し、更に、単位読出データ量が同一の画像処理モジュール38については第1制御部に相当するプログラムを共通化し、単位書込データ量が同一の画像処理モジュール38については第2制御部に相当するプログラムを共通化するようにしてもよい。
更に、画像処理部50を構成する個々のモジュールの実体はプログラムであるので、画像処理部50による画像処理は実際にはCPU12によって実行されるが、ここで、画像処理部50を構成する個々の画像処理モジュール38に相当するプログラムを、CPU12による実行対象のプロセス、スレッド又はオブジェクトとして待ち行列に登録し、当該待ち行列に登録した特定の画像処理モジュールに相当するプログラムがCPU12によって前記待ち行列から取り出される毎に、特定の画像処理モジュール38の前段のモジュールから単位処理データ量の画像データを取得可能か否かを判断し、単位処理データ量の画像データを取得可能と判断した場合にのみ、前記特定の画像処理モジュール38の前段のモジュールから単位処理データ量の画像データを取得し、取得した単位処理データ量の画像データに対して所定の画像処理(特定の画像処理モジュール38の画像処理エンジン38Aに相当する処理)を行い、所定の画像処理を経た画像データ又は所定の画像処理の処理結果を自モジュールの後段のモジュールへ出力する処理を行った後に、処理対象の画像全体に対する処理が終了していなければ、取り出した特定の画像処理モジュールに相当するプログラムを実行対象のプロセス、スレッド又はオブジェクトとして前記待ち行列に再登録する単位画像処理をCPU12によって繰り返させることで、画像処理部50によって処理対象の画像全体を処理させるようにしてもよい(ラウンドロビン方式)。
また、画像処理部50を構成する個々のモジュールのプログラムを、各々複数のモジュールに対応する複数のスレッドとして実行させるようにしてもよい。例えば、4個の画像処理モジュール38と、画像処理モジュール38の間に設けられたバッファモジュール40をパイプライン形態で連結した構成において、最前段の画像処理モジュール38と該画像処理モジュール38の後段のバッファモジュール40をスレッドAとして実行させ、2段目の画像処理モジュール38と該画像処理モジュール38の後段のバッファモジュール40をスレッドBとして実行させ、3段目の画像処理モジュール38と該画像処理モジュール38の後段のバッファモジュール40をスレッドCとして実行させ、4段目の画像処理モジュール38と該画像処理モジュール38の後段のバッファモジュール40をスレッドDとして実行させるように構成してもよい(図26も参照)。
すなわち、ここでは、画像処理モジュール38と、該画像処理モジュール38が画像処理した画像データの出力先である後段のバッファモジュール40との組み合わせに相当するプログラムを1つのスレッドとして扱う。この組み合わせに相当する画像処理モジュール38及びバッファモジュール40の各々が使用するプロセッサは同一である。
このように構成した場合、更に、スレッドを構成する画像処理モジュール38及びバッファモジュール40が実行すべき処理をタスクとしたときに、該タスクを登録する先入れ先出し型(FIFO)のバッファ(以下、キューと呼称する)を、画像データの処理単位毎に設けることもできる。各キューは、メインプロセッサが主として使用するメインメモリに設けるようにしてもよい。画像処理モジュール38やバッファモジュール40が実行すべき処理は、スレッドからキューにタスクとして登録され、キューへの登録順にタスクが該当のプロセッサで実行されるように構成する。
ここでは、画像処理モジュール38により実行される画像処理を画像処理タスクとし、画像処理モジュール38或いはバッファモジュール40により実行される転送処理を転送処理タスクと呼称する。なお、転送処理とは、図10のステップ486、或いは図24のステップ289で実行される転送処理をいう。処理単位毎の画像データの各々に対してキューを設け、これらタスクをキューに格納された順に実行することで、画像処理と転送処理とが並列に実行され、転送時間の隠蔽を行うことができる。
以下、図26を参照して、具体例を挙げてより詳細に説明する。図26(A)に、メインプロセッサである第1プロセッサと、アクセラレータ、或いはコプロセッサなどの別のプロセッサである第2プロセッサとにより画像処理部を構築したときの各モジュールの連結状態の例を示した。ここでは、画像処理部に含まれる画像処理モジュール38の各々をM1、M2、M3、M4の符号で表し、各画像処理モジュール38の後段のバッファモジュール40の各々をB1、B2、B3、B4の符号で表わした。以下、画像処理モジュールについては、符号38に代えてM1〜M4の符号を用い、バッファモジュールについては、符号40に代えて、B1〜B4の符号を用いて区別して説明する。
画像処理モジュールM1、及び画像処理モジュールM4は、第1プロセッサを使用して画像処理を行う。画像処理モジュールM1で処理された画像データの出力先となるバッファモジュールB1、及び画像処理モジュールM4で処理された画像データの出力先となるバッファモジュールB4は、画像処理モジュールM1、M4が使用する第1プロセッサに対応するメモリ(第1メモリ)に、前段の画像処理モジュールが画像データの書き込みを行うためのバッファを確保する。
一方、画像処理モジュールM2、及び画像処理モジュールM2は、第2プロセッサを使用して画像処理を行う。画像処理モジュールM2で処理された画像データの出力先となるバッファモジュールB2、及び画像処理モジュールM3で処理された画像データの出力先となるバッファモジュールB3は、画像処理モジュールM2、M3が使用する第2プロセッサに対応するメモリ(第2メモリ)に、前段の画像処理モジュールが画像データの書き込みを行うためのバッファを確保する。
なお、前述したように、画像処理モジュールM1とバッファモジュールB1との組み合わせをスレッドAとする。また、画像処理モジュールM2とバッファモジュールB2との組み合わせをスレッドBとする。また、画像処理モジュールM3とバッファモジュールB3との組み合わせをスレッドCとする。また、画像処理モジュールM4とバッファモジュールB4との組み合わせをスレッドDとする。
画像処理モジュールM1及び画像処理モジュールM2は使用するプロセッサが互いに異なるため、画像データの転送処理が必要となる。また、画像処理モジュールM2及び画像処理モジュールM3は、互いに使用するプロセッサが同じであるため、転送処理は不要である。画像処理モジュールM3及び画像処理モジュールM4は使用するプロセッサが互いに異なるため、画像データの転送処理が必要となる。
また、図示は省略するが、処理対象の画像データが画像処理部に供給される毎に、モジュール生成部44により、キュー管理部を備えたキューモジュールが生成される。キューモジュールの各々は、メインプロセッサである第1プロセッサを使用するものとする。モジュール生成部44によりキューモジュールが生成され起動されると、まず、第1メモリからキューとしてのメモリ領域を確保し(例えば、リソース管理部46Bに要求する)、各スレッドからのタスクの登録を待つ。各スレッドは、互いに非同期で画像処理タスク及び転送タスクをキューに登録する登録要求をキューモジュールに対して発行する。これにより、キューモジュールのキュー管理部は自身が管理するキューに登録が要求されたタスクを登録する。このように、キューへのタスクの登録は、各スレッドからのキューモジュールへの登録要求並びに登録要求を受けたキュー管理部の登録処理により完了する。以下では、キューにタスクを登録する、という簡単な表現により、これら一連の処理を表わすものとする。
このように、キューは画像データの処理単位毎に設けられる。処理単位は特に限定されないが、ここでは、一例として、動画1フレーム分の画像データを1処理単位とし、処理単位となる1フレーム毎の3つの画像データを、画像0、画像1、画像2という識別文字により各々区別して表す。図26(B)に示すように、画像データ毎にキューが生成される。画像データは、画像0、画像1、画像2の順に処理される。
ここで、画像処理モジュールM1により画像処理が終了した後、画像処理モジュールM4で前段の画像処理モジュールM3が画像処理した画像データを受け取るまでの動作に着目して説明する。なお、前述したように、前後のモジュールで使用するプロセッサが異なる場合には、プロセッサ間の転送処理が行われる。図26(A)では、バッファモジュールB1と画像処理モジュールM2との間の画像データの授受において行われる転送処理タスクを、T0という符号で表わし、バッファモジュールB3と画像処理モジュールM4との間の画像データの授受において行われる転送処理タスクを、T1という符号で表わした。また、画像処理モジュールM2の画像処理タスクをIP0という符号で表わし、画像処理モジュールM3の画像処理タスクをIP1という符号で表わした。
まず最初に、画像処理モジュールM4から前段のバッファモジュールB3に対して、画像0の画像データの読出要求を出す。バッファモジュールB3のバッファに画像処理モジュールM3で画像処理された画像データが書き込まれていなければ、画像データの書き込みを前段の画像処理モジュールM3に要求する。これを繰り返し、順に前段のモジュールに対して画像データの要求がなされる。該要求をトリガとして、各スレッドは該当のタスクを該当の画像データのキューに非同期に登録する。
例えば、スレッドAは、画像0のキューに、画像処理モジュールM1の画像処理タスクを登録した後(不図示)、今度は転送処理タスクT0を画像0のキューに登録する。スレッドBは、前段のスレッドAの画像0に対するタスク登録を待って、自身の画像処理タスクIP0を画像0のキューに登録する。スレッドCは、前段のスレッドBの画像0に対するタスク登録を待って、自身の画像処理タスクIP1を登録し、その後、画像0のキューに転送処理タスクT1を登録する。
その後、画像1の画像データの要求が発生すると、各スレッドは画像0の場合と同様に、画像1のキューに順次タスクを登録していく。画像データ毎にキューが設けられているため、各スレッドは、画像0に対するタスクとは独立に、各々非同期で画像1に対するタスクを画像1のキューに登録していく。その後、画像2の画像データの要求が発生した場合も同様に、それぞれのスレッドが順に画像2のキューにタスクを登録する。
このように、前段のモジュールの処理完了を待たずに(但し、前段のスレッドによるタスクの登録は待つ)、各スレッドはキューにタスクを投入する。転送処理や画像処理を実際に行うのは、投入されたタスクに対応するプロセッサである。画像0、画像1、画像2の各々のキューに登録されたタスクが、登録された順に各タスクに対応するプロセッサによって読み出される。プロセッサは、読み出したタスクを実行する。こうして、キューに登録されたタスクの全てが順に実行され終了すれば、該キューに対応する画像データに対する画像処理が終了したこととなる。
このように、1つのキューに登録されているタスク(すなわち、同じ画像データに対するタスク)は、その登録順に実行されることとなるが、例えば、画像0の画像処理タスクと、画像1の画像データの転送処理タスクとは並行して処理できる。
例えば、各プロセッサにDMA(Direct Memory Access)を制御するDMAコントローラを設け、DMAコントローラに、プロセッサから画像データのDMA転送命令を発行すれば、該転送命令発行後、DMA転送中は、該プロセッサは、他の画像データの画像処理タスクを実行することができる。例えば、第1プロセッサが画像1の転送処理タスクT0を画像1のキューから取り出して転送命令を発行した後、画像0の画像処理タスクをキューから取り出して実行することができる。このように、転送処理と画像処理とを並列に行うことで、転送時間の隠蔽を行うことができる。なお、ここではDMA転送を例に挙げて説明したが、これに限定されず、例えば、プロセッサが複数のコアを有している場合、例えば、1つのコアで画像処理タスクを実行し、それとは別のコアで転送処理タスクを実行するようにしてもよい。これによっても、上記と同様に転送処理と画像処理とを並列に行うことができる。
但し、複数のスレッドを使用することにより発生するオーバーヘッドや、キューモジュールへのタスク登録・終了待ちのオーバーヘッド等、本構成を取ることにより発生するオーバーヘッドが、隠蔽すべき転送時間を超えてしまう場合には、本構成を採用しなくてもよい。
ところで、上記実施形態では、アプリケーション32から、モジュール生成部44に対して、CPU12及びGPU52の何れのプロセッサを使用して画像処理を行なうのかを指定して、画像処理モジュール38の各々を生成させる例について説明したが、これに限定されない。例えば、モジュール生成部44が、画像処理モジュール38の画像処理エンジン38Aで行う画像処理に特化或いは適しているプロセッサを自律的に決定して割り当てるようにしてもよい。また、例えば、上記転送処理が発生する回数が低下するように、使用するプロセッサが異なるモジュールが前後に連結される箇所の数が閾値未満となるように、各画像処理モジュール38のプロセッサを決定するようにしてもよい。また、上記2つの決定方法を組み合わせて画像処理モジュール38が使用するプロセッサを決定して生成するようにしてもよい。
また、上記実施形態では、2つのプロセッサを使用して画像処理部を構築し、所望の画像処理を実行する例について説明したが、3以上のプロセッサを使用して画像処理部を構築してもよい。更に又、上記実施形態では、複数のプロセッサが搭載された1つのコンピュータ10が画像処理装置として機能する例を説明したが、これに限定されない。例えば、互いに独立した装置として構成された複数のコンピュータの各々で、各コンピュータに搭載されたプロセッサを使用して画像処理する画像処理モジュール38を生成する。画像処理モジュール38の間には、バッファモジュール40を設ける。そして、複数のコンピュータをネットワークを介して連結することにより、複数のモジュールが連結されてなる画像処理部を構築して、所望の画像処理を行うようにしてもよい。この場合であっても、上記実施形態で説明したように必要に応じて転送用バッファを確保して効率的に画像データの受け渡しを行うことができる。なお、この場合、各コンピュータに、プロセッサと独立に動作してデータの送受信を行う通信処理部を設け、プロセッサから該通信処理部に転送命令を発行して、その後は、プロセッサを介さずに通信処理部により画像データの転送処理を実行させるようにしてもよい。
また、上記では、第1メモリ14及び第2メモリ54を物理的に異なるメモリとして説明したが、これに限定されない。例えば、第1メモリ14及び第2メモリ54が、仮想的に異なるメモリ空間とされていてもよい。