JP2009187099A - 情報処理装置およびプログラム - Google Patents

Abstract

【課題】複数の処理部品を連結して一連のタスクを行うプログラムの少なくとも一部の処理の変更や修正を従来と比して容易に行う。
【解決手段】情報処理装置１０は、所定のタスクを実行するための複数のプラグインライブラリの各々を少なくとも１つずつ格納する複数のフォルダをディレクトリ構造で保持するプラグインライブラリ蓄積部４０と、各フォルダに格納された各プラグインライブラリの処理モジュールを、ディレクトリ構造に基づき予め定められた連結順に従って、連結する処理構築部３０とを備え、連結された各処理モジュールを各々実行してタスクを実行する。
【選択図】図１

Description

本発明は、情報処理装置およびプログラムに関する。

情報処理装置において、プログラマブルな処理モジュール群の中からいくつかの処理モジュールを選択し、選択した処理モジュールを連結して一連の処理を実行するプログラムが知られている。

例えば、入力された画像データに対して画像処理を行う画像処理装置でも上記のようなプログラムが採用されることがある。

特許文献１には、プログラマブルな処理モジュールをパイプライン形態やＤＡＧ（Ｄｉｒｅｃｔｅｄ Ａｃｙｃｌｉｃ Ｇｒａｐｈ：有向非循環グラフ）形態に接続して、所望の画像処理を行う技術が開示されている。特許文献１では、画像処理モジュールを適宜組み合わせてパイプラインを構成し、各画像処理モジュールを順次動作させることで、所望の画像処理を行っている。

また、特許文献２では、画像処理のタスクに用いる処理部品と処理部品間の結合情報とを記述したタスクシナリオ情報と、処理部品の情報が記述されたコンポーネント情報と、処理部品の実体が格納されたコンポーネットライブラリとを備え、コンテンツを特定するコンテンツ識別子とタスクを特定するタスク識別子に対応するタスクシナリオ情報を解析して、各処理部品間を連結する技術が開示されている。

特許第３６１７８５１号 特開２００３−３０３１０２号公報

上記のような複数の処理モジュールを連結して一連の処理を行うプログラムにおいて、処理モジュールの追加、他の処理モジュールへの置き換え、あるいは処理モジュールの連結順の変更などを行うことで、プログラムを一部変更あるいは修正したいという要望がある。

しかし、一度完成したプログラムにおける処理モジュールの変更や連結順の変更によりプログラムを一部変更あるいは修正することは容易でない場合が多い。

本発明は、複数の処理部品を連結して一連のタスクを行うプログラムの少なくとも一部の処理の変更や修正を従来と比して容易に行うことを目的とする。

本願請求項１に係る発明は、所定のタスクを実行するための複数の処理部品を少なくとも１つずつ格納する複数のフォルダをディレクトリ構造で保持する処理部品蓄積部と、各フォルダに格納された各処理部品を、前記ディレクトリ構造に基づき予め定められた連結順に従って、連結する連結部と、連結された各処理部品を実行して前記タスクを実行する実行部と、を備える情報処理装置である。

本願請求項２に係る発明は、所定のタスクを実行するための複数の処理部品の各々に対応する各識別子を少なくとも１つずつ格納する複数のフォルダをディレクトリ構造で保持する識別子蓄積部と、各フォルダに格納された各識別子に基づいて、処理部品の実体を格納する処理部品格納部から各処理部品を取得し、前記ディレクトリ構造に基づき予め定められた連結順に従って、取得した各処理部品を連結する連結部と、連結された各処理部品を実行して前記タスクを実行する実行部と、を備える情報処理装置である。

本願請求項３に係る発明は、請求項１または２に記載の情報処理装置において、各フォルダは、ディレクトリ構造上の同一階層に存在し、前記連結順は、各フォルダの各々を一意に特定する各フォルダ識別子を所定の規則に従って並べた場合における昇順あるいは降順に対応する、ことを特徴とする情報処理装置である。

本願請求項４に係る発明は、所定のタスクを実行するための複数の処理部品を少なくとも１つずつ格納する複数のフォルダをディレクトリ構造で保持する処理部品蓄積部と、各フォルダに格納された各処理部品を、前記ディレクトリ構造に基づき予め定められた連結順に従って、連結する連結部と、連結された各処理部品を実行して前記タスクを実行する実行部と、してコンピュータを機能させるためのプログラムである。

