JPH10248014A - 画像処理方法 - Google Patents

Abstract

(57)【要約】 【課題】 画像処理の間にシステムを通過する画像デー
タ量を減少させる。 【解決手段】ユーザ・アプリケーションは、本発明に従
って備えられる画像サーバに印刷すべき画像を含むドキ
ュメントを登録し、ドキュメントを識別する識別子を画
像サーバから受け取る。その後、印刷されるドキュメン
トの所望の様相を記述する印刷パラメータとともに、識
別子をプリンタ・ドライバに渡す。プリンタ・ドライバ
はドキュメントを参照する識別子を使用して、画像サー
バに画像処理要求を送り、その要求に応じて、画像サー
バが印刷パラメータに従ってドキュメントの画像を処理
してプリンタ画像を生成する。次に、プリンタ・ドライ
バは、プリンタにダウンロードするために必要とされる
画像データからのみ構成される処理済みプリンタ画像を
画像サーバから取り出す。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、一般的にはドキュ
メント処理に関するもので、特に印刷のためドキュメン
トを準備する方法およびシステムに関するものである。

【０００２】

【従来の技術】画像処理は、画像を捕捉するために使用
されるハードウェアおよびソフトウェアの簡便さおよび
普及によってごく一般的活動となった。インターネット
の一般化およびアクセス可能性、および一層重要な点で
あるがワールド・ワイド・ウェッブ(ＷＷＷ)の登場が画
像の使用を顕著に増加させた。しかしながら、捕捉され
た画像およびその他のグラフィック・エレメントの処理
は、テキスト・データの処理と比較して一般的に複雑で
ある。例えば、カラー画像は、ビデオ・ディスプレイと
プリンタの間のカラー合致や一定の特徴を抽出するため
のエッジ強調などを必要とする。そのような操作はＣＰ
Ｕ集約的となる傾向があり、画像ファイル特にカラー画
像に関連するデータは典型的には大量であるので、その
ような操作はまた入出力集約的となりがちである。画像
の使用の増加によって影響を受ける分野は、例えば、そ
のような画像を含むドキュメントの準備および印刷の分
野である。

【０００３】高度化された文書処理およびその他のデス
クトップ・パブリッシング・プログラムの普及によっ
て、ドキュメントは一般的にはもはや単にテキスト・デ
ータから構成されることはなく、むしろ種々の画像を含
む。コンピュータ上での印刷のためそのようなドキュメ
ントを準備するためには、拡大縮小、切り取り、鮮鋭
化、種々の変換などを含むいくつかの画像処理操作を必
要とする。それらの操作は、アプリケーション、また
は、プリンタに通常含まれるプリンタ・ドライバ・ソフ
トウェアによって実行される。画像をドキュメントに組
み込む結果として、コンピュータ・システムは、グラフ
ィック画像エレメントを表す大量のデータの処理のため
高い度合いの負荷を経験する。ドキュメントの準備およ
び印刷に対するアプローチはいくつかある。一部のアプ
リケーションは、印刷されるべきドキュメント画像の装
置独立的ビットマップを準備する。ビットマップは次に
その対応するプリンタ・ドライバ・ソフトを経由してプ
リンタに送られる。ほとんどの場合、アプリケーション
はプリンタの必要条件に関する知識を持たない。例え
ば、ユーザはある種類の紙を使用する媒体品質画像を印
刷することを望むかもしれない。これは、ドキュメント
画像が一定の解像度およびビット深度をもって作成され
ることを必要とする。アプリケーションは、ユーザによ
って選択される印刷パラメータに応じて出力を提示する
ために必要な解像度やビット深度を判断することができ
ない。そのような知識はプリンタ・ドライバに含まれて
いる。従って、どのような種類のプリンタにも適応しな
ければならないアプリケーションは、保守的アプローチ
を取り、画像の高解像度ビットマップのコピーをプリン
タ・ドライバへ送る。そこで、プリンタ・ドライバは、
受け取った高解像度画像コピーに対して(例えば間引き
のような)追加処理を実行して、当該プリンタにとって
適切な解像度の出力を生成する。

【０００４】この単純なアプローチは、非常に非効率な
印刷方法である。アプリケーションは、プリンタおよび
選択された印刷パラメータに関係なく、常にドキュメン
トの高解像度コピーを生成する。これは、不必要な大量
のデータを変換し、ディスクの数回の入出力を伴う中間
ファイルの作成を伴う過度のディスク活動を必要とす
る。そのような活動は、印刷ジョブが完了するまでＣＰ
Ｕへのアクセスが止められるので、ユーザに悪い影響を
与える。

【０００５】別のアプローチにおいては、ドキュメント
処理アプリケーションは、どのような画像処理能力がプ
リンタ・ドライバに存在するか判断するためプリンタ・
ドライバに照会する。次に、アプリケーションはアプリ
ケーションとプリンタ・ドライバの間で画像処理作業を
どのように分担すべきか決定する。アプリケーションは
ドキュメントの適切な画像を作成しプリンタ・ドライバ
に画像のコピーを送る。プリンタ・ドライバは、受け取
った画像のコピーに対して必要な追加処理を実行してド
キュメントの最終的なプリンタ画像をプリンタへ出力す
る。出力解像度生成のようなプリンタ特有処理がプリン
タ・ドライバによって実行されるので、プリンタ・ドラ
イバ画像処理能力を知っていることは効率を改善する。
アプリケーションは、もはや、すべてのプリンタに適応
するため高解像度ビットマップを生成する必要がない。
むしろ、アプリケーションは、切り取り、赤目補正、鮮
鋭化などプリンタ・ドライバによって典型的にサポート
されていない操作のような装置独立的操作のみを実行す
る。これによって、アプリケーションからドライバへ渡
される画像ファイルは小さくなる。しかしながら、ユー
ザの観点からみれば、アプリケーションが画像を処理し
プリンタ・ドライバに画像のコピーを渡し、その時点で
プリンタ・ドライバが受け取った画像のコピーに対する
プリンタ特有の追加処理を実行してプリンタに生成した
プリンター画像を出力するまで、ＣＰＵはなお占有され
る。

