JP7186541B2 - 画像処理装置、その制御方法、及びプログラム - Google Patents

Description

本発明は、画像処理装置、その制御方法、及びプログラムに関する。

従来から、画像処理装置で提供されていない画像処理を含む各種ジョブを実行したい場合、新規画像処理を含むジョブ実行アプリケーションをプラグインとして作成し、当該画像処理装置にインストールして実現することが知られている。ここで、各種ジョブとは、例えば、コピー、プリント、スキャン保存、及びスキャン送信といった、画像処理装置上で実行可能な画像処理を含むデバイス制御処理を表す。また、新規画像処理とは、例えば、入力データに対する斜行補正、フォーマット変換、ＯＣＲ（ｏｐｔｉｃａｌ ｃｈａｒａｃｔｅｒ ｒｅｃｏｇｎｉｔｉｏｎ）後の翻訳変換といった、画像処理装置の既存のジョブでは実現できない処理を表す。

複数の新規画像処理を追加した画像処理装置では、追加した新規画像処理を並列動作させることが可能である。しかし、メモリを多く利用する複数の画像処理が同時に実行されると、画像処理装置の保有するメモリの上限を超えてしまう場合がある。

メモリの上限を超えてしまうと、ＯＳは、使用頻度の低いメモリ領域をハードディスクに一旦退避して領域を空け、必要に応じてまたメモリに書き戻すｓｗａｐ操作を行う。この際、ＨＤＤに書き込み処理を行うため、同プロセス内の様々な処理のパフォーマンスを低下させる場合がある。例えばＵＩモジュールが同プロセスに存在する場合、ユーザの操作に対してＵＩ画面がすぐに反応しない現象が発生しうる。また、同プロセス上で実行している複数の画像処理の完了までの時間が、ｓｗａｐしていない場合と比較して遅くなる現象も発生しうる。さらに、Ｓｗａｐ領域までも使い果たしてしまった場合には、ＯＳがメモリリソースを多く消費しているプロセスを強制終了させてしまう。この場合、画像処理を行うプロセスが終了してしまうため、画像処理装置を再起動しないと画像処理を再開することはできない。

そこで、特許文献１には、個々のプラグインで使用されるメモリ使用量をリアルタイムで計測し、予め決められたメモリ最大量を上回る場合はプラグインを起動させない技術が提案されている。

特開２０１３－０１２０１０３号公報

しかしながら、上記従来技術には以下に記載する課題がある。上記従来技術では、例えば、プラグイン起動時に各プラグインに定義された使用メモリ宣言量と、既に画像処理装置で利用しているメモリ使用量の合計を計算する。さらに、予め決められたメモリ最大量を合計のメモリ使用量が上回る場合は、プラグイン自体を起動させないことによって、上述のようなメモリ不足を回避している。上記制御では、メモリ使用量が上回る計算となった場合、既に起動しているプラグインを停止させない限り、新規のプラグインを起動することができない。したがって、実際には並列で実行しなければ実行できるプラグインであっても起動して処理を行うことができず、ユーザの利便性が低下するといった課題が存在する。

本発明は、上述の問題の少なくとも一つに鑑みて成されたものであり、処理実行中に（ランタイムで）総メモリ使用量を動的に計算し、プラグイン自体の起動を制限することなく、好適にメモリ不足を回避しつつ、複数の画像処理を並行して実行する仕組みを提供することを目的とする。

本発明は、例えば、１以上の画像処理モジュールがプレインストールされた画像処理装置であって、アプリケーションによる要求に応じて第一の画像処理モジュールで画像処理を実行中に、アプリケーションによる新たな画像処理が要求されると、前記新たな画像処理を実行可能な第二の画像処理モジュールを探索する探索手段と、前記探索手段によって探索された第二の画像処理モジュールによる新たな画像処理を実行した際のメモリ使用量、及び前記第一の画像処理モジュールによって既に実行中の画像処理のメモリ使用量を取得する取得手段と、前記取得手段によって取得された各画像処理のメモリ使用量及び前記新たな画像処理を実行した際のメモリ使用量から得られる総メモリ使用量と、画像処理モジュールが動作するプロセスでの使用が許容されるメモリ使用量を示す許容メモリ量とを比較する比較手段と、前記比較手段によって比較した結果、前記総メモリ使用量が前記許容メモリ量を超えない場合は前記新たな画像処理を実行し、前記総メモリ使用量が前記許容メモリ量を超える場合は前記新たな画像処理を実行せず、要求元の動作中のアプリケーションに対してメモリ不足により前記新たな画像処理が実行できない旨のエラーを通知する実行制御手段とを備えることを特徴とする。

また、本発明は、例えば、画像処理装置であって、第一の実行環境で動作中のアプリケーションからの画像処理の要求に応じて、前記第一の実行環境とは論理メモリ空間が異なる第二の実行環境で動作する第一の画像処理モジュールでの画像処理の実行中に、前記アプリケーションによる新たな画像処理の実行が要求されると、該新たな画像処理を実行可能な第二の画像処理モジュールを探索する探索手段と、前記探索手段によって探索された前記第二の画像処理モジュールとともに保持されている、該第二の画像処理モジュールによる新たな画像処理を実行した際のメモリ使用量と、前記第二の実行環境で既に実行中の画像処理のそれぞれのメモリ使用量とを取得する取得手段と、前記取得手段によって取得された各画像処理のメモリ使用量及び前記要求された新たな画像処理を実行した際のメモリ使用量から得られる総メモリ使用量と、前記第二の実行環境での使用が許容されるメモリ使用量を示す許容メモリ量とを比較する比較手段と、前記比較手段による比較の結果、前記総メモリ使用量が前記許容メモリ量を超えない場合は前記新たな画像処理を実行し、前記総メモリ使用量が前記許容メモリ量を超える場合は前記新たな画像処理を実行せず、要求元の前記第一の実行環境で動作中のアプリケーションに対してメモリ不足により前記新たな画像処理が実行できない旨のエラーを通知する実行制御手段と、を備えることを特徴とする。

本発明によれば、処理実行中に総メモリ使用量を動的に計算し、プラグイン自体の起動を制限することなく、好適にメモリ不足を回避しつつ、複数の画像処理を並行して実行することができる。

一実施形態に係る画像処理形成システムの構成例を表す図。 一実施形態に係る画像処理装置のハードウェア構成の一例を表す図。 一実施形態に係る画像処理装置のソフトウェア構成の一例を示す図。 一実施形態に係る画像処理装置の処理手順を示すフローチャート。 一実施形態に係るＮａｔｉｖｅ画像処理サーバの処理手順を示すフローチャート。 一実施形態に係る画像処理装置のソフトウェア構成の一例を示す図。 一実施形態に係る画像処理装置の処理手順を示すフローチャート。 一実施形態に係るＮａｔｉｖｅ画像処理モジュールの処理手順を示すフローチャート。 一実施形態に係るＮａｔｉｖｅ画像処理サーバの処理手順を示すフローチャート。 一実施形態に係るＮａｔｉｖｅ画像処理サーバの処理手順を示すフローチャート。 一実施形態に係るＮａｔｉｖｅ画像処理モジュールの処理手順を示すフローチャート。

以下に本発明の一実施形態を示す。以下で説明される個別の実施形態は、本発明の上位概念、中位概念及び下位概念など種々の概念を理解するために役立つであろう。また、本発明の技術的範囲は、特許請求の範囲によって確立されるのであって、以下の個別の実施形態によって限定されるわけではない。なお、実施形態に係る印刷装置として複合機（デジタル複合機／ＭＦＰ／Ｍｕｌｔｉ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）を例に説明する。しかしながら適用範囲は複合機に限定はせず、印刷装置であればよい。

＜第１の実施形態＞
＜システム構成＞
以下では、添付図面を参照して、本発明の第１の実施形態について説明する。まず、図１を参照して、画像形成システムの構成の一例を説明する。本実施形態に係る画像形成システムは、画像処理装置１０１、１０２と、情報処理端末１０３、１０４と、サーバ１０５とを含んで構成される。画像処理装置１０１、１０２と、情報処理端末１０３、１０４と、サーバ１０５とは、ネットワーク１０６により相互に通信可能に接続される。

図１では、画像処理装置１０１、１０２が２台である場合を一例として示すが、画像処理装置の数は任意（１つ又は２以上）である。また、それぞれの画像処理装置１０１、１０２は、同様の構成で実現することができる。従って、以下では、画像処理装置１０１、１０２を代表して画像処理装置１０１の構成について説明し、画像処理装置１０２についての詳細な説明を省略する。なお、ネットワーク１０６は、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、Ｉｎｔｅｒｎｅｔ等、画像形成システム内の装置が相互に通信できるものであればよい。また、情報処理端末やサーバについてもその台数や機能を限定する意図はない。サーバ１０５については、その機能を分散して複数台の装置で実現されてもよい。なお、本発明を適用する画像処理装置は、画像形成機能を必ずしも含む必要はなく、複数の画像処理を同時に（並行して）実行可能な装置であれば適用することができる。

