JP2006338505A

JP2006338505A - 画像処理装置、方法及びプログラム

Info

Publication number: JP2006338505A
Application number: JP2005164195A
Authority: JP
Inventors: Takashi Nagao; 隆長尾; Noriaki Seki; 範顕関; Yukio Kumazawa; 幸夫熊澤; Yasuhiko Kaneko; 康彦金子; Junichi Kaneko; 順一金子
Original assignee: Fujifilm Holdings Corp; Fuji Xerox Co Ltd
Current assignee: Fujifilm Holdings Corp; Fujifilm Business Innovation Corp
Priority date: 2005-06-03
Filing date: 2005-06-03
Publication date: 2006-12-14
Anticipated expiration: 2025-06-03
Also published as: US20060274967A1; CN1873690A; US7602392B2; JP4694270B2; CN1873690B

Abstract

【課題】個々の画像処理モジュールの構成を複雑化することなく任意のモジュールを組み合わせて所望の画像処理をすることを可能とする。
【解決手段】前段からの画像データを単位処理データ量ずつ画像処理し、処理結果を後段へ出力する複数種の画像処理モジュールの中から選択された１つ以上の画像処理モジュールの各々の前段及び後段の少なくとも一方に、単位データ量の画像データを受け渡す１つ以上のバッファモジュールが連結されるように、個々のモジュールをパイプライン形態又は有向非循環グラフ形態で連結し、個々のモジュールからメモリ確保が要求されると、要求サイズが閾値以下なら事前に確保したメモリ領域から、大きければオペレーティングシステムを通じてメモリを確保し、メモリの解放が要求されると、テーブルへの登録の有無に応じて事前に確保したメモリ領域に編入するかオペレーティングシステムを通じてメモリを解放する。
【選択図】図２

Description

本発明は画像処理装置、方法及びプログラムに係り、特に、複数種の画像処理モジュールの中から選択された１つ以上の画像処理モジュールを含んで構築された画像処理部を備えた画像処理装置、該画像処理装置に適用可能な画像処理方法、及び、コンピュータを前記画像処理装置として機能させるための画像処理プログラムに関する。

入力された画像データに対して画像処理を行う画像処理装置や、画像を取扱可能なＤＴＰ（デスクトップ・パブリッシング）システム、入力された画像データが表す画像を記録材料に記録するプリントシステム等では、入力された画像データに対して拡大・縮小、回転、アフィン変換、色変換、フィルタ処理、画像合成等の各種の画像処理が行われる。これらの装置やシステムにおいて、入力される画像データの属性や画像データに対する画像処理の内容・手順・パラメータ等が固定されている場合には、専用に設計したハードウエアによって画像処理を行わせる場合もあるが、例えば色空間や１画素当たりのビット数が異なる様々な画像データが入力されたり、画像処理の内容や手順・パラメータ等が様々に変更される場合には、実行する画像処理をより柔軟に変更可能な構成が必要となる。このような要求を満たすために、例えば特許文献１や特許文献２には、プログラマブルな処理モジュールをパイプライン形態やＤＡＧ(Directed Acyclic Graph：有向非循環グラフ)形態に接続して、所望の画像処理を行うことを可能とする技術が提案されている。

特許文献１には、複数のプログラマブル演算処理部の各々における演算処理の内容と、ネットワーク部による各プログラマブル演算処理部の接続形態を、ホストコントロール手段を通じて外部から自在に設定できるように構成することで、高速かつ高度な演算処理が可能で、機能変更や系統変更に対する自由度が高いデジタル映像信号処理装置が開示されている。

また特許文献２には、所望の画像処理を行うために必要な機能モジュールを所望の順番でパイプライン形態に接続／初期化して処理を行うことで所望の画像処理を実現する技術が開示されている。特許文献２に記載の技術では、最後尾のモジュールに対して一定量のデータ出力を要求すると、最後尾のモジュールが、要求されたデータ出力を行うために必要な画像データの入力を前段のモジュールに対して要求し、各モジュールが同様の処理を行うことで画像データの入力要求が最前段へ向けて遡って伝達され、最前段の画像入力モジュールから出力された画像データに対し、各モジュールが画像処理を行って後段のモジュールへ渡すことが順次行われることで、所望の処理が行われた画像データが最終的に最後尾の処理モジュールから出力される。上記の処理が画像の最後まで、又は必要な部分に対して行われると、各モジュールによってリソースの解放や自モジュールの消去等の処理が行われる。

特許文献２に記載の技術は、例えばＵＮＩＸ（登録商標）等のオペレーティングシステムで用いられている単一プロセッサによる多重処理パイプラインのシミュレーションを画像処理等の分野に応用したものであり、特に画像処理では、１回の処理単位を例えば画像の１ライン等のように画像の一部に固定化することで、各処理モジュールが処理用に保持するメモリを極めて少なくすることが可能となる。その結果、少ないメモリで複雑な処理を実行できる低コストの画像処理装置を実現することができ、或いは仮想記憶をサポートするオペレーティングシステム上で動作させる場合には、メモリ不足によるスワップアウトが最小限に抑えられるため、高速に処理を実行することが可能となる。

また、特許文献３には、例えば画像の90度回転等のように出力する１ライン分の画像データを得るために入力画像全体を必要とする処理を行う場合や、入力画像を複数の処理モジュールへ各々出力する分岐モジュール等において、画像全体のバッファリングが終了したらそれよりも前段のモジュールに対して終了処理を行うことで、必要なメモリ資源を最小限に抑えて高速に処理することを可能とする技術が記載されている。

また特許文献４には、各画像処理手段が同期して動くように構成すると、バージョンアップ等で一部を変更する際に、他の画像処理手段にも変更を行うことを不要とするため、各画像処理手段をモジュール化し、隣接する画像処理モジュールの間にバッファメモリを挟んでタイミングを合わせる方法が提案されている。
特開平５−２６０３７３号公報特開平７−１０５０２０号公報特開平８−２７２９８１号公報

上述した特許文献１〜３に記載の技術のように、複数種の画像処理モジュールを任意に組み合わせて所望の画像処理を行う画像処理装置を構成する場合、以下に述べるような問題がある。すなわち、各画像処理モジュールには、実行する画像処理の種類や内容に応じて処理し易い単位（例えば画素単位、１ライン単位、複数ライン単位、面単位等）がある。しかし、各画像処理モジュールを任意の順番で連結し協調して処理することを可能とするためには、全ての画像処理モジュールの出力単位を揃えるか、或いは各画像処理モジュールが任意の入力単位に対応可能に構成する必要があり、各画像処理モジュールの構成が複雑になる。また、各画像処理モジュールは他の画像処理モジュールと連携して動作するため、各画像処理モジュールには、入力された画像データに対して実際に画像処理を行う部分以外に、自モジュールと連結された他の画像処理モジュールとの間で画像データを受け渡す処理を制御する部分も必要となり、各画像処理モジュールの構成は一層複雑になる。

また、特許文献４に記載の技術においては、各バッファメモリはその前後に接続された画像処理モジュールの処理内容に応じた領域を持ち、単に処理の途中経過を保持するのみの機能で構成されている。このため、ある画像処理モジュールを変更した場合には、その前後のバッファメモリは、当該画像処理モジュールの処理内容と、当該画像処理モジュールとバッファメモリを挟んで前後の画像処理モジュールの処理内容に応じて、その容量を変更するか、又は前後の画像処理モジュールを変更する等、変更が当該画像処理モジュールのみに限定されないという課題があった。

本発明は上記事実を考慮して成されたもので、個々の画像処理モジュールの構成の複雑化を招くことなく、任意の画像処理モジュールを組み合わせて所望の画像処理を行わせることが可能な画像処理装置、画像処理方法及び画像処理プログラムを得ることが目的である。

上記目的を達成するために本発明は、画像データに対する所定の画像処理を、予め設定された単位処理データ量ずつ行う画像処理エンジンと、自モジュールの前段から取得した画像データを前記画像処理エンジンが前記単位処理データ量ずつ処理するために必要なデータ量単位で入力すると共に、前記画像処理エンジンによる所定の画像処理を経た画像データ又は前記所定の画像処理の処理結果を自モジュールの後段へ出力する制御手段を備え、前記画像処理エンジンが行う画像処理の種類又は内容が互いに異なる複数種の画像処理モジュールの中から選択された１つ以上の画像処理モジュールと、画像データを記憶するためのバッファと、自モジュールの前段に画像処理モジュールが連結されている場合に、自モジュールに対して事前に設定されるか又は画像データ出力の都度通知される書込データ量のデータを記憶可能な前記バッファ上の記憶領域に前記前段の画像処理モジュールから出力される画像データを書き込ませると共に、自モジュールの後段に画像処理モジュールが連結されている場合に、前記バッファに記憶されている画像データを、前記後段の画像処理モジュールにより、自モジュールに対して事前に設定されるか又は画像データ要求の都度指定される読出データ量だけ読み出させる処理を行うバッファ制御手段を備えた１つ以上のバッファモジュールと、が、前記選択された個々の画像処理モジュールの前段及び後段の少なくとも一方にバッファモジュールが連結されるように、個々のモジュールがパイプライン形態又は有向非循環グラフ形態で連結されて構築された画像処理部を備えた画像処理装置であって、前記画像処理部の構築時又は処理対象の画像データの処理時の個々のモジュールからの要求に応じて、前記画像処理装置に設けられているメモリから前記個々のモジュールに割り当てるメモリを確保して前記個々のモジュールに割り当てると共に、前記個々のモジュールの消去時には前記個々のモジュールに割り当てたメモリを解放するメモリ管理処理を複数種の管理方式で実行可能で、前記複数種の管理方式のうち外部から指示された管理方式で前記メモリ管理処理を行うメモリ管理手段を更に備えたことを特徴している。

本発明に係る画像処理モジュールは、画像データに対する所定の画像処理を、予め設定された単位処理データ量ずつ行う画像処理エンジンと、自モジュールの前段から取得した画像データを画像処理エンジンが単位処理データ量ずつ処理するために必要なデータ量単位で入力すると共に、画像処理エンジンによる所定の画像処理を経た画像データ又は前記所定の画像処理の処理結果を自モジュールの後段へ出力する制御手段を備えている。本発明では、画像処理エンジンが行う画像処理の種類又は内容が互いに異なる複数種の画像処理モジュールが用意されており、画像処理部の構築に際しては、複数種の画像処理モジュールの中から１つ以上の画像処理モジュールが選択される。なお、画像処理部の構築のために選択される画像処理モジュールは、互いに異なる画像処理モジュールであってもよいし、画像処理モジュールの一部又は全部が重複して選択されてもよい。

また、本発明に係るバッファモジュールは、画像データを記憶するためのバッファと、自モジュールの前段に画像処理モジュールが連結されている場合に、自モジュールに対して事前に設定されるか又は画像データ出力の都度通知される書込データ量のデータを記憶可能なバッファ上の記憶領域に前段の画像処理モジュールから出力される画像データを書き込ませると共に、自モジュールの後段に画像処理モジュールが連結されている場合に、バッファに記憶されている画像データを、後段の画像処理モジュールにより、自モジュールに対して事前に設定されるか又は画像データ要求の都度指定される読出データ量だけ読み出させる処理を行うバッファ制御手段を備えている。

なお、上記の単位処理データ量、書込データ量及び読出データ量は画像の１ライン分であってもよいし、画像の複数ライン分、画像１面分、画像の１画素分、等を含む任意のバイト数の何れであってもよい。また、画像処理モジュールによってバッファモジュールのバッファに書き込まれる画像データは未圧縮の画像データであってもよいし、何らかの符号化方法により符号化されて圧縮された画像データであってもよく、単位処理データ量と単位書込データ量は同一であっても相違していてもよい。また、バッファ上の記憶領域に画像データを書き込ませる処理としては、例えば自モジュールの前段の画像処理モジュールに対して記憶領域のアドレスを通知する処理等が挙げられる。更に、バッファから画像データを読み出させることは、自モジュールの後段の画像処理モジュールに対し、読出対象の画像データが記憶されている記憶領域（この記憶領域は後段の画像処理モジュールが記憶内容を変更できない記憶領域であってもよいし、後段の画像処理モジュールが記憶内容を変更できる記憶領域であってもよい）のアドレスを通知することで行ってもよいし、後段の画像処理モジュールから通知されたアドレスの記憶領域に読出対象データを複写することで行ってもよい。

そして本発明では、選択された個々の画像処理モジュールの前段及び後段の少なくとも一方に、画像データを記憶するためのバッファを備えたバッファモジュールが連結されるように、個々のモジュールがパイプライン形態又は有向非循環グラフ形態で連結されて画像処理部が構築され、本発明に係る処理管理手段は、画像処理部の個々の画像処理モジュールにおいて、自モジュールの前段から取得した画像データを画像処理エンジンへ入力すると共に、画像処理エンジンによる所定の画像処理を経た画像データ又は所定の画像処理の処理結果を自モジュールの後段へ出力する処理を繰り返させることで、画像処理部によって処理対象の画像全体を処理させる。

このように、本発明では、バッファモジュールの前段に連結された画像処理モジュールが、後段のバッファモジュールのバッファへの画像データの書き込み時の書込データ量を任意に設定可能とされていると共に、バッファモジュールの後段に連結された画像処理モジュールが、後段のバッファモジュールのバッファからの画像データ読み出し時の読出データ量を任意に設定可能とされているので、バッファモジュールの前段の画像処理モジュールが、画像データの出力単位を固定的に定められた基準値に揃える必要がなくなると共に、バッファモジュールの後段の画像処理モジュールについても、画像データの取得単位を前記基準値に揃える必要がなくなる。従って、個々の画像処理モジュールの画像処理エンジンにおける単位処理データ量を画像処理エンジンが行う画像処理の種類等に応じて最適化することができ、個々の画像処理モジュールの画像処理エンジンが行う画像処理の最適化（高速化や画質向上等）を実現することができる。

また、バッファモジュールが介在している画像処理モジュールの間の画像データの受け渡しはバッファモジュールのバッファを介して行われるので、画像処理モジュールの間の画像データの受け渡しに際し、両者間で通信を行ってタイミングを合わせる等の複雑な制御も不要となり、処理管理手段が、画像処理部の個々の画像処理モジュールに対して、自モジュールの前段から取得した画像データを画像処理エンジンへ入力すると共に、画像処理エンジンによる所定の画像処理を経た画像データ又は所定の画像処理の処理結果を自モジュールの後段へ出力する処理を繰り返させることで、処理対象の画像全体を処理させることができる。従って、本発明によれば、個々の画像処理モジュールの構成の複雑化を招くことなく、任意の画像処理モジュールを組み合わせて所望の画像処理を行わせることが可能となる。

また、本発明に係るメモリ管理手段は、画像処理部の構築時又は処理対象の画像データの処理時の個々のモジュールからの要求に応じて、画像処理装置に設けられているメモリから個々のモジュールに割り当てるメモリを確保して個々のモジュールに割り当てると共に、個々のモジュールの消去時には前記個々のモジュールに割り当てたメモリを解放するメモリ管理処理を複数種の管理方式で実行可能で、複数種の管理方式のうち外部から指示された管理方式でメモリ管理処理を行う。これにより、画像処理装置に設けられているメモリのサイズ等の装置環境に応じてメモリ管理方式を切り替えることが可能となり、本発明に係る画像処理装置の汎用性を向上させることができる。