本願請求項５に係る発明は、所定のタスクを実行するための複数の処理部品の各々に対応する各識別子を少なくとも１つずつ格納する複数のフォルダをディレクトリ構造で保持する処理部品保持部と、各フォルダに格納された各識別子に基づいて、処理部品の実体を格納する処理部品格納部から各処理部品を取得し、前記ディレクトリ構造に基づき予め定められた連結順に従って、取得した各処理部品を連結する連結部と、連結された各処理部品を実行して前記タスクを実行する実行部と、してコンピュータを機能させるためのプログラムである。

本願請求項１，２，４，５に係る発明によれば、ディレクトリ構造に基づいて各処理部品を格納すれば、そのディレクトリ構造に基づき定められた連結順で各処理部品が連結され、所定のタスクを実現することができる。よって、例えば、各処理部品を格納するディレクトリ（フォルダ）を変更する、あるいはディレクトリに格納された処理部品を変更／修正するだけで、所定のタスクの処理の少なくとも一部の処理を変更／修正することができる。

本願請求項３に係る発明によれば、連結順が各フォルダの各々を一意に特定する各フォルダ識別子を所定の規則に従って並べた場合における昇順あるいは降順に対応するため、各フォルダ識別子に基づいて連結順を容易に特定することができる。

本発明を実施するための最良の形態（以下、「実施形態」と称す）について、以下図面を用いて説明する。

本実施形態では、所定のタスクを行う情報処理装置の１つとして、所定の画像処理を行う画像処理装置を例に説明する。

図１は、本実施形態に係る画像処理装置の機能ブロックを示す図である。画像処理装置１０は、複写機、プリンタ、ファクシミリ装置、これらの機能を備えた複合機でもよい。また、スキャナ、写真プリンタなどのように内部で画像処理を行う必要のある任意の画像取扱機器に組み込まれてもよい。さらに、パーソナルコンピュータなどの独立したコンピュータでもよく、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）や携帯電話などの携帯機器に組み込まれたコンピュータでもよい。

画像処理装置１０は、ＣＰＵ１２、メモリ１４、表示部１６、操作部１８、記憶部２０、画像データ供給部２２を備え、これらはバス２６を介して各々接続される。ＣＰＵ１２が、記憶部２０に記録された各種プログラムを適宜メモリ１４に展開して、各部を制御する。画像処理装置１０が、上記のような画像取扱機器に組み込まれる場合、表示部１６や操作部１８としては、画像取扱機器に設けられた液晶ディスプレイなどの表示パネルやテンキーなどを適用することができる。また、画像処理装置１０が、独立したコンピュータである場合、表示部１６や操作部１８として、当該コンピュータに接続されたディスプレイやキーボード、マウスなどを適用することができる。また、記憶部２０としてはハードディスクドライブ（ＨＤＤ）が好適であるが、これに代えてフラッシュメモリなどの他の不揮発性メモリを用いることもできる。

画像データ供給部２２は、処理対象の画像データを供給できるものであればよく、例えば紙や写真フィルムなどの記録材料に記録されている画像を読み取って画像データを出力する画像読取部、通信回線を介して外部から画像データを受信する受信部、画像データを記憶する画像記憶部などを適用することができる。

また、画像出力部２４は、画像処理を経た画像データ又は当該画像データが表す画像を出力するものであればよく、例えば画像データが表す画像を紙や感光材料などの記録材料に記録する画像記録部、画像データが表す画像をディスプレイなどに表示する表示部、画像データを記録メディアに書き込む書込装置、通信回線を介して画像データを送信する送信部などを適用することができる。また、画像出力部２４は、画像処理を経た画像データを単に記憶する画像記憶部であっても構わない。

図１に示すように、記憶部２０には、ＣＰＵ１２によって実行される各種プログラムおよび各種データベースが記憶されている。

処理構築部３０は、アプリケーションプログラム８０からの構築指示に従い、アプリケーションプログラム８０が指示した画像処理を行う画像処理部をメモリ１４上に構築し、アプリケーションプログラム８０からの実行指示に従い、当該画像処理部によって画像処理を行う。

