JP2004103016A

JP2004103016A - ダイナミックな色提供辞書

Info

Publication number: JP2004103016A
Application number: JP2003306171A
Authority: JP
Inventors: Michael T Stevens; マイケル　ティー　スティーブンズ
Original assignee: Xerox Corp
Current assignee: Xerox Corp
Priority date: 2002-09-05
Filing date: 2003-08-29
Publication date: 2004-04-02
Anticipated expiration: 2023-08-29
Also published as: US20040046978A1; US7310165B2; JP4511142B2

Abstract

【課題】　画像またはグラフィックが要求されるか否かを迅速に判断すると同時に、適切な色を提供する。
【解決手段】　２つ以上の色変換テーブルを、一つのRenderTableに連結し、複数のオブジェクトタイプの間の色提供ビヘイビアを自動的にスイッチングし、一定のオフセットを、一つのRenderTableの指標軸（indexing axis）に加算することによって、個々の色テーブルにアクセスし、前記一つのRenderTableの異なった領域（region）にアクセスすることによって、一つのグラフィックス状態内の異なった提供ビヘイビアにアクセスすること、を含む、ダイナミックな色提供辞書。
【選択図】　　　　　図２

Description

　本発明はダイナミックな色提供辞書に関する。

　コンピュータに基づく画像システムは、電子的画像とハードコピー画像の双方を生成することに関してポピュラーになってきた。この理由は一つには、デスクトップ出版の普及であり、一つには、その利用可能性である。そのようなシステムにおいて、ホストコンピュータは一般的に、画像を記述するデータを生成し、次にデータを画像生成装置に転送する。そこでデータは、装置によって使用され得るフォーマットに変換される。通常は、画像データは、Adbeから入手可能な、例えばPostscriptのようなページ記述言語（ＰＤＬ）のフォーマットである。

　ページ記述言語、即ちPostScript、とコンパチブルなデスクトップ出版及び／又は他の画像生成アプリケーションプログラムは、ページ記述言語コマンドに変換されるグラフィックスコマンドを生成する。例えばプリンタまたはディスプレイ装置のような画像化装置は、グラフィックス・オペレーションの適切なタイプとシーケンスが、デスクトップ出版プログラムで作られた画像を生成または提供するために実行されるように、ページ記述言語コマンドを解釈・翻訳する。グラフィックス・オペレーションは一般的に、ページ記述言語に埋めこまれた画像化オペレーションに応答して、画像オブジェクト上で実行（performed）される、テキスト、グラフィックス、および画像（ビットマップ）オペレーションを含む。色提供辞書（ＣＲＤ）は、装置に依存しない色を提供するためにAdobeによって生成された機構（mechanism）である。概念的には、アプリケーションが事前に、別個のやりかたで、色を指定する。次にプリンタがそのＣＲＤを用いて、装置に依存しない色を、プリンタに特有のベストの一致ＣＭＹＫ値に変換する。

　色提供辞書は、グラフィックスと画像の双方に対して同一の色を提供するように設計された。実際には、グラフィックスに対するベストの色一致は、画像に対するベストの色一致とは非常に異なる。良いグラフィックスの色一致は、輝度及び／又は色相が一致することを条件として、パンチのある飽和した色を生成する。対照的に、色相および輝度をより良く維持するために、良い画像色一致は、飽和を犠牲にする。色提供辞書を生成することに対する伝統的なアプローチは、（多くの）色一致スタイル（color matching styles）の間の最良の妥協を発見することを含む。一つ色提供辞書内に複数の色ビヘイビアを提供する能力は、この妥協を為す必要性を緩和する。これによって、全体としてのより良い色一致という結果をもたらす。

　インターフェースの下で、Adobeのコアコード（core code）は、ＣＲＤを、２つの別個のやり方で用いる。グラフィックス・オブジェクトは、一つの色計算だけを必要とする。これらの種類のオブジェクトについては、適切な色を計算するために用いられるＣＰＵサイクル数は小さい。提供ビットマップされた画像（rendering bitmapped images）は、数億の別個の色を計算することを含み得る。画像で色を計算するために用いられるＣＰＵサイクルの数は、非常に大きくなり得る。この理由から、Ａｄｏｂｅは、２つの色パイプラインを作った。正確な色パイプラインは、最も正確であるが、比較的遅い。速い色パイプラインは、より速いが、結果としての計算は正確ではない。グラフィック・オブジェクトは、正確な色パイプラインを使用する。画像は、速い色パイプラインを用いる。

