特許 6563915 ＨＤＲ画像のための汎用コードマッピングのためのＥＯＴＦ関数を生成するための方法及び装置、並びにこれらの画像を用いる方法及び処理

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6563915

(24)【登録日】2019年8月2日

(45)【発行日】2019年8月21日

(54)【発明の名称】ＨＤＲ画像のための汎用コードマッピングのためのＥＯＴＦ関数を生成するための方法及び装置、並びにこれらの画像を用いる方法及び処理

(51)【国際特許分類】

   H04N 19/85 20140101AFI20190808BHJP

   H04N 19/46 20140101ALI20190808BHJP

【ＦＩ】

   H04N19/85

   H04N19/46

【請求項の数】11

【全頁数】32

(21)【出願番号】特願2016-526497(P2016-526497)

(86)(22)【出願日】2014年7月1日

(65)【公表番号】特表2016-533072(P2016-533072A)

(43)【公表日】2016年10月20日

(86)【国際出願番号】EP2014063890

(87)【国際公開番号】WO2015007510

(87)【国際公開日】20150122

【審査請求日】2017年6月28日

(31)【優先権主張番号】13176612.3

(32)【優先日】2013年7月16日

(33)【優先権主張国】EP

(73)【特許権者】

【識別番号】590000248

【氏名又は名称】コーニンクレッカ フィリップス エヌ ヴェ

【氏名又は名称原語表記】ＫＯＮＩＮＫＬＩＪＫＥ ＰＨＩＬＩＰＳ Ｎ．Ｖ．

(74)【代理人】

【識別番号】110001690

【氏名又は名称】特許業務法人Ｍ＆Ｓパートナーズ

(74)【代理人】

【識別番号】100122769

【弁理士】

【氏名又は名称】笛田 秀仙

(74)【代理人】

【識別番号】100163810

【弁理士】

【氏名又は名称】小松 広和

(72)【発明者】

【氏名】ファン デル ヴルーテン レナトゥス ジョセフス

【審査官】 坂東 大五郎

(56)【参考文献】

【文献】 国際公開第２０１２／１１８９６１（ＷＯ，Ａ１）

【文献】 国際公開第２０１３／０８６１６９（ＷＯ，Ａ１）

【文献】 国際公開第２０１２／１４７０１８（ＷＯ，Ａ２）

【文献】 国際公開第２０１２／１２７４０１（ＷＯ，Ａ１）

【文献】 国際公開第２００７／１１９５３９（ＷＯ，Ａ１）

【文献】 米国特許出願公開第２０１０／００９２１０４（ＵＳ，Ａ１）

【文献】 国際公開第２０１２／１２５８０２（ＷＯ，Ａ１）

【文献】 野口 孝文等，コンストラクションセットを持つマイクロワールド，情報処理学会論文誌，日本，１９９５年 １月３１日，第３６巻 第１号，１５３−１６６頁

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｎ １９／００−１９／９８

(57)【特許請求の範囲】

【請求項1】

画像を符号化するための方法であって、前記方法は、
線形ルミナンス値を持つ画素を有する入力高ダイナミックレンジ画像を受信するステップと、
画素の線形ルミナンス値をルマコードにマッピングするためにコード配分関数を構成するステップと、
前記コード配分関数を適用することによって、前記入力高ダイナミックレンジ画像における画素の線形ルミナンス値に対応するルマコードを生成することにより、前記画素の線形ルミナンス値を、前記コード配分関数を使用してこれら線形ルミナンス値を符号化するルマコードにマッピングするステップと、
画素に対して、伝送又は格納のために符号化された画像信号内に彩度値と一緒に前記ルマコードを格納するステップと
を有し、
画素の線形ルミナンス値をルマコードへマッピングする前記コード配分関数が部分関数生成部によって決定される少なくとも２つの部分関数から構成され、
前記２つの部分関数の第１の部分関数は、第１の出力ルマコードの全体ルマ範囲への線形ルミナンス値の全体ルミナンス範囲の非線形可逆マッピングを規定し、前記２つの部分関数の第２の部分関数は、第２の出力ルマコードへ、前記２つの部分関数の第１の部分関数からの第１の出力ルマコードをマッピングし、前記第２の部分関数は、第２の出力ルマコードの全体ルマ範囲への前記第１の出力ルマコードである入力ルマコードの全体ルマ範囲の非線形可逆マッピングを規定し、前記コード配分関数は、ルマコードへの線形ルミナンス値の非線形マッピングを規定し、
前記方法は、前記第１の部分関数及び前記第２の部分関数を規定する制御データを、伝送又は格納のために前記符号化された画像信号内に格納するステップを含む、
方法。

【請求項2】

前記部分関数のうち少なくとも１つは、予め決められた色調マッピング関数である、請求項１に記載の方法。

【請求項3】

前記制御データは、前記部分関数の１つ又は複数のパラメータを有する、請求項１に記載の方法。

【請求項4】

前記部分関数のうち少なくとも１つは、ガンマ関数である、請求項１に記載の方法。

【請求項5】

前記部分関数のうち少なくとも１つは、非線形ガンマ曲線、ｓＲＧＢ仕様に従う非線形ガンマ曲線、ＩＴＵ−Ｒ ＢＴ．７０９−５仕様に従う非線形ガンマ曲線、ドルビーの知覚的な量子化関数、

【数8】

として実質的に与えられる関数（ここで、Ｙはルマ値であり、Ｖは［０；１］の範囲における線形ルミナンス入力値であり、Ｌは白色ポイントを反映する定数であり、及び、ｍ，ｎ，ｃ１，ｃ２及びｃ３は、設計パラメータである）、及び、

【数9】

として実質的に与えられる関数（ここで、ｘは［０；１］の範囲における出力値であり、ｖは［０；１］の範囲における入力値であり、値ａ，ｂ，ｃ及びｄは、設計パラメータである）からなるグループからのものである、請求項１に記載の方法。

【請求項6】

請求項１乃至５のいずれか１項に記載の方法を実行するように構成された、エンコーダ。

【請求項7】

受信した符号化された画像信号から高ダイナミックレンジ画像をデコードするための方法であって、前記方法は、
ルマコード及び彩度値を持つ画素を含む前記符号化された画像信号を受信するステップと、
第１の部分関数及び第２の部分関数を規定する制御データを、受信した前記符号化された画像信号から受信するステップと、
コードマッピング関数のための少なくとも２つの逆部分関数を決定するステップと、
前記少なくとも２つの逆部分関数に基づいて、線形ルミナンス値へルマコードをマッピングするためのコードマッピング関数を構成するステップと、
前記コードマッピング関数を適用することにより、前記高ダイナミックレンジ画像の線形ルミナンス値へ前記ルマコードをマッピングするステップと、を有し、
前記コードマッピング関数は、線形ルミナンス値へのルマコードの非線形マッピングを規定し、前記コードマッピング関数は、第１の部分関数及び第２の部分関数という逆部分関数で構成され、
前記少なくとも２つの逆部分関数の前記第１の部分関数は、出力ルマコードの全体ルマ範囲への入力ルマコードの全体ルマ範囲の非線形可逆マッピングを規定し、
前記少なくとも２つの逆部分関数の前記第２の部分関数は、線形ルミナンス値へ、前記少なくとも２つの逆部分関数の前記第１の部分関数から出力される前記出力ルマコードをマッピングし、前記第２の部分関数は、線形ルミナンス値の全体ルミナンス範囲へ、前記出力ルマコードであるルマ入力コードの全体ルマ範囲の非線形可逆マッピングを規定する、方法。

【請求項8】

前記制御データ内に含まれる前記部分関数の１つ又は複数のパラメータを受信するステップを有する、請求項７に記載の方法。

【請求項9】

コードマッピング関数を決定し、線形ルミナンス値へルマコードをマッピングすることによって、高ダイナミックレンジイメージ画像をデコードするためのデコーダであって、前記デコーダは、
前記ルマコード及び彩度値を含む符号化された画像信号を受信する手段を備え、
前記デコーダは、更に、
受信した前記符号化された画像信号内の制御データから少なくとも２つの逆部分関数を決定する第１の決定器と、
前記少なくとも２つの逆部分関数に基づいて、コードマッピング関数を決定する第２の決定器と、
前記コードマッピング関数を適用することにより、前記高ダイナミックレンジ画像の線形ルミナンス値へ前記ルマコードをマッピングする手段と、を有し、
前記コードマッピング関数は、線形ルミナンス値へのルマコードの非線形マッピングを規定し、前記コードマッピング関数は、第１の部分関数及び第２の部分関数という２つの逆部分関数から規定され、
前記少なくとも２つの逆部分関数の前記第１の部分関数は、出力ルマコードの全体ルマ範囲への入力ルマコードの全体ルマ範囲の非線形可逆マッピングを規定し、
前記少なくとも２つの逆部分関数の前記第２の部分関数は、線形ルミナンス値へ、前記少なくとも２つの逆部分関数の前記第１の部分関数から出力されるルマコードをマッピングし、前記第２の部分関数は、線形ルミナンス値の全体ルミナンス範囲へ、前記出力ルマコードであるルマ入力コードの全体ルマ範囲の非線形可逆マッピングを規定する、デコーダ。

【請求項10】

前記第１の決定器は、前記制御データ内に含まれる前記部分関数のパラメータから前記少なくとも２つの逆部分関数を決定する、請求項９に記載のデコーダ。

【請求項11】

少なくとも２つの部分関数のうちの１つは、非線形ガンマ曲線、ｓＲＧＢ仕様に従う非線形ガンマ曲線、ＩＴＵ−Ｒ ＢＴ．７０９−５仕様に従う非線形ガンマ曲線、ドルビーの知覚的な量子化関数、

【数10】

として実質的に与えられる関数（ここで、Ｙはルマ値であり、Ｖは［０；１］の範囲における線形ルミナンス入力値であり、Ｌは白色ポイントを反映する定数であり、及び、ｍ，ｎ，ｃ１，ｃ２及びｃ３は、設計パラメータである）、及び、

【数11】

として実質的に与えられる関数（ここで、ｘは［０；１］の範囲における出力値であり、ｖは［０；１］の範囲における入力値であり、値ａ，ｂ，ｃ及びｄは、設計パラメータである）からなるグループからのものである、請求項９に記載のデコーダ。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、線形輝度値とｌｕｍａコードとの間のマッピングに関し、とりわけ、排他的ではないが、例えばブルーレイディスク記憶装置又はＨＤＭＩケーブル接続のような、既存の技術の現在の枠組みに適合する、１又は好ましくはそれ以上の高ダイナミックレンジ（ＨＤＲ）画像（即ちビデオ）のエンコーディングに関する。

【背景技術】

【0002】

従来は、再生された画像のダイナミックレンジは、通常の視野に関して大幅に低減される傾向にあった。実際に、現実の世界において発生する輝度レベルは、月のない夜から直接太陽をのぞきこむことまで変化する、１４桁の大きさのダイナミックレンジに渡る。瞬間的な輝度ダイナミックレンジ及び対応する人間の視覚系応答は、快晴日又は夜（明るい反射対暗い影領域）に関して１０．０００：１と１００．０００：１との間に入り得る。昔から、ディスプレイのダイナミックレンジは、約２−３桁に限られていた。また、センサは、ノイズ許容可能性に依存して、制限された範囲を有していた（例えば＜１０．０００：１）。従って、従来のレンダリングデバイス上に知覚的に目立つアーチファクトを取り込むことなく８ビットガンマエンコードされたフォーマットにおいて画像を格納及び送信することが昔から考えられていた。しかしながら、より精密な及びより鮮明なイメージを記録する努力において、６桁を超えるダイナミックレンジを記録可能な新規なＨＤＲ（High Dynamic Range）画像センサが開発されている。更に、ほとんどの特殊効果、コンピュータグラフィックス強化及び他の製造後の作業は、より高いビット深度で及びより高いダイナミックレンジによって既に日常的に行われている。