プラグインライブラリ蓄積部４０は、画像処理における少なくとも一部の処理を行う処理モジュール（処理部品）を提供する複数のプラグインライブラリ４２を保持する。本実施形態では、プラグインライブラリ蓄積部４０は、各プラグインライブラリ４２をディレクトリ構造で保持する。ディレクトリ管理部５０は、プラグインライブラリ蓄積部４０のディレクトリ構造を管理する。ディレクトリ管理部５０は、画像処理装置１０に備えられる各部の入出力機能やメモリ管理を司るオペレーティングシステム９０で一般的に提供されるディレクトリサービスの機能を用いればよい。

図２に示すように、プラグインライブラリ４２は、予め定められた画像処理（例えば、入力処理、フィルタ処理、色変換処理、拡大・縮小処理、スキュー角検知処理、画像回転処理、画像合成処理、出力処理など）を行う少なくとも１つの画像処理モジュール４８と、画像処理モジュール４８をメモリ１４上に展開し画像処理モジュール４８を機能させる処理生成モジュール４６と、処理生成モジュール４６が画像処理モジュール４８を機能させるために呼び出す処理モジュール生成関数４４とを備える。

また、補助モジュール蓄積部７０は、処理モジュールが連結して処理を行うために必要な補助モジュールとして、各種の属性変換処理モジュール７２およびバッファモジュール７４を蓄積する。

各種画像処理モジュールは、それぞれ入力可能な画像属性（１画素を表現するビット数すなわち白黒画像、フルカラー画像や圧縮の有無など）または出力する画像属性が異なる。そのため、前段の画像処理モジュールが出力する画像属性と後段の画像処理モジュールに入力可能な画像属性とが異なる場合には、前段の画像処理モジュールが出力した画像データの属性を後段の画像処理モジュールに入力可能な画像属性に変換するための属性変換処理モジュール７２が用意されている。

また、画像処理モジュールが処理の途中経過を保持するためのバッファメモリが必要である。このバッファメモリは画像処理モジュールの処理内容によって異なる。そこで、処理モジュールを任意の順番で連結し協調して処理をするために、本実施形態では、処理モジュール間に連結されるためのバッファモジュールが用意されている。バッファモジュールは、バッファモジュールの前段に連結された画像処理モジュールがバッファへの画像データの書き込み時の書込データ量を任意に設定可能にし、バッファモジュールの後段に連結された画像処理モジュールがバッファから画像データ読み出し時の読出データ量を任意に設定可能としている。

処理構築部３０は、アプリケーションプログラム８０からの指示により、例えば図３Ａや図３Ｂに示すように、予め定められた画像処理を行う１つ以上の処理モジュール４８と、個々の処理モジュール４８の前段および後段の少なくとも一方に配置され画像データを記憶するためのバッファを備えたバッファモジュール７４とが、パイプライン形態あるいはＤＡＧ形態で連結され、制御手段８６で各モジュールを制御する画像処理部６０を構築する。

図３Ａでは、画像データ供給部２２から提供された画像データに対して、１段目の処理モジュール４８が入力処理を行い、２段目のバッファモジュール７４を介して、３段目の処理モジュール４８が色変換処理を行う。その後、４段目のバッファモジュール７４を介して５段目の処理モジュール４８が拡大／縮小処理を行い、６段目のバッファモジュール７４を介して７段目の処理モジュール４８が出力処理を行い、画像出力部２４へ入力している。

また、図３Ｂでは、３段目の処理モジュール４８が色変換処理の後、処理後の画像データは、４段目のバッファモジュール７４を介して、スキュー角度検知処理を行う第１の５段目の処理モジュール４８と、画像回転処理を行う第２の５段目の処理モジュール４８とに入力される。ここでは、スキュー角度検知処理の結果が、画像データの他に画像回転処理を行う処理モジュール４８に入力され、その検知結果を利用して画像回転処理が行われる。その後、画像回転処理後の画像データが６段目のバッファモジュール７４を介して７段目の処理モジュール４８に入力され、出力処理が行われ、画像出力部２４へ入力される。このように、画像処理の内容によっては、処理モジュール４８やバッファモジュールの入力や出力は、１つではなく複数に分岐することもある。

さて、本実施形態では、上記の通り、ディレクトリ管理部５０が、プラグインライブラリをディレクトリ構造で管理している。このように、ディレクトリ構造でプラグインライブラリ群を管理することで、本実施形態では、プラグインライブラリの変更、修正、追加などにより、画像処理の一部を変更することを容易にしている。

