【発明の詳細な説明】
カラー・マッチング・システム
発明の背景
発明の分野
本発明は、一般的には、オペレーティング・システム・ソフトウェア・アーキ
テクチャに関し、より具体的には、カラー処理をサポートするオペレーティング
・システム・ソフトウェア・アーキテクチャおよびその方法に関する。
関連技術の説明
コンピュータ・システムは、テキスト情報やグラフィック情報を含む、さまざ
まな種類の情報を処理することを目的とした情報処理システムである。これらの
コンピュータ・システムは、そのハードウェアとソフトウェアを含めて、上記情
報をカラーで処理できるようにますます高度化されているが、カラー情報をサポ
ートし、処理する能力にはそれでもなお限界がある。例えば、コンピュータ・シ
ステムの能力に限界がある問題の１つは、カラーを表示し、印刷し、プロットし
て、視聴者にカラーで表示する広大な種々の周辺デバイスと、コンピュータ制御
の下で、インタフェースしサポートすることである。もう１つの問題は、自分が
選んだ「カラー（色）空間」（color space）のカラーをコンピュータ・システ
ム上でプログラムしたり、処理したりするコンピュータ・プログラマやコンピュ
ータ・ユーザの能力に限界があることである。
具体的には、上に挙げた最初の問題に関しては、比較的普及しているカラー周
辺デバイスのいくつかを列挙すると、コンピュータ・モニタやＴＶスクリーンな
どのディスプレイ（表示装置）、インクジェット・プリンタやレーザ・プリンタ
、写真印刷(photolithography)プリンタなどのプリンタ、静電式プロッタやド
ラム／フラットベッド(flatbed)プロッタなどのプロッタがある。これらのデバ
イスの各々はコンピュータ・システムに直接またはインタフェースを介して接続
でき、その場合、表示、印刷またはプロットされるカラー情報は、コンピュータ
・システムのハードウェア、オペレーティング・システム・ソフトウェアおよび
アプリケーション・ソフトウェアによって処理されている。
これらのカラー周辺デバイスには、少なくとも２つの側面がある。それは、(1
) デバイスが動作するカラー空間と(2) カラーのデバイス依存性(device-depend
ency)である。カラー空間（色空間）とは、空間内の各点がカラーに対応づけら
れている３次元空間のことである。例えば、RGB カラー空間は、各々の点が赤(R
) 、緑(G) および青(B) 色素の加法混色量(additive amount)から作られたカラ
ーになっているデバイス・カラー空間である。RGB カラー空間で動作する代表的
なものとしては、カラー・モニタやTVスクリーンがあり、そこでは、モニタ上の
赤、緑および青のけい光物質からの光が組み合わされて特定のカラーを表示して
いる。別の例としては、CYMKカラー空間があり、そこでは各点はシアン(C) 、マ
ゼンタ(M) 、黄(Y) および黒(K) の減法混色量から作られたカラーになっている
。インクを使用するプリンタはCYMKカラー空間で動作するのが通常であり、そこ
ではインクの色素が組み合わされてハードコピー媒体上にカラーを形成している
。種々のカラー・デバイスに関係する他のカラー空間はこの分野において周知で
ある。
カラーのデバイス依存性(color device-dependency)は、各デバイスが独自の
「色域」（color gamut）をもっていることと関連がある。色域とは、ある特定
のデバイスの１組の色素けい光物質、インクまたは他の色素を使用してカラー空
間内に作ることができるカラーの範囲のことである。言い換えれば、あるデバイ
スの色域は、そのデバイスによって作成可能な可視カラー(visible colors)の特
定領域を構成している。例えば、あるメーカ製のRGB カラー・モニタは、別のメ
ーカ製のRGB カラー・モニタと異なった色域をもつ場合もあれば、同じメーカ製
のカラー・モニタはモデルが異なるごとに異なる色域をもつ場合もある。これら
のデバイスから得られるカラーに「デバイス依存性」があるのはそのためである
。さらに、各デバイスは独自のカラー「プロフィール」をもっている。カラー・
プ
ロフィール(color profile)とは、特定のデバイスがその色域内で必要なカラー
を実際に作るのにどれだけ理想から離れているかを示す尺度である。従って、例
えば、２つの異なるカラー・モニタから表示される同じ赤のネクタイは異なった
カラーの赤で現れることがあるので、デバイス依存性があり、カラーが不正確に
なる。本明細書に記載され、例を挙げて説明されているカラー、カラー空間、色
域、その他カラーに関係する原理については、例えば、Fred W.Billmeyer,JrとM
ax Salzman 共著「カラー・テクノロジの原理」（Principles of Color Technol
ogy）第２版(John Wiley & Sons，1981)およびFoley 他共著「カラーとコンピュ
ータ」(Color and Computer)(Addison-Wesley Publishing Co.，Inc．1990)に詳
しく解説されている。
上述した従来のコンピュータ・システムにおけるカラー処理の特徴の１つは、
「カラー・マッチング」（color matching−色合せ、等色）に関係するものであ
る。コンピュータ・システムのユーザは、カラー・モニタに表示されているイメ
ージを、プリンタを使用してハードコピーでとりたい場合もあれば、プリンタに
現れたハードコピー・イメージを、モニタからカラー・イメージで表示したい場
合もある。これらの周辺デバイスは異なるカラー空間で動作し、異なる色域とプ
ロフィールをもっているので、一方のデバイスに現れるイメージのカラーは、他
方のデバイスに現れるカラーと一致していない。しかし、コンピュータ・システ
ムは、カラー・マッチング方式(color matching scheme)を実装したソフトウェ
ア・オペレーティング・システム・アーキテクチャを採用しており、一方のデバ
イスに現れたカラーが、他方のデバイスヘ転送されたカラーと実質的に同一では
ないとしても、それに近いカラーになるようにしている。
従来のソフトウェア・オペレーティング・システム・アーキテクチャは、その
カラー処理能力に限界がある。限界の１つは、あるカラー空間で動作している周
辺デバイスがあるとき、アーキテクチャがそのデバイスをサポートするように設
計されていなかったか、あるいはサポートするように変更できなければ、オペレ
ーティング・システム・アーキテクチャがそのデバイスをサポートできないこと
である。また、従来のアーキテクチャは、カラー・モニタのように、独自のカラ
ー空間、色域およびプロフィール特性をもつ特定の周辺デバイスのカラーをサ
ポートし、そのカラーを特定のカラー・プリンタのように、独自の上記カラー特
性をもつ別の周辺デバイスにマッチングさせる能力を有している場合もある。そ
れにもかかわらず、上に挙げた特定のカラー・モニタやプリンタとは異なるカラ
ー特性をもつカラー・モニタやプリンタが１種類または２種類以上コンピュータ
に接続される、あるいは、プロッタやカラーＴＶカメラのような他のタイプのカ
ラー周辺デバイスがコンピュータに接続されると、従来のコンピュータ・システ
ム、具体的には、そのオペレーティング・システム・アーキテクチャは、これら
の他の異種周辺デバイスのいずれについてもカラー・マッチングをサポートでき
なくなるという別の限界がある。
さらに、二番目に挙げた問題については、コンピュータ・システムのユーザは
、限界をもつ従来のオペレーティング・システム・アーキテクチャによってサポ
ートされる周辺デバイスのカラー空間とは異なる、自分の選んだいくつかのカラ
ー空間で仕事をすることを望んでいる場合がある。例えば、RGB カラー空間とCY
MKカラー空間の他にも、ルミナンス・ユニット・ベクトル(Luminance Unit Vect
or - LUV)カラー空間およびLUV 色相、彩度、明るさ(hue，saturation，brightn
ess - HSL）カラー空間と呼ばれるカラー空間が２つある。しかるに、限界のあ
るオペレーティング・システム・アーキテクチャを採用した上述のコンピュータ
・システムで仕事をしているコンピュータ・ユーザはモニタのRGB カラー空間や
プリンタのCYMKカラー空間だけで仕事を行うことができ、他のカラー空間では仕
事ができない場合がある。
発明の概要
本発明は、カラー処理をグローバル・スケールでサポートする独特のオペレー
ティング・システム・アーキテチャと方法を提供している。本発明のオペレーテ
ィング・システム・カラー・アーキテクチャと方法によれば、異種の周辺カラー
・デバイスがいくつでもサポートされるのと同じように、カラー・マッチング方
式(color matching scheme)もいくつでもサポートされる。言い換えれば、本発
明のアーキテクチャは、デバイスでカラーを使用するために、周辺デバイ
ス・メーカが採用しているどのアプローチとも結びついていないし、またどのア
プローチにも拘束されていない。また、アーキテクチャ自体はカラー・マッチン
グ方式と結びついていないし、拘束されていない。さらに、新しいカラー周辺デ
バイスが、本発明のアーキテクチャを実装した所与のコンピュータ・システムと
のインタフェースとなったとき、かかる新デバイスのメーカは、これらのデバイ
スが、そのシステムとインタフェースとなっている既存のすべてのカラー周辺デ
バイスと正しく通信できるという保証が得られる。
さらに、本発明のオペレーティング・システム・アーキテクチャと方法によれ
ば、アーキテクチャのユーザは、自分が望ましいとするどのカラー空間において
も作業することができ、また、完全に拡張可能であるので、アプリケーション・
ソフトウェア・プログラマが新しいカラー・モデルまたはカラー空間を作成した
り、それが必要になったとき、これらをアーキテクチャに追加して、アーキテク
チャにサポートさせることができる。これと同時に、本発明のアーキテクチャに
よれば、カラー・モデルが追加されたとき、システムにすでに追加されている他
のカラー・モデルがあればそのカラー・モデルと完全に統合化して使用できるこ
とが保証される。
また、カラー空間を大きく分類すると、２つのタイプがある。１つは未較正(u
ncalibrated)カラーまたはデバイスに依存するものであり、もう１つは較正(cal
ibrated)カラーまたはデバイスから独立したものである。本発明の別の特徴によ
れば、アーキテクチャは、独自の色域をもつ未較正カラーと共に較正カラーをサ
ポートしているので、各未較正カラーは、どうすれば較正カラーになるか、つま
り、未較正カラーと較正カラー空間との関係をどのように指定するかを知ってい
る。
本発明のオペレーティング・システム・カラー・アーキテクチャは、上に挙げ
た特徴を実行するするためにオブジェクト指向設計として実現されている。オブ
ジェクト指向設計の一般理論と手法はこの分野では周知である。例えば、Grady
Booch 著「オブジェクト指向設計とそのアプリケーション」(Object Oriented D
esign with Applications)(Benjamin/Cummings Publishing Company,1991)に記
載されている。
本発明のオブジェクト指向オペレーティング・システム・カラー・アーキテク
チャがもつ１つの側面によれば、バーチャル（仮想）抽象基底クラスと、未較正
カラーを収めているコンテナ・クラスとを定義しているクラス(TColor)と、クラ
ス(TColorGamut)およびアーキテクチャとのインタフェースとなっている各周辺
デバイスの色域を定義している他のカラー仕様パラメータと、各周辺デバイスの
色調再現曲線(tonal reproducation curve)を定義しているデータを収めている
クラス(TColorProfile)である、１つのインタフェース・レベルをもつ統合カラ
ー・モジュール(integrated color module)と、周辺デバイスからのカラー・デ
ータを統合カラー・モジュールへ入力する入力インタフェース・ソフトウェア・
モジュール(input interface software module)と、統合カラー・モジュールに
よって処理されたカラー・データを周辺デバイスへ出力する出力ソフトウェア・
インタフェース・モジュール(output software interface module)とを含んでい
る。
本発明のオブジェクト指向ソフトウェア・システム・アーキテクチャがもつも
う１つの側面によれば、すべてのカラー・クラスがそれから派生し、基底クラス
および較正カラーのコンテナ・クラスであるクラス(TColor)と、クラス(TColor)
から直接に派生し、基底クラスおよび未較正カラーのコンテナ・クラスであるク
ラス(TDeviceColor)と、クラス(TColor)から直接に派生した少なくとも１つの較
正カラー・クラス(TXYColor)と、クラス(TDeviceColor)から直接に派生した少な
くとも１つの未較正カラー・クラス(TRGBColor)と、１つまたは２つ以上の周辺
デバイスの色域情報をストアするテンプレートを収めているクラス(TColorGamut
)と、１つまたは２つ以上の周辺デバイスのカラー・プロフィール情報をストア
するテンプレートを収めているクラス(TColorProfile)とをもっている。
さらに、本発明の別の側面によれば、カラー処理システムは、複数の周辺デバ
イスとのインタフェースとなる機能を備えたデータ・プロセッサと、オブジェク
ト指向ソフトウェア・オペレーティング・システム・アーキテクチャとを備えた
構成になっており、アーキテクチャは次のようなプロパティの１つまたは２つ以
上をもっている。つまり、(i) 較正および未較正カラーをそれぞれ較正および未
較正カラーと関係づけて処理すること、(ii)未較正カラーを較正カラーに変形す
ること、（iii）すべてのカラーがそれ自身からRGB カラーとXYZ カラーを得る
こと、(iv)すべてのカラーがRGB カラーとXYZ カラーを使用して自らをセットす
ること、（v）すべてのカラーがTColorから自らを作ること、(vi)すべてのカラ
ーがTColorから自らをセットすること、（vii）測定可能な色調再現曲線をもつ
ことにより理想的デバイスに対して自身を特徴づける方法を知っている周辺デバ
イスとのインタフェースを行うことである。
さらに、本発明の方法の別の側面によれば、アーキテクチャはソース・カラー
・デバイスからソース・カラー・データを受け取り、ソース・カラー・デバイス
とデスティネーション・カラー・デバイスの色域をそれぞれ示しているデータを
ストアしているクラス(TColorGamut)をコールし、ソース・カラー・デバイスと
デスティネーション・カラー・デバイスのカラー・プロフィールをそれぞれ示し
ているデータをストアしているクラス(TColorProfile)をコールし、ソース・カ
ラー・デバイスのカラーをデスティネーション・カラー・デバイスのカラーにマ
ッチングさせるメソッド関数(method function)をストアしているクラス(TColor
Matcher)をコールし、メソッド関数と、ソース・カラー・デバイスとデスティネ
ーション・カラー・デバイスの色域データおよびカラー・プロフィール・データ
とを使用して、ソース・カラー・データに一致するデスティネーション・カラー
・データを得て、そのデスティネーション・カラー・データをデスティネーショ
ン・カラー・デバイスあてに送るように構成されている。
本発明のその他の側面と利点は、添付図面、詳細な説明および請求の範囲に記
載されている通りである。
図面の簡単な説明
第１図は、好適実施例によるオペレーティング・システム・カラー・アーキテ
クチャを採用したコンピュータ・システムを示すブロック図である。
第２図は、好適実施例においてカラー空間と色域を示す色度グラフ図である。
第３図は、好適実施例において周辺デバイスのある色素の場合の色調再現曲線
またはプロフィールを示す幾何学的グラフ図である。
第４図は、好適実施例による基本的ソフトウェア・コンポーネント（構成要素
）を示すブロック図である。
第５図は、好適実施例においてオブジェクト指向プログラミング設計で実現さ
れたときのカラー・アーキテクチャを示すクラス図である。
第6A図と第6B図は、好適実施例において１つのカラー空間からのカラーを１つ
または２つ以上のカラー空間に変形する様子を絵で表して示す図である。
第７図は、好適実施例によるCIE カラー・マッチング関数を示す図である。
第８図は、好適実施例に従って実行されるカラー・マッチング・プロセスの一
例を、絵で表して示す図である。
第９図は好適実施例を示すブロック図である。
第10図は、好適実施例によるシステム・コンポーネントを示すブロック図であ
る。
第11図は、好適実施例によるシステム・コンポーネントを示すブロック図であ
る。
第12図は、好適実施例においてカラー・マッチングをオーバライド（無効化）
する２つのメソッドを示す図である。
第13図は、好適実施例によるTColorProfiles、TCcolorsおよびTGImagesを示す
Booch Class 図である。
第14図は、好適実施例による２つのカラー・プロフィールColorGamutとColorP
rofileを示す図である。
第15図は、好適実施例においてクラスTColorProfile からサブクラス化(subcl
assing)して、カラー・プロフィールを別のアプリケーションへ入力するオペレ
ーションを示す図である。
第16図は、TColorMatcher と３つのデフォルト・カラー・マッチング・クラス
・インプリメンテーション(TColorimetricColorMatcher、TAppearanceColorMatc
her、TEexactColorMatcher)を示すクラス図である。
発明の詳細な説明
第１図に示すように、コンピュータ・システム10は、複数の周辺デバイス14の
１つまたは２つ以上とインタフェースすることができるコンピュータまたはデー
タ・プロセッサ12を含んでいる。これらの周辺デバイス14の各々は、プロセッサ
12とのインタフェースに追加、あるいは除去できるカラー・デバイスである。こ
れらの周辺デバイス14は、データ・プロセッサ12との間でカラー情報を受渡しで
きるカラー・デバイスの例である。従って、例えば、カラー・デバイス14には、
モニタ16、モニタ18、ドラム・スキャナ20、フラットベッド・スキャナ22、カメ
ラとフレーム・グラバー(grabber)24、トランスファ・プリンタ(transfer print
er)26、ドラム／フラットベッド・プロッタ28、ドットマトリックス・プリンタ3
0、静電式プロッタ32、レーザ・プリンタ34、インクジェット・プリンタ36およ
び写真印刷プリンタ38を含めることが可能である。図にはシングル・データ・プ
ロセッサだけが示されているが、本発明のオペレーティング・システム・ソフト
ウェア・アーキテクチャでは、パラレル・ハードウェア・アーキテクチャに基づ
くシステムで結合可能なマルチプロセッサ12もサポートしている。
データ・プロセッサ12とインタフェースを行う周辺デバイス14は、モニタ16ま
たはモニタ18ではRGB カラー空間、プリンタ36ではCYMKカラー空間といったよう
に、種々のカラー空間の下で動作するリアル（実）デバイス(real device)であ
る。さらに、第１図にはバーチャル（仮想）デバイス(virtual device)40も示さ
れているが、これはプロセッサ12とインタフェースを行い、選択したカラー空間
でカラーを操作するものである。例えば、バーチャル・デバイス42は公知のカラ
ー空間HLS でカラーを操作できるのに対し、別のバーチャル・デバイス44は別の
公知カラー空間xyY でカラーを操作することができる。
所与のカラー空間で動作する各周辺デバイスは、独自の個別的色域とカラー・
プロフィールをもつことができる。第２図と第３図は、それぞれ色度グラフ46と
幾何学的グラフ48を、各デバイス14別に例示したものである。第２図の２次元グ
ラフ46は、RGB カラー空間のように、例えば、モニタ16とモニタ18が共に動作す
るカラー空間CSを示している。しかるに、モニタ16とモニタ18は、第２図にそれ
ぞれCG156 とCG18と示されているように、異なる色域CGをもっている。第２図に
示す情報は「国際照明委員会」(Commission International de l'Eclairage - C
IE)色度空間xyY にプロットされている。第３の次元Ｙが示されていないが、色
域は３次元オブジェクトである。グラフ48に示すように、あるカラー（例えば、
赤）のカラー・プロフィールまたは色調再現曲線TRC16 とTRC18 は、モニタ16と
モニタ18では異なっている。これらの曲線TRC16 とTRC18 は、カラーの赤をそれ
ぞれの色域CG16とCG18内で再現するとき、各モニタ16と18がどれだけ理想から離
れているかを示す尺度を表している。
グラフ46とグラフ48のそれぞれは、各デバイス14別にデータ・プロセッサ12に
ストアされているカラー・データを表している。このデータは本発明のオペレー
ティング・システム・カラー・アーキテクチャによって使用されて、以下で詳し
く説明するカラー処理を行う。従って、例えば、モニタ16はあるメーカ製で、モ
ニタ18は別のメーカ製であることがあり、あるいはモニタ16と18は同一メーカ製
の異種モデルであって、共にRGB カラー空間で動作する場合がある。しかし、各
デバイスは色域(CG)と色調再現曲線(TRC)が異なっている場合がある。第１図に
示す他の周辺デバイス14のすべてにも同じことがあてはまるが、本発明のカラー
・オペレーティング・システム・アーキテクチャは、これらの異種タイプのリア
ル・デバイスとバーチャル・デバイスのすべてについてカラー処理をサポートす
るように拡張可能になっている。
第４図に示すように、オペレーティング・システム・ソフトウェア50（第１図
にも示されている）は、入力インタフェース・モジュール52、カラー・モデル・
アーキテクチャ54および出力インタフェース・モジュール56を含んでいる。入力
インタフェース・モジュール52は、周辺デバイス14と間接的にインタフェースを
行い、カラー・モデル・アーキテクチャ54によって処理されるカラー情報を提供
する。出力インタフェース・モジュール56は、周辺デバイス14とのインタフェー
スを行い、カラー・モデル・アーキテクチャ54によって処理されたカラー情報を
周辺デバイス14へ出力する。
第５図は、オブジェクト指向プログラミング設計で実現されたカラー・アーキ
テクチャ54のクラス図である。このクラス図は、アーキテクチャ54の論理設計に
クラスが存在し、クラス間に関係があることを示している。上掲のBooch が説明
している従来のクラス図では、TColor（ブロック58）と示されているような雲形
は、クラスが明確に定義された境界をもつ抽象であることを表している。また、
矢印で示された他のアイコンはクラス間の継承関係を示している。従って、例え
ば、TXYZColor(ブロック58A)と示されているクラは、クラスTColor（ブロック58
）から継承したものであり、TSpectralColor（ブロック58Aa）と示されているク
ラスは、クラスTXYZColor(ブロック58A)から継承したものであることを示してい
る。一般的に、オブジェクト指向設計におけるクラスまたはオブジェクトは、構
造（つまり、データ）とその構造に操作を及ぼす作用(behavior)(つまり、メソ
ッド関数(method function))をカプセル化(encapsulate)している。
カラー・アーキテクチャ54は、種々のオブジェクト指向プログラミング言語の
いずれでも書くことができる。そのような言語には、Smalltalk、Ada、CLOS、Ｃ
およびC++ としてよく知られている言語がある。本明細書で説明しているアーキ
テクチャ54は、C++ 言語で書かれている。
オブジェクト指向原理に基づくアーキテクチャ54は、以下で説明するように、
いくつかの一般的プロパティ（特性）をもっている。データは抽象化され、カプ
セル化される。つまり、カラーを表しているオブジェクト、つまり、カラーを収
めているオブジェクトは、アーキテクチャ全体を変更することなく、様々な形体
で表現して、データ・フォーマットのタイプに変化をもたせることができる。オ
ブジェクトとのインタフェースは、オブジェクト自体が抽象化され、独立してい
る限り一定のままになっている。オブジェクト指向設計では、インタフェースと
は、クラスまたはオブジェクトの構造と作用を隠したまま、クラスまたはオブジ
ェクトを外側から見たものである。
さらに、以下で詳しく説明するが、基底クラスTColor（ブロック58）などの、
カラー基底クラスから派生するすべてのオブジェクトは、基底クラスと同じプロ
パティをもつことになり、基底クラスのオペレーションに関して多態(polymorph
ic)になっている。これは継承(inheritance)と呼ばれ、基底クラスから派生する
カラー・オブジェクトはいずれも、基底クラスのプロパティを継承し、基底クラ
スのインスタンス(instance)を表すために使用することができ、あ
るいは基底クラスが必要になったとき置き換えることができることを意味する。
この結果、ほとんど無制限のカラー空間を表現して、システム・アーキテクチャ
54によって使用することがきる。この場合、プログラマやユーザは、データ内容
がどのように表現されているかを正確に知っている必要がない。従って、カラー
空間とカラー・マッチングは、新しいカラー・モデルやカラー・マッチング方式
が開発されたとき拡張可能になっている。これはアーキテクチャ54がもつ特徴の
１つの例である。
さらに、上記のプロパティは、基底クラスがテンプレート・クラスで表されて
いれば、さらに単純化される。プログラミング言語C++ では、テンプレート・ク
ラス(template class)とは、同じプロパティを共有するクラス群のことである。
つまり、クラスのクラスのことである。以下では、いくつかのテンプレート・ク
ラスについて説明する。
一般的抽象クラスTColor（ブロック58）で表現されたオブジェクトを例にして
、説明することにする。ここでは、このオブジェクトの内容は、シアン(C)、マ
ゼンタ(M)、黄(Y)、黒(K)の４つのコンポーネント・ピース(component piece)で
表されているものとする。これらのコンポーネント・ピースのサイズと定義は、
オブジェクトによって保存され、そのクライアント・ユーザから見えないように
なっている。もう１つはTColorクラス・オブジェクトであり、そのコンポーネン
トはNTSC（National Television Standard Control）のYIQ 値からなっており、
これらもオブジェクト自体によって定義されている。YIQ はＴＶ規格であり、Ｙ
は明るさ(Intensity)を表し、Ｉはインフェーズ(In Phase)を表し、Ｑは量子フ
ェーズ(Quantum Phase)を表している。インタフェースのメソット関数をアクセ
スするだけで、一方のカラーを他方のカラーに追加することも（add が定義され
ている場合）、他方のカラーにマッチングすることも、あるいはコピーすること
もできる。追加、マッチングまたはコピーする３通りの方法を疑似コードで書く
と、次のようになる。
上記タイプのオペレーションが完成していて明確に定義されているのは、加算
オペレーション、つまり、クラスColor(ブロック58)にストアされているメソッ
ド関数が基底クラスColor(ブロック58)によって明確に定義されているためであ
る。この加算オペレーションがどのように基底クラスによって実行されるかとい
うと、まず、両方のカラーCMYKとYIQ が共通の周知較正カラー(この例では、XYZ
)に変換または変形される。つまり、カラーYIQ とカラーCMYKはそれぞれ、所与
の変形プロセスまたはアルゴリズム（これもメソッド関数としてクラスColor（
ブロック58）にストアしておくことができる）を用いて、共にカラーXYZ に変形
される。これらの２つのXYZ コンポーネントは次にXYZ カラー空間で加算されて
、合成カラーがXYZ 空間に得られる。最終的カラーをXYZ カラーにするのであれ
ば、所与の変形アルゴリズム（これもメソッド関数として、例えばクラスColor
にストアされている）を用いて、合成カラーXYZ から最終的カラーへの変
形はこれ以上行われずに、対応するクラスにストアされる。
さらに、アーキテクチャ54はシングル・カラー空間内のオペレーション、例え
ば、TXXXColor=TXXXColor l2+TXXXColor 2、または複数のカラー空間の間のオペ
レーション、例えば、TXXXColor=TFOOColor+TBARColor もサポートしている。シ
ングル・カラー空間内のオペレーションはそのカラー空間によって定義される。
カラー空間の間のオペレーションは較正カラー空間、例えば、XYZ へ変形するこ
とにより定義され、較正カラー空間で演算されたあと、未変形(untransformed)
にされる。
アーキテクチャ54のもう１つの一般的特徴は、カラー・クラス（較正と未較正
）はすべて基底クラスColor(ブロック58)から派生していることである。以下で
詳しく説明するが、アーキテクチャ54がオブジェクト指向原理の１つである多態
をカラーで使用できるのはそのためである。多態(polymorphism)とは、共通のサ
ブクラス、つまり、クラスColor(ブロック58)によって関係づけられている、多
数の異なるクラスのオブジェクトを名前（変数宣言など）で示すことができるよ
うにする概念である。従って、その名前で示されたどのオブジェクトも、ある種
の比較オペレーションに対していろいろな応答の仕方をすることができる。
また、第５図のクラス図に示されているカラー・アーキテクチャ54は、基本的
に２つのレベルをもっている。第１レベルはクラスColor(ブロック58とそのサブ
クラス)に示されている。すでに説明したように、クラスColor(ブロック58)は、
バーチャル抽象クラスを定義しているインタフェースであると同時に、他のカラ
ー空間への変形とカラー・マッチングのために使用されるデバイス独立または較
正カラーを収めているコンテナ・クラスでもある。これについては、以下で詳し
く説明する。アーキテクチャ54のもう１つのレベルである、第２レベルはTDevic
eColor（ブロック60とそのサブクラス）と示したクラスに示されている。このク
ラスTDeviceColor（ブロック60）は、バーチャル抽象基底クラスを定義するイン
タフェースと、デバイス依存または未較正カラー空間を収めているコンテナ・ク
ラスの働きをする。これについては、以下で詳しく説明する。各クラスColor(ブ
ロック58)とクラスTDeviceColor（ブロック60）は抽象基底クラスであるが、そ
のことは、そのサブクラスがクラス構造（データ）と作用（メンバ関
数）に加算を行うように、これらのクラスが書かれていることを意味する。
上述した一般的プロパティのほかに、カラー・アーキテクチャ54は、次のよう
な特定的プロパティを１つまたは２つ以上もっている。
１．アーキテクチャ54は、それぞれLab やHSL のように、較正または未較正のカ
ラー空間に関連してすべてのカラーを処理する。
２．アーキテクチャ54は、較正カラーに変形されたカラーを処理する。
３．すべてのカラーは、RGB カラーのような所与の未較正カラーとXYZ カラーの
ような所与の較正カラーから自らを「セット」することができる。
４．すべてのカラーは、RGB カラーのような所与の未較正カラーやXYZ カラーの
ような所与の較正カラーに自らを「セット」することができる。
５．すべてのカラーはColor から自らを「セット」することができる。
６．すべてのカラーはColor を使用して自らを作ることができる。
７．アーキテクチャ54は、どのカラーを作成／記録できるか、つまり、その色域
CGがどうなっているかを知っている周辺デバイス14ならば、どのデバイス14でも
サポートできる。
８．アーキテクチャ54は、周辺デバイス14がどれだけ理想に近いか、つまり、そ
の色調再現曲線TRC がどうなっているかを知っていれば、どのデバイス14でもサ
ポートできる。
すべてのカラーはカラー空間に関連して処理されるので、このことは、カラー
が明確に定義されていること、その空間へとその空間からの変形が存在すること
を意味している。また、すべてのカラーは較正カラーに変形され、あるいは変形
されることがあるので、カラーをある空間から別の空間へ正しく変形することが
可能である。このことは、デバイス14がそのカラーを作成できることを意味しな
い。モニタ16のように、ソースであるデバイス14のカラーが、プリンタ34のよう
に、デスティネーションであるデバイス14の色域に対して色域外にあるような場
合は、カラー・マッチング・アルゴリズムを採用することが好ましい。カラー・
マッチングは、デスティネーション色域がソース色域と等しくないか、あるいは
そこに含まれていなければ非可逆(non-reciprocal)になる。
カラー・アーキテクチャ54を使用するには、すべてのカラーがそれへまたはそ
こから変形できるカラー空間が少なくとも１つ存在している必要がある。１つの
例として、このカラー空間にXYZ カラー空間が選択されているのは、この空間が
公知の可視カラーをすべて含んでいるためである。しかし、実用面から見たとき
は、すべてのカラーをそこへとそこから変形できる１つのカラー空間にXYZ を選
択することは、必ずしも十分ではない。利用される追加のカラー空間としては、
RGB カラー空間がある。これは、公知の変形アルゴリズムを使用すると、ほとん
どすべての未較正カラーが自らをRGB カラー空間へ、そしてそこから変形できる
からである。従って、実用面から見たとき、アーキテクチャ54は、各カラーがXY
Z カラー空間を使用して自らをセットし、あるいはXYZ カラー空間から自らを得
ること、およびRGB カラー空間を使用して自らをセットし、あるいはRGB カラー
空間から自らを得ることができるように追加処理をサポートしている。
第6A図は、所与の未較正カラーからXYZ カラー空間内のカラーへの変形がアー
キテクチャ54によって行われる様子を示している。第6B図は、所与の較正カラー
からRGB カラー空間への変形がアーキテクチャ54によって行われる様子を絵で表
して示している。従って、第6A図に示すように、ColorSpace 1内の未較正カラー
は、公知の変形アルゴリズムを使用してRGB カラー空間内のRGB カラーのような
未較正カラーに変形し、次に、公知の変形アルゴリズムを使用してXYZ カラー空
間の較正XYZ カラーに変形することができる。第6B図に示すように、ColorSpace
2内の較正カラーは、公知の変形アルゴリズムを使用してXYZ カラー空間内のXY
Z カラーに変形し、次に、公知の変形アルゴリズムを使用してRGB カラー空間内
のRGB カラーに変形することができる。
さらに、本明細書で用いられている、「未較正」カラー空間という用語は、CI
E に準拠しないカラー空間に関連して用いられている。つまり、「未較正」とは
公知であるが、例えば、XYZ のような較正空間のように、明確に定義された表現
がCIE 空間にないようなカラー空間(RGB、HSV、HSL、CMY、CMYK)のことである。
これらの未較正空間のどれにおいても、上に挙げたカラーはそのソースとなった
、あるいはそれが表示（レンダリング）されるデバイス14に依存している。例え
ば、あるRGB 空間またはデバイス14からの飽和赤(saturated red)は値が1.0 に
なっていることがある。このような理由から、任意の２つの未較正カ
ラーは、たとえ同じクラスであっても、異なるカラー空間にあるものとみなされ
る。例えば、カラーＡとカラーＢが共にRGB カラーである場合、そのソースとな
るデバイス14が異なっていれば、実際には異なるカラー空間にあることがある。
本発明のアーキテクチャによれば、これらのカラー・オブジェクトは自動的に処
理されるので、これらのオブジェクトを使用するクラアイントはその源について
なにも知らなくてもよいようになっている。
次に、第５図に示す本発明のカラー・オペレーティング・システム・アーキテ
クチャ54のカラー・クラスについて簡単に説明する。インタフェースは、C++ プ
ログラミング言語で使用されている.hまたはヘッダ・ファイルに詳しく示されて
いるが、ファイル名はクラス名と同じになっている（プレフィックスの"T"は除
かれている）。MCollectible（ブロック62）
MCollectible（第５図のブロック62）と示されているクラスは、他のすべての
クラスがそれから派生している汎用オブジェクト・クラス(generic object clas
s)を定義している。これが抽象クラスであるのは、多くのサブクラスがこのクラ
ス（ブロック62）の宣言(declaration)の一部であるメソッド関数の一部または
全部を再定義（つまり、追加または変更）するからである。第５図に示すカラー
・クラスのすべては、MCollectible（ブロック62）の次のメソッド関数を正しく
働くように再定義している。
TAttribute（ブロック64）
属性(attribute)とは、ある種のオブジェクト・プロパティを特徴づけ、共用
することを意味する広義の用語である。属性を使用すると、カラーとカラー特性
を異なるタスク間で共有し、アーキテクチャ54のすべてのユーザが共用するため
にプールしておくことができる。従って、クラスTAttribute（ブロック64）は共
有プロセスを管理する基底クラスであるので、そのような共有が望ましいときア
ーキテクチャ54に組み入れておくことができる。クラスTColorGamut(ブロック66)
クラスTColorGamut（ブロック66）はクラスTAttribute（ブロック64）から派
生し、データ・プロセッサ12とのインタフェースとなっている各周辺デバイス14
の色域CG情報をストアしている。前述したように、色域は一方の周辺デバイス（
例えば、モニタ16）のカラーを他方の周辺デバイス（例えば、プリンタ30）へ変
換するために使用される。カラーが色域を用いて変換されても、その変形が色域
内のものであるとの保証は得られない。カラーが色域内のものであることを確か
めるには、所与のカラー・マッチング・アルゴリズムが使用できる。マッチング
・アルゴリズムを実行するカラー・マッチング・メソッド関数はクラスTColorPr
ofile(下述するブロック68)に収められている。
較正カラー空間XYZ の色域CGは、XYZ 空間内に８個のXYZ 点によって定義され
ている。これらはシアン、緑、黄、赤、マゼンタ、青、黒、および白である。一
般的に、各周辺デバイス14（カラー・プリンタ、カラー・スキャナ、カラー・モ
ニタなど）は、例えば第２図に示すような独自の色域をもち、この色域情報はデ
バイス・メーカによって指定されているはずである。クラスTColorGamut(ブロッ
ク66)は２つのコントラクタ(contractor)をストアしている。１つはヌル・コン
トラクタ(null contractor)であり、これは、例えばApple Computer，Inc.(Cupe
rtino，California)製の13”Apple RGB モニタを定義している。もう１つはファ
イル・コントラクタ(file contractor)であり、これは色域CGを収めてい
るファイル名をその引数として受け取る。（コントラクタはオブジェクトの作成
および／またはそのステートの初期化を行うメソッド関数である。）
クラスTColorGamut(ブロック66)は、プログラマがこの色域情報をストアして
おくためのヘッダ（.hファイルと呼ばれる）を書くのを支援するテンプレート(t
emplate)を収めている。新しい周辺デバイス14をデータ・プロセッサ12に追加す
るとき、以下で説明するように、このテンプレートを使用すると、その独自の色
域データをクラスTColorGamut(ブロック66)に追加することができる。TColorProfile(ブロック68)
クラスTColorProfile(ブロック68)はクラスColorGamut（ブロック66）から派
生し、プロセッサ12に追加された各周辺デバイス14のカラー・プロフィール・デ
ータをストアしている。さらに、クラスTColorProfile(ブロック66)はクラスTCo
lorMatcher(ブロック70)(カラー・マッチングと関連づけて以下で詳しく説明す
る)から所与のカラー・マッチャ・アルゴリズムを「取得」して、一種類または
数種類のカラー・マッチング・アルゴリズム（これらはクラスTColorGamut(ブロ
ック66)の色域CG情報とクラスTColorProfiles（ブロック68）のカラー・プロフ
ィール情報を使用していたものである）を実行するようなメカニズムになってい
る。クラスTColorProfile(ブロック68)は、新しい周辺デバイス14がデータ・プ
ロセッサ12に接続されたときそのカラー・プロフィール情報をストアしておくた
めのヘッダ・ファイルを、プログラマが書くのを支援するテンプレートを収めて
いる。クラスTColorProfile(ブロック68)から派生したクラスTAppleColorProfil
e（ブロック72）も第５図に示されている（カラー・マッチングと関連づけて以
下で詳しく説明する）
一例として、所与の周辺デバイス14のカラー・プロフィールは、７つのカラー
（シアン、緑、黄、赤、マゼンタ、青、黒）のそれぞれに対する７つの色調再現
曲線(TRC)からなっている。言い換えれば、説明の便宜上、第３図には、２種類
の周辺デバイス14のカラー赤だけのTRCが示されているが、クラスTColorProfile
(ブロック68)はそれぞれの周辺デバイス14別に７つのTRC をスト
アしている。各デバイス別のTRC は試験的に、さらに、デバイス14のメーカ指定
の色域情報の場合と同様に、TColorProfile(ブロック68)にストアされているTRC
曲線に対応するTRC データを使用して測定することが可能である。別の例とし
て、デバイス16のようなカラー・モニタの場合は、TRC をガンマ修正曲線(gamma
correction curve)と呼ばれる単一の曲線にすることを、デフォルトにすること
も可能である。
クラスTColorProfile(ブロツク68)は２つのコンストラクタ(constructor)もス
トアしている。１つのコンストラクタはは、Apple Computer，Inc.製の13”RGB
モニタのカラー・プロフィールといったように、所与の周辺デバイス14のカラー
・プロフィールを定義しているヌル・コンストラクタ(null constructor)であり
、もう１つのコンストラクタはカラー・プロフィールを収めているファイル名を
その引数として受け取るファイル・コンストラクタ(file constructor)である。クラスColor(ブロック58)
上述したように、クラスColor(ブロック58)はアーキテクチャ54の１レベルを
構成し、バーチャル抽象基底クラスを定義しているインタフェースであり、較正
カラーのコンテナ・クラスでもある。カラー・アーキテクチャ54では、所与のカ
ラーは未較正RGB カラー（デバイス依存）および／または較正XYZ カラー（デバ
イス独立）に変形できるので、クラスColor(ブロック58)は次に示すように、少
なくとも３つの純粋バーチャル・メンバ関数をもっている。
これらのメソッド関数は、クラスColor(ブロック58)から発生したすべてのカラ
ー・クラスがオブジェクト指向設計原理に準拠するこの機能をサポートするよ
うに保証する。また、クラスColor(ブロック58)は所与のカラーのコンポーネン
トのためのフィールドをもっている。XYZ カラーのフィールド・コンポーネント
は、浮動点(floating points)がとる値のすべてをとることができる三刺激値座
標(Tristimulus Coord)タイプになっている。RGB カラーのフィールド・コンポ
ーネントは0.0から1.0までの範囲の輝度(Intensity)タイプになっている。さら
に、クラスColor(ブロック58)は不透明(opacity)フィールドをもつこともできる
。その場合、不透明値が1.0のときは、カラーが純粋に不透明であることを意味
し、不透明値が0.0のときは、カラーが透明であることを意味する。クラスTXYZColor(ブロック58A)
クラスTXYZColor(ブロック58A)はクラスColor(ブロック58)から派生している
。クラスColor(ブロック58)から派生するすべてのカラーは、以下で詳しく説明
するように、本発明のアーキテクチャ54によれば、そのカラー自身を較正XYZ カ
ラーに変換または変形することができる。クラスTSpectralColor(ブロック58Aa)
クラスTSpectralColor（ブロック58Aa）はクラスTXYZColor(ブロック58A)から
派生している。TSpectralColorクラスは、第７図に示すように、３つの積分方程
式(1),(2)および(3)で表されている公知の３つのCIE カラー・マッチング関数を
使用するメソッド関数をストアしている。それぞれの方程式において、xxx はマ
ッチングされるカラーのスペクトル・エネルギ分布(spectral energy distribut
ion)であり、X(u),Y(u)およびZ(u)は実験で求めたカラー・マッチング関数であ
る。これらの関数は、上で引用した文献に記載されているように、視界が２度の
ときのCIE 1931標準表色観測者(Standard Calorimetric Observer)のカラー・マ
ッチング・プロパティを定義している。従って、クラスTSpectralColor（ブロッ
ク58Aa）のCIE カラー・マッチング・メンバ関数は加重関数(weighting functio
n)として使用されるので、第７図の例でグラフで
示すように、Ｘ，ＹおよびＺの原色をスペクトル・パワー・データ(spectral po
wer data)から得てスペクトル情報からXYZ を計算することができる。クラスTSp
ectralColor（ブロック58Aa）は第７図に示す３つのCIE スペクトル・カラー・
マッチング・パワー曲線Ｘ，ＹおよびＺを、このクラスのためにヌル・コンスト
ラクタによって初期化される静的配列(static array)としてストアしている。クラスTLabColor(ブロック58B)
クラスTLabColor(ブロック58B)はクラスColor(ブロック58)から派生している
。TLabColor は均等三刺激値デバイス較正カラー空間を定義しているクラスであ
り、その値もCIE によって国際的に標準化されている。次元（ａとｂ）の２つは
均等色度図上の座標である。Ｌは明度指数(psychometric lightness)である。TL
abColor クラス(ブロック58B)は、カラーを知覚可能な線形的にそして、カラー
間の知覚可能距離を表わす。TLabColor クラスは、基準白色(reference white c
olor)を定義するために使用される３つの静的フィールドをもっている。基準白
色を使用すると、TLabColor をTXYZColor へ変形することができる。デフォルト
は基準白色である。このクラスTLabColor(ブロック58B)のメンバ関数は明度(lig
htness)、クロマ(choroma)、彩度(saturation)および色差(colordifference)の
相関付けを行う。クラスTLuvColor(ブロック58C)
クラスTLuvColor(ブロック58C)はクラスColor(ブロック58)から派生している
。TLuvColor も均等三刺激値デバイス較正カラー空間を定義しているクラスであ
り、その値はCIE によって国際的に標準化されている。次元（ｕとｖ）の２つは
均等色度図上の座標である。Ｌは明度指数(psychometric lightness)である。TL
uvColor クラスはカラーを知覚可能な線形的に表すために使用され、カラー間の
知覚可能距離はカラー間の幾何学的距離に比例している。TLuvColor
クラス(ブロック58C)は、基準白色(reference white color)を定義するために使
用される３つの静的フィールドをもち、基準白色は使TLuvColor をTXYZColor へ
変形するために使用される。デフォルトは基準白色である。このクラスTLuvColo
r(ブロック58C)のメンバ関数は明度(lightness)、クロマ(choroma)、彩度(satur
ation)および色差(color difference)相関付けを行う。
産業用カラー測定機器のような周辺デバイス14は、CIE カラー系（較正系）を
使用している。このCIE 系によると、入力デバイスや出力デバイスから独立した
形で、カラーを光源、オブジェクトおよび観察者からとらえて指定することがで
きる。従って、アーキテクチャ54は、ユーザがそれを望むならば、カラーをユニ
ークに定義している三刺激値XYZ をカラーLab 座標またはカラーLUV 座標に変形
する。Lab 座標は反射光で表示されるデバイス14の場合に使用できるのに対し、
LUV 座標は光源のような自己発光周辺デバイス14の場合に使用できる。クラスTxyYColor(ブロック58D)
クラスTxyYColor(ブロック58D)はクラスColor(ブロック58)から派生している
。カラー空間xyY はクラスTXYZCOLOR(ブロック58A)のカラー空間XYZ から派生す
ることができる。空間XYZ と空間xyY 間の変形は以下に説明するとおりである。
カラー変換とその基礎になる数学の詳しい説明は、Wyszecki他共著「カラー科学
：概念と方法、数量的データと公式」(Color Science: Concepts and Methods，
Quantitative Data and Formulae)(John Wiley and Sons，1982)に記載されてい
る。
XYZ からxyY への変形：
xyY からXYZ への変形：
クラスTDeviceColor（ブロック60）
クラスTDeviceColor（ブロック60）はクラスColor(ブロック58)から派生し、
上述したように、２レベル・アーキテクチャ54のもう１つのレベルを構成してい
る。クラスTDeviceColor（ブロック60）はバーチャル抽象基底クラスを定義して
いるインタフェースであり、アーキテクチャ54における未較正カラーのコンテナ
・クラスでもある。TDeviceColorはクラスTColorGamut(ブロック66)へのconstru
ct 参照を収めている。このクラスは少なくとも３つの純粋バーチャル・メンバ
関数をもち、すべてのデバイス依存カラーまたは未較正カラーがクラスTRGBColo
r (ブロック60A)の未較正RGB カラー（下述する）とクラスTXYColor(ブロック5
8A)の較正XYZ カラーの両方に変換または変形できるようになっている。これら
のメンバ関数は次のとおりである。
これらのメンバ関数は、TDeviceColor（ブロック60）から派生したすべてのカラ
ー・クラスがこの機能をサポートするように保証する。前述したように、変形を
行うためには、カラーが定義される対象の特定デバイス14に依存する色域CGは分
かっていて、クラスTColorGamut(ブロック68)にストアされていなければならな
い。クラスTRGBColor(ブロック60A)
クラスTRGBColor(ブロック6OA)はクラスTDeviceColor（ブロック60）から派生
している。TRGBColor クラスは、赤(R)、緑(G)および青(B)のカラー・モデルに
基づいてデカルト座標(Cartesian coordinate)を定義している。これらの三原色
は加法混色であり、大部分のカラー・モニタとカラー・ラスタ・グラフィック・
システム用に使用されている。RGB 三原色の値は0.0 - 1.O(原色)の範囲にして
おくべきである。このクラスのメンバ関数はRBG 三原色をこの範囲にクランプす
るためのものである。RGB カラー空間は未較正である。従って、RGB カラーはそ
の色域CGを通して特定のカラー・デバイス14に対して定義されていなければなら
ない。クラスTCMYKColor（ブロック60B）
クラスTCMYKColor(ブロック60B)はクラスTDeviceColor（ブロック60）から派
生している。TCMYKColorクラスはシアン(C)、マゼンタ(N)、黄(Y)、および黒(K)
のカラー空間を定義しており、これらはプリンタ36などの大部分のカラー・ハー
ドコピー・デバイス用に使用されている減法混色の原色である。CMYK値は、まず
カラーに存在するCMYK値を求めることにより計算される。カラーに存在する黒の
量はK=minimum(CX,M,Y)の関係式から求められる。次に、CMYK値からK を引くと
、CMYK値が定まる。この手法は下色除去(under color removal)と呼ばれ、この
手法によると、３カラーではなく４カラーで印刷するので、ハードコピー・カラ
ー・デバイスから得られる出力品質が向上する。四原色CYMKの値は、0.0 - 1.0
の範囲に拘束されている。クラスTCMYKColor(ブロック60B)はCMYK原色をこの範
囲にクランプするメンバ関数を収めている。CMYKカラー・モデルは未較正である
ので、CMYKカラーは、プリンタ36などの特定のカラー・デバイス14の色域CGに対
して定義される。クラスTHSLColor(ブロック60C)
クラスTHSLColor(ブロック60C)はクラスTDeviceColor（ブロック60）から派生
し、公知のカラー・モデルHSL を定義している。色相(H) 、明度(L) 、および彩
度(S) カラー・モデルは、上記の文献に示されているように、３次元空間に二重
六角円錐(double-hexcone)によって定義されている。色相はＬ軸を中心とする角
度によって測定される。赤はH=0.0 で現れる。円周を反時計方向に通過していく
と、赤、黄、シアン、青、およびマゼンタが得られる。補色はＨ値に180 度を加
えると得られる。彩度は垂直軸から半径方向に測定され、その範囲は0.0 - 1.0
である。明度は黒を表す0 （二重六角円錐の底辺）から1.0 （円錐の上辺）まで
である。HSL カラー・モデルは未較正カラー空間であるので、HSL カラーは、ク
ラスColorGamut（ブロック66）にストアされているその色域CGを通して特定のカ
ラー周辺デバイス14に対して定義される。クラスTGrayColor（ブロック60E）
クラスTGray(ブロック60E)はクラスTDeviceColor（ブロック60）から派生して
いる。TGrayColorクラスはグレースケール・モデルを定義しており、このモデル
では、グレーの値は0.0 - 1.0 の範囲に拘束することができる。このクラスはグ
レー値をこの範囲にクランプするメンバ関数を収めている。グレースケール・カ
ラー・モデルは未較正であるので、グレー・カラーは特定のカラー周辺デバイス
14の色域CGに対して定義される。新しいカラー・クラスの追加
アーキテクチャ54の拡張性の一部として、新しいカラー・モデルが開発された
とき追加のカラー・クラスを追加することができる。例えば、新しい較正カラー
空間 ABCが開発されたとする。この較正カラー空間ABC 内にカラーを表すために
は、新しいカラー・クラスTNewCalColor(この例では、TABColor)(第５図に点線
で示されている)が定義されており、これはクラスColor(ブロック58)から派生し
、継承している。この新クラスTNewCalColorのメソッド関数はクラス定義の一部
としてプログラマが書くことにより、カラーABC をXYZ カラー空間およびクラス
Color(ブロック58)から提供される他のカラー空間との間で変形することができ
る。
１つの具体例として、Tektronix Corp.(Beaverton,Oregon)は較正カラー空間H
VC と、この空間を他の空間へ変形するための変換メソッドを開発している。こ
のカラー空間HVC は、クラスColor(ブロック58)から派生するクラス THVCColor
（図示せず）を定義し、公表されている上記変換または変形をこのクラス定義の
一部として用意しておけば、アーキテクチャ54の拡張性により簡単に取り入れる
ことができる。カラー変形はアーキテクチャ54に追加される較正カラー空間によ
って定義され、これはColor 基底クラス・オブジェクトとしてアーキテクチャ54
の他の部分とのインタフェースとなっている。同じように、新しい未較正カラー
空間が開発されたときも、クラスTDeviceColor（ブロック60）から派生し継承す
るクラス TNewDeviceColor（第５図に点線で示されている）を定義することによ
り追加することができる。
以上、第５図に示すクラスColor(ブロック58)とクラス(ブロック60A)のメソッ
ド関数について説明してきたが、以下ではもっと詳しく説明する。クラスColor(ブロック58)
Get
不透明フィールドの値が返却されるだけである。
各サブクラスはこのメソッド関数をオーバライド(override)することができ
る。各サブクラスはXYZColorを自身のために得る方法を知っている必要がある。
これらのメソッド関数は効率化のためにクラスColor(ブロック58)にストアされ
ており、サブクラスはそのどれでもオーバライド(override)することができる。
クラスColor(ブロック58)から派生するカラー空間サブクラスの各々は、自身の
クラス内のメソッド関数をオーバライドするようにしておくべきである。例えば
、クラスTHSVColor(ブロック58D)はクラスColor(ブロック58)にストアされてい
るGetHSVColor をオーバライドすれば、較正XYZ への中間変換が回避さられるの
で変換時間が節約される。
このメソッド関数は、XYZ カラー空間への中間変形を用いて常に”get”する。
従って、このメソッド関数が使用されるのは、カラーがRGB のように同じカラー
空間にあるが、異なる色域CGをもっている場合である。
Return
これらのメソッド関数は効率化のためにクラスColor(ブロック58)にストアされ
ているが、サブクラスはそのどれでもオーバライドすることができる。クラスCo
lor(ブロック58)から派生するカラー空間サブクラスの各々は、自身のクラス内
のメソッド関数をオーバライドすることができる。例えば、クラスTHSVColor(ブ
ロック60D)が、クラスColor(ブロック58)にストアされているReturnHSVColorを
オーバライドすれば、XYZ への中間変換を回避することができる。
インデックス(Index)
このメソッド関数は最も近く一致したものをcolorlist から探し出す。サブクラ
スはこのメソッド関数をオーバライドして、特定ブランドのColor サブクラスを
受け取るTColorListメソッドを呼び出す(invoke)ことができる。
Set
各サブクラスがこのメソッド関数をオーバライドすることができるのは、各カラ
ーがXYZColorを使用して自身をセットする方法を知っているからである。
このメソッド関数は多態のための使用される。各カラーはColor を使用して自身
を多態的(polymorphically)に「セット」できるようにしておくべきである。Set
Colorをオーバライドするとき、クライアントは、カラーを使用して同等のXYZ
を取得し、次に、その同等のXYZ を独自のフォーマットに変換し（その方法はす
でに分かっている）、それに応じて独自のデータ・フィールドをセットする。
効率化のために、クラスColor(ブロック58)のサブクラスはこれらのどれでもオ
ーバライドすることができる。例えば、THLSColor(ブロック6OC)はSetWithHLSCo
lor をオーバライドすると、カラーXYZ への中間変換を回避することができる。TRGBColor クラス（ブロック60A）
クラスTRGBColor(ブロック60A)は代表的なデバイス依存カラー・クラスを表し
ており、以下に説明するメソッド関数をストアしている。
コンストラクタ
以下では、クラス・コンストラクタについて説明する。これらがアーキテクチ
ャ54を書いたコードの中でコールされると、TRGBColor オブジェクトの新しいイ
ンスタンスを作成する。
このコンストラクタはヌル・コンストラクタである。「ヌル」とは、RGB カラー
を作るためにコンストラクタが引数を必要としないことを意味し、これは２つの
分岐をもっている。カラー内のフィールドはすべてfRed =fGreen = fBlue = O、f
Opacity = 1.0にセットされ、使用される色域CGもヌルになっている（クラスTCo
lorGamut の説明個所のコンストラクタを参照のこと）。
これらのコンストラクタを使用すると、LabColorなどの任意の較正カラーまたは
任意の未較正TDeviceColorからRGBColorを多態的に作成することができ
る。未較正カラーがこの構築(construction)で使用されていれば、RGBVColorは
そのフィールド(fRed...fOpacity)が周辺デバイス16のカラー空間などのaDevice
ColorSpace からRGB カラー空間へ変形される。RGBColorはaDeviceColorの色域C
Gを継承する。他方、Lab のようなColor がこの構築で使用されていれば、RGBCo
lorはフィールドが上記のように変形されて終了し、ヌル色域が新しいカラーに
割り当てられる。これらのコンストラクタは、次のようにタイプ・キャスト(typ
e casting)でも使用される。
このコンストラクタがコピー・コンストラクタであるのは、aRGBColor から新し
いRGBColorオブジェクトを作成するためである。作成されたオブジェクトはaRGB
Color と同じフィールドと色域CGをもっている。
新しいカラーの中のフィールドはすべてfRed = fGreen = fBlue = 0，fOpacity
= 1.0にセットされ、色域CGはDeviceColorGamutにセットされる。
新しいカラーの中のフィールドはすべてfRed = Red，fGreen = Green，fBlue =
Blueにセットされる。不透明は、値の指定がなければ1.0 にセットされ、値の指
定があればその値にセットされる。色域CGはヌル色域にセットされる。
新しいカラーの中のフィールドはすべてfRed = Red，fGreen = Green,fBlue =
B1ueにセットされる。Opacity は、値の指定がなければ1.0 にセットされ、値の
指定があればその値にセットされる。色域CGはDeviceColorGamutにセットされる
。
Get
get は、その名前が意味するように、特定のカラー・オブジェクトをカラー・オ
ブジェクトから取得する。例えば、メンバ関数GetXYZColor はRGBColorオブジェ
クトへの必要な変形を行ってaXYZColor を返却する。
GetComponents はオブジェクトからコンポーネント値を読み取って、それらを変
数Red、Green、Blue、およびOpacity に入れて返却するだけである。
Return
returnRGBColorはRGBColorオブジェクトを正確にコピーしたもの、つまり、
フィールドと色域を返却する。
Set
各SetWith は、その名前が意味するように、特定のカラー・オブジェクトからの
RGB カラー・オブジェクトをセットする。例えば、メンバ関数SetWithXYZColor
はXYZColorからRGBColorを作るために必要な変形を行い、そのカラーを使用して
RGBColor値をセットする。色域CGは、この特性ケースに限り、ヌル色域にセット
される。
これらは単純セットである。引き渡される値はオブジェクト値をセットするため
に使用される。
SetColorは、RGB カラーが任意のタイプのカラーから多態的にセットできるよう
に定義されている。
RGBColorの数学計算
これらのメソッド関数はC++ における標準演算子をオーバライドして、RGB カ
ラー用に正しく定義されるようにする。論理演算子は、不透明を含むColor1とCo
lor2の各フィールド・コンポーネントで条件が満足されるとその場合に限り、TR
UEを返却する。残りの演算子は、不透明を除く個別フィールド・コンポーネント
ごとにそこに記述されている数学関数を実行する。
カラーを使用した作業例
このセクションでは、アーキテクチャ54でカラーを使用する例をいくつか挙げ
て説明する。これらの例の大部分では、デバイス依存または未較正カラーではRG
BColorが使用され、デバイス独立または較正カラーではXYZColorが使用されてい
る。NullGamut とNullProfile は、前述したように、Apple Computer，Inc.製の
標準13”カラー・モニタの色域とプロフィールになるように定義することが可能
である。
RGBColorのフィールド・コンポーネントRGB は、前述したように、0.0 - 1.0
の範囲を意味するGIntensityタイプになっている。しかし、この制約は厳格に適
用する必要はない。従って、カラー、特に異なる色域をもつカラーで変形を行う
とき、フィールド・コンポーネント値をこの範囲外にすることも可能である。
カラーの作成例
以下は６つのコンストラクタの例である。これらをコールすると、オブジェク
トのstate は次のようになっている。
この構築では、次のような等価のプロセスが行われる。これはデバイス依存カ
ラーであるので、色域CGをもっている。さらに、すべてのカラーは自身からRGB
カラーを得る方法を知っている。
従って、次のようになる。
Set とGet の例
このセクションでは、set とget のいくつかを使用してカラーを取り扱う方法
について説明する。以下の例では、次のようなカラーが定義されるとする。
RGBColorでXYZColorをセットする
これにより、カラーaXYZColor は、NullGamut をもつaRGBColor1に対応する正
しいXYZ 値をもつことになる。次に、次のものが実行されると、
aRGBColor2のステートは次のようになる。
次のものが実行された場合：
別のRGBColorからRGBColoｒを得る
次のものが実行されると、
aRGBColorGamut2 のステートは次のようになる。
カラーで単純数学計算を使用する例
アーキテクチャ54では、カラー・クラスのすべてには、強力な単純数学計算セ
ットが定義されている。以下に示す例では、次のようなXYZ カラーが定義されて
いる。
論理演算では、カラーの各個別フィールドは、式がTRUEと評価されるためには
論理条件を満足していなければならない。従って、次のようになる。
加算演算(sum operation)前のaXYZColor3が次のようになっていれば、
加算演算後のaXYZColor3は次のようになる。
カラーの不透明は数学計算には組み入れられない。
減算演算前のaXYZColor3が次のようになっていれば、
減算演算後のaXYZColor3は次のようになる。
乗算演算前のaXYZColor3が次のようになっていれば、
乗算演算後のaXYZColor3は次のようになる。
除算演算前のaXYZColor3が次のようになっていれば、
除算後のaXYZColor3は次のようになる。
カラーで多態を使用する例
カラー・クラスはすべて基底クラス Color（ブロック58）から派生している。
TColors を引数として受け取る多態関数(polymorphic function)とメソッド関数
を書くことが可能である。以下に示す例は、その使い方を示したものである。カラー間の色相差の判断
以下に説明するメソッド関数は２つのTColors を入力として受け取り、これら
のカラー間の色相差を返却する。色相差とは、Lab カラー空間またはLuv カラー
空間の正確に定義された量である。下に示す例はLub ベースの定義を使用してい
る。
明るさの相関の判断
もう１つは、カラーの明るさの相関を計算する例である。
個別カラーのカラー・マッチング
一般的に、カラー・マッチングは、較正または未較正である、ある種のカラー
空間に表されている内部カラーが、特定のデバイス上の特定のカラーを近似的に
表している別のカラー空間（未較正であるのが通常）に変形されるとき行われる
。逆の場合も同じである。本発明のアーキテクチャ54では、カラー・マッチング
・プロセスまたは関数は、カラー・マッチング基底クラスTColorMatcher(ブロッ
ク70)に組み込まれており、これは、クラスTDeviceColor（ブロック60）から派
生するすべての未較正オブジェクトの中で内部的に、デバイス・カラー・クラス
・オブジェクト内のTCColorProfile（ブロック68）参照を通してアクセスされる
。つまり、そのような参照が行われると、TColorProfile(ブロック68)を通して
、クラスTColorMatcher(ブロック70)内のカラー・マッチャ・コンテナが
「取得」(get)される。カラー・マッチャが使用できるサンプル・プロフィール
は、第５図にクラスTAppleColorProfile（ブロック72）として示されている。
本発明のアーキテクチャ54では、ある特定のカラー・マッチング・アルゴリズ
ムを別のアルゴリズムに対して指定していない。共通のインターチェンジ・アプ
リケーション・プログラマ・インタフェース("API")を使用すると、プログラマ
は任意のカラー・マッチング・プロセスをクラスTColorMatcher(ブロック70)に
ドロップすることも、ストアしておくこともできる。その結果、アーキテクチャ
54では、どのカラー・マッチング・メカニズムでも取り入れることが可能である
。クラスTColorMatcher(ブロック70)のカラー・マッチャは、所与のカラーに含
まれる色域とカラー・プロフィールを自由に使用して、カラー・マッチングを行
うことができる。アーキテクチャ54の中にドロップされたクライアント提供のカ
ラー・マッチャは、システム・デフォルト・カラー・プロフィールが存在すれば
、それを解釈し、クライアント提供のカラー・プロフィールが存在するときは、
その中の非公開情報を解釈することができる。
第８図は、本発明のアーキテクチャ54を使用すると、個々のカラーが複数の周
辺デバイス14の間でどのようにしてカラー・マッチングされるかを、図解してい
る図である。一例として示した周辺デバイス14としては、RGB のようなColor カ
ラー空間で入力またはソース・デバイスとして動作するフラットベッド・スキャ
ナ22などのカラー・デバイス14およびCYMKのようなColor カラー空間で出力また
はデスティネーション・デバイスとして動作するプリンタ36などのカラー・デバ
イス14がある。第８図には、データ構造としてクラスTColorProfile(ブロック68
)にストアされているスキャナ色調再現曲線TRC22、データ構造としてクラスTCol
orGamut(ブロック66)にストアされているスキャナ色域CG22、データ構造として
クラスTColorGamut(ブロック66)にストアされているプリンタ色域CG36、および
データ構造としてクラスTColorProfile(ブロック68)にストアされているプリン
タ逆色調再現曲線TRC36 も示されている。また、第８図には、データ構造として
クラスTColorGamut(ブロック66)にストアされているカラー空間XYZ およびスキ
ャナ22のRGB カラー空間とプリンタ36のCYMKカラー空間の間のカラー・マッチン
グを行うクラスTColorMatcher(ブロック70)のカラー・マッチャも示されて
いる。
一般的には、第８図に示すように、色域とプロフィール情報をアーキテクチャ
54にストアすることによりプロセッサ12が初期化されると、このようなカラー情
報のソースとして働くスキャナ22からの生カラー・データがデータ・プロセッサ
12に入力される。次に、アーキテクチャ54は、色調再現曲線TRC22 を用いて生RG
B データを修正するためにクラスTColorProfile(ブロック68)を使用する。次に
、アーキテクチャは修正したRGB カラー・データを、クラスTColorGamut(ブロッ
ク66)の色域CG22と該当のメソッド関数をコールすることによってXYZ カラー空
間に変形する。次に、クラスTColorMatcher(ブロック70)のカラー・マッチャを
取得するためにクラスTColorProfile がコールされて、クラスRGB カラー・デバ
イス22に対応するXYZ カラーが、プリンタ36のCYMKカラーに対応するXYZ カラー
空間内のカラーとカラー・マッチングされる。マッチングされたXYZ カラーは次
に、色域CG36を用いてCYMKカラーに変形され、次に、カラー・マッチングされた
CYMKカラーは、クラスTColorProfile(ブロック68)の色調再現曲線TRC36 をコー
ルし、それを用いてプリディストート(predistort)される。このプリディストー
トされたカラー・データは次にプリンタ36へ転送されて、カラー・マッチングさ
れたCYMKカラーで印刷されることになる。以上のように、本発明のアーキテクチ
ャの特徴によれば、どの周辺デバイス14でもプロセッサ12に追加することができ
、他のどの周辺デバイス14ともカラー・マッチングすることができる。
カラーの処理は、カラーのマッチングを含めて、上述した通りである。本発明
の原理は、イメージが個々のカラーではなく、３カラー・イメージに代表例を示
すようにカラー群または集合からなるような、カラー・イメージの処理に拡張す
ることが可能である。例えば、イメージ中の各個別カラー・ピクセルは、上述し
たカラー・マッチング・プロセスを用いて変形することが可能である。処理速度
を最適化するために、カラー・マッチング・プロセスは入力ピクセル・ストリー
ム（あるカラー・クラス・フォーマットで）を出力し、出力ピクセル・ストリー
ム（別のクラス・フォーマットで）を返却することができる。
好適実施例では、カラー・マッチングは３タイプのものが用意されている。(1) 測色(Colorimetric)
−これはスペクトル色度と相対ルミナンスを等しくする
ものである。(2) 外観(Appearance)−これはソース色域をデスティネーション色
域に変形して、カラーまたはイメージが正しい外観になるようにするものである
。(3) 正確(Exact)−これは色度と絶対ルミナンスを等しくするものである。外
観カラー・マッチングは３種類のカラー・マッチングの中で最も主観的である。
カラー・マッチングは２レベルのどちらかで行うことができる。TColorレベル
は通常スポット・カラー(spot color)の場合に使用されるのに対し、TGImage レ
ベルは通常イメージの場合に使用される。カラー・マッチングがどのように、ど
こで行われるかは、かなり複雑なプロセスである。第９図、第10図および第11図
は、カラー・マッチングを行うときの制御の流れを示している。第９図は、好適
実施例による代表的な構成を示している。処理はドキュメントがスキャナ900 を
通って走査されるとき開始される。走査された情報は機能ブロック910 で修正さ
れ、機能ブロック920 でXYZ グラフィック空間に変換される。次に、カラー・マ
ッチャはその情報を、プリンタ960 が認識できる情報に変形する。変形された情
報はデバイス空間940 にストアされデバイス修正機能ブロック950 で修正されて
から、プリンタ960 から出力される。スポット・カラー・マッチングは幾何学的
レンダリング(geometry rendering)で行われるのに対し、イメージのそれはRend
erImage で行われる。幸いなことに、新しいカラー・マッチングの使用または準
備は容易であり単純化されている。第12図は、好適実施例に従ってカラー・マッ
チングをオーバライドする２つの方法を示している。デフォルトCase(0)はデフ
ォルト・カラー・マッチングのオーバライド化がとられなかったとき、どのよう
な処理が行われるかを示している。オーバライドが存在しなければ、正確なカラ
ー外観またはカラー・メトリック・カラー・マッチングが行われる。独立ソフト
ウェア・ベンダ(IndependentSoftware Vendor - ISV)がデフォルト・カラー・マ
ッチャCase(1) をオーバライドしていれば、ISV 提供のカラー・マッチャはデフ
ォルトColorProfileを使用する。ISV がColorMatcherとColorProfileを提供して
いれば、処理はCase(2) に示すように行われる。
Booch カラー・クラス図は第13図に示されている。好適実施例でのカラー・ク
ラスは実世界でのカラー空間に対応している。各カラー・クラスは、第13図に示
すように、そのカラー自身を、RGB カラーとXYZ カラーに変換し、そしてそのカ
ラーから変換する方法を知っている。第13図に示すように、TColorから直接に派
生するカラーは較正カラーである。このことは、カラーのコンポーネント値が分
かっていれば、そのカラーは絶対的に分かっていることを意味する。較正カラー
の例として、XYZColorがある。
第９図に示すスキャナ900 やプリンタ960 のような入出力カラー・ハードウェ
ア・デバイスは、人間の視覚系が知覚できるカラーのサブセットしか出力しない
ので、内在的欠陥をもっている。実世界のデバイスから入出力されるDeviceColo
r のカラーは、ある種の追加情報がカラーと関連づけられていなければ、一般的
に較正されていない。好適実施例では、この追加情報はデバイスのColorProfile
と呼ばれている。カラー・プロフィールの例は第13図に示されている。
イメージ処理
イメージ処理の場合は、カラー・マッチングは個々のカラー間ではなくTGImag
es間で行われる。イメージのプリミティブはTGImage である。カラーと同様に、
TGImage はカラー・プロフィールへの参照をもっている。第14図は、好適実施例
による２つのカラー・プロフィールColorGamutとColorProfileを示している。
カラー・マッチングの活動化
ユーザはカラー・マッチングをコントロール・パネル・レベルでオン、オフす
ることができる。カラー・マッチングが活動化されると、ユーザはオペレーティ
ング・システムに用意されているデフォルト・カラー・マッチャ（測色、外観、
正確）から１つを選択することができる。アプリケーション・レベルでは、デフ
ォルト・カラー・マッチャは下述するように、マッチャを作成し、
SceneBundle にそのマッチャを採用させることによりオーバライドすることがで
きる。そのあと、システムはどのタイプのカラー・マッチングを使用するかを制
御する。
さらに、アプリケーションは、デフォルト・デバイス以外の各デバイス用に使
用するカラー・プロフィールを、ユーザが選択できるようになっていなければな
らない。
色域とカラー・プロフィール
第14図は、好適実施例によるカラー・プロフィールであり、データが図形化さ
れて示されている。各デバイス・カラーとイメージはカラー・プロフィールへの
参照をもっている。カラー・プロフィールはデバイスからどのカラーが出力／入
力できるか(ColorGamut)、そのデバイスからこれらのカラーがどれだけ正確に出
力できるか（色調再現曲線）を定義している。カラー・プロフィールは、デバイ
スを記述する他に、XYZ カラーとRGB カラー間の変換と逆変換に関するイネーブ
ル情報も含んでいなければならない。このことが重要であるのは、デフォルト・
カラー・マッチングのオーバライドを望んでいるアプリケーションは、カラー・
デバイス用に独自のカラー・プロフィールを用意しなければならないからである
。カラー・マッチングは重要であるが、これは既存のカラー・アキテクチャと矛
盾しないように行わなければならない。
オペレーティング・システムのColorProfileのオーバライド
第15図は、好適実施例に従ってカラー・プロフィールを別のアプリケーション
へ提供するために、クラスTColorProfile からサブクラス化するオペレーション
を示す図である。TColorProfile からサブクラス化すると、サブクラス化された
ColorMatcherが理解不能のカラー・プロフィールを見つけたとき、許容できるデ
フォルト作用が保証される。このために、オーバライドされたプロフィールが大
きくなっても、STANDARDカラー・プロフィールが小さいのでそれ程には大きくな
らない。 ここで説明しているTColorProfile で重要なメソッドを示すと、次の
ものがある。
ConvertRGBtoXYZ メソッドとConvertXYZtoRGB メソッドはバーチャルであるので
、用意されるカラー・プロフィールで働くようにオーバライドすることができる
。これらがオーバライドされなかったときは、RGB とXYZ 間の変形はDEFAULT変
形に基づくことになる。
カラー・マッチャ・クラス
好適実施例では、カラー・マッチングを行うオブジェクトはColorMatcherであ
る。好適実施例では、ColorMatcherは再入可能(reentrant)でなければならない
。ストアされるステートはColorMatcherにはないが、実際には、ColorMatcherは
カラー・キャッシュ(DeviceCache)にストアできるステートを生成する。カラー
・マッチングで使用されるカラー・キャッシュはGrafDeviceにストアされている
。
カラー・マッチング機会は２つの部分に分けることができる。(1) データを表
すカラー・プロフィールと(2) そのデータに作用を及ぼすカラー・マッチング・
アルゴリズムを表すColorMatcherである。カラー・マッチングは入力デバイスの
カラー・プロフィールを出力デバイスのカラー・プロフィールにマッピングする
ことにより行われる。この変形が識別されると、これはTColorまたはTGImage に
適用される。
第16図は、好適実施例によるTColorProfile と３つのデフォルト・カラー・マ
ッチング・クラス・インプリメンテーション(TColorimetricColorMatcher、TApp
earanceColorMatcher、およびTExactColorMatcher)のクラス図を示したものであ
る。
TColorMatcher は抽象基底クラスであり、３つの重要な純粋バーチャル・メソ
ッドをもっているが、これらはオーバライドされる必要がある。次のとおりであ
る。
各ColorMatcherは、TColorとTGImage をマッチングできるColorMatchメソッド
を提供しなければならない。なんらかの理由で、ソースおよびマッチングされた
カラー（イメージ）が同一であると、どのカラーも自身と自動的にマッチングさ
れるので、なにも行われない。カラー・マッチャは再入可能でなければならない
ので、キャッシュは３メソッドのすべてに渡される。
デフォルト・カラー・マッチング
レンダリング時にカラー・マッチングが行われるかどうかは、SceneBundle で
の条件によって決まる。下に示したのは、TSceneBundleクラス定義である。
構築時には、TColorMatcher を指すポインタは、ユーザがコントロール・パネ
ル・レベルでデフォルトとして選択したカラー・マッチャにセットされる。カラ
ー・マッチングはレンダリング・パイプライン(rendering pipeline)においてCo
pyBitsで行われる。
次の疑似コードの一部分は、デフォルト・カラー・マッチングがどのように行
われるかを示している。
//デフォルトのカラー・マッチャがユーザにより選択
//全てのColorsおよび／または標準カラー・プロフィールのTGImagesを生成
//カラー・マッチングがgrafportの全てのDrawに対して行われる
デフォルト・カラー・マッチングのオーバライド
好適実施例では、デフォルト・カラー・マッチングをオーバライドするには、
２通りの方法がある。第１の方法では、STANDARD ColorProfilesのセットが使用
され、ユーザのColorMatcherによって部分的にオーバライドされる。第２のケー
スでは、ユーザはColorProfiles のセットを定義し、デフォルトColorMatcherを
オーバライドすることができる。次の疑似コードは、第２のケースで必要になる
ステップを示している。
//ソースとデスティネーションのカラーのColorProfileの定義とインプレメット
//自身のColorMatcherクラスを定義
//フアイル１とフアイル２の中の情報からカラー・プロフィールを生成
//カラー・マッチャとキャシュを生成
//ソース・プロフィールからカラーを生成
//SceneBundleを生成し、マッチングを行わせる
//grafportの各Drawに対してカラー・マッチングが行われる
【手続補正書】特許法第１８４条の８
【提出日】１９９５年７月６日
【補正内容】
（原文明細書第３頁）
アーキテクチャがそのデバイスをサポートするように設計されていなかったか、
あるいはサポートするように変更できなければ、オペレーティング・システム・
アーキテクチャがそのデバイスをサポートできないことである。また、従来のア
ーキテクチャは、カラー・モニタのように、独自のカラー空間、色域およびプロ
フィール特性をもつ特定の周辺デバイスのカラーをサポートし、そのカラーを特
定のカラー・プリンタのように、独自の上記カラー特性をもつ別の周辺デバイス
にマッチングさせる能力を有している場合もある。それにもかかわらず、上に挙
げた特定のカラー・モニタやプリンタとは異なるカラー特性をもつカラー・モニ
タやプリンタが１種類または２種類以上コンピュータに接続される、あるいは、
プロッタやカラーＴＶカメラのような他のタイプのカラー周辺デバイスがコンピ
ュータに接続されると、従来のコンピュータ・システム、具体的には、そのオペ
レーティング・システム・アーキテクチャは、これらの他の異種周辺デバイスの
いずれについてもカラー・マッチングをサポートできなくなるという別の限界が
ある。
さらに、二番目に挙げた問題については、コンピュータ・システムのユーザは
、限界をもつ従来のオペレーティング・システム・アーキテクチャによってサポ
ートされる周辺デバイスのカラー空間とは異なる、自分の選んだいくつかのカラ
ー空間で仕事をすることを望んでいる場合がある。例えば、RGB カラー空間とCY
MK カラー空間の他にも、ルミナンス・ユニット・ベクトル(Luminance Unit Vec
tor - LUV)カラー空間およびLUV 色相、彩度、明るさ(hue，saturation，bright
ness - HSL)カラー空間と呼ばれるカラー空間が２つある。しかるに、限界のあ
るオペレーティング・システム・アーキテクチャを採用した上述のコンピュータ
・システムで仕事をしているコンピュータ・ユーザはモニタのRGB カラー空間や
プリンタのCYMKカラー空間だけで仕事を行うことができ、他のカラー空間では仕
事ができない場合がある。
欧州特許公開第0,448,250 号公報では、第１のイメージ出力デバイスを制御す
るのに適した第１カラー空間でイメージを表示するデータを処理する方法と装置
を記載している。装置は、イメージを明るさ、彩度、および色相コンポーネント
により定義される知覚可能なカラー空間に逆変換し、所定のアルゴリズムに応じ
てイメージの明るさ、彩度、および色相コンポーネントを修正し、イメージのす
べてのカラーを第２のイメージ出力デバイスの色域内に含めるようにするプロセ
ッサ(11,14,17)と、修正されたおよび未修正の明るさ、彩度および色相コンポー
ネントを定義するデータをストアする記憶装置を具備する。欧州特許公開第0,37
8,448 号公報では、入力カラー・データ(例えば、RGB)を出力カラー(例えば、CM
Y)に変換する方法を記載している。入力カラー・データは出力デバイスから集め
られて所定のカラー空間データに変換される。カラー空間データは出力カラー・
データに変換され出力デバイスに出力される。欧州特許公開第0,209,266 号公報
では、モニタ(6)、モニタ(6)に接続されるモニタ制御装置(4,5)、および記憶装
置(1)からイメージのピクセルの色の内容を表示する第１信号を受信し、モニタ
制御装置に供給される各ピクセル用モニタ制御信号を生成するカラー修正回路(2
)を具備するイメージ・ディスプレイ装置が記載されている。カラー修正回路(2)
は、モニタ(6)で通常表示できる色域に含まれないカラーを表示するすべての第
１信号に対し、所定のアルゴリズムを第１信号に適用することにより、モニタ色
域内に含まれる各等価色を表わすモニタ制御信号を生成する。終りに、欧州特許
公開第0,313,794 号公報では、カラー・ディスプレイ装置の三原色により生成可
能な色域から選択され、知覚的に同一のカラー空間に変換される、カラーを逆変
換する方法と装置が記載されている。カラー空間の座標は、容易にカラー測定の
国際的に容認された基準に変換できる。また、選択されたカラーのカラー空間座
標をディスプレイ装置の対応する相対的な三原色強度レベルに変換する方法もあ
る。
発明の概要
本発明は、カラー処理をグローバル・スケールでサポートする独特のオペレー
ティング・システム・アーキテクチャと方法を提供している。本発明のオペレー
ティング・システム・カラー・アーキテクチャと方法によれば、異種の周辺カ
ラー・デバイスがいくつでもサポートされるのと同じように、カラー・マッチン
グ方式(color matching scheme)もいくつでもサポートされる。言い換えれば、
本発明のカラーアーキテクチャは、デバイスでカラーを使用するために、周辺デ
バイス・メーカが採用しているどのアプローチとも結びついていないし、またど
のアプローチにも拘束されていない。また、アーキテクチャ自体はカラー・マッ
チング方式と結びついていないし、拘束されていない。さらに、新しいカラー周
辺デバイスが、本発明のアーキテクチャを実装した所与のコンピュータ・システ
ムとのインタフェースされるとき、かかる新デバイスのメーカは、これらのデバ
イスが、そのシステムとインタフェースされている既存のすべてのカラー周辺デ
バイスと正しく通信できるという保証が得られる。
さらに、本発明のオペレーティング・システム・カラー・アーキテクチャと方
法によれば、アーキテクチャのユーザは、自分が望ましいとするどのカラー空間
においても作業することができ、また、完全に拡張可能であるので、
請求の範囲
１．所定の基準(54)に応じて、入力デバイス(22)で生成される第１カラー空間（
第6A図）の入力カラー信号(52)を、第２カラー空間（第6B図）の出力カラー信号
(56)に変換して、デバイス特性をもつ出力デバイス(36)に適用するカラー・マッ
チング・システムにおいて、
(a) 入力カラー信号(22,910)に応答して、較正カラー空間(CG22)内の対応する
カラー信号の第１の組を生成する入力変換手段と、
(b) 前記出力デバイスの特性(CG32)および前記出力カラー信号(TRC36)に応答
して、すべてのカラー信号が前記第２カラー空間(940)内で対応する信号をもつ
出力カラーの色域を前記較正空間内で定義する変形手段(54,930)と、
(c) 前記較正カラー空間の前記カラー信号の第１の組に応答して、前記較正カ
ラー空間(36,950)の前記出力カラーの色域内でカラー信号の第２の組を生成する
マッチング手段と、
(d) 前記カラー信号の第２の組および前記出力デバイスの特性に応答して、前
記出力カラー信号を前記第２カラー空間に生成する出力変換手段であって、前記
カラー出力信号は、前記の所定の基準(54,TRC36,36、第５図）に応じて前記入力
カラー信号とマッチングする
を具備することを特徴とするカラー・マッチング・システム。
２．前記変形手段は、修正デバイス・データを共通カラー空間(58A〜58D 、第6A
図〜第6B図）内の第１較正カラー信号に変形することを特徴とする請求の範囲第
１項に記載のカラー・マッチング・システム。
３．修正デバイス・データ生成手段は、前記入力デバイスに特有の色調再現デー
タと、前記色調再現データを前記入力カラー信号に適用するロジック(TRC22,TRC
36)を具備することを特徴とする請求の範囲第１項に記載のカラー・マッチング
・システム。
４．前記第１カラー空間が未較正カラー空間であり、
前記入力変換手段は、前記入力カラー信号に応答して、前記入力カラー信号を
RGB カラー空間のRGB カラー信号に変換する手段および前記RGB カラー信号に応
答して、前記RGB カラー信号を較正XYZ カラー空間（第５図）のXYZ カラー信号
に変形する手段を具備することを特徴とする請求の範囲第１項に記載のカラー・
マッチング・システム。
５．前記第２カラー空間が未較正で、前記出力変換手段が、前記カラー信号の第
２の組に応答して前記カラー信号の第２の組を較正カラー空間のXYZ カラー信号
に変形し、前記XYZ カラー信号を未較正RGB カラー空間（第５図）のRGB カラー
信号に変形する手段を具備することを特徴とする請求の範囲第１項に記載のカラ
ー・マッチング・システム。
６．所定の基準(54)に応じて入力デバイス(22)で生成される第１カラー空間（第
6A図）の入力カラー信号(52)を第２カラー空間（第6B図）の出力カラー信号(56)
に変換してデバイス特性をもつ出力デバイス(36)に適用する方法において、
(a) 較正カラー空間(CG22)内で、前記入力カラー信号から対応するカラー信号
(22,910)の第１の組を生成するステップと、
(b) 前記出力デバイスの特性(CG32)および前記出力カラー信号(TRC36)を使い
、すべてのカラー信号が前記第２カラー空間(940)で対応する信号をもつ出力カ
ラーの色域を前記較正空間内で定義するステップと、
(c) 前記較正カラー空間の前記カラー信号の第１の組に所定のマッチング方法
を適用し、前記較正カラー空間(36,950)の前記出力カラーの色域内でカラー信号
の第２の組を生成するステップと、
(d) 前記出力デバイスの特性および前記カラー信号の第２の組を使い、前記の
所定の基準(54,TRC36,36、第５図)に応じて前記入力カラー信号とマッチングす
る前記出力カラー信号を前記第２カラー空間に生成するステップと
を具備することを特徴とする方法。
７．前記ステップ(d)は、入力色域オブジェクトの中のロジックを呼出して修正
デバイス・データを較正共通カラー空間(58A〜58D 、第6A図〜第6B図）内の第１
カラー信号に変形するステップを具備することを特徴とする請求の範囲第６項に
記載の方法。
８．入力カラー情報と、前記入力カラー情報(TRC22,TRC36)を変更し取得するた
めのロジックとを収めている入力カラー・オブジェクトを生成するステップをさ
らに具備することを特徴とする請求の範囲第６項に記載の方法。
９．前記ステップ(a)が、カラー信号をRGB カラー空間の未較正RGB カラー信号
に変形し、前記RGB カラー信号を較正XYZ カラー空間（第５図）のXYZ カラー信
号に変形するステップを具備することを特徴とする請求の範囲第６項に記載の方
法。
10．ステップ(e)は、入力カラー・プロフィール・オブジェクトの中のロジック
を呼出してカラー・マッチャ・オブジェクト(66)を生成するステップを具備する
ことを特徴とする請求の範囲第６項に記載の方法。
─────────────────────────────────────────────────────
フロントページの続き
(81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ，
ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，Ｍ
Ｃ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ
，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，
ＴＤ，ＴＧ)，ＡＴ，ＡＵ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，
ＣＡ，ＣＨ，ＣＮ，ＣＺ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，Ｇ
Ｂ，ＨＵ，ＪＰ，ＫＰ，ＫＲ，ＫＺ，ＬＫ，ＬＵ，ＬＶ
，ＭＧ，ＭＮ，ＭＷ，ＮＬ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，
ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＫ，ＵＡ，ＵＺ，ＶＮ
(72)発明者 ハリス，ジェリー ジィー.
アメリカ合衆国 94087 カリフォルニア
州 サニーベイル ウエスト レミントン
ドライブ 672
【要約の続き】
カラー・マッチング・アルゴリズムを必要に応じて追加
できるように拡張可能であり、ユーザが自分の選んだカ
ラー空間で作業することを可能にし、アーキテクチャと
のインタフェースとなる周辺デバイス間でカラー・マッ
チングを行うことができる。