画像処理装置１０１は、情報処理端末１０３、１０４から画像データの印刷依頼（印刷データ）を受信して印刷することや、画像処理装置１０１に備わるスキャナで画像データを読み取ることや、スキャナで読み取られた画像データを印刷することが可能である。また、画像処理装置１０１は、情報処理端末１０３、１０４から受信した印刷データを保存したり、画像処理装置１０１のスキャナで読み取られた画像を情報処理端末１０３、１０４に送信したりすることが可能である。更に画像処理装置１０１は、サーバ１０５を用いて画像処理を行ったり、サーバ１０５に格納されている文書を印刷したりすることが可能である。画像処理装置１０１は、この他に、ＭＦＰ（Ｍｕｌｔｉｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）等の公知の画像処理装置が有する機能を実現することが可能である。

＜画像処理装置のハードウェア構成＞
次に、図２を参照して、画像処理装置１０１のハードウェア構成の一例を説明する。画像処理装置１０１は、コントローラ２０１、プリンタ２０２、スキャナ２０３、及び操作部２０４を備える。コントローラ２０１は、ＣＰＵ２１１、ＲＡＭ２１２、ＨＤＤ２１３、ネットワークＩ／Ｆ２１４、プリンタＩ／Ｆ２１５、スキャナＩ／Ｆ２１６、操作部Ｉ／Ｆ２１７、及び拡張Ｉ／Ｆ２１８を備える。ＣＰＵ２１１は、ＲＡＭ２１２、ＨＤＤ２１３、ネットワークＩ／Ｆ２１４、プリンタＩ／Ｆ２１５、スキャナＩ／Ｆ２１６、操作部Ｉ／Ｆ２１７、及び拡張Ｉ／Ｆ２１８とデータを授受することが可能である。

ＣＰＵ２１１は、ＨＤＤ２１３から読み出した命令をＲＡＭ２１２に展開し、ＲＡＭ２１２に展開した命令を実行し、後述する各種処理を実行する。ＨＤＤ２１３には、ＣＰＵ２１１で実行可能な命令、画像処理装置１０１で使用する設定値、及びユーザから依頼された処理に関するデータ等を記憶しておくことが可能である。ＲＡＭ２１２は、ＣＰＵ２１１がＨＤＤ２１３から読み出した命令を一時的に格納するための領域である。また、ＲＡＭ２１２は、命令の実行に必要な各種のデータを記憶しておくことも可能である。例えば画像処理では、入稿されたデータをＲＡＭ２１２に展開することで処理を行うことが可能である。

ネットワークＩ／Ｆ２１４は、画像形成システム内の装置とネットワーク通信を行うためのインタフェースである。ネットワークＩ／Ｆ２１４は、データ受信を行ったことをＣＰＵ２１１に伝達することや、ＲＡＭ２１２上のデータをネットワーク１０６に送信することが可能である。プリンタＩ／Ｆ２１５は、ＣＰＵ２１１から送信された印刷データをプリンタ２０２に送信することや、プリンタ２０２から受信したプリンタの状態をＣＰＵ２１１に伝達することが可能である。スキャナＩ／Ｆ２１６は、ＣＰＵ２１１から送信された画像読み取り指示をスキャナ２０３に送信し、スキャナ２０３から受信した画像データをＣＰＵ２１１に伝達することや、スキャナ２０３から受信した状態をＣＰＵ２１１に伝達することが可能である。

操作部Ｉ／Ｆ２１７は、操作部２０４から入力されたユーザからの指示をＣＰＵ２１１に伝達することや、ユーザが操作するための画面情報を操作部２０４に伝達することが可能である。拡張Ｉ／Ｆ２１８は、画像処理装置１０１に外部機器を接続することを可能とするインタフェースである。拡張Ｉ／Ｆ２１８は、例えば、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）形式のインタフェースを具備する。画像処理装置１０１は、ＵＳＢメモリ等の外部記憶装置が拡張Ｉ／Ｆ２１８に接続されることにより、当該外部記憶装置に記憶されているデータの読み取り及び当該外部記憶装置に対するデータの書き込みを行うことが可能である。

プリンタ２０２は、プリンタＩ／Ｆ２１５から受信した画像データを用紙やシート等の記録媒体に印刷することや、プリンタ２０２の状態をプリンタＩ／Ｆ２１５に伝達することが可能である。スキャナ２０３は、スキャナＩ／Ｆ２１６から受信した画像読み取り指示に従って、自身に置かれた用紙に表示されている情報を読み取ってデジタル化してスキャナＩ／Ｆ２１６に伝達することが可能である。また、スキャナ２０３は、自身の状態をスキャナＩ／Ｆ２１６に伝達することが可能である。操作部２０４は、画像処理装置１０１に対して各種の指示を行うための操作をユーザに行わせるためのインタフェースである。例えば、操作部２０４は、タッチパネルを有する液晶画面を具備し、ユーザに操作画面を提供すると共に、ユーザからの操作を受け付ける。

＜画像処理装置のソフトウェア構成＞
次に、図３を参照して、本実施形態に係るＣＰＵ２１１が処理するソフトウェアの構造の一例を説明する。図３に示す構造を有するソフトウェアは、画像処理装置１０１のＨＤＤ２１３に記憶されたプログラムを用いることにより構成される。図３において、一部の例外を除いて、下位の階層が提供するサービスを上位の階層が利用する関係になっている。

図３において、最下層は、オペレーティングシステム３１７を含み、プログラムの実行の管理やメモリ管理等を行う階層である。オペレーティングシステム３１７の中には、プリンタ制御ドライバ３１８、スキャナ制御ドライバ３１９、及びネットワークＩ／Ｆ制御ドライバ３２０が組み込まれる。プリンタ制御ドライバ３１８、スキャナ制御ドライバ３１９、及びネットワークＩ／Ｆ制御ドライバ３２０は、相互に連携することにより機能することが可能である。プリンタ制御ドライバ３１８はプリンタＩ／Ｆ２１５を介してプリンタ２０２を制御するためのソフトウェアである。スキャナ制御ドライバ３１９はスキャナＩ／Ｆ２１６を介してスキャナ２０３を制御するためのソフトウェアである。ネットワークＩ／Ｆ制御ドライバ３２０はネットワークＩ／Ｆ２１４を制御するためのソフトウェアである。

最下層から２段目の層には、第２の実行環境の一例となる言語デバイス制御ライブラリ３０９と画像処理制御部３４０とが含まれる。本実施形態においては、例えば、デバイス制御ライブラリ３０９と画像処理制御部３４０とはＣ言語やＣ＋＋言語などのコンパイル言語（第２のプログラミング言語）で記述される。従って、ＣＰＵ２１１で直接実行できるオブジェクトファイルの形式でＨＤＤ２１３に格納されているものとする。デバイス制御ライブラリ３０９は、後述の単独機能プラグインアプリケーション３０２又はデバイス制御アプリケーション３０４と静的又は動的にリンクされる。さらに、デバイス制御ライブラリ３０９は、各アプリケーションプログラムによる指示に基づいて、オペレーティングシステム３１７を利用する。また、各デバイス制御ライブラリ３０９は、Ｎａｔｉｖｅ画像処理接続ライブラリ３１４に対して画像処理を依頼することも可能である。

次に、デバイス制御ライブラリ３０９の構成の一例について説明する。プリントライブラリ３１０は、プリンタ制御ドライバ３１８の機能を利用してプリントジョブの制御を行うためのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を提供するライブラリである。プリントジョブは、画像処理装置１０１のＨＤＤ２１３に保存されている印刷データを印刷することや、ネットワークＩ／Ｆ２１４を通して外部装置から受信した印刷データを印刷するといった一連の処理を示す。外部装置は、例えば、情報処理端末１０３、１０４である。コピーライブラリ３１１は、スキャナ制御ドライバ３１９及びプリンタ制御ドライバ３１８の機能を利用して、コピージョブの制御を行うためのＡＰＩを提供するライブラリである。コピージョブは、スキャナ２０３でスキャンされた画像データをプリンタ２０２で印刷する一連の処理を示す。

スキャン保存ライブラリ３１２は、スキャナ制御ドライバ３１９の機能を利用してスキャン保存ジョブの制御を行うためのＡＰＩを提供するライブラリである。スキャン保存ジョブは、スキャナ２０３でスキャンされた画像データを印刷データ又は汎用フォーマットに変換後、ＨＤＤ２１３又は拡張Ｉ／Ｆ２１８に接続されているＵＳＢ等の外部記憶装置に保存する一連の処理を示す。なお、汎用フォーマットは、例えば、ＰＤＦ（Ｐｏｒｔａｂｌｅ Ｄｏｃｕｍｅｎｔ Ｆｏｒｍａｔ）やＪＰＥＧ（Ｊｏｉｎｔ Ｐｈｏｔｏｇｒａｐｈｉｃ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）といったデータフォーマットである。