以上説明したように本発明は、自モジュールの前段から取得した画像データに対して画像処理エンジンで単位処理データ量ずつ画像処理を行うと共に、画像処理を経た画像データ又は処理結果を自モジュールの後段へ出力する複数種の画像処理モジュールの中から選択された１つ以上の画像処理モジュールの各々の前段及び後段の少なくとも一方に、自モジュールの前段の画像処理モジュールから出力される画像データを、設定された書込データ量のデータを記憶可能なバッファ上の記憶領域に書き込ませると共に、バッファに記憶されている画像データを、自モジュールの後段の画像処理モジュールにより設定された読出データ量だけ読み出させる１つ以上のバッファモジュールが連結されるように、個々のモジュールをパイプライン形態又は有向非循環グラフ形態で連結して画像処理部を構築し、個々のモジュールからの要求に応じて個々のモジュールに割り当てるメモリを確保して割り当てると共に、個々のモジュールの消去時に割り当てたメモリを解放するメモリ管理処理を複数種の管理方式で実行可能で、複数種の管理方式のうち外部から指示された管理方式でメモリ管理処理を行うようにしたので、個々の画像処理モジュールの構成の複雑化を招くことなく、任意の画像処理モジュールを組み合わせて所望の画像処理を行わせることが可能となる、という優れた効果を有する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

また図１に示すように、処理管理部４６は、画像処理部５０における画像処理の実行を制御するワークフロー管理部４６Ａ、画像処理部５０の各モジュールによるメモリ１４や各種のファイル等のコンピュータ１０のリソースの使用を管理するリソース管理部４６Ｂ、及び、画像処理部５０で発生したエラーを管理するエラー管理部４６Ｃを含んで構成されている。なお、処理構築部４２によって構築される画像処理部５０は、画像処理部５０を構成する個々の画像処理モジュール３８が、画像１面分よりも小さいデータ量を単位として後段へ画像データを引き渡しながら並列に画像処理を行うように動作する（ブロック単位処理と称する）ことも、前段の画像処理モジュール３８が画像１面分の画像データに対する画像処理を完了した後に、後段の画像処理モジュール３８が画像１面分の画像データに対する画像処理を行うように動作する（面単位処理と称する）ことも可能とされており、ワークフロー管理部４６Ａのプログラムとして、画像処理部５０にブロック単位処理を行わせるためのプログラムと、画像処理部５０に面単位処理を行わせるためのプログラムが各々用意されている。

次に本実施形態の作用を説明する。本実施形態では、コンピュータ１０の電源が投入されるとリソース管理部４６Ｂが起動され、リソース管理部４６Ｂによって図２(Ａ)に示す初期化処理が行われる。

本実施形態では、リソース管理部４６Ｂによるメモリ管理の方式として、画像処理部５０の個々のモジュールからの要求の都度、メモリ１４から要求元のモジュールに割り当てるメモリ領域をオペレーティングシステム３０を通じて確保する第１管理方式、メモリ１４から一定サイズのメモリ領域をオペレーティングシステム３０を通じて事前に確保し、個々のモジュールからの要求があると、事前に確保したメモリ領域のうちの一部領域を要求元のモジュールに割り当てる第２管理方式、及び、メモリ１４から一定サイズのメモリ領域をオペレーティングシステム３０を通じて事前に確保し、個々のモジュールからの要求があると、要求されたメモリ領域のサイズが閾値未満であれば事前に確保したメモリ領域のうちの一部領域を要求元のモジュールに割り当て、要求されたメモリ領域のサイズが閾値以上であれば要求元のモジュールに割り当てるメモリ領域をオペレーティングシステム３０を通じて確保する第３管理方式、の３種類の管理方式が用意されており、何れの管理方式でメモリ管理を行うかを選択・設定可能とされている。なお、本発明はこれに限定されるものではなく、他のメモリ管理方式が含まれていても良い。

これらの各管理方式は、例えば次のように選択される。特にメモリ制限等の無いアプリケーションから使われ、かつ複雑なメモリ管理によるプログラムサイズの増加を抑えたい場合等には、第１管理方式が好適である。また、本発明による画像処理を行うアプリケーションの全体で使用可能なメモリ量が制限されており、その範囲で動作する必要がある場合には、第２管理方式が好適である。一方、メモリ確保や解放に要する処理時間を高速化する必要がある場合には、細かいメモリ領域の確保や解放にオペレーティングシステム３０のメモリ確保／解放機能を使うとオーバーヘッドが大きくなることがあるので、第３管理方式が好適である。

図２(Ａ)に示す初期化処理のステップ１００では、選択・設定されているメモリ管理方式が第２管理方式又は第３管理方式か否か判定する。なお、メモリ管理方式の選択は、コンピュータ１０に画像処理プログラム群３４をインストールする際に選択・設定するようにしてもよいし、リソース管理部４６Ｂがコンピュータ１０のシステム環境（例えばメモリ１４のサイズや画像処理プログラム群３４が実装されている機器の種別等）を取得し、取得したシステム環境に基づいて自動的に選択・設定するようにしてもよい。メモリ管理方式が第１管理方式である場合は上記判定が否定されて初期化処理を終了するが、上記判定が肯定された場合はステップ１０２へ移行し、コンピュータ１０に設けられているメモリ１４から、オペレーティングシステム３０を通じて所定サイズのメモリ領域（連続領域）を確保して終了する。なお、上記の所定サイズについても、システム環境等に応じて選択・設定してもよい。

ここで、メモリ管理方式が第１管理方式である場合には、その後に発生するメモリ確保要求に応答してオペレーティングシステム３０を通じて要求されたメモリ領域を確保し、またメモリ解放要求に応答して同じくオペレーティングシステム３０を通じてメモリ領域を解放する。これらの処理は、通常のプログラムで用いられているものと同様なので、説明を省略する。

また、メモリ管理方式が第２管理方式である場合には、その後に発生するメモリ確保要求に応答して、先のステップ１０２で事前に確保したメモリ領域のうち、状態が「未使用」の未使用領域から要求に対応するサイズのメモリ領域を探索して確保し、確保したメモリ領域の状態を「使用済み」に変更すると共に、確保したメモリ領域を要求元へ引き渡す。メモリ解放要求に対しては、解放が要求されたメモリ領域を事前に確保したメモリ領域のうちの未使用領域に編入すると共に、編入したメモリ領域の状態を「使用済み」から「未使用」に変更する処理を行う。メモリ領域の状態が未使用か使用済みかを表す情報は、例えばテーブルやリスト等で管理することができる。

次にメモリ管理方式が第３管理方式である場合を説明する。メモリ管理方式が第３管理方式である場合、メモリ確保要求が発生すると、リソース管理部４６Ｂによって図２(Ｂ)に示すメモリ確保要求時処理が行われる。メモリ確保要求時処理では、まずステップ１０４でその要求サイズが予め定めた閾値以下か否かを判定する。要求サイズが閾値以下でない場合には、第１管理方式と同様に、ステップ１０６でオペレーティングシステム３０を通じて要求サイズのメモリ領域を確保し、ステップ１０８で確保したメモリ領域の先頭アドレスをリソース管理部４６Ｂ中のテーブルに登録する。なお、テーブルに代えてリストや連想配列等の他の手段を使っても良い。ステップ１０４において要求サイズが閾値以下と判定された場合には、第２管理方式と同様に、先のステップ１０２で事前に確保したメモリ領域のうちの未使用領域から要求サイズのメモリ領域を確保し（ステップ１１０）、確保した領域の状態を「使用済み」に変更する（ステップ１１２）。そしてステップ１１４で、確保したメモリ領域を要求元へ引き渡す。

また、メモリ管理方式が第３管理方式である場合、メモリ解放要求が発生すると、リソース管理部４６Ｂによって図２(Ｃ)に示すメモリ解放要求時処理が行われる。メモリ解放要求時処理では、まずステップ１１６において、解放が要求されているメモリ領域の先頭アドレスが前述のテーブルに登録されているか否かを判定する。ステップ１１６の判定が肯定された場合、解放が要求されているメモリ領域はオペレーティングシステム３０を通じて確保したメモリ領域であるので、ステップ１１８において解放が要求されたメモリ領域をオペレーティングシステム３０を通じて解放し、次のステップ１２０で解放が要求されているメモリ領域の先頭アドレスを前述のテーブルから削除する。また、ステップ１１６の判定が否定された場合、解放が要求されているメモリ領域は先のステップ１０２で事前に確保したメモリ領域から確保したメモリ領域であるので、ステップ１２２において、解放が要求されているメモリ領域を事前に確保したメモリ領域のうちの未使用領域に編入し、編入したメモリ領域の状態を次のステップ１２４で「未使用」に変更する。このような処理の後、ステップ１２６において要求されたメモリ領域の解放を要求元に通知してメモリ解放要求時処理を終了する。

次に、リソース管理部４６Ｂに対してメモリ以外のリソース（例えば特定のファイル等）の確保・解放が要求された場合について説明する。リソース確保要求が入力されると、リソース管理部４６Ｂは図２(Ｄ)に示すリソース確保要求時処理を行う。リソース確保要求時処理では、まずステップ１３０において、確保が要求されたリソースをオペレーティングシステム３０を通じて確保し、次のステップ１３２では確保したリソースのアドレスを要求元のモジュールを識別する情報と対応付けてリソース管理部４６Ｂ中のテーブルに登録し、ステップ１３４で確保したリソースを要求元に引き渡して処理を終了する。また、リソース解放要求が入力されると、リソース管理部４６Ｂは図２(Ｅ)に示すリソース解放要求時処理を行う。リソース解放要求時処理では、まずステップ１３６において、要求元のモジュールを識別する情報と対応付けてリソース管理部４６Ｂ中のテーブルに登録した情報（確保したリソースのアドレス）を読み出す。次のステップ１３８では読み出した情報が表すリソースをオペレーティングシステム３０を通じて全て解放する。また、ステップ１４０では解放したリソースに対応する情報がテーブルから削除されるようにテーブルを更新し、次のステップ１４２でリソースの解放を要求元に通知して処理を終了する。

このように、メモリ以外のリソースの確保／解放では、確保したリソースを確保時にテーブルへ登録しておき、解放時にはテーブルに登録されているリソース（同一要求元からの要求に従って確保したリソース）を全て解放するので、リソース解放要求元が解放対象のリソースを指定して解放を要求する方式と比較して、リソースの解放漏れが生ずることを防止することができる。なお、これらメモリやリソースの確保／解放処理においては、リソースの不足等から処理に失敗する場合があり、その場合にはエラー管理部４６Ｃに通知する等の処理が必要となるが、ここではそれらのエラー処理については説明を簡単にするために省略する。

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

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

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

そしてアプリケーション３２は、上記で判定した画像処理の種類及び実行順序に基づいて、まず実行順序が１番の画像処理に対応するモジュール生成部４４を起動（モジュール生成部４４のプログラムを実行するプロセス、スレッド又はオブジェクトを生成）した後に（図３のステップ１６４も参照）、起動したモジュール生成部４４に対し、当該モジュール生成部４４によるモジュール群の生成に必要な情報として、前記モジュール群に画像データを入力する入力モジュールを識別するための入力モジュール識別情報、前記モジュール群が画像データを出力する出力モジュールを識別するための出力モジュール識別情報、前記モジュール群に入力される入力画像データの属性を表す入力画像属性情報、実行すべき画像処理のパラメータを通知し、対応するモジュール群の生成を指示する（図３のステップ１６６も参照）。

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

一方、モジュール生成部４４は、アプリケーション３２によって起動されると図４(Ａ)に示すモジュール生成処理を行う（図３のステップ１６８も参照）。モジュール生成処理では、まずステップ２００において、このモジュール生成部４４で次に生成すべき画像処理モジュール３８が有るか否かを判定する。判定が否定された場合はモジュール生成処理を終了する。生成すべき画像処理モジュール３８が有る場合には、ステップ２０２で生成すべき画像処理モジュール３８に入力される入力画像データの属性を表す入力画像属性情報を取得し、次のステップ２０４では、ステップ２０２で取得した情報が表す入力画像データの属性に照らしても先のステップ２００で生成すべきと判定した画像処理モジュール３８の生成が必要か否かを判定する。

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

なお、入力画像データの属性を取得する処理は、生成する画像処理モジュール３８の前段にバッファモジュール４０が存在している場合、当該バッファモジュール４０に画像データの書き込みを行う更に前段の画像処理モジュール３８から出力画像データの属性を取得することによって実現できる。

次のステップ２０６では、生成する画像処理モジュール３８の後段にバッファモジュール４０が必要が否かを判定する。この判定は、画像処理モジュールの後段が出力モジュール（画像出力部２４）である場合（例えば図５(Ａ)〜(Ｃ)に示す画像処理部５０における最後段の画像処理モジュール３８を参照）や、例として図５(Ｂ)に示す画像処理部５０においてスキュー角検知処理を行う画像処理モジュール３８のように、画像処理モジュールが、画像データに対して解析等の画像処理を行いその結果を他の画像処理モジュール３８へ出力するモジュールである場合は否定され、バッファモジュール４０の生成を行うことなくステップ２１０へ移行するが、上記以外の場合は判定が肯定されてステップ２０８へ移行し、バッファ制御部４０Ｂを起動する（バッファ制御部４０Ｂのプログラムを実行するプロセス、スレッド又はオブジェクトを生成する）ことで、画像処理モジュールの後段に連結するバッファモジュール４０を生成する。バッファ制御部４０Ｂは、モジュール生成部４４（或いは前述したアプリケーション３２）によって起動されると図６に示すバッファ制御処理を行う。このバッファ制御処理については後述する。

次のステップ２１０では、前段のモジュール（例えばバッファモジュール４０）の情報と後段のバッファモジュール４０の情報、画像処理モジュール３８に入力される入力画像データの属性、処理パラメータを与えて、画像処理モジュール３８を生成する。なお、ステップ２０６で後段のバッファモジュール４０が不要と判断された画像処理モジュール３８に対しては後段のバッファモジュール４０の情報は与えられず、また例えば50％縮小処理のように処理内容が固定的で特別な画像処理パラメータが必要ない場合には処理パラメータは与えられない。

モジュール生成処理（ステップ２１０）では、モジュールライブラリ３６に登録されており、画像処理モジュール３８として利用可能な複数の候補モジュールの中から、ステップ２０２で取得した入力画像データの属性、及び、画像処理モジュール３８で実行すべき処理パラメータに合致する画像処理モジュール３８を選択する。例えば実行中のモジュール生成処理に対応するモジュール生成部４４が色変換処理を行うモジュール群を生成するモジュール生成部であり、処理パラメータにより出力画像データの色空間としてＣＭＹ色空間がアプリケーション３２から指定され、更に入力画像データがＲＧＢ色空間のデータであった場合には、モジュールライブラリ３６に登録されている各種の色空間処理を行う複数種の画像処理モジュール３８の中から、ＲＧＢ→ＣＭＹの色空間変換を行う画像処理モジュール３８が選択される。