【０００６】待機を軽減するため、ほとんどのコンピュ
ータは、スプーリングとして知られる技法を使用して印
刷ジョブから可能な限り迅速にＣＰＵをユーザに返す。
プリンタ画像、すなわちプリンタに実際に送られるビッ
トマップ画像は、ディスクにコピーされ背景プロセスと
してプリンタに送られる。これによって、プリンタ・ド
ライバが、実際の出力が作成されるのを待たずにコンピ
ュータの制御をユーザに返すことを可能にする。しかし
ながら、プリンタへの最終的プリンタ画像の伝送は、印
刷ジョブの全体のわずかな部分を占めるにすぎず、ほと
んどの努力と時間は、アプリケーションおよびプリンタ
・ドライバが最初にドキュメントのプリンタ画像を生成
するために費やされる。

【０００７】スプーリング技術を一歩進めたオペレーテ
ィング・システムがある。マイクロソフト・ウィンドウ
ズ９５オペレーティング・システムの下で、改良メタフ
ァイル形式(すなわちenhanced metafile formatを略し
てＥＭＦと呼ばれる)スプーリングとして知られる方法
が実施された。ＥＭＦスプーリングを使用すれば、オペ
レーティング・システム(以下単にＯＳと呼ぶ)は、プリ
ンタ画像が現行のようにスプールされる場合と同じ方法
で、アプリケーションがプリンタ・ドライバに対して行
う呼び出しすべてをスプール・ファイルにスプールす
る。次に、ＯＳはスプールされたファイルを再生して、
プリンタ・ドライバにスプールされた情報を送り出し、
それによって印刷ジョブは完全に背景ジョブとして実行
される。プリンタ・ドライバがその画像処理操作を実行
するのをユーザはもはや待つ必要がないので、ＥＭＦス
プーリングの下ではコンピュータの制御は一層迅速にユ
ーザに返される。

【０００８】しかし、このようなＥＭＦスプーリングを
使用しても、印刷の間システム性能に影響を与える要因
がなお存在する。もっとも注意すべき要因は、大量のデ
ータがシステムを通過するという事実である。8"x10"の
写真の２４ビット・カラー・デジタル画像を例として考
察すれば、そのような画像を３００dpiで表現するには
約２０メガバイトのデータが必要とされ、６００dpiで
表現するには約８０メガバイトが必要となる。ＥＭＦス
プーリングの場合、ＯＳは、アプリケーションからプリ
ンタ・ドライバに対して行われる呼び出しと共に、画像
を表現する２０または８０メガバイトのデータのコピー
をもスプールする。スプールされるファイルはディスク
に書き込まれる。再生の間、(２０メガバイトの画像デ
ータを含む)スプールされたファイルがディスクから読
み戻され、プリンタ・ドライバに渡される。プリンタ・
ドライバがプリンタ画像を準備する際、一時的ファイル
が作成されディスクに書き込まれ、ディスクから読み戻
され、再びディスクへ書き込まれる等の動作が行われ
る。このようなディスク活動のすべては、ＯＳの応答時
間および性能全体に影響を与える。ユーザは、非常に遅
いかまたは反応しないシステムに出会うこととなる。

【０００９】

【発明が解決しようとする課題】以上の記述は、印刷ジ
ョブの処理の間に経験される隘路に焦点をあてたが、同
様の隘路は、画像処理に一般的に存在する。画像処理の
間にＯＳを通過するデータの量を最小にする方法および
システムが必要とされる。特に、印刷ジョブを一層効果
的に処理する方法およびシステムが必要とされる。更
に、印刷ジョブのような画像処理の間にＯＳがかかわる
ディスク活動を最小にすることもまた必要とされる。

【００１０】

【課題を解決するための手段】本発明に従って、所望の
様相の画像を生成するために行われる画像処理は、画像
サーバに画像を登録することから始まる。画像サーバ
は、画像サーバ内で画像を識別するハンドルを返す。次
に、画像の所望の様相に従った画像処理要求が画像サー
バに送られる。次に、処理された画像が画像サーバから
取り出される。

【００１１】本発明の１面において、ドキュメントを印
刷する方法およびシステムが提供される。この方法およ
びシステムは、ドキュメントを画像サーバに登録し、そ
の後ドキュメントを識別する識別子を該画像サーバから
受け取ることを含む。印刷されるべきドキュメントは、
ドキュメントの位置を特定するファイル記述子を画像サ
ーバに渡すことによって、画像サーバに登録される。フ
ァイル記述子は、典型的にはディスクに記憶されるドキ
ュメントのファイル名であるが、ドキュメントが記憶さ
れる共有メモリにおける位置を指し示すポインタでもよ
い。その後、印刷されるドキュメントの所望の様相を記
述する印刷パラメータとともに、上記識別子がプリンタ
・ドライバに渡される。ドキュメントを参照する識別子
を使用して、プリンタ・ドライバは、画像サーバに画像
処理要求を送り、その要求に応じて、画像サーバが印刷
パラメータに従ってドキュメントの画像を処理すること
によってプリンタ画像を形成する。最後に、プリンタ・
ドライバは、プリンタにダウンロードするために必要と
される画像データからのみ構成される処理済みプリンタ
画像を画像サーバから取り出す。

【００１２】印刷の間システムを通過するデータ量は最
小限に保たれる。例えば、ある１つのプロセスのアドレ
ス空間から別のプロセスのアドレス空間にドキュメント
を表現する大量のデータをコピーする代わりに、識別子
が使用される。識別子はドキュメントを識別するのに役
立ち、それがドキュメントそのものではなくドキュメン
トの識別子であるので、通過するデータ量は顕著に減少
する。

【００１３】本発明の別の特徴は、最終的プリンタ画像
を形成するために必要とされる画像部分だけが画像サー
バによってアクセスされる点である。このようにして、
ドキュメントに含まれる画像の取り扱いの量は最小限に
とどめられる。その結果、プリンタ画像の形成の間にデ
ィスクとの間で行われるデータ保存および読み出しのた
めのディスク活動が削減される。加えて、ＣＰＵに対す
る負荷も減少する。これは、ユーザがプリント・コマン
ドを出すターンアラウンド・タイムを迅速化しシステム
性能を向上させるという全般的効果を持つ。

【００１４】本発明を実施するシステムにおいては、印
刷ジョブを始動するユーザ・アプリケーションは、画像
サーバおよびプリンタ・ドライバの両方とは分離独立し
て稼働する。同様に、ＯＳがマルチタスクをサポートし
ている限り、画像サーバおよびプリンタ・ドライバは、
別々のプロセスとして、あるいは並列プロセスとして、
あるいは独立実行プロセスとして稼働することができ
る。画像サーバがドキュメントを登録するようにアプリ
ケーション(すなわち文書処理アプリケーション)から要
求を受け取ると、画像サーバは、他のプロセスがドキュ
メントにアクセスするのを防止するためドキュメントを
ロックする。これによって、画像サーバが所望のプリン
タ画像を生成している間のドキュメントの保全が保証さ
れる。しかしながら、その後ロック解除要求を受け取り
次第、画像サーバはドキュメントの一時的コピーを作成
して、オリジナルのロックを解くことができる。ドキュ
メントは、画像サーバによって先ず準備される識別子と
いう手段によって参照されているので、画像サーバの外
側のプロセスはコピーによって影響を受けない。