スキャン送信ライブラリ３１３は、スキャナ制御ドライバ３１９及びネットワークＩ／Ｆ制御ドライバ３２０の機能を利用して、スキャン送信ジョブの制御を行うためのＡＰＩを提供するライブラリである。スキャン送信ジョブは、スキャナ２０３でスキャンされた画像データを汎用フォーマットに変換後、ネットワークＩ／Ｆ２１４を通してファイルサーバに送信したり、電子メールに添付して外部装置に送信したりする一連の処理を示す。ここで、ファイルサーバは、例えばサーバ１０５であり、外部装置は、例えば情報処理端末１０３、１０４である。

画像処理制御部３４０は、Ｎａｔｉｖｅ画像処理接続ライブラリ３１４、Ｎａｔｉｖｅ画像処理サーバ３１５、及びＮａｔｉｖｅ画像処理モジュール（ネイティブアプリケーション）３１６を含む。ここで、ネイティブアプリケーションとは、画像処理装置１０１にプリインストールされ、画像処理等の各種機能を提供するアプリケーションである。一方、後述するプラグインアプリケーションは、画像処理装置１０１に対して、製品出荷後に追加可能なアプリケーションである。Ｎａｔｉｖｅ画像処理接続ライブラリ３１４は、デバイス制御ライブラリ３０９から画像処理の実行依頼を受けると、画像処理接続ライブラリ３３２に依頼内容を転送する。Ｎａｔｉｖｅ画像処理サーバ３１５は、後述するＪａｖａ（登録商標）言語で記述されたソフトウェアから依頼を受けてＮａｔｉｖｅ画像処理モジュールを実行する機能を提供する。Ｎａｔｉｖｅ画像処理モジュール３１６は、様々な種類の画像処理を実行することの可能なソフトウェアである。なお、Ｎａｔｉｖｅ画像処理サーバ３１５及びＮａｔｉｖｅ画像処理モジュール３１６は、図３に記載の他のソフトウェアとは分離された論理メモリ空間を有するプログラム実行単位である、Ｎａｔｉｖｅ画像処理制御プロセス３５０上で実行される。メモリ空間を分離する具体的な方法としては、一般的なＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）が備えるプロセス機構を用いることが考えられるが、他の方法でも構わない。このように、画像処理を行う場合に論理メモリ空間を分離する構成とすることにより、複雑な演算やこれに伴うメモリ操作を行う場合でも、処理の不具合が処理の依頼側に及ぼす影響を抑制することができる。

最上位層であるＪａｖａ言語実行環境３３０は、第１の実行環境の一例であり、プラグインアプリケーション３０１及びデバイス制御アプリケーション３０４を含む、アプリケーション層である。本実施形態では、プラグインアプリケーション３０１及びデバイス制御アプリケーション３０４はＪａｖａ言語（第１のプログラミング言語）で記述され、Ｊａｖａ仮想マシンが解釈するＪａｖａバイトコード形式でＨＤＤ２１３に格納される。そのため、ＣＰＵ２１１はＪａｖａ仮想マシンのプログラムを実行し、Ｊａｖａ仮想マシンがＪａｖａバイトコードを読み出して実行することによって処理を行う。このようなプログラミング言語を利用する理由の一つにプログラム記述の簡易さが挙げられる。Ｊａｖａにおいては、メモリ領域の管理を開発者で行う必要がなく、自動的に行われる。従って、プログラムを記述する際の手間が低減され、開発効率が向上することが見込まれる。

各アプリケーションは、デバイス制御ライブラリ３０９や画像処理接続ライブラリ３３２の各ＡＰＩを利用しながら動作することで様々な機能を提供する。また、デバイス制御アプリケーション３０４は、ファームウェアの更新により、その機能を拡張することが可能である。デバイス制御アプリケーション３０４に含まれるプリントアプリケーション３０５、コピーアプリケーション３０６、スキャン保存アプリケーション３０７、及びスキャン送信アプリケーション３０８は、それぞれ画面情報３２１、３２２、３２３、３２４を有する。ＣＰＵ２１１は、操作部Ｉ／Ｆ２１７を通して操作部２０４にそれぞれの画面情報３２１、３２２、３２３、３２４を表示する。ＣＰＵ２１１は、ユーザが操作部２０４を操作することによりデバイス制御アプリケーション３０４の設定の変更を検知すると、その変更の内容をＨＤＤ２１３に書き込む。

ＣＰＵ２１１（デバイス制御アプリケーション３０４）は、操作部２０４を介してジョブの実行依頼を検知すると、デバイス制御ライブラリ３０９のＡＰＩをコールすることにより当該ジョブを開始する。また、デバイス制御アプリケーション３０４は、画像処理接続ライブラリ３３２に対して、画像処理を依頼することも可能である。

画像処理接続ライブラリ３３２は許容メモリ定義部３２５を保持する。許容メモリ定義部３２５には画像処理接続ライブラリ３３２が同時実行する際の最大の許容メモリ量が定義されている。許容メモリ定義部３２５に定義された許容メモリは、プログラムに直接記載してＨＤＤ２１３から取得する方法や、予め許容量を定義したファイルを設置した上で、実行時にロードする方法などが挙げられる。なお、許容メモリを取得する方法は上述以外の方法でも構わない。画像処理接続ライブラリ３３２は、さらに実行中メモリ管理部３２６を保持する。実行中メモリ管理部３２６は、画像処理接続ライブラリ３３２経由で実行中の画像処理の総メモリ量を管理している。

次に、デバイス制御アプリケーション３０４の一例について説明する。プリントアプリケーション３０５は、プリントライブラリ３１０のＡＰＩをコールすることによりプリントジョブを実行する。コピーアプリケーション３０６は、コピーライブラリ３１１のＡＰＩをコールすることによりコピージョブを実行する。スキャン保存アプリケーション３０７は、スキャン保存ライブラリ３１２のＡＰＩをコールすることによりスキャン保存ジョブを実行する。スキャン送信アプリケーション３０８は、スキャン送信ライブラリ３１３のＡＰＩをコールすることでスキャン送信ジョブを実行する。

次に、プラグインアプリケーション３０１の一例について説明する。プラグインアプリケーション３０１は、常駐アプリケーションであるデバイス制御アプリケーション３０４とは別に、プラグインとしてインストール及びアンインストールが可能なアプリケーションである。プラグインアプリケーション３０１は、単独機能プラグインアプリケーション３０２と、画像処理プラグインアプリケーション３０３とを有する。プラグインアプリケーション３０１には、それぞれ動作に必要なプログラムがパッケージングされている。プラグインアプリケーション３０１は、リモートＵＩ（Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）等を用いることにより、画像処理装置１０１にインストールされる。なお、リモートＵＩは、外部装置におけるＷｅｂブラウザからネットワークＩ／Ｆ２１４を経由して画像処理装置１０１にアクセスし、画像処理装置１０１の状況の確認、印刷ジョブの操作、及び各種設定などを行うことができる仕組みである。外部装置は、例えば、情報処理端末１０３、１０４である。また、プラグインアプリケーション３０１（単独機能プラグインアプリケーション３０２、及び画像処理プラグインアプリケーション３０３）は、それぞれ個別に起動及び停止を行うことが可能である。

以下に、プラグインアプリケーション３０１のインストールから起動、停止、アンインストールまでの一連の流れの一例を示す。ＣＰＵ２１１は、プラグインアプリケーション３０１のインストールを検知すると、当該プラグインアプリケーション３０１の情報をＨＤＤ２１３に保存する。続いて、ＣＰＵ２１１は、プラグインアプリケーション３０１に対する開始指示を検知すると、当該プラグインアプリケーション３０１に対する起動指示を行う。プラグインアプリケーション３０１は起動している間、各プログラムの内容を実行することが可能である。続いて、ＣＰＵ２１１は、プラグインアプリケーション３０１に対する停止指示を検知すると、当該プラグインアプリケーション３０１に対して停止指示を行う。さらに、ＣＰＵ２１１は、プラグインアプリケーション３０１に対するアンインストール指示を検知すると、当該プラグインアプリケーション３０１の情報をＨＤＤ２１３から削除する。なお、これらの指示は、例えば、リモートＵＩや操作部２０４から行うことが可能であるが、これら以外の方法でこれらの指示が行われても構わない。

次に、単独機能プラグインアプリケーション３０２の一例について説明する。単独機能プラグインアプリケーション３０２は、画面情報３２１を有する。単独機能プラグインアプリケーション３０２は、デバイス制御ライブラリ３０９のＡＰＩをコールすることで常駐のデバイス制御アプリケーション３０４とは別の機能や画面をユーザに提供することができる。例えば、単独機能プラグインアプリケーション３０２は、ある画像データをコピーすると共にスキャンし、自身が保持する送信先データベース内の特定の宛先に文書を送信する機能等、複数の機能を組み合わせて提供することが可能である。なお、単独機能プラグインアプリケーション３０２は、画像処理を行う機能を有していなくてもよい。この場合、画像処理の設定は行われない。更に、デバイス制御ライブラリ３０９は、印刷データ又は汎用フォーマットに変換後の画像データを受信すると、適切なオペレーティングシステム３１７に対して処理制御を指示し、ジョブを実行させる。