また、画像処理モジュールが拡大・縮小処理を行う画像処理モジュール３８であり、指定された拡大縮小率が50％以外であれば、入力された画像データに対して指定された拡大・縮小率で拡大・縮小処理を行う画像処理モジュール３８が選択され、指定された拡大縮小率が50％であれば、拡大縮小率50％に特化した拡大縮小処理、すなわち入力された画像データを１画素おきに間引くことで50％に縮小する縮小処理を行う画像処理モジュール３８が選択される。なお、画像処理モジュール３８の選択は上記に限られるものではなく、例えば画像処理エンジン３８Ａによる画像処理における単位処理データ量が異なる画像処理モジュール３８をモジュールライブラリ３６に複数登録しておき、画像処理部５０へ割当可能なメモリ領域のサイズ等の動作環境に応じて、適切な単位処理データ量の画像処理モジュール３８を選択する（例えば上記サイズが小さくなるに従って単位処理データ量の小さい画像処理モジュール３８を選択する等）ようにしてもよいし、アプリケーション３２或いはユーザに選択させるようにしてもよい。

次のステップ２１２では、後段のバッファモジュール４０のＩＤと生成した画像処理モジュール３８のＩＤの組をワークフロー管理部４６Ａに通知する。このＩＤは、個々のモジュールを一意に判別できる情報であればよく、例えば個々のモジュールの生成順に付与した番号や、バッファモジュール４０や画像処理モジュール３８のオブジェクトのメモリ上でのアドレス等でも良い。ワークフロー管理部４６Ａに通知された情報は、例えば図４(Ｂ)に示すようなテーブル形式やリスト形式、連想配列形式等でワークフロー管理部４６Ａの内部に保持され、後の処理で使われる。ここではテーブル形式で保持するものとして説明を続ける。

なお、先程述べた後段のバッファモジュール４０を持たない画像処理モジュール３８の場合には、例えば下記の方法で処理を行う。図５(Ａ)において出力処理を行う画像処理モジュール３８のように、生成する画像処理モジュール３８がパイプラインの終点又は有向非循環グラフの終点の一つである場合には、当該画像処理モジュール３８をモジュール生成部４４の出力として呼び出し元のアプリケーション３２に戻す。また、図５(Ｂ)においてスキュー角検知処理を行う画像処理モジュール３８のように、生成した画像処理モジュール３８における画像処理の結果が他の画像処理モジュール（図５(Ｂ)では画像回転処理を行う画像処理モジュール３８）で使われる場合、モジュール生成部４４は、当該画像処理モジュール３８に対して処理が終了するまで繰り返し処理実行を指示して、処理結果を取得する。

ステップ２１２の処理が終了すると、モジュール生成部４４は制御をステップ２００に戻して次に生成すべき画像処理モジュールがあるか否かを判定する。なお、個々のモジュール生成部４４は、対応する一定の画像処理を行うモジュール群を生成するので、この判定は、個々のモジュール生成部４４毎にどのような画像処理モジュールをどのような接続関係で生成するかに関する情報を予め登録して読み出すか、またはモジュール生成部４４を動作させるプログラム中に記述しておくことでも実現できる。例えば実行中のモジュール生成処理に対応するモジュール生成部４４が、複数種の画像処理モジュール３８によって実現される画像処理（例えばスキュー角検知処理を行う画像処理モジュール３８と画像回転処理を行う画像処理モジュール３８によって実現されるスキュー補正処理）を行うモジュール群を生成する場合には、２個以上の画像処理モジュール３８を含むモジュール群が生成される。

アプリケーション３２は、モジュール群の生成を指示したモジュール生成部４４から、上記のようにしてモジュール群の生成完了が通知されると、図３のステップ１６２における判定の結果に基づいて、必要とされる画像処理を実現するために他の画像処理を行うモジュール群も生成する必要があるか否か判断する。必要とされる画像処理が複数種の画像処理を組み合わせた処理である場合、アプリケーション３２は、個々の画像処理に対応する他のモジュール生成部４４を起動してモジュール群の生成に必要な情報を通知する処理を順次行う（図３のステップ１７０，１７２も参照）。そして、順次起動されたモジュール生成部４４によって上述したモジュール生成処理（図４）が順次行われる（図３のステップ１７４も参照）ことで、例として図５(Ａ)〜(Ｃ)に示すように、必要とされる画像処理を行う画像処理部５０が構築されることになる。

なお、本実施形態では、特定の画像処理の実行頻度が高い等の場合に、アプリケーション３２が、特定の画像処理を行う画像処理部５０を生成するための複数種のモジュール生成部４４に対し、特定の画像処理を行う画像処理部５０を生成させた後も処理終了を指示しないことでプロセス、スレッド又はオブジェクトとして残しておき、特定の画像処理を行う必要が生ずる毎に、プロセス、スレッド又はオブジェクトとして残しておいた各モジュール生成部４４に対してモジュール群の生成を順次指示することで、特定の画像処理を行う画像処理部５０を再生成させることも可能とされている。これにより、特定の画像処理を行う必要が生ずる毎に対応する各モジュール生成部４４を各々起動する処理が不要となり、特定の画像処理を行う画像処理部５０を再生成するのに要する時間を短縮することができる。

ところで、画像処理モジュール３８の制御部３８Ｂは、モジュール生成部４４によって起動されると図１２に示す画像処理モジュール初期化処理を行う。この画像処理モジュール初期化処理では、まずステップ２５０において、モジュール生成部４４がモジュール生成処理（図４）のステップ２１０の処理を行うことでモジュール生成部４４から与えられた自モジュールの前段及び後段のモジュールの情報を記憶する。また、次のステップ２５２では、自モジュールの画像処理エンジン３８Ａが行う画像処理の種類や内容等に基づき、自モジュールが使用するメモリのサイズ及び自モジュールが使用する他のリソースを認識する。なお、自モジュールが使用するメモリは、画像処理エンジン３８Ａが画像処理を行うために必要なメモリが主であるが、前段のモジュールが画像データ供給部２２である場合や後段のモジュールが画像出力部２４である場合には、前段又は後段のモジュールとの画像データの送受に際して画像データを一時記憶するためのバッファ用のメモリが必要となることもある。また、処理パラメータにテーブル等の情報が含まれている場合には、それを保持するためのメモリ領域が必要となることもある。そしてステップ２５４では、ステップ２５２で認識したサイズをリソース管理部４６Ｂへ通知すると共に、通知したサイズのメモリ領域の確保をリソース管理部４６Ｂへ要求する。

図２に示すリソース管理処理（リソース管理部４６Ｂ）では、画像処理モジュール３８又はバッファモジュール４０からメモリ領域の確保が要求されると、例えば選択・設定されているメモリ管理方式が第１管理方式である場合には、メモリ確保要求元のモジュールから通知されたサイズのメモリ領域（連続領域）をオペレーティングシステム３０を通じてメモリ１４から確保する。そして確保したメモリ領域の先頭アドレスをメモリ確保要求元のモジュールへ通知することで、確保したメモリ領域をメモリ確保要求元のモジュールに引き渡す。また、メモリ管理方式が第２管理方式であれば、事前に確保したメモリ領域のうちの未使用領域から通知されたサイズのメモリ領域（連続領域）を確保し、確保したメモリ領域を「使用済み」に変更すると共に、確保したメモリ領域をメモリ確保要求元へ引き渡す。また、選択・設定されているメモリ管理方式が第３管理方式であれば、前述したメモリ確保要求時処理（図２(Ｂ)参照）が実行されることで、通知されたサイズのメモリ領域の確保・引き渡しが行われる。

図１２に示す画像処理モジュール初期化処理（画像処理モジュール３８の制御部３８Ｂ）では、上記の処理を経てリソース管理部４６Ｂ経由で必要なメモリ領域を確保すると、次のステップ２５６において、先のステップ２５２の処理結果に基づき、メモリ以外の他のリソースを自モジュール（の画像処理エンジン３８Ａ）が必要としているか否か判定する。判定が否定された場合は何ら処理を行うことなくステップ２６２へ移行するが、判定が肯定された場合はステップ２５８へ移行し、自モジュールが必要としているメモリ以外の他のリソースの種類等をリソース管理部４６Ｂへ通知すると共に、通知した他のリソースの確保をリソース管理部４６Ｂへ要求して確保する。

次に、ステップ２６２では自モジュールの前段のモジュールを判定し、自モジュールの前段にモジュールが存在していない場合にはステップ２７２へ移行し、前段のモジュールがバッファモジュール４０以外、例えば画像データ供給部２２や特定のファイル等である場合には、必要に応じてステップ２７０でその初期化処理を行ってステップ２７２に移る。また、自モジュールの前段にモジュールが存在しており、当該前段のモジュールがバッファモジュール４０であった場合には、ステップ２６２からステップ２６４へ移行し、前段のバッファモジュール４０からの１回の画像データの読み出しによって取得する画像データのデータ量（単位読出データ量）を認識する。この単位読出データ量は、自モジュールの前段のバッファモジュール４０の数が１個であれば１個だけであるが、例えば図５(Ｃ)に示す画像処理部５０において画像合成処理を行う画像処理モジュール３８のように、前段のバッファモジュール４０の数が複数で、複数のバッファモジュール４０から各々取得した画像データを用いて画像処理エンジン３８Ａが画像処理を行う等の場合、前段の個々のバッファモジュール４０に対応する単位読出データ量は、自モジュールの画像処理エンジン３８Ａが行う画像処理の種類や内容、前段のバッファモジュール４０の数等に応じて定まる。

ステップ２６６では、ステップ２６４で認識した単位読出データ量を前段の単一のバッファモジュール４０へ通知することで、当該バッファモジュール４０に対して単位読出データ量を設定する（図１５(Ａ)の(1)も参照）。次のステップ２６８では、自モジュールの前段の全てのバッファモジュール４０に単位読出データ量を設定したか否か判定する。自モジュールの前段のバッファモジュール４０の数が１個であれば当該判定は肯定されてステップ２７２へ移行するが、前段のバッファモジュール４０の数が複数であればステップ２６８の判定が否定されてステップ２６６に戻り、ステップ２６８の判定が肯定される迄、ステップ２６６，２６８を繰り返す。これにより、前段の全てのバッファモジュール４０に対して単位読出データ量が各々設定されることになる。

ステップ２７２では、自モジュールの後段のモジュールを判定し、自モジュールの後段のモジュールがバッファモジュール４０以外、例えば画像出力部２４や特定のファイル等の場合には、必要に応じてステップ２７８でその初期化処理を行ってステップ２８０に移る。例えば後段のモジュールが、画像記録部や表示部、書込装置、送信部の何れかから成る画像出力部２４であれば、この画像出力部２４に対し、上記の初期化処理として、単位書込データ量に相当するデータ量ずつ画像データを出力することを通知する処理等を行う。また、後段のモジュールがバッファモジュール４０である場合には、ステップ２７４で１回の画像データの書き込みにおける画像データのデータ量（単位書込データ量）を認識し、ステップ２７６で後段のバッファモジュールに当該単位書込データ量を設定（図１５(Ａ)の(2)も参照）した後に、ステップ２８０に移る。ステップ２８０では、当該画像処理モジュール初期化処理の完了をモジュール生成部４４に通知して、画像処理モジュール初期化処理を終了する。

一方、画像処理部５０を構成する個々のバッファモジュール４０のバッファ制御部４０Ｂは、モジュール生成部４４又はアプリケーション３２によって起動されると図６に示すバッファ制御処理を行う。このバッファ制御処理では、モジュール生成部４４又はアプリケーション３２によって起動されてバッファモジュール４０の生成が指示されると、ステップ３５６で待ち要求数を０に初期化する。また、次のステップ３５８では、自モジュールの前段の画像処理モジュール３８から単位書込データ量が通知されるか又は自モジュールの後段の画像処理モジュール３８から単位読出データ量が通知されたか否か判定する。判定が否定された場合はステップ３６２へ移行し、自モジュールと連結されている全ての画像処理モジュール３８から単位書込データ量又は単位読出データ量が通知されたか否か判定する。判定が否定された場合はステップ３５８に戻り、ステップ３５８又はステップ３６２の判定が肯定される迄ステップ３５８，３６２を繰り返す。

自モジュールと連結されている特定の画像処理モジュール３８から単位書込データ量又は単位読出データ量が通知されると、ステップ３５８の判定が肯定されてステップ３６０へ移行し、通知された単位書込データ量又は単位読出データ量を記憶した後にステップ３５８に戻る。従って、自モジュールと連結されている個々の画像処理モジュール３８の制御部３８Ｂによって画像処理モジュール初期化処理（図１２）のステップ２６６又はステップ２７６の処理が行われることで、前記個々の画像処理モジュール３８から単位書込データ量又は単位読出データ量が通知される毎に、通知された単位書込データ量又は単位読出データ量が記憶されることで、通知された単位書込データ量又は単位読出データ量がバッファモジュール４０に設定される（図１５(Ｂ)の(1),(2)も参照）。

自モジュールと連結されている全ての画像処理モジュール３８から単位書込データ量又は単位読出データ量が通知され、通知された単位書込データ量及び単位読出データ量が各々設定されると、ステップ３６２の判定が肯定されてステップ３６４へ移行し、自モジュールと連結されている個々の画像処理モジュール３８によって各々設定された単位書込データ量及び単位読出データ量に基づいて、自モジュールのバッファ４０Ａの管理単位である単位バッファ領域のサイズを決定し、決定した単位バッファ領域のサイズを記憶する。単位バッファ領域のサイズとしては、自モジュールに設定された単位書込データ量及び単位読出データ量のうちの最大値が好適であるが、単位書込データ量を設定してもよいし、単位読出データ量（自モジュールの後段に複数の画像処理モジュール３８が連結されている場合は、個々の画像処理モジュール３８によって各々設定された単位読出データ量の最大値）を設定してもよいし、単位書込データ量と単位読出データ量（の最大値）の最小公倍数を設定してもよいし、この最小公倍数が所定値未満であれば最小公倍数を、最小公倍数が所定値以上であれば別の値（例えば上述した単位書込データ量及び単位読出データ量のうちの最大値、単位書込データ量、単位読出データ量（の最大値）の何れか）を設定するようにしてもよい。

次のステップ３６６では、自モジュールのバッファ４０Ａとして用いるメモリ領域が既に設けられているか否か判定する。この判定は、自モジュールがモジュール生成部４４によって生成された場合には否定され、ステップ３６８でバッファフラグに０を設定した後にステップ３７４へ移行する。また、自モジュールがアプリケーション３２によって生成され、画像データ供給部２２又は画像出力部２４として機能するバッファモジュール４０であった場合には、自モジュールのバッファ４０Ａとして用いるメモリ領域が既に存在しているので、ステップ３６６の判定が肯定されてステップ３７０へ移行し、先程ステップ３６４で決定した単位バッファ領域のサイズを、自モジュールのバッファ４０Ａとして用いる既設のメモリ領域のサイズに変更する。また、次のステップ３７２でバッファフラグに１を設定した後にステップ３７４へ移行する。