【００１５】本発明の別の局面において、複数のアプリ
ケーションがロードされ、それぞれのアプリケーション
が印刷されるべきドキュメントを選択し、印刷ジョブを
始動することができる。同様に、複数のプリンタ・ドラ
イバをロードして、それらを独立したプログラム単位と
して実行させることも可能である。このようにして、多
数の種類のプリンタをサポートすることができる。その
ようなプリンタ・ドライバの各々は、その対応するプリ
ンタと通信する能力を持つようにプログラムされるか、
さもなければ、そのような構成に配置される。

【００１６】本発明の更に別の局面において、画像サー
バおよびプリンタ・ドライバは、複数のネットワーク上
に存在するように構成できる。アプリケーションは画像
サーバまたはプリンタ・ドライバと同じコンピュータに
配置されることも、あるいは別のコンピュータに配置さ
れることもできる。これによって、１つのファイル・サ
ーバおよび複数のプリンタに関連して構成される複数の
ワークステーションを有するサイトを構成する場合、最
大限の柔軟性が与えられ、同時に本発明によって可能と
される性能上の利点が実現する。

【００１７】本発明は、発明の課題を解決する手段とし
て、デジタル画像を取得するステップ、上記デジタル画
像の所望の様相を標示する変換パラメータを指定するス
テップ、上記デジタル画像を画像サーバに登録するステ
ップ、上記登録ステップに対する応答として上記画像サ
ーバから画像識別子ハンドルを受け取るステップ、上記
デジタル画像を識別する上記画像識別子と共に、上記変
換パラメータに従って上記デジタル画像の画像データの
上記所望の様相を生成するように画像処理要求を上記画
像サーバに送るステップ、および、生成された上記画像
データを上記画像サーバから取り出すステップからなる
画像処理方法を含む。

【００１８】

【発明の実施の形態】本発明を実施するために考案され
た最良の形態が、図１のシステム・ブロック図に示され
ている。コンピュータ・システム４０において、１つま
たは複数のユーザ・アプリケーション１００、２００
が、ユーザ・インターフェースを介してドキュメントを
生成し処理する。そのようなアプリケーションには、文
書処理プログラム、作図プログラム、表計算プログラ
ム、ドキュメント構成プログラム、写真画像プログラム
などが含まれる。本明細書で使用する用語「ユーザ」
は、アプリケーションと対話する人間か、または例えば
到来ファックスを自動的に受け取るファックス機の機能
を果たすソフトウェア、画像走査ソフトウェア、自動デ
ータ検索ソフトウェアなどのアプリケーションと対話す
る自動エージェントのいずれかとして定義される。アプ
リケーション１００は、必要の都度データを記憶し取り
戻すためデータ記憶装置３０へアクセスする。更に、デ
ータ記憶装置３０には、アプリケーションのランダム・
アクセス・メモリ(ＲＡＭ)のアドレス空間内の区域が含
まれ、それら共有メモリ内の異なる区域が参照される場
合もある。画像処理サーバ１０は、画像内包ドキュメン
トを操作する画像処理能力を提供する。アプリケーショ
ン１００、２００は、画像サーバ・インターフェースを
経由して画像サーバ１０と通信する(詳細は後述)。アプ
リケーションと同様に、画像サーバ１０はデータ記憶装
置３０へのアクセスを行う。

【００１９】図１において、いくつかのアプリケーショ
ン１００が、印刷装置２２、２４に接続するプリンタ・
ドライバ３００と通信している。プリンタ・ドライバ３
００の各々は、特定のタイプのプリンタ装置に関して特
別にプログラムされる。例えば、プリンタ装置２２がプ
ロッタであり、プリンタ装置２４がレーザ・プリンタで
あるかもしれない。あるいはまた、プリンタ装置２２、
２４の両方がインクジェット式プリンタであるが製造業
者は異なり、プリンタ各々と通信できるドライバを必要
とするかもしれない。

【００２０】本発明の１つの局面において、複数のプリ
ンタ・ドライバ３００が、独立して実行するプログラム
単位としてロードされる。すなわちそれらプリンタ・ド
ライバの各々は独立プロセスである。プロセスの間の通
信は、RPC OLEおよびCOMのような周知のプロセス間通信
(すなわちinterprocess communicationでその頭文字を
とってＩＰＣと呼ばれる)技術を介して提供される。ほ
とんどのオペレーティング・システム(ＯＳ)は少くとも
何らかの形式のマルチタスキングをサポートし、プロセ
ス間のＩＰＣを提供する。代表的ＯＳは、ＵＮＩＸ Ｏ
Ｓの多数の変形、マッキントッシュＯＳ、ウィンドウズ
３.Ｘ、ウィンドウズ９５およびマイクロソフトＮＴを
含む。当然のことながら、このリストは単に典型的例を
示すものであり、それらに制限する意図はない。本発明
は、ＩＰＣをサポートするその他のマルチタスキング・
システム上で効果的に実施することができる。

【００２１】本発明に従って画像およびドキュメントを
印刷する場合の典型的実行ステップが図２の流れ図に示
されている。図２で示されるシーケンスは、図１で示さ
れるアプリケーション１００およびプリンタ・ドライバ
３００に対応する。最初に、ステップ６０において、デ
ータ記憶装置３０またはアプリケーション・ユーザによ
って与えられる入力からアプリケーション１００がファ
イルに読み取ることによって、ドキュメントが取得され
る。ドキュメントは、ディスク上のファイル名またはド
キュメントが記憶されるメモリのアドレス・ポインタに
よって、識別される。ドキュメントの取得に加えて、ア
プリケーション１００は、印刷されるドキュメントの所
望の様相を記述する印刷パラメータをユーザから取得す
る。