【0003】

更に、最高水準のディスプレイシステムのコントラスト及びピーク輝度は増大し続けている。近年では、新たな試作品ディスプレイは、３０００ｃｄ／ｍ^２の高さのピーク輝度及び５−６桁のコントラスト比によって示されている。（ディスプレイ固有、表示環境は、最後にレンダリングされたコントラスト比に影響するだろう。これは、日中のテレビ表示に対するものであっても５０：１よりも低下し得る）。将来のディスプレイは、より高いダイナミックレンジ及び詳細にはより高いピーク輝度及びコントラスト比を与え得ることが期待される。

【0004】

ＨＤＲ画像は、例えば、複数の低ダイナミックレンジ（ＬＤＲ）画像を組み合わせることにより生成され得る。例えば、３つのＬＤＲ画像は異なる範囲で取り込まれ、３つのＬＤＲ画像は、個々のＬＤＲ画像のダイナミックレンジの組み合わせに等しいダイナミックレンジを有する単一の画像を生成するために組み合わせられ得る。

【0005】

ＨＤＲイメージングを正常に取り込むため、及び、ＨＤＲの将来性を完全に利用するために、増大したダイナミックレンジを扱い得るシステム及びアプローチが開発されることが重要である。更に、これは、ＬＤＲ画像処理の種々の要素及び機能がＨＤＲによって再利用されるのを可能にする機能が取り込まれた場合に望ましい。例えば、ＬＤＲのために規定されたインタフェース、通信手段又は配布媒体がＨＤＲ画像のために再利用され得ることが望ましいだろう。

【0006】

ＨＤＲイメージングに関連した１つの重要な特徴は、ＨＤＲ画像データを効率的にエンコードする方法である。

【0007】

最近、例えばＷＯ２００５／１０４００３５において開示されたドルビーのデュアルレイヤ方法のような、幾つかのＨＤＲエンコード技術が提案されている。

【0008】

例えばＨＤＲ画像を効率的に処理するために、多くのシナリオにおいて、比較的大きな数のビットにより典型的に表されるＨＤＲのより大きなダイナミックレンジが実質的に低減された数のビットを用いた表現に変換されることが重要である。

【0009】

例えば、幾つかのシナリオにおいて、ＬＤＲのために開発された入力インタフェースを有するディスプレイ上でＨＤＲ画像を表示することが有利であり得る。故に、例えばディスプレイインタフェースによりＬＤＲ値として処理され得る値を生成することが望ましいかもしれない。他のシナリオにおいて、より低いビットレートを有するとともにいくらかの下位互換性を有するＨＤＲ値をＬＤＲにエンコードすることが望ましいかもしれない。

【0010】

適切なフォーマットにおいてＬＤＲ画像を表すために、これは、多くの場合、ＨＤＲ線形輝度値から適切に量子化されたｌｕｍａコードにマッピングするコード配分関数を用いるために用いられる。ＨＤＲ線形輝度値は、多くの場合、例えば値毎に比較的高い数のビットを有する浮動ポイント値として表される（例えば１６ビット）。これに対し、量子化されたｌｕｍａコードは、典型的には、比較的低い数のビット（例えば８ビット）により、及び、多くの場合整数値として、ｌｕｍａ値を表す。

【0011】

ＬＤＲとＨＤＲとの間の差はダイナミックレンジのサイズだけではない。むしろ、ほとんどのシーンにおける強度の相対分布は、ＬＤＲ及びＨＤＲ表現の間で大幅に異なる。

【0012】

実際に、ＨＤＲ画像／ビデオは、典型的には、従来の（ＬＤＲ）画像／ビデオとは異なる強度分布を有する。とりわけ、高ダイナミックレンジ画像データのピーク対平均輝度比は非常により高くなる。それ故、現在適用されているコード配分曲線又は電子光学的伝達関数（ＥＯＴＦ；electro optical transfer function）は、ＨＤＲデータに対して準最適になる傾向がある。故に、ＨＤＲ輝度値からエンコードされたｌｕｍａ値への従来のＬＤＲマッピングが用いられる場合、重大な画像劣化が典型的には生じる。例えば、画像コンテンツのほとんどは、少しのコード値によってのみ表され得る。多数のコードは増大された輝度範囲に対して保存されるためである。これは、しかしながら、典型的には、少しの極めて明るい画像オブジェクトに対してのみ用いられる。

【0013】

実用的なシナリオの一例として、色等級づけ（リファレンス［１］を参照）又は色補正は、商業映画又はフォトグラフィ生産の一体的部分である。とりわけ、これは、製造後のステージ（リファレンス［２］）の部分である。色等級づけアーティスト又はカラリストは、色等級づけセットにおいて機能し、これは、色等級づけ／補正ツールと等級分け／補正された画像又はビデオ上の色等級づけツール動作の効果のリアルタイムプレビューとを供給する。

【0014】

ＨＤＲカメラの導入並びにＨＤＲ画像及びビデオを撮影及び表示するためのディスプレイによれば、色等級づけセットは、この高ダイナミックレンジコンテンツを等級分けするために適してなければならない。ＨＤＲの導入を促進するために、既存のツールに対する最小限の変化を有する色等級づけ／補正を可能にすることが有益である。

【0015】

例えば１００ｃｄ／ｍ^２のピーク輝度のリファレンスモニタ上に表示されることを意図した現在の規格のダイナミックレンジビデオは、通常、現在の規格のｌｕｍａ／輝度領域においてエンコードされ、これらは、これらのログ曲線又はＥＯＴＦ（電気光学伝達関数）を用いて特定される。これの例は、ｓＲＧＢ（リファレンス［４］）又はＩＴＵ Ｒｅｃ．７０９（リファレンス［５］）対数関数的データのために使用される曲線である。ビデオデータは、この対数関数的領域において、色等級づけツール（例えばＰＣ上のソフトウェア）からハードウェアインタフェース（典型的にはＨＤ−ＳＤＩ）を介してプレビューディスプレイに送られる。ハードウェアインタフェースのビット深度は、通常、例えば８又は１０ビットに限定される。

【0016】

ＨＤＲ画像／ビデオは、典型的には、現在の規格のダイナミックレンジ画像とは異なる（例えば、ディスプレイにレンダリングされた輝度として規定されたときの）輝度分布を有する。例えば、現在のビデオコンテンツ分布が典型的には（ｌｕｍａコードが例えば２５５値の半分にうまく広がることを意味する）ピーク輝度の約２０％でピークに達する一方で、ＨＤＲコンテンツは、典型的には、しばしば、ピーク輝度の非常に低い割合（例えば１％）周辺でピークに達し得る（少なくともＨＤＲ画像のより暗い領域のデータがコード最大のコード１／１００に広がる）。故に、関連したＨＤＲコンテンツのほとんどは、現在の規格のログ曲線を用いてエンコードされるときに、８ビット又は１０ビットのビデオレベルの少数のみに含まれるだろう。これは、プレビュー画像における厳しい及び受け入れられない量子化アーチファクトをもたらし、それ故、カラリストがＨＤＲ画像を色等級分け／補正するのを妨げる。

【0017】

従って、従来のコード配分関数が、斯様な８ビット又は１０ビットの入力フォーマットを有する既存のディスプレイのための適切なコードを生成するためにＨＤＲ画像に対して用いられる場合、表示された画像の大幅に低減された質は、例えば少しだけの入力レベルに渡って分布される画像に存在する強度のほとんどによって生じるだろう。

【0018】

実際の技術的なコードをレンダリングするディスプレイ上でどのようにみられるか又はその逆に関する線形光輝度をマッピングするコード配分関数は、しかしながら、主として、（ガンマ２．２のような）ＬＤＲモデルに基づいているが、約１００ｎｉｔ又はｃｄ／ｍ^２のピーク輝度のＬＤＲディスプレイ対してのみ最適だった（以後は、ｎｉｔ及びｃｄ／ｍ^２の双方が用いられるだろう）。ＨＤＲディスプレイ（例えば５０００ｎｉｔのピーク輝度）への接続ケーブルを介した伝送のための非常に粗いコードのＨＤＲビデオの場合、ビデオのより暗い部分におけるバンディングのようなアーチファクトを見るリスクがある（例えば、とりわけ色あせたダークブルーの空におけるバンディング）。

【0019】

従って、例えば現在の色等級づけツール及びインタフェースを用いてＨＤＲ画像の色等級づけを可能にするために、異なるコード配分曲線が、ビデオデータをエンコードするために用いられるべきであり、従って、充分な数の量子化レベルは最も重要なビデオデータに割り当てられる。

【0020】

しかしながら、適切なコード配分関数を見つけることは、重要なだけではなく、困難でもある。実際に、チャレンジは、コード配分関数を決定するときに入力輝度値とｌｕｍａコードとの間で最良にマッピングする方法である。実際に、選択されたマッピングが（例えば量子化エラーに起因して）生ずる質に対して強い影響を与えるので、これは重要な問題である。更に、画像の質に対する影響は、エンコード／デコードされる画像の特性及び性質や、画像をレンダリングするために使用される機器に依存し得る。

【0021】

もちろん、最も単純なアプローチは、単純に均一の量子化を用いることであるだろう。しかしながら、斯様なアプローチは、多くのシナリオにおいて最適状態に及ばないパフォーマンスをもたらす傾向がある。従って、不均一性の量子化が適用されたコード配分関数が開発された。これは、詳細には、非線形関数（ｌｕｍａコードマッピング／色調マッピング関数）を入力輝度値に適用することにより実行されてもよい。その後に線形量子化が続く。しかしながら、述べられるように、多くのシナリオにおける規定された関数が最適状態に及ばない結果を与えることが解っている。例えば、例えば値（典型的には８ビット）毎に比較的低い数のビットでＬＤＲ回路により処理されるのを可能にするためにコード配分関数をＨＤＲ画像に適用することは、ＨＤＲ画像の最適状態に及ばない変換をもたらす傾向があり、詳細には、少しの量子化レベル／コード周辺に集中される画像値をもたらす。

【0022】

詳細には例えばＨＤＲ画像のために最適化される明示的な関数を開発及び規定することが可能であるが、これは、多くのシナリオにおいて非実用的であり得る。実際に、斯様なアプローチは、個々の及び専門の関数が各シナリオのために開発されるのを必要とする。更に、典型的には、機器及び／又は画像における差分を補償するために、多数の考えられる関数が選択のために利用可能であることを必要とする。

【0023】

これは、更に、動作を複雑にし、追加のリソース要件を取り込む。

【0024】

例えば、専用の関数を用いることは、どの特定の関数が用いられるかをエンコーダが通信するのを必要とするだけでなく、加えて、エンコーダ及びデコーダは、全ての考えられる関数のローカル表現を格納することを必要とする。これは、メモリ格納要件を大幅に増大させるだろう。他のオプションは、使用されるコード配分関数を完全に規定するデータをエンコーダがエンコードすることであるが、斯様なアプローチはデータレートを大幅に増大させるだろう。

【0025】