　オブジェクトタイプに基づく、色ビヘイビアのスイッチングの重要な部分は、提供されているオブジェクト・タイプを”検知”するタスクからなる。この質問は、容易に、”私は、画像またはグラフィックオブジェクトを提供しているか？”と言い替えられる。Postscriptは、そのような問合せを為すための明白な機構を提供しない。それゆえ、画像またはグラフィックが要求されるか否かを迅速に判断すると同時に、適切な色を提供するための必要性が存在する。

　本発明の概要は、オブジェクトのタイプ（object types）の間で色提供ビヘイビア（color rendering behavior）を自動的に切り替えるために、ダイナミックな（dynamic）色提供辞書（Color Render Dictionaries）が提供される。この実施（implementation）は、完全に、色提供辞書（ＣＲＤ：Color Render Dictionary）内に存し、ポストスクリプト・インタープリタ（Postscript Interpreter）の状態への、何の変更も必要としない（何の、”Ｃ”コード変更およびＰｏｓｔｓｃｒｉｐｔオペレータ再定義も要求されない）。異なる色提供ビヘイビアは、複数の色変換テーブルを、ＣＲＤ内の単一の／RenderTable（／提供テーブル）内に連結することによって実現される。単に、／RenderTableの異なった領域（region）にアクセスすることによって、異なった提供ビヘイビアによって、単一のグラフィック状態へアクセス可能である。色提供ビヘイビアを持つことによって、グラフィック状態無しの”切替（switch）”が、実行（implementation）を非常に高速にする。全体の実行が、色提供辞書に限定されるので、ダイナミックなＣＲＤｓは、いかなる現存するPostscriptプリンタの上でも実行され得る。これは、何年もの間使用されてきた物においてさえも、同じである。

　本発明の追加の目的および利点が、添付の図面を参照した以下の詳細な記述から明白になろう。

　本発明の課題の一つは、画像またはグラフィックが要求されるか否かを迅速に判断すると同時に、適切な色を提供することである。

　本発明の課題を解決するために、本発明では、２つまたはそれ以上の色変換テーブルを一つのRenderTableに連結する、ステップを含む、ダイナミックな色提供辞書を生成するための方法を提供する。

　また、一つ以上の色変換テーブルを、Postscript内の一つのRenderTableに連結するための手段、を備えるダイナミックな提供辞書システムを提供する。

　更に、２つ以上の色変換テーブルを、一つのRenderTableに連結し、複数のオブジェクトタイプの間の色提供ビヘイビアを自動的にスイッチングし、一定のオフセットを、一つのRenderTableの指標軸（indexing axis）に加算することによって、個々の色テーブルにアクセスし、前記一つのRenderTableの異なった領域（region）にアクセスすることによって、一つのグラフィックス状態内の異なった提供ビヘイビアにアクセスすること、を含む、ダイナミックな色提供辞書を提供する。

　本発明の効果のひとつは、画像またはグラフィックが要求されるか否かを迅速に判断すると同時に、適切な色を提供することができることである。

　AdobeのPostscriptは、装置に依存しない色指定方法を提供する。Postscriptが、装置に依存しない色を指定するための色提供辞書の色変換工程を利用する例が、図１および２に示される。装置に依存しない色を使用する用途（application）は、複数の印刷装置および印刷技術において、より、首尾一貫した見かけの色（consistent looking color）を生成する傾向がある。その用途は、その選択した色空間１２において旨く働く。一般的に、用途の動作空間は、特定の校正された装置空間（device space）である。より強力な用途のいくつかは、ユーザが、装置に依存しない空間（即ちＣＩＥＬ＊ａ＊ｂ）で直接作業することを可能とする。本用途は、その作業色空間をＣＩＥ三刺激値の（tristimulus）空間（x，y，z）に変換する方法を指定（specify）しなければならない。本用途は、ＣＩＥに基づいた色空間（CIEBased color space）（CIEB asedA, CIEBasedABC,またはCIEBasedDEFG）を設定することによってこれを達成する。CIEBased色空間のいずれもの出力も、常にCIExyz１４である。