【００２２】次に、ステップ６２において、アプリケー
ション１００は、ドキュメントのファイル名またはアド
レス・ポインタを画像サーバに送ることによって、ドキ
ュメントを画像サーバ１０に登録する。上述のように、
アプリケーション１００、２００および画像サーバ１０
は独立して実行するプロセスとすることもできる。従っ
て、各プロセスは、一般的に他のプロセスによって直接
アクセスされないそれ自身の論理アドレス空間を持つ場
合がある。このように、アプリケーションがアドレス・
ポインタを介してドキュメントを登録する場合、ドキュ
メントは少なくとも２つのプロセスによってアクセスさ
れることができる共有メモリ区域に置かれなければなら
ない。同様に、データは、動的連結ライブラリ(すなわ
ちＤＬＬ)を使用する場合のようにデータが１つのアド
レス空間に存在する時、アドレス・ポインタが使用され
る。

【００２３】ドキュメント識別子を受け取り次第、画像
サーバ１０は、アプリケーション１００によって提供さ
れた識別子とは別に、ドキュメントを識別するハンドル
を作成する(ステップ６４)。用語「ハンドル」は典型的
には特定のデータ構造を暗示するが、本明細書における
「ハンドル」という用語は、そのようなデータ構造に限
定するように意図されてはいない。むしろ、本明細書で
与えられる記述と整合する「ハンドル」のいかなる実施
も考慮されている。プロセスはステップ６６へと進み、
画像サーバは、他のアプリケーションによるアクセスを
防止するためドキュメントをロックする。ドキュメント
・ハンドルおよびドキュメント・ロック機構によって、
ドキュメントが画像サーバによって処理されている間の
ドキュメントの保全および整合性が保証される。例え
ば、第２のアプリケーションがドキュメントを修正しよ
うとすると、その第２のアプリケーションは、先ず、画
像サーバにアンロック要求を送らなければならない。画
像サーバはその要求に応答して、ドキュメントから局所
的コピーを作成しオリジナルのロックを解く。その後画
像サーバはその局所的コピーを参照し、第２のアプリケ
ーションがアクセスできるようにオリジナルのドキュメ
ントを解放する。

【００２４】続いて、アプリケーション１００は、画像
サーバによって作成されたハンドルを受け取り(ステッ
プ６８)、ハンドルおよび指定された印刷パラメータを
プリンタ・ドライバ３００へ送る(ステップ９０)。次
に、プリンタ・ドライバ３００は、印刷パラメータに従
ってハンドルによって指定された画像を処理するように
画像サーバ１０へ１つまたは複数の画像処理要求を送る
(ステップ７０)。次に、プリンタ・ドライバは、処理さ
れた画像データを画像サーバから取り出し(ステップ７
２)、対応するプリンタ２２、２４へ取り出した画像デ
ータを送る(ステップ９２)。最後に、ドキュメントのロ
ックが解かれる(ステップ７４)。

【００２５】画像サーバが上述のようにドキュメントの
局所的コピーを作成するとすれば、画像処理要求は局所
的コピーに向けられる。プリンタ・ドライバがドキュメ
ントを参照するためドキュメント・ハンドルを使用して
いるので、コピーするという事実はプリンタ・ドライバ
にとって完全に透過的である。印刷ジョブの完了次第、
画像サーバは局所的コピーを削除する。

【００２６】一般的に、画像サーバ１０は、本発明にお
いて画像処理操作の大部分を提供する。しかしながら、
画像サーバの処理能力をいかなるタイプのプリンタにも
従属しないような一般的処理に制限することが望ましい
場合もある。プリンタ特有の画像要件は、プリンタに送
られる最終的プリンタ画像を作成するためステップ７２
において画像データを取り出し次第、プリンタ・ドライ
バによって実行することができる。

【００２７】図２は、本発明をサポートしないシステム
における互換性問題に対処する付加的ステップ８０乃至
８４を含む。画像サーバ１０へのドキュメント登録に先
立ち、アプリケーション１００は、先ず、プリンタ・ド
ライバが画像サーバに対するインターフェースを有して
いるか否かを判断するためプリンタ・ドライバに照会を
送る。回答が否定的であれば、アプリケーションは従来
技術の印刷方法に従って処理を進める。これは、典型的
には、アプリケーションが印刷されるべきドキュメント
の装置独立ビットマップ(すなわちＤＩＢ)画像を生成し
(ステップ８２)、引き続き行われる印刷のためそのＤＩ
Ｂ画像をプリンタ・ドライバへ送る(ステップ８４)こと
を意味する。しかしながら、プリンタ・ドライバが画像
サーバ・インターフェースをサポートしていれば、アプ
リケーションは、上述のようにステップ６２乃至９２を
通して処理を進める。

【００２８】別の実施形態においては、本発明の方法
は、図２において６０から７２までの記号によって示さ
れるステップだけを含む。このシーケンスは、図１のア
プリケーション２００に対応する。この代替実施形態
は、本発明の一般化であり、上述の印刷処理はその特別
ケースである。一般化された方法においては、アプリケ
ーション２００自体が画像サーバと通信して、ドキュメ
ントに関する所望の画像処理演算処理を実行させる(ス
テップ７０)。加えて、結果として生ずる処理された画
像データは必ずしも印刷されるというわけではなく、単
にデータ記憶装置３０に記憶するだけの場合もあり、ま
たビデオ端末上に表示されることもある。

【００２９】本発明を構成するコンポーネントを以下説
明する。多数のソフトウェア・モジュールが、本システ
ムの主要コンポーネントを構成する。従って、本発明を
実施するため、ＣおよびＣ++を含む多くの既存のプログ
ラミング言語を使用することができる。ソフトウェア・
モジュールの関数は、各モジュールに対するアプリケー
ション・プログラマ・インターフェース(すなわちＡＰ
Ｉ)として定義され、特定の実施詳細は、ＡＰＩを実施
するために必要とされる演算を実行するコードを単に作
成することにすぎない。しかしながら、場合によって
は、実際のＯＳという観点から演算を説明することが必
要かもしれない。そのような場合に必要とされる文脈を
準備するためにはウィンドウズ９５オペレーティング・
システム環境が使用される。

【００３０】図３に示されるように、アプリケーション
１００は、典型的には、アプリケーション特有コード１
０１、プリンタ・ドライバ３００と通信するプリンタ・
ユーティリティ３０２、記憶装置３０への読み書きを行
うＩ／Ｏユーティリティ３２、および画像サーバ１０と
通信する画像サーバ・ユーティリティ１２を含む。アプ
リケーション特有コード１０１は、当然、アプリケーシ
ョンに従って変わる。上述の通り、アプリケーションに
は、文書処理、図面プログラム、表計算、デスクトップ
・パブリッシング・プログラムなどの種々のタイプが含
まれる。

