以下、図面を参照して実施形態の一例を詳細に説明する。
図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のプログラムと、処理管理部46のプログラムに大別される。詳細は後述するが、本実施形態に係る処理構築部42は、アプリケーションからの指示により、例として図4に示すように、予め定められた画像処理を行う1つ以上の画像処理モジュール38と、個々の画像処理モジュール38の前段及び後段の少なくとも一方に配置され画像データを記憶するためのバッファを備えたバッファモジュール40と、がパイプライン形態又はDAG(Directed Acyclic Graph:有向非循環グラフ)形態で連結されて成る画像処理部50を構築する。画像処理部50を構成する個々の画像処理モジュールの実体はCPU12によって実行されCPU12で予め定められた画像処理を行わせるためのプログラムであり、上述したモジュールライブラリ36には、予め定められた互いに異なる画像処理(例えば入力処理やフィルタ処理、色変換処理、拡大・縮小処理、スキュー角検知処理、画像回転処理、画像合成処理、出力処理等)を行う複数種の画像処理モジュール38のプログラムが各々登録されている。
個々の画像処理モジュール38は、例として図12(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を実装する各種機器で必要とされる画像処理に応じて、追加・削除・入替等してよい。
個々の画像処理モジュール38は、対応するプログラムが、画像処理装置に設けられたプログラム実行リソース(該対応するプログラムを実行するために用いられるリソース)によって並列に実行されるように構成することで実現される。プログラム実行リソースは、例えばCPU、或いはMMX(MultiMedia eXtention)用の演算器やSSE (Streaming SIMD Extension)用の演算器、或いはCPUと別に設けられたDSP(Digital Signal Processor)等の高速演算器等が挙げられるが、本実施の形態では、プログラム実行リソースとしてCPUを用いる場合を例に挙げて説明する。
また、画像処理部50を構成する個々のバッファモジュール40は、例として図12(B)にも示すように、コンピュータ10に設けられたメモリ14からオペレーティングシステム30を通じて確保されたメモリ領域で構成されるバッファ40Aと、バッファモジュール40の前段及び後段のモジュールとの画像データの入出力及びバッファ40Aの管理を行うバッファ制御部40Bから構成されている。個々のバッファモジュール40のバッファ制御部40Bもその実体はCPU12によって実行されるプログラムであり、モジュールライブラリ36にはバッファ制御部40Bのプログラムも登録されている(図1ではバッファ制御部40Bのプログラムを「バッファモジュール」と表記して示している)。
また、アプリケーション32からの指示に従って画像処理部50を構築する処理構築部42は、図1に示すように複数種のモジュール生成部44から構成されている。複数種のモジュール生成部44は互いに異なる画像処理に対応しており、アプリケーション32によって起動されることで、対応する画像処理を実現するための画像処理モジュール38及びバッファモジュール40から成るモジュール群を生成する処理を行う。なお、図1ではモジュール生成部44の一例として、モジュールライブラリ36に登録されている個々の画像処理モジュール38が実行する画像処理の種類に対応するモジュール生成部44を示しているが、個々のモジュール生成部44に対応する画像処理は、複数種の画像処理モジュール38によって実現される画像処理(例えばスキュー角検知処理と画像回転処理から成るスキュー補正処理)であってもよい。必要とされる画像処理が複数種の画像処理を組み合わせた処理である場合、アプリケーション32は複数種の画像処理の何れかに対応するモジュール生成部44を順次起動する。これにより、アプリケーション32によって順次起動されたモジュール生成部44により、必要とされる画像処理を行う画像処理部50が構築されることになる。
また図1に示すように、処理管理部46は、画像処理部50における画像処理の実行を制御するワークフロー管理部46A、画像処理部50の各モジュールによるメモリ14や各種のファイル等のコンピュータ10のリソースの使用を管理するリソース管理部46B、及び、画像処理部50で発生したエラーを管理するエラー管理部46Cを含んで構成されている。なお、本実施形態において、処理構築部42によって構築される画像処理部50は、画像処理部50を構成する個々の画像処理モジュール38が、画像1面分よりも小さいデータ量を単位として後段へ画像データを引き渡しながら並列に画像処理を行うように動作する(ブロック単位処理と称する)。
なお、リソース管理部46Bによるメモリ管理の方式としては、例えば、画像処理部50の個々のモジュールからの要求の都度、メモリ14から要求元のモジュールに割り当てるメモリ領域をオペレーティングシステム30を通じて確保する第1管理方式、メモリ14から予め定められたサイズのメモリ領域をオペレーティングシステム30を通じて事前に(例えばコンピュータ10の電源投入する際に)確保し、個々のモジュールからの要求があると、事前に確保したメモリ領域のうちの一部領域を要求元のモジュールに割り当てる第2管理方式、及び、メモリ14から予め定められたサイズのメモリ領域をオペレーティングシステム30を通じて事前に確保し、個々のモジュールからの要求があると、要求されたメモリ領域のサイズが閾値未満であれば事前に確保したメモリ領域のうちの一部領域を要求元のモジュールに割り当て、要求されたメモリ領域のサイズが閾値以上であれば要求元のモジュールに割り当てるメモリ領域をオペレーティングシステム30を通じて確保する第3管理方式の何れかを採用してもよい。また、何れの管理方式でメモリ管理を行うかを選択・設定するようにしてもよい。
またエラー管理部46Cは、画像処理部50が画像処理を実行している途中でエラーが発生した場合に、発生したエラーの種別・発生箇所等のエラー情報を取得し、画像処理プログラム群34がインストールされたコンピュータ10が組み込まれている機器の種別や構成等を表す装置環境情報を記憶部20等から取得し、取得した装置環境情報が表す装置環境に応じたエラー通知方法を判断し、判断したエラー通知方法でエラーの発生を通知する処理を行う。
次に本実施形態の作用を説明する。画像処理プログラム群34が実装されている機器において、何らかの画像処理を行う必要のある状況になると、この状況が特定のアプリケーション32によって検知され、当該アプリケーション32によって図2に示す処理が行われる。なお、画像処理を行う必要のある状況としては、例えば画像データ供給部22としての画像読取部によって画像を読み取り、画像出力部24としての画像記録部により記録材料に画像として記録するか、画像出力部24としての表示部に画像として表示させるか、画像出力部24としての書込装置により画像データを記録メディアに書き込むか、画像出力部24としての送信部により画像データを送信するか、画像出力部24としての画像記憶部に記憶させる処理の実行がユーザによって指示された場合、或いは、画像データ供給部22としての受信部によって受信されるか、画像データ供給部22としての画像記憶部に記憶されている画像データに対して、上記の記録材料への記録、表示部への表示、記録メディアへの書き込み、送信、画像記憶部への記憶の何れかを行う処理の実行がユーザによって指示された場合が挙げられる。また、画像処理を行う必要のある状況は上記に限られるものではなく、例えばユーザからの指示に応じてアプリケーション32が実行可能な処理の名称等を表示部16に一覧表示している状態で、実行対象の処理がユーザによって選択された等の場合であってもよい。
上記のように、何らかの画像処理を行う必要のある状況になったことを検知すると、アプリケーション32は、まず画像処理対象の画像データを供給する画像データ供給部22の種別を認識し(図2のステップ150も参照)、認識した種別がバッファ領域(メモリ14の一部領域)であった場合(図2のステップ152の判定が肯定された場合)には、画像データ供給部22として指定されたバッファ領域を含むバッファモジュール40を生成する(図2のステップ154も参照)。後述するバッファモジュール40の新規生成では、バッファモジュール40のバッファ制御部40Bのプログラムを実行するスレッド(又はプロセス又はオブジェクト)を生成することでバッファ制御部40Bを生成し、生成されたバッファ制御部40Bによりバッファ40Aとして使用するメモリ領域が確保されることによって成されるが、このステップ154におけるバッファモジュール40の生成は、指定されたバッファ領域を既に確保されたバッファ40Aとして(バッファ制御部40Bに)認識させるパラメータを設定してバッファ制御部40Bを生成する処理を行うことによって成される。ここで生成されたバッファモジュール40は画像データ供給部22として機能する。
続いてアプリケーション32は、上記と同様に、画像処理を行った画像データの出力先としての画像出力部24の種別を認識し(図2のステップ156も参照)、認識した種別がバッファ領域(メモリ14の一部領域)であった場合(図2のステップ158の判定が肯定された場合)は、画像出力部24として指定されたバッファ領域を含むバッファモジュール40を上記と同様にして生成する(図2のステップ160も参照)。ここで生成されたバッファモジュール40は画像出力部24として機能する。また、アプリケーション32は実行すべき画像処理の内容を認識し、実行すべき画像処理を、個々のモジュール生成部44に対応するレベルの画像処理の組み合わせに分解し、実行すべき画像処理を実現するために必要な画像処理の種類及び個々の画像処理の実行順序を判定する(図2のステップ162も参照)。なお、この判定は、例えば上記の画像処理の種類及び個々の画像処理の実行順序を、ユーザが実行を指示可能な処理の種類と対応付けて予め情報として登録しておき、アプリケーション32は、実行が指示された処理の種類に対応する情報を読み出すことによって実現する。
そしてアプリケーション32は、上記で判定した画像処理の種類及び実行順序に基づいて、まず実行順序が1番の画像処理に対応するモジュール生成部44を起動(モジュール生成部44のプログラムを実行するスレッド(又はプロセス又はオブジェクト)を生成)した後に(図2のステップ164も参照)、起動したモジュール生成部44に対し、当該モジュール生成部44によるモジュール群の生成に必要な情報として、前記モジュール群に画像データを入力する入力モジュールを識別するための入力モジュール識別情報、前記モジュール群が画像データを出力する出力モジュールを識別するための出力モジュール識別情報、前記モジュール群に入力される入力画像データの属性を表す入力画像属性情報、実行すべき画像処理のパラメータを通知し、対応するモジュール群の生成を指示する(図2のステップ166も参照)。
なお、上記の入力モジュールは、実行順序が1番目のモジュール群については画像データ供給部22が入力モジュールとなり、実行順序が2番目以降のモジュール群については前段のモジュール群の最終モジュール(通常はバッファモジュール40)が入力モジュールとなる。また、上記の出力モジュールについては、実行順序が最後のモジュール群では画像出力部24が出力モジュールとなるので、画像出力部24が出力モジュールとして指定されるが、その他のモジュール群では出力モジュールは未確定のためにアプリケーション32による指定は行われず、必要な場合はモジュール生成部44によって生成・設定される。また、入力画像属性や画像処理のパラメータについては、例えばユーザが実行を指示可能な処理の種類と対応付けて予め情報として登録しておき、実行が指示された処理の種類に対応する情報を読み出すことでアプリケーション32が認識するようにしてもよいし、ユーザに指定させるようにしてもよい。
一方、モジュール生成部44は、アプリケーション32によって起動されると図3(A)に示すモジュール生成処理を行う(図2のステップ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)である場合(例えば図4(A)から(C)に示す画像処理部50における最後段の画像処理モジュール38を参照)や、例として図4(B)に示す画像処理部50においてスキュー角検知処理を行う画像処理モジュール38のように、画像処理モジュールが、画像データに対して解析等の画像処理を行いその結果を他の画像処理モジュール38へ出力するモジュールである場合は否定され、バッファモジュール40の生成を行うことなくステップ210へ移行するが、上記以外の場合は判定が肯定されてステップ208へ移行し、バッファ制御部40Bを起動する(バッファ制御部40Bのプログラムを実行するスレッド(又はプロセス又はオブジェクト)を生成する)ことで、画像処理モジュールの後段に連結するバッファモジュール40を生成する。バッファ制御部40Bは、モジュール生成部44(或いは前述したアプリケーション32)によって起動されると図5に示すバッファ制御処理を行う。このバッファ制御処理については後述する。
次のステップ210では、前段のモジュール(例えばバッファモジュール40)の情報と後段のバッファモジュール40の情報、画像処理モジュール38に入力される入力画像データの属性、処理パラメータを与えて、画像処理モジュール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に通知された情報は、例えば図3(B)に示すテーブル形式やリスト形式、連想配列形式等でワークフロー管理部46Aの内部に保持され、後の処理で使われる。ここではテーブル形式で保持するものとして説明を続ける。
なお、先程述べた後段のバッファモジュール40を持たない画像処理モジュール38の場合には、例えば下記の方法で処理を行う。図4(A)において出力処理を行う画像処理モジュール38のように、生成する画像処理モジュール38がパイプラインの終点又は有向非循環グラフの終点の一つである場合には、当該画像処理モジュール38をモジュール生成部44の出力として呼び出し元のアプリケーション32に戻す。また、図4(B)においてスキュー角検知処理を行う画像処理モジュール38のように、生成した画像処理モジュール38における画像処理の結果が他の画像処理モジュール(図4(B)では画像回転処理を行う画像処理モジュール38)で使われる場合、モジュール生成部44は、当該画像処理モジュール38に対して処理が終了するまで繰り返し処理実行を指示して、処理結果を取得する。
ステップ212の処理が終了すると、モジュール生成部44は制御をステップ200に戻して次に生成すべき画像処理モジュールがあるか否かを判定する。なお、個々のモジュール生成部44は、対応する予め定められた画像処理を行うモジュール群を生成するので、この判定は、個々のモジュール生成部44毎にどのような画像処理モジュールをどのような接続関係で生成するかに関する情報を予め登録して読み出すか、又はモジュール生成部44を動作させるプログラム中に記述しておくことでも実現する。例えば実行中のモジュール生成処理に対応するモジュール生成部44が、複数種の画像処理モジュール38によって実現される画像処理(例えばスキュー角検知処理を行う画像処理モジュール38と画像回転処理を行う画像処理モジュール38によって実現されるスキュー補正処理)を行うモジュール群を生成する場合には、2個以上の画像処理モジュール38を含むモジュール群が生成される。
アプリケーション32は、モジュール群の生成を指示したモジュール生成部44から、上記のようにしてモジュール群の生成完了が通知されると、図2のステップ162における判定の結果に基づいて、必要とされる画像処理を実現するために他の画像処理を行うモジュール群も生成する必要があるか否か判断する。必要とされる画像処理が複数種の画像処理を組み合わせた処理である場合、アプリケーション32は、個々の画像処理に対応する他のモジュール生成部44を起動してモジュール群の生成に必要な情報を通知する処理を順次行う(図2のステップ170,172も参照)。そして、順次起動されたモジュール生成部44によって上述したモジュール生成処理(図3)が順次行われる(図2のステップ174も参照)ことで、例として図4(A)から(C)に示すように、必要とされる画像処理を行う画像処理部50が構築されることになる。
なお、本実施形態では、特定の画像処理の実行頻度が高い等の場合に、アプリケーション32が、特定の画像処理を行う画像処理部50を生成するための複数種のモジュール生成部44に対し、特定の画像処理を行う画像処理部50を生成させた後も処理終了を指示しないことでスレッド(又はプロセス又はオブジェクト)として残しておき、特定の画像処理を行う必要が生ずる毎に、スレッド(又はプロセス又はオブジェクト)として残しておいた各モジュール生成部44に対してモジュール群の生成を順次指示することで、特定の画像処理を行う画像処理部50を再生成可能に構成されている。これにより、特定の画像処理を行う必要が生ずる毎に対応する各モジュール生成部44を各々起動する処理が不要となり、特定の画像処理を行う画像処理部50を再生成するのに要する時間を短縮される。
ところで、画像処理モジュール38の制御部38Bは、モジュール生成部44によって起動されると図10に示す画像処理モジュール初期化処理を行う。この画像処理モジュール初期化処理では、まずステップ250において、モジュール生成部44がモジュール生成処理(図3)のステップ210の処理を行うことでモジュール生成部44から与えられた自モジュールの前段及び後段のモジュールの情報を記憶する。また、次のステップ252では、自モジュールの画像処理エンジン38Aが行う画像処理の種類や内容等に基づき、自モジュールが使用するメモリのサイズ及び自モジュールが使用する他のリソースを認識する。なお、自モジュールが使用するメモリは、画像処理エンジン38Aが画像処理を行うために必要なメモリが主であるが、前段のモジュールが画像データ供給部22である場合や後段のモジュールが画像出力部24である場合には、前段又は後段のモジュールとの画像データの送受に際して画像データを一時記憶するためのバッファ用のメモリが必要となることもある。また、処理パラメータにテーブル等の情報が含まれている場合には、それを保持するためのメモリ領域が必要となることもある。そしてステップ254では、ステップ252で認識したサイズをリソース管理部46Bへ通知すると共に、通知したサイズのメモリ領域の確保をリソース管理部46Bへ要求し、リソース管理部46Bによって確保されたメモリ領域をリソース管理部46Bから受け取る。
図10に示す画像処理モジュール初期化処理(画像処理モジュール38の制御部38B)では、上記の処理を経てリソース管理部46B経由で必要なメモリ領域を確保すると、次のステップ256において、先のステップ252の処理結果に基づき、メモリ以外の他のリソースを自モジュール(の画像処理エンジン38A)が必要としているか否か判定する。判定が否定された場合は何ら処理を行うことなくステップ262へ移行するが、判定が肯定された場合はステップ258へ移行し、自モジュールが必要としているメモリ以外の他のリソースの種類等をリソース管理部46Bへ通知すると共に、通知した他のリソースの確保をリソース管理部46Bへ要求して確保する。
次に、ステップ262では自モジュールの前段のモジュールを判定し、自モジュールの前段にモジュールが存在していない場合にはステップ272へ移行し、前段のモジュールがバッファモジュール40以外、例えば画像データ供給部22や特定のファイル等である場合には、必要に応じてステップ270でその初期化処理を行ってステップ272に移る。また、自モジュールの前段にモジュールが存在しており、当該前段のモジュールがバッファモジュール40であった場合には、ステップ262からステップ264へ移行し、前段のバッファモジュール40からの1回の画像データの読み出しによって取得する画像データのデータ量(単位読出データ量)を認識する。この単位読出データ量は、自モジュールの前段のバッファモジュール40の数が1個であれば1個だけであるが、例えば図4(C)に示す画像処理部50において画像合成処理を行う画像処理モジュール38のように、前段のバッファモジュール40の数が複数で、複数のバッファモジュール40から各々取得した画像データを用いて画像処理エンジン38Aが画像処理を行う等の場合、前段の個々のバッファモジュール40に対応する単位読出データ量は、自モジュールの画像処理エンジン38Aが行う画像処理の種類や内容、前段のバッファモジュール40の数等に応じて定まる。
ステップ266では、ステップ264で認識した単位読出データ量を前段の単一のバッファモジュール40へ通知することで、当該バッファモジュール40に対して単位読出データ量を設定する(図12(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で後段のバッファモジュールに当該単位書込データ量を設定(図12(A)の(2)も参照)した後に、ステップ280に移る。ステップ280では、当該画像処理モジュール初期化処理の完了をモジュール生成部44に通知して、画像処理モジュール初期化処理を終了する。
一方、画像処理部50を構成する個々のバッファモジュール40のバッファ制御部40Bは、モジュール生成部44又はアプリケーション32によって起動されると図5に示すバッファ制御処理を行う。このバッファ制御処理では、モジュール生成部44又はアプリケーション32によって起動されてバッファモジュール40の生成が指示されると、ステップ356で待ち要求数を0に初期化する。また、次のステップ358では、自モジュールの前段の画像処理モジュール38から単位書込データ量が通知されるか又は自モジュールの後段の画像処理モジュール38から単位読出データ量が通知されたか否か判定する。判定が否定された場合はステップ362へ移行し、自モジュールと連結されている全ての画像処理モジュール38から単位書込データ量又は単位読出データ量が通知されたか否か判定する。判定が否定された場合はステップ358に戻り、ステップ358又はステップ362の判定が肯定される迄ステップ358,362を繰り返す。
自モジュールと連結されている特定の画像処理モジュール38から単位書込データ量又は単位読出データ量が通知されると、ステップ358の判定が肯定されてステップ360へ移行し、通知された単位書込データ量又は単位読出データ量を記憶した後にステップ358に戻る。従って、自モジュールと連結されている個々の画像処理モジュール38の制御部38Bによって画像処理モジュール初期化処理(図10)のステップ266又はステップ276の処理が行われることで、前記個々の画像処理モジュール38から単位書込データ量又は単位読出データ量が通知される毎に、通知された単位書込データ量又は単位読出データ量が記憶されることで、通知された単位書込データ量又は単位読出データ量がバッファモジュール40に設定される(図12(B)の(1),(2)も参照)。
自モジュールと連結されている全ての画像処理モジュール38から単位書込データ量又は単位読出データ量が通知され、通知された単位書込データ量及び単位読出データ量が各々設定されると、ステップ362の判定が肯定されてステップ363へ進む。
ステップ363では、自モジュールと連結されている個々の画像処理モジュール38によって各々設定された単位書込データ量及び単位読出データ量に基づいて、起動条件を設定する。起動条件とは、自モジュールと連結されている後段の画像処理モジュール38を起動させるための条件である。後述するように、画像処理モジュール38は、処理要求を入力すると待機状態から起動し、前段のバッファモジュールから画像データを取得して画像処理を開始する。一方、前段のバッファモジュールからの画像データの取得に失敗すると、画像処理の実行を停止して待機状態へ移行し(図11のステップ289も参照。)、次に処理要求が入力されるまで待機状態を継続する。
例えば、「自モジュールに設定された単位読出データ量の有効データ(後述)が自モジュールのバッファ40Aに書き込まれる毎に起動する」という単純な起動条件もあるが、起動にも時間を要するため、常にこうした起動条件で起動させると、オーバーヘッドが大きくなり連結された各画像処理モジュール38が並列に画像処理する時間が短くなる場合もあるため、本実施の形態では一律に起動条件を設定するのではなく、連結された画像処理モジュール38に応じて起動条件を決定して、設定している。起動条件の具体例については後述する。
ステップ364では、自モジュールと連結されている個々の画像処理モジュール38によって各々設定された単位書込データ量及び単位読出データ量に基づいて、自モジュールのバッファ40Aの管理単位である単位バッファ領域のサイズを決定し、決定した単位バッファ領域のサイズを記憶する。単位バッファ領域のサイズとしては、自モジュールに設定された単位書込データ量及び単位読出データ量のうちの最大値を設定してもよいし、単位書込データ量を設定してもよいし、単位読出データ量(自モジュールの後段に複数の画像処理モジュール38が連結されている場合は、個々の画像処理モジュール38によって各々設定された単位読出データ量の最大値)を設定してもよい。また、単位書込データ量と単位読出データ量(の最大値)の最小公倍数を設定してもよいし、この最小公倍数が予め定められた値未満であれば最小公倍数を、最小公倍数が予め定められた値以上であれば別の値(例えば上述した単位書込データ量及び単位読出データ量のうちの最大値、単位書込データ量、単位読出データ量(の最大値)の何れか)を設定するようにしてもよい。更にまた、上記ステップ363で「自モジュールのバッファ40Aに書き込まれた有効データ(後述)のデータ量が、データ量αになった場合に起動する」という起動条件が設定された場合には、自モジュールに設定された単位書込データ量、単位読出データ量、及びデータ量αのうちの最大値を単位バッファ領域のサイズとして設定するようにしてもよい。
次のステップ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へ通知する。ステップ380では、自モジュールの前段又は後段に連結されている画像処理モジュール38から、当該画像処理モジュール38を消去する処理を行うことを通知する消去通知を受信したか否か判定する。この判定が否定された場合はステップ382に進み、前段の画像処理モジュール38から書込要求を受信したか否か判定する。更にここで否定判定された場合はステップ384に進み、後段の画像処理モジュール38から読出要求を受信したか否か判定する。ここで、否定判定された場合は、ステップ380に戻る。
一方、アプリケーション32は、順次起動したモジュール生成部44によって前述のモジュール生成処理(図3)が順次行われることで、必要とされる画像処理を行う画像処理部50の構築が完了すると、ワークフロー管理部46Aのプログラムを実行するスレッド(又はプロセス又はオブジェクト)に処理要求を送信して起動することで、ワークフロー管理部46Aに対して画像処理部50による画像処理の実行を指示する(図2のステップ176も参照)。
処理管理部46のワークフロー管理部46Aは、プログラムが起動されることで図13に示すブロック単位制御処理を行う。なお、このブロック単位処理は、図2のステップ178に示す画像処理部制御処理に対応している。ワークフロー管理部46Aはブロック単位処理において、画像処理部50を構成する画像処理モジュール38のうちの予め定められた画像処理モジュール38に処理要求を入力することで、画像処理部50による画像処理をブロック単位の実行形態で行わせるが、以下では画像処理部50全体の動作説明に先立ち、個々のバッファモジュール40のバッファ制御部40Bによって行われる初期化処理完了以降の処理、個々の画像処理モジュール38の制御部38Bによって行われる画像処理モジュール制御処理について順に説明する。
本実施形態では、画像処理モジュール38が後段のバッファモジュール40に画像データを書き込む場合には、画像処理モジュール38からバッファモジュール40へ書込要求が入力され、画像処理モジュール38が前段のバッファモジュール40から画像データを読み出す場合には、画像処理モジュール38からバッファモジュール40へ読出要求が入力される。
まず、書込要求が入力された場合について説明する。図5のステップ382で、前段の画像処理モジュール38から書込要求を受信した場合には、ステップ386に進み、図6に示すデータ書込処理を行う。
データ書込処理では、まずステップ410において、バッファフラグに1が設定されているか否か、すなわち自モジュールがアプリケーション32によって生成されたバッファモジュール40か否か判定する。この判定が肯定された場合は、バッファ40Aとして用いるメモリ領域が既に確保されているので、何ら処理を行うことなくステップ422へ移行する。また、ステップ410の判定が否定された場合、すなわち自モジュールがモジュール生成部44によって生成されたバッファモジュール40であった場合にはステップ412へ移行し、自モジュールのバッファ40Aを構成する単位バッファ領域の中に、空き領域が有る単位バッファ領域(画像データが末尾まで書き込まれていない単位バッファ領域)が存在しているか否か判定する。
モジュール生成部44によって生成されたバッファモジュール40は、当初はバッファ40Aとして用いるメモリ領域(単位バッファ領域)が確保されておらず、メモリ領域の不足が生ずる度に単位バッファ領域を単位として確保されるので、バッファモジュール40に最初に書込要求が入力されたときにはバッファ40Aとして用いるメモリ領域(単位バッファ領域)が存在しておらず、この判定は否定される。また、後述する処理を経てバッファ40Aとして用いる単位バッファ領域が確保された後も、当該単位バッファ領域への画像データの書込に伴って当該単位バッファ領域が丁度満杯になった場合には上記判定は否定される。
ステップ412の判定が否定された場合はステップ414へ移行し、待ち行列から取り出した要求情報に含まれる要求元識別情報に基づいて書込要求元の画像処理モジュール38を認識し、書込要求元の画像処理モジュール38によって設定された単位書込データ量を認識した後に、認識した単位書込データ量が、先のステップ364(図5)で決定した単位バッファ領域のサイズよりも大きいか否か判定する。この判定は、単位バッファ領域のサイズとして、自モジュールに設定された単位書込データ量及び単位読出データ量のうちの最大値、或いは自モジュールに設定された単位書込データ量を採用した場合には常に否定されてステップ420へ移行し、確保すべきメモリ領域のサイズ(単位バッファ領域のサイズ)をリソース管理部46Bに通知すると共に、自モジュールのバッファ40Aとして用いるメモリ領域(画像データの保管に用いる単位バッファ領域)の確保をリソース管理部46Bに要求する。これにより、リソース管理部46Bによって単位バッファ領域が確保される。
また、自モジュールのバッファ40Aを構成する単位バッファ領域の中に、空き領域有りの単位バッファ領域が存在していた場合には、ステップ412の判定が肯定されてステップ416へ移行し、前述したステップ414と同様にして書込要求元の画像処理モジュール38によって設定された単位書込データ量を認識した後に、空き領域有りの単位バッファ領域における空き領域のサイズが認識した単位書込データ量以上か否か判定する。判定が肯定された場合は、自モジュールのバッファ40Aとして用いる単位バッファ領域を新たに確保する必要はないので、何ら処理を行うことなくステップ422へ移行する。
単位バッファ領域のサイズが単位書込データ量の整数倍である場合には、自モジュールの前段の画像処理モジュール38から書込要求が入力される毎に、上記のようにステップ412,414の判定が各々否定されるか又はステップ412,416の判定が各々肯定され、バッファ40Aとして用いる単位バッファ領域のみが必要に応じて確保される。
一方、単位バッファ領域のサイズが単位書込データ量の整数倍でない場合には、バッファ40A(単位バッファ領域)への単位書込データ量の画像データの書込が繰り返されることで、例として図7(A)にも示すように、空き領域有りの単位バッファ領域における空き領域のサイズが単位書込データ量よりも小さい状態が生ずる(ステップ416の判定が肯定される)。また本実施形態では、単位バッファ領域のサイズとして、自モジュールに設定された単位読出データ量(又はその最大値)を採用してもよいが、そのサイズが単位書込データ量よりも小さい場合(ステップ414の判定が肯定される場合)には、書込要求が入力されたときに常に上記の状態が生じていることになる。
上記のように、空き領域有りの単位バッファ領域における空き領域のサイズが単位書込データ量よりも小さい場合、単位書込データ量の画像データが書き込まれる領域が複数の単位バッファ領域に跨ることになるが、本実施形態では、バッファ40Aとして用いるメモリ領域を単位バッファ領域を単位として確保するので、異なるタイミングで確保した単位バッファ領域が実メモリ(メモリ14)上で連続する領域であることは保証されない。このため、画像データが書き込まれる領域が複数の単位バッファ領域に跨る場合、すなわち、ステップ416の判定が否定されるかステップ414の判定が肯定された場合にはステップ418へ移行し、確保すべきメモリ領域のサイズとして単位書込データ量をリソース管理部46Bに通知すると共に、書込用に用いるメモリ領域(書込用バッファ領域:図7(B)も参照)の確保をリソース管理部46Bに要求する。そして、書込用バッファ領域を確保すると、次のステップ420でバッファ40Aとして用いる単位バッファ領域の確保を行う。
ステップ422では、空き領域有りの単位バッファ領域における空き領域のサイズが単位書込データ量以上の場合は当該空き領域を書込領域とする一方、空き領域有りの単位バッファ領域における空き領域のサイズが単位書込データ量よりも小さい場合には、新たに確保した書込用バッファ領域を書込領域として、当該書込領域の先頭アドレスを書込要求元の画像処理モジュール38へ通知すると共に、書込対象の画像データを通知した先頭アドレスから順に書き込むよう要請する。これにより、書込要求元の画像処理モジュール38は、先頭アドレスが通知された書込領域(単位バッファ領域又は書込用バッファ領域)に画像データを書き込む(図7(B)も参照)。前述したように、画像データが書き込まれる領域が複数の単位バッファ領域に跨る場合は書込用バッファ領域を別途確保するので、画像データが書き込まれる領域が複数の単位バッファ領域に跨るか否かに拘わらず、書込要求元の画像処理モジュール38への書込領域の通知は、上記のようにその先頭アドレスを通知するのみで済み、画像処理モジュール38とのインタフェースが簡単になる。
次のステップ424では、前段の画像処理モジュール38による書込領域への画像データの書き込みが完了したか否か判定し、判定が肯定される迄ステップ424を繰り返す。前段の画像処理モジュール38から書込完了が通知されると、ステップ424の判定が肯定されてステップ426へ移行し、上記の書込処理における書込領域が、先のステップ416で確保した書込用バッファ領域か否か判定する。判定が否定された場合は何ら処理を行うことなくステップ432へ移行するが、ステップ426の判定が肯定された場合はステップ428へ移行し、例として図7(C)に示すように、書込用バッファ領域に書き込まれた画像データを、空き領域有りの単位バッファ領域と、先のステップ422で確保した新たな単位バッファ領域に分けて複写する。またステップ430では、先のステップ418で書込用バッファ領域として確保したメモリ領域の先頭アドレスをリソース管理部46Bへ通知して、当該メモリ領域の解放をリソース管理部46Bに要求し、リソース管理部46Bによって前記メモリ領域を開放させる。
なお、ここでは必要なときに書込用バッファ領域を確保して、不要になったら解放する態様を説明したが、保管用単位バッファ領域のサイズが単位書込データ量の整数倍になっていない場合には、書込用バッファ領域は必ず必要となるので、初期化の際に確保しておき、バッファモジュール40が消去されるときに解放するよう構成しても良い。
データ書込処理(図6)において、ステップ426の判定が否定されるか、又はステップ430でメモリ領域の解放を要求した後にリソース管理部46Bから解放完了が通知されるとステップ432へ移行し、自モジュールの後段の個々の画像処理モジュール38に対応する有効データポインタのうち、有効データの末尾位置を表すポインタを各々更新する(図7(C)も参照)。なお、上記のポインタ更新は、ポインタが指し示す有効データの末尾位置を単位書込データ量分だけ後へ移動させることによって成されるが、自モジュールの前段の画像処理モジュール38によって今回書き込まれた画像データが処理対象の画像データの末尾に相当するデータであった場合には、前段の画像処理モジュール38による書込処理完了した際に、処理対象の画像データが終了したことを表す全体処理終了通知と共に、書き込んだ画像データのサイズが前段の画像処理モジュール38から入力されるので、書込処理完了した際に前段の画像処理モジュール38から全体処理終了通知が入力された場合には、これとともに通知されたサイズ分だけ有効データの末尾位置を後へ移動させることでポインタ更新が行われる。
次のステップ434では、書込処理完了の際に全体処理終了通知が入力されたか否かに基づいて、バッファ40Aへの処理対象の画像データの書込が終了したか否か判定する。判定が否定された場合は何ら処理を行うことなくステップ438へ移行するが、判定が肯定された場合はステップ436へ移行し、ステップ432で更新したポインタ(自モジュールの後段の個々の画像処理モジュール38に対応する有効データポインタのうち有効データの末尾位置を表すポインタ)に対し、処理対象の画像データの末尾であることを表すデータ最終位置情報を付加した後に、データ書込処理を終了してバッファ制御処理(図5)のステップ388に進む。
ステップ388では、バッファ40Aに書き込まれた有効データのデータ量が起動条件を満たしたか否か判定する。ここで肯定判定した場合には、ステップ390で、後段の画像処理モジュール38を起動する。具体的には、画像処理モジュール38に対して後段の画像処理モジュール38を起動するための起動要求を処理管理部46のワークフロー管理部46Aに通知する。該起動要求の通知を受け付けたワークフロー管理部46Aは、図13(E)に示すブロック単位制御処理5を実行する。
このブロック単位制御処理5では、ステップ514において、起動要求通知を送信したバッファモジュール40の後段の画像処理モジュール38を認識し、認識した後段の画像処理モジュール38に処理要求を入力して処理を終了する。これにより、待機状態にあった後段の画像処理モジュール38が起動する。待機状態から起動した後は、画像処理モジュール38は図11に示す画像処理モジュール制御処理を実行する。
またバッファ制御処理(図5)において、ステップ384で読出要求を受信した場合には、ステップ392へ移行し、図8に示すデータ読出処理を行う。データ読出処理では、まずステップ450において、待ち行列から取り出した要求情報に含まれる要求元識別情報に基づいて読出要求元の画像処理モジュール38を認識し、読出要求元の画像処理モジュール38によって設定された単位読出データ量を認識すると共に、読出要求元の画像処理モジュール38に対応する有効データポインタに基づいて、読出要求元の画像処理モジュール38に対応する有効データのバッファ40A上での先頭位置及び末尾位置を認識する。次のステップ452では、ステップ450で認識した有効データの先頭位置及び末尾位置に基づいて、読出要求元の画像処理モジュール38に対応する有効データ(読出要求元の画像処理モジュール38が読出可能な画像データ)が単位読出データ量以上有るか否か判定する。
判定が否定された場合はステップ454へ移行し、バッファ40Aに記憶されており読出要求元の画像処理モジュール38が読出可能な有効データの末尾が処理対象の画像データの末尾か否か判定する。読出要求元の画像処理モジュール38に対応する有効データがバッファ40Aに単位読出データ量以上記憶されているか、又は、バッファ40Aに記憶されている読出要求元の画像処理モジュール38に対応する有効データが単位読出データ量未満であるものの、当該有効データの末尾が処理対象の画像データの末尾であった場合には、ステップ452又はステップ454の判定が肯定されてステップ456へ移行する。ステップ456では、先のステップ450で認識した有効データの先頭位置に基づいて、有効データの先頭部分の画像データを記憶している単位バッファ領域を認識し、認識した単位バッファ領域に記憶されている有効データのデータ量がステップ450で認識した単位読出データ量以上か否かを判断することで、今回の読出対象の有効データが複数の単位バッファ領域に跨っているか否か判定する。
ステップ456の判定が否定された場合は何ら処理を行うことなくステップ460へ移行するが、例として図9(A)に示すように、有効データの先頭部分の画像データを記憶している単位バッファ領域に記憶されている有効データのデータ量が単位読出データ量未満であり、今回の読出対象の有効データが複数の単位バッファ領域に跨っている場合、今回の読出対象の有効データが実メモリ(メモリ14)上で連続する領域に記憶されているとは限らない。このため、ステップ456の判定が肯定された場合はステップ460へ移行し、確保すべきメモリ領域のサイズとして読出要求元の画像処理モジュール38に対応する単位読出データ量をリソース管理部46Bに通知すると共に、読出に用いるメモリ領域(読出用バッファ領域:図9(B)も参照)の確保をリソース管理部46Bに要求する。また、読出用バッファ領域を確保すると、次のステップ460で複数の単位バッファ領域に跨って記憶されている読出対象の有効データを、ステップ458で確保した読出用バッファ領域に複写する(図9(B)も参照)。
ステップ462では、読出対象の有効データが単一の単位バッファ領域に記憶されている場合は、当該単位バッファ領域のうち読出対象の有効データが記憶されている領域を読出領域とする一方、読出対象の有効データが複数の単位バッファ領域に跨って記憶されている場合には読出用バッファ領域を読出領域とし、当該読出領域の先頭アドレスを読出要求元の画像処理モジュール38へ通知すると共に、通知した先頭アドレスから画像データを順に読み出すよう要請する。これにより、読出要求元の画像処理モジュール38は、先頭アドレスが通知された読出領域(単位バッファ領域又は読出用バッファ領域)からの画像データの読み出しを行う(図9(C)も参照)。なお、読出対象の有効データが処理対象の画像データの末尾に相当するデータであった場合(読出対象の有効データの末尾位置が、読出要求元の画像処理モジュール38に対応する有効データポインタが指し示す有効データの末尾位置に一致しており、かつ前記ポインタにデータ最終位置情報が付加されていた場合)には、画像データの読出要請に際し、読出対象の有効データのサイズと共に、処理対象の画像データの末尾であることも読出要求元の画像処理モジュール38に通知する。
前述したように、読出対象の有効データが複数の単位バッファ領域に跨って記憶されている場合は、別途確保した読出用バッファ領域に読出対象の有効データを複写するので、読出対象の有効データが複数の単位バッファ領域に跨って記憶されているか否かに拘わらず、読出要求元の画像処理モジュール38への読出領域の通知は、上記のようにその先頭アドレスを通知するのみで済み、画像処理モジュール38とのインタフェースが簡単になる。なお、自モジュールがアプリケーション32によって生成されたバッファモジュール40である場合は、バッファ40Aとして用いているメモリ領域(単位バッファ領域の集合体)は連続領域であるので、ステップ456の判定を行う前にバッファフラグが1か否か判定し、判定が肯定された場合は読出対象の有効データが複数の単位バッファ領域に跨って記憶されているか否かに拘わらずステップ462へ移行するようにしてもよい。
次のステップ464では、読出要求元の画像処理モジュール38による読出領域からの画像データの読み出しが完了したか否か判定し、判定が肯定される迄ステップ464を繰り返す。読出要求元の画像処理モジュール38から読出完了が通知されると、ステップ464の判定が肯定されてステップ466へ移行し、上記の読出処理における読出領域が、先のステップ458で確保した読出用バッファ領域か否か判定する。判定が否定された場合は何ら処理を行うことなくステップ470へ移行するが、ステップ466の判定が肯定された場合はステップ468へ移行し、先のステップ458で読出用バッファ領域として確保したメモリ領域の先頭アドレス及びサイズをリソース管理部46Bへ通知して、当該メモリ領域の解放をリソース管理部46Bに要求する。この読出用バッファ領域についても、保管用単位バッファ領域のサイズが単位読出データ量の整数倍になっていない場合には、読出用バッファ領域は必ず必要となるので、初期化の際に確保しておき、バッファモジュール40が消去されるときに解放するよう構成しても良い。
次のステップ470では、読出要求元の画像処理モジュール38に対応する有効データポインタのうち、有効データの先頭位置を表すポインタを更新する(図9(C)も参照)。なお、上記のポインタ更新は、ポインタが指し示す有効データの先頭位置を単位読出データ量分だけ後へ移動させることによって成されるが、今回の読出対象の有効データが処理対象の画像データの末尾に相当するデータであった場合には、読出要求元の画像処理モジュール38へも通知した今回の読出対象の有効データのサイズ分だけ有効データの先頭位置を後へ移動させることでポインタ更新が行われる。
ステップ472では、後段の個々の画像処理モジュール38に対応する有効データポインタを各々参照し、ステップ470のポインタ更新により、バッファ40Aを構成する単位バッファ領域の中に、記憶している画像データの後段の各画像処理モジュール38による読み出しが全て完了した単位バッファ領域、すなわち有効データを記憶していない単位バッファ領域が出現したか否か判定する。判定が否定された場合は何ら処理を行うことなくステップ478へ移行するが、判定が肯定された場合はステップ474へ移行し、バッファフラグが1か否か判定する。自モジュールがモジュール生成部44によって生成されたバッファモジュール40である場合は判定が否定されてステップ476へ移行し、有効データを記憶していない単位バッファ領域の解放をリソース管理部46Bに要求し、データ読出処理を終了してバッファ制御処理(図5)のステップ380に戻る。
なお、自モジュールがアプリケーション32によって生成されたバッファモジュール40である場合にはステップ474の判定が肯定され、何ら処理を行うことなく、データ読出処理を終了してバッファ制御処理(図5)のステップ380に戻る。
一方、バッファ40Aに記憶されており読出要求元の画像処理モジュール38が読出可能な有効データのデータ量が単位読出データ量未満であり、かつ読出可能な有効データの末尾が処理対象の画像データの末尾でない場合(図12(B)の(4)で読出可能な有効データ無が検知された場合)には、ステップ452,454の判定が各々否定されてステップ480へ移行し、新たな画像データを要求するデータ要求をワークフロー管理部46Aへ出力する(図12(B)の(5)も参照)。この場合、ワークフロー管理部46Aにより、自モジュールの前段の画像処理モジュール38に処理要求が入力されることになる。そして、データ読出処理を終了する。
図5に示すように、データ読出処理を終了するとステップ380(図5)に戻る。その後は、前述したステップ388で起動条件が満たされてステップ390で起動されるまで後段の画像処理モジュール38は待機状態を継続する。後段の画像処理モジュール38が起動された後は、上記と同様にデータ読出処理が実行されることになる。
詳細は後述するが、ワークフロー管理部46Aはバッファモジュール40からデータ要求が入力されると(図12(B)の(6)も参照)、データ要求元のバッファモジュール40の前段の画像処理モジュール38に処理要求を入力する(図12(B)の(7)も参照)。この処理要求の入力をトリガとして前段の画像処理モジュール38の制御部38Bで行われる処理により、前段の画像処理モジュール38がバッファモジュール40へ画像データを書込可能な状態になると、前段の画像処理モジュール38から書込要求が入力されることで前述したデータ書込処理(図6)が行われ、前段の画像処理モジュール38からバッファモジュール40のバッファ40Aに画像データが書き込まれる(図12(B)の(8),(9)も参照)。そして、書込の結果、前述の起動条件が満たされると、バッファモジュール40から起動要求が通知され(図12(B)の(10)も参照)、ワークフロー管理部46Aから後段の画像処理モジュール38に対して処理要求が入力され(図12(B)の(11)も参照)、これを受け付けた後段の画像処理モジュール38が起動して、後段の画像処理モジュール38によるバッファ40Aからの画像データの読出が行われることになる(図12(B)の(12)も参照)。
続いて、画像処理部50を構成する個々の画像処理モジュール38に対してワークフロー管理部46Aから処理要求が入力される毎に、個々の画像処理モジュール38の制御部38Bによって各々行われる画像処理モジュール制御処理(図11)を説明する。画像処理モジュール制御処理では、まずステップ284において、自モジュールの前段にモジュール(バッファモジュール40や画像データ供給部22、画像処理モジュール38等)が存在している場合に、当該前段のモジュールに対してデータ(画像データ又は解析等の画像処理の処理結果)を要求する。次のステップ286では、前段のモジュールからデータが取得可能であるかを判定する。判定が否定された場合は、ステップ288で全体処理終了が通知されたか否かを判定し、判定が肯定された場合はステップ308で全体処理終了をワークフロー管理部46A及び自モジュールの前段及び後段のモジュールに通知した後に、ステップ310で自モジュール消去処理(後述)を行う。
一方、ステップ288の判定が否定された場合は、ステップ289で、自モジュールを待機状態へ移行させる(処理停止)。その後は、新たに処理要求を受信するまで(入力されるまで)、待機状態を継続する。また、ステップ286の判定が肯定された場合には、ステップ290で前段のモジュールからデータを取得するデータ取得処理を行う。
ここで、自モジュールの前段のモジュールがバッファモジュール40である場合には、先のステップ284でデータを要求すると(読出要求)、読出可能な有効データがバッファモジュール40のバッファ40Aに単位読出データ量以上記憶されているか、読出可能な有効データの末尾が処理対象の画像データの末尾に一致している状態であれば、バッファモジュール40から読出領域の先頭アドレスが通知されて画像データの読出が要請される(図8のステップ462も参照)。これにより、ステップ286の判定が肯定されてステップ290へ移行し、前段のバッファモジュール40より先頭アドレスが通知された読出領域から単位読出データ量(又はそれ未満のデータ量)の画像データを読み出すデータ取得処理を行う(図12(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から先頭アドレスが通知された書込領域)が取得できたら(図12(A)の(4)も参照)、次のステップ300において、先のデータ取得処理で取得したデータと後段のモジュールから取得したデータ出力領域(の先頭アドレス)を画像処理エンジン38Aに入力し、入力したデータに対して予め定められた画像処理を行わせる(図12(A)の(5)も参照)と共に、処理後のデータをデータ出力領域に書き込ませる(図12(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では自モジュール消去処理(後述)を行い、画像処理モジュール制御処理を終了する。
ここで、ワークフロー管理部46Aの処理について図13及び図14を参照しながら説明する。なお、図14では、バッファモジュール40からの起動要求通知、及び該起動要求に応じて出力される処理要求の図示は省略してある。
ワークフロー管理部46Aは、画像処理の実行が指示されると、図13(A)に示すブロック単位制御処理1を行い、バッファモジュール40からデータ要求が入力される毎に図13(B)に示すブロック単位制御処理2を行い、画像処理モジュール38から処理完了通知が入力される毎に図13(C)に示すブロック単位制御処理3を行い、画像処理モジュール38から全体処理終了通知が入力される毎に図13(D)に示すブロック単位制御処理4を行い、バッファモジュール40から起動要求通知が入力される毎に図13(E)に示すブロック単位制御処理5を行う。
先にも述べたように、ブロック単位制御処理1では、ワークフロー管理部46Aによる画像処理部50の個々の画像処理モジュール38への処理要求の入力では、単位処理の実行回数を指定可能とされているが、ステップ500では、1回の処理要求で指定する単位処理の実行回数を個々の画像処理モジュール38毎に決定する。この処理要求1回当りの単位処理の実行回数は、例えば処理対象の画像データ全体を処理する間の個々の画像処理モジュール38への処理要求の入力回数が平均化されるように定めてもよいが、他の基準、例えば、上記設定した起動条件に従って画像処理モジュール38毎に定めてもよい。例えば、「自モジュールのバッファ40Aに書き込まれた有効データのデータ量が、データ量αになった場合に起動する」という起動条件が設定された場合には、データ量αの有効データが後段のバッファモジュール40のバッファ40Aに書き込まれるまで単位処理が繰り返されるように、実行回数を定めてもよい。そして次のステップ502において、画像処理部50のうち最後段の画像処理モジュール38に処理要求を入力し(図14の(1)も参照)、ブロック単位制御処理1を終了する。
ここで、図14に示す画像処理部50において、ワークフロー管理部46Aから最後段の画像処理モジュール384に処理要求が入力されると、画像処理モジュール384の制御部38Bは前段のバッファモジュール403に読出要求を入力する(図14の(2)参照)。このとき、バッファモジュール403のバッファ40Aには画像処理モジュール384が読出可能な有効データ(画像データ)が記憶されていないので、バッファモジュール403のバッファ制御部40Bはワークフロー管理部46Aにデータ要求を入力する(図14の(3)参照)。また、画像処理モジュール384は、待機状態となる。
ワークフロー管理部46Aは、バッファモジュール40からデータ要求が入力される毎に、図13(B)に示すブロック単位制御処理2を行う。このブロック単位制御処理2では、ステップ504において、データ要求入力元のバッファモジュール40(ここではバッファモジュール403)の前段の画像処理モジュール38(ここでは画像処理モジュール383)を認識し、認識した前段の画像処理モジュール38に処理要求を入力(図14の(4)参照)して処理を終了する。
画像処理モジュール383の制御部38Bは、処理要求が入力されると前段のバッファモジュール402に読出要求を入力し(図14の(5)参照)、バッファモジュール402のバッファ40Aにも読出可能な画像データが記憶されていないので、バッファモジュール402のバッファ制御部40Bはワークフロー管理部46Aにデータ要求を入力する(図9の(6)参照)。また、画像処理モジュール383は、待機状態となる。ワークフロー管理部46Aは、バッファモジュール402からデータ要求が入力された場合も、前述のブロック単位制御処理2を再度行うことで、その前段の画像処理モジュール382に処理要求を入力し(図14の(7)参照)、画像処理モジュール382の制御部38Bは前段のバッファモジュール401に読出要求を入力する(図14の(8)参照)。また、バッファモジュール401のバッファ40Aにも読出可能な画像データが記憶されていないので、バッファモジュール401のバッファ制御部40Bもワークフロー管理部46Aにデータ要求を入力する(図14の(9)参照)。また、画像処理モジュール382は、待機状態となる。ワークフロー管理部46Aは、バッファモジュール401からデータ要求が入力された場合も、前述のブロック単位制御処理2を再度行うことで、その前段の画像処理モジュール381に処理要求を入力する(図14の(10)参照)。
ここで、画像処理モジュール381の前段のモジュールは画像データ供給部22であるので、画像処理モジュール381の制御部38Bは、画像データ供給部22にデータ要求を入力することで画像データ供給部22から単位読出データ量の画像データを取得し(図14の(11)参照)、取得した画像データに対して画像処理エンジン38Aが画像処理を行うことで得られた画像データを、後段のバッファモジュール401のバッファ40Aに書き込む(図14の(12)参照)。
また、バッファモジュール401のバッファ制御部40Bは、起動条件を満たすデータ量の有効データが書き込まれるとワークフロー管理部46Aに起動要求を通知して、画像処理モジュール382を起動させ、画像処理モジュール382に対して読出を要請する。これに伴い画像処理モジュール382の制御部38Bは、バッファモジュール401のバッファ40Aから単位読出データ量の画像データを読み出し(図14の(13)参照)、取得した画像データに対して画像処理エンジン38Aが画像処理を行うことで得られた画像データを、後段のバッファモジュール402のバッファ40Aに書き込む(図14の(14)参照)。バッファモジュール402のバッファ制御部40Bは、起動条件を満たすデータ量の有効データが書き込まれるとワークフロー管理部46Aに起動要求を通知して、画像処理モジュール383を起動させ、画像処理モジュール383へ読出を要請し、画像処理モジュール383の制御部38Bは、バッファモジュール402のバッファ40Aから単位読出データ量の画像データを読み出し(図14の(15)参照)、取得した画像データに対して画像処理エンジン38Aが画像処理を行うことで得られた画像データを、後段のバッファモジュール403のバッファ40Aに書き込む(図14の(16)参照)。
更に、バッファモジュール403のバッファ制御部40Bは、起動条件を満たすデータ量の有効データが書き込まれるとワークフロー管理部46Aに起動要求を通知して、画像処理モジュール384を起動させ、画像処理モジュール384に対して読出を要請し、これに伴い画像処理モジュール384の制御部38Bは、バッファモジュール403のバッファ40Aから単位読出データ量の画像データを読み出し(図14の(17)参照)、取得した画像データに対して画像処理エンジン38Aが画像処理を行うことで得られた画像データを、後段のモジュールである画像出力部24へ出力する(図14の(18)参照)。
また、個々の画像処理モジュール38の制御部38Bは、後段のバッファモジュール40のバッファ40Aへの画像データの書き込みを完了すると、ワークフロー管理部46Aへ処理完了通知を入力する。ワークフロー管理部46Aは、画像処理モジュール38から処理完了通知が入力される毎に、図13(C)に示すブロック単位制御処理3を行う。このブロック単位制御処理3では、まずステップ506において、処理完了通知元の画像処理モジュール38が最後段の画像処理モジュール38か否か判定する。判定が否定された場合は何ら処理を行うことなくブロック単位制御処理3を終了する。また、判定が肯定された場合はステップ508へ移行し、処理完了通知元の画像処理モジュール38に処理要求を再度入力して処理を終了する。
また、ワークフロー管理部46Aは、画像処理モジュール38から全体処理終了通知が入力される毎に、図13(D)に示すブロック単位制御処理4を行う。このブロック単位制御処理4では、ステップ510において、全体処理終了通知入力元の画像処理モジュール38が最後段の画像処理モジュール38か否か判定する。判定が否定された場合は何ら処理を行うことなく処理を終了するが、処理対象の画像データに対して必要な画像処理が行われた画像データが画像出力部24へ全て出力されることで、最後段の画像処理モジュール38から全体処理終了通知が入力された場合には、ステップ510の判定が肯定されてステップ512へ移行し、アプリケーション32に対して画像処理の完了を通知し(図2のステップ180も参照)、ブロック単位制御処理を終了する。そして、画像処理の完了が通知されたアプリケーション32は、ユーザに対して画像処理の完了を通知する(図2のステップ182も参照)。
なお、ブロック単位制御処理5については、前述のとおりである。
このように、ブロック単位処理では、最後段の画像処理モジュール38に入力された処理要求がより前段の画像処理モジュール38へ遡り、最前段の画像処理モジュール38に到達すると、最前段の画像処理モジュール38で画像処理が行われて後段のバッファモジュール40にデータが書き込まれ、それでデータが足りるようであれば処理が後段のモジュールへ進んで行くという流れで一連の画像処理が行われる。
次に、処理対象の画像データに対する画像処理を完了した後に行われる画像処理部50の消去について説明する。個々の画像処理モジュール38の制御部38Bは、画像処理モジュール制御処理(図11)のステップ308で、ワークフロー管理部46A及び後段のモジュールへ全体処理終了通知を出力した後に、次のステップ310において自モジュール消去処理を行う。この自モジュール消去処理では、先のステップ254(図10)で確保したメモリ領域をリソース管理部46Bによって解放させると共に、リソース管理部46Bを通じて自モジュールが確保したメモリ以外のリソースが有れば、当該リソースをリソース管理部46Bによって解放させ、自モジュールの前段のモジュール、後段のモジュール及びワークフロー管理部46Aに対し、自モジュールを消去する処理を行うことを通知するための消去通知を入力した後に、自モジュールを消去する処理が行われる。なお、自モジュールを消去することは、自モジュールに対応するスレッド(又はプロセス)を終了するか、又はオブジェクトを削除することで実現する。
なお、バッファモジュール40のバッファ制御部40Bによって行われるバッファ制御処理(図5)では、自モジュールの前段又は後段の画像処理モジュール38から消去通知が入力されると、ステップ380の判定が肯定されてステップ394へ移行し、消去通知入力元のモジュールを記憶した後に、自モジュールの前段及び後段の全てのモジュールから消去通知が入力されたか否か判定する。判定が否定された場合はステップ380へ戻る。また、自モジュールの前段及び後段の全てのモジュールから消去通知が入力されると、ステップ394の判定が肯定されてステップ396へ移行し、ワークフロー管理部46Aに対して消去通知を入力することで、自モジュールを消去する処理を行うことを通知する。そして次のステップ398で自モジュールを消去する処理を行ってバッファ制御処理(図5)を終了する。
ここで、前述した起動条件の決定方法の具体例について説明する。以下では、データ量を表す単位としてライン、画素数、バイト等を用いる。
[単位処理データ量に基づく決定方法]
例えば、前段の画像処理モジュール38及び後段の画像処理モジュール38の各々の単位処理データ量が1ラインの場合には、バッファモジュール40に画像データ(有効データ)が1ラインずつ書き込まれる毎に起動を繰り返すのではなく、ある程度まとまったライン数が書き込まれた場合に起動させる起動条件を定める。具体的には、上記単位処理データ量のライン数が予め定められた閾値(例えば10ライン)以下の場合は、自モジュールのバッファ40Aに書き込まれた有効データのデータ量が、10ライン分のデータ量になった場合に起動する起動条件とする。
なお、ここで、10ラインというデータ量は一例であって、これに限定されるものではない。また、連結された画像処理モジュール38の各々の単位処理データ量が異なる場合であっても、何れも閾値より小さければ、上記と同様に起動条件を決定する。なお、上記閾値は小さすぎると起動回数が増え、オーバーヘッドが大きくなってしまうが、閾値があまりに大きすぎると、前段の画像処理モジュール38が画像1面分の画像データに対する画像処理が終了した後に後段の画像処理モジュール38が起動されることにもなりかねず、かえって並列して処理する時間が短くなることもあるため、予め試験等により適切な値を求めて設定しておく。
更にまた、連結された画像処理モジュール38の各々の単位処理データ量が閾値より大きい場合には、該単位処理データ量の有効データが自モジュールのバッファ40Aに書き込まれた場合に起動させる起動条件を定める。
なお、連結された各画像処理モジュール38の単位処理データ量を示す情報は、図5のステップ363で起動条件を設定する前に予め取得しておく。例えば、図5のステップ358で、連結された各画像処理モジュール38が単位書込データ量及び単位読出データ量をバッファモジュール40に通知する際に、各々の単位処理データ量も通知するように構成してもよい。
[処理の重さ(画像処理の単位処理に要する時間)に基づく決定方法]
単位処理データ量の有効データが書き込まれる毎に後段の画像処理モジュール38を起動させる場合には、各画像処理モジュール38の処理の重さが重いほど(単位処理に要する時間が長いほど)は、各画像処理モジュール38が並列して画像処理を実行する期間も長く(並列度が高く)なり、逆に処理の重さが軽いほど(単位処理に要する時間が短いほど)、待機状態に移行しやすく、並列度が低くなる傾向がある。
そこで、連結された画像処理モジュール38が画像処理を実行している時間が平均化されて並列度が上がるように起動条件を設定するようにしてもよい。以下、様々なパターンを例示して説明する。ここでは、処理の重さを1〜5(数値が上がるほど重い)の数値で表すこととし、目標連続処理時間(連続して処理させたい時間の目標値、ここでは処理の重さの最大レベル)を5とし、各画像処理モジュール38の単位処理データ量を、1ラインで共通とする。また、ここでは、単位処理データ量の有効データが書き込まれる毎に起動要求を出力して後段の画像処理モジュール38を起動させる場合を基準として、該起動要求の出力を間引くか否か、間引く場合にはどの程度間引くかを連結された画像処理モジュール38に応じて求め、起動条件を定める場合を例に挙げて説明する。
図15の(1)に示すように、前段の画像処理モジュール38及び後段の画像処理モジュール38の各々の処理の重さが共に軽い場合には、起動回数が抑制されるように起動条件を定める。例えば、前段の画像処理モジュール38及び後段の画像処理モジュール38の処理の重さが共に1である場合には、目標連続処理時間の5を1で割ると、5/1=5ラインであるため、自モジュールのバッファ40Aに書込まれた有効データのデータ量が5ライン分のデータ量になった場合に後段の画像処理モジュール38を起動する起動条件とする。すなわち、単位処理データ量の有効データが書き込まれる毎に起動要求を出力して後段の画像処理モジュール38を起動させると起動要求が5回出力されることになるが、これを1回の出力となるよう間引く。
また、前段の画像処理モジュール38及び後段の画像処理モジュール38の処理の重さが共に2である場合には、5/2=2.5ラインであるため、2ライン分又は3ライン分の有効データが自モジュールのバッファ40Aに書き込まれる毎に後段の画像処理モジュール38を起動させる起動条件を定めてよい。また、2ライン分の有効データが自モジュールのバッファ40Aに書き込まれたら後段の画像処理モジュール38を起動させ、次は3ライン分の有効データが自モジュールのバッファ40Aに書き込まれたら後段の画像処理モジュール38を起動させ、その次は、2ライン分の有効データが自モジュールのバッファ40Aに書き込まれたら後段の画像処理モジュール38を起動させ、・・・というように起動条件を定めてもよい。
図15の(2)に示すように、前段の画像処理モジュール38及び後段の画像処理モジュール38の処理の重さが共に重い場合には、上記軽い場合に比べて待機状態に移行しにくい。図15(2)に示す例では、前段の画像処理モジュール38及び後段の画像処理モジュール38の処理の重さが共に5であり、前述したように目標連続処理時間が5であるため、起動要求の出力を間引くことなく、自モジュールのバッファ40Aに書込まれた有効データが5ライン分のデータ量になった場合に後段の画像処理モジュール38を起動させる起動条件を定める。
図15の(3)に示すように、前段の画像処理モジュール38の処理の重さが後段の画像処理モジュール38の処理の重さより重い場合には、後段の画像処理モジュール38の画像処理の方が前段の画像処理モジュール38よりも早く終了するため、処理の重さが同じ場合に比べて後段の画像処理モジュール38の待機状態が多くなる。従って、後段の画像処理モジュール38を起動要求を間引くことなく起動させて処理させた方が並列度が上がる。そこで、この場合には、自モジュールのバッファ40Aに有効データが単位処理データ量1ライン分書き込まれた場合に後段の画像処理モジュール38を起動させる起動条件を定める。
図15の(4)に示すように、前段の画像処理モジュール38の処理の重さが後段の画像処理モジュール38の処理の重さより軽い場合には、前段の画像処理モジュール38の単位処理が終了してバッファ40Aに対する書込が終わっても、後段の画像処理モジュール38はまだ処理途中であるため、起動要求を出力する意味がない。そこで、後段の画像処理モジュール38の単位処理が終了してから起動されるように、起動要求が間引かれるように起動条件を定める。例えば、自モジュールのバッファ40Aに書込まれた有効データのデータ量が5ライン分のデータ量となった場合に後段の画像処理モジュール38を起動させる起動条件を定める。
なお、連結された各画像処理モジュール38の処理の重さを示す情報は、図5のステップ363で起動条件を設定する前に予め取得しておく。例えば、図5のステップ358で、連結された各画像処理モジュール38が単位書込データ量及び単位読出データ量をバッファモジュール40に通知する際に、各々の処理の重さも通知するように構成してもよい。
[連結された画像処理モジュールの数に基づく決定方法]
図16の(1)に示すように、後段に画像処理モジュール38が複数連結されている場合には、一回の起動要求で該複数の画像処理モジュール38が起動されるため、起動回数が多くなってしまう。そこで、起動要求の出力を間引く。例えば、後段に単位処理データ量が1ラインの画像処理モジュール38が3つ連結されていた場合、通常3回起動要求を出力するところを1回に減らすように起動要求を定める。
図16の(2)に示すように、前段に画像処理モジュール38が複数連結されている場合には、1つのバッファ40Aに複数の画像処理モジュール38が画像データを書き込むという状況は発生しない。従って、起動要求を間引くことなく起動条件を定める。
[連結された画像処理モジュールの処理対象の画像データが表す画像の大きさに基づく決定方法]
単位処理データ量が1ラインであっても、処理対象の画像データが横長の画像を表す画像データの場合、1ラインの画素数が大きくなる。一方、処理対象の画像データが縦長の画像を表す画像データの場合、横長の場合に比べて1ラインの画素数は小さい。従って、縦長の画像を表す画像データを処理対象とする場合に、1ライン分の有効データが書き込まれる毎に後段の画像処理モジュール38を起動すると、横長の画像を示す画像データを処理対象とする場合に比べて起動回数が多くなり、並列度が低くなる、そこで、処理対象の画像データが表す画像の大きさ(すなわち画像1面分の大きさ、或いは画像全体の大きさと言い換えてもよい)起動要求の出力を抑制する(間引く)よう起動条件を定める。
後段の画像処理モジュール38の単位処理データ量を1ラインとする場合を例に挙げて説明する。まず、(処理対象の画像データが表す画像の大きさ)/(1ラインのデータ量)を求める。そして、求めた値を予め定められた間引き係数で割ったものを起動条件とする。例えば、上記画像の大きさが1500*1000画素であり、単位処理データ量が1ライン(1000画素)の場合には、(1500*1000画素)/(1000画素)は、1500が求められる。上記間引き係数は、予め実験等で目標の並列度が得られた値として求めておき、これを250とすると、1500/250=6が求められる。従って、自モジュールのバッファ40Aに書込まれた有効データが6ライン分のデータ量となった場合に後段の画像処理モジュール38を起動するという起動条件を定める。
なお、前段の画像処理モジュール38の処理対象の画像データが表す画像と後段の画像処理モジュール38の処理対象の画像データが表す画像の大きさが等しければ、前段の画像処理モジュール38の処理対象の画像データが表す画像の大きさに基づいて起動条件を定めてもよい。
なお、後段の画像処理モジュール38の処理対象となる画像データが表す画像の大きさの情報は、図5のステップ363で起動条件を設定する前に予め取得しておく。例えば、図5のステップ358で、連結された各画像処理モジュール38が単位書込データ量及び単位読出データ量をバッファモジュール40に通知する際に、処理対象となる画像データが表す画像の大きさも通知するように構成してもよい。
[複数の要素の組み合わせに基づいて起動条件を決定する場合の決定方法]
上記では、単位処理データ量、処理の重さ、連結する画像処理モジュールの数、及び処理対象の画像データが表す画像の大きさの各々に基づいて起動条件を定める例について説明したが、これらのうち、2以上の要素を組み合わせ、この組み合わせに基づいて起動条件を定めるようにしてもよい。なお、ここでも、単位処理データ量の有効データが書き込まれる毎に起動要求を出力して後段の画像処理モジュール38を起動させる場合を基準として、該起動要求の出力を間引くか否か、間引く場合にはどの程度間引くかを連結された画像処理モジュール38に応じて求め、起動条件を定める場合を例に挙げて説明する。
(1)単位処理データ量及び処理対象の画像データが表す画像の大きさに基づく決定方法
単位処理データ量の有効データが書き込まれる毎に起動すると、(処理対象の画像の大きさ)/(単位処理データ量)が、画像処理モジュール38の起動回数になる。この起動回数が予め定めた閾値より大きい場合には、起動要求の出力を間引き、閾値以下の場合には間引かないようにする。
以下、具体例を示す。
A.後段の画像処理モジュール38の処理対象の画像データが表す画像の大きさが1000×1500画素であり、1ラインを1000画素とすると、前段及び後段の画像処理モジュール38の単位処理データ量が2ラインの場合、単位処理データ量の有効データが書き込まれる毎に起動すると、起動回数は、1500/2=750回になる。
B.後段の画像処理モジュール38の処理対象の画像データが表す画像の大きさが250×250画素であり、前段及び後段の画像処理モジュール38の単位処理データ量が5ラインの場合は、単位処理データ量の有効データが書き込まれる毎に起動すると、起動回数は、250/5=50回になる。
予め、実験などにより目標となる並列度を達成する間引き係数を定めておき、この間引き係数に基づいて、起動要求が間引かれるよう起動条件を定める。ここで、間引き係数を50とすると、Aの場合は、750/50=15で15回に1回起動要求を出力されるように起動条件を定める。すなわち、有効データが30ライン書き込まれる毎に後段の画像処理モジュール38を起動する起動条件を定める。また、Bの場合は、50/50=1であるため、起動要求を間引かない。すなわち、自モジュールのバッファ40Aに書込まれた有効データのデータ量が単位処理データ量になった場合に起動する起動条件を定める。
なお、上記起動条件の計算において、単位処理データ量が前段と後段とで異なる場合には、その最大値を用いるものとする。
(2)単位処理データ量及び処理の重さに基づく決定方法
処理の重さが軽く単位処理データ量が少ないほど起動回数が多くなる傾向があるため、処理の重さが軽く単位処理データ量が少ないほど起動要求の間引きを多くする。
以下、具体例を示す。
ここでは、前段の画像処理モジュール38及び後段の画像処理モジュール38の双方の単位処理データ量、及び処理の重さが等しいものとして説明する。更に、処理の重さを1〜5(数値が上がるほど重い)の数値で表すこととし、目標連続処理時間を20とする。
まず、以下AからCの各々の場合について、処理の重さ×単位処理データ量(ライン数)を計算する。
A.処理の重さが5で単位処理データ量が2ラインずつの場合、5×2=10
B.処理の重さが2で単位処理データ量が1ラインずつの場合、2×1=2
C.処理の重さが5で単位処理データ量が5ラインずつの場合、5×5=25
次に、AからCの各々について、目標連続処理時間/(処理の重さ×単位処理データ量)を計算し、これに基づいて起動条件を求める。
Aの場合は、20/10=2となり、単位処理データ量の有効データが書き込まれる毎に起動要求を出力して後段の画像処理モジュール38を起動させる場合には起動要求を2回出力することになるが、これを1回に減らす。すなわち、自モジュールのバッファ40Aに書込まれた有効データのデータ量が4ライン分のデータ量となった場合に起動する起動条件を定める。
Bの場合は、20/2=10となり、単位処理データ量の有効データが書き込まれる毎に起動要求を出力して後段の画像処理モジュール38を起動させる場合には起動要求を10回出力することになるが、これを1回に減らす。すなわち、自モジュールのバッファ40Aに書込まれた有効データのデータ量が10ライン分のデータ量となった場合に起動する起動条件を定める。
Cの場合は、20/25=0.8で1以下になるので、起動要求を間引かない。すなわち、自モジュールのバッファ40Aに書込まれた有効データのデータ量が5ライン分のデータ量となった場合に起動する起動条件を定める。
(3)単位処理データ量、処理対象の画像データが表す画像の大きさ、処理の重さ、及び連結された画像処理モジュールの数に基づく決定方法
ここでは、前段及び後段に連結された各画像処理モジュール38の各々の単位処理データ量、及び処理の重さが等しいものとして説明する。
まず、後段の画像処理モジュール38の処理対象の画像データが表す画像の大きさ/単位処理データ量を計算する。以下、2つの計算例を示す。
A.1500/2=750
B.250/5=50
次に、図17に示すテーブルから自モジュールの該当する間引き係数を探し、上記計算した数値/間引き係数を間引き回数とする。図17に示すテーブルは、処理の重さ及び連結されたモジュール数に応じた間引き係数が記憶されたテーブルである。なお、本テーブルは、処理の重さの方が連結されるモジュール数よりも起動回数に対する影響が大きいため、それを考慮して作成されている。本テーブルは、予め実験等により各係数を求め作成しておく。なお、本テーブルは、例えば、メモリ14に確保され、生成された各バッファモジュール40が読出し可能な共通の記憶領域に予め記憶されており、各バッファモジュール40が該記憶領域から必要な間引き係数を読み出すようにしてもよい。
上記Aの場合、間引き係数は100であるため、上記計算した値を間引き係数で割ると、750/100=7.5となる。従って、単位処理データ量の有効データが書き込まれる毎に起動要求を出力して後段の画像処理モジュール38を起動させる場合に起動要求を7回出力することになるが、これを1回に減らす。すなわち、自モジュールのバッファ40Aに書込まれた有効データのデータ量が14ライン分のデータ量となった場合に起動する起動条件を定める。
上記Bの場合、間引き係数は10であるため、上記計算した値を間引き係数で割ると、50/10=5となる。従って、単位処理データ量の有効データが書き込まれる毎に起動要求を出力して後段の画像処理モジュール38を起動させる場合に起動要求を5回出力することになるが、これを1回に減らす。すなわち、自モジュールのバッファ40Aに書込まれた有効データのデータ量が25ライン分のデータ量となった場合に起動する起動条件を定める。
なお、上記様々な起動条件の決定方法について説明したが、バッファ40Aに書き込まれた有効データのデータ量が後段の画像処理モジュール38の単位読出データ量未満の状態で起動要求が出力されてしまうことがないように上記方法で決定した起動条件を調整し、該調整した起動条件を最終的な起動条件として決定して設定する。例えば、単位処理データ量が単位読出データ量未満であり、且つ上記方法により、単位処理データ量の有効データが自モジュールのバッファ40Aに書き込まれた場合に起動させる起動条件を決定された場合には、単位読出データ量の有効データが自モジュールのバッファ40Aに書き込まれた場合に起動させる起動条件に変更し、これを起動条件として設定する。
図18は、本実施の形態に係るバッファモジュール40の機能構成を示す図である。前述したように、バッファモジュール40は、バッファ40A及びバッファ制御部40Bを備えている。バッファ制御部40Bは、起動部50、起動条件決定部52、書き込み状況監視部54、及び書込・読出制御部56を備えている。起動部50は、起動条件決定部52が決定した起動条件に従って起動要求を処理管理部46に送信する(図5のステップ390も参照)。起動条件決定部52は、前述したように、起動条件を決定し、設定する(図5のステップ363も参照)。書き込み状況監視部54は、バッファ40Aに対する有効データの書き込み状態を監視する(図5のステップ388も参照)。書込・読出制御部56は、前段に連結された画像処理モジュール38からの書込要求に対する書き込みの制御、及び後段に連結された画像処理モジュール38からの読出要求に対する読出しの制御を行う(図5のステップ363,388,390以外の各ステップ、図6、及び図8も参照)。
上記実施形態ではプログラム実行リソースとしてCPU12が1個のみ設けられた構成を説明したが、これに限定されるものではなく、同種のプログラム実行リソースが複数設けられた構成に適用してもよい。また、複数種のプログラム実行リソースが設けられた構成としてもよい。
更に、上記ではバッファモジュール40において、後段の画像処理モジュール38から読出要求が入力され、読出要求元の画像処理モジュール38が読出可能な有効データが自モジュールのバッファ40Aに記憶されていなかった場合に、バッファ制御部40Bがワークフロー管理部46Aへデータ要求を入力する態様を例に説明したが、これに限定されるものではなく、上記場合にバッファ制御部40Bが前段の画像処理モジュール38へデータ要求を直接入力するようにしてもよい。この態様の処理シーケンスを図19に示す。図19からも明らかなように、この態様において、ワークフロー管理部46Aは画像処理部50のうち最後段の画像処理モジュール38についてのみ処理要求を入力すれば済むので、ワークフロー管理部46Aにおける処理が簡単になる。
このように構成した場合には、バッファモジュール40のバッファ制御部40Bを、自モジュールの前段の画像処理モジュール38によってバッファ40Aに起動条件を満たすデータ量の有効データが書き込まれる毎に後段の画像処理モジュール38に対して起動要求としての処理要求を入力させるようにする。また、バッファ40Aに書き込まれた有効データが後段の画像処理モジュール38の単位読出データ量未満であり、かつ読出可能な有効データの末尾が処理対象の画像データの末尾でなければ、前段の画像処理モジュール38に対してデータ要求としての処理要求を入力させる。
なお、図20に示すように、上記画像処理装置10を、画像形成部60を備えた画像形成装置70に組み込んでもよい。この画像形成装置70では、画像処理装置10の画像処理部50が画像処理した画像データを用いて画像形成部60が画像を形成する。画像形成部60は、有色の液滴を吐出して記録媒体に画像を形成する画像形成部であってもよいし、静電写真方式で画像を形成する画像形成部であってもよい。