特許 6358718 ＨＤＲ画像をエンコードするための方法及び装置、並びに、斯様なエンコードされた画像の使用のための方法及び装置

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

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

(11)【特許番号】6358718

(24)【登録日】2018年6月29日

(45)【発行日】2018年7月18日

(54)【発明の名称】ＨＤＲ画像をエンコードするための方法及び装置、並びに、斯様なエンコードされた画像の使用のための方法及び装置

(51)【国際特許分類】

   H04N 19/36 20140101AFI20180709BHJP

   H04N 19/186 20140101ALI20180709BHJP

   H04N 19/85 20140101ALI20180709BHJP

   H04N 19/46 20140101ALI20180709BHJP

【ＦＩ】

   H04N19/36

   H04N19/186

   H04N19/85

   H04N19/46

【請求項の数】6

【全頁数】41

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

(86)(22)【出願日】2015年3月19日

(65)【公表番号】特表2017-523621(P2017-523621A)

(43)【公表日】2017年8月17日

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

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

(87)【国際公開日】20151203

【審査請求日】2017年12月11日

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

(32)【優先日】2014年5月28日

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

【早期審査対象出願】

(73)【特許権者】

【識別番号】590000248

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

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

(74)【代理人】

【識別番号】100122769

【弁理士】

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

(74)【代理人】

【識別番号】100163810

【弁理士】

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

(72)【発明者】

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

(72)【発明者】

【氏名】マーテンス マーク ジョゼフ ウィレム

【審査官】 堀井 啓明

(56)【参考文献】

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

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

【文献】 High Dynamic Range video coding[online]， JCTVC-P JCTVC-P0159r1，インターネット＜URL:http://phenix.it-sudparis.eu/jct/doc_end_user/documents/16_San Jose/wg11/JCTVC-P0159-v3.zip＞

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

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

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

【請求項1】

高ダイナミックレンジ画像をエンコードする方法であって、
ａ）高ダイナミックレンジ画像の、正規化された高ダイナミックレンジ画像をもたらす［０，１］であるｌｕｍａ軸のスケールへの正規化であって、正規化された色は、正規化されたルミナンスを有する、正規化、
ｂ）ガンマ変換されたルミナンスをもたらす正規化されたルミナンス上のガンマ関数を計算すること、
ｃ）

【数1】

として規定されるルマをもたらす第１のトーンマッピングを適用すること、ここで、ＲＨＯは、予め決められた値を有し、
ｄ）前記ｌｕｍａを低ダイナミックレンジ画像の出力ｌｕｍａにマッピングする任意の単調に増大するトーンマッピング関数を適用すること、
を適用することにより、高ダイナミックレンジ画像を低ルミナンスダイナミックレンジの画像に変換するステップと、
画像信号において、前記低ルミナンスダイナミックレンジ画像の画素色を符号化した結果を出力するステップと、
前記画像信号において、メタデータとしての上記の色変換ｂ〜ｄの関数形状をエンコードする値又はこれらの逆関数のための値を出力するステップとを有し、
前記メタデータは、レシーバが、前記低ルミナンスダイナミックレンジ画像から、復元された高ダイナミックレンジ画像を復元するのを可能にし、ＲＨＯ又はＲＨＯの関数である値は、前記メタデータにおいて出力される、方法。

【請求項2】

ガンマ関数計算は、１／（２．４）に等しいガンマ値を用いる、請求項１に記載の方法。

【請求項3】

低ダイナミックレンジ画像の最大ｌｕｍａを、復元された高ダイナミックレンジ画像における考えられる値の特定の値にマッピングするためのゲイン値を決定するステップと、
前記画像信号においてそのゲイン値をエンコードするステップとを有する請求項１に記載の方法。

【請求項4】

高ダイナミックレンジ画像をエンコードするように構成された画像エンコーダであって、
前記高ダイナミックレンジ画像を低ルミナンスダイナミックレンジの画像に変換するように構成されたダイナミックレンジ変換ユニットを有し、
前記ダイナミックレンジ変換ユニットは、
ａ）高ダイナミックレンジ画像を［０，１］の範囲に渡るｌｕｍａ軸に正規化し、正規化されたルミナンスを出力する正規化部、
ｂ）前記正規化されたルミナンスにガンマ関数を適用し、ガンマ変換されたルミナンスを出力するガンマ変換ユニット、
ｃ）

【数2】

として規定されるルマをもたらす第１のトーンマッピングユニット、ここで、ＲＨＯは、予め決められた値を有し、
ｄ）前記ｌｕｍａを低ダイナミックレンジ画像の出力ｌｕｍａにマッピングする任意の単調に増大するトーンマッピング関数を適用するように構成された任意のトーンマッピングユニット、
を有し、
当該画像エンコーダは、
前記低ダイナミックレンジ画像の色にデータ削減変換を適用するように構成された画像圧縮部であって、これらの色は、成分画像において構成され、削減変換は、少なくとも、隣り合う色成分のブロックにＤＣＴ変換を適用することを含み、低ルミナンスダイナミックレンジ画像の画素色の圧縮された符号化結果をもたらす、画像圧縮部と、
圧縮された符号化結果を画像信号において出力するように構成され、加えて、画像信号において、色変換の関数形状をメタデータとしてエンコードする値又はこれらの逆関数のための値を出力するように構成されたフォーマッタとを有し、
メタデータは、レシーバが、低ルミナンスダイナミックレンジ画像に基づいて高ダイナミックレンジ画像を復元するのを可能にし、前記値は、ＲＨＯ又はＲＨＯの関数である値を有する、画像エンコーダ。

【請求項5】

高ダイナミックレンジ画像信号を受信するように構成された画像デコーダであって、
画像信号から、圧縮された画素化された低ダイナミックレンジ画像及びパラメータデータを取得するように構成されたデフォーマッタと、
画素化された低ダイナミックレンジ画像を取得するために、圧縮された画素化された低ダイナミックレンジ画像に少なくとも逆ＤＣＴ変換を適用するように構成された解凍部と、
低ダイナミックレンジ画像を復元された高ダイナミックレンジ画像に変換するように構成されたダイナミックレンジ変換ユニットとを有し、
前記ダイナミックレンジ変換ユニットは、
ａ）任意の単調に増大するトーンマッピングを適用するように構成された任意のトーンマッピングユニットであって、これを規定するパラメータは、パラメータデータにおいて受信される、任意のトーンマッピングユニット、
ｂ）

【数3】

の形式の関数により規定されるマッピングを適用するように構成された第１のトーンマッピングユニット、ここで、ＲＨＯは、前記パラメータデータにおいて受信される定数であり、
ｃ）受信したガンマ値を有するガンママッピングを適用するように構成されたガンマ変換ユニット、
を有する、画像デコーダ。

【請求項6】

高ダイナミックレンジ画像信号をデコードする方法であって、
画像信号から圧縮された画素化された低ダイナミックレンジ画像及びパラメータデータを取得するステップと、
画素化された低ダイナミックレンジ画像を取得するために圧縮された画素化された低ダイナミックレンジ画像に少なくとも逆ＤＣＴ変換を適用することにより、圧縮された画素化された低ダイナミックレンジ画像を解凍するステップと、
ａ）任意の単調に増大するトーンマッピングを適用することであって、これを規定するパラメータは、パラメータデータにおいて受信されている、適用すること、
ｂ）

【数4】

の形式の関数により規定されるマッピングを適用すること、
ｃ）受信したガンマ値を有するガンママッピングを適用すること、により、
低ダイナミックレンジ画像を復元された高ダイナミックレンジ画像に変換するステップとを有する、方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、１つの高ダイナミックレンジ画像（即ち、静止画）、好ましくは複数の高ダイナミックレンジ画像（即ち、ビデオ）のエンコーディング、必要な符号化された画像情報を受信側に伝達するための対応する技術的システム及び方法、並びに、符号化された画像をデコードし、最終的にこれらを表示のために利用可能にするデコーダに関する。

【0002】

ＨＤＲ画像は、ＨＤＲシーンの視覚的に良好な品質のレンダリングが例えば５０００ｎｉｔのような高いピーク輝度を有するＨＤＲディスプレイ上で行われ得るような態様において、シーンにおける種々の取り込まれたオブジェクトの色テクスチャの高品質エンコーディングのための充分な情報によって（典型的には非常に明るい領域及び非常に暗い領域の双方を含み得る）ＨＤＲシーンのテクスチャをエンコードする画像である。数年に渡って開発された我々のＨＤＲエンコーディングフレームワークにおいて、我々は、同時に、そのシーン上の種々の包囲されたダイナミックレンジの下位視野（subview）もエンコードしたかった。これは、連続的に低減されたダイナミックレンジの種々の表示のための良好な駆動画像、少なくとも例えば１００ｎｉｔのピーク輝度の表示を駆動させるのに適しているＬＤＲ画像の見た目として機能し得る。

【0003】

更に、ＨＤＲエンコーディングは、好ましくは、既存のビデオ符号化技術と比較的良好にマッチするだけでなく、例えばブルーレイディスクストレージ（及び、ストレージメモリの量のようなその制約、実質的に全ての他の規格化された態様）のような既存の技術の現在の画像又はビデオエンコーディングフレームワーク、又は、ＨＤＭＩケーブル接続、又は、他の画像伝送又はストレージシステム等にも合わせることができるように技術的に設計される。とりわけ、時間インスタント毎に２つのエンコードされた画像（例えば、ＬＤＲ画像、及び、各画素をＨＤＲ画像画素までブーストするための局所的に明るくなる強度を有する画像）を用いるＨＤＲエンコードシステムは、不必要に複雑なもののようにとりわけ装置製造者により理解される。

【0004】

ＨＤＲビデオ（又は静止画像）エンコーディングは、最近暫定的に調査されているだけであり、及び、今まで困難なタスクであった。典型的な考えは、シーンオブジェクトのＬＤＲ範囲より高い輝度をエンコードする（例えば、シーンルミナンスを直接エンコードするエンコーディングの）ために非常に多くのビットへ向かうことを必要とすること、又は、２層アプローチを必要とすることである。例えばオブジェクト反射画像に加えて、イルミネーションブースト画像又は類似の分解ストラテジが存在する。例えばドルビーのＨＤＲ符号化システムのような代替アプローチは、典型的には、２層ＨＤＲエンコーディング技術を常に用いる（ＵＳ８２４８４８６Ｂ１参照）。ＷＯ２０１０／１０５０３６は、ドルビーからの斯様な時間インスタンス当たり２画像エンコーディングシステムの他の例である。（例えば、古典的アナログセルロイドフォトグラフィの動作を模倣する）単純な固定されたトーンマッピングＴＭは、これに対応するＨＤＲグレーディングにＬＤＲ画像をマッピングするために用いられ得るか、又は、逆もまた同じである。これは、あまり正しくないマッピング関数になるかもしれない（グレーダは、言わばＬＤＲグレーディングにおける複雑にされた最適化の決定を用いているかもしれないためである）。従って、元の言わばＨＤＲ画像の予測と元のＨＤＲ画像自体との間にかなりの差分があるかもしれないが、これは問題にならない。システムは、第２の補正画像として差分（残余ビットストリーム７４２）を送信することができるためである。

【0005】

斯様な２画像エンコーディングシステムの他の例は、テクニカラーＨＤＲ符号化システムである（Joint Cooperative Team on video coding of ITU-T SG 16 WP3, San Jose of 9-17 Jan. 2014の第１６回ミーティングの文書JCTVC-P0159r1）。これは、第１の画像として、局所的イルミネーションである低解像度信号をエンコードする。これは、典型的には、調整された２Ｄ ＬＥＤバックライトにおいて生成されるためである。第２の画像は、その低周波数信号に基づく典型的により低いダイナミックレンジ変調のテクスチャ画像である。これは、典型的には、適切なＬＣＤバルブ駆動信号による表示に基づき生成されるだろう。

【0006】

フィリップスは、非常に単純な単一画像アプローチを最近発明した（依然として公にされていないが、幾つかの態様は、ＷＯ２０１２／１４７０２２及びＷＯ２０１２／１５３２２４において見られ得る）。これは、画像及びビデオ符号化における新たな方向であり、想像することが容易ではない先験的なものであるだけでなく、実際にこれを行うときに、解決されるべき多くの技術的な課題をもたらす。しかしながら、これは、実際にうまく機能する。

【0007】

"高ダイナミックレンジ"（ＨＤＲ；high dynamic range）によれば、取り込み側から取り込まれた画像がレガシーＬＤＲエンコーディングと比較して高いルミナンスコントラスト比を有することを意味する（即ち、１０．０００：１又はそれ以上のオブジェクトルミナンスコントラスト比は、符号化により扱われ得る。画像ハンドリングの全ての成分はレンダリングにつながれる。取り込まれたオブジェクトルミナンスは、１０００ｎｉｔを越え得る。あるいは、より詳細には、典型的には、再生環境が与えられた場合に言わば点灯されたランプ又は日が照っている屋外の望ましい外観を生成するために１０００ｎｉｔより上で再生／レンダリングされ得る）。そして、典型的には、斯様な画像のレンダリングは、ＨＤＲである（即ち、これらの画像は、高画質ＨＤＲレンダリングのために充分な情報を含むという点で、好ましくは技術的に使いやすい態様において、適切でなければならない）。画像は、少なくとも１０００のｎｉｔのピーク輝度によりディスプレイ上にレンダリングされるか又はレンダリングされるのを意図される（これらは、典型的には適切なカラーマッピングの後に、例えば１００ｎｉｔのピーク輝度のＬＤＲディスプレイ上に代わりにレンダリングされ得ない、及び、レンダリングされる必要がないことを意味するものではない）。

【背景技術】

【0008】

最近、例えばドルビーのデュアルレイヤ手法（ＷＯ２００５／１０４００３５）のように、多数のＨＤＲエンコーディング技術が提案されている。しかしながら、産業界は、現在、データ量、計算複雑性（ＩＣの価格）、取り込みの容易さ、アーティストが好きであるものは何でも生成するための用途の広さ等のような極めて重要なファクタのような全ての要件（のバランス）を有する実際的なＨＤＲビデオ（／画像）エンコーディング技術を依然として探している。とりわけ、デュアルレイヤアプローチは不必要に複雑なものとして見られる。理想的には、例えばＤＣＴベースのＭＰＥＧ ＨＥＶＣエンコーディングのようなレガシーエンコーディングに適合する符号化技術を設計することができるようにしたい。問題は、これが多少直観に反しているということである。即ち、ＨＤＲ画像をどのようにエンコードすることができるかであり、これは、定義により、ＬＤＲ画像とは異なるものになるべきである。典型的には、ＬＤＲ画像を含めるために最適化された技術において、興味深い輝度／ルミナンス範囲のより大きな量を有する。これらのレガシーＬＤＲ画像ハンドリング／符号化システムは、典型的なＬＤＲイメージングシナリオによって機能するように設計及び最適化された。これは、通常、例えばスタジオ照明比において４：１（又は、例えば１０：１）によって適切に照らされる。視野における（白色のための言わば８５％と黒色のための５％との間の反射において変化し得る）ほとんどのオブジェクトに対して約６８：１（１７０：１）の全体のコントラスト比を与える。ピークホワイトから開始するオブジェクトルミナンスの相対的レンダリング（即ち、画像ホワイトを利用可能なディスプレイホワイトにマッピングする）を見る場合、局所的調光を伴わない典型的な初期のＬＣＤモニタは、１００ｎｉｔの白色及び１ｎｉｔの黒色のようなものを有するだろう。これは、画像コントラスト比とマッチするだろう。典型的には、平均のＣＲＴシステム上でその日の間にも見られたかもしれないと考えられるものは、４０：１の能力のようなものを有するだろう。これらのシステムにおける２．２の標準レガシールミナンスコード割当てガンマ関数を有することは、より高いシーンコントラストのほとんどのシナリオのために満足に思われた。その頃に許容可能なエラーとみなされたものが作られたにもかかわらず、悪くエンコードされた高ルミナンスシーン領域のレンダリングの斯様な誤差（例えばウインドウの背後で明るい屋外をハードクリッピングする）は、許容可能であった。ＬＤＲディスプレイは、これらのオブジェクトルミナンスを物理的に正確にレンダリングすることができなかったためである。

【0009】

しかしながら、例えば屋内シーンのような、レンダリングを向上させるという欲求があるというシナリオがある。これは、日当りのよい屋外を同時に見ることができ、この場合において、１００：１又はそれ以上のイルミネーション比であってもよい。線形の相対的レンダリング（即ち、最も明るいエンコードされた領域又は同等に最も明るいシーン領域の中間グレーにフォーカスし、画像ホワイトをディスプレイホワイトにマッピングする）によれば、屋内ホワイトは、観察者に対して精神視覚的な黒にマッピングされるだろう。従って、ＬＤＲにおいて、これらの日当りのよい領域は、典型的には、（典型的には、これらの画素のための最大２５５周辺でコードを識別するのを困難にするエンコードされた画像において）（ソフト）クリッピングされるように示されるだろう。しかしながら、ＨＤＲディスプレイ上で、我々は、これらを明るくカラフルに示すことを望む。これは、（実際にイタリアでの休日の場合のように）斯様なシーンの非常により自然主義的な及び素晴らしいレンダリングを与えるだろう。しかしながら、より高輝度のコンテンツが幾つかの鏡面反射のみで構成されるシーンであっても、大きな視覚的画質改善を既に示す。クリッピング又は量子化エラーのようなアーチファクトが例えば５０００又は１００００ｎｉｔのディスプレイ上で不快に見えない場合、少なくとも、我々は、レンダリングされた画像がＨＤＲディスプレイが可能にするのと同じくらい美しくなるように、正しい種類の画像により斯様なＨＤＲディスプレイを駆動させることができるようにしたい。

【0010】

しかしながら、古典的考えは、追加の過度な輝度範囲をエンコードするために（非常に）多くのビットを有する必要があるということであった。これらは、ＬＤＲの範囲より高いオブジェクトルミナンスをエンコードするより高いビットである。これは、（符号ビット、５ビットの累指数及び１０ビットの仮数の１６ビットを有するＯｐｅｎＥＸＲ、又は、考えられるオブジェクトルミナンスの全体を高精度に数学的に正確に取り込もうとするWardのＬｏｇＬｕｖエンコーディングのような）単一の大きなコード語において最適化されてエンコードすることにより、又は、標準のＬＤＲの範囲のコードを有する第１のレイヤ（例えばＨＤＲ画像の古典的ＪＰＥＧ近似値）及び斯様な画素ルミナンスをより高い輝度まで向上させるための第２のレイヤ（例えば、より高いルミナンスを必要とする場合に各画素をブーストするためのブースト画像、即ち、単一の線形１６ビットコードと等価である２つの斯様な８ビット画像の乗算）を用いることにより、生じ得る。

【0011】