更に、専用の及び明示的なＨＤＲコード配分関数を用いることは、多くのシナリオにおいて、適切な関数を規格化及び特定することについてかなりの仕事を必要とするだろう。更に、既存の機器は新たな関数をサポートしないので、後方互換性が問題になるだろう。例えば、既存の回路は、詳細にはＨＤＲ画像をサポートするために規定された新たな関数をサポートすることができないだろう。

【発明の概要】

【発明が解決しようとする課題】

【0026】

従って、コード配分関数を供給及び／又は生成するための改良されたアプローチが有利であるだろう。

【課題を解決するための手段】

【0027】

本発明の一態様によれば、請求項１に記載のコード配分関数を構成する方法が提供される。

【0028】

本発明は、多くのシナリオにおいて、画像の促進された又は向上した例えば通信、格納、処理又は操作を可能にし得る。

【0029】

本アプローチは、多くのシナリオにおいて、ＨＤＲ画像の促進された又は向上した例えば通信、格納、処理又は操作を可能にし得る、とりわけ、ＨＤＲ画像がＬＤＲ画像のために設計された既存の機能を用いるのを可能にし得る。例えば、コード配分関数は、低減された数のビットに制限されたリンク又は機能を介して改良されたＨＤＲ画像表現可能にし得る。

【0030】

規定される部分関数の使用は、多くの実施形態において、改良された画像表現を供給し、及び／又は、動作を促進するために見出されている。とりわけ、多くの実施形態において、既存の色調マッピング関数が新たなアプリケーション及びシナリオのために再生利用されるのを可能にしてもよい。とりわけ、多くの実施形態において、例えばＬＤＲ画像処理及び表現のために規定又は決定された既存の関数が、ＨＤＲ画像の表現を画素毎のより少ないビットで供給するｌｕｍａ表現にＨＤＲ線形輝度をマッピングするために再生利用されるのを可能にしてもよい。また、幾つかの部分関数を組み合わせて用いることにより、多種多様なコード配分関数がサポートされ得る一方で、例えば幾つかの部分関数の格納又は通信しか必要としない。

【0031】

ｌｕｍａ値又はコードは、（無色の）輝度値の任意の非線形関数であってもよい。故に、ｌｕｍａ値は、典型的には、対応する輝度の単調な非線形表現を供給するが、ｌｕｍａ値を輝度に関連付ける関数は、任意の適切な及び詳細には非線形関数であってもよい。

【0032】

線形輝度値に関して、輝度値と所望の放射された光との間の直接的線形関係、即ち線形輝度値と画素からの対応する光放射線との間の直接的線形関係が存在する。

【0033】

幾つかの実施形態において、コード配分関数はエンコーダの部分であってもよい。画素輝度値は、コード配分関数に対する入力であってもよく、これにより量子化されたｌｕｍａ値を生成する。これらの値は、例えば通信、処理又はエンコードされてもよい。

【0034】

部分関数は、連続的に適用されてもよい。第１の部分関数のアプリケーションは第２の部分関数へ進んでもよく、詳細には、第１のｌｕｍａ出力値は、幾つかの実施形態において、第２の部分関数に供給されてもよい。即ち、ｌｕｍａ入力値は、第１のｌｕｍａ出力値であってもよい。

【0035】

コード配分関数は、ｌｕｍａコード値を生成するために第２のｌｕｍａ出力値の量子化を含んでもよい。ｌｕｍａコードは、典型的には線形量子化である量子化に基づいて第２のｌｕｍａ出力値から生成されてもよい。量子化は、各画素ｌｕｍａ値を表すビットの数の低減を与えてもよく、例えば浮動小数点値から整数値までの表現の変換を含んでもよい。

【0036】

値のための最大範囲は、値が利用することができる全ての値を含む。画素線形輝度入力値の最大の輝度範囲は、線形輝度入力値の全ての考えられる値を含む。第１のｌｕｍａ出力値の最大のｌｕｍａ範囲は、第１のｌｕｍａ出力値の全ての考えられる値を含む。ｌｕｍａ入力値の最大のｌｕｍａ範囲は、ｌｕｍａ入力値の全ての考えられる値を含む。第２のｌｕｍａ出力値の最大のｌｕｍａ範囲は、第２のｌｕｍａ出力値の全ての考えられる値を含む。

【0037】

最大範囲の１又はそれ以上は同じであってもよい。例えば、全ての最大ｌｕｍａ範囲は、［０；１］間隔に正規化されてもよい。最大線形輝度範囲は、同様に［０；１］間隔における値により表されてもよい。

【0038】

部分関数は、固定された関数であってもよく、又は、１又はそれ以上のパラメータに依存してもよい。

【0039】

本発明のオプショナルな特徴によれば、請求項６が提供される。

【0040】

これは、効率的な及びフレキシブルなシステムを提供し、ソース又は送信側がコード配分関数を柔軟に最適化するのを可能にし得る一方で、シンク又は受信側が使用される特定のコード配分関数に適応するのを可能にする。

【0041】

表現は、例えばコード配分関数全体の表現又は部分関数の１若しくはそれ以上の指標及び／又はこれらのパラメータをエンコードすることにより、コード配分関数の特性を示す任意のデータとしてエンコードされてもよい。

【0042】

本発明の一態様によれば、請求項１２によるｌｕｍａコードから画素線形輝度関数へのマッピングのためのコードマッピング関数を決定する方法が提供される。

【0043】

本発明は、多くのシナリオにおいて、促進又は改良された、例えば画像の通信、格納、処理又は操作を可能にし得る。

【0044】

本アプローチは、とりわけ、多くのシナリオにおいて、促進又は改良された、例えばＨＤＲ画像の通信、格納、処理又は操作を可能にし、とりわけ、ＨＤＲ画像がＬＤＲ画像のために設計された既存の機能を用いるのを可能にし得る。例えば、コード配分関数は、低減された数のビットに制限されたリンク又は機能を介して改良されたＨＤＲ画像表現を可能にし得る。

【0045】

コードマッピング関数は、ｌｕｍａコードを生成するために使用されるコード配分関数の少なくとも部分の反転を含んでもよい。第１の部分関数は、ｌｕｍａコードを生成するために使用されるコード配分関数のｌｕｍａコードに対するｌｕｍａ値のマッピングの逆関数であってもよい。第２の部分関数は、ｌｕｍａコードを生成するために使用されるコード配分関数のｌｕｍａ値に対する線形輝度値のマッピングの逆関数であってもよい。

【0046】

規定される部分関数の使用は、多くの実施形態において、改良された画像表現を提供し、及び／又は、動作を促進するために見出された。とりわけ、多くの実施形態において、既存の色調マッピング関数が新たなアプリケーション及びシナリオのために再生利用されるのを可能にしてもよい。とりわけ、多くの実施形態において、例えばＬＤＲ画像処理及び表現のために規定又は決定された既存の関数が画素毎のより少ないビットによりＨＤＲ画像の表現を与えるｌｕｍａ表現にＨＤＲ線形輝度をマッピングし、受信／シンク側においてこのマッピングを元に戻すために再生利用されるのを可能にしてもよい。また、いくらかの部分関数を組み合わせて用いることにより、多種多様なコード配分関数がサポートされ得る一方で、例えばいくらかの部分関数の格納又は通信しか必要としない。

【0047】

幾つかの実施形態において、コードマッピング関数はデコーダの部分であってもよい。Ｌｕｍａコードは、例えばリモートソースから受信され、線形輝度画素値に変換されてもよい。

【0048】

部分関数は、連続的に適用されてもよい。第１の部分関数のアプリケーションは、第２の部分関数へ進んでもよく、詳細には、幾つかの実施形態において、第１の部分関数のｌｕｍａ出力値が第２の部分関数に供給されてもよい。即ち、第２の部分関数の入力ｌｕｍａ値は、第１の部分関数のｌｕｍａ出力値であってもよい。

【0049】

コードマッピング関数は、第１の部分関数によるマッピングの前に例えばｌｕｍａコードの非量子化を含んでもよい。

【0050】

値のための最大範囲は、値が利用することができる全ての値を含む。画素線形輝度入力値の最大輝度範囲は、線形輝度入力値の全ての考えられる値を含む。ｌｕｍａ出力値の最大ｌｕｍａ範囲は、ｌｕｍａ出力値の全ての考えられる値を含む。ｌｕｍａ入力値の最大ｌｕｍａ範囲は、ｌｕｍａ入力値の全ての考えられる値を含む。ｌｕｍａコードの最大ｌｕｍａ範囲は、ｌｕｍａコードの全ての考えられる値を含む。

【0051】

最大範囲の１又はそれ以上は同じであってもよい。例えば、全ての最大ｌｕｍａ範囲は、［０；１］間隔に正規化されてもよい。最大線形輝度範囲は、同様に［０；１］間隔における値により表されてもよい。

【0052】

部分関数は、固定された関数であってもよく、又は、１又はそれ以上のパラメータに依存してもよい。

【0053】

幾つかの実施形態において、部分関数は、コードマッピング関数に従ってｌｕｍａコードから線形輝度値に変換される画像データと一緒に受信されるデータに基づいて生成されてもよい。

【0054】

本発明による方法及び装置のこれらの及び他の態様は、後述される実装及び実施形態、及び単により一般的な概念を例証する非限定的な特定の図としての役割を果たす添付の図面から明らかになり、これらを参照して説明されるだろう。

【図面の簡単な説明】

【0055】

【図1】本発明の幾つかの実施形態によるコード配分関数を生成する装置の一例を示す。

【図2】本発明の幾つかの実施形態によるコードマッピング関数を生成する装置の一例を示す。

【図3】本発明の幾つかの実施形態によるコードマッピング関数の一例を示す。

【図4】コーディングにおいて量子化段階前の曲線をどのようにＮビットに適用し得るか、及び元の入力信号をほぼ復元するための逆曲線を図式的に示す。

【図5】斯様なストラテジーが画素（例えばＲＧＢ）の３つの色座標に典型的にどのように適用されるかを図式的に示す。

【図6】適用されるべき我々の全体のコード配分曲線（ｌｕｍａ Ｙ又は非線形Ｒ（Ｇ，Ｂ）＝ｆ［典型的にはＨＤＲ入力画像の線形色空間表現の対応する座標］）が３つの部分的マッピング機能形式から形成される本発明の一実施形態を図式的に示す。

【図7】幾つかの部分が全体のコード空間の輝度範囲のｌｕｍａ上の圧縮動作を有するとともに、その他がその部分範囲において拡張動作を有する他の実施形態を図式的に示す。

【図8】第２の部分関数がｓＲＧＢ規格のコード配分関数である場合においてＨＤＲが典型的には約５０００ｎｉｔのピーク輝度で終了するとともに０．１ｎｉｔ又はそれより低い下端である範囲にあるときに我々が最適化されたコード配分を与えるために見出した第１の部分関数を図式的に示す。

【図9】ｒｅｃ．７０９コードマッピングを第２の部分として用いるときにより低いビット量のコード語（例えば８ビット、１０ビット、１２ビット）を介したＨＤＲエンコーディングのための最適に機能する第１の部分関数を図式的に示す。

【図10】ドルビーのＰＱ関数を第２の部分として用いるときに最適に機能する第１の（又は、もちろん実際の適用遷移において最後に用い得る）部分を図式的に示す。

【図11】より多くの部分関数から全体コード配分関数を構成することもできることを図式的に示し、この場合において、配分関数を正しい最終形状に曲げる最終的なガンマ補正の後に２つのｓＲＧＢマッピングが連続的に用いられ、従って、充分なコードが典型的にはＨＤＲ画像における全ての輝度領域のために存在する。

