(57)【特許請求の範囲】
【請求項１】
所定のＡＰＩ（Application Programming Interface）に準拠した画像処理アプリケーションと画像入力デバイスとの間のインタフェースを制御することにより該画像入力デバイスを動作させ、画像データを入力するための画像処理方法であって、
画像入力デバイスを特定するための識別子を複数保持し、
前記画像処理アプリケーションからの前記所定のＡＰＩに対応したプロトコルに従った前記識別子に基づく画像入力デバイスの選択要求を受け付け、
前記選択要求に応じて前記所定のＡＰＩに対応したプロトコルを介して、複数の画像入力デバイスのデバイスドライバの中から前記選択要求に対応する画像入力デバイスのデバイスドライバをロードし、
前記ロードされたデバイスドライバが提供する機能に従ったユーザインタフェースを表示し、
前記ユーザインタフェースに基づく画像入力要求を受け付け、
前記画像入力要求に応じて前記選択要求に対応するデバイスドライバの制御により前記画像入力デバイスによって入力した画像データを、前記複数の画像入力デバイスから入力される画像データに対して共通に使用される画像処理用モジュールによって処理し、該処理が行われた画像データを前記所定のＡＰＩに対応したプロトコルを介して前記画像処理アプリケーションに供給することを特徴とする画像処理方法。
【請求項２】
前記デバイスドライバのロードは、前記所定のＡＰＩに準拠した画像処理アプリケーションからの選択要求に応じて実行可能であると共に、前記所定のＡＰＩに準拠した画像処理アプリケーションからの選択要求を受けずに実行可能であることを特徴とする請求項１に記載の画像処理方法。
【請求項３】
前記デバイスドライバのロードは、画像処理用モジュールを呼び出す工程を有し、
該呼び出す工程では、前記所定のＡＰＩに準拠した画像処理アプリケーションを介してロードするか前記所定のＡＰＩに準拠した画像処理アプリケーションを介さずロードするかに応じて、異なる画像処理用モジュールを呼び出すことを特徴とする請求項１又は２に記載の画像処理方法。
【請求項４】
前記所定のＡＰＩに準拠した画像処理アプリケーションから画像入力デバイスの能力の問い合わせを受け付け、
前記問い合わせに応じて画像入力デバイスの能力を前記所定のＡＰＩに準拠したアプリケーションに通知することを特徴とする請求項１乃至３のいずれか１項に記載の画像処理方法。
【請求項５】
前記所定のＡＰＩはＴＷＡＩＮであることを特徴とする請求項１乃至４のいずれか１項に記載の画像処理方法。
【請求項６】
請求項１乃至５のいずれか１項に記載の画像処理方法の各工程をコンピュータに実行させるためのプログラムを記憶したコンピュータ可読の記憶媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、所定のＡＰＩ（Application Programming Interface）に準拠した画像処理アプリケーションと画像入力デバイスとの間のインタフェースを制御することにより該画像入力デバイスを動作させ、画像データを入力するための画像処理方法及び該画像処理方法を実行するためのプログラムを格納した記憶媒体に関するものである。
【０００２】
【従来の技術】
“TWAIN”とは、Eastman Kodak、Logitech、Caere、AldusおよびHwelett-Packardによって共同開発された業界の画像標準であるアプリケーション・プログラミング・インタフェース（API）の名前である。TWAINは、報道機関、アナリストおよび販売業界に広く受け入れられてきており、さらに広がり続けている。したがって、ソフトウェアの画像処理アプリケーションにおいても、ハードウェアの画像入力デバイスにおいても、“TWAIN準拠”であることが望ましい。
【０００３】
ソフトウェアの観点から言えば、TWAIN準拠の画像処理アプリケーションは最新版にたびたび更新する必要がある。この必要性にはいくつかの要因がある。第１に、TWAINプロトコルは絶えず発展している。例えば、TWAINは、元々、画像データがハードウェアスキャナによってスキャンされ得るプロトコルとして開発されたが、現在では、コンピュータファイルに格納された画像データを検索するプロトコルとしても利用されている。第２に、ハードウェアデバイスがますます複雑になりつつあり、そしてTWAINの開発当初には構想されなかった新しい機能（スキャナのプラテンの一部だけがスキャンされるマーキースキャニングのような）を提供しつつある。したがって、そのようなハードウェアデバイスに対する支援を提供するために、デバイスドライバを画像処理アプリケーションに加える必要がある。第３に、エンドユーザは、スキャンされた画像が操作されて変換される、改良されたまたは新しい画像変換及び処理技術を引き続いて求めている。そして第４に、最近では、TWAIN準拠ドライバが、サービスモードでも、独立ユーザインタフェースおよび対応する画像処理能力を提供するスタンドアロンモードでも機能するために、呼び出されるようになった。もちろん、TWAIN準拠の画像処理アプリケーションをたびたび更新する必要性には、この他にも要因がある。
【０００４】
【発明が解決しようとしている課題】
従来のTWAIN準拠デバイスドライバを更新して前の環境をアドレス指定するのは容易ではない。従来のソフトウェアは、“the ground up”、すなわち特定の設計要求および特定のハードウェアに対して書かれた１つの孤立した単位のコードから設計されている。したがって、そのようなソフトウェアは設計要求を満足するが、新しい要求を満たすように拡張するのは容易ではない。
【０００５】
本発明の目的は、所定のＡＰＩに準拠した画像処理アプリケーションから所望の画像入力デバイスを用いて、当該画像入力デバイスの有する機能によって画像データを入力し取得することを可能とした画像処理方法及び該画像処理方法を実行するためのプログラムを格納した記憶媒体を提供することにある。
【０００６】
【課題を解決するための手段】
上記目的のため、本発明の画像処理方法は、所定のＡＰＩ（Application Programming Interface）に準拠した画像処理アプリケーションと画像入力デバイスとの間のインタフェースを制御することにより該画像入力デバイスを動作させ、画像データを入力するための画像処理方法であって、画像入力デバイスを特定するための識別子を複数保持し、前記画像処理アプリケーションからの前記所定のＡＰＩに対応したプロトコルに従った前記識別子に基づく画像入力デバイスの選択要求を受け付け、前記選択要求に応じて前記所定のＡＰＩに対応したプロトコルを介して、複数の画像入力デバイスのデバイスドライバの中から前記選択要求に対応する画像入力デバイスのデバイスドライバをロードし、前記ロードされたデバイスドライバが提供する機能に従ったユーザインタフェースを表示し、前記ユーザインタフェースに基づく画像入力要求を受け付け、前記画像入力要求に応じて前記選択要求に対応するデバイスドライバの制御により前記画像入力デバイスによって入力した画像データを、前記複数の画像入力デバイスから入力される画像データに対して共通に使用される画像処理用モジュールによって処理し、該処理が行われた画像データを前記所定のＡＰＩに対応したプロトコルを介して前記画像処理アプリケーションに供給することを特徴とする。又、上記画像処理方法の各工程をコンピュータに実行させるためのプログラムを記憶したコンピュータ可読の記憶媒体を提供する。
【０００７】
【発明の実施の形態】
本発明の特徴がより良く理解されるように、実施の形態を添付図を参照して説明する。
以下に説明するアーキテクチャは、いろいろな画像入力デバイス、画像処理機能、グラフィカルユーザインタフェース、およびオペレーティングシステムをサポートするために、容易に拡張できるインタフェースを提供する画像処理アプリケーションに関する。また、このアプリケーションは、いろいろな画像入力デバイスと他のTWAIN準拠の画像処理アプリケーションの間の拡張TWAINインタフェースを提供する。
【０００８】
図１に示すように、本実施の形態は、複数のワークステーションおよび複数の周辺機器を備えるローカルエリアネットワークで実施される。画像入力デバイスは、スキャナ、ファクシミリ、ファイルサーバなどである。
図１はローカルエリアネットワーク（LAN）6の一例を示し、Novellネットワークオペレーティングシステムのようなネットワークオペレーティングシステムによって制御されて、LAN6に接続した他のネットワークデバイスと通信するワークステーション11および12のような複数のワークステーションを備える。ワークステーション14のようなワークステーションの１つが、ネットワーク管理者に指定される。また、ワークステーション18に接続するファクシミリ20のように、１つ以上のワークステーションにファクシミリが接続される。さらに、ワークステーション22に接続するスキャナ24のように、１つ以上のワークステーションにスキャナが接続される。
【０００９】
追加のスキャナは、デバイスサーバ機能を提供する独立ネットワーク周辺インタフェースについての一般用語である“ネットポート”28のようなデバイスを通してLAN6に接続される。図１に示すように、“ネットポート”28はスキャナ26のためにデバイスサーバ機能を提供する。ファクシミリ36やスキャナ38のような他の周辺デバイスがローカルエリアネットワークに直接接続される。これらのデバイスは、内部ソフトウェアおよび／またはハードウェアを通してそれら自体のサーバ機能を提供する。また、ネットワークファイルへのアクセスを管理するファイルサーバ30がLAN6に接続される。また、ファイルサーバ30は、スキャナ32やプリンタ34のような他のネットワーク周辺機器に接続される。
【００１０】
図１の配置では、ファイルサーバ30はそれに接続するネットワーク周辺機器のためのデバイスサーバ機能を提供する。同様に、ワークステーション22はスキャナ24からLAN6へのスキャニングサービスを提供し、ワークステーション18はファクシミリ20からLAN6へのファクシミリサービスを提供する。もちろん、本実施の形態を実施する場合には、他に多くのネットワーク周辺機器、ワークステーションおよびネットワーク制御装置が使用される。
【００１１】
また、注目すべきは、本実施に形態は、スタンドアロンコンピュータまたは１つ以上の外部画像入力デバイスに接続されたスタンドアロンコンピュータにおいて実施されることである。
図２は、図１に示したワークステーションのような本実施の形態を採用したワークステーションの一般化構造を示すブロック図である。もちろん、この構造は、また、本実施の形態によるスタンドアロンワークステーションを一般的に表すものである。
【００１２】
図２に示すように、インテル社のペンティアムプロセッサ、モトローラ社の68000プロセッサなどのような中央処理ユニット（CPU）201は、ワークステーションコンピュータバス215にインタフェースする。また、スキャニングデバイスと通信するためのスキャナインタフェース202、ディスプレーデバイスと通信するためのディスプレーインタフェース204、プリンティングデバイスと通信するためのプリンタインタフェース205、LANにインタフェースするためのネットワークインタフェース206、データが検索され、それによってソフトウェアが固定ディスクドライブ211にインストールされるフロッピーディスクドライブインタフェース210、キーボード209、およびマースなどのような座標指示器207が、ワークステーションコンピュータバス215にインタフェースする。
【００１３】
主メモリ214は、CPU201がメモリ格納場所へアクセスできるようにする、コンピュータバス215へのランダムアクセスメモリ（RAM）インタフェースを備える。特に、固定ディスク211に格納されたインストラクションのようなアプリケーションプログラムインストラクションを実行する場合に、CPU201はそれらのインストラクションを固定ディスク211（またはネットワークインタフェース206を経由してネットワークからアクセスする媒体のような他の記録媒体）から主メモリ214にロードし、そして主メモリ214からのそれら格納されたプログラムインストラクションを実行する。リードオンリーメモリー（ROM）212は、キーボード209、フロッピーディスクドライブインタフェース210などの動作のための基本入力／出力オペレーティングシステム（BIOS）のような不変インストラクションシーケンスを格納するために提供される。
【００１４】
図２に示すように、固定ディスクドライブ211は、ウィンドウズやDOSオペレーティングシステムのようなオペレーティングシステム216のためのプログラムインストラクションを格納する。以下に述べるように、本実施の形態のアーキテクチャは、常駐オペレーティングシステム216に従属しない。また、固定ディスクドライブ211は、ネットワーク内の動作に必要な他のアプリケーションとユーテリティ220とを含む。また、本実施の形態による画像処理アプリケーション217、およびAdobe Photoshop（商標）またはCorel Draw（商標）のような少なくとも１つの他の画像処理アプリケーション219が、固定ディスクドライブ211に格納される。
【００１５】
図３は、本実施の形態による画像処理アプリケーション217のTWAINインタフェースモードを表す一般化ブロック図である。
アプリケーション217は、他の画像処理アプリケーション219のTWAINソースマネージャー303によって呼び出される、動的リンクライブラリである複数のTWAINスタブデータソース302を含む。
【００１６】
TWAINソースマネージャー303は、図３に分離されて示されているが、他の画像処理アプリケーション219の１つのエレメントである。各TWAINスタブデータソース302はサポートされた画像入力デバイス309に対応する。
TWAINソースマネージャー303は、利用できる画像入力デバイス309のタイプを確かめるために、TWAINプロトコルに従って各TWAINスタブデータソース302に問い合わせ、選択された画像入力デバイス309に対応するTWAINスタブデータソース302を呼び出す。
【００１７】
TWAINソースマネージャー303によって呼び出された後、TWAINスタブデータソース302は、本実施の形態による画像処理アプリケーション217のスタンドアロンモジュール310とのアプリケーション間通信リンク304を確立する。そして他の画像処理アプリケーション219は、呼び出されたTWAINスタブデータソース302にデバイスコマンドを送信し、TWAINスタブデータソース302は、そのコマンドをアプリケーション間通信リンク304を経由してスタンドアロンモジュール310に、そしてTWAINプロトコルマネージャー305に送信する。TWAINプロトコルマネージャー305は、TWAINトリプレットの形式であるコマンドを解析して、適切な動作を実行する。
【００１８】
TWAINソースマネージャー303が、TWAINスタブデータソース302に問い合わせて利用できる画像入力デバイス309のタイプを確かめ、他の画像処理アプリケーション219が、TWAINスタブデータソース302を使用して対応する画像入力デバイス309の能力を決定するので、追加される画像入力デバイス309のためのサポートを必要とする度に、他の画像処理アプリケーション219を更新する必要はない。その代わり、追加される画像入力デバイス309をサポートするためには、適当なデバイスドライバ307および対応するTWAINスタブデータソース302を、本実施の形態による画像処理アプリケーション217に追加する必要がある。以下に述べるように、各TWAINスタブデータソース302は、各データソースの対応する追加される画像入力デバイス309を表すディスクリプタを除けば同じなので、この操作は簡単である。
【００１９】
図４は、本実施の形態による画像処理アプリケーション217のアーキテクチャを示す詳細図である。
便利なことに、このアーキテクチャを使用すると、アプリケーション217はスタンドアロンモードで動作可能であり、または他の画像処理アプリケーション219に対するTWAINインタフェースとして動作できる。しかし、スタンドアロンモードで動作する場合には、アーキテクチャのいくつかのモジュールは採用されない。これらのモジュールは図５では省略している。すなわち、図５はスタンドアロンモードについて示している。
【００２０】
ユーザインタフェースマネージャー401は、グラフィカルユーザインタフェースをユーザに提示し、ユーザのインタフェース操作に従ってユーザから入力を受け取る。ユーザインタフェースマネージャー401は、画像処理のユーザ制御を助けるために、そのグラフィカルユーザインタフェースを通してデータを表示する。例えば、ユーザは、グラフィカルユーザインタフェース内に表示される“プレビュー”アイコンを選択する。それに応じて、ドキュメントがスキャンされた場合に、ユーザインタフェースマネージャー401はリアルタイムでドキュメントの低解像度画像を表示する。さらに、ユーザインタフェースマネージャー401だけがグラフィカルユーザインタフェースを表示し制御するために応答可能なので、ユーザインタフェースマネージャー401を、異なるグラフィカルユーザインタフェースを表示し制御できる他のユーザインタフェースマネージャー401に置き換えることによって、他のグラフィカルユーザインタフェースを簡単に採用することができる。
【００２１】
オペレーションマネージャー402は、グラフィカルユーザインタフェースを通してユーザインタフェースマネージャー401に送り込まれたコマンドのすべてを受け取る。したがって、オペレーションマネージャー402は、これらの入力、すなわち、プレビュー、ズーム、スキャン、およびコピーを、実際の動作に翻訳する。オペレーションマネージャー402は、これらの動作を監督して、必要な処理ステップが正しい順序で実行されるように保証する。例えば、“scan-to-file”動作では、オペレーションマネージャー402は、ファイルマネージャー406と通信して指定されたフォーマットおよびネームのファイルを開き、画像マネージャー404と通信して読み取る画像を開き、画像マネージャー404から画像データを読み取り、そしてファイルマネージャー406に画像データを書き込む。
【００２２】
画像マネージャー404は画像の読み取りおよび処理を制御する。画像マネージャー404は、画像入力デバイス309を開き、画像データを画像入力デバイス309から読み取り、ライン毎の処理（ハーフトーニング、色調整など）のためのライン変換モジュール407のような画像処理モジュールに画像データを送り出し、必要な場合には、画像変換モジュール501、カラーマッチングモジュール502または他の画像ユーテリティ504のような他の画像処理モジュールにデータを送り出すように、調整する。それから、処理された画像データは、その画像を読み込むように指示されたマネージャーに送り出される。
【００２３】
したがって、本画像処理アプリケーション217がスタンドアロンモードで動作している場合には、画像マネージャー404はドライバマネージャー306およびオペレーションマネージャー402と通信する。
ライン変換モジュール407は、画像データの個々のブロックで動作するどんな画像フィルタも含んでいる。ライン変換モジュール407は、選択されたどのフィルタでも入力画像データに適用する機能を備える。したがって、画像データの１つのブロックで動作するどんな画像フィルタも、ライン変換モジュール407に対しそのフィルタを提供するモジュールをインタフェースすることによって、サポートされる。逆に、画像変換モジュール501はいろいろなモジュールを呼び出して、画像回転のような全体の画像上で動作する画像変換も提供する。
【００２４】
ドライバマネージャー306は、画像マネージャー404によって呼び出されて、ハードウェアの特定機能を実行する。ドライバマネージャー306は、ユーザインタフェースで選択された画像入力デバイス309に対応するDLLデバイスドライバ307をロードして通信する機能を備える。ドライバマネージャー306の主な目的は、あらゆるデバイス依存のファンクションコールをアーキテクチャの残部から分離することである。その結果、追加される画像入力デバイス309は、適当なデバイスドライバ307を追加することによって簡単にサポートされる。
【００２５】
OSユーテリティモジュール410を使用すれば、本実施の形態による画像処理アプリケーション217を、Windows NT、Macintosh、およびOS/2などの異なるオペレーティングシステムプラットフォームに移植することができる。OSユーテリティモジュール410は、その中で画像処理アプリケーション217が実行しつつある特定のオペレーティングシステムに対して、画像処理アプリケーション217によって行われるオペレーティングシステムコールの共通セットを取り出す。それによって、OSユーテリティモジュール410は、オペレーティングシステム機能にアクセスする必要があるすべてのモジュールのために、共通システムレベルAPIを提供する。したがって、OSユーテリティモジュール410は、オペレーティングシステムサービスを必要とするアーキテクチャ内のどんなモジュールにもアクセスできる。
【００２６】
前述のように、本実施の形態によるアーキテクチャは要求の変化に容易に適応する。例えば、OSユーテリティモジュール410を置き換えることによって、そしてユーザインタフェースマネージャー401を新しいオペレーティングシステムのネイティブ環境とより一致するグラフィカルユーザインタフェースを提供するものと置き換えることによって、アプリケーションを新しいオペレーティングシステムプラットフォームに移植することができる。さらに、新しい画像処理の特徴は、画像マネージャー404によってアクセスされる追加モジュールを加えることで簡単にサポートされる。さらに、追加される画像入力デバイス309が、適当なデバイスドライバ307を追加することによってサポートされる。
【００２７】
TWAINインタフェースモードの動作について、図４に関連して以下に記述する。
TWAINインタフェースモードでは、本実施の形態による画像処理アプリケーション217は、プロセス間通信リンク409を経由して他の画像処理アプリケーション219と通信する。プロセス間通信リンク409は、TWAINスタブデータソース302が、他の画像処理アプリケーション219によって呼び出されるTWAINソースマネージャー303によって呼び出された後に、TWAINスタブデータソース302によって確立される。他のアプリケーション219は、いずれかのデバイスドライバを呼び出す場合に、TWAINソースマネージャー303を呼び出す。しかし、TWAINスタブデータソース302は本当の（true）デバイスドライバ機能を実行しない。むしろ、TWAINスタブデータソース302は、リンク409を確立し、リンク409上でコマンドを渡しデータを受け取るのみである。この点で、TWAINスタブデータソース302を“ダミー”デバイスドライバとみなすことができる。
【００２８】
理解されるべきことは、本実施の形態による画像処理アプリケーション217は、他の画像処理アプリケーション219に対するTWAINに完全準拠したインタフェースだけではなく、スタンドアロン画像処理機能をも提供するということである。本実施の形態によるTWAINインタフェースの動作を、図６及び図７に関連して記述する。図６及び図７は、TWAIN“スキャン”コマンドに関連した本実施の形態の動作を示す。
【００２９】
先ず、ステップS601において、他のアプリケーション219が開始する。他のアプリケーション219が“スキャン”コマンドを発行するのを待つ間、フローはステップS602に止まって動かない。スキャンコマンドは、他のアプリケーション219がTWAIN準拠の画像データを選択された画像入力デバイス309から受け取ろうとした場合に発行される。続いて、ステップS604において、他の画像処理アプリケーション219のTWAINソースマネージャー303は、TWAINスタブデータソース302に問い合わせて、選択された画像入力デバイス309に対応するデバイスドライバを探索する。問い合わせを受けると、DLLであり、したがってそれら自体の機能を提供するTWAINスタブデータソース302は、各々が、対応するTWAINスタブデータソース302と同じディレクトリイ中に常駐するディスクリプタによって、TWAINソースマネージャー303に対して特定のデバイスタイプを特定する。
【００３０】
ステップS606において、TWAINソースマネージャー303は、選択された画像入力デバイス309を識別する“get identity”コマンドを、TWAINスタブデータソース302に送信する。TWAINソースマネージャー303が、選択された画像入力デバイス309に対応するディスクリプタを含むTWAINスタブデータソース302を位置づけることができない場合には、フローはステップS605に進み、そこで新しい画像入力デバイス309が選択される。そして、フローはステップS602に戻る。
【００３１】
したがって、他の画像処理アプリケーション219が特定の画像入力デバイス309にアクセスするために、TWAINスタブデータソース302はそのデバイス309に対応するディスクリプタを含まなければならない。すなわち、各TWAINスタブデータソース302は１つのサポートされた画像入力デバイス309に対応し、そしてサポートされた各画像入力デバイス309は１つのTWAINスタブデータソース302に対応する。
【００３２】
ステップS607において、TWAINスタブデータソース302は、本実施の形態によるユーザインタフェースマネージャー401とDDEリンク409を確立する。しかし、Object Linking and Embedding (OLE) 1.0 or 2.0 link のような、どのタイプのプロセス間通信リンクでも、本実施の形態を実施する場合に使用することができる。標準DDEプロトコルにもとづいて、DDEリンクを確立するためにDDEサーバアプリケーションを開始しなければならない。この場合、サーバアプリケーションは本実施の形態を具体化した画像処理アプリケーション217である。したがって、ステップS607において、TWAINスタブデータソース302は、本実施の形態による画像処理アプリケーション217を開始し、これによって本実施の形態による画像処理アプリケーション217はその主ダイアログウインドウをユーザに表示する。さらに、TWAINスタブデータソース302は、DDEデータリンクを本実施の形態によるアプリケーション217のユーザインタフェースマネージャー401に組み込む。
【００３３】
ステップS609において、TWAINスタブデータソース302は、そのディスクリプタおよびステップS606においてTWAINソースマネージャー303から受け取ったスキャンコマンドを、DDEリンク409を経由してユーザインタフェースマネージャー401に送信する。ユーザインタフェースマネージャー401は、他の画像処理アプリケーション219に対するDDEサーバサポートを提供する。TWAINスタブデータソース302からユーザインタフェースマネージャー401に送信されたすべてのコマンドは、TWAINトリプレットによって表される。
【００３４】
しかし、TWAINトリプレットは、TWAINプロトコルマネージャー305によって独占的に処理される。TWAINプロトコルマネージャー305はトリプレットを解析し、受け取ったコマンドを遂行するのに必要な動作のすべてを実行する。さらに、TWAINプロトコルマネージャー305は、オペレーションマネージャー402からだけダイレクトコマンドを受け取ることができる。したがって、TWAINトリプレットがユーザインタフェースマネージャー401からオペレーションマネージャー402に渡され、そして最終的にTWAINプロトコルマネージャー305に渡される。
【００３５】
次に、ステップS610において、TWAINトリプレットに従って、TWAINプロトコルマネージャー305はオペレーションマネージャー402に指示して、ステップS609において渡されたディスクリプタによって識別したデバイスドライバ307を使用して、画像をスキャンする。次に、ステップS611において、オペレーションマネージャー402は、画像マネージャー404に指示して、画像をスキャンする。
【００３６】
画像マネージャー404は、ドライバマネージャー306に指示して、ステップS612において識別されたデバイスドライバ307をロードする。したがって、選択された画像入力デバイス309を識別するために、TWAINスタブデータソース302内に配置されたディスクリプタは、TWAINソースマネージャー303および画像マネージャー404の両方によって使用される。
【００３７】
上述のように、各TWAINスタブデータソース302は異なるディスクリプタを含むが、TWAINスタブデータソース302の各々の機能は同一である。したがって、各TWAINスタブデータソース302のプログラムコードは、それらの特定ディスクリプタを反映するデータを除いて同一である。その結果、新しい画像入力デバイス309は、適当なデバイスドライバ307および新しいTWAINスタブデータソース302を追加することによって、簡単にサポートされる。新しいTWAINスタブデータソース302は、現在の各TWAINスタブデータソース302の複製であるが、新しい画像入力デバイス309を示すディスクリプタを含む。したがって、新しいTWAINスタブデータソース302は、問い合わせのあった場合に、新しい画像入力デバイス309に対する他のアプリケーション219にアラートを出し、そして図３に関して上述したように、他のアプリケーション219は新しい画像入力デバイス309のハードウェア能力について問い合わせることができる。したがって、新しい画像入力デバイス309を追加する度に他の画像処理アプリケーション219を更新する必要はない。
【００３８】
ステップS613において、ステップS611でロードされたデバイスドライバは、選択された画像入力デバイス309によって画像スキャニングを制御し、スキャンされたデータをドライバマネージャー306を経由して画像マネージャー404に送信する。
ステップS614において、画像マネージャー404は、１つのブロックのスキャンされたデータを処理するために、ライン変換モジュール407に送信する。その後に、ステップS615において、ライン変換モジュール407は、処理データの１つのブロックを画像マネージャー404に送信する。本実施の形態において、画像処理アプリケーション217がスタンドアロン画像処理モードまたはTWAINインタフェースモードである場合に、ライン変換モジュール407がデータを処理する。もちろん、他の画像処理モジュールは、本実施の形態によるアプリケーション217をTWAINインタフェースモードで動作させる場合に使用される。しかし、他の画像処理アプリケーション219は、本実施の形態によるアプリケーション217より多くの画像処理ケイバビリティを提供するので、ライン変換モジュール407によって提供されるような予備的処理が必要なだけかもしれない。
【００３９】
ステップS616において、処理されたデータのブロックがオペレーションマネージャー402に送信される。次に、ステップS617において、オペレーションマネージャー402はスキャンされ処理されたデータをスキャンを開始したマネージャーに送信し、それからデータはTWAINプロトコルマネージャー305に送信される。次に、ステップS619において、データはTWAINプロトコルマネージャー305からユーザインタフェースマネージャー401に送信される。DDEリンクがユーザインタフェースマネージャー401に組み込まれるので、ユーザインタフェースマネージャー401に送信されたデータは、ステップS620において他の画像処理アプリケーション219に送信される。
【００４０】
ステップS621において、画像全体が未だ処理されていない場合には、フローはステップS613に戻り、そこで画像データの他のブロックが画像マネージャー404に入力される。画像全体が処理された場合には、フローはステップS622に進み、そこでスキャニング処理は終了する。
【００４１】
なお、本発明は、複数の機器（例えばホストコンピュータ，インタフェイス機器，リーダ，プリンタなど）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、複写機，ファクシミリ装置など）に適用してもよい。
また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても達成される。この場合、記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【００４２】
プログラムコードを供給するための記憶媒体としては、例えば、フロッピディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，磁気テープ，不揮発性のメモリカード，ＲＯＭなどを用いることができる。
また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。
【００４３】
さらに、記憶媒体から読出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。
【００４４】
本発明を上記記憶媒体に適用する場合、その記憶媒体には、先に説明したフローチャートに対応する処理を実行するプログラムコードを格納することになるが、簡単に説明すると、図２乃至図５の本画像処理アプリケーションの構成例に示す各アプリケーション、モジュール、マネージャー、ドライバ、ユーティリティ、データ等を記憶媒体に格納することになる。
【００４５】
本発明を現在適当と考えられる実施の形態について説明したが、本発明は提示した実施の形態に限定されない。本発明は、請求項の精神および範囲内に含まれる数多くの変形および同等の装置を包含しようとするものである。
【００４６】
本実施の形態により、画像処理アプリケーションのいろいろな機能が、画像処理アプリケーションの特定アスペクトを管理する機能を備える特定のマネージャーの間に分配されて、TWAINスタブデータソースが他のTWAIN準拠の画像処理アプリケーションと通信するのに使用される、TWAIN準拠の画像処理ドライバ／アプリケーションのアーキテクチャを提供することができる。
【００４７】
本実施の形態による画像処理アプリケーションは、いろいろなマネージャーに分割されているので、アプリケーションを、いろいろなオペレーティングシステム内での動作や、フルラインの画像入力デバイスとのインタフェースや、新しいまたは拡張された画像変換機能を提供するプラグインモジュールの利用等に、容易に拡張できる。さらに、TWAINスタブデータソースによって、コードがTWAIN間で共用されるので、ディスクの使用を少なくし、コードの更新を容易にする。
【発明の効果】
本発明により、所定のＡＰＩに準拠した画像処理アプリケーションから所望の画像入力デバイスを用いて、当該画像入力デバイスの有する機能によって画像データを入力し取得することを可能とした画像処理方法及び該画像処理方法を実行するためのプログラムを格納した記憶媒体を提供できる。
【図面の簡単な説明】
【図１】本実施の形態のローカルエリアネットワークの構成例を示す図である。
【図２】本実施の形態によるコンピュータの構成例を示すブロック図である。
【図３】本実施の形態による画像処理アプリケーションのアーキテクチャの構成例を示す図である。
【図４】本実施の形態による画像処理アプリケーションのアーキテクチャの構成例を示す詳細図である。
【図５】本実施の形態による画像処理アプリケーションのスタンドアロンモード時の構成例を示す図である。
【図６】本実施の形態による画像処理アプリケーションのTWAINインタフェースモードでの動作手順例を示すフローチャートである。
【図７】本実施の形態による画像処理アプリケーションのTWAINインタフェースモードでの動作手順例を示すフローチャートである。
【図１】
0004208278.tif 000002
【図２】
0004208278.tif 000003
【図３】
0004208278.tif 000004
【図４】
0004208278.tif 000005
【図５】
0004208278.tif 000006
【図６】
0004208278.tif 000007
【図７】
0004208278.tif 000008