次に、画像処理プラグインアプリケーション３０３の一例について説明する。画像処理プラグインアプリケーション３０３は、特定の画像処理を提供するアプリケーションである。画像処理プラグインアプリケーション３０３は、単独機能プラグインアプリケーション３０２やデバイス制御アプリケーション３０４などから画像処理接続ライブラリ３３２経由で処理対象の画像データと処理パラメータを受け付け、依頼された画像処理を実行する。また、画像処理プラグインアプリケーション３０３はデバイス制御ライブラリ３０９からも、Ｎａｔｉｖｅ画像処理接続ライブラリ３１４と画像処理接続ライブラリ３３２を経由して画像処理依頼を受信することが可能である。なお、画像処理プラグインアプリケーション３０３は、ＨＤＤ２１３内に複数存在してもよい。例えば、入力画像に対する画像形式変換、斜行補正や、帳票認識やＯＣＲ処理等を行うことができる画像処理プラグインアプリケーション３０３がそれぞれ存在してもよい。

画像処理プラグインアプリケーション３０３は、それ自体が画像処理機能を有していなくてもよい。例えば、画像処理プラグインアプリケーション３０３は、Ｎａｔｉｖｅ画像処理クライアント３３１を利用し、Ｎａｔｉｖｅ画像処理モジュール３１６の画像処理機能を利用することもできる。画像処理プラグインアプリケーション３０３がＮａｔｉｖｅ画像処理モジュール３１６を利用する理由の一例として、画像処理を行う際の処理速度の高速化が挙げられる。画像処理を行う際には大量かつ複雑な数値演算を行ったり、処理の過程で大量のメモリを必要とする場合がある。そのような場合にはＪａｖａのような仮想マシンを仲介して処理を行うプログラミング言語処理系を利用するよりも、直接ＣＰＵが実行可能なオブジェクトファイルを生成できるコンパイル言語を利用する方が処理速度を向上させることができる。

各画像処理プラグインアプリケーション３０３は、実行メモリ定義部３２７を保持する。実行メモリ定義部３２７には、各プラグインが実行する画像処理によって利用される最大メモリ量が定義されている。なお、上述のメモリ量は、プラグインごとに保持してもよいし、画像処理の関数ごとに保持してもよい。

＜処理手順＞
次に、図４を参照して、本実施形態に係る画像処理装置１０１の処理手順の一例を説明する。ここでは、画像処理接続ライブラリ３３２が画像処理を受け付け、メモリ制御を行った上で画像処理プラグインアプリケーション３０３に処理依頼を行うケースを想定する。本フローチャートでは、画像処理プラグインアプリケーション３０３を用いた画像処理の一例を示す。なお、以下で説明する処理は、例えばＣＰＵ２１１がＨＤＤ２１３に保存されたプログラムをＲＡＭ２１２に読み出して実行することにより実現される。

まず、Ｓ４０１で、画像処理接続ライブラリ３３２は、デバイス制御アプリケーション３０４、Ｎａｔｉｖｅ画像処理接続ライブラリ３１４、又は単独機能プラグインアプリケーション３０２から画像処理の実行依頼を受信する。このとき、受信した実行依頼には処理を依頼する画像処理プラグインアプリケーション３０３を特定するために必要なパラメータが入力されているものとする。

次に、Ｓ４０２で、画像処理接続ライブラリ３３２は、取得した実行依頼に対応する画像処理を実行可能な画像処理プラグインアプリケーション３０３を探索する。続いて、Ｓ４０３で、画像処理接続ライブラリ３３２は、Ｓ４０２の探索結果に基づいて、対象となる画像処理プラグインアプリケーションが存在したか否かを判定する。

Ｓ４０３で受信した画像処理依頼を実行できるアプリケーションが存在しないと判定するとＳ４０４に進み、画像処理接続ライブラリ３３２は、受信した画像処理を実行できるアプリケーションが存在しない旨のエラーを依頼元（要求元）のモジュールに返却する。その後、処理を終了する。例えば、Ｎａｔｉｖｅ画像処理接続ライブラリ３１４が依頼元であった場合、デバイス制御ライブラリ３０９を通じて、デバイス制御アプリケーション３０４又は単独機能プラグインアプリケーション３０２に上述のエラー内容が伝播される。デバイス制御アプリケーション３０４又は単独機能プラグインアプリケーション３０２は受信した上述のエラー内容を各アプリケーションの操作画面に表示する。本エラーにより、処理に必要なモジュールが存在していないことをユーザが知ることが可能となる。したがって、サービスマン又はＩＴ管理者が上述のインストール手法によって必要な画像処理プラグインアプリケーション３０３をインストールすることにより、処理を継続することが可能である。

一方、Ｓ４０３で対象の画像処理プラグインアプリケーション３０３が存在したと判定すると、Ｓ４０５に進み、画像処理接続ライブラリ３３２は、対象の画像処理プラグインアプリケーション３０３の実行メモリ定義部３２７から実行メモリ量を取得する。この実行メモリ量は、上述したように、各プラグイン単位で定義されてもよいし、各プラグインにおける画像処理の各関数単位で保持されてもよい。続いて、Ｓ４０６で、画像処理接続ライブラリ３３２は、自身の許容メモリ定義部３２５から許容メモリ量を取得する。続いて、Ｓ４０７で、画像処理接続ライブラリ３３２は、自身の実行中メモリ管理部３２６から実行中総メモリ量を取得する。

次に、Ｓ４０８で、画像処理接続ライブラリ３３２は、取得した実行中メモリ量と、自身が管理している実行中総メモリ量を加算した結果が、許容メモリ量を超えるか否か（メモリ不足となるか否か）を判断する。超えないと判断した場合、Ｓ４０９で、画像処理接続ライブラリ３３２は、実行中メモリ管理部３２６で管理している実行中メモリ量に実行メモリ定義部３２７で定義された実行メモリ量を加算する。続いて、Ｓ４１０で、画像処理接続ライブラリ３３２は、対象の画像処理プラグインアプリケーション３０３に処理を依頼する。画像処理プラグインアプリケーション３０３は、画像処理接続ライブラリ３３２から処理パラメータと共に、画像処理依頼を受信すると、処理パラメータに応じて画像処理を実行する。画像処理は画像処理プラグインアプリケーション３０３内で行う手法と、Ｎａｔｉｖｅ画像処理モジュール３１６で実行する手法があるが、詳細については後述する。なお、画像処理実行時に、画像処理プラグインアプリケーション３０３又はＮａｔｉｖｅ画像処理モジュール３１６では、ＣＰＵ２１１が入力データをＲＡＭ２１２に展開する。この際に画像処理内容、及び入力データサイズに応じた量のメモリを確保する必要がある。その後、Ｓ４１１で、画像処理接続ライブラリ３３２は、画像処理プラグインアプリケーション３０３から処理結果を受信すると、Ｓ４１２で実行中総メモリ量から実行メモリ量を減算する。さらに、Ｓ４１３で、画像処理接続ライブラリ３３２は、画像処理結果を依頼元の各モジュールに返却し、処理を終了する。

一方、Ｓ４０８で超えたと判断した場合、Ｓ４１４に進み、画像処理接続ライブラリ３３２は、依頼元のモジュールに対し、現在画像処理に必要なメモリリソースが足りていないため（メモリ不足のため）実行できない旨のエラーを返却し、処理を終了する。Ｎａｔｉｖｅ画像処理接続ライブラリ３１４が依頼元であった場合、デバイス制御ライブラリ３０９を通して、上述のエラー内容がデバイス制御アプリケーション３０４又は単独機能プラグインアプリケーション３０２に伝播される。デバイス制御アプリケーション３０４又は単独機能プラグインアプリケーション３０２は受信した上述のエラー内容に基づき、例外処理を実行する。

上記例外処理の一例としてリトライ処理が挙げられる。各アプリケーションは上述のエラーの受信により、画像処理接続ライブラリ３３２上で複数の画像処理が同時に実行されていると判断できる。従って、各アプリケーションは、一旦現在実行中の画像処理が終わるのをリトライにより待ち、実行中の画像処理が終わったタイミングで再び画像処理要求を送信する。これにより、処理を中断することなく継続することが可能となる。

また、その他の例外処理として、各アプリケーションの操作画面において、複数の画像処理が同時実行中であるため、時間を置いて（所定時間が経過した後に）再度ジョブを投入するように促す旨のエラーを表示する制御が挙げられる。ユーザは上述のエラーによって、時間を置けばジョブが実行可能であることを知ることが可能となる。