　プリンタ側においては、CIExyz１４からプリンタ装置信号（一般的にＣＭＹＫ）への変換を提供することは（提供するか否かは）、製造者に依存する。CIExyz１４からプリンタ装置信号への変換は、Adbeによって決定された、数学的操作の手順（sequence）を通じて実現される。数学的変換の手順は厳格に定義され、変更不可能である。しかし、各数学的変換の仕様（specifics）は、完全に変更可能である。これによって、色マッチング（color matching）のための、強力でロバストな機構（mechanism）が実現可能となる。装置信号機構へのCIExyz１４は、色提供辞書を通じて変更される。

　図１および２に再度戻る。ここで、色提供辞書は、白ポイント調整方法（white point adjustment method）１６を指定しなければならない。これは、入力してくる色を、ソース色空間の白ポイントと、装置（目的）白ポイントとの間の差異のために調整する。現在用いられている白ポイント調整１６の例は、線形化されたブラッドフォード空間（Linearlized Bradford space）でのVonKries変換である。

　白ポイント調整１６後に、白ポイント調整されたCIExyz信号を補間空間（interpolation space）に変換する、複数ステップの工程が開始される。最初に、調整されたCIExyz値は、ＬＭＮ値１８を生成するために配列乗算（matrix multiplied）される。使用される特定の配列は、色提供辞書内へのMatrixLMNエントリとして特定される。次に、LMN信号は、符号化関数（encoding functions）２０によって変換される。符号化工程は、図２の３つの新しい値、Ｌ’，Ｍ’，Ｎ’６６，６８，７０を、それぞれ生成する。符号化関数は、３つのPostscript手順、Ｔ_L（Ｌ），Ｔ_M（Ｍ）、Ｔ_N（Ｎ）の形式を採る。これらの手順のそれぞれは、それに渡された入力値を、オペランド・スタック（operand stack）での最高の（topmost）項目として消費（consume）し、次に、結果としての値をオペランド・スタックにプッシュすることが想定される。これらの手順は、EncodeLMNエントリとともに色提供辞書内で指定される。

　次のステップは、信号ＡＢＣ２２を生成するための、Ｌ’Ｍ’Ｎ’信号の配列乗算である。使用される特定の配列は、色提供辞書へのMatrixABCエントリによって決定される。次に、ＡＢＣ信号は、符号化関数２４を用いて変換される。符号化工程は、３つの新しい値、Ａ’Ｂ’Ｃ’を生成する。符号化関数は、３つのPostscript手順、Ｔ_A（Ａ）、Ｔ_B（Ｂ）およびＴ_C（Ｃ）の形式を採る。これらの手順のそれぞれは、それに渡された入力値を、オペランド・スタック上の最高の項目として消費し、次に、結果としての値をオペランド・スタックの上にプッシュすることが想定される。これらの手順は、色提供辞書内でEncodeABCエントリとともに指定される。

　Ａ’Ｂ’Ｃ’は今、３次元ルックアップテーブル２６への入力を表す。ルックアップテーブルは、いかなる数の、各軸に沿って均等に間隔が空けられた節点（nodes）をも含み得る。節点間の値は、トリ・リニア（tri-linear）補間を用いて計算される。補間のドメインは、色提供辞書で、RangeABCエントリとともに（with）指定される。補間の結果は、中間装置信号（

でありうる）である。装置信号を調整ための、一つの最後の機会が存在し得る。ポスト補間符号化関数（post interpolation encoding functions）２８が存在する。これらの符号化関数は一般的に、調的な（tonal）応答曲線を装置信号に適用（apply）するために使用される。これらの符号化関数の出力は、

信号（これは、要求された色への所望の色マッチ（color match）を提供することになる）である。少なくとも装置信号が、ハーフトーニング・ルーチン（halftoning routines）に渡され、結局は、それらはフレームバッファ３０へ進む。

