JP2011004265A - 画像処理装置及びプログラム - Google Patents

Abstract

【課題】画像処理の間中バッファモジュールが一定サイズのバッファを確保・解放する場合よりも処理のオーバヘッドを削減する。
【解決手段】前段から取得した画像データに対して画像処理を行い、画像処理を経た画像データを後段へ出力する画像処理モジュールの前段及び後段の少なくとも一方に、後段からのデータ要求に応じてバッファを確保し前段からの画像データをバッファに書き込ませ書き込ませた画像データを後段によって読み出させ読み出しが終了したバッファを解放するバッファモジュールが設けられた画像処理部において、バッファモジュールに対する後段のモジュールからのデータ要求のパターン(例えば(A)〜(D)のパターン)を検出し、検出したパターンに基づいてバッファ確保サイズを決定し、次回以降は決定したバッファ確保サイズのバッファをバッファモジュールで確保させる
【選択図】図５

Description

本発明は画像処理装置及びプログラムに関する。

特許文献１には、画像処理モジュールの前段及び後段の少なくとも一方にバッファモジュールが連結されるように、個々のモジュールをパイプライン形態又はＤＡＧ(Directed Acyclic Graph：有向非循環グラフ)形態で連結して成る画像処理部を構築し、画像処理部の個々の画像処理モジュールにおいて、バッファモジュールは、自モジュールの後段に画像処理モジュールが連結されている場合に、後段に連結されている画像処理モジュールの数を認識すると共に、バッファに記憶されている画像データのうち未読出の画像データの先頭位置を後段の個々の画像処理モジュール毎に記憶し、自モジュールの後段の画像処理モジュールから画像データが要求される毎に、前記バッファに記憶されている画像データを、読出要求元の画像処理モジュール毎に当該読出要求元の画像処理モジュールに対応する前記先頭位置から、自モジュールの後段の個々の画像処理モジュール毎に自モジュールに対して事前に設定されるか又は画像データ要求の都度指定される読出データ量だけ読み出させる処理を行う技術が提案されている。

特開２００６−３３８５０２号公報

本発明は、画像処理の間中バッファモジュールが一定サイズのバッファを確保・解放する場合よりも処理のオーバヘッドを削減できる画像処理装置及び画像処理プログラムを得ることが目的である。

上記目的を達成するために請求項１記載の発明に係る画像処理装置は、自モジュールの前段から取得した画像データに対して互いに異なる画像処理を行い、当該画像処理を経た画像データ又は前記画像処理の処理結果を自モジュールの後段へ出力する複数種の画像処理モジュールの中から選択した１つ以上の画像処理モジュールの各々の前段及び後段の少なくとも一方に、後段のモジュールからのデータ要求に応じてバッファを確保し前段のモジュールから出力される画像データを前記確保したバッファに書き込ませ前記バッファに書き込ませた画像データを後段のモジュールによって読み出させ後段のモジュールによるデータの読み出しが終了した前記バッファを解放するバッファモジュールが設けられ、各モジュールがパイプライン形態又は有向非循環グラフ形態で連結されて構築された画像処理部と、前記画像処理部のバッファモジュールに対する後段のモジュールからのデータ要求のパターンに基づいて前記バッファモジュールにおけるバッファ確保サイズを決定し、前記バッファモジュールで前記バッファ確保サイズのバッファを確保させる制御手段と、を含んで構成されている。

請求項２記載の発明は、請求項１記載の発明において、前記バッファモジュールは、後段のモジュールによるデータの読み出しが終了しかつ前記後段のモジュールから前記バッファの解放が指示された場合に前記バッファの解放を行い、前記制御手段は、前記バッファモジュールに対する後段のモジュールからのデータ要求のパターンが、後段の同一のモジュールからデータがＮ(≧２)回要求された後にバッファの解放が指示されるパターンである場合に、前記バッファ確保サイズを１回のデータ要求での要求データサイズのＮ倍のサイズ以上に決定する。

請求項３記載の発明は、請求項１記載の発明において、前記バッファモジュールは、後段に複数のモジュールが存在する場合、後段の複数のモジュールによるデータの読み出しが終了した前記バッファの解放を行い、前記制御手段は、後段に複数のモジュールが存在するバッファモジュールに対する後段のモジュールからのデータ要求のパターンが、後段の単一のモジュールからデータがＭ(≧２)回要求される毎に、データを要求するモジュールが後段の他のモジュールへ切り替わるパターンである場合に、前記バッファ確保サイズを１回のデータ要求での要求データサイズのＭ倍のサイズ以上に決定する。

請求項４記載の発明は、請求項１〜請求項３の何れかに記載の発明において、前記制御手段は、前記画像処理部の各バッファモジュールについて、前記データ要求のパターンを各々検出し、前記バッファ確保サイズの決定、及び、前記バッファ確保サイズのバッファを確保させる制御を各々行う。

請求項５記載の発明は、請求項１〜請求項４の何れかに記載の発明において、前記制御手段は、前段のモジュールから圧縮されたデータがバッファに書き込まれるバッファモジュールに対しては、可変長のデータを記憶可能なストレージを前記バッファとして確保させる。

請求項６記載の発明に係る画像処理プログラムは、自モジュールの前段から取得した画像データに対して互いに異なる画像処理を行い、当該画像処理を経た画像データ又は前記画像処理の処理結果を自モジュールの後段へ出力する複数種の画像処理モジュールのプログラムと、後段のモジュールからのデータ要求に応じてバッファを確保し前段のモジュールから出力される画像データを前記確保したバッファに書き込ませ前記バッファに書き込ませた画像データを後段のモジュールによって読み出させ後段のモジュールによるデータの読み出しが終了した前記バッファを解放するバッファモジュールのプログラムと、を記憶する記憶手段が接続されたコンピュータを、前記複数種の画像処理モジュールの中から選択した１つ以上の画像処理モジュールの各々の前段及び後段の少なくとも一方に前記バッファモジュールが設けられ、各モジュールがパイプライン形態又は有向非循環グラフ形態で連結されて構築された画像処理部のバッファモジュールに対する後段のモジュールからのデータ要求のパターンに基づいて前記バッファモジュールにおけるバッファ確保サイズを決定し、前記バッファモジュールで前記バッファ確保サイズのバッファを確保させる制御手段として機能させる。

請求項１及び請求項６記載の発明は、画像処理の間中バッファモジュールが一定サイズのバッファを確保・解放する場合よりも処理のオーバヘッドを削減できる、という効果を有する。

請求項２記載の発明は、バッファモジュールの後段のモジュールから連続的にデータが要求される場合のバッファ確保サイズを適正値に設定できる、という効果を有する。

請求項３記載の発明は、バッファモジュールの後段の複数のモジュールの各々から連続的にデータが要求される場合のバッファ確保サイズを適正値に設定できる、という効果を有する。

請求項４記載の発明は、画像処理部にバッファモジュールが複数設けられている場合に個々のバッファモジュールにおけるバッファ確保サイズを各々適正値に設定できる、という効果を有する。

請求項５記載の発明は、前段のモジュールから圧縮された不定長のデータが書き込まれる場合の処理を簡略化できる、という効果を有する。