上述のように、本実施形態によれば、画像処理実行を行うモジュール（プラグインアプリケーション）に処理依頼を行う前に、実行する画像処理によって許容メモリ量を超えるか否かを予め判断し、超える場合にはそもそも画像処理を依頼しない。これにより、本実施形態では、許容メモリ量を超えたメモリの確保を回避することができる。したがって、システムが許容するメモリ量を超えたメモリを確保することでシステムの動作が不安定になる前に、事前にメモリ確保の制御を行うことが可能となる。

＜画像処理プラグインアプリケーションによる画像処理＞
以下では、画像処理プラグインアプリケーションによる画像処理について説明する。画像処理を依頼された画像処理プラグインアプリケーション３０３は、依頼された処理内容に基づき、画像処理を実行する。画像処理プラグインアプリケーション３０３は、少なくとも２種類の方法で画像処理を実行することができる。１つ目は、画像処理プラグインアプリケーション３０３内で実行する方法である。この場合、画像処理プラグインアプリケーションは、画像処理接続ライブラリ３３２から受信した処理依頼及び処理パラメータを元に画像処理を実行する。この場合、画像処理プラグインアプリケーションはＪａｖａ言語で記載する必要がある。２つ目は、Ｎａｔｉｖｅ画像処理モジュール３１６に依頼する方法である。画像処理プラグインアプリケーション３０３は、Ｎａｔｉｖｅ画像処理クライアント３３１に処理を依頼することにより、画像処理プラグインアプリケーション３０３とは異なる画像処理専用プロセスにおいて画像処理を実行することが可能となる。

ここで、図５を参照して、各画像処理プラグインアプリケーション３０３が画像処理を実行する処理手順を説明する。本フローチャートでは、Ｎａｔｉｖｅ画像処理サーバ３１５に依頼して画像処理を実行する処理手順を示す。なお、以下で説明する処理は、例えばＣＰＵ２１１がＨＤＤ２１３に保存されたプログラムをＲＡＭ２１２に読み出して実行することにより実現される。

画像処理プラグインアプリケーション３０３はＮａｔｉｖｅ画像処理クライアント３３１に処理パラメータと共に画像処理依頼を送信する。Ｎａｔｉｖｅ画像処理クライアント３３１はＮａｔｉｖｅ画像処理サーバ３１５に対して、受信した処理パラメータと共に処理依頼を行う。

Ｓ５０１で、Ｎａｔｉｖｅ画像処理サーバ３１５は、画像処理の実行依頼を受信すると、Ｓ５０２で、受信した処理パラメータを元に、対象となるＮａｔｉｖｅ画像処理モジュール３１６を探索する。続いて、Ｓ５０３で、Ｎａｔｉｖｅ画像処理サーバ３１５は、対象のＮａｔｉｖｅ画像処理モジュール３１６が存在するか否かを判定する。存在しない場合は、Ｓ５０４に進み、Ｎａｔｉｖｅ画像処理サーバ３１５は、対象のＮａｔｉｖｅ画像処理モジュール３１６が存在しない旨のエラーをＮａｔｉｖｅ画像処理クライアント３３１に返却し、処理を終了する。

一方、対象のＮａｔｉｖｅ画像処理モジュール３１６が存在する場合、Ｓ５０５に進み、Ｎａｔｉｖｅ画像処理サーバ３１５は、対象のＮａｔｉｖｅ画像処理モジュール３１６において、受信した処理パラメータを元に画像処理を実行させる。続いて、Ｓ５０６で、Ｎａｔｉｖｅ画像処理サーバ３１５は、Ｓ５０５の画像処理結果をＮａｔｉｖｅ画像処理クライアント３３１に返却し、処理を終了する。Ｎａｔｉｖｅ画像処理クライアント３３１は、画像処理結果又はエラー内容を受信すると、その内容を画像処理プラグインアプリケーション３０３に返却する。

以上説明したように、本実施形態に係る画像処理装置は、１以上のプラグインアプリケーションによる複数の画像処理を実行可能な画像処理装置である。本画像処理装置は、プラグインアプリケーションによる画像処理の実行中に、プラグインアプリケーションによる新たな画像処理の実行が要求されると、当該新たな画像処理を実行可能なプラグインアプリケーションを探索する。また、探索されたプラグインアプリケーションとともに保持されている、プラグインアプリケーションによる新たな画像処理を実行した際のメモリ使用量と、プラグインアプリケーションによって既に実行中の画像処理のそれぞれのメモリ使用量とを取得する。また、取得された各画像処理のメモリ使用量及び要求された新たな画像処理を実行した際のメモリ使用量から得られる総メモリ使用量と、当該プラグインアプリケーションを実行するプロセスでの使用が許容されるメモリ使用量を示す許容メモリ量とを比較する。さらに、本画像処理装置は、比較の結果、総メモリ使用量が許容メモリ量を超えない場合は新たな画像処理を実行する。一方、総メモリ使用量が許容メモリ量を超える場合は新たな画像処理を実行せず、要求元に対してメモリ不足により新たな画像処理が実行できない旨のエラーを通知する。これにより、画像処理プラグインアプリケーション３０３の起動（インストール）を制限することなく、画像処理実行時に実行中の画像処理の総メモリを計算することにより、複数の画像処理に対するメモリ制御をランタイムで行うことができる。つまり、本実施形態によれば、好適にメモリ不足を回避しつつ、複数の画像処理を実行することができる。その結果ユーザの利便性を向上することができる。

本発明は上記実施形態に限らず様々な変形が可能である。例えば、各画像処理プラグインアプリケーション３０３の実行メモリ定義部３２７に定義されている実行メモリは、Ｎａｔｉｖｅ画像処理モジュール３１６で画像処理を実行する際の実行メモリを記載することも可能である。

＜第２の実施形態＞
以下では、本発明の第２の実施形態について説明する。上記第１の実施形態では、画像処理接続ライブラリ３３２が、複数の画像処理に対するメモリ制御をランタイムに行う例を説明した。本実施形態では、プラグインアプリケーションから画像処理を依頼された際に、Ｎａｔｉｖｅ画像処理制御プロセス３５０に閉じてＮａｔｉｖｅ画像処理サーバ３１５が複数の画像処理に対するメモリ制御を行う例について説明する。

＜画像処理装置のソフトウェア構成＞
まず、図６を参照して、本実施形態に係るＣＰＵ２１１が処理するソフトウェアの構造の一例を説明する。なお、基本的な構成は上記第１の実施形態において図３を用いて説明した内容と同様であるため、主に差分について説明する。従って、同様の構成については同一の参照符号を付し、説明を省略する。

Ｎａｔｉｖｅ画像処理サーバ３１５は、許容メモリ定義部６０１を保持する。許容メモリ定義部６０１にはＮａｔｉｖｅ画像処理サーバ３１５上で同時実行される際の可能な最大の許容メモリ量が定義されている。許容メモリ定義部６０１に定義された許容メモリ量は、プログラムに直接記載してＨＤＤ２１３から取得する方法や、予め許容メモリ量を定義したファイルを設置した上で、実行時にロードする方法などが挙げられる。なお、許容メモリを取得する方法は上述以外の方法でも構わない。Ｎａｔｉｖｅ画像処理サーバ３１５は、さらに実行中メモリ管理部６０２を保持する。実行中メモリ管理部６０２は、Ｎａｔｉｖｅ画像処理サーバ３１５経由で実行中の画像処理の総メモリ量を管理している。

＜処理手順＞
次に、図７を参照して、本実施形態に係る画像処理装置１０１の処理手順の一例を説明する。ここでは、Ｎａｔｉｖｅ画像処理サーバ３１５が実行中の画像処理のメモリを管理して、画像処理を実行するケースを想定する。ここでの画像処理の依頼元は、画像処理プラグインアプリケーション３０３となる。なお、以下で説明する処理は、例えばＣＰＵ２１１がＨＤＤ２１３に保存されたプログラムをＲＡＭ２１２に読み出して実行することにより実現される。

Ｓ７０１で、Ｎａｔｉｖｅ画像処理サーバ３１５は、Ｎａｔｉｖｅ画像処理クライアント３３１から処理パラメータと共に画像処理の実行依頼を受信すると、Ｓ７０２でＮａｔｉｖｅ画像処理モジュール３１６を探索する。続いて、Ｓ７０３で、Ｎａｔｉｖｅ画像処理サーバ３１５は、Ｓ７０２の探索結果に基づき、対象のＮａｔｉｖｅ画像処理モジュール３１６が存在するか否かを判断する。

存在しない場合はＳ７０４に進み、Ｎａｔｉｖｅ画像処理サーバ３１５は、対象のＮａｔｉｖｅ画像処理モジュール３１６が存在しない旨のエラーを返却し、処理を終了する。エラーを受信したＮａｔｉｖｅ画像処理クライアント３３１は、依頼元の画像処理プラグインアプリケーション３０３にエラー内容を伝播する。この場合、画像処理装置１０１のＨＤＤ２１３に必要なＮａｔｉｖｅ画像処理モジュール３１６がインストールされていないということなので、通常の操作においては発生しない。したがって、開発者がソースコードを修正する必要がある。