実用的なＨＤＲ符号化技術を設計するときに解決されるべき大きな実用的な問題は、もちろん異なるＨＤＲ画像の巨大な範囲を扱うことができなければならないという事実に加えて、ハードウェア製造者がコード語（チャネル（即ちｌｕｍａ及び２つの色彩チャネル））毎により低い量のビットを要求することである。しかしながら、我々の以下で提案された技術はより大きなビット語によって機能することもできるが、少なくともルミナンス（又はより正確にはｌｕｍａ）チャネルのための１０ビットの制約下でうまく機能する解決策をもたらす（ルミナンスチャネルを有する実施形態を解明するにもかかわらず、我々の概念は、（線形又は非線形の）ＲＧＢ色表現上で機能するものとして必要な変更を加えて具現化され得ることに留意されたい）。更に、我々は、二重の観点において、（ＬＤＲ画像を介したＨＤＲの見た目の）色画素エンコーディング及び幾つかのレンダリングシナリオのための色外観変換（即ち、異なるピーク輝度、例えばＰＢ＝８００ｎｉｔを有する幾つかのディスプレイ上にシーンをレンダリングするための必要とされる最適な見た目）の双方を機能的な態様において行うことができるフレームワークを開発した。これは、少なくとも１つの更なるグレーディングの見た目、及び、詳細には各画像に対して少なくとも１秒の画像の代わりにＬＤＲの見た目に加えてＨＤＲの見た目をエンコードするときに関数だけが共同エンコードされるのを必要とすることを意味する。

【0012】

我々は、現在ＨＤＲエンコーディングシステムの２つのカテゴリを有する。市場が、種々のプレーヤ及びこれらの異なるニーズが与えられる、エンコーディングシステムにおける斯様な用途の広さを望んでいるためである。モードｉ（又は、例えばＢＤディスク上の単独で規定する画像としてエンコードされるＨＤＲの見た目、又は、ネットワーク接続を介したＡＶＣ若しくはＨＥＶＣ画像のストリーム）システムにおいて、我々は、唯一の画素画像としてＨＤＲの見た目の画像を用いる。これは、オブジェクトの色テクスチャ及び形状をエンコードするために用いられる（斯様な唯一のＨＤＲ画像が少なくともＨＤＲの見た目の画素色を規定するためにどのようにレシーバに送信され得るか、及び、適切な再グレーディング関数によってどのようにレシーバがその画像における色を処理することにより他の見た目の画像を計算することができるかについて、出願人のＷＯ２０１５００７５０５を参照）。これにより、我々は、元のＨＤＲマスターグレーディング画像、即ち、例えば典型的には５０００ｎｉｔのピーク輝度ディスプレイのような基準ＨＤＲディスプレイ上で最良に見るために最適に色等級分けされた画像を利用し、これを最小限変換するだけである。基本的に、コード割当て関数又は光電子伝達関数ＯＥＴＦのみを適用する（このＯＥＴＦは例えばカメラにより取り込まれるシーンルミナンスがどのようにｌｕｍａコードに伝達されるかを規定するが、テレビエンジニアは、ｌｕｍａコードから基準ディスプレイでレンダリングされるルミナンスにするために代わりに電気光学伝達関数ＥＯＴＦである逆関数を特定したいことに留意されたい）。ＯＥＴＦを用いることにより、利用可能なもの（例えば、全ての輝度値に渡るｌｕｍａ Ｙ´チャネルのための１０ビットのコード）を最適に割り当てる。これは、基準［０−５０００］ｎｉｔディスプレイ上で行うことを必要とする。そして、異なるピーク輝度のディスプレイのための他の所望のグレーディングは、このＨＤＲの見た目の画像を変換することにより行われ得る。我々のフレームワークにおいて、我々は、典型的は１つの第２のグレーディングのみによりこのディスプレイの見た目の同調性を可能にする。これは、考えられるディスプレイの範囲の他の最端において機能すべきである（即ち、１００ｎｉｔピーク輝度ディスプレイのためのコンテンツ作者／色グレーダに従って最適又は適切である見た目（これは、典型的にはＬＤＲディスプレイのカテゴリのための基準ディスプレイである））。これは、単なる作成側の再カラーリングステップよりもむしろ更なる見た目の共同エンコーディングであることに留意されたい。この要求される色変換は、全体的な輝度再調整（例えば、画像においてより暗い色を輝かせる）を実現するガンマ関数、局所的コントラストを調整する任意のＳ字型又は逆Ｓ字型の曲線、例えば彩度を画像等における幾つかのオブジェクト又は領域の対応する輝度に調整する色彩度処理関数のようなマッピング関数を適用することにより決定される。我々は、これらの関数を、画素化されたＨＤＲの見た目の画像と関連付けられるメタデータとして自由に共同エンコードすることができる（基本関数の制限されたセットに属するものと同じくらい長い限り、我々はどの関数でも必要とする。レシーバは、規格化された態様において理解することができる）。この場合において、我々は、ＨＤＲの見た目の画像から第２のＬＤＲの見た目のグレーディング画像をパラメータ的に規定する（即ち、我々は、画素イメージとしてのそのＬＤＲの見た目の画像をもはやエンコードすることを必要としない）。２つのレイヤエンコーディングシステムとの差を慎重に示す。我々のシステムにおいて、色変換関数は、レシーバにおける第２の見た目を再等級分けすることができるように第２の見た目についてエンコードされる。従って、２画像技術の粗い近似関数よりはむしろ、我々の関数は、種々のオブジェクトの照射がコンテンツ作者によって種々のレンダリングの見た目においてどのように機能するべきかという完全にスマートな認識を含む。生成するアーティストが、その見た目が、色レンダリング機能の第１のレベルを有する表示のための第１の見た目から、色レンダリング機能の第２のレベル（とりわけディスプレイピーク輝度）を有する表示のための第２の見た目に、どのように変換することを望むかというこの認識が与えられる場合、中間機能（例えば１２００ｎｉｔピーク輝度）を有するディスプレイは、２つのグレーディング及び挿入についての認識を用いるにより、そのレンダリング状況のためのより最適な駆動画像自動的にもたらし得る（例えば、ディスプレイは、ＨＤＲの見た目の画像及び機能的変換からの導出されたＬＤＲの見た目の画像及びＨＤＲの見た目の２つの画素化された画像の非対称の混合を行ってもよい。乗法的混合割合は、実際のディスプレイが精神視覚的非線形スケール上でＨＤＲ又はＬＤＲディスプレイにどれくらい近いかにより決定される）。これは、元のＨＤＲの見た目の画像又はＬＤＲの見た目の画像のいずれかによりディスプレイを駆動させることよりも良好になるだろう。

【0013】

これは、シーン（例えば５０００ｎｉｔレンダリング）上の単一の（ＨＤＲ）画像の見た目の強力であり依然として単純な定義であるが、消費者の自宅におけるようなフィールドにおける種々の考えられる表示のためのシーンの適切なレンダリングを導出するための完全なフレームワークである（及び、例えば種々の周囲照明下の人間の視野の変更されたコントラスト感度をモデル化するポストガンマを適用することによる観察環境への潜在的適応）。これは、例えば作者がこれらのコンテンツの良いＨＤＲバージョンを作り、（例えば、ＨＤＲ ＢＤディスク上で、又は、インターネットを介してＨＤＲ動画をオンラインで注文することにより、又は、ＨＤＲテレビジョン放送により）レシーバに送信される実際のエンコーディングにおけるこのＨＤＲの見た目を有したいというアプリケーション／シナリオのために主として有益である。実際にこのコンテンツ版を購入する顧客がＨＤＲディスプレイを有することは必要ではない。顧客は、後にＨＤＲディスプレイを有する時のために購入することができ、ＨＤＲ−２−ＬＤＲ変換を用いることができるためである。しかしながら、顧客がＨＤＲディスプレイのためのコンテンツを望むときに好ましいオプションになるだろう。

【0014】

これに対し、ＨＤＲシーンをエンコードする上記のＨＤＲの見た目の態様（説明されたように、モードｉは、少なくともＨＤＲの見た目の画像は、画素画像としてエンコードされたものである。しかしながら、実際には、その同じシーン上の他の見た目がエンコードされる。しかしながら、その後、例えばクリッピングの実施形態のような色変換関数をパラメータ的に有する。ＬＤＲの見た目は、ＨＤＲ画像の下位範囲を分離し、残りをクリップする）は、主にビデオエンコーディングであるが将来の画像のための実際的な新たな技術的システムをもたらすための重大な技術的なチャレンジをもたらす（ハードウェア製造者のためのＩＣ設計の簡単さとして斯様なファクタを考慮し、それでも、コンテンツメーカーが、実際に点灯されるように見えるランプのような多くの創造的なＨＤＲ効果により、ＳＦ映画、超大作テレビ番組又は自然ドキュメンタリー等のような美しいＨＤＲコンテンツを生成するのを可能にする）。市場は複雑性のさらに他のレイヤを要求した。我々はこの特許の説明において教示するだろう。

【0015】

即ち、幾つかの（我々はモードｉｉと言う）アプリケーションに関して、シーンオブジェクトをエンコードする唯一の画素化された画像としてＬＤＲの見た目の画像を有したくてもよい。これは、例えばブルーレイディスク上に唯一の画像として書き込まれる。コンテンツ作者は、ＨＤＲの見た目の画質を気にかけるにもかかわらず、レガシー技術と同様のＬＤＲの見た目にフォーカスする。そして、典型的には、画像信号Ｓ＿ｉｍにおいて通信されたＬＤＲの見た目の画像をアップグレードすることによりＨＤＲの見た目の画像を導出するために、関連付け可能なメタデータにおいて共同エンコードされる関数パラメータがあるだろう。このモードｉｉの変形（又はＬＤＲの見た目）を選択するための種々の理由があってもよい。これは、例えば任意の処理を行うことができないレガシーシステムのためのものであってもよい（例えば、ＹＣｒＣｂエンコーディングよりもむしろＹ´ｕｖ色として色をエンコードする特定の実施形態において唯一の画像をエンコードするのを好む場合、Ｙ´ｕｖ画像を装うことによりレガシーＨＥＶＣフレームワークにおいてこれを依然としてエンコードすることができる。これは、奇妙に着色されたＹＣｒＣｂ画像であり、ＭＰＥＧコーデックファミリーのメンバーのうちの１つにおいて規格化されるようなレガシーＤＣＴベースのエンコーディング方式を更に用いる。）が、（例えば低輝度のポータブルディスプレイ上で動画を表示する）ＬＤＲの見た目を必要とするアプリケーションのためのものであってもよく、あまりに多くの処理を行いたくはなくてもよい。あるいは、おそらく、作者は、完全なＨＤＲの見た目を生成することについてあまり多くの時間を注ぎ込みたくない（しかしながら、例えばＬＤＲ−２−ＨＤＲ自動変換の軽微な微調整を行うことによりそれを急激に行う。これは、例えば、古いＬａｕｒｅｌ及びＨａｒｄｙの動画リマスタリングのために明るい領域を分離してこれらを非線形にブーストする。）。彼のＬＤＲの見た目をＬＤＲ及びＨＤＲの見た目の最も重要なマスターグレーディングとみなす。これは、潜在的な色誤差によって、任意の色変換を必要とすることなく直接的にエンコードされるべきである。例えば、テレビブロードキャスタは、とりわけ現実の放送のために、このオプションを選んでもよい（例えば、ニュースは、最も素晴らしいＨＤＲである必要はない）。

【0016】

しかしながら、このＬＤＲの見た目（モードｉｉ）のエンコーディングは、他方における自由な芸術的なグレーディング欲求に対する一方における問題の数学的性質及び符号化数学に起因して追加の複雑性を有する。これは、良好な技術的なフレームワークをもたらすために困難なタスクになる。より正確にするために、一方では、我々は、所望のマスターＨＤＲ画像からグレードダウンする関数を必要とし、これらの受信した関数（又は、実際にはダウングレーディングの逆関数）を有するレシーバにおいて、レシーバは、即ち（グレーダがマスターＨＤＲからのダウングレーディングにおいて用いた関数からエンコーダにより導出される）関数のためのパラメータが存在するメタデータ関数パラメータデータにおいて、少なくとも元のＨＤＲ画像の近似値にアップグレードすることができる。これは、唯一のＬＤＲ画像を、十分に近いＨＤＲ予測Ｒｅｃ＿ＨＤＲにマッピングすることができる。しかしながら、一方、ＬＤＲ画像は、±１００ｎｉｔディスプレイ上で直接レンダリングされたとき、即ち更なる色変換を伴うことなく、色等級分け部に従って十分良好に見えるべきである。従って、関数の選択とこれらがＬＤＲ及びＲｅｃ＿ＨＤＲの見た目にどのように影響するかとの間のバランスがそこにあるだろう。また、ＩＣ又は装置の製造者が規格の関数の制限されたセットを参照したいというような他の問題を考慮する。これは、見た目の再グレーディング、及びコンテンツ作者が要求するいかなる見た目も素早く特定するためのこれらの関数に対して有益である。グレーディング時間は高価なものであり、映画リリースのタイミングは重要であり得るためである。以下の説明において、我々は、ＨＤＲシーンエンコーディングのこのモードｉｉの変形を扱うための実用的なシステムを述べるだろう。

【発明の概要】

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

【0017】

我々は、ＨＤＲ画像の改良されたエンコーディングを有することを必要とし、とりわけ、我々は、現時点でとりわけ多くのレガシーＬＤＲシステムがその分野において依然として存在しているときに幾つかのレベルの互換性を必要とするという観点により開始した。これは、一方では、我々が既存の（デ）コーダＩＣを用い続けることを望むことを意味する。これは、（Ｉ）ＤＣＴ［＝画像通信技術との第１のレベルの互換性］のような機能を実装する。しかしながら、加えて、ディスプレイとの第２のレベルの互換性が存在することを必要とする。これは、これらの低ピーク輝度のため、ＬＤＲ画像を必要とする（即ち、ＬＤＲの見た目、例えば画像のより暗い部分において暗すぎる色を有するが、むしろＬＤＲディスプレイ上のより良好な可視性のために明るくされたより暗い色を伴うＨＤＲの見た目ではない）。これらは、ＬＤＲ画像（即ち、斯様なディスプレイダイナミックレンジ機能下での正しいＬＤＲの見た目）のみをレンダリングすることができるためである。これは、現在開発されているレガシーＴＶに加えて、更なる将来において、ラップトップ又はパッドコンピュータ又はモバイルフォンのような低輝度機能の小さなポータブルディスプレイからの範囲にあるディスプレイのスペクトルが存在するためである。また、消費者は、将来において例えば１００００ｎｉｔ及びこれらの間又はそのまわりの全てのディスプレイのピーク輝度を有し得る最も進化したＨＤＲディスプレイへのＨＤＲ映画のレンダリングを望む。そして、ディスプレイが依然としてレガシーであってもよく、単純なものであってもよいにもかかわらず、これは、例えばＨＤＭＩ又は他の接続を介してＨＤＲコンテンツを供給する将来のセットトップボックス又はコンピュータにおいて高い複雑性の新たなデコーディング及びカラーマッピングＩＣにより機能し得る。セットトップボックスは、我々が発明した及び述べたオプションの任意の組み合わせを提供する。レガシーＬＤＲ画像は、イントラオブジェクト及びインターオブジェクトコントラストの間の最適化であることを必要とすることに留意されたい。我々は、オブジェクトの内部テクスチャをはっきりと見ることを望み、それでも、依然として、元のシーンのコントラストが強い大きなＨＤＲの印象をＬＤＲ画像において有することを望む。即ち、高輝度の領域と低輝度の領域との間の差は、ＬＤＲ画像によって完全にレンダリング可能ではなくてもよく、それでも、これの残りが依然として存在すべきであり、人間のグレーダによりＬＤＲにおいて伝送可能な依然として可能な限り最適なシーンにおいて照明変化を行う。

【0018】

我々は、これらの要件を、理想的なシナリオにおいてコンテンツ提供者からの同じ動画又は画像のための（少なくとも）２つのグレーディングを必要とするというアプローチに変換した。我々は、これらを（例えば１００ｎｉｔのまわりのピーク輝度を有するディスプレイを有する、ＬＤＲディスプレイシナリオのために用いられる）ＬＤＲ画像及び（より明るいディスプレイ（例えば５０００ｎｉｔのピーク輝度の基準ディスプレイ）のための）ＨＤＲ画像と単純に言うだろう。

【0019】

従って、幾つかの実用的な例のシナリオのために、我々は、入力としての新規なＨＤＲエンコーディング実施形態のための開始ポイントとして、マスターＨＤＲ等級化画像を有する（作者の好みに従っていかなる色も処理するソフトウェアであったもの、及び、例えばＯｐｅｎＥＸＲのような開始色エンコーディングにおいてエンコードされるものについて等級化と言おう。例えばコンピュータグラフィックス効果を追加することによりもともとＬＤＲとして取り込まれた画像のＨＤＲの見た目へのアップグレーディングであってもよい）。そして、我々は、例えば新たなＢＤディスクプレーヤ又はテレビのＩＣ受信インターネットストリーミングビデオ、又は、現在の画像／ビデオエンコーディング技術の変形に主として準拠する画像ソースに接続される任意のレシーバのための、現在のビデオ又は画像符号化技術のために実際に使用可能である態様においてこのマスターＨＤＲ（Ｍ＿ＨＤＲ）をエンコードする必要がある（即ち、斯様な符号化技術を用いるための通常の手段から少しだけ修正される。これは、符号の意味の再検討を含み得る。即ち、種々のｌｕｍａコードによりエンコードされるそれぞれのルミナンス。しかしながら、例えば全てのバスが１２ビットに変えられる必要はない。即ち、我々の方法は、成分毎に１０ビットだけが利用可能である場合、又は、８ビットシステム上でもより低い画質を受け入れる場合、１２ビットのハードウェアで機能すべきである）。

【0020】

我々は、そのＬＤＲの見た目をＨＤＲの見た目の画像（我々のモードｉｉ）に変換し得る色マッピング関数のパラメータを追加しさえすれば、ＨＤＲ画像がＬＤＲの見た目の画像（即ち、少ししか比色処理（おそらく他の色空間への変換）を伴わないか又は全く伴わない画像。しかしながら、他のルミナンスダイナミックレンジを有するディスプレイにより適している画像オブジェクトの輝度を変換するために任意の又はより多くのトーンマッピングではない。ＬＤＲディスプレイ上に良好な画質表示のために直接用いられ得る）としてエンコードされ得るという重要な理解をもたらした。読者は、理論的に、確実に推測的にではなく、しかしながら、技術的なタスクをセットした後にさえ、これが些細な行為ではないことを予測するべきである（正確な更なる開発を伴うことなく、多少、異なると思われる他の見た目を介して１つの見た目をエンコードすることは若干相反するように見えるためである）。とりわけ、我々の実施形態の多くが既存のＭ＿ＨＤＲから始まるので、エンコードされたＬＤＲの見た目の画素化された画像を、関数は、Ｍ＿ＨＤＲの近い復元Ｒｅｃ＿ＨＤＲにマッピングすることができる。しかし、もちろん、これは、まさに任意の特定のアドホックの態様において一般的に行われ得ない。即ち、特定の技術的なエンコーディングチェインが必要である。

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

【0021】