更に、ステップ３７４では自モジュールの後段の個々の画像処理モジュール３８に対応する有効データポインタを各々生成し、生成した有効データポインタを各々初期化する。この有効データポインタは、自モジュールの前段の画像処理モジュールによって自モジュールのバッファ４０Ａに書き込まれた画像データのうち、対応する後段の画像処理モジュール３８によって読み出されていない画像データ（有効データ）について、その先頭位置（次の読出開始位置）と末尾位置を各々指し示すポインタであり、ステップ３７４の初期化処理では通常、有効データが存在していないことを意味する特定の情報が設定されるが、自モジュールが自モジュールがアプリケーション３２によって生成され、画像データ供給部２２として機能するバッファモジュール４０であれば、自モジュールのバッファ４０Ａとして用いるメモリ領域には既に画像処理対象の画像データが書き込まれている場合があり、この場合には当該画像データの先頭位置及び末尾位置が後段の個々の画像処理モジュール３８に対応する有効データポインタに各々設定される。

以上の処理によりバッファモジュール４０における初期化処理が完了し、次のステップ３７６では初期化処理の完了をワークフロー管理部４６Ａへ通知する。また、ステップ３７８では、先のステップ３５６で初期設定を行った待ち要求数に０よりも大きい値が設定されているか否か判定する。判定が否定された場合はステップ３８０へ移行し、自モジュールの前段又は後段に連結されている画像処理モジュール３８から、当該画像処理モジュール３８を消去する処理を行うことを通知する消去通知を受信したか否か判定する。この判定も否定された場合はステップ３７８に戻り、何れかの判定が肯定される迄ステップ３７８，３８０を繰り返す。

一方、アプリケーション３２は、順次起動したモジュール生成部４４によって前述のモジュール生成処理（図４）が順次行われることで、必要とされる画像処理を行う画像処理部５０の構築が完了すると、実行が指示されている画像処理の実行形態がブロック単位処理か面単位処理かを判断し、判断した実行形態に対応するワークフロー管理部４６Ａのプログラムを実行するプロセス、スレッド又はオブジェクトを起動することで、ワークフロー管理部４６Ａに対して画像処理部５０による画像処理の実行を指示する（図３のステップ１７６も参照）。

処理管理部４６のワークフロー管理部４６Ａは、画像処理の実行形態に応じて異なるプログラムが起動されることで、画像処理の実行形態がブロック単位処理である場合は図１６に示すブロック単位制御処理を、画像処理の実行形態が面単位処理である場合は図１７に示す面単位制御処理を行う。なお、このブロック単位処理及び面単位制御処理は、図３のステップ１７８に示す画像処理部制御処理に各々対応している。ワークフロー管理部４６Ａはブロック単位処理又は面単位制御処理において、画像処理部５０を構成する画像処理モジュール３８のうちの所定の画像処理モジュール３８に処理要求を入力することで、画像処理部５０による画像処理をブロック単位又は面単位の実行形態で行わせるが、以下では画像処理部５０全体の動作説明に先立ち、個々のバッファモジュール４０のバッファ制御部４０Ｂによって行われる初期化処理完了以降の処理、個々の画像処理モジュール３８の制御部３８Ｂによって行われる画像処理モジュール制御処理について順に説明する。

本実施形態では、画像処理モジュール３８が後段のバッファモジュール４０に画像データを書き込む場合には、画像処理モジュール３８からバッファモジュール４０へ書込要求が入力され、画像処理モジュール３８が前段のバッファモジュール４０から画像データを読み出す場合には、画像処理モジュール３８からバッファモジュール４０へ読出要求が入力される。このため、バッファモジュール４０のバッファ制御部４０Ｂは、自モジュールの前段の画像処理モジュール３８から書込要求が入力されるか、又は自モジュールの後段の画像処理モジュール３８からデータ要求が入力されると、割込が発生することで図７に示す要求受信割込処理を行う。なお、以下では割込発生を前提に説明するが、通常のプログラムのように関数やメソッドの呼び出しで処理が始まっても良い。その場合には、以下で説明するように要求を待ち行列にキューイングするのではなく、要求毎に処理が行われるよう構成しても良い。

この要求受信割込処理では、まずステップ４００において、自モジュールに書込要求又はデータ要求を入力した要求元を識別する要求元識別情報と要求の種別（書込か読出か）を表す要求種別情報を要求情報として待ち行列の末尾に登録する。この待ち行列は、個々のバッファモジュール４０に割り当てられたメモリ上に各々形成される。また、次のステップ４０２では待ち要求数を１だけインクリメントし、要求受信割込処理を終了する。この要求受信割込処理により、特定のバッファモジュール４０の前段又は後段の画像処理モジュールから特定のバッファモジュール４０に書込要求又は読出要求が入力される毎に、入力された書込要求又は読出要求に対応する要求情報が特定のバッファモジュール４０に対応する待ち行列に順次登録されると共に、待ち要求数が１ずつインクリメントされることになる。

また、上記の要求受信割込処理が実行されることで待ち要求数が１以上の値になると、バッファ制御処理（図６）のステップ３７８の判定が肯定されてステップ３８２へ移行し、待ち行列の先頭から要求情報を取り出す。次のステップ３８４では、ステップ３８２で取り出した要求情報に含まれる要求種別情報に基づいて、取り出した要求情報に対応する要求の種別（書込か読出か）を判定し、判定結果に応じて分岐する。要求の種別が読出であった場合には、ステップ３８４からステップ３８６へ移行し、図８に示すデータ書込処理を行う。

データ書込処理では、まずステップ４１０において、バッファフラグに１が設定されているか否か、すなわち自モジュールがアプリケーション３２によって生成されたバッファモジュール４０か否か判定する。この判定が肯定された場合は、バッファ４０Ａとして用いるメモリ領域が既に確保されているので、何ら処理を行うことなくステップ４２２へ移行する。また、ステップ４１０の判定が否定された場合、すなわち自モジュールがモジュール生成部４４によって生成されたバッファモジュール４０であった場合にはステップ４１２へ移行し、自モジュールのバッファ４０Ａを構成する単位バッファ領域の中に、空き領域が有る単位バッファ領域（画像データが末尾まで書き込まれていない単位バッファ領域）が存在しているか否か判定する。

モジュール生成部４４によって生成されたバッファモジュール４０は、当初はバッファ４０Ａとして用いるメモリ領域（単位バッファ領域）が確保されておらず、メモリ領域の不足が生ずる度に単位バッファ領域を単位として確保されるので、バッファモジュール４０に最初に書込要求が入力されたときにはバッファ４０Ａとして用いるメモリ領域（単位バッファ領域）が存在しておらず、この判定は否定される。また、後述する処理を経てバッファ４０Ａとして用いる単位バッファ領域が確保された後も、当該単位バッファ領域への画像データの書込に伴って当該単位バッファ領域が丁度満杯になった場合には上記判定は否定される。

ステップ４１２の判定が否定された場合はステップ４１４へ移行し、待ち行列から取り出した要求情報に含まれる要求元識別情報に基づいて書込要求元の画像処理モジュール３８を認識し、書込要求元の画像処理モジュール３８によって設定された単位書込データ量を認識した後に、認識した単位書込データ量が、先のステップ３６４（図６）で決定した単位バッファ領域のサイズよりも大きいか否か判定する。この判定は、単位バッファ領域のサイズとして、自モジュールに設定された単位書込データ量及び単位読出データ量のうちの最大値、或いは自モジュールに設定された単位書込データ量を採用した場合には常に否定されてステップ４２０へ移行し、確保すべきメモリ領域のサイズ（単位バッファ領域のサイズ）をリソース管理部４６Ｂに通知すると共に、自モジュールのバッファ４０Ａとして用いるメモリ領域（画像データの保管に用いる単位バッファ領域）の確保をリソース管理部４６Ｂに要求する。これにより、リソース管理部４６Ｂによって前述のステップ１１２〜ステップ１２０（図２）の処理が行われることで単位バッファ領域が確保される。

また、自モジュールのバッファ４０Ａを構成する単位バッファ領域の中に、空き領域有りの単位バッファ領域が存在していた場合には、ステップ４１２の判定が肯定されてステップ４１６へ移行し、前述したステップ４１４と同様にして書込要求元の画像処理モジュール３８によって設定された単位書込データ量を認識した後に、空き領域有りの単位バッファ領域における空き領域のサイズが認識した単位書込データ量以上か否か判定する。判定が肯定された場合は、自モジュールのバッファ４０Ａとして用いる単位バッファ領域を新たに確保する必要は無いので、何ら処理を行うことなくステップ４２２へ移行する。

単位バッファ領域のサイズが単位書込データ量の整数倍である場合には、自モジュールの前段の画像処理モジュール３８から書込要求が入力される毎に、上記のようにステップ４１２，４１４の判定が各々否定されるか又はステップ４１２，４１６の判定が各々肯定され、バッファ４０Ａとして用いる単位バッファ領域のみが必要に応じて確保される。

一方、単位バッファ領域のサイズが単位書込データ量の整数倍でない場合には、バッファ４０Ａ（単位バッファ領域）への単位書込データ量の画像データの書込が繰り返されることで、例として図９(Ａ)にも示すように、空き領域有りの単位バッファ領域における空き領域のサイズが単位書込データ量よりも小さい状態が生ずる（ステップ４１６の判定が肯定される）。また本実施形態では、単位バッファ領域のサイズとして、自モジュールに設定された単位読出データ量（又はその最大値）を採用することも可能であるが、そのサイズが単位書込データ量よりも小さい場合（ステップ４１４の判定が肯定される場合）には、書込要求が入力されたときに常に上記の状態が生じていることになる。

上記のように、空き領域有りの単位バッファ領域における空き領域のサイズが単位書込データ量よりも小さい場合、単位書込データ量の画像データが書き込まれる領域が複数の単位バッファ領域に跨ることになるが、本実施形態では、バッファ４０Ａとして用いるメモリ領域を単位バッファ領域を単位として確保するので、異なるタイミングで確保した単位バッファ領域が実メモリ（メモリ１４）上で連続する領域であることは保証されない。このため、画像データが書き込まれる領域が複数の単位バッファ領域に跨る場合、すなわち、ステップ４１６の判定が否定されるかステップ４１４の判定が肯定された場合にはステップ４１８へ移行し、確保すべきメモリ領域のサイズとして単位書込データ量をリソース管理部４６Ｂに通知すると共に、書込用に用いるメモリ領域（書込用バッファ領域：図９(Ｂ)も参照）の確保をリソース管理部４６Ｂに要求する。そして、書込用バッファ領域を確保すると、次のステップ４２０でバッファ４０Ａとして用いる単位バッファ領域の確保を行う。

ステップ４２２では、空き領域有りの単位バッファ領域における空き領域のサイズが単位書込データ量以上の場合は当該空き領域を書込領域とする一方、空き領域有りの単位バッファ領域における空き領域のサイズが単位書込データ量よりも小さい場合には、新たに確保した書込用バッファ領域を書込領域として、当該書込領域の先頭アドレスを書込要求元の画像処理モジュール３８へ通知すると共に、書込対象の画像データを通知した先頭アドレスから順に書き込むよう要請する。これにより、書込要求元の画像処理モジュール３８は、先頭アドレスが通知された書込領域（単位バッファ領域又は書込用バッファ領域）に画像データを書き込む（図９（Ｂ）も参照）。前述したように、画像データが書き込まれる領域が複数の単位バッファ領域に跨る場合は書込用バッファ領域を別途確保するので、画像データが書き込まれる領域が複数の単位バッファ領域に跨るか否かに拘わらず、書込要求元の画像処理モジュール３８への書込領域の通知は、上記のようにその先頭アドレスを通知するのみで済み、画像処理モジュール３８とのインタフェースが簡単になる。

次のステップ４２４では、前段の画像処理モジュール３８による書込領域への画像データの書き込みが完了したか否か判定し、判定が肯定される迄ステップ４２４を繰り返す。前段の画像処理モジュール３８から書込完了が通知されると、ステップ４２４の判定が肯定されてステップ４２６へ移行し、上記の書込処理における書込領域が、先のステップ４１６で確保した書込用バッファ領域か否か判定する。判定が否定された場合は何ら処理を行うことなくステップ４３２へ移行するが、ステップ４２６の判定が肯定された場合はステップ４２８へ移行し、例として図９(Ｃ)に示すように、書込用バッファ領域に書き込まれた画像データを、空き領域有りの単位バッファ領域と、先のステップ４２２で確保した新たな単位バッファ領域に分けて複写する。またステップ４３０では、先のステップ４１８で書込用バッファ領域として確保したメモリ領域の先頭アドレスをリソース管理部４６Ｂへ通知して、当該メモリ領域の解放をリソース管理部４６Ｂに要求する。

なお、ここでは必要な時に書込用バッファ領域を確保して、不要になったら直ぐに解放する態様を説明したが、保管用単位バッファ領域のサイズが単位書込データ量の整数倍になっていない場合には、書込用バッファ領域は必ず必要となるので、初期化時に確保しておき、バッファモジュール４０が消去される時に解放するよう構成しても良い。

リソース管理部４６Ｂは、画像処理モジュール３８又はバッファモジュール４０からメモリ領域の解放が要求されると、選択・設定されているメモリ管理方式に応じたメモリ解放の処理を行う。例えばメモリ管理方式が第３管理方式であれば図２(Ｃ)のメモリ解放要求時処理（示す処理）を行ってメモリ領域の解放を行う。

データ書込処理（図８）において、ステップ４２６の判定が否定されるか、又はステップ４３０でメモリ領域の解放を要求した後にリソース管理部４６Ｂから解放完了が通知されるとステップ４３２へ移行し、自モジュールの後段の個々の画像処理モジュール３８に対応する有効データポインタのうち、有効データの末尾位置を表すポインタを各々更新する（図９(Ｃ)も参照）。なお、上記のポインタ更新は、ポインタが指し示す有効データの末尾位置を単位書込データ量分だけ後へ移動させることによって成されるが、自モジュールの前段の画像処理モジュール３８によって今回書き込まれた画像データが処理対象の画像データの末尾に相当するデータであった場合には、前段の画像処理モジュール３８による書込処理完了時に、処理対象の画像データが終了したことを表す全体処理終了通知と共に、書き込んだ画像データのサイズが前段の画像処理モジュール３８から入力されるので、書込処理完了時に前段の画像処理モジュール３８から全体処理終了通知が入力された場合には、同時に通知されたサイズ分だけ有効データの末尾位置を後へ移動させることでポインタ更新が行われる。

次のステップ４３４では、書込処理完了時に全体処理終了通知が入力されたか否かに基づいて、バッファ４０Ａへの処理対象の画像データの書込が終了したか否か判定する。判定が否定された場合は何ら処理を行うことなくステップ４３８へ移行するが、判定が肯定された場合はステップ４３６へ移行し、ステップ４３２で更新したポインタ（自モジュールの後段の個々の画像処理モジュール３８に対応する有効データポインタのうち有効データの末尾位置を表すポインタ）に対し、処理対象の画像データの末尾であることを表すデータ最終位置情報を付加した後にステップ４３８へ移行する。そしてステップ４３８では待ち要求数を１だけデクリメントし、データ書込処理を終了してバッファ制御処理（図６）のステップ３７８に戻る。