一方、対象のＮａｔｉｖｅ画像処理モジュール３１６が存在する場合はＳ７０５に進み、Ｎａｔｉｖｅ画像処理サーバ３１５は、対象のＮａｔｉｖｅ画像処理モジュール３１６の実行メモリ定義部６０３から実行メモリ量を取得する。続いて、Ｓ７０６で、Ｎａｔｉｖｅ画像処理サーバ３１５は、自身の許容メモリ定義部６０１から許容メモリ量を取得する。さらに、Ｓ７０７で、Ｎａｔｉｖｅ画像処理サーバ３１５は、自身の実行中メモリ管理部６０２から実行中総メモリ量を取得する。

次に、Ｓ７０８で、Ｎａｔｉｖｅ画像処理サーバ３１５は、取得した実行中メモリ量と実行中総メモリ量を加算した結果が、許容メモリ量を超えるかどうかを判断する。許容メモリ量を超えないと判断した場合は、Ｓ７０９に進み、Ｎａｔｉｖｅ画像処理サーバ３１５は、実行中総メモリ量に実行メモリ量を加算し、Ｓ７１０で、Ｎａｔｉｖｅ画像処理モジュール３１６に対して画像処理実行を依頼する。Ｎａｔｉｖｅ画像処理モジュール３１６は、処理パラメータと共に画像処理依頼を受信すると、処理パラメータに応じて画像処理を実行する。なお、画像処理実行する際、Ｎａｔｉｖｅ画像処理モジュール３１６では、ＣＰＵ２１１が入力データをＲＡＭ２１２に展開し、処理を行う。この際に画像処理内容、及び入力データサイズに応じて、メモリを確保する必要がある。

次に、Ｓ７１１で、Ｎａｔｉｖｅ画像処理サーバ３１５は、画像処理結果をＮａｔｉｖｅ画像処理モジュール３１６から受け取ると、Ｓ７１２で実行中総メモリ量から実行メモリ量を減算する。続いて、Ｓ７１３で、Ｎａｔｉｖｅ画像処理サーバ３１５は、画像処理結果をＮａｔｉｖｅ画像処理クライアント３３１に返却し、処理を終了する。

一方、Ｓ７０８で許容メモリ量を超えると判断した場合はＳ７１４に進み、Ｎａｔｉｖｅ画像処理サーバ３１５は、現在必要なメモリリソースが足りていないため、画像処理を実行できない旨のエラーをＮａｔｉｖｅ画像処理クライアント３３１に返却する。その後、処理を終了する。

Ｎａｔｉｖｅ画像処理クライアント３３１は上述の画像処理結果及びエラー内容を画像処理プラグインアプリケーション３０３に伝播する。画像処理プラグインアプリケーションは画像処理結果を受け取ると、画像処理接続ライブラリ３３２を通じて依頼元のモジュールに伝播する。一方、メモリリソースが足りていないエラーを受信した場合、例外処理を実行する。ここでの例外処理の一例としてリトライ処理が挙げられる。画像処理プラグインアプリケーション３０３は、上述のエラーを受信した場合、既に実行中の画像処理が存在するため実行できないと判断できる。したがって、一定の時間を置いて再度画像処理クライアント３３１に処理を依頼することで、実行することが可能になる。このように画像処理プラグインアプリケーションに閉じてリトライ処理を行うことで、依頼元のモジュールでリトライ処理を行わなくてもよいといったメリットがある。また、他の例外処理として依頼元の単独機能プラグインアプリケーション３０２及びデバイス制御アプリケーション３０４まで上述のエラーを伝播することが挙げられる。アプリケーションにより、リトライしたい場合と、中断したい場合の、両者が想定できる場合には、アプリケーション側に上述のエラーを伝播することによって、アプリケーション内でリトライ及び中断を切り替えることが可能となる。

上述のようにＮａｔｉｖｅ画像処理モジュール３１６に処理依頼を行う前に、予め実行する画像処理によって許容メモリ量を超えているか否かを判断して制御することで、超えた場合にはそもそも画像処理を依頼しないためメモリを無駄に確保しない。従って、システム（装置）が許容するメモリ量を超えてメモリを確保することでシステムの動作が不安定になる前に、事前にメモリ確保の制御を行うことが可能となる。

本実施形態において、Ｎａｔｉｖｅ画像処理制御プロセス３５０に閉じた上記のメモリ制御と並行して、プラグインによって実現される他の画像処理制御プロセスについても同様のメモリ制御を行うこととしてもよい。即ち、プロセス毎にメモリ許容量を定義してもよい。例えば、本実施形態の構成を上記第１の実施形態の構成と組み合わせて適用してもよい。

本実施形態によれば、画像処理プラグインアプリケーション３０３の起動の制限はしないが、画像処理実行時に実行中の画像処理の総メモリを計算することにより、複数の画像処理に対するメモリ制御をランタイムで行うことが可能となる。その結果ユーザの利便性を向上することができる。さらに、上記第１の実施形態とは異なり、画像処理を専門に行うプロセス（Ｎａｔｉｖｅ画像処理制御プロセス３５０）内に制限してメモリ管理を行うことが可能となる。よって、各画像処理プラグインアプリケーション３０３がＮａｔｉｖｅ画像処理制御プロセス３５０上での画像処理のメモリ制御を意識する必要がなくなり、画像処理プラグインアプリケーション３０３の開発効率が向上するといったメリットもある。

＜第３の実施形態＞
以下では、本発明の第３の実施形態について説明する。本実施形態では、Ｎａｔｉｖｅ画像処理モジュール３１６が主体となってメモリ制御を行う例を説明する。また、本実施形態においては、メモリ制御を行ったうえで、上記第１及び第２の実施形態のように並列処理が行えない場合はエラーを直ぐに返却することなくそのまま処理を実行し、複数ページの画像処理に対する並列処理が行える場合は並列処理を用いることで高速化を行う例を示す。

＜処理手順＞
まず、図８を参照して、本実施形態に係る画像処理装置１０１の処理手順の一例を説明する。ここでは、Ｎａｔｉｖｅ画像処理モジュール３１６がＮａｔｉｖｅ画像処理サーバ３１５に実行メモリを登録し、メモリ制御を行う一例を説明する。なお、以下で説明する処理は、例えばＣＰＵ２１１がＨＤＤ２１３に保存されたプログラムをＲＡＭ２１２に読み出して実行することにより実現される。

まず、Ｓ８０１で、Ｎａｔｉｖｅ画像処理モジュール３１６は、Ｎａｔｉｖｅ画像処理サーバ３１５から画像処理の実行依頼を受信する。続いて、Ｓ８０２で、Ｎａｔｉｖｅ画像処理モジュール３１６は、受信した画像処理に必要なメモリサイズ（メモリ使用量）を実行メモリ定義部６０３から取得する。さらに、Ｓ８０３で、Ｎａｔｉｖｅ画像処理モジュール３１６は、受信した画像処理に対して並列処理が可能かどうかを判断する。この判断は、Ｎａｔｉｖｅ画像処理モジュール３１６に対して並列処理が可能か否かの情報を持たせ、当該情報を用いて判断してもよい。なお、並列処理が可能か否かの情報は、上記第１及び第２の実施形態で説明したように、ネイティブアプリケーションによって既に実行中の画像処理のそれぞれのメモリ使用量と、上記必要なメモリ使用量とに基づき、並列処理が可能であるか否かを判断してもよい。例えば、上記２つの総メモリ使用量で並行処理を行った場合に許容メモリ量に収まるような、総メモリ使用量に対応する閾値メモリ量を定義し、それらの比較結果に基づいてもよい。また、実行メモリ定義部６０３に予めメタ情報として並列処理可能か否かの情報（例えば、閾値メモリ量）を付加しておき、それを読み出すことで判断してもよい。

次に、Ｓ８０４で、Ｎａｔｉｖｅ画像処理モジュール３１６は、Ｓ８０３の判断結果に基づいて、受信した画像処理に対して並列処理が可能でなければＳ８０５に処理を進め、可能である場合にはＳ８１１に処理を進める。

Ｓ８０５は、並列処理が可能でない（各画像処理を順次実行する）場合におけるＳ８０６乃至Ｓ８１０の処理を同期的に受信した画像処理のページ数分繰り返す処理を示す。Ｓ８０６で、Ｎａｔｉｖｅ画像処理モジュール３１６は、Ｎａｔｉｖｅ画像処理サーバ３１５に自身の実行メモリ定義部６０３から取得したメモリ情報を登録する。Ｎａｔｉｖｅ画像処理サーバ３１５によるメモリ情報の登録の詳細については図９を用いて後述する。Ｓ８０７で、Ｎａｔｉｖｅ画像処理モジュール３１６は、Ｓ８０６で実行メモリを登録できたか否かを判断する。登録できなかった場合はＳ８０８に進み、Ｎａｔｉｖｅ画像処理モジュール３１６は、画像処理に必要なメモリリソースが足りていないため実行できない旨のエラーをＮａｔｉｖｅ画像処理サーバ３１５に返却し、処理を終了する。ここで、Ｎａｔｉｖｅ画像処理サーバ３１５はＮａｔｉｖｅ画像処理クライアント３３１を通して呼び出し側のアプリに上記エラーを伝播する。