我々の発明は、例えば少なくとも以下の手段において実現され得る。高ダイナミックレンジ画像（Ｍ＿ＨＤＲ）をエンコードする方法であって、
− 以下のａ）−ｄ）を適用することにより前記高ダイナミックレンジ画像を低いルミナンスのダイナミックレンジ（ＬＤＲ＿ｏ）の画像に変換するステップと、
ａ）正規化されたルミナンス（Ｙｎ＿ＨＤＲ）を有する正規化された色により正規化された高ダイナミックレンジ画像をもたらす［０，１］であるｌｕｍａ軸のスケールへの高ダイナミックレンジ画像の正規化、
ｂ）ガンマ変換されたルミナンス（ｘｇ）をもたらす正規化されたルミナンス上のガンマ関数を計算すること、
ｃ）ｌｕｍａ（ｖ）をもたらす１．５と５．０との間にある予め決められた量を伴う０．１より低い正規化された高ダイナミックレンジ画像の画素のこれらのガンマ変換されたルミナンスをブーストする第１のトーンマッピングを適用すること、
ｄ）低ダイナミックレンジ画像（ＬＤＲ＿ｏ）のｌｕｍａ（Ｙｎ＿ＬＤＲ）を出力するためにステップｂ及びｃを実行することから生じるｌｕｍａをマッピングする任意の単調に増大するトーンマッピング関数を適用すること、
− 画像信号（Ｓ＿ｉｍ）において、低いルミナンスのダイナミックレンジ画像（ＬＤＲ＿ｏ）の画素色の符号化結果を出力するステップと、
− 前記画像信号（Ｓ＿ｉｍ）において、上記の色変換ｂのメタデータとしてのｄへの関数形状をエンコードする値又はこれらの逆関数のための値を出力するステップであって、メタデータは、レシーバが、低いルミナンスのダイナミックレンジ画像（ＬＤＲ＿ｏ）から、復元された高ダイナミックレンジ画像（Ｒｅｃ＿ＨＤＲ）を復元するのを可能にする、ステップとを有する、方法。

【0022】

ｌｕｍａ変換関数のこの特別な組み合わせは、モードｉｉの思考法においてＨＤＲ画像をエンコードすることを処理するための極めて良好な手段であると判明した。即ち、とりわけ、マスターＨＤＲからのこれらの変換関数により導出されるＬＤＲの見た目の画像としてＨＤＲ画像をエンコードするという二重の手段において、ＬＤＲ画像は、適切に使用可能なＬＤＲの見た目の画像であるのと同様にＨＤＲの見た目を忠実にエンコードするという二重の目的にかなう。

【0023】

画素色の任意の符号化結果（即ち、色空間コードシステムにおいて画素の色を表す）が用いられ得ること、及び、他のものより実際的であることに留意されたい。例えば、ＬＤＲ＿ｏは、（Ｒ´Ｇ´Ｂ´）画像として出力され得る。ここで、ダッシュは、線形ＲＧＢ成分の非線形マッピングを示す。我々は、Ｙｕ´ｖの態様においてレシーバに通信されるべきＬＤＲ画像をエンコードすることができる例により解明する。そして、トーンマッピングのような処理は、例えばｕ´ｖ´のようなｘｙ色度座標を有するＹｘｙ表現において実行され得る。しかしながら、同じ以下の発明原理は、他の色表現（例えば線形ＲＧＢ表現）において具現化されてもよい（即ち、計算は、後に、Ｙ成分よりもむしろＲＧＢ成分によって直接行われる）。また、当業者は、幾つかの態様のうちいずれかを機能的なマッピングを特徴付けるパラメータを共同エンコードするために用いることができることを理解するだろう（これは、例えば、そのセグメントの変化ポイントにより規定される多重線形関数であり得る）。これは、典型的には、画像信号Ｓ＿ｉｍにおけるメタデータ又はそれに関連付け可能なメタデータであるだろう（例えばＳＥＩメッセージ構造又は類似物）。これは、その時に、レシーバが、これらを接続されたディスプレイ上でレンダリングするための例えば線形ＲＧＢ出力画像に変換するためのエンコードされた画素色データを理解するためにこれらのパラメータを必要とすることを意味する。データ通信技術によりこれらの観察を規定するパラメータを取得しなければならない（例えば通信リンクを介した接続可能なメモリ位置）。

【0024】

少なくとも画像における最も暗いオブジェクトの色（最も暗い画素色の下位範囲において、実際には、正規化された線形画像の１０％の最も低いルミナンスになるように規定することができる。これは、例えばＹチャネル、又は、対応する最も低い線形ＲＧＢ値であってもよい。）を輝かせる"感度的"マッピング及びガンマ／べき関数のこの特定の組み合わせは、ＨＤＲ画像の比色特性及びとりわけＬＤＲレンダリングを伴うこれらの典型的な不適当な組合せを適切に扱うように機能する。もちろん、多くのＬＤＲレンダリングを予想することができた。例えば、全ての色を無視する些細なもの。これらは、クリッピングにより明るすぎるか又は暗すぎると見なされる。しかしながら、これは、必ずしも、最良のＬＤＲの見た目というわけではなく、良好な画質のＨＤＲの見た目の復元のために確実に使用可能というわけではない。

【0025】

（直接的にモードｉにおける）ＨＤＲ画像及びＬＤＲ画像（とりわけ、ＨＤＲ画像を実際にエンコードするＬＤＲ画像）は、類似の、例えば３ｘ１０ビットのＨＥＶＣコンテナにおいて実際にエンコードされ得るので、ＨＤＲ画像とＬＤＲ画像との間の差について尋ねるかもしれない。この差分は比色差分であり、これは、ディスプレイ、表示環境及び観察者が含まれるときに非常に重要である。数学的には、正規化された画像（即ち、正規化されたＬＤＲ又はＨＤＲ画像）における典型的な画素値及びとりわけヒストグラムからこれを測定することができる。通常のＬＤＲ画像である場合、典型的には、最も暗い画素色と最も明るい画素色との間で斯様な高コントラストは存在しないだろう。もちろん、ＬＤＲ画像においても、白色である値及び黒色である値（ゼロ）があってもよい。しかしながら、これらは、レンダリングされたルミナンスになるだろう。これらを規定する異なるコード割当て関数があるためである。我々の新規なレシーバ／デコーダは、この状況を認識し、いずれの場合においても適切なデコーディングを適用するだろう。我々が、ＬＤＲ画像がレガシーディスプレイ上で直接使用可能であるべきであると言うとき、我々は、デコードされた画像をレシーバに供給するレシーバが、レガシーのコード割当て関数（即ち、典型的にはＲｅｃ．７０９のガンマ２．２）を有するｌｕｍａ値を理解／デコードすることを意味する。ここで、ｍａｓｔｅｒ＿ＨＤＲ（モードｉ）画像は、全体として異なるコード割当て関数によりエンコードされ得る。これは、言わば０．０５の黒いｌｕｍａがＬＤＲ画像より非常に暗い黒色に対応し、０．９６が非常に明るい色に対応することを意味する。それに加えて、モードｉｉは、更なる新たな概念を取り込む。ｌｕｍａコードは、さらに他のコード割当てによるレンダリングされたｌｕｍａになるべきＨＤＲに関連してもよい。グレーダ（とりわけカスタマイズした曲線）による選択に依存して可変でさえあってもよい。とりわけ、モードｉ画像は、典型的には、レガシーのＬＤＲエンコーディングにおけるもののような、比較的均一な（明るい）ヒストグラムを有しないだろう。しかしながら、典型的には多数のより暗いオブジェクトがあり、多数の非常に明るい画素がある二峰性ヒストグラムである（例えば、線形ルミナンス表現において１００ｘより明るい外側の画素。しかしながら、即ち最終的に用いられたｌｕｍａ表現において、特定のコード割当て関数を用いるときに例えば３ｘより明るくてもよい）。幾つかのＨＤＲ画像において、より明るい画素は、極めて少なくてもよい（例えば夜景における２、３のランプ）。
モードｉｉ画像において、この関係は、前と同じように異なるだろう。（単純な解明においてＨＤＲ画像がそのように形成されると想定する）明るい領域と暗い領域との間にいくらかの充分な差が依然としてあるだろう。比較的単純な関数は、Ｒｅｃ＿ＨＤＲにマッピングすることができるだけでなく、ＬＤＲ直接レンダリングでさえも、コントラストの見た目を多少保持することを望み得るためである。しかしながら、一方、２つのルミナンス範囲は、ＬＤＲ全域の制約のため、ある程度、互いに向かって、又は、互いに縮小されてもよかった。しかしながら、これの全てにおいて重要なことは、画像がＬＤＲシーン又はＨＤＲシーンだったかどうかのサインを依然として見ることができるということである。数学的画像分析アルゴリズムだけが、画像においてエンコードされるダイナミックレンジの見た目を解析することができるというわけではない（例えば、見た目の最終的な画質は例えば生産コストよりもあまり重要でないリアルタイムのテレビ製造のため）。画像解析ユニット１７７が用いられ得る。しかし、一般に、これらの最高画質フォーマットにおける我々の符号化技術は、生成側における人間の色等級分け部によって用いられるだろう。生成側は、典型的には、ＨＤＲ及びＬＤＲディスプレイ上で、システムがどのように動作するかを見ることができ（即ち、ＬＤＲの見た目及びＨＤＲの見た目が実際に見える）、等級化キーボードのダイヤルをオンにすることができ、最後に、彼が満足するＬＤＲ画像及びＨＤＲ復元関数をエンコードすることができる。典型的には、レシーバは、この状況の完全な分析を行う必要がないことに留意されたい。これらは、受信した正規化された画像がＨＤＲ画像又はＬＤＲ画像であったかどうか、及び、どれがＬＤＲ画像の変形であるかについてそれ自体気にかける必要はない。これらは、受信した関数を"盲目的に"適用することだけを必要とする。典型的に知ることを必要とする唯一のものは、関数が規定するもの及び／又は唯一の画像が規定するものである。従って、典型的には、信号は、信号のタイプのインジケータ（ＩＮＤ）を含むだろう。もちろん、更なる画像改良を行いたい、例えばテレビのための信号についての通信される多くのものがあってもよい。しかしながら、典型的には、レシーバが最小限知ることを必要とするものは、このＨＤＲエンコーディング信号Ｓ＿ｉｍのタイプである。これは、ＬＤＲレンダリングのために直接使用可能な画像を含む（その見た目がレシーバにより良好なＬＤＲ画像に微調整され得るかどうか。これは、［Ｆｆ１、Ｆｆ２等によってパラメータ化される］更なるトーンマッピング関数を有する受信したＬＤＲ画像ＬＤＲ＿ｔをトーンマッピングすることができる）。この情報により、レシーバは、接続されたＬＤＲディスプレイが適切な画像によって機能する場合にはＬＤＲの見た目の画像は直接送信され得ること、及び、ＨＤＲディスプレイである場合にはレンダリングのための正しいＨＤＲ画像を取得するために最初に色変換が適用されることを知る。技術を要する読者は、これが幾つかの手段において、例えば"ＤＩＲＥＣＴＬＤＲ"のようなキーワードによって、又は、一組の数"１００／５０００"によって、示され得ることを理解するだろう。これは、唯一の画像が１００ｎｉｔディスプレイ（実際の又は基準ディスプレイ）のために意図される画像であり、５０００ｎｉｔのＨＤＲ画像から導出され、これにマッピング可能であることを示す（他のピーク輝度のディスプレイのための他の画像が、色変換関数を規定するパラメータにおける情報によりＬＤＲ画像から導出され得るものではないことを意味するものではない）。

【0026】

我々が、ＨＤＲ画像の詳細をもう少し見る場合（正規化されたとき、及び、最適なモードｉｉのＬＤＲ画像に等級分けされる）、種々のシーンが典型的には例えば５０００又は１００００ｎｉｔのピーク輝度を有するＨＤＲ基準ディスプレイで規定された環境においてマスターグレーディングされることを理解すべきである。

【0027】

前と同じように、明るい日当りのよい屋外を伴う屋内のシーンの説明例を利用すると、Ｍ＿ＨＤＲにおける屋外の色をほぼＨＤＲ中央グレー、従って５０００ｎｉｔの約２０％（即ち±１０００ｎｉｔ）に等級分けしたくてもよい。屋内の色は、実際の典型的な屋内ルミナンスによりレンダリングされるべきでない。我々は、他の環境（例えばテレビ表示の典型的な暗い環境）において動画を見ているためである。従って、明確には、屋内の色は、日が照っている屋外の画素ルミナンスの１／１００でレンダリングされるべきでない。これらは、正確にレンダリングされるわけではなく、基準ディスプレイ上の基準マスターグレーディングが何であったかという任意の受信側での正確なコピーしかないためである。我々は、適合された平均的な観察者に対する外観を考慮することを必要とする。とりわけ、ＨＤＲの見た目において、屋内は、非現実的に暗く見えるべきではない。我々は、例えば"日当りのよい屋外"の画像領域色の１／１０の平均ルミナンスにおいて、従って±１００ｎｉｔのまわりでこれらの色を等級分けすることができる。しかしながら、（少なくとも概念的に言わば線形拡張に近い色マッピングによって）１００ｎｉｔのＬＤＲ基準ディスプレイ上へこれらのｌｕｍａを素朴にマッピングすると、ＬＤＲにおける日が照っている屋外の色は、約２０ｎｉｔ周辺で完全に、及び、もっと高いところでは白色に見えるだろう。しかしながら、屋内の色は、２ｎｉｔまわりでレンダリングされるだろう。これは、精神視覚的な黒色として見えるだろう。これは、"いくらか"最適化を行うことを必要とする。これは、特定のＨＤＲシーンの複雑性上に依存して非常に複雑になるかもしれない。これは、好ましくは、（我々のエンコーディングフレームワークの態様のための）コンテンツ生成側に含まれる人間の色等級分け部を有する。これらの屋内の色をかなり見えるようにするために、我々は、これらを中間グレー（１８％）より多少暗くしてもよい。しかしながら、最適化においてあまり暗くならない。従って、我々は、典型的には５〜７のファクタによりこれらのより暗い色をブーストしたくてもよい（もちろん暗いそれぞれの明るい小領域におけるものに依存して、最適化は、異なる暗い地階に対して異なり得る。壁上のツールをかろうじて見るべきであり、これを照明するランプの光をクリップしてもよい）。それより高いより明るい色を維持する。図５は、我々のＨＤＲ／ＬＤＲエンコーディングチェインの２つの例となるシナリオを示している。曲線５０１及び５０２は、即ちガンマの前の、典型的な第１の"感度"トーンマッピング曲線を示す。これらは、

【数1】

により規定される。０〜１．０の入力ｘｇのための可能な正規化された値、及び、最適なＲＨＯ値を有する。この場合において、マスターＨＤＲは、曲線５０１のための１０００ｎｉｔ（取り込まれたシーンにおけるいかなるコンテンツでも、Ｍ＿ＨＤＲにおけるオブジェクトルミナンスは、０〜最大１０００ｎｉｔ（例えば溶接スパーク又は太陽が等級分けされ得る値）の間で規定される）及び曲線５０２のための５０００ｎｉｔの基準ディスプレイピーク輝度によって規定された。例えば、グレーダは、特定のＭ＿ＨＤＲ画像を与えた良好なＬＤＲの見た目を考慮するのに適切なものを選択し得る。あるいは、生成側の装置は、例えば以下の式に従って自動的に計算してもよい。

【数2】

【0028】

この式において、ＰＢＨＤＲは、Ｍ＿ＨＤＲグレーディング（例えば図５のような１０００又は５０００ｎｉｔ）と関連付けられる基準ディスプレイのピーク輝度である（即ち、これは、考えられる値の範囲を規定し、典型的には、グレーダがマスターＨＤＲの見た目を検討及び生成した現実のディスプレイのＰＢに対応する）。ＧＡＭはガンマ値であり、これは、例えば、典型的には、２．４であってもよい。もちろん、装置（又はグレーダ）は、任意の他のアルゴリズム又は経験則によりこれらの値から逸れてもよい。例えば、多少明るい、又は、平坦な見た目が必要とされる等である。

【0029】

図５において、±１．５〜４．０の間の値のみに対する第１の／感度トーンマッピング部分のためのブーストファクタ（対角線と比較して、正規化されたＨＤＲ ｌｕｍａはｘ軸上にあり、正規化されたＬＤＲ ｌｕｍａはｙ軸上にある）を決定する場合、２．４のガンマを伴うガンママッピング、色の最も暗い１０％のための約６〜７のブーストファクタ）を適用する（曲線５０３及び５０４は、対数及びガンマの組み合わせられたマッピングである）。これは、概略的に必要とするものである（グレーダは、任意のトーンマッピング曲線によって要望通り後に微調整することができる。しかしながら、これは、例えば自動変換装置のための良好なストラテジである。これは、グレーダのみを最小限含む。この場合、微調整が必要とされるか又は望ましい）。一般に、組み合わせられた対数／ガンマトーンマッピング動作（即ちユニット６０２及び６０３）のための±４〜８のブーストを一般的に有することを望む。これは、１．５〜５．０の間のブースト値は、ＲＨＯベースの感度部分（ユニット６０３）のみに対して適切であることを意味する。より暗い色のための斯様な動作を有するユニット６０３のための任意のトーンマッピング関数は、我々が本発明のために必要とするものを満たすだろう。しかしながら、上記の対数ベースの式は、これを実現する単純な実際的な態様である。より明るい色のための動作は、典型的には、典型的にはブーストされたより暗い色により取り込まれた範囲より高いより明るいルミナンスを非線形的にマッピングする関数形状によって穏やかな圧縮になるだろう。極めて複雑なＨＤＲ画像を有することができる。これは、他の値を要求するかもしれない。しかしながら、斯様な極端な状況は、グレーダ（又は自動等級化アルゴリズム）により適切な任意の曲線定義により扱われ得る。デコーディング側において、処理のチェインは、唯一の通信されたＬＤＲ画像からＲｅｃ＿ＨＤＲを計算することができるように、実質的に逆行可能である必要があることに留意されたい。実質的に逆行可能は、元のＭ＿ＨＤＲのような、Ｒｅｃ＿ＨＤＲにおいて同じ色成分値を必ずしも正確に取得する必要はないことを意味する。しかしながら、色の差分は、許容誤差制限の範囲内であるべきである。従って、レシーバは、ＬＤＲ＿ｏ（又はＬＤＲ＿ｉ）にＭ＿ＨＤＲを形成させるとき、及び、これらの関数の形状情報を受信するときにレシーバ側でもともと使用されたダウングレーディング関数を反転させることによりこれらを計算するかどうかに関わらず、又は、Ｒｅｃ＿ＨＤＲにアップグレードを行うために必要な逆関数を直接受信することにより、最後に、ＨＤＲの見た目Ｒｅｃ＿ＨＤＲにアップグレードするための必要とされる色変換関数を取得することができるべきである。これは、とりわけ、典型的には、グレーダがＬＤＲの見た目を厳しい優先度に微調整するために規定することができる任意のトーンマッピング関数のために、当業者が理解するように正規化されたＬＤＲ ｌｕｍａ及びＨＤＲ ｌｕｍａを関連させる単調に増大する関数を規定することを必要とすることを意味するだろう。

【0030】