図４に示すように、本実施形態では、ディレクトリを構成する各フォルダには、予め各々を一意に特定できるフォルダ名が付与されている。本実施形態では、各フォルダ内をフォルダ名の昇順に検索し、各フォルダ内から所定の拡張子（本実施形態では「．ｄｌｌ」）をもつ各々プラグインライブラリを取得して、その昇順を連結順として、各処理モジュールを連結して、画像処理部（画像処理パイプライン）を構築する。なお、連結順は、ディレクトリ構造に基づく所定の規則に従った順であれば他の順でもよく、例えばフォルダ名の降順、ディレクトリ階層の降順／昇順などでも構わない。また、本実施形態では、フォルダ名により連結順が定められるため、名前順に規則的に並べられる識別子が好ましく、例えば「１０」、「２０」、「３０」・・・の数字が好適である。また、フォルダ名を数字にする場合、下記に示す通り、フォルダとフォルダとの間に新たなフォルダを追加できるように、連続した数字を付与するよりも、「１０」などの所定の数字間隔ごとに付与しておくことが好ましい。

さらに、各フォルダにはプラグインライブラリと同一のファイル名で拡張子の異なる（本実施形態では「．ｘｍｌ」）ファイルが格納されている。このファイルは、プラグインライブラリの画像処理モジュールを生成する際に呼び出される関数（処理モジュール生成関数）に対して設定される設定パラメータが示されている。

本実施形態では、上記の通り、各モジュールの連結順が、ディレクトリ構造に基づき定められている。よって、例えば、プラグインライブラリの修正、置き換えなどを行う場合には、対象のプラグインライブラリが格納されたフォルダを特定し、そのフォルダに新たなプラグインライブラリを格納するだけで済む。また、プラグインライブラリを追加する場合にも、挿入したいプラグインライブラリのフォルダとプラグインライブラリのフォルダとの間に新たなフォルダを追加し、そのフォルダに新たなプラグインライブラリを追加するだけで済む。

図５は、処理構築部３０が、アプリケーションプログラム８０からの指示に従って、プラグインライブラリ蓄積部４０に蓄積されたプラグインライブラリ群を用いて、画像処理部を生成する手順を示す。

図５において、処理構築部３０は、アプリケーションプログラム８０からの画像処理部の構築指示を受けると、ディレクトリ管理部５０から、プラグインライブラリ群４２のディレクトリに関する情報（以下、「ディレクトリ情報」と称す）を取得し（Ｓ１００）、さらに各モジュールを制御する制御手段８６を生成する（Ｓ１０２）。

続いて、処理構築部３０は、ディレクトリ情報を参照して、まず検索ディレクトリを先頭ディレクトリに設定する（Ｓ１０４）。ここで、先頭ディレクトリとは、フォルダ名の昇順などの所定規則に従った順のうち、第１番目のフォルダ名をもつフォルダのことをいう。

処理構築部３０は、検索ディレクトリのフォルダにプラグインライブラリが存在するか否かをディレクトリ管理部５０を介して判定する（Ｓ１０６）。判定の結果、検索フォルダにプラグインライブラリが存在する場合には（ステップＳ１０６の判定結果、肯定「Ｙ」）、そのプラグインライブラリを呼び出し、画像処理モジュールを生成する（Ｓ１０８）。処理モジュールの生成手順については後述する。

モジュール生成後、処理構築部３０は、前段モジュールの出力属性が、生成した処理モジュールの入力属性と一致するか否かを判定する（Ｓ１１０）。判定の結果、一致しない場合には（ステップＳ１１０の判定結果が、否定「Ｎ」）、前段モジュールの出力属性と、生成した処理モジュールの入力属性とを一致させるのに適合する属性変換処理モジュール７２を補助モジュール蓄積部７０に蓄積された属性変換処理モジュール７２を用いて生成し、前段モジュールの次処理としてその属性変換処理モジュール７２を登録する（Ｓ１１２）。

前段モジュールの出力属性が、生成した処理モジュールの入力属性と一致する場合（ステップＳ１１０の判定結果が、肯定「Ｙ」）、あるいは前段モジュールの次処理としてその属性変換処理モジュール７２が登録された後、処理構築部３０は、ステップＳ１０８で生成された画像処理モジュールを前段モジュールの次処理として登録する（Ｓ１１４）。

なお、プラグインライブラリによっては複数の処理モジュールを生成するものもある。複数の処理モジュールが生成される場合には、予め定められた順番で生成された各処理モジュールを連結して、連結された先頭の処理モジュールを前段のモジュールの次処理として登録する。

