(57)【要約】【課題】カスタマイズ可能な着色画像をサポートするユーザインターフェースを提供するアプリケーションにより使用するための、彩度マップを用いるモノクロ着色により画像を着色するためのシステムと方法を提供する。【解決手段】画像に由来する彩度マップとモノクロの明度マップとを用い、且つ着色領域を特定するように彩度マップを設定することにより、一連の迅速処理の算術計算により、或る色合いの色を画像に付けることができる。これは、不必要なネットワーク回線容量又はプロセッサリソースを無駄にすることなく、アプリケーション内の画像に着色するための軽量で高品質の方法を提供する。更に、本方法は、多数の着色カラーを多数の着色に適用するか、又は、モノクロの明度マップのために失われる色情報を復元するために適応することができる。これにて得られる着色画像は、三次元レンダリングエンジン用のテクスチャとして用いることもできる。【選択図】図１
2010161779.tif 000002
【特許請求の範囲】
【請求項１】
着色画像を表示するためにプロセッサを用いて画像に着色するシステムであって、
該システムは、
ディスプレイと、
該ディスプレイと通信するプロセッサとを備え、
該プロセッサは、
ベタに塗りつぶす色としての着色カラーを、より大きい彩度をより低い値として表わす彩度マップを用いてスクリーンブレンドすることにより、中間画像を作成し、
該中間画像に明度マップを乗じ、
着色画像を作成するために、前記着色カラーのRGBの色空間内で、前記中間画像を正規化し、
前記着色画像を前記ディスプレイに表示するように構成される、
画像を着色するシステム。
【請求項２】
請求項１に記載の画像を着色するシステムであって、
前記中間画像を作成する前に、前記プロセッサは、更に、
カラー値ごとにビットで定義する色深度を有するRGBの色空間において、３つのRGBのカラー値から成る前記着色カラーをメモリに格納し、
画像の大きさに等しい大きさを有する複数の画像マップを検索し、該画像マップは、前記着色カラーにより着色すべき領域に対応する画像から導かれたHSVピクセル彩度から成る彩度マップと、前記画像から導かれたHSVピクセル明度から成る明度マップとを含み、
ピクセル彩度のビット深度と前記色深度に等しいピクセル明度のビット深度とを有する色相彩度明度（HSV）表現を用いて、前記複数の画像マップを前記メモリに格納するように構成される、
画像を着色するシステム。
【請求項３】
前記プロセッサは、前記着色画像を前記ディスプレイに表示するために、フラッシュアプリケーションを実行するように構成される、
請求項１に記載の画像を着色するシステム。
【請求項４】
前記プロセッサは、前記着色画像を前記ディスプレイに表示するために、ジャバアプリケーションを実行するように構成される、
請求項１に記載の画像を着色するシステム。
【請求項５】
前記プロセッサは、前記着色画像を前記ディスプレイに表示するために、シルバーライトアプリケーションを実行するように構成される、
請求項１に記載の画像を着色するシステム。
【請求項６】
前記プロセッサは、前記着色画像を前記ディスプレイに表示する前に、三次元レンダラーで前記着色画像を処理するように構成される、
請求項１に記載の画像を着色するシステム。
【請求項７】
請求項１に記載の画像を着色するシステムであって、
前記着色画像を表示する前に、前記プロセッサは、請求項１に記載の前記プロセッサにより実行されるステップの反復を行うことにより、第２の着色カラーにより前記画像を更に着色するように構成され、
前記着色画像は前記反復において前記明度マップの代わりに用いられ、
前記第２の着色カラーにより着色すべき領域に対応する前記画像から導かれたHSVピクセル彩度から成る第２の彩度マップは、前記反復において彩度マップの代わりに用いられる、
画像を着色するシステム。
【請求項８】
前記プロセッサは、独立のカラーチャネル内に埋め込まれた前記複数の画像マップの各々を有する単一の画像ファイルから、前記複数の画像マップを検索するように構成される、
請求項２に記載の画像を着色するシステム。
【請求項９】
前記画像を表示する前に、前記プロセッサは、前記着色画像が表示される時に、画像の透明性を提供するアルファチャネルを適用するように構成される、
請求項２に記載の画像を着色するシステム。
【請求項１０】
前記プロセッサは、アルファチャネルが失われたカラー情報を表示できるように、適用されるアルファチャネルを有する前記着色画像を、前記画像の上に重ねることにより、前記着色画像から失われたカラー情報を復元するように構成される、
請求項２に記載の画像を着色するシステム。
【請求項１１】
プロセッサを用いて画像を着色する方法であって、
該方法は、
ベタに塗りつぶす色としての着色カラーを、より大きい彩度をより低い値として表わす彩度マップを用いてスクリーンブレンドすることにより、中間画像を作成するステップと、
該中間画像に明度マップを乗じるステップと、
着色画像を作成するために、前記着色カラーのRGBの色空間内で、前記中間画像を正規化し、
前記着色画像を前記プロセッサと通信するディスプレイに表示するステップとを有する、
画像を着色する方法。
【請求項１２】
請求項１１に記載の画像を着色する方法であって、
前記中間画像を作成する前に、前記プロセッサは、更に、
カラー値ごとにビットで定義する色深度を有するRGBの色空間において、３つのRGBのカラー値から成る前記着色カラーをメモリに格納し、
画像の大きさに等しい大きさを有する複数の画像マップを検索し、該画像マップは、前記着色カラーにより着色すべき領域に対応する画像から導かれたHSVピクセル彩度から成る彩度マップと、前記画像から導かれたHSVピクセル明度から成る明度マップとを含み、
ピクセル彩度のビット深度と前記色深度に等しいピクセル明度のビット深度とを有する色相彩度明度（HSV）表現を用いて、前記複数の画像マップを前記メモリに格納するように構成される、
画像を着色する方法。
【請求項１３】
前記プロセッサは、前記着色画像を前記ディスプレイに表示するために、フラッシュアプリケーションを実行するように構成される、
請求項１１に記載の画像を着色する方法。
【請求項１４】
前記プロセッサは、前記着色画像を前記ディスプレイに表示する前に、三次元レンダラーで前記着色画像を処理するように構成される、
請求項１１に記載の画像を着色する方法。
【請求項１５】
前記プロセッサは、前記着色画像を前記ディスプレイに表示するために、シルバーライトアプリケーションを実行するように構成される、
請求項１１に記載の画像を着色する方法。
【請求項１６】
前記プロセッサは、前記着色画像を前記ディスプレイに表示するために、ネイティブ・バイナリ・アプリケーションを実行するように構成される、
請求項１１に記載の画像を着色する方法。
【請求項１７】
請求項１１に記載の画像を着色する方法であって、
前記着色画像を表示する前に、前記プロセッサは、請求項１２に記載の前記方法の反復を行うことにより、第２の着色カラーにより前記画像を更に着色するように構成され、
前記着色画像は前記反復において前記明度マップの代わりに用いられ、
前記第２の着色カラーにより着色すべき領域に対応する前記画像から導かれたHSVピクセル彩度から成る第２の彩度マップは、前記反復において彩度マップの代わりに用いられる、
画像を着色する方法。
【請求項１８】
前記プロセッサは、独立のカラーチャネル内に埋め込まれた前記複数の画像マップの各々を有する単一の画像ファイルから、前記複数の画像マップを検索するように構成される、
請求項１２に記載の画像を着色する方法。
【請求項１９】
前記画像を表示する前に、前記プロセッサは、前記着色画像が表示される時に、画像の透明性を提供するアルファチャネルを適用するように構成される、
請求項１２に記載の画像を着色する方法。
【請求項２０】
前記プロセッサは、アルファチャネルが失われたカラー情報を表示できるように、適用されるアルファチャネルを有する前記着色画像を、前記画像の上に重ねることにより、前記着色画像から失われたカラー情報を復元するように構成される、
請求項１２に記載の画像を着色する方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般的にデジタルデータの処理に関する。特に、本発明は画像データを処理するためのシステムに関する。
【背景技術】
【０００２】
ビデオゲーム用のグラフィックスのカスタマイズ、プロダクティビティ及び他のアプリケーションを提供することは、ユーザに有意な価値をもたらす機能であると評価されることがよくある。しかしながら、多くのアプリケーションは、あるグラフィカルなカスタマイズ効果を達成するのに、クライアント及びとサーバのコンピューティングリソースを非効率的に使用する傾向があることにより、インターフェースの動作が遅く反応しなくなり、ユーザをイライラさせる。オンラインインターネットのコンテキストでは、帯域幅が大きいアプリケーションは処理の準備ができていないサーバの容量をオーバーロードにし、サービスの遅延又は機能停止をもたらす。さらに、ユーザは、インターネット接続が遅いと、多くのアプリケーションに必要とされる長いダウンロード時間にイライラをつのらせ、ユーザは最終的に断念し、インターネットのコンテンツをほかのどこかで探すことになる。ユーザのこのようなマイグレーションを防ぐために、広い範囲のハードウェア構成とインターネットの接続速度に拡張可能な快適で反応の良いユーザ体験を与えることが必須である。
【０００３】
同じ基本原理は、コンテンツの創作者、すなわち、アプリケーションに用いるべき創造的なコンテンツを作る開発者にとっての開発にも当てはまる。複雑な技術的及び手順のガイドラインは、ワークフローのプロセスを制限し、コンテンツの創作を妨げることになり、ストレスと無駄な努力感を引き起こし、最終作業製品にマイナスの影響を与える可能性がる。反対に、コンテンツの創作プロセスがより容易になり、もっと分かりやすくなれば、コンテンツの創作者は、新たなモチベーションと、より高いプロダクティビティを持って創造的アイデアを深く探求して、エンドユーザ向けコンテンツの質を改善することができる。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
上述したように、特定のアプリケーションを悩ましている１つの問題は、特定の視覚効果を達成するのに、単純ではあるが効果的で視覚的にアピールする方法を使用できないことである。コンテンツの創作者は、望ましい効果を成就するために、時間のかかる次善策を用いて、擬装のカスタムコンテンツを創作せざるを得ないことがよくあり、開発時間と乏しいリソースを無駄にしている。アプリケーションは、望ましい視覚効果を提供するために、非効率的でリソース集中型のプログラマティックな方法を実装することもできるが、ユーザ体験の質を落とすことになる。
【０００５】
従って、円滑なコンテンツ開発のワークフローを促進しながら、サーバ及びクライアントのリソースを効率的に用いる方法で、特定のカスタム視覚効果を達成するアプリケーションのための方法を提供することにより、従来技術の欠点と欠陥を克服する必要がある。
【課題を解決するための手段】
【０００６】
本発明によれば、少なくとも１つの図面に示され、及び／又は、図面に関連して記載され、特許請求の範囲にもっと完全に記載されているように、カスタマイズ可能な着色画像をサポートするユーザインターフェースを提供するアプリケーションにより使用するために、彩度マップを用いるモノクロ着色により画像に着色するためのシステムと方法が、提供される。
【０００７】
本発明の特徴及び利点は、以下の詳細な説明及び添付図面をレビューした後に、当業者にはもっと容易に明らかになるであろう。
【図面の簡単な説明】
【０００８】
【図１】アプリケーションを実行するプロセッサが、彩度マップを用いるモノクロ着色により画像に着色することができる、本発明の一実施形態によるステップを視覚的に記述しているフローチャートである。
【図２】アプリケーションを実行するプロセッサが、多数の彩度マップを用いるモノクロ着色により、画像にマルチトーン着色することができる、本発明の一実施形態によるステップを視覚的に記述しているフローチャートである。
【図３】アプリケーションを実行するプロセッサが、本発明の一実施形態に従って、彩度マップを用いるモノクロ着色により、カスタマイズ可能な着色画像をサポートするユーザインターフェースを提供できる、アプリケーション環境を示す図である。
【図４】アプリケーションを実行するプロセッサが、彩度マップを用いるモノクロ着色により画像に着色することができる、本発明の一実施形態によるステップを記述しているフローチャートである。
【発明を実施するための形態】
【０００９】
本出願は、カスタマイズ可能な着色画像をサポートするユーザインターフェースを提供するアプリケーションにより使用するために、彩度マップを用いるモノクロ着色により画像に着色するためのシステム及び方法を対象としたものである。以下の説明は本発明の実施に関する具体的情報を含む。当業者は、本発明が本出願で具体的に述べる方法とは異なる方法で実施できることを認識するであろう。その上、本発明の特定な細部のいくつかは、本発明を曖昧にしないため述べないものとする。本出願で記載しない特定な細部は、当業者の知識の範囲内である。本出願の図面及び付随の詳細な説明は、本発明の単なる例示実施形態を対象としたものである。簡潔にするために、本発明の原理を用いる本発明の他の実施形態は、本出願において具体的に記載せず、また、本図面においても具体的に例示していない。
【００１０】
図１は、アプリケーションを実行するプロセッサが彩度マップを用いるモノクロ着色により画像に着色できる、本発明の一実施形態によるステップを視覚的に記述しているフローチャートを示す。この着色フローチャート１００は、彩度マップ１１０、反転彩度マップ１１１、スクリーンブレンドした彩度マップ１１２、明度マップ１２０、赤、緑、青（RGB）の色合いのカラー値１３０、着色カラー１３５、着色画像１３９及び着色画像１４０を含む。
【００１１】
図１では、規定寸法の自動車の原画像を２つの別々のマッピング、すなわち、彩度マップ１１０と明度マップ１２０とに変換して編集する。原画像は、寸法が８００ピクセル幅×３００ピクセル高さの自動車のフルカラーRGB画像とすることができる。対応する画像マップは、それから標準の赤、緑、青（RGB）の色空間から色相、彩度、明度の（HSV）色モデル表現への、周知の変換アルゴリズムを用いて最初に導き出すことができる。RGBにおけるように、加えるべき赤、緑、青の光の量を指定する代わりに、HSVは、色相、すなわち、赤又は黄色のような特定の色合いと、彩度、すなわち、同等の明るさの灰色からの色の量と、明度、すなわち、輝度とも呼ばれ、黒から純粋色までの色を計るものとにより色を表現する。色の強さは彩度の要素内で分離でき、RGBだけでは表現しにくいことがあるカラー操作を容易にするので、HSV色モデルは、RGBの代わりになるものとして有用である。
【００１２】
彩度と色相の要素を取り除くと、黒から白までの明度の要素しか残らないため、明度マップ１２０は原画像のモノクロ表現にすぎないので、明度マップは慨して自動的に生成できる。しかしながら、彩度マップ１１０は、最初に原画像から望ましい彩度の要素を分離した後に、何らかのプログラム的又は手作業による修正を必要とする。純粋に原画像から得た彩度マップによって、全原画像を所定の色合いの色で着色することになる。一般に、このことは、原画像の他の部分は、異なる色で着色するか、又は単に無修正のままで、モノクロに変換する必要があり得るので、望ましい結果にはならないかも知れない。従って、彩度マップ１１０のホイール、ナンバープレート、排気管及び自動車の他の非車体要素は、これらの要素が着色されると不自然に見えるので、彩度０の方へとシフトする。これは、例えば、赤塗り作業する車の赤色チャンネルを分離することにより、もっと容易に得られることになる。
【００１３】
彩度マップ１１０を調べると、より小さい彩度要素値は黒で描かれ、より大きい彩度を示すのに対し、より大きい彩度要素値は白で描かれ、より小さい彩度を示すことが分かる。この彩度スケールは最初は直観に反しているように思われるかも知れないけれども、グラフィックス・アーチストは一般的に白の「白紙」のカンバスに描くことに慣れているので、より低い彩度が「色の欠如」又は白に向く傾向にあることは、視覚的にもっと自然であるかも知れない。しかしながら、コンピュータシステムでは、「色の欠如」は一般的に黒に関連付けており、より低い値は黒に向く傾向を意味している。大抵のディスプレイ技術は、色を送信するのに光を混合することに頼っており、これは、「色の欠如」を黒とする加法カラーシステムであるので、コンピュータシステムは、画像データに対してRGBの表現を用いる傾向にある。
【００１４】
しかしながら、彩度マップ１１０を格納するために選定する特定のスケールは任意であり、そのスケールは別の実施形態では、関連する着色計算ステップも必要に応じて調整して、容易に反転させることができる。特に、彩度マップ１１０を直接編集可能なグレイスケール画像として格納する場合には、より白い領域をより小さい飽和色として表現することは、グラフィックス・アーチストの直観にもっと近づけることになるから、図１に採用したスケールは編集するのに好適である。さらに、白が０に対応する彩度スケールを用いる彩度マップ１１０を格納することは、以下に述べるように、スクリーンブレンドステップを簡単にする。
【００１５】
図１を続けて調べると、RGBの色合いのカラー値１３０は、３つのカラー値としてRすなわち赤を２５５、Gすなわち緑を２５５、及び、Bすなわち青を０００として示している。RGBの色合いのカラー値１３０は、３つ一組のRGBのカラー値で表わされる。RGBの色合いのカラー値１３０は、２５５が８ビットで表わすことができる最大数であるので、８ビットの色深度を有する。従って、RGBの色合いのカラー値１３０の値は、最大の赤、最大の緑、最小の青を示す。
【００１６】
図１では、色成分を表わすワードサイズ、すなわちビット数を、全ての色成分の右上部に示している。カラー画像は、RGBのカラー値すなわちビットの深度で示される３つの値、すなわち、赤のカラー値、緑のカラー値及び青のカラー値で表わされる。モノクロ画像は、図示のビット深度での単一のモノクロ値で表わされ、いずれもモノクロ値に等しくセットされる赤、緑及び青のカラー値を有するカラー画像に相当する。
【００１７】
RGBの色合いのカラー値１３０は、カラー値ごとに８ビット、すなわち１ピクセル当り２４ビットとして表わすけれども、別の実施形態では、異なるRGBの色空間、又は色深度を用いることができる。例えば、１つのカラー値当り１６ビット、すなわち１ピクセル当り４８ビットを提供するコンピュータディスプレイが将来もっと普及するようになるかもしれない。さらに、広い色域のモニターを目指す最近の傾向は、正しい色のためにRGB値を直接標準のRGB（sRGB）の色域ディスプレイにマッピングするという従来の仮定を無効にしている。それから、広い色域のディスプレイ上に色を正しく変換するのに、カラー管理を使用できる。標準のRGB（sRGB）の色域にマッピングすることは、現在は、画像のピクセルデータを格納するのに最も普及している方法ではあるが、ディスプレイ技術の将来の発展によって、画像データを格納する新しいフォーマットを導入し、例えば、新たな原色を加えて、色域を広げることができるかもしれない。本発明の原理は、これらの新しいフォーマットにも、適用可能である。
【００１８】
図１の上から下へ見ると、RGBの色合いのカラー値１３０を混合すると、黄色の着色カラー１３５になることを見ることができる。本実施例の目的のために、着色カラー１３５を原画像に着色するための色として選定するが、任意の色を用いることができる。それから、着色カラー１３５は彩度マップ１１０に相等する寸法を有する画像をベタに塗りつぶす色の画像として処理する。このベタに塗りつぶす色の画像は、実際には、生成する必要はなく、画像処理計算の中で統合できるが、説明する目的のため、着色画像１４０を生成するための中間ステップを明らかにするのに役立てることができる。
【００１９】
着色カラー１３５及び彩度マップ１１０を入力として準備した後に、これらの入力をスクリーンブレンドすることにより一時的画像であるスクリーンブレンドした彩度マップ１１２を得ることができる。スクリーンブレンドする簡単なアルゴリズムを図１に解説している。この機能は画像編集ソフトウェアとして一般に入手可能な「スクリーン」層ブレンディングモードに等価である。
【００２０】
スクリーンブレンディングステップをもっと詳細に説明するために、「反転」とは、明度をそのワードサイズで表現可能な最大可能値から引き算することと定義すれば、スクリーンブレンドにより得られる出力カラー要素、すなわち図１の「Output.C」は３つのステップで生成することができる。第１のステップは、２つの入力ピクセル、すなわち図１の「X」と「Y」を前提として、入力ピクセル「X」の逆数と入力ピクセル「Y」の逆数とを一緒に乗算する。これを、図１では「（Max−X.C)*(Max−Y.C)」により表わしている。第２のステップでは、第１のステップからの結果をワードサイズの分だけ論理的に右へビットシフトさせる。これは、ワードサイズで規定される可能な値の数により割り算することにより、第１のステップの結果を有効に正規化することである。論理的なビットシフトは、除算演算に近づけることにすぎないけれども、どんな場合にも整数でのみ結果を表わすことができる整数演算にとっては、計算的に非常に速くなる。これを、図１では「>>Depth」により表わしている。第３のステップでは、第２のステップからの結果そのものを反転させる。これを、図１では最初の「Max−」の表現により表わしている。
【００２１】
それから、これらの３つのステップは、各々の色成分、すなわち図１で「R,G,B」を表わす「C.」に対して繰り返すことができる。入力「X」として着色カラー１３５を表わすベタに塗りつぶす色の画像と入力「Y」として彩度マップ１１０のカラー画像バージョンとを用いることにより、出力「Output」としてスクリーンブレンドした彩度マップ１１２を生成することができる。彩度マップ１１０はモノクロ画像として格納できるけれども、３つの全ての色成分を対応するモノクロ値に相当するように設定することにより、モノクロ画像をカラー画像バージョンに簡単に変換できる。例えば、モノクロのピクセルが５５を指定する場合には、対応するカラーピクセルは、赤に対しては５５を、緑に対しては５５を、青に対しては５５を指定するだけである。
【００２２】
一旦、スクリーンブレンドした彩度マップ１１２が利用可能になれば、それに明度マップ１２０のカラー画像バージョンを乗算することができる。これは、各入力からの対応するカラー成分を直接乗算することにより達成でき、各原入力のビット深度の２倍を有する出力が得られる。従って、図１に示すように、着色画像１３９は１６ビットカラーで表わされる。
【００２３】
元のRGBの色合いのカラー値１３０は８ビットの色深度で表わしたので、正規化ステップにより、着色画像１３９の１６ビットのカラー値を元の８ビット色深度に戻す変換ができる。この正規化ステップは、例えば、色深度だけ右へ、すなわち８ビットだけ右へ論理的にビットシフトすることにより、達成できる。これは、８ビットで規定される可能値の数、すなわち２５６により除算をすることにほぼ相当する。これにより８ビットのカラー値で表される着色画像１４０が得られる。従って、望ましい結果が着色画像１４０として生成され、原画像からの車の本体は、RGBの色合いのカラー値１３０により指定される黄色に着色される。
【００２４】
図１にて用いられる計算の特定のステップ及び順序付けは、１つの可能な実施形態を表わしたに過ぎず、同じ明度及び彩度マップのコンセプトで異なる計算ステップを用いる別の実施形態も同じく有効である。図１のプロセスは、主として理解し易くするために提示したのであって、作業負荷の最適化のものではない。例えば、図１に示した多くのステップは、個別のステップとして示してあるが、効率をより大きくするためにグループ化して組み合わせたものにすることもできる。同様に、結果のキャッシング、前もって計算したルックアップテーブル、推定、並べ替え、及び他の最適化は、処理の作業負荷を減らすのに役立つ。
【００２５】
図２は、アプリケーションを実行するプロセッサが、多数の彩度マップを用いるモノクロ着色により、画像にマルチトーン着色することができる、本発明の一実施形態によるステップを視覚的に記述しているフローチャートである。ツートーン着色するフローチャート２００は、彩度マップ２１０ａ、第２の彩度マップ２１０ｂ、明度マップ２２０、着色カラー２３５ａ、第２の着色カラー２３５ｂ、着色画像２４０、及びツートーン着色画像２４１を含む。明度マップ２２０は図１からの明度マップ１２０に対応する。着色カラー２３５ａは図１からの着色カラー１３５に対応する。着色画像２４０は図１からの着色画像１４０に対応する。
【００２６】
図２は着色画像２４０を生成するための入力を簡略化した図を示す。彩度マップにより画像に着色するプロセスには、図１で述べたように、着色プロセス用に着色カラー、彩度マップ及び明度マップの最小限の入力を必要とする。図２では、これらの入力は、着色カラー２３５ａ、彩度マップ２１０ａ及び明度マップ２２０によりそれぞれ与えられる。図１内の他の要素は、着色プロセスにおける独立入力というよりはむしろ計算目的のための中間派生的のものであるため、図２では省いてある。図１と類似の着色プロセスを用いて、図２に示す入力から着色画像２４０を作成することができる。
【００２７】
彩度マップ２１０ａを調べると、図１の彩度マップ１１０との違いが分かる。彩度マップ１１０では、自動車のブレーキ灯が、いくらか飽和値になっているので、着色画像１４０において、いくらか黄色に着色されている。このことは、ブレーキ灯は、通常、赤に着色されるので、視覚的に奇妙に見える。従って、図２では、ブレーキ灯が、彩度マップ２１０ａにおいて、飽和しないようにして、着色画像２４０におけるブレーキ灯が殆んどグレースケールで描画されるようにする。それから、着色プロセスの別のパスにより、ブレーキ灯を赤色に着色できる。同様に、車体にツートーンの塗り作業を所望する場合には、着色プロセスの別のパスにより第２の色調の塗り作業を行うことができる。
【００２８】
従って、独立した色相の着色カラーを画像に着色する必要のある状況では、着色プロセスにおける単一の彩度マップでは不十分なことがある。例えば、着色画像は、主として二次元のユーザインターフェースを用いるアプリケーションにとってのスプライトとすることができる。他方、単一の着色カラーは、他のカラートーン又は画像セグメントを着色画像にリアルタイムで重ね合わせるアプリケーションにとっては、十分である。例えば、アプリケーションによっては、レンダリングエンジンにおいて、三次元の表面に対するテクスチャとして着色画像を用いることがあり、この場合には、適当な表面をレンダリングシーンに単に加えることにより、他の色相を加えることができる。主として二次元のアプリケーションは、他の色相又は画像セグメントを重ね合わせるために、リアルタイムのアルファチャネルサポートを適用することがある。従って、アプリケーションの要件に応じて、単一の又はマルチトーンの着色画像が所望されることがある。
【００２９】
図２は、図１の着色プロシージャが、２つの彩度マップと２つの着色カラーを、どのように使用して、ツートーンの着色画像２４１を生成することができるかを、示している。着色プロシージャは、必要なだけ多くの独立した色相の着色カラーに対して用いることができるが、着色カラー及び彩度マップの数が増えるために、プロセッサリソースのリターンが減少することになる。この場合に、調整可能なパレット又は色相シフトを伴うインデックスカラーのような従来の着色方法は、より良い性能を提供できるが、より大きい開発リソースを必要とし、画質を落とすことになる。
【００３０】
着色プロシージャの第２のパスは、着色画像２４０が明度マップ２２０のグレースケールRGBレンダリングの代わりになることを除いて、第１のパスと殆んど同じである。従って、着色プロシージャへの入力は、第２の彩度マップ２１０b、第２の着色カラー２３５b及び明度マップとして作用する着色画像２４０を含む。図２に示すように、第２の彩度マップ２１０bは彩度をブレーキ灯の領域に適用するだけであり、第２の着色カラー２３５bは赤又は（２５５，０００，０００）として示される。そのほかの点では、ツートーン着色画像２４１を生成するために、第２のパスは、なお、図１に類似の着色プロセスに従う。
【００３１】
図１と同様に、図２のステップは一実施形態を表わし、異なる計算方法を用いるが、彩度マップ２１０ａ及び第２の彩度マップ２１０bに頼る他の実施形態も使用できる。例えば、ツートーンの着色プロセスを各々の彩度マップに対して２つの別個のパスに分けるよりも、全ての着色カラーと彩度マップを通して各々のピクセルを処理する単一のパスを用いて、処理リソースの最適化を図ることができる。
【００３２】
図３は、アプリケーションを実行するプロセッサが、本発明の一実施形態に従って、彩度マップを用いるモノクロ着色によるカスタマイズ可能な着色画像をサポートするユーザインターフェースを提供できるアプリケーション環境を示している。アプリケーション環境３００は、コンピュータ３７０、画像サーバ３８０及びディスプレイ３９０を含む。コンピュータ３７０はプロセッサ３７１及びメモリ３７５を含む。メモリ３７５は、着色カラー３３０ａ、着色カラー３３０ｂ、着色カラー３３０ｃ、第２の着色カラー３３１及びアプリケーション３７６を含む。画像サーバ３８０は、メタデータ３８６、赤チャネル３８７、緑チャネル３８８及び青チャネル３８９を含む画像ファイル３８５を含む。第２の彩度マップ３１０bは赤チャネル３８７に埋め込まれ、彩度マップ３１０ａは緑チャネル３８８に埋め込まれ、明度マップ３２０は青チャネル３８９に埋め込まれる。ディスプレイ３９０は、ツートーン着色画像３４１ａ、ツートーン着色画像３４１ｂ及びツートーン着色画像３４１ｃを含む、ユーザインターフェース３９１を示す。
【００３３】
図３は、図１及び図２で既に詳細に説明した着色プロセスを用いるシステムの様々な部分の一般化ブロック図を示す。コンピュータ３７０内で、プロセッサ３７１はメモリ３７５にアクセスでき、メモリ３７５は、黄色すなわち（２５５，２５５，０００）としての着色カラー３３０ａ、紫すなわち（２５５，０００，２５５）としての着色カラー３３０ｂ、青すなわち（０００，０００，２５５）としての着色カラー３３０ｃ、及び赤すなわち（２５５，０００，０００）としての第２の着色カラー３３１を含む。加えて、プロセッサ３７１は、コンピュータ３７０に取り付けたディスプレイ３９０にユーザインターフェース３９１を提供する、アプリケーション３７６を実行できる。アプリケーション３７６は、例えば、フラッシュアプリケーション、シルバーライトアプリケーション、ジャバアプリケーション又はパソコン、ビデオゲームコンソール又は他のプラットフォーム用に実行されるネイティブ・バイナリで構成することが可能である。
【００３４】
ユーザインターフェース３９１を提供するために、アプリケーション３７６は、着色プロセス用のHSVマップを包含している画像ファイル３８５用の、画像サーバ３８０に先ず問い合わせることになる。メモリ３７５は既に様々な着色カラーを格納しているけれども、プロセッサ３７１は、彩度マップ３１０ａ、第２の彩度マップ３１０ｂ及び明度マップ３２０を含む様々なHSVマップにもアクセスする必要がある。配分を容易にするために、HSVマップは、画像ファイル３８５に示されるように、画像ファイルの別個のカラーチャネルに埋め込むようにする。各々のHSVマップは単一の変数である、色相、彩度又は明度をたどるだけなので、HSVマップのデータは任意のカラーチャネル内に埋め込むことができる。従って、３つのHSVマップを画像ファイル３８５として単一のRGB画像内に埋め込むことにより、アプリケーション３７６は、画像サーバ３８０に対し、３つの画像ファイル要求よりも１つの画像ファイル要求をすることができる。次に、アプリケーション３７６を実行するプロセッサ３７１は、画像ファイル３８５を受信した後に、HSVマップをメモリ３７５に引き抜くことができる。
【００３５】
HSVマップを単一の画像ファイル内に埋め込むことにより、３つの別個のファイルを要求し、受信を確認し、且つ送信する必要がなくなるので、コンピュータ３７０と画像サーバ３８０との間のネットワーク性能を改善できる。加えて、JPEG又はPNGのような標準化され広くサポートされている画像ファイルフォーマットを用いることができ、カスタムコードを用いずに、画像圧縮のようなファイルフォーマットの特徴をうまく利用するように、既存の画像処理ライブラリ及びコードルーチンを活用できる。ファイルフォーマットにより与えられるカラーチャネルの数より少ないHSVマップで済めば、残りの空のカラーチャネルは他のデータを格納するのに使用するか、又は、空又は未使用のままとすることができる。更に、カラーチャネルは、カラー情報のためよりも、一般的データを格納するために用いられるので、特定のHSVマップを格納するためのカラーチャネルの選択は任意である。例えば、第２の彩度マップ３１０ｂは、緑チャネル３８８又は青チャネル３８９内に代わりに置くこともできるが、自由裁量で赤チャネル３８７に置いている。そのために、メタデータ３８６は、各々のカラーチャネルの特定の内容を指定する識別情報を提供するか、又は、特定のチャネルが、特定のHSVマップを常に格納し得るようにする。例えば、青チャネルは常に明度マップを搬送するようにする。
【００３６】
プロセッサ３７１がHSVマップをメモリ３７５に引き抜き終えた後に、メモリ３７５は、図２に示したプロセスと類似のプロセスを用いて、ツートーンの着色画像３４１ａ、ツートーンの着色画像３４１ｂ及びツートーンの着色画像３４１ｃを生成するための入力を包含することになる。一旦、これらのツートーンの着色画像を生成すれば、それらはユーザインターフェース３９１の一部として、ディスプレイ３９０に送ることができ、ユーザ実行のアプリケーション３７６に自動車用のカスタムカラーを選別させることができる。図３に示した実施形態では、ユーザインターフェース３９１は所定の色で着色した画像を示しているが、別の実施形態では、ユーザからのカスタム着色カラーを要求することにより、ユーザに任意の所望の着色カラーを選択させることができる。例えば、ユーザインターフェース３９１は、赤、緑及び青に対応する３つのスライダーを表示させて、ユーザに、ユーザの好みに従って着色カラーを調整させることができる。
【００３７】
一旦、着色カラーが選択されると、例えば、レーシングゲーム、自動車のＥコマースアプリケーション、自動車向けのバーチャルコミュニティをサポートするアプリケーション３７６、又は、カスタマイズ可能な着色画像を必要とする他の任意のアプリケーションに、着色画像を用いることができるであろう。更に、対象は、自動車に限定されず、ビデオゲームキャラクター、家具、インテリアデザイン、衣類及び着色を必要とし得る無数の他の物のような着色を必要とする任意の物に適用できるであろう。着色画像は、上記図２で議論したように、アプリケーション３７６の三次元レンダラーにおいて、表面用地柄として用いることさえできるかもしれない。
【００３８】
図４は、アプリケーションを実行するプロセッサが、彩度マップを用いるモノクロ着色することにより画像に着色することができる、本発明の一実施形態によるステップを記述しているフローチャートを示す。各々のステップは、図からの例の入力データを用いる疑似コード４１１〜４５１の説明も伴っている。当業者に明らかな一定の詳細と特徴はフローチャート４００から除外してある。例えば、公知技術として、ステップは、１つ以上のサブステップを備えることができ、特殊な装置又は材料を含むことができる。フローチャート４００に示されたステップ４１０〜４５０は、本発明の一実施形態を説明するのに十分であるものの、本発明の他の実施形態はフローチャート４００に示されたステップと異なるステップを利用できる。
【００３９】
図４のフローチャート４００のステップ４１０及び図３のアプリケーション環境３００を参照すると、フローチャート４００のステップ４１０は、RGBの色空間における各々のカラー値がカラー値ごとに８ビットで定義する色深度を有し、赤のカラー値が２５５であり、緑のカラー値が２５５であり、青のカラー値が０００である、着色カラーを、プロセッサ３７１が実行するアプリケーション３７６がメモリ３７５に格納するステップから成る。これらの動作はCスタイル文法に緩く従う疑似コード４１１で例示されている。色深度（Depth）は８ビットに決められ、関連する最大値（Max）は、１を左へ８ビットだけ論理的にビットシフトした値から１を引くことにより計算される。これは、２の８乗を計算し、１を引くことと同じであるが、プロセッサ上で論理ビットシフトは同等の演算よりもより速く実行できる。この「Max」値は後の使用のためにメモリ３７５に保存される。そして、RGBのカラー値は、（２５５，２５５，０００）を形成するRGBのカラー値、すなわち黄色である着色カラー３３０ａとして、指定される。疑似コード４１１において、RGBのカラー値は、ハードコードされているが、アプリケーション３７６により生成される、又は、ユーザからユーザインターフェース３９１経由で要求される画像サーバ３８０から検索できるであろう。
【００４０】
図４のフローチャート４００のステップ４２０及び図３のアプリケーション環境３００を参照すると、フローチャート４００のステップ４２０は、着色すべき車の画像から導かれたHSV表現を用いて、プロセッサ３７１が彩度マップ３１０ａ及び明度マップ３２０を検索するステップから成る。疑似コード４２１において、GetHSVルーチンは、画像サーバ３８０に問い合わせを行い画像ファイル３８５を検索する。画像ファイル３８５が検索された後に、HSVマップは、カラーチャネルから、メモリ３７５の格納用に彩度マップグレースケール画像及び明度マップグレースケール画像へ引き出される。疑似コード４２１において、彩度マップは緑チャネルとしてハードコードされ、明度マップ３２０は青チャネルとしてハードコードされるが、カラーチャネルへのマッピングは埋め込むこともできるであろうしメタデータ３８６から引き出すこともできるであろうし、又は、いくつかの他のマッピング技法に従うこともできるであろう。
【００４１】
図４のフローチャート４００のステップ４３０及び図３のアプリケーション環境３００を参照すると、フローチャート４００のステップ４３０は、着色カラー（Tint）３３０ａをベタに塗りつぶす色として、彩度マップ（S）３１０ａを用いてスクリーンブレンドにより、プロセッサ３７１が中間画像（Temp）を作るステップから成る。疑似コード４３１を調べると、ステップ４３０は、図１に示されたスクリーンブレンドアルゴリズムで説明された同じプロセスにより、達成される。すなわち、各々の入力ピクセル（S及びTintにおける定数としてのピクセルI）の各々のカラー要素（R,G,B）に対して、各々の入力ピクセルの逆数が一緒に掛け合わされ、その結果の積自体が反転され、反転は最大値（Max）から入力を引くこととして定義される。結果は一時的中間画像（Temp）として保存される。
【００４２】
図４のフローチャート４００のステップ４４０及び図３のアプリケーション環境３００を参照すると、フローチャート４００のステップ４４０は、プロセッサ３７１がステップ４３０からの中間画像（Temp）に明度マップ（V）３２０を乗じるステップから成る。疑似コード４４１を調べると、ステップ４４０は、ステップ４３０の中間画像（Temp）からの各々の入力ピクセルのカラー要素（R,G,B）と明度マップ（V）との直接的乗算を適用する。中間画像（Temp）は、それから、その結果の積を用いて更新される。
【００４３】
図４のフローチャート４００のステップ４５０及び図３のアプリケーション環境３００を参照すると、フローチャート４００のステップ４５０は、着色画像（T）を作るために、ステップ４１０のRGBの色空間の色深度（Depth）内で、ステップ４４０からの中間画像（Temp）をプロセッサ３７１が正規化するステップから成る。元の着色カラーは８ビットのカラー値で規定されているのに、ステップ４４０後は、中間画像（Temp）は１６ビットのカラー値で保存されているので、最終の画像が元の着色カラーのビット深度に一致するように、ステップ４４０後のビット深度を調整することが適切であるといえる。従って、中間画像（Temp）の各々のピクセルをビット深度、すなわち８ビットだけ、論理的に右にビットシフトし、その結果、最終的に８ビットのカラー値となる。この結果は、それから、最終の着色画像（T）として、保存される。ステップ４５０の後、「T」すなわち着色画像は、ディスプレイ３９０に示す準備ができており、又は、アプリケーション３７６により更に操作する準備ができている。「T」に対応する画像は、図２の着色画像２４０に類似しているように見えるかもしれない。
【００４４】
着色画像「T」が生成された後に、元の画像から失われたカラー情報を復元するために、アプリケーション３７６は、更に、アルファチャネルを用いて、透過的な階層化手続き経由で、操作できる。例えば、自動車の元の画像におけるナンバープレートは、色彩豊かなカスタムナンバープレートを持っていたかもしれないが、元の画像が着色プロセスを経由すると、カスタムナンバープレートからのカラー情報は着色画像において失われている。着色領域が不透明で非着色領域が透明なように、アルファチャネルが着色画像に適用されるならば、このカラー情報は復元可能にできる。それから、アルファチャネルを有するこの着色画像は、元の画像の上に重ねることができ、特定の領域を着色する能力を加えながら、元の画像のカラー情報を保有できる。画像ファイル３８５において、空のカラーチャネルが利用できるならば、HSVマップと一緒にアルファチャネルを単一の画像ファイルに埋め込むこともできるであろう。代替的に、明度マップ３２０内の特定の値を透過の目的のために留保できるかもしれない。しかし、透過エッジは制限されたアルファ値によりアーチファクトを示す可能性があるので、この代替的方法は、色深度が低いならば、満足する結果を提供できない。
【００４５】
元の画像からカラーを復元するほかに、アルファチャネルは、アプリケーション３７６によりサポートされるユーザインターフェース３９１内の透明性をサポートするために用いることができるであろう。例えば、ンターフェース３９１内で示される車の画像は、全て、望ましくない可視のアーチファクトを表わし得る黒の背景を含む。この場合に、黒の背景を透明にするために、アルファチャネルを適用でき、車のみを周囲の黒の領域がないように表示でき、もっと視覚的にアピールできる。
【００４６】
上述したように、他の色相の追加をサポートできる三次元レンダラー又はリアルタイムの変換を提供する別のエンジンにおいて、結果の着色画像を使用できるかもしれないので、追加の色相を提供するために、透明性を用いることは必要でないのかもしれない。しかしながら、主として、二次元アプリケーションインターフェース用に、透明効果の階層化は追加のカラー操作のために追加の柔軟性を提供できる。
【００４７】
本発明の上記の記載から、本発明の範囲から逸脱することなく、本発明の概念を実施するために、様々な技術を使用できることは明白である。更に、本発明を特定の実施形態で特別に参照して説明したが、本発明の精神及び範囲から逸脱することなく、形式及び細部を変更できることを当業者は認めるであろう。そのようなものとして、記載された実施形態は、全ての点において、例示的であり、限定的でないとして考慮されるべきである。本発明は、ここに記載された特定の実施形態に限定されず、本発明の範囲から逸脱することなく、多くの再配置、修正及び置換ができる。
【符号の説明】
【００４８】
１００    着色フローチャート
１１０、２１０ａ    彩度マップ
１１１    反転彩度マップ
１１２    スクリーンブレンドした彩度マップ
１２０、２２０    明度マップ
１３０    赤、緑、青（RGB）の色合いのカラー値
１３５、２３５ａ、３３０ａ、３３０ｂ、３３０ｃ    着色カラー
１３９、１４０、２４０    着色画像
２００    ツートーン着色するフローチャート
２１０ｂ第２の彩度マップ
２３５ｂ、３３１    第２の着色カラー
２４１    ツートーン着色画像
３００    アプリケーション環境
３７０    コンピュータ
３７５    メモリ
３７６    アプリケーション
３７１    プロセッサ
３８０    画像サーバ
３８５    画像ファイル
３８６    メタデータ
３８７    赤チャネル
３８８    緑チャネル
３８９    青チャネル
３９０    ディスプレイ
【図１】
2010161779.tif 000003
【図２】
2010161779.tif 000004
【図３】
2010161779.tif 000005
【図４】
2010161779.tif 000006
【外国語明細書】
2010161779000001.pdf