　Adobeのコア符号（core code）は既に、各オブジェクト・タイプの決定を為しており、適切な色パイプライン（color pipeline）を使用する。どの色パイプラインが使用されるかを決定することによって、提供されるオブジェクトタイプが安全に推理される（deduced）。ＣＲＤ手順が実行される順番（order）を追跡（tracking）することによって、どの色パイプラインが使用されているかを推理することが可能である。もし手順が、Adobeレッドブック（Red Book）（特に、その後に、提供テーブル構造（RenderTable structure）での変換手順が続く、EncodeL,EncodeM,EncodeN,EncodeA,EncodeB,EncodeC）で記述された順番で実行されているならば、オブジェクトはグラフィックである。もし反復する同じ手順のコール（call）が存在するならば、キャッシュテーブルが生成されており、オブジェクトは画像（image）である。この実行（implementation）に対しては、非常に大きい数の変動が存在することに留意して欲しい。この実行の全ては、以下の一般的な要素（element）を含まねばならない。いつそれが実行されたかについての明白な情報（explicit information）を記憶（メモリに書きこみ）するための２つ以上のＣＲＤ手順、（メモリから）記憶された情報を読むための２つ以上のＣＲＤ手順、および、使用されている色パイプラインのタイプを決定するための一つあるいはそれ以上のＣＲＤ手順を可能とする計算タスク（computational tasks）を実行するための２つ以上のＣＲＤ手順。

　図２を再度参照する。ここで、ダイナミックな色提供辞書は、実際には２つのテーブル（画像テーブル３２およびグラフィック・テーブル３４）の連結（concatenation）である、提供テーブル２６を備える。色テーブル連結は、プリンタ内または外部ホスト（不図示）上において為され得る。色テーブルは、提示テーブルアレイ（RenderTable array）の第４要素（element）（指標（index）３）内に記憶される。色テーブル実施は、ストリング（string）のアレイである。色テーブルは、軸、即ちＡ、Ｂ、および、Ｃ、に沿って、または複数軸に沿っても、連結され得る。しかし、Ａ軸に沿ってテーブルを連結することが、より容易である。Ａ軸に沿って、２つの色テーブルを、単一の色テーブルに連結するために、色テーブルアレイのストリングが単一のより大きいアレイに連結される。以下のコード・フラグメント（code fragment）が、プリンタ上でそのタスクを実行する。”[exch{}forall counttomark 1 add index {} forall ]exch pop ”このコード・フラグメントは、オペランド・スタック（それが想定するものが色テーブルアレイである）の上の頂部の２つのオブジェクトを消費する。このコード・フラグメントは次に、各アレイのコンテンツを連結し、連結を、オペランンド・スタック上の最頂部のオブジェクトとして残す（leaves）。Ｂ軸に沿ってテーブルを連結することは、ストリング自身を連結することによって実現される。色テーブルをＣ軸に沿って連結することは、ストリングの固定された間隔（interval）をインターリーブすることによって実現される。連結された色テーブルは、個々の色テーブル内の全ての節点の合計と等しいトータルの節点数を持つことになる。

　本発明の一つの実施例によって、Ｔ_A（Ａ）７２の符号化手続中に問合せ（query）が為される。以下により詳細に説明されるように、この手続において、グラフィック・オブジェクトが画像化された（imaged）か否かを判断するために問合せが為される。もしグラフィック・オブジェクトが画像化されているならば、より大きいオフセットが、Ａ軸（連結軸）３６に沿って、結果としての値に加えられる。これによって、補間ステップが、提供テーブル２６のグラフィック部分３４を参照することを強いられる。もし、加えられるオフセットが存在しなければ、補間ステップは、テーブル２６の画像部分３２を参照する。２つのテーブルの間の空間は、決して参照されない（それは、２つのテーブルの間を補間することになる）。

