(57)【要約】      （修正有）【課題】コンポーネントとカラー管理システムとの間においてレガシアプリケーションプログラミングインターフェース（ＡＰＩ）セットをサポートする方法およびデバイスを提供する。【解決手段】レガシＡＰＩセットは、新しい機能ならびにレガシ機能の両方をサポートする。カラー管理システムは、ＡＰＩコールによって参照されるオブジェクトのフォーマットタイプを決定する。オブジェクトがレガシフォーマットに関連付けられる場合、ＡＰＩコールは、レガシ処理モジュールによって処理される。オブジェクトが先進のフォーマットに関連付けられる場合、ＡＰＩコールは、先進の処理モジュールによって処理される。複数のオブジェクトが、混合フォーマットを有するＡＰＩコールに関連付けられる場合、カラー管理システムは、オブジェクトが一貫したフォーマットを有するように、オブジェクトのいくつかを変換する。【選択図】図４
2011248908.tif 000002
【特許請求の範囲】
【請求項１】
１または複数のプロセッサと、カラー管理システムにコンポーネントからのカラー管理要求をサポートさせるように前記１または複数のプロセッサを介して実行可能なモジュールを格納したメモリとを備えたカラー管理システムであって、前記モジュールは、
コンポーネントから前記要求を受け取るアプリケーションプログラムインターフェース（ＡＰＩ）レイヤモジュールであって、前記要求がプロファイルに対応するオブジェクトおよび前記オブジェクトの要求された要素に関して行うカラー管理オペレーションを識別する、ＡＰＩレイヤモジュールと、
前記ＡＰＩレイヤモジュールから前記要求を得て、前記要求を分析して前記オブジェクトに対応する前記プロファイルがレガシーフォーマットと関連付けられているか、先進フォーマットと関連付けられているかを判定するＡＰＩアダプテーションレイヤモジュールと、
前記オブジェクトに対応する前記プロファイルが前記レガシーフォーマットと関連付けられている場合、前記要求を処理するレガシー処理モジュールと、
前記オブジェクトに対応する前記プロファイルが前記先進フォーマットと関連付けられている場合、前記要求を処理する先進処理モジュールとを備え、
前記ＡＰＩレイヤモジュールは、前記要求に対する応答を返し、前記応答は、
前記要求された要素が前記プロファイルの判定されたフォーマットとコンパチブルであるとき、前記要求された要素に関する前記オペレーションの結果を返し、
前記要求された要素が前記プロファイルの判定されたフォーマットとコンパチブルでなく、異なる要素が利用可能であるとき、前記要求された要素に合致すると判定された前記プロファイルの異なる要素に関する前記オペレーションの結果を返す
ように構成されていることを特徴とするカラー管理システム。
【請求項２】
請求項１に記載のカラー管理システムであって、前記オブジェクトを表すように構成された前記レガシーフォーマットおよび前記先進フォーマットとコンパチブルな共通構造をさらに備えたことを特徴とするカラー管理システム。
【請求項３】
請求項２に記載のカラー管理システムであって、別のオブジェクトを表すように構成された前記レガシーフォーマットおよび前記先進フォーマットとコンパチブルな別の共通構造をさらに備えたことを特徴とするカラー管理システム。
【請求項４】
請求項２に記載のカラー管理システムであって、前記共通構造は、前記オブジェクトの要素を識別するハンドルを利用することを特徴とするカラー管理システム。
【請求項５】
請求項２に記載のカラー管理システムであって、前記ＡＰＩアダプテーションレイヤモジュールは、前記オブジェクトに対応する前記プロファイルについて判定された前記フォーマットに従って前記オブジェクトを表す前記共通構造を変更することを特徴とするカラー管理システム。
【請求項６】
請求項１に記載のカラー管理システムであって、前記ＡＰＩアダプテーションレイヤモジュールは、別のオブジェクトが前記先進フォーマットと関連付けられている場合、前記オブジェクトを前記レガシーフォーマットから前記先進フォーマットに変換することを特徴とするカラー管理システム。
【請求項７】
請求項１に記載のカラー管理システムであって、前記応答は、前記要求された要素が前記判定されたフォーマットとコンパチブルでなく、前記異なる要素が利用可能でないとき、エラーを返すようにさらに構成されていることを特徴とするカラー管理システム。
【請求項８】
請求項１に記載のカラー管理システムであって、前記アプリケーションプログラムインターフェース（ＡＰＩ）レイヤモジュールは、前記オブジェクトおよび前記要求された要素に関して行う前記カラー管理オペレーションを識別する１または複数のパラメータが入ったＡＰＩコールとして前記要求を受け取ることを特徴とするカラー管理システム。
【請求項９】
請求項８に記載のカラー管理システムであって、前記１または複数のパラメータは、前記オブジェクトを識別するポインタを備えたことを特徴とするカラー管理システム。
【請求項１０】
カラー管理システムの１または複数のコンピューティングデバイスによって行われるアプリケーションプログラムインターフェース（ＡＰＩ）に対するカラー管理コールをサポートする方法であって、
コンポーネントから要求を受け取ることであって、前記要求がプロファイルに対応するオブジェクトおよび前記オブジェクトの要求された要素に関して行うカラー管理オペレーションを識別することと、
前記要求を分析して、前記オブジェクトに対応する前記プロファイルがレガシーフォーマットと関連付けられているか、先進フォーマットと関連付けられているかを判定することと、
前記オブジェクトに対応する前記プロファイルが前記レガシーフォーマットと関連付けられている場合、前記要求を処理するレガシー処理モジュールを呼び出し、
前記オブジェクトに対応する前記プロファイルが前記先進フォーマットと関連付けられている場合、前記要求を処理する先進処理モジュールを呼び出す、
ことによって前記要求を処理することと、
前記要求された要素が前記プロファイルの判定されたフォーマットとコンパチブルであるとき、前記要求された要素に関する前記オペレーションの結果を返すことと、
前記要求された要素が前記プロファイルの判定されたフォーマットとコンパチブルでないとき、前記要求された要素に合致する前記プロファイルからの異なる要素の利用可能性を判定し、前記異なる要素が利用可能であるとき、前記プロファイルの前記異なる要素に関する前記オペレーションの結果を返すことと
を備えることを特徴とする方法。
【請求項１１】
請求項１０に記載の方法であって、
前記要求された要素が前記判定されたフォーマットとコンパチブルでなく、前記異なる要素が利用可能でないとき、エラーを返すことをさらに備えることを特徴とする方法。
【請求項１２】
請求項１１に記載の方法であって、
前記オブジェクトに対応する前記プロファイルについて判定された前記フォーマットに従って前記オブジェクトを表す共通構造を変更することであって、前記共通構造が前記レガシーフォーマットおよび前記先進フォーマットを収容することをさらに備えることを特徴とする方法。
【請求項１３】
請求項１２に記載の方法であって、受け取ることは、
前記オブジェクトおよび前記要求された要素に関して行う前記カラー管理オペレーションを識別する１または複数のパラメータが入ったアプリケーションプログラムインターフェース（ＡＰＩ）コールとして前記要求を受け取ることを備えることを特徴とする方法。
【請求項１４】
コンピューティングデバイスによって実行されるとき、
コンポーネントからアプリケーションプログラムインターフェース（ＡＰＩ）コールとしてカラー管理要求を受け取ることであって、前記ＡＰＩコールがプロファイルに対応するオブジェクトおよび前記オブジェクトの要求された要素に関して行うカラー管理オペレーションを識別するパラメータを含むことと、
前記オブジェクトを分析して、前記オブジェクトに対応する前記プロファイルがレガシーフォーマットに対応するか、先進フォーマットに対応することを判定することと、
前記オブジェクトに対応するプロファイルが前記レガシーフォーマットと関連付けられている場合、前記ＡＰＩコールを処理するレガシー処理モジュールを呼び出すことと、
前記オブジェクトに対応するプロファイルが前記先進フォーマットと関連付けられている場合、前記ＡＰＩコールを処理する先進処理モジュールを呼び出すことと、
前記オブジェクトに対応する前記プロファイルについて判定された前記フォーマットに従って前記オブジェクトを表す共通構造を変更することであって、前記共通構造が前記レガシーフォーマットおよび前記先進フォーマットを収容することと、
ＡＰＩ応答を返すことであって、
前記要求された要素が前記プロファイルの判定されたフォーマットとコンパチブルであるとき、前記要求された要素に関する前記オペレーションを行い、前記要求された要素に関する前記オペレーションの結果を返すことと、
前記要求された要素が前記プロファイルの判定されたフォーマットとコンパチブルでないとき、前記要求された要素に合致する前記プロファイルの異なる要素が利用可能であるときを判定し、前記異なる要素が利用可能であるとき、前記異なる要素に関する前記オペレーションを行い、前記異なる要素に関する前記オペレーションの結果を返すか、前記異なる要素が利用可能でないとき、エラーを返すことと
を含むアクトを前記コンピューティングデバイスに行わせるコンピュータ実行可能命令を格納した１または複数のコンピュータ可読記憶媒体。
【請求項１５】
請求項１４に記載の１または複数のコンピュータ可読記憶媒体であって、分析することは、
前記オブジェクトが前記レガシーフォーマットと関連付けられ、別のオブジェクトが前記先進フォーマットに関連付けられる場合、前記別のオブジェクトが前記ＡＰＩコールに含まれた別のパラメータによって識別され、前記オブジェクトを前記先進フォーマットとコンパチブルであるように変換することを備えることを特徴とする１または複数のコンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、２００３年１１月１０日に出願された米国特許出願第１０／７０５，１３２号明細書、「Color Management System That Supports Legacy and Advanced Color Management Applications」（整理番号００３７９７．００７００）に対する優先権を主張し、参照によって本明細書に組み込まれる。
【０００２】
本発明は、コンピュータシステムのカラー管理技術に関し、特に、先進のカラー管理能力をサポートするレガシアプリケーションプログラムインターフェース（ＡＰＩ）の互換性を提供する。
【背景技術】
【０００３】
従来の技術によってサポートされる１入力１出力のワークフローでは、カラー管理は、通常、必要ではなかった。画像は、通常、単一の出力デバイスに同調されるシアン、マゼンタ、黄、および黒（ＣＭＹＫ）のフォーマットなどのカラー表示を生成する単一のスキャナを使用して、専門オペレータによってスキャンされた。スポットカラーは、スポットインクを混合することによって、または見本ブックの標準的なＣＭＹＫ配合を使用することによって扱われた。精確なモニタ表示デバイスは、通常、利用可能ではなかった。システムは機能したが、その理由は、スキャナが生成したＣＭＹＫ値が出力デバイスに同調されて、１セットの数を扱う閉ループを形成したからである。
【０００４】
より最近では、入力デバイスおよび出力デバイスのタイプは、劇的に増加した。入力デバイスは、ハイエンドのドラムスキャナだけでなく、ハイエンドのフラットベッドスキャナ、デスクトップのフラットベッド、デスクトップのスライドスキャナ、およびデジタルカメラをも含む。出力デバイスは、無水インク、ソイインク、直接プレート印刷、およびハイファイカラーによるウェブおよびシートフィードプレスだけでなく、デジタルプルーファ、フレキソグラフィ、フィルムレコーダ、シルクスクリーナ、カラーコピー、レーザプリンタ、インクジェットプリンタ、およびさらには最終出力デバイスとして機能するモニタをも含む。入力デバイスおよび出力デバイスの多様性は、以前に議論された閉ワークフローのアプローチを非常に複雑にする。それゆえ、可能なワークフローは、入力デバイスから出力デバイスへの多対多マッピングに関連付けることができる。
【０００５】
その結果、入力デバイスから出力デバイスへの可能な変換の数は、潜在的に膨大となる。ｍ入力からｎ出力のワークフローでは、入力から出力へのｍ×ｎの異なる変換を必要とする可能性がある。入力デバイスおよび出力デバイスの多様性の増大と共に、入力から出力に望ましいカラー変換を提供するタスクは、容易に管理不可能となることがある。
【０００６】
カラー管理は、様々な入力デバイスおよび出力デバイスの組合せの間においてサポートすることができる様々なワークフローを管理するソリューションである。カラー管理は、通常、望ましいカラーの中間表現をサポートする。中間表現は、プロファイル接続空間（ＰＣＳ）と一般に呼ばれ、代替として作業域と呼ぶこともある。プロファイル接続空間の機能は、複数のデバイスからデバイス変換のハブとして作用することである。そのようなアプローチでは、ｍ×ｎリンクの問題は、ｍ＋ｎリンクに低減され、この場合、単に１つのリンクが、各デバイスに必要とされる。各リンクは、デバイスのカラー再生動作を有効に記述する。リンクは、デバイスプロファイルと一般に呼ばれる。デバイスプロファイルおよびプロファイル接続空間は、カラー管理システムにおける４つの枢要な構成要素のうちの２つである。
【０００７】
現行の国際カラーコンソーシアム（ＩＣＣ）の使用に基づくように、カラー管理システムの４つの基本的な構成要素は、プロファイル接続空間、１セットのプロファイル、カラー管理モジュール（ＣＭＭ）、およびレンダリングインテントである。プロファイル接続空間により、カラー管理システムは、カラーを再生するために使用される複数のデバイスの癖に依存せず、代わりに、そのカラーを実際に人が見る際のカラーを定義するＣＩＥ  ＸＹＺカラースペースまたはＣＩＥ  ＬＡＢカラースペースにおいて、明瞭な数値カラーを与えることが可能になる。（ＣＩＥ  ＸＹＺおよびＣＩＥ  ＬＡＢの両方とも、デバイスに独立なものとしてモデリングされているカラースペースである）。プロファイルは、デバイスのＲＧＢ（赤、緑、および青）制御信号またはＣＭＹＫ制御信号とその制御信号によって生成される実際のカラーとの関係を記述する。具体的には、プロファイルは、与えられた１セットのＲＧＢ数またはＣＭＹＫ数に対応するＣＩＥ  ＸＹＺ値またはＣＩＥ  ＬＡＢ値を定義する。カラー管理モジュール（ＣＭＭ）は、カラー管理システムのエンジンとしばしば呼ばれる。カラー管理モジュールは、ＲＧＢ値またはＣＭＹＫ値を変換するために必要とされるすべての計算を実行するソフトウェアの１つである。カラー管理モジュールは、プロファイルに含まれるカラーデータと共に作用する。レンダリングインテントは、４つの異なるレンダリングインテントを含む。レンダリングインテントの各タイプは、「色域外」カラーに対処する異なる方式であり、この場合、出力デバイスは、ソース空間に存在するカラーを再生することが物理的にできない。
【０００８】
ワークフローがより複雑になるにつれ、カラー管理は、画像ファイルが入力（例えば、スキャナ）から出力（例えば、プリンタ）に流れる際に画像ファイルのカラーを管理するユーザにとってより重要になる。ワークフローは、カラーの意味の定義、カラーの正規化、カラーの変換、およびプルーフィングを含むカラー管理の４つの段階を使用する。カラーの意味を定義することは、プロファイルがコンテンツに埋め込まれているかを判定することと、埋込みプロファイルが存在しない場合にプロファイルを定義することとを含む。次いで、ワークフローは、作業域（デバイス独立のカラースペースに対応する）に対してカラーを正規化するか、または画像ファイルのカラー表示を宛先空間に直接変換することができる。カラーが作業域に正規化される場合、オペレーションは、作業域において実行され、例えば、ユーザは、作業域において選択カラーを修正する。次いで、カラー管理システムは、作業域からの共通値を使用して、ソースプロファイルおよび宛先プロファイルから変換表を決定することができる。その結果、カラー管理システムは、変換表を使用して、ソース画像を宛先画像に変換することができる。
【０００９】
顕著な努力、リソース、およびお金を、オペレーティングシステムによってサポートされるカラー管理の機能を利用するアプリケーションに投資することができる。この場合、アプリケーションは、アプリケーションプログラムインターフェース（ＡＰＩ）を使用して、これらの機能を利用する。市場で競争力があり、ユーザによる要求を満たすために、カラー管理システムを改訂して、アプリケーションによって利用することができる新しい機能を追加することができる。しかし、アプリケーションが、レガシ機能についてすでにレガシＡＰＩセットを使用しており、先進のＡＰＩセットがレガシＡＰＩセットに準拠していない場合、レガシアプリケーションが、新しい機能および改良にアクセスするために先進のＡＰＩセットをサポートすることは、通常望ましくない。そのようにするためには、アプリケーションを改訂する多大な努力およびコストを必要とする。
【発明の概要】
【発明が解決しようとする課題】
【００１０】
従来の技術では、カラー管理のソリューションは、対応する新しいＡＰＩセットを有するカラー管理システムの新バージョンが導入されるとき、レガシアプリケーションまたはソリューションを通常サポートしない。カラー管理システムの新バージョンは、レガシを変更および／または尾ひれをつけることによって、あるいはレガシＡＰＩセットを先進のＡＰＩセットで置き換えることによって、新しい機能、改良、および解決（修繕）をレガシバージョンの問題に提供することが可能である。そのような場合、レガシアプリケーションは、先進のＡＰＩセットとコンパチブルではない可能性があり、それゆえ、カラー管理システムの新バージョンとコンパチブルではない可能性がある。一方、カラー管理システムがレガシＡＰＩセットおよび先進のＡＰＩセットの両方をサポートすることは、開発およびメインテナンスの問題を考慮すると、困難でコストがかかる可能性がある。レガシＡＰＩと新しいカラー管理ソリューションとの互換性を提供することが当技術分野における進展である。
【課題を解決するための手段】
【００１１】
本発明は、コンポーネント（例えば、アプリケーション）とシステム（例えば、カラー管理システム）との間においてレガシアプリケーションプログラミングインターフェース（ＡＰＩ）セットをサポートする方法および装置を提供する。システムによって提供される新しい機能および改良により、レガシＡＰＩセットは、新しい機能および改良の両方、ならびにレガシ機能をサポートする。その結果、システムソフトウェアの更新および維持は容易になるが、その理由は、複数のＡＰＩセットではなく、レガシＡＰＩセットのみをサポートすればよいからである。さらに、レガシアプリケーションは、レガシＡＰＩセットを使用してシステムと対話することができる。
【００１２】
本発明の一態様では、カラー管理システムは、レガシＡＰＩセットでレガシアプリケーションおよび先進のアプリケーションの両方をサポートすることができる。カラー管理システムは、ＡＰＩコールによって参照されるオブジェクトについてフォーマットのタイプを決定する。オブジェクトがレガシフォーマットに関連付けられる場合、ＡＰＩコールは、レガシ処理モジュールによって処理される。オブジェクトが先進のフォーマットに関連付けられる場合、ＡＰＩコールは、先進の処理モジュールによって処理される。
【００１３】
本発明の他の態様では、複数のオブジェクトがＡＰＩコールに関連付けられ、複数のオブジェクトが混合したフォーマットを有する場合、カラー管理システムは、オブジェクトのフォーマットが一貫するように、オブジェクトのいくつかを変換する。次いで、カラー管理システムは、一貫フォーマットを有するオブジェクトについて要求されたオペレーションを実行する。
【００１４】
本発明の他の態様では、共通構造が、レガシフォーマットまたは先進のフォーマットをサポートするために別々の構造を要求するのではなく、レガシフォーマットまたは先進のフォーマットのいずれかを有することが可能であるオブジェクトをサポートする。
【図面の簡単な説明】
【００１５】
【図１】本発明を実施することができる適切なコンピューティングシステム環境の一例を示す図である。
【図２】本発明の一実施形態によってサポートされる国際カラーコンソーシアム（ＩＣＣ）のプロファイルを示す図である。
【図３】本発明の一実施形態によってサポートされる仮想デバイスモデルプロファイルを示す図である。
【図４】本発明の一実施形態によるカラー管理システムのアーキテクチャを示す図である。
【図５】本発明の一実施形態に従って要求コンポーネントが中間コンポーネントを通してカラー管理システムへのＡＰＩコールを呼び出すことを示す図である。
【図６】本発明の一実施形態に従ってソース画像ドキュメントから宛先画像ドキュメントへカラー情報を変換するカラー管理システムのアーキテクチャを示す図である。
【図７】本発明の一実施形態に従って画像ドキュメントを処理する共通構造を使用するカラー管理システムのアーキテクチャを示す図である。
【図８】本発明の一実施形態に従ってＧＥＴ／ＳＥＴ  ＡＰＩカテゴリを処理する流れ図である。
【図９】第１コードセグメントおよび第２コードセグメントが通信するコンジットとしてのインターフェースを示す図である。
【図１０】インターフェースオブジェクトを備えるインターフェースを示す図である。
【図１１】インターフェースの通信を複数のインターフェースに変換するためにさらに分割することができるインターフェースによって提供される機能を示す図である。
【図１２】図１１に示される機能と同じ結果を達成するために、複数のインターフェースにさらに分割することができるインターフェースによって提供される機能を示す図である。
【図１３】プログラミングインターフェースの態様を無視、追加、または再定義する一方、依然として同じ結果を達成する例を示す図である。
【図１４】プログラミングインターフェースの態様を無視、追加、または再定義する一方、依然として同じ結果を達成する他の例を示す図である。
【図１５】図９に示される例に関連してコードセグメントをマージすることを示す図である。
【図１６】図１０に示される例に関連してコードセグメントをマージすることを示す図である。
【図１７】通信を変換して、異なるインターフェースに準拠するミドルウェアを示す図である。
【図１８】分離インターフェースに関連付けられるコードセグメントを示す図である。
【図１９】オペレーティングシステムが変更されて異なるインターフェースを使用するインターフェースプロトコルに従って、アプリケーションのインストールベースがオペレーティングシステムと通信するように設計される例を示す図である。
【図２０】インターフェースを書き直して、インターフェースを動的にファクタ化するか、そうでなければインターフェースを変更することを示す図である。
【発明を実施するための形態】
【００１６】
様々な実施形態の以下の記述において、その一部を形成し、本発明を実行することができる様々な実施形態が例として示される添付の図面を参照する。本発明の範囲から逸脱せずに、他の実施形態を使用することができ、構造上および機能上の修正を実施することができることを理解されたい。
【００１７】
以下の用語の定義は、詳細な記述の理解を容易にするために含められている。
【００１８】
・  チャネル−画像は、情報の１つまたは複数の「チャネル」を含む。一般に、カラーは、加法混合の原色（赤、緑、および青）によって表される。これらの３色のそれぞれのカラー情報は、それ自体のチャネルに符号化される。チャネルは、ＲＧＢに限定されず、チャネルは、ルミナンス（輝度）チャネルおよびクロミナンス（彩度）チャネル、または他のさらにより新奇な方式に分類することができる。チャネルを使用して、透明度など、カラー以外のものを符号化することもできる。画像のカラー品質の尺度は、チャネルあたりの符号化するために使用されるビット数（ｂｐｃｈ）である。
【００１９】
・  クリッピング−ソースデータの２つの異なる値が、宛先データの同じ値にマッピングされるたびに、値はクリッピングされると言われる。これは重要であるが、その理由は、クリッピングされたデータが元の状態に復元することができないからである（情報は失われる）。輝度またはコントラストの変更などのオペレーションは、データをクリッピングする可能性がある。
【００２０】
・  カラー管理−カラー管理は、１つのデバイスによって記録されたカラーが、異なるデバイスにおいてユーザの好みに可能な限り忠実に表されることを保証するプロセスであり、しばしば、これはあるデバイス上の知覚を他へ整合させる。イメージングデバイスのセンサは、人の目と比較するとき、人の目が捉えることができるすべてのカラーおよびダイナミックレンジを捉える能力が限定されている。同じ問題が、表示デバイスおよび出力デバイスの両方に関して起きる。問題は、デバイスのすべての３つのクラスがこれらのカラーおよびダイナミックレンジの限定を有するが、そのいずれもまったく同じ形では限定されないことである。したがって、情報がワークフローを進む際に、変換「規則」をセットアップして、すでに限定されたカラーおよびダイナミックレンジの情報を可能な限り保存し、ならびに情報が人の目に可能な限り現実的であることを保証しなければならない。
【００２１】
・  カラースペース−センサは、カラーを検出および記録することが可能であるが、未加工の電圧値は、基準がない場合、まったく意味をなさない。基準スケールは、センサ自体の測定された能力とすることができ、センサが特定の周波数応答スペクトルを有すると測定される場合、生成される数字は意味を有することになる。しかし、人の目によって可視であるすべてのカラーを表す共通の基準の方がより有用である。そのような基準（ＣＩＥ  ＬＡＢとして知られるカラースペース）により、カラーを明瞭に表すことができ、他のデバイスがこの情報を利用して、カラーを再生するために最適を尽くすことができる。それぞれイメージングの分野内の特定の目的について開発されたｓＲＧＢ、ｓｃＲＧＢ、アドビＲＧＢを含め、様々な周知のカラースペースが存在する。
【００２２】
・  カラーコンテキスト−記述されるカラースペースの色域の一般化された形態。あるファイルフォーマットが、特定のカラー管理規格によって記述される色域情報を使用する限り、カラーコンテキストは事実上同じ概念であるが、ＩＣＣ色域をサポートしないファイル（符号化）フォーマットを含む。
【００２３】
・  ダイナミックレンジ−数学的に、システムが符号化することができる最大値の信号を同じシステムが符号化することができる最小値の信号によって除算したもの。この値は、システムが符号化する情報のスケールの表示を与える。
【００２４】
・  色域−プリンタまたはモニタなどの出力デバイスにおいて再生可能なカラーおよび密度値の範囲。
【００２５】
・  色相−人が主波長を知覚するカラーの属性。
【００２６】
・  色相、彩度、明度（ＨＳＶ）−色相を角度として表し、彩度を中心からの距離として表す色相ダイアグラム。
【００２７】
・  ＩＣＣ−国際カラーコンソーシアム。
【００２８】
・  強度−観測者がどのように知覚するかに関係なく、表面または光源からの光の純然たる量。
【００２９】
・  精度−カラーを表す精度。ソースデータが適切なカラー分解能を有するとすれば、精度は、通常、各チャネルで符号化されるビット数を増加させることによって向上する。
【００３０】
・  プロファイル−カラー管理システムがカラーを特定のカラースペースの内外に変換するのに十分な情報を含むファイル。これは、サブカテゴリ入力プロファイル、出力プロファイル、および表示プロファイル（それぞれ、入力デバイス、出力デバイス、および表示デバイス用）を有するデバイスプロファイルと呼ばれるデバイスのカラースペース、または抽象カラースペースとすることが可能である。
【００３１】
・  レンダリングインテント−より大きい色域からより小さい色域へ移行するとき、カラースペース間でカラーを変換する問題を取り扱う方法をカラー管理システムに通知するセッティング。
【００３２】
・  彩度−カラーの純度。
【００３３】
・  ｓＲＧＢ−インターネット、ＩＥＣ６１９６６−２−１の画像のための「標準」ＲＧＢカラースペース。
【００３４】
・  ｓｃＲＧＢ−「標準コンピューティング」ＲＧＢカラースペース、ＩＥＣ６１９６６−２−２。
【００３５】
・  ワークフロー−ドキュメントの数字がどのカラーを表すかを定義し、ワークがキャプチャから編集を通して出力に進む際に、それらのカラーを保持または制御するプロセス。
【００３６】
図１は、本発明を実施することができる適切なコンピューティングシステム環境１００の例を示す。特に、図１は、コンピューティングシステム環境１００のコンテキストにおける、光学無線マウスなどの無線ポインタデバイス１６１のオペレーションを示す。コンピューティングシステム環境１００は、適切なコンピューティング環境の単なる一例であり、本発明の使用範囲または機能に関する限定を示唆することを意図するものではない。コンピューティング環境１００は、例示的なオペレーティング環境１００において示されるコンポーネントのいずれか１つまたは組合せに関する依存性または必要性を有すると解釈されるべきではない。
【００３７】
本発明は、多くの他の汎用または専用のコンピューティングシステム環境または構成と共に動作可能である。本発明と共に使用されるのに適切である可能性がある周知のコンピューティングシステム、環境、および／または構成の例には、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドデバイスまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースシステム、セットトップボックス、プログラム可能家電、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたはデバイスのいずれかを含む分散型コンピューティング環境などがあるが、これに限定されるものではない。
【００３８】
本発明は、コンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的なコンテキストにおいて記述することができる。一般に、プログラムモジュールは、特定のタスクを実行するか、または特定の抽象的なデータタイプを実施するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。本発明は、タスクが通信ネットワークを経てリンクされるリモート処理デバイスによって実行される、分散型コンピューティング環境において実行することもできる。分散型コンピューティング環境では、プログラムモジュールは、メモリストレージデバイスを含め、ローカルおよびリモートのコンピュータ記憶メディアの両方に配置することができる。
【００３９】
図１を参照すると、本発明を実施する例示的なシステムは、コンピュータ１１０の形態の汎用コンピューティングデバイスを含む。コンピュータ１１０のコンポーネントは、処理ユニット１２０、システムメモリ１３０、およびシステムメモリを含めて様々なシステムコンポーネントを処理ユニット１２０に結合するシステムバス１２１を含むことが可能であるが、これに限定されるものではない。システムバス１２１は、メモリバスまたはメモリ制御デバイス、周辺バス、および様々なバスアーキテクチャのいずれかを使用するローカルバスを含め、いくつかのタイプのバス構造のいずれかとすることが可能である。例として、そのようなアーキテクチャには、ＩＳＡ（Ｉｎｄｕｓｔｒｙ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ  Ｃｈａｎｎｅｌ  Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、拡張ＩＳＡ（Ｅｎｈａｎｃｅｄ  ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｓｔａｎｄａｒｄｓ  Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、およびメザニンバスとしても知られるＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスがあるが、これに限定されるものではない。
【００４０】
コンピュータ１１０は、通常、様々なコンピュータ可読メディアを含む。コンピュータ可読メディアは、コンピュータ１１０によってアクセスすることができる任意の利用可能なメディアとすることができ、揮発性および不揮発性のメディア、リムーバブルおよび非リムーバブルなメディアの両方を含む。例として、コンピュータ可読メディアは、コンピュータ記憶メディアおよび通信メディアを備えることが可能であるが、これに限定されるものではない。コンピュータ記憶メディアには、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの情報を格納する任意の方法または技術において実施される揮発性および不揮発性、リムーバブルおよび非リムーバブルのメディアの両方がある。コンピュータ記憶メディアには、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光学ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたは他の磁気ストレージ、あるいは所望の情報を格納するために使用することができ、コンピュータ１１０によってアクセスすることができる任意の他の媒体があるが、これに限定されるものではない。通信メディアは、通常、搬送波などの変調データ信号または他のトランスポート機構において、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータを実現し、任意の情報送達メディアを含む。「変調データ信号」という用語は、信号の情報を符号化するような形でその特徴の１つまたは複数を設定または変更した信号を意味する。例として、限定ではなく、通信メディアには、有線ネットワークまたは直接配線接続などの有線メディア、および音声、ＲＦ、赤外線などの無線メディア、および他の無線メディアがある。上記のいずれかの組合せも、コンピュータ可読メディアの範囲内に含まれる。
【００４１】
システムメモリ１３０は、読取専用メモリ（ＲＯＭ）１３１およびランダムアクセスメモリ（ＲＡＭ）１３２など、揮発性メモリおよび／または不揮発性メモリの形態のコンピュータ記憶メディアを含む。起動中などにコンピュータ１１０内の要素間において情報を転送するように作用する基本ルーチンを含む基本的な入力／出力システム１３３（ＢＩＯＳ）は、通常、ＲＯＭ１３１に格納される。ＲＡＭ１３２は、通常、処理ユニット１２０に即座にアクセス可能であり、および／または処理ユニット１２０によって現在動作されているデータおよび／またはプログラムモジュールを含む。例として、限定ではなく、図１は、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７を示す。
【００４２】
コンピュータ１１０は、他のリムーバブル／非リムーバブル、揮発性／不揮発性コンピュータ記憶メディアをも含むことが可能である。例としてのみ、図１は、非リムーバブル不揮発性磁気メディアから読み取り、またはそれに書き込むハードディスクドライブ１４０、リムーバブル不揮発性磁気ディスク１５２から読み取り、またはそれに書き込む磁気ディスクドライブ１５１、およびＣＤ  ＲＯＭまたは他の光学メディアなどのリムーバブル不揮発性光学ディスク１５６から読み取り、またはそれに書き込む光ディスクドライブ１５５を示す。例示的なオペレーティング環境において使用することができる他のリムーバブル／非リムーバブル、揮発性／不揮発性コンピュータ記憶メディアには、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、半導体ＲＡＭ、半導体ＲＯＭなどがあるが、これに限定されるものではない。ハードディスクドライブ１４１は、通常、インターフェース１４０などの非リムーバブルメモリインターフェースを経てシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は、通常、インターフェース１５０などのリムーバブルメモリインターフェースによってシステムバス１２１に接続される。
【００４３】
上記で議論され、図１に示されるデバイスおよびそれに関連するコンピュータ記憶メディアは、コンピュータ１１０のコンピュータ可読命令、データ構造、プログラムモジュール、および他のデータのストレージを提供する。図１では、例えば、ハードディスクドライブ１４１が、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を格納するものとして示されている。これらのコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同じか、または異なるものとすることができることに留意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７は、ここでは、少なくとも、それらが異なるコピーであることを示すために、異なる数字が与えられている。ユーザは、マウス、トラックボール、またはタッチパッドと一般に呼ばれるキーボード１６２および無線ポインティングデバイス１６１などの入力デバイスにより、コマンドおよび情報をコンピュータ１１０に入力することが可能である。本発明の一実施形態では、無線ポインティングデバイス１６１は、マウスの動きを検出する光センサを有するマウスとして実施することができる。他の入力デバイス（図示せず）は、マイクロフォン、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナなどを含むことが可能である。これらおよび他の入力デバイスは、システムバスに結合されるユーザ入力インターフェース１６０を経て処理ユニット１２０にしばしば接続されるが、パラレルポート、ゲームポート、またはユニバーサルシリアスバス（ＵＳＢ）など、他のインターフェースおよびバス構造によって接続することができる。図１では、無線ポインタ１６１は、無線チャネル１９９によりユーザ入力インターフェース１６０と通信する。無線チャネル１９９は、無線周波数（ＲＦ）信号、赤外線信号、または可視光信号など、電磁信号を使用する。モニタ１９１または他のタイプの表示デバイスも、ビデオインターフェース１９０などのインターフェースを介してシステムバス１２１に接続される。モニタの他に、コンピュータは、スピーカ１９７およびプリンタ１９６などの他の周辺出力デバイスをも含むことが可能であり、出力周辺インターフェース１９０を経て接続することが可能である。
【００４４】
コンピュータ１１０は、リモートコンピュータ１８０など、１つまたは複数のリモートコンピュータへの論理接続を使用するネットワーク環境において動作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、または他の共通ネットワークノードとすることが可能であり、通常、コンピュータ１１０に関して上述された要素の多くまたはすべてを含むが、図１には、メモリストレージ１８１のみが示されている。図１に示される論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１およびワイドエリアネットワーク（ＷＡＮ）１７３を含むが、他のネットワークを含むことも可能である。そのようなネットワーキング環境は、オフィス、企業全体にわたるコンピュータネットワーク、イントラネット、およびインターネットにおいて一般的である。
【００４５】
ＬＡＮネットワーキング環境において使用されるとき、コンピュータ１１０は、ネットワークインターフェースまたはアダプタ１７０を経てＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境において使用されるとき、コンピュータ１１０は、インターネットなどのＷＡＮ１７３による通信を確立するためのモデム１７２または他の手段を通常含む。モデム１７２は、内蔵または外付けとすることが可能であり、ユーザ入力インターフェース１６０または他の適切な機構を介してシステムバス１２１に接続することができる。ネットワーク環境では、コンピュータ１１０に対して示されるプログラムモジュール、またはその一部は、リモートメモリストレージに格納することができる。例として、限定ではなく、図１は、リモートアプリケーションプログラム１８５がメモリデバイス１８１の上にあるように示している。示されるネットワーク接続は、例示であり、コンピュータ間において通信リンクを確立する他の手段を使用することができることが理解されるであろう。
【００４６】
周辺インターフェース１９５は、スキャナ（図示せず）またはデジタルカメラ１９４などのビデオ入力デバイスへインターフェースすることが可能であり、この場合、出力周辺インターフェースは、ユニバーサルシリアルバス（ＵＳＢ）インターフェースを含め、標準インターフェースをサポートすることが可能である。オペレーティングシステム１３４によって、またはアプリケーション１３５によってサポートすることが可能であるカラー管理は、コンピュータデバイス間において望ましいカラー変換を得ることについてユーザを補助する。コンピュータデバイスは、デジタルカメラ１９４などの入力デバイス、通常、モニタ１９１などの表示デバイス、およびプリンタ１９６などの出力デバイスとして分類される。カラー管理のオペレーションは、以下の議論においてより詳細に説明される。
【００４７】
図２は、本発明の一実施形態によってサポートされる国際カラーコンソーシアム（ＩＣＣ）プロファイル２００を示す。ＩＣＣプロファイル２００は、測定−デバイスモデルセグメント２０１、カラー外観モデルセグメント２０３、および色域マッピングアルゴリズムセグメント２０５を含む。この実施形態では、プロファイル２００は、ＩＣＣのウェブサイト（http://www.color.org.）から利用可能であるＩＣＣ仕様バージョン３．０から４．０に準拠する。測定−デバイスモデルセグメント２０１は、複数の比色値ならびに照度に関する情報でデバイスを特徴付ける。カラー外観モデルセグメント２０３は、入力照度およびビュー環境に基づいて、比色値をプロファイル接続空間（ＰＣＳ）に変換するために使用される。対応するカラー外観モデルは、多くの場合、独自のものである。色域マッピングアルゴリズムセグメント２０５は、基準媒体と特定の出力デバイスとの間のカラー色域の違いを考慮する。ＩＣＣプロファイル２００では、色域マッピングアルゴリズムセグメント２０５は、ソースプロファイル接続空間が宛先プロファイル接続空間に等価であると想定する。ＩＣＣプロファイル２００は、以下の議論において参照されるプロファイルのレガシフォーマットを例示する。
【００４８】
ＩＣＣプロファイル２００は、「ブラックボックス」アプローチを想定する２進フォーマットで通常表される。結果として、ユーザは、ＩＣＣプロファイル２００が、他のプロファイルフォーマットによって対処することができる重大な欠点を有すると結論することがある。
【００４９】
図３は、本発明の一実施形態によってサポートされる仮想デバイスモデルプロファイル３００を示す。仮想デバイスモデルプロファイル３００は、ＩＣＣプロファイル２００に関連する欠点のいくつかを解決する。仮想デバイスモデルプロファイル３００は、測定デバイスモデルセグメント３０１、カラー外観モデルセグメント３０３、色域マッピングアルゴリズムセグメント３０５、反転カラー外観モデルセグメント３０７、および宛先測定モデルセグメント３０９を含む。
【００５０】
仮想デバイスモデルプロファイル３００は、ユーザにとって有利である可能性があるいくつかの特徴を有する。例えば、プロファイル３００は、ソースプロファイル空間が宛先プロファイル空間と等価であると想定しない。カラー外観モデル（カラー外観モデルセグメント３０３および反転カラー外観モデルセグメント３０７に対応する）は、独自のものであることを必要とせず、ＣＩＥベースのカラー外観モデルを使用することが可能である。また、プロファイル３００は、ＩＣＣプロファイル２００によって使用される２進フォーマットではなく、テキストフォーマット（例えば、拡張可能マークアップ言語（ＸＭＬ））を使用することによって、よりアクセス可能とすることが可能である。仮想デバイスモデルプロファイル３００は、以下の議論において参照されるように、先進のプロファイルフォーマットを例示する。
【００５１】
図４は、本発明の一実施形態によるカラー管理システムのアーキテクチャ４００を示す。カラー管理システムは、ＡＰＩ層モジュール４０１、ＡＰＩアダプテーション層モジュール４０７、レガシ処理モジュール４１７、および先進の処理モジュール４１９を備える。この実施形態では、ＡＰＩ層モジュール４０１およびＡＰＩアダプテーション層モジュール４０７は、ＩＣＭ２（Ｉｍａｇｅ  Ｃｏｌｏｒ  Ｍａｎａｇｅｍｅｎｔ２）など、レガシＡＰＩセットをサポートする。
【００５２】
ＩＣＭ２は、ウィンドウズ（登録商標）９８およびそれ以降に組み込まれている。ＩＣＭ２は、
・  ＯＰＥＮ／ＣＬＯＳＥプロファイル
・  ＧＥＴ／ＳＥＴプロファイル要素
・  ＣＲＥＡＴＥ  ＴＲＡＮＳＦＯＲＭ
・  ＴＲＡＮＳＦＯＲＭ  ＣＯＬＯＲＳ
を含む、様々なＡＰＩカテゴリを有するレガシアプリケーションプログラムインターフェース（ＡＰＩ）セットをサポートする。ＡＰＩコールは、通常、少なくとも１つのパラメータを含む。パラメータは、プロファイルオブジェクトまたはトランスフォームオブジェクトなどのオブジェクトを特定するポインタとすることが可能である。ＡＰＩセットのＯＰＥＮカテゴリにより、アプリケーションによって指定プロファイルにアクセスすることが可能になる。指定カテゴリがオープンにされると、プロファイル要素は、ＡＰＩセットのＧＥＴ／ＳＥＴカテゴリを使用して、アプリケーションによって読み取るか、または書き込むことができる。カラー管理システムがソース画像を宛先画像に変換するために、変換ルックアップテーブル（通常多次元である）が、ソースプロファイルおよび宛先プロファイルなど、プロファイルの指定セットから構築される。アプリケーションは、ＣＲＥＡＴＥ  ＴＲＡＮＳＦＯＲＭカテゴリを使用することによって、ルックアップテーブルの構築を呼び出すことができる。ルックアップテーブルが構築されると、ＡＰＩセットのＴＲＡＮＳＦＯＲＭ  ＣＯＬＯＲＳカテゴリを使用することによって、ソース画像を宛先画像に画素ごとに変換するように、カラー管理システムに命令することができる。
【００５３】
図４を参照すると、レガシアプリケーション４０３および先進のアプリケーション４０５は、ＡＰＩ層モジュール４０１と対話して、どの処理モジュールがＡＰＩ要求を処理するべきであるかを決定する。アプリケーション４０３および４０５の両方とも、ＡＰＩ要求をＡＰＩ層モジュール４０１に送る。ＡＰＩコール４０９、ＡＰＩリターン結果４１１、ＡＰＩコール４１３、およびＡＰＩリターン結果４１５の構造およびフォーマットが、レガシフォーマットに準拠する限り、先進のアプリケーション４０５は、先進の処理モジュール４１９によって提供される機能および改良を使用することができる。しかし、レガシアプリケーション４０３は、修正せずに、レガシＡＰＩセットを使用し続けることができる。例えば、先進のアプリケーション４０５は、仮想デバイスモデルプロファイル３００を使用して、ＡＰＩコールにおいて１つまたは複数の指定プロファイルを表すことが可能である。ＡＰＩアダプテーション層モジュール４０７は、ＡＰＩコールにおいて特定されるオブジェクトを分析して、オブジェクトがレガシフォーマットを有するか（例えば、ＩＣＣプロファイル２００）、またはオブジェクトが先進のフォーマット（例えば、仮想デバイスモデルプロファイル３００）を有するかを判定する。（先進のフォーマットは、非レガシフォーマットであると定義することができる）。オブジェクトがレガシフォーマットを有する場合、レガシ処理モジュール４１７がＡＰＩコールを処理する。オブジェクトが先進のフォーマットを有する場合、先進の処理モジュール４１９がＡＰＩコールを処理する。
【００５４】
ＡＰＩコールによって特定される１セットのオブジェクトのオブジェクトが、混合フォーマットを有する場合、すなわち、オブジェクトの１つがレガシフォーマットを有し、他のオブジェクトが先進のフォーマットを有する場合、オブジェクトのいくつかのフォーマットは、オブジェクトのすべてのフォーマットが一貫するように変換される。例として、宛先プロファイルおよびソースプロファイルが異なるフォーマットを有する場合（１つのプロファイルがレガシフォーマットを有し、他のプロファイルが先進のフォーマットを有する場合）、レガシフォーマットを有するオブジェクトのフォーマットは、先進のフォーマットに変換される。この実施形態では、ＡＰＩアダプテーション層モジュール４０７は、表１に示される論理を使用して、フォーマット変換を決定する（本発明の他の実施形態では、フォーマット変換は、カラー管理システムの他のモジュールによって実行することができる）。
【００５５】
【表１】
2011248908.tif 000003
【００５６】
表１に示される実施形態では、１セットのオブジェクトの任意のオブジェクトが先進のフォーマットに関連付けられる場合、レガシフォーマットを有するセットの任意の残りのオブジェクトは、セットのすべてのオブジェクトが、フォーマット変換後、先進のフォーマットを有するように、先進のフォーマットに変換される。先進のモジュール４１９がその後呼び出されて、ＡＰＩコールを処理する。
【００５７】
この実施形態では、表１に示されるように、オブジェクトのセットのすべてのオブジェクトがレガシフォーマットに関連付けられる場合、オブジェクトのいずれも、先進のフォーマットに変換されない。レガシモジュール４１７がその後呼び出されて、ＡＰＩコールを処理する。しかし、他の実施形態では、ポリシにより、フォーマットオーバーライドインジケータを構成することができ（「先進のフォーマットのみ」に対応する）、それにより、オブジェクトのセットの任意のオブジェクトが先進のフォーマットに関連付けられるかに関係なく、レガシフォーマットを有するすべてのオブジェクトが、先進のフォーマットに変換される。さらに、ポリシは、フォーマットオーバーライドインジケータ（「先進のフォーマットを好む」に対応する）を構成するための複数のモード選択をサポートすることが可能であり、それにより、すべてのレガシオブジェクトは、無条件では先進のフォーマットに変換されない。すなわち、上述されたように、レガシオブジェクトは、少なくとも１つのオブジェクトが先進のフォーマットを有する場合のみ、先進のフォーマットに変換される。この実施形態は、「レガシフォーマットのみ」および「レガシフォーマットを好む」など、他のモード選択をサポートすることが可能である。表２は、これらのモード選択によるオペレーションを示す。
【００５８】
【表２】
2011248908.tif 000004
【００５９】
この実施形態は、オブジェクトをレガシフォーマットから先進のフォーマットに変換するが、他の実施形態は、オブジェクトを先進のフォーマットからレガシフォーマットに変換することが可能である。しかし、レガシソフトウェアは、更新が非レガシソフトウェアに組み込まれる間、通常フリーズされる。その場合、レガシソフトウェアの修正を回避するために、表１に示されるようにレガシフォーマットを先進のフォーマットに変換することが有利である可能性がある。
【００６０】
図５は、本発明の一実施形態に従って要求コンポーネント５０５が中間コンポーネント５０３を通してカラー管理システム５１０へのＡＰＩコール５０７を呼び出すことを示す。図５に示される構成では、中間コンポーネント５０３は、ＡＰＩコール５０７をカラー管理システム５０１に中継し、カラー管理システム５０１からのＡＰＩリターン結果５０９を要求コンポーネント５０５に中継する。この実施形態では、中間コンポーネント５０３は、アプリケーションまたはユーティリティとすることが可能である。
【００６１】
図６は、本発明の一実施形態に従ってソース画像ドキュメント６０１または６０５から宛先画像ドキュメントにカラー情報を変換するカラー管理システム６００のアーキテクチャを示す。カラー管理システム６００は、レガシモジュール４１７と、先進の処理モジュール４１９と、カラー管理システムに関連付けられる様々なオブジェクトをサポートする複数の構造とを備える。この実施形態では、構造６０９、６１１、６１３、および６１５は、レガシフォーマット（レガシソースプロファイル６０９、レガシ宛先プロファイル６１１、およびレガシ変換表６１７）と、先進のフォーマット先進の（ソースプロファイル６１３、先進の宛先プロファイル６１５、および先進の変換表６１９）とに別々に関連付けられる。必要であれば、上記で議論されたように、レガシソースプロファイル６０９は、フォーマット変換６５１により先進のソースプロファイル６１３に変換され、レガシ宛先プロファイル６１１は、フォーマット変換６５３により先進の宛先プロファイル６１５に変換される。
【００６２】
図７は、本発明の一実施形態に従って画像ドキュメントを処理する共通構造を使用するカラー管理システム７０１のアーキテクチャ７００を示す。レガシ処理モジュール７０７、先進の処理モジュール７０９、ＡＰＩ層モジュール７０３、およびＡＰＩアダプテーションモジュール７０５は、それぞれ、図４に示されるレガシ処理モジュール４１７、先進の処理モジュール４１９、ＡＰＩ層モジュール４０１、およびＡＰＩアダプテーション層モジュール４０７に対応する。コンポーネント７１７は、ＡＰＩコールでカラーオペレーションを要求する。アーキテクチャ７００は、レガシフォーマットまたは先進のフォーマットで、オブジェクトの共通構造をサポートする。例えば、ソースプロファイル構造７１１、宛先プロファイル構造７１３、および変換構造７１５は、それぞれ、ソースプロファイル、宛先プロファイル、および変換ルックアップテーブルについてレガシフォーマットまたは先進のフォーマットをサポートする。この実施形態では、構造７１１、７１３、および７１５は、ハンドルを使用して、オブジェクトの要素を特定し、この場合、ヌルポインタが、オブジェクトのフォーマットとは異なるフォーマットに対応する要素を表す（ハンドルはポインタごとである）。しかし、本発明の他の実施形態は、ポインタなど、他の特定機構を使用することが可能である。
【００６３】
図８は、本発明の一実施形態に従ってＧＥＴ／ＳＥＴ  ＡＰＩカテゴリを処理する流れ図８００を示す。以前に議論されたように、ＧＥＴ／ＳＥＴカテゴリにより、アプリケーションが、プロファイル要素を取り出すか、または設定することが可能になる。流れ図８００では、指定プロファイルが、レガシフォーマットまたは先進のフォーマットを有することが可能である。ステップ８０１において、カラー管理システムは、ＡＰＩコールを受け取って、プロファイルの要素を取り出すか、または設定する。ステップ８０３において、カラー管理システムは、要求された要素がプロファイルフォーマットと一貫するかを判定する。要素は、レガシフォーマットでサポートすることができるが、先進のフォーマットでサポートすることはできない可能性があり、逆もまた同じである。例えば、「好ましいＣＭＭ」要素は、ＩＣＣフォーマット２００でサポートすることができるが、仮想デバイスモデルプロファイル３００でサポートすることはできない。ステップ８０３により、プロファイル要素がプロファイルフォーマットと一貫すると判定される場合、要素は、ステップ８０９において返される。ステップ８０３により、プロファイル要素がプロファイルフォーマットと一貫しないと判定される場合、エラー表示が返される。他の実施形態では、カラー管理システムはエラー表示を返すのではなく、カラー管理システムは、要求されたプロファイル要素に最適に整合するプロファイル要素（プロファイルフォーマットに対応する）を決定して、ステップ８０７において、整合プロファイル要素に関する情報を返す。
【００６４】
図４〜図７に示される実施形態は、コンポーネントとカラー管理システムとの間においてアプリケーションプログラムインターフェースをサポートするが、本発明は、他のタイプのシステムのレガシＡＰＩによるシステム改良をサポートすることが可能である。その結果、レガシＡＰＩは、システムの改良および新しい機能をサポートすることができ、一方、レガシアプリケーションは、レガシアプリケーションを修正せずに、システムとの対話を続行することが可能になる。
【００６５】
プログラミングインターフェース（または、より簡単にはインターフェース）は、コードの１つまたは複数のセグメントが、コードの１つまたは複数の他のセグメントによって提供される機能と通信するか、またはそれにアクセスすることを可能にする任意の機構、プロセス、プロトコルと見なすことができる。代替として、プログラミングインターフェースは、他のコンポーネントの１つまたは複数の機構、メソッド、関数コール、モジュールなどに通信結合することができるシステムのコンポーネントの１つまたは複数の機構、メソッド、関数コール、モジュール、オブジェクトなどと見なすことができる。前文の「コードのセグメント」という用語は、１つまたは複数の命令またはコードのラインを含むことが意図され、適用される用語、またはコードセグメントが別々にコンパイルされるか、またはコードセグメントがソースコード、中間コード、もしくはオブジェクトコードとして提供されるか、コードセグメントがランタイムシステムまたはプロセスにおいて使用されるか、または、コードセグメントが同じマシン、もしくは異なるマシンにあるか、もしくは複数のマシンにわたって分散するか、または、コードのセグメントによって現される機能が、完全にソフトウェアにおいて、完全にハードウェアにおいて、もしくはハードウェアおよびソフトウェアの組合せにおいて実施されるかに関係なく、同じコードモジュール、オブジェクト、サブルーチン、機能などを含む。
【００６６】
概念的には、プログラミングインターフェースは、図９または図１０に示されるように一般的に見ることができる。図９は、第１コードセグメントおよび第２コードセグメントが通信するコンジットとしてのインターフェース、インターフェース１を示す。図１０は、インターフェースオブジェクトＩ１およびＩ２（第１コードセグメントおよび第２コードセグメントの一部であるか、または一部ではないことが可能である）を備えるものとしてのインターフェースを示し、これにより、システムの第１コードセグメントおよび第２コードセグメントは、媒体Ｍを介して通信することが可能になる。図１０を考慮すると、インターフェースオブジェクトＩ１およびＩ２を同じシステムの別々のインターフェースと見なすことが可能であり、また、オブジェクトＩ１およびＩ２ならびに媒体Ｍがインターフェースを備えるものと見なすことが可能である。図９および図１０は、フローの各側における双方向のフローおよびインターフェースを示すが、ある実施態様は、一方向の情報フローのみ（もしくは、以下で記述されるように情報フローなし）を有することが可能であり、または、インターフェースオブジェクトを一方の側においてのみ有することが可能である。例として、限定ではなく、アプリケーションプログラミングインターフェース（ＡＰＩ）、エントリポイント、メソッド、関数、サブルーチン、リモートプロシージャコール、およびコンポーネントオブジェクトモデル（ＣＯＭ）インターフェースなどの用語は、プログラミングインターフェースの定義内に内包される。
【００６７】
そのようなプログラミングインターフェースの態様は、第１コードセグメントが情報を第２コードセグメントに送信する方法（「情報」は、最も広範な意味で使用され、データ、コマンド、要求などを含む）、第２コードセグメントが情報を受信するメソッド、ならびに情報の構造、シーケンス、シンタックス、編成、スキーマ、タイミング、および内容を含むことが可能である。これに関して、情報がインターフェースによって定義される形でトランスポートされる限り、媒体が有線または無線であるか、もしくは両方の組合せであるかに関係なく、基礎となるトランスポート自体は、インターフェースのオペレーションに重要ではない場合がある。ある状況では、情報は、従来の意味で一方向または両方向で渡されないことがあるが、その理由は、１つのコードセグメントが第２コードセグメントによって実行される機能に単にアクセスするときのように、情報の転送が、他の機構（例えば、コードセグメント間の情報フローとは別に、バッファ、ファイルなどに配置される情報）を介するか、または存在しないことがあるからである。これらの態様のいずれかまたはすべては、コードセグメントが、疎結合された構成、または密結合された構成においてシステムの一部であるかに応じてなど、所与の状況において重要である可能性があり、したがって、このリストは、例示であり、限定ではないと見なされるべきである。
【００６８】
プログラミングインターフェースのこの概念は、当業者には既知であり、本発明の以上の詳細な記述から明らかである。しかし、プログラミングインターフェースを実施する他の方式があり、明らかに排除されない限り、これらも、本明細書の終わりに述べられる請求項によって包含されることを意図する。そのような他の方式は、図９および図１０の簡略的な図より洗練され、または複雑であるように見える可能性があるが、それにもかかわらず、同じ機能を実行して、同じ全体的な結果を達成する。ここで、プログラミングインターフェースのいくつかの例示的な代替実施態様を簡潔に記述する。
【００６９】
１つのコードセグメントから他への通信は、通信を複数の離散通信に分割することによって間接的に達成することができる。これは、図１１および図１２に概略的に示される。図示されるように、機能の分割可能なセットの観点で、いくつかのインターフェースを記述することができる。それゆえ、数学では、２４すなわち２かける２かける３かける２を提供することが可能であるように、図９および図１０のインターフェース機能をファクタ化して、同じ結果を達成することが可能である。したがって、図１１に示されるように、インターフェース、インターフェース１によって提供される機能は、インターフェースの通信を複数のインターフェース、インターフェース１Ａ、インターフェース１Ｂ、インターフェース１Ｃなどに変換するように、さらに分割し、一方、同じ結果を達成することが可能である。図１２に示されるように、インターフェースＩ１によって提供される機能は、複数のインターフェースＩ１ａ、Ｉ１ｂ、Ｉ１ｃなどにさらに分割し、一方、同じ結果を達成することが可能である。同様に、第１コードセグメントから情報を受信する第２コードセグメントのインターフェースＩ２は、複数のインターフェースＩ２ａ、Ｉ２ｂ、Ｉ２ｃなどにファクタ化することができる。ファクタ化するとき、第１コードセグメントに含まれるインターフェースの数は、第２コードセグメントに含まれるインターフェースの数と整合する必要はない。図１１および図１２の場合のどちらにおいても、インターフェース、インターフェース１およびＩ１の機能的趣旨は、それぞれ、図９および図１０と依然として同じである。インターフェースのファクタ化は、ファクタ化を認識することが困難であることがるように、結合、可換、および他の数学的プロパティに準拠することも可能である。例えば、オペレーションの順序は、重要ではないこともあり、その結果、インターフェースによって実行される機能は、他のコードまたはインターフェースの部分によって、インターフェースに到達するかなり前に実行する、またはシステムの別のコンポーネントによって実行することが可能である。さらに、プログラミング分野の技術者なら、同じ結果を達成する様々な関数コールを作成する様々な方式があることを理解することができる。
【００７０】
いくつかの場合、プログラミングインターフェースのある態様（例えば、パラメータ）を無視、追加、または再定義する一方、意図した結果を依然として達成することが可能であることがある。これは、図１３および図１４に示される。例えば、図９のインターフェース、インターフェース１が、関数コールＳｑｕａｒｅ（入力、精度、出力）を含むと想定し、入力、精度、出力の３つのパラメータを含むコールは、第１コードセグメントから第２コードセグメントに発行される。図１３に示されるように、中間パラメータの精度が所与のシナリオにおいて重要ではない場合、単に無視することができ、またはさらには無意味な（この状況では）パラメータで置き換えることができる。また、重要ではない追加パラメータを追加することも可能である。どちらの場合でも、入力が第２コードセグメントによってスクエアされた後、出力が返される限り、スクエアの機能を達成することができる。精度は、コンピューティングシステムにおける何らかのダウンストリームまたは他の部分にとって、意味のあるパラメータである可能性が非常に高いが、精度が、スクエアを計算する狭義の目的では必要ではないと認識されると、置き換えるか、または無視することができる。例えば、有効な精度値を渡す代わりに、結果に悪影響を与えずに、誕生日などの無意味な値を渡すことができる。同様に、図１４に示されるように、インターフェースＩ１は、インターフェースＩ１’によって置き換えられ、パラメータを無視するか、またはパラメータをインターフェースに追加するように再定義される。インターフェースＩ２は、同様に、インターフェースＩ２’として再定義し、不必要なパラメータ、または他で処理することができるパラメータを無視するように再定義することができる。ここで重要なことは、いくつかの場合、プログラミングインターフェースは、ある目的には必要とされないパラメータなどの態様を含むことが可能であり、したがって、無視するか、または再定義するか、あるいは他の目的について他で処理することができる。
【００７１】
また、２つの別々のコードモジュール間の「インターフェース」が形態を変更するように、それらのモジュールの機能のいくつかまたはすべてをマージすることも実行可能であることがある。例えば、図９および図１０の機能は、それぞれ、図１５および図１６の機能に変換することができる。図１５では、図９の以前の第１コードセグメントおよび第２コードセグメントは、それらの両方を含むモジュールにマージされる。この場合、コードセグメントは、互いに依然として通信することが可能であるが、インターフェースは、単一モジュールにより適切である形態に適合することができる。それゆえ、例えば、フォーマルコールおよびリターンステートメントは、もはや必要ではない可能性があるが、インターフェース、インターフェース１による同様の処理または応答は、依然として有効である可能性がある。同様に、図１６に示されるように、図１０からのインターフェースＩ２の一部（またはすべて）は、インターフェースＩ１”を形成するように、インターフェースＩ１にインライン式に書き込むことができる。図示されるように、インターフェースＩ２は、Ｉ２ａおよびＩ２ｂに分割され、インターフェース部分Ｉ２ａは、インターフェースＩ１とインライン式にコード化されて、インターフェースＩ１”を形成する。具体的な例として、図１０のインターフェースＩ１が関数コールＳｑｕｒｅ（入力、出力）を実行し、これは、インターフェースＩ２によって受信され、その値を処理した後、第２コードセグメントによって入力と共に渡され（それをスクエアするために）、出力と共にスクエアされた結果を再び渡すことを考慮する。そのような場合、第２コードセグメントによって実行される処理（入力をスクエアする）は、インターフェースへのコールなしで、第１コードセグメントによって実行することができる。
【００７２】
１つのコードセグメントから他への通信は、通信を複数の離散通信に分割することによって、間接的に達成することができる。これは、図１７および図１８に概略的に示される。図１７に示されるように、ミドルウェア（元のインターフェースから機能および／またはインターフェース機能を分離するので分離インターフェース）の１つまたは複数の部分は、第１インターフェースであるインターフェース１での通信を変換して、それらを異なるインターフェース、この場合はインターフェース、インターフェース２Ａ、インターフェース２Ｂ、およびインターフェース２Ｃに準拠させるために提供される。これは、実行することができるが、例えば、インターフェース１プロトコルに従ってオペレーティングシステムなどと通信するように設計されるアプリケーションのインストールベースが存在するが、次いで、オペレーティングシステムが、この場合はインターフェース、インターフェース２Ａ、インターフェース２Ｂ、およびインターフェース２Ｃである異なるインターフェースを使用するように要求される場合である。重要なことは、第２コードセグメントによって使用される元のインターフェースが、第１コードセグメントによって使用されるインターフェースともはやコンパチブルではないように変更され、それにより、媒介物を使用して、旧インターフェースおよび新インターフェースをコンパチブルにすることである。同様に、図１８に示されるように、第３コードセグメントを分離インターフェースＤＩ１と共に導入して、インターフェースＩ１から通信を受信することができ、また分離インターフェースＤＩ２と共に導入して、ＤＩ２と共に作用するが、同じ機能的結果を提供するように再設計されたインターフェースＩ２ａおよびＩ２ｂなどにインターフェース機能を送信することができる。同様に、ＤＩ１およびＤＩ２は、共に作用して、図１０のインターフェースＩ１およびＩ２の機能を新しいオペレーティングシステムに転送し、一方、同じまたは同様の機能的結果を提供することが可能である。
【００７３】
他の可能な変形形態は、コードを動的に書き直して、インターフェース機能をその他と置き換えるが、同じ全体的な結果を達成するようにすることである。例えば、中間言語（例えば、マイクロソフトＩＬ、Ｊａｖａ（登録商標）  ＢｙｔｅＣｏｄｅなど）において提示されるコードセグメントが実行環境（．ＮＥＴフレームワーク、Ｊａｖａ（登録商標）ランタイム環境、または他の同様のランタイムタイプ環境によって提供されるものなど）においてジャストインタイム（ＪＩＴ）コンパイラまたはインタープリタに提供されるシステムが存在することが可能である。ＪＩＴコンパイラは、第１コードセグメントから第２コードセグメントに通信を動的に変換する、すなわち通信を第２コードセグメント（元のまたは異なる第２コードセグメント）によって要求することができる異なるインターフェースに準拠させるように書くことができる。これは、図１９および図２０に示される。図１９からわかるように、このアプローチは、上述された分離シナリオと同様である。これは、実行することができるが、例えば、アプリケーションのインストールベースが、インターフェース１プロトコルに従ってオペレーティングシステムと通信するように設計されるが、次いで、オペレーティングシステムが、変更されて、異なるインターフェースを使用する場合である。ＪＩＴコンパイラを使用して、通信をインストールベースアプリケーションからオペレーティングシステムの新しいインターフェースに実行中に準拠させることができる。図２０に示されるように、インターフェースを動的に書き直すこのアプローチを適用して、動的にインターフェースを分解するか、そうでなければインターフェースを同様に変更することができる。
【００７４】
また、代替実施形態によるインターフェースと同じまたは同様の結果を達成する上述されたシナリオは、様々な方法でシリアルおよび／またはパラレルに、あるいは他の介在コードと共に、組み合わせることもできることにも留意されたい。それゆえ、上記で提示された代替実施形態は、相互に排他的ではなく、混合、整合、および組み合わせて、図９および図１０において提示された一般的なシナリオと同じまたは等価のシナリオを生成することができる。また、ほとんどのプログラミング構築の場合と同様に、本明細書において記述されていない可能性があるが、それにもかかわらず、本発明の精神および範囲によって表されるインターフェースの同じまたは同様の機能を達成する他の類似の方法が存在することにも留意されたい。すなわち、これは、少なくとも部分的には、インターフェースの価値の基盤となる、インターフェースによって表される機能、およびインターフェースよって可能になる有利な結果であることに留意されたい。
【００７５】
本発明は、本発明を実行する現在好ましいモードを含めて、特定の例に関して記述されたが、当業者なら、添付の請求項において述べられる本発明の精神および範囲内にある上述されたシステムおよび技術の多くの変更および置換が存在することを理解するであろう。
【符号の説明】
【００７６】
４００  カラー管理システムのアーキテクチャ
６００  カラー管理システム
７００  カラー管理システムのアーキテクチャ
【図１】
2011248908.tif 000005
【図２】
2011248908.tif 000006
【図３】
2011248908.tif 000007
【図４】
2011248908.tif 000008
【図５】
2011248908.tif 000009
【図６】
2011248908.tif 000010
【図７】
2011248908.tif 000011
【図８】
2011248908.tif 000012
【図９】
2011248908.tif 000013
【図１０】
2011248908.tif 000014
【図１１】
2011248908.tif 000015
【図１２】
2011248908.tif 000016
【図１３】
2011248908.tif 000017
【図１４】
2011248908.tif 000018
【図１５】
2011248908.tif 000019
【図１６】
2011248908.tif 000020
【図１７】
2011248908.tif 000021
【図１８】
2011248908.tif 000022
【図１９】
2011248908.tif 000023
【図２０】
2011248908.tif 000024