その後、処理構築部３０は、現在の検索ディレクトリが最終のディレクトリか否かを判定する（Ｓ１１６）。判定の結果、処理構築部３０は、プラグインライブラリ蓄積部４０に構築されたすべてのディレクトリを検索していない場合には（ステップＳ１１６の判定結果、否定「Ｎ」）、検索ディレクトリを次順のディレクトリに設定し（Ｓ１１８）、ステップＳ１０６以降の処理を繰り返す。一方、プラグインライブラリ蓄積部４０に構築されたすべてのディレクトリを検索した場合には（ステップＳ１１６の判定結果、肯定「Ｙ」）、画像処理部に必要なすべての画像処理モジュールの連結が終了したと判断して、処理を終了する。

続いて、図６を参照して、各プラグインライブラリの処理モジュールの生成手順についてさらに説明する。図６は、処理構築部３０が検索ディレクトリ内の各プラグインライブラリを呼び出し、各プラグインライブラリの処理モジュールを生成する手順を示すフローチャートである。

図６において、処理構築部３０は、まず、検索ディレクトリのフォルダ内のプラグインライブラリの数を計数し、その計数した数をＮ、前段の処理モジュールの数をＭに設定する（Ｓ２００）。次いで、処理構築部３０は、前段の処理モジュールの数Ｍが１個か否かを判定する（Ｓ２０２）。判定の結果、前段の処理モジュールの数Ｍが１個の場合には（ステップＳ２０２の判定結果、「Ｙ」）には、Ｎが１か否かを判定する（Ｓ２０４）。つまり、処理構築部３０は、検索ディレクトリのフォルダ内のプラグインライブラリの数が１個か否かを判定する。判定の結果、１個の場合には（ステップＳ２０４の判定結果が、肯定「Ｙ」）、後述するステップＳ２１６以降の処理を行い、複数の場合には（ステップＳ２０４の判定結果が、否定「Ｎ」）、前段の処理モジュールから出力される画像データをＮ個の処理モジュールに入力させるために、前段の処理モジュールの出力をＮ個に分岐させる（Ｓ２０６）。

また、前段の処理モジュールの数Ｍが複数の場合（ステップＳ２０２の判定結果が、否定「Ｎ」）、処理構築部３０は、前段の処理モジュールの数ＭがＮ個か否かを判定する（Ｓ２０７）。つまり、処理構築部３０は、前段の処理モジュールの数Ｍと、検索ディレクトリ内のプラグインライブラリの数とが一致するか否かを判定する。一致しない場合には（ステップＳ２０７の判定結果が、否定「Ｎ」）、Ｎが１かどうかを判定し（Ｓ２０８）、Ｎが１である場合には検索ディレクトリ内のプラグインライブラリが生成する先頭の処理モジュールは前段モジュールを複数持つものとして扱い、Ｍ対１に対応づけ（Ｓ２０９）、後述のステップＳ２１６以降の処理を行う。一方、Ｎが１でない場合には、前段の処理モジュールとの連結に矛盾が生じるため、エラーを通知する（Ｓ２１０）。

前段の処理モジュールの数Ｍと、検索ディレクトリ内のプラグインライブラリの数とが一致する場合には（ステップＳ２０７の判定結果が、肯定「Ｙ」）、処理構築部３０は、前段の各処理モジュールと、検索ディレクトリ内の各プラグインライブラリを所定の規則に基づいて１対１に対応付ける（Ｓ２１２）。処理構築部３０は、例えば、前段の各処理モジュールに対応する各プラグインライブラリの名前および検索ディレクトリ内の各プラグインライブラリの名前をそれぞれ数字やアルファベットに基づいて昇順に並べ、それぞれ対応する順番同士を１対１に対応付ける。

その後、処理構築部３０は、検索ディレクトリ内の各プラグインライブラリのうち、例えば、プラグインライブラリの名前の数字やアルファベットに基づいて昇順に並べた場合に、１番目のプラグインライブラリを先頭のライブラリとして、処理対象に設定する（Ｓ２１４）。次いで、処理構築部３０は、処理対象のプラグインライブラリに対応する処理パラメータファイルを検索ディレクトリ内から検索する（Ｓ２１６）。対応する処理パラメータファイルが存在する場合には（ステップＳ２１６の判定結果が、肯定「Ｙ」）、その処理パラメータを使用して、処理対象のプラグインライブラリの生成モジュール関数を呼び、処理モジュールを生成する（Ｓ２２２）。対応する処理パラメータファイルが存在しない場合には処理対象のプラグインライブラリのデフォルトの処理パラメータを使用して、処理対象のプラグインライブラリの生成モジュール関数を呼び、処理モジュールを生成する（Ｓ２２２）。なお、デフォルトの処理パラメータは、生成モジュール関数の属性などに関連づけて予め記憶部２０に登録しておけばよい。