【００３１】プリンタ・ドライバ３００は、印刷装置と
通信するドライバ特有コード３０１を含み、更に画像サ
ーバと通信する画像サーバ・ユーティリティを含む。印
刷装置に対する通信インターフェースを備えることに加
えて、ドライバ特有コード３０１は、プリンタに特有の
画像処理演算を実行する場合もある。従って、画像サー
バ１０は、装置に依存しない画像処理演算だけを行えば
よい。

【００３２】画像サーバ１０は、Ｉ／Ｏユーティリティ
３２に加えて、解像度変更、画像拡大縮小、切り取り、
赤目補正、回転、特徴抽出、輪郭強化などの画像処理操
作を実施する画像サーバ固有コード１１を含む。そのよ
うな操作は、コンピュータ画像処理およびコンピュータ
・グラフィックス技術分野において周知のものである。
画像サーバは、ＪＰＥＧ、ＭＰＥＧ、ＧＩＦ、ＴＩＦＦ
等々を含む多くのタイプの画像形式をサポートすること
ができるように設計される。どのようなタイプの形式が
画像サーバによってサポートされるかは、本発明にとっ
て重要ではなく、むしろ、形式の選択は、画像サーバに
要求される能力、コードの複雑さ、画像形式の複雑さ、
処理能力、記憶容量、操作環境、システム・コストなど
という要因の重さに依存する。

【００３３】Ｉ／Ｏユーティリティ３２は、ファイルの
オープン／クローズおよびファイルの読み書きを含む標
準的動作を実行する。そのような動作はソフトウェア業
界において十分理解されているものであるので、これ以
上の説明は必要ではない。

【００３４】プリンタ・ユーティリティ３０２は、アプ
リケーション１００がプリンタ・ドライバ３００と通信
して印刷ジョブを始動することを可能にする。プリンタ
・ユーティリティには、プリンタ・ドライバ３００が画
像サーバ・インターフェースをサポートしているか否か
をアプリケーション１００が判断する(図２のステップ
８０参照)ことを可能にする機能が含まれる。ウィンド
ウズ９５の下では、これは、例えばIS_SUPPORTコード
(画像サーバ・サポート)に関するExtEscape()システム
呼び出しを行うことによって達成できる。画像サーバ１
０をサポートするプリンタ・ドライバ３００は、IS_SUP
PORTコードを認識し、肯定的応答を行う。従って、ExtE
scape(QUERYESCSUPPORT, IS_SUPPORT)に対するシステム
呼び出しの戻り値は正である。そうでない場合は、画像
サーバがサポートされていないことを示す値であるゼロ
が戻される。

【００３５】画像サーバがサポートされていなければ、
アプリケーションは、従来技術における現行の方法で処
理を続ける。すなわち、アプリケーションはＤＩＢ画像
を生成してプリンタ・ドライバ３００にその画像を送
る。これはウィンドウズ９５の下で、StretchDIBits()
システム呼び出しを行ってＤＩＢ画像へのポインタを渡
すことによって実行される。一方、プリンタ・ドライバ
が画像サーバをサポートしていれば、アプリケーション
は、画像に対するハンドルを取得し(図２のステップ６
８参照)、StretchDIBits()システム呼び出しを行ってＤ
ＩＢ画像の代わりにそのハンドルを渡す。

【００３６】画像サーバ・ユーティリティ１２は画像サ
ーバに対するインターフェースを定義する。このよう
に、画像処理操作は、ユーティリティに対して適切な呼
び出しを行うことによって達成される。画像サーバ・ユ
ーティリティに関するアプリケーション・プログラマ・
インターフェース(ＡＰＩ)は後述される。これらのＡＰ
ｌは、画像サーバの機能性を定義し、使用されるＯＳお
よびプログラミング言語に依存する画像サーバを実施す
る原始コードのサンプルを提供する必要性を取り除く。
当業者がＡＰＩによって定義される関数を実施するコー
ドを生成することができる点は明白である。

【００３７】上述のように、画像サーバ１０は種々の画
像形式をサポートすることができる。画像サーバが画像
サーバ・ユーティリティ１２を通してアクセスされるの
で、新しい形式が定義される都度、画像サーバは、追加
画像形式をサポートするように容易に拡張することがで
きる。画像サーバ・ユーティリティ１２の存在は、画像
サーバを使用するアプリケーション／ドライバに対して
このような拡張を完全に透過的にするので、画像サーバ
が新しい画像形式をサポートするように更新される時、
後方互換性が維持される。

【００３８】図３には、画像サーバ・ユーティリティに
対するＡＰＩ定義が示されている。図３は、ユーティリ
ティが、アプリケーション１００とプリンタ・ドライバ
３００の間に分けられていることを示している。しか
し、これは必ずしも必要であるというわけではない。特
定の用途に従って、リストされたユーティリティのすべ
てが１つのアプリケーション内に配置されることも、多
数のアプリケーションの間に分けられることもある。以
下にＡＰＩをアルファベット順に記述する。

【００３９】CloseImage 機能：画像ファイルの処理が完了したことを画像サーバ
に通知する。画像サーバは、画像ファイルのロックを解
き、他のプロセスによるそのファイルへのアクセスを可
能にする。 パラメータ： ・ihImageHandle−画像ファイルを識別する。 戻り値： ・TRUE(真)−関数が成功した。 ・ISE_NOTREGISTERED−ihImageHandleが現在登録されて
いる画像ファイルに対応しない。

【００４０】ConfigureImage 機能：(形式オプションの)画像処理演算が画像に対して
実行されるべきことを画像サーバに通知する。 パラメータ： ・ihImageHandle−処理されるべき画像ファイルを識別
する。 ・ipImageProcOptions−所望の画像処理オプションを含
むデータ構造。 戻り値： ・TRUE−関数の成功。 ・ISE_FORMAT_NOTSUPPORTED−指定された形式は画像サ
ーバによってサポートされていない。 ・ISE_NOTREGISTERED−ihImageHandleが現在登録されて
いる画像ファイルに対応しない。

【００４１】OpenImage 機能：画像処理演算が(ConfigureImage()によって)指定
された画像に関して実行されるべきことを画像サーバへ
通知する。 パラメータ： ・ihImageHandle−処理されるべき画像ファイルを識別
する。 戻り値： ・TRUE−関数の成功。画像サーバは、ihImageHandleに
対する画像処理要求を受ける準備ができている。 ・ISE_NOTREGISTERED−ihImageHandleが現在登録されて
いる画像ファイルに対応しない。