　グラフィック検知機構のための問合せは、複数のＣＲＤ手続（procedures）にまたがり、手順は組の手順（set sequence）で実行されない。これによって、単一のフローチャートを構築することが困難となり、それ故、図３から７の一続きのフローチャートとして示される。これらのフローチャートは、特定のＣＲＤ手続の中からの、論理的フラグメントを表す。Postscriptは、静的な局所変数（static local variables）の概念を利用しない。全体のグラフィック検知機構は、単一の変数ｇを使用する。ここで、ｇは、ＣＲＤ内の手続に対してのみ可視的（visible）な静的な局所変数である。所望の可変特性（variable properties）をシミュレートするために、ｇは、単一の要素（single element）を持つ配列（array）であるように定義される。ｇの値は、配列に配置される。この手続は、即時置換オペレータ（immediate substitution operator）（即ち、／／g）がそれ（ｇ）に先行する、ｇへの全ての参照（references）とともに定義される。これは、ｇの値を、定義の時刻（time of definition）における手続内に配置する（ｇは配列である。そして、配列は複合のオブジェクトなので、配列オブジェクトの全てのインスタンスは、同じコンテンツを共有する）。均等な振舞いを実現するための類似のやり方で使用され得る、他のPostscript複合オブジェクトが存在する。図３を参照する。ここで、変数ｇは、ステップ３８でコード・フラグメントを開始し、ステップ４２でｇを０に設定し、そして、コード・フラグメント４０をＣＲＤ内で符号化する、ことによって初期化されなければならない。それをＣＲＤ自身で初期化することは、これを行うのに好ましい。手続が定義されている間に、変数は、定義され、”可視化”されなければならない。ＣＲＤが、辞書スタックの上の最頂部の辞書である限り、ｇは可視的である。次の３つの論理／コード・フラグメントは、図４から６に示されるように実際に検知を行う。それらは全て、EncodeLMN手続の一部分である。もしEncodeLMN手続が次々と（in sequence）実行されるなら、ｇは、３の値を持つことになる。いかなる他の手順に対しても、ｇは、３とは等しくない値を持つことになる。もしｇが３と等しいならば、手続は次々と（in sequence）実行された。ＣＲＤは、正確な色パイプラインとともに使用されている。提供されているオブジェクトは、グラフィックである。もしｇが３と等しくないならば、手続は次々と実行されていなかった。コアのコードは、速い（fast）色キャッシュ・テーブルを構築している。ＣＲＤが、速い色パイプラインとともに用いられている。提供されているオブジェクトは画像である。EncodeLMN手続の手順を判断するために使用される方法は、対応するPostscriptコードを持つ（各フローチャートを反映するコメントを有する）図４から６を参照して以下に更に詳細に説明される。

　図４を参照する。ここで、EncodeL手続は、ステップ４４で、配列のオブジェクト検知要素ｇの値をチェックするコード・フラグメント３８を含む。コード・フラグメントは次に、要素に新たな値を割り当てる。もし古い値が０ならば、ステップ４６に示されるように新しい値は１である。ステップ４８に示されるように、全ての他の古い値に対して、新規に割り当てられた値は０である。これで、EncodeL手続に対するコード・フラグメント・ステップ４０が終了する。

　次に、図５を参照する。ここで、EncodeM手続は、ステップ５２で配列のオブジェクト検知要素ｇの値をチェックするコード・フラグメント３８を含む。次にコード・フラグメントは、要素に新しい値を割り当てる。もし古い値が１ならば、ステップ５０に示されるように新しい値は２である。全ての他の古い値に対して、ステップ５４のように、新しく割り当てられた値は０である。これで、EncodeM手続に対する、コード・フラグメント・ステップ４０が終了する。

　次に、図６を参照する。ここで、EncodeN手続は、ステップ５６で配列のオブジェクト検知要素ｇの値をチェックするコード・フラグメント３８を含む。コード・フラグメントは次に、要素に新しい値を割り当てる。もし、古い値が２ならば、ステップ５８に示されるように、新しい値は３である。全ての他の古猪値について、ステップ６０のように、新しく割り当てられた値は０である。これで、EncodeN手続に対するコード・フラグメント・ステップ４０が終了する。

　全てのＣＲＤ手続が定義された後に、ＣＲＤ内のｇへの参照は、除去され得る。これによって、潜在的な、変数ｇが何らかの他のPostscriptジョブによって参照される、という問題が避けられる。オブジェクト・タイプについての情報は、RenderTable内で指定された、EncodeABC手続及び／又は変換手続（transform procedure）で使用され得る。最後の、ｇへの参照が、状態を元に（その初期状態に）リセットすることが重要である。これは、図７に示されるように行われる。ここで、ステップ３８のコード・フラグメントは、ステップ６４においてｇを０に等しくリセットし、ステップ４０でこのフラグメントを終了させる。もしこれが為されなければ、次にグラフィック検知機構が、引き続く問合せについての誤った結果を生成し得る。名称ｇが、何らかの他の目的に対して他の誰かによって使用され得る、という高い可能性が存在する。変数を定義しないことによって、インタープリタが、この変数を他の誰かのものと、混同することを防ぐことができる。