【図12】２つの古典的なＲｅｃ．７０９関数を用いるときの（しかし古典的ではない２つのアプリケーションにおいて）同じものを図式的に示す。

【図13】斯様なコード配分関数がＹ軸輝度を出力するためにＸ軸入力コード値をマッピングするコード空間を介してどのように見えるかを図式的に示す。

【図14】コードマッピング関数の例を示す。

【図15】コードマッピング関数の例を示す。

【図16】コードマッピング関数の例を示す。

【図17】正しく等級分けされたＨＤＲ出力画像を取得するために、色等級分けアプリケーションにおけるコード配分関数の斯様な部分的な構成をどのように有利に用い得るかを図式的に示す。

【発明を実施するための形態】

【0056】

図１は、本発明の幾つかの実施形態によるＨＤＲ画像演算処理システムの一例を示している。この図は、ＨＤＲシステムのためのソース、エンコーディング又は送信側を示す。本例において、コード配分関数は、ＨＤＲ線形輝度である入力値からｌｕｍａコードにマッピングするために用いられる。本例において、コード配分関数は、Ｎビットにより表される入力値からＭビットにより表される出力値にマッピングする（Ｎ＞Ｍ）。加えて、本例において、入力ＨＤＲ線形輝度値は、浮動小数点値として（例えば１６ビットの浮動小数点値として）表され、出力ｌｕｍａコードは、整数（例えば８ビットの整数）により表される。

【0057】

図１の例において、本システムは、ＨＤＲ画像又はビデオシーケンスのソース１０１を有する。

【0058】

従来のディスプレイは、典型的にはＬＤＲ表現を用いる。典型的には、斯様なＬＤＲ表現は、指定された原色に関する３つの成分の８ビットの表現により与えられる。例えば、ＲＧＢ色表現は、赤、緑及び青の原色にそれぞれ参照される３つの８ビットのサンプルにより与えられてもよい。他の表現は、１つの輝度成分及び２つの彩度成分（例えばＹＣｂＣｒ）を用いる。これらのＬＤＲ表現は、所与の輝度又は輝度範囲に対応する。

【0059】

ＨＤＲは、詳細には、ＨＤＲディスプレイ上に適切に示されるかなり明るい画像（又は画像エリア）を可能にする。実際には、ＨＤＲディスプレイ上に表示されるＨＤＲ画像は、ＬＤＲディスプレイ上に示される対応するＬＤＲ画像により与えられ得るかなり明るい白色を与え得る。実際には、ＨＤＲディスプレイは、典型的には、ＬＤＲディスプレイより少なくとも４倍明るい白色を可能にし得る。輝度は、詳細には、所与のグレー又は黒いレベルに対して表され得るか又は測定され得る最も濃い黒に対して測定されてもよい。

【0060】

ＬＤＲ画像は、詳細には、特定の白色ポイント及び／又は原色の特定のセットに関連した固定されたビット分解能のような、特定の表示パラメータに対応してもよい。例えば、８ビットは、ＲＧＢ原色の所与のセット及び例えば５００ｃｄ／ｍ２の白色ポイントに対して与えられてもよい。ＨＤＲ画像は、これらの制限を越えるようにされるべきであるデータを含む画像である。とりわけ、輝度は、白色ポイント（例えば２０００ｃｄ／ｍ２）より４倍を超える明るさであってもよく、又は、それより明るくてもよい。

【0061】

高ダイナミックレンジ画素値は、ＮＴＳＣ及びＭＰＥＧ２時代に規格化されたディスプレイ上に忠実に表示され得る範囲より（非常に）大きい輝度コントラスト範囲（最も暗い輝度で割った画素のセットにおける最も明るい輝度）を有する（その典型的なＲＧＢ原色を伴う、及び、最大駆動レベル［２５５、２５５、２５５］を伴うＤ６５の白色、例えば５００ｎｉｔ又はそれより低い基準輝度）。典型的には、斯様な基準ディスプレイに関して、８ビットは、視覚的に小さな段階において約５００ｎｉｔと約０．５ｎｉｔとの間の（即ち、コントラスト範囲１０００：１又はそれより低い範囲を伴う）全てのグレー値を表示するのに十分であるのに対し、ＨＤＲ画像は、より高いビット語（例えば１６ビット）によってエンコードされる。とりわけ、ＨＤＲ画像は、典型的には、白色のシーンより高い（明るい画像オブジェクトの多くの画素値を含む。とりわけ、幾つかの画素は、白色のシーンの２倍より明るい。白色のこのシーンは、典型的には、ＮＴＳＣ／ＭＰＥＧ２基準ディスプレイの白色と同等視され得る。

【0062】

ＬＤＲ画像とＨＤＲ画像との間の差は、より多くのビットがＬＤＲ画像よりＨＤＲ画像に対して用いられるということだけではないことに留意すべきでる。むしろ、ＨＤＲ画像は、ＬＤＲ画像より大きな輝度範囲をカバーし、典型的には、より高い最大の輝度値（即ち、より高い白色ポイント）を有する。実際には、ＬＤＲ画像は、５００ｎｉｔに過ぎない値に対応する最大輝度（白色）ポイントを有するのに対し、ＨＤＲ画像は、５００ｎｉｔを超える値、多くの場合、１０００ｎｉｔ、２０００ｎｉｔ、４０００ｎｉｔ又はそれ以上に対応する最大輝度（白色）ポイントを有する。故に、ＨＤＲ画像は、より高い粒状又は改良された量子化に対応するより多くのビットを用いるだけでなく、むしろより大きな実際の輝度範囲に対応する。故に、最も明るい考えられるピクセル値は、概して、ＬＤＲ画像よりもＨＤＲ画像に対して高くなる輝度／光出力に対応する。実際には、ＨＤＲ画像及びＬＤＲ画像は、同じビット数を用い得るが、ＬＤＲ画像値よりも大きな輝度ダイナミックレンジ／明るい最大輝度に参照されるＨＤＲ画像値を有する（それ故、輝度スケール上のより粗い量子化によって表されるＨＤＲ画像を有する）。

【0063】

ＨＤＲ画像のために使用されるビット数Ｘは、典型的には、ＬＤＲ画像のために使用されるビット数Ｙより大きくてもよく、又は、これに等しくてもよい（Ｘは、典型的には例えば（チャネルの幾つかが用いられる場合、色チャネル当たり）１２、１４又は１６ビットであってもよく、Ｙは、例えば８又は１０ビットであってもよい）。

【0064】

ＨＤＲ画像が、ＬＤＲに準拠したディスプレイインタフェース又は画像エンコーディングアルゴリズムのような、ＬＤＲに準拠した機器又はインタフェースで用いられるのを可能にするために、変換／マッピングは、ＨＤＲ値をより小さな範囲に合わせるために必要とされ得る。例えば圧縮スケーリングが要求され得る。斯様な変換は、典型的にはむしろ複雑であり、輝度範囲の単純なスケーリングに等しいだけではない。斯様なスケーリングが、異常に見えるものとして知覚される、典型的には大きな量子化エラーを伴う画像をもたらすためである。むしろ複雑な変換が典型的に用いられ、これらの変換は、多くの場合、色調マッピングという用語を用いて言及される。

【0065】

図１のシステムにおいて、ＨＤＲ画像は、ＨＤＲ画像の画素の線形輝度値を、各線形輝度値よりも各ｌｕｍａコードに対して与えられる低減された数のビットを有するｌｕｍａコードにマッピングするコード配分関数１０３に供給される。

【0066】

それ故、コード配分関数は、ＨＤＲ画像の線形輝度値である入力値を有する。

【0067】

所与の画素のための輝度値は、その画素の輝度を示す。即ち、これは、その画素により放射された（それ故、画素により知覚される輝度の）、供給されるべき光の量を示す。本例において、輝度入力値は、最大の輝度に関して（即ち、白色ポイントに関して）所与のレベルに関連付けられる。例えば、入力輝度が、範囲が放散された輝度レベルに関連付けられる所与の範囲における値として与えられてもよい。詳細には、範囲の低い側は、例えば放射される光のないものに対応する黒色ポイントに関連付けられてもよい。範囲の高い側は、白色ポイントに関連付けられてもよい。白色ポイントは、（例えば５０００ｎｉｔ又は１０００ｎｉｔのような）ＨＤＲ輝度である。

【0068】

故に、コード配分関数への入力は、放散された光値に対応する実際の白色ポイント及び黒色ポイントに関連付けられ得る輝度値であってもよい。例えば、入力輝度値は、［０；１］の範囲における値として与えられてもよい。ここで、値０は、例えば０ｎｉｔの黒色ポイントに対応し、値１は、５００ｎｉｔを超える値、多くの場合１０００ｎｉｔ、２０００ｎｉｔ、４０００ｎｉｔ又はそれ以上の白色ポイントに対応する。

【0069】

故に、所与の輝度値は、所望の輝度に直接対応する。

【0070】

ＨＤＲソース１０１からの入力輝度値は、本例においては、線形輝度値である。故に、輝度値と所望の放散された輝度との間に直接的線形関係が存在する。即ち、線形輝度値と画素からの対応する光放射との間に直接的線形関係が存在する。例えば、０が０ｎｉｔの黒色ポイントに対応するとともに１が５０００ｎｉｔの白色ポイントに対応する［０；１］の範囲における輝度値に関して、０．２５の値は、１２５０ｎｉｔの輝度に対応し、０．５の値は、２５００ｎｉｔ輝度に対応する等である。

【0071】

入力輝度値は、比較的大きいビット数及びそれ故に比較的高い精度により表される。これは、更に、浮動小数点値として表されてもよい。故に、線形輝度は、実質的に非量子化されたものとみなされ得る。

【0072】

本例において、輝度値は、詳細には、画素の全体輝度であってもよい。即ち、（Ｒチャネル輝度、Ｇチャネル輝度又はＢチャネル輝度のような）色チャネルの輝度だけよりもむしろ画素全体の輝度を反映してもよい。例えば、本例において、画素色は、別々の輝度及び彩度成分を有するフォーマットにより表されてもよい。例えば、これらは、（ピクセル値が輝度値Ｙ及び２つの彩度値ｕｖにより表される）Ｙｕｖフォーマットにおいて与えられてもよい。この場合、コード配分関数は、Ｙ成分（輝度成分）に適用され得る一方で、彩度成分ｕｖを一定に保つ。幾つかの実施形態において、本システムは、入力値を例えばＲＧＢフォーマットから例えばＹｕｖフォーマットに変換するための色表現コンバータを有してもよい。

【0073】

線形輝度入力は、詳細には、ＳＩ及びＣＩＥにより言及される線形輝度であってもよい。

【0074】

コード配分関数への入力信号は、それ故、実際の輝度レベル（即ち、特定の白色ポイント又は最大輝度）に関連付けられた輝度値であってもよい。詳細には、ＨＤＲソース１０１は、特定の輝度レベルに対して色等級分けされた画像を与えてもよい。例えば、色等級分け部は、入力輝度範囲に関連付けられた白色ポイントに対応する白色ポイントを伴うＨＤＲディスプレイ上に示されるときに、ＨＤＲ画像の画素色／輝度値が所望の見て美しい画像を得るように手動で調整してもよい。

【0075】