本実施形態に係るコンピュータ(画像処理装置)の概略構成を示すブロック図である。 画像処理部の構成例を示すブロック図である。 (Ａ)は画像処理モジュール、(Ｂ)はバッファモジュールの概略構成及び実行される処理を各々示すブロック図である。 バッファサイズ管理処理の内容を示すフローチャートである。 本実施形態における処理シーケンスの一例を示す概略図である。 本実施形態における処理シーケンスの他の例を示す概略図である。

以下、図面を参照して本発明の実施形態の一例を詳細に説明する。図１には、本発明に係る画像処理装置として機能することが可能なコンピュータ１０が示されている。なお、このコンピュータ１０は、複写機、プリンタ、ファクシミリ装置、これらの機能を兼ね備えた複合機、スキャナ、写真プリンタ等のように内部で画像処理を行う必要のある画像取扱機器に組み込まれていてもよいし、パーソナル・コンピュータ（ＰＣ）等の独立したコンピュータであってもよく、更にＰＤＡ（Personal Digital Assistant）や携帯電話機等の携帯機器に組み込まれたコンピュータであってもよい。

コンピュータ１０はＣＰＵ１２、メモリ１４、表示部１６、操作部１８、記憶部２０、画像データ供給部２２及び画像出力部２４を備えており、これらはバス２６を介して互いに接続されている。コンピュータ１０が上述した画像取扱機器に組み込まれている場合、表示部１６や操作部１８としては、画像取扱機器に設けられたＬＣＤ等から成る表示パネルやテンキー等を適用することができる。また、コンピュータ１０が独立したコンピュータである場合、表示部１６や操作部１８としては、当該コンピュータに接続されたディスプレイやキーボード、マウス等を適用することができる。また、記憶部２０としてはＨＤＤ(Hard Disk Drive)が好適であるが、これに代えてフラッシュメモリ等の他の不揮発性記憶手段を用いることも可能である。

また、画像データ供給部２２は処理対象の画像データを供給できるものであればよく、例えば紙や写真フィルム等の記録材料に記録されている画像を読み取って画像データを出力する画像読取部、通信回線を介して外部から画像データを受信する受信部、画像データを記憶する画像記憶部（メモリ１４又は記憶部２０）等を適用することができる。また、画像出力部２４は画像処理を経た画像データ又は該画像データが表す画像を出力するものであればよく、例えば画像データが表す画像を紙や感光材料等の記録材料に記録する画像記録部、画像データが表す画像をディスプレイ等に表示する表示部、画像データを記録メディアに書き込む書込装置、画像データを通信回線を介して送信する送信部を適用することができる。また、画像出力部２４は画像処理を経た画像データを単に記憶する画像記憶部（メモリ１４又は記憶部２０）であっても構わない。

図１に示すように、記憶部２０には、ＣＰＵ１２によって実行される各種のプログラムとして、メモリ１４等のリソースの管理やＣＰＵ１２によるプログラムの実行の管理、コンピュータ１０と外部との通信等を司るオペレーティングシステム３０のプログラム、コンピュータ１０を本発明に係る画像処理装置として機能させるための画像処理プログラム群３４、ＣＰＵ１２が上記画像処理プログラム群を実行することで実現される画像処理装置に対して所望の画像処理を行わせる各種のアプリケーション３２のプログラム（図１ではアプリケーションプログラム群３２と表記）が各々記憶されている。

画像処理プログラム群３４は、前述した各種の画像取扱機器や携帯機器を開発する際の開発負荷を軽減したり、ＰＣ等で利用可能な画像処理プログラムを開発する際の開発負荷を軽減することを目的として、各種の画像取扱機器や携帯機器、ＰＣ等の各種機器（プラットフォーム）で共通に使用可能に開発されたプログラムであり、本発明に係る画像処理プログラムに対応している。画像処理プログラム群３４によって実現される画像処理装置は、アプリケーション３２からの構築指示に従い、アプリケーション３２が指示した画像処理を行う画像処理部を構築し、アプリケーション３２からの実行指示に従い、前記画像処理部によって画像処理を行うが（詳細は後述）、画像処理プログラム群３４は、所望の画像処理を行う画像処理部（所望の構成の画像処理部）の構築を指示したり、構築された画像処理部による画像処理の実行を指示するためのインタフェースをアプリケーション３２に提供している。このため、内部で画像処理を行う必要のある任意の機器を新規開発する等の場合にも、前記画像処理を行うプログラムの開発に関しては、当該機器で必要とされる画像処理を上記のインタフェースを利用して画像処理プログラム群３４に行わせるアプリケーション３２を開発するのみで済み、実際に画像処理を行うプログラムを新たに開発する必要が無くなる。

また、画像処理プログラム群３４によって実現される画像処理装置は、前述のように、アプリケーション３２からの構築指示に従い、アプリケーション３２が指示した画像処理を行う画像処理部を構築し、構築した画像処理部によって画像処理を行うので、例えば画像処理対象の画像データの色空間や１画素当たりのビット数が不定であったり、実行すべき画像処理の内容や手順・パラメータ等が不定である場合にも、アプリケーション３２が画像処理部の再構築を指示することで、画像処理装置（画像処理部）によって実行される画像処理を、処理対象の画像データ等に応じて柔軟に変更することが可能となる。

以下、画像処理プログラム群３４について説明する。図１に示すように、画像処理プログラム群３４はモジュールライブラリ３６と、処理構築部４２のプログラムと、処理管理部４６のプログラムに大別される。本実施形態に係る処理構築部４２は、アプリケーションからの指示により、例として図２に示すように、予め定められた画像処理を行う１つ以上の画像処理モジュール３８と、個々の画像処理モジュール３８の前段及び後段の少なくとも一方に配置され画像データを記憶するためのバッファを備えたバッファモジュール４０と、がパイプライン形態又はＤＡＧ(Directed Acyclic Graph：有向非循環グラフ)形態で連結されて成る画像処理部５０を構築する。画像処理部５０を構成する個々の画像処理モジュールの実体はＣＰＵ１２によって実行されＣＰＵ１２で画像処理を行わせるための第１プログラム、又は、ＣＰＵ１２によって実行されＣＰＵ１２により図１に図示されていない外部の画像処理装置（例えば専用画像処理ボード等）に対する処理の実行を指示するための第２プログラムであり、上述したモジュールライブラリ３６には、予め定められた互いに異なる画像処理（例えば入力処理やフィルタ処理、色変換処理、拡大・縮小処理、スキュー角検知処理、画像回転処理、画像合成処理、出力処理等）を行う複数種の画像処理モジュール３８のプログラムが各々登録されている。以下では、説明を簡単にするために、画像処理部５０を構成する個々の画像処理モジュールの実体が上記の第１プログラムであるものとして説明する。

個々の画像処理モジュール３８は、例として図３(Ａ)にも示すように、画像データに対する画像処理を予め定めた単位処理データ量ずつ行う画像処理エンジン３８Ａと、画像処理モジュール３８の前段及び後段のモジュールとの画像データの入出力及び画像処理エンジン３８Ａの制御を行う制御部３８Ｂから構成されている。個々の画像処理モジュール３８における単位処理データ量は、画像の１ライン分、画像の複数ライン分、画像の１画素分、画像１面分等を含む任意のバイト数の中から、画像処理エンジン３８Ａが行う画像処理の種類等に応じて予め選択・設定されており、例えば色変換処理やフィルタ処理を行う画像処理モジュール３８では単位処理データ量が１画素分とされ、拡大・縮小処理を行う画像処理モジュール３８では単位処理データ量が画像の１ライン分又は画像の複数ライン分とされ、画像回転処理を行う画像処理モジュール３８では単位処理データ量が画像１面分とされ、画像圧縮伸長処理を行う画像処理モジュール３８では単位処理データ量が実行環境に依存するＮバイトとされている。