　要約すると、画像とグラフィック・オブジェクトの間を差別化（differentiation）するための機構は、完全に、ＣＲＤ内に含まれる。ここで、画像とグラフィック・オブジェクトの間の差別化は、その中でEncodeLMN手続（procedure）が実行される手順（sequence）を監視することによって実現される。EncodeL、EncodeM、およびEncodeN手続が、その順番で実行されるとき、グラフィック・オブジェクトは、処理（processed）／提供（rendered）される。もしEncodeLMN手続が、他の何らかの手順で実行されるならば、画像オブジェクトが処理／提供される。

　図８は、テーブル選択機構の表現である。このフローチャートは、EncodeA手続７２を構成するコードを表す。EncodeA手続が開始される７４ときに、Ａの入力値が渡される。EncodeA手続は次に、任意の符号化７６を実行する。この符号化の結果は、変数Ａ’に割り当てられる。この任意の符号化は、Adobeによって元々定義された全ての機能（functionality）を含む。

　残りの処理の全ては、厳格に、テーブルスイッチング機構に関連する。次のステップは、提供されている現在のオブジェクトタイプが、グラフィック７８であるか否かを判断することである。これはブールのテスト（Boolean test）であり、状態変数ｇと３を比較することによって実現され得る。もし状態変数ｇが３に等しいならば、次にグラフィックオブジェクトが提供され、さもなければ、提供されているオブジェクトタイプは画像のはずである。もし提供されているオブジェクトタイプが画像ならば、それ以上の処理は必要とされず、EncodeA手続は実行を終了する（８２）。もし、提供されているオブジェクト・タイプがグラフィックならば、のＡ’値は、グラフィックテーブル８０の仮想ドメイン（virtual domain）に変換（translated）される必要がある。これは、定数Ａ０をＡ’の値に加算することによって実現される。Ａ０の値は、以下の方程式を用いて計算され得る。
Ａ０＝ｕ０−ｖ０＋｛Ｎu（ｕ１−ｕ０）／（Ｎｕ−１）｝
ここで、[ｕ０，ｕ１]は、連結された軸に沿った画像色テーブルのドメインであり、Ｎｕは、連結された軸に沿った画像色テーブルでの節点の数であり、[ｖ０，ｖ１]は連結された軸に沿ったグラフィック色テーブルのドメインであり、Ｎｖは、連結された軸に沿ったグラフィック色テーブルでの節点の数である。一旦これが為されると、EncodeA手続は終了する（８２）。

　図９は、代替的な、テーブル。スイッチング機構の実行を表す。この実行において、RenderTableに連結された３つの色テーブル（画像テーブル、グラフィックテーブル、および側色一致テーブル（colorimetric match table））が存在することが想定される。EncodeA手続の実行は、８４から始まる。手続は、入力値Ａを渡される。EncodeA手続は、次に任意の符号化８６を実行する。この符号化の結果は、変数Ａ’に割り当てられる。この任意の符号化には、元々Adobeによって定義された全ての機能が含まれる。

　残りの処理の全ては、厳格に、テーブル・スイッチング機構に関連する。第１のステップは、処理されている色が、４つの色入力として指定されているか否かをチェックすることである（８８）。４つの色入力は、最も、プレスＣＭＹＫ値（press CMYK value）を表す傾向があり、パントン・スポット・カラー（pantone spot colors）を表し得る。これらの場合に対して、カラリメトリック・インテント（colorimetric intent）を使用している（真に、なるべく近く一致させるように努力する）オブジェクトを提供することが最も望ましい。色入力チャンネルの数を判断することは、PostScriptにおいて些細なタスクである。以下のコード・フラグメント（現在の色カウントをマーク（mark）にマークする（mark））によって、それは容易に実現され得る。もしこの問合せの結果が、４に等しいならば、カラリメトリック・テーブルが選択される必要がある。定数Ａ１をＡ’の値に加算することによって（９４）、カラリメトリック・テーブルは選択される。これは、Ａ’をカラリメトリック・テーブルの仮想ドメイン（virtual domain）に変換する。Ａ１の値は、以下の式を用いて計算され得る。
Ａ１＝ｖ０−ｗ０＋｛（Ｎu＋Ｎｖ）（ｖ１−ｖ０）／（Ｎｕ−１）｝
ここで、[ｕ０，ｕ１]は、連結された軸に沿った画像色テーブルのドメインであり、Ｎｕは、連結された軸に沿った画像色テーブルでの節点の数であり、[ｖ０，ｖ１]は連結された軸に沿ったグラフィック色テーブルのドメインであり、Ｎｖは、連結された軸に沿ったグラフィック色テーブルでの節点の数であり、[ｗ０、ｗ１]は、連結された軸に沿ったグラフィック色テーブルのドメインであり、Ｎｗは、連結された軸に沿ったグラフィック色テーブルでの節点の数である。一旦カラリメトリック・テーブルが選択されると、EncodeAの実行手続は、終了し得る（９６）。