コード配分関数１０３の出力は、ｌｕｍａ値又はコードである。ｌｕｍａは、色がない輝度値の任意の非線形関数であってもよい。故に、ｌｕｍａ値は、典型的には、対応する輝度の単調な表現を与えるが、ｌｕｍａ値を画素輝度に関連付ける関数は、任意の適切なもの、詳細には非線形関数であってもよい。故に、ｌｕｍａ値に関して、他の値の２倍の大きさは、２倍の大きさいである所望の輝度に対応するために想定され得ない。幾つかのシナリオにおいて、ｌｕｍａ値は、所与の輝度範囲に直接関連付けられないものとみなされ得る。例えば、ｌｕｍａ値に対して利用可能な範囲は、例えば［０；１］から［０；２５５］までの範囲として与えられてもよい。しかしながら、この範囲は、所与の輝度範囲に又は実際には所与の黒色ポイント若しくは白色ポイントに直接関連付けられなくてもよい。例えば、幾つかの実施形態において、ｌｕｍａ値は、画像輝度範囲又は分布の抽象的表現を与えてもよく、特定の輝度レベルへの正確なマッピングは、例えば画像を示すために使用されるディスプレイの輝度品質に依存して適合されてもよい。

【0076】

ｌｕｍａ値は、詳細には、ＣＩＥ＿ＸＹＺから輝度表記法に対応してもよい。

【0077】

故に、画素のためのｌｕｍａ値は、画素に対する輝度又はルミナンス値の表現を与えてもよいが、これらの値に対する予め決められた又は直接的なマッピングを有してなくてもよく、とりわけ、線形マッピングを表さなくてもよい。むしろ、ｌｕｍａ値は、エンコーディングを提供するが、ｌｕｍａコードを特定の輝度値に戻すようマッピングするために、ｌｕｍａコードと元の線形ルミナンス値との間の関係を規定する関数を用いることが必要である。図１のエンコーダにおいて、コード配分関数は、線形ルミナンス入力からｌｕｍａコードにマッピングする。ｌｕｍａコードをルミナンスコードに戻すようマッピングするために、逆コード配分関数が適用され得る。詳細には、ｌｕｍａコードをエンコーダへの入力の線形ルミナンス範囲に戻すようマッピングするために、コード配分関数の逆は、ルミナンス値を生成するために用いられてもよい。ｌｕｍａコードからルミナンス値へのマッピングは、以下において逆コード配分関数と呼ばれる。この関数は、幾つかのシナリオにおいて、それ自身、コード配分関数と呼ばれることに留意すべきである。

【0078】

コード配分関数１０３は、線形ルミナンス値を、後に量子化されるｌｕｍａ値にマッピングする非線形マッピングを含む。詳細には、コード配分関数は、線形ルミナンス入力値をｌｕｍａ値にマッピングするｌｕｍａコードマッピング１０７を含む。マッピングは非線形マッピングである。ｌｕｍａコードマッピング１０７の出力におけるｌｕｍａ値は、コード配分関数１０３からの出力ｌｕｍａコードを生成するためにｌｕｍａ値の量子化を実行する量子化部１０９に供給される。

【0079】

量子化部１０９は、線形ルミナンス値のより大きいビット数が既存のＬＤＲ機能の使用を可能にするより低いビット数まで低減されるように、ビット低減を実行する。詳細には、量子化部１０９は、ｌｕｍａ値のビット数をＮからＭまで低減してもよい。量子化部１０９は、詳細には、均一の量子化を実行する。

【0080】

ｌｕｍａコードマッピング１０７は、線形ルミナンス入力から逆量子化されていないｌｕｍａ値への非線形マッピングを実行するように構成される。それ故、ｌｕｍａコードマッピング１０７及び量子化部１０９の組み合わせられた効果は、非均一の量子化に対応し得る。

【0081】

詳細には、非線形マッピングは、値の分布が改良されることを保証してもよい。例えば、非線形マッピングは、入力ルミナンス値の範囲の最も暗いもの（即ち、１０％）が量子化されていないｌｕｍａ値の範囲の最も暗いもの（即ち、７０％）にマッピングされるようになる。これは、ＬＤＲ画像と典型的に関連付けられた低減された解像度を用いたＨＤＲ画像の画像特性の効率的なエンコーディングを保証するだろう。

【0082】

故に、図１のシステムにおいて、コード配分関数は、ｌｕｍａ値を生成するために線形ルミナンス入力値に適用されるｌｕｍａコードマッピング１０７から構成され、その後に、出力ｌｕｍａコードを生成するためにｌｕｍａ値の（線形）量子化が続く。ｌｕｍａコードマッピング１０７は、入力線形ルミナンスをｌｕｍａ値にマッピングするマッピングを供給する。即ち、ｌｕｍａコードマッピング１０７は、線形ルミナンス値からｌｕｍａ値への色調マッピングを供給するために考慮されてもよい。

【0083】

しかしながら、本システムにおいて、ｌｕｍａコードマッピング１０７は、単一の関数又はマッピングとして構成されるだけでなく、むしろ、ｌｕｍａコードマッピング１０７の全体マッピングを与えるために一緒に機能する２つの部分関数１１１，１１３又はマッピングから構成される。図１の例において、ｌｕｍａコードマッピング１０７は、第１及び第２の部分関数１１１，１１３のみで作られるが、他の実施形態において、ｌｕｍａコードマッピング１０７は、更なる関数を含んでもよく、とりわけ追加のマッピングを含んでもよいことは言うまでもないだろう。例えば、後述するように、コード配分関数は、ユーザにより変更され得る可変マッピングを含んでもよく、実際には、幾つかの実施形態において、コード配分関数は、ユーザにより制御される色等級づけを含んでもよい。

【0084】

詳細には、図１のシステムにおいて、ｌｕｍａコードマッピング１０７は、線形ルミナンス入力値をＨＤＲソース１０１から受信する第１の部分関数１１１を有する。第１の部分関数１１１は、線形ルミナンス入力値を第１のｌｕｍａ値にマッピングするように構成される。第１の部分関数１１１は、全ての考えられる線形ルミナンス入力値のための出力ｌｕｍａ値を規定する。即ち、線形ルミナンス入力値により表され得る最大ルミナンス範囲全体は、出力ｌｕｍａ範囲にマッピングされる。更に、第１の部分関数１１１のマッピングは、線形ルミナンス入力値により表され得る最大ルミナンス範囲を、出力において表され得る最大ｌｕｍａ範囲にマッピングするようになっている。詳細には、最も低い考えられる線形ルミナンス入力値は、最も低い考えられるｌｕｍａ値にマッピングされる。同様に、最も高い考えられる線形ルミナンス入力値は、最も高い考えられるｌｕｍａ値にマッピングされる。

【0085】

更に、マッピングは、非線形マッピングである。典型的には、マッピングは、典型的な輝度値に対応するサブレンジが増大され、極めて高い輝度値に対応するサブレンジが圧縮されるようになる。故に、ＨＤＲ分布は、ＬＤＲ制限（詳細にはビット制限）により適し得る分布にマッピングされる。

【0086】

第１の部分関数１１１のマッピングは、更に、可逆関数である。詳細に、第１の部分関数１１１は、ルミナンス入力からｌｕｍａ出力への１対１マッピングを提供し、実際には、ｌｕｍａ出力からルミナンス入力への１対１マッピングが存在する。故に、第１の部分関数１１１は、上への（surjective）又は全単射の（bijective）関数／マッピングである。線形ルミナンス入力の範囲のあらゆる考えられる線形ルミナンス入力値に関して、第１の部分関数１１１は、ｌｕｍａ出力の範囲の正確な１つのｌｕｍａ値にマッピングする。更に、第１の部分関数１１１の逆のものが存在し、ｌｕｍａ出力の範囲のあらゆる考えられるｌｕｍａ値は、線形ルミナンス入力の範囲の正確な１つの線形ルミナンス入力値にマッピングする。

【0087】

詳細には、線形ルミナンス入力値は、［０；１］からの間隔における（例えば浮動小数点）値により表されてもよい。同様に、ｌｕｍａ値は、［０；１］からの間隔における浮動小数点値により表されてもよい。第１の部分関数１１１は、ルミナンス入力値範囲［０；１］の、ｌｕｍａ出力値［０；１］への全単射の非線形マッピングを与えてもよい。

【0088】

図１の例において、第１の部分関数１１１の出力は、第２の部分関数１１３に供給される。

【0089】

第２の部分関数１１３は、ｌｕｍａ値をマッピングするように構成され、実際には、図１の具体例において、第１の部分関数１１１からのｌｕｍａ値を第２のｌｕｍａ値にマッピングするように構成される。第２の部分関数１１３は、全ての考えられるｌｕｍａ入力値のためのｌｕｍａ出力値を規定する。即ち、ｌｕｍａ入力値により表され得る最大ｌｕｍａ範囲全体は、出力ｌｕｍａ範囲にマッピングされる。更に、第２の部分関数１１３のマッピングは、入力ｌｕｍａ範囲を、出力において表され得る最大ｌｕｍａ範囲にマッピングするようになる。詳細には、最も低い考えられるｌｕｍａ入力値は、最も低い考えられるｌｕｍａ出力値にマッピングされる。同様に、最も高い考えられるｌｕｍａ入力値は、最も高い考えられるｌｕｍａ出力値にマッピングされる。

【0090】

更に、マッピングは、非線形マッピングである。多くのシナリオにおいて、マッピングは、典型的な輝度値に対応するサブレンジは増大され、極めて高い輝度値に対応するサブレンジは圧縮されるようになる。故に、ＨＤＲ分布は、ＬＤＲ制限により適し得る分布にマッピングされる。

【0091】

第２の部分関数１１３のマッピングは、更に、可逆関数である。詳細には、第２の部分関数１１３は、ｌｕｍａ入力からｌｕｍａ出力への１対１マッピングを与え、実際には、ｌｕｍａ出力からｌｕｍａ入力への１対１マッピングが存在する。故に、第２の部分関数１１３は、上への又は全単射の関数／マッピングである。ｌｕｍａ入力の範囲のあらゆる考えられるｌｕｍａ入力値に関して、第２の部分関数１１３は、ｌｕｍａ出力の範囲の正確に１つのｌｕｍａ値にマッピングする。更に、第２の部分関数１１３の逆のものが存在し、ｌｕｍａ出力の範囲のあらゆる考えられるｌｕｍａ値は、線形ｌｕｍａ入力の範囲の正確に１つのｌｕｍａ入力値にマッピングする。

【0092】

詳細には、ｌｕｍａ入力値は、［０；１］からの間隔における値により表されてもよい。同様に、ｌｕｍａ出力値は、［０；１］からの間隔における値により表されてもよい。第２の部分関数１１３は、ｌｕｍａ値範囲［０；１］の、ｌｕｍａ出力値［０；１］への全単射の非線形マッピングを与えてもよい。ｌｕｍａ値は、浮動小数点値であってもよい。

【0093】

従って、第１の部分関数１１１及び第２の部分関数１１３の連続した適用の全体の組み合わせられた効果は、ＨＤＲ信号の入力線形ルミナンス表現からの、より少ないビットによる表現により適した表現への非線形マッピングである。故に、ｌｕｍａ値への入力線形ルミナンスの組み合わせられた非線形ｌｕｍａコードマッピング又は色調マッピングが実現される。

【0094】

図１のシステムにおいて、第２のｌｕｍａ出力値、即ち、第２の部分関数１１３からのｌｕｍａ値は、量子化部１０９に供給される。量子化部１０９は、量子化を第２のｌｕｍａ値に適用し、これにより出力ｌｕｍａコードを生成する。

【0095】