またバッファ制御処理（図６）において、ステップ３８２で取り出した要求情報に対応する要求の種別が読出であった場合には、ステップ３８４からステップ３８８へ移行し、図１０に示すデータ読込処理を行う。データ読出処理では、まずステップ４５０において、待ち行列から取り出した要求情報に含まれる要求元識別情報に基づいて読出要求元の画像処理モジュール３８を認識し、読出要求元の画像処理モジュール３８によって設定された単位読出データ量を認識すると共に、読出要求元の画像処理モジュール３８に対応する有効データポインタに基づいて、読出要求元の画像処理モジュール３８に対応する有効データのバッファ４０Ａ上での先頭位置及び末尾位置を認識する。次のステップ４５２では、ステップ４５０で認識した有効データの先頭位置及び末尾位置に基づいて、読出要求元の画像処理モジュール３８に対応する有効データ（読出要求元の画像処理モジュール３８が読出可能な画像データ）が単位読出データ量以上有るか否か判定する。

判定が否定された場合はステップ４５４へ移行し、バッファ４０Ａに記憶されており読出要求元の画像処理モジュール３８が読出可能な有効データの末尾が処理対象の画像データの末尾か否か判定する。読出要求元の画像処理モジュール３８に対応する有効データがバッファ４０Ａに単位読出データ量以上記憶されているか、又は、バッファ４０Ａに記憶されている読出要求元の画像処理モジュール３８に対応する有効データが単位読出データ量未満であるものの、当該有効データの末尾が処理対象の画像データの末尾であった場合には、ステップ４５２又はステップ４５４の判定が肯定されてステップ４５６へ移行する。ステップ４５６では、先のステップ４５０で認識した有効データの先頭位置に基づいて、有効データの先頭部分の画像データを記憶している単位バッファ領域を認識し、認識した単位バッファ領域に記憶されている有効データのデータ量がステップ４５０で認識した単位読出データ量以上か否かを判断することで、今回の読出対象の有効データが複数の単位バッファ領域に跨っているか否か判定する。

ステップ４５６の判定が否定された場合は何ら処理を行うことなくステップ４６０へ移行するが、例として図１１(Ａ)に示すように、有効データの先頭部分の画像データを記憶している単位バッファ領域に記憶されている有効データのデータ量が単位読出データ量未満であり、今回の読出対象の有効データが複数の単位バッファ領域に跨っている場合、今回の読出対象の有効データが実メモリ（メモリ１４）上で連続する領域に記憶されているとは限らない。このため、ステップ４５６の判定が肯定された場合はステップ４６０へ移行し、確保すべきメモリ領域のサイズとして読出要求元の画像処理モジュール３８に対応する単位読出データ量をリソース管理部４６Ｂに通知すると共に、読出に用いるメモリ領域（読出用バッファ領域：図９(Ｂ)も参照）の確保をリソース管理部４６Ｂに要求する。また、読出用バッファ領域を確保すると、次のステップ４６０で複数の単位バッファ領域に跨って記憶されている読出対象の有効データを、ステップ４５８で確保した読出用バッファ領域に複写する（図１１(Ｂ)も参照）。

ステップ４６２では、読出対象の有効データが単一の単位バッファ領域に記憶されている場合は、当該単位バッファ領域のうち読出対象の有効データが記憶されている領域を読出領域とする一方、読出対象の有効データが複数の単位バッファ領域に跨って記憶されている場合には読出用バッファ領域を読出領域とし、当該読出領域の先頭アドレスを読出要求元の画像処理モジュール３８へ通知すると共に、通知した先頭アドレスから画像データを順に読み出すよう要請する。これにより、読出要求元の画像処理モジュール３８は、先頭アドレスが通知された読出領域（単位バッファ領域又は読出用バッファ領域）からの画像データの読み出しを行う（図１１（Ｃ）も参照）。なお、読出対象の有効データが処理対象の画像データの末尾に相当するデータであった場合（読出対象の有効データの末尾位置が、読出要求元の画像処理モジュール３８に対応する有効データポインタが指し示す有効データの末尾位置に一致しており、かつ前記ポインタにデータ最終位置情報が付加されていた場合）には、画像データの読出要請に際し、読出対象の有効データのサイズと共に、処理対象の画像データの末尾であることも読出要求元の画像処理モジュール３８に通知する。

前述したように、読出対象の有効データが複数の単位バッファ領域に跨って記憶されている場合は、別途確保した読出用バッファ領域に読出対象の有効データを複写するので、読出対象の有効データが複数の単位バッファ領域に跨って記憶されているか否かに拘わらず、読出要求元の画像処理モジュール３８への読出領域の通知は、上記のようにその先頭アドレスを通知するのみで済み、画像処理モジュール３８とのインタフェースが簡単になる。なお、自モジュールがアプリケーション３２によって生成されたバッファモジュール４０である場合は、バッファ４０Ａとして用いているメモリ領域（単位バッファ領域の集合体）は連続領域であるので、ステップ４５６の判定を行う前にバッファフラグが１か否か判定し、判定が肯定された場合は読出対象の有効データが複数の単位バッファ領域に跨って記憶されているか否かに拘わらずステップ４６２へ移行するようにしてもよい。

次のステップ４６４では、読出要求元の画像処理モジュール３８による読出領域からの画像データの読み出しが完了したか否か判定し、判定が肯定される迄ステップ４６４を繰り返す。読出要求元の画像処理モジュール３８から読出完了が通知されると、ステップ４６４の判定が肯定されてステップ４６６へ移行し、上記の読出処理における読出領域が、先のステップ４５８で確保した読出用バッファ領域か否か判定する。判定が否定された場合は何ら処理を行うことなくステップ４７０へ移行するが、ステップ４６６の判定が肯定された場合はステップ４６８へ移行し、先のステップ４５８で読出用バッファ領域として確保したメモリ領域の先頭アドレス及びサイズをリソース管理部４６Ｂへ通知して、当該メモリ領域の解放をリソース管理部４６Ｂに要求する。この読出用バッファ領域についても書込用バッファ領域と同様に、保管用単位バッファ領域のサイズが単位読出データ量の整数倍になっていない場合には、読出用バッファ領域は必ず必要となるので、初期化時に確保しておき、バッファモジュール４０が消去される時に解放するよう構成しても良い。

次のステップ４７０では、読出要求元の画像処理モジュール３８に対応する有効データポインタのうち、有効データの先頭位置を表すポインタを更新する（図１１(Ｃ)も参照）。なお、上記のポインタ更新は、ポインタが指し示す有効データの先頭位置を単位読出データ量分だけ後へ移動させることによって成されるが、今回の読出対象の有効データが処理対象の画像データの末尾に相当するデータであった場合には、読出要求元の画像処理モジュール３８へも通知した今回の読出対象の有効データのサイズ分だけ有効データの先頭位置を後へ移動させることでポインタ更新が行われる。

ステップ４７２では、後段の個々の画像処理モジュール３８に対応する有効データポインタを各々参照し、ステップ４７０のポインタ更新により、バッファ４０Ａを構成する単位バッファ領域の中に、記憶している画像データの後段の各画像処理モジュール３８による読み出しが全て完了した単位バッファ領域、すなわち有効データを記憶していない単位バッファ領域が出現したか否か判定する。判定が否定された場合は何ら処理を行うことなくステップ４７８へ移行するが、判定が肯定された場合はステップ４７４へ移行し、バッファフラグが１か否か判定する。自モジュールがモジュール生成部４４によって生成されたバッファモジュール４０である場合は判定が否定されてステップ４７６へ移行し、有効データを記憶していない単位バッファ領域の解放をリソース管理部４６Ｂに要求する。

なお、自モジュールがアプリケーション３２によって生成されたバッファモジュール４０である場合にはステップ４７４の判定が肯定され、何ら処理を行うことなくステップ４７８へ移行する。従って、ユーザによって指定されたバッファ領域（メモリ領域）をバッファ４０Ａとして用いている場合には、前記バッファ領域は解放されることなく保存されることになる。そしてステップ４７８では待ち要求数を１だけデクリメントし、データ読み出し処理を終了してバッファ制御処理（図６）のステップ３７８に戻る。

一方、バッファ４０Ａに記憶されており読出要求元の画像処理モジュール３８が読出可能な有効データのデータ量が単位読出データ量未満であり、かつ読出可能な有効データの末尾が処理対象の画像データの末尾でない場合（図１５(Ｂ)の(4)で読出可能な有効データ無が検知された場合）には、ステップ４５２，４５４の判定が各々否定されてステップ４８０へ移行し、新たな画像データを要求するデータ要求をワークフロー管理部４６Ａへ出力する（図１５(Ｂ)の(5)も参照）。この場合、ワークフロー管理部４６Ａにより、自モジュールの前段の画像処理モジュール３８に処理要求が入力されることになる。またステップ４８２では、先のステップ３８２（図６）で待ち行列から取り出した要求情報を元の待ち行列の末尾に再度登録し、データ読出処理を終了する。

図６に示すように、データ読出処理を終了するとステップ３７８（図６）に戻るので、この場合、待ち行列の末尾に再度登録された要求情報は、待ち行列に他の要求情報が登録されていなければ直ちに、待ち行列に他の要求情報が登録されていれば他の要求情報が取り出されてこの要求情報に応じた処理が行われた後に、待ち行列から再度取り出され、図１０のデータ読出処理が再度実行される。従って、後段の画像処理モジュール３８から読出要求が入力されたものの、読出要求元の画像処理モジュール３８が読出可能な有効データのデータ量が単位読出データ量未満であり、かつ読出可能な有効データの末尾が処理対象の画像データの末尾でない場合には、読出可能な有効データのデータ量が単位読出データ量以上になるか、読出可能な有効データの末尾が処理対象の画像データの末尾であることが検知される迄（ステップ４５２又はステップ４５４の判定が肯定される迄）、対応する要求情報が保存されてデータ読出処理が繰り返し実行されることになる。

詳細は後述するが、ワークフロー管理部４６Ａはバッファモジュール４０からデータ要求が入力されると、データ要求元のバッファモジュール４０の前段の画像処理モジュール３８に処理要求を入力する（図１５(Ｂ)の(6)も参照）。この処理要求の入力をトリガとして前段の画像処理モジュール３８の制御部３８Ｂで行われる処理により、前段の画像処理モジュール３８がバッファモジュール４０へ画像データを書込可能な状態になると、前段の画像処理モジュール３８から書込要求が入力されることで前述したデータ書込処理（図８）が行われ、前段の画像処理モジュール３８からバッファモジュール４０のバッファ４０Ａに画像データが書き込まれる（図１５(Ｂ)の(7),(8)も参照）。これにより、後段の画像処理モジュール３８によるバッファ４０Ａからの画像データの読出が行われることになる（図１５(Ｂ)の(9)も参照）。

上述したように、本実施形態に係るバッファ制御処理では、前段の画像処理モジュール３８から書込要求が入力されるか、又は後段の画像処理モジュールから読出要求が入力される毎に、入力された要求を要求情報として待ち行列に登録し、待ち行列から要求情報を１つづつ取り出して処理するので、データ書込処理の実行中に読出要求が入力されたり、データ読出処理の実行中に書込要求が入力された場合にも、実行中の処理が完了し入力された要求に対応する処理を実行可能な状態となる迄、入力された要求に対応する処理の実行を停止する排他制御が行われる。これにより、コンピュータ１０のＣＰＵ１２が画像処理部５０を構成する個々のモジュールに対応するプロセス又はスレッドを並列に実行しても、単一のバッファモジュール４０に複数の要求が同時又は略同時に入力されることによる不都合の発生を回避できるので、コンピュータ１０のＣＰＵ１２が個々のモジュールに対応するプロセス又はスレッドを並列に実行することができる。もちろん、バッファモジュールを通常のプログラムまたはオブジェクトとして実現しても良い。

続いて、画像処理部５０を構成する個々の画像処理モジュール３８に対してワークフロー管理部４６Ａから処理要求が入力される毎に、個々の画像処理モジュール３８の制御部３８Ｂによって各々行われる画像処理モジュール制御処理（図１３）を説明する。画像処理モジュール制御処理では、まずステップ２８４において、自モジュールの前段にモジュール（バッファモジュール４０や画像データ供給部２２、画像処理モジュール３８等）が存在している場合に、当該前段のモジュールに対してデータ（画像データ又は解析等の画像処理の処理結果）を要求する。次のステップ２８６では、前段のモジュールからデータが取得可能であるかを判定する。判定が否定された場合は、ステップ２８８で全体処理終了が通知されたか否かを判定する。ステップ２８８の判定が否定された場合はステップ２８６に戻り、前段のモジュールからデータを取得可能となる迄ステップ２８６，２８８を繰り返す。ステップ２８６の判定が肯定された場合には、ステップ２９０で前段のモジュールからデータを取得するデータ取得処理を行う。

ここで、自モジュールの前段のモジュールがバッファモジュール４０である場合には、先のステップ２８４でデータを要求すると（読出要求）、読出可能な有効データがバッファモジュール４０のバッファ４０Ａに単位読出データ量以上記憶されているか、読出可能な有効データの末尾が処理対象の画像データの末尾に一致している状態であれば直ちに、当該状態でなければ、当該バッファモジュール４０の前段の画像処理モジュール３８が当該バッファモジュール４０のバッファ４０Ａに画像データを書き込んだことに伴って前記状態へ変化した後に、バッファモジュール４０から読出領域の先頭アドレスが通知されて画像データの読出が要請される（図１０のステップ４６２も参照）。これにより、ステップ２８６の判定が肯定されてステップ２９０へ移行し、前段のバッファモジュール４０より先頭アドレスが通知された読出領域から単位読出データ量（又はそれ未満のデータ量）の画像データを読み出すデータ取得処理を行う（図１５(Ａ)の(3)も参照）。

また、自モジュールの前段のモジュールが画像データ供給部２２であれば、先のステップ２８４でデータ要求を出力すると画像データを取得可能な状態であることが前段の画像データ供給部２２から直ちに通知されることで、ステップ２８６の判定が肯定されてステップ２９０へ移行し、前段の画像データ供給部２２から単位読出データ量の画像データを取得する画像データ取得処理を行う。また、自モジュールの前段のモジュールが画像処理モジュール３８であれば、先のステップ２８４でデータ要求（処理要求）を出力すると、前段の画像処理モジュール３８が画像処理を実行可能な状態であれば書込要求が入力されることでデータ（画像処理結果）を取得可能な状態であることが通知されるので、ステップ２８６の判定が肯定されてステップ２９０へ移行し、前段の画像処理モジュール３８によってデータを書き込ませるバッファ領域のアドレスを通知して書込を要請することで、前段の画像処理モジュール３８から出力されるデータを前記バッファに書き込ませるデータ取得処理を行う。

次のステップ２９２では、自モジュールの前段に複数のモジュールが連結されているか否か判定する。判定が否定された場合には何ら処理を行うことなくステップ２９６へ移行するが、判定が肯定された場合はステップ２９４へ移行し、前段に連結されている全てのモジュールからデータを取得したか否か判定する。ステップ２９４の判定が否定された場合はステップ２８４に戻り、ステップ２９４の判定が肯定される迄ステップ２８４〜ステップ２９４を繰り返す。前段のモジュールから取得すべきデータが全て揃うと、ステップ２９２の判定が否定されるかステップ２９４の判定が肯定されてステップ２９６へ移行する。