　もしステップ８８で、現在の色が、４つの色入力として指定されていないと判断されるならば、処理は以下のように続く。次のステップは、提供されている現在のオブジェクト・タイプがグラフィックであるか否かを判断することである９０。これは、ブールテスト（Boolean test）であり、状態変数（state variable）ｇを３と比較することによって実現され得る。もし状態変数ｇが３と等しいならば、グラフィック・オブジェクトが提供され、さもなければ提供されるオブジェクト・タイプは画像のはずである。もし提供されているオブジェクト・タイプが画像ならば、それ以上の処理は要求されず、EncodeA手続は実行を終了する（９６）。もし提供されているオブジェクト・タイプがグラフィックならば、Ａ’の値は、グラフィック・テーブルの仮想ドメインに変換されねばならない（９２）。これは、Ａ’の値に定数Ａ０を加算することによって実現される。Ａ０の値は、以下の式を用いて計算され得る。
Ａ０＝ｕ０−ｖ０＋｛Ｎu（ｕ１−ｕ０）／（Ｎｕ−１）｝
ここで、[ｕ０，ｕ１]は、連結された軸に沿った画像色テーブルのドメインであり、Ｎｕは、連結された軸に沿った画像色テーブルでの節点の数であり、[ｖ０，ｖ１]は連結された軸に沿ったグラフィック色テーブルのドメインであり、Ｎｖは、連結された軸に沿ったグラフィック色テーブルでの節点の数である。一旦これが為されると、EncodeA手続は実行を終了する（９６）。

　配列のオブジェクト・タイプ検知要素の値は、いずれかの以下のＣＲＤ手続で使用され得る。EncodeA,EncodeB,EncodeC、および、RenderTable変換手続の全て。配列のオブジェクト検知要素の値は、インテリジェントに（intelligently）、提供の色ビヘイビア（color behavior）を変更（alter）／スイッチ（switch）するために使用され得る。これらの手続の一つもまた、要素の値を、その初期値０にリセットしなければならない。一つのＣＲＤ提供テーブルエントリ（Render Table entry）に連結された複数の色テーブルが存在する。各色テーブルは、明確な色ビヘイビアのためのデータを含む。個々の色テーブルは、一定のオフセットを、RenderTableの指標軸（indexing axis）に加算することによってアクセスされる。

　一般的なＣＲＤ色変換工程は、静的（static）である。言いかえれば、結果としての色は、アプリケーション（application）が要求する色のみの関数である。これは、完全には、増大する色に精通したプリンタ市場の要求を満たさない。ユーザは、多くの色を期待する一方、画像とグラフィックの双方を印刷することを期待する。実際には、グラフィックスのためのベストの色一致（color match）は、画像のためのベストの色一致とは非常に異なる。良いグラフィックス色一致は、輝度及び／又は色相を確保することによって、生気に溢れる飽和度に達した（vibrant saturated）色を提供する。対照的に、色相および輝度をより良く維持するために、良い画像色一致は、飽和を犠牲にする。色提供辞書を生成することに対する伝統的なアプローチは、（多くの）色一致スタイル（color matching styles）の間の最良の妥協を発見することを含む。一つ色提供辞書内に複数の色ビヘイビアを提供する能力は、この妥協を為す必要性を緩和する。これによって、全体としてのより良い色一致という結果をもたらす。

