JPH09500980A - オブジェクト指向パレット・システム - Google Patents

Abstract

(57)【要約】 オブジェクト指向パレット・システムが開示され、さらに具体的には、オブジェクト指向オペレーティング・システム用にカラー・パレットを管理し、外部デバイスから表示するために複数のカラー（例えば、256カラー）を共用できるようにするシステムと方法が開示されている。本発明がもつ第１の側面では、８ビットのカラー・ルックアップ・テーブル(color lookup table - CLUT)は外部デバイス上に表示されているドキュメント内の複数のビューによって共用され、外観的に統一されたカラーが複数のグラフィック・デバイスに共通して提供されるようにしている。本発明による方法は、オペレーティング・システム用にカラー・ルックアップ・テーブル(CLUT)を作成し、CLUTをあらかじめ決めた数のカラーに均等に分割し、複数のビューをもつグラフィック情報を表示し、CLUT内のあらかじめ決めた数のカラーをグラフィック情報の複数のビュー間で共用することからなっている。あらかじめ決めた数のカラーは複数のカラーを含み、その各々は異なるカラー・ディスプレイから表示されるとき統一されている。

Description

【発明の詳細な説明】 オブジェクト指向パレット・システム 発明の分野 本発明は一般的には、オペレーティング・システムで使用するためのカラー・ パレット管理に関し、より具体的には、オブジェクト指向オペレーティング・シ ステムにおいてカラー・パレットを管理することに関する。 発明の背景 オブジェクト指向プログラミング(object orientedprogramming -OOP)は、ユ ーザに親しみやすい、インテリジェント・コンピュータ・ソフトウェアを構築す るのに好適な環境である。OOPのキーとなるエレメントはデータのカプセル化(en capsulation)、継承(inheritance)および多態(polymorphism)である。これらの エレメントを使用すると、アイコン、マウス・カーソルおよびメニューをもつウ ィンドウ操作環境で代表される特徴をもつグラフィカル・ユーザ・インタフェー ス(graphical user interface - GUI)を作ることができる。この３つのキー・エ レメントはOOP言語に共通しているが、大部分の言語では、これらの３つのキー ・エレメントのインプリメントの仕方（実現方法）が異なっている。OOP言語の 例としては、Smalltalk、Object PascalおよびC++がある。Smalltalkは実際には 言語以上のものである。プログラミング環境といった方が正確かもしれない。Sm alltalkは、Xerox社Palo Alto Research Center PARC）のLearning Research Gr oupで1970年代初期に開発されたものである。Smalltalkでは、メッセージがオブ ジェクトヘ送られ、オブジェクト自体が評価される。メッセージは従来のプログ ラミング言語における関数コール(function call)のそれと似たタスクを実行す る。プログラマはデータのタイプ（型）を気にする必要がない。むしろ、プログ ラマはメッセージを正しい順序で作成し、正 しいメッセージを使うことだけを気にするだけでよい。Object Pascalはアップ ル社マッキントッシュ（登録商標）コンピュータ用に使用されている言語である 。Object PascalはPascalの設計者であるNiklaus Wirthの協力を得てアップル社 が開発したものである。C++はＣの拡張として、1983年にAT&T社Bell Laboratori esのBjarne Stroustrupによって開発されたものである。C++のキーとなる概念は クラスであり、これはユーザが定義するタイプである。クラスはオブジェクト指 向プログラミングの特徴をもっている。C++モジュールはＣモジュールと互換性 があるので、自由にリンクして既存のＣライブラリをC++プログラムで使用する ことができる。最も普及しているオブジェクト・ベースとオブジェクト指向のプ ログラミング言語の起源は、ノールウェイのO-J.Dahl，B.MyhrhaugおよびK.Nyga rdによって1960年代に開発されたSimulaである。OOPを詳しく論じたものとして 、Grady Booch著「オブジェクト指向設計とそのアプリケーション」(Object Ori ented Design with Applications)(The Benjimin/Cummings Publishing Co.,Inc .，Redwood City，Calif.，1991)がある。 OOPの簡単な概要は上述したとおりであるが、カラー・パレット管理(color pa lette management)は、プログラミング環境における固有の問題を提示している 。カラー・モニタの表示面上の各ピクセルは、赤の蛍光体(phosphor)、緑の蛍光 体および青の蛍光体を含んでいる。各蛍光体はモニタが再現できるカラーを決め る物理的特性をもっている。これらの３つの蛍光体と電子ビーム銃の最大等輝度 (maximum equal intensity)により、モニタの色域(color gamut)が決まっている 。しかし、理論的には、どのカラーがこのデバイスから物理的に得られるかはモ ニタの蛍光体によって決まるが、実用上は、各モニタが再現できるカラーの数に は制約がある。例えば、コンピュータはディジタル（アナログとは反対）の世界 で動作するので、モニタが実際に再現できるカラーの数は有限数に限られている 。モニタが再現できるカラーの数が増加していくと、スクリーン（表示画面）の ディジタル・イメージをストアしておくためのメモリがそれに伴って増加してい く。スクリーンをストアするメモリはビデオ・カード上に実装されているのが通 常である。 メモリ・コストの関係から、従来、開発者はモニタの色域のうちオペレーショ ンに必要な部分を動的に設定していた。このアプローチでは、カラー・ルックア ップ・テーブル(Color Look Up Tab1e - CLUT)が使用されている。カラー・パレ ットはアプリケーション内のウィンドウまたはアプリケーション自体のどちらか と選択的に関連づけられていた。ある開発されたパレット管理システムでは、カ ラーがウィンドウからでも、アプリケーションからでも要求できるようになって いる。どちらのタイプの要求を行うかによって、カラーが親しみやすい方法で共 有できる場合と、親しみにくい方法で共有できる場合とがあった。アクティブ（ 活動状態の）ウィンドウまたはアプリケーションが変更されたときは、パレット ・マネージャは元のアクティブ・パレットから新しいパレットへの移行を、ユー ザが見たとき（視覚的に）できるかぎり親しみやすくなるように行っていた。 しかるに、従来のオペレーション・システムでは、CLUTをアプリケーションま たはウィンドウと関連づけることが相対的に容易になっているが、好適なオペレ ーション・システムでは、このような関連づけにいくつかの問題がある。 発明の概要 従って、本発明の目的は、ビュー(view)が調和のとれた方法で、しかも視覚的 に親しみやすい方法でカラーを共有することができる新規なカラー・パレット管 理方法とシステムを提供することであり、本発明の方法とシステムはいくつかの エンカプセルレータ(encapsulator)からなり、これらをアセンブルすると大きな ドキュメントとなるような複合ドキュメント(compound document)を含んでいる オペレーティング・システムで使用されることを目的としている。本発明は、CL UTとビューとを関連つけ、カラーを共有する異なる考え方を提供している。 本発明の一側面では、オブジェクト指向オペレーティング・システム用にカラ ー・パレットを管理する方法は、オペレーティング・システム用にカラー・ルッ クアップ・テーブル(CLUT)を作成し、CLUTをあらかじめ決めた数のカラーに均等 に分割し、複数のビューをもつグラフィック情報を表示し、CLUT内のあらか じめ決めた数のカラーをグラフィック情報の複数のビュー間で共有するステップ からなり、この場合、あらかじめ決めた数のカラーは複数のカラーを含んでおり 、その各々は複数のビューのうち第１ビューと第２ビュー間で共有されたとき、 あらかじめ決めた統一性をもっていることを特徴としている。 図面の簡単な説明 上記および他の目的、側面および利点の理解を容易にするために、以下では、 添付図面を参照して本発明の好適実施例について詳しく説明する。なお、図面に おいて、 第１図は好適実施例によるコンピュータ・システムを示すブロック図である。 第２図は好適実施例によるモニタおよびビデオ・カードの構成を示す図である 。 第３図は好適実施例による赤緑青(RGB)カラー空間（色空間）を示す図である 。 第４図は好適実施例によるモニタの色域の例を示す図である。 第５図は好適実施例によるカラー・ルックアップ・テーブル(CLUT)を示す図で ある。 第６図は好適実施例による複合ドキュメントを示す図である。 第７図は好適実施例によるモニタの代表的色域のプロット図である。 第８図は好適実施例による第７図の色域プロットの断面図である。 第９図は、好適実施例による平面の周囲を取り巻く正しい位置と平面のホワイ ト・ポイントに間隔が置かれたカラーを示す図である。 第10図は好適実施例による弛緩手法(relaxation technique)の結果を示す図で ある。 第11図は好適実施例によるフローチャートである。 発明の好適実施例の詳細な説明 本発明は、好ましくは、IBM（登録商標）社PS/2（登録商標）またはアップル （登録商標）社マッキントッシュ（登録商標）コンピュータなどのパーソナル・ コンピュータ上に置かれているオペレーティング・システムの環境（コンテキス ト）で実施される。代表的なハードウェア環境は第１図に示されているが、同図 は従来のマイクロプロセッサのような中央演算処理ユニット10、およびシステム ・バス12を介して相互に接続された複数の他のユニットを装備した、本発明によ るワークステーションの代表的ハードウェア構成を示している。第１図に示すワ ークステーションはランダム・アクセス・メモリ(RAM)14、リードオンリ・メモ リ(ROM)16、ディスク・ユニット20などの周辺デバイスをバスに接続するための 入出力アダプタ18、キーボード24、マウス26、スピーカ28、マイクロホン32、お よび／またはタッチ・スクリーン・デバイス（図示せず）などの他のユーザ・イ ンタフェース・デバイスをバスに接続するためのユーザ・インタフェース・アダ プタ22、ワークステーションをデータ処理ネットワークに接続するための通信ア ダプタ34、およびバスをディスプレイ・デバイス38に接続するための表示アダプ タ36を装備している。ワークステーションには、アップル社System/7（登録商標 ）オペレーティング・システムなどのオペレーティング・システムが置かれてい る。 好適実施例では、本発明は、オブジェクト指向プログラミング技法を使用して C++プログラミング言語で書かれている。この分野に精通しているものならば容 易に理解されるように、オブジェクト指向プログラミング(Object-Oriented Pro gramming - OOP)のオブジェクトは、データ構造とデータに対するオペレーショ ン（操作、演算など）からなるソフトウェア・エンティティ（software entity ）である。これらのエレメントが協力し合うことにより、オブジェクトは、その データ・エレメントで表されたその特性、およびそのデータ操作関数(data manu pulation functions)で表されたその作用(behavior)からとらえて、ほとんどど のような実世界のエンティティでもモデル化することができる。この方法による と、オブジェクトは、人やコンピュータなどの具体物をモデル化する ことができ、また、数や幾何学的概念などの抽象概念をモデル化することができ る。オブジェクト・テクノロジの利点は次の３つの基本的原理から得られるもの である。それは、カプセル化(encapsulation)、多態(polymorphism)および継承( inheritance)である。 オブジェクトは、そのデータの内部構造とその関数が実行されるときのアルゴ リズムを隠蔽する。つまりカプセル化する。これらのインプリメンテーション細 部を見せる代わりに、オブジェクトは、外部情報(extraneous information)のな いクリーンな形でその抽象化(abstractions)を表しているインタフェースを提示 する。多態はカプセル化をさらに一歩進めたものである。この考え方は、多数の 形体をもつ、１つのインタフェースである。あるソフトウェア・コンポーネント は、別のコンポーネントがなんであるかを正確に知らなくても、その別のコンポ ーネントを要求することができる。要求を受け取ったコンポーネントはその要求 を解釈し、その要求をどのように実行すべきかを、その変数とデータに従って判 断する。三番目の原理である継承によれば、開発者は既存の設計やコードを再利 用することができる。この機能を利用すると、開発者はソフトウェアを初めから 作ることが回避される。むしろ、継承を通して、開発者は作用を継承するサブク ラスを派生し、その作用を開発者独自の要求に合ったものにカストマイズするこ とができる。 従来のアプローチでは、オブジェクトとクラス・ライブラリを手続き向き環境 で階層化する方法がとられていた。市販されている多くのアプリケーション・フ レームワークはこの設計手法を採用している。この設計では、モノリシック・オ ペレーティング・システム(monolithic operating system)の上に１つまたは２ つ以上のオブジェクト層が置かれている。このアプローチでは、カプセル化、多 態および継承のすべての原理がオブジェクト層に採用され、手続き向きプログラ ミング技法を大幅に改善しているが、このアプローチにはいくつかの制約がある 。これらの問題は、開発者が自身のオブジェクトを再利用することは容易である が、他のシステムからのオブジェクトを使用することが困難であるため、手続き 向きオペレーティング・システム(OS)のコールを使用して、下位の非オブジェク ト層まで到達する必要があることに起因している。 オブジェクト指向プログラミングがもつもう１つの側面は、アプリケーション を開発するのにフレームワーク・アプローチを採用していることである。フレー ムワークの最も合理的な定義の１つとして、イリノイ大学のRalph E.JohnsonとP urdueのVincent F.Russoによるものがある。両氏の1991年の論文「オブジェクト 指向設計の再利用」（Reusing Object-Oriented Designs）、イリノイ大学技術 報告書UIUCDCS91-1696の中で、次のような定義を提案している。「抽象クラスと は、一組の責任分担を協力し合って実行するオブジェクトの集合を設計したもの である。従って、フレームワークとは、組で定義された演算責任分担を協力し合 って実行するオブジェクト・クラスが集まったものである。」プログラミング側 から見たときは、フレームワークとは、基本的には、実動アプリケーション(wor king application)の事前に作られた構造を提供する、相互に接続されたオブジ ェクト・クラスの集まりである。例えば、ユーザ・インタフェース・フレームワ ークは、描画ウィンドウ(drawing window)、スクロールバー、メニューなどをサ ポートし、これらの「デフォルト（省略時）」の作用を提供することができる。 フレームワークはオブジェクト・テクノロジを基礎にしているので、この作用を 継承してオーバライド(override)することにより、開発者はフレームワークを拡 張し、カストマイズした解決手法を特定の専門分野で作ることができる。これが 従来のプログラミングに比べて大きな利点であるのは、プログラマはオリジナル ・コードを変更することなく、むしろソフトウェアを拡張できるからである。さ らに、フレームワークは、アーキテクチャに関するガイダンスとモデリングを提 供すると同時に、問題領域に特有の個々のアクションを指定することから開発者 を解放するので、開発者はいくつかのコード層を通って盲目的に作業する必要が ない。 ビジネス側から見たときは、フレームワークは、特定の知識分野において専門 知識をカプセル化または具現化する方法と見ることができる。企業の開発集団、 独立ソフトウェア・ベンダ(Independent Software Vendors - ISV)およびシステ ム統合者(systems integrators)は、前述した例のように、製造、会計、通貨取 引きといった特定分野における専門知識をもっている。この専門知識はコードで 具現化されている。フレームワークを使用すると、企業は、その専門知識を企業 のコードで具現化することにより、専門知識の共通特性を取り込んで、パッケー ジ化することができる。まず、そのようにすると、開発者は専門知識を利用する アプリケーションを作成または拡張できるので、問題がいったん解決されれば、 ビジネス・ルールや設計は統一的に実施され、使用されることになる。また、フ レームワークと、フレームワークの背景にある具現化された専門知識は、製造、 会計、バイオテクノロジといった垂直的マーケットにおいて専門知識を得た企業 にとっては、戦略的資産をもつことを意味し、企業の専門知識をパッケージ化し 、再販し、流布し、テクノロジの進歩と普及化を促進するための分配メカニズム をもつことになる。 歴史的には、フレームワークがパーソナル・コンピューティング・プラットフ ォーム上の主流概念として出現したのは、つい最近のことである。この移行を助 長したのが、C++といったオブジェクト指向言語の出現である。従来までは、C++ は大部分がUNIXシステムと研究者のワークステーション上に搭載され、コマーシ ャル・ベースのパーソナル・コンピュータには搭載されていなかった。いくつか の大学や研究所のプロジェクトが今日の商用フレームワークおよびクラス・ライ ブラリの先駆けとなり得たのは、C++などの言語やSmalltalkなどの他のオブジェ クト指向言語のお陰である。その例のいくつかを挙げると、スタンフォード大学 のInterViews、カーネギ・メロン大学のAndrewツールキット、チューリッヒ大学 のET++フレームワークがある。 フレームワークは、どのレベルのシステムに関心があり、どのような問題を解 決しようとしているかに応じて、多種類のものがある。フレームワークの種類は ユーザ・インタフェースの開発を支援するアプリケーション・フレームワークか ら、通信、印刷、ファイル・システム・サポート、グラフィックスなどの基本的 システム・ソフトウェア・サービスを提供する低レベルのフレームワークまでに わたっている。商用化されているアプリケーション・フレームワークの例をいく つか挙げると、MacApp(Apple)、Bedrock(Symantec)、OWL(Borland)、NeXtStep A pp Kit(NeXT)、Smalltak-80 MVC(ParcPlace)がある。 フレームワークでプログラミングを行うには、他の種類のシステムに慣れてい る開発者は考え方を変える必要がある。確かに、このプログラミングは、従来考 えられていた「プログラミング」とはまったく異なっている。DOSやUNIXなどの 旧スタイルのオペレーティング・システムでは、開発者自身のプログラムが構造 全体になっている。オペレーティング・システムはシステム・コール(system ca ll)を通してサービスを提供している。つまり、開発者のプログラムはサービス の必要時にコールを行い、サービスが提供されたとき制御が返却される。プログ ラム構造は制御の流れに基礎を置き、これは開発者が書いたコードに具現化され ている。 フレームワークが使用されるときは、これとは反対である。開発者は制御の流 れに責任をもつ必要がなくなる。開発者は、プログラミング・タスクを実行の流 れからとらえて理解しようとする癖を止めなければならない。むしろ、オブジェ クトの責任分担からとらえて思考する必要があるので、タスクをいつ実行させる かを判断するには、フレームワークに頼らざるを得なくなる。開発者が書いたル ーチンは、開発者が書かなかった、従って開発者には見えないコードによってア クチベート(activate−活性化)される。この制御の流れのフリップフロップは、 手続き向きプログラミングだけに経験のある開発者にとっては、大きな心理的障 壁となっている。しかし、このことをいったん理解してしまえば、フレームワー ク・プログラミングによると、他のタイプのプログラミングによる場合よりも作 業量が大幅に減少することになる。 アプリケーション・フレームワークが開発者にプレハブの機能を提供するのと 同じように、本発明の好適実施例に含まれているようなシステム・フレームワー クはシステム・レベルのサービスを提供することによって同じ考え方をてこにし ている。つまり、システム・プログラマといった開発者は、システム・レベルの サービスをサブクラス化またはオーバライドして、カストマイズした解決手法を 作成することができる。例えば、オーディオ、ビデオ、MIDI、アニメーションな どの新規なデバイスや異種デバイスをサポートする基礎を提供できるマルチメデ ィア・フレームワークについて考えてみることにする。新しい種類のデバイスを サポートする必要がある場合、開発者はデバイス・ドライバを書く必要が起こる ことになる。フレームワークでこれを行う場合は、開発者に要求されることは、 その新デバイスに特有の特性と作用を指定するだけである。 この場合の開発者は、マルチメディア・フレームワークから呼び出されるある 種のメンバ関数(member functions)のインプリメンテーションを用意することに なる。開発者にとって即時に利点となることは、デバイスのカテゴリ別に必要に なる汎用コード(generic code)がマルチメディア・フレームワークにすでに用意 されていることである。このことは、デバイス・ドライバ開発者が書き、テスト し、デバッグするコードが少なくなることを意味する。システム・フレームワー クを使用するもう１つの例は、入出力フレームワークがSCSIデバイス、NuBusカ ード、およびグラフィックス・デバイス別になっていることである。機能は継承 されるので、各フレームワークには、そのデバイス・カテゴリに見られる共通機 能に対するサポートが用意されている。この場合、他の開発者は、これらの統一 インタフェース(consistent interfaces)を通して、あらゆる種類のデバイスに アクセスすることが可能になる。 好適実施例はフレームワークの考え方を取り入れており、この考え方をシステ ム全体に適用している。商業的または企業の開発者、システム統合者、またはOE Mにとっては、このことはMacAppのようなフレームワークについて説明してきた すべての利点を、テキストやユーザ・インタフェースといったアプリケーション ・レベルだけでなく、グラフィック、マルチメディア、ファイル・システム、入 出力(I/O)、テストなどのサービスのようなシステム・レベルでも活用できるこ とを意味する。好適実施例のアーキテクチャでアプリケーションを作成すること は、フレームワーク・プロトコルに準拠するドメイン(domain - 問題領域）特有 のジクソーパズルのピース（断片）を書くのと基本的に同じである。このように して、プログラミングの概念全体が変わっている。複数のAPI階層をコールする コードを一行ずつ書くのではなく、ソフトウェアはこの環境内の既存のフレーム ワークからクラスを派生し、そのあとで、必要に応じて新しい作用(behavior)を 追加しおよび／または継承した作用をオーバライドすることによって開発される 。 以上のように、開発者のアプリケーションは、書かれたあと他のすべてのフレ ームワーク・アプリケーションと共有されるコードの集まりとなる。これが強力 な概念となっているのは、開発者同士が他の開発者の作業の上に積み上げてい くことができるからである。また、この概念によれば、開発者はカストマイズす る量を必要に応じて多くしたり、少なくしたりできる柔軟性が得られる。フレー ムワークには、そのままで使用されるものもある。ある場合には、カスマイズす る量が最小となるので、開発者がプラグインするジクソーパズルのピースは小さ くなる。他の場合には、開発者は大幅な変更を行って、まったく新しいものを作 ることもできる。上述したOOPの概要に留意すると、カラー・パレット管理はプ ログラミング環境における固有の問題を提示している。カラーによるイメージの 視覚化(color visualizations of images)の使用について、以下簡単に説明する 。一般的に、カラー空間(color space - 色空間）は３次元で表現したもので、 カラーを定義するスカラー・コンポーネント（成分）(scalar component)を視覚 化するときに利用されている。カラー・モニタ上のカラーを記述するとき最もよ く使用されているカラー空間は赤緑青(RGB)カラー空間である。これを図形化し て示したのが第３図であり、これは加法混色カラー空間(additive color space) である。RGBカラー空間では、カラー・モニタで使用される赤、緑および青の各 「電子銃(gun)」は立方体の座標軸と関連づけられている。つまり、赤の電子銃 は赤軸と、緑の電子銃は緑軸と、青の電子銃は青軸と関連づけられている。これ らの３つの座標はディスプレイのカラー３原色の赤、緑、および青を表している 。スカラー・コンポーネント値を０と1.0の間で変化させると、RGB空間に含まれ るカラーのすべてを再現することができる。 カラー・モニタの表示面上の各ピクセルは赤の蛍光体、緑の蛍光体および青の 蛍光体を含んでいる。各蛍光体はモニタが再現できるカラーを決める物理的特性 をもっている。３つの蛍光体と電子ビーム銃の最大等輝度により、モニタの色域 が決まっている。色域は、第３図に示すように、モニタが可視スペクトルのどの カラーを再現できるかを定義したものである。馬蹄形曲線(horseshoe curve)は 可視カラーのすべてを含んでおり、このグラフは色域内の輝度情報をすべて除外 し、色度(chromaticity)情報だけを含んでいる。カラー・モニタの色域を色度空 間にプロットすると、第４図に示すような三角形が得られる。 モニタは第４図に示す三角形の外にあるカラーを再現することはできない。従 って、可視カラーのどのサブセットが再現できるかは、モニタの蛍光体によっ て決まる。しかし、モニタの三角形の中では、作り出すことができるカラーの量 はほぼ無限に存在する。しかし、デバイスがどのカラーを物理的に再現できるか は、理論的には、モニタの蛍光体によって決まるが、実用上は、各モニタが再現 できるカラーの数には制約がある。例えば、コンピュータはディジタル（アナロ グとは反対）の世界で動作するので、モニタから実際に再現できるカラーの数は 有限数に限られている。モニタが再現できるカラーの数が増加していくと、スク リーン（表示画面）のディジタル・イメージをストアするためのメモリが増加す る。スクリーンをストアするメモリは、ビデオ・カード上に実装されているのが 普通である。 メモリ・コストの関係から、従来、開発者はモニタの色域のうちオペレーショ ンのために必要な部分を動的に設定していた。このアプローチでは、第５図に示 すように、カラー・ルックアップ・テーブル(CLUT)を使用している。CLUTはコン ピュータのメモリまたはコンピュータに内蔵されたディスプレイ・アダプタのメ モリにストアされている。図示の例では、アプリケーションは16,000,000カラー から256カラーを選択することができる。従って、モニタによるカラー再現を制 限しているのは、カラーを再現するモニタの能力ではなく、コンピュータに実装 されたビデオ・カードが要求する制約である。しかし、再現できるカラー数が制 限されていると、どのカラーをCLUT内に設定すべきかを判断するときに問題（つ まり、柔軟性の欠如）が起こっている。もう１つの問題は、複数のアプリケーシ ョンが同じCLUTを共有する可能性があることである。 さらに、モニタの色域を十分にきめ細かくカバーするだけの十分なカラー数に しておけば、CLUTが不要になり、直接カラーまたは連続カラーを得ることができ る。人間の視覚系は約50,000種類のカラーを識別することができる。人間の視覚 系のカラー感度は馬蹄形曲線上を平坦になっていない。好適オペレーティング・ システムの場合は、直接カラーはピクセル当たりのビット数が16を越えた時点で スタートしている。従って、カラーのピクセル当たりのビット数が少なくとも16 であれば、RGBカラー空間は十分にきめ細かく分割されるので、CLUTは不要にな る。しかし、８ビットのCLUTでは、上述した問題が存在する。 例えば、ある従来のオペレーティング・システムでは、システムのCLUTの共有 を取り扱う方式が開発されていた。カラー・パレットは、アプリケーション内の ウィンドウまたはアプリケーション自体のどちらかと選択的に関連づけられてい た。ある開発されたパレット管理システムでは、カラーがウィンドウからでも、 アプリケーションからでも要求できるようになっている。どちらのタイプの要求 を行うかによって、カラーが親しみやすい方法で共有できる場合と、親しみにく い方法で共有できる場合とがあった。アクティブ（活動状態の）ウィンドウまた はアプリケーションが変更されたときは、パレット・マネージャは元のアクティ ブ・パレットから新しいパレットへの移行を、ユーザが見たとき（視覚的に）で きるかぎり親しみやすくなるように行っていた。 しかるに、従来のオペレーション・システムでは、CLUTをアプリケーションま たはウィンドウと関連づけることが相対的に容易になっているが、好適なオペレ ーション・システムでは、このような関連づけにいくつかの問題がある。好適オ ペレーティング・システムでは、ドキュメント・フレームワークは従来のオペレ ーティング・システムとは根本的に異なっている。好適オペレーティング・シス テムはいくつかの小さなエンカプセルレータ（例えば、ミニアプリケーション） からなり、これらが「結合(glue)」されて大きなドキュメントとなる複合ドキュ メントを含んでいる。各エンカプセルレータは第６図に示すようにビュー(View) 内にあって、どのシステム資源が必要であるかを知っているが、他のエンカプレ ルセータがなにを必要としているかは知らない。その結果、複数の小さなエンカ プセルレータからなり、これらが統合されて１つのドキュメントとなる複合ドキ ュメントを含んでいるオペレーティング・システムでは、CLUTをビューと関連づ けることは極めて困難である。従って、従来のシステムで使用されているものと は異なるカラー共用の考え方を開発する必要がある。 第11図に示すようなカラー・モニタが与えられているとき、正しいCLUTエント リ(entry−項目)値を判断するためには、実行しなければならないステップがい くつかある。好適な環境では、色域の定義が用いられている。カラー・モニタで は、色域は分光測光器などの計器を用いて、厳格な制御下で測定を８回行うこと によって測定されている。これらの測定はXYZ空間で行われている。RGBカラー・ モニタ上の８点の定義は次のようになっている。 Full Off Black Full on Red Full on Green Full on Blue Full on Yellow Full on Cyan Full on Magenta Full On White 第７図は、モニタの代表的な色域をXYZカラー空間にプロットした図を示した ものである。色域がXYZ座標で求まったら、次に必要なことは、数学的変形によ ってその色域をLUVカラー空間に変換することである。LUVカラー空間は数学的に は非線形的であり、カラーを知覚するときは線形に近くなっている。LUVカラー 空間に変形を行うと、第３図に示したRGBカラー空間で表されているような色域 の立方体が大幅に変化する。このことは、第８図を第３図と比較するとよく分か る。第８図に示すように、Ｌが図示の値のときLUV空間カラーで第７図にプロッ トした色域全体がスライス(slice)化されている。 平面弛緩手法(planar relaxation technique)はCLUT内の実際のRGBカラーを判 断するために用いられている。この手法では、Ｌがあらかじめ決めた値であると き色域がスライス化される。これらのスライスのＬ軸との直交交点は平面を定義 しており、これを表した代表例を示したのが第８図である。これらの平面の各々 の面積が計算される。総面積を得るためにすべての平面の面積が総和される。そ こで、すべての面積の総面積を使用すると単位面積当たりのCLUTカラー数を計算 することができる。これは、総面積をCLUTエントリの数(通常、256)で除するこ とにより行われる。この値は平面当たりのCLUTエントリの数を求めるために使用 される。L=62.5のときの例を示したのが第９図であり、この例に示す平面では、 52カラー、つまり、52個のCLUTエントリが必要である。 値を実際に求めるためのアプローチとしては、弛緩手法が用いられている。カ ラーはまず、第９図に示すように、平面の周囲と平面のホワイト・ポイントを取 り巻く正しい位置に間隔をおいて置かれる。ホワイト・ポイント(white point) とは、ホワイト・ポイントとブラック・ポイントを通るように引かれたラインが その平面と交差する点のことである。次に、残りのカラーはホワイト・ポイント の周囲にランダムに置かれる。次に、各ポイントは、それを取り巻くポイントが 離れている距離に逆比例する距離だけ、その隣接ポイントに増分的に調整される 。この調整は、すべてのポイントで許容誤差が得られるまで各ポイントごとに繰 り返される。弛緩手法の結果は、L=50のときの第10図に示されている。このプロ セスが各平面ごとに繰り返されると、完全なセットのCLUTエントリが得られる。 この処理を詳しく示したのが第11図である。第11図は好適実施例によるフローチ ャートである。処理は機能ブロック1100から開始され、そこで色域が測定され、 LUVカラー空間に変換される。この処理は第７図と第８図に示すものと対応して いる。次に機能ブロック1110で、ルミナンス・レベルの数が定義され、すべての ルミナンス平面の総和が機能ブロック1120で求められ、変数Ｓが機能ブロック11 30でカラー・ルックアップ・テーブル当たりの単位面積に初期化される。次に、 ルミナンス平面当たりのカラー・ルックアップ・テーブルのエントリ数が機能ブ ロック1140で求められる。これは、Ｓを各ルミナンス平面の面積に分割すること によって求められる。次に、機能ブロック1150で、各ルミナンス平面ごとに、カ ラーが平面の境界の周囲に置かれる。カラーは、第９図に示すように、カラー・ ルックアップ・テーブル・エントリ当たりの単位面積の平方根に一致する位置に 間隔をおいて置かれる。最後に、追加のカラーが、機能ブロック1160で図示のよ うにランダムに中央に置かれ、各ルミナンス平面ごとに、カラーが機能ブロック 1170で弛緩されて、図示のようにピクセルが均等に分布される。これを示したの が第11図である。 好適実施例では、第２図に示すように、モニタとビデオ・カードの構成はいく つかがサポートされている。８ビット以下のカラーは、好適実施例によるカラー ・パレット管理システムでは積極的にサポートされていないが、その方が好まし いためである。８ビットを越えるときは、モニタの色域を十分にきめ細かく分割 すると、直接（例えば、連続）カラーが得られるので好ましい。８ビットのCLUT は前述したように、ビューのすべてと共有しなければならない。 従って、好適オペレーティング・システムにおけるパレット管理は、あらかじ め決めたビット数をもつ１つのシステムCLUTを分割することを中心思想としてい る。そのようにすると、あるドキュメント（例えば、複合ドキュメント）内のす べてのビューが調和的に、統一的にカラーを共有できるからである。本発明によ れば、グレー構成とカラー構成を共にサポートしなければならないので、本発明 では、あらかじめ決めた数のグレーを選択して、カラーが存在するときでもグレ ー間の移行が円滑になるようにしている。さらに、選択されるグレーは純粋なグ レーであることが好ましい。グレーのシェード（陰影）は、人間の目が比較的に 簡単に検出できるのでグレーに近くない方がよい。例えば、使用するグレーのシ ェードはほぼ24位にすることが好ましい（この中には、下述するようにカラーと 数えられる６個は含まれていない）。 以上説明したように、本発明によれば、取り扱うのに好ましいカラー数は232 個（例えば、256 - 24 = 232）になっている。実用上の理由から（例えば、スク リーン上のイメージをレンダリング(rendering)するスピードとの関係から）、 色域は均等に分割すべきである。例えば、赤のシェードが６、緑のシェードが６ 、青のシェードが６であれば、カラーの組合せは6*6*6 = 216種類になる。オリ ジナルの256 - 24- 216カラーのうち、16カラーは残されている。残された16カ ラーは、複数のグラフィック・デバイスに共通して統一的に現れるように選択す ることが好ましい。さらに、プログラミング環境では、これらの16カラーをユニ ークにしておくことが好ましい。そうすれば、値でなく名前で参照できるからで ある。例えば、これらのカラーのうち２つは、Taligent社のTeal(Pantone 4125 C)とPurple（2735 C）（Taligent社の商標）で使用されているものと同じにする ことが好ましい。 本発明の特徴の１つは、本発明によるカラー・パレット管理システムを使用す る開発者にある程度の自由度が与えられることである。例えば、開発者によって は、基礎となるCLUTを変更したい場合が起こるかもしれない。その場合、本発明 によれば、フック(hook)を作ることによって開発者は新しいグラフィック・デバ イスを作成し、256カラーからなる独自のセットを選択できるようにする機能が 用意されている。この機能は好適オペレーティング・システムが稼働していると きでも可能である。さらに、本発明によれば、開発者はカラー・モニタ・デバイ スでガンマ(Gamma)テーブルを変更することができ、それを可能にする機能も本 発明に用意されている。 以上を要約して説明すると、本発明によれば、オペレーティング・システム上 に常駐する柔軟性に富んだ汎用目的の８ビットCLUTを選択することによりカラー ・パレット管理を行うことができる。フックはモニタの２ビットと４ビットのカ ラーCLUT用に用意されているが、これらは実装されていない。２ビットと４ビッ トのオフスクリーン(off-screen)CLUTは完全に実装されている。８ビットのグレ ーCLUTは実装される予定である。８ビットCLUTを変更するためのフックも用意さ れているが、これらは実装されていない。ガンマ・テーブル・コントロールが実 装されており、名前付きカラー（例えば、１６カラー）がサポートされている。 従って、本発明によるカラー・パレット管理システムはアプリケーション開発者 によってカストマイズすることができる。これがオペレーティング・システム内 のフレームワークと呼ばれるのは、開発者が用意されたフックを使用して基礎と なるCLUTを変更して、新しいグラフィック・デバイスを作成し、独自の256カラ ーを選択できるからである。 以上、単一の好適実施例を参照して本発明を説明してきたが、この分野に精通 したものならば理解されるように、本発明は請求の範囲に明確化されている本発 明の精神と範囲内で実施することが可能である。

【手続補正書】特許法第１８４条の８ 【提出日】１９９５年８月２９日 【補正内容】 （原文明細書第２頁） カラー・モニタの表示面上の各ピクセルは、赤の蛍光体(phosphor)、緑の蛍光体 および青の蛍光体を含んでいる。各蛍光体はモニタが再現できるカラーを決める 物理的特性をもっている。これらの３つの蛍光体と電子ビーム銃の最大等輝度(m aximum equal intensity)により、モニタの色域(color gamut)が決まっている。 しかし、理論的には、どのカラーがこのデバイスから物理的に得られるかはモニ タの蛍光体によって決まるが、実用上は、各モニタが再現できるカラーの数には 制約がある。例えば、コンピュータはディジタル（アナログとは反対）の世界で 動作するので、モニタが実際に再現できるカラーの数は有限数に限られている。 モニタが再現できるカラーの数が増加していくと、スクリーン（表示画面）のデ ィジタル・イメージをストアしておくためのメモリがそれに伴って増加していく 。スクリーンをストアするメモリはビデオ・カード上に実装されているのが通常 である。 メモリ・コストの関係から、従来、開発者はモニタの色域のうちオペレーショ ンに必要な部分を動的に設定していた。このアプローチでは、カラー・ルックア ップ・テーブル(Color Look Up Table - CLUT)が使用されている。カラー・パレ ットはアプリケーション内のウィンドウまたはアプリケーション自体のどちらか と選択的に関連づけられていた。ある開発されたパレット管理システムでは、カ ラーがウィンドウからでも、アプリケーションからでも要求できるようになって いる。どちらのタイプの要求を行うかによって、カラーが親しみやすい方法で共 有できる場合と、親しみにくい方法で共有できる場合とがあった。アクティブ（ 活動状態の）ウィンドウまたはアプリケーションが変更されたときは、パレット ・マネージャは元のアクティブ・パレットから新しいパレットへの移行を、ユー ザが見たとき（視覚的に）できるかぎり親しみやすくなるように行っていた。カ ラー・パレットを定義する多次元空間でのカラーを管理する方法が欧州特許(EPO )第404,398号に教示されている。さらに従来のカラー・ラスタ・ディスプレイ・ システム用のカラー・ルックアップ・テーブル(CLUT)がディ・エッチ・ストラー ヤ著、コンピュータ・デザイン第21巻第７号123〜130ペー ジ、1982年７月刊(Computer Design，Vol.21，No.7，July 1982，pp123-130 by D.H.Straayer)に開示されている。 しかるに、従来のオペレーション・システムでは、CLUTをアプリケーションま たはウィンドウと関連づけることが相対的に容易になっているが、好適なオペレ ーティング・システムでは、このような関連づけにいくつかの問題がある。 発明の概要 従って、本発明の目的は、ビュー(view)が調和のとれた方法で、しかも視覚的 に親しみやすい方法でカラーを共有することができる新規なカラー・パレット管 理方法とシステムを提供することであり、本発明の方法とシステムは、アセンブ ルされてさらに大きなドキュメントになる多くのエンカプスレータ(encapsulato r)からなる複合ドキュメント(compound document)を含むオペレーティング・シ ステムで使用される。本発明は、CLUTとビューとを関連つけ、カラーを共有する 異なる考え方を提供している。 本発明の一側面では、オブジェクト指向オペレーティング・システム用にカラ ー・パレットを管理する方法は、オペレーティング・システム用にカラー・ルッ クアップ・テーブル(CLUT)を作成し、CLUTをあらかじめ決めた数のカラーに均等 に分割し、複数のビューをもつグラフィック情報を表示し、CLUT内のあらかじめ 決めた数のカラーをグラフィック情報の複数のビュー間で共有するステップから なり、 （原文明細書第１３頁） 独自の256カラーを選択できるからである。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，Ｍ Ｃ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ， ＴＤ，ＴＧ)，ＡＴ，ＡＵ，ＢＢ，ＢＧ，ＢＲ，ＢＹ， ＣＡ，ＣＨ，ＣＮ，ＣＺ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，Ｇ Ｂ，ＨＵ，ＪＰ，ＫＰ，ＫＲ，ＫＺ，ＬＫ，ＬＵ，ＬＶ ，ＭＧ，ＭＮ，ＭＷ，ＮＬ，ＮＯ，ＮＺ，ＰＬ，ＰＴ， ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＫ，ＵＡ，ＵＺ，ＶＮ

Claims (1)

1. 【特許請求の範囲】 １．接続されたディスプレイ・デバイスを備えたコンピュータのメモリに置かれ たカラー・パレットを管理する方法であって、メモリにはオブジェクト指向オペ レーティング・システムが収容されているものにおいて、 （a）オペレーティング・システム用にカラー・ルックアップ・テーブル(CLUT )を作成し、 （b）CLUTをあらかじめ決めた数のカラーに分割し、 （c）複数のビューをもつグラフィック情報を表示し、 （d）CLUT内のあらかじめ決めた数のカラーをグラフィック情報の複数のビュ ー間で共有するステップからなり、あらかじめ決めた数のカラーは複数のカラー を含み、その各々が複数のビューの第１と第２のビュー間で共有されたとき、あ らかじめ決めた統一性をもっていることを特徴とする方法。 ２．請求の範囲第１項に記載の方法において、コンピュータのメモリに置かれた あらかじめ決めた数のカラーの一定方式のシェードをもつCLUTを作成するステッ プを含むことを特徴とする方法。 ３．請求の範囲第１項に記載の方法において、第１の参照CLUTに基づいて第２の CLUTを作成するためのデバイスを作成するステップを含み、第２のCLUTはコンピ ュータのメモリ内でカストマイズ可能であることを特徴とする方法。 ４．請求の範囲第１項に記載の方法において、コンピュータのメモリに置かれた CLUT内の複数のカラーのあらかじめ決めた数のシェードを定義するステップを含 むことを特徴とする方法。 ５．請求の範囲第１項に記載の方法において、カラーはコンピュータのメモリに 置かれた赤、緑、青およびグレーを含むことを特徴とする方法。 ６．請求の範囲第１項に記載の方法において、解像度が８ビットのCLUTをコンピ ュータのメモリに用意するステップを含むことを特徴とする方法。 ７．請求の範囲第１項に記載の方法において、解像度が16ビットのCLUTをコンピ ュータのメモリに用意するステップを含むことを特徴とする方法。 ８．請求の範囲第１項に記載の方法において、解像度が64ビットのCLUTをコンピ ュータのメモリに用意するステップを含むことを特徴とする方法。 ９．請求の範囲第１項に記載の方法において、解像度が128ビットのCLUTをコン ピュータのメモリに用意するステップを含むことを特徴とする方法。 10．請求の範囲第１項に記載の方法において、複数のビューを複合ドキュメント 内に用意するステップを含み、複合ドキュメントは複数のアプリケーションが複 合ドキュメント内にアセンブルされている複数のエンカプセルレータからなり、 エンカプセルレータの各々はコンピュータのメモリに置かれたそれぞれのビュー 内にあることを特徴とする方法。 11．請求の範囲第１項に記載の方法において、グラフィック情報をそのガンマ・ テーブルと関連づけてディスプレイから表示するステップを含むことを特徴とす る方法。 12．請求の範囲第11項に記載の方法において、コンピュータのメモリに置かれた ガンマ・テーブルを修正しておき、そのあとでディスプレイから表示するための ステップを含むことを特徴とする方法。 13．請求の範囲第12項に記載の方法において、ガンマ・テーブルをコンピュータ のメモリにストアするステップを含むことを特徴とする方法。 14．接続されたディスプレイ・デバイスを備えたコンピュータのメモリに置かれ たカラー・パレットを管理する装置であって、メモリにはオブジェクト指向オペ レーティング・システムが収容されているものにおいて、 （a）オペレーティング・システム用のカラー・ルックアップ・テーブル(CLUT )を作成する手段と、 （b）CLUTをあらかじめ決めた数のカラーに分割する手段と、 （c）複数のビューをもつグラフィック情報を表示する手段と、 （d）CLUT内のあらかじめ決めた数のカラーをグラフィック情報の複数のビュ ー間で共有する手段とを備え、あらかじめ決めた数のカラーは複数のカラーを含 み、その各々が複数のビューの第１と第２のビュー間で共有されたとき、あらか じめ決めた統一性をもっていることを特徴とする装置。 15．請求の範囲第14項に記載の装置において、コンピュータのメモリに置かれた あらかじめ決めた数のカラーの一定方式のシェードをもつCLUTを作成する手段を 含むことを特徴とする装置。 16．請求の範囲第14項に記載の装置において、第１の参照CLUTに基づいて第２の CLUTを作成するためのデバイスを作成する手段を含み、第２のCLUTはコンピュー タのメモリ内でカストマイズ可能であることを特徴とする装置。 17．請求の範囲第14項に記載の装置において、コンピュータのメモリに置かれた CLUT内の複数のカラーのあらかじめ決めた数のシェードを定義する手段を含むこ とを特徴とする装置。 18．請求の範囲第14項に記載の装置において、カラーはコンピュータのメモリに 置かれた赤、緑、青およびグレーを含むことを特徴とする装置。 19．請求の範囲第14項に記載の装置において、解像度が８ビットのCLUTをコンピ ュータのメモリに用意する手段を含むことを特徴とする装置。 20．請求の範囲第14項に記載の装置において、解像度が16ビットのCLUTをコンピ ュータのメモリに用意する手段を含むことを特徴とする装置。 21．請求の範囲第14項に記載の装置において、解像度が64ビットのCLUTをコンピ ュータのメモリに用意する手段を含むことを特徴とする装置。 22．請求の範囲第14項に記載の装置において、解像度が128ビットのCLUTをコン ピュータのメモリに用意する手段を含むことを特徴とする装置。 23．請求の範囲第14項に記載の装置において、複数のビューを複合ドキュメント 内に用意する手段を含み、複合ドキュメントは、複数のアプリケーションが複合 ドキュメント内にアセンブルされている複数のエンカプセルレータからなり、エ ンカプセルレータの各々はコンピュータのメモリに置かれたそれぞれのビュー内 にあることを特徴とする装置。 24．請求の範囲第14項に記載の装置において、グラフィック情報をそのガンマ・ テーブルと関連づけてディスプレイから表示する手段を含むことを特徴とする装 置。 25．請求の範囲第24項に記載の装置において、コンピュータのメモリに置かれた ガンマ・テーブルを修正しておき、そのあとでディスプレイから表示するための 手段を含むことを特徴とする装置。 26．請求の範囲第25項に記載の装置において、ガンマ・テーブルをコンピュータ のメモリにストアする手段を含むことを特徴とする装置。 27．接続されたディスプレイを備えたコンピュータのメモリに置かれているカラ ー・パレットを、オブジェクト指向オペレーティング・システムで使用すること を目的に管理するフレームワークであって、 （a）グラフィカル情報をディスプレイから表示する手段であって、該グラフ ィカル情報は複数のビューを含んでいるものと、 （b）オペレーティング・システム用のカラー・ルックアップ・テーブル(CLUT )をコンピュータのメモリ内に作成する手段と、 （c）コンピュータのメモリ内でCLUTをあらかじめ決めた数のカラーに均等に 分割する手段と、 （d）CLUT内のあらかじめ決めた数のカラーをグラフィック情報の複数のビュ ーの間で共用する手段とを備え、あらかじめ決めた数のカラーは複数のカラーを 含み、その各々は複数のビューの第１ビューと第２ビューの間で共有されたとき あらかじめ決めた統一性をもっており、CLUTを作成する手段は、表示されている グラフィカル情報を表しているデータを変更するために各々がアクセスされるよ うに複数のプログラマ定義のコンポーネントを設定する手段を含み、ユーザ定義 のコンポーネントはプログラマが望むとおりにオブジェクト指向フレームワーク 内で選択的に交換可能であることを特徴とするフレームワーク。