次に、ステップ２９６で自モジュールの後段のモジュールに対してデータ出力用の領域を要求し、ステップ２９８でデータ出力領域が取得できる迄（データ出力領域の先頭アドレスが通知される迄）繰り返し判定を行う。なお、後段のモジュールがバッファモジュール４０であれば、上記のデータ出力用領域の要求は当該バッファモジュール４０に対して書込要求を出力することによって成される。データ出力領域（後段のモジュールがバッファモジュール４０であれば当該バッファモジュール４０から先頭アドレスが通知された書込領域）が取得できたら（図１５(Ａ)の(4)も参照）、次のステップ３００において、先のデータ取得処理で取得したデータと後段のモジュールから取得したデータ出力領域（の先頭アドレス）を画像処理エンジン３８Ａに入力し、入力したデータに対して所定の画像処理を行わせる（図１５(Ａ)の(5)も参照）と共に、処理後のデータをデータ出力領域に書き込ませる（図１５(Ａ)の(6)も参照）。画像処理エンジン３８Ａへの単位読出データ量のデータの入力が完了し、画像処理エンジン３８Ａから出力されたデータがデータ出力領域に全て書き込まれると、次のステップ３０２で出力が完了したことを後段のモジュールに通知する。

上記のステップ２８４〜ステップ３０２により画像処理モジュール３８における単位処理データ量のデータに対する処理（単位処理）が完了するが、ワークフロー管理部４６Ａから画像処理モジュール３８に入力される処理要求では、ワークフロー管理部４６Ａによって単位処理の実行回数が指定されることがある。このためステップ３０４では、単位処理の実行回数が、入力された処理要求によって指示された実行回数に達したか否か判定する。指示された単位処理の実行回数が１回の場合、この判定は無条件に肯定されるが、指示された単位処理の実行回数が２回以上の場合はステップ２８４に戻り、ステップ３０４の判定が肯定される迄ステップ２８４〜ステップ３０４を繰り返す。ステップ３０４の判定が肯定されるとステップ３０６へ移行し、ワークフロー管理部４６Ａへ処理完了通知を出力することで、入力された処理要求に対応する処理が完了したことをワークフロー管理部４６Ａへ通知し、画像処理モジュール制御処理を終了する。

また、ワークフロー管理部４６Ａから処理要求が入力される毎に上述した処理が繰り返されることで処理対象の画像データを末尾まで処理すると、前段のモジュールから処理対象の画像データの終了が通知されることで、ステップ２８８の判定が肯定されてステップ３０８へ移行し、処理対象の画像データに対する処理が終了したことを意味する全体処理終了通知をワークフロー管理部４６Ａ及び後段のモジュールへ各々出力する。また、次のステップ３１０では自モジュール消去処理（後述）を行い、画像処理モジュール制御処理を終了する。

なお、スキュー角検知処理等の画像解析処理を行う画像処理エンジン３８Ａは、単位読出データ量単位では画像処理結果が出力されず、処理対象の画像データ全体が入力された後に画像処理結果が出力される構成であることが多いが、このような画像処理エンジン３８Ａを備えた画像処理モジュール３８の制御部３８Ｂでは、画像処理モジュール制御処理（図１３）のステップ２９６，２９８及びステップ３００における後段のモジュールへのデータの出力を行わず、処理対象の画像データを末尾まで処理することでステップ２８８の判定が肯定されると、画像処理エンジン３８Ａから出力されたデータ（画像処理結果）を自モジュールの外部（ワークフロー管理部４６Ａ又はアプリケーション３２）へ出力する。そして、上記の画像処理結果を必要としている別の画像処理モジュール３８（例えばスキュー角検知処理の結果に基づいて画像回転処理を行う画像処理モジュール３８等）があれば、ワークフロー管理部４６Ａ又はアプリケーション３２から当該画像処理モジュール３８へ上記の画像処理結果が入力される。

一方、画像処理の実行形態としてブロック単位処理が指定された場合、ワークフロー管理部４６Ａは、アプリケーション３２によって起動されると、図１６(Ａ)に示すブロック単位制御処理１を行う。先にも述べたように、ワークフロー管理部４６Ａによる画像処理部５０の個々の画像処理モジュール３８への処理要求の入力では、単位処理の実行回数を指定可能とされているが、ブロック単位制御処理１のステップ５００では、１回の処理要求で指定する単位処理の実行回数を個々の画像処理モジュール３８毎に決定する。この処理要求１回当りの単位処理の実行回数は、例えば処理対象の画像データ全体を処理する間の個々の画像処理モジュール３８への処理要求の入力回数が平均化されるように定めることができるが、他の基準に従って定めてもよい。そして次のステップ５０２において、画像処理部５０のうち最後段の画像処理モジュール３８に処理要求を入力し（図１８の(1)も参照）、ブロック単位制御処理１を終了する。

ここで、図１８に示す画像処理部５０において、ワークフロー管理部４６Ａから最後段の画像処理モジュール３８₄に処理要求が入力されると、画像処理モジュール３８₄の制御部３８Ｂは前段のバッファモジュール４０₃に読出要求を入力する（図１８の(2)参照）。このとき、バッファモジュール４０₃のバッファ４０Ａには画像処理モジュール３８₄が読出可能な有効データ（画像データ）が記憶されていないので、バッファモジュール４０₃のバッファ制御部４０Ｂはワークフロー管理部４６Ａにデータ要求を入力する（図１８の(3)参照）。

ワークフロー管理部４６Ａは、画像処理の実行形態がブロック単位処理である場合、バッファモジュール４０からデータ要求が入力される毎に、図１６(Ｂ)に示すブロック単位制御処理２を行う。このブロック単位制御処理２では、ステップ５０４において、図４(Ｂ)に示したテーブルに登録されている情報に基づいて、データ要求入力元のバッファモジュール４０（ここではバッファモジュール４０₃）の前段の画像処理モジュール３８（ここでは画像処理モジュール３８₃）を認識し、認識した前段の画像処理モジュール３８に処理要求を入力（図１８の(4)参照）して処理を終了する。

画像処理モジュール３８₃の制御部３８Ｂは、処理要求が入力されると前段のバッファモジュール４０₂に読出要求を入力し（図１８の(5)参照）、バッファモジュール４０₂のバッファ４０Ａにも読出可能な画像データが記憶されていないので、バッファモジュール４０₂のバッファ制御部４０Ｂはワークフロー管理部４６Ａにデータ要求を入力する（図１８の(6)参照）。ワークフロー管理部４６Ａは、バッファモジュール４０₂からデータ要求が入力された場合も、前述のブロック単位制御処理２を再度行うことで、その前段の画像処理モジュール３８₂に処理要求を入力し（図１８の(7)参照）、画像処理モジュール３８₃の制御部３８Ｂは前段のバッファモジュール４０₁に読出要求を入力する（図１８の(8)参照）。また、バッファモジュール４０₁のバッファ４０Ａにも読出可能な画像データが記憶されていないので、バッファモジュール４０₁のバッファ制御部４０Ｂもワークフロー管理部４６Ａにデータ要求を入力し（図１８の(9)参照）。ワークフロー管理部４６Ａは、バッファモジュール４０₁からデータ要求が入力された場合も、前述のブロック単位制御処理２を再度行うことで、その前段の画像処理モジュール３８₁に処理要求を入力する（図１８の(10)参照）。

ここで、画像処理モジュール３８₁の前段のモジュールは画像データ供給部２２であるので、画像処理モジュール３８₁の制御部３８Ｂは、画像データ供給部２２にデータ要求を入力することで画像データ供給部２２から単位読出データ量の画像データを取得し（図１８の(11)参照）、取得した画像データに対して画像処理エンジン３８Ａが画像処理を行うことで得られた画像データを、後段のバッファモジュール４０₁のバッファ４０Ａに書き込む（図１８の(12)参照）。なお、画像処理モジュール３８₁の制御部３８Ｂは後段のバッファモジュール４０₁のバッファ４０Ａへの画像データの書き込みを完了すると、ワークフロー管理部４６Ａへ処理完了通知を入力する。

ワークフロー管理部４６Ａは、画像処理の実行形態がブロック単位処理である場合、画像処理モジュール３８から処理完了通知が入力される毎に、図１６(Ｃ)に示すブロック単位制御処理３を行う。このブロック単位制御処理３では、ステップ５０６において、処理完了通知元が画像処理部５０の最後段の画像処理モジュール３８か否か判定する。この場合は判定が否定され、何ら処理を行うことなく処理を終了する（画像処理モジュール３８₂，３８₃から処理完了通知が入力された場合についても同様）。

また、バッファモジュール４０₁のバッファ制御部４０Ｂは、後段の画像処理モジュール３８₂が読出可能な単位読出データ量以上の有効データが書き込まれると画像処理モジュール３８₂に対して読出を要請し、これに伴い画像処理モジュール３８₂の制御部３８Ｂは、バッファモジュール４０₁のバッファ４０Ａから単位読出データ量の画像データを読み出し（図１８の(13)参照）、取得した画像データに対して画像処理エンジン３８Ａが画像処理を行うことで得られた画像データを、後段のバッファモジュール４０₂のバッファ４０Ａに書き込む（図１８の(14)参照）。バッファモジュール４０₂のバッファ制御部４０Ｂは、後段の画像処理モジュール３８₃が読出可能な単位読出データ量以上の有効データが書き込まれると画像処理モジュール３８₃へ読出を要請し、画像処理モジュール３８₃の制御部３８Ｂは、バッファモジュール４０₂のバッファ４０Ａから単位読出データ量の画像データを読み出し（図１８の(15)参照）、取得した画像データに対して画像処理エンジン３８Ａが画像処理を行うことで得られた画像データを、後段のバッファモジュール４０₃のバッファ４０Ａに書き込む（図１８の(16)参照）。

更に、バッファモジュール４０₃のバッファ制御部４０Ｂは、後段の画像処理モジュール３８₄が読出可能な単位読出データ量以上の有効データが書き込まれると画像処理モジュール３８₄に対して読出を要請し、これに伴い画像処理モジュール３８₄の制御部３８Ｂは、バッファモジュール４０₃のバッファ４０Ａから単位読出データ量の画像データを読み出し（図１８の(17)参照）、取得した画像データに対して画像処理エンジン３８Ａが画像処理を行うことで得られた画像データを、後段のモジュールである画像出力部２４へ出力する（図１８の(18)参照）。また、画像処理モジュール３８₄の制御部３８Ｂは後段の画像出力部２４への画像データの書き込みを完了すると、ワークフロー管理部４６Ａへ処理完了通知を入力する（図１８の(19)参照）が、この場合は前述のブロック単位制御処理３のステップ５０６の判定が肯定されてステップ５０８へ移行し、最後段の画像処理モジュール３８である画像処理モジュール３８₄に処理要求を再度入力した後に処理を終了する。

この最後段の画像処理モジュール３８₄への処理要求の再入力により、上述した処理シーケンスが再度繰り返され、処理対象の画像データに対し、ブロック単位の実行形態での画像処理が順次行われることになる。画像データ供給部２２から供給される画像データが処理対象の画像データの末尾に達すると、個々の画像処理モジュール３８からワークフロー管理部４６Ａへの全体処理終了通知の入力が、前段側の画像処理モジュール３８から順次行われる。

ワークフロー管理部４６Ａは、画像処理の実行形態がブロック単位処理である場合、画像処理モジュール３８から全体処理終了通知が入力される毎に、図１６(Ｄ)に示すブロック単位制御処理４を行う。このブロック単位制御処理４では、ステップ５１０において、全体処理終了通知入力元の画像処理モジュール３８が最後段の画像処理モジュール３８か否か判定する。判定が否定された場合は何ら処理を行うことなく処理を終了するが、処理対象の画像データに対して必要な画像処理が行われた画像データが画像出力部２４へ全て出力されることで、最後段の画像処理モジュール３８から全体処理終了通知が入力された場合には、ステップ５１０の判定が肯定されてステップ５１２へ移行し、アプリケーション３２に対して画像処理の完了を通知し（図３のステップ１８０も参照）、ブロック単位制御処理を終了する。そして、画像処理の完了が通知されたアプリケーション３２は、ユーザに対して画像処理の完了を通知する（図３のステップ１８２も参照）。

このように、ブロック単位処理では、最後段の画像処理モジュール３８に入力された処理要求がより前段の画像処理モジュール３８へ遡り、最前段の画像処理モジュール３８に到達すると、最前段の画像処理モジュール３８で画像処理が行われて後段のバッファモジュール４０にデータが書き込まれ、それでデータが足りるようならば処理が後段のモジュールへ進んで行くという流れで一連の画像処理が行われる。

また、画像処理の実行形態として面単位処理が指定された場合、ワークフロー管理部４６Ａは、アプリケーション３２によって起動されると、図１７(Ａ)に示す面単位制御処理１を行う。面単位制御処理１では、前述のブロック単位制御処理１（図１６(Ａ)）と同様に、１回の処理要求で指定する単位処理の実行回数を個々の画像処理モジュール３８毎に決定し（ステップ５４０）、次のステップ５４２において、画像処理部５０のうち最後段の画像処理モジュール３８に処理要求を入力し（図１８の(1)参照）、処理を終了する。また、ワークフロー管理部４６Ａは、画像処理の実行形態が面単位処理である場合、バッファモジュール４０からデータ要求が入力される毎に、図１７(Ｂ)に示す面単位制御処理２を行う。面単位制御処理２では、前述のブロック単位制御処理２（図１６(Ｂ)）と同様に、ステップ５４４において、図４(Ｂ)に示したテーブルに登録されている情報に基づいて、データ要求入力元のバッファモジュール４０の前段の画像処理モジュール３８を認識し、認識した前段の画像処理モジュール３８に処理要求を入力して処理を終了する。

このように、画像処理の実行形態が面単位処理であっても、アプリケーション３２によって起動された場合にワークフロー管理部４６Ａが行う処理及びバッファモジュール４０からデータ要求が入力される毎にワークフロー管理部４６Ａが行う処理は、画像処理の実行形態がブロック単位処理のときと同一であるので、面単位処理においても、ワークフロー管理部４６Ａから画像処理部５０の最後段の画像処理モジュール３８に処理要求が入力された後は、図１８の(2)〜(10)に示すように、処理要求が入力された画像処理モジュール３８から前段のバッファモジュール４０へのデータ要求の入力、データ要求が入力されたバッファモジュール４０からワークフロー管理部４６Ａへのデータ要求の入力に伴うワークフロー管理部４６Ａから上記バッファモジュール４０の前段の画像処理モジュールへの処理要求の入力が、画像処理部５０の最後段の画像処理モジュール３８から画像処理部５０の最前段の画像処理モジュール３８へ向けて順次進んでいくことになる。