量子化部１０９による量子化は、各画素輝度を表すために使用されるビット数をより少ないビットまで低減する。例えば、ｌｕｍａ値は、１６ビットの浮動小数点値であってもよく、これは、８又は１０ビットの整数に量子化されてもよい。

【0096】

コード配分関数の結果として、ＨＤＲ輝度をかなり少ないビットで表す一方でより少ないビットが元のＨＤＲ画像の適切な表現を与えるのを可能にするｌｕｍａコードがそれ故に生成され得る。実際には、コード配分関数は、ＬＤＲのために開発された例えば通信、エンコーディング又は画像処理機能により扱われ得るコードを生成し得る。

【0097】

例えば、ディスプレイインタフェースは、例えば、Ｙ成分のために割り当てられる例えば１０ビットを有するＹｕｖデータとして表される画像をサポートするように規定されてもよい。斯様なディスプレイインタフェースは、ＬＤＲを考慮して設計されてもよい。しかしながら、ＨＤＲ線形ルミナンスを１０ビットのｌｕｍａコードにマッピングすることにより、同じディスプレイインタフェースが、ＨＤＲ画像をサポートするために用いられてもよい。

【0098】

他の例として、エンコーディングアルゴリズムは、Ｙ成分のための８ビットを用いたＹｕｖ表現に基づいて生成されてもよい。ＨＤＲ線形ルミナンスを８ビットのｌｕｍａコードにマッピングすることにより、同じエンコーディングアルゴリズムが、ＨＤＲ画像のエンコーディングをサポートするために用いられ得る。

【0099】

故に、図１のシステムは、ＨＤＲ線形ルミナンスをｌｕｍａ表現に効果的に圧縮し、多くのシナリオにおいて、生ずる信号がＬＤＲ機能により扱われるのを可能にする。とりわけ、生ずる信号は、ＬＤＲのために設計された通信媒体、チャネル又は中間体を用いて通信されてもよい。

【0100】

更に、これが実現され得る一方で、ＨＤＲ特性の効率的な表現を依然として可能にする。故に、画像データは、後に用いられるＬＤＲ画像に変換されない。むしろ、ＬＤＲに準拠した容器内のＨＤＲ表現が用いられ得る。

【0101】

多くの実施形態において、レシーバは、ｌｕｍａコード値を受信してもよく、線形ルミナンスＨＤＲ表現を生成しようとしてもよい。例えば、ｌｕｍａ値を受信するＨＤＲディスプレイは、ディスプレイを駆動させるために後に用いられるＨＤＲ線形ルミナンス値を生成しようとしてもよい。

【0102】

斯様なシンク、デコーディング又は受信側の一例が図２に示されている。

【0103】

本例において、レシーバは、図１の送信側から生成された符号化された値を受信する画像レシーバ２０１を有する。幾つかの実施形態において、ｌｕｍａコードは、符号化された信号において受信されてもよく、データ受信器２０１は、ｌｕｍａコードを取り出すために符号化信号をデコードするための機能を有してもよいことは言うまでもないだろう。符号化信号は、彩度値を更に有してもよく、例えば、ｌｕｍａコード及び彩度値は、画像における各画素に対して供給されてもよく、例えば、各画素は、Ｙｕｖフォーマットにおいて表されてもよいことは言うまでもないだろう。

【0104】

受信したｌｕｍａコードは、受信したｌｕｍａコードを線形ルミナンス値にマッピングするように構成されたコードマッピング関数２０３に供給される。詳細には、コードマッピング関数２０３は、ＨＤＲ画像に適している線形ルミナンス値を生成し得る非線形マッピングを与える。

【0105】

線形ルミナンス値は、本例においては、ＨＤＲディスプレイを駆動させるように構成される駆動部２０５に供給される。故に、特定の例において、レシーバは、例えば、ＨＤＲ画像を表す（ｌｕｍａコードがＬＤＲ通信チャネルに準拠するのを可能にするフォーマットを用いた）ｌｕｍａコードを受信し、これらのｌｕｍａコードをＨＤＲ線形ルミナンス値に変換するための機能を有するＨＤＲディスプレイであってもよい。

【0106】

幾つかの実施形態において、コードマッピング関数２０３は、コード配分関数１０３の逆関数に対応してもよい。故に、コードマッピング関数２０３により実行されるマッピングは、線形ルミナンス値を生成するときに、ｌｕｍａコードマッピング１０７の動作を反転させてもよい。

【0107】

他の実施形態において、コードマッピング関数２０３は、変更された又は追加のマッピングを有してもよい。例えば、ＨＤＲルミナンス値へのマッピングは、ローカル特性又は優先度に、例えば特定のディスプレイの白色ポイント又は例えば特定のユーザ優先度に、適合されてもよい。

【0108】

しかしながら、一般に、コードマッピング関数２０３は、送信側のコード配分関数／ｌｕｍａコードマッピング１０７を考慮するために生成される。それ故、このアプローチは、ＨＤＲ線形ルミナンス範囲が、ＬＤＲフォーマットに制限された通信チャネルを用いて通信され、その後、遠端においてＨＤＲ線形ルミナンス範囲に戻すようマッピングされ得る、ＬＤＲフォーマットに準拠した表現にマッピングされ得るシステムを可能にする。

【0109】

コードマッピング関数２０３は、２つの部分関数に基づいて生成され、以下のものは、第１の逆部分関数及び第２の逆部分関数と呼ばれるだろう。特定の例において、第１の逆部分関数は、図１のトランスミッタの第１の部分関数の逆関数であり、第２の逆部分関数は、図１のトランスミッタの第２の部分関数１１３の逆関数である。

【0110】

第２の逆部分関数は、従って、受信したｌｕｍａコードのｌｕｍａ値へのマッピングを与え、第１の逆部分関数は、ｌｕｍａ値の線形ルミナンス値へのマッピングを与える。

【0111】

第１の逆部分関数及び第２の逆部分関数は、これらが逆関数であるので、第１の部分関数１１１及び第２の部分関数１１３に対応する特性を有することは言うまでもないだろう。

【0112】

詳細には、第１の逆部分関数は、入力ｌｕｍａ値の最大ｌｕｍａ範囲の、画素線形ルミナンス入力値の最大ルミナンス範囲への非線形可逆マッピングを規定する。

【0113】

従って、第２の逆部分関数は、入力ｌｕｍａコードの最大ｌｕｍａ範囲の、ｌｕｍａ出力値の最大のｌｕｍａ範囲への非線形可逆マッピングを規定する。

【0114】

従って、本例において、レシーバは、レシーバにおいて用いられる部分関数を決定するように構成される部分関数生成部２０９を有する。詳細には、部分関数生成部２０９は、第１の逆部分関数及び第２の逆部分関数を決定してもよい。

【0115】

幾つかの実施形態において、第１の逆部分関数及び第２の逆部分関数は、例えば、逆部分関数を規定する例えばユーザ入力又はローカル情報に基づいて生成されてもよい。

【0116】

しかしながら、多くの実施形態において、第１の逆部分関数及び第２の逆部分関数は、画像データと一緒に受信される制御データに基づいて決定される。詳細には、図１のトランスミッタは、第１の部分関数１１１及び第２の部分関数１１３を規定するデータを含んでもよい。データは、幾つかの実施形態において、２つの関数の識別を単純に規定してもよく、図２のレシーバは、異なる関数が関連した識別と一緒に格納されるローカルストアを有してもよい。幾つかの実施形態において、受信したデータは、部分関数の１又はそれ以上のパラメータを更に有してもよい。例えば、ガンマ関数が識別されてもよく、ガンマ値は、ガンマ変換のためのパラメータとしての受信したデータストリームにおいて供給されてもよい。

【0117】

部分関数生成部２０９は、決定された部分関数に基づいてコードマッピング関数２０３を生成するように構成されるマッピング生成部２１１に結合される。マッピング生成部２１１は、例えば、第２の逆部分関数及び第１の逆部分関数の連続した適用としてコードマッピング関数２０３を直接生成してもよい。

【0118】

実際には、幾つかの実施形態において、コードマッピング関数２０３は、第２の逆部分関数及び第１の逆部分関数の連続した適用として生成されてもよい。実際には、受信した入力ｌｕｍａコードは、第２の逆部分関数に供給されてもよく、第２の逆部分関数のｌｕｍａ出力値は、第１の逆部分関数に直接供給されてもよい。幾つかの実施形態において、生ずる線形ルミナンス値が直接用いられてもよく、実際には、この線形ルミナンスは、元のＨＤＲ画像に対応するだろう。

【0119】

図３は、追加のマッピングが実行され得るコードマッピング関数２０３の一例を示している。本例において、ｌｕｍａコードは、ｌｕｍａ出力値を生成するために非線形マッピングを適用する第２の逆部分関数３０１に供給される。ｌｕｍａ出力値は、ｌｕｍａ対ｌｕｍａマッピングを実行し得る第３の関数３０３に供給される。このマッピングは、例えば、ローカル優先度に従う自動化された補正であってもよく、又は、ｌｕｍａ値に適用される手動色等級づけであってもよい。そして、生ずるｌｕｍａ値は、これらのｌｕｍａ値を線形ルミナンス値にマッピングする第１の逆部分関数に供給される。

【0120】

第１の逆部分関数及び第２の逆部分関数を直接適用するよりはむしろ、これらのうち少なくとも１つの変更されたバージョンが用いられてもよいことは言うまでもないだろう。例えば、第１の逆部分関数は、ガンマ変換を有してもよく、第１の逆部分関数は、第１の部分関数１１１において適用されるものとは異なるガンマ値を用いるように構成されてもよい。しかしながら、斯様なアプローチは、第１の逆部分関数を最初に適用し、その後、生ずる値から、変更されたガンマ関数に対応する値にマッピングする第２の関数が続くのと同じである。換言すれば、例えば異なるガンマ値を適用する場合であっても、（例えば第１の部分関数１１１による）エンコーダにおけるマッピングの情報が依然として考慮され、それ故、コードマッピング関数２０３は、第１の逆部分関数及び第２の逆部分関数の双方に依然として依存する。

【0121】

幾つかの実施形態及びシナリオにおいて、コードマッピング関数２０３は、量子化部１０９のマッピングを表してもよいことは言うまでもないだろう。とりわけ、量子化部が（例えば浮動小数点から整数値までの）表現の変換を含む場合、その効果は、コードマッピング関数２０３により反転されてもよい。

【0122】

コードマッピング関数２０３及び／又は逆関数を決定するための異なるアプローチは、異なる実施形態において用いられてもよいことは言うまでもないだろう。

【0123】

例えば、先に述べた通りに、幾つかの実施形態において、受信したデータは、第１の逆部分関数及び第２の逆部分関数を直接識別してもよく、コードマッピング関数２０３は、（例えば他のマッピングに加えて）これらの関数を受信したデータに適用することにより決定されてもよい。

【0124】

幾つかの実施形態において、レシーバは、コード配分関数の少なくとも部分を最初に決定して、典型的にはコード配分関数の部分の反転を決定することにより、コードマッピング関数２０３を決定してもよい。

【0125】