基本的なモードｉｉの技術的なチェインは、単純な態様において動作する。例えば、幾つかのあまり重要でないシーンのために、グレーダは、任意の関数をインデント性の変換であるデフォルト値で満たしてもよい。我々がチェインにおいて必要な基本的な技術的な成分について述べるにもかかわらず、実用的なリアリゼーションにおいて、これらのブロックの１又はそれ以上は、関数を実行する実際のユニットにおいてグループ化されてもよいことに留意されたい。例えば、幾つかのアプリケーションにおいて、全ての色マッピング関数の全体ＬＵＴを一緒に送信することは望ましいかもしれない。その一方で、他のアプリケーションにおいて、分離した関数を送信することが有利であるかもしれない。テレビが（例えばシーンの分析の後に、又は、観察者によるユーザインタフェース制御下で、自動的に）例えば第１の関数を更に調整したくてもよいためである。これは、画像／ビデオ通信技術を介して受信された感度又はＲＨＯ値と比較して画像を多少輝かせる。より高度なバージョンは、幾つかの更なる処理ステップを用いてもよい。例えば、エンコーディングの方法は、復元された高ダイナミックレンジ画像（Ｒｅｃ＿ＨＤＲ）における考えられる値の特定の値に対して低ダイナミックレンジ画像（ＬＤＲ＿ｏ）の最大のｌｕｍａをマッピングするためのゲイン値（ｇａｉ）を決定してもよい。及び、画像信号（Ｓ＿ｉｍ）におけるそのゲイン値をエンコードする。これは、接続されたディスプレイのピーク輝度（例えばＬｍ＝５０００ｎｉｔ）に対して最終的なスケーリング形式の正規化された色と混同されるべきでない。このゲインは、より用途が広いグレーディング及び／又は符号化を可能にする。

【0031】

高ダイナミックレンジ画像（Ｍ＿ＨＤＲ）をエンコードする極めて有益な改良された方法は以下を有する。
低ダイナミックレンジ画像（ＬＤＲ＿ｏ）を決定するために上記の色マッピングのいずれかを適用した後に、第２の低ダイナミックレンジ画像（ＬＤＲ＿ｉ）を決定するために更なる技術的なトーンマッピングを適用する（３０１）。これは、低ルミナンスダイナミックレンジ画像（ＬＤＲ＿ｏ）に対する代替駆動画像としてＬＤＲディスプレイを駆動させるために用いられ得る。技術的なトーンマッピングは、以下により決定される。
ａ）低ルミナンスダイナミックレンジ画像（ＬＤＲ＿ｏ）の第１の幾何形状領域を決定する。対応する復元された高ダイナミックレンジ画像（Ｒｅｃ＿ＨＤＲ）においてバンディングする可視性は許容可能なレベルを越える。
ｂ）その領域のためのｌｕｍａ（Ｌ＿ｕ）の範囲を決定する。
ｃ）ｌｕｍａ（Ｌ＿ｕ）の範囲に対するｌｕｍａ軸上の隣り合う画素ｌｕｍａ（Ｌ＿ｕｕ）の第２の範囲を決定する。第２の範囲は、最小数（ＭＩＮ）より高い多数のｌｕｍａを有するという条件を満たすために識別され、テクスチャを含む第２の幾何学像領域に対応する。テクスチャは、ＬＤＲ画像（ＬＤＲ＿ｉ）における最小数より少ないコードを用いて表され得る。その第２の領域のための充分な視覚的な画質の復元された高ダイナミックレンジ画像（Ｒｅｃ＿ＨＤＲ）をもたらす関数を適用する。
ｄ）追加のコードが第１の範囲に対して利用可能になるように、ｌｕｍａの第１及び第２の範囲のｌｕｍａを再分配する再分配マッピング関数を決定し、画像信号（Ｓ＿ｉｍ）において、再分配マッピング関数又は好ましくはその逆の関数形状をエンコードする値を出力する。

【0032】

とりわけ、ハードウェア（及び、グレーディングコスト）がグレーディング関数の比較的制限された量が用いられるべきであることを指示する場合、Ｒｅｃ＿ＨＤＲの完全な又は十分に正確な復元とＬＤＲ画像ＬＤＲ＿ｏの見た目との間のトレードオフについて多少限定される。幾つかのＨＤＲシーンはそれほど難しくならないかもしれない（例えば、平均的な観察者は、最適な見た目から過度にずれ過ぎない限り、日の当たる道路の影側の影が少し暗いか又は少しの明るいグレーであるかについてあまり重要ではないかもしれない）。しかしながら、幾つかのＨＤＲシーンはより重要になり得る（例えば、ＨＤＲルミナンス範囲上のどこかに、明るい霧において部分的に隠される人がいるかもしれない。局所的コントラストが高過ぎる場合、見え過ぎるだけかもしれない。しかしながら、コントラストが低過ぎる場合、不可視になり、ストーリーを変えるかもしれない）。レガシーではない（及び、任意のＨＤＲ処理を行う方法を知らない）、及び、更なるトーンマッピングを行うことができる少なくともレシーバのために、グレーディングの他の次元を可能にすることが有利であるだろう。そして、レガシーディスプレイは、"最良の努力の"ＬＤＲ画像を得ることができる。これは、送信される唯一の画像であるだろう。しかしながら、スマートな将来のレシーバは、ＬＤＲの見た目を更に最適化するために幾つかのスマートな技術的トリックを行い得る。従って、グレーダが要求するものにより近くなる（おそらく最終的なＬＤＲの見た目におけるいくつかの値さえクリップする。これは、唯一の送信されたＬＤＲ画像において起こる場合、ＨＤＲ復元と一致しないだろう）。斯様な可能性を有する場合、幾つかのエンコーディング方法又はエンコーダは、この要求を満たすことができる。ＬＤＲ単独画像における極めて複雑な極めて高コントラスト比のＨＤＲ画像を圧搾する場合（例えば、多くのグレー値を有する幾つかの重要な領域を有するＨＤＲ画像、例えば、暗い点灯されていない部屋、比較的適切に照らされた第２の部屋、及び同時にカラフルな日に照らされた屋外、及び、例えば適切に照らされた部屋におけるランプの下の白色テーブルの、多くのグレー値をカバーする重要な勾配を含むこれらの３つの領域を伴う）、１又はそれ以上の領域が受け入れられなくなることが生じ得る。色成分のための制限されたワード長（例えば１０ビット）に起因して、（色マッピング関数の形状に依存する）どこかで、どこが厳し過ぎると判断されるかというバンディングがあるためである。
この領域は、例えばこれを見分けるグレーダにより識別され得る（グレーディング装置におけるＨＤＲ画像分析ソフトウェアにより潜在的に重要なエリアにポイントされることにより支援されてもよい）。バンディング検出部は、例えば拡張された領域のためにそれを計算することができる（潜在的にこの領域がどのルミナンスを有するか、及び、推定されたＪＮＤを考慮する）。各時間のジャンプ、多数の連続的に同等の色が存在する。これらは、斯様な計算からの（及び、典型的には工場実験における）値に基づいて許容可能なレベルを規定することができる。（例えばグレーダが粗く選択したものをより微細に分割することにより）斯様な領域を見つけた後のグレーディング装置は、その後、これに対応するルミナンスの範囲Ｌ＿ｕを粗く決定することができる。例えば、青空においてバンディングがあってもよく、その色は、Ｌ＿ｓｋｙ＿ｌｏｗとＬ＿ｓｋｙ＿ｈｉｇｈとの間のルミナンスを有する。ＬＤＲエンコーディングが画像をエンコードするためにより多くの値を有する場合に問題は軽減されるだろう。我々は、エンコーディング側で、Ｍ＿ＨＤＲ及び任意の変換が依然として極めて高精度であってもよいことを理解すべきである。しかしながら、これらのコードは存在しない。我々は、全ての必要とされるルミナンスに対して利用可能な１０のビットのみを有する。我々は、異なるイルミネーションの全ての他の画像領域を十分にエンコードすることも必要とする。しかしながら、幾つかのコードがＬ＿ｕに隣接するルミナンスを有する画像の領域から借りられ得る場合、とりわけこれらの領域の視覚的な質がこれらのコード範囲からの少しのコードを利用することによりほとんど低下しない場合、トリックが用いられ得る（典型的には、グレーダは、その結果に順応する単純な動作により、判断するだろう。あるいは、一致しないこの場合において、他の試みが試されるだろう。バンディングが依然として元のバンディングされたエリアのための高い場合により積極的になる。隣り合う領域は、依然としてより劣化され得る。あるいは、グレーダが隣り合う領域があまりに多く劣化し始めていることを示す場合、あまり積極的にはならない）。コードを再分配する単純な態様は、例えば局所的関数部分の線形又は非線形的変更である。唯一の送信された画像ＬＤＲ＿ｏによる問題は、空が例えば少しばかり暗くなってもよかったこと、及び、おそらく、この動作によりあまりにコントラストが強くなることである（また、隣接領域がいくらか暗すぎるかもしれない、これらのテクスチャの見た目は変えてもよかった等）。これは、小さな変化及びあまり重要でないシーンの場合にはあまり問題を含まないかもしれない、及び、困難なシーンにとって少し不都合かもしれない。これは、レガシーシステムが払わなければならないかもしれない価格である。これらは、ＬＤＲ＿ｏを直接レンダリングすることを除いて、受信したデータのいずれかにより絶対的に何も行うことができないためである。しかしながら、新たなレシーバは、（即ち適切な空のルミナンス等を有する）もともと意図されたものに非常に近いが少ないバンディングを有するＬＤＲの見た目を生成するために、ｌｕｍａを再分配するために使用される変換の逆を適用することができる。レシーバは、非常にスマートな分析を行う必要はない。斯様な技術的なトーンマッピング関数が利用可能であるということを知ることしか必要としない。及び、より良好なＬＤＲの見た目の画像ＬＤＲ＿ｕｌを取得するために唯一の送信されたＬＤＲ画像ＬＤＲ＿ｔの復元に適用する。多数の方法は、隣り合う領域のための良好な提案をもたらすように、グレーディング装置において適用されてもよい。例えば、（例えば空における量に等しい）ｌｕｍａの充分な量を有する領域及び複雑なテクスチャが決定されてもよい。単純な実施形態は、例えば、最も黒い黒色までの、バンディングされた領域の範囲より低い全てのコードを用いてもよい。

【0033】

第１の範囲のための追加のコードの量は、第１の幾何学形状領域のためのバンディング可視性基準に基づいて決定される。自動のアルゴリズムは、計画（例えば２０％の追加のコード）によってもよい。典型的には、人間のグレーダはこれを認識するだろう。アルゴリズムは、例えばこれらの領域の色彩を点滅させることにより、劣化させなければならなかった領域を強調してもよい。従って、グレーダは、復元されたＨＤＲ Ｒｅｃ＿ＨＤＲにおける充分な視覚的な画質のものかどうかを素早くチェックすることができる。

【0034】

最も実用的な実施形態において、過度なバンディングを示す第１の幾何学形状領域の識別は、典型的には、例えばバンディングされた領域に沿って波形のラインを走り書きすることにより、ユーザインタフェースユニット（１０５）を介して人間のグレーダにより最終的に実行される。復元された高ダイナミックレンジ画像（Ｒｅｃ＿ＨＤＲ）における第１の幾何学形状領域のバンディングの量、及び、復元された高ダイナミックレンジ画像（Ｒｅｃ＿ＨＤＲ）における第２の幾何学形状領域の復元の視覚的画質は、許容可能な又は許容不能として人間のグレーダにより判断される。許容可能という判断の場合には、再分配マッピング関数又はその逆の関数形状をエンコードする値は、画像信号においてエンコードされ、又は、許容不能という判断の場合には、これらのステップは、代替再分配マッピング関数をもたらすように異なるパラメータによって前と同じように行われる。例えば、１０％より多いコードが（おそらく、拡張された隣り合うｌｕｍａ範囲Ｌ＿ｕｕを犠牲にして）バンディングされた領域に割り当てられてもよい。

【0035】

高ダイナミックレンジ画像（Ｍ＿ＨＤＲ）をエンコードする方法の興味深い実施形態は、低ルミナンスダイナミックレンジ画像（ＬＤＲ＿ｏ）の画素色が、ｌｕｍａチャネル並びにｕ´及びｖ´色座標としてエンコードされることである。ｕ´及びｖ´色座標は、

【数3】

及び

【数4】

として計算される。Ｘ，Ｙ及びＺは、任意のＲＧＢ表現（即ち、ＣＩＥ１９７６（ｕ´，ｖ´）色度表現）のために導出可能であるデバイス非依存の１９３１ＣＩＥ色座標である。通常、レガシーの観点によれば、画像（とりわけＬＤＲ画像）は、ＹＣｒＣｂ画像としてエンコードされるだろう。しかしながら、（例えばインターネット伝送のための）任意のコーデックを変える場合、Ｙｕｖ成分平面として色成分をエンコードした方がよい。これは、も送信された画像の画質、及び、我々のシステムの種々の色変換を適用することの容易さにおいて幾つかの利点を有する（もちろん、レガシーのテレビは、これの良好な見た目の画像をもたらすことはできないだろう）。

【0036】

我々は、一般的に選ばれたｌｕｍａ定義を見出した（上記ステップの選ばれた完全なトーンマッピングストラテジにより規定され、ＬＤＲ＿ｏ又はＬＤＲ＿ｉにおけるｌｕｍａを最終的に取得する）。これらは、２つのｌｕｍａ非依存の色度座標、とりわけＣＩＥにより規格化されたｕ´，ｖ´座標と一緒に、規格の画像又はビデオ圧縮技術において用いられるべき良好な符号化であるだろう。例えばＨＥＶＣに類似の圧縮技術は、典型的には、サンプルのブロックのＤＣＴを行うことにより、少なくとも空間圧縮を適用するだろう。しかしながら、ビデオに関して、これらは、圧縮等に基づいて動作推定を行ってもよい。

【0037】

単純な実施形態において、色変換の機能的色変換動作のエンコーディングは、唯一の画像と関連付けられるか又は関連付け可能なメタデータにおいて以下のものを格納することにより、少しだけの単純なパラメータと通信され得る。
ａ）感度値（例えばＲＨＯ、又は、ＳＥＮＳと呼ばれるとともに以下に規定されるＲＨＯを規定する等価パラメータ、又は、ＲＨＯ値を決定するのを可能にするＲＨＯの任意の関数又は相関物）
ｂ）ガンマ値（ＧＡＭ）
ｃ）ｌｕｍａをマッピングする任意の関数の機能的形状を特徴付ける多数の値

【0038】

高ダイナミックレンジ画像（Ｍ＿ＨＤＲ）をエンコードする方法は、低ダイナミックレンジ画像（ＬＤＲ＿ｏ）の最大ｌｕｍａを、復元された高ダイナミックレンジ画像（Ｒｅｃ＿ＨＤＲ）における考えられる値の特定の値にマッピングするためのゲイン値を決定すること、及び、画像信号（Ｓ＿ｉｍ）においてそのゲイン値をエンコードすることを有する。これは、例えば比較的暗いショットのＬＤＲ画像が比較的明るく表される場合、ＬＤＲ画像から取得可能なＲｅｃ＿ＨＤＲ画像の更なるスケーリングのために有益である。即ち、ｌｕｍａを考えられるＬＤＲ ｌｕｍａｓの範囲の比較的高い値まで上げる。それでも、ＨＤＲ画像は、あまり明るくレンダリングされるべきでない。これは、あまり高過ぎないｌｕｍａによりこれをデコードすることにより最良に扱われる。

【0039】

高ダイナミックレンジ画像（Ｍ＿ＨＤＲ）をエンコードする方法は、低ダイナミックレンジ画像（ＬＤＲ＿ｏ）における色に対する高ダイナミックレンジ画像（Ｍ＿ＨＤＲ）の色の彩度変更ストラテジ又はその反対を決定すること、及び、信号（Ｓ＿ｉｍ）におけるメタデータにおけるパラメトリック値としてこの彩度変更ストラテジを符号化することを有する。典型的には、グレーダは、画像の彩度の影響を受けたいだろう。例えば、彩度マッピングストラテジー、及び／又は、ＬＤＲ＿ｏからのＲｅｃ＿ＨＤＲの彩度により、Ｍ＿ＨＤＲから取得されるＬＤＲ＿ｏの彩度を変えてもよい（例えば、第１のトーンマッピングは、ＬＤＲ＿ｏにおいて有した値での取得されたＲｅｃ＿ＨＤＲ色のｕ，ｖ色度を残し、その後、これらのＲｅｃ＿ＨＤＲ色の彩度を変える）。

【0040】

高ダイナミックレンジ画像（Ｍ＿ＨＤＲ）をエンコードする方法の幾つかの実施形態は、低ダイナミックレンジ画像（ＬＤＲ＿ｏ）を決定するために上記の色マッピングのいずれかを適用した後に、再分配されたｌｕｍａ、即ち少なくとも画像のｌｕｍａサブレンジ及び幾何学領域のための典型的に僅かに変更された値のｌｕｍａ（即ち、再分配されたｌｕｍａの低ダイナミックレンジ画像ＬＤＲ＿ｉ）を有する第２の低ダイナミックレンジ画像を決定するために更なる技術的トーンマッピングを適用すること（３０１）を有する。これは、少なくとも第２の低ダイナミックレンジ画像（ＬＤＲ＿ｉ）のより重要な領域をグレーダに対して保証する。例えば、これらは、典型的な意図された観察者により慎重に見られる。これらは、例えば大きく且つ明るいものであり、バンディングを起こしやすいためである。充分なｌｕｍａコードは、予め決められた誤差基準（最小バンディング量）より低い誤差を有する復元された高ダイナミックレンジ画像（Ｒｅｃ＿ＨＤＲ）を復元することを可能にするために、これらの領域におけるテクスチャを充分な精度でエンコードするために割り当てられ得る。

【0041】

幾つかの実施形態は、任意の変なトーンマッピングストラテジを選ばないことが重要である。とりわけ、数学的画素色値においてＭ＿ＨＤＲに近い良好な画質Ｒｅｃ＿ＨＤＲを取得したい場合、ＬＤＲ＿ｉにおいてアンダーサンプリングされたテクスチャがないことを保証することを必要とする。これは、均一な量子化の前の最終的なマッピングがどこでもあまり平坦にならないことを保証する場合に生じる。

【0042】

典型的には、これは、例えばＨＤＲ画像上のバンディング検出部又は斯様な任意の予め決められたＨＤＲ復元誤差基準のようなｌｕｍａ計数ストラテジ及び／又はＬＤＲ画像上のｌｕｍａ計数ストラテジにより行われてもよい。幾つかの実施形態において、前記基準は、人間のグレーダにより実行されてもよい。その存在は、よりスマートな将来の世代のレシーバにより適用されるべき、Ｓ＿ｉｍにおいて共同エンコードされた技術的リマッピングストラテジを有することにより理解され得る。

【0043】