また、画像処理部５０の最前段の画像処理モジュール３８₁は、ワークフロー管理部４６Ａから処理要求が入力されると、画像データ供給部２２から単位読出データ量の画像データを取得し（図１８の(11)参照）、取得した画像データに対して画像処理エンジン３８Ａが画像処理を行うことで得られた画像データを、後段のバッファモジュール４０₁のバッファ４０Ａに書き込み（図１８の(12)参照）、ワークフロー管理部４６Ａへ処理完了通知を入力するが、ワークフロー管理部４６Ａは、画像処理の実行形態が面単位処理である場合、画像処理モジュール３８から処理完了通知が入力される毎に、図１７(Ｃ)に示す面単位制御処理３を行う。この面単位制御処理３では、ステップ５４６において、処理完了通知元の画像処理モジュール３８に処理要求を再度入力し、処理を終了する。このように、面単位制御処理では、ワークフロー管理部４６Ａに処理完了通知を入力した特定の画像処理モジュール３８が処理対象の画像データに対する画像処理を完了する迄の間、前記特定の画像処理モジュール３８から処理完了通知が入力される毎に、前記特定の画像処理モジュール３８に対してのみ処理要求が繰り返し入力される。

画像処理モジュール３８₁が処理対象の画像データに対する画像処理を完了し、画像処理モジュール３８₁における画像処理を経た処理対象の画像データがバッファモジュール４０₁のバッファ４０Ａに全て記憶されると、画像処理モジュール３８₁からワークフロー管理部４６Ａに全体処理終了通知が入力される。ワークフロー管理部４６Ａは、画像処理の実行形態が面単位処理である場合、画像処理モジュール３８から全体処理終了通知が入力される毎に、図１７(Ｄ)に示す面単位制御処理４を行う。この面単位制御処理４では、ステップ５４８において、全体処理終了通知元が画像処理部５０の最後段の画像処理モジュール３８か否か判定する。判定が否定された場合はステップ５５０へ移行し、図４(Ｂ)に示したテーブルに登録されている情報に基づいて、全体処理終了通知元の画像処理モジュール３８の次の画像処理モジュール３８を認識し、認識した次の画像処理モジュール３８に処理要求を入力して処理を終了する。

このように、面単位制御処理では、最後段の画像処理モジュール３８に入力された処理要求がより前段の画像処理モジュール３８へ遡り、最前段の画像処理モジュール３８に到達した後は、最前段の画像処理モジュール３８に対してのみ処理要求を繰り返し入力し、当該画像処理モジュール３８における処理対象の画像データ全体に対する画像処理が完了すると、次の画像処理モジュール３８で処理対象の画像データ全体に対する画像処理を行わせ、この処理を後段の画像処理モジュール３８に対して順に進めていくことで、一連の画像処理が行われる。そして、処理対象の画像データに対して必要な画像処理が行われた画像データが画像出力部２４へ全て出力されることで、最後段の画像処理モジュール３８から全体処理終了通知が入力されると、面単位制御処理４（図１７(Ｄ))のステップ５４８の判定が肯定されてステップ５５２へ移行し、アプリケーション３２に対して画像処理の完了を通知し（図３のステップ１８０も参照）、面単位制御処理を終了する。そして、画像処理の完了が通知されたアプリケーション３２は、ユーザに対して画像処理の完了を通知する（図３のステップ１８２も参照）。

なお、図１７に示した面単位制御処理では、画像処理モジュールから全体処理終了通知が入力されたことを契機として、処理要求を繰り返し入力する画像処理モジュール３８を切り替えていたが、これに限定されるものではなく、異なる画像処理モジュール３８から処理完了通知が入力されたことを契機として、処理要求を繰り返し入力する画像処理モジュール３８を切り替えるように構成することも可能である。

また、上記では最後段の画像処理モジュール３８への処理要求の入力はワークフロー管理部４６Ａが行うものとして説明したが、本発明はこれに限定されるものではなく、パイプラインの最後段又は有向非循環グラフの複数の終点に位置するモジュールをワークフロー管理部４６Ａが保持して処理要求を行っても、またはアプリケーション３２が保持して処理要求を行っても良い。或いは、前述した図５(Ｂ)の例のように、モジュール生成部４４の内部で、スキュー角検知処理を行う画像処理モジュールと、画像回転処理を行う画像処理モジュールとを組み合わせて、スキュー補正処理モジュールとするような場合には、画像回転処理モジュールの生成時に処理パラメータとしてスキュー角情報が必要なので、スキュー補正モジュール生成部の内部で、スキュー角検知処理モジュールに処理要求を繰り返し行って画像全体を処理し、その結果得られるスキュー角情報を画像回転処理モジュールに処理パラメータとして与えるといった方式も存在する。

続いて、処理対象の画像データに対する画像処理を完了した後に行われる画像処理部５０の消去について説明する。個々の画像処理モジュール３８の制御部３８Ｂは、画像処理モジュール制御処理（図１３）のステップ３０８で、ワークフロー管理部４６Ａ及び後段のモジュールへ全体処理終了通知を出力した後に、次のステップ３１０において自モジュール消去処理を行う。

図１４に示すように、自モジュール消去処理では、まずステップ３２０において、先のステップ２５４（図１２）で確保したメモリ領域の解放をリソース管理部４６Ｂへ要求する。これにより、リソース管理部４６Ｂでメモリ解放要求時処理（図２(Ｃ)))が行われることで、上記のメモリ領域が解放される。次のステップ３２２では、リソース管理部４６Ｂを通じて自モジュールが確保したメモリ以外のリソースが有るか否か判定する。判定が否定された場合は何ら処理を行うことなくステップ３２６へ移行するが、判定が肯定された場合はステップ３２４へ移行し、自モジュールの識別情報をリソース管理部４６Ｂへ通知し、自モジュールが確保したメモリ以外のリソースの解放を要求する。これにより、リソース管理部４６Ｂでリソース解放要求時処理（図２(Ｅ)))が行われることで、上記のリソースが解放される。

自モジュール消去処理（図１４）では、ステップ３２２の判定が否定されるか、ステップ３２４でメモリ以外のリソースの解放をリソース管理部４６Ｂに要求した後に、リソース管理部４６Ｂからリソースの解放完了が通知されると、ステップ３２６へ移行して自モジュールの前段のモジュール、後段のモジュール及びワークフロー管理部４６Ａに対し、自モジュールを消去する処理を行うことを通知するための消去通知を入力する。そしてステップ３２８では自モジュールを消去する処理を行い、図１４の自モジュール消去処理（すなわち図１３のステップ３１０）を終了する。なお、自モジュールを消去することは、自モジュールに対応するプロセス、スレッドを終了するか、又はオブジェクトを削除することで実現することができる。

なお、バッファモジュール４０のバッファ制御部４０Ｂによって行われるバッファ制御処理（図６）では、自モジュールの前段又は後段の画像処理モジュール３８から消去通知が入力されると、ステップ３８０の判定が肯定されてステップ３９０へ移行し、消去通知入力元のモジュールを記憶した後に、自モジュールの前段及び後段の全てのモジュールから消去通知が入力されたか否か判定する。判定が否定された場合はステップ３７８へ戻り、先にも説明したようにステップ３７８，３８０を繰り返す。また、自モジュールの前段及び後段の全てのモジュールから消去通知が入力されると、ステップ３９０の判定が肯定されてステップ３９２へ移行し、ワークフロー管理部４６Ａに対して消去通知を入力することで、自モジュールを消去する処理を行うことを通知する。そして次のステップ３９４で自モジュールを消去する処理を行ってバッファ制御処理（図６）を終了する。

最後に、画像処理部５０が画像処理を実行している途中でエラーが発生した場合の処理について説明する。処理管理部４６のエラー管理部４６Ｃは、画像処理部５０が画像処理を実行している途中でエラーが発生すると、割込が発生することで図１９に示すエラー発生割込処理を行う。このエラー発生割込処理では、まずステップ５７０において、発生したエラーの種別・発生箇所等のエラー情報を取得する。また本実施形態では、画像処理プログラム群３４がインストールされたコンピュータ１０が組み込まれている機器の種別や構成等を表す装置環境情報が記憶部２０に記憶されており、次のステップ５７２では上記の装置環境情報を記憶部２０等から取得し、取得した装置環境情報が表す装置環境に応じたエラー通知方法を判断する。

例えばコンピュータ１０がＰＣ等の独立したコンピュータであれば、表示部１６として種々の情報を一度に表示可能なディスプレイが設けられているため、エラー通知方法として、ステップ５７０で取得したエラー情報の内容をポップアップウインドウ等によって表示部１６に全て表示させる等のエラー通知方法を選択する。また、例えばコンピュータ１０が組まれている機器が複写機、プリンタ、ファクシミリ装置、複合機、スキャナ、写真プリンタ等の機器であれば、表示部１６に一度に表示可能な情報量が限られている一方でブザー等が設けられているため、ブザーを鳴らすことでエラーの発生を通知すると共に、ステップ５７０で取得したエラー情報のうちエラーの種別のみを表示部１６に表示させる等の通知方法を選択する。そしてステップ５７４では、ステップ５７２で判断したエラー通知方法でエラーの発生を通知し、エラー発生割込処理を終了する。

このように、本実施形態に係るエラー発生割込処理では、複数種のエラー通知方法の中から装置環境に応じたエラー通知方法を選択し、選択したエラー通知方法でエラーの発生を通知するので、本発明に係る画像処理プログラム群３４を種々の構成のコンピュータ１０にインストールして本発明を適用することが可能になり、汎用性が向上すると共に、画像処理プログラム群３４をインストールするコンピュータ１０の構成（独立したコンピュータか、各種機器の何れに組み込まれたコンピュータか等）に応じてエラー発生時の処理を切り替える等の設定変更作業を行う必要がなくなるので、インストール時の作業負荷も軽減される。

なお、ここではエラー処理を割込を前提に説明したが、割込処理でなくてもよい。例えばエラーが起きた際には、当該モジュールはエラー管理部４６Ｃにエラー情報を通知し、その後の処理指示に対しては処理できない事を示す状態コードを返す。その情報を受け取った処理管理部４６は、その情報をアプリケーション３２に返し、アプリケーション３２は処理管理部４６のエラー管理部４６Ｃからエラー情報を受け取り、それに基づいて自身で表示やブザー等の処理を行うように構成しても良い。

なお、上記では、後段の画像処理モジュール３８からバッファモジュール４０に読出要求が入力されたものの、読出要求元の画像処理モジュール３８が読出可能な有効データのデータ量が単位読出データ量未満であり、かつ読出可能な有効データの末尾が処理対象の画像データの末尾でない場合に、読出可能な有効データのデータ量が単位読出データ量以上になるか、読出可能な有効データの末尾が処理対象の画像データの末尾であることが検知される迄、バッファモジュール４０からワークフロー管理部４６Ａへデータ要求が繰り返し入力される例を説明したが、これに限定されるものではなく、上記場合にバッファモジュール４０はワークフロー管理部４６Ａへデータ要求を１回のみ入力すると共に、読出可能な有効データのデータ量が単位読出データ量以上になるか、読出可能な有効データの末尾が処理対象の画像データの末尾であることが検知されるとワークフロー管理部４６Ａへ蓄積完了通知を入力し、ワークフロー管理部４６Ａはバッファモジュール４０からデータ要求が入力されてから蓄積完了通知が入力される迄の間、前記バッファモジュール４０の前段の画像処理モジュール３８へ処理要求を繰り返し入力するようにしてもよい。

また、上記ではバッファモジュール４０において、後段の画像処理モジュール３８から読出要求が入力され、読出要求元の画像処理モジュール３８が読出可能な有効データが自モジュールのバッファ４０Ａに記憶されていなかった場合に、バッファ制御部４０Ｂがワークフロー管理部４６Ａへデータ要求を入力する態様を例に説明したが、これに限定されるものではなく、上記場合にバッファ制御部４０Ｂが前段の画像処理モジュール３８へデータ要求を直接入力するようにしてもよい。この態様で画像処理の実行形態がブロック単位処理の場合の処理シーケンスを図２０に示す。図２０からも明らかなように、この態様において、ワークフロー管理部４６Ａは画像処理部５０のうち最後段の画像処理モジュール３８についてのみ処理要求を入力すれば済むので、ワークフロー管理部４６Ａにおける処理が簡単になる。

また、上記ではブロック単位の画像処理の一例として、まずワークフロー管理部４６Ａが画像処理部５０の最後段の画像処理モジュール３８へ処理要求を入力し、この処理要求がデータ要求又は処理要求として順次前段のモジュールへ伝達される態様を説明したが、これに限定されるものではなく、処理要求又はデータ要求を前段のモジュールから後段のモジュールへ順次伝達させてブロック単位の画像処理を行わせることも可能である。これは、例えばバッファモジュール４０のバッファ制御部４０Ｂを、自モジュールの前段の画像処理モジュール３８によってバッファ４０Ａに画像データが書き込まれる毎に、後段の画像処理モジュール３８が読出可能な有効データのデータ量が単位読出データ量未満で、かつ読出可能な有効データの末尾が処理対象の画像データの末尾でなければワークフロー管理部４６Ａへデータ要求を入力する一方、読出可能な有効データのデータ量が単位読出データ量以上になるか、読出可能な有効データの末尾が処理対象の画像データの末尾であることが検知されるとワークフロー管理部４６Ａへ蓄積完了通知を入力するように構成すると共に、ワークフロー管理部４６Ａを、画像処理部５０の最後段の画像処理モジュール３８へ処理要求を入力した後に、任意のバッファモジュール５０からデータ要求が入力される毎に、データ要求元のバッファモジュール４０の前段の画像処理モジュール３８に処理要求を入力し、任意のバッファモジュール４０から蓄積完了通知が入力される毎に、当該バッファモジュール４０の後段の画像処理モジュール３８に処理要求を入力するように構成することで実現することができる。また、上記において、バッファモジュール４０からのデータ要求を当該バッファモジュール４０の前段の画像処理モジュール３８へ処理要求として直接入力させると共に、バッファモジュール４０からの蓄積完了通知を当該バッファモジュール４０の後段の画像処理モジュール３８へ処理要求として直接入力させるようにしてもよい。

更に、上記ではバッファモジュール４０に対し、前段の画像処理モジュール３８からは単位書込データ量が、後段の画像処理モジュールからは単位読出データ量が事前に設定される態様を説明したが、これに限定されるものではなく、バッファモジュール４０へのデータの書込やバッファモジュール４０からのデータの読出の都度、書込又は読出のデータ量が画像処理モジュール３８から通知されるようにしてもよい。

また、上記では、バッファモジュール４０に書込要求又は読出要求が入力される毎に、入力された要求を要求情報として待ち行列に登録し、待ち行列から要求情報を１つづつ取り出して処理することで、書込要求入力時にバッファ４０Ａからのデータの読出を実行中であれば、このデータ読出が完了した後に前記書込要求に対応するデータ書込処理を行うと共に、読出要求入力時にバッファ４０Ａへのデータの書込を実行中であれば、このデータ書込が完了した後に前記読出要求に対応するデータ読出処理を行う排他制御を実現していたが、これに限定されるものではなく、例えば単位バッファ領域を単位とする排他制御、すなわち書込要求入力時に、バッファ４０Ａのうち当該書込要求における書込対象の単位バッファ領域に対してデータの読出を実行中であれば、このデータ読出が完了した後に前記書込要求に対応するデータ書込処理を行うと共に、読出要求入力時に、バッファ４０Ａのうち当該読出要求における読出対象の単位バッファ領域に対してデータの書込を実行中であれば、このデータ書込が完了した後に前記読出要求に対応するデータ読出処理を行うようにしてもよい。単位バッファ領域を単位とする排他制御は、例えば個々の単位バッファ領域毎に待ち行列を設けて排他制御を行う等により実現することができる。