例えば、幾つかの実施形態において、部分関数生成部２０９は、エンコーダにおいて使用される第１の部分関数１１１及び第２の部分関数１１３（又はこれらのうちの１つ）を最初に決定してもよい。そして、逆関数を、即ち、第１の部分関数１１１から第１の逆部分関数を、第２の部分関数１１３から第２の逆部分関数を、決定するよう進行してもよい。逆関数の決定は、幾つかの実施形態において、関数がエンコーダにより第１の部分関数１１１又は第２の部分関数１１３として用いられ得る考えられる関数の逆関数であるという予め決められた認識に基づいてもよい。他の実施形態において、第１の部分関数１１１の定義は、例えば、線形ルミナンス値と第１の部分関数１１１の対応する出力ｌｕｍａ値とのルックアップテーブルを生成するために用いられてもよい。そして、このルックアップテーブルは、格納されたｌｕｍａ値を入力パラメータとして用いることにより逆関数として用いられてもよい。即ち、所与のｌｕｍａ値のために、ルックアップテーブルにおいて関連付けられた線形ルミナンス値が取り出されてもよい。もちろん、同じアプローチが、第２の部分関数１１３及び第２の逆部分関数に対して用いられてもよい。

【0126】

以下において、考えられる部分関数、コードマッピング関数及びコードマッピング関数２０３の仕様を含む、幾つかの特定の有利な実施形態が更に詳細に述べられるだろう。本例において、関数及びマッピングは、簡潔さ及び分かりやすさのために、曲線と呼ばれる。

【0127】

多くの実施形態において、コード配分関数は、対数関数的曲線を与えるために生成されてもよい。即ち、コード配分関数は、対数曲線に対応してもよい。本アプローチにおいて、これらの曲線は既存のツールにおいて容易に利用可能であり／実装されるので、対数曲線は、既存の対数曲線（即ち部分関数）の単純な連結により構成される。とりわけ、ＨＤＲに適した新たな対数曲線を構成する構成ブロックとしてｓＲＧＢ、Ｒｅｃ７０９及びガンマ曲線を用いることが提案される。最も簡単な形態において、新たな曲線は、これらの構成ブロックのうちの２つだけを連結することにより取得されるが、これらのブロックのうちの３つを連結することにより、より小さな（あまり可視でない）量子化アーチファクトを有する曲線も取得されてもよい。

【0128】

"構成ブロックの"アプローチは、我々が、（１）多数の曲線を素早く構成及び評価すること、（２）例えば色等級づけツールにおいて既に利用可能である曲線の利点を利用すること、を可能にする。

【0129】

曲線をＨＤＲ信号に適用する基本的なブロック図が図４に示されている（全ての図面は、本アプローチのより一般的な概念を説明するためだけの実施形態を説明していることに留意されたい）。

【0130】

図４において、下向きの矢印は、或る曲線により（（典型的にはこのように行われるのを必要としない）ディスプレイ上にこの画像を直接レンダリングする場合に、輝度方向に一緒に近づく比較的暗くて中間の範囲のより代表的な画素を見る）ダイナミックレンジの低減を示し、上向きの矢印は、逆の曲線によるダイナミックレンジ展開を示す。Ｑは、量子化ステップを表す。即ち、我々は、これらに基づく信号及び全ての処理は、チェインにおける位置Ｑにおける浮動小数点（又は高い精度の整数、例えば１２ビット又は１６ビット）において規定されると想定する一方で、表現レベルの数は、例えば２５６又は１０２４まで低減され、従って、信号は、例えば８ビット量子化部インデックスにより表されてもよく、これは、制限されたビット深度／帯域幅のインタフェースを介して格納、送信及び／又はエンコードされてもよい。以下において、我々は、全ての信号及び曲線が、０...１の正規化された浮動小数範囲上で規定されることを想定するだろう。

【0131】

図４中の図は、ルミナンス成分に対応する、単一の信号経路のみを示すという点で、簡素化されている。詳細には、画素色値は、ルミナンス成分及び２つの彩度成分（例えばＹｕｖ表現））として与えられてもよい。図４は、（図１〜３と同様に）ルミナンス成分のための（即ちＹのための）信号経路を示す。

【0132】

画素値が例えばＲＧＢ又はＸＹＺ色表現のような色チャネルとして与えられる幾つかのシナリオにおいて、色チャネルの各々は、個々のモノクロ画像を提供するものとみなされ得る。斯様な考察において、各色チャネルの値は、関連付けられたモノクロ画像のルミナンス表現に対応するものとみなされ得る。故に、実際には、同じ対数曲線は、図５に示すように、各色成分／チャネルに独立して適用され得る。

【0133】

本アプローチは、幾つかの容易に利用可能な曲線を、所望の特性を有する組み合わせられた曲線に組み合わせる。我々が要求する特別な特性は、詳細には、最も低い考えられる知覚的な歪みを有するＨＤＲ信号を量子化するための曲線の適合性である。我々は、（我々が量子化アーチファクトに対して敏感になるように確立した）幾つかの元の（量子化されていない浮動小数点）ＨＤＲテスト画像に適用し、ＨＤＲ基準ディスプレイ上の（逆曲線を適用した後の）量子化された画像におけるアーチファクト（即ちオリジナルとの差分）を視覚的に評価することにより、この目的のための曲線の適合性を確立する。我々は、２又は３の曲線を構成ブロックとして組み合わせることが非常に適切に組み合わせられた曲線を与えることを見出した。

【0134】

３つの曲線を組み合わせる一般的な例、より詳細には、これらを連結する一般的な例（組み合わせられた曲線及び反転の組み合わせられた曲線を組み込むために３本の曲線を連結する例）が図６に示されている。

【0135】

幾つかの実施形態において、量子化前の全ての曲線は、下向きの矢印により示されるように、ダイナミックレンジを低下させる方向に機能し得る（正規化された０...１範囲上で出力≧入力）。量子化後の全ての曲線は、上向きの矢印により示されるように、ダイナミックレンジを増大させるだろう（正規化された０...１範囲上で出力≦入力）。

【0136】

しかしながら、容易に利用可能な構成ブロック（その一つは可変ガンマ曲線であってもよく、少なくともガンマパワーは一部の基準状況で機能するように最適化される）が適用されてもよいので、また、及び、有利には、全体の組み合わせられた曲線が所望の下方又は上方への補正を維持する限り、反対方向に機能するように個々の構成ブロックを適用してもよい（即ち、第１の曲線があまりに急激に曲がる、即ち黒を強く引き伸ばし、その後、利用可能なコードにおいて高を離れたレベルになる場合、黒があまり引き伸ばされないように最終結果の曲線をあまり曲げない第２の補正ブロックを用いてもよく、これは、我々が例えば深い黒色に進まない映画を有する場合に有利になり得る）。これを示す一例が図７に示される。ここで、曲線（ｃ）は、曲線（ａ）及び（ｂ）"に対して"機能する。即ち、他のものが圧縮された場合に局所的に引き伸ばし、その逆も同様である。

【0137】

我々は、５０００ｃｄ／ｍ^２のピーク輝度によりＨＤＲ基準ディスプレイ上に示されるＨＤＲ信号の量子化のために良好に機能するために実験的に決定された種々の組み合わせられた曲線をここで示すだろう（ここで、０．．５０００ｃｄ／ｍ^２の範囲は曲線を適用するために０．．１の範囲に正規化される）。我々の基準ディスプレイＥＯＴＦは、１．２５のガンマであり、これは、我々が正確な暗いサラウンドレンダリングの意図を与えるために見出したものであり、従来の基準ディスプレイ（Cathode Ray Tube）を用いた従来のテレビチェインにおいて生じる値でもある（〔６〕セクション２３．１４，１９．１３及び１１．９を参照）。ＥＯＴＦは、（１．２５に等しいガンマを有する）追加のガンマ曲線構成ブロックであるものとみなされ得る。これは、デコーダ／ディスプレイ側で（のみ）連結される。ほとんどの曲線は、広く実装されるが他の曲線が構成ブロックとして用いられてもよいので、ｓＲＧＢ、Ｒｅｃ７０９及びガンマ曲線構成ブロックを用いて作られた。曲線、従って構成ブロックは、線形のより高度なダイナミックな表現から"対数関数的な"／圧縮されたより低いダイナミックレンジ表現に変換するために、量子化の前に、これらがソース側で用いられるか、又は、"対数関数的"表現からより線形の表現に変換するためにシンク側で用いられるかに依存して、標準及び逆の形式において存在する。構成ブロックとして使用された曲線の正確な定義は、付録：building block curve definitionsにおいて与えられる。

【0138】

ガンマ及びｓＲＧＢ構成ブロック（及びこれらの逆）から構成される第１の曲線が図８に示される。２．１（約２．０．．２．２の範囲）のまわりのガンマの値は、このチェインにおいて適切に機能する。第２の曲線部分を、基準（例えば標準的な状況）と比較される、補正前又は調整後のものとみなしてもよい。

【0139】

ガンマ及びＲｅｃ．７０９構成ブロックから構成される第２の２つのブロック曲線が図９に示される。

【0140】

最後に、我々は、ＰＱがガンマ曲線構成ブロックを追加することにより改良され得ることを実験的に見出した。ここで、ＰＱは、〔７〕の式（７）により与えられる。

【0141】

ＰＱ関数は、

【数1】

として規定される。

【0142】

この式において、Ｙは、割り当てられた結果として生じるｌｕｍａコードであり、Ｖは、（例えば、最適な映画の観察のためにカメラで取得された又は等級分けされた）入力の、０＜＝Ｖ＜＝１の範囲内の浮動小数点としてスケールされたルミナンスであり、Ｌは、１００００ｎｉｔ、ｍ＝７８．８４３８、ｎ＝０．１５９３、ｃ１＝０．８３５９、ｃ２＝１８．８５１６、ｃ３＝１８．６８７５であるように利用された定数であり、

【数2】

は、べき関数である。

【0143】

この曲線は、事前の想定によって規定された。１００００ｎｉｔより高い（又は、少なくとも１００００ｎｉｔより上ではレンダリングしない）シーンルミナンスをエンコードすることはない。その範囲内において（ソフト）クリッピングにより太陽のようにより明るいオブジェクトを常に処理することができるためである。

【0144】

我々は、これからの例示的な実施形態として、基準範囲を規定してもよく、これは、最大５０００ｎｉｔに常に規定される（そして、より明るいディスプレイは、これのエンコードされた値を例えば７０００ｎｉｔのこれらのピーク輝度に（すばやく）ブーストするだろう）。技術を要する読者は、我々は５０００ｎｉｔの白色基準レベルを有する実施形態を教示するが、例えば符号化可能な規格である１５０００ｎｉｔ基準ルミナンス範囲の要求を満たすコーデックに我々の教示を同様に適用することができることをもちろん理解する。

【0145】

ＰＱは、０...１００００ｃｄ／ｍ^２の範囲上に規定されたが、我々は、我々の実験において例えば０の．．５０００ｃｄ／ｍ^２の部分だけを用いる（及び、０の．．１への制限された範囲のための入出力範囲を正規化した）。

【0146】

これを行うために、線形からＬｏｇへの変換において、我々は、１００００で０．．１の入力範囲を乗算し（そして、０の．．５０００の入力範囲のみを用いる）、その後、ｄｏＰＱ（）関数の出力をｄｏＰＱ（５０００）により除算することにより、再び、出力を０．．１の範囲に正規化する。Ｌｏｇから線形への変換において、我々は、最初にｄｏＰＱ（５０００）により乗算することにより入力範囲を適宜スケールし、その後、出力範囲を０．．１に正規化するためにｄｏＰＱｉｎｖ（）の出力を５０００により除算する必要がある。

【数3】

【数4】

【0147】

図１０に示すように、我々が見出した最良に実行するガンマ値は、約１．２５である。図１０におけるＰＱ構成ブロックは、上で述べられるように、０．．５０００上にｃｄ／ｍ^２の範囲で動作する曲線である。

【0148】