最後に、処理構築部３０は、検索ディレクトリ内のすべてのプラグインライブラリについて処理モジュールの生成が完了したか否かを判定する。（Ｓ２２４）。判定の結果、まだ処理モジュールの生成が済んでいない場合には（ステップＳ２２４の判定結果が、否定「Ｎ」）、次順のプラグインライブラリを処理対象のプラグインライブラリとして（Ｓ２２６）、ステップＳ２１６以降の処理を繰り返す。その後、すべてのプラグインライブラリについて処理モジュールの生成が済んだ時点で（ステップＳ２２４の判定結果、肯定「Ｙ」）、処理構築部３０は処理モジュール生成の処理を終了する。

例えば、図７Ａに示すようなディレクトリに各プラグインライブラリが格納されている場合、図７Ｂに示すように、各モジュールが連結される。なお、図７Ａ、図７Ｂにおいて、プラグイランライブラリａ〜ｅの入出力属性は同一とし、プラグインライブラリｆは、前段のプラグインライブラリｄ，ｅとは入出力属性が異なるものとする。

図７Ａ、図７Ｂに示すように、フォルダ１には、プラグインライブラリａが格納されているため、最前段には、プラグインライブラリａの処理モジュールａが登録され、さらにその後段にバッファモジュールＢが生成される。フォルダ２には、プラグインライブラリｂとプラグインライブラリｃとが存在するため、バッファモジュールＢ１の出力は２つに分岐される。また、プラグインライブラリｂは処理モジュールを２つ保有し、これらを直列に連結して、先頭の処理モジュールｂ１がバッファモジュールＢ１の一方の出力に連結される。また、プラグインライブラリｃの処理モジュールｃがバッファモジュールＢ１の他方の出力に連結される。同様に、フォルダ３には、２つのプラグインライブラリｄ，ｅが格納されているため、それぞれの処理モジュールｄ，ｅを前段の処理モジュールｂ２，ｃにバッファモジュールＢを介して連結される。加えて、フォルダ４は、１つのプラグインライブラリｆが格納される。また、その処理モジュールｆの入力属性と、処理モジュールｂ２，ｃの出力属性は異なるため、各属性を一致させるための属性変換処理モジュール７２が挿入され、処理モジュールｆが連結される。

以上の通り、本実施形態では、予めディレクトリを構築して、そのディレクトリ構造に基づきモジュールの連結順に対応する順番を予め各ディレクトリ（各フォルダ）に付与しておく。プログラム開発者は、画像処理に必要な各プラグインライブラリを、連結したい順番に、各ディレクトリに格納しておく。処理構築部３０は、構築対象の画像処理部に対応するディレクトリ群を参照して、そのディレクトリ群に対して予め定められた順番に、各ディレクトリのフォルダ内を検索して、フォルダ内のプラグインライブラリおよび対応する処理パラメータファイルを取得する。その後、各プラグインライブラリに基づいて生成された各処理モジュールをバッファモジュール（および必要に応じて属性変換処理モジュール）を介して、上記通りディレクトリ構造に基づき予め定められた順番に連結し、１つの画像処理部を構築する。

本実施形態によれば、ディレクトリ構造に基づいて画像処理部の連結順が予め定められている。よって、例えば、プラグインライブラリの修正、置き換えなどを行う場合には、対象のプラグインライブラリが格納されたフォルダを特定し、そのフォルダに新たなプラグインライブラリを格納するだけで済む。また、プラグインライブラリを追加する場合にも、挿入したいプラグインライブラリのフォルダとプラグインライブラリのフォルダとの間に新たなフォルダを追加し、そのフォルダに新たなプラグインライブラリを追加するだけで済む。