また、モジュールライブラリ３６には、画像処理エンジン３８Ａが実行する画像処理の種類が同一でかつ実行する画像処理の内容が異なる画像処理モジュール３８も登録されている（図１では、この種の画像処理モジュールを「モジュール１」「モジュール２」と表記して示している）。例えば拡大・縮小処理を行う画像処理モジュール３８については、入力された画像データを１画素おきに間引くことで50％に縮小する縮小処理を行う画像処理モジュール３８、入力された画像データに対して指定された拡大・縮小率で拡大・縮小処理を行う画像処理モジュール３８等の複数の画像処理モジュール３８が各々用意されている。また、例えば色変換処理を行う画像処理モジュール３８については、ＲＧＢ色空間をＣＭＹ色空間へ変換する画像処理モジュール３８やその逆へ変換する画像処理モジュール３８、Ｌ*ａ*ｂ*色空間等の他の色空間変換を行う画像処理モジュール３８が各々用意されている。

また、画像処理モジュール３８の制御部３８Ｂは、画像処理エンジン３８Ａが単位処理データ量ずつ処理するために必要な画像データを入力するために、自モジュールの前段のモジュール（例えばバッファモジュール４０）から画像データを単位読出データ量ずつ取得し、画像処理エンジン３８Ａから出力される画像データを単位書込データ量ずつ後段のモジュール（例えばバッファモジュール４０）へ出力する（画像処理エンジン３８Ａで圧縮等のデータ量の増減を伴う画像処理が行われなければ単位書込データ量＝単位処理データ量となる）か、画像処理エンジン３８Ａによる画像処理の結果を自モジュールの外部へ出力する（例えば画像処理エンジン３８Ａがスキュー角検知処理等の画像解析処理を行う場合、画像データに代えてスキュー角検知結果等の画像解析処理結果が出力されることがある）処理を行うが、モジュールライブラリ３６には、画像処理エンジン３８Ａが実行する画像処理の種類及び内容が同一で、上記の単位処理データ量や単位読出データ量、単位書込データ量が異なる画像処理モジュール３８も登録されている。例えば画像回転処理を行う画像処理モジュール３８における単位処理データ量についても、前述した画像１面分に限られるものではなく、同じ画像回転処理を行いかつ単位処理データ量が互いに異なる（例えば画像の１ライン分や複数ライン分等の）複数の画像処理モジュール３８がモジュールライブラリ３６に含まれていても良い。

また、モジュールライブラリ３６に登録されている個々の画像処理モジュール３８のプログラムは、画像処理エンジン３８Ａに相当するプログラムと制御部３８Ｂに相当するプログラムから構成されているが、制御部３８Ｂに相当するプログラムは部品化されており、個々の画像処理モジュール３８のうち単位読出データ量及び単位書込データ量が同一の画像処理モジュール３８は、画像処理エンジン３８Ａで実行される画像処理の種類や内容に拘わらず、制御部３８Ｂに相当するプログラムが共通化されている（制御部３８Ｂに相当するプログラムとして同一のプログラムが用いられている）。これにより、画像処理モジュール３８のプログラムの開発にあたっての開発負荷が軽減される。

なお、画像処理モジュール３８の中には、入力される画像の属性が未知の状態では単位読出データ量及び単位書込データ量が確定しておらず、入力画像データの属性を取得し、取得した属性を予め定めた演算式に代入して演算することで単位読出データ量や単位書込データ量が確定するモジュールが存在しているが、この種の画像処理モジュール３８については、単位読出データ量と単位書込データ量が互いに同一の演算式を用いて導出される画像処理モジュール３８について、制御部３８Ｂに相当するプログラムを共通化するようにすればよい。また、本実施形態に係る画像処理プログラム群３４は、前述のように各種機器に実装可能であるが、画像処理プログラム群３４のうちモジュールライブラリ３６に登録する画像処理モジュール３８の数や種類等については、画像処理プログラム群３４を実装する各種機器で必要とされる画像処理に応じて、追加・削除・入替等が可能であることは言うまでもない。

また、画像処理部５０を構成する個々のバッファモジュール４０は、例として図３(Ｂ)にも示すように、バッファ４０Ａと、バッファモジュール４０の前段及び後段のモジュールとの画像データの入出力及びバッファ４０Ａの管理を行うバッファ制御部４０Ｂから構成されている。なお、バッファ４０Ａはコンピュータ１０に設けられたメモリ１４(或いはストレージ、例えばＨＤＤ等から成る記憶部２０等))からオペレーティングシステム３０及びリソース管理部４６Ｃを通じてバッファ制御部４０Ｂが確保した記憶領域で構成される。個々のバッファモジュール４０のバッファ制御部４０Ｂもその実体はＣＰＵ１２によって実行されるプログラムであり、モジュールライブラリ３６にはバッファ制御部４０Ｂのプログラムも登録されている（図１ではバッファ制御部４０Ｂのプログラムを「バッファモジュール」と表記して示している）。

また、アプリケーション３２からの指示に従って画像処理部５０を構築する処理構築部４２は、図１に示すように複数種のモジュール生成部４４から構成されている。複数種のモジュール生成部４４は互いに異なる画像処理に対応しており、アプリケーション３２によって起動されることで、対応する画像処理を実現するための画像処理モジュール３８及びバッファモジュール４０から成るモジュール群を生成する処理を行う。なお、図１ではモジュール生成部４４の一例として、モジュールライブラリ３６に登録されている個々の画像処理モジュール３８が実行する画像処理の種類に対応するモジュール生成部４４を示しているが、個々のモジュール生成部４４に対応する画像処理は、複数種の画像処理モジュール３８によって実現される画像処理（例えばスキュー角検知処理と画像回転処理から成るスキュー補正処理）であってもよい。必要とされる画像処理が複数種の画像処理を組み合わせた処理である場合、アプリケーション３２は複数種の画像処理の何れかに対応するモジュール生成部４４を順次起動する。これにより、アプリケーション３２によって順次起動されたモジュール生成部４４により、必要とされる画像処理を行う画像処理部５０が構築されることになる。

また図１に示すように、処理管理部４６は、画像処理部５０における画像処理の実行を制御する処理フロー管理部４６Ａ、画像処理部５０で発生したエラーを管理するエラー管理部４６Ｂ、画像処理部５０の各モジュールによるメモリ１４や各種のファイル等のコンピュータ１０のリソースの使用を管理するリソース管理部４６Ｃ、及び、画像処理部５０の個々のバッファモジュール４０におけるバッファ４０Ａのサイズを管理するバッファサイズ管理部４６Ｄを含んで構成されている。なお、エラー管理部４６Ｂは、画像処理部５０が画像処理を実行している途中でエラーが発生した場合に、発生したエラーの種別・発生箇所等のエラー情報を取得し、画像処理プログラム群３４がインストールされたコンピュータ１０が組み込まれている機器の種別や構成等を表す装置環境情報を記憶部２０等から取得し、取得した装置環境情報が表す装置環境に応じたエラー通知方法を判断し、判断したエラー通知方法でエラーの発生を通知する処理を行う。