Ｎａｔｉｖｅ画像処理サーバ３１５に実行メモリを登録できた場合はＳ８０９に進み、Ｎａｔｉｖｅ画像処理モジュール３１６は、対象の画像処理を実行する。画像処理が完了すると、Ｓ８１０で、Ｎａｔｉｖｅ画像処理モジュール３１６は、Ｎａｔｉｖｅ画像処理サーバ３１５に対して解除するメモリ情報と共に実行メモリ解除依頼を行う。繰り返しのループ処理が終了すると、処理を終了する。

一方で、Ｓ８０４で並列処理が可能であると判断した場合は、Ｓ８１１に進み、並列処理が可能である場合におけるＳ８１２乃至Ｓ８１４の処理を同期的に受信した画像処理のページ数分繰り返す。Ｓ８１２で、Ｎａｔｉｖｅ画像処理モジュール３１６は、自身の実行メモリ定義部６０３から取得した実行メモリをＮａｔｉｖｅ画像処理サーバ３１５に対して登録する。なお、Ｎａｔｉｖｅ画像処理サーバ３１５によるメモリ登録のフローについては図９を用いて後述する。Ｓ８１３で、Ｎａｔｉｖｅ画像処理モジュール３１６は、実行メモリを登録できたか否かを判断する。登録できた場合はＳ８１４に進み、Ｎａｔｉｖｅ画像処理モジュール３１６は、並列実行数をインクリメントする。ここで、並列実行数とは、並列して実行するスレッド数を示し、ＲＡＭ２１２やＨＤＤ２１３等で管理している変数を示す。一方で実行メモリが登録できなかった場合は本ループ処理から抜けて、Ｓ８１５に進む。また、繰り返しのループ処理が終了すると、Ｓ８１５に進む。このループ処理を抜けた段階で、並列実行数には、０から設定されたページ数分までの領域の正の整数が入力されている状況になっている。

次に、Ｓ８１５で、Ｎａｔｉｖｅ画像処理モジュール３１６は、計算した並列実行数が０より大きいかどうかを判断する。並列実行数が０より大きければＳ８１６に進み、そうでない場合はＳ８０８に進む。Ｓ８０８で、Ｎａｔｉｖｅ画像処理モジュール３１６は、画像処理に必要なメモリリソースが足りていないため実行できない旨のエラーをＮａｔｉｖｅ画像処理サーバ３１５に返却し、処理を終了する。Ｎａｔｉｖｅ画像処理サーバ３１５はＮａｔｉｖｅ画像処理クライアント３３１を通して呼び出し側のアプリに上記エラーを伝播する。

一方で並列実行数が１以上の整数であればＳ８１６に進み、Ｎａｔｉｖｅ画像処理モジュール３１６は、その並列実行数分のスレッドを起動する。本実施形態ではスレッドを起動したが、プロセスを起動する構成であってもよい。続いて、Ｓ８１７に進み、Ｓ８１８の処理を設定されたページ数分繰り返す。Ｓ８１８で、Ｎａｔｉｖｅ画像処理モジュール３１６は、空いているスレッドに１ページ単位の画像処理を割り当てて実行する。このループ処理を抜けると、全てのスレッドの画像処理実行が完了し、受信した全てのページに対する画像処理が完了する。最後に、Ｓ８１９で、Ｎａｔｉｖｅ画像処理モジュール３１６は、Ｎａｔｉｖｅ画像処理サーバ３１５に対して実行メモリの解除依頼を起動スレッド数分行い、処理を終了する。

＜実行メモリ登録＞
次に、図９を参照して、Ｓ８０６及びＳ８１２において、Ｎａｔｉｖｅ画像処理サーバ３１５がＮａｔｉｖｅ画像処理モジュール３１６から実行メモリ登録依頼を受けた際の処理手順を説明する。なお、以下で説明する処理は、例えばＣＰＵ２１１がＨＤＤ２１３に保存されたプログラムをＲＡＭ２１２に読み出して実行することにより実現される。

Ｓ９０１で、Ｎａｔｉｖｅ画像処理サーバ３１５は、Ｎａｔｉｖｅ画像処理モジュール３１６から実行メモリ情報と共に実行メモリ登録依頼を受信する。続いて、Ｓ９０２で、Ｎａｔｉｖｅ画像処理サーバ３１５は、受信したメモリサイズと実行中の画像処理メモリサイズとの合計が許容メモリサイズを超えているかどうかを判断する。超えていればＳ９０３に進み、Ｎａｔｉｖｅ画像処理サーバ３１５は、登録できなかった旨をＮａｔｉｖｅ画像処理モジュール３１６に返却し、処理を終了する。一方、超えていなければＳ９０４に進み、Ｎａｔｉｖｅ画像処理サーバ３１５は、実行中メモリ管理部６０２に受信したメモリサイズを加算し、Ｓ９０５で登録できた旨をＮａｔｉｖｅ画像処理モジュール３１６に返却し、処理を終了する。

＜実行メモリ解除＞
次に、図１０を参照して、Ｓ８１０において、Ｎａｔｉｖｅ画像処理サーバ３１５がＮａｔｉｖｅ画像処理モジュール３１６から実行メモリの解除依頼を受けた際の処理手順を説明する。なお、以下で説明する処理は、例えばＣＰＵ２１１がＨＤＤ２１３に保存されたプログラムをＲＡＭ２１２に読み出して実行することにより実現される。

Ｓ１００１で、Ｎａｔｉｖｅ画像処理サーバ３１５は、Ｎａｔｉｖｅ画像処理モジュール３１６から実行メモリ解除依頼を受信する。続いて、Ｓ１００２で、Ｎａｔｉｖｅ画像処理サーバ３１５は、実行中メモリから受信したメモリサイズを減算し、処理を終了する。

以上説明したように、本実施形態によれば、Ｎａｔｉｖｅ画像処理モジュール３１６が主体となってメモリ制御を実施することが可能となる。また、各Ｎａｔｉｖｅ画像処理モジュール３１６の特性上、並列処理可能なもの、可能ではないものに応じて適切にスレッド制御を行うことが可能となるため、メモリ制御を行いつつ、複数ページにおける高速化を実現することが可能となる。

＜第４の実施形態＞
以下では、本発明の第４の実施形態について説明する。上記第３の実施形態では、並列実行が可能な画像処理モジュールにおいては、複数ページの画像処理の実施前に、並列実行数を決定し、並列処理を行う例を示した。本実施形態では、上記第３の実施形態の変形例として、画像処理の実行中に動的に並列実行数を増やす例を説明する。

＜処理手順＞
図１１を参照して、本実施形態に係る画像処理中に動的に並列実行数を増やす処理手順について説明する。本フローチャートは図８のフローチャートのＳ８１６からＳ８１９までの処理の変形例となる。Ｓ８１６より前に行われる処理は図８のフローチャートと同じである。なお、以下で説明する処理は、例えばＣＰＵ２１１がＨＤＤ２１３に保存されたプログラムをＲＡＭ２１２に読み出して実行することにより実現される。

Ｓ１１０１で、Ｎａｔｉｖｅ画像処理モジュール３１６は、並列実行数分のスレッドを起動する。続いて、Ｓ１１０２に進み、Ｓ１１０３乃至Ｓ１１０７のループ処理を設定されたページ数分繰り返し実行する。具体的には、Ｓ１１０３で、Ｎａｔｉｖｅ画像処理モジュール３１６は、空いているスレッドに１ページ単位の画像処理を割り当てて実行する。さらに、Ｓ１１０４に進み、Ｓ１１０５乃至Ｓ１１０７のループ処理を画像処理待ちのページ数分繰り返し実行する。

Ｓ１１０５で、Ｎａｔｉｖｅ画像処理モジュール３１６は、Ｎａｔｉｖｅ画像処理サーバ３１５に実行メモリを登録する。続いて、Ｓ１１０６で、Ｎａｔｉｖｅ画像処理モジュール３１６は、実行メモリを登録できたか否かを判断する。実行メモリが登録できなかった場合はＳ１１０４のループを抜け、Ｓ１１０２のループへ戻る。一方、Ｓ１１０６で実行メモリを登録できたと判断すると、Ｎａｔｉｖｅ画像処理モジュール３１６は、実行スレッドを生成し、Ｓ１１０４に戻る。これらのループを設定された画像処理に対するページ数分繰り返し実行することにより（Ｓ１１０２）、全てのページの画像処理が完了し、Ｓ１１０８に進む。