本方法は、以下のものを有する高ダイナミックレンジ画像（Ｍ＿ＨＤＲ）をエンコードするように構成された画像エンコーダ（１００）において具現化されてもよい。
− 高ダイナミックレンジ画像を低ルミナンスダイナミックレンジ（ＬＤＲ＿ｏ）の画像に変換するように構成されたダイナミックレンジ変換ユニット（１０４）。ダイナミックレンジ変換ユニット（１０４）は、以下の処理順序で接続されるものを有する。
ａ）高ダイナミックレンジ画像を、［０，１］の範囲にあるｌｕｍａ軸に正規化し、正規化されたルミナンス（Ｙｎ＿ＨＤＲ）を出力するように構成された正規化部（６０１）。
ｂ）正規化されたルミナンスにガンマ関数を適用し、ガンマ変換されたルミナンス（ｘｇ）を出力するように構成されたガンマ変換ユニット（６０２）。
ｃ）ｌｕｍａ（ｖ）をもたらすよう、１．５〜５．０の間にある予め決められた量により０．１より低いこれらのガンマ変換されたルミナンスをブーストする第１のトーンマッピングを適用するように構成された第１のトーンマッピングユニット（６０３）。
ｄ）ｌｕｍａ（ｖ）を低ダイナミックレンジ画像（ＬＤＲ＿ｏ）の出力ｌｕｍａ（Ｙｎ＿ＬＤＲ）にマッピングする任意の関数を適用するように構成された任意のトーンマッピングユニット（６０４）。
及び、画像エンコーダ（１００）は、以下のものを更に有する。
− 低ダイナミックレンジ画像（ＬＤＲ＿ｏ）の色に対してデータ整削減変換を適用するように構成された画像圧縮部（１０８）。これらの色は、成分画像において構成される。削減変換は、少なくともＤＣＴ変換を隣り合う色成分値のブロックに適用し、低ルミナンスダイナミックレンジ画像の画素色の圧縮された符号化結果（ＬＤＲ＿ｃ）をもたらす。
− 圧縮された符号化結果（ＬＤＲ＿ｃ）を画像信号（Ｓ＿ｉｍ）において出力するように構成され、加えて、色変換の関数形状又はこれらの逆関数のための値をメタデータとしてエンコードする値を画像信号（Ｓ＿ｉｍ）において出力するように構成されたフォーマッタ（１１０）。メタデータは、レシーバが低ルミナンスダイナミックレンジ画像（ＬＤＲ＿ｏ）に基づいて高ダイナミックレンジ画像（Ｒｅｃ＿ＨＤＲ）を復元するのを可能にする。

【0044】

斯様なエンコーダの実際的な実施形態は、ガンマ変換ユニット（６０２）が１／（２．４）に等しいガンマ値を用いるものである。及び／又は、第１のトーンマッピングユニット（６０３）は、式

【数5】

により規定されるトーンマッピングを用いる。ＲＨＯは予め決められた値を有する。この値は、典型的には、マスターＨＤＲエンコーディングＭ＿ＨＤＲと関連付けられた基準ディスプレイ及び／又は意図された整備されたディスプレイのピーク輝度の関数である。

【0045】

画像エンコーダ（１００）は、低ダイナミックレンジ画像（ＬＤＲ＿ｏ）におけるｌｕｍａコードで最大のものを復元された高ダイナミックレンジ画像（Ｒｅｃ＿ＨＤＲ）の選ばれたｌｕｍａ値にマッピングすることを可能にするゲインを特定するように構成され、画像信号（Ｓ＿ｉｍ）におけるメタデータにおける値としてこのゲインを出力するように構成されたフォーマッタ（１１０）を有する。

【0046】

上記のエンコーダに係る請求項のいずれかに記載の画像エンコーダ（１００）は、技術的トーンマッピングユニット（１０６）を有する。これは、低ダイナミックレンジ画像（ＬＤＲ＿ｏ）のテクスチャ及び統計情報、とりわけ少なくとも１つの重要な幾何学形状領域を自動的に又は人間によるガイドにより決定するように構成される。少なくとも１つの重要な幾何学形状領域は、誤差、とりわけＲｅｃ＿ＨＤＲにおけるバンディングを復元する傾向にある。これに基づいて、低ダイナミックレンジ画像（ＬＤＲ＿ｏ）に対して変換として適用されるための第２のトーンマッピング（Ｆｆ１、Ｆｆ２...）を計算する。第２の低ダイナミックレンジ画像（ＬＤＲ＿ｉ）の少なくとも少し重要な誤差を起こしやすい領域のテクスチャを特徴付けるｌｕｍａコードの最小数（例えば１．３＊Ｌ＿ｕ）を有する第２の低ダイナミックレンジ画像（ＬＤＲ＿ｉ）をもたらす。これにより、予め決められた誤差基準より低い誤差を有する復元された高ダイナミックレンジ画像（Ｒｅｃ＿ＨＤＲ）を復元することを可能にする。エンコーディングの後にレシーバが我々のモードｉｉのシステムをミラーのように実装するのを可能にする必要な情報を通信することを可能にするために、以下のものを有する高ダイナミックレンジ画像信号（Ｓ＿ｉｍ）を送信（又は後に伝送のために格納）することが有益である。
− エンコードされた画素色を有する画素化された低ダイナミックレンジ画像（ＬＤＲ＿ｏ）
− 感度値（ＲＨＯ）
− ガンマ値（ＧＡＭ）
− ゲイン値（ＧＡＩ）
− 任意のトーンマッピング関数形状を特定する値のセット（Ｐ＿ＣＣ）

【0047】

そして、これらの値から、レシーバは、唯一の通信されたＬＤＲ画像（ＬＤＲ＿ｏ又はＬＤＲ＿ｉ）に適用されるべき全ての関数の関数形状を決定することができ、１００ｎｉｔのＬＤＲ画像より高いダイナミックレンジの任意の画像が必要とされるべきであり、計算されるべきである。

【0048】

とりわけ、Ｓ＿ｉｍは、コンテンツの人間の作者／グレーダにより要求される芸術的なＬＤＲグレーディングと技術的なＬＤＲとの間のマッピングのための技術的リマッピングストラテジ（Ｆｆ１、Ｆｆ２...）を符号化する値２０７を有してもよい。技術的なＬＤＲは、サンプリングされたときに、良好なＲｅｃ＿ＨＤＲ復元のための画像の全ての領域のための充分なｌｕｍａ、又は、自動画像分析ユニット又は人間により重要なものとして決定される少なくともこれらの領域を有する。

【0049】

とりわけ、これは有益である。非常に実際的に、とりわけ高ダイナミックレンジの画像がエンコードされたことを特定するインジケータ（ＩＮＤ）を画像信号Ｓ＿ｉｍにおいて有することにより、及び、ＬＤＲディスプレイ上のレンダリングのために更なるトーンマッピングの必要なく直接使用可能である低ダイナミックレンジの画像としてこれをエンコードする方法によって、レシーバが幾つかの（非常に）異なる考えられるＨＤＲ画像エンコーディングメカニズムのうちどれが用いられたかを素早く決定するためである。エンコーディングの種々の斯様な手段は、任意のレシーバがこれを理解する限り、合意され得る。

【0050】

メモリ製品は、例えば、我々の高ダイナミックレンジ画像信号（Ｓ＿ｉｍ）の任意の実施形態を格納するブルーレイディスクである。

【0051】

受信側で画像通信チェインを有するために、高ダイナミックレンジ画像信号（Ｓ＿ｉｍ）を受信するように構成された画像デコーダであるか又はこれを有する種々のリアリゼーションを有してもよく、及び、以下のものを有する。
− 画像信号（Ｓ＿ｉｍ）からの圧縮され画素化された低ダイナミックレンジ画像（ＬＤＲ＿ｃ）及びパラメータデータ（Ｐ）を取得するように構成されたデフォーマッタ（１５１）。
− 画素化された低ダイナミックレンジ画像（ＬＤＲ＿ｔ）を取得するために圧縮され画素化された低ダイナミックレンジ画像（ＬＤＲ＿ｃ）に対して少なくとも逆ＤＣＴを適用するように構成されたデコンププレッサ（１５２）。及び、低ダイナミックレンジ画像（ＬＤＲ＿ｔ）を復元された高ダイナミックレンジ画像（Ｒｅｃ＿ＨＤＲ）に変換するように構成されたダイナミックレンジ変換ユニット（１５３）。ダイナミックレンジ変換ユニット（１５３）は、処理順序において、以下のものを有する。
ａ）任意のトーンマッピングを適用するように設けた任意のトーンマッピングユニット（４０２）。パラメータは、パラメータデータ（Ｐ）において受信される（Ｐ＿ＣＣ）規定する。
ｂ）第１のトーンマッピングを規定する少なくとも１つの受信したパラメータ（ＲＨＯ）により規定されるマッピングを適用するように構成された第１のトーンマッピングユニット（４０３）。第１のトーンマッピングは、我々のエンコーダ又はエンコーディング方法の実施形態のいずれかによって前に決定されたものである。
ｃ）受信したガンマ値（ＧＡＭ）によりガンママッピングを適用するように構成されたガンマ変換ユニット（４０４）。

【0052】

このデコーダは、全ての典型的なレガシー、例えばＨＥＶＣ又は類似の圧縮された符号化結果を最初に元に戻すだろう。そして、逆の順序で種々のマッピングを適用するだろう（全ての実施形態において必要される全てのものが正確に逆の順序にあるわけではないことに留意されたい。例えばＹｕ´ｖ´において、最終結果が正確に又はおおよそ意図された色である限り、おそらく僅かに異なる数学的関数を伴って、逆の順序において直交するｌｕｍａ及び彩度処理を選択するかもしれない）。追加の処理ステップがあってもよいことに留意されたい。これは、受信側にのみ存在してもよい（例えば、画像は、Ｒｅｃ．２０２０のようなＲＧＢ表現においてエンコードされてもよいが、テレビ（例えばＤＣＩ−Ｐ３）により理解される他のフォーマットに変換される必要性があってもよく、ＴＶの実際のプライマリに更に変換されてもよい）。

【0053】

従って、画像デコーダ（１５０）は、低ダイナミックレンジ画像（ＬＤＲ＿ｔ）を復元された高ダイナミックレンジ画像（Ｒｅｃ＿ＨＤＲ）に変換するように構成されたダイナミックレンジ変換ユニット（１５３）を有するだろう。及び、典型的には、論理回路装置があってもよく、更なる色処理関数は、（例えば、どのディスプレイが現在接続されているか、及び、機能しているかに依存して）少なくともいつ何を行うかを規定する。

【0054】

画像デコーダの実際的な実施形態は、以下の形式の関数を適用するように構成された第１のトーンマッピングユニット（４０３）を有する。

【数6】

ｖは、画素ｌｕｍａであり、ＲＨＯは、パラメータデータ（Ｐ）において受信される実数値化された又は整数パラメータである。

【0055】

画像デコーダ（１５０）の有益な実施形態は、第２の低ダイナミックレンジ画像（ＬＤＲ＿ｕｌ）を取得するために、画像信号（Ｓ＿ｉｍ）において受信された更なるトーンマッピング（Ｆｆ１、Ｆｆ２...）を低ダイナミックレンジ画像（ＬＤＲ＿ｔ）に適用するように構成されたトーンリマッピングユニット（１５９）を有する。これは、少なくとも復元された高ダイナミックレンジ画像（Ｒｅｃ＿ＨＤＲ）の領域における低減されたバンディングを取得するための再分配されたｌｕｍａによって第２の低ダイナミックレンジ画像（ＬＤＲ＿ｉ）をもたらすエンコーダ方法５〜７のいずれかにより適用されるコード再分配アクションを反転させたものである。実際には、エンコーダは、必ずしも任意のエンコーダがｌｕｍａを再分配する特定の変換関数をどのようにもたらすかを必ずしも知る必要があるというわけではない。実質的に意図されたＬＤＲの見た目（ＬＤＲ＿ｕｌ）をもたらすように逆関数を適用することを必要とするだけである。

【0056】

デコーダの他の有益な実施形態は、ＬＤＲ画像のＹｕ´ｖ´エンコーディングを理解することができ、ＲＧＢ色表現においてＹｕ´ｖ´色表現を変換するように構成された色変換ユニット（１５５）を有する。トーンマッピングは、変換が行われる前に行われ得る。それ故、処理チェインの最後の部分に対するＲＧＢへの変換を残す。あるいは、代わりに、変換が最初に行われてもよく、等価な色処理がＲＧＢ信号上で行われてもよい。

【0057】

デコーダのうちいずれかに対応して、高ダイナミックレンジ画像信号（Ｓ＿ｉｍ）をデコードする対応する方法は、パラメータデータ（Ｐ）においてエンコードされた色変換を低ダイナミックレンジ画像（ＬＤＲ＿ｔ）に適用することにより、復元された高ダイナミックレンジ画像（Ｒｅｃ＿ＨＤＲ）を取得することを有する。とりわけ、高ダイナミックレンジ画像信号（Ｓ＿ｉｍ）をデコードする方法は、以下のステップを有する。画像信号（Ｓ＿ｉｍ）からのパラメータデータ（Ｐ）及び圧縮され画素化された低ダイナミックレンジ画像（ＬＤＲ＿ｃ）を取得するステップ。画素化された低ダイナミックレンジ画像（ＬＤＲ＿ｔ）を取得するために圧縮され画素化された低ダイナミックレンジ画像（ＬＤＲ＿ｃ）に少なくとも逆ＤＣＴ変換を適用することにより、圧縮され画素化された低ダイナミックレンジ画像（ＬＤＲ＿ｃ）を解凍するステップ。以下のものにより、低ダイナミックレンジ画像（ＬＤＲ＿ｔ）を復元された高ダイナミックレンジ画像（Ｒｅｃ＿ＨＤＲ）に変換するステップ。
ａ）任意のトーンマッピングを適用する。パラメータは、パラメータデータ（Ｐ）において受信される（Ｐ＿ＣＣ）を規定する。
ｂ）我々のエンコーダ又はエンコーディング方法の実施形態のいずれかにより前に決定された第１のトーンマッピングを規定する少なくとも１つの受信したパラメータ（ＲＨＯ）により規定されるマッピングを適用する。
ｃ）好ましくは２．４に等しい受信したガンマ値（ＧＡＭ）によりガンママッピングを適用する。
我々は、グレーダが、ＨＤＲシーンのＨＤＲ画像上のＬＤＲの見た目を、単純であるが依然として力強く最適化するのを可能にするシステムについて述べる。好ましくは、可能な限り少しの視覚的品質の犠牲しか払われない。しかしながら、ＬＤＲは、そのダイナミックレンジの制約に起因して何らかの最適化を必要としてもよいので、本システムは、グレーダが関心のあるシーンオブジェクト（即ち、このシーンにおける典型的に重要な特性オブジェクト）のマイクロコントラストを微調整するのを可能にする。これにより、何らかの輝度―質の犠牲が払われる必要がある場合に、シーンにおける主なオブジェクトよりもむしろ、背景における壁のような幾つかのあまり重要ではないオブジェクトの正確な見た目を犠牲にする。本発明は、信号において具現化される規定のパラメータのような種々の実施形態の中心的技術的要件を含むような、多くの他の（部分的な）手段において実現され得る。その多くのアプリケーションは、種々の考えられる信号について通信、使用、色変換等を行うようにもたらしてもよい。及び、種々のハードウェアコンポーネントを取り込むか、又は、消費者向け又はプロフェッショナル向けのシステムにおいて種々の方法を用いる種々の手段をもたらしてもよい。任意の成分は、もちろん、小さな成分において又はそれとして実現されてもよく、又は、その逆に、この成分のため主に機能する大きな装置又はシステムの中心として実現されてもよい。

【0058】

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

【図面の簡単な説明】

【0059】

【図1】画像通信技術における本発明によるエンコーダ及びデコーダの一実施形態の一例を概略的に示す。

【図2】本発明によるＨＤＲ画像信号Ｓ＿ｉｍがどのように見えるかについての一実施形を態概略的に示す。

【図3】技術的なＬＤＲグレーディングをどのように一般的に取得することができるかについて概略的に説明する。これは、幾つかの実施形態において、グレーダ又はコンテンツ製作者のじゃまをすることなく自動的にフードの下で起こり得る。これは、オブジェクトｌｕｍａのより良好なサンプリング、従って、Ｒｅｃ＿ＨＤＲのより良好な画質復元を可能にする。

【図4】本発明による考えられるデコーダの単純な概略的な説明である。

【図5】色を大幅に明るくする感度マッピング、加えてガンマ動作によって、組み合わせられた最初のＬＤＲグレーディングを行うための２×２の考えられる実施形態の曲線を示す。

【図6】エンコーダの考えられるダイナミックレンジ変換ユニットの単純な概略的な説明である。

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

【0060】

図１は、生成側の画像（又はビデオ）エンコーダ１００、及び、画像デコーダ１５０を有する、我々の発明を具現化する例示的な典型的なシステムを示している。我々は、マスターグレーディングされたＨＤＲの見た目の画像（Ｍ＿ＨＤＲ）を含むグレーディングシステムにおいてメモリ１０１が存在すると想定する。これらは、例えばＤａ Ｖｉｎｃｉのような色グレーディングソフトウェアにおける動画の現在既知の色グレーディング技術に従ってコンテンツ作者により望まれるようにグレーディングされている（類似の他のシステムは、我々の出願における教示から利益を享受されてもよい。例えば、Ｍ＿ＨＤＲは、例えばカメラ等のダイヤル上のカメラの見た目の曲線の調整の後に、カメラから直接もたらされてもよい）。このＭ＿ＨＤＲにおいて、例えば、ウインドウを介して光っている光の輝度は、これらの画素を意図されたレンダリングされるべきルミナンスＬ＿ｏｕｔ及び対応するｌｕｍａコードｖ＿ＨＤＲに与えることにより、［０，５０００］ｎｉｔの基準ディスプレイ上でとても楽しい見た目を与えるように選ばれてもよかった。多くの更なる光の効果は、他の色の最適化と同様に設計されてもよかった。Ｍ＿ＨＤＲは、我々のエンコーダ１００における画像入力１１５を介して入力される。及び、ＨＤＲ基準ディスプレイ１０２上に見られてもよい（例えば我々がＨＤＲエンコーディングのために提案する理論的な［０−５０００］ｎｉｔの基準ディスプレイの特性）。これは、グレーダがいつＬＤＲの見た目をもたらしたいかを意味する（これは、オブジェクトテクスチャだけを十分に正確にエンコードすべきではない。従って、受信側で、Ｍ＿ＨＤＲのかなり正確な復元Ｒｅｃ＿ＨＤＲが取得され得る。しかしながら、このＬＤＲの見た目も、ＬＤＲディスプレイ上のエンコードされたＨＤＲシーンを最適にレンダリングするのに適しているべきである）。グレーダは、ＬＤＲディスプレイ１０３上の技術的な制約の見た目が与えられたＬＤＲの見た目がＭ＿ＨＤＲと同様にいかに見えるかについて同時に比較することができ、及び、好みに従って望まれるＭ＿ＨＤＲから取得するための色マッピング関数を変えることにより最適化することができる。２つのディスプレイは、これらの異なる最適な表示環境にあってもよく、グレーダは、例えば壁により（例えば、これらを同時に見るためのそれらのそれぞれの窓開口部を伴う２つの囲まれた基準環境において、及び、グレーダが時間間隔の間にこれらのうち１つだけを見たい場合に閉じられ得るカーテンによって）切り離されるように見てもよい。グレーダは、ＨＤＲディスプレイ１０２上のＨＤＲの見た目の復元されたグレーディングをチェックしてもよい（例えば代わりにＲｅｃ＿ＨＤＲ及びＭ＿ＨＤＲを切り替えてもよい）。

【0061】