【００４２】QueryFormatSupport 機能：指定された画像形式を画像サーバがサポートして
いるか否かを画像サーバに照会する。指定された画像形
式に関して画像サーバによってサポートされる追加処理
能力を示す情報が提供される。 パラメータ： ・dwImageFormat−当該画像形式。例えばＴＩＦＦ、Ｊ
ＰＥＧ、ＭＰＥＧ、ＧＩＦ。 ・lpFormatData−画像サーバによって提供される追加処
理能力(例えば合成)を示すデータ構造へのポインタ。 戻り値： ・ISE_FORMAT_SUPPORTED−指定された形式が画像サーバ
によってサポートされている。lpFormatDataがヌルのポ
インタでなければ、追加形式機能が画像サーバによって
指定される。 ・ISE_FORMAT_NOTSUPPORTED−指定された形式は画像サ
ーバによってサポートされていない。

【００４３】QueryImage 機能：指定された画像ファイルに関する情報を提供す
る。 パラメータ：ihImageHandle−情報が必要とされる画像
ファイルを識別する。 lpImageInfo−画像情報データ構造へのポインタ。画像
サーバによって記入される。 戻り値： ・TRUE−関数の成功。 ・ISE_NOTREGISTERED−ihImageHandleが現在登録されて
いる画像ファイルに対応しない。

【００４４】RegisterImage 機能：指定された画像ファイルをロックしコピーして、
ロック／コピーした画像ファイルに対するプライベート
・ハンドルを戻す。ハンドルはファイルに対する以後の
アクセスにおいて使用される。 パラメータ： ・lpszImageFileName−画像ファイルのパス／ファイル
名を指す。別の方法としては、バッファへのポインタに
よって画像ファイルが渡される。この場合lpszImageFil
eNameはヌルのポインタである。 ・lpJobData−印刷装置の名前のような適切なジョブ・
データを含む構造をポイントする。 ・dwImageFormat−指定された画像ファイルの画像形式
を指定する。 ・lpImageHandle−(画像サーバによって生成される)画
像ハンドルがコピーされるバッファをポイントする。 ・lpImageData−画像ファイルを含むバッファをポイン
トする。別の方法としては、パス／ファイル名によって
画像ファイルは参照される。この場合lpImageDataはヌ
ルのポインタである。 ・lpImageDataHeader−lpImageDataによってポイントさ
れるデータの形式を定義するデータ構造をポイントす
る。lpImageDataがヌル・ポインタであればこれはヌル
・ポインタである。 ・dwOptions−画像ファイルが画像サーバに登録される
方法を指定する。有効な値は以下を含む。IS_TEMPFIL
E：lpszImageFileNameによって指定されるファイルは、
CloseImageへの呼び出しが行われる時画像サーバによっ
て削除されるべき一時的ファイルである。IS_COPYNOW：
lpszImageFileNameによって指定されるファイルは一時
的ファイルではなく、画像サーバは、ファイルをロック
するのではなく画像ファイルからコピーを作成しなけれ
ばならない。 戻り値： ・TRUE−関数の成功。lpImageHandleは、画像に関する
(画像サーバによって作成された)有効なハンドルをポイ
ントする。 ・ISE_OUTOFSPACE−要求された画像ファイル・コピーを
作成できない。lpImageHandleの内容は不確定。 ・ISE_FORMNOTSUPP−dwImageFormatで指定された形式は
この画像サーバ・バージョンではサポートされていな
い。

【００４５】RetrieveImageBand 機能：ConfigureImage()に対する先行呼び出しの結果と
して画像サーバによって生成された処理画像の画像デー
タを要求する。 パラメータ： ・ihImageHandle−画像ファイルを識別する。 ・XSrc−画像サーバによって生成された画像データの所
望の部分のＸ座標(ピクセル単位)。 ・YSrc−画像サーバによって生成された画像データの所
望の部分のＹ座標(ピクセル単位)。 ・cxSrc−画像サーバによって生成された画像データの
所望の部分の幅(ピクセル単位)。 ・cySrc−画像サーバによって生成された画像データの
所望の部分の高さ(ピクセル単位)。 ・lpBandBuffer−画像サーバが生成された画像データの
要求部分を書き込むべきバッファを指すポインタ。 ・lpBandHeader−lpBandBufferに記憶されるべき画像デ
ータの形式を指定するデータ構造を指すポインタ。 戻り値： ・TRUE−関数は成功。 ・ISE_PROCERROR−画像サーバが処理エラーに遭遇。 ・ISE_NOTCONFIGURED−処理演算は実行されなかった。 ・ISE_NOTREGISTERED−ihImageHandleが現在登録されて
いる画像ファイルに対応しない。

【００４６】UnlockImage 機能：lpszImageFileNameに関するファイルのロック
を、現在画像サーバによってロックされていれば、解除
する。この場合、画像サーバは画像ファイルから一時的
コピーを作成する。 パラメータ： ・lpszImageFileName−ロックを解除すべき画像ファイ
ルのファイル名。 戻り値： ・TRUE−関数の成功。lpszImageFileNameはロック解除
された。 ・ISE_OUTOFSPACE−lpszImageFileNameのロックを解除
するため画像ファイルのコピーを作成することができな
かった。画像ファイルは画像サーバによってロックされ
たままである。 ・ISE_NOTUNLOCK−lpszImageFileNameのロックを解除す
ることができなかった。これは、ファイルのロックが画
像サーバによって解除されなかったことを典型的に示
す。

【００４７】以下の疑似コード(表１)は、上記の呼び出
しが典型的ドキュメント処理アプリケーションにおいて
どのように出現するかを示す。

【００４８】

【表１】 : : /* ＪＰＥＧがサポートされているか？ */ dwImageFormat <-- JPEG画像形式 QueryFormatSupport( dwImageFormat, IpFormatData )
if( 戻り値 = = ISE_FORMAT_NOTSUPPORTED ) exit /* 画像ファイル登録 */ lpszImageFileName <-- ドキュメント・ファイル名 lpJobData <-- ユーザ指定プリンタ、プリンタ・オプシ
ョン dwImageFormat <-- JPEG画像形式 lpImageData <-- ヌル lpImageDataHeader <-- ヌル dwOptions <-- IS_COPYNOW /* ファイルをロックしない
*/ RegisterImage( IpszImageFileName,IpJobdata,dwImage
Format,lpImageHandle,lpImageData,lpImageDataHeade
r,dwOptions ) if( 戻り値 ! = 真 ) exit /* 印刷パラメータとともにプリンタ・ドライバにハン
ドル(lpImageHandle)を送る */ : :