なお、本実施形態では、ディレクトリ構造で構築された各フォルダにプラグインライブラリの実体そのものを格納する例について説明した。しかし、プラグインライブラリ（および設定パラメータファイル）の実体は他のデータベースに格納しておき、ディレクトリ構造で構築された各フォルダには、プラグインライブラリを識別する識別子（例えば、プラグインライブラリ名や、プラグインライブラリの格納場所）のみ格納しおいてもよい。この場合、処理構築部３０は、各フォルダからプラグインライブラリの識別子を取得し、その識別子をキーとしてデータベースを検索し、対応するプラグインライブラリの実体を取得すればよい。

本実施形態に係る画像処理装置の全体の構成を機能ブロックで示した図である。 プラグインライブラリの構成例を機能ブロックで示した図である。 処理構築部によって構築される画像処理部（画像処理パイプライン）の一例を示す図である。 処理構築部によって構築される画像処理部（画像処理パイプライン）の一例を示す図である。 プラグインライブラリ蓄積部に蓄積されるプラグインライブラリのディレクトリ構造の一例を示す図である。 処理構築部がプラグインライブラリを用いて画像処理に必要な画像処理モジュールを連結する手順を示すフローチャートである。 処理構築部が検索ディレクトリ内の各プラグインライブラリを呼び出し、各プラグインライブラリの処理モジュールを生成する手順を示すフローチャートである。 プラグインライブラリ蓄積部に蓄積されるプラグインライブラリのディレクトリ構造の一例を示す図である。 図７Ａに示すディレクトリ構造で蓄積されたプラグインライブラリ群を用いて構築された画像処理部を示す図である。

符号の説明

１０ 情報処理装置、１２ ＣＰＵ、１４ メモリ、１６ 表示部、１８ 操作部、２０ 記憶部、２２ 画像データ供給部、２４ 画像出力部、２６ バス、３０ 処理構築部、４０ プラグインライブラリ蓄積部、４２ プラグインライブラリ、４４ 処理モジュール生成関数、４６ 処理生成モジュール、４８ 画像処理モジュール、５０ ディレクトリ管理部、６０ 画像処理部、７０ 補助モジュール蓄積部、７２ 属性変換処理モジュール、７４ バッファモジュール、８０ アプリケーションプログラム、８６ 制御手段、９０ オペレーティングシステム。

Claims (5)

1. 所定のタスクを実行するための複数の処理部品を少なくとも１つずつ格納する複数のフォルダをディレクトリ構造で保持する処理部品蓄積部と、
   各フォルダに格納された各処理部品を、前記ディレクトリ構造に基づき予め定められた連結順に従って、連結する連結部と、
   連結された各処理部品を実行して前記タスクを実行する実行部と、
   を備える情報処理装置。
2. 所定のタスクを実行するための複数の処理部品の各々に対応する各識別子を少なくとも１つずつ格納する複数のフォルダをディレクトリ構造で保持する識別子蓄積部と、
   各フォルダに格納された各識別子に基づいて、処理部品の実体を格納する処理部品格納部から各処理部品を取得し、前記ディレクトリ構造に基づき予め定められた連結順に従って、取得した各処理部品を連結する連結部と、
   連結された各処理部品を実行して前記タスクを実行する実行部と、
   を備える情報処理装置。
3. 請求項１または２に記載の情報処理装置において、
   各フォルダは、ディレクトリ構造上の同一階層に存在し、
   前記連結順は、各フォルダの各々を一意に特定する各フォルダ識別子を所定の規則に従って並べた場合における昇順あるいは降順に対応する、
   ことを特徴とする情報処理装置。
4. 所定のタスクを実行するための複数の処理部品を少なくとも１つずつ格納する複数のフォルダをディレクトリ構造で保持する処理部品蓄積部と、
   各フォルダに格納された各処理部品を、前記ディレクトリ構造に基づき予め定められた連結順に従って、連結する連結部と、
   連結された各処理部品を実行して前記タスクを実行する実行部と、
   してコンピュータを機能させるためのプログラム。
5. 所定のタスクを実行するための複数の処理部品の各々に対応する各識別子を少なくとも１つずつ格納する複数のフォルダをディレクトリ構造で保持する処理部品蓄積部と、
   各フォルダに格納された各識別子に基づいて、処理部品の実体を格納する処理部品格納部から各処理部品を取得し、前記ディレクトリ構造に基づき予め定められた連結順に従って、取得した各処理部品を連結する連結部と、
   連結された各処理部品を実行して前記タスクを実行する実行部と、
   してコンピュータを機能させるためのプログラム。

Images