また、上記では、モジュールライブラリ３６にプログラムが登録されている個々の画像処理モジュール３８のうち、単位読出データ量及び単位書込データ量が同一の画像処理モジュール３８の制御部３８Ｂに相当するプログラムを共通化した例を説明したが、これに限定されるものではなく、例えば制御部３８Ｂに相当するプログラムを、前段のモジュールから画像データを取得して画像処理エンジン３８Ａに入力する第１制御部に相当するプログラム、画像処理エンジン３８Ａから出力されたデータを前段のモジュールへ出力する第２制御部に相当するプログラム、単位読出データ量や単位処理データ量、単位書込データ量に依存しない制御（例えばワークフロー管理部４６Ａとの通信等）を行う共通制御部に相当するプログラムに分割し、全ての画像処理モジュールについて、共通制御部に相当するプログラムを共通化し、更に、単位読出データ量が同一の画像処理モジュール３８については第１制御部に相当するプログラムを共通化し、単位書込データ量が同一の画像処理モジュール３８については第２制御部に相当するプログラムを共通化するようにしてもよい。

更に、画像処理部５０を構成する個々のモジュールの実体はプログラムであるので、画像処理部５０による画像処理は実際にはＣＰＵ１２によって実行されるが、ここで、画像処理部５０を構成する個々の画像処理モジュール３８に相当するプログラムを、ＣＰＵ１２による実行対象のプロセス、スレッド又はオブジェクトとして待ち行列に登録し、当該待ち行列に登録した特定の画像処理モジュールに相当するプログラムがＣＰＵ１２によって前記待ち行列から取り出される毎に、特定の画像処理モジュール３８の前段のモジュールから単位処理データ量の画像データを取得可能か否かを判断し、単位処理データ量の画像データを取得可能と判断した場合にのみ、前記特定の画像処理モジュール３８の前段の前段のモジュールから単位処理データ量の画像データを取得し、取得した単位処理データ量の画像データに対して所定の画像処理（特定の画像処理モジュール３８の画像処理エンジン３８Ａに相当する処理）を行い、所定の画像処理を経た画像データ又は所定の画像処理の処理結果を自モジュールの後段のモジュールへ出力する処理を行った後に、処理対象の画像全体に対する処理が終了していなれば、取り出した特定の画像処理モジュールに相当するプログラムを実行対象のプロセス、スレッド又はオブジェクトとして前記待ち行列に再登録する単位画像処理をＣＰＵ１２によって繰り返させることで、画像処理部５０によって処理対象の画像全体を処理させるようにしてもよい（ラウンドロビン方式）。

本実施形態に係るコンピュータ（画像処理装置）の概略構成を示すブロック図である。リソース管理部によって実行される、(Ａ)は初期化処理、(Ｂ)は第３管理方式でのメモリ確保要求時処理、(Ｃ)は第３管理方式でのメモリ解放要求時処理、(Ｄ)はリソース確保要求時処理、(Ｅ)はリソース解放要求時処理の内容を各々示すフローチャートである。アプリケーションによる処理を説明するためのシーケンス図である。 (Ａ)はモジュール生成部によって実行されるモジュール生成処理の内容を示すフローチャート、(Ｂ)はワークフロー管理部のテーブルを説明する概略図である。画像処理部の構成例を示すブロック図である。バッファモジュールのバッファ制御部によって実行されるバッファ制御処理の内容を示すフローチャートである。バッファモジュールのバッファ制御部によって実行される要求受信割込処理の内容を示すフローチャートである。バッファモジュールのバッファ制御部によって実行されるデータ書込処理の内容を示すフローチャートである。書込対象の画像データが複数の保管用単位バッファ領域に跨る場合の処理を説明する概略図である。バッファモジュールのバッファ制御部によって実行されるデータ読出処理の内容を示すフローチャートである。読出対象の画像データが複数の保管用単位バッファ領域に跨っていた場合の処理を説明する概略図である。画像処理モジュールの制御部によって実行される画像処理モジュール初期化処理の内容を示すフローチャートである。画像処理モジュールの制御部によって実行される画像処理モジュール制御処理の内容を示すフローチャートである。画像処理モジュールの制御部によって実行される自モジュール消去処理の内容を示すフローチャートである。 (Ａ)は画像処理モジュール、(Ｂ)はバッファモジュールの概略構成及び実行される処理を各々示すブロック図である。処理管理部によって実行されるブロック単位制御処理の内容を示すフローチャートである。処理管理部によって実行される面単位制御処理の内容を示すフローチャートである。ブロック単位処理及び面単位処理の流れを説明する概略図である。処理管理部によって実行されるエラー発生割込処理の内容を示すフローチャートである。バッファモジュールが前段の画像処理モジュールに画像データを直接要求する態様におけるブロック単位処理の流れを説明する概略図である。

符号の説明

１０コンピュータ
１４メモリ
２０記憶部
２２画像データ供給部
２４画像出力部
３２アプリケーション
３４画像処理プログラム群
３８画像処理モジュール
３８Ａ画像処理エンジン
３８Ｂ制御部
４０バッファモジュール
４０Ａバッファ
４０Ｂバッファ制御部
４２処理構築部
４４モジュール生成部
４６処理管理部
４６Ｃエラー管理部
４６Ｂリソース管理部
４６Ａワークフロー管理部
５０画像処理部

Claims

画像データに対する所定の画像処理を、予め設定された単位処理データ量ずつ行う画像処理エンジンと、自モジュールの前段から取得した画像データを前記画像処理エンジンが前記単位処理データ量ずつ処理するために必要なデータ量単位で入力すると共に、前記画像処理エンジンによる所定の画像処理を経た画像データ又は前記所定の画像処理の処理結果を自モジュールの後段へ出力する制御手段を備え、前記画像処理エンジンが行う画像処理の種類又は内容が互いに異なる複数種の画像処理モジュールの中から選択された１つ以上の画像処理モジュールと、
画像データを記憶するためのバッファと、自モジュールの前段に画像処理モジュールが連結されている場合に、自モジュールに対して事前に設定されるか又は画像データ出力の都度通知される書込データ量のデータを記憶可能な前記バッファ上の記憶領域に前記前段の画像処理モジュールから出力される画像データを書き込ませると共に、自モジュールの後段に画像処理モジュールが連結されている場合に、前記バッファに記憶されている画像データを、前記後段の画像処理モジュールにより、自モジュールに対して事前に設定されるか又は画像データ要求の都度指定される読出データ量だけ読み出させる処理を行うバッファ制御手段を備えた１つ以上のバッファモジュールと、
が、前記選択された個々の画像処理モジュールの前段及び後段の少なくとも一方にバッファモジュールが連結されるように、個々のモジュールがパイプライン形態又は有向非循環グラフ形態で連結されて構築された画像処理部を備えた画像処理装置であって、
前記画像処理部の構築時又は処理対象の画像データの処理時の個々のモジュールからの要求に応じて、前記画像処理装置に設けられているメモリから前記個々のモジュールに割り当てるメモリを確保して前記個々のモジュールに割り当てると共に、前記個々のモジュールの消去時には前記個々のモジュールに割り当てたメモリを解放するメモリ管理処理を複数種の管理方式で実行可能で、前記複数種の管理方式のうち外部から指示された管理方式で前記メモリ管理処理を行うメモリ管理手段を更に備えたことを特徴とする画像処理装置。
前記単位処理データ量は、前記画像処理エンジンが行う前記所定の画像処理の種類又は動作環境に応じて予め設定されることを特徴とする請求項１記載の画像処理装置。
前記複数種の管理方式は、前記個々のモジュールからの要求の都度、前記画像処理装置に設けられたメモリから要求元のモジュールに割り当てるメモリをオペレーティングシステムを通じて確保する第１の管理方式、前記画像処理装置に設けられたメモリから一定サイズのメモリをオペレーティングシステムを通じて事前に確保し、前記個々のモジュールからの要求があると、前記事前に確保したメモリの中から要求元のモジュールに割り当てるメモリを確保する第２の管理方式、及び、前記画像処理装置に設けられたメモリから一定サイズのメモリをオペレーティングシステムを通じて事前に確保し、前記個々のモジュールからの要求があると、要求されたメモリのサイズが閾値未満であれば、前記画像処理装置に設けられたメモリから要求元のモジュールに割り当てるメモリをオペレーティングシステムを通じて確保し、要求されたメモリのサイズが閾値以上であれば、前記事前に確保したメモリの中から要求元のモジュールに割り当てるメモリを確保する第３の管理方式のうちの複数の管理方式であることを特徴とする請求項１記載の画像処理装置。
前記画像処理部の個々の画像処理モジュールにおいて、自モジュールの前段から取得した画像データを前記画像処理エンジンへ入力すると共に、前記画像処理エンジンによる所定の画像処理を経た画像データ又は前記所定の画像処理の処理結果を自モジュールの後段へ出力する単位処理を繰り返させることで、前記画像処理部によって処理対象の画像全体を処理させると共に、処理終了時には、前記個々の画像処理モジュールを消去しかつ前記個々の画像処理モジュールに割り当てられていたメモリを前記メモリ管理手段を介して解放させる処理を行う処理管理手段を更に備えたことを特徴とする請求項１記載の画像処理装置。
前記処理管理手段は、面単位処理の実行が指示された場合に、特定の画像処理モジュールから処理対象の画像全体に相当する画像データが出力される迄、前記特定の画像処理モジュールで前記単位処理を繰り返させることを、前記画像処理部の最上流の画像処理モジュールから順に行うことを特徴とする請求項４記載の画像処理装置。
前記バッファモジュールのバッファ制御手段は、処理対象の画像データ全体に対する画像処理が完了することで、自モジュールに連結された全ての画像処理モジュールが消去された場合には、自モジュールを消去する処理を行うと共に、自モジュールに割り当てられていたメモリを前記メモリ管理手段を介して解放させる処理を行うことを特徴とする請求項４記載の画像処理装置。
前記処理管理手段は、前記画像処理部の構築時又は処理対象の画像データの処理時の個々のモジュールからの要求に応じて、前記画像処理装置に設けられているメモリ以外のリソースから前記個々のモジュールに割り当てるリソースを確保して前記個々のモジュールに割り当てると共に、前記個々のモジュールに割り当てたリソースをテーブルに登録しておき、処理終了時には前記個々の画像処理モジュールを消去しかつ前記テーブルに登録したリソースを全て解放することを特徴とする請求項４記載の画像処理装置。
前記画像処理装置でエラーが発生した場合にエラーの発生を外部へ通知するエラー通知処理を複数種の通知方式で実行可能で、前記複数種の通知方式の中から選択された通知方式で前記エラー通知処理を行うエラー通知手段を更に備えたことを特徴とする請求項１乃至請求項７の何れか１項記載の画像処理装置。
実行すべき画像処理の種類を指定する処理パラメータ及び処理対象の画像の属性に基づいて前記画像処理部を構築する構築手段を更に備えたことを特徴とする請求項１乃至請求項８の何れか１項記載の画像処理装置。
画像データに対する所定の画像処理を、予め設定された単位処理データ量ずつ行う画像処理エンジンと、自モジュールの前段から取得した画像データを前記画像処理エンジンが前記単位処理データ量ずつ処理するために必要なデータ量単位で入力すると共に、前記画像処理エンジンによる所定の画像処理を経た画像データ又は前記所定の画像処理の処理結果を自モジュールの後段へ出力する制御手段を備え、前記画像処理エンジンが行う画像処理の種類又は内容が互いに異なる複数種の画像処理モジュールの中から選択された１つ以上の画像処理モジュールと、
画像データを記憶するためのバッファと、自モジュールの前段に画像処理モジュールが連結されている場合に、自モジュールに対して事前に設定されるか又は画像データ出力の都度通知される書込データ量のデータを記憶可能な前記バッファ上の記憶領域に前記前段の画像処理モジュールから出力される画像データを書き込ませると共に、自モジュールの後段に画像処理モジュールが連結されている場合に、前記バッファに記憶されている画像データを、前記後段の画像処理モジュールにより、自モジュールに対して事前に設定されるか又は画像データ要求の都度指定される読出データ量だけ読み出させる処理を行うバッファ制御手段を備えた１つ以上のバッファモジュールと、
が、前記選択された個々の画像処理モジュールの前段及び後段の少なくとも一方にバッファモジュールが連結されるように、個々のモジュールがパイプライン形態又は有向非循環グラフ形態で連結されて構築された画像処理部を備えた画像処理装置によって画像処理を行う画像処理方法であって、
前記画像処理部の構築時又は処理対象の画像データの処理時の個々のモジュールからの要求に応じて、前記画像処理装置に設けられているメモリから前記個々のモジュールに割り当てるメモリを確保して前記個々のモジュールに割り当てると共に、前記個々のモジュールの消去時には前記個々のモジュールに割り当てたメモリを解放するメモリ管理処理を複数種の管理方式で実行可能としておき、前記複数種の管理方式のうち外部から指示された管理方式で前記メモリ管理処理を行うことを特徴とする画像処理方法。
コンピュータを、
画像データに対する所定の画像処理を、予め設定された単位処理データ量ずつ行う画像処理エンジンと、自モジュールの前段から取得した画像データを前記画像処理エンジンが前記単位処理データ量ずつ処理するために必要なデータ量単位で入力すると共に、前記画像処理エンジンによる所定の画像処理を経た画像データ又は前記所定の画像処理の処理結果を自モジュールの後段へ出力する制御手段を備え、前記画像処理エンジンが行う画像処理の種類又は内容が互いに異なる複数種の画像処理モジュールの中から選択された１つ以上の画像処理モジュールと、
画像データを記憶するためのバッファと、自モジュールの前段に画像処理モジュールが連結されている場合に、自モジュールに対して事前に設定されるか又は画像データ出力の都度通知される書込データ量のデータを記憶可能な前記バッファ上の記憶領域に前記前段の画像処理モジュールから出力される画像データを書き込ませると共に、自モジュールの後段に画像処理モジュールが連結されている場合に、前記バッファに記憶されている画像データを、前記後段の画像処理モジュールにより、自モジュールに対して事前に設定されるか又は画像データ要求の都度指定される読出データ量だけ読み出させる処理を行うバッファ制御手段を備えた１つ以上のバッファモジュールと、
が、前記選択された個々の画像処理モジュールの前段及び後段の少なくとも一方にバッファモジュールが連結されるように、個々のモジュールがパイプライン形態又は有向非循環グラフ形態で連結されて構築された画像処理部を備えた画像処理装置として機能させるための画像処理プログラムであって、
前記画像処理部の構築時又は処理対象の画像データの処理時の個々のモジュールからの要求に応じて、前記画像処理装置に設けられているメモリから前記個々のモジュールに割り当てるメモリを確保して前記個々のモジュールに割り当てると共に、前記個々のモジュールの消去時には前記個々のモジュールに割り当てたメモリを解放するメモリ管理処理を複数種の管理方式で実行可能で、前記複数種の管理方式のうち外部から指示された管理方式で前記メモリ管理処理を行うメモリ管理手段を更に備えたことを特徴とする画像処理プログラム。