次に本実施形態の作用を説明する。画像処理プログラム群３４が実装されている機器において、何らかの画像処理を行う必要のある状況になると、この状況が特定のアプリケーション３２によって検知される。なお、画像処理を行う必要のある状況としては、例えば画像データ供給部２２としての画像読取部によって画像を読み取り、画像出力部２４としての画像記録部により記録材料に画像として記録するか、画像出力部２４としての表示部に画像として表示させるか、画像出力部２４としての書込装置により画像データを記録メディアに書き込むか、画像出力部２４としての送信部により画像データを送信するか、画像出力部２４としての画像記憶部に記憶させるジョブの実行がユーザによって指示された場合、或いは、画像データ供給部２２としての受信部によって受信されるか、画像データ供給部２２としての画像記憶部に記憶されている画像データに対して、上記の記録材料への記録、表示部への表示、記録メディアへの書き込み、送信、画像記憶部への記憶の何れかを行うジョブの実行がユーザによって指示された場合が挙げられる。また、画像処理を行う必要のある状況は上記に限られるものではなく、例えばユーザからの指示に応じてアプリケーション３２が実行可能な処理の名称等を表示部１６に一覧表示している状態で、実行対象の処理がユーザによって選択された等の場合であってもよい。

上記のように、何らかの画像処理を行う必要のある状況になったことを検知すると、アプリケーション３２は、画像処理対象の画像データを供給する画像データ供給部２２の種別を認識し、認識した種別がバッファ領域（メモリ１４の一部領域）であった場合には、画像データ供給部２２として指定されたバッファ領域を既に確保されたバッファ４０Ａとしてバッファ制御部４０Ｂに認識させるパラメータを設定し、バッファ制御部４０Ｂのプログラムを実行するスレッド（プロセス又はオブジェクトでもよい：以下同様）を生成する（バッファ制御部４０Ｂを生成する）ことで、指定されたバッファ領域を含むバッファモジュール４０（画像データ供給部２２として機能するバッファモジュール４０）を生成する。

続いてアプリケーション３２は、上記と同様に、画像処理を行った画像データの出力先としての画像出力部２４の種別を認識し、認識した種別がバッファ領域（メモリ１４の一部領域）であった場合は、画像出力部２４として指定されたバッファ領域を含むバッファモジュール４０を上記と同様にして生成する。ここで生成されたバッファモジュール４０は画像出力部２４として機能する。また、アプリケーション３２は実行すべき画像処理の内容を認識し、実行すべき画像処理を、個々のモジュール生成部４４に対応するレベルの画像処理の組み合わせに分解し、実行すべき画像処理を実現するために必要な画像処理の種類及び個々の画像処理の実行順序を判定する。なお、この判定は、例えば上記の画像処理の種類及び個々の画像処理の実行順序を、ユーザが実行を指示可能なジョブの種類と対応付けて予め情報として登録しておき、アプリケーション３２は、実行が指示されたジョブの種類に対応する情報を読み出すことによって実現することができる。

そしてアプリケーション３２は、上記で判定した画像処理の種類及び実行順序に基づいて、特定の画像処理に対応するモジュール生成部４４を起動（モジュール生成部４４のプログラムを実行するスレッドを生成）した後に、起動したモジュール生成部４４に対し、当該モジュール生成部４４によるモジュール群の生成に必要な情報として、前記モジュール群に画像データを入力する入力モジュールを識別するための入力モジュール識別情報、前記モジュール群が画像データを出力する出力モジュールを識別するための出力モジュール識別情報、前記モジュール群に入力される入力画像データの属性を表す入力画像属性情報、実行すべき画像処理のパラメータ等を通知して、対応するモジュール群の生成を指示する。また、必要とされる画像処理が複数種の画像処理を組み合わせた処理である場合、アプリケーション３２は、指示したモジュール生成部４４からモジュール群の生成完了が通知されると、個々の画像処理に対応する他のモジュール生成部４４を起動してモジュール群の生成に必要な情報を通知する処理を個々の画像処理の実行順序の昇順に繰り返す。

なお、上記の入力モジュールは、実行順序が１番目のモジュール群については画像データ供給部２２が入力モジュールとなり、実行順序が２番目以降のモジュール群については前段のモジュール群の最終モジュール（通常はバッファモジュール４０）が入力モジュールとなる。また、上記の出力モジュールについては、実行順序が最後のモジュール群では画像出力部２４が出力モジュールとなるので、画像出力部２４が出力モジュールとして指定されるが、その他のモジュール群では出力モジュールは未確定のためにアプリケーション３２による指定は行われず、必要な場合はモジュール生成部４４によって生成・設定される。また、入力画像属性や画像処理のパラメータについては、例えばユーザが実行を指示可能なジョブの種類と対応付けて予め情報として登録しておき、実行が指示されたジョブの種類に対応する情報を読み出すことでアプリケーション３２が認識するようにしてもよいし、ユーザに指定させるようにしてもよい。

一方、モジュール生成部４４は、アプリケーション３２によって起動されるとモジュール生成処理を行う。モジュール生成処理では、まず生成対象の画像処理モジュール３８に入力される入力画像データの属性を表す入力画像属性情報を取得する。なお、入力画像データの属性を取得する処理は、生成対象の画像処理モジュール３８の前段にバッファモジュール４０が存在している場合、当該バッファモジュール４０に画像データの書き込みを行う更に前段の画像処理モジュール３８から出力画像データの属性を取得することによって実現できる。

そして、取得した情報が表す入力画像データの属性に基づいて、生成対象の画像処理モジュール３８の生成が必要か否か判定する。例えばモジュール生成部４４が色変換処理を行うモジュール群を生成するモジュール生成部であり、画像処理のパラメータにより出力画像データの色空間としてＣＭＹ色空間がアプリケーション３２から指定された場合、取得した入力画像属性情報に基づいて入力画像データがＲＧＢ色空間のデータであることが判明したときには、色空間処理を行う画像処理モジュール３８としてＲＧＢ→ＣＭＹの色空間変換を行う画像処理モジュール３８を生成する必要があるが、入力画像データがＣＭＹ色空間のデータであったときには、入力画像データの属性と出力画像データの属性が色空間に関して一致しているので、色空間変換処理を行う画像処理モジュール３８は生成不要と判断する。

生成対象の画像処理モジュール３８の生成が必要と判断した場合には、生成対象の画像処理モジュール３８の後段にバッファモジュール４０が必要が否かを判定する。この判定は、画像処理モジュールの後段が出力モジュール（画像出力部２４）である場合（例えば図２(Ａ)〜(Ｃ)に示す画像処理部５０における最後段の画像処理モジュール３８を参照）や、例として図２(Ｂ)に示す画像処理部５０においてスキュー角検知処理を行う画像処理モジュール３８のように、画像処理モジュールが、画像データに対して解析等の画像処理を行いその結果を他の画像処理モジュール３８へ出力するモジュールである場合は否定されるが、上記以外の場合は判定が肯定されてバッファ制御部４０Ｂを起動することで、画像処理モジュール３８の後段に連結するバッファモジュール４０を生成する。

