画像処理装置及びプログラム
【課題】大サイズの画像データを扱う場合にもバッファ容量の増大、処理速度の低下を抑制する。
【解決手段】前段のモジュールから単位データ量ずつ画像データを取得して画像処理を行い、画像処理後の画像データ又は画像処理結果を後段のモジュールへ出力する機能を備え、実行する画像処理の種類又は内容が互いに異なる複数の画像処理モジュールと、前段のモジュールからの画像データをバッファに書き込ませ、バッファに記憶されている画像データを後段のモジュールによって読み出させるバッファモジュールが連結されて構築された画像処理部において、個々のバッファモジュールは順次入力される画像データのサイズを比較して圧縮／非圧縮を判断し(120〜136)、非圧縮の場合は画像データを圧縮した後にバッファに書き込み(142)、バッファからの読出時には伸長処理を行った後に後段の画像処理モジュールへ出力する。
【解決手段】前段のモジュールから単位データ量ずつ画像データを取得して画像処理を行い、画像処理後の画像データ又は画像処理結果を後段のモジュールへ出力する機能を備え、実行する画像処理の種類又は内容が互いに異なる複数の画像処理モジュールと、前段のモジュールからの画像データをバッファに書き込ませ、バッファに記憶されている画像データを後段のモジュールによって読み出させるバッファモジュールが連結されて構築された画像処理部において、個々のバッファモジュールは順次入力される画像データのサイズを比較して圧縮／非圧縮を判断し(120〜136)、非圧縮の場合は画像データを圧縮した後にバッファに書き込み(142)、バッファからの読出時には伸長処理を行った後に後段の画像処理モジュールへ出力する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は画像処理装置及びプログラムに係り、特に、画像処理モジュール及びバッファモジュールがパイプライン形態又は有向非循環グラフ形態で連結されて構築された画像処理部を備えた画像処理装置、及び、コンピュータを前記画像処理装置として機能させるための画像処理プログラムに関する。
【背景技術】
【０００２】
入力された画像データに対して画像処理を行う画像処理装置や、画像を取扱可能なＤＴＰ（デスクトップ・パブリッシング）システム、入力された画像データが表す画像を記録材料に記録するプリントシステム等では、入力された画像データに対して拡大・縮小、回転、アフィン変換、色変換、フィルタ処理、画像合成等の各種の画像処理が行われる。これらの装置やシステムにおいて、入力される画像データの属性や画像データに対する画像処理の内容・手順・パラメータ等が固定されている場合には、専用に設計したハードウエアによって画像処理を行わせる場合もあるが、例えば色空間や１画素当たりのビット数が異なる様々な画像データが入力されたり、画像処理の内容や手順・パラメータ等が様々に変更される場合には、実行する画像処理をより柔軟に変更可能な構成が必要となる。
【０００３】
このような要求を満たすために、例えば特許文献１には、プログラマブルな処理モジュールをパイプライン形態やＤＡＧ(Directed Acyclic Graph：有向非循環グラフ)形態に接続して、所望の画像処理を行うことを可能とする技術が提案されている。特許文献１に記載の技術では、複数のプログラマブル演算処理部の各々における演算処理の内容と、ネットワーク部による各プログラマブル演算処理部の接続形態を、ホストコントロール手段を通じて外部から自在に設定できるように構成することで、高速かつ高度な演算処理が可能で、機能変更や系統変更に対する自由度が高いデジタル映像信号処理装置を実現している。
【０００４】
また、画像処理にも適用可能な技術として、特許文献２には、複数の記憶手段と、時分割された処理の一つである実行単位について、複数の記憶手段のうちの入力用の単一の記憶手段から入力データを受け取り、出力用の単一の記憶手段に処理結果を記憶するデータ処理手段と、記憶手段のデータ記憶量の情報から実行単位の実行状況を求め、実行単位の起動優先度を決定する起動優先度決定手段を備えたプロセッサが開示されている。
【特許文献１】特開平５−２６０３７３号公報
【特許文献２】特開２００４−２８７８８３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
特許文献１に記載の技術のように、複数種の画像処理モジュールを任意に組み合わせて所望の画像処理を行う画像処理装置を構成する場合、以下に述べるような問題がある。すなわち、各画像処理モジュールには、実行する画像処理の種類や内容に応じて処理し易い単位（例えば画素単位、１ライン単位、複数ライン単位、面単位等）がある。しかし、各画像処理モジュールを任意の順番で連結し協調して処理することを可能とするためには、全ての画像処理モジュールの出力単位を揃えるか、或いは各画像処理モジュールが任意の入力単位に対応可能に構成する必要があり、各画像処理モジュールの構成が複雑になる。また、各画像処理モジュールは他の画像処理モジュールと連携して動作するため、各画像処理モジュールには、入力された画像データに対して実際に画像処理を行う部分以外に、自モジュールと連結された他の画像処理モジュールとの間で画像データを受け渡す処理を制御する部分も必要となり、各画像処理モジュールの構成は一層複雑になる。
【０００６】
上記の問題は、特許文献２に記載の技術のように画像処理モジュール（データ処理手段）の前後にバッファ（記憶手段）を設けた構成を用い、個々の画像処理モジュールで各種の画像処理を行わせると共に、個々の画像処理モジュールを、実行する画像処理の種類や内容に応じた処理し易い単位ずつバッファから画像データを取得するように構成することで解決可能である。
【０００７】
しかしながら、近年デジタル画像の高精細化が進み、これに伴ってデジタル画像データのサイズも肥大化してきており、例えばカラー画像をＲＧＢで表すカラー画像データは、解像度が400dpiであれば、Ａ４サイズで44Ｍバイト、Ａ３サイズでは88Ｍバイトになり、解像度が600dpiであれば、Ａ４サイズで100Ｍバイト、Ａ３サイズでは200Ｍバイトもの大サイズになる。このため、特許文献２に記載の技術のように画像処理モジュールの前後にバッファを設ける構成では、個々のバッファの記憶容量も大きくする必要があり、個々のバッファを構成するメモリ等のリソースを大量に消費するという問題がある。また、プロセッサの動作速度に比してメモリ等の記憶デバイスの書込／読出速度は低速であり、プロセッサの性能向上に伴って上記の速度差は更に拡大する一方であるので、画像データの大サイズ化に伴ってバッファへの画像データの書き込みやバッファからの画像データの読み出しに要する時間が画像処理装置における処理速度のボトルネックとなり、処理速度の低下を招くという問題もある。
【０００８】
本発明は上記事実を考慮して成されたもので、大サイズの画像データを扱う場合にもバッファ容量の増大、処理速度の低下を抑制可能な画像処理装置及び画像処理プログラムを得ることが目的である。
【課題を解決するための手段】
【０００９】
上記目的を達成するために請求項１記載の発明に係る画像処理装置は、自モジュールの前段から単位データ量ずつ画像データを取得し、取得した画像データに対して所定の画像処理を行い、前記所定の画像処理を経た画像データ又は前記所定の画像処理の処理結果を自モジュールの後段へ出力する機能を各々備え、実行する画像処理の種類又は内容が互いに異なる複数種の画像処理モジュールの中から選択された１つ以上の画像処理モジュールと、画像データを記憶するためのバッファを備えた１つ以上のバッファモジュールと、が、前記選択された個々の画像処理モジュールの前段及び後段の少なくとも一方にバッファモジュールが連結されるように、個々のモジュールがパイプライン形態又は有向非循環グラフ形態で連結されて構築された画像処理部を備えた画像処理装置であって、前記バッファモジュールは、前段のモジュールから書込対象の画像データが入力された場合に、入力された画像データが圧縮されているか否かに応じて書込方法を切り替えて前記画像データを前記バッファに書き込む書込手段と、後段のモジュールから画像データが要求された場合に、前記バッファから画像データを読み出し、読み出した画像データが圧縮されているか否かに応じて出力方法を切り替えて前記画像データを後段のモジュールへ出力する読出手段と、を備えていることを特徴としている。
【００１０】
本発明に係る画像処理モジュールは、自モジュールの前段から単位データ量ずつ画像データを取得し、取得した画像データに対して所定の画像処理を行い、所定の画像処理を経た画像データ又は所定の画像処理の処理結果を自モジュールの後段へ出力する機能を備えている。本発明では、画像処理モジュールが実行する画像処理の種類又は内容が互いに異なる複数種の画像処理モジュールが用意されており、複数種の画像処理モジュールの中から選択された１つ以上の画像処理モジュールを用いて画像処理部が構築される。なお、画像処理部の構築のために複数の画像処理モジュールが選択される場合、これらの画像処理モジュールは、互いに異なる画像処理モジュールであってもよいし、画像処理モジュールの一部又は全部が重複して選択されてもよい。
【００１１】
また本発明に係る画像処理部は、選択された個々の画像処理モジュールの前段及び後段の少なくとも一方に、画像データを記憶するためのバッファを備えた１つ以上のバッファモジューが連結されるように、個々のモジュールがパイプライン形態又は有向非循環グラフ形態で連結されて構築される。このように、個々の画像処理モジュールの前段及び後段の少なくとも一方にバッファモジュールを連結することで、画像処理モジュールが前段から取得する画像データのサイズ（単位データ量）及び画像処理モジュールが後段へ出力する画像データのサイズを、個々の画像処理モジュールが実行する画像処理の種類や内容に応じて最適化することができ、画像処理モジュールの構成も簡単にすることができる。
【００１２】
なお、個々の画像処理モジュールが前段から取得する画像データのサイズ及び画像処理モジュールが後段へ出力する画像データのサイズは、画像の１ライン分、画像の複数ライン分、画像１面分、画像の１画素分等を含む任意のバイト数の何れであってもよく、単一の画像処理モジュールが前段から取得する画像データのサイズ及び後段へ出力する画像データのサイズは同一であっても相違していてもよい。また、個々の画像処理モジュールが後段へ出力する画像データは未圧縮の画像データであってもよいし、何らかの符号化方法により符号化されて圧縮された画像データであってもよい。
【００１３】
また、本発明に係るバッファモジュールは、前段のモジュールから書込対象の画像データが入力された場合に、入力された画像データが圧縮されているか否かに応じて書込方法を切り替えて前記画像データを前記バッファに書き込む書込手段と、後段のモジュールから画像データが要求された場合に、前記バッファから画像データを読み出し、読み出した画像データが圧縮されているか否かに応じて出力方法を切り替えて前記画像データを後段のモジュールへ出力する読出手段を備えている。これにより、例えば入力された画像データをバッファにそのまま書き込む第１の書込方法と、入力された画像データに対して圧縮処理を行った後にバッファに書き込む第２の書込方法を、入力された画像データが圧縮されているか否かに応じて切り替えると共に、バッファから読み出した画像データを後段のモジュールへそのまま出力する第１の出力方法と、バッファから読み出した画像データに対して伸長処理を行った後に後段のモジュールへ出力する第２の出力方法を、入力された画像データが圧縮されているか否かに応じて切り替えることも可能となり、大サイズの画像データを扱う場合にもバッファ容量の増大、処理速度の低下を抑制することが可能となる。
【００１４】
なお、請求項１記載の発明において、書込手段は、例えば請求項２に記載したように、前段のモジュールから入力された書込対象の画像データが圧縮されているか否か判断し、圧縮されていると判断した場合は画像データをバッファにそのまま書き込み、圧縮されていないと判断した場合は画像データに対して圧縮処理を行った後にバッファに書き込むように構成することが好ましい。これにより、前段のモジュールから入力された画像データが非圧縮の場合にも、バッファモジュールのバッファに書き込む画像データのサイズが小さくされることでバッファの容量を削減できると共に、バッファへの画像データの書込時間及びバッファからの画像データの読出時間を短縮することができる。従って、大サイズの画像データを扱う場合にもバッファ容量の増大、処理速度の低下を抑制することができる。
【００１５】
また、請求項２記載の発明において、バッファモジュールの書込手段をプロセッサで構成した場合（画像データの圧縮処理をプロセッサで行うように構成した場合）、当該プロセッサには上記処理の実行に伴って負荷が加わることになるが、前述のように本発明に係るバッファとして機能させることが可能なメモリ等の記憶デバイスに対する書込／読出速度に比してプロセッサの動作速度は高速であり、記憶デバイスに対する書込／読出速度が処理速度のボトルネックとなっているので、バッファモジュールで画像データの圧縮処理を行うことを原因として処理速度の低下が生ずることを回避することができる。
【００１６】
また、請求項１又は請求項２記載の発明において、バッファモジュールの前段のモジュールからバッファモジュールへの画像データの入力は、画像を構成する所定の単位領域毎に分けて行われるように構成することができるが、この場合、書込手段は、例えば請求項３に記載したように、単位領域のデータが前段のモジュールから所定回入力される間、入力された単位領域のデータのサイズを相互に比較し、入力された所定数の単位領域のデータのサイズが一定の場合は前段のモジュールから入力される画像データが圧縮されていないと判断し、所定数の単位領域のデータのサイズが一定でない場合は前段のモジュールから入力される画像データが圧縮されていると判断するように構成することが好ましい。前段のモジュールから入力される画像データが圧縮されているか否かは、圧縮の有無を通知する情報を前段のモジュールから送信させることによっても検知可能であるが、請求項３記載の発明では、入力される画像データが圧縮されているか否かを、前段のモジュールとの間に上記のような新たなインタフェースを設けることなく検知できるので、本発明に係る画像処理装置を構成する各モジュール間のインタフェースの複雑化を回避することができる。
【００１７】
また、請求項２記載の発明において、書込手段は、例えば請求項４に記載したように、バッファの空き容量又はバッファとして使用可能なシステムリソース（例えばメモリやＨＤＤ(Hard Disk Drive)等の記憶リソース）の空き容量が所定値以上の場合には、入力された画像データが圧縮されていないと判断したときにも、圧縮処理を行うことなく画像データをバッファにそのまま書き込むように構成してもよい。この場合、入力された画像データを記憶するために必要なバッファの容量は増大するものの、書込手段及び読出手段に加わる負荷（書込手段及び読出手段をプロセッサで構成した場合、当該プロセッサに加わる負荷）を軽減することができる。
【００１８】
また、請求項２記載の発明において、バッファを構成するデバイスのアクセス速度やバッファとの間のデータ転送速度は、画像処理装置を構成するハードウェアの構成によって左右される。これを考慮すると、書込手段は、例えば請求項５に記載したように、入力された画像データが圧縮されていないと判断した場合に、バッファを構成するデバイスがアクセス速度が第１所定値以上の記憶デバイスであるか、又は、バッファとの間のデータ転送速度が第２所定値以上の環境のときには、圧縮処理を行うことなく画像データをバッファにそのまま書き込み、バッファを構成するデバイスがアクセス速度が第１所定値未満の記憶デバイスであるか、又は、バッファとの間のデータ転送速度が第２所定値未満の環境のときには、画像データに対して圧縮処理を行った後にバッファに書き込むように構成してもよい。
【００１９】
請求項５記載の発明では、バッファを構成するデバイスがアクセス速度が第１所定値以上の記憶デバイスであるか、又は、バッファとの間のデータ転送速度が第２所定値以上の環境のとき、すなわちバッファに対する画像データの書込／読出速度が処理速度のボトルネックになりにくい場合には、圧縮処理を行うことなく画像データをバッファにそのまま書き込むので、バッファモジュールの書込手段及び読出手段（書込手段及び読出手段をプロセッサで構成した場合は当該プロセッサ）に必要以上に負荷が加わることを防止することができる。
【００２０】
また、請求項２記載の発明において、読出手段は、例えば請求項６に記載したように、後段のモジュールからの要求に応じて前記バッファから読み出した画像データが前記書込手段によって圧縮処理が行われていない画像データであれば、読み出した画像データを後段のモジュールへそのまま出力し、読み出した画像データが前記書込手段によって圧縮処理が行われた画像データであれば、読み出した画像データに対して伸長処理を行った後に後段のモジュールへ出力するように構成することが好ましい。これにより、バッファモジュールに入力され圧縮処理が行われてバッファに書き込まれた画像データが、伸長された後に（元に戻された後に）後段のモジュールへ出力されることになり、バッファモジュールが圧縮処理を行ったか否かに応じて後段のモジュール（画像処理モジュール）が処理を切り替える必要がなくなるので、本発明に係る画像処理装置の構成を簡単にすることができる。
【００２１】
なお、請求項６記載の発明において、バッファモジュールの読出手段をプロセッサで構成した場合（画像データの伸長処理をプロセッサで行うように構成した場合）、当該プロセッサには上記処理の実行に伴って負荷が加わることになるが、前述のように本発明に係るバッファとして機能させることが可能なメモリ等の記憶デバイスに対する書込／読出速度に比してプロセッサの動作速度は高速であり、記憶デバイスに対する書込／読出速度が処理速度のボトルネックとなっているので、バッファモジュールで画像データの伸長処理を行うことを原因として処理速度の低下が生ずることを回避することができる。
【００２２】
また、請求項６記載の発明において、読出手段を備えたバッファモジュールの後段のモジュールが、前段のモジュールから取得した圧縮画像データに対して伸長処理を行った後に画像処理を行う機能、又は、前段のモジュールから取得した圧縮画像データに対して伸長処理を行うことなく画像処理を行う機能を備えた画像処理モジュールである場合、読出手段は、例えば請求項７に記載したように、読み出した画像データが圧縮処理が行われた圧縮画像データであっても伸長処理を行わず、かつ圧縮画像データに適用された圧縮形式を表す属性情報を圧縮画像データに付加することで、後段の画像処理モジュールにおいて、圧縮画像データに対して伸長処理を行った後に画像処理を行わせるか、又は、圧縮画像データに対して伸長処理を行うことなく画像処理を行わせるように構成してもよい。これにより、後段の画像処理モジュールが上記機能を備えている場合に、上記機能を利用することで伸長処理の実行を省略することができ、バッファモジュールの読出手段（読出手段をプロセッサで構成した場合は当該プロセッサ）に必要以上に負荷が加わることを回避することができる。
【００２３】
請求項８記載の発明に係る画像処理プログラムは、コンピュータを、自モジュールの前段から単位データ量ずつ画像データを取得し、取得した画像データに対して所定の画像処理を行い、前記所定の画像処理を経た画像データ又は前記所定の画像処理の処理結果を自モジュールの後段へ出力する機能を各々備え、実行する画像処理の種類又は内容が互いに異なる複数種の画像処理モジュールの中から選択された１つ以上の画像処理モジュールと、画像データを記憶するためのバッファを備えた１つ以上のバッファモジュールと、が、前記選択された個々の画像処理モジュールの前段及び後段の少なくとも一方にバッファモジュールが連結されるように、個々のモジュールがパイプライン形態又は有向非循環グラフ形態で連結されて構築された画像処理部を備えた画像処理装置として機能させるための画像処理プログラムであって、前記バッファモジュールは、前段のモジュールから書込対象の画像データが入力された場合に、入力された画像データが圧縮されているか否かに応じて書込方法を切り替えて前記画像データを前記バッファに書き込む書込手段と、後段のモジュールから画像データが要求された場合に、前記バッファから画像データを読み出し、読み出した画像データが圧縮されているか否かに応じて出力方法を切り替えて前記画像データを後段のモジュールへ出力する読出手段と、を備えていることを特徴としている。
【００２４】
請求項８記載の発明に係る画像処理プログラムは、コンピュータを、上記の書込手段及び読出手段として機能させるためのプログラムであるので、コンピュータが請求項８記載の発明に係る画像処理プログラムを実行することにより、コンピュータが請求項１に記載の画像処理装置として機能することになり、請求項１記載の発明と同様に、大サイズの画像データを扱う場合にもバッファ容量の増大、処理速度の低下を抑制することが可能となる。
【発明の効果】
【００２５】
以上説明したように本発明は、実行する画像処理の種類又は内容が互いに異なる複数種の画像処理モジュールの中から選択された１つ以上の画像処理モジュールの前段及び後段の少なくとも一方にバッファモジュールが連結されるように、個々のモジュールがパイプライン形態又は有向非循環グラフ形態で連結されて構築された構成において、バッファモジュールが、前段のモジュールから書込対象の画像データが入力された場合に、入力された画像データが圧縮されているか否かに応じて書込方法を切り替えてバッファに書き込むと共に、後段のモジュールから画像データが要求された場合に、バッファから読み出した画像データが圧縮されているか否かに応じて出力方法を切り替えて後段のモジュールへ出力するようにしたので、大サイズの画像データを扱う場合にもバッファ容量の増大、処理速度の低下を抑制することが可能になる、という優れた効果を有する。
【発明を実施するための最良の形態】
【００２６】
以下、図面を参照して本発明の実施形態の一例を詳細に説明する。図１には、本発明に係る画像処理装置として機能することが可能なコンピュータ１０が示されている。なお、このコンピュータ１０は、複写機、プリンタ、ファクシミリ装置、これらの機能を兼ね備えた複合機、スキャナ、写真プリンタ等のように内部で画像処理を行う必要のある任意の画像取扱機器に組み込まれていてもよいし、パーソナル・コンピュータ（ＰＣ）等の独立したコンピュータであってもよく、更にＰＤＡ（Personal Digital Assistant）や携帯電話機等の携帯機器に組み込まれたコンピュータであってもよい。
【００２７】
コンピュータ１０はＣＰＵ１２、メモリ１４、表示部１６、操作部１８、記憶部２０、画像データ供給部２２及び画像出力部２４を備えており、これらはバス２６を介して互いに接続されている。コンピュータ１０が上述したような画像取扱機器に組み込まれている場合、表示部１６や操作部１８としては、画像取扱機器に設けられたＬＣＤ等から成る表示パネルやテンキー等を適用することができる。また、コンピュータ１０が独立したコンピュータである場合、表示部１６や操作部１８としては、当該コンピュータに接続されたディスプレイやキーボード、マウス等を適用することができる。また、記憶部２０としてはＨＤＤ(Hard Disk Drive)が好適であるが、これに代えてフラッシュメモリ等の他の不揮発性記憶手段を用いることも可能である。
【００２８】
また、画像データ供給部２２は処理対象の画像データを供給できるものであればよく、例えば紙や写真フィルム等の記録材料に記録されている画像を読み取って画像データを出力する画像読取部、通信回線を介して外部から画像データを受信する受信部、画像データを記憶する画像記憶部（メモリ１４又は記憶部２０）等を適用することができる。また、画像出力部２４は画像処理を経た画像データ又は該画像データが表す画像を出力するものであればよく、例えば画像データが表す画像を紙や感光材料等の記録材料に記録する画像記録部、画像データが表す画像をディスプレイ等に表示する表示部、画像データを記録メディアに書き込む書込装置、画像データを通信回線を介して送信する送信部を適用することができる。また、画像出力部２４は画像処理を経た画像データを単に記憶する画像記憶部（メモリ１４又は記憶部２０）であっても構わない。
【００２９】
図１に示すように、記憶部２０には、ＣＰＵ１２によって実行される各種のプログラムとして、メモリ１４等のリソースの管理やＣＰＵ１２によるプログラムの実行の管理、コンピュータ１０と外部との通信等を司るオペレーティングシステム３０のプログラム、コンピュータ１０を本発明に係る画像処理装置として機能させるための画像処理プログラム群３４、ＣＰＵ１２が上記画像処理プログラム群を実行することで実現される画像処理装置に対して所望の画像処理を行わせる各種のアプリケーション３２のプログラム（図１ではアプリケーションプログラム群３２と表記）が各々記憶されている。
【００３０】
画像処理プログラム群３４は、前述した各種の画像取扱機器や携帯機器を開発する際の開発負荷を軽減したり、ＰＣ等で利用可能な画像処理プログラムを開発する際の開発負荷を軽減することを目的として、各種の画像取扱機器や携帯機器、ＰＣ等の各種機器（プラットフォーム）で共通に使用可能に開発されたプログラムであり、本発明に係る画像処理プログラムに対応している。画像処理プログラム群３４によって実現される画像処理装置は、アプリケーション３２からの構築指示に従い、アプリケーション３２が指示した画像処理を行う画像処理部を構築し、アプリケーション３２からの実行指示に従い、前記画像処理部によって画像処理を行うが（詳細は後述）、画像処理プログラム群３４は、所望の画像処理を行う画像処理部（所望の構成の画像処理部）の構築を指示したり、構築された画像処理部による画像処理の実行を指示するためのインタフェースをアプリケーション３２に提供している。このため、内部で画像処理を行う必要のある任意の機器を新規開発する等の場合にも、前記画像処理を行うプログラムの開発に関しては、当該機器で必要とされる画像処理を上記のインタフェースを利用して画像処理プログラム群３４に行わせるアプリケーション３２を開発するのみで済み、実際に画像処理を行うプログラムを新たに開発する必要が無くなるので、開発負荷を軽減することができる。
【００３１】
また、画像処理プログラム群３４によって実現される画像処理装置は、前述のように、アプリケーション３２からの構築指示に従い、アプリケーション３２が指示した画像処理を行う画像処理部を構築し、構築した画像処理部によって画像処理を行うので、例えば画像処理対象の画像データの色空間や１画素当たりのビット数が不定であったり、実行すべき画像処理の内容や手順・パラメータ等が不定である場合にも、アプリケーション３２が画像処理部の再構築を指示することで、画像処理装置（画像処理部）によって実行される画像処理を、処理対象の画像データ等に応じて柔軟に変更することができる。
【００３２】
以下、画像処理プログラム群３４について説明する。図１に示すように、画像処理プログラム群３４はモジュールライブラリ３６と、処理構築部４２のプログラムと、処理管理部４６のプログラムに大別される。詳細は後述するが、本実施形態に係る処理構築部４２は、アプリケーションからの指示により、例として図２に示すように、予め定められた画像処理を行う１つ以上の画像処理モジュール３８と、個々の画像処理モジュール３８の前段及び後段の少なくとも一方に配置され画像データを記憶するためのバッファを備えたバッファモジュール４０と、がパイプライン形態又はＤＡＧ(Directed Acyclic Graph：有向非循環グラフ)形態で連結されて成る画像処理部５０を構築する。画像処理部５０を構成する個々の画像処理モジュールの実体はＣＰＵ１２によって実行されＣＰＵ１２で所定の画像処理を行わせるための第１のプログラム、又は、ＣＰＵ１２によって実行されＣＰＵ１２により図１に図示されていない外部の画像処理装置（例えば専用画像処理ボード等）に対する処理の実行を指示するための第２のプログラムであり、上述したモジュールライブラリ３６には、予め定められた互いに異なる画像処理（例えば入力処理やフィルタ処理、色変換処理、拡大・縮小処理、スキュー角検知処理、画像回転処理、画像合成処理、出力処理等）を行う複数種の画像処理モジュール３８のプログラムが各々登録されている。以下では、説明を簡単にするために、画像処理部５０を構成する個々の画像処理モジュールの実体が上記の第１のプログラムであるものとして説明する。
【００３３】
個々の画像処理モジュール３８は、例として図８(Ａ)にも示すように、画像データに対する画像処理を所定の単位処理データ量ずつ行う画像処理エンジン３８Ａと、画像処理モジュール３８の前段及び後段のモジュールとの画像データの入出力及び画像処理エンジン３８Ａの制御を行う制御部３８Ｂから構成されている。個々の画像処理モジュール３８における単位処理データ量は、画像の１ライン分、画像の複数ライン分、画像の１画素分、画像１面分等を含む任意のバイト数の中から、画像処理エンジン３８Ａが行う画像処理の種類等に応じて予め選択・設定されており、例えば色変換処理やフィルタ処理を行う画像処理モジュール３８では単位処理データ量が１画素分とされ、拡大・縮小処理を行う画像処理モジュール３８では単位処理データ量が画像の１ライン分又は画像の複数ライン分とされ、画像回転処理を行う画像処理モジュール３８では単位処理データ量が画像１面分とされ、画像圧縮伸長処理を行う画像処理モジュール３８では単位処理データ量が実行環境に依存するＮバイトとされている。
【００３４】
また、モジュールライブラリ３６には、画像処理エンジン３８Ａが実行する画像処理の種類が同一でかつ実行する画像処理の内容が異なる画像処理モジュール３８も登録されている（図１では、この種の画像処理モジュールを「モジュール１」「モジュール２」と表記して示している）。例えば拡大・縮小処理を行う画像処理モジュール３８については、入力された画像データを１画素おきに間引くことで50％に縮小する縮小処理を行う画像処理モジュール３８、入力された画像データに対して指定された拡大・縮小率で拡大・縮小処理を行う画像処理モジュール３８等の複数の画像処理モジュール３８が各々用意されている。また、例えば色変換処理を行う画像処理モジュール３８については、ＲＧＢ色空間をＣＭＹ色空間へ変換する画像処理モジュール３８やその逆へ変換する画像処理モジュール３８、Ｌ*ａ*ｂ*色空間等の他の色空間変換を行う画像処理モジュール３８が各々用意されている。
【００３５】
また、画像処理モジュール３８の制御部３８Ｂは、画像処理エンジン３８Ａが単位処理データ量ずつ処理するために必要な画像データを入力するために、自モジュールの前段のモジュール（例えばバッファモジュール４０）から画像データを単位読出データ量ずつ取得し、画像処理エンジン３８Ａから出力される画像データを単位書込データずつ後段のモジュール（例えばバッファモジュール４０）へ出力する（画像処理エンジン３８Ａで圧縮等のデータ量の増減を伴う画像処理が行われなければ単位書込データ量＝単位処理データ量となる）か、画像処理エンジン３８Ａによる画像処理の結果を自モジュールの外部へ出力する（例えば画像処理エンジン３８Ａがスキュー角検知処理等の画像解析処理を行う場合、画像データに代えてスキュー角検知結果等の画像解析処理結果が出力されることがある）処理を行うが、モジュールライブラリ３６には、画像処理エンジン３８Ａが実行する画像処理の種類及び内容が同一で、上記の単位処理データ量や単位読出データ量、単位書込データ量が異なる画像処理モジュール３８も登録されている。例えば、先程は画像回転処理を行う画像処理モジュール３８における単位処理データ量を画像１面分と説明したが、同じ画像回転処理を行う画像処理モジュール３８で単位処理データ量が画像の１ライン分又は画像の複数ライン分であるものがモジュールライブラリ３６に含まれていても良い。
【００３６】
また、モジュールライブラリ３６に登録されている個々の画像処理モジュール３８のプログラムは、画像処理エンジン３８Ａに相当するプログラムと制御部３８Ｂに相当するプログラムから構成されているが、制御部３８Ｂに相当するプログラムは部品化されており、個々の画像処理モジュール３８のうち単位読出データ量及び単位書込データ量が同一の画像処理モジュール３８は、画像処理エンジン３８Ａで実行される画像処理の種類や内容に拘わらず、制御部３８Ｂに相当するプログラムが共通化されている（制御部３８Ｂに相当するプログラムとして同一のプログラムが用いられている）。これにより、画像処理モジュール３８のプログラムの開発にあたっての開発負荷が軽減される。
【００３７】
なお、画像処理モジュール３８の中には、入力される画像の属性が未知の状態では単位読出データ量及び単位書込データ量が確定しておらず、入力画像データの属性を取得し、取得した属性を所定の演算式に代入して演算することで単位読出データ量や単位書込データ量が確定するモジュールが存在しているが、この種の画像処理モジュール３８については、単位読出データ量と単位書込データ量が互いに同一の演算式を用いて導出される画像処理モジュール３８について、制御部３８Ｂに相当するプログラムを共通化するようにすればよい。また、本実施形態に係る画像処理プログラム群３４は、前述のように各種機器に実装可能であるが、画像処理プログラム群３４のうちモジュールライブラリ３６に登録する画像処理モジュール３８の数や種類等については、画像処理プログラム群３４を実装する各種機器で必要とされる画像処理に応じて、適宜追加・削除・入替等が可能であることは言うまでもない。
【００３８】
また、画像処理部５０を構成する個々のバッファモジュール４０は、例として図８(Ｂ)にも示すように、コンピュータ１０に設けられたメモリ１４からオペレーティングシステム３０を通じて確保されたメモリ領域で構成されるバッファ４０Ａと、バッファモジュール４０の前段及び後段のモジュールとの画像データの入出力及びバッファ４０Ａの管理を行うバッファ制御部４０Ｂから構成されており、更にバッファ制御部４０Ｂは書込制御部４０Ｃと読出制御部４０Ｄを備えている。個々のバッファモジュール４０のバッファ制御部４０Ｂ（の書込制御部４０Ｃ及び読出制御部４０Ｄ）もその実体はＣＰＵ１２によって実行されるプログラムであり、モジュールライブラリ３６にはバッファ制御部４０Ｂのプログラムも登録されている（図１ではバッファ制御部４０Ｂのプログラムを「バッファモジュール」と表記して示している）。
【００３９】
また、アプリケーション３２からの指示に従って画像処理部５０を構築する処理構築部４２は、図１に示すように複数種のモジュール生成部４４から構成されている。複数種のモジュール生成部４４は互いに異なる画像処理に対応しており、アプリケーション３２によって起動されることで、対応する画像処理を実現するための画像処理モジュール３８及びバッファモジュール４０から成るモジュール群を生成する処理を行う。なお、図１ではモジュール生成部４４の一例として、モジュールライブラリ３６に登録されている個々の画像処理モジュール３８が実行する画像処理の種類に対応するモジュール生成部４４を示しているが、個々のモジュール生成部４４に対応する画像処理は、複数種の画像処理モジュール３８によって実現される画像処理（例えばスキュー角検知処理と画像回転処理から成るスキュー補正処理）であってもよい。必要とされる画像処理が複数種の画像処理を組み合わせた処理である場合、アプリケーション３２は複数種の画像処理の何れかに対応するモジュール生成部４４を順次起動する。これにより、アプリケーション３２によって順次起動されたモジュール生成部４４により、必要とされる画像処理を行う画像処理部５０が構築されることになる。
【００４０】
また図１に示すように、処理管理部４６は、画像処理部５０における画像処理の実行を制御するワークフロー管理部４６Ａ、画像処理部５０の各モジュールによるメモリ１４や各種のファイル等のコンピュータ１０のリソースの使用を管理するリソース管理部４６Ｂ、及び、画像処理部５０で発生したエラーを管理するエラー管理部４６Ｃを含んで構成されている。なお、本実施形態において、処理構築部４２によって構築される画像処理部５０は、画像処理部５０を構成する個々の画像処理モジュール３８が、画像１面分よりも小さいデータ量を単位として後段へ画像データを引き渡しながら並列に画像処理を行うように動作する（ブロック単位処理と称する）。
【００４１】
なお、リソース管理部４６Ｂによるメモリ管理の方式としては、例えば、画像処理部５０の個々のモジュールからの要求の都度、メモリ１４から要求元のモジュールに割り当てるメモリ領域をオペレーティングシステム３０を通じて確保する第１管理方式、メモリ１４から一定サイズのメモリ領域をオペレーティングシステム３０を通じて事前に（例えばコンピュータ１０の電源投入時に）確保し、個々のモジュールからの要求があると、事前に確保したメモリ領域のうちの一部領域を要求元のモジュールに割り当てる第２管理方式、及び、メモリ１４から一定サイズのメモリ領域をオペレーティングシステム３０を通じて事前に確保し、個々のモジュールからの要求があると、要求されたメモリ領域のサイズが閾値未満であれば事前に確保したメモリ領域のうちの一部領域を要求元のモジュールに割り当て、要求されたメモリ領域のサイズが閾値以上であれば要求元のモジュールに割り当てるメモリ領域をオペレーティングシステム３０を通じて確保する第３管理方式の何れかを採用することができる。また、何れの管理方式でメモリ管理を行うかを選択・設定可能としてもよい。
【００４２】
またエラー管理部４６Ｃは、画像処理部５０が画像処理を実行している途中でエラーが発生した場合に、発生したエラーの種別・発生箇所等のエラー情報を取得し、画像処理プログラム群３４がインストールされたコンピュータ１０が組み込まれている機器の種別や構成等を表す装置環境情報を記憶部２０等から取得し、取得した装置環境情報が表す装置環境に応じたエラー通知方法を判断し、判断したエラー通知方法でエラーの発生を通知する処理を行う。
【００４３】
次に本実施形態の作用を説明する。画像処理プログラム群３４が実装されている機器において、何らかの画像処理を行う必要のある状況になると、この状況が特定のアプリケーション３２によって検知される。なお、画像処理を行う必要のある状況としては、例えば画像データ供給部２２としての画像読取部によって画像を読み取り、画像出力部２４としての画像記録部により記録材料に画像として記録するか、画像出力部２４としての表示部に画像として表示させるか、画像出力部２４としての書込装置により画像データを記録メディアに書き込むか、画像出力部２４としての送信部により画像データを送信するか、画像出力部２４としての画像記憶部に記憶させるジョブの実行がユーザによって指示された場合、或いは、画像データ供給部２２としての受信部によって受信されるか、画像データ供給部２２としての画像記憶部に記憶されている画像データに対して、上記の記録材料への記録、表示部への表示、記録メディアへの書き込み、送信、画像記憶部への記憶の何れかを行うジョブの実行がユーザによって指示された場合が挙げられる。また、画像処理を行う必要のある状況は上記に限られるものではなく、例えばユーザからの指示に応じてアプリケーション３２が実行可能な処理の名称等を表示部１６に一覧表示している状態で、実行対象の処理がユーザによって選択された等の場合であってもよい。
【００４４】
上記のように、何らかの画像処理を行う必要のある状況になったことを検知すると、アプリケーション３２は、まず画像処理対象の画像データを供給する画像データ供給部２２の種別を認識し、認識した種別がバッファ領域（メモリ１４の一部領域）であった場合には、画像データ供給部２２として指定されたバッファ領域を既に確保されたバッファ４０Ａとしてバッファ制御部４０Ｂに認識させるパラメータを設定し、バッファ制御部４０Ｂのプログラムを実行するプロセス、スレッド又はオブジェクトを生成する（バッファ制御部４０Ｂを生成する）ことで、指定されたバッファ領域を含むバッファモジュール４０（画像データ供給部２２として機能するバッファモジュール４０）を生成する。
【００４５】
続いてアプリケーション３２は、上記と同様に、画像処理を行った画像データの出力先としての画像出力部２４の種別を認識し、認識した種別がバッファ領域（メモリ１４の一部領域）であった場合は、画像出力部２４として指定されたバッファ領域を含むバッファモジュール４０を上記と同様にして生成する。ここで生成されたバッファモジュール４０は画像出力部２４として機能する。また、アプリケーション３２は実行すべき画像処理の内容を認識し、実行すべき画像処理を、個々のモジュール生成部４４に対応するレベルの画像処理の組み合わせに分解し、実行すべき画像処理を実現するために必要な画像処理の種類及び個々の画像処理の実行順序を判定する。なお、この判定は、例えば上記の画像処理の種類及び個々の画像処理の実行順序を、ユーザが実行を指示可能なジョブの種類と対応付けて予め情報として登録しておき、アプリケーション３２は、実行が指示されたジョブの種類に対応する情報を読み出すことによって実現することができる。
【００４６】
そしてアプリケーション３２は、上記で判定した画像処理の種類及び実行順序に基づいて、特定の画像処理に対応するモジュール生成部４４を起動（モジュール生成部４４のプログラムを実行するプロセス、スレッド又はオブジェクトを生成）した後に、起動したモジュール生成部４４に対し、当該モジュール生成部４４によるモジュール群の生成に必要な情報として、前記モジュール群に画像データを入力する入力モジュールを識別するための入力モジュール識別情報、前記モジュール群が画像データを出力する出力モジュールを識別するための出力モジュール識別情報、前記モジュール群に入力される入力画像データの属性を表す入力画像属性情報、実行すべき画像処理のパラメータを通知して対応するモジュール群の生成を指示する。また、必要とされる画像処理が複数種の画像処理を組み合わせた処理である場合、アプリケーション３２は、指示したモジュール生成部４４からモジュール群の生成完了が通知されると、個々の画像処理に対応する他のモジュール生成部４４を起動してモジュール群の生成に必要な情報を通知する処理を個々の画像処理の実行順序の昇順に繰り返す。
【００４７】
なお、上記の入力モジュールは、実行順序が１番目のモジュール群については画像データ供給部２２が入力モジュールとなり、実行順序が２番目以降のモジュール群については前段のモジュール群の最終モジュール（通常はバッファモジュール４０）が入力モジュールとなる。また、上記の出力モジュールについては、実行順序が最後のモジュール群では画像出力部２４が出力モジュールとなるので、画像出力部２４が出力モジュールとして指定されるが、その他のモジュール群では出力モジュールは未確定のためにアプリケーション３２による指定は行われず、必要な場合はモジュール生成部４４によって生成・設定される。また、入力画像属性や画像処理のパラメータについては、例えばユーザが実行を指示可能なジョブの種類と対応付けて予め情報として登録しておき、実行が指示されたジョブの種類に対応する情報を読み出すことでアプリケーション３２が認識するようにしてもよいし、ユーザに指定させるようにしてもよい。
【００４８】
一方、モジュール生成部４４は、アプリケーション３２によって起動されるとモジュール生成処理を行う。モジュール生成処理では、まず生成対象の画像処理モジュール３８に入力される入力画像データの属性を表す入力画像属性情報を取得する。なお、入力画像データの属性を取得する処理は、生成対象の画像処理モジュール３８の前段にバッファモジュール４０が存在している場合、当該バッファモジュール４０に画像データの書き込みを行う更に前段の画像処理モジュール３８から出力画像データの属性を取得することによって実現できる。
【００４９】
そして、取得した情報が表す入力画像データの属性に基づいて、生成対象の画像処理モジュール３８の生成が必要か否か判定する。例えばモジュール生成部４４が色変換処理を行うモジュール群を生成するモジュール生成部であり、画像処理のパラメータにより出力画像データの色空間としてＣＭＹ色空間がアプリケーション３２から指定された場合、取得した入力画像属性情報に基づいて入力画像データがＲＧＢ色空間のデータであることが判明したときには、色空間処理を行う画像処理モジュール３８としてＲＧＢ→ＣＭＹの色空間変換を行う画像処理モジュール３８を生成する必要があるが、入力画像データがＣＭＹ色空間のデータであったときには、入力画像データの属性と出力画像データの属性が色空間に関して一致しているので、色空間変換処理を行う画像処理モジュール３８は生成不要と判断する。
【００５０】
生成対象の画像処理モジュール３８の生成が必要と判断した場合には、生成対象の画像処理モジュール３８の後段にバッファモジュール４０が必要が否かを判定する。この判定は、画像処理モジュールの後段が出力モジュール（画像出力部２４）である場合（例えば図２(Ａ)〜(Ｃ)に示す画像処理部５０における最後段の画像処理モジュール３８を参照）や、例として図２(Ｂ)に示す画像処理部５０においてスキュー角検知処理を行う画像処理モジュール３８のように、画像処理モジュールが、画像データに対して解析等の画像処理を行いその結果を他の画像処理モジュール３８へ出力するモジュールである場合は否定されるが、上記以外の場合は判定が肯定されてバッファ制御部４０Ｂを起動する（バッファ制御部４０Ｂのプログラムを実行するプロセス、スレッド又はオブジェクトを各々生成する）ことで、画像処理モジュール３８の後段に連結するバッファモジュール４０を生成する。
【００５１】
続いて、前段のモジュール（例えばバッファモジュール４０）の情報、後段のバッファモジュール４０の情報（後段にバッファモジュール４０を生成した画像処理モジュール３８のみ）、画像処理モジュール３８に入力される入力画像データの属性、処理パラメータを与えて、モジュールライブラリ３６に登録されており、画像処理モジュール３８として利用可能な複数の候補モジュールの中から、先に取得した入力画像データの属性、及び、画像処理モジュール３８で実行すべき処理パラメータに合致する画像処理モジュール３８を選択・生成（画像処理エンジン３８Ａ及び制御部３８Ｂのプログラムを実行するプロセス、スレッド又はオブジェクトを生成）する。
【００５２】
例えばモジュール生成部４４が色変換処理を行うモジュール群を生成するモジュール生成部であり、処理パラメータにより出力画像データの色空間としてＣＭＹ色空間が指定され、更に入力画像データがＲＧＢ色空間のデータであった場合には、モジュールライブラリ３６に登録されている各種の色空間処理を行う複数種の画像処理モジュール３８の中から、ＲＧＢ→ＣＭＹの色空間変換を行う画像処理モジュール３８が選択・生成される。また、画像処理モジュールが拡大・縮小処理を行う画像処理モジュール３８であり、指定された拡大縮小率が50％以外であれば、入力された画像データに対して指定された拡大・縮小率で拡大・縮小処理を行う画像処理モジュール３８が選択・生成され、指定された拡大縮小率が50％であれば、拡大縮小率50％に特化した拡大縮小処理、すなわち入力された画像データを１画素おきに間引くことで50％に縮小する縮小処理を行う画像処理モジュール３８が選択・生成される。
【００５３】
なお、画像処理モジュール３８の選択は上記に限られるものではなく、例えば画像処理エンジン３８Ａによる画像処理における単位処理データ量が異なる画像処理モジュール３８をモジュールライブラリ３６に複数登録しておき、画像処理部５０へ割当可能なメモリ領域のサイズ等の動作環境に応じて、適切な単位処理データ量の画像処理モジュール３８を選択する（例えば上記サイズが小さくなるに従って単位処理データ量の小さい画像処理モジュール３８を選択する等）ようにしてもよいし、アプリケーション３２或いはユーザに選択させるようにしてもよい。
【００５４】
画像処理モジュール３８の生成が完了すると、後段のバッファモジュール４０のＩＤと生成した画像処理モジュール３８のＩＤの組をワークフロー管理部４６Ａに通知する。このＩＤは、個々のモジュールを一意に判別できる情報であればよく、例えば個々のモジュールの生成順に付与した番号や、バッファモジュール４０や画像処理モジュール３８のオブジェクトのメモリ上でのアドレス等でも良い。またモジュール生成部４４が、複数種の画像処理モジュール３８によって実現される画像処理（例えばスキュー角検知処理を行う画像処理モジュール３８と画像回転処理を行う画像処理モジュール３８によって実現されるスキュー補正処理）を行うモジュール群を生成する場合には、上記処理が繰り返されて２個以上の画像処理モジュール３８を含むモジュール群が生成される。アプリケーション３２によって順次起動された個々のモジュール生成部４４により、以上のモジュール生成処理が順次行われることで、例として図２(Ａ)〜(Ｃ)に示すように、必要とされる画像処理を行う画像処理部５０が構築される。
【００５５】
なお、本実施形態では、特定の画像処理の実行頻度が高い等の場合に、アプリケーション３２が、特定の画像処理を行う画像処理部５０を生成するための複数種のモジュール生成部４４に対し、特定の画像処理を行う画像処理部５０を生成させた後も処理終了を指示しないことでプロセス、スレッド又はオブジェクトとして残しておき、特定の画像処理を行う必要が生ずる毎に、プロセス、スレッド又はオブジェクトとして残しておいた各モジュール生成部４４に対してモジュール群の生成を順次指示することで、特定の画像処理を行う画像処理部５０を再生成させることも可能とされている。これにより、特定の画像処理を行う必要が生ずる毎に対応する各モジュール生成部４４を各々起動する処理が不要となり、特定の画像処理を行う画像処理部５０を再生成するのに要する時間を短縮することができる。
【００５６】
ところで、画像処理モジュール３８の制御部３８Ｂは、モジュール生成部４４によって起動されると画像処理モジュール３８の初期化を行う。この初期化では、まずモジュール生成部４４から与えられた自モジュールの前段及び後段のモジュールの情報を記憶する。次に、自モジュールの画像処理エンジン３８Ａが行う画像処理の種類や内容等に基づき、自モジュールが使用するメモリのサイズ及び自モジュールが使用する他のリソースの有無を認識する。なお、自モジュールが使用するメモリは、画像処理エンジン３８Ａが画像処理を行うために必要なメモリが主であるが、前段のモジュールが画像データ供給部２２である場合や後段のモジュールが画像出力部２４である場合には、前段又は後段のモジュールとの画像データの送受に際して画像データを一時記憶するためのバッファ用のメモリが必要となることもある。また、処理パラメータにテーブル等の情報が含まれている場合には、それを保持するためのメモリ領域が必要となることもある。そして、認識したサイズのメモリ領域の確保をリソース管理部４６Ｂへ要求し、リソース管理部４６Ｂによって確保されたメモリ領域をリソース管理部４６Ｂから受け取る。また、自モジュール（の画像処理エンジン３８Ａ）がメモリ以外の他のリソースを必要としていると認識した場合には、上記他のリソースの確保をリソース管理部４６Ｂへ要求し、上記他のリソースをリソース管理部４６Ｂから受け取る。
【００５７】
続いて自モジュールの前段のモジュールを判定する。自モジュールの前段にモジュールが存在していない場合には何ら処理を行わないが、前段のモジュールがバッファモジュール４０以外、例えば画像データ供給部２２や特定のファイル等である場合には、必要に応じてその初期化処理を行う。また、自モジュールの前段にバッファモジュール４０が存在している場合には、前段のバッファモジュール４０からの１回の画像データの読み出しによって取得する画像データのデータ量（単位読出データ量）を認識する。この単位読出データ量は、自モジュールの前段のバッファモジュール４０の数が１個であれば１個だけであるが、例えば図２(Ｃ)に示す画像処理部５０において画像合成処理を行う画像処理モジュール３８のように、前段のバッファモジュール４０の数が複数で、複数のバッファモジュール４０から各々取得した画像データを用いて画像処理エンジン３８Ａが画像処理を行う等の場合、前段の個々のバッファモジュール４０に対応する単位読出データ量は、自モジュールの画像処理エンジン３８Ａが行う画像処理の種類や内容、前段のバッファモジュール４０の数等に応じて定まる。そして、認識した単位読出データ量を、前段に存在している全てのバッファモジュール４０へ通知することで、前段に存在している全てのバッファモジュール４０に単位読出データ量を設定する（図８(Ａ)の(1)も参照）。
【００５８】
次に、自モジュールの後段のモジュールを判定する。自モジュールの後段のモジュールがバッファモジュール４０以外、例えば画像出力部２４や特定のファイル等の場合には、必要に応じてその初期化処理（例えば後段のモジュールが画像出力部２４であれば、単位書込データ量に相当するデータ量ずつ画像データを出力することを通知する処理等）を行う。また、後段のモジュールがバッファモジュール４０であれば、１回の画像データの書き込みにおける画像データのデータ量（単位書込データ量）を認識し、後段のバッファモジュールに当該単位書込データ量を設定（図８(Ａ)の(2)も参照）する。そして、当該画像処理モジュール３８の初期化の完了をモジュール生成部４４に通知して処理を終了する。
【００５９】
一方、画像処理部５０を構成する個々のバッファモジュール４０のバッファ制御部４０Ｂは、モジュール生成部４４又はアプリケーション３２によって起動されるとバッファモジュール４０の初期化を行う。バッファモジュール４０の初期化では、まず自モジュールの前段の画像処理モジュール３８から単位書込データ量が通知されるか又は自モジュールの後段の画像処理モジュール３８から単位読出データ量が通知される毎に、通知された単位書込データ量又は単位読出データ量を記憶する（図８(Ｂ)の(1),(2)も参照）。
【００６０】
自モジュールと連結されている全ての画像処理モジュール３８から単位書込データ量又は単位読出データ量が通知されると、自モジュールと連結されている個々の画像処理モジュール３８によって各々設定された単位書込データ量及び単位読出データ量に基づいて、自モジュールのバッファ４０Ａの管理単位である単位バッファ領域のサイズを決定し、決定した単位バッファ領域のサイズを記憶する。単位バッファ領域のサイズとしては、自モジュールに設定された単位書込データ量及び単位読出データ量のうちの最大値が好適であるが、単位書込データ量を設定してもよいし、単位読出データ量（自モジュールの後段に複数の画像処理モジュール３８が連結されている場合は、個々の画像処理モジュール３８によって各々設定された単位読出データ量の最大値）を設定してもよいし、単位書込データ量と単位読出データ量（の最大値）の最小公倍数を設定してもよいし、この最小公倍数が所定値未満であれば最小公倍数を、最小公倍数が所定値以上であれば別の値（例えば上述した単位書込データ量及び単位読出データ量のうちの最大値、単位書込データ量、単位読出データ量（の最大値）の何れか）を設定するようにしてもよい。
【００６１】
また、自モジュールがアプリケーション３２によって生成され、画像データ供給部２２又は画像出力部２４として機能するバッファモジュール４０であった場合には、自モジュールのバッファ４０Ａとして用いるメモリ領域が既に存在しているので、先に決定した単位バッファ領域のサイズを、自モジュールのバッファ４０Ａとして用いる既設のメモリ領域のサイズに変更する。更に、自モジュールの後段の個々の画像処理モジュール３８に対応する有効データポインタを各々生成し、生成した有効データポインタを初期化する。この有効データポインタは、自モジュールの前段の画像処理モジュールによって自モジュールのバッファ４０Ａに書き込まれた画像データのうち、対応する後段の画像処理モジュール３８によって読み出されていない画像データ（有効データ）の先頭位置（次の読出開始位置）と末尾位置を各々指し示すポインタであり、初期化時には通常、有効データが存在していないことを意味する特定の情報が設定されるが、自モジュールが自モジュールがアプリケーション３２によって生成され、画像データ供給部２２として機能するバッファモジュール４０であれば、自モジュールのバッファ４０Ａとして用いるメモリ領域には既に画像処理対象の画像データが書き込まれていることがあり、この場合は当該画像データの先頭位置及び末尾位置が後段の個々の画像処理モジュール３８に対応する有効データポインタに各々設定される。
【００６２】
また、バッファ制御部４０Ｂの書込制御部４０Ｃによって行われるデータ書込処理で使用される「検出フラグ」を１に、「圧縮フラグ」及び「入力回数」を各々０に初期設定する。以上の処理によりバッファモジュール４０の初期化が完了し、バッファ制御部４０Ｂは初期化の完了をワークフロー管理部４６Ａへ通知する。
【００６３】
一方、アプリケーション３２は、順次起動したモジュール生成部４４によって前述のモジュール生成処理が順次行われることで、必要とされる画像処理を行う画像処理部５０の構築が完了すると、ワークフロー管理部４６Ａのプログラムを実行するスレッド（又はプロセス又はオブジェクト）を起動することで、ワークフロー管理部４６Ａに対して画像処理部５０による画像処理の実行を指示する。
【００６４】
処理管理部４６のワークフロー管理部４６Ａは、プログラムが起動されることで図９に示すブロック単位制御処理を行う。ワークフロー管理部４６Ａはブロック単位処理において、画像処理部５０を構成する画像処理モジュール３８のうちの所定の画像処理モジュール３８に処理要求を入力することで、画像処理部５０による画像処理をブロック単位の実行形態で行わせるが、以下では画像処理部５０全体の動作説明に先立ち、個々のバッファモジュール４０のバッファ制御部４０Ｂによって行われる初期化処理完了以降の処理、個々の画像処理モジュール３８の制御部３８Ｂによって行われる画像処理モジュール制御処理について順に説明する。
【００６５】
本実施形態では、画像処理モジュール３８が後段のバッファモジュール４０に画像データを書き込む場合には、画像処理モジュール３８からバッファモジュール４０へ書込要求が入力され、画像処理モジュール３８が前段のバッファモジュール４０から画像データを読み出す場合には、画像処理モジュール３８からバッファモジュール４０へ読出要求が入力される。前段の画像処理モジュール３８からの書込要求を含む何らかの情報がバッファモジュール４０に入力された場合（及び、後述するタイマがタイムアウトした場合）は、図３に示すデータ書込処理がバッファ制御部４０Ｂの書込制御部４０Ｃによって実行される。なお、以下で説明するデータ書込処理は、関数やメソッドの呼び出しで処理が始まるようにしてもよい。なお、このデータ書込処理を行う書込制御部４０Ｃは本発明に係る書込手段（詳しくは請求項２に記載の書込手段）に対応している。
【００６６】
データ書込処理では、まずステップ１００において、今回のデータ書込処理の起動要因が、タイマがタイムアウトしたことによる起動か否か判定する。判定が否定された場合はステップ１０４へ移行するが、上記判定が肯定された場合はステップ１０２へ移行し、過去に入力されてワークメモリ等に保管している書込要求情報をワークメモリ等から取り出す。ステップ１０４では、処理対象の情報（バッファモジュール４０に入力された情報又はワークメモリ等から取り出した情報）が書込要求情報か否か判定する。判定が肯定された場合はステップ１０６へ移行し、自モジュールのバッファ４０Ａが他のプロセス、スレッド又はオブジェクトによって使用中か否か判定する。バッファ４０Ａは読出制御部４０Ｄからもアクセスされるので、当該判定が肯定された場合はステップ１０８へ移行して今回の処理対象の書込要求情報をワークメモリ等に保管し、次のステップ１１０でタイマをスタートさせてデータ書込処理を一旦終了する。
【００６７】
一方、ステップ１０６の判定が否定された場合にはステップ１１２へ移行し、確保すべきメモリ領域のサイズとして単位書込データ量をリソース管理部４６Ｂに通知して、書込用に用いるメモリ領域（書込用バッファ領域：図４(Ｂ)も参照）をリソース管理部４６Ｂによって確保させる。次のステップ１１４では、自モジュールのバッファ４０Ａを構成する保管用の単位バッファ領域の中に、単位書込データ量以上の空き領域が有る単位バッファ領域（単位書込データ量の画像データを書き込み可能な単位バッファ領域）が存在しているか否か判定する。モジュール生成部４４によって生成されたバッファモジュール４０は、当初はバッファ４０Ａとして用いるメモリ領域（単位バッファ領域）が確保されておらず、メモリ領域の不足が生ずる度に単位バッファ領域を単位として確保されるので、バッファモジュール４０に最初に書込要求が入力されたときにはバッファ４０Ａとして用いるメモリ領域（単位バッファ領域）が存在しておらず、この判定は否定される。また、後述する処理を経てバッファ４０Ａとして用いる単位バッファ領域が確保された後も、当該単位バッファ領域への画像データの書込に伴って当該単位バッファ領域内の空き領域が単位書込データ量未満になった場合にも上記判定は否定される。
【００６８】
ステップ１１４の判定が否定された場合はステップ１１６へ移行し、確保すべきメモリ領域のサイズ（単位バッファ領域のサイズ）をリソース管理部４６Ｂに通知して、自モジュールのバッファ４０Ａとして用いるメモリ領域（画像データの保管に用いる単位バッファ領域）をリソース管理部４６Ｂによって確保させた後にステップ１１８へ移行する。また、ステップ１１４の判定が肯定された場合はステップ１１６をスキップしてステップ１１８へ移行する。そしてステップ１１８では、先のステップ１１２で確保した書込用バッファ領域を書込領域として、当該書込領域の先頭アドレスを書込要求元の画像処理モジュール３８へ通知すると共に、書込対象の画像データを通知した先頭アドレスから順に書き込むよう要請する。これにより、書込要求元の画像処理モジュール３８は、先頭アドレスが通知された書込領域（単位バッファ領域又は書込用バッファ領域）に画像データを書き込む（図４（Ｂ）も参照）。
【００６９】
例えば単位バッファ領域のサイズが単位書込データ量の整数倍でない場合、バッファ４０Ａ（単位バッファ領域）への単位書込データ量の画像データの書込が繰り返されることで、例として図４(Ａ)にも示すように、空き領域有りの単位バッファ領域における空き領域のサイズが単位書込データ量よりも小さい状態が生ずる。この場合、単位書込データ量の画像データが書き込まれる領域が複数の単位バッファ領域に跨ることになるが、本実施形態では、バッファ４０Ａとして用いるメモリ領域を単位バッファ領域を単位として確保するので、異なるタイミングで確保した単位バッファ領域が実メモリ（メモリ１４）上で連続する領域であることは保証されない。これに対して本実施形態では、画像処理モジュール３８による画像データの書き込みを、保管用の単位バッファ領域と別に確保した書込用バッファ領域に対して行わせ、図４(Ｃ)に示すように、書込用バッファ領域に一旦書き込まれた画像データを保管用の単一又は複数の単位バッファ領域へ複写するので、画像データが書き込まれる領域が複数の単位バッファ領域に跨るか否かに拘わらず、書込要求元の画像処理モジュール３８への書込領域の通知は、上記のようにその先頭アドレスを通知するのみで済み、画像処理モジュール３８とのインタフェースが簡単になる。
【００７０】
なお、自モジュールがアプリケーション３２によって生成されたバッファモジュール４０である場合、すなわちバッファ４０Ａとして用いるメモリ領域が既に確保されている場合には、先に説明したステップ１１２〜ステップ１１６をスキップしてステップ１１８へ移行し、既に確保されたメモリ領域のアドレスを画像処理モジュール３８に書込領域のアドレスとして通知し、上記メモリ領域への画像データの書き込みを行わせる。
【００７１】
前段の画像処理モジュール３８による書込領域への画像データの書き込みが完了するとステップ１２４へ移行し、検出フラグが０か否か判定する。検出フラグは、書込領域に書き込まれた画像データに対して圧縮／非圧縮の検出を行うか否かを表すフラグであり、前述のように検出フラグには初期設定時に１が設定されるので、このときは判定が否定されてステップ１２６へ移行し、入力回数が０か否か判定する。入力回数はバッファモジュール４０が生成されてから現在迄に画像データが入力された回数を表す情報であり、前述のように入力回数には初期設定時に０が設定されるので、このときは判定が肯定されてステップ１２４へ移行し、前段の画像処理モジュール３８によって書込領域に書き込まれた画像データのサイズを検知し、検知したサイズを初回サイズとしてワークメモリ等に記憶させる。
【００７２】
次のステップ１２６では、入力回数を１だけインクリメントした後にステップ１４０へ移行し、書込用バッファ領域に書き込まれている画像データに属性情報を付加した後に、保管用バッファ領域にそのまま書き込む。なお、上記の属性情報としては、バッファモジュール４０で圧縮を行った画像データか否かを表す圧縮フラグや画像データのサイズ等の情報を用いることができ、ステップ１４０では、圧縮フラグとして０(非圧縮)を設定すると共に、画像データのサイズとして先に検知したサイズを設定した属性情報を画像データに付加することができる。
【００７３】
そしてステップ１４４では、自モジュールの後段の個々の画像処理モジュール３８に対応する有効データポインタのうち有効データの末尾位置を表すポインタを、該ポインタが指し示す有効データの末尾位置が単位書込データ量分だけ後へ移動するように更新する（図４(Ｃ)も参照）と共に、先に書込用バッファ領域として確保したメモリ領域をリソース管理部４６Ｂによって解放させ、データ書込処理を一旦終了する。なお、書込用バッファ領域はバッファモジュール４０の初期化時に確保し、バッファモジュール４０の消去時に解放するように構成してもよい。
【００７４】
上記のデータ書込処理は前段の画像処理モジュール３８から書込要求が入力される毎に実行されるが、前段の画像処理モジュール３８から最初に書込要求が入力された以降は入力回数が１以上の値となるので、ステップ１２２の判定が否定されてステップ１２８へ移行し、入力回数を１だけインクリメントする。また、ステップ１３０では前段の画像処理モジュール３８によって書込領域に書き込まれた画像データのサイズを検知し、検知したサイズがワークメモリ等に記憶されている初回サイズと一致しているか否か判定する。判定が肯定された場合はステップ１３２へ移行し、入力回数が所定値Ｎに達したか否か判定する。判定が否定された場合はステップ１４０へ移行し、前述のように書込用バッファ領域に書き込まれている画像データに、値０(非圧縮)が設定された圧縮フラグ及び画像データのサイズを含む属性情報を付加した後に、保管用バッファ領域にそのまま書き込む処理を行う。なお、空き領域有りの単位バッファ領域における空き領域のサイズが単位書込データ量よりも小さい場合、書込用バッファ領域に書き込まれた画像データは、図４(Ｃ)に示すように、保管用の複数の単位バッファ領域へ分けて書き込まれることになる。
【００７５】
前段の画像処理モジュール３８から書込要求がＮ＋１回入力される間、書込領域に書き込まれた画像データのサイズが初回サイズと毎回一致していた場合、前段の画像処理モジュール３８によって書込領域に書き込まれた画像データは非圧縮の画像データであると判断できる。このため、上記場合にはＮ＋１回目の書込要求が入力された時点でステップ１３２の判定が肯定され、ステップ１３４で圧縮フラグに１を設定する。なお、圧縮フラグは保管用の単位バッファ領域に書き込む画像データに対して圧縮処理を行うか否かを表すフラグであり、圧縮フラグ＝１は圧縮処理を行うことを意味し、圧縮フラグ＝０は圧縮処理を行わないことを意味している。また、ステップ１３６では検出フラグに０を設定し、次のステップ１３８では圧縮フラグが１か否か判定する。
【００７６】
判定が肯定された場合はステップ１４２へ移行し、書込用バッファ領域に書き込まれている画像データを所定の圧縮方式によって圧縮し、圧縮後の画像データに、圧縮フラグとして１(圧縮)を設定すると共に画像データのサイズとして先に検知したサイズ（圧縮前のサイズ）を設定した属性情報を付加し、属性情報を付加した圧縮画像データを保管用バッファ領域に書き込む。なお、ステップ１４２において、画像データの圧縮に際して適用した圧縮方式を表す情報も属性情報として付加するようにしてもよい。圧縮フラグに１が一旦設定されると、バッファモジュール４０が消去される迄の間、圧縮フラグは１のまま維持されるので、以降に前段の画像処理モジュール３８から出力された（書込領域に書き込まれた）画像データは全て圧縮された後に保管用バッファ領域に書き込まれることになる。また、検出フラグに０が設定されることで、以降に実行されるデータ書込処理ではステップ１２２〜ステップ１３６の処理がスキップされる。
【００７７】
このように、本実施形態に係るデータ書込処理では、前段の画像処理モジュール３８から出力される（書込領域に書き込まれる）画像データが非圧縮の画像データであった場合には、当該画像データに対して圧縮処理を行った後に保管用バッファ領域に書き込むので、保管用バッファ領域として確保すべきメモリ領域を節減できると共に、保管用バッファ領域への画像データの書き込み及び保管用バッファ領域からの画像データの読み出しに要する時間も短縮することができる。また、保管用バッファ領域に書き込む画像データの圧縮（及び保管用バッファ領域から読み出した画像データの伸長）を行うことで、これらの処理を行うＣＰＵ１２に負荷が加わることになるが、バッファ領域としてのメモリ等に対するアクセス速度に比してＣＰＵ１２の動作速度は高速であり、特に大サイズの画像データを扱う場合には、バッファ領域としてのメモリ等に対するアクセス速度が十分でないことが画像処理部５０における処理速度のボトルネックとなるので、上記のように画像データの圧縮（及び伸長）を行うことに伴って画像処理部５０における処理速度の低下が生ずることも回避できる。
【００７８】
また、前段の画像処理モジュール３８から書込要求がＮ＋１回入力される迄の間に、初回サイズと異なるサイズの画像データが書込領域に書き込まれた場合には、前段の画像処理モジュール３８によって書込領域に書き込まれた画像データは圧縮された画像データであると判断できる。この場合はステップ１３０の判定が否定されてステップ１３６へ移行し、検出フラグに０を設定してステップ１３８へ移行する（圧縮フラグに１を設定するステップ１３４がスキップされる）ので、ステップ１３８の判定が否定され、ステップ１４０において、書込用バッファ領域に書き込まれている画像データに対し、値０(非圧縮)が設定された圧縮フラグ及び画像データのサイズを含む属性情報を付加した後に、保管用バッファ領域にそのまま書き込む処理が行われる。従って、前段の画像処理モジュール３８から出力される画像データが既に圧縮された画像データであった場合には、当該画像データはそのまま保管用バッファ領域に書き込まれることになる。
【００７９】
続いて、後段の画像処理モジュール３８から読出要求がバッファモジュール４０に入力された場合（及び、後述するタイマがタイムアウトした場合）に、バッファモジュール４０の読出制御部４０Ｄによって実行されるデータ読出処理について、図５を参照して説明する。なお、以下で説明するデータ読出処理についても、関数やメソッドの呼び出しで処理が始まるようにしてもよい。なお、このデータ読出処理を行う読出制御部４０Ｄは本発明に係る読出手段（詳しくは請求項６に記載の読出手段）に対応している。
【００８０】
データ読出処理では、まずステップ１７０において、今回のデータ読出処理の起動要因が、後段の画像処理モジュールから読出要求を受信したことによる起動か否か判定する。判定が否定された場合はステップ１７４へ移行するが、上記判定が肯定された場合はステップ１７２へ移行し、後段の画像処理モジュールから今回受信した読出要求情報を読出用の待ち行列の末尾に登録する。ステップ１７４では、自モジュールのバッファ４０Ａが他のプロセス、スレッド又はオブジェクトによって使用中か否か判定する。バッファ４０Ａは書込制御部４０Ｃからもアクセスされるので、当該判定が肯定された場合はステップ２０８へ移行し、読出用の待ち行列に読出要求情報が登録されているか否か判定する。判定が否定された場合はデータ読出処理を終了するが、判定が肯定された場合はステップ２１０でタイマをスタートさせてデータ読出処理を一旦終了する。タイマをスタートさせた場合には、タイマがタイムアウトするとデータ読出処理が再度起動され、読出用の待ち行列に登録されている未処理の読出要求（情報）が再度取り出され、当該読出要求に応じた処理が行われる。
【００８１】
一方、ステップ１７４の判定が否定された場合にはステップ１７６へ移行し、読出用の待ち行列から先頭に登録されている読出要求情報を取り出す。次のステップ１７８では、読出用の待ち行列から取り出した読出要求情報に含まれる要求元識別情報に基づいて読出要求元の画像処理モジュール３８を認識し、読出要求元の画像処理モジュール３８によって設定された単位読出データ量を認識すると共に、読出要求元の画像処理モジュール３８に対応する有効データポインタに基づいて、読出要求元の画像処理モジュール３８に対応する有効データのバッファ４０Ａ上での先頭位置及び末尾位置を認識する。次のステップ１８０では、ステップ１７８で認識した有効データの先頭位置及び末尾位置に基づいて、読出要求元の画像処理モジュール３８に対応する有効データ（読出要求元の画像処理モジュール３８が読出可能な画像データ）が単位読出データ量以上有るか否か判定する。
【００８２】
なお、上記の有効データが書込制御部４０Ｃによって圧縮された画像データであった場合、読出制御部４０Ｄは、後述のように当該画像データに対して伸長処理を行った後に読出要求元の画像処理モジュール３８へ出力するので、上記のステップ１８０では、ステップ１７８で認識した有効データに付加されている属性情報のうち圧縮フラグを参照することで、有効データが書込制御部４０Ｃによって圧縮された画像データか否かを判定し、書込制御部４０Ｃによって圧縮された画像データであった場合は、属性情報のうちの画像データのサイズを参照することで伸長処理後の有効データのサイズを認識し、認識したサイズが単位読出データ量以上か否かを判定する。
【００８３】
ステップ１８０の判定が否定された場合はステップ１８２へ移行し、バッファ４０Ａに記憶されており読出要求元の画像処理モジュール３８が読出可能な有効データの末尾が処理対象の画像データの末尾か否か判定する。読出要求元の画像処理モジュール３８に対応する有効データがバッファ４０Ａに単位読出データ量以上記憶されているか、又は、バッファ４０Ａに記憶されている読出要求元の画像処理モジュール３８に対応する有効データが単位読出データ量未満であるものの、当該有効データの末尾が処理対象の画像データの末尾であった場合には、ステップ１８０又はステップ１８２の判定が肯定されてステップ１８４へ移行する。ステップ１８４では、確保すべきメモリ領域のサイズとして読出要求元の画像処理モジュール３８に対応する単位読出データ量をリソース管理部４６Ｂに通知すると共に、読出に用いるメモリ領域（読出用バッファ領域：図６(Ｂ)も参照）の確保をリソース管理部４６Ｂに要求する。
【００８４】
読出用バッファ領域を確保すると、次のステップ１８６では、読出対象の有効データに付加されている属性情報（の圧縮フラグ）を参照することで、読出対象の有効データが書込制御部４０Ｃによって圧縮された画像データであるか否か判定する。読出対象の有効データに付加されている属性情報の圧縮フラグに１が設定されていた場合には、上記判定が肯定されてステップ１８８へ移行し、読出対象の有効データを圧縮前のサイズが単位読出データ量に相当するサイズだけバッファ４０Ａから読み出し、読み出した有効データから属性情報を除去し、属性情報を除去した有効データに対して伸長処理を行うことで単位読出データ量分の非圧縮の画像データに戻した後に読出用バッファ領域に書き込む。また、読出対象の有効データに付加されている属性情報の圧縮フラグに０が設定されていた場合には、上記判定が否定されてステップ１９０へ移行し、読出対象の有効データをバッファ４０Ａから単位読出データ量分だけ読み出して属性情報を除去し、属性情報を除去した有効データをそのまま読出用バッファ領域に書き込む。
【００８５】
次のステップ１９２では、読出用バッファ領域の先頭アドレスを読出領域の先頭アドレスとして読出要求元の画像処理モジュール３８へ通知すると共に、通知した先頭アドレスから画像データを順に読み出すよう要請する。これにより、読出要求元の画像処理モジュール３８は、先頭アドレスが通知された読出領域（読出用バッファ領域）からの画像データの読み出しを行う。なお、読出対象の有効データが処理対象の画像データの末尾に相当するデータであった場合には、画像データの読出要求に際し、読出対象の画像データのサイズと共に、処理対象の画像データの末尾であることも読出要求元の画像処理モジュール３８に通知する。また、自モジュールがアプリケーション３２によって生成されたバッファモジュール４０である場合は、バッファ４０Ａとして用いているメモリ領域（単位バッファ領域の集合体）は連続領域であるので、読出用バッファ領域の確保、読出対象の画像データの読出用バッファ領域への書き込みを省略し、後段の画像処理モジュール３８が単位バッファ領域から直接画像データを読み出すようにしてもよい。
【００８６】
このように、読出対象の画像データが書込制御部４０Ｃによって圧縮された画像データであった場合には、当該画像データに対して伸長処理を行い読出用バッファ領域に書き込んだ後に、読出要求元の画像処理モジュール３８によって読み出させるので、バッファモジュール４０の後段の画像処理モジュール３８は、バッファモジュール４０の前段の画像処理モジュール３８からの出力画像データと同一の画像データを受け取る（出力画像データが圧縮された画像データであればバッファモジュール４０から圧縮された画像データを受け取り、出力画像データが非圧縮の画像データであればバッファモジュール４０から非圧縮の画像データを受け取る）ことになる。従って、個々の画像処理モジュール３８が、前段のバッファモジュール４０が画像データの圧縮を行ったか否かに応じて処理を切り替える必要がなくなるので、先にも説明したように、前段の画像処理モジュール３８から非圧縮の画像データが受け渡された場合に画像データの圧縮／伸長を行うようにバッファモジュール４０を構成したことに伴って、画像処理モジュール３８の構成が複雑化することも回避することができる。
【００８７】
また、例として図６(Ａ)に示すように、有効データの先頭部分の画像データを記憶している単位バッファ領域に記憶されている有効データのデータ量が単位読出データ量未満であり、読出対象の有効データが複数の単位バッファ領域に跨っている場合には、今回の読出対象の有効データが実メモリ（メモリ１４）上で連続する領域に記憶されているとは限らないが、上記のデータ読出処理では、図６(Ｂ),(Ｃ)に示すように、このような場合にも読出対象の画像データを読出用バッファ領域に一旦書き込んだ後に該読出用バッファ領域から画像データを読み出させるので、読出対象の画像データが複数の単位バッファ領域に跨って記憶されているか否かに拘わらず、読出要求元の画像処理モジュール３８への読出領域の通知は、上記のようにその先頭アドレスを通知するのみで済み、画像処理モジュール３８とのインタフェースが簡単になる。
【００８８】
次のステップ１９４では、読出要求元の画像処理モジュール３８による読出領域からの画像データの読み出しが完了したか否か判定し、判定が肯定される迄ステップ１９４を繰り返す。読出要求元の画像処理モジュール３８から読出完了が通知されると、ステップ１９４の判定が肯定されてステップ１９６へ移行し、読出用バッファ領域として確保したメモリ領域の先頭アドレス及びサイズをリソース管理部４６Ｂへ通知して、当該メモリ領域をリソース管理部４６Ｂによって解放させる。この読出用バッファ領域についても、バッファモジュール４０の初期化時に確保しておき、バッファモジュール４０が消去される時に解放するよう構成してもよい。またステップ１９８では、読出要求元の画像処理モジュール３８に対応する有効データポインタのうち有効データの先頭位置を表すポインタを、該ポインタが指し示す有効データの先頭位置を単位読出データ量分だけ後へ移動させることで更新する（図６(Ｃ)も参照）。
【００８９】
ステップ２００では、後段の個々の画像処理モジュール３８に対応する有効データポインタを各々参照し、ステップ１９８のポインタ更新により、バッファ４０Ａを構成する単位バッファ領域の中に、記憶している画像データの後段の各画像処理モジュール３８による読み出しが全て完了した単位バッファ領域、すなわち有効データを記憶していない単位バッファ領域が出現したか否か判定する。判定が否定された場合はステップ２０８へ移行し、前述のステップ２０８，２１０を経てデータ読出処理を終了するが、判定が肯定された場合はステップ２０２へ移行し、有効データを記憶していない単位バッファ領域をリソース管理部４６Ｂによって解放させた後にステップ２０８へ移行し、ステップ２０８，２１０を経てデータ読出処理を終了する。
【００９０】
一方、バッファ４０Ａに記憶されており読出要求元の画像処理モジュール３８が読出可能な有効データのデータ量が単位読出データ量未満であり、かつ読出可能な有効データの末尾が処理対象の画像データの末尾でない場合（図８(Ｂ)の(4)で読出可能な有効データ無が検知された場合）には、ステップ１８０，１８２の判定が各々否定されてステップ２０４へ移行し、新たな画像データを要求するデータ要求をワークフロー管理部４６Ａへ出力する（図８(Ｂ)の(5)も参照）。この場合、ワークフロー管理部４６Ａにより、自モジュールの前段の画像処理モジュール３８に処理要求が入力されることになる。またステップ２０６では、読出用の待ち行列から取り出した読出要求情報を元の待ち行列（の先頭又は末尾）に再度登録し、ステップ２０８，２１０を経てデータ読出処理を終了する。これにより、読出可能な有効データのデータ量が単位読出データ量以上になるか、読出可能な有効データの末尾が処理対象の画像データの末尾であることが検知される迄（ステップ１８０又はステップ１８２の判定が肯定される迄）の間、対応する読出要求情報は読出用の待ち行列に保存されると共に定期的に取り出されて要求された処理の実行が繰り返し試行されることになる。
【００９１】
詳細は後述するが、ワークフロー管理部４６Ａはバッファモジュール４０からデータ要求が入力されると、データ要求元のバッファモジュール４０の前段の画像処理モジュール３８に処理要求を入力する（図８(Ｂ)の(6)も参照）。この処理要求の入力をトリガとして前段の画像処理モジュール３８の制御部３８Ｂで行われる処理により、前段の画像処理モジュール３８がバッファモジュール４０へ画像データを書込可能な状態になると、前段の画像処理モジュール３８から書込要求が入力されることで前述したデータ書込処理（図３）が行われ、前段の画像処理モジュール３８からバッファモジュール４０のバッファ４０Ａに画像データが書き込まれる（図８(Ｂ)の(7),(8)も参照）。これにより、後段の画像処理モジュール３８によるバッファ４０Ａからの画像データの読出が行われることになる（図８(Ｂ)の(9)も参照）。
【００９２】
上述したデータ書込処理及びデータ読出処理では、一方が自モジュールのバッファ４０Ａにアクセスしている間、他方がバッファ４０Ａへのアクセスを停止する排他制御が行われる。これにより、コンピュータ１０のＣＰＵ１２が画像処理部５０を構成する個々のモジュールに対応するプロセス又はスレッドを並列に実行しても、単一のバッファモジュール４０に複数の要求が同時又は略同時に入力されることによる不都合の発生を回避できるので、コンピュータ１０のＣＰＵ１２が個々のモジュールに対応するプロセス又はスレッドを並列に実行することができる。もちろん、バッファモジュールを通常のプログラムまたはオブジェクトとして実現しても良い。
【００９３】
続いて、画像処理部５０を構成する個々の画像処理モジュール３８に対してワークフロー管理部４６Ａから処理要求が入力される毎に、個々の画像処理モジュール３８の制御部３８Ｂによって各々行われる画像処理モジュール制御処理（図７）を説明する。画像処理モジュール制御処理では、まずステップ２２０において、自モジュールの前段にモジュール（バッファモジュール４０や画像データ供給部２２、画像処理モジュール３８等）が存在している場合に、当該前段のモジュールに対してデータ（画像データ又は解析等の画像処理の処理結果）を要求する。次のステップ２２２では前段のモジュールからデータが取得可能であるかを判定し、ステップ２２２の判定が否定された場合はステップ２２４で全体処理終了が通知されたか否かを判定する。ステップ２２４の判定が否定された場合はステップ２２２に戻り、前段のモジュールからデータを取得可能となる迄ステップ２２２，２２４を繰り返す。ステップ２２２の判定が肯定された場合には、ステップ２２６で前段のモジュールからデータを取得するデータ取得処理を行う。
【００９４】
ここで、自モジュールの前段のモジュールがバッファモジュール４０である場合には、先のステップ２２０でデータを要求すると（読出要求）、読出可能な有効データがバッファモジュール４０のバッファ４０Ａに単位読出データ量以上記憶されているか、読出可能な有効データの末尾が処理対象の画像データの末尾に一致している状態であれば直ちに、当該状態でなければ、当該バッファモジュール４０の前段の画像処理モジュール３８が当該バッファモジュール４０のバッファ４０Ａに画像データを書き込んだことに伴って前記状態へ変化した後に、バッファモジュール４０から読出領域の先頭アドレスが通知されて画像データの読出が要請される（図５のステップ１９２も参照）。これにより、ステップ２２２の判定が肯定されてステップ２２６へ移行し、前段のバッファモジュール４０より先頭アドレスが通知された読出領域から単位読出データ量（又はそれ未満のデータ量）の画像データを読み出すデータ取得処理を行う（図８(Ａ)の(3)も参照）。
【００９５】
また、自モジュールの前段のモジュールが画像データ供給部２２であれば、先のステップ２２０でデータ要求を出力すると画像データを取得可能な状態であることが前段の画像データ供給部２２から直ちに通知されることで、ステップ２２２の判定が肯定されてステップ２２６へ移行し、前段の画像データ供給部２２から単位読出データ量の画像データを取得する画像データ取得処理を行う。また、自モジュールの前段のモジュールが画像処理モジュール３８であれば、先のステップ２２０でデータ要求（処理要求）を出力すると、前段の画像処理モジュール３８が画像処理を実行可能な状態であれば書込要求が入力されることでデータ（画像処理結果）を取得可能な状態であることが通知されるので、ステップ２２２の判定が肯定されてステップ２２６へ移行し、前段の画像処理モジュール３８によってデータを書き込ませるバッファ領域のアドレスを通知して書込を要請することで、前段の画像処理モジュール３８から出力されるデータを前記バッファに書き込ませるデータ取得処理を行う。
【００９６】
次のステップ２２８では、自モジュールの前段に複数のモジュールが連結されているか否か判定する。判定が否定された場合には何ら処理を行うことなくステップ２３２へ移行するが、判定が肯定された場合はステップ２３０へ移行し、前段に連結されている全てのモジュールからデータを取得したか否か判定する。ステップ２３０の判定が否定された場合はステップ２２０に戻り、ステップ２３０の判定が肯定される迄ステップ２２０〜ステップ２３０を繰り返す。前段のモジュールから取得すべきデータが全て揃うと、ステップ２２８の判定が否定されるかステップ２３０の判定が肯定されてステップ２３２へ移行する。
【００９７】
次に、ステップ２３２で自モジュールの後段のモジュールに対してデータ出力用の領域を要求し、ステップ２３２でデータ出力領域が取得できる迄（データ出力領域の先頭アドレスが通知される迄）繰り返し判定を行う。なお、後段のモジュールがバッファモジュール４０であれば、上記のデータ出力用領域の要求は当該バッファモジュール４０に対して書込要求を出力することによって成される。データ出力領域（後段のモジュールがバッファモジュール４０であれば当該バッファモジュール４０から先頭アドレスが通知された書込領域）が取得できたら（図８(Ａ)の(4)も参照）、次のステップ２３６において、先のデータ取得処理で取得したデータと後段のモジュールから取得したデータ出力領域（の先頭アドレス）を画像処理エンジン３８Ａに入力し、入力したデータに対して所定の画像処理を行わせる（図８(Ａ)の(5)も参照）と共に、処理後のデータをデータ出力領域に書き込ませる（図８(Ａ)の(6)も参照）。画像処理エンジン３８Ａへの単位読出データ量のデータの入力が完了し、画像処理エンジン３８Ａから出力されたデータがデータ出力領域に全て書き込まれると、次のステップ２３８で出力が完了したことを後段のモジュールに通知する。
【００９８】
上記のステップ２２０〜ステップ２３８により画像処理モジュール３８における単位処理データ量のデータに対する処理（単位処理）が完了するが、ワークフロー管理部４６Ａから画像処理モジュール３８に入力される処理要求では、ワークフロー管理部４６Ａによって単位処理の実行回数が指定されることがある。このためステップ２４０では、単位処理の実行回数が、入力された処理要求によって指示された実行回数に達したか否か判定する。指示された単位処理の実行回数が１回の場合、この判定は無条件に肯定されるが、指示された単位処理の実行回数が２回以上の場合はステップ２２０に戻り、ステップ２４０の判定が肯定される迄ステップ２２０〜ステップ２４０を繰り返す。ステップ２４０の判定が肯定されるとステップ２４２へ移行し、ワークフロー管理部４６Ａへ処理完了通知を出力することで、入力された処理要求に対応する処理が完了したことをワークフロー管理部４６Ａへ通知し、画像処理モジュール制御処理を終了する。
【００９９】
また、ワークフロー管理部４６Ａから処理要求が入力される毎に上述した処理が繰り返されることで処理対象の画像データを末尾まで処理すると、前段のモジュールから処理対象の画像データの終了が通知されることで、ステップ２２４の判定が肯定されてステップ２４４へ移行し、処理対象の画像データ（なお、処理対象の画像データは１頁分の画像データであることが多いが、複数頁分の画像データであってもよい）に対する処理が終了したことを意味する全体処理終了通知をワークフロー管理部４６Ａ及び後段のモジュールへ各々出力する。また、次のステップ２４６では自モジュール消去処理（後述）を行い、画像処理モジュール制御処理を終了する。
【０１００】
一方、ワークフロー管理部４６Ａは、アプリケーション３２によって起動されると、図９(Ａ)に示すブロック単位制御処理１を行う。先にも述べたように、ワークフロー管理部４６Ａによる画像処理部５０の個々の画像処理モジュール３８への処理要求の入力では、単位処理の実行回数を指定可能とされているが、ブロック単位制御処理１のステップ５００では、１回の処理要求で指定する単位処理の実行回数を個々の画像処理モジュール３８毎に決定する。この処理要求１回当りの単位処理の実行回数は、例えば処理対象の画像データ全体を処理する間の個々の画像処理モジュール３８への処理要求の入力回数が平均化されるように定めることができるが、他の基準に従って定めてもよい。そして次のステップ５０２において、画像処理部５０のうち最後段の画像処理モジュール３８に処理要求を入力し（図１０の(1)も参照）、ブロック単位制御処理１を終了する。
【０１０１】
ここで、図１０に示す画像処理部５０において、ワークフロー管理部４６Ａから最後段の画像処理モジュール３８4に処理要求が入力されると、画像処理モジュール３８4の制御部３８Ｂは前段のバッファモジュール４０3に読出要求を入力する（図１０の(2)参照）。このとき、バッファモジュール４０3のバッファ４０Ａには画像処理モジュール３８4が読出可能な有効データ（画像データ）が記憶されていないので、バッファモジュール４０3のバッファ制御部４０Ｂはワークフロー管理部４６Ａにデータ要求を入力する（図１０の(3)参照）。
【０１０２】
ワークフロー管理部４６Ａは、画像処理の実行形態がブロック単位処理である場合、バッファモジュール４０からデータ要求が入力される毎に、図９(Ｂ)に示すブロック単位制御処理２を行う。このブロック単位制御処理２では、ステップ５０４において、データ要求入力元のバッファモジュール４０（ここではバッファモジュール４０3）の前段の画像処理モジュール３８（ここでは画像処理モジュール３８3）を認識し、認識した前段の画像処理モジュール３８に処理要求を入力（図１０の(4)参照）して処理を終了する。
【０１０３】
画像処理モジュール３８3の制御部３８Ｂは、処理要求が入力されると前段のバッファモジュール４０2に読出要求を入力し（図１０の(5)参照）、バッファモジュール４０2のバッファ４０Ａにも読出可能な画像データが記憶されていないので、バッファモジュール４０2のバッファ制御部４０Ｂはワークフロー管理部４６Ａにデータ要求を入力する（図１０の(6)参照）。ワークフロー管理部４６Ａは、バッファモジュール４０2からデータ要求が入力された場合も、前述のブロック単位制御処理２を再度行うことで、その前段の画像処理モジュール３８2に処理要求を入力し（図１０の(7)参照）、画像処理モジュール３８3の制御部３８Ｂは前段のバッファモジュール４０1に読出要求を入力する（図１０の(8)参照）。また、バッファモジュール４０1のバッファ４０Ａにも読出可能な画像データが記憶されていないので、バッファモジュール４０1のバッファ制御部４０Ｂもワークフロー管理部４６Ａにデータ要求を入力し（図１０の(9)参照）。ワークフロー管理部４６Ａは、バッファモジュール４０1からデータ要求が入力された場合も、前述のブロック単位制御処理２を再度行うことで、その前段の画像処理モジュール３８1に処理要求を入力する（図１０の(10)参照）。
【０１０４】
ここで、画像処理モジュール３８1の前段のモジュールは画像データ供給部２２であるので、画像処理モジュール３８1の制御部３８Ｂは、画像データ供給部２２にデータ要求を入力することで画像データ供給部２２から単位読出データ量の画像データを取得し（図１０の(11)参照）、取得した画像データに対して画像処理エンジン３８Ａが画像処理を行うことで得られた画像データを、後段のバッファモジュール４０1のバッファ４０Ａに書き込む（図１０の(12)参照）。なお、画像処理モジュール３８1の制御部３８Ｂは後段のバッファモジュール４０1のバッファ４０Ａへの画像データの書き込みを完了すると、ワークフロー管理部４６Ａへ処理完了通知を入力する。
【０１０５】
ワークフロー管理部４６Ａは、画像処理の実行形態がブロック単位処理である場合、画像処理モジュール３８から処理完了通知が入力される毎に、図９(Ｃ)に示すブロック単位制御処理３を行う。このブロック単位制御処理３では、ステップ５０６において、処理完了通知元が画像処理部５０の最後段の画像処理モジュール３８か否か判定する。この場合は判定が否定され、何ら処理を行うことなく処理を終了する（画像処理モジュール３８2，３８3から処理完了通知が入力された場合についても同様）。
【０１０６】
また、バッファモジュール４０1のバッファ制御部４０Ｂは、後段の画像処理モジュール３８2が読出可能な単位読出データ量以上の有効データが書き込まれると画像処理モジュール３８2に対して読出を要請し、これに伴い画像処理モジュール３８2の制御部３８Ｂは、バッファモジュール４０1のバッファ４０Ａから単位読出データ量の画像データを読み出し（図１０の(13)参照）、取得した画像データに対して画像処理エンジン３８Ａが画像処理を行うことで得られた画像データを、後段のバッファモジュール４０2のバッファ４０Ａに書き込む（図１０の(14)参照）。バッファモジュール４０2のバッファ制御部４０Ｂは、後段の画像処理モジュール３８3が読出可能な単位読出データ量以上の有効データが書き込まれると画像処理モジュール３８3へ読出を要請し、画像処理モジュール３８3の制御部３８Ｂは、バッファモジュール４０2のバッファ４０Ａから単位読出データ量の画像データを読み出し（図１０の(15)参照）、取得した画像データに対して画像処理エンジン３８Ａが画像処理を行うことで得られた画像データを、後段のバッファモジュール４０3のバッファ４０Ａに書き込む（図１０の(16)参照）。
【０１０７】
更に、バッファモジュール４０3のバッファ制御部４０Ｂは、後段の画像処理モジュール３８4が読出可能な単位読出データ量以上の有効データが書き込まれると画像処理モジュール３８4に対して読出を要請し、これに伴い画像処理モジュール３８4の制御部３８Ｂは、バッファモジュール４０3のバッファ４０Ａから単位読出データ量の画像データを読み出し（図１０の(17)参照）、取得した画像データに対して画像処理エンジン３８Ａが画像処理を行うことで得られた画像データを、後段のモジュールである画像出力部２４へ出力する（図１０の(18)参照）。また、画像処理モジュール３８4の制御部３８Ｂは後段の画像出力部２４への画像データの書き込みを完了すると、ワークフロー管理部４６Ａへ処理完了通知を入力する（図１０の(19)参照）が、この場合は前述のブロック単位制御処理３のステップ５０６の判定が肯定されてステップ５０８へ移行し、最後段の画像処理モジュール３８である画像処理モジュール３８4に処理要求を再度入力した後に処理を終了する。
【０１０８】
この最後段の画像処理モジュール３８4への処理要求の再入力により、上述した処理シーケンスが再度繰り返され、処理対象の画像データに対し、ブロック単位の実行形態での画像処理が順次行われることになる。画像データ供給部２２から供給される画像データが処理対象の画像データの末尾に達すると、個々の画像処理モジュール３８からワークフロー管理部４６Ａへの全体処理終了通知の入力が、前段側の画像処理モジュール３８から順次行われる。
【０１０９】
ワークフロー管理部４６Ａは、画像処理の実行形態がブロック単位処理である場合、画像処理モジュール３８から全体処理終了通知が入力される毎に、図９(Ｄ)に示すブロック単位制御処理４を行う。このブロック単位制御処理４では、ステップ５１０において、全体処理終了通知入力元の画像処理モジュール３８が最後段の画像処理モジュール３８か否か判定する。判定が否定された場合は何ら処理を行うことなく処理を終了するが、処理対象の画像データに対して必要な画像処理が行われた画像データが画像出力部２４へ全て出力されることで、最後段の画像処理モジュール３８から全体処理終了通知が入力された場合には、ステップ５１０の判定が肯定されてステップ５１２へ移行し、アプリケーション３２に対して画像処理の完了を通知し、ブロック単位制御処理を終了する。そして、画像処理の完了が通知されたアプリケーション３２は、ユーザに対して画像処理の完了を通知する。
【０１１０】
このように、ブロック単位処理では、最後段の画像処理モジュール３８に入力された処理要求がより前段の画像処理モジュール３８へ遡り、最前段の画像処理モジュール３８に到達すると、最前段の画像処理モジュール３８で画像処理が行われて後段のバッファモジュール４０にデータが書き込まれ、それでデータが足りるようならば処理が後段のモジュールへ進んで行くという流れで一連の画像処理が行われる。
【０１１１】
なお、ブロック単位処理における処理シーケンスは上記に限られるものではなく、バッファモジュール４０からデータ要求が入力される毎に、データ要求入力元のバッファモジュール４０に処理要求を入力することに代えて、まずブロック単位制御処理１で全ての画像処理モジュール３８に処理要求を各々入力し、特定の画像処理モジュールから全体処理完了通知が入力される迄の間、特定の画像処理モジュール３８から処理完了通知が入力される毎に、処理完了通知入力元の特定の画像処理モジュール３８に処理要求を再入力する処理を、全ての画像処理モジュールに対して各々行うようにしてもよい。
【０１１２】
また、上記では最後段の画像処理モジュール３８への処理要求の入力はワークフロー管理部４６Ａが行うものとして説明したが、本発明はこれに限定されるものではなく、パイプラインの最後段又は有向非循環グラフの複数の終点に位置するモジュールをワークフロー管理部４６Ａが保持して処理要求を行っても、またはアプリケーション３２が保持して処理要求を行っても良い。或いは、前述した図２(Ｂ)の例のように、モジュール生成部４４の内部で、スキュー角検知処理を行う画像処理モジュールと、画像回転処理を行う画像処理モジュールとを組み合わせて、スキュー補正処理モジュールとするような場合には、画像回転処理モジュールの生成時に処理パラメータとしてスキュー角情報が必要なので、スキュー補正モジュール生成部の内部で、スキュー角検知処理モジュールに処理要求を繰り返し行って画像全体を処理し、その結果得られるスキュー角情報を画像回転処理モジュールに処理パラメータとして与えるといった方式も存在する。
【０１１３】
続いて、処理対象の画像データに対する画像処理を完了した後に行われる画像処理部５０の消去について説明する。個々の画像処理モジュール３８の制御部３８Ｂは、画像処理モジュール制御処理（図７）のステップ２４４で、ワークフロー管理部４６Ａ及び後段のモジュールへ全体処理終了通知を出力した後に、次のステップ２４６で自モジュールを消去する。具体的には、先に確保したメモリ領域をリソース管理部４６Ｂによって解放させると共に、リソース管理部４６Ｂを通じて自モジュールが確保したメモリ以外のリソースが有れば、当該リソースをリソース管理部４６Ｂによって解放させ、自モジュールの前段のモジュール、後段のモジュール及びワークフロー管理部４６Ａに対し、自モジュールを消去する処理を行うことを通知するための消去通知を入力した後に、自モジュールを消去する処理が行われる。なお、自モジュールを消去することは、自モジュールに対応するプロセス、スレッドを終了するか、又はオブジェクトを削除することで実現することができる。
【０１１４】
一方、バッファモジュール４０の書込制御部４０Ｃによって実行されるデータ書込処理（図３）では、自モジュールの前段又は後段の画像処理モジュール３８から消去通知が入力されると、ステップ１０４の判定が肯定されてステップ１４６へ移行し、消去通知入力元のモジュールを記憶した後に、自モジュールの前段及び後段の全てのモジュールから消去通知が入力されたか否か判定する。判定が否定された場合はデータ書込処理を一旦終了する。また、自モジュールの前段及び後段の全てのモジュールから消去通知が入力されると、ステップ１４６の判定が肯定されてステップ１４８へ移行し、ワークフロー管理部４６Ａに対して消去通知を入力することで、自モジュールを消去する処理を行うことを通知する。そして次のステップ１５０で自モジュールを消去する処理を行ってデータ書込処理を終了する。
【０１１５】
なお、上記ではデータ書込処理（図３）において、前段の画像処理モジュール３８から入力された画像データが非圧縮であった場合に一律に圧縮処理を行う態様を説明したが、本発明はこれに限定されるものではなく、前段の画像処理モジュール３８からの画像データの入力時にバッファモジュール４０のバッファ４０Ａとして使用可能なメモリ１４等のシステムリソースの空き容量（或いは、バッファモジュール４０の生成時に所定容量のメモリ１４をバッファ４０Ａとして予め割り当てる場合はバッファ４０Ａの空き容量）を検知し、検知した空き容量が所定値以上であれば、入力された画像データが非圧縮であっても圧縮処理を行うことなくバッファ４０Ａにそのまま書き込むようにしてもよい。この態様では、入力された画像データを記憶するために必要なバッファ４０Ａの容量は増大するものの、データ書込処理（圧縮処理）やデータ読出処理（伸長処理）を行うＣＰＵ１２に加わる負荷を軽減することができる。なお、上記態様は請求項４記載の発明に対応している。
【０１１６】
また、上記ではバッファモジュール４０のバッファ４０Ａとして使用可能なシステムリソースとしてメモリ１４を例に説明したが、本発明はこれに限定されるものではなく、メモリ以外にＨＤＤやフラッシュメモリ、通信回線を介してコンピュータ１０に接続された各種の外部記憶デバイスをバッファ４０として用いることも可能である。また、バッファモジュール４０のバッファ４０Ａとして使用する記憶デバイスを、上記のような複数種の記憶デバイスの中から選択可能に構成した場合、バッファ４０Ａに対するアクセス速度が、バッファ４０Ａとして使用する記憶デバイスの種類や、記憶デバイスとの間の通信回線の回線速度等の環境によって変化することになる。これを考慮すると、前段の画像処理モジュール３８から非圧縮の画像データが入力された際に、当該画像データを書き込むバッファ４０Ａがアクセス速度が第１所定値以上の記憶デバイス（例えばメモリ１４等の高速の記憶デバイス）で構成されている場合や、バッファ４０Ａとの間のデータ転送速度が第２所定値以上となる環境の場合（例えばバッファ４０Ａが高速の記憶デバイスから成り、かつバッファ４０Ａとの間に高速の通信回線が介在している場合）には、入力された非圧縮の画像データを圧縮せずにバッファ４０Ａにそのまま書き込み、画像データを書き込むバッファ４０Ａがアクセス速度が第１所定値未満の記憶デバイス（例えばフラッシュメモリや外部記憶デバイス等の低速の記憶デバイス）で構成されている場合や、バッファ４０Ａとの間のデータ転送速度が第２所定値未満となる環境の場合（例えばバッファ４０Ａが低速の記憶デバイスで構成されているか、バッファ４０Ａとの間に低速の通信回線が介在している場合）には、入力された非圧縮の画像データを圧縮した後にバッファ４０Ａに書き込むようにしてもよい。これにより、バッファ４０Ａに対するアクセス速度が低速である場合に画像処理部５０における処理速度の大幅な低下を引き起こすことを防止できると共に、ＣＰＵ１２に必要以上に負荷が加わることも防止することができる。なお、上記事項は請求項５記載の発明に対応している。
【０１１７】
また、上記では後段の画像処理モジュール３８から読出要求が入力された際の読出対象の画像データが、データ書込処理によって圧縮された画像データであった場合に、当該画像データをバッファ４０Ａから読み出して伸長した後に読出要求元の画像処理モジュール３８へ引き渡すようにしていたが、本発明はこれに限定されるものではない。例えば画像処理モジュール３８の構成としては、前段のモジュールから取得した圧縮画像データに対して伸長処理を行った後に画像処理を行う機能を備えた構成や、前段のモジュールから取得した圧縮画像データに対して伸長処理を行うことなく画像処理を行う機能を備えた構成、すなわち圧縮された画像データを入力可能な構成も考えられるので、後段の画像処理モジュール３８が上記のような構成である場合には、読出対象の画像データがデータ書込処理によって圧縮された画像データであったとしても、当該画像データに対して伸長処理を行うことなく圧縮方式を表す情報を属性情報として付加して後段の画像処理モジュール３８へ受け渡すようにしてもよい。この場合、データ読出処理を行うＣＰＵ１２に加わる負荷を軽減することができる。なお、上記事項は請求項７記載の発明に対応している。
【０１１８】
また、画像データの圧縮方式としては様々な方式が存在しているが、後段の画像処理モジュール３８が圧縮された画像データを入力可能な構成であったとしても、後段の画像処理モジュール３８が取扱可能な画像データの圧縮形式は限られている可能性が高いので、バッファモジュール４０の初期設定時に後段の画像処理モジュール３８が取扱可能な圧縮形式を認識し、データ書込処理において、初期設定時に認識した圧縮形式で画像データの圧縮を行うようにしてもよい。
【０１１９】
更に、上記で説明したデータ書込処理では、検出フラグに０が設定される迄の間（前段の画像処理モジュール３８から画像データがＮ＋１回入力される迄の間）、入力された画像データを圧縮せずにバッファ領域に書き込むので、前段の画像処理モジュール３８から入力される画像データが非圧縮の画像データであったとしても、当該画像データの先頭部分（先頭から単位書込データ量×(Ｎ＋１)に相当するサイズの部分）は圧縮されずにバッファ領域に書き込まれることになるが、本発明はこれに限定されるものではなく、例えば書込用バッファ領域のサイズを、単位書込データ量×(Ｎ＋１)に相当するサイズの画像データを書込可能なサイズとし、入力された画像データの圧縮／非圧縮を判断する迄の間は入力された画像データを書込用バッファ領域に蓄積し、入力された画像データが圧縮されていると判断した場合は書込用バッファ領域に蓄積した画像データをそのまま保管用のバッファ領域に書き込み、入力された画像データが非圧縮であると判断した場合は書込用バッファ領域に蓄積した画像データを全て圧縮した後に保管用のバッファ領域に書き込むようにしてもよい。
【０１２０】
また、上記では、後段の画像処理モジュール３８からバッファモジュール４０に読出要求が入力されたものの、読出要求元の画像処理モジュール３８が読出可能な有効データのデータ量が単位読出データ量未満であり、かつ読出可能な有効データの末尾が処理対象の画像データの末尾でない場合に、読出可能な有効データのデータ量が単位読出データ量以上になるか、読出可能な有効データの末尾が処理対象の画像データの末尾であることが検知される迄、バッファモジュール４０からワークフロー管理部４６Ａへデータ要求が繰り返し入力される例を説明したが、これに限定されるものではなく、上記場合にバッファモジュール４０はワークフロー管理部４６Ａへデータ要求を１回のみ入力すると共に、読出可能な有効データのデータ量が単位読出データ量以上になるか、読出可能な有効データの末尾が処理対象の画像データの末尾であることが検知されるとワークフロー管理部４６Ａへ蓄積完了通知を入力し、ワークフロー管理部４６Ａはバッファモジュール４０からデータ要求が入力されてから蓄積完了通知が入力される迄の間、前記バッファモジュール４０の前段の画像処理モジュール３８へ処理要求を繰り返し入力するようにしてもよい。
【０１２１】
また、上記ではバッファモジュール４０において、後段の画像処理モジュール３８から読出要求が入力され、読出要求元の画像処理モジュール３８が読出可能な有効データが自モジュールのバッファ４０Ａに記憶されていなかった場合に、バッファ制御部４０Ｂがワークフロー管理部４６Ａへデータ要求を入力する態様を例に説明したが、これに限定されるものではなく、上記場合にバッファ制御部４０Ｂが前段の画像処理モジュール３８へデータ要求を直接入力するようにしてもよい。この態様で画像処理の実行形態がブロック単位処理の場合の処理シーケンスを図１１に示す。図１１からも明らかなように、この態様において、ワークフロー管理部４６Ａは画像処理部５０のうち最後段の画像処理モジュール３８についてのみ処理要求を入力すれば済むので、ワークフロー管理部４６Ａにおける処理が簡単になる。
【０１２２】
更に、上記ではブロック単位の画像処理の一例として、まずワークフロー管理部４６Ａが画像処理部５０の最後段の画像処理モジュール３８へ処理要求を入力し、この処理要求がデータ要求又は処理要求として順次前段のモジュールへ伝達される態様を説明したが、これに限定されるものではなく、処理要求又はデータ要求を前段のモジュールから後段のモジュールへ順次伝達させてブロック単位の画像処理を行わせることも可能である。これは、例えばバッファモジュール４０のバッファ制御部４０Ｂを、自モジュールの前段の画像処理モジュール３８によってバッファ４０Ａに画像データが書き込まれる毎に、後段の画像処理モジュール３８が読出可能な有効データのデータ量が単位読出データ量未満で、かつ読出可能な有効データの末尾が処理対象の画像データの末尾でなければワークフロー管理部４６Ａへデータ要求を入力する一方、読出可能な有効データのデータ量が単位読出データ量以上になるか、読出可能な有効データの末尾が処理対象の画像データの末尾であることが検知されるとワークフロー管理部４６Ａへ蓄積完了通知を入力するように構成すると共に、ワークフロー管理部４６Ａを、画像処理部５０の最後段の画像処理モジュール３８へ処理要求を入力した後に、任意のバッファモジュール４０からデータ要求が入力される毎に、データ要求元のバッファモジュール４０の前段の画像処理モジュール３８に処理要求を入力し、任意のバッファモジュール４０から蓄積完了通知が入力される毎に、当該バッファモジュール４０の後段の画像処理モジュール３８に処理要求を入力するように構成することで実現することができる。また、上記において、バッファモジュール４０からのデータ要求を当該バッファモジュール４０の前段の画像処理モジュール３８へ処理要求として直接入力させると共に、バッファモジュール４０からの蓄積完了通知を当該バッファモジュール４０の後段の画像処理モジュール３８へ処理要求として直接入力させるようにしてもよい。
【０１２３】
また、上記ではバッファモジュール４０に対し、前段の画像処理モジュール３８からは単位書込データ量が、後段の画像処理モジュールからは単位読出データ量が事前に設定される態様を説明したが、これに限定されるものではなく、バッファモジュール４０へのデータの書込やバッファモジュール４０からのデータの読出の都度、書込又は読出のデータ量が画像処理モジュール３８から通知されるようにしてもよい。
【０１２４】
また、上記では、バッファモジュール４０に書込要求又は読出要求が入力される毎に、入力された要求を要求情報として待ち行列に登録し、待ち行列から要求情報を１つづつ取り出して処理することで、書込要求入力時にバッファ４０Ａからのデータの読出を実行中であれば、このデータ読出が完了した後に前記書込要求に対応するデータ書込処理を行うと共に、読出要求入力時にバッファ４０Ａへのデータの書込を実行中であれば、このデータ書込が完了した後に前記読出要求に対応するデータ読出処理を行う排他制御を実現していたが、これに限定されるものではなく、例えば単位バッファ領域を単位とする排他制御、すなわち書込要求入力時に、バッファ４０Ａのうち当該書込要求における書込対象の単位バッファ領域に対してデータの読出を実行中であれば、このデータ読出が完了した後に前記書込要求に対応するデータ書込処理を行うと共に、読出要求入力時に、バッファ４０Ａのうち当該読出要求における読出対象の単位バッファ領域に対してデータの書込を実行中であれば、このデータ書込が完了した後に前記読出要求に対応するデータ読出処理を行うようにしてもよい。単位バッファ領域を単位とする排他制御は、例えば個々の単位バッファ領域毎に待ち行列を設けて排他制御を行うことや、排他制御に利用可能な公知のmutex(MUTualEXclusionservice)等の技術を利用する等によって実現することができる。
【０１２５】
更に、画像処理部５０を構成する個々のモジュールの実体はプログラムであるので、画像処理部５０による画像処理は実際にはＣＰＵ１２によって実行されるが、ここで、画像処理部５０を構成する個々の画像処理モジュール３８に相当するプログラムを、ＣＰＵ１２による実行対象のプロセス、スレッド又はオブジェクトとして待ち行列に登録し、当該待ち行列に登録した特定の画像処理モジュールに相当するプログラムがＣＰＵ１２によって前記待ち行列から取り出される毎に、特定の画像処理モジュール３８の前段のモジュールから単位処理データ量の画像データを取得可能か否かを判断し、単位処理データ量の画像データを取得可能と判断した場合にのみ、前記特定の画像処理モジュール３８の前段の前段のモジュールから単位処理データ量の画像データを取得し、取得した単位処理データ量の画像データに対して所定の画像処理（特定の画像処理モジュール３８の画像処理エンジン３８Ａに相当する処理）を行い、所定の画像処理を経た画像データ又は所定の画像処理の処理結果を自モジュールの後段のモジュールへ出力する処理を行った後に、処理対象の画像全体に対する処理が終了していなれば、取り出した特定の画像処理モジュールに相当するプログラムを実行対象のプロセス、スレッド又はオブジェクトとして前記待ち行列に再登録する単位画像処理をＣＰＵ１２によって繰り返させることで、画像処理部５０によって処理対象の画像全体を処理させるようにしてもよい（ラウンドロビン方式）。
【０１２６】
また、上記では画像処理部の個々の画像処理モジュール３８が、画像１面分よりも小さいデータ量を単位として後段へ画像データを引き渡しながら並列に画像処理を行うように動作させることで、画像処理部が全体としてブロック単位処理を行うようにワークフロー管理部４６Ａが制御する態様を説明したが、これに限定されるものではなく、画像処理部の個々の画像処理モジュール３８が、前段の画像処理モジュール３８が画像１面分の画像データに対する画像処理を完了した後に、後段の画像処理モジュール３８が画像１面分の画像データに対する画像処理を行うように動作させることで、画像処理部が全体として面単位処理を行うことも可能なように、ワークフロー管理部４６Ａを構成してもよい。
【図面の簡単な説明】
【０１２７】
【図１】本実施形態に係るコンピュータ（画像処理装置）の概略構成を示すブロック図である。
【図２】画像処理部の構成例を示すブロック図である。
【図３】バッファモジュールの書込制御部によって実行されるデータ書込処理の内容を示すフローチャートである。
【図４】書込対象の画像データが複数の保管用単位バッファ領域に跨る場合を説明する概略図である。
【図５】バッファモジュールの読出制御部によって実行されるデータ読出処理の内容を示すフローチャートである。
【図６】読出対象の画像データが複数の保管用単位バッファ領域に跨っていた場合を説明する概略図である。
【図７】画像処理モジュールの制御部によって実行される画像処理モジュール制御処理の内容を示すフローチャートである。
【図８】(Ａ)は画像処理モジュール、(Ｂ)はバッファモジュールの概略構成及び実行される処理を各々示すブロック図である。
【図９】処理管理部によって実行されるブロック単位制御処理の内容を示すフローチャートである。
【図１０】画像処理部における画像処理の流れを説明する概略図である。
【図１１】バッファモジュールが前段の画像処理モジュールに画像データを直接要求する態様におけるブロック単位処理の流れを説明する概略図である。
【符号の説明】
【０１２８】
１０ コンピュータ
１２ ＣＰＵ
１４ メモリ
２０ 記憶部
２２ 画像データ供給部
２４ 画像出力部
３８ 画像処理モジュール
３８Ａ 画像処理エンジン
３８Ｂ 制御部
４０ バッファモジュール
４０Ａ バッファ
４０Ｂ バッファ制御部
４０Ｃ 書込制御部
４０Ｄ 読出制御部
４６ 処理管理部
４６Ａ ワークフロー管理部
４６Ｂ リソース管理部
５０ 画像処理部
【技術分野】
【０００１】
本発明は画像処理装置及びプログラムに係り、特に、画像処理モジュール及びバッファモジュールがパイプライン形態又は有向非循環グラフ形態で連結されて構築された画像処理部を備えた画像処理装置、及び、コンピュータを前記画像処理装置として機能させるための画像処理プログラムに関する。
【背景技術】
【０００２】
入力された画像データに対して画像処理を行う画像処理装置や、画像を取扱可能なＤＴＰ（デスクトップ・パブリッシング）システム、入力された画像データが表す画像を記録材料に記録するプリントシステム等では、入力された画像データに対して拡大・縮小、回転、アフィン変換、色変換、フィルタ処理、画像合成等の各種の画像処理が行われる。これらの装置やシステムにおいて、入力される画像データの属性や画像データに対する画像処理の内容・手順・パラメータ等が固定されている場合には、専用に設計したハードウエアによって画像処理を行わせる場合もあるが、例えば色空間や１画素当たりのビット数が異なる様々な画像データが入力されたり、画像処理の内容や手順・パラメータ等が様々に変更される場合には、実行する画像処理をより柔軟に変更可能な構成が必要となる。
【０００３】
このような要求を満たすために、例えば特許文献１には、プログラマブルな処理モジュールをパイプライン形態やＤＡＧ(Directed Acyclic Graph：有向非循環グラフ)形態に接続して、所望の画像処理を行うことを可能とする技術が提案されている。特許文献１に記載の技術では、複数のプログラマブル演算処理部の各々における演算処理の内容と、ネットワーク部による各プログラマブル演算処理部の接続形態を、ホストコントロール手段を通じて外部から自在に設定できるように構成することで、高速かつ高度な演算処理が可能で、機能変更や系統変更に対する自由度が高いデジタル映像信号処理装置を実現している。
【０００４】
また、画像処理にも適用可能な技術として、特許文献２には、複数の記憶手段と、時分割された処理の一つである実行単位について、複数の記憶手段のうちの入力用の単一の記憶手段から入力データを受け取り、出力用の単一の記憶手段に処理結果を記憶するデータ処理手段と、記憶手段のデータ記憶量の情報から実行単位の実行状況を求め、実行単位の起動優先度を決定する起動優先度決定手段を備えたプロセッサが開示されている。
【特許文献１】特開平５−２６０３７３号公報
【特許文献２】特開２００４−２８７８８３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
特許文献１に記載の技術のように、複数種の画像処理モジュールを任意に組み合わせて所望の画像処理を行う画像処理装置を構成する場合、以下に述べるような問題がある。すなわち、各画像処理モジュールには、実行する画像処理の種類や内容に応じて処理し易い単位（例えば画素単位、１ライン単位、複数ライン単位、面単位等）がある。しかし、各画像処理モジュールを任意の順番で連結し協調して処理することを可能とするためには、全ての画像処理モジュールの出力単位を揃えるか、或いは各画像処理モジュールが任意の入力単位に対応可能に構成する必要があり、各画像処理モジュールの構成が複雑になる。また、各画像処理モジュールは他の画像処理モジュールと連携して動作するため、各画像処理モジュールには、入力された画像データに対して実際に画像処理を行う部分以外に、自モジュールと連結された他の画像処理モジュールとの間で画像データを受け渡す処理を制御する部分も必要となり、各画像処理モジュールの構成は一層複雑になる。
【０００６】
上記の問題は、特許文献２に記載の技術のように画像処理モジュール（データ処理手段）の前後にバッファ（記憶手段）を設けた構成を用い、個々の画像処理モジュールで各種の画像処理を行わせると共に、個々の画像処理モジュールを、実行する画像処理の種類や内容に応じた処理し易い単位ずつバッファから画像データを取得するように構成することで解決可能である。
【０００７】
しかしながら、近年デジタル画像の高精細化が進み、これに伴ってデジタル画像データのサイズも肥大化してきており、例えばカラー画像をＲＧＢで表すカラー画像データは、解像度が400dpiであれば、Ａ４サイズで44Ｍバイト、Ａ３サイズでは88Ｍバイトになり、解像度が600dpiであれば、Ａ４サイズで100Ｍバイト、Ａ３サイズでは200Ｍバイトもの大サイズになる。このため、特許文献２に記載の技術のように画像処理モジュールの前後にバッファを設ける構成では、個々のバッファの記憶容量も大きくする必要があり、個々のバッファを構成するメモリ等のリソースを大量に消費するという問題がある。また、プロセッサの動作速度に比してメモリ等の記憶デバイスの書込／読出速度は低速であり、プロセッサの性能向上に伴って上記の速度差は更に拡大する一方であるので、画像データの大サイズ化に伴ってバッファへの画像データの書き込みやバッファからの画像データの読み出しに要する時間が画像処理装置における処理速度のボトルネックとなり、処理速度の低下を招くという問題もある。
【０００８】
本発明は上記事実を考慮して成されたもので、大サイズの画像データを扱う場合にもバッファ容量の増大、処理速度の低下を抑制可能な画像処理装置及び画像処理プログラムを得ることが目的である。
【課題を解決するための手段】
【０００９】
上記目的を達成するために請求項１記載の発明に係る画像処理装置は、自モジュールの前段から単位データ量ずつ画像データを取得し、取得した画像データに対して所定の画像処理を行い、前記所定の画像処理を経た画像データ又は前記所定の画像処理の処理結果を自モジュールの後段へ出力する機能を各々備え、実行する画像処理の種類又は内容が互いに異なる複数種の画像処理モジュールの中から選択された１つ以上の画像処理モジュールと、画像データを記憶するためのバッファを備えた１つ以上のバッファモジュールと、が、前記選択された個々の画像処理モジュールの前段及び後段の少なくとも一方にバッファモジュールが連結されるように、個々のモジュールがパイプライン形態又は有向非循環グラフ形態で連結されて構築された画像処理部を備えた画像処理装置であって、前記バッファモジュールは、前段のモジュールから書込対象の画像データが入力された場合に、入力された画像データが圧縮されているか否かに応じて書込方法を切り替えて前記画像データを前記バッファに書き込む書込手段と、後段のモジュールから画像データが要求された場合に、前記バッファから画像データを読み出し、読み出した画像データが圧縮されているか否かに応じて出力方法を切り替えて前記画像データを後段のモジュールへ出力する読出手段と、を備えていることを特徴としている。
【００１０】
本発明に係る画像処理モジュールは、自モジュールの前段から単位データ量ずつ画像データを取得し、取得した画像データに対して所定の画像処理を行い、所定の画像処理を経た画像データ又は所定の画像処理の処理結果を自モジュールの後段へ出力する機能を備えている。本発明では、画像処理モジュールが実行する画像処理の種類又は内容が互いに異なる複数種の画像処理モジュールが用意されており、複数種の画像処理モジュールの中から選択された１つ以上の画像処理モジュールを用いて画像処理部が構築される。なお、画像処理部の構築のために複数の画像処理モジュールが選択される場合、これらの画像処理モジュールは、互いに異なる画像処理モジュールであってもよいし、画像処理モジュールの一部又は全部が重複して選択されてもよい。
【００１１】
また本発明に係る画像処理部は、選択された個々の画像処理モジュールの前段及び後段の少なくとも一方に、画像データを記憶するためのバッファを備えた１つ以上のバッファモジューが連結されるように、個々のモジュールがパイプライン形態又は有向非循環グラフ形態で連結されて構築される。このように、個々の画像処理モジュールの前段及び後段の少なくとも一方にバッファモジュールを連結することで、画像処理モジュールが前段から取得する画像データのサイズ（単位データ量）及び画像処理モジュールが後段へ出力する画像データのサイズを、個々の画像処理モジュールが実行する画像処理の種類や内容に応じて最適化することができ、画像処理モジュールの構成も簡単にすることができる。
【００１２】
なお、個々の画像処理モジュールが前段から取得する画像データのサイズ及び画像処理モジュールが後段へ出力する画像データのサイズは、画像の１ライン分、画像の複数ライン分、画像１面分、画像の１画素分等を含む任意のバイト数の何れであってもよく、単一の画像処理モジュールが前段から取得する画像データのサイズ及び後段へ出力する画像データのサイズは同一であっても相違していてもよい。また、個々の画像処理モジュールが後段へ出力する画像データは未圧縮の画像データであってもよいし、何らかの符号化方法により符号化されて圧縮された画像データであってもよい。
【００１３】
また、本発明に係るバッファモジュールは、前段のモジュールから書込対象の画像データが入力された場合に、入力された画像データが圧縮されているか否かに応じて書込方法を切り替えて前記画像データを前記バッファに書き込む書込手段と、後段のモジュールから画像データが要求された場合に、前記バッファから画像データを読み出し、読み出した画像データが圧縮されているか否かに応じて出力方法を切り替えて前記画像データを後段のモジュールへ出力する読出手段を備えている。これにより、例えば入力された画像データをバッファにそのまま書き込む第１の書込方法と、入力された画像データに対して圧縮処理を行った後にバッファに書き込む第２の書込方法を、入力された画像データが圧縮されているか否かに応じて切り替えると共に、バッファから読み出した画像データを後段のモジュールへそのまま出力する第１の出力方法と、バッファから読み出した画像データに対して伸長処理を行った後に後段のモジュールへ出力する第２の出力方法を、入力された画像データが圧縮されているか否かに応じて切り替えることも可能となり、大サイズの画像データを扱う場合にもバッファ容量の増大、処理速度の低下を抑制することが可能となる。
【００１４】
なお、請求項１記載の発明において、書込手段は、例えば請求項２に記載したように、前段のモジュールから入力された書込対象の画像データが圧縮されているか否か判断し、圧縮されていると判断した場合は画像データをバッファにそのまま書き込み、圧縮されていないと判断した場合は画像データに対して圧縮処理を行った後にバッファに書き込むように構成することが好ましい。これにより、前段のモジュールから入力された画像データが非圧縮の場合にも、バッファモジュールのバッファに書き込む画像データのサイズが小さくされることでバッファの容量を削減できると共に、バッファへの画像データの書込時間及びバッファからの画像データの読出時間を短縮することができる。従って、大サイズの画像データを扱う場合にもバッファ容量の増大、処理速度の低下を抑制することができる。
【００１５】
また、請求項２記載の発明において、バッファモジュールの書込手段をプロセッサで構成した場合（画像データの圧縮処理をプロセッサで行うように構成した場合）、当該プロセッサには上記処理の実行に伴って負荷が加わることになるが、前述のように本発明に係るバッファとして機能させることが可能なメモリ等の記憶デバイスに対する書込／読出速度に比してプロセッサの動作速度は高速であり、記憶デバイスに対する書込／読出速度が処理速度のボトルネックとなっているので、バッファモジュールで画像データの圧縮処理を行うことを原因として処理速度の低下が生ずることを回避することができる。
【００１６】
また、請求項１又は請求項２記載の発明において、バッファモジュールの前段のモジュールからバッファモジュールへの画像データの入力は、画像を構成する所定の単位領域毎に分けて行われるように構成することができるが、この場合、書込手段は、例えば請求項３に記載したように、単位領域のデータが前段のモジュールから所定回入力される間、入力された単位領域のデータのサイズを相互に比較し、入力された所定数の単位領域のデータのサイズが一定の場合は前段のモジュールから入力される画像データが圧縮されていないと判断し、所定数の単位領域のデータのサイズが一定でない場合は前段のモジュールから入力される画像データが圧縮されていると判断するように構成することが好ましい。前段のモジュールから入力される画像データが圧縮されているか否かは、圧縮の有無を通知する情報を前段のモジュールから送信させることによっても検知可能であるが、請求項３記載の発明では、入力される画像データが圧縮されているか否かを、前段のモジュールとの間に上記のような新たなインタフェースを設けることなく検知できるので、本発明に係る画像処理装置を構成する各モジュール間のインタフェースの複雑化を回避することができる。
【００１７】
また、請求項２記載の発明において、書込手段は、例えば請求項４に記載したように、バッファの空き容量又はバッファとして使用可能なシステムリソース（例えばメモリやＨＤＤ(Hard Disk Drive)等の記憶リソース）の空き容量が所定値以上の場合には、入力された画像データが圧縮されていないと判断したときにも、圧縮処理を行うことなく画像データをバッファにそのまま書き込むように構成してもよい。この場合、入力された画像データを記憶するために必要なバッファの容量は増大するものの、書込手段及び読出手段に加わる負荷（書込手段及び読出手段をプロセッサで構成した場合、当該プロセッサに加わる負荷）を軽減することができる。
【００１８】
また、請求項２記載の発明において、バッファを構成するデバイスのアクセス速度やバッファとの間のデータ転送速度は、画像処理装置を構成するハードウェアの構成によって左右される。これを考慮すると、書込手段は、例えば請求項５に記載したように、入力された画像データが圧縮されていないと判断した場合に、バッファを構成するデバイスがアクセス速度が第１所定値以上の記憶デバイスであるか、又は、バッファとの間のデータ転送速度が第２所定値以上の環境のときには、圧縮処理を行うことなく画像データをバッファにそのまま書き込み、バッファを構成するデバイスがアクセス速度が第１所定値未満の記憶デバイスであるか、又は、バッファとの間のデータ転送速度が第２所定値未満の環境のときには、画像データに対して圧縮処理を行った後にバッファに書き込むように構成してもよい。
【００１９】
請求項５記載の発明では、バッファを構成するデバイスがアクセス速度が第１所定値以上の記憶デバイスであるか、又は、バッファとの間のデータ転送速度が第２所定値以上の環境のとき、すなわちバッファに対する画像データの書込／読出速度が処理速度のボトルネックになりにくい場合には、圧縮処理を行うことなく画像データをバッファにそのまま書き込むので、バッファモジュールの書込手段及び読出手段（書込手段及び読出手段をプロセッサで構成した場合は当該プロセッサ）に必要以上に負荷が加わることを防止することができる。
【００２０】
また、請求項２記載の発明において、読出手段は、例えば請求項６に記載したように、後段のモジュールからの要求に応じて前記バッファから読み出した画像データが前記書込手段によって圧縮処理が行われていない画像データであれば、読み出した画像データを後段のモジュールへそのまま出力し、読み出した画像データが前記書込手段によって圧縮処理が行われた画像データであれば、読み出した画像データに対して伸長処理を行った後に後段のモジュールへ出力するように構成することが好ましい。これにより、バッファモジュールに入力され圧縮処理が行われてバッファに書き込まれた画像データが、伸長された後に（元に戻された後に）後段のモジュールへ出力されることになり、バッファモジュールが圧縮処理を行ったか否かに応じて後段のモジュール（画像処理モジュール）が処理を切り替える必要がなくなるので、本発明に係る画像処理装置の構成を簡単にすることができる。
【００２１】
なお、請求項６記載の発明において、バッファモジュールの読出手段をプロセッサで構成した場合（画像データの伸長処理をプロセッサで行うように構成した場合）、当該プロセッサには上記処理の実行に伴って負荷が加わることになるが、前述のように本発明に係るバッファとして機能させることが可能なメモリ等の記憶デバイスに対する書込／読出速度に比してプロセッサの動作速度は高速であり、記憶デバイスに対する書込／読出速度が処理速度のボトルネックとなっているので、バッファモジュールで画像データの伸長処理を行うことを原因として処理速度の低下が生ずることを回避することができる。
【００２２】
また、請求項６記載の発明において、読出手段を備えたバッファモジュールの後段のモジュールが、前段のモジュールから取得した圧縮画像データに対して伸長処理を行った後に画像処理を行う機能、又は、前段のモジュールから取得した圧縮画像データに対して伸長処理を行うことなく画像処理を行う機能を備えた画像処理モジュールである場合、読出手段は、例えば請求項７に記載したように、読み出した画像データが圧縮処理が行われた圧縮画像データであっても伸長処理を行わず、かつ圧縮画像データに適用された圧縮形式を表す属性情報を圧縮画像データに付加することで、後段の画像処理モジュールにおいて、圧縮画像データに対して伸長処理を行った後に画像処理を行わせるか、又は、圧縮画像データに対して伸長処理を行うことなく画像処理を行わせるように構成してもよい。これにより、後段の画像処理モジュールが上記機能を備えている場合に、上記機能を利用することで伸長処理の実行を省略することができ、バッファモジュールの読出手段（読出手段をプロセッサで構成した場合は当該プロセッサ）に必要以上に負荷が加わることを回避することができる。
【００２３】
請求項８記載の発明に係る画像処理プログラムは、コンピュータを、自モジュールの前段から単位データ量ずつ画像データを取得し、取得した画像データに対して所定の画像処理を行い、前記所定の画像処理を経た画像データ又は前記所定の画像処理の処理結果を自モジュールの後段へ出力する機能を各々備え、実行する画像処理の種類又は内容が互いに異なる複数種の画像処理モジュールの中から選択された１つ以上の画像処理モジュールと、画像データを記憶するためのバッファを備えた１つ以上のバッファモジュールと、が、前記選択された個々の画像処理モジュールの前段及び後段の少なくとも一方にバッファモジュールが連結されるように、個々のモジュールがパイプライン形態又は有向非循環グラフ形態で連結されて構築された画像処理部を備えた画像処理装置として機能させるための画像処理プログラムであって、前記バッファモジュールは、前段のモジュールから書込対象の画像データが入力された場合に、入力された画像データが圧縮されているか否かに応じて書込方法を切り替えて前記画像データを前記バッファに書き込む書込手段と、後段のモジュールから画像データが要求された場合に、前記バッファから画像データを読み出し、読み出した画像データが圧縮されているか否かに応じて出力方法を切り替えて前記画像データを後段のモジュールへ出力する読出手段と、を備えていることを特徴としている。
【００２４】
請求項８記載の発明に係る画像処理プログラムは、コンピュータを、上記の書込手段及び読出手段として機能させるためのプログラムであるので、コンピュータが請求項８記載の発明に係る画像処理プログラムを実行することにより、コンピュータが請求項１に記載の画像処理装置として機能することになり、請求項１記載の発明と同様に、大サイズの画像データを扱う場合にもバッファ容量の増大、処理速度の低下を抑制することが可能となる。
【発明の効果】
【００２５】
以上説明したように本発明は、実行する画像処理の種類又は内容が互いに異なる複数種の画像処理モジュールの中から選択された１つ以上の画像処理モジュールの前段及び後段の少なくとも一方にバッファモジュールが連結されるように、個々のモジュールがパイプライン形態又は有向非循環グラフ形態で連結されて構築された構成において、バッファモジュールが、前段のモジュールから書込対象の画像データが入力された場合に、入力された画像データが圧縮されているか否かに応じて書込方法を切り替えてバッファに書き込むと共に、後段のモジュールから画像データが要求された場合に、バッファから読み出した画像データが圧縮されているか否かに応じて出力方法を切り替えて後段のモジュールへ出力するようにしたので、大サイズの画像データを扱う場合にもバッファ容量の増大、処理速度の低下を抑制することが可能になる、という優れた効果を有する。
【発明を実施するための最良の形態】
【００２６】
以下、図面を参照して本発明の実施形態の一例を詳細に説明する。図１には、本発明に係る画像処理装置として機能することが可能なコンピュータ１０が示されている。なお、このコンピュータ１０は、複写機、プリンタ、ファクシミリ装置、これらの機能を兼ね備えた複合機、スキャナ、写真プリンタ等のように内部で画像処理を行う必要のある任意の画像取扱機器に組み込まれていてもよいし、パーソナル・コンピュータ（ＰＣ）等の独立したコンピュータであってもよく、更にＰＤＡ（Personal Digital Assistant）や携帯電話機等の携帯機器に組み込まれたコンピュータであってもよい。
【００２７】
コンピュータ１０はＣＰＵ１２、メモリ１４、表示部１６、操作部１８、記憶部２０、画像データ供給部２２及び画像出力部２４を備えており、これらはバス２６を介して互いに接続されている。コンピュータ１０が上述したような画像取扱機器に組み込まれている場合、表示部１６や操作部１８としては、画像取扱機器に設けられたＬＣＤ等から成る表示パネルやテンキー等を適用することができる。また、コンピュータ１０が独立したコンピュータである場合、表示部１６や操作部１８としては、当該コンピュータに接続されたディスプレイやキーボード、マウス等を適用することができる。また、記憶部２０としてはＨＤＤ(Hard Disk Drive)が好適であるが、これに代えてフラッシュメモリ等の他の不揮発性記憶手段を用いることも可能である。
【００２８】
また、画像データ供給部２２は処理対象の画像データを供給できるものであればよく、例えば紙や写真フィルム等の記録材料に記録されている画像を読み取って画像データを出力する画像読取部、通信回線を介して外部から画像データを受信する受信部、画像データを記憶する画像記憶部（メモリ１４又は記憶部２０）等を適用することができる。また、画像出力部２４は画像処理を経た画像データ又は該画像データが表す画像を出力するものであればよく、例えば画像データが表す画像を紙や感光材料等の記録材料に記録する画像記録部、画像データが表す画像をディスプレイ等に表示する表示部、画像データを記録メディアに書き込む書込装置、画像データを通信回線を介して送信する送信部を適用することができる。また、画像出力部２４は画像処理を経た画像データを単に記憶する画像記憶部（メモリ１４又は記憶部２０）であっても構わない。
【００２９】
図１に示すように、記憶部２０には、ＣＰＵ１２によって実行される各種のプログラムとして、メモリ１４等のリソースの管理やＣＰＵ１２によるプログラムの実行の管理、コンピュータ１０と外部との通信等を司るオペレーティングシステム３０のプログラム、コンピュータ１０を本発明に係る画像処理装置として機能させるための画像処理プログラム群３４、ＣＰＵ１２が上記画像処理プログラム群を実行することで実現される画像処理装置に対して所望の画像処理を行わせる各種のアプリケーション３２のプログラム（図１ではアプリケーションプログラム群３２と表記）が各々記憶されている。
【００３０】
画像処理プログラム群３４は、前述した各種の画像取扱機器や携帯機器を開発する際の開発負荷を軽減したり、ＰＣ等で利用可能な画像処理プログラムを開発する際の開発負荷を軽減することを目的として、各種の画像取扱機器や携帯機器、ＰＣ等の各種機器（プラットフォーム）で共通に使用可能に開発されたプログラムであり、本発明に係る画像処理プログラムに対応している。画像処理プログラム群３４によって実現される画像処理装置は、アプリケーション３２からの構築指示に従い、アプリケーション３２が指示した画像処理を行う画像処理部を構築し、アプリケーション３２からの実行指示に従い、前記画像処理部によって画像処理を行うが（詳細は後述）、画像処理プログラム群３４は、所望の画像処理を行う画像処理部（所望の構成の画像処理部）の構築を指示したり、構築された画像処理部による画像処理の実行を指示するためのインタフェースをアプリケーション３２に提供している。このため、内部で画像処理を行う必要のある任意の機器を新規開発する等の場合にも、前記画像処理を行うプログラムの開発に関しては、当該機器で必要とされる画像処理を上記のインタフェースを利用して画像処理プログラム群３４に行わせるアプリケーション３２を開発するのみで済み、実際に画像処理を行うプログラムを新たに開発する必要が無くなるので、開発負荷を軽減することができる。
【００３１】
また、画像処理プログラム群３４によって実現される画像処理装置は、前述のように、アプリケーション３２からの構築指示に従い、アプリケーション３２が指示した画像処理を行う画像処理部を構築し、構築した画像処理部によって画像処理を行うので、例えば画像処理対象の画像データの色空間や１画素当たりのビット数が不定であったり、実行すべき画像処理の内容や手順・パラメータ等が不定である場合にも、アプリケーション３２が画像処理部の再構築を指示することで、画像処理装置（画像処理部）によって実行される画像処理を、処理対象の画像データ等に応じて柔軟に変更することができる。
【００３２】
以下、画像処理プログラム群３４について説明する。図１に示すように、画像処理プログラム群３４はモジュールライブラリ３６と、処理構築部４２のプログラムと、処理管理部４６のプログラムに大別される。詳細は後述するが、本実施形態に係る処理構築部４２は、アプリケーションからの指示により、例として図２に示すように、予め定められた画像処理を行う１つ以上の画像処理モジュール３８と、個々の画像処理モジュール３８の前段及び後段の少なくとも一方に配置され画像データを記憶するためのバッファを備えたバッファモジュール４０と、がパイプライン形態又はＤＡＧ(Directed Acyclic Graph：有向非循環グラフ)形態で連結されて成る画像処理部５０を構築する。画像処理部５０を構成する個々の画像処理モジュールの実体はＣＰＵ１２によって実行されＣＰＵ１２で所定の画像処理を行わせるための第１のプログラム、又は、ＣＰＵ１２によって実行されＣＰＵ１２により図１に図示されていない外部の画像処理装置（例えば専用画像処理ボード等）に対する処理の実行を指示するための第２のプログラムであり、上述したモジュールライブラリ３６には、予め定められた互いに異なる画像処理（例えば入力処理やフィルタ処理、色変換処理、拡大・縮小処理、スキュー角検知処理、画像回転処理、画像合成処理、出力処理等）を行う複数種の画像処理モジュール３８のプログラムが各々登録されている。以下では、説明を簡単にするために、画像処理部５０を構成する個々の画像処理モジュールの実体が上記の第１のプログラムであるものとして説明する。
【００３３】
個々の画像処理モジュール３８は、例として図８(Ａ)にも示すように、画像データに対する画像処理を所定の単位処理データ量ずつ行う画像処理エンジン３８Ａと、画像処理モジュール３８の前段及び後段のモジュールとの画像データの入出力及び画像処理エンジン３８Ａの制御を行う制御部３８Ｂから構成されている。個々の画像処理モジュール３８における単位処理データ量は、画像の１ライン分、画像の複数ライン分、画像の１画素分、画像１面分等を含む任意のバイト数の中から、画像処理エンジン３８Ａが行う画像処理の種類等に応じて予め選択・設定されており、例えば色変換処理やフィルタ処理を行う画像処理モジュール３８では単位処理データ量が１画素分とされ、拡大・縮小処理を行う画像処理モジュール３８では単位処理データ量が画像の１ライン分又は画像の複数ライン分とされ、画像回転処理を行う画像処理モジュール３８では単位処理データ量が画像１面分とされ、画像圧縮伸長処理を行う画像処理モジュール３８では単位処理データ量が実行環境に依存するＮバイトとされている。
【００３４】
また、モジュールライブラリ３６には、画像処理エンジン３８Ａが実行する画像処理の種類が同一でかつ実行する画像処理の内容が異なる画像処理モジュール３８も登録されている（図１では、この種の画像処理モジュールを「モジュール１」「モジュール２」と表記して示している）。例えば拡大・縮小処理を行う画像処理モジュール３８については、入力された画像データを１画素おきに間引くことで50％に縮小する縮小処理を行う画像処理モジュール３８、入力された画像データに対して指定された拡大・縮小率で拡大・縮小処理を行う画像処理モジュール３８等の複数の画像処理モジュール３８が各々用意されている。また、例えば色変換処理を行う画像処理モジュール３８については、ＲＧＢ色空間をＣＭＹ色空間へ変換する画像処理モジュール３８やその逆へ変換する画像処理モジュール３８、Ｌ*ａ*ｂ*色空間等の他の色空間変換を行う画像処理モジュール３８が各々用意されている。
【００３５】
また、画像処理モジュール３８の制御部３８Ｂは、画像処理エンジン３８Ａが単位処理データ量ずつ処理するために必要な画像データを入力するために、自モジュールの前段のモジュール（例えばバッファモジュール４０）から画像データを単位読出データ量ずつ取得し、画像処理エンジン３８Ａから出力される画像データを単位書込データずつ後段のモジュール（例えばバッファモジュール４０）へ出力する（画像処理エンジン３８Ａで圧縮等のデータ量の増減を伴う画像処理が行われなければ単位書込データ量＝単位処理データ量となる）か、画像処理エンジン３８Ａによる画像処理の結果を自モジュールの外部へ出力する（例えば画像処理エンジン３８Ａがスキュー角検知処理等の画像解析処理を行う場合、画像データに代えてスキュー角検知結果等の画像解析処理結果が出力されることがある）処理を行うが、モジュールライブラリ３６には、画像処理エンジン３８Ａが実行する画像処理の種類及び内容が同一で、上記の単位処理データ量や単位読出データ量、単位書込データ量が異なる画像処理モジュール３８も登録されている。例えば、先程は画像回転処理を行う画像処理モジュール３８における単位処理データ量を画像１面分と説明したが、同じ画像回転処理を行う画像処理モジュール３８で単位処理データ量が画像の１ライン分又は画像の複数ライン分であるものがモジュールライブラリ３６に含まれていても良い。
【００３６】
また、モジュールライブラリ３６に登録されている個々の画像処理モジュール３８のプログラムは、画像処理エンジン３８Ａに相当するプログラムと制御部３８Ｂに相当するプログラムから構成されているが、制御部３８Ｂに相当するプログラムは部品化されており、個々の画像処理モジュール３８のうち単位読出データ量及び単位書込データ量が同一の画像処理モジュール３８は、画像処理エンジン３８Ａで実行される画像処理の種類や内容に拘わらず、制御部３８Ｂに相当するプログラムが共通化されている（制御部３８Ｂに相当するプログラムとして同一のプログラムが用いられている）。これにより、画像処理モジュール３８のプログラムの開発にあたっての開発負荷が軽減される。
【００３７】
なお、画像処理モジュール３８の中には、入力される画像の属性が未知の状態では単位読出データ量及び単位書込データ量が確定しておらず、入力画像データの属性を取得し、取得した属性を所定の演算式に代入して演算することで単位読出データ量や単位書込データ量が確定するモジュールが存在しているが、この種の画像処理モジュール３８については、単位読出データ量と単位書込データ量が互いに同一の演算式を用いて導出される画像処理モジュール３８について、制御部３８Ｂに相当するプログラムを共通化するようにすればよい。また、本実施形態に係る画像処理プログラム群３４は、前述のように各種機器に実装可能であるが、画像処理プログラム群３４のうちモジュールライブラリ３６に登録する画像処理モジュール３８の数や種類等については、画像処理プログラム群３４を実装する各種機器で必要とされる画像処理に応じて、適宜追加・削除・入替等が可能であることは言うまでもない。
【００３８】
また、画像処理部５０を構成する個々のバッファモジュール４０は、例として図８(Ｂ)にも示すように、コンピュータ１０に設けられたメモリ１４からオペレーティングシステム３０を通じて確保されたメモリ領域で構成されるバッファ４０Ａと、バッファモジュール４０の前段及び後段のモジュールとの画像データの入出力及びバッファ４０Ａの管理を行うバッファ制御部４０Ｂから構成されており、更にバッファ制御部４０Ｂは書込制御部４０Ｃと読出制御部４０Ｄを備えている。個々のバッファモジュール４０のバッファ制御部４０Ｂ（の書込制御部４０Ｃ及び読出制御部４０Ｄ）もその実体はＣＰＵ１２によって実行されるプログラムであり、モジュールライブラリ３６にはバッファ制御部４０Ｂのプログラムも登録されている（図１ではバッファ制御部４０Ｂのプログラムを「バッファモジュール」と表記して示している）。
【００３９】
また、アプリケーション３２からの指示に従って画像処理部５０を構築する処理構築部４２は、図１に示すように複数種のモジュール生成部４４から構成されている。複数種のモジュール生成部４４は互いに異なる画像処理に対応しており、アプリケーション３２によって起動されることで、対応する画像処理を実現するための画像処理モジュール３８及びバッファモジュール４０から成るモジュール群を生成する処理を行う。なお、図１ではモジュール生成部４４の一例として、モジュールライブラリ３６に登録されている個々の画像処理モジュール３８が実行する画像処理の種類に対応するモジュール生成部４４を示しているが、個々のモジュール生成部４４に対応する画像処理は、複数種の画像処理モジュール３８によって実現される画像処理（例えばスキュー角検知処理と画像回転処理から成るスキュー補正処理）であってもよい。必要とされる画像処理が複数種の画像処理を組み合わせた処理である場合、アプリケーション３２は複数種の画像処理の何れかに対応するモジュール生成部４４を順次起動する。これにより、アプリケーション３２によって順次起動されたモジュール生成部４４により、必要とされる画像処理を行う画像処理部５０が構築されることになる。
【００４０】
また図１に示すように、処理管理部４６は、画像処理部５０における画像処理の実行を制御するワークフロー管理部４６Ａ、画像処理部５０の各モジュールによるメモリ１４や各種のファイル等のコンピュータ１０のリソースの使用を管理するリソース管理部４６Ｂ、及び、画像処理部５０で発生したエラーを管理するエラー管理部４６Ｃを含んで構成されている。なお、本実施形態において、処理構築部４２によって構築される画像処理部５０は、画像処理部５０を構成する個々の画像処理モジュール３８が、画像１面分よりも小さいデータ量を単位として後段へ画像データを引き渡しながら並列に画像処理を行うように動作する（ブロック単位処理と称する）。
【００４１】
なお、リソース管理部４６Ｂによるメモリ管理の方式としては、例えば、画像処理部５０の個々のモジュールからの要求の都度、メモリ１４から要求元のモジュールに割り当てるメモリ領域をオペレーティングシステム３０を通じて確保する第１管理方式、メモリ１４から一定サイズのメモリ領域をオペレーティングシステム３０を通じて事前に（例えばコンピュータ１０の電源投入時に）確保し、個々のモジュールからの要求があると、事前に確保したメモリ領域のうちの一部領域を要求元のモジュールに割り当てる第２管理方式、及び、メモリ１４から一定サイズのメモリ領域をオペレーティングシステム３０を通じて事前に確保し、個々のモジュールからの要求があると、要求されたメモリ領域のサイズが閾値未満であれば事前に確保したメモリ領域のうちの一部領域を要求元のモジュールに割り当て、要求されたメモリ領域のサイズが閾値以上であれば要求元のモジュールに割り当てるメモリ領域をオペレーティングシステム３０を通じて確保する第３管理方式の何れかを採用することができる。また、何れの管理方式でメモリ管理を行うかを選択・設定可能としてもよい。
【００４２】
またエラー管理部４６Ｃは、画像処理部５０が画像処理を実行している途中でエラーが発生した場合に、発生したエラーの種別・発生箇所等のエラー情報を取得し、画像処理プログラム群３４がインストールされたコンピュータ１０が組み込まれている機器の種別や構成等を表す装置環境情報を記憶部２０等から取得し、取得した装置環境情報が表す装置環境に応じたエラー通知方法を判断し、判断したエラー通知方法でエラーの発生を通知する処理を行う。
【００４３】
次に本実施形態の作用を説明する。画像処理プログラム群３４が実装されている機器において、何らかの画像処理を行う必要のある状況になると、この状況が特定のアプリケーション３２によって検知される。なお、画像処理を行う必要のある状況としては、例えば画像データ供給部２２としての画像読取部によって画像を読み取り、画像出力部２４としての画像記録部により記録材料に画像として記録するか、画像出力部２４としての表示部に画像として表示させるか、画像出力部２４としての書込装置により画像データを記録メディアに書き込むか、画像出力部２４としての送信部により画像データを送信するか、画像出力部２４としての画像記憶部に記憶させるジョブの実行がユーザによって指示された場合、或いは、画像データ供給部２２としての受信部によって受信されるか、画像データ供給部２２としての画像記憶部に記憶されている画像データに対して、上記の記録材料への記録、表示部への表示、記録メディアへの書き込み、送信、画像記憶部への記憶の何れかを行うジョブの実行がユーザによって指示された場合が挙げられる。また、画像処理を行う必要のある状況は上記に限られるものではなく、例えばユーザからの指示に応じてアプリケーション３２が実行可能な処理の名称等を表示部１６に一覧表示している状態で、実行対象の処理がユーザによって選択された等の場合であってもよい。
【００４４】
上記のように、何らかの画像処理を行う必要のある状況になったことを検知すると、アプリケーション３２は、まず画像処理対象の画像データを供給する画像データ供給部２２の種別を認識し、認識した種別がバッファ領域（メモリ１４の一部領域）であった場合には、画像データ供給部２２として指定されたバッファ領域を既に確保されたバッファ４０Ａとしてバッファ制御部４０Ｂに認識させるパラメータを設定し、バッファ制御部４０Ｂのプログラムを実行するプロセス、スレッド又はオブジェクトを生成する（バッファ制御部４０Ｂを生成する）ことで、指定されたバッファ領域を含むバッファモジュール４０（画像データ供給部２２として機能するバッファモジュール４０）を生成する。
【００４５】
続いてアプリケーション３２は、上記と同様に、画像処理を行った画像データの出力先としての画像出力部２４の種別を認識し、認識した種別がバッファ領域（メモリ１４の一部領域）であった場合は、画像出力部２４として指定されたバッファ領域を含むバッファモジュール４０を上記と同様にして生成する。ここで生成されたバッファモジュール４０は画像出力部２４として機能する。また、アプリケーション３２は実行すべき画像処理の内容を認識し、実行すべき画像処理を、個々のモジュール生成部４４に対応するレベルの画像処理の組み合わせに分解し、実行すべき画像処理を実現するために必要な画像処理の種類及び個々の画像処理の実行順序を判定する。なお、この判定は、例えば上記の画像処理の種類及び個々の画像処理の実行順序を、ユーザが実行を指示可能なジョブの種類と対応付けて予め情報として登録しておき、アプリケーション３２は、実行が指示されたジョブの種類に対応する情報を読み出すことによって実現することができる。
【００４６】
そしてアプリケーション３２は、上記で判定した画像処理の種類及び実行順序に基づいて、特定の画像処理に対応するモジュール生成部４４を起動（モジュール生成部４４のプログラムを実行するプロセス、スレッド又はオブジェクトを生成）した後に、起動したモジュール生成部４４に対し、当該モジュール生成部４４によるモジュール群の生成に必要な情報として、前記モジュール群に画像データを入力する入力モジュールを識別するための入力モジュール識別情報、前記モジュール群が画像データを出力する出力モジュールを識別するための出力モジュール識別情報、前記モジュール群に入力される入力画像データの属性を表す入力画像属性情報、実行すべき画像処理のパラメータを通知して対応するモジュール群の生成を指示する。また、必要とされる画像処理が複数種の画像処理を組み合わせた処理である場合、アプリケーション３２は、指示したモジュール生成部４４からモジュール群の生成完了が通知されると、個々の画像処理に対応する他のモジュール生成部４４を起動してモジュール群の生成に必要な情報を通知する処理を個々の画像処理の実行順序の昇順に繰り返す。
【００４７】
なお、上記の入力モジュールは、実行順序が１番目のモジュール群については画像データ供給部２２が入力モジュールとなり、実行順序が２番目以降のモジュール群については前段のモジュール群の最終モジュール（通常はバッファモジュール４０）が入力モジュールとなる。また、上記の出力モジュールについては、実行順序が最後のモジュール群では画像出力部２４が出力モジュールとなるので、画像出力部２４が出力モジュールとして指定されるが、その他のモジュール群では出力モジュールは未確定のためにアプリケーション３２による指定は行われず、必要な場合はモジュール生成部４４によって生成・設定される。また、入力画像属性や画像処理のパラメータについては、例えばユーザが実行を指示可能なジョブの種類と対応付けて予め情報として登録しておき、実行が指示されたジョブの種類に対応する情報を読み出すことでアプリケーション３２が認識するようにしてもよいし、ユーザに指定させるようにしてもよい。
【００４８】
一方、モジュール生成部４４は、アプリケーション３２によって起動されるとモジュール生成処理を行う。モジュール生成処理では、まず生成対象の画像処理モジュール３８に入力される入力画像データの属性を表す入力画像属性情報を取得する。なお、入力画像データの属性を取得する処理は、生成対象の画像処理モジュール３８の前段にバッファモジュール４０が存在している場合、当該バッファモジュール４０に画像データの書き込みを行う更に前段の画像処理モジュール３８から出力画像データの属性を取得することによって実現できる。
【００４９】
そして、取得した情報が表す入力画像データの属性に基づいて、生成対象の画像処理モジュール３８の生成が必要か否か判定する。例えばモジュール生成部４４が色変換処理を行うモジュール群を生成するモジュール生成部であり、画像処理のパラメータにより出力画像データの色空間としてＣＭＹ色空間がアプリケーション３２から指定された場合、取得した入力画像属性情報に基づいて入力画像データがＲＧＢ色空間のデータであることが判明したときには、色空間処理を行う画像処理モジュール３８としてＲＧＢ→ＣＭＹの色空間変換を行う画像処理モジュール３８を生成する必要があるが、入力画像データがＣＭＹ色空間のデータであったときには、入力画像データの属性と出力画像データの属性が色空間に関して一致しているので、色空間変換処理を行う画像処理モジュール３８は生成不要と判断する。
【００５０】
生成対象の画像処理モジュール３８の生成が必要と判断した場合には、生成対象の画像処理モジュール３８の後段にバッファモジュール４０が必要が否かを判定する。この判定は、画像処理モジュールの後段が出力モジュール（画像出力部２４）である場合（例えば図２(Ａ)〜(Ｃ)に示す画像処理部５０における最後段の画像処理モジュール３８を参照）や、例として図２(Ｂ)に示す画像処理部５０においてスキュー角検知処理を行う画像処理モジュール３８のように、画像処理モジュールが、画像データに対して解析等の画像処理を行いその結果を他の画像処理モジュール３８へ出力するモジュールである場合は否定されるが、上記以外の場合は判定が肯定されてバッファ制御部４０Ｂを起動する（バッファ制御部４０Ｂのプログラムを実行するプロセス、スレッド又はオブジェクトを各々生成する）ことで、画像処理モジュール３８の後段に連結するバッファモジュール４０を生成する。
【００５１】
続いて、前段のモジュール（例えばバッファモジュール４０）の情報、後段のバッファモジュール４０の情報（後段にバッファモジュール４０を生成した画像処理モジュール３８のみ）、画像処理モジュール３８に入力される入力画像データの属性、処理パラメータを与えて、モジュールライブラリ３６に登録されており、画像処理モジュール３８として利用可能な複数の候補モジュールの中から、先に取得した入力画像データの属性、及び、画像処理モジュール３８で実行すべき処理パラメータに合致する画像処理モジュール３８を選択・生成（画像処理エンジン３８Ａ及び制御部３８Ｂのプログラムを実行するプロセス、スレッド又はオブジェクトを生成）する。
【００５２】
例えばモジュール生成部４４が色変換処理を行うモジュール群を生成するモジュール生成部であり、処理パラメータにより出力画像データの色空間としてＣＭＹ色空間が指定され、更に入力画像データがＲＧＢ色空間のデータであった場合には、モジュールライブラリ３６に登録されている各種の色空間処理を行う複数種の画像処理モジュール３８の中から、ＲＧＢ→ＣＭＹの色空間変換を行う画像処理モジュール３８が選択・生成される。また、画像処理モジュールが拡大・縮小処理を行う画像処理モジュール３８であり、指定された拡大縮小率が50％以外であれば、入力された画像データに対して指定された拡大・縮小率で拡大・縮小処理を行う画像処理モジュール３８が選択・生成され、指定された拡大縮小率が50％であれば、拡大縮小率50％に特化した拡大縮小処理、すなわち入力された画像データを１画素おきに間引くことで50％に縮小する縮小処理を行う画像処理モジュール３８が選択・生成される。
【００５３】
なお、画像処理モジュール３８の選択は上記に限られるものではなく、例えば画像処理エンジン３８Ａによる画像処理における単位処理データ量が異なる画像処理モジュール３８をモジュールライブラリ３６に複数登録しておき、画像処理部５０へ割当可能なメモリ領域のサイズ等の動作環境に応じて、適切な単位処理データ量の画像処理モジュール３８を選択する（例えば上記サイズが小さくなるに従って単位処理データ量の小さい画像処理モジュール３８を選択する等）ようにしてもよいし、アプリケーション３２或いはユーザに選択させるようにしてもよい。
【００５４】
画像処理モジュール３８の生成が完了すると、後段のバッファモジュール４０のＩＤと生成した画像処理モジュール３８のＩＤの組をワークフロー管理部４６Ａに通知する。このＩＤは、個々のモジュールを一意に判別できる情報であればよく、例えば個々のモジュールの生成順に付与した番号や、バッファモジュール４０や画像処理モジュール３８のオブジェクトのメモリ上でのアドレス等でも良い。またモジュール生成部４４が、複数種の画像処理モジュール３８によって実現される画像処理（例えばスキュー角検知処理を行う画像処理モジュール３８と画像回転処理を行う画像処理モジュール３８によって実現されるスキュー補正処理）を行うモジュール群を生成する場合には、上記処理が繰り返されて２個以上の画像処理モジュール３８を含むモジュール群が生成される。アプリケーション３２によって順次起動された個々のモジュール生成部４４により、以上のモジュール生成処理が順次行われることで、例として図２(Ａ)〜(Ｃ)に示すように、必要とされる画像処理を行う画像処理部５０が構築される。
【００５５】
なお、本実施形態では、特定の画像処理の実行頻度が高い等の場合に、アプリケーション３２が、特定の画像処理を行う画像処理部５０を生成するための複数種のモジュール生成部４４に対し、特定の画像処理を行う画像処理部５０を生成させた後も処理終了を指示しないことでプロセス、スレッド又はオブジェクトとして残しておき、特定の画像処理を行う必要が生ずる毎に、プロセス、スレッド又はオブジェクトとして残しておいた各モジュール生成部４４に対してモジュール群の生成を順次指示することで、特定の画像処理を行う画像処理部５０を再生成させることも可能とされている。これにより、特定の画像処理を行う必要が生ずる毎に対応する各モジュール生成部４４を各々起動する処理が不要となり、特定の画像処理を行う画像処理部５０を再生成するのに要する時間を短縮することができる。
【００５６】
ところで、画像処理モジュール３８の制御部３８Ｂは、モジュール生成部４４によって起動されると画像処理モジュール３８の初期化を行う。この初期化では、まずモジュール生成部４４から与えられた自モジュールの前段及び後段のモジュールの情報を記憶する。次に、自モジュールの画像処理エンジン３８Ａが行う画像処理の種類や内容等に基づき、自モジュールが使用するメモリのサイズ及び自モジュールが使用する他のリソースの有無を認識する。なお、自モジュールが使用するメモリは、画像処理エンジン３８Ａが画像処理を行うために必要なメモリが主であるが、前段のモジュールが画像データ供給部２２である場合や後段のモジュールが画像出力部２４である場合には、前段又は後段のモジュールとの画像データの送受に際して画像データを一時記憶するためのバッファ用のメモリが必要となることもある。また、処理パラメータにテーブル等の情報が含まれている場合には、それを保持するためのメモリ領域が必要となることもある。そして、認識したサイズのメモリ領域の確保をリソース管理部４６Ｂへ要求し、リソース管理部４６Ｂによって確保されたメモリ領域をリソース管理部４６Ｂから受け取る。また、自モジュール（の画像処理エンジン３８Ａ）がメモリ以外の他のリソースを必要としていると認識した場合には、上記他のリソースの確保をリソース管理部４６Ｂへ要求し、上記他のリソースをリソース管理部４６Ｂから受け取る。
【００５７】
続いて自モジュールの前段のモジュールを判定する。自モジュールの前段にモジュールが存在していない場合には何ら処理を行わないが、前段のモジュールがバッファモジュール４０以外、例えば画像データ供給部２２や特定のファイル等である場合には、必要に応じてその初期化処理を行う。また、自モジュールの前段にバッファモジュール４０が存在している場合には、前段のバッファモジュール４０からの１回の画像データの読み出しによって取得する画像データのデータ量（単位読出データ量）を認識する。この単位読出データ量は、自モジュールの前段のバッファモジュール４０の数が１個であれば１個だけであるが、例えば図２(Ｃ)に示す画像処理部５０において画像合成処理を行う画像処理モジュール３８のように、前段のバッファモジュール４０の数が複数で、複数のバッファモジュール４０から各々取得した画像データを用いて画像処理エンジン３８Ａが画像処理を行う等の場合、前段の個々のバッファモジュール４０に対応する単位読出データ量は、自モジュールの画像処理エンジン３８Ａが行う画像処理の種類や内容、前段のバッファモジュール４０の数等に応じて定まる。そして、認識した単位読出データ量を、前段に存在している全てのバッファモジュール４０へ通知することで、前段に存在している全てのバッファモジュール４０に単位読出データ量を設定する（図８(Ａ)の(1)も参照）。
【００５８】
次に、自モジュールの後段のモジュールを判定する。自モジュールの後段のモジュールがバッファモジュール４０以外、例えば画像出力部２４や特定のファイル等の場合には、必要に応じてその初期化処理（例えば後段のモジュールが画像出力部２４であれば、単位書込データ量に相当するデータ量ずつ画像データを出力することを通知する処理等）を行う。また、後段のモジュールがバッファモジュール４０であれば、１回の画像データの書き込みにおける画像データのデータ量（単位書込データ量）を認識し、後段のバッファモジュールに当該単位書込データ量を設定（図８(Ａ)の(2)も参照）する。そして、当該画像処理モジュール３８の初期化の完了をモジュール生成部４４に通知して処理を終了する。
【００５９】
一方、画像処理部５０を構成する個々のバッファモジュール４０のバッファ制御部４０Ｂは、モジュール生成部４４又はアプリケーション３２によって起動されるとバッファモジュール４０の初期化を行う。バッファモジュール４０の初期化では、まず自モジュールの前段の画像処理モジュール３８から単位書込データ量が通知されるか又は自モジュールの後段の画像処理モジュール３８から単位読出データ量が通知される毎に、通知された単位書込データ量又は単位読出データ量を記憶する（図８(Ｂ)の(1),(2)も参照）。
【００６０】
自モジュールと連結されている全ての画像処理モジュール３８から単位書込データ量又は単位読出データ量が通知されると、自モジュールと連結されている個々の画像処理モジュール３８によって各々設定された単位書込データ量及び単位読出データ量に基づいて、自モジュールのバッファ４０Ａの管理単位である単位バッファ領域のサイズを決定し、決定した単位バッファ領域のサイズを記憶する。単位バッファ領域のサイズとしては、自モジュールに設定された単位書込データ量及び単位読出データ量のうちの最大値が好適であるが、単位書込データ量を設定してもよいし、単位読出データ量（自モジュールの後段に複数の画像処理モジュール３８が連結されている場合は、個々の画像処理モジュール３８によって各々設定された単位読出データ量の最大値）を設定してもよいし、単位書込データ量と単位読出データ量（の最大値）の最小公倍数を設定してもよいし、この最小公倍数が所定値未満であれば最小公倍数を、最小公倍数が所定値以上であれば別の値（例えば上述した単位書込データ量及び単位読出データ量のうちの最大値、単位書込データ量、単位読出データ量（の最大値）の何れか）を設定するようにしてもよい。
【００６１】
また、自モジュールがアプリケーション３２によって生成され、画像データ供給部２２又は画像出力部２４として機能するバッファモジュール４０であった場合には、自モジュールのバッファ４０Ａとして用いるメモリ領域が既に存在しているので、先に決定した単位バッファ領域のサイズを、自モジュールのバッファ４０Ａとして用いる既設のメモリ領域のサイズに変更する。更に、自モジュールの後段の個々の画像処理モジュール３８に対応する有効データポインタを各々生成し、生成した有効データポインタを初期化する。この有効データポインタは、自モジュールの前段の画像処理モジュールによって自モジュールのバッファ４０Ａに書き込まれた画像データのうち、対応する後段の画像処理モジュール３８によって読み出されていない画像データ（有効データ）の先頭位置（次の読出開始位置）と末尾位置を各々指し示すポインタであり、初期化時には通常、有効データが存在していないことを意味する特定の情報が設定されるが、自モジュールが自モジュールがアプリケーション３２によって生成され、画像データ供給部２２として機能するバッファモジュール４０であれば、自モジュールのバッファ４０Ａとして用いるメモリ領域には既に画像処理対象の画像データが書き込まれていることがあり、この場合は当該画像データの先頭位置及び末尾位置が後段の個々の画像処理モジュール３８に対応する有効データポインタに各々設定される。
【００６２】
また、バッファ制御部４０Ｂの書込制御部４０Ｃによって行われるデータ書込処理で使用される「検出フラグ」を１に、「圧縮フラグ」及び「入力回数」を各々０に初期設定する。以上の処理によりバッファモジュール４０の初期化が完了し、バッファ制御部４０Ｂは初期化の完了をワークフロー管理部４６Ａへ通知する。
【００６３】
一方、アプリケーション３２は、順次起動したモジュール生成部４４によって前述のモジュール生成処理が順次行われることで、必要とされる画像処理を行う画像処理部５０の構築が完了すると、ワークフロー管理部４６Ａのプログラムを実行するスレッド（又はプロセス又はオブジェクト）を起動することで、ワークフロー管理部４６Ａに対して画像処理部５０による画像処理の実行を指示する。
【００６４】
処理管理部４６のワークフロー管理部４６Ａは、プログラムが起動されることで図９に示すブロック単位制御処理を行う。ワークフロー管理部４６Ａはブロック単位処理において、画像処理部５０を構成する画像処理モジュール３８のうちの所定の画像処理モジュール３８に処理要求を入力することで、画像処理部５０による画像処理をブロック単位の実行形態で行わせるが、以下では画像処理部５０全体の動作説明に先立ち、個々のバッファモジュール４０のバッファ制御部４０Ｂによって行われる初期化処理完了以降の処理、個々の画像処理モジュール３８の制御部３８Ｂによって行われる画像処理モジュール制御処理について順に説明する。
【００６５】
本実施形態では、画像処理モジュール３８が後段のバッファモジュール４０に画像データを書き込む場合には、画像処理モジュール３８からバッファモジュール４０へ書込要求が入力され、画像処理モジュール３８が前段のバッファモジュール４０から画像データを読み出す場合には、画像処理モジュール３８からバッファモジュール４０へ読出要求が入力される。前段の画像処理モジュール３８からの書込要求を含む何らかの情報がバッファモジュール４０に入力された場合（及び、後述するタイマがタイムアウトした場合）は、図３に示すデータ書込処理がバッファ制御部４０Ｂの書込制御部４０Ｃによって実行される。なお、以下で説明するデータ書込処理は、関数やメソッドの呼び出しで処理が始まるようにしてもよい。なお、このデータ書込処理を行う書込制御部４０Ｃは本発明に係る書込手段（詳しくは請求項２に記載の書込手段）に対応している。
【００６６】
データ書込処理では、まずステップ１００において、今回のデータ書込処理の起動要因が、タイマがタイムアウトしたことによる起動か否か判定する。判定が否定された場合はステップ１０４へ移行するが、上記判定が肯定された場合はステップ１０２へ移行し、過去に入力されてワークメモリ等に保管している書込要求情報をワークメモリ等から取り出す。ステップ１０４では、処理対象の情報（バッファモジュール４０に入力された情報又はワークメモリ等から取り出した情報）が書込要求情報か否か判定する。判定が肯定された場合はステップ１０６へ移行し、自モジュールのバッファ４０Ａが他のプロセス、スレッド又はオブジェクトによって使用中か否か判定する。バッファ４０Ａは読出制御部４０Ｄからもアクセスされるので、当該判定が肯定された場合はステップ１０８へ移行して今回の処理対象の書込要求情報をワークメモリ等に保管し、次のステップ１１０でタイマをスタートさせてデータ書込処理を一旦終了する。
【００６７】
一方、ステップ１０６の判定が否定された場合にはステップ１１２へ移行し、確保すべきメモリ領域のサイズとして単位書込データ量をリソース管理部４６Ｂに通知して、書込用に用いるメモリ領域（書込用バッファ領域：図４(Ｂ)も参照）をリソース管理部４６Ｂによって確保させる。次のステップ１１４では、自モジュールのバッファ４０Ａを構成する保管用の単位バッファ領域の中に、単位書込データ量以上の空き領域が有る単位バッファ領域（単位書込データ量の画像データを書き込み可能な単位バッファ領域）が存在しているか否か判定する。モジュール生成部４４によって生成されたバッファモジュール４０は、当初はバッファ４０Ａとして用いるメモリ領域（単位バッファ領域）が確保されておらず、メモリ領域の不足が生ずる度に単位バッファ領域を単位として確保されるので、バッファモジュール４０に最初に書込要求が入力されたときにはバッファ４０Ａとして用いるメモリ領域（単位バッファ領域）が存在しておらず、この判定は否定される。また、後述する処理を経てバッファ４０Ａとして用いる単位バッファ領域が確保された後も、当該単位バッファ領域への画像データの書込に伴って当該単位バッファ領域内の空き領域が単位書込データ量未満になった場合にも上記判定は否定される。
【００６８】
ステップ１１４の判定が否定された場合はステップ１１６へ移行し、確保すべきメモリ領域のサイズ（単位バッファ領域のサイズ）をリソース管理部４６Ｂに通知して、自モジュールのバッファ４０Ａとして用いるメモリ領域（画像データの保管に用いる単位バッファ領域）をリソース管理部４６Ｂによって確保させた後にステップ１１８へ移行する。また、ステップ１１４の判定が肯定された場合はステップ１１６をスキップしてステップ１１８へ移行する。そしてステップ１１８では、先のステップ１１２で確保した書込用バッファ領域を書込領域として、当該書込領域の先頭アドレスを書込要求元の画像処理モジュール３８へ通知すると共に、書込対象の画像データを通知した先頭アドレスから順に書き込むよう要請する。これにより、書込要求元の画像処理モジュール３８は、先頭アドレスが通知された書込領域（単位バッファ領域又は書込用バッファ領域）に画像データを書き込む（図４（Ｂ）も参照）。
【００６９】
例えば単位バッファ領域のサイズが単位書込データ量の整数倍でない場合、バッファ４０Ａ（単位バッファ領域）への単位書込データ量の画像データの書込が繰り返されることで、例として図４(Ａ)にも示すように、空き領域有りの単位バッファ領域における空き領域のサイズが単位書込データ量よりも小さい状態が生ずる。この場合、単位書込データ量の画像データが書き込まれる領域が複数の単位バッファ領域に跨ることになるが、本実施形態では、バッファ４０Ａとして用いるメモリ領域を単位バッファ領域を単位として確保するので、異なるタイミングで確保した単位バッファ領域が実メモリ（メモリ１４）上で連続する領域であることは保証されない。これに対して本実施形態では、画像処理モジュール３８による画像データの書き込みを、保管用の単位バッファ領域と別に確保した書込用バッファ領域に対して行わせ、図４(Ｃ)に示すように、書込用バッファ領域に一旦書き込まれた画像データを保管用の単一又は複数の単位バッファ領域へ複写するので、画像データが書き込まれる領域が複数の単位バッファ領域に跨るか否かに拘わらず、書込要求元の画像処理モジュール３８への書込領域の通知は、上記のようにその先頭アドレスを通知するのみで済み、画像処理モジュール３８とのインタフェースが簡単になる。
【００７０】
なお、自モジュールがアプリケーション３２によって生成されたバッファモジュール４０である場合、すなわちバッファ４０Ａとして用いるメモリ領域が既に確保されている場合には、先に説明したステップ１１２〜ステップ１１６をスキップしてステップ１１８へ移行し、既に確保されたメモリ領域のアドレスを画像処理モジュール３８に書込領域のアドレスとして通知し、上記メモリ領域への画像データの書き込みを行わせる。
【００７１】
前段の画像処理モジュール３８による書込領域への画像データの書き込みが完了するとステップ１２４へ移行し、検出フラグが０か否か判定する。検出フラグは、書込領域に書き込まれた画像データに対して圧縮／非圧縮の検出を行うか否かを表すフラグであり、前述のように検出フラグには初期設定時に１が設定されるので、このときは判定が否定されてステップ１２６へ移行し、入力回数が０か否か判定する。入力回数はバッファモジュール４０が生成されてから現在迄に画像データが入力された回数を表す情報であり、前述のように入力回数には初期設定時に０が設定されるので、このときは判定が肯定されてステップ１２４へ移行し、前段の画像処理モジュール３８によって書込領域に書き込まれた画像データのサイズを検知し、検知したサイズを初回サイズとしてワークメモリ等に記憶させる。
【００７２】
次のステップ１２６では、入力回数を１だけインクリメントした後にステップ１４０へ移行し、書込用バッファ領域に書き込まれている画像データに属性情報を付加した後に、保管用バッファ領域にそのまま書き込む。なお、上記の属性情報としては、バッファモジュール４０で圧縮を行った画像データか否かを表す圧縮フラグや画像データのサイズ等の情報を用いることができ、ステップ１４０では、圧縮フラグとして０(非圧縮)を設定すると共に、画像データのサイズとして先に検知したサイズを設定した属性情報を画像データに付加することができる。
【００７３】
そしてステップ１４４では、自モジュールの後段の個々の画像処理モジュール３８に対応する有効データポインタのうち有効データの末尾位置を表すポインタを、該ポインタが指し示す有効データの末尾位置が単位書込データ量分だけ後へ移動するように更新する（図４(Ｃ)も参照）と共に、先に書込用バッファ領域として確保したメモリ領域をリソース管理部４６Ｂによって解放させ、データ書込処理を一旦終了する。なお、書込用バッファ領域はバッファモジュール４０の初期化時に確保し、バッファモジュール４０の消去時に解放するように構成してもよい。
【００７４】
上記のデータ書込処理は前段の画像処理モジュール３８から書込要求が入力される毎に実行されるが、前段の画像処理モジュール３８から最初に書込要求が入力された以降は入力回数が１以上の値となるので、ステップ１２２の判定が否定されてステップ１２８へ移行し、入力回数を１だけインクリメントする。また、ステップ１３０では前段の画像処理モジュール３８によって書込領域に書き込まれた画像データのサイズを検知し、検知したサイズがワークメモリ等に記憶されている初回サイズと一致しているか否か判定する。判定が肯定された場合はステップ１３２へ移行し、入力回数が所定値Ｎに達したか否か判定する。判定が否定された場合はステップ１４０へ移行し、前述のように書込用バッファ領域に書き込まれている画像データに、値０(非圧縮)が設定された圧縮フラグ及び画像データのサイズを含む属性情報を付加した後に、保管用バッファ領域にそのまま書き込む処理を行う。なお、空き領域有りの単位バッファ領域における空き領域のサイズが単位書込データ量よりも小さい場合、書込用バッファ領域に書き込まれた画像データは、図４(Ｃ)に示すように、保管用の複数の単位バッファ領域へ分けて書き込まれることになる。
【００７５】
前段の画像処理モジュール３８から書込要求がＮ＋１回入力される間、書込領域に書き込まれた画像データのサイズが初回サイズと毎回一致していた場合、前段の画像処理モジュール３８によって書込領域に書き込まれた画像データは非圧縮の画像データであると判断できる。このため、上記場合にはＮ＋１回目の書込要求が入力された時点でステップ１３２の判定が肯定され、ステップ１３４で圧縮フラグに１を設定する。なお、圧縮フラグは保管用の単位バッファ領域に書き込む画像データに対して圧縮処理を行うか否かを表すフラグであり、圧縮フラグ＝１は圧縮処理を行うことを意味し、圧縮フラグ＝０は圧縮処理を行わないことを意味している。また、ステップ１３６では検出フラグに０を設定し、次のステップ１３８では圧縮フラグが１か否か判定する。
【００７６】
判定が肯定された場合はステップ１４２へ移行し、書込用バッファ領域に書き込まれている画像データを所定の圧縮方式によって圧縮し、圧縮後の画像データに、圧縮フラグとして１(圧縮)を設定すると共に画像データのサイズとして先に検知したサイズ（圧縮前のサイズ）を設定した属性情報を付加し、属性情報を付加した圧縮画像データを保管用バッファ領域に書き込む。なお、ステップ１４２において、画像データの圧縮に際して適用した圧縮方式を表す情報も属性情報として付加するようにしてもよい。圧縮フラグに１が一旦設定されると、バッファモジュール４０が消去される迄の間、圧縮フラグは１のまま維持されるので、以降に前段の画像処理モジュール３８から出力された（書込領域に書き込まれた）画像データは全て圧縮された後に保管用バッファ領域に書き込まれることになる。また、検出フラグに０が設定されることで、以降に実行されるデータ書込処理ではステップ１２２〜ステップ１３６の処理がスキップされる。
【００７７】
このように、本実施形態に係るデータ書込処理では、前段の画像処理モジュール３８から出力される（書込領域に書き込まれる）画像データが非圧縮の画像データであった場合には、当該画像データに対して圧縮処理を行った後に保管用バッファ領域に書き込むので、保管用バッファ領域として確保すべきメモリ領域を節減できると共に、保管用バッファ領域への画像データの書き込み及び保管用バッファ領域からの画像データの読み出しに要する時間も短縮することができる。また、保管用バッファ領域に書き込む画像データの圧縮（及び保管用バッファ領域から読み出した画像データの伸長）を行うことで、これらの処理を行うＣＰＵ１２に負荷が加わることになるが、バッファ領域としてのメモリ等に対するアクセス速度に比してＣＰＵ１２の動作速度は高速であり、特に大サイズの画像データを扱う場合には、バッファ領域としてのメモリ等に対するアクセス速度が十分でないことが画像処理部５０における処理速度のボトルネックとなるので、上記のように画像データの圧縮（及び伸長）を行うことに伴って画像処理部５０における処理速度の低下が生ずることも回避できる。
【００７８】
また、前段の画像処理モジュール３８から書込要求がＮ＋１回入力される迄の間に、初回サイズと異なるサイズの画像データが書込領域に書き込まれた場合には、前段の画像処理モジュール３８によって書込領域に書き込まれた画像データは圧縮された画像データであると判断できる。この場合はステップ１３０の判定が否定されてステップ１３６へ移行し、検出フラグに０を設定してステップ１３８へ移行する（圧縮フラグに１を設定するステップ１３４がスキップされる）ので、ステップ１３８の判定が否定され、ステップ１４０において、書込用バッファ領域に書き込まれている画像データに対し、値０(非圧縮)が設定された圧縮フラグ及び画像データのサイズを含む属性情報を付加した後に、保管用バッファ領域にそのまま書き込む処理が行われる。従って、前段の画像処理モジュール３８から出力される画像データが既に圧縮された画像データであった場合には、当該画像データはそのまま保管用バッファ領域に書き込まれることになる。
【００７９】
続いて、後段の画像処理モジュール３８から読出要求がバッファモジュール４０に入力された場合（及び、後述するタイマがタイムアウトした場合）に、バッファモジュール４０の読出制御部４０Ｄによって実行されるデータ読出処理について、図５を参照して説明する。なお、以下で説明するデータ読出処理についても、関数やメソッドの呼び出しで処理が始まるようにしてもよい。なお、このデータ読出処理を行う読出制御部４０Ｄは本発明に係る読出手段（詳しくは請求項６に記載の読出手段）に対応している。
【００８０】
データ読出処理では、まずステップ１７０において、今回のデータ読出処理の起動要因が、後段の画像処理モジュールから読出要求を受信したことによる起動か否か判定する。判定が否定された場合はステップ１７４へ移行するが、上記判定が肯定された場合はステップ１７２へ移行し、後段の画像処理モジュールから今回受信した読出要求情報を読出用の待ち行列の末尾に登録する。ステップ１７４では、自モジュールのバッファ４０Ａが他のプロセス、スレッド又はオブジェクトによって使用中か否か判定する。バッファ４０Ａは書込制御部４０Ｃからもアクセスされるので、当該判定が肯定された場合はステップ２０８へ移行し、読出用の待ち行列に読出要求情報が登録されているか否か判定する。判定が否定された場合はデータ読出処理を終了するが、判定が肯定された場合はステップ２１０でタイマをスタートさせてデータ読出処理を一旦終了する。タイマをスタートさせた場合には、タイマがタイムアウトするとデータ読出処理が再度起動され、読出用の待ち行列に登録されている未処理の読出要求（情報）が再度取り出され、当該読出要求に応じた処理が行われる。
【００８１】
一方、ステップ１７４の判定が否定された場合にはステップ１７６へ移行し、読出用の待ち行列から先頭に登録されている読出要求情報を取り出す。次のステップ１７８では、読出用の待ち行列から取り出した読出要求情報に含まれる要求元識別情報に基づいて読出要求元の画像処理モジュール３８を認識し、読出要求元の画像処理モジュール３８によって設定された単位読出データ量を認識すると共に、読出要求元の画像処理モジュール３８に対応する有効データポインタに基づいて、読出要求元の画像処理モジュール３８に対応する有効データのバッファ４０Ａ上での先頭位置及び末尾位置を認識する。次のステップ１８０では、ステップ１７８で認識した有効データの先頭位置及び末尾位置に基づいて、読出要求元の画像処理モジュール３８に対応する有効データ（読出要求元の画像処理モジュール３８が読出可能な画像データ）が単位読出データ量以上有るか否か判定する。
【００８２】
なお、上記の有効データが書込制御部４０Ｃによって圧縮された画像データであった場合、読出制御部４０Ｄは、後述のように当該画像データに対して伸長処理を行った後に読出要求元の画像処理モジュール３８へ出力するので、上記のステップ１８０では、ステップ１７８で認識した有効データに付加されている属性情報のうち圧縮フラグを参照することで、有効データが書込制御部４０Ｃによって圧縮された画像データか否かを判定し、書込制御部４０Ｃによって圧縮された画像データであった場合は、属性情報のうちの画像データのサイズを参照することで伸長処理後の有効データのサイズを認識し、認識したサイズが単位読出データ量以上か否かを判定する。
【００８３】
ステップ１８０の判定が否定された場合はステップ１８２へ移行し、バッファ４０Ａに記憶されており読出要求元の画像処理モジュール３８が読出可能な有効データの末尾が処理対象の画像データの末尾か否か判定する。読出要求元の画像処理モジュール３８に対応する有効データがバッファ４０Ａに単位読出データ量以上記憶されているか、又は、バッファ４０Ａに記憶されている読出要求元の画像処理モジュール３８に対応する有効データが単位読出データ量未満であるものの、当該有効データの末尾が処理対象の画像データの末尾であった場合には、ステップ１８０又はステップ１８２の判定が肯定されてステップ１８４へ移行する。ステップ１８４では、確保すべきメモリ領域のサイズとして読出要求元の画像処理モジュール３８に対応する単位読出データ量をリソース管理部４６Ｂに通知すると共に、読出に用いるメモリ領域（読出用バッファ領域：図６(Ｂ)も参照）の確保をリソース管理部４６Ｂに要求する。
【００８４】
読出用バッファ領域を確保すると、次のステップ１８６では、読出対象の有効データに付加されている属性情報（の圧縮フラグ）を参照することで、読出対象の有効データが書込制御部４０Ｃによって圧縮された画像データであるか否か判定する。読出対象の有効データに付加されている属性情報の圧縮フラグに１が設定されていた場合には、上記判定が肯定されてステップ１８８へ移行し、読出対象の有効データを圧縮前のサイズが単位読出データ量に相当するサイズだけバッファ４０Ａから読み出し、読み出した有効データから属性情報を除去し、属性情報を除去した有効データに対して伸長処理を行うことで単位読出データ量分の非圧縮の画像データに戻した後に読出用バッファ領域に書き込む。また、読出対象の有効データに付加されている属性情報の圧縮フラグに０が設定されていた場合には、上記判定が否定されてステップ１９０へ移行し、読出対象の有効データをバッファ４０Ａから単位読出データ量分だけ読み出して属性情報を除去し、属性情報を除去した有効データをそのまま読出用バッファ領域に書き込む。
【００８５】
次のステップ１９２では、読出用バッファ領域の先頭アドレスを読出領域の先頭アドレスとして読出要求元の画像処理モジュール３８へ通知すると共に、通知した先頭アドレスから画像データを順に読み出すよう要請する。これにより、読出要求元の画像処理モジュール３８は、先頭アドレスが通知された読出領域（読出用バッファ領域）からの画像データの読み出しを行う。なお、読出対象の有効データが処理対象の画像データの末尾に相当するデータであった場合には、画像データの読出要求に際し、読出対象の画像データのサイズと共に、処理対象の画像データの末尾であることも読出要求元の画像処理モジュール３８に通知する。また、自モジュールがアプリケーション３２によって生成されたバッファモジュール４０である場合は、バッファ４０Ａとして用いているメモリ領域（単位バッファ領域の集合体）は連続領域であるので、読出用バッファ領域の確保、読出対象の画像データの読出用バッファ領域への書き込みを省略し、後段の画像処理モジュール３８が単位バッファ領域から直接画像データを読み出すようにしてもよい。
【００８６】
このように、読出対象の画像データが書込制御部４０Ｃによって圧縮された画像データであった場合には、当該画像データに対して伸長処理を行い読出用バッファ領域に書き込んだ後に、読出要求元の画像処理モジュール３８によって読み出させるので、バッファモジュール４０の後段の画像処理モジュール３８は、バッファモジュール４０の前段の画像処理モジュール３８からの出力画像データと同一の画像データを受け取る（出力画像データが圧縮された画像データであればバッファモジュール４０から圧縮された画像データを受け取り、出力画像データが非圧縮の画像データであればバッファモジュール４０から非圧縮の画像データを受け取る）ことになる。従って、個々の画像処理モジュール３８が、前段のバッファモジュール４０が画像データの圧縮を行ったか否かに応じて処理を切り替える必要がなくなるので、先にも説明したように、前段の画像処理モジュール３８から非圧縮の画像データが受け渡された場合に画像データの圧縮／伸長を行うようにバッファモジュール４０を構成したことに伴って、画像処理モジュール３８の構成が複雑化することも回避することができる。
【００８７】
また、例として図６(Ａ)に示すように、有効データの先頭部分の画像データを記憶している単位バッファ領域に記憶されている有効データのデータ量が単位読出データ量未満であり、読出対象の有効データが複数の単位バッファ領域に跨っている場合には、今回の読出対象の有効データが実メモリ（メモリ１４）上で連続する領域に記憶されているとは限らないが、上記のデータ読出処理では、図６(Ｂ),(Ｃ)に示すように、このような場合にも読出対象の画像データを読出用バッファ領域に一旦書き込んだ後に該読出用バッファ領域から画像データを読み出させるので、読出対象の画像データが複数の単位バッファ領域に跨って記憶されているか否かに拘わらず、読出要求元の画像処理モジュール３８への読出領域の通知は、上記のようにその先頭アドレスを通知するのみで済み、画像処理モジュール３８とのインタフェースが簡単になる。
【００８８】
次のステップ１９４では、読出要求元の画像処理モジュール３８による読出領域からの画像データの読み出しが完了したか否か判定し、判定が肯定される迄ステップ１９４を繰り返す。読出要求元の画像処理モジュール３８から読出完了が通知されると、ステップ１９４の判定が肯定されてステップ１９６へ移行し、読出用バッファ領域として確保したメモリ領域の先頭アドレス及びサイズをリソース管理部４６Ｂへ通知して、当該メモリ領域をリソース管理部４６Ｂによって解放させる。この読出用バッファ領域についても、バッファモジュール４０の初期化時に確保しておき、バッファモジュール４０が消去される時に解放するよう構成してもよい。またステップ１９８では、読出要求元の画像処理モジュール３８に対応する有効データポインタのうち有効データの先頭位置を表すポインタを、該ポインタが指し示す有効データの先頭位置を単位読出データ量分だけ後へ移動させることで更新する（図６(Ｃ)も参照）。
【００８９】
ステップ２００では、後段の個々の画像処理モジュール３８に対応する有効データポインタを各々参照し、ステップ１９８のポインタ更新により、バッファ４０Ａを構成する単位バッファ領域の中に、記憶している画像データの後段の各画像処理モジュール３８による読み出しが全て完了した単位バッファ領域、すなわち有効データを記憶していない単位バッファ領域が出現したか否か判定する。判定が否定された場合はステップ２０８へ移行し、前述のステップ２０８，２１０を経てデータ読出処理を終了するが、判定が肯定された場合はステップ２０２へ移行し、有効データを記憶していない単位バッファ領域をリソース管理部４６Ｂによって解放させた後にステップ２０８へ移行し、ステップ２０８，２１０を経てデータ読出処理を終了する。
【００９０】
一方、バッファ４０Ａに記憶されており読出要求元の画像処理モジュール３８が読出可能な有効データのデータ量が単位読出データ量未満であり、かつ読出可能な有効データの末尾が処理対象の画像データの末尾でない場合（図８(Ｂ)の(4)で読出可能な有効データ無が検知された場合）には、ステップ１８０，１８２の判定が各々否定されてステップ２０４へ移行し、新たな画像データを要求するデータ要求をワークフロー管理部４６Ａへ出力する（図８(Ｂ)の(5)も参照）。この場合、ワークフロー管理部４６Ａにより、自モジュールの前段の画像処理モジュール３８に処理要求が入力されることになる。またステップ２０６では、読出用の待ち行列から取り出した読出要求情報を元の待ち行列（の先頭又は末尾）に再度登録し、ステップ２０８，２１０を経てデータ読出処理を終了する。これにより、読出可能な有効データのデータ量が単位読出データ量以上になるか、読出可能な有効データの末尾が処理対象の画像データの末尾であることが検知される迄（ステップ１８０又はステップ１８２の判定が肯定される迄）の間、対応する読出要求情報は読出用の待ち行列に保存されると共に定期的に取り出されて要求された処理の実行が繰り返し試行されることになる。
【００９１】
詳細は後述するが、ワークフロー管理部４６Ａはバッファモジュール４０からデータ要求が入力されると、データ要求元のバッファモジュール４０の前段の画像処理モジュール３８に処理要求を入力する（図８(Ｂ)の(6)も参照）。この処理要求の入力をトリガとして前段の画像処理モジュール３８の制御部３８Ｂで行われる処理により、前段の画像処理モジュール３８がバッファモジュール４０へ画像データを書込可能な状態になると、前段の画像処理モジュール３８から書込要求が入力されることで前述したデータ書込処理（図３）が行われ、前段の画像処理モジュール３８からバッファモジュール４０のバッファ４０Ａに画像データが書き込まれる（図８(Ｂ)の(7),(8)も参照）。これにより、後段の画像処理モジュール３８によるバッファ４０Ａからの画像データの読出が行われることになる（図８(Ｂ)の(9)も参照）。
【００９２】
上述したデータ書込処理及びデータ読出処理では、一方が自モジュールのバッファ４０Ａにアクセスしている間、他方がバッファ４０Ａへのアクセスを停止する排他制御が行われる。これにより、コンピュータ１０のＣＰＵ１２が画像処理部５０を構成する個々のモジュールに対応するプロセス又はスレッドを並列に実行しても、単一のバッファモジュール４０に複数の要求が同時又は略同時に入力されることによる不都合の発生を回避できるので、コンピュータ１０のＣＰＵ１２が個々のモジュールに対応するプロセス又はスレッドを並列に実行することができる。もちろん、バッファモジュールを通常のプログラムまたはオブジェクトとして実現しても良い。
【００９３】
続いて、画像処理部５０を構成する個々の画像処理モジュール３８に対してワークフロー管理部４６Ａから処理要求が入力される毎に、個々の画像処理モジュール３８の制御部３８Ｂによって各々行われる画像処理モジュール制御処理（図７）を説明する。画像処理モジュール制御処理では、まずステップ２２０において、自モジュールの前段にモジュール（バッファモジュール４０や画像データ供給部２２、画像処理モジュール３８等）が存在している場合に、当該前段のモジュールに対してデータ（画像データ又は解析等の画像処理の処理結果）を要求する。次のステップ２２２では前段のモジュールからデータが取得可能であるかを判定し、ステップ２２２の判定が否定された場合はステップ２２４で全体処理終了が通知されたか否かを判定する。ステップ２２４の判定が否定された場合はステップ２２２に戻り、前段のモジュールからデータを取得可能となる迄ステップ２２２，２２４を繰り返す。ステップ２２２の判定が肯定された場合には、ステップ２２６で前段のモジュールからデータを取得するデータ取得処理を行う。
【００９４】
ここで、自モジュールの前段のモジュールがバッファモジュール４０である場合には、先のステップ２２０でデータを要求すると（読出要求）、読出可能な有効データがバッファモジュール４０のバッファ４０Ａに単位読出データ量以上記憶されているか、読出可能な有効データの末尾が処理対象の画像データの末尾に一致している状態であれば直ちに、当該状態でなければ、当該バッファモジュール４０の前段の画像処理モジュール３８が当該バッファモジュール４０のバッファ４０Ａに画像データを書き込んだことに伴って前記状態へ変化した後に、バッファモジュール４０から読出領域の先頭アドレスが通知されて画像データの読出が要請される（図５のステップ１９２も参照）。これにより、ステップ２２２の判定が肯定されてステップ２２６へ移行し、前段のバッファモジュール４０より先頭アドレスが通知された読出領域から単位読出データ量（又はそれ未満のデータ量）の画像データを読み出すデータ取得処理を行う（図８(Ａ)の(3)も参照）。
【００９５】
また、自モジュールの前段のモジュールが画像データ供給部２２であれば、先のステップ２２０でデータ要求を出力すると画像データを取得可能な状態であることが前段の画像データ供給部２２から直ちに通知されることで、ステップ２２２の判定が肯定されてステップ２２６へ移行し、前段の画像データ供給部２２から単位読出データ量の画像データを取得する画像データ取得処理を行う。また、自モジュールの前段のモジュールが画像処理モジュール３８であれば、先のステップ２２０でデータ要求（処理要求）を出力すると、前段の画像処理モジュール３８が画像処理を実行可能な状態であれば書込要求が入力されることでデータ（画像処理結果）を取得可能な状態であることが通知されるので、ステップ２２２の判定が肯定されてステップ２２６へ移行し、前段の画像処理モジュール３８によってデータを書き込ませるバッファ領域のアドレスを通知して書込を要請することで、前段の画像処理モジュール３８から出力されるデータを前記バッファに書き込ませるデータ取得処理を行う。
【００９６】
次のステップ２２８では、自モジュールの前段に複数のモジュールが連結されているか否か判定する。判定が否定された場合には何ら処理を行うことなくステップ２３２へ移行するが、判定が肯定された場合はステップ２３０へ移行し、前段に連結されている全てのモジュールからデータを取得したか否か判定する。ステップ２３０の判定が否定された場合はステップ２２０に戻り、ステップ２３０の判定が肯定される迄ステップ２２０〜ステップ２３０を繰り返す。前段のモジュールから取得すべきデータが全て揃うと、ステップ２２８の判定が否定されるかステップ２３０の判定が肯定されてステップ２３２へ移行する。
【００９７】
次に、ステップ２３２で自モジュールの後段のモジュールに対してデータ出力用の領域を要求し、ステップ２３２でデータ出力領域が取得できる迄（データ出力領域の先頭アドレスが通知される迄）繰り返し判定を行う。なお、後段のモジュールがバッファモジュール４０であれば、上記のデータ出力用領域の要求は当該バッファモジュール４０に対して書込要求を出力することによって成される。データ出力領域（後段のモジュールがバッファモジュール４０であれば当該バッファモジュール４０から先頭アドレスが通知された書込領域）が取得できたら（図８(Ａ)の(4)も参照）、次のステップ２３６において、先のデータ取得処理で取得したデータと後段のモジュールから取得したデータ出力領域（の先頭アドレス）を画像処理エンジン３８Ａに入力し、入力したデータに対して所定の画像処理を行わせる（図８(Ａ)の(5)も参照）と共に、処理後のデータをデータ出力領域に書き込ませる（図８(Ａ)の(6)も参照）。画像処理エンジン３８Ａへの単位読出データ量のデータの入力が完了し、画像処理エンジン３８Ａから出力されたデータがデータ出力領域に全て書き込まれると、次のステップ２３８で出力が完了したことを後段のモジュールに通知する。
【００９８】
上記のステップ２２０〜ステップ２３８により画像処理モジュール３８における単位処理データ量のデータに対する処理（単位処理）が完了するが、ワークフロー管理部４６Ａから画像処理モジュール３８に入力される処理要求では、ワークフロー管理部４６Ａによって単位処理の実行回数が指定されることがある。このためステップ２４０では、単位処理の実行回数が、入力された処理要求によって指示された実行回数に達したか否か判定する。指示された単位処理の実行回数が１回の場合、この判定は無条件に肯定されるが、指示された単位処理の実行回数が２回以上の場合はステップ２２０に戻り、ステップ２４０の判定が肯定される迄ステップ２２０〜ステップ２４０を繰り返す。ステップ２４０の判定が肯定されるとステップ２４２へ移行し、ワークフロー管理部４６Ａへ処理完了通知を出力することで、入力された処理要求に対応する処理が完了したことをワークフロー管理部４６Ａへ通知し、画像処理モジュール制御処理を終了する。
【００９９】
また、ワークフロー管理部４６Ａから処理要求が入力される毎に上述した処理が繰り返されることで処理対象の画像データを末尾まで処理すると、前段のモジュールから処理対象の画像データの終了が通知されることで、ステップ２２４の判定が肯定されてステップ２４４へ移行し、処理対象の画像データ（なお、処理対象の画像データは１頁分の画像データであることが多いが、複数頁分の画像データであってもよい）に対する処理が終了したことを意味する全体処理終了通知をワークフロー管理部４６Ａ及び後段のモジュールへ各々出力する。また、次のステップ２４６では自モジュール消去処理（後述）を行い、画像処理モジュール制御処理を終了する。
【０１００】
一方、ワークフロー管理部４６Ａは、アプリケーション３２によって起動されると、図９(Ａ)に示すブロック単位制御処理１を行う。先にも述べたように、ワークフロー管理部４６Ａによる画像処理部５０の個々の画像処理モジュール３８への処理要求の入力では、単位処理の実行回数を指定可能とされているが、ブロック単位制御処理１のステップ５００では、１回の処理要求で指定する単位処理の実行回数を個々の画像処理モジュール３８毎に決定する。この処理要求１回当りの単位処理の実行回数は、例えば処理対象の画像データ全体を処理する間の個々の画像処理モジュール３８への処理要求の入力回数が平均化されるように定めることができるが、他の基準に従って定めてもよい。そして次のステップ５０２において、画像処理部５０のうち最後段の画像処理モジュール３８に処理要求を入力し（図１０の(1)も参照）、ブロック単位制御処理１を終了する。
【０１０１】
ここで、図１０に示す画像処理部５０において、ワークフロー管理部４６Ａから最後段の画像処理モジュール３８4に処理要求が入力されると、画像処理モジュール３８4の制御部３８Ｂは前段のバッファモジュール４０3に読出要求を入力する（図１０の(2)参照）。このとき、バッファモジュール４０3のバッファ４０Ａには画像処理モジュール３８4が読出可能な有効データ（画像データ）が記憶されていないので、バッファモジュール４０3のバッファ制御部４０Ｂはワークフロー管理部４６Ａにデータ要求を入力する（図１０の(3)参照）。
【０１０２】
ワークフロー管理部４６Ａは、画像処理の実行形態がブロック単位処理である場合、バッファモジュール４０からデータ要求が入力される毎に、図９(Ｂ)に示すブロック単位制御処理２を行う。このブロック単位制御処理２では、ステップ５０４において、データ要求入力元のバッファモジュール４０（ここではバッファモジュール４０3）の前段の画像処理モジュール３８（ここでは画像処理モジュール３８3）を認識し、認識した前段の画像処理モジュール３８に処理要求を入力（図１０の(4)参照）して処理を終了する。
【０１０３】
画像処理モジュール３８3の制御部３８Ｂは、処理要求が入力されると前段のバッファモジュール４０2に読出要求を入力し（図１０の(5)参照）、バッファモジュール４０2のバッファ４０Ａにも読出可能な画像データが記憶されていないので、バッファモジュール４０2のバッファ制御部４０Ｂはワークフロー管理部４６Ａにデータ要求を入力する（図１０の(6)参照）。ワークフロー管理部４６Ａは、バッファモジュール４０2からデータ要求が入力された場合も、前述のブロック単位制御処理２を再度行うことで、その前段の画像処理モジュール３８2に処理要求を入力し（図１０の(7)参照）、画像処理モジュール３８3の制御部３８Ｂは前段のバッファモジュール４０1に読出要求を入力する（図１０の(8)参照）。また、バッファモジュール４０1のバッファ４０Ａにも読出可能な画像データが記憶されていないので、バッファモジュール４０1のバッファ制御部４０Ｂもワークフロー管理部４６Ａにデータ要求を入力し（図１０の(9)参照）。ワークフロー管理部４６Ａは、バッファモジュール４０1からデータ要求が入力された場合も、前述のブロック単位制御処理２を再度行うことで、その前段の画像処理モジュール３８1に処理要求を入力する（図１０の(10)参照）。
【０１０４】
ここで、画像処理モジュール３８1の前段のモジュールは画像データ供給部２２であるので、画像処理モジュール３８1の制御部３８Ｂは、画像データ供給部２２にデータ要求を入力することで画像データ供給部２２から単位読出データ量の画像データを取得し（図１０の(11)参照）、取得した画像データに対して画像処理エンジン３８Ａが画像処理を行うことで得られた画像データを、後段のバッファモジュール４０1のバッファ４０Ａに書き込む（図１０の(12)参照）。なお、画像処理モジュール３８1の制御部３８Ｂは後段のバッファモジュール４０1のバッファ４０Ａへの画像データの書き込みを完了すると、ワークフロー管理部４６Ａへ処理完了通知を入力する。
【０１０５】
ワークフロー管理部４６Ａは、画像処理の実行形態がブロック単位処理である場合、画像処理モジュール３８から処理完了通知が入力される毎に、図９(Ｃ)に示すブロック単位制御処理３を行う。このブロック単位制御処理３では、ステップ５０６において、処理完了通知元が画像処理部５０の最後段の画像処理モジュール３８か否か判定する。この場合は判定が否定され、何ら処理を行うことなく処理を終了する（画像処理モジュール３８2，３８3から処理完了通知が入力された場合についても同様）。
【０１０６】
また、バッファモジュール４０1のバッファ制御部４０Ｂは、後段の画像処理モジュール３８2が読出可能な単位読出データ量以上の有効データが書き込まれると画像処理モジュール３８2に対して読出を要請し、これに伴い画像処理モジュール３８2の制御部３８Ｂは、バッファモジュール４０1のバッファ４０Ａから単位読出データ量の画像データを読み出し（図１０の(13)参照）、取得した画像データに対して画像処理エンジン３８Ａが画像処理を行うことで得られた画像データを、後段のバッファモジュール４０2のバッファ４０Ａに書き込む（図１０の(14)参照）。バッファモジュール４０2のバッファ制御部４０Ｂは、後段の画像処理モジュール３８3が読出可能な単位読出データ量以上の有効データが書き込まれると画像処理モジュール３８3へ読出を要請し、画像処理モジュール３８3の制御部３８Ｂは、バッファモジュール４０2のバッファ４０Ａから単位読出データ量の画像データを読み出し（図１０の(15)参照）、取得した画像データに対して画像処理エンジン３８Ａが画像処理を行うことで得られた画像データを、後段のバッファモジュール４０3のバッファ４０Ａに書き込む（図１０の(16)参照）。
【０１０７】
更に、バッファモジュール４０3のバッファ制御部４０Ｂは、後段の画像処理モジュール３８4が読出可能な単位読出データ量以上の有効データが書き込まれると画像処理モジュール３８4に対して読出を要請し、これに伴い画像処理モジュール３８4の制御部３８Ｂは、バッファモジュール４０3のバッファ４０Ａから単位読出データ量の画像データを読み出し（図１０の(17)参照）、取得した画像データに対して画像処理エンジン３８Ａが画像処理を行うことで得られた画像データを、後段のモジュールである画像出力部２４へ出力する（図１０の(18)参照）。また、画像処理モジュール３８4の制御部３８Ｂは後段の画像出力部２４への画像データの書き込みを完了すると、ワークフロー管理部４６Ａへ処理完了通知を入力する（図１０の(19)参照）が、この場合は前述のブロック単位制御処理３のステップ５０６の判定が肯定されてステップ５０８へ移行し、最後段の画像処理モジュール３８である画像処理モジュール３８4に処理要求を再度入力した後に処理を終了する。
【０１０８】
この最後段の画像処理モジュール３８4への処理要求の再入力により、上述した処理シーケンスが再度繰り返され、処理対象の画像データに対し、ブロック単位の実行形態での画像処理が順次行われることになる。画像データ供給部２２から供給される画像データが処理対象の画像データの末尾に達すると、個々の画像処理モジュール３８からワークフロー管理部４６Ａへの全体処理終了通知の入力が、前段側の画像処理モジュール３８から順次行われる。
【０１０９】
ワークフロー管理部４６Ａは、画像処理の実行形態がブロック単位処理である場合、画像処理モジュール３８から全体処理終了通知が入力される毎に、図９(Ｄ)に示すブロック単位制御処理４を行う。このブロック単位制御処理４では、ステップ５１０において、全体処理終了通知入力元の画像処理モジュール３８が最後段の画像処理モジュール３８か否か判定する。判定が否定された場合は何ら処理を行うことなく処理を終了するが、処理対象の画像データに対して必要な画像処理が行われた画像データが画像出力部２４へ全て出力されることで、最後段の画像処理モジュール３８から全体処理終了通知が入力された場合には、ステップ５１０の判定が肯定されてステップ５１２へ移行し、アプリケーション３２に対して画像処理の完了を通知し、ブロック単位制御処理を終了する。そして、画像処理の完了が通知されたアプリケーション３２は、ユーザに対して画像処理の完了を通知する。
【０１１０】
このように、ブロック単位処理では、最後段の画像処理モジュール３８に入力された処理要求がより前段の画像処理モジュール３８へ遡り、最前段の画像処理モジュール３８に到達すると、最前段の画像処理モジュール３８で画像処理が行われて後段のバッファモジュール４０にデータが書き込まれ、それでデータが足りるようならば処理が後段のモジュールへ進んで行くという流れで一連の画像処理が行われる。
【０１１１】
なお、ブロック単位処理における処理シーケンスは上記に限られるものではなく、バッファモジュール４０からデータ要求が入力される毎に、データ要求入力元のバッファモジュール４０に処理要求を入力することに代えて、まずブロック単位制御処理１で全ての画像処理モジュール３８に処理要求を各々入力し、特定の画像処理モジュールから全体処理完了通知が入力される迄の間、特定の画像処理モジュール３８から処理完了通知が入力される毎に、処理完了通知入力元の特定の画像処理モジュール３８に処理要求を再入力する処理を、全ての画像処理モジュールに対して各々行うようにしてもよい。
【０１１２】
また、上記では最後段の画像処理モジュール３８への処理要求の入力はワークフロー管理部４６Ａが行うものとして説明したが、本発明はこれに限定されるものではなく、パイプラインの最後段又は有向非循環グラフの複数の終点に位置するモジュールをワークフロー管理部４６Ａが保持して処理要求を行っても、またはアプリケーション３２が保持して処理要求を行っても良い。或いは、前述した図２(Ｂ)の例のように、モジュール生成部４４の内部で、スキュー角検知処理を行う画像処理モジュールと、画像回転処理を行う画像処理モジュールとを組み合わせて、スキュー補正処理モジュールとするような場合には、画像回転処理モジュールの生成時に処理パラメータとしてスキュー角情報が必要なので、スキュー補正モジュール生成部の内部で、スキュー角検知処理モジュールに処理要求を繰り返し行って画像全体を処理し、その結果得られるスキュー角情報を画像回転処理モジュールに処理パラメータとして与えるといった方式も存在する。
【０１１３】
続いて、処理対象の画像データに対する画像処理を完了した後に行われる画像処理部５０の消去について説明する。個々の画像処理モジュール３８の制御部３８Ｂは、画像処理モジュール制御処理（図７）のステップ２４４で、ワークフロー管理部４６Ａ及び後段のモジュールへ全体処理終了通知を出力した後に、次のステップ２４６で自モジュールを消去する。具体的には、先に確保したメモリ領域をリソース管理部４６Ｂによって解放させると共に、リソース管理部４６Ｂを通じて自モジュールが確保したメモリ以外のリソースが有れば、当該リソースをリソース管理部４６Ｂによって解放させ、自モジュールの前段のモジュール、後段のモジュール及びワークフロー管理部４６Ａに対し、自モジュールを消去する処理を行うことを通知するための消去通知を入力した後に、自モジュールを消去する処理が行われる。なお、自モジュールを消去することは、自モジュールに対応するプロセス、スレッドを終了するか、又はオブジェクトを削除することで実現することができる。
【０１１４】
一方、バッファモジュール４０の書込制御部４０Ｃによって実行されるデータ書込処理（図３）では、自モジュールの前段又は後段の画像処理モジュール３８から消去通知が入力されると、ステップ１０４の判定が肯定されてステップ１４６へ移行し、消去通知入力元のモジュールを記憶した後に、自モジュールの前段及び後段の全てのモジュールから消去通知が入力されたか否か判定する。判定が否定された場合はデータ書込処理を一旦終了する。また、自モジュールの前段及び後段の全てのモジュールから消去通知が入力されると、ステップ１４６の判定が肯定されてステップ１４８へ移行し、ワークフロー管理部４６Ａに対して消去通知を入力することで、自モジュールを消去する処理を行うことを通知する。そして次のステップ１５０で自モジュールを消去する処理を行ってデータ書込処理を終了する。
【０１１５】
なお、上記ではデータ書込処理（図３）において、前段の画像処理モジュール３８から入力された画像データが非圧縮であった場合に一律に圧縮処理を行う態様を説明したが、本発明はこれに限定されるものではなく、前段の画像処理モジュール３８からの画像データの入力時にバッファモジュール４０のバッファ４０Ａとして使用可能なメモリ１４等のシステムリソースの空き容量（或いは、バッファモジュール４０の生成時に所定容量のメモリ１４をバッファ４０Ａとして予め割り当てる場合はバッファ４０Ａの空き容量）を検知し、検知した空き容量が所定値以上であれば、入力された画像データが非圧縮であっても圧縮処理を行うことなくバッファ４０Ａにそのまま書き込むようにしてもよい。この態様では、入力された画像データを記憶するために必要なバッファ４０Ａの容量は増大するものの、データ書込処理（圧縮処理）やデータ読出処理（伸長処理）を行うＣＰＵ１２に加わる負荷を軽減することができる。なお、上記態様は請求項４記載の発明に対応している。
【０１１６】
また、上記ではバッファモジュール４０のバッファ４０Ａとして使用可能なシステムリソースとしてメモリ１４を例に説明したが、本発明はこれに限定されるものではなく、メモリ以外にＨＤＤやフラッシュメモリ、通信回線を介してコンピュータ１０に接続された各種の外部記憶デバイスをバッファ４０として用いることも可能である。また、バッファモジュール４０のバッファ４０Ａとして使用する記憶デバイスを、上記のような複数種の記憶デバイスの中から選択可能に構成した場合、バッファ４０Ａに対するアクセス速度が、バッファ４０Ａとして使用する記憶デバイスの種類や、記憶デバイスとの間の通信回線の回線速度等の環境によって変化することになる。これを考慮すると、前段の画像処理モジュール３８から非圧縮の画像データが入力された際に、当該画像データを書き込むバッファ４０Ａがアクセス速度が第１所定値以上の記憶デバイス（例えばメモリ１４等の高速の記憶デバイス）で構成されている場合や、バッファ４０Ａとの間のデータ転送速度が第２所定値以上となる環境の場合（例えばバッファ４０Ａが高速の記憶デバイスから成り、かつバッファ４０Ａとの間に高速の通信回線が介在している場合）には、入力された非圧縮の画像データを圧縮せずにバッファ４０Ａにそのまま書き込み、画像データを書き込むバッファ４０Ａがアクセス速度が第１所定値未満の記憶デバイス（例えばフラッシュメモリや外部記憶デバイス等の低速の記憶デバイス）で構成されている場合や、バッファ４０Ａとの間のデータ転送速度が第２所定値未満となる環境の場合（例えばバッファ４０Ａが低速の記憶デバイスで構成されているか、バッファ４０Ａとの間に低速の通信回線が介在している場合）には、入力された非圧縮の画像データを圧縮した後にバッファ４０Ａに書き込むようにしてもよい。これにより、バッファ４０Ａに対するアクセス速度が低速である場合に画像処理部５０における処理速度の大幅な低下を引き起こすことを防止できると共に、ＣＰＵ１２に必要以上に負荷が加わることも防止することができる。なお、上記事項は請求項５記載の発明に対応している。
【０１１７】
また、上記では後段の画像処理モジュール３８から読出要求が入力された際の読出対象の画像データが、データ書込処理によって圧縮された画像データであった場合に、当該画像データをバッファ４０Ａから読み出して伸長した後に読出要求元の画像処理モジュール３８へ引き渡すようにしていたが、本発明はこれに限定されるものではない。例えば画像処理モジュール３８の構成としては、前段のモジュールから取得した圧縮画像データに対して伸長処理を行った後に画像処理を行う機能を備えた構成や、前段のモジュールから取得した圧縮画像データに対して伸長処理を行うことなく画像処理を行う機能を備えた構成、すなわち圧縮された画像データを入力可能な構成も考えられるので、後段の画像処理モジュール３８が上記のような構成である場合には、読出対象の画像データがデータ書込処理によって圧縮された画像データであったとしても、当該画像データに対して伸長処理を行うことなく圧縮方式を表す情報を属性情報として付加して後段の画像処理モジュール３８へ受け渡すようにしてもよい。この場合、データ読出処理を行うＣＰＵ１２に加わる負荷を軽減することができる。なお、上記事項は請求項７記載の発明に対応している。
【０１１８】
また、画像データの圧縮方式としては様々な方式が存在しているが、後段の画像処理モジュール３８が圧縮された画像データを入力可能な構成であったとしても、後段の画像処理モジュール３８が取扱可能な画像データの圧縮形式は限られている可能性が高いので、バッファモジュール４０の初期設定時に後段の画像処理モジュール３８が取扱可能な圧縮形式を認識し、データ書込処理において、初期設定時に認識した圧縮形式で画像データの圧縮を行うようにしてもよい。
【０１１９】
更に、上記で説明したデータ書込処理では、検出フラグに０が設定される迄の間（前段の画像処理モジュール３８から画像データがＮ＋１回入力される迄の間）、入力された画像データを圧縮せずにバッファ領域に書き込むので、前段の画像処理モジュール３８から入力される画像データが非圧縮の画像データであったとしても、当該画像データの先頭部分（先頭から単位書込データ量×(Ｎ＋１)に相当するサイズの部分）は圧縮されずにバッファ領域に書き込まれることになるが、本発明はこれに限定されるものではなく、例えば書込用バッファ領域のサイズを、単位書込データ量×(Ｎ＋１)に相当するサイズの画像データを書込可能なサイズとし、入力された画像データの圧縮／非圧縮を判断する迄の間は入力された画像データを書込用バッファ領域に蓄積し、入力された画像データが圧縮されていると判断した場合は書込用バッファ領域に蓄積した画像データをそのまま保管用のバッファ領域に書き込み、入力された画像データが非圧縮であると判断した場合は書込用バッファ領域に蓄積した画像データを全て圧縮した後に保管用のバッファ領域に書き込むようにしてもよい。
【０１２０】
また、上記では、後段の画像処理モジュール３８からバッファモジュール４０に読出要求が入力されたものの、読出要求元の画像処理モジュール３８が読出可能な有効データのデータ量が単位読出データ量未満であり、かつ読出可能な有効データの末尾が処理対象の画像データの末尾でない場合に、読出可能な有効データのデータ量が単位読出データ量以上になるか、読出可能な有効データの末尾が処理対象の画像データの末尾であることが検知される迄、バッファモジュール４０からワークフロー管理部４６Ａへデータ要求が繰り返し入力される例を説明したが、これに限定されるものではなく、上記場合にバッファモジュール４０はワークフロー管理部４６Ａへデータ要求を１回のみ入力すると共に、読出可能な有効データのデータ量が単位読出データ量以上になるか、読出可能な有効データの末尾が処理対象の画像データの末尾であることが検知されるとワークフロー管理部４６Ａへ蓄積完了通知を入力し、ワークフロー管理部４６Ａはバッファモジュール４０からデータ要求が入力されてから蓄積完了通知が入力される迄の間、前記バッファモジュール４０の前段の画像処理モジュール３８へ処理要求を繰り返し入力するようにしてもよい。
【０１２１】
また、上記ではバッファモジュール４０において、後段の画像処理モジュール３８から読出要求が入力され、読出要求元の画像処理モジュール３８が読出可能な有効データが自モジュールのバッファ４０Ａに記憶されていなかった場合に、バッファ制御部４０Ｂがワークフロー管理部４６Ａへデータ要求を入力する態様を例に説明したが、これに限定されるものではなく、上記場合にバッファ制御部４０Ｂが前段の画像処理モジュール３８へデータ要求を直接入力するようにしてもよい。この態様で画像処理の実行形態がブロック単位処理の場合の処理シーケンスを図１１に示す。図１１からも明らかなように、この態様において、ワークフロー管理部４６Ａは画像処理部５０のうち最後段の画像処理モジュール３８についてのみ処理要求を入力すれば済むので、ワークフロー管理部４６Ａにおける処理が簡単になる。
【０１２２】
更に、上記ではブロック単位の画像処理の一例として、まずワークフロー管理部４６Ａが画像処理部５０の最後段の画像処理モジュール３８へ処理要求を入力し、この処理要求がデータ要求又は処理要求として順次前段のモジュールへ伝達される態様を説明したが、これに限定されるものではなく、処理要求又はデータ要求を前段のモジュールから後段のモジュールへ順次伝達させてブロック単位の画像処理を行わせることも可能である。これは、例えばバッファモジュール４０のバッファ制御部４０Ｂを、自モジュールの前段の画像処理モジュール３８によってバッファ４０Ａに画像データが書き込まれる毎に、後段の画像処理モジュール３８が読出可能な有効データのデータ量が単位読出データ量未満で、かつ読出可能な有効データの末尾が処理対象の画像データの末尾でなければワークフロー管理部４６Ａへデータ要求を入力する一方、読出可能な有効データのデータ量が単位読出データ量以上になるか、読出可能な有効データの末尾が処理対象の画像データの末尾であることが検知されるとワークフロー管理部４６Ａへ蓄積完了通知を入力するように構成すると共に、ワークフロー管理部４６Ａを、画像処理部５０の最後段の画像処理モジュール３８へ処理要求を入力した後に、任意のバッファモジュール４０からデータ要求が入力される毎に、データ要求元のバッファモジュール４０の前段の画像処理モジュール３８に処理要求を入力し、任意のバッファモジュール４０から蓄積完了通知が入力される毎に、当該バッファモジュール４０の後段の画像処理モジュール３８に処理要求を入力するように構成することで実現することができる。また、上記において、バッファモジュール４０からのデータ要求を当該バッファモジュール４０の前段の画像処理モジュール３８へ処理要求として直接入力させると共に、バッファモジュール４０からの蓄積完了通知を当該バッファモジュール４０の後段の画像処理モジュール３８へ処理要求として直接入力させるようにしてもよい。
【０１２３】
また、上記ではバッファモジュール４０に対し、前段の画像処理モジュール３８からは単位書込データ量が、後段の画像処理モジュールからは単位読出データ量が事前に設定される態様を説明したが、これに限定されるものではなく、バッファモジュール４０へのデータの書込やバッファモジュール４０からのデータの読出の都度、書込又は読出のデータ量が画像処理モジュール３８から通知されるようにしてもよい。
【０１２４】
また、上記では、バッファモジュール４０に書込要求又は読出要求が入力される毎に、入力された要求を要求情報として待ち行列に登録し、待ち行列から要求情報を１つづつ取り出して処理することで、書込要求入力時にバッファ４０Ａからのデータの読出を実行中であれば、このデータ読出が完了した後に前記書込要求に対応するデータ書込処理を行うと共に、読出要求入力時にバッファ４０Ａへのデータの書込を実行中であれば、このデータ書込が完了した後に前記読出要求に対応するデータ読出処理を行う排他制御を実現していたが、これに限定されるものではなく、例えば単位バッファ領域を単位とする排他制御、すなわち書込要求入力時に、バッファ４０Ａのうち当該書込要求における書込対象の単位バッファ領域に対してデータの読出を実行中であれば、このデータ読出が完了した後に前記書込要求に対応するデータ書込処理を行うと共に、読出要求入力時に、バッファ４０Ａのうち当該読出要求における読出対象の単位バッファ領域に対してデータの書込を実行中であれば、このデータ書込が完了した後に前記読出要求に対応するデータ読出処理を行うようにしてもよい。単位バッファ領域を単位とする排他制御は、例えば個々の単位バッファ領域毎に待ち行列を設けて排他制御を行うことや、排他制御に利用可能な公知のmutex(MUTualEXclusionservice)等の技術を利用する等によって実現することができる。
【０１２５】
更に、画像処理部５０を構成する個々のモジュールの実体はプログラムであるので、画像処理部５０による画像処理は実際にはＣＰＵ１２によって実行されるが、ここで、画像処理部５０を構成する個々の画像処理モジュール３８に相当するプログラムを、ＣＰＵ１２による実行対象のプロセス、スレッド又はオブジェクトとして待ち行列に登録し、当該待ち行列に登録した特定の画像処理モジュールに相当するプログラムがＣＰＵ１２によって前記待ち行列から取り出される毎に、特定の画像処理モジュール３８の前段のモジュールから単位処理データ量の画像データを取得可能か否かを判断し、単位処理データ量の画像データを取得可能と判断した場合にのみ、前記特定の画像処理モジュール３８の前段の前段のモジュールから単位処理データ量の画像データを取得し、取得した単位処理データ量の画像データに対して所定の画像処理（特定の画像処理モジュール３８の画像処理エンジン３８Ａに相当する処理）を行い、所定の画像処理を経た画像データ又は所定の画像処理の処理結果を自モジュールの後段のモジュールへ出力する処理を行った後に、処理対象の画像全体に対する処理が終了していなれば、取り出した特定の画像処理モジュールに相当するプログラムを実行対象のプロセス、スレッド又はオブジェクトとして前記待ち行列に再登録する単位画像処理をＣＰＵ１２によって繰り返させることで、画像処理部５０によって処理対象の画像全体を処理させるようにしてもよい（ラウンドロビン方式）。
【０１２６】
また、上記では画像処理部の個々の画像処理モジュール３８が、画像１面分よりも小さいデータ量を単位として後段へ画像データを引き渡しながら並列に画像処理を行うように動作させることで、画像処理部が全体としてブロック単位処理を行うようにワークフロー管理部４６Ａが制御する態様を説明したが、これに限定されるものではなく、画像処理部の個々の画像処理モジュール３８が、前段の画像処理モジュール３８が画像１面分の画像データに対する画像処理を完了した後に、後段の画像処理モジュール３８が画像１面分の画像データに対する画像処理を行うように動作させることで、画像処理部が全体として面単位処理を行うことも可能なように、ワークフロー管理部４６Ａを構成してもよい。
【図面の簡単な説明】
【０１２７】
【図１】本実施形態に係るコンピュータ（画像処理装置）の概略構成を示すブロック図である。
【図２】画像処理部の構成例を示すブロック図である。
【図３】バッファモジュールの書込制御部によって実行されるデータ書込処理の内容を示すフローチャートである。
【図４】書込対象の画像データが複数の保管用単位バッファ領域に跨る場合を説明する概略図である。
【図５】バッファモジュールの読出制御部によって実行されるデータ読出処理の内容を示すフローチャートである。
【図６】読出対象の画像データが複数の保管用単位バッファ領域に跨っていた場合を説明する概略図である。
【図７】画像処理モジュールの制御部によって実行される画像処理モジュール制御処理の内容を示すフローチャートである。
【図８】(Ａ)は画像処理モジュール、(Ｂ)はバッファモジュールの概略構成及び実行される処理を各々示すブロック図である。
【図９】処理管理部によって実行されるブロック単位制御処理の内容を示すフローチャートである。
【図１０】画像処理部における画像処理の流れを説明する概略図である。
【図１１】バッファモジュールが前段の画像処理モジュールに画像データを直接要求する態様におけるブロック単位処理の流れを説明する概略図である。
【符号の説明】
【０１２８】
１０ コンピュータ
１２ ＣＰＵ
１４ メモリ
２０ 記憶部
２２ 画像データ供給部
２４ 画像出力部
３８ 画像処理モジュール
３８Ａ 画像処理エンジン
３８Ｂ 制御部
４０ バッファモジュール
４０Ａ バッファ
４０Ｂ バッファ制御部
４０Ｃ 書込制御部
４０Ｄ 読出制御部
４６ 処理管理部
４６Ａ ワークフロー管理部
４６Ｂ リソース管理部
５０ 画像処理部
【特許請求の範囲】
【請求項１】
自モジュールの前段から単位データ量ずつ画像データを取得し、取得した画像データに対して所定の画像処理を行い、前記所定の画像処理を経た画像データ又は前記所定の画像処理の処理結果を自モジュールの後段へ出力する機能を各々備え、実行する画像処理の種類又は内容が互いに異なる複数種の画像処理モジュールの中から選択された１つ以上の画像処理モジュールと、
画像データを記憶するためのバッファを備えた１つ以上のバッファモジュールと、
が、前記選択された個々の画像処理モジュールの前段及び後段の少なくとも一方にバッファモジュールが連結されるように、個々のモジュールがパイプライン形態又は有向非循環グラフ形態で連結されて構築された画像処理部を備えた画像処理装置であって、
前記バッファモジュールは、
前段のモジュールから書込対象の画像データが入力された場合に、入力された画像データが圧縮されているか否かに応じて書込方法を切り替えて前記画像データを前記バッファに書き込む書込手段と、
後段のモジュールから画像データが要求された場合に、前記バッファから画像データを読み出し、読み出した画像データが圧縮されているか否かに応じて出力方法を切り替えて前記画像データを後段のモジュールへ出力する読出手段と、
を備えていることを特徴とする画像処理装置。
【請求項２】
前記書込手段は、前段のモジュールから入力された書込対象の画像データが圧縮されているか否か判断し、圧縮されていると判断した場合は前記画像データを前記バッファにそのまま書き込み、圧縮されていないと判断した場合は前記画像データに対して圧縮処理を行った後に前記バッファに書き込むことを特徴とする請求項１記載の画像処理装置。
【請求項３】
前記バッファモジュールの前段のモジュールから前記バッファモジュールへの画像データの入力は、画像を構成する所定の単位領域毎に分けて行われ、
前記書込手段は、前記単位領域のデータが前段のモジュールから所定回入力される間、入力された前記単位領域のデータのサイズを相互に比較し、入力された所定数の単位領域のデータのサイズが一定の場合は前段のモジュールから入力される画像データが圧縮されていないと判断し、前記所定数の単位領域のデータのサイズが一定でない場合は前段のモジュールから入力される画像データが圧縮されていると判断することを特徴とする請求項１又は請求項２記載の画像処理装置。
【請求項４】
前記書込手段は、前記バッファの空き容量又は前記バッファとして使用可能なシステムリソースの空き容量が所定値以上の場合には、入力された画像データが圧縮されていないと判断したときにも、前記圧縮処理を行うことなく前記画像データを前記バッファにそのまま書き込むことを特徴とする請求項２記載の画像処理装置。
【請求項５】
前記書込手段は、入力された画像データが圧縮されていないと判断した場合に、前記バッファを構成するデバイスがアクセス速度が第１所定値以上の記憶デバイスであるか、又は、前記バッファとの間のデータ転送速度が第２所定値以上の環境のときには、前記圧縮処理を行うことなく前記画像データを前記バッファにそのまま書き込み、前記バッファを構成するデバイスがアクセス速度が前記第１所定値未満の記憶デバイスであるか、又は、前記バッファとの間のデータ転送速度が前記第２所定値未満の環境のときには、前記画像データに対して圧縮処理を行った後に前記バッファに書き込むことを特徴とする請求項２記載の画像処理装置。
【請求項６】
前記読出手段は、後段のモジュールからの要求に応じて前記バッファから読み出した画像データが前記書込手段によって圧縮処理が行われていない画像データであれば、読み出した画像データを後段のモジュールへそのまま出力し、読み出した画像データが前記書込手段によって圧縮処理が行われた画像データであれば、読み出した画像データに対して伸長処理を行った後に後段のモジュールへ出力することを特徴とする請求項２記載の画像処理装置。
【請求項７】
前記読出手段は、当該読出手段を備えたバッファモジュールの後段のモジュールが、前段のモジュールから取得した圧縮画像データに対して伸長処理を行った後に画像処理を行う機能、又は、前段のモジュールから取得した圧縮画像データに対して伸長処理を行うことなく画像処理を行う機能を備えた画像処理モジュールである場合には、読み出した画像データが圧縮処理が行われた圧縮画像データであっても前記伸長処理を行わず、かつ前記圧縮画像データに適用された圧縮形式を表す属性情報を前記圧縮画像データに付加することで、後段の画像処理モジュールにおいて、前記圧縮画像データに対して伸長処理を行った後に画像処理を行わせるか、又は、前記圧縮画像データに対して伸長処理を行うことなく画像処理を行わせることを特徴とする請求項６記載の画像処理装置。
【請求項８】
コンピュータを、
自モジュールの前段から単位データ量ずつ画像データを取得し、取得した画像データに対して所定の画像処理を行い、前記所定の画像処理を経た画像データ又は前記所定の画像処理の処理結果を自モジュールの後段へ出力する機能を各々備え、実行する画像処理の種類又は内容が互いに異なる複数種の画像処理モジュールの中から選択された１つ以上の画像処理モジュールと、
画像データを記憶するためのバッファを備えた１つ以上のバッファモジュールと、
が、前記選択された個々の画像処理モジュールの前段及び後段の少なくとも一方にバッファモジュールが連結されるように、個々のモジュールがパイプライン形態又は有向非循環グラフ形態で連結されて構築された画像処理部を備えた画像処理装置として機能させるための画像処理プログラムであって、
前記バッファモジュールは、
前段のモジュールから書込対象の画像データが入力された場合に、入力された画像データが圧縮されているか否かに応じて書込方法を切り替えて前記画像データを前記バッファに書き込む書込手段と、
後段のモジュールから画像データが要求された場合に、前記バッファから画像データを読み出し、読み出した画像データが圧縮されているか否かに応じて出力方法を切り替えて前記画像データを後段のモジュールへ出力する読出手段と、
を備えていることを特徴とする画像処理プログラム。
【請求項１】
自モジュールの前段から単位データ量ずつ画像データを取得し、取得した画像データに対して所定の画像処理を行い、前記所定の画像処理を経た画像データ又は前記所定の画像処理の処理結果を自モジュールの後段へ出力する機能を各々備え、実行する画像処理の種類又は内容が互いに異なる複数種の画像処理モジュールの中から選択された１つ以上の画像処理モジュールと、
画像データを記憶するためのバッファを備えた１つ以上のバッファモジュールと、
が、前記選択された個々の画像処理モジュールの前段及び後段の少なくとも一方にバッファモジュールが連結されるように、個々のモジュールがパイプライン形態又は有向非循環グラフ形態で連結されて構築された画像処理部を備えた画像処理装置であって、
前記バッファモジュールは、
前段のモジュールから書込対象の画像データが入力された場合に、入力された画像データが圧縮されているか否かに応じて書込方法を切り替えて前記画像データを前記バッファに書き込む書込手段と、
後段のモジュールから画像データが要求された場合に、前記バッファから画像データを読み出し、読み出した画像データが圧縮されているか否かに応じて出力方法を切り替えて前記画像データを後段のモジュールへ出力する読出手段と、
を備えていることを特徴とする画像処理装置。
【請求項２】
前記書込手段は、前段のモジュールから入力された書込対象の画像データが圧縮されているか否か判断し、圧縮されていると判断した場合は前記画像データを前記バッファにそのまま書き込み、圧縮されていないと判断した場合は前記画像データに対して圧縮処理を行った後に前記バッファに書き込むことを特徴とする請求項１記載の画像処理装置。
【請求項３】
前記バッファモジュールの前段のモジュールから前記バッファモジュールへの画像データの入力は、画像を構成する所定の単位領域毎に分けて行われ、
前記書込手段は、前記単位領域のデータが前段のモジュールから所定回入力される間、入力された前記単位領域のデータのサイズを相互に比較し、入力された所定数の単位領域のデータのサイズが一定の場合は前段のモジュールから入力される画像データが圧縮されていないと判断し、前記所定数の単位領域のデータのサイズが一定でない場合は前段のモジュールから入力される画像データが圧縮されていると判断することを特徴とする請求項１又は請求項２記載の画像処理装置。
【請求項４】
前記書込手段は、前記バッファの空き容量又は前記バッファとして使用可能なシステムリソースの空き容量が所定値以上の場合には、入力された画像データが圧縮されていないと判断したときにも、前記圧縮処理を行うことなく前記画像データを前記バッファにそのまま書き込むことを特徴とする請求項２記載の画像処理装置。
【請求項５】
前記書込手段は、入力された画像データが圧縮されていないと判断した場合に、前記バッファを構成するデバイスがアクセス速度が第１所定値以上の記憶デバイスであるか、又は、前記バッファとの間のデータ転送速度が第２所定値以上の環境のときには、前記圧縮処理を行うことなく前記画像データを前記バッファにそのまま書き込み、前記バッファを構成するデバイスがアクセス速度が前記第１所定値未満の記憶デバイスであるか、又は、前記バッファとの間のデータ転送速度が前記第２所定値未満の環境のときには、前記画像データに対して圧縮処理を行った後に前記バッファに書き込むことを特徴とする請求項２記載の画像処理装置。
【請求項６】
前記読出手段は、後段のモジュールからの要求に応じて前記バッファから読み出した画像データが前記書込手段によって圧縮処理が行われていない画像データであれば、読み出した画像データを後段のモジュールへそのまま出力し、読み出した画像データが前記書込手段によって圧縮処理が行われた画像データであれば、読み出した画像データに対して伸長処理を行った後に後段のモジュールへ出力することを特徴とする請求項２記載の画像処理装置。
【請求項７】
前記読出手段は、当該読出手段を備えたバッファモジュールの後段のモジュールが、前段のモジュールから取得した圧縮画像データに対して伸長処理を行った後に画像処理を行う機能、又は、前段のモジュールから取得した圧縮画像データに対して伸長処理を行うことなく画像処理を行う機能を備えた画像処理モジュールである場合には、読み出した画像データが圧縮処理が行われた圧縮画像データであっても前記伸長処理を行わず、かつ前記圧縮画像データに適用された圧縮形式を表す属性情報を前記圧縮画像データに付加することで、後段の画像処理モジュールにおいて、前記圧縮画像データに対して伸長処理を行った後に画像処理を行わせるか、又は、前記圧縮画像データに対して伸長処理を行うことなく画像処理を行わせることを特徴とする請求項６記載の画像処理装置。
【請求項８】
コンピュータを、
自モジュールの前段から単位データ量ずつ画像データを取得し、取得した画像データに対して所定の画像処理を行い、前記所定の画像処理を経た画像データ又は前記所定の画像処理の処理結果を自モジュールの後段へ出力する機能を各々備え、実行する画像処理の種類又は内容が互いに異なる複数種の画像処理モジュールの中から選択された１つ以上の画像処理モジュールと、
画像データを記憶するためのバッファを備えた１つ以上のバッファモジュールと、
が、前記選択された個々の画像処理モジュールの前段及び後段の少なくとも一方にバッファモジュールが連結されるように、個々のモジュールがパイプライン形態又は有向非循環グラフ形態で連結されて構築された画像処理部を備えた画像処理装置として機能させるための画像処理プログラムであって、
前記バッファモジュールは、
前段のモジュールから書込対象の画像データが入力された場合に、入力された画像データが圧縮されているか否かに応じて書込方法を切り替えて前記画像データを前記バッファに書き込む書込手段と、
後段のモジュールから画像データが要求された場合に、前記バッファから画像データを読み出し、読み出した画像データが圧縮されているか否かに応じて出力方法を切り替えて前記画像データを後段のモジュールへ出力する読出手段と、
を備えていることを特徴とする画像処理プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２００７−２８７０８４（Ｐ２００７−２８７０８４Ａ）
【公開日】平成１９年１１月１日（２００７．１１．１）
【国際特許分類】
【出願番号】特願２００６−１１６６４０（Ｐ２００６−１１６６４０）
【出願日】平成１８年４月２０日（２００６．４．２０）
【出願人】（０００００５４９６）富士ゼロックス株式会社 (21,908)
【出願人】（０００００５２０１）富士フイルムホールディングス株式会社 (7,609)
【Ｆターム（参考）】
【公開日】平成１９年１１月１日（２００７．１１．１）
【国際特許分類】
【出願日】平成１８年４月２０日（２００６．４．２０）
【出願人】（０００００５４９６）富士ゼロックス株式会社 (21,908)
【出願人】（０００００５２０１）富士フイルムホールディングス株式会社 (7,609)
【Ｆターム（参考）】
[ Back to top ]