例えばガンマ又は感度値のような値を設定するためのチューニングホイール又は類似のスライダのようなグレーダ古典的制御を提供するユーザインタフェースユニット１０５によって、グレーダは、エンコーダの出力１１６を介して画像信号Ｓ＿ｉｍにおいて出力されるべき変換のパラメータによって、Ｍ＿ＨＤＲがどのようにＬＤＲの見た目の画像にマッピングされるべきかを規定する比色変換を行うことができる。これは、任意の画像伝送媒体１４０、例えば、通信ネットワーク、又は、ＢＤ若しくはソリッドステートメモリ等のような物理担体メモリに接続可能であってもよい。

【0062】

ＬＤＲの見た目は、ダイナミックレンジ変換ユニット１０４を介して生成される。これは、少なくとも画素色のｌｕｍａ上で、典型的には色度座標上で、比色変換を適用するように構成される。ｌｕｍａにより、我々は、物理的ルミナンス、又は精神視覚的モデルを介して輝度について最終的に変換可能である任意のエンコーディングを意味する（これは、画像がディスプレイ上にレンダリングされたときに観察者が見るだろう最終的な外観である）。等価な数学により、ｌｕｍａ変換は、ＲＧＢ成分上の対応する変換として直接適用され得ることに留意されたい。究極の目的が見た目における正しいオブジェクト輝度（外観）であるにもかかわらず、我々は、我々の技術的議論を、基準（例えば［０−５０００］）範囲、又は、この範囲により規定されるＸＹＺのようなデバイス非依存の色空間におけるルミナンスの決定に限定することができる。更に、我々は、色の任意の色彩の変換が１９７６ ＣＩＥ Ｌｕｖ空間のＵＣＳ平面において行われると想定するだろう。しかしながら、当業者は、他の第２の及び第３の色成分がどのように同様に用いられ得るかについて理解することができる。本発明の基本的成分は概して適用可能である。

【0063】

ＣＩＥＬｕｖは、

【数7】

及び

【数8】

として、（同様に何らかのＲＧＢから変換することができる）ＸＹＺからのｕ及びｖを規定する。

【0064】

我々は、簡単さのために、ＨＤＲ及びＬＤＲ全域（即ち、２つの画像のエンコーディング計算と関連付けられた理論的表示の全域）は、同じ３（又はそれ以上）のＲ，Ｇ，Ｂプライマリを有し、それ故、言わば５０００及び１００ｎｉｔのそれぞれの最大を１．０にスケーリングすることにより、正確に重複するよう配置され得るものと想定する。従って、ＨＤＲからＬＤＲへのトーンマッピングは、この単一のデバイスに依存するＲＧＢ全域の範囲内の正規化されたｌｕｍａ方向に沿った相対的変換になる。例えば、ＨＤＲの見た目におけるより暗い色をＬＤＲ及びＨＤＲディスプレイ上で同じにしたい場合、これは、同じ全域における相対的変換として、以下のようになる。５０００ｎｉｔで規定された鮮明度において、ＨＤＲ画像における斯様な色は、（例えば０．１より低い）小さなコードを有するので、我々は、（例えば０．３のまわりの値により）１００ｎｉｔのＬＤＲディスプレイ上で十分に可視になるようにこれらを輝かせることを必要とする。正確なマッピングは、ＬＤＲ画像及びＨＤＲ画像の双方のためのｌｕｍａの定義に依存するだろう。レガシーＬＤＲ画像及びビデオエンコーディングの［ガンマ２．２］の定義の一般化として、我々は、物理的ルミナンスからｌｕｍａコードへの任意のコード割当て関数マッピングを規定することができるためである（あるいは、反対に、典型的には、ＴＶエンジニアは、基準ディスプレイを規定することにより開始する。基準［０―５０００］ｎｉｔ範囲に加えて、例えば１０２４ ｌｕｍａがその基準範囲に沿ったレンダリング可能なルミナンスにどのようにマッピングされるかを示す何らかの基準ディスプレイＥＯＴＦ動作を有する）。我々は、ＯＥＴＦとしてのパワー１／（７．０）ガンマを用いることができるだけではない。我々は、画像のショットにおいてルミナンスの下側範囲とルミナンスの上側範囲との間にあるルミナンスが存在しない場合に、不連続なコード割当て関数を用いることさえできた。ｌｕｍａ非依存の色度（ｕ，ｖ）によるＹ´ｕｖ表現における動作は、色空間の無彩色及び色彩の方向において全体として独立して及び自由に動作するのを可能にすることにも留意されたい。

【0065】

技術を要する読者のための我々の説明をＨＤＲ−２−ＬＤＲの無彩色マッピングのみに限定すると、これらは、実際にはＨＤＲの見た目の画像の［０，１］ｌｕｍａからＬＤＲの見た目の画像の［０，１］ｌｕｍａへの任意のトーンマッピング関数として一般的に公式化され得る。これは、図２ａにおける例によって理解できる。

【0066】

斯様な関数を特定すると、我々は、全ての色（Ｙ＿Ｍ＿ＨＤＲ、ｕ，ｖ）に対してマッピングが行われることを想定するだろう。従って、非無彩色の色（ｕ＜＞ｕ＿ｗｐ，ｖ＜＞ｖ＿ｗｐ）に関して、（ｕ＿ｗｐ、ｖ＿ｗｐ）は、Ｄ６５のような選ばれたホワイトポイントの色度座標である。決定されたトーンマッピング関数２１０は、ＷＯ２０１４０５６６７９において更に詳細に教示されるように、その色のために達成可能な最大のルミナンスＬ＿ｍａｘ（ｕ，ｖ）に線形的にスケールされる。技術を要する読者は、斯様な処理がＹ´ｕｖ色エンコーディングにおいて適用される代わりにＲＧＢ色エンコーディングにおいてどのように同様に行われ得るかについて理解し得る。

【0067】

グレーダが斯様なトーンマッピング動作を特定すると、エンコーダは、Ｍ＿ＨＤＲにおける任意の考えられる色上に適用されるべき輝度ダイナミックレンジ変換のための充分な情報を有し、元の（圧縮されていない、場合により依然として浮動表現において量子化されていない）ＬＤＲの見た目ＬＤＲ＿ｏをもたらす。これから、任意の正確な又は近似の数学的変換は、エンコーダにより決定され得る。これは、レシーバがＬＤＲ＿ｏからＲｅｃ＿ＨＤＲへの反対の予測を行うのを可能にする。グレーダは、画像出力１１１を介して、斯様な画像が（例えばＨＤＭＩのような画像通信リンクを介して通信され得る画像信号に十分にフォーマット化された後に）基準（言わば１００ｎｉｔ、又は、将来においておそらく５００ｎｉｔ）のＬＤＲディスプレイ１０３上でどのように見えるかについてチェックすることができる。

【0068】

しかしながら、我々は、本発明において、トーンマッピングが任意の一般的な態様において構成されないが特定の態様において構成されるときにこれは有益であることを教示するだろう。（少ない）対応するパラメータは、画像信号Ｓ＿ｉｍにおける分離したメタデータとして有用にエンコードされる。これらは、例えば特定のＸ ｎｉｔのディスプレイのための最適な駆動画像を導出するために調整可能な間に、受信側で有利に用いられ得るためである。

【0069】

第１のパラメータとして、グレーダは、例えば感度をパラメータＳＥＮＳ又はＲＨＯを直接選ぶだろう。これは、フォトグラフィからの知られるＡＳＡ又はＩＳＯ値に直観的に類似する値になるだろう。及び、典型的には、ＬＤＲ画像がどれくらい明るく見えるか（とりわけ、Ｍ＿ＨＤＲの暗いオブジェクトの色がどれくらい上昇するか）を決定する。

【0070】

好ましい実施形態として、エンコーダは、良好な最初のＬＤＲの見た目を既に与えているＥＯＴＦ／ＯＥＴＦ関数を用い得る。ＥＯＴＦ関数は、

【数9】

のように規定される。

【0071】

この式は、言わば１０２４の考えられる値としての、画素色のｌｕｍａコード語のために利用可能なビットの量に基づいて、等距離に広がる［０，１］におけるｌｕｍａコードｖに対応するレンダリングされるべきＨＤＲルミナンスＬを規定する。Ｌｍは、Ｍ＿ＨＤＲ又はＲｅｃ−ＨＤＲの線形色／ルミナンス表現の基準ディスプレイのピーク輝度を示す選択可能な変数であり、これは、例えば５０００として固定され得る。例えば、グレーダは、典型的には、

【数10】

としてのｒｈｏに関連し得る感度を選択するためのダイヤルを有するだろう。

【0072】

暗い色の動作及び全体的な輝度を決定するＳＥＮＳ（ＲＨＯ）値と一緒に、グレーダは、考えられるＬＤＲ ｌｕｍａの範囲に沿ってオブジェクト／領域輝度を再割り当てする曲げパラメータとしてガンマ（ＧＡＭ）を共同調整することができる。もちろん、（有益な中間表現であってもよい）Ｍ＿ＨＤＲグレーディングの基準ＸＹＺ空間表現におけるルミナンスＬからＬＤＲの見た目のｖ ｌｕｍａ値にマッピングするとき、グレーダは、逆関数を規定するだろう。

【0073】

ＲＨＯ除算上の基本的な数学的計算を行うと、逆関数（ＯＥＴＦ）は、以下のように理解され得る。最初に、

【数11】

をもたらす１／（ＧＡＭ）を適用し、そして、

【数12】

を計算する。

【0074】

典型的には、エンコーダにおいて、画像分析ユニット１７７の種々の考えられる実施形態のうちの１つがあってもよい。このユニットは、人工知能によって画像における領域を解析するように構成されもよい。これらの領域のうちどれかが、とりわけモードｉｉのタイプの、ＨＤＲエンコーディングにおける特定の問題をもたらし得る。とりわけ、バンディングになりやすい領域、及び、十分に仕上げられた領域を識別してもよい。従って、これらは、色成分コード及び／又はｌｕｍａのより小さい量によってエンコードされ得る。幾つかのアプリケーションにおいて、このユニットは、任意の人間のグレーダの関与を伴うことなく最終のエンコーディング計画（例えばトランスコーダ）を自動的にもたらし得る。しかしながら、他のアプリケーションにおいて、これらを精査することができるように、例えばグレーダの注目下で領域をもたらしてもよい。もちろん、ユーザインタフェースとのインタラクションがあってもよい。例えば、グレーダは、特定の領域によって、又は、特定のテクスチャによって、バンディングを緩和したいことを示すことができる。そして、ユニット１７７は、斯様な領域及びそのｌｕｍａ範囲等を抽出することができる。

【0075】

図２において理解できるように、典型的にはメタデータ２０５におけるリザーブされたＬＵＴ空間における最終的なトーンマッピング関数をエンコードすることを決めることができるが、典型的には、ガンマメタデータフィールド２０３及び感度メタデータフィールド２０２のそれぞれにおけるガンマ値（例えば２．８）及び感度パラメータ（例えば２００のＩＳＯ）又はＲＨＯ値をエンコードするだろう。図２は、画像又はビデオ信号Ｓ＿ｉｍ（２００）がどのように見えるかを概略的に示している。当業者は、もちろん、多くのデジタルの変形、所与の既存の画像データコンテナ等において実際に規定され得ることを知るだろう。我々のエンコーダの実施形態は、画素色画像（２０１）の古典的な３つの成分のエンコーディングを用いる。これは、我々のグレーダにより最適化されたＬＤＲの見た目の画像であるだろう。このＬＤＲ画像ＬＤＲ＿ｏは、典型的には、ＪＰＥＧのような画像エンコーディングの規格化されたフォーマット又はＭＰＥＧ−ＨＥＶＣ、ＶＰ１等のような規格化されたビデオエンコーディングフォーマットに従って、古典的にＤＣＴエンコードされる、ランレングスエンコードされる、フォーマット化される等であるだろう。
技術を要する読者は、レガシーの（又は類似の将来の）符号化技術を再利用することができるように比色分析的にリフォーマットすることを理解するだろう。一般的な概念は本発明の部分であるためである。しかしながら、斯様な符号化のうちどれが実際に用いられるかはそれほど重要ではない。本発明の他の部分は、例えば少なくともシーンのＲｅｃ＿ＨＤＲの見た目を回復させるときにデータを解明するために必要なメタデータである（ＬＤＲの見た目は、理論的には更なるダイナミックレンジ処理を伴うことなく、Ｙ´ｕｖからデバイスに依存するＲＧＢ空間エンコーディングへの比色再定義マッピングだけにより、ＬＤＲディスプレイを駆動させるために直接用いられ得るためである）。

【0076】

更に、グレーダは、（ゲインメタデータフィールド２０４において共同エンコードされる）ＧＡＩＮ値を用いることができる。従って、関数は、濃青色マップ１．０〜１．０を必要としない。例えば、ゲインは、完全な範囲［０，１］に渡って規定されるＬＤＲ画像がＨＤＲディスプレイの［０，５０００］範囲の［０，１５００］サブレンジのみにどのようにマッピングされるべきかを示してもよい。反対に、用いられる可能性は低いが、使用されるＬＤＲ範囲を限定することも原理上考えられる。このゲインは、幾つかの画像をあまり明るくならないようにするために用いられ得る。これは、シーンが例えば霧の深いシーンであるかどうか、又は、ＬＤＲにおいてかなり明るくなるがＨＤＲにおいて暗い状態にとどまる必要がある暗い画像であるかどうかを想像することができる。

【0077】

これらの３つのパラメータ（ＲＨＯ，ＧＡＭ，ＧＡＩ）は、おおまかな全体的な輝度又は照明調整により、対応するＬＤＲの見た目の画像へのＭ＿ＨＤＲ画像の極めて有益な第１のマッピングを与える。これは、例えば最適なパラメータが放送の開始の前に正しく決定される実生活を放送するのに充分であり得る。映画製作者のようなより重要なユーザは、その見た目を介してより微調整された制御を望むかもしれない。これらは、曲線に曲げられて微細に配置される上記の"ｌｏｇｇａｍｍａ"のものよりも一般的なトーンマッピング関数を特定したいかもしれない。これは、例えば特定のオブジェクト（例えば顔）の平均的局所的輝度又はコントラストを全てのレンダリング可能なＬＤＲルミナンスの所望のサブレンジ（又はより正確に言うとこれらの対応するｌｕｍａ）まで上昇させ得る。あるいは、局所的傾斜の仕様は、ＬＤＲの見た目の画像における他の領域／オブジェクトの輝度位置及びコントラストを犠牲にして、画像における重要な領域のいくらかの関心のあるサブレンジＢＬにおける所望のコントラストを特定し得る。

【0078】

理解する重要なものは、我々のモードｉ（ＨＤＲの見た目）のシステムによって、グレーダが任意の斯様なマッピングを規定し得ることである。我々は、（復元ではないが、グレーダにより望まれる場合にはデータ破壊的に行われ得る）ＬＤＲの見た目の画像を導出することのみを必要とするためである。そのエンコーディングアプローチにおいて、我々は、画像信号Ｓ−ｉｍにおける唯一の画像としてエンコードされたＨＤＲの見た目の画像を有するためである。しかしながら、モードｉｉのシステムにおいて、我々は、二重の基準を満たすことを必要とする。一方では、我々は、良好な画質でＲｅｃ＿ＨＤＲ画像を復元することができることを必要とするが、他方では、我々は、グレーダが望むほとんどの全てではないＬＤＲの見た目を生成するための充分な自由度を望む（そして、例えば映画Sin City 2において理解され得るように、時々非常に創造的であり得る）。

【0079】

しかしながら、グレーダが好ましいトーンマッピング２１０によりたとえどんなグレーディングＬＤＲ＿ｏをもたらしたとしても、レガシーエンコーディングにおいて、これらの出力ＬＤＲ ｌｕｍａは、古典的な均一の量子化（及び、ＤＣＴ−ｉｎｇ）を介して進行することを理解するべきである。従って、我々は、これらの範囲の幾つかの部分に渡って平坦過ぎるマッピングを生成しないように注意すべきである（即ち、局所的導関数ｄｅｌｔａ＿ＬＤＲ＿ｏｕｔ／ｄｅｌｔａ＿ＨＤＲ−ｉｎは、あまり小さくなるべきではない。従って、ＬＤＲ ｌｕｍａコードの最小の必要とされる量は、その範囲ｄｅｌｔａ＿ＨＤＲ―ｉｎ又は対応するｄｅｌｔａ＿ＬＤＲ＿ｏｕｔに割り当てられる）。そうでなければ、ＬＤＲ−２−ＨＤＲトーンマッピングにおいてその範囲をブーストするときに、我々は、バンディング又は極端にコントラストが強い及び可視ＤＣＴアーチファクトのようなアーチファクトを見るためである。

【0080】

我々は、ユーザが任意のトーンマッピングの形状を変化させるために用いる局所的制御ポイントの安定性を伴う制御メカニズムを有することができた。しかしながら、これは、とりわけ厳しく実装される場合に、ユーザにとっては不快である（もちろん、システムは、グレーダが実際に変なマッピング曲線をもたらしたい場合に警告することができる。例えば、Ｎ曲線のような逆転は行われるべきでない）。

【0081】

有益な実施形態が図３に示される。これは、技術的トーンマッピングユニット１０６の動作を説明している。これは、第２のＬＤＲの見た目を決定するために用いられ得る。代わりに、ＬＤＲディスプレイを提供する必要があるよりスマートなレシーバによりＬＤＲ＿ｏに対して使用可能である。我々は、グレーダが所望の曲線を選択したと想定する。これは、適切なＬＤＲの見た目を与え、これは、図３における実曲線である。トーンマッピング曲線が良好でない場合、これは、平坦過ぎる少なくとも１つの範囲が存在することを意味するだろう。我々は、ここで、最も明るいＨＤＲの部分Ｒ−ｕがＬＤＲ画素であると想定する。例を挙げるならばシーンの空である。我々は、ＬＤＲにおけるその範囲Ｌ＿ｕを伸ばすことができることを必要とする。従って、グレーダのために可能な限り非破壊的（見た目をほとんど変えない）態様において。いくらかのより多くのｌｕｍａコードが割り当てられ得る。

【0082】

これは、よりざらつきのあるオブジェクトを含む隣り合う範囲Ｌ＿ｕｕがあるときに行われ得る。

【0083】

これは、所望のＬＤＲの見た目を得るための我々の見た目の曲線は、同時に、種々のＨＤＲ領域テクスチャを忠実にエンコードするために利用可能なｌｕｍａコードの量子化又は数を決定するという難しい問題からの方法である（シーンにおける全てのテクスチャの充分な誠実な特徴付けは、ＨＤＲエンコーディングにおけるエンコーディングの質の主目的である）。１０２４の異なるｌｕｍａ／グレーレベル（及び、何百万ものコード）を有することは、適切に行われる場合、人間の視野のための全てのテクスチャをうまくエンコードするのに十分であるべきである。複雑なオブジェクトは、比較的少ないコードによってエンコードされ得る。目は、第１に、粗いテクスチャパターン、及び、画素色のそれほど正確な値ではないものを見るためである。特定の好適ではない状況において、少なすぎるコードしか用いなかった輝度を有する場合に問題を有する。

【0084】