続いて、前段のモジュール（例えばバッファモジュール４０）の情報、後段のバッファモジュール４０の情報（後段にバッファモジュール４０を生成した画像処理モジュール３８のみ）、画像処理モジュール３８に入力される入力画像データの属性、処理パラメータを与えて、モジュールライブラリ３６に登録されており、画像処理モジュール３８として利用可能な複数の候補モジュールの中から、先に取得した入力画像データの属性、及び、画像処理モジュール３８で実行すべき処理パラメータに合致する画像処理モジュール３８を選択・生成する。

例えばモジュール生成部４４が色変換処理を行うモジュール群を生成するモジュール生成部であり、処理パラメータにより出力画像データの色空間としてＣＭＹ色空間が指定され、更に入力画像データがＲＧＢ色空間のデータであった場合には、モジュールライブラリ３６に登録されている各種の色空間処理を行う複数種の画像処理モジュール３８の中から、ＲＧＢ→ＣＭＹの色空間変換を行う画像処理モジュール３８が選択・生成される。また、画像処理モジュールが拡大・縮小処理を行う画像処理モジュール３８であり、指定された拡大縮小率が50％以外であれば、入力された画像データに対して指定された拡大・縮小率で拡大・縮小処理を行う画像処理モジュール３８が選択・生成され、指定された拡大縮小率が50％であれば、拡大縮小率50％に特化した拡大縮小処理、すなわち入力された画像データを１画素おきに間引くことで50％に縮小する縮小処理を行う画像処理モジュール３８が選択・生成される。

なお、画像処理モジュール３８の選択は上記に限られるものではなく、例えば画像処理エンジン３８Ａによる画像処理における単位処理データ量が異なる画像処理モジュール３８をモジュールライブラリ３６に複数登録しておき、画像処理部５０へ割当可能なメモリ領域のサイズ等の動作環境に応じて、適切な単位処理データ量の画像処理モジュール３８を選択する（例えば上記サイズが小さくなるに従って単位処理データ量の小さい画像処理モジュール３８を選択する等）ようにしてもよいし、アプリケーション３２或いはユーザに選択させるようにしてもよい。

またモジュール生成部４４が、複数種の画像処理モジュール３８によって実現される画像処理（例えばスキュー角検知処理を行う画像処理モジュール３８と画像回転処理を行う画像処理モジュール３８によって実現されるスキュー補正処理）を行うモジュール群を生成する場合には、上記処理が繰り返されて２個以上の画像処理モジュール３８を含むモジュール群が生成される。アプリケーション３２によって順次起動された個々のモジュール生成部４４により、以上のモジュール生成処理が順次行われることで、例として図２(Ａ)〜(Ｃ)に示すように、必要とされる画像処理を行う画像処理部５０が構築される。

更に、モジュール生成部４４が生成する画像処理モジュール３８が、別の画像処理モジュール３８による画像処理の結果(例えばヒストグラム等の画像解析処理結果)を用いて画像処理を行うモジュールであり、前記別の画像処理モジュール３８が未生成の場合には、モジュール生成部４４によって前記別の画像処理モジュール３８（或いは前記別の画像処理モジュール３８を含むモジュール群）の生成も行われる。

一方、処理構築部４２は、アプリケーション３２からの指示に従い、画像処理部５０を構成する個々のモジュールを順次生成する上述した処理と並行して、処理管理部４６のプログラムを実行するスレッドを生成することで、コンピュータ１０上で動作する処理管理部４６の処理フロー管理部４６Ａ、、エラー管理部４６Ｂリソース管理部４６Ｃ及びバッファサイズ管理部４６Ｄを各々生成する処理も行う。また、処理フロー管理部４６Ａは管理対象のモジュールの識別情報を登録するための管理テーブルを備えており、処理構築部４２は、アプリケーション３２からの指示に従って新たな画像処理モジュール３８が生成される毎に、新たに生成された画像処理モジュール３８の識別情報(ＩＤ)を、当該画像処理モジュール３８の後段に連結されたバッファモジュール４０の識別情報(ＩＤ)と対応付け、処理フロー管理部４６Ａの管理テーブルに登録する。なお、上記の識別情報(ＩＤ)は個々のモジュールを一意に判別できる情報であればよく、例えば個々のモジュールの生成順に付与した番号や、バッファモジュール４０や画像処理モジュール３８のオブジェクトのメモリ上でのアドレス等でも良い。

次に、上記の処理で構築された画像処理部５０で画像処理が行われる際の個々の画像処理モジュール３８及びバッファモジュール４０の動作を順に説明する。