前に示された曲線は２つの構成ブロックの組み合わせであった一方で、我々は、３つの構成ブロックの組み合わせを用いて、概ね良好な曲線、即ちより小さな知覚可能な量子化アーチファクトを有する曲線を見出した。例えば、図１１は、２つのｓＲＧＢ構成ブロック及びガンマブロックから構成される曲線を示す。図１２は、２つのＲｅｃ．７０９構成ブロック及びガンマブロックを用いた同様の設計を示している。

【0149】

示された曲線の迅速な概観及び比較を与えるために、これらは、図１３において一緒にプロットされた。横軸は、０．．１の範囲に正規化された、対数関数的／ＬＤＲ領域を表す。縦軸は、０．．１の範囲に正規化された、線形／ＨＤＲ領域を表す。ここで、１の値は、この場合において５０００ｃｄ／ｍ^２のピーク輝度に対応する。より小さな線形値のより明瞭な可視性に関して、値のｌｏｇ２（）は、実際の値の代わりにプロットされる。

【0150】

適切な曲線の他の例は、図１４−１６に示される。本例において、マッピングは、コードマッピング関数を参照して示される。即ち、ｌｕｍａコードの線形ルミナンス値へのマッピングが示される。

【0151】

これらの例は、

【数5】

として与えられるＬＣ（ａ）と呼ばれる部分関数に基づく。ここで、ｘは、０．．１の範囲に正規化された出力値であり、ｖは、０．．１の範囲に正規化された、入力値である。値ｂ、ｃ及びｄは、所望のマッピングを与えるために選択され得る設計パラメータである。

【0152】

我々は、２つの部分曲線定義が色等級づけにおいて、とりわけ既存のＬＤＲ哲学の等級分けツールをＨＤＲフレームワークに適合させることにおいて、どのように極めて有用に用いられ得るかを述べるだろう。このフレームワークにおいて、我々は、ＬＤＲの標準的なソフトウェアをＨＤＲモニタに結合し、ＨＤＲワークフローに変換するためにここで恭二された数学的処理を用いる。我々は、例えばAdobe After Effects［８］を用いることができる（同様の実装は、もちろん、Da Vinci 等からのような異なる色等級づけを用いて行われ得る）。

【0153】

（図８に示された構造までの同様の）曲線の適用のブロック図が図１７に示されている。ここで特別なことは、電子光学的伝達関数曲線を割り当てる完全なコードを、色等級分けツールにおいて用いられる前後のデータに適用する代わりに、我々は、色等級分けの道筋においてＥＯＴＦ定義の第１の部分のみ（即ちガンマ構成ブロックのみ）を適用することである。これは、統計的に変えられた最適な前処理済みの画像をもたらし、これは、しかしながら、ＨＤＲ統計を等級分けツールの内部特性（とりわけ、例えば全体的又は局所的に関わらず画像における異なるオブジェクトの明るさを変えるためのｌｕｍａ曲線曲げツールのようなツールのｌｕｍａ範囲）に最適にマッピングする。

【0154】

その理由は、色等級分けツールの一部は、データを、これらの処理のための（例えば２．２に近いガンマを想定する）線形領域に内部的に変換することであり、従って、ツールは、線形光空間において例えば良好な彩度処理を行うことができる。ＨＤＲ対数曲線全体の部分だけを入力された画像／ビデオデータに適用することにより、これらのツールは、実質的に正しく機能し続けるだろう。

【0155】

リアルタイムプレビューパス、即ち、標準コネクタ（例えばＨＤＭＩ等）を介してＨＤＲディスプレイに進むパスにおいて（注記、関連するＨＤＲディスプレイの更なる所有者の駆動があってもよく、これは、伝達コード又は駆動コード等に変換するためにビデオ画素データ上に更なるマッピングを行うが、我々は、ここでは、一般的なＨＤＲエンコーディング（例えば、ＨＤＲ色等級分けされたビデオコードがどのようにＢＤディスク上へ書き込まれ得たか）にフォーカスする）、我々は、もちろん、インタフェースを介して量子化アーチファクトを制限するために完全な曲線を用いなければならない。従って、等級分け出力の後、我々は、追加のｓＲＧＢ構成ブロックを追加する。長期的には、ＨＤＲ色等級分けが適切に確立されてログ曲線が規格化されたときに、これらの規格化された曲線は、もちろん、色等級分けツールにおいても実装されるだろう。従って、曲線の特別な崩壊はもはや必要とされないだろう。

【0156】

従って、標準の／"理論的な"ＨＤＲワークフローは、（我々が１つのＥＯＴＦ部分の模式的な近似値として平方根ｓｑｒｔを利用する場合）以下のようになるだろう。
[linearize sqrt(sqrt)_encoded "LDR-ed" HDR]又は線形から開始、カメラで取得されたマスターＨＤＲ→線形光エンコーディングにおけるマスター色等級分け→ＨＤＲストレージのためのｓｑｒｔ（ｓｑｒｔ）エンコード又は標準機能のケーブル接続を介した伝送、又は無線（即ち、十分な量子化は、この方法により暗い部分を可能にした、及び、細かい等級分け失われないだろう）→ディスプレイは、前と同じように、元のカメラで取り込まれたシーン／等級分けされた光を略線形的にレンダリングするために、累乗

【数6】

を行う。

【0157】

ここで、我々は、ＨＤＲ等級分けに関して、以下のようにそれを分けた。必要とされる追加のガンマは、事前補償として参照され、我々は、ＬＤＲ線形化される（が、実際のＨＤＲ線形光及び格納又は伝送のためのコードと比較して統計学的に変えられる）画像を我々が等級分けを始める前の等級分けセットにロードする。その利点は、（既存の等級分けツール及びこれらの精度による）我々の等級分けを介して非常に良好な制御を有することである。これは、この疑似画像において、暗い領域は、等級分け部が処理することがほとんどできない幾つかの暗いコードに一緒に束ねられないが（例えば黒い部分においてルミナンスが変化する曲線を少し曲げようとする場合、ｌｕｍａｓは既に大きく変化する）、全体の利用可能な範囲に渡る重大な部分に広がるためであり、従って、我々は、これらを正確に等級分けすることができる。後で、すべては反対に補正され、従って、これらの暗いものは、表示されるときに、ルミナンス位置をレンダリングするこれらの必要とされる線形光で終わる。

【0158】

入力としての線形マスターＨＤＲ→第１のsqrt_preproces→この最適化された"疑似ピクチャ"に対する等級分け→ストレージ又はケーブル伝送のための第２のsqrtを行う→ディスプレイは復元する累乗

【数7】

を再び行う。

【0159】

ビデオ信号として送信又は格納されるものは、例えば以下の手段において規定される用いられたコード配分を有してもよい。２つのガンマ関数濃青色（しかし、典型的には基準／標準関数は、１＝ｓＲＧＢ、２＝７０９等のようなタイプインジケータのみを割り当てられ、我々は、差分／第２のブロックガンマ関数のみ、即ち典型的には少なくともガンマ累乗及びおそらくオフセット及びゲインをエンコードする）。（全ての部分ブロックの連続的適用である）全体のコード配分関数をエンコードし得る（例えば、関数、ＬＵＴ又は結果として生じるガンマを伴う近似最終的なガンマ関数として［暗いオフセットのため必ずしも２つのガンマの製品を必要としない］、及び、主として我々の提案したデュアルブロック曲線に続くオフセット及びゲイン）。

【0160】

本アプローチは、例えば以下のものに適用され得る良好なＨＤＲコード配分曲線を生成するツールとして適用され得る。
１．（前に詳細に述べられるような）色等級分け
２．異なるダイナミックレンジ間の信号の色調マッピング（対数関数的データのダイナミックレンジは、直接的なレンダリングのために適用する場合、線形データのものより低い。極めて暗いコードを有する画素がほとんどないため。最も関連した詳細はより低いピーク輝度を有するディスプレイ上で視覚化され得る）、例えば自動又は半自動式の色調マッピング
３．効率的なＨＤＲ格納／伝送（現在のビデオコーデックは、画像／ビデオデータサンプル当たり８、１０又は１２ビットを用いた整数データ表現で機能する。構成された曲線は、視覚的な質の最小限の損失を伴う斯様な整数フォーマットにおいてＨＤＲデータをエンコードするために適用され得る）

【0161】

当業者は、我々が教示するものの組み合わせが存在し得ること、及び、我々が１つの段落において述べたものが他の実施形態にも関連することを理解する。単なる例のいずれも限定的であると思われないし、明確に意図されない場合の特定の用語も限定的であると思われない。全ての方法機能は、装置構成と同様に実現され、逆もまた同じである。

【0162】

付録：構成ブロック曲線の定義
この付録は、ＡＮＳＩ Ｃコード実装を与えることにより個々の構成ブロックを詳細に述べる。全ての入力及び出力は、正規化された０．．１の範囲を想定する。

【0163】

ｓＲＧＢ構成ブロックは、ｓＲＧＢ仕様（ＩＥＣ ６１９６６−２−１：１９９９）から導出される。↓ｓＲＧＢ曲線は表１において規定され、逆↑ＲＧＢ曲線は表２において規定される。

【0164】

Ｒｅｃ．７０９構成ブロックは、Ｒｅｃ．ＩＴＵ−Ｒ ＢＴ．７０９−５から導出される。↓Ｒｅｃ．７０９曲線は表３において規定され、↑Ｒｅｃ．７０９曲線は表４において規定される。

【0165】

（パラメータγを有する）ガンマ構成ブロックは単純な累乗関数である。下向きに関してγ＜１を有し、上向きに関してγ＞１を有する。それ故、↓γ及び↑γ構成ブロックは、表５において規定される。
表１：↓ｓＲＧＢ曲線の定義

【表1】

表２：↑ｓＲＧＢ曲線の定義

【表2】

表３：↓Ｒｅｃ．７０９曲線の定義

【表3】

表４：↑Ｒｅｃ．７０９曲線の定義

【表4】

表５：ガンマ曲線の定義

【表5】

【0166】

リファレンス
［１］"Color grading," Wikipedia, the free encyclopedia, ［オンライン］.入手可能: http://en.wikipedia.org/wiki/Color_grading.［アクセス 07 08 2012］.
［２］"Post-production," Wikipedia, the free encyclopedia, ［オンライン］. 入手可能: http://en.wikipedia.org/wiki/Post_production.［アクセス 26 06 2013］.
［３］"High-dynamic-range imaging," Wikipedia, the free encyclopedia, ［オンライン］.入手可能: http://en.wikipedia.org/wiki/High-dynamic-range_imaging. ［アクセス 27 06 2013］.
［４］"sRGB," Wikipedia, the free encyclopedia, ［オンライン］. 入手可能: http://en.wikipedia.org/wiki/SRGB. ［アクセス 10 08 2012］.
［５］"Rec.709," Wikipedia, the free encyclopedia, ［オンライン］. 入手可能: http://en.wikipedia.org/wiki/Rec._709. ［アクセス10 08 2012］.
［６］R. Hunt, The Reproduction of Colour, Sixth ed., Wiley, 2006.
［７］S. Miller, M. Nezamabadi及びS. Daly, "Perceptual Signal Coding for More Efficient Usage of Bit Codes," SMPTE Annual Technical Conference & Exhibition, Hollywood, CA, 2012.
［８］"Adobe After Effects," Wikipedia, the free encyclopedia, ［オンライン］. 入手可能: http://en.wikipedia.org/wiki/Adobe_After_Effects. ［アクセス 28 06 2013］.

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】