従って、曲線を適合させるときに２つのものが存在する。技術的トーンマッピングユニット１０６は、典型的には、ｌｕｍａ軸上において十分に局所的であることを必要としたときに、前記の適合を保つ。従って、我々は、あまり多くのオブジェクト色のｌｕｍａを混乱させない（例えば、この場合も同様に、重要な暗い領域を暗くし過ぎることを回避する）。この例となるシーンの画質基準は、我々は、良好なＬＤＲの見た目を得るために暗い色を輝かせることを必要とすることであり得る。従って、明るい色における局所的変化は、いかなる手法においてもそれを妨害しないだろう。従って、トーンマッピングユニット１０６は、典型的には、問題のエリアの周辺でいくらかの局所的ｌｕｍａサブレンジにおいてコードを再分配し、点線である、これのための対応する適応曲線を決定するだろう（この曲線は、その２つの画像領域のエンコーディング部分において、多少元の曲線の形状に追従していてもよい。即ち、空のｌｕｍａのための放物線状に曲がっている局所的形状があった場合、典型的には、空気のためのスケーリングされた、より大きな類似の曲がっている放物線状のセグメントを用い得る。しかしながら、これは、絶対に必要であるというわけではない。コードの精度だけが基準であるためである）。

【0085】

従って、我々は、Ｒｅｃ＿ＨＤＲの青空勾配を忠実にエンコードするための十分なコードを有するために空領域の輝度範囲を多少広げることを必要とする。しかしながら、我々がそれをどれくらい行う必要があるか、及び、調整範囲Ｒ＿Ａｄｊをどれくらい広げるべきか。

【0086】

これは、多数のものに依存する。もちろん、Ｒ＿ａｄｊは、問題がある領域を覆うべきである。これは、典型的には、空における勾配のような比較的均一な領域のような、比較的視覚的に単純な領域であるだろう（この青い勾配は、ＬＤＲ ｌｕｍａ範囲に沿ってどこかに存在するだろう）。一方、我々は、十分に粗くされている隣り合う領域を必要としなければならない。ありそうにない状況において、隣り合う領域は、更に他の滑らかな勾配である（これは、人工的勾配テスト画像のような合成画像において生じ得る。この場合において、我々は、我々が得ることができるいかなる最適なｌｕｍａ割り当てにも満足しなければならないだろう。しかしながら、これは、典型的には、自然な画像において発生しない）。Ｒ＿ａｄｊは、比較的大きくなってもよい。ざらつきのある範囲をすぐに発生させる通常の状況において、我々は、同じ大きさの範囲Ｌ＿ｕｕによりＬ＿ｕを拡張することができる。これは、我々がどれくらいのコードを追加しなければならないか、及び、テクスチャパターンの複雑さに依存する。３つのコードのみを空に追加することを必要とする場合、Ｌ＿ｕｕにおける３つのｌｕｍａコードを保存することを必要とする。十分にざらつきがある場合、ａｙ１０−１５ｌｕｍａの範囲に渡って、グレーダ又は観察者が見つけるか又は見つけ得る許容可能なものに依存して、これを行うことができる。

【0087】

本装置は、それのための表を含み得る。

【0088】

従って、見た目の曲線に依存するｌｕｍａ符号化に関する不快な問題が主としてここで解決される。一方、隣り合う暗いオブジェクトをあまり激しく暗くしない。我々の空の範囲Ｌ＿ｕを拡張させることにより、上側範囲上でＬ＿ｕｕの色を少しだけシフトするためである。しかしながら、主に、少ししかサンプリングされない、Ｌ＿ｕｕの下側部分を同じに保つ。これは、視覚的に顕著な問題ではない。テクスチャは、それほど多くのコードを必要としないためである。空の広げられた範囲は、少しだけ最適状態に及ばないかもしれない。しかしながら、通常、実際に問題になるべきではない。我々は、代わりに、向上した画質Ｒｅｃ＿ＨＤＲを得る。しかしながら、この全ては、例えば如何なる処理も行い得ないレシーバにより、受信側において任意の反作用を利用しない場合にのみ、静的である。デコーダにおいて、トーンリマッピングユニット１５９における事前補正ストラテジを行うことができるためである。そして、これは、ｌｕｍａ割り当てを、グレーダの芸術的な意図の懸念の外の単なる技術的な事項にするだろう。トーンリマッピングユニット１５９は、例えばＬＤＲディスプレイを駆動させるために生ずる意図されたＬＤＲの見た目（ＬＤＲ＿ｕｌ）を用いる前に、前と同じように、圧縮への局所的伸長のための補正を適用するだろう。従って、空の例において、Ｌ＿ｕの空の下側制限を、隣り合う範囲Ｌ＿ｕｕにおけるオブジェクトの輝度まで下に広げた（これにより、これらのオブジェクトを暗くする）場合、デコーダ１５０のトーンリマッピングユニット１５９は、補正として３０１の逆マッピングを適用するだろう。これは、視覚的に、空の範囲が前と同じようにその元のｌｕｍａ範囲Ｌ＿ｕを有することを意味する。及び、ＬＤＲディスプレイ上にレンダリングされるとき、正しいルミナンス範囲は依然としてより高い精度を有する。より多くのテクスチャエンコーディングｌｕｍａコードが割り当てられたためである。同様に、ＬＤＲ＿ｕｌの見た目において、Ｌ＿ｕｕにおける隣り合う輝度を有するオブジェクトは、正しい暗くない輝度も有するだろう。及び、コードの低減された量のため、精度的にのみ異なる。当業者は、この技術が、グレーダの意図されたＬＤＲの見た目ＬＤＲ＿ｕｌを保つ一方で、常に、種々の他の考えられる状況において、必要な場合、画像のこれらの領域における符号化精度をどのように向上させ得るかを理解することができる。トーンリマッピングユニット１５９が行う必要がある唯一のものは、例えばＬＵＴによって、デコードされた技術的なＬＤＲ＿ｔにトーンマッピングストラテジを適用することである。これは、信号Ｓ＿ｉｍにおいて共同エンコードされ得る（あるいは、トーンマッピングが、例えば線形セグメントを区切る、例えば制御ポイントの制限されたセットから導出され得る場合に部分的にエンコードされる）。それ故、Ｓ＿ｉｍにおけるこの技術的調整関数（Ｆｆ１，Ｆｆ２...）を別々にエンコードすることが有利である理由は明らかであるべきである。生成側で決定され、グレーダにより受け入れられ、受信側に通信されると、より望ましいＬＤＲの見た目ＬＤＲ＿ｕｌをもたらすようにデコーダにより用いられ得るためである。

【0089】

上記を可能にするエンコーダ実施形態の２つのカテゴリが主として存在するだろう。１つは、全ての処理を主として自動的に行い、ユーザを含む必要はない。平滑性及びテクスチャ検出部は、種々の領域を自動的に分類し、空における勾配パターン、及び、隣接して位置された（即ち、Ｌ＿ｕより低く及び／又は高く配置されたｌｕｍａ範囲上の）他のざらつきのあるオブジェクトを識別するだろう。種々のテクスチャキャラクタライザは、テクスチャの複雑性（例えば、微細な粒度、絡み合っているグレー値の量等）を決定し、そこから、より少ないエンコーディングｌｕｍａをもたらす視覚的に顕著な混乱がどのようになるかを決定するために搭載されてもよい。そこから、必要とされるＬ＿ｕｕ範囲をもたらす。述べられたように、これらの優先度は、Ｌ＿ｕｕを機能的に決定する式において又はＬＵＴによって予め組み込まれてもよい。また、幾つかの実施形態において、ＤＣＴ又は他の圧縮エミュレータが存在してもよい。例えば、これは、Ｒ＿ａｄｊのための種々の選択及び機能的なトーンマッピング摂動形状３０１の下で生ずる解凍されたＬＤＲ画像ＬＤＲ＿ｄを計算する。及び、バンディング及び／又は他の圧縮アーチファクトの（通常の表示範囲、ディスプレイサイズ、周囲輝度等における）典型的な可視性のための尺度を計算する。テクスチャ分析ユニット１１７は、これのために存在してもよい。これは、典型的には、元の（ＬＤＲ＿ｏ）及びエンコードされたＬＤＲ＿ｃにおける、テクスチャ及びとりわけこれらの視覚的影響を分析するように構成される。実際には、そのデコーディングＬＤＲ＿ｄは、最後に受信側に存在するだろう。とりわけ、ＬＤＲ−２−ＨＤＲ色マッピングユニット１１８によるＨＤＲへのリマッピングは、必要に応じて、グレーダが視覚的影響をチェックするのを可能にするために用いられてもよい。グレーダがＲｅｃ＿ＨＤＲとしてのこのＭ＿ＨＤＲの復元可能性をチェックしたい場合、ＨＤＲ画像出力１１９を介して、ＨＤＲディスプレイ１０２上でこれらを時間的に例えば切り換えることができる。実際には、デコーダは、ＬＤＲの種々のバージョンをチェックすることができる（別々に示されたが、もちろん、これらは、１つだけの出力に内部的に送られ得る）幾つかの出力１１１，１１２，１１３，１１４を有してもよい。

【0090】

技術的再グレーディングを伴うエンコーダの第２のカテゴリは、人間のグレーダを直接含んでもよい。自動化アルゴリズムの質をチェックしている場合、（即ち、典型的には半自動的に）結果に影響するためのオプションを有してもよい。これは、グレーダのために簡素であるべきである。見た目の芸術的な決定とより関与したいかもしれないためである（即ち、圧縮アーチファクトのような技術的問題というよりはむしろオブジェクトｌｕｍａの配置。これを見たい場合、及び、画像通信ラインの下で１又はそれ以上の典型的な及び承認されたシナリオをチェックするにもかかわらず、もちろんより厳しいアーチファクトを有し得る更なる圧縮があってもよい）。

【0091】

これらのエンコーダの実施形態において、ユーザインタフェースユニット１０５は、典型的には、グレーダが特に問題のエリアである幾何学画像エリアを特定するのを可能にするだろう。例えば、空に渡って走り書きしてもよい。そして、ヒストグラム分析及びテクスチャ分析ユニットは、これらの分析及び技術的更新部分のトーンマッピング曲線の決定を行うとき、画像のこの部分上にフォーカスするだろう。例えば、これらは、グレーダが満足するまで、より多くのｌｕｍａコードを一度に空に追加するストラテジを連続的に提案してもよい。例えば、トーンマッピングユニット１０６の一実施形態のアルゴリズムは、例えばｋ＝１．５により、勾配（バンディングに敏感な）オブジェクトのこの範囲を乗算してもよく、ざらつきのある画像領域の隣接範囲を選択してもよく、及び、これをＬ＿ｕｕ−１．５＊Ｌ＿ｕに圧縮してもよい。即ち、２つの領域におけるコードの任意の線形又は曲線再分配が用いられ得る。Ｌ＿ｕｕは、少なくとも例えば３＊Ｌ＿ｕになるように選択されてもよい。これらの値は、典型的には、代表的な画像のセットに基づいて装置設計者により最適化される。装置による計画が良好である場合、グレーダはこれを受け入れ、エンコーダにＳ＿ｉｍにおける対応するパラメータを格納させる。あるいは、そうでなければ、新たな繰り返しが、例えばｋ＝１．１＊１．５により開始される。

【0092】

摂動３０１は、最終的なトーンマッピングをもたらすだろう。これは、最終的な技術的グレーディングＬＤＲ＿ｉに対応する。これは、我々のモードｉｉのＨＤＲエンコーディングシステムによる更なるフォーマッティングの後に通信システムに送信されるＬＤＲの見た目であるだろう。及び、これは、グレーダがＬＤＲの見た目として望むものに主として対応する。グレーダ関与の利点は、少なくとも最小限の関与により、どの領域が意味的に関連しているかを示すことができるということである。統計的テクスチャアナライザは、少ないｌｕｍａ（即ち少ない画素）が例えば屋内の部屋の暗いｌｕｍａと日当りのよい屋外の明るいｌｕｍａとの間の領域に実際に存在しないことを決定してもよい。それ故、少ないコードを適用するリマッピングストラテジを適用することを決める（デコーダリマッパ−１５９は、所望のＬＤＲの見た目を任意に復元することができる場合において、強い技術的な変形曲線を用いるかもしれない。これは、ＬＤＲ＿ｉエンコーディングから全体的にほとんど用いられていないサブレンジをほとんど切り取り、これにより、ＬＤＲ＿ｉ ｌｕｍａ値における直接隣り合うものを屋内及び屋外のサブレンジにする）。しかしながら、この小さな領域において偶然現れるオブジェクトのように何とか強調された誰かの顔又はオブジェクトのような重要なオブジェクトがある場合、グレーダは、これの反対に作用してもよい。幾つかの実用的な実施形態が考えられる。例えば、この領域周辺で矩形を走り書きしてもよい。そして、その領域のために用いられるｌｕｍａコードの量を増大させるダイヤルをオンにする。技術を要する読者は、画像又はショットにおいて重要な領域又はオブジェクトを選択し、どのようにｌｕｍａｓによってエンコードされるべきかを示すための種々の他のユーザインタフェース手段があることを理解するだろう。グレーダは変更曲線３０１自体の形状を描くか又はこれに影響する。

【0093】

我々のモードｉｉのシステムの残りは以下の通りである。オプションとして、ダイナミックレンジ変換ユニットは、色彩度処理を行ってもよい（例えば、彩度は暗くなるとともに減少し、逆もまた同じである。グレーダは彩度を補正したいかもしれない。これは、ｌｕｍａトーンマッピングのため、多少不適切になる）。良好な実用的な例示的な実施形態は、非情報破壊的タイプの一般的な彩度関数によって機能する。これにより、この彩度関数がどこも平坦過ぎないことを意味する。従って、反転されてもよい。しかしながら、幾つかの実施形態において、彩度関数は、ＬＤＲ−２−ＨＤＲアップグレーディングにおいて適用されることのみを必要とし得る。そして、これはより自由であってもよい。図３において、ｓ＿ｉｎからｓ＿ｏｕｔへの滑らかな彩度が示されている。これは、信号Ｓ＿ｉｍにおけるＬＵＴにおける多数の値Ｓ１，Ｓ２，Ｓ３によってエンコードされ得る。これらは、等距離のｓ＿ｉｎ値のためのｓ＿ｏｕｔ値であってもよい（所望の曲線がデコーダにおいてかなり滑らかに回復され得る十分な量）。しかしながら、これは、例えば関数形状制御ポイントであってもよい。不飽和化関数は、例えば、（ｓ＿ｉｎ対ｓ＿ｏｕｔのプロット上の）４５度より小さな傾斜を有するラインとしてエンコードされてもよい。斯様な不飽和の場合において、画像信号は、メタデータにおける乗数のための浮動値又は整数を有し得る。我々は、説明する例において、ｓ＿ｏｕｔがＨＤＲ画像の彩度であるものと想定した。我々は、彩度を増大させるためにシーンの暗くされたより暗い色の彩度をブーストすることを必要とする。しかしながら、当業者は、同じ構造的エンコーディングの観点で異なる処理変形が存在し得ることを理解し得る。我々は、説明の簡単さのために、例えば動作ｓ＿ｏｕｔ＝ｓ＿ｉｎ＋ＭＳ（ｓ＿ｉｎ）＊ｓ＿ｉｎを実行し得るｌｕｍａに関わらず、彩度がｕｖ空間において実行されることを想定するだろう。そして、ＭＳ（ｓ＿ｉｎ）は、図２ｂにおいて見られ、ＬＵＴ ２０６においてエンコードされる関数から検索可能な乗法的値である。これは、ホワイトポイントと比較される色相方向における彩度ベクトルを伸ばす。説明を簡単にするため、我々は、周辺の（及び１．０として符号化された）最大の彩度を有する円柱形のものにおいてｕｖ空間を規定したと想定する。もちろん、当業者は、他の比色定義における我々の彩度ストラテジを両方ともエンコードすることができることを理解するだろう。あるいは、定義が例えば円柱形のＹ´ｕｖ空間において与えられると、デコーダハードウェア又はソフトウェアの設計者は、ＲＧＢベースのＹＣｒＣｂ空間等のような他の色空間においてそれを実際に同等に実行するように選択することができる。グレーダは、Ｓ＿ｉｍにおいてｌｕｍａに依存する彩度ストラテジ（即ち、彩度を変える関数）を決定及びエンコードすることができる。乗算部は、処理された色のルミナンスによって変化する。基本的に、Ｓ＿ｉｍのより高度な実施形態は、彩度エンコーディング構造を有するだろう。これは、例えばウェブベースの定義であってもよい。これは、多数の鍵となる色相（例えば６：ＲＧＢＣＹＭ）に関して、ｌｕｍａ：ＭＳ（Ｙ´）に渡って規定された乗算関数を有する。２０６に類似する値の６つのＬＵＴとしてエンコードされ得るものから、受信側において、デコーダは、補間により全域における全ての色のための彩度ストラテジを決定することができる。より複雑なストラテジは、半径方向における彩度の変動性を取り込みさえしてもよい。これは、（図２ｂにおける理解されるものと同様であるが、全域におけるｌｕｍａの高さに渡って可変である）これらの関数を単純にパラメータ的に、例えば、オフセット、ガンマ、ゲイン関数として決定することにより容易なエンコーダになり得る。この場合、以下のものを有するだろう。鍵となる色相のためのｓ＿ｏｕｔ＝ｓ＿ｉｎ＋Ｆ（ｓ＿ｉｎ，Ｙ´）。例えば３パラメータ関数形状制御の場合において、例えばＹ´に渡って変化するよう彩度＿ガンマパラメータのｌｕｍａ動作を特定する３ｘ６ＬＵＴ又は色相のための６つのＬＵＴとしてＳ＿ｉｍにおいてこれをエンコードしてもよい。しかしながら、単一の乗法的値は各位置でエンコードされない。しかし、全域における考えられるｌｕｍａをサンプリングする多数の位置ｉに渡って連続的に三つ組みｓａｔ＿ｏｆｆｓｅｔ（Ｙ´＿ｉ）、ｓａｔ＿ｇａｉｎ（Ｙ ´＿ｉ）、ｓａｔ＿ｇａｍｍａ（Ｙ´＿ｉ）］＿ＬＵＴ＿ｏｆ＿ｙｅｌｌｏｗ。

【0094】

エンコーダ（及び対応するデコーダ）の幾つかの実施形態において、画素の色特性のためのｕ´ｖ´へのオプショナルな変換がある。我々は、ここで説明するだろう（しかしながら、他の実施形態は、例えばＹＣｒＣｂのためのＲ´Ｇ´Ｂ´等において代わりに又は追加的に直接エンコードしてもよい。及び、オプショナルなユニット１０７さえ内部に有さない。Ｙｕ´ｖ´処理は、等価な線形ＲＧＢ処理として数学的に書き直され得る）。

【0095】