【００４９】以下の擬似コード(表２)は、画像サーバ・
ユーティリティがプリンタ・ドライバ・ソフトにどのよ
うに出現するかを示す。

【００５０】

【表２】 : : /* 画像処理の開始を画像サーバに伝える */ ihlmageHandle <-- ユーザ・アプリケーションから受け
取った画像ハンドルOpenImage( ihlmageHandle ) if ( 戻り値 = = ISE_NOTREGISTERED )ユーザ・アプリ
ケーションにハンドル無効を通知する exit /* 画像処理を実行する */ すべての印刷パラメータ毎に以下を実行 iplmageProcOptions <-- 印刷パラメータ Configurelmage( inImageHandle,iplmageProcOptions ) if( 戻り値 = = ISE_FORMAT_NOTSUPPORTED )ユーザ・ア
プリケーションに印刷パラメータ無効を通知する exit 続行 /* 処理された画像の画像データを取得してプリンタに
送る */ XSrc <-- 処理画像の初期セグメントのＸ座標 YSrc <-- 処理画像の初期セグメントのＹ座標 cxSrc <-- 画像部分の幅 cySrc <-- 画像部分の高さ lpBandHeader <-- GIF形式の処理済み画像を取り出す 処理画像データのすべてのセグメントに関して以下を実
行 RetrieveImageBand( ihlmageHandle,Xsrc,Ysrc,cxSrc,c
ySrc,IpBandBuffer,IpBandHeader ) lpBandBufferによってポイントされるセグメントをプリ
ンタへ送る 処理画像の次のセグメントへ増分 Xsrc <-- 次のセグメントのＸ座標 Ysrc <-- 次のセグメントのＹ座標 続行 : : CloseImage( ihlmageHandle ) : :

【００５１】本発明の１つの実施形態が図４に示されて
いる。図１に示されている本発明のコンポーネントが１
つのコンピュータに配置されているのに対して、図４で
は図１と同じコーンポーネントがネットワーク化された
複数のコンピュータに分散されている。コンピュータ４
２乃至４８は１つのネットワーク５０によって相互接続
されている。ネットワーク５０は、ＬＡＮ(ローカル・
エリア・ネットワーク)におけるイーサネット・バック
ボーンであっても、あるいはＷＡＮ(ワイド・エリア・
ネットワーク)における電話ネットワークであってもよ
い。より一般的には、コンピュータ４２乃至４８は、Ｌ
ＡＮおよびＷＡＮのいくつかの組合せによって相互接続
されることができる。本発明は、どのようなネットワー
ク構成ででも実施することができ、特定の１つのアーキ
テクチャに限定されない。

【００５２】各コンピュータは、ネットワーク・インタ
ーフェース５２を経由してネットワーク上で通信する。
インターフェース５２は、特定のコンピュータがネット
ワーク上の別のコンピュータにアクセスすることを可能
にするために必要とされるハードウェアおよびサーバ・
ソフトウェアを含む。上述のように、アプリケーション
１００、画像サーバ１０およびプリンタ・ドライバ３０
０は別々のプロセスであり、それらプロセスの間の通信
は適切なＩＰＣコールによって実行されるという点に注
意する必要がある。ネットワーク構成においては、これ
らプロセスがネットワークにわたって動作することがで
きるようにするため、ＩＰＣ呼び出しは、同等の遠隔手
続き呼び出し(すなわちＲＰＣ)に置き換えられなければ
ならない。ＲＰＣの実施は一般には特定のＯＳ能力に依
存するが、それはプログラミング分野の通常の技術を有
する者の知識範囲に入るものである。

【００５３】図４は、ディスク・サーバの機能を果たす
コンピュータ４４を示す。このディスク・サーバに本発
明の画像サーバ１０が含まれる。また、プリンタ２２、
２４をドライブするプリンタ・ドライバ３００'がディ
スク・サーバ４４にロードされる。別の１つのコンピュ
ータ４８は、主にプリンタ２６、２８のためのプリンタ
・サーバの役目を果たす。コンピュータ４２上のユーザ
・アプリケーション１００は、ディスク・サーバ４４上
で動いているサーバ・ソフトウェアを経由してディスク
３０上のファイルにアクセスすることができる。コンピ
ュータ４６上で動いているユーザ・アプリケーション２
００は同様の形態で動作する。

【００５４】本発明の諸コンポーネントが分散されてい
るとはいえ、本発明の動作は図１の形態と同じままであ
る。例えば、RegisterImage()呼び出しは、コンピュー
タ４２上のアプリケーション１００から始動され、ネッ
トワークをわたってコンピュータ４４に送られ画像サー
バ１０で処理される。画像サーバ１０はハンドルを作成
し、アプリケーション１００にハンドルを戻す。次に、
アプリケーション１００は、コンピュータ４４上のプリ
ンタ・ドライバ３００'による印刷ジョブを始動させる
ためネットワークを通して通信する。この時点から、同
じコンピュータ４４内で動作するプリンタ・ドライバ３
００'および画像サーバ１０は、上述した形態と同様に
相互に対話しながら最終的プリンタ画像を生成する。代
替的形態としては、アプリケーション１００は、コンピ
ュータ４８上のプリンタ・ドライバ３００"を用いる印
刷ジョブを始動することもできる。コンピュータ４４上
のプリンタ・ドライバ３００'と同様に、コンピュータ
４８上のプリンタ・ドライバ３００"は、画像サーバ１
０と画像処理要求について交渉する。しかしながら、コ
ンピュータ４４上のプリンタ・ドライバ３００'と相違
して、プリンタ・ドライバ３００"はネットワークを通
して画像サーバ呼び出しについて交渉しなければならな
い。