　非常に非従来型の、現存する機構（およびコード）の使用によって、ＣＲＤが、動的（dynamic）である状態がもたらされることも、（ここに）開示されている。一つのPostscript色提供辞書（ＣＲＤ）は、一つのグラフィック状態内に複数の色提供意図（intents）を自動的に生成する。これによって、結果としての色が、アプリケーションが要求した色に依存すること、以上のことが可能となる。自動的にインテリジェントに選択された複数の提供意図が存在し得る。選択基準は、入力色空間、提供されるオブジェクトタイプ、及び／又は実際の入力色、を含み得、それに限定されない。

　本出願の請求項記載以外の発明について記載する。

　請求項１に記載の方法において、複数のオブジェクトタイプの間の色提供ビヘイビアを自動的にスイッチングするステップを更に含んでもよい。

　請求項１に記載の方法において、一定のオフセットを、一つのRenderTableの指標軸（indexing axis）に加算することによって、個々の色テーブルにアクセスするステップを更に含んでもよい。

　請求項１に記載の方法において、前記一つのRenderTableの異なった領域（region）にアクセスすることによって、一つのグラフィックス状態内の異なった提供ビヘイビアにアクセスするステップを更に含んでもよい。

　請求項１に記載の方法において、２つ以上の色変換テーブルを、Postscriptタスクとして一つのマージされたRenderTableにマージするステップを更に含んでもよい。

　請求項１に記載の方法において、画像テーブル、グラフィックテーブル、およびカラリメトリ一致テーブルを前記一つのRenderTableに連結するステップを更に含んでもよい。

　請求項１に記載の方法において、２つ以上の色変換テーブルを、外部ホストによって前記一つのマージされたRenderTableにマージするステップを更に含んでもよい。

　請求項１に記載の方法において、いずれかの一つ以上の色テーブルの軸に沿って連結するステップを更に含んでもよい。

　請求項１に記載の方法において、複数の一つ以上の色テーブルの軸に沿って連結するステップを更に含んでもよい。

　請求項１に記載の方法において、色テーブル配列のストリングを一つのより大きな配列に連結するステップを更に含んでもよい。

　請求項１に記載の方法において、ストリング自身を連結することによって、色テーブル配列のストリングを連結するステップを更に含んでもよい。

　請求項１に記載の方法において、固定されたストリングのインターバル（interval）ををインターリービングすることによって色テーブル配列を連結するステップを更に含んでもよい。

　また、請求項１に記載の方法において、技術的に可能な場合には、以上の各付加ステップの複数を組合せてもよい。

Adobeによって指定された色提供辞書色変換工程のブロック図。本発明の一つの実施例によるダイナミックな色提供辞書色変換工程のブロック図。色提供辞書内の変数ｇの初期化のステップを示すフローチャート。 EncodeL工程中にオブジェクトタイプ（object type）を検知するためのフローチャート。 EncodeM工程中にオブジェクトタイプを検知するためのフローチャート。 EncodeN工程中にオブジェクトタイプを検知するためのフローチャート。色提供辞書内で変数ｇを初期状態に復元するステップを示すフローチャート。提供テーブル内へのダイナミックな参照を実行するための符号化関数（encoding function）を使用した例を示すフローチャート。提供テーブル内へのダイナミックな参照を実行するための符号化関数の使用の他の例を示すフローチャート。

Claims

　２つまたはそれ以上の色変換テーブルを一つのRenderTableに連結する、
ステップを含む、ダイナミックな色提供辞書を生成するための方法。
　一つ以上の色変換テーブルを、Postscript内の一つのRenderTableに連結するための手段、を備えるダイナミックな提供辞書システム。
　２つ以上の色変換テーブルを、一つのRenderTableに連結し、
　複数のオブジェクトタイプの間の色提供ビヘイビアを自動的にスイッチングし、
　一定のオフセットを、前記一つのRenderTableの指標軸（indexing axis）に加算することによって、個々の色テーブルにアクセスし、
　前記一つのRenderTableの異なった領域（region）にアクセスすることによって、一つのグラフィックス状態内の異なった提供ビヘイビアにアクセスすること、
を含む、ダイナミックな色提供辞書。