（例えば、ＲＧＢ空間又はＸＹＺ等において）正しいＬＤＲの見た目を生成するためにダイナミックレンジ変換に適用した場合、Ｙ´ｕｖ空間におけるマッピングを行わないと仮定すると、例となる説明の実施形態の色変換ユニット１０７は、ｌｕｍａ Ｙ´によってｕ´ｖ´表現への変換を行うだろう。色表現は、上記の式毎に、我々の全体のトーンマッピング関数（即ち、中間ＬＤＲ画像ＬＤＲ＿ｉのｌｕｍａ）及び、ｕ，ｖにより決定される。我々は、ユニット１０７において比色変換を行うことができた。これは、異なるデバイスに依存するＲＧＢ又はマルチプライマリ空間が想定されるときに、色を条件付ける。例えば、我々のＭ＿ＨＤＲがより小さなＲＧＢ三角形によってエンコードされるがＬＤＲが広い全域ディスプレイのためのものである場合、グレーダは、多くの場合ものが周辺にあるにもかかわらず彩度ブーストストラテジを予め規定してもよい。この場合において、ユニット１０７は、色彩全域マッピングを実装してもよい。

【0096】

最終的に、生ずるＬＤＲ＿ｕｖは、古典的ＬＤＲ画像又はビデオ圧縮器１０８（即ち、典型的にはＤＣＴ又はウェーブレット変換等）によってエンコードされる。

【0097】

この圧縮された画像ＬＤＲ＿ｃは、フォーマッタ１１６に送信される。これは、受信側で適切に利用可能にするために、規格化されたフォーマットに従って、適用されたマッピング関数上のメタデータを追加する。即ち、このフォーマッタは、感度値（ＲＨＯ又は代わりにＳＥＮＳ）、パラメータ２０５を典型的には値（Ｆ１，Ｆ２...）のＬＵＴとして規定する関数を有する（更なる将来において幾つかのエンコーダがそれ自体いくらかの微調整を行うのに十分スマートであるかもしれないにもかかわらず）人間のグレーダにより典型的に決定されるＬＤＲの見た目を微調整するための更なるトーンマッピング、彩度エンコーディング２０６、例えば、マルチリニア関数等を規定するパラメータのセットを追加する。

【0098】

技術的な理由のための更なるトーンマッピングは、典型的には、好ましくは整数又は現実の値２０７のセットとして、画像又はビデオ信号Ｓ＿ｉｍにおいて別々に格納される。これは、例えば２５６ポイント又は１０２４ポイントのＬＵＴを格納するために用いられ得る。

【0099】

符号化されたＬＤＲ＿ｃは、前と同じように、ＬＤＲ＿ｄにデコードされ得る。そして、色マッピングユニット１１８によりアップグレードされ得る。従って、グレーダは、画像出力１１９を介して、復元されたＨＤＲ Ｒｅｃ＿ＨＤＲが受信側でどのように見えるかを確認することができる。グレーダが要求する場合、例えば強圧縮に対する幾つかの典型的な圧縮設定の影響を試験することさえできる。ここで述べられたデコーダは、再符号化ストラテジにおいて用いられ得る。グレーディングの見た目は、事前に準備されてもよいが、例えば、低画質高圧縮のＬＤＲバージョンは、いくらかの特定の画像／ビデオ通信アプリケーションのために再決定される。その二次グレーダは、パラメータを再調整さえしてもよい。利用可能な元のＭ＿ＨＤＲを有するかどうかに依存して、例えば、（例えば、モバイルフォン観察者に提供する）新たなより適切に調整されたＬＤＲの見た目を実現するためにダウングレーディング関数を再決定してもよい。実際には、Ｍ＿ＨＤＲの代わりに利用可能な良好なＲｅｃ＿ＨＤＲのみを有するときにそれを行いさえしてもよい。ｌｕｍａコードをより適切に割り当てるための技術的なグレーディング部分の分割は、斯様なシナリオに対して極めて有用である。ＬＤＲ＿ｏへのマッピング関数（及び、その対応する近い復元ＬＤＲ＿ｕｌ）は、実際の芸術的なＬＤＲの見た目を決定するので、これらは、コンテンツの最初の製造時に又は一次グレーダにより決定され得る。しかしながら、エンコーダは、二次グレーダの関与によって、３０１のような小さな変形及び対応するＬＤＲ＿ｉ（又はＬＤＲ＿ｔ）、及びＳ＿ｉｍにおける現実の又は整数値２０７のセットにおける符号化されたメタデータＦｆ１，Ｆｆ２を有する技術的なマッピングを依然として自動的に又は半自動的に決定することができる。これは、もちろん、異なる技術的制約（例えばビットの量（例えばｌｕｍａチャネルのための８ビットのみ））の間で異なってもよい。

【0100】

デコーダ１５０は、例えばこの説明のように、ディスプレイ１６０又はテレビに接続可能なセットトップボックス又はコンピュータにおけるＩＣであってもよい（従って、我々がデコーダを言うときには、我々は、"ＵＳＢスティック上のセットトップボックス"又はハードディスク及び光ディスク読み取り装置を有するセットトップボックスのような本発明から実現する及び利益を与える任意の大きな装置のようなこれの任意の小さなリアリゼーションをカバーすることを意図する。エンコーダは、小さなデバイスから大きなグレーディングシステム等までの何らかのものであり得る）。しかしながら、もちろん、テレビは、処理能力のないモニタでなくてもよいが、それ自身のＩＣにおいてこのデコーディング技術の全てを含む。ディスプレイ１６０は、ＬＤＲディスプレイ又はＨＤＲディスプレイ、あるいは、基本的には、例えばポータブルマルチメディアデバイス又はプロフェッショナルシネマプロジェクタへのワイヤレスストリーミングのような画像出力１５７を介して任意の画像通信技術を介して接続される任意のディスプレイであってもよい。

【0101】

デコーダは、画像入力１５８を介して我々のフォーマットされたＳ＿ｉｍを得る。デフォーマッタ１５１は、古典的なＪＰＥＧのような又はＭＰＥＧのような解凍部１５２及び、メタデータからのパラメータＰ（例えば、感度設定１０００、及び、トーンマッピング又は彩度マッピングの機能的形状を復元するために用いられ得る幾つかの値）により解凍するために画像ＬＤＲ＿ｃ（図２におけるＩＭＧ）において分割するだろう。オプションとして、デコーダにトーンリマッピングユニット１５９がある。この技術的なリマッピングは、通常グレーダが意図したＬＤＲの見た目ＬＤＲ＿ｕｌの厳しい変形ではないので、幾つかのデコーダはこれを無視しても差し支えない。しかしながら、完全にＨＤＲに準拠するデコーダは、（ＬＤＲ＿ｏの近似値である）正しいＬＤＲの見た目ＬＤＲ＿ｕｌに達するよう、２０７のＦｆ値において符号化される技術的な再補正ストラテジを適用するために、このユニット１５９を用いるべきである。この補正されたＬＤＲ画像（ＬＤＲ＿ｕｌ）は、更なるディスプレイ色調整ユニット１５４に進む。このユニット１５４は、特定の言わば１３００ｎｉｔの広さの全域ディスプレイのための必要とされる最適化を適用することができる（同調性）。変形が考えられるにもかかわらず、我々は、我々のＨＤＲエンコーディングの観点のための典型的なデコーダを描いた。これは、（又は１５９が近似値ＬＤＲ＿ｔを示さない場合に）ＬＤＲ＿ｕｌを復元するための画像処理用経路を有する。しかしながら、Ｒｅｃ＿ＨＤＲを決定するために第２の画像処理用経路を有する。これは、ダイナミックレンジ変換ユニット１５３において行われる。これは、典型的には、エンコーダにおいて適用される逆マッピングを適用する（実際には、信号において、典型的には、この逆マッピング（即ち、アップグレーディング）のパラメータをエンコードするだろう）。ディスプレイ色調整ユニット１５４は、典型的には、２つのグレーディングにおける情報を組み合わせるように構成されるだろう。これは、１つだけの画像及び色マッピングパラメータＰを用いることに基づいて行われ得る。しかしながら、この説明された実施形態において、我々は、Ｒｅｃ＿ＨＤＲ及びＬＤＲ＿ｕｌ画像を入力として取得し、そして、どのピーク輝度がどのディスプレイに接続されるか、及び、適切に等級化された画像により供給されるかに従って、これらを挿入するものと想定する。

【0102】

正しい輝度の見た目を取得するためのトーンマッピングから離れて、色変換ユニット１５５は、典型的には、エンコーディングの全域とは異なる色域（例えばＤＣＩ−Ｐ３に対するＲｅｃ．２０２０又はＲｅｃ．７０９等）に対して最適化するために、色彩の適応を行うように構成されてもよい。

【0103】

画像出力１５７を介して出力されるもの、それ故、ユニット１５４により計算されるものは、もちろん、接続されたディスプレイに依存するだろう。ＬＤＲディスプレイである場合、ユニット１５４は、もちろん（ユニット１５５による）正しい色リマッピングの後、例えば、ＬＤＲ＿ｕｌをＹ´ｕｖから特定のデバイスに依存するＲ´Ｇ´Ｂ´エンコーディングに送信してもよい。続されるディスプレイ１６０が５０００ｎｉｔのピーク輝度ディスプレイの近くにある場合（デコーディング装置がどのようにｔｖにその機能を尋ねることができるかについてＷＯ２０１３／０４６０９６を参照；コントローラ１６１は、ディスプレイと斯様な通信を行うことができ、優先度を取得するために観察者とさえ通信を行うことができ、ディスプレイ調整ユニット１５４がどのように動作するか、及び、どの種類の画像の見た目を計算及び出力すべきかを設定するように構成される）、前と同じようにテレビが受信したいものに応じた適切なフォーマッティングの後に、Ｒｅｃ＿ＨＤＲの見た目の画像が出力されてもよい（即ち、これは、依然として、Ｙ´ｕｖエンコーディング、例えば、２０１／ＩＭＧに格納されたＨＤＲの見た目の画像を有する我々のＳ＿ｉｍフォーマットであり得る。幾つかの機能的メタデータが送信されてもよく、従って、テレビは、このメタデータにおいてエンコードされるレンダリング可能性のスペクトルに渡ってグレーディングがどのように変化するかに関する情報に基づいて、最後の見た目の比色の微調整を行うことができる。あるいは、Ｒ´Ｇ´Ｂ´ＨＤＲディスプレイ駆動画像であり得る）。中間のピーク輝度ディスプレイに関して、ユニット１５４は、前と同じように我々のＹ´ｕｖフォーマットにおいて、又は、他のフォーマットにおいて、適切な駆動画像を出力してもよい。

【0104】

最終的に、コンテンツ作者は、ユニット１５９の補償マッピングがスキップされるべきでないことを望むかどうかを信号において規定してもよい。例えばコンテンツ作者はＬＤＲ＿ｔがＬＤＲ＿ｕｌから深刻にそれると思うためである。これは、メタデータのＩＧＮＯＲＥ＿ＴＥＣＨＮＩＣＡＬ＿ＭＡＰＰＩＮＧフィールドにおけるＢｏｏｌｅａｎ ２０９をエンコードすることにより行われ得る。

【0105】

もちろん同じ合理的根拠に沿って我々はパラメータの１つのセットの最小限のもののみを説明した場合、色マッピング機能的メタデータの幾つかのセットは、Ｓ＿ｉｍ、例えば、唯一の（ＬＤＲ画像である）画像ＩＭＧから基準（例えば［０−５０００］ｎｉｔのＨＤＲの見た目の画像）に進むための１つのセットにおいてエンコードされ得る、及び、第２のセットは、例えば１５００ｎｉｔのＭＤＲの見た目に進むために追加され得ることが読者にとって明らかになるべきである。感度、ガンマ、ゲインの特定の分解を行うにもかかわらず、関数形状を更に微調整することは有利であり、技術的説明のため少なくとも良好である。これらのマッピングのうちいずれか１つ、例えばマッピングＬＤＲ−２−ＭＤＲは、例えばトーンマッピングＬＵＴ又は値２０５のセットのみを満たすことにより、短縮された形式におけるＳ＿ｉｍにおいてエンコードされ得る。これは、最終的なマッピング関数を（即ち、感度、微調整及び技術的マッピングのすべてを一緒に）符号化する。

【0106】

図４は、我々のデコーダコアユニット４００（この例では、技術的な再グレーディング又はＹｕ´ｖ´変換等を伴うことなく、モードｉｉの最小限の部分）の典型的な実施形態を図式的に示している。ランレングス又は算術デコーディング、及び、逆ＤＣＴ等を行う解凍部４０１の後、我々は、画像ＬＤＲ＿ｔを得る。我々は、（即ち、Ｒｅｃ．７０９に従って規定されたｌｕｍａｓ又はＲ´Ｇ´Ｂ´成分を有する）ガンマ２．２表現にあり、正規化されることを想定するだろう。第１の制御ユニット４２０があってもよく、これは、この画像を、接続されたＬＤＲ ＴＶ ４１０に直接送信することができる（もちろん関連するいくつかのレガシーフォーマッティングがあってもよいことを直接意味する；原理上、ＬＤＲ＿ｔは例えば線形画像であってもよい。この場合において、これらは、これをＬＤＲディスプレイに送信する前にこれを再―ガンマ―２．２マッピングすることを必要とするだろう。しかしながら、これが必要ではない場合に有利であってもよい；更なるトーンマッピング関数は、典型的には、ＬＤＲ＿ｔがどんなタイプであるかに依存して異なってもよいだろう。これは、Ｓ＿ｉｍにおけるインジケータＩＮＤ＿２によって示されてもよい）。そして、第１のトーンマッピングユニット４０２は、任意のトーンマッピングの逆マッピングを行う。その関数形状Ｐ＿ＣＣの規定するパラメータは、メタデータＭＥＴ（Ｆ）において受信される。そして、第２のトーンマッピングユニット４０３は、例えば受信したＲＨＯ値によって上記のｒｈｏの式を適用することにより、より明るいものに対してより暗い色を比較的暗くするトーンマッピングを行う。ユニットは、接続されたＨＤＲディスプレイ４１１から受信される、受信したディスプレイピーク輝度ＰＢ＿ＨＤＲからＲＨＯ値を計算することができる。そして、第３のトーンマッピングユニット４０４は、好ましくは例えば２．４である受信したＧＡＭ値を有するガンマべき関数を実行する。そして、乗算部４０５は、ＧＡＩにより乗算を行ってもよく、これは、デフォルトで１．０であってもよい。オプションとして、色彩度プロセッサ４０６は、いくらかの彩度処理を行ってもよい。最終的に、制御ユニット４２１は、画像をＨＤＲディスプレイ４１１に送信してもよく、例えば、ディスプレイが例えばＨＤＭＩ接続を介して理解する規格に従って画像を正しくフォーマットするためにいくらかの更なる処理を行ってもよい。

【0107】

図６は、単純なエンコーダのダイナミックレンジ変換ユニットの実施形態を示している。これは、全ての色成分を１に正規化するための正規化ユニット６０１を有する（即ち、例えばＲ，Ｇ及びＢが１．０に正規化される場合、最大のルミナンスも１．０に正規化されるだろう、及び、逆もまた同じである）。ＨＤＲ画像画素の正規化されたルミナンスＹｎ＿ＨＤＲ（又は、等価な実施形態において、例えば正規化された線形ＲＧＢ成分）は、グレーダにより望まれたガンマ（しかしながら、通常１／（２．４）に固定される）により、ガンマ動作を行う第１のトーンマッパー６０２（又は、自動グレーディングユニット）に進む。そして、第２のトーンマッパー６０３は、例えば、

【数13】

により、例えば、Ｍ＿ＨＤＲの（ピーク輝度）と典型的には１００ｎｉｔのＬＤＲとの間のダイナミックレンジ差に依存してグレーディングシステムにより提案される、及び、典型的には、グレーダにより最終的に扱われる適切なＲＨＯファクタにより、ＨＤＲの暗い色を適切に輝かせる変換を行う（この最初に提案されたＲＨＯ値を変えてもよい又は変えなくてもよい）。そして第３のトーンマッパー６０４を用いることにより、グレーダは、画像における種々のオブジェクトを見る微調整を開始し、及び、グレーダにとって重要な画像オブジェクトに従ってこれらの種々のｌｕｍａを変えることにより、カスタマイズしたトーンマッピング曲線ＣＣを最終的に規定する。これは、エンコードされる全てのデータを伴う、ＬＤＲ＿ｏ画像のｌｕｍａ Ｙｎ＿ＬＤＲをもたらす。

【0108】

このテキストにおいて開示されるアルゴリズムの成分は、ハードウェア（例えばアプリケーション専用のＩＣの部分）として、又は、特別なデジタル信号プロセッサ又は汎用プロセッサ等上で実行するソフトウェアとして実際に（完全に又は部分的に）実現されてもよい。

【0109】

成分はオプショナルな改良であってもよいこと、他の成分と組み合わせて実現されてもよいこと、方法の（オプションの）ステップが装置のそれぞれの手段にどのように対応するか（及び逆の場合も同じである）は、我々の提示から当業者によって理解可能であるべきである。この出願における"装置"という用語は、その最も幅広い意味、即ち、特定の目的のリアリゼーションを可能にする手段のグループ）において用いられ、それ故、例えばＩＣ（の小さな部分）又は専用の電気機器（例えばディスプレイを有する電気機器）又はネットワーク化されたシステムの部分等であってもよい。また、装置は、最も広い意味において用いられることを意図される。従って、これは、とりわけ単一の装置、装置の一部、協働する装置（の部分）の集合等を有してもよい。

【0110】

表示としての本実施形態のコンピュータプログラム製品のバージョンは、プロセッサにコマンドを入力するため、及び、発明の特徴的関数のいずれかを実行するために、（中間体変換ステップ（例えば、中間言語及び最終的なプロセッサ言語への変換）を含んでもよい）一連のローディングステップの後、汎用目的又は専用のプロセッサを可能にする一まとまりのコマンドの任意の物理的なリアリゼーションを含むように理解されるべきである。とりわけ、コンピュータプログラム製品は、例えばディスク又はテープ、メモリ内に存在するデータ、有線若しくは無線のネットワーク接続を介して伝送するデータ、又は刊行物上のプログラムコードのような担体上のデータとして実現されてもよい。プログラムコードから離れて、プログラムのために必要とされる特性データは、コンピュータプログラム製品として具現化されてもよい。コンピュータがデータ計算を実行可能な任意のデバイスであることを意味する、即ち、例えばモバイルフォンであってもよいことが明らかであるべきである。また、装置に係る請求項は、実施形態のコンピュータにより実行されるバージョンをカバーしてもよい。

【0111】

方法の動作のために必要とされるステップの幾つかは、データ入力及び出力ステップのような、コンピュータプログラム製品において述べられたものの代わりに、プロセッサの機能において既に存在していてもよい。

【0112】

上述の実施形態は、本発明を限定するよりはむしろ例示であることに留意すべきである。示された例の請求項の他の領域へのマッピングを当業者が容易に実現することができる一方で、我々は簡潔さのためにこれらのオプションを詳細に述べていない。請求項において組み合わせられる本発明の要素の組み合わせから離れて、前記要素の他の組み合わせが可能である。要素の任意の組み合わせは、単一の専用の要素において実現されてもよい。

【0113】

請求項における括弧内の任意の参照符号は、請求項を限定することを意図するものではない。有するという用語は、請求項に記載されていない要素又は態様の存在を除外するものではない。要素の単数表記は、斯様な要素の複数の存在を除外するものではない。

【図1】

【図2-2b】

【図3】

【図4】

【図5】

【図6】