【００５５】本発明には、例として次のような実施様態
が含まれる。 （１）デジタル画像を取得するステップ(a)と、上記デ
ジタル画像の所望の様相を標示する変換パラメータを指
定するステップ(b)と、上記デジタル画像を画像サーバ
に登録するステップ(c)と、上記登録ステップ(c)に対す
る応答として上記画像サーバから画像識別子ハンドルを
受け取るステップ(d)と、上記デジタル画像を識別する
上記画像識別子と共に上記変換パラメータに従って上記
デジタル画像の画像データの所望の様相を生成するよう
に画像処理要求を上記画像サーバに送るステップ(e)
と、生成された上記画像データを上記画像サーバから取
り出すステップ(f)と、を含む画像処理方法。 （２）上記方法が、ユーザ・アプリケーションおよび上
記画像サーバを並列かつ独立に実行するプログラムとし
て１つのコンピュータにロードするステップを更に含
み、上記アプリケーションが上記（１）に記載のステッ
プ(a)乃至(f)を実行する、上記（１）に記載の画像処理
方法。 （３）上記方法が、第１および第２のユーザ・アプリケ
ーションを１つのコンピュータにロードするステップを
更に含み、上記第１のユーザ・アプリケーションが第１
のデジタル画像に関して上記ステップ(a)乃至(e)を実行
し、上記第２のユーザ・アプリケーションが第２のデジ
タル画像に関して上記ステップ(a)乃至(e)を実行する、
上記（１）または（２）に記載の画像処理方法。 （４）上記方法が第１のコンピュータにユーザ・アプリ
ケーションをロードし第２のコンピュータに上記画像サ
ーバをロードするステップを更に含み、上記ユーザ・ア
プリケーションが、上記ステップ(a)ないし(f)を実行す
る、上記（１）、（２）または（３）に記載の画像処理
方法。

【００５６】（５）上記方法が、ユーザ・アプリケーシ
ョン、上記画像サーバおよびプリンタ・ドライバをそれ
ぞれ並列かつ独立に実行するプログラム単位としてロー
ドするステップを更に含み、上記プリンタ・ドライバが
第１のタイプのプリンタと通信し、上記ユーザ・アプリ
ケーションが上記ステップ(a)乃至(d)を実行し、上記方
法が更に上記ユーザ・アプリケーションから上記プリン
タ・ドライバへ上記画像ハンドルおよび変換パラメータ
を送るステップを含み、その後上記プリンタが上記ステ
ップ(d)を実行し、上記方法が上記プリンタ・ドライバ
から上記第１のタイプのプリンタへ上記画像データを送
るステップを更に含む、上記（１）（２）、（３）また
は（４）に記載の画像処理方法。 （６）上記方法が、並列かつ独立に実行するプログラム
とし上記コンピュータに第２のプリンタ・ドライバをロ
ードするステップを更に含み、上記第２のプリンタ・ド
ライバが第２のタイプのプリンタと通信するように構成
される、上記（５）に記載の画像処理方法。 （７）第１のコンピュータにユーザ・アプリケーション
をロードし、上記画像サーバおよび上記プリンタ・ドラ
イバを第２のコンピュータ上にロードするステップを更
に含む、上記（５）に記載の画像処理方法。

【００５７】（８）ドキュメント処理アプリケーション
からドキュメントを印刷するシステムであって、ドキュ
メントの記憶位置を指定するドキュメント位置指定子を
有する複数のドキュメントを含む第１の記憶装置と、そ
れぞれ独立した実行プログラム単位である画像処理サー
バおよびプリンタ・ドライバと、を備え、上記画像処理
サーバが、上記ドキュメント位置指定子を受領次第上記
ドキュメント識別子によって指定されるドキュメントを
識別するドキュメント識別子を生成する電気回路を持
ち、該システムは更に、上記ドキュメント位置指定子の
うちの１つを上記画像処理サーバに通知するコード、上
記画像処理サーバから対応するドキュメント識別子を取
得するコード、および印刷パラメータおよび上記対応す
るドキュメント識別子を含むジョブ・パラメータを上記
プリンタ・ドライバに通知するコードを含む印刷ジョブ
始動コードを備え、上記プリンタ・ドライバが、上記印
刷パラメータに従って上記画像処理サーバに画像処理要
求を送るコードを含め、対応するドキュメント識別子に
よって識別されるドキュメントの画像データを操作する
コード、上記画像処理サーバから上記操作された画像デ
ータを取得するコード、および上記操作された画像デー
タを第１のタイプのプリンタに送るコードを有する、ド
キュメント印刷システム。 （９）上記ドキュメント処理アプリケーション、画像処
理サーバおよびプリンタ・ドライバが、単一のコンピュ
ータに配置される、上記（８）に記載のドキュメント印
刷システム。

【００５８】

【発明の効果】本発明に従ったドキュメント識別子の使
用によって、印刷の間システムを通過するデータ量は最
小限に保たれる。また、本発明によって、最終的プリン
タ画像を形成するために必要とされる画像部分だけが画
像サーバによってアクセスされるので、ドキュメントに
含まれる画像の取り扱い量は最小限にとどめられる。こ
の結果、プリンタ画像の形成の間にディスクとの間で行
われるデータ保存および読み出しのためのディスク活動
が削減され、ＣＰＵに対する負荷も減少し、従って、全
般的システム性能が向上するという効果を奏する。

【図面の簡単な説明】

【図１】本発明の実施形態のシステムを示すブロック図
である。

【図２】ドキュメント処理の際の本発明に従う典型的事
象シーケンスを示すブロック図である。

【図３】本発明のシステムのソフトウェア・コンポーネ
ントの間のインターフェースを示すブロック図である。

【図４】ネットワーク構成に配置された本発明のシステ
ムを示すブロック図である。

【符号の説明】

１０ 画像サーバ １１ 画像ドライバ特有コード １２ 画像サーバ・ユーティリティ ２２、２４、２６、２８ プリンタ ３０ データ記憶装置 ３２ Ｉ／Ｏユーティリティ ４０、４２、４４、４６、４８ コンピュータ・シス
テム ５０ ネットワーク ５２ ネットワーク・インターフェース １００、２００ アプリケーション １０１ アプリケーション特有コード ３００、３００'、３００" プリンタ・ドライバ ３０１ ドライバ特有コード ３０２ プリンタ・ユーティリティ

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ロバート・チョウ アメリカ合衆国92128カリフォルニア州サ ン・ディエゴ、ゲーブル・リッヂ・ロード 14844 (72)発明者 サチン・ネイク アメリカ合衆国92122カリフォルニア州サ ン・ディエゴ、カミント・ディア 7949、 ナンバー ４

Claims (1)

【特許請求の範囲】
1. 【請求項１】デジタル画像を取得するステップと、 上記デジタル画像の所望の様相を標示する変換パラメー
   タを指定するステップと、 上記デジタル画像を画像サーバに登録するステップと、 上記登録ステップに対する応答として上記画像サーバか
   ら画像識別子ハンドルを受け取るステップと、 上記デジタル画像を識別する上記画像識別子と共に、上
   記変換パラメータに従って上記デジタル画像の画像デー
   タの上記所望の様相を生成するように画像処理要求を上
   記画像サーバに送るステップと、 生成された上記画像データを上記画像サーバから取り出
   すステップと、を含む画像処理方法。