画像処理が実行される際には、対応する処理フロー管理部４６Ａから個々の画像処理モジュール３８に処理要求が入力される(図３(Ａ)の(1)も参照)。画像処理モジュール３８は、処理要求が入力されると、予め設定された識別情報で規定されている自モジュールの前段のモジュール（通常はバッファモジュール４０）に対して画像データを要求する(図３(Ａ)の(2)も参照)。ここで、前段のバッファモジュール４０にバッファ４０Ａが存在しており、当該バッファ４０Ａに読出可能な有効データが自モジュールの単位読出データ量以上記憶されている場合には、バッファモジュール４０から読出領域の先頭アドレスが通知されて画像データの読出が要請される。これにより、画像処理モジュール３８は先頭アドレスが通知された前段のモジュールの読出領域から単位読出データ量の画像データを読み出す(図３(Ａ)の(3)も参照）。

次に、画像処理モジュール３８は自モジュールの後段のモジュールに対し、自モジュールの単位書込データ量と同サイズのデータ出力用の領域を要求し、データ出力領域（後段のモジュールがバッファモジュール４０であれば当該バッファモジュール４０から先頭アドレスが通知された書込領域）が取得できたら(図３(Ａ)の(4)も参照)、先に前段のモジュールから取得した画像データ、後段のモジュールから取得したデータ出力領域（の先頭アドレス）を画像処理エンジン３８Ａに入力し、入力したデータに対して予め定めた画像処理を行わせる(図３(Ａ)の(5)も参照)と共に、処理後のデータをデータ出力領域に書き込ませる(図３(Ａ)の(6)も参照)。そして、画像処理エンジン３８Ａへの単位読出データ量のデータの入力が完了し、画像処理エンジン３８Ａから出力された単位書込データ量のデータがデータ出力領域に全て書き込まれると、出力完了を後段のモジュールに通知すると共に、先に入力された処理要求に対応する処理を完了したことを処理要求元(対応する処理フロー管理部４６Ａ)へ通知する(図３(Ａ)の(7)も参照)。個々の画像処理モジュール３８で上記処理が繰り返されることで、画像処理部５０における画像処理が実現される。

また、バッファモジュール４０のバッファ制御部４０Ｂは、予め設定された識別情報で規定されている自モジュールの後段のモジュール（通常は画像処理モジュール３８）から画像データが要求されると(図３(Ｂ)の(1)も参照)、バッファ４０Ａが存在しているか否かをチェックし、更に、要求された画像データがバッファ４０Ａに記憶されているか否かをチェックする(図３(Ｂ)の(2)も参照)。ここで、バッファ４０Ａが存在しない場合、バッファ制御部４０Ｂはリソース管理部４６Ｃを通じてバッファ４０Ａを確保する。本実施形態では、バッファ確保サイズの初期値が、バッファモジュール４０の後段の画像処理モジュール３８から通知された単位読出データ量と、バッファモジュール４０の前段の画像処理モジュール３８から通知された単位書込データ量と、のうちの大きい方と同サイズとされており、当該サイズのバッファ４０Ａがリソース管理部４６Ｃを通じて確保される。

また、バッファ４０Ａを新たに確保した場合、或いは、バッファ４０Ａは存在しているものの、当該バッファ４０Ａに後段の画像処理モジュール３８が読出可能な有効データが後段の画像処理モジュール３８の単位読出データ量以上記憶されていない場合は、処理フロー管理部４６Ａに対して画像データを要求する(図３(Ｂ)の(3)も参照)。ここで、処理フロー管理部４６Ａは、画像データ要求元のバッファモジュール４０の識別情報(ＩＤ)をキーにして管理テーブルを検索し、画像データ要求元のバッファモジュール４０の識別情報(ＩＤ)と対応付けて管理テーブルに識別情報(ＩＤ)が登録されている画像処理モジュール３８を、画像データ要求元のバッファモジュール４０の前段に位置している画像処理モジュール３８と認識し、認識した画像処理モジュール３８に処理要求を入力する(図３(Ｂ)の(4)も参照)。

そして、図３(Ａ)に示したシーケンスを経て、前段の画像処理モジュール３８によってバッファ４０Ａに画像データが書き込まれ(図３(Ｂ)の(5),(6)も参照)、バッファ４０Ａから読出可能な有効データが後段の画像処理モジュール３８の単位読出データ量以上になると、バッファモジュール４０から後段の画像処理モジュール３８に対して読出領域の先頭アドレスが通知され、後段の画像処理モジュール３８によってバッファモジュール４０のバッファ４０Ａから画像データが読み出されることになる(図３(Ｂ)の(7)も参照)。

なお、図３では図示を省略するが、画像処理モジュール３８は、前段のバッファモジュール４０のバッファ４０Ａから単位読出データ量の画像データの読み出しが完了する毎に、前段のバッファモジュール４０に対して画像データの読み出しが完了したバッファ４０Ａの解放を指示する。また、バッファモジュール４０は、後段の画像処理モジュール３８からバッファ４０Ａの解放が指示されると、通常、解放が指示されたバッファ４０Ａをリソース管理部４６Ｃを通じて解放する。但し、後段に複数の画像処理モジュール３８が連結されているバッファモジュール４０(例えば図２(Ｂ)に示す画像処理部５０において、スキュー角検知処理を行う画像処理モジュール３８と画像回転処理を行う画像処理モジュール３８と後段に各々連結されたバッファモジュール４０等)については、後段の何れかの画像処理モジュール３８からバッファ４０Ａの解放が指示された場合であっても、解放が指示されたバッファ４０Ａに記憶されている画像データが後段の全ての画像処理モジュール３８によって読み出される迄はバッファ４０Ａの解放を保留する。

一方、先の処理管理部生成処理によって生成された個々の処理管理部４６の処理フロー管理部４６Ａは、画像処理部５０の構築完了を検知したアプリケーション３２から画像処理の実行が指示されると、画像処理部５０の最後段に位置している画像処理モジュール３８に処理要求を入力し、任意のバッファモジュール４０からデータ要求が入力される毎に、前述のように管理テーブルの検索を行うことで、データ要求入力元のバッファモジュール４０の前段の画像処理モジュール３８を認識し、認識した画像処理モジュール３８に処理要求を入力する。また、画像処理部５０の最後段に位置している画像処理モジュール３８から処理完了通知が入力される毎に、前記最後段に位置している画像処理モジュール３８に処理要求を再度入力することを、前記最後段に位置している画像処理モジュール３８から全体処理の終了(処理対象の画像データ(例えば１フレーム分の画像データ)に対する画像処理の終了）が通知される迄繰り返す。そして、前記最後段に位置している画像処理モジュール３８から全体処理の終了が通知されると、画像処理の実行を指示したアプリケーション３２に対して管理対象のモジュール群における画像処理の実行終了を通知する。

また、画像処理部５０で画像処理が開始されると、バッファサイズ管理部４６Ｄは、処理フロー管理部４６Ａにおける処理と並行して、図４に示すバッファサイズ管理処理を行う。本実施形態に係るバッファサイズ管理処理では、画像処理部５０のバッファモジュール４０のうち、画像データ供給部２２や画像出力部２４として機能するバッファモジュール４０を除いた個々のバッファモジュール４０を管理対象としており、まずステップ５０では、管理対象の個々のバッファモジュール４０について、データ要求回数を計数するための記憶領域及び設定フラグの記憶領域をメモリ１４に設け、設けた各記憶領域に各々０を設定する。なお、上記処理では管理対象の個々のバッファモジュール４０について、後段に連結されている画像処理モジュール３８の数も確認され、データ要求回数の記憶領域が、後段に連結されている画像処理モジュール３８の数と同数だけ設けられる。

次のステップ５２では、管理対象の何れかのバッファモジュール４０から処理フロー管理部４６Ａにデータ要求が入力されたか否か判定する。判定が否定された場合はステップ６６へ移行し、管理対象の何れかのバッファモジュール４０でバッファ４０Ａが解放されたか否か判定する。この判定も否定された場合はステップ８０へ移行し、画像処理部５０における画像処理(全体処理)が終了したか否か判定する。この判定も否定された場合はステップ５２に戻り、ステップ５２,６６,８０の何れかの判定が肯定される迄ステップ５２,６６,８０を繰り返す。

また、管理対象の何れかのバッファモジュール４０から処理フロー管理部４６Ａにデータ要求が入力され、これに伴い、データ要求が入力されたことがデータ要求入力元のバッファモジュール４０の識別情報(ＩＤ)と共に処理フロー管理部４６Ａから通知されると、ステップ５２の判定が肯定されてステップ５６へ移行し、通知された識別情報(ＩＤ)に基づいて認識したデータ要求入力元のバッファモジュール４０に対応する設定フラグが０か否か判定する。個々のバッファモジュール４０に対応する設定フラグは先のステップ５０で各々０が設定されているので、当初はこの判定が肯定されてステップ５８へ移行し、認識したデータ要求入力元のバッファモジュール４０の後段に複数の画像処理モジュール３８が存在しているか否か判定する。

ステップ５８の判定が否定された場合はステップ６０へ移行し、データ要求入力元のバッファモジュール４０に対応するデータ要求回数を１だけインクリメントした後にステップ６６へ移行する。また、ステップ５８の判定が肯定された場合はステップ６２へ移行し、データ要求入力元のバッファモジュール４０から今回入力されたデータ要求が、データ要求入力元のバッファモジュール４０の後段に存在する複数の画像処理モジュール３８のうち何れの画像処理モジュール３８からバッファモジュール４０に入力されたデータ要求であるかを判断することで、今回のデータ要求の出力元の画像処理モジュール３８を認識する。そしてステップ６４では、データ要求入力元のバッファモジュール４０に対応する複数のデータ要求回数のうち、ステップ６２で認識したデータ要求の出力元の画像処理モジュール３８に対応するデータ要求回数を１だけインクリメントした後にステップ６６へ移行する。

このように、本実施形態に係るバッファサイズ管理処理では、管理対象の何れかのバッファモジュール４０から処理フロー管理部４６Ａへデータ要求が入力される毎に、データ要求入力元のバッファモジュール４０(及びデータ要求の出力元の画像処理モジュール３８)に対応するデータ要求回数を１ずつインクリメントすることで、後段の個々の画像処理モジュール３８からバッファモジュール４０にデータ要求が入力された回数が、管理対象の個々のバッファモジュール４０について各々計数される。なお、上述したステップ５０〜ステップ６４は本発明に係る制御手段のうち、請求項４に記載の「画像処理部の各バッファモジュールについて、データ要求のパターンを各々検出」するステップに対応している。

また、管理対象の何れかのバッファモジュール４０でバッファ４０Ａが解放された場合には、前述のステップ６６の判定が肯定されてステップ６８へ移行し、バッファ４０Ａが今回解放されたバッファモジュール４０の後段に複数の画像処理モジュール３８が存在しているか否か判定する。判定が否定された場合はステップ７２へ移行し、バッファ４０Ａが今回解放されたバッファモジュール４０に対応するデータ要求回数(の計数結果)を参照する。そしてステップ７４では、バッファ４０Ａが今回解放されたバッファモジュール４０におけるバッファ確保サイズを、ステップ７２で参照したデータ要求回数に応じて決定する。具体的には、例えばデータ要求回数(の計数結果)がＮである場合、バッファ確保サイズは、バッファ４０Ａが今回解放されたバッファモジュール４０の後段の画像処理モジュール３８における単位読出データ量のＮ倍、又は、バッファ４０Ａが今回解放されたバッファモジュール４０におけるバッファ確保サイズの初期値のＮ倍に相当するサイズ、或いはそれ以上のサイズに決定することができる。

また、ステップ６８の判定が肯定された場合はステップ７０へ移行し、バッファ４０Ａが今回解放されたバッファモジュール４０において確保されていたバッファ４０Ａが全て解放された否か判定する。判定が否定された場合はステップ８０へ移行し、バッファ４０Ａが今回解放されたバッファモジュール４０において、確保されていたバッファ４０Ａが全て解放される迄バッファ確保サイズの決定を保留する。そして、後段に複数の画像処理モジュール３８が存在しているバッファモジュール４０で確保されていたバッファ４０Ａが全て解放されると、ステップ７０の判定が肯定されてステップ７２へ移行し、データ要求回数(の計数結果)が参照され、次のステップ７４でバッファ確保サイズが決定される。この場合のバッファ確保サイズとしては、例えば後段の複数の画像処理モジュール３８のうちの特定の画像処理モジュール３８に対応するデータ要求回数(の計数結果)がＭ1であるとすると、バッファ確保サイズは、前記特定の画像処理モジュール３８における単位読出データ量のＭ1倍に相当するサイズとしてもよいし、複数の画像処理モジュール３８の各々に対応するデータ要求回数(の計数結果)の最大値がＭmaxであるとすると、バッファ４０Ａが今回解放されたバッファモジュール４０におけるバッファ確保サイズの初期値のＭmax倍に相当するサイズとしてもよいし、それ以上のサイズとしてもよい。

次のステップ７６では、ステップ７４で決定したバッファ確保サイズを、バッファ４０Ａが今回解放されたバッファモジュール４０に設定する。これにより、バッファモジュール４０が次回以降にバッファ４０Ａの確保を行う際には、今回設定したバッファ確保サイズのバッファ４０Ａが確保されることになる。続いてステップ７８では、ステップ７６でバッファ確保サイズを設定したバッファモジュール４０の設定フラグに設定完了を意味する「１」を設定し、ステップ８０へ移行する。これにより、ステップ７４で決定したバッファ確保サイズが設定されたバッファモジュール４０に対しては、以後、ステップ５６の判定が否定されることで、データ要求回数の計数やその結果に基づくバッファ確保サイズの決定・設定(更新)は行われない。なお、上述したステップ６６〜ステップ７８は本発明に係る制御手段に対応している。

上述したバッファサイズ管理処理について、一例を挙げて更に説明する。画像処理部５０で画像処理が開始された場合、バッファモジュール４０は、後段の画像処理モジュール３８からデータ要求が入力される毎に、前述のように、バッファ確保サイズの初期値と同サイズのバッファ４０Ａを確保した後に、処理管理部４６(の処理フロー管理部４６Ａ)へデータ要求を出力する(図３(Ｂ)及び図５(Ａ)の(1)〜(3)も参照)処理を行い、。これに伴い、処理管理部４６(の処理フロー管理部４６Ａ)からバッファモジュール４０の前段の画像処理モジュール３８へ処理要求が入力され、前段の画像処理モジュール３８によってバッファ４０Ａに画像データが書き込まれ、バッファ４０Ａに書き込まれた画像データが後段の画像処理モジュール３８によって読み出される (図３(Ｂ)の(4)〜(7)及び図５(Ａ)の(4)〜(6)も参照)。またバッファモジュール４０は、後段の画像処理モジュール３８からバッファ４０Ａの解放が指示される毎に、後段の画像処理モジュール３８による画像データの読み出しが完了したバッファ４０Ａをバッファ確保サイズの初期値と同サイズずつ解放する。

ここで、個々の画像処理モジュール３８から前段のバッファモジュール４０へのデータ要求及びバッファ解放の出力パターンは、画像処理部５０の構築を指示するアプリケーション３２による処理の内容に依存し、図５に示すようにバッファモジュール４０の後段に単一の画像処理モジュール３８(図５では「画像処理Ｂ」と表記)が連結された構成において、例えば図５(Ａ)〜(Ｃ)に示すように、後段の画像処理モジュール３８からデータ要求が複数(Ｎ)回連続して前段のバッファモジュール４０へ出力された後に、後段の画像処理モジュール３８から前段のバッファモジュール４０へバッファ解放が指示される(図５(Ｄ)参照)ことがある。

これに対して本実施形態に係るバッファサイズ管理処理では、上記の場合、後段の画像処理モジュール３８から前段のバッファモジュール４０へのデータ要求の連続入力の回数がデータ要求回数として計数され、データ要求回数の計数結果に従ってバッファ確保サイズが決定されて設定(変更)されるので、後段の画像処理モジュール３８から前段のバッファモジュール４０へのデータ要求の入力が以降にＮ回連続した場合、データ要求が最初に入力された際により大サイズ(例えばバッファ確保サイズの初期値のＮ倍のサイズ)のバッファ４０Ａが確保される(図５(Ｅ)参照)一方、２回目以降にデータ要求が入力された際にはバッファ４０Ａを新たに確保する必要が無くなるのでバッファ４０Ａの確保が省略され(図５(Ｆ)参照)、バッファ４０Ａを確保する処理が行われる回数が削減される。同様にバッファ４０Ａの解放についても、設定変更後のバッファ確保サイズのバッファ４０Ａを単位としてバッファ４０Ａの解放が行われるので、バッファ４０Ａを解放する処理が行われる回数が削減される。

また、図６に示すようにバッファモジュール４０の後段に複数の画像処理モジュール３８(図６では「画像処理Ｂ」と表記した画像処理モジュール３８と「画像処理Ｃ」と表記した画像処理モジュール３８の２個)が連結された構成においても、例えば図６(Ａ)〜(Ｄ)に示すように、何れかの画像処理モジュール３８からデータ要求及びバッファ解放指示が複数(Ｍ)回連続して前段のバッファモジュール４０へ出力された後に、他の画像処理モジュール３８からデータ要求及びバッファ解放指示が複数(Ｍ)回連続して前段のバッファモジュール４０へ出力されることがある。

これに対して本実施形態に係るバッファサイズ管理処理では、上記の場合にも、後段の個々の画像処理モジュール３８から前段のバッファモジュール４０へのデータ要求の連続入力の回数がデータ要求回数として計数され、データ要求回数の計数結果に従ってバッファ確保サイズが決定されて設定(変更)されるので、後段の複数の画像処理モジュール３８から前段のバッファモジュール４０へのデータ要求及びバッファ解放指示の入力が同じパターンで繰り返された場合、データ要求が最初に入力された際により大サイズ(例えばバッファ確保サイズの初期値のＭ倍のサイズ)のバッファ４０Ａが確保される(図６(Ｅ)参照)一方、２回目以降にデータ要求が入力された際にはバッファ４０Ａを新たに確保する必要が無くなるのでバッファ４０Ａの確保が省略され、バッファ４０Ａを確保する処理が行われる回数が削減される。バッファ４０Ａの解放についても、設定変更後のバッファ確保サイズのバッファ４０Ａを単位としてバッファ４０Ａの解放が行われるので、バッファ４０Ａを解放する処理が行われる回数が削減される。

なお、図４に示すバッファサイズ管理処理では、後段に複数の画像処理モジュール３８が連結されたバッファモジュール４０に対し、確保していた全てのバッファ４０Ａが解放されるのを待ってバッファ確保サイズの決定及び設定を行っていたが、本発明はこれに限定されるものではなく、例えば、後段の何れかの画像処理モジュール３８からバッファ４０Ａの解放が指示されたこと、或いはデータ要求出力元の画像処理モジュール３８が切り替わったことをトリガとして、確保していた全てのバッファ４０Ａが解放される前にバッファ確保サイズの決定及び設定を行うようにしてもよい。

また、上記では前段の画像処理モジュール３８から後段のバッファモジュール４０に対し画像データが単位書込データ量ずつバッファ４０Ａに書き込まれる態様を説明したが、例えば前段の画像処理モジュール３８が圧縮された画像データをバッファ４０Ａに書き込む構成である場合には、前段の画像処理モジュール３８から後段のバッファモジュール４０のバッファ４０Ａに書き込まれる画像データのデータ量が不定となる。このため、この場合、バッファモジュール４０のバッファ制御部４０Ｂにより、バッファ４０Ａとして可変長のデータを記憶可能なストレージ(例えばＨＤＤ等)が確保されるように制御することが好ましい。なお、上記態様は請求項５記載の発明に対応している。

また、上記では処理管理部４６にバッファサイズ管理部４６Ｄを設け、本発明に係る制御手段に相当する処理を処理管理部４６で行う態様を説明したが、本発明はこれに限定されるものではなく、バッファサイズ管理部４６Ｄに相当する機能を個々のバッファモジュール４０に設け、本発明に係る制御手段に相当する処理個々のバッファモジュール４０で行うようにしてもよい。

更に、上記では本発明に係る画像処理プログラムに対応するプログラム(処理管理部４６のプログラムのうちバッファサイズ管理部４６Ｄとして機能するプログラム)が記憶部２０に予め記憶（インストール）されている態様を説明したが、本発明に係る画像処理プログラムは、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ等の記録媒体に記録されている形態で提供することも可能である。

１０ コンピュータ
１４ メモリ
２０ 記憶部
３８ 画像処理モジュール
３８Ｂ 制御部
３８ 当該画像処理モジュール
４０Ａ バッファ
４０ バッファモジュール
４６ 処理管理部
４６Ａ 処理フロー管理部
４６Ｄ バッファサイズ管理部
５０ 画像処理部

Claims (6)

1. 自モジュールの前段から取得した画像データに対して互いに異なる画像処理を行い、当該画像処理を経た画像データ又は前記画像処理の処理結果を自モジュールの後段へ出力する複数種の画像処理モジュールの中から選択した１つ以上の画像処理モジュールの各々の前段及び後段の少なくとも一方に、後段のモジュールからのデータ要求に応じてバッファを確保し前段のモジュールから出力される画像データを前記確保したバッファに書き込ませ前記バッファに書き込ませた画像データを後段のモジュールによって読み出させ後段のモジュールによるデータの読み出しが終了した前記バッファを解放するバッファモジュールが設けられ、各モジュールがパイプライン形態又は有向非循環グラフ形態で連結されて構築された画像処理部と、
   前記画像処理部のバッファモジュールに対する後段のモジュールからのデータ要求のパターンに基づいて前記バッファモジュールにおけるバッファ確保サイズを決定し、前記バッファモジュールで前記バッファ確保サイズのバッファを確保させる制御手段と、
   を含む画像処理装置。
2. 前記バッファモジュールは、後段のモジュールによるデータの読み出しが終了しかつ前記後段のモジュールから前記バッファの解放が指示された場合に前記バッファの解放を行い、
   前記制御手段は、前記バッファモジュールに対する後段のモジュールからのデータ要求のパターンが、後段の同一のモジュールからデータがＮ(≧２)回要求された後にバッファの解放が指示されるパターンである場合に、前記バッファ確保サイズを１回のデータ要求での要求データサイズのＮ倍のサイズ以上に決定する請求項１記載の画像処理装置。
3. 前記バッファモジュールは、後段に複数のモジュールが存在する場合、後段の複数のモジュールによるデータの読み出しが終了した前記バッファの解放を行い、
   前記制御手段は、後段に複数のモジュールが存在するバッファモジュールに対する後段のモジュールからのデータ要求のパターンが、後段の単一のモジュールからデータがＭ(≧２)回要求される毎に、データを要求するモジュールが後段の他のモジュールへ切り替わるパターンである場合に、前記バッファ確保サイズを１回のデータ要求での要求データサイズのＭ倍のサイズ以上に決定する請求項１記載の画像処理装置。
4. 前記制御手段は、前記画像処理部の各バッファモジュールについて、前記データ要求のパターンを各々検出し、前記バッファ確保サイズの決定、及び、前記バッファ確保サイズのバッファを確保させる制御を各々行う請求項１〜請求項３の何れか１項記載の画像処理装置。
5. 前記制御手段は、前段のモジュールから圧縮されたデータがバッファに書き込まれるバッファモジュールに対しては、可変長のデータを記憶可能なストレージを前記バッファとして確保させる請求項１〜請求項４の何れか１項記載の画像処理装置。
6. 自モジュールの前段から取得した画像データに対して互いに異なる画像処理を行い、当該画像処理を経た画像データ又は前記画像処理の処理結果を自モジュールの後段へ出力する複数種の画像処理モジュールのプログラムと、後段のモジュールからのデータ要求に応じてバッファを確保し前段のモジュールから出力される画像データを前記確保したバッファに書き込ませ前記バッファに書き込ませた画像データを後段のモジュールによって読み出させ後段のモジュールによるデータの読み出しが終了した前記バッファを解放するバッファモジュールのプログラムと、を記憶する記憶手段が接続されたコンピュータを、
   前記複数種の画像処理モジュールの中から選択した１つ以上の画像処理モジュールの各々の前段及び後段の少なくとも一方に前記バッファモジュールが設けられ、各モジュールがパイプライン形態又は有向非循環グラフ形態で連結されて構築された画像処理部のバッファモジュールに対する後段のモジュールからのデータ要求のパターンに基づいて前記バッファモジュールにおけるバッファ確保サイズを決定し、前記バッファモジュールで前記バッファ確保サイズのバッファを確保させる制御手段
   として機能させるための画像処理プログラム。

Images