Ｓ１１０８で、Ｎａｔｉｖｅ画像処理モジュール３１６は、Ｎａｔｉｖｅ画像処理サーバ３１５に実行メモリの解除依頼を起動スレッド数分行って、処理を終了する。なお、実行メモリ登録（Ｓ１１０５）及び実行メモリ解除（Ｓ１１０８）に対するＮａｔｉｖｅ画像処理サーバ３１５の処理フローは、図９及び図１０で説明したとおりである。

以上説明したように、本実施形態によれば、複数ページの画像処理において、毎ページの画像処理の間に、Ｎａｔｉｖｅ画像処理サーバ３１５に問い合わせることにより実行スレッドを動的に増やすことが可能となる。したがって、上記第３の実施形態より、さらに効率よく複数ページの画像処理を実行することが可能となる。

＜その他の実施形態＞
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

１０１、１０２：画像処理装置、１０３、１０４：情報処理端末、１０５：サーバ

Claims (14)

1. １以上の画像処理モジュールがプレインストールされた画像処理装置であって、
   アプリケーションによる要求に応じて第一の画像処理モジュールで画像処理を実行中に、アプリケーションによる新たな画像処理が要求されると、前記新たな画像処理を実行可能な第二の画像処理モジュールを探索する探索手段と、
   前記探索手段によって探索された第二の画像処理モジュールによる新たな画像処理を実行した際のメモリ使用量、及び前記第一の画像処理モジュールによって既に実行中の画像処理のメモリ使用量を取得する取得手段と、
   前記取得手段によって取得された各画像処理のメモリ使用量及び前記新たな画像処理を実行した際のメモリ使用量から得られる総メモリ使用量と、画像処理モジュールが動作するプロセスでの使用が許容されるメモリ使用量を示す許容メモリ量とを比較する比較手段と、
   前記比較手段によって比較した結果、前記総メモリ使用量が前記許容メモリ量を超えない場合は前記新たな画像処理を実行し、前記総メモリ使用量が前記許容メモリ量を超える場合は前記新たな画像処理を実行せず、要求元の動作中のアプリケーションに対してメモリ不足により前記新たな画像処理が実行できない旨のエラーを通知する実行制御手段と
   を備えることを特徴とする画像処理装置。
2. 前記第一の画像処理モジュールによる画像処理を実行中に、アプリケーションによる新たな画像処理が要求されると、前記第一の画像処理モジュールによる新たな画像処理を実行した際のメモリ使用量と、前記第一の画像処理モジュールによって既に実行中の画像処理のそれぞれのメモリ使用量とから並列処理が実行可能か否かを判断する判断手段と、
   前記判断手段によって判断した結果、前記並列処理が実行可能でない場合は前記新たな画像処理と、前記既に実行中の画像処理を順次実行し、前記並列処理が実行可能な場合は前記新たな画像処理と前記既に実行中の画像処理とを並行し実行する制御手段と
   をさらに備えることを特徴とする請求項１に記載の画像処理装置。
3. 前記判断手段は、画像処理のページごとに並列処理が可能か否かを動的に判断することを特徴とする請求項２に記載の画像処理装置。
4. 前記制御手段は、画像処理を実行するための実行メモリを確保できない場合には、画像処理が実行できない旨のエラーを通知することを特徴とする請求項２又は３に記載の画像処理装置。
5. 前記実行制御手段は、前記メモリ不足により前記新たな画像処理が実行できない場合は、所定時間が経過した後に、再度、前記新たな画像処理が実行可能か判断することを特徴とする請求項１乃至４の何れか１項に記載の画像処理装置。
6. 前記要求元のアプリケーションは、前記新たな画像処理が実行される画像処理モジュールのプロセスとは異なるプロセスで動作していることを特徴とする請求項１に記載の画像処理装置。
7. 画像処理装置であって、
   第一の実行環境で動作中のアプリケーションからの画像処理の要求に応じて、前記第一の実行環境とは論理メモリ空間が異なる第二の実行環境で動作する第一の画像処理モジュールでの画像処理の実行中に、前記アプリケーションによる新たな画像処理の実行が要求されると、該新たな画像処理を実行可能な第二の画像処理モジュールを探索する探索手段と、
   前記探索手段によって探索された前記第二の画像処理モジュールとともに保持されている、該第二の画像処理モジュールによる新たな画像処理を実行した際のメモリ使用量と、前記第二の実行環境で既に実行中の画像処理のそれぞれのメモリ使用量とを取得する取得手段と、
   前記取得手段によって取得された各画像処理のメモリ使用量及び前記要求された新たな画像処理を実行した際のメモリ使用量から得られる総メモリ使用量と、前記第二の実行環境での使用が許容されるメモリ使用量を示す許容メモリ量とを比較する比較手段と、
   前記比較手段による比較の結果、前記総メモリ使用量が前記許容メモリ量を超えない場合は前記新たな画像処理を実行し、前記総メモリ使用量が前記許容メモリ量を超える場合は前記新たな画像処理を実行せず、要求元の前記第一の実行環境で動作中のアプリケーションに対してメモリ不足により前記新たな画像処理が実行できない旨のエラーを通知する実行制御手段と、
   を備えることを特徴とする画像処理装置。
8. 前記第二の実行環境での前記第一の画像処理モジュールによる画像処理の実行中に、前記第一の実行環境で動作しているアプリケーションによる新たな画像処理が要求されると、該第一の画像処理モジュールによる新たな画像処理を実行した際のメモリ使用量と、前記第二の実行環境で既に実行中の画像処理のそれぞれのメモリ使用量とから並列処理が実行可能か否かを判断する判断手段と、
   前記判断手段による判断の結果、前記並列処理が実行可能でない場合は前記新たな画像処理と、前記既に実行中の画像処理を順次実行し、前記並列処理が実行可能な場合は前記新たな画像処理と前記既に実行中の画像処理とを並行し実行する制御手段と
   をさらに備えることを特徴とする請求項７に記載の画像処理装置。
9. 前記判断手段は、画像処理のページごとに並列処理が可能か否かを動的に判断することを特徴とする請求項８に記載の画像処理装置。
10. 前記制御手段は、画像処理を実行するための実行メモリを確保できない場合には、画像処理が実行できない旨のエラーを通知することを特徴とする請求項８又は９に記載の画像処理装置。
11. 前記実行制御手段は、前記メモリ不足により前記新たな画像処理が実行できない場合は、所定時間が経過した後に、再度、前記新たな画像処理が実行可能か判断することを特徴とする請求項７乃至１０の何れか１項に記載の画像処理装置。
12. 画像処理を実行する際の前記メモリ使用量は、該画像処理に含まれる関数ごとに保持されていることを特徴とする請求項１乃至１１の何れか１項に記載の画像処理装置。
13. アプリケーションによる要求に応じて第一の画像処理モジュールで画像処理を実行中に、アプリケーションによる新たな画像処理が要求されると、前記新たな画像処理を実行可能な第二の画像処理モジュールを探索する探索ステップと、
    前記探索ステップによって探索された第二の画像処理モジュールによる新たな画像処理を実行した際のメモリ使用量、及び前記第一の画像処理モジュールによって既に実行中の画像処理のメモリ使用量を取得する取得ステップと、
    前記取得ステップによって取得された各画像処理のメモリ使用量及び前記新たな画像処理を実行した際のメモリ使用量から得られる総メモリ使用量と、画像処理モジュールが動作するプロセスでの使用が許容されるメモリ使用量を示す許容メモリ量とを比較する比較ステップと、
    前記比較ステップによって比較した結果、前記総メモリ使用量が前記許容メモリ量を超えない場合は前記新たな画像処理を実行し、前記総メモリ使用量が前記許容メモリ量を超える場合は前記新たな画像処理を実行せず、要求元の動作中のアプリケーションに対してメモリ不足により前記新たな画像処理が実行できない旨のエラーを通知する実行制御ステップと、
    を備えることを特徴とする画像処理装置の制御方法。
14. コンピュータに、
    アプリケーションによる要求に応じて第一の画像処理モジュールで画像処理を実行中に、アプリケーションによる新たな画像処理が要求されると、前記新たな画像処理を実行可能な第二の画像処理モジュールを探索する探索手段と、
    前記探索手段によって探索された第二の画像処理モジュールによる新たな画像処理を実行した際のメモリ使用量、及び前記第一の画像処理モジュールによって既に実行中の画像処理のメモリ使用量を取得する取得手段と、
    前記取得手段によって取得された各画像処理のメモリ使用量及び前記新たな画像処理を実行した際のメモリ使用量から得られる総メモリ使用量と、画像処理モジュールが動作するプロセスでの使用が許容されるメモリ使用量を示す許容メモリ量とを比較する比較手段と、
    前記比較手段によって比較した結果、前記総メモリ使用量が前記許容メモリ量を超えない場合は前記新たな画像処理を実行し、前記総メモリ使用量が前記許容メモリ量を超える場合は前記新たな画像処理を実行せず、要求元の動作中のアプリケーションに対してメモリ不足により前記新たな画像処理が実行できない旨のエラーを通知する実行制御手段と
    を備えることを特徴とする画像処理装置として動作させるためのプログラム。

Images