JP6382805B2 - 改良されたｈｄｒ画像符号化及び復号方法並びに装置 - Google Patents

Description

本発明は、ローダイナミックレンジ（ＬＤＲ）画像と呼ばれるレガシー画像と比較して広いダイナミック輝度レンジを有する少なくも１つの画像又は映像の改良された符号化のための装置及び方法、並びに、例えばメモリ内に保存されるデータストレージ結果物又は符号化信号等の結果物に関連する。

近年、撮像、画像表示、そして特に画像符号化は、いわゆるローダイナミックレンジ（ＬＤＲ）イメージング（ＰＡＬ又はＭＰＥＧ２等の古典的なシステム）からいわゆるハイダイナミックレンジイメージング（ＨＤＲ）に改良された。今日のセンサは高い信号電圧レンジ（飽和する又は少なくとも最大許容画素電圧を与えるシーン輝度と最小レベル又は典型的なノイズレベルとの間）を元々有するか、又は、複数の画像、例えば、異なる感度の空間系からの複数の画像若しくは露出設定が異なる連続画像から画像を構成することでセンサレンジを伸長する技術を有する。ＬＤＲカメラによる撮像との違いは、ＬＤＲカメラは通常一部の領域をクリップ及び／又はソフトクリップし、例えば外部の明輝度は白色になるが（それらの保存される符号化ＬＤＲ画像画素のルマＹは２５５である）、一方、ＨＤＲ撮像システムは適切且つ忠実にシーン内の全輝度を取り込むことが可能な点である。しかし、依然として問題なのは、それらをどう扱うか、すなわち、それらを例えばテレビネットワークシステムを介する送信のために如何に符号化すべきか、また、それらを如何にして例えばＬＤＲディスプレイの典型的なピーク輝度より高いピーク輝度（例えば、１００又は５００ニットではなく３０００ニット）を有するＨＤＲディスプレイ上に（忠実若しくは好適に又は少なくとも許容可能に）レンダリングすべきかである。

レンダリング画像の見かけは多くのパラメータ、特に画像内のコンテンツ、レンダリングディスプレイの種類（ピーク輝度等）、及び視聴環境等に依存するので、通常、取り込まれた生のセンサ画像（オリジナルシーンとは密接に関係し得るが、最終的なレンダリング環境とは全く関係せず、よって人間がこれらの２つのシナリオをどう見るかに関する情報は存在しない）の画素カラーが変換され、これはグレーディングと呼ばれる。典型的には、これは人間のグレーダーによって行われてもよい。例えば、映画製作では、（時間及び費用の制約も加味して）室内を正確に照明することが困難な場合があり、特定のグレイパターンの雷雲を作成することは言うまでもない。この場合、シーン照明クルーは少なくとも「十分な」又は「適量の」光をあらゆる場所に作り出す大まかに正しい照明を目標に定め、実物（例えば、テーブル上のキャンドル（又はそれを模したもの）等の雰囲気照明、ネオンサイン等）を配置し得る。しかし、グレーダーがその後画像処理ソフトウェア内でそれを改良し、例えば、グレーダーはあたかも実際のシーンにおいて日が窓から差し込んでいたかのように日差しを描き込むことができる。

ＬＤＲ符号化は特徴的な他の特性を有していた。専門知識がない人は、ＬＤＲを単に画素毎にルマが８ビットコードワードを有する符号化（又は、当然ながら類似の実施形態）として考え、また、その反対に８ビットがＬＤＲを意味すると考えられる可能性がある。しかし、理論的にはそれらの８ビットコードの画像アレイに何を符号化しても構わないので、少なくとも理論的には非常に複雑なパターンを符号化することができ、よってＨＤＲ画像をできないとする理由はない。

問題は、部分的には長い歴史的な慣習の遺産であり、センサ電圧（すなわち、シーン輝度の線形表現）が特定のコードマッピング関数に従って８ビットコードに符号化されていたことであった。これは単純な、過度に非線形ではない単調連続関数、すなわちガンマ２．２であった。アイデアは、かかる直接的な接続システムを介する取り込み、コーディング、及びレンダリングの密接な結びつきが、正確且つほぼ自動的なグレーディングの実行をもたらすということであった。信号はＣＲＴディスプレイのカソードに直接印加され、このＣＲＴの物理的特性のためにガンマ２．２が選択された（付随的に、適度に均等な心理視覚的輝度スケールも与えた）。１種類のディスプレイしか存在しない場合、ＬＤＲ信号である駆動信号による駆動であり、ＬＤＲ信号がカメラから真っ直ぐに補正ガンマ、すなわち約１／２．２によって自動的にプリグレーディングされれば、ディスプレイは駆動値を出力輝度に正確にレンダリングする。しかし、製作者側のグレーディングアーティストが画素カラーを微調整又は改良することを望む場合、同じ補正後画像で駆動されたために消費者の家庭用テレビが同じレンダリングを概ね正確に与えるよう（視聴者の周囲効果を除き）、グレーダーは製作者側にて同一のＣＲＴ上で信号を見ながら行うであろう。

いずれにせよ、このＬＤＲ符号化チェーンは閉じた指定として機能し、レンダリング及び符号化（又はグレーディング）が同じものをもたらす。今日、例えば家庭用ＬＣＤ、電車で画像コンテンツを見るためのＩｐａｄ、ホームプロジェクタ、及び最近の非常に高輝度なＨＤＲディスプレイ等、顕著に異なるディスプレイが存在することは、レンダリング又はガマットマッピングが画像符号化とは完全に分離したフェーズであることを要求する。同じ入力画像が与えられた場合、これらのディスプレイの出力の見かけにはかなりのばらつきがあり、それが所望されるもの以上に厳しい可能性があるからである。

しかし、いずれにせよ、ＬＤＲシステムでは、コンテンツ製作側、例えばカメラと符号化との間では、この密接なリンクは依然として守られていた。最新の消費者用カメラ（特に最近はＨＤＲ機能を備え始めたので）はガンマ２．２よりも高度なコードマッピング関数を使用し得るが、依然として高度に非線形ではない比較的類似な関数を有し、すなわち、それらの数学的挙動の多くの側面を線形解析によって近似できない程度には違わない。

これは特に、例えば車に乗っている人のシーン等、比較的輝度レンジが高いシーンを取り込む場合に見られる。人の顔の露出及びコードマッピング関数（例えば、Ｓ字曲線）等のファクタの組み合わせは、典型的には、車内のために十分に露光をした場合、外部がコードガマットの上限付近の淡いカラー、すなわち２５５付近のルマでしか表すことができないという事態をもたらす。これは、カメラ又はカメラマンが例えば顔のカラーコードを平均グレイ付近に（例えば単純さのために１２８とする）することを選択するからである。この値付近のマッピング関数が２乗関数であると推定すると、値２５５は４倍高い外部ルマしか表すことができない。当然ながら、実際の値はカメラシステムが（人間のオペレータによる選択を含む）そのような明領域を如何に賢明に取り扱うかに依存し、コードマッピング内の適切なショルダは依然として、少なくとも、顔の輝度の４倍以上の異なるコード値をシーン輝度に割り当てることができる（但し、実際では、余り準備をせずにロケ撮影をする場合、素早く作成されるコンテンツのかなりの部分は画像の大部分を２５５にクリップし、これがさほど望ましいのかは疑問である）。

いずれにせよ、大まかな目安として、例えば５００：１（又は少なくとも１０００：１）以上の輝度比では、ＬＤＲ符号化には問題が生じると言え、少なくともシーンを正しく符号化したい場合はＨＤＲ符号化の技術分野に突入する。よって、これは、物体の反射率は通常１％〜１００％の範囲であるので、ハイライト−シャドウが約５〜１０−１の照明不均一性を作り出す幾何学的形状係数を有する場合に起こる。このような照明低下は、部屋の中の窓から数メートル離れた位置で容易に起こり得る。

同様に人間の観察者に対して特徴的なカラースキームを明示するハイダイナミックレンジシーンの一例は、夕暮れの都市景観である。光が既にそれ（「光」）以上の輝度レベルにジャンプするので、白色は人間の視覚に薄い灰色として映り、シーン内に白色が欠けているように見える。すなわち、これらをＨＤＲディスプレイ上で光物体として示し、且つ、それらが明確に光として認識され得るような態様でそれらを符号化し得ることが望まれるよう（特に、入力信号を駆動信号として直接適用せず、いくらかのガマットマッピング最適化を行うレンダラーによって）。カメラ撮影、コーディング、及びディスプレイが分離されるので、どのダイナミックレンジが指定されるかを注意深く判別すべきであることに留意されたい（また、常に輝度コントラストであるべきではない）。特定の、例えば１０００００：１のダイナミックレンジは必ずしもレンダリング時に同じコントラストを要さない可能性があるからであり（例えば、画面上の太陽が実際に視聴者の目を傷つける必要はない）、実際に関連するファクタは、心理視覚的に適切な類似の見かけである。汎用的な高度に非線形な符号化において、これがコーデックのダイナミックレンジに関して何かを言うべきことは当然である。特定のマッピング又はコーディング／レンダリング精度等のファクタはいずれもそれに影響を及ぼし得るからである。画面表示に関しては、ディスプレイシステムがＬＤＲディスプレイ上では忠実にレンダリングすることができない特定の光効果、例えば本物の輝くランプ又はあたかも本物に見える屋外シーンの日光等をレンダリング可能な場合、ＨＤＲディスプレイシステムを有していることがわかる。そして特に、他のシーン物体（例えば、室内の家具）の明るさがそれと調和し、すなわち、（人間の視覚に関して）明るい物体及び通常の／暗い物体の両方について良好な見かけが得られるようなルマが与えられる。

ＨＤＲ画像符号化のために最初に想起された（ネイティブ）ソリューションは、特にコンピュータグラフィックの分野で働く人々によって考えられた。コンピュータではあらゆる種類の信号が作成可能なためである（コンピュータでは撮像レンズの制約がなく、超新星の隣の宇宙空間は実際に０輝度を有することができ、またフォトンノイズが捉えることはない）。一切の従来のテレビ技術制約を完全に破棄できるこの枠組みでは、論理的なソリューションはシーン輝度を単に線形に符号化することであろう。これは、画素ルマのためにより多くのコードビット、例えば１６又は３２ビットが必要であることを意味するであろう。動画の場合は問題になり得る多量のデータのほか、上記のように、このようなネイティブ符号化は画像処理チェーンの残りの部分、すなわちレンダリングシステムと全くつながりがない（又は、符号化画素画像と共に又は別個にではあるがリンク可能にメタデータとして共符号化され得る埋め込み技術知識、例えば付加的な値、測定値、又は方程式に含まれる知識等が存在しない）。

代替的な第２の符号化の方法は、デュアルＬＣＤパネルディスプレイ等のデュアルディスプレイシステム又は２Ｄ可変バックライトを備えるシングルパネルＬＣＤによってインスパイアされ又は少なくともこれらに概念的に関連付けられ得る。これらのシステムでは、最終的な出力は背面層ディスプレイが生成する光パターンと前面のＬＣＤの透過率の積である。ここで問題は、例えば上記のようにネイティブ１６ビット（少なくともルマ）ＨＤＲ符号化と、標準ドライバ電子機器及び例えば８ビットＬＣＤの物理的円光能力とを有するとして、如何に両信号を駆動するかということである（つまり、線形透過ではＬＣＤは自身のフル透過の１／２５５の黒色を作成することができ、非線形挙動の場合はいくらか異なる値を作成し、更に、例えばバックライトが８線形ビットにより変更可能であることを意味する）。この場合の単純なソリューションは、画素ルマの平方根を取り、この平方根の２倍を２つのドライバに送信することであろう。原則的にはあらゆる乗算分解が（理論的には）使用可能であろう。例えば、ＬＣＤが透過率を４つのステップ（２ビット線形）でしか変更できない場合、除算の残りを与える信号でバックライトを駆動すれば、依然として正確なＨＤＲシステムを作成することができる。
Ｙ＿ｂａｃｋｌｉｇｈｔ＝Ｙ＿ＨＤＲ／Ｙ＿ＬＣＤ
ここで、この例ではＹ＿ＬＣＤは背後の光を４つの異なる態様でより明るく又は暗く変更する（例えば、背後の光の１／８０透過であり得る最大黒色対１００％透過と、これらの間の等距離透過率）。

Ｙ＿ＨＤＲは１６ビット信号であり、最大値はディスプレイのバックライトを（局所的に）その最大値に（加熱、老朽化等を考慮して）切り替えることにより近似的にレンダリング可能な非常に明るいシーン輝度を意味する。よって、レンダリングは物理的にそのように働くので、同様に線形コーディングを使用して、バックライトは１６ビットの１／４のレンジを作成しなくてはならず（６５５３６線形ステップが作成される）、（同様に線形コーディング及び等間隔駆動が必要だと仮定する場合）これはバックライトが１４ビット信号により駆動されることを意味する（そのような精度が必要な場合）。したがって、バックライトは、ＨＤＲ画像をレンダリングするのに必要な任意のファクタによってローカル値をＬＣＤバルブに変更することができる。実際には、これらのディスプレイは画素よりはるかに少ない数のＬＥＤバックライト素子を含んでいたので、何らかの平均輝度に従ってバックライトを駆動することにより、画像の近似がレンダリングされていた。よって、例えばブリティッシュコロンビア大学のＵＳ７１７２２９７の請求項２に示されるように、ローカル画像画素の平均ルマを最初に計算し、これが必要なレンダリングを近似するバックライト値をもたらし、そしてＹ＿ＨＤＲとこの近似の商としてＬＣＤ画素が設定される。したがって、この乗算の興味深い特性は、これが画像の１つを符号化するための線形ビットの減少に対応することであり、これは数学的に一種のレンジ圧縮又はガマットマッピングと見なすことができる。

したがって、これが更に昇華され、すなわち、このような乗算スキームに基づいて任意のＨＤＲ画像を符号化するよう昇華された（必ずしも実際の２層ディスプレイについてだけではなく）。すなわち、何らかの汎用トーンマッピングを実行することにより第１の画像を形成し、このマッピングされた８ビット画像から標準ＪＰＥＧ画像（Ｙ＿ＪＰＥＧ）を作成することができる。そしてその後、比画像Ｙ＿ＨＤＲ／Ｙ＿ＪＰＥＧである第２の画像を保存する。したがって、デコーダ側では通常のＬＤＲＪＰＥＧ画像を使用するか、又は２つのＬＤＲ画像を乗算することでＨＤＲ画像を再作成することができる（オリジナルが２つの８ビット画像を生成する１６ビットであったと仮定し、これは全てとは言えないまでもほとんどのＨＤＲシーン又はシナリオで通常十分である）。この方法の第１の欠点は、任意のＨＤＲ画像をそのようにして符号化することが可能であるが（比画像内のＪＰＥＧ画像に含まれるものを補正することにより、又は、例えば、やはり線形を想定する場合、２つの隣接する画像がＪＰＥＧでは１であるように選択されるがＨＤＲでは２３０及び３５０であるべき場合に起こり得ることであるが、補正が可能レンジを上回る程にＪＰＥＧ画像が劣悪に符号化されるときは少なくとも適切な近似に到達することができる）、２つの画像を符号化しなければならないことを代償とする。これらの２つの画像をフォーマットするための周辺セマンティクスが必要であることに加えて、数学的相関による節約がなければ、単一の１６ビット画像を保存する場合と同じ量のビットが明らかに必要なように見える（少なくとも空間的サブサンプリング等をしない場合）。第２に、この「盲目的な」分解は実際のレンダラーの物理的特性、又は、レンダリングされるシーン内に存在する物理的若しくは心理視覚的セマンティック法則（例えばどの物体が明るいランプに過ぎない等）とは関連性がなく、むしろ、これは単にＪＰＥＧベース画像になるよう選択されたものの乗算補正から生成される。とはいえ、これは画像符号化のための良好な後方互換性戦略である。

第３のコーディングの方法は、予測が付加的な補正画像によって補正される予測−補正スケーラブルコーディングの歴史から辿ることができる。元々は、これは特にＳＮＲスケーラビリティにおいて起こり、第１の画像は画素ルマの丸められた又は量子化されたバージョンを含み得る近似であった。これに更なる精度を加える画像が付加される（他の実施形態では例えば空間的近似を含んでもよく、これも補正信号を加えることで補正可能であり、この場合更に例えば境界における高周波が修復される）。したがって、例えば符号化されるオリジナルの（ＬＤＲ）信号が空間的に隣接する画素１２７、１４４を有していた場合、例えば６ビット及び精度ステップ４の近似で符号化され、画素値１２８及び１４４を与える。その後、これは値−１及び０を含むより高精度の画像で補正され得る。近似は既に概ね良好であったため、補正信号のレンジはより低くなるはずであり、ビットの節約につながり得る。

あるレンジとレンジ内の精度は原則的に交換可能なので、ＨＤＲ画像符号化に関してもこのような技術が使用可能であることが想起され得る。実際には、任意のコーディングレンジ（同様に８ビット符号化）の最大値は任意のシーン輝度に対応するよう定めることができる。しかし、ＨＤＲシーンにおける輝度ステップの量を考慮して、これは８ビット以上の符号化の場合にのみ適切であり得ると考えられていた。また、単純なスケーラビリティはトーンマッピングにおける一切の変化も示唆せず、すなわち、定義として、ルマ精度問題のみを取り扱い、特定のＬＤＲ符号化が任意のＨＤＲ符号化に如何に関連するか、又は任意の符号化画像が任意のディスプレイ上に如何にして最適にレンダリングされなければならないか（例えば、より低いピーク輝度のディスプレイ上に全体的に過度に暗くレンダリングされることなく）については何も述べない。

また、この概念に基づき、ＷＯ２００７／０８２５６２において２層ＨＤＲ符号化方法が開発された（図１参照）。このようなエンコーダでは、取得、符号化（例えば、ガマットマッピングによって）、又は典型的にはグレーディング（典型的にはコンテンツ製作者のために働くアーティストグレーダーによって）され得るＨＤＲとＬＤＲとの間に関係性があることが認識される。例えば、ＬＤＲガマット（例えば４００ニットの典型的なＬＤＲディスプレイがレンダリングするであろうものによって定義）は例えば晴れた屋外のような明領域を忠実に保持することができない可能性があるので、そのような領域はルマを下げてＬＤＲ空間にマッピングされ得る（場合によっては更に色飽和度を下げて）。オリジナルシーンのこのようなＬＤＲ符号化からＨＤＲ画像を作成することは、例えば所定の若しくはＬＤＲルマ依存輝度を加え若しくは概して少なくともルマにあるマッピング関数を適用して（Ｙ＿ＨＤＲ＝ｆ（Ｙ＿ＬＤＲ））ＬＤＲルマをオフセットすることにより、画像の明るい屋外領域の画素ルマ／カラーをより高い輝度にマッピングすることを伴う（又は、言い換えれば、ＨＤＲグレーディングされた画像がどのようになるかを予測すること）。少なくともよりＨＤＲ的な見かけは得ることができるが、この予測がオリジナルのＨＤＲグレードにどれだけ近いかは、特にマッピング／予測関数の正確さ（及び複雑さ）に強く依存する。画像の高度な複雑性のために（これは、通常、例えばいずれにせよオリジナルのＨＤＲ画像を完全に正確には予測しないより複雑なものではなく、各画素ルマをもっぱらルマ値にマッピングし、画像内の画素の空間位置等の他のファクタはマッピングしないより単純な予測、例えばグローバルトーンマッピング等を人々に選択させる）差が生じることになり、これは差画像となる。したがって、２層方法はこの画像も符号化する。ＬＤＲグレード（原則的にはＨＤＲグレードに近い又は類似する必要はなく、何でもよい）とＨＤＲグレードとの間の差は信号のＸビット精度とＸ＋Ｙビット精度表現との間の差とは全く異なるので、これらの差画像は制限された値域を有さなくてよい。これらは原則的には何でもよく、例えばＨＤＲ画素ルマが例えば６５０００、６５００４等である一方、画素ルマが連続する０として予測される程に予測が劣悪な場合、８ビット差画像ではなくオリジナルのＨＤＲと同様な１６ビット画像でさえ良い（但し、このような最悪のシナリオはあまりに想定しづらいので、このケースではコーデックに単純にミスを起こすよう制約できる）。いずれにせよ、これらの予測コーデックのいくつかを補正画像によって試験した結果、これらが大量の符号化データを要求し得ることが認められ、また、特にこのデータはＨＤＲ体験には実際にはそれほど関連しない画像情報を符号化し得ること、例えばＨＤＲルマを誤った方向にマッピングした予測モデルエラーの補正、又は心理視覚的にそれほど関連しないか若しくは少なくともＨＤＲ効果に寄与する最も重要な画像構造ではないノイズ若しくは画像構造を符号化し得ることがわかった（ＨＤＲ関連性の階層において、例えば、炎が重要であり、その見かけは良く選択された少数のデータワードによって予め符号化され得る）。

したがって、以下に提示される技術の一課題は、シーン内のＨＤＲ側面（すなわち、光、特定の画像領域への日射等の物体の照光、ローカルコントラスト等の特定の側面の改良されたレンダリング等）の全てとは言えないまでも少なくとも一部の符号化に関するより優れた管理を与えるＨＤＲ符号化技術（すなわち、古典的なＬＤＲよりルマレンジに沿う画像領域の品質が高い任意の符号化技術）を提供することであり、例えば、より低いビットレート、又は少なくとも符号化されたビットの階層においてより重要な情報等の潜在的な利点をもたらす。

課題の問題の一部は、第１の輝度ダイナミックレンジ（Ｒ＿ｏＬＤＲ）に対応する画像符号化（ＬＤＲ＿ＣＯＮＴ）を第２の輝度ダイナミックレンジ（Ｒ＿ｏＨＤＲ）出力画像（ＨＤＲ＿ＦＩＮ）に復号する方法であって、画像符号化（ＬＤＲ＿ＣＯＮＴ）は、ハイダイナミックレンジシーンのオリジナル画像（ＨＤＲ＿ＯＲＩＧ）の符号化画素であり、
所定のトーンマッピング戦略（ＦＬ２Ｈ）により、画像符号化（ＬＤＲ＿ＣＯＮＴ）内の画素の少なくともルマを、第２の輝度ダイナミックレンジ（Ｒ＿ｏＨＤＲ）に対応する中間画像（ＨＤＲ＿ＰＲＥＤ）内の画素のルマにトーンマッピングするステップと、
中間画像（ＨＤＲ＿ＰＲＥＤ）の少なくとも一部の画素のルマに所定の乗算係数を掛けることにより当該ルマを変更し、出力画像（ＨＤＲ＿ＦＩＮ）を得るステップと
を含む、方法によって処理される。

符号化画素とは、当然ながら、（画素は、選択された表色系において定められる、特定のサンプリング位置のテキスチャカラーサンプリングなので）画素の情報、すなわちそれらが表す画像物体のテキスチャ、すなわち画素のカラー表現（例えばＹＣｒＣｂ又はＲＧＢ））を意味する。しかし、ＬＤＲ＿ＣＯＮＴはオリジナルＨＤＲ画像のカラー符号化における実際の表現を保持せず（３ｘ８ビット画像として符号化される場合でも）、ＬＤＲ＿ＣＯＮＴは新しい色であるこれらの色の変換を保持するが、新しい色は依然としてオリジナル画像をレンダリングするために必要とされる空間−統計的カラー情報を保持する。したがって、画素は依然として同じ幾何学的画像物体構造を表すが、特定のディスプレイ上でレンダリングされる場合は入力オリジナルＨＤＲ画像とは異なる比色的見かけを有する（しかし、情報理論的に、比色的変換が何であれ、オリジナル画像内に存在したものと同じ情報、すなわちＨＤＲシーン内の情報の良好な捕捉が、画像符号化ＬＤＲ＿ＣＯＮＴ内に依然としてほぼ全て存在し、少なくとも追加メタデータ、特に本発明の実施形態に係るメタデータを用いることで再取得可能である）。画像に対応する又は関連付けられたダイナミックレンジとは、それが主に特定のダイナミックレンジのディスプレイ、又は類似するダイナミックレンジのディスプレイ上でのレンダリングを対象とすることを意味する（かかる態様での符号化の意味を定義するレンダリングダイナミックレンジと、線形符号化に関してのみ意味をなす、例えば８ビットルマ符号化等のダイナミックレンジとして人々が通常考えるものとの間の正確な違いは後述する）。トーンマッピングとは、例えば単純なグローバルトーンマッピング関数、又は、例えば画像符号化の画素カラーを出力画像の画素カラーに究極的に変化させる任意のアルゴリズムを意味する。

後方互換性の直接使用可能なＬＤＲ信号によりそのようなシステムを実現するための非常に興味深い態様は、ハイダイナミックレンジ（入力又はマスター）画像又は映像信号の符号化をハイダイナミックレンジ出力画像又は映像信号に復号する方法であって、方法は、
−所定のトーンマッピング関数により、符号化内の画素の少なくともルマをハイダイナミックレンジ中間画像内のＨＤＲ画素のルマにトーンマッピングするステップと、
−中間画像の少なくとも一部のＨＤＲ画素のルマに所定の乗算係数を掛けることにより当該ルマを変更するステップとを含む。

符号化とはシーンの画像の任意の表現を意味し、必ずしも圧縮されていないが、特にその表現にてＨＤＲシーンの特性を賢明に使用する（例えば、あるルマサブレンジを平均グレイ物体に割り当て、他のサブレンジを光効果に割り当てる）。物体の明るさの値を規定することは視覚的品質のためにより重要な情報であり、そのまわりのカラーはいくらかより小さい影響力を持つので（例えば、ニュースキャスターのシャツの色はわからないので）、単純さのために、ルマに焦点を当てる。したがって、例えばガマット形状問題のために変形誤差が生じなければならない場合、色彩方向に生じさせる方が良い。当業者は、例えば規定されたルマのまわりのガマットマッピングされた彩度を指定することにより（例えば、何らかの色相及び飽和関数）、又はルマ−彩度色表現の代わりにＲＧＢ３軸上で作業等することにより、このルマ軸のまわりの色の色彩的側面も指定できることを知る。これは本発明の核心ではないので、これについては詳述しない。当業者は、ルマチャネル上で実行可能な作業（マッピング及び変更）は他のチャネル、例えば赤色チャネル上でも当然に実行可能なことを理解する。信号については、特に更なるメタデータが追加される場合、画像データが何らかの規格に従って如何にフォーマットされたかが理解され、一方、画像は、本明細書では生の画素カラーのアレイとして理解され得る（しかし、本発明はどちらの説明によっても容易に理解され得る）。

基本的な方法を、ＨＤＲシーンを主に８ビットレガシー画像（「ＨＤＲ＿ｅｎｃｏｄｅｄ＿ａｓ＿ＬＤＲ」又は、ＨＤＲがＬＤＲの枠組み内に入れられるため「ＬＤＲコンテナ」と呼ばれ得る）として符号化する（すなわち、例えばＭＰＥＧ−ＡＶＣ符号化によって符号化する）有用なアプリケーションに関して説明する（少なくとも変換関数が共符号化されるが、一部のＨＤＲ高輝度領域は補助的な態様で、例えばデコーダ側において空間的に局所的な画素のセットを与えるために、例えば局所的置換画像を用いて符号化され得る）。本例での符号化は、マスターハイダイナミックレンジ入力映像信号の情報、例えば１６ビット線形を保持する例えばＬＤＲＭＰＥＧ又はＪＰＥＧである。そのような符号化が多くのシナリオにおいて機能し得る理由は理解され得るであろう。但し、細かいグラデーション又は微細な物体のテキスチャ上のバンディングを回避する最高の品質のためには、今日のディスプレイ輝度及びサイズにおいては８ビット以上さえ望ましい可能性がある。しかし、画像内で素早く動く複雑な物体のテキスチャについては、６ビット近似が既に適当であり得る。したがって、６ビット以上で大きなルマサブレンジを圧縮するマッピングはいずれも良好であり得る。レンジ全体については、ＬＤＲとＨＤＲ８ビットグレーディングとの間でのマッピングにより８から６ビットに落とすことで、既にファクタ４若しくは２絞り薄暗くなる線形ストレッチ又はガンマが可能になる。特に、バンド幅／メモリ又はビットレートがいくらか重要なアプリケーションでは、より多くのビットを必要とする最大可能品質ではなく、非常に適切な品質でＨＤＲ特徴のほとんどを既に許容する符号化を有することが賢明である可能性がある（また場合によっては、多くのいわゆる高品質アプリケーションでは、例えばＤＣＴ係数の量子化を不適切に又は致命的に調整すること等により大きなアーティファクトがいずれにせよ発生する）。

ＬＤＲレンジ等の特定の輝度レンジのために（例えば、その信号を駆動信号として直接適用することにより使用可能なように）符号化された信号と、それが実際に保持する情報との間の本教示のための重要な違いを理解するよう注意深く考察すべきである（これは一般的に理解される洞察ではない）。符号化とレンダリングとを完全に切り離したため、これを行うことができる。これは、ルマサブレンジ内の情報を、特定のディスプレイ上で正しくレンダリングするために［０，１］又は［ｍｉｎ＿ｌｕｍａ，ｍａｘ＿ｌｕｍａ］レンジ沿いの適切なレベルにシフトすることにのみ関する。例えば、符号化はＬＤＲディスプレイ上に良好な見かけの画像を与えるよう構築（例えば、人間によってグレーディング）され得る（符号化に対応するレンジをルマではなく輝度で表すことにも留意されたい。輝度は最終的にレンダリングされるときに画像符号化が対応する線形出力結果であり、一方、ルマは実際の符号化であり、理論的には何でもよく、例えば輝度０．１ニットがルマ３２によって符号化されてもよいし、輝度２００ニットがルマ０によって符号化されてもよい）。これは、低ピーク輝度、例えば１００ニットディスプレイ上で、例えばほとんど判別できない黒色で全てを視覚的に混乱させるようにではなく、依然として構造が十分視認できるよう暗い領域をグレーディングすることを意味する。しかし、この画像グレーディングはＨＤＲレンダリングではそれほど有用ではない。例えば、暗い画像領域が正しいシーン雰囲気を伝達するためには明るすぎると考えられる可能性があるからである。しかし、このＬＤＲグレーディングされた画像（正しい暗領域挙動等）は低オリジナルシーンレンジ若しくはサブレンジ又は高い輝度（サブ）レンジの情報（すなわち、画素ルマ空間的多様構造）の両方を含み得ることに留意されたい。例えば、眩しい屋外領域を最大白色（２５５）にクリップするが、依然として同じ暗い及び中領域ルマ値を有するＬＤＲ信号を単純なカメラを使用するだけで得ることができる。又は、眩しい屋外領域のオリジナル捕捉テキスチャの一部を含む知的ガマットマッピングアルゴリズムを使用することができる。これは、ＬＤＲ画像のローダイナミックレンジ内のものをスクイーズし（通常、より少ないビットへのスクイーズが考えられるが、より重要な問題は、符号化に対応するテント形状のルマ、色相、飽和ガマットの部分領域を如何に割り当てるかということである）、そのようなシーンはＬＤＲディスプレイシステム上で決して忠実にレンダリングされ得ないという点て、いくらかのエラーを引き起こす。しかし、それにも関わらず、丸めエラーとは別に、ＨＤＲ情報が依然として存在する。すなわち、それはＬＤＲ符号化内に直接レンダリング可能な態様で存在する（より暗い室内の平均輝度と多かれ少なかれ同じ淡い屋外領域はどのみちクリッピングよりもはるかに良い）。しかし、ＨＤＲ情報が符号化内に存在するので、ＨＤＲレンダリングのためにも使用可能であるが、この場合、当然ながら、正しい見かけの出力画像を得るための適切なトーンマッピングがまず要求される。しかし、ＨＤＲシーンをＬＤＲ使用可能信号（すなわち、ＬＤＲディスプレイ上に直接適用されたときに正しい見かけを有する）として符号化するこの非常に有用な後方互換性システムに代えて、本発明の同じ技術的教示を反対に使用することもできることに留意されたい。

すなわち、同じように８ビット符号化であるが、今回は例えば３５００ニットのＨＤＲディスプレイ上で直接使用するためにグレーディングされる。すなわち、この信号は典型的には例えば暗い輝度領域でより小さいルマを有するよう、異なるようにグレーディングがされる。この場合、ＬＤＲ信号からＨＤＲ信号を（すなわち、ＨＤＲ輝度レンジレンダラーのために）復元する必要はなく、大部分で反転した特性を有するトーンマッピングを適用することにより（例えば、暗い領域を圧縮するのではなく伸長する）、８ビットＨＤＲグレーディングから、レガシーディスプレイ用のＬＤＲ信号が導出される。トーンマッピング関数は同様にメタデータ内に共符号化されるが、大まかに反対の形状でされる（伸長ではなく圧縮）。その後、ＨＤＲ予測ではなくＬＤＲ予測に我々の乗算変更が適用される。当然ながら、方法は、予測がほぼ十分であるが、主要な効果のための少しの追加ビットによるいくらかの補正が、少なくとも一部のシナリオにて、すなわち、一部の画像の一部の部分のために望まれる他のシステムでも機能し得る。例えば、レガシー８ビット符号化制約を落としても、ＨＤＲを例えば１０ビットコンテナにトーンマッピングすることは依然として分別があり、その後伸長トーンマッピングにより任意の基準ディスプレイ（ピーク輝度）のためのＨＤＲが再取得され、いくらかの乗算微調整が適用される。したがって、本方法が如何にして異なる第１及び第２の輝度レンジの符号化の間のトーンマッピングを有するシステムに対して非常に有用且つ有力な補正として機能するかが明らかになったであろう。

画像信号が何を意味するか、すなわち、典型的には例えば画像アスペクト比等のデータの意味のための記述子等のメタデータ等、及び、画像を変更するため等の符号化画像に関連する有用な情報を保持する更なるメタデータ等を含む画像データをパックするための既存の又は同様の方法のうちの任意のものであることが理解されよう。

最終的なＨＤＲ見かけに少ししか又は全く影響を与えない精度及び無駄なビットに高度に焦点を当てる、オリジナルと予測との残存する差（すなわち、依然として符号化されるべきもの）を論理的に符号化する改良方法とは対照的に、出願人は、好ましくは著しいＨＤＲ印象の向上を素早く与えるより重要なビットに好ましくは焦点を当てる。例えば、ＨＤＲ＿ｅｎｃｏｄｅｄ＿ａｓ＿ＬＤＲ符号化は、レンジのために精度を犠牲にすることができるので機能し得る。原理的には、さもなければバンディングが見られるリスクがあるため、特に高輝度ディスプレイ上でグレイ値を正確にレンダリングするためには８ビット以上が必要であると考えられるかもしれない。この問題の他の見方は、人間の視覚的体験にとって、そのような論理的誤差が実際にどれほど悪いのかを考察することである。高度にテキスチャリングされた領域では、これらの量子化エラーは通常あまり目立たず、特に動画では目立たない。一部のシーン、例えば背景グラデーションでそれらが発生したとしても、それらは邪魔に見えるかもしれないが、問題は当然ながら、そのようなアーティファクトが他のアーティファクトに対してどれだけ深刻であるかということである。例えば、低容量又はバンド幅媒体では、ＨＤＲ見かけをレンダリング可能であることが最も重要な視覚的ファクタであり、もしＤＣＴブロック歪み等のアーティファクトが既に存在するならば、いくらかの時々のバンディングは許容され得る。この場合、ＨＤＲ符号化は精度より、シーン物体のルマ／明るさの正しい割り当て及び対応するトーンマッピング関数等の符号化技術に関連する。実際には、６ビット／チャネルが既にＬＤＲのためには比較的良好な量のデータ精度であると言うことができ、それであれば８ビットはより高い輝度レンジを許容するであろう。実際には、２つの追加のビットは４つの追加のファクタを許容し、これらは精度ではなく追加のルマレンジとして使用され得る（例えば、「暗い影」、「平均グレイ／通常照光」、「明領域（例えば、屋外の日が差す領域）」、及び「非常に明るい」等の様々なシーン領域のために４つの異なるルマレンジを割り当て、様々な物体をそれらに符号化する）。

しかし、より重要には、良好な制御を有することによりトーンマッピング関数を調整することができ、それにより必要な部分領域を最適に割り当てることができる。このようにすることで、全てが６ビット精度等価のサブレンジを有する必要はなく、一部の重要なサブレンジ（例えば、俳優が存在する主要（平均グレイ）レンジ）がより高い精度を必要とする場合、例えばシーン内でたいしたことが起こっていない他のレンジを代償にしてそれを得ることができる（例えば、明るい光を２〜３のコードだけで符号化してもよい）。

これは、ＨＤＲグレーディングをＬＤＲグレーディングと同一化する試みに高度な多様性を与える。本説明では、更に優れた機能を奏するシナリオ、すなわちそのＨＤＲからＬＤＲを導出するシナリオを仮定する。したがって、原則的には（完全に又は少なくともほぼ）可逆であるトーンマッピングにより、ＨＤＲルマがＬＤＲルマにマッピングされる。そのようにして得られたＬＤＲグレーディングがＨＤＲグレーディングに類似して見えるようにする（ＬＤＲディスプレイの低輝度ガマットが許す限り）こと、及び空間的部分領域又は物体に対応する様々な（特に重要な場合）ルマサブレンジのための十分な精度を維持すること等のファクタがトレードオフされ得る。

ここで、このマッピングは逆転することができるので、マスターＨＤＲグレードからその例えばＨＤＲ＿ｅｎｃｏｄｅｄ＿ａｓ＿ＬＤＲグレーディングへのグレーディングの逆関数である所定のトーンマッピング関数でトーンマッピングすることにより、ＬＤＲ符号化からＨＤＲ画像を再構築することができる（例えば、標準［０，１］小数点表現内の値を［０，２５５］ＬＤＲルマを得るために再割り当てするためにガンマ０．３３関数を使用する場合、ＨＤＲを再構築するためにはガンマ３が使用される）。原則的には、ＨＤＲ信号を完全に復元することができる。しかし、いくつかの問題が存在し得る。ＬＤＲグレーディングをレガシーＬＤＲディスプレイ上で良好な見かけのレガシー映像信号として使用できることが望まれ、またそれがＨＤＲ信号（例えば、ＨＤＲを強調するために一部の領域では非常に高いコントラストを有する可能性があり、又は反対に、低輝度レンジへのマッピング後は、一部の他の領域で低すぎるコントラストを有する可能性がある）から計算されることを考慮すれば、ＬＤＲが所望の通りに見えない可能性がある。当然ながら、グレーダーはトレードオフをすることができる。グレーダーは、ＬＤＲが適切に見え、また再構築されたＨＤＲが依然として十分な視覚的品質を有するようトーンマッピング関数を更に調整することを試み得る。しかし、グレーダーがこれから著しく外れ、異なるＬＤＲグレードを作成することも考えられる。少なくとも一部の領域において、例えばグレーダーは、顔の画素を任意に再配色し始め得る。そのような場合、ＬＤＲ信号からＨＤＲ信号に戻る予測はオリジナルのマスターＨＤＲグレード（このＨＤＲ＿ｅｎｃｏｄｅｄ＿ａｓ＿ＬＤＲグレーディング内に符号化されるはずであった）に適切に近く見えないだけではなく（ＰＳＮＲ等の数学的基準によって決定されるにせよ、心理視覚的に決定されるにせよ）、より深刻には、著しく異なる、異なるＨＤＲ見かけを与える若しくはＨＤＲ効果を全く有さない、又はＨＤＲレンダリング内に深刻な視覚的歪みが生じる等の可能性がある。したがって、そのような場合にはＨＤＲ再構築を更に変更しなければならない。本発明によれば、単に任意の変更を使用するのではなく、強い影響を及ぼし、特に多くの場合でＨＤＲ再構築がおそらくはＰＳＮＲ値に基づいてではなく心理視覚的に既に所望なものに比較的近いことを考慮する変更を使用すべきことを主張する。

補正は少なくとも２つの有用な種類に分類することができる。再構築されたＨＤＲ画像のルマが深刻に外れている、例えば、画素ルマがＹ＿ＨＤＲ＿ＭＡＳＴＲ２０４８であるべきはずなのにＹ＿ＨＤＲ＿ＲＥＣＯＮＳＴＲ１０２４である場合か、又は、例えば物体内にいくらか強いコントラスト又はテキスチャを導入するために小さな補正が実行されるべき場合である。小さな変更を加える他に、視覚的重要性の階層に従って変更を実行することができ、特に両方のシナリオを乗算補正によって取り扱うことができる。符号化されるオリジナルＨＤＲのＹ＿ＨＤＲ＿ＭＡＳＴＲが２０００だったとしても、ＨＤＲ＿ｅｎｃｏｄｅｄ＿ａｓ＿ＬＤＲ画素からトーンマッピングによって再構築されたＨＤＲ画素を係数２で乗算することができる。これは依然として４８（又は２％）の誤差を含むが、元々の１００％の誤差よりは遥かにましである。いずれにせよ、このような小さな誤差は心理視覚的にそれほど重要ではない可能性が高い（例えば光子ノイズ等のために常に画像ノイズが存在することを所与として）。ＬＤＲ符号化において過度に低いコントラストがあり、これがＨＤＲへのトーンマッピングによっても十分に復元されなかった場合、例えば１．５を掛けることによりそれを高くし、オリジナルと変更されたローカル平均との差（又は、乗算された画素と未変更の最初の画素との差）を補正し、画素４５０、４５２、４４９を６７５、６７８及び６７４に変更し、その後４５０、４５３、４４９に変更する。空間的に連続する又は一連の隣接する画素のための乗算補正を有する前例では、画素毎に乗算補正パターンを指定することもできる。そのシナリオでは、例えば低精度ＬＤＲ色空間において丸めにより完全に失われたテキスチャを導入することさえ可能である。例えば、平均輝度を変更することなく、所定のルマ９８０を例えば２．３、４、３．８、１．２等により再び乗算してもよい。

様々な実施形態が、要求される乗算補正を異なる賢明に最適化された態様で符号化する。例えば、精度の低い、最も重要なＨＤＲ効果の一見を取ることにより、１．２２２２３５等の任意の乗算係数は必要なく、よってこの追加データを符号化するのにわずかな追加ビットしか要さない。具体的には、このビット量はＨＤＲ＿ｅｎｃｏｄｅｄ＿ａｓ＿ＬＤＲ符号化（既に非常に効率的である）を大きく越えて変更されるべきではない。多くの場合、いくらかの差があるにせよ、グレーダーが改良が必要ないと結論付ける可能性があるため、一部の画像（の部分）については変更は時々にしか必要ないと予測されるからである。しかし、この場合、符号化される部分は典型的には重要なＨＤＲ見かけ（例えば、金属物体をより輝くように又は高コントラスト見えるようにする等に）、ＨＤＲ効果、邪魔であると考えられる符号化歪みの緩和等である。出願人は、乗算が例えばカラーチャネルＲＧＢの変更を介して間接的にルマに作用するシナリオもカバーすることを意図するが、これらの特徴を請求項に加えると非常に読みづらくなる。

本原理のいくつかの興味深い変形例は特に以下の通りである。

所定の乗算係数は、画像符号化（ＬＤＲ＿ＣＯＮＴ）に関連付けられたメタデータ内に保存され、復号方法は、メタデータにおいて、当該空間領域のためにメタデータ内に少なくとも１つの乗算係数が符号化されている画像符号化（ＬＤＲ＿ＣＯＮＴ）の空間領域を定める情報を読み取るステップを含み、空間領域の幾何学形状がメタデータ内に符号化されている（５０３、５０４、５０５）、画像符号化を復号する方法。

幾何学領域が多様に符号化可能であることが理解され、例えば、中心（ｘ，ｙ）及び２つの軸によって楕円を定めてもよく、第１のトーンマッピング戦略によって予測された中間画像の対応する領域が、例えば単一の乗算係数によって乗算変更されなければならず、又は、例えば１０画素毎に異なる乗算係数が使用される部分領域からそれを構成してもよい。

所定の乗算係数は、画素又は画素のグループ毎に乗算係数を備える乗算係数アレイ（５０６）内に含まれ、アレイは空間領域幾何学形状の符号化に対応して定められる、画像符号化を復号する方法。

例えば、楕円内に含まれる走査線に対応する１Ｄアレイ内の画素毎に１つの乗算係数を指定してもよく、例えば、第１のラインでは２つの画素、次は６つ等である。しかし、例えば乗算係数が例えば幾何学領域内の２つの連続画素のために使用されるよう関係を定めてもよい。

乗算係数アレイ（５０６）内の乗算係数は、定義テーブル（５２０）のインデックスとして符号化され、定義テーブルはインデックスに対する実際の乗算係数を保持する、画像符号化を復号する方法。

これは、最も有用な実際の乗数係数を符号化するために少数のインデックスのみが使用されることを可能にする。このようにすることで、アレイ５０６は例えば乗算係数毎にわずか４ビットで符号化され得る。

定義テーブル（５２０）は、定義テーブルと共に例えば特定の画像ショット等どのようなルマ変更の場合に定義テーブルが使用されるべきかを特徴付ける記述子（５３０）に関連付けられる、画像符号化を復号する方法。

乗算係数に記述子を与えることは、それらが特定の所定のシナリオ時に使用又は再使用されることを可能にする。例えば、映画符号化の最初に、映画のどの時点で出現しようと、暗環境領域の特定のクラスに対して使用されるべき定義テーブル（５２０）を定めることができる。しかし、他のかかる暗環境領域クラスは異なるテーブルを使用してもよい。更に、それらを条件付きで決定してもよく、例えば、現在のショットでは選択されているテーブルが使用されるべきであるが、例えばＨＤＲ＿ＰＲＥＤの画素ルマが値Ｌｘ未満の場合にのみであり（他の場合では、符号化されていたとしても乗数係数を無視してもよい）、又は、符号化インデックスの一部が無視されてもよく、これはテーブルの再使用を可能にし、この画像ショットの前に例えば「２９〜３１不使用」等と指定されてもよい。また、これは以前にグレーディング及び符号化された画像信号Ｓ＿ｉｍをトランスコードすることを可能にする。

復号は更にウィンドウタイプ（５３１）を読み取り、ウィンドウタイプ（５３１）は、そのウィンドウタイプ（５３１）に関連付けられた空間領域が、当該ウィンドウタイプ（５３１）に対応する記述子（５３０）に関連付けられた定義テーブルによって符号化された乗算係数を有することを示す、画像符号化を復号する方法。これは、定義テーブル又はその部分を画像の部分とより密にリンクするために使用することができる。

中間画像（ＨＤＲ＿ＰＲＥＤ）の少なくとも一部の画素のルマを変更するステップは、乗算を、出力画像（ＨＤＲ＿ＦＩＮ）のローカル平均輝度が中間画像（ＨＤＲ＿ＰＲＥＤ）のローカル平均輝度から所定の割合のずれ内に含まれる乗算戦略に制約する態様で実行される、画像符号化を復号する方法。これは、乗算変更戦略の方程式に平均輝度又は同様の値を導入することにより多様に実現され得る。

乗算係数がそのような制約された乗算に関連して定められることを示すタイプ値５０８が読み取られる、画像符号化を復号する方法。複数の変更戦略のタイプをそのように符号化することができるが、そのうちの２つの興味深いものを説明のために述べる。

乗算係数は、一連の１次元又は２次元位置座標にわたる乗算係数の関数的定義としてメタデータから読み取られる、画像符号化を復号する方法。特にそれらが一定の形状に従い、概してそれらがそれほど正確である必要がないことを前提として、乗算係数を関数的形態として符号化してもよい。例えば、係数１、４、９又は１、５、８を一連の位置にわたって２乗関数として符号化してもよい。しかし、一般的には、乗算係数の数値コード化が好ましい。

ハイダイナミックレンジシーンのオリジナル画像（ＨＤＲ＿ＯＲＩＧ）を第１の輝度ダイナミックレンジ（Ｒ＿ｏＬＤＲ）に対応する画像符号化（ＬＤＲ＿ＣＯＮＴ）として符号化する方法であって、
−所定のトーンマッピング戦略（ＦＬ２Ｈ）により、画像符号化（ＬＤＲ＿ＣＯＮＴ）内の画素の少なくともルマを第２の輝度ダイナミックレンジ（Ｒ＿ｏＨＤＲ）に対応する中間画像（ＨＤＲ＿ＰＲＥＤ、ＧＲＡＤ＿１ＬＤＲ）内の画素のルマにトーンマッピングするステップと、
−中間画像（ＨＤＲ＿ＰＲＥＤ、ＧＲＡＤ＿１ＬＤＲ）内の画素カラーと指定された第２の画像（ＨＤＲ＿ＯＲＩＧ又はＧＲＡＤ＿ＦＩＮＬＤＲ）の画素カラーとの間の差を分析することにより、中間画像（ＨＤＲ＿ＰＲＥＤ、ＧＲＡＤ＿１ＬＤＲ）の少なくとも一部の画素のルマに掛けるための乗算係数を決定するステップと、
−画像信号（Ｓ＿ｉｍ）内に画像符号化（ＬＤＲ＿ＣＯＮＴ）、トーンマッピング戦略（ＦＬ２Ｈ）を指定するデータ、及び乗算係数を指定するデータを符号化するステップと
を含む、方法。

ＨＤＲ信号Ｓ＿ｉｍがＨＤＲディスプレイに主に適合する場合、これは例えば低ダイナミックレンジ予測の変更を符号化することができる。このシナリオでは、システムは、ＨＤＲ駆動画像８ｂｉｔ＿ＨＤＲ（又は任意のＨＤＲ符号化、例えば、線形輝度ＨＤＲ表現に対して、何らかの定義トーンマッピング関数を備える１０ビット）として使用可能な８ビットの輝度をダウンマッピングすることにより、接続されたＬＤＲディスプレイ用のＬＤＲ画像を導出することができる。しかし、典型的には、エンコーダは当然ながらレガシーＬＤＲシステム上で単純に使用可能なＬＤＲ＿ＣＯＮＴを符号化することができ、その場合、ＨＤＲ画像が中間として予測され、乗算係数がそれをＨＤＲ＿ＯＲＩＧに近づくよう変更する役割を果たす。すなわち、これは、第１の輝度ダイナミックレンジ（Ｒ＿ｏＬＤＲ）は、典型的には５００ニット以下のレンジのピーク輝度に対応するローダイナミックレンジであり、第２の輝度ダイナミックレンジ（Ｒ＿ｏＨＤＲ）は、少なくとも７５０ニットのピーク輝度を有するハイダイナミックレンジである、ハイダイナミックレンジシーンのオリジナル画像（ＨＤＲ＿ＯＲＩＧ）を符号化する方法に対応するであろう。

−第１の輝度ダイナミックレンジ（Ｒ＿ｏＬＤＲ）に対応する画像符号化（ＬＤＲ＿ＣＯＮＴ）を取得するためのデコーダ（４０２）と、
−トーンマッピング戦略の指定を取得して、トーンマッピング戦略（ＦＬ２Ｈ）を画像符号化（ＬＤＲ＿ＣＯＮＴ）に適用することにより、第２の輝度ダイナミックレンジ（Ｒ＿ｏＨＤＲ）に対応する中間画像（ＨＤＲ＿ＰＲＥＤ）を生成するためのトーンマッパー（４０３）と、
−少なくとも１つの乗算係数を含む乗算係数データ（Ａ＿ＭＵＬ）を取得して、少なくとも１つの乗算係数を中間画像（ＨＤＲ＿ＰＲＥＤ）内の少なくとも１つの画素のルマと掛け合わせることにより、出力として出力画像（ＨＤＲ＿ＦＩＮ）を生成する画素カラー変更部（４０４）と
を含む、ＨＤＲ画像復号装置（４０１）。

−ハイダイナミックレンジシーンのオリジナル符号化（ＨＤＲ＿ＯＲＩＧ）を取得するための入力部と、
−オリジナル符号化（ＨＤＲ＿ＯＲＩＧ）を第１の輝度ダイナミックレンジ（Ｒ＿ｏＬＤＲ）に対応する画像符号化（ＬＤＲ＿ＣＯＮＴ）に変換するための、及び、画像符号化（ＬＤＲ＿ＣＯＮＴ）をトーンマッピングデータ（ＦＬ２Ｈ）内に符号化されたトーンマッピング戦略を用いてトーンマッピングすることにより、第２の輝度ダイナミックレンジ（Ｒ＿ｏＨＤＲ）に対応する中間画像（ＨＤＲ＿ＰＲＥＤ）を決定するためのグレーディングマネージャー（７０２）と、
−中間画像（ＨＤＲ＿ＰＲＥＤ）を指定された第２の画像（ＨＤＲ＿ＯＲＩＧ又はＧＲＡＤ＿ＦＩＮＬＤＲ）と比較し、両画像間の差に基づき、中間画像の少なくとも１つの画素のルマと掛け合せられると、中間画像（ＨＤＲ＿ＰＲＥＤ）内の画素のカラーより第２の画像内の対応する画素のカラーに近い出力画像（ＨＤＲ＿ＦＩＮ）の最終的画素カラーを生成する少なくとも１つの乗算係数を含む乗算係数データ（Ａ＿ＭＵＬ）を導出するためのグレーディング差比較器（７０４）と、
−画像符号化（ＬＤＲ＿ＣＯＮＴ）、トーンマッピングデータ（ＦＬ２Ｈ）、及び乗算係数データ（Ａ＿ＭＵＬ）を出力画像信号（Ｓ＿ｉｍ）内に符号化するための符号化ユニット（７１０）と
を含む、ＨＤＲ画像符号化装置（７０１）。

人間のカラーグレーダーが少なくとも画像符号化（ＬＤＲ＿ＣＯＮＴ）及びトーンマッピング戦略を決定することを可能にするためのユーザーインターフェイスユニット（７０３）を含む、ＨＤＲ画像符号化装置（７０１）。

当業者は、本発明の構成要素がソフトウェア、又は、
−第１の輝度ダイナミックレンジ（Ｒ＿ｏＬＤＲ）に対応する画像符号化（ＬＤＲ＿ＣＯＮＴ）と、
−画像符号化（ＬＤＲ＿ＣＯＮＴ）を第２の輝度ダイナミックレンジ（Ｒ＿ｏＨＤＲ）に対応する中間画像（ＨＤＲ＿ＰＲＥＤ）にトーンマッピングするために使用されるトーンマッピングデータ（ＦＬ２Ｈ）と、
−中間画像（ＨＤＲ＿ＰＲＥＤ）内の少なくとも１つの画素のルマと掛け合わせるために使用される少なくとも１つの乗算係数を含む乗算係数データ（Ａ＿ＭＵＬ）と
を含む、ＨＤＲ画像信号等、更に多様に具体例され得ることを認識するであろう。

又は、そのようなＨＤＲ画像信号を含むデータを保存可能な、例えばＢｌｕ−ｒａｙ（登録商標）ディスク等のポータブルデータデバイス。

本発明に係る方法及び装置の上記及び他の側面は、以下に説明される実装形態及び実施形態、並びに添付の図面を参照して説明され、明らかになるであろう。図面は単により一般的な概念を例示する非限定的な特定の具体例であり、図中、破線は構成要素がオプションであることを示すために使用され、破線でない構成要素が必ずしも必須であるとは限らない。破線は必須であると説明される要素が物体の内側に隠されていることを示すために、又は例えば物体／領域の選択肢（及びそれらがディスプレイ上に如何にして表され得るか）等無形のものを表すためにも使用され得る。

図１はＨＤＲシーンを概略的に示す。 図２ａは、ＨＤＲシーン内の物体輝度を概略的に示す。 図２ｂは、図２ｂが如何にして図２ａに示されるような物体輝度が１つの可能なＬＤＲルマ符号化によりコード化され得るかを、すなわち、ＬＤＲ画像内のそのようなルマ値のヒストグラムを概略的に示す。 図３ａは、ＨＤＲシーンの画像の異なる表現の間のマッピングチェーンを概略的に示す。 図３ｂは、図３ａに示されるような２つの異なる表現の間のマッピングのために使用され得るグローバルトーンマッピング関数の一例を示す。 図４は、本発明の原理に係るＨＤＲ画像の可能な符号化を取得し、且つＨＤＲディスプレイに接続される受信側の復号装置を概略的に示す。 図５は、画像信号の一部の実施形態内に、一部の実施形態具体例のために必要なデータの一部が如何にして符号化され得るかを概略的に示し、当業者は、このデータの一部が選択的、追加的、オプション等であり得ることを理解する。 図６は、ＨＤＲ＿ｅｎｃｏｄｅｄ＿ａｓ＿ＬＤＲ符号化技術が使用される場合に、第１及び第２の輝度ダイナミックレンジ符号化の間の最適化マッピングの後に乗算変更の適用の一例が如何に機能し得るかをガマット図で概略的に示す。 図７は、本原理に係るＨＤＲ画像符号化装置の可能な具体例がどのように見えるかを概略的に示す。 図８は、ＬＤＲ／レガシーディスプレイのために使用可能なグレードが主要画像テキスチャ画素データとして符号化されるシナリオとは別の本概念を適用する符号化例を概略的に示す。

図１は、コンテンツ製作者がＨＤＲシーンをデザインし得る方法の典型例を概略的に示す（写真用途、映画、現場取材、コンピュータグラフィックス生成等）。テーブル１０５等の物体を含む平均的に照らされた室内が通常存在し、その輝度を符号化するルマは通常符号化のコードレンジの中央付近のどこかに落ちる（例えば、ルマ１２８付近）。かなり高い輝度の領域が少なくとも１つ存在し、すなわち、このケースでは窓１０１のシェード（バー１０２）を介して見られる日が差す外界１０３である。シェードのために部屋は相当により暗い可能性がある。屋外には家１０４等の明るい物体が存在し、これらは通常コードレンジの上部のルマで符号化されるべきである。室内のあまり光が当たらない影領域には、例えばバスケット１２０等の非常に暗い物体が存在し得る。また、カラーレンダリングに関してＨＤＲディスプレイ及びＬＤＲディスプレイの両方で極めて重要な領域が存在する。この例では人１１０である。ＬＤＲイメージングのためのＬＤＲシーンでは、通常、顔にいくらかの光構造が存在するが、それほどコントラストが高くない（例えば３：１）よう照明を最適化するが、対照的に、この照明シナリオでは顔の上に明るい日差しの縞模様１１２及び暗い影の縞模様１１１が存在し得る。

図２ａは、輝度ヒストグラムの観点からシーンが比色的にどのように見えるか（ｎは輝度Ｌ＿ｓｃを有する画素の数）、及び、説明の簡潔さのためにレンジにわたって線形であると仮定するカメラにより如何に捕捉され得るかを示す。実際には、現実のシーンの代わりに、対応する画素に関してシーン輝度がコード化された代理輝度Ｌ＿ｓｃ（例えば、ＸＹＺカラー表現）を含み、既に捕捉され且つ典型的にはＨＤＲグレーディングされたオリジナル又はマスターＨＤＲ画像を考えることができる（実践的には５００００ニットで終わり、１０億ニットの太陽はこれにクリッピングされる）。外界の物体の輝度はローブ２０３によって概括される。バスケットはローブ２０４に対応する。顔の上の暗い縞模様及び明るい縞模様はそれぞれローブ２０１及びローブ２０２に対応する。古典的なＬＤＲカメラ撮像は典型的にはサブレンジＲ＿Ｇｒａｂ＿ＬＤＲ−Ｃｌａｓｓを取り、典型的にはガンマ関数Ｙ＿ＬＤＲ＝ａ＋ｂ＊Ｌ＿ｓｃ＾ｇａｍｍａを用いてこれらの輝度を［０，２５５］内のルマにマッピングする。レンジＲ＿Ａｂｏｖｅ内の全ての輝度が２５５にクリップされる。本発明を説明するこの例示的な実施形態では、８ビット符号化Ｙ＿ＬＤＲ＿ａｕｔからＨＤＲ表現をほぼ同一に復元できなければならないので（すなわち、マスターＨＤＲ表現に近く）、全ての値をＨＤＲレンジＲａｎｇｅ＿ＨＤＲ内に符号化しなければならない。これは様々なローブを知的にシフトさせること及び圧縮することを含む。図２ｂの例では、対象とする視聴条件では暗い領域についてはそれほど高い視覚的再現の品質が要求されないことが予期されるため、暗い領域に対して狭いレンジ２８４のコードが割り当てられ、例えばＹ＿ＬＤＲ＿ａｕｔ＝｛０，１，２，３，４，５｝のみが可能である。（縞模様を生じたり、誇張されたＤＣＴ圧縮歪み等を呈してはならない）家１０４のレンガの詳細等、日によって照らされた屋外環境の全テキスチャの十分な情報をコード化するには十分なコード値が必要なため、明るい物体のローブ２８３には相当なサブレンジを割り当てた。顔領域はルマコードローブ２８１及び２８２に対応する。低い方のローブの上限ルマＹ１は依然として明るく照らされた顔の高い方のローブ２９３の下限Ｙ２からいくらか離れていると仮定する。これはバランスを考慮した選択である。コーディングの観点からは、ＨＤＲ画像を復元するために当然ながらコードローブが接触していてもよい。この場合、これらを要求されるＨＤＲ予測画像レンジに投影するためにはいくらかより伸長させるトーンマッピングが必要になる。しかし、Ｙ＿ＬＤＲ＿ａｕｔ符号化がＬＤＲデコーディング及びレンダリングチェーンを介して直接送信される場合でも、良好な見かけのＬＤＲ画像が必要であることに留意されたい（この場合、ルマは典型的にはガンマ２．２マッピングを介して出力ディスプレイ輝度に変換される）。すなわち、制限的なＬＤＲディスプレイ上でもこのＨＤＲシーン照明がいくらか得られるよう、顔を十分に高コントラストに見せるためにこの距離が必要な可能性がある。しかし、一方、ＬＤＲレンジがそれほど多くのコード値を含まないという事実のみからしても、この物体内コントラストはそれほど高くあるべきでもない（日が差す屋外のために依然として上方に十分なコード値が必要だからである。よって、所与の制約下で最も適切なレンダリングは、更なるコードの損失なくそれらをＹ４で開始させることであり、これは、いずれにせよそこではもはや正確なＨＤＲレンダリングが不可能なことを前提とする）。ＨＤＲダイナミックレンジ及びＬＤＲダイナミックレンジの２つのガマット等の側面の非線形性により、画素カラーの色座標も関与することに留意されたい。いずれにせよ、この顔が非最適にマッピング／符号化される場合、例えば、明るい部分がバニラのようで暗い茶色の部分がチョコレートのように見えるチョコアイス人間のような何かが見られ得る。このような場合、グレーダーは間違いなくグレーディングを続けて何らかの方法でより良いものを得るべきであり、すなわち、理想的には復元可能なＨＤＲをそれほど変更することなく（マスターＨＤＲを正確に復元可能にするよう、原則的には（ほぼ）完全に可逆であるべきである）、ＬＤＲグレード及び対応するマッピング又は一般的な変換が改良されるべきである。

図３ａは、ＨＤＲ＿ｅｎｃｏｄｅｄ＿ａｓ＿ＬＤＲ技術の実施形態における符号化及び特定のＨＤＲディスプレイを駆動するのに適したＨＤＲ画像のそのような生成を示す可能な処理チェーンを示す。コード０．０と１．０（又は実際には例えば１．００００００００）との間の小数点精度レンジ３０１に沿って符号化されたと仮定するマスターグレーディング後ＨＤＲ画像ＨＤＲ＿ＯＲＩＧから開始する。シーン物体の位置及びサイズは、符号化に対応してレンダリングを行うディスプレイ上でシーン物体がカバーするサブレンジを概略的に示す。ＨＤＲ＿ＯＲＩＧについては線形輝度空間を仮定する。窓（又は少なくとも明るい屋外）はＨＤＲディスプレイが生成可能な最も高い、ピーク輝度ではないかもしれないがそれに近い輝度のどこかに横たわり、よって本物の太陽が輝いているような見かけが得られる。バスケットはピーク輝度の最も低いパーセントの部分にマッピングされるので非常に小さいが、３５００ニットの場合、依然としてこれらの暗いテキスチャの可視性は良好である。顔は非常に高コントラストなＨＤＲ照光見かけが実際に存在したかのようにグレーディングされ、すなわち、顔は非常に明るいから比較的暗いまでの相当なサブレンジに及ぶ。これは（マスターグレードを作成する際にグレーダーが使用したものであり得る）その３５００ＨＤＲディスプレイ上では許容できる見かけを有し得るが、他のディスプレイ上では好ましくない見かけを呈し得る。ここで、左方向に示されるように、これらの小数点は常に８ビット表現（レンジ３０２を有するＨＤＲ＿８ｂｉｔであり、これは当然ながら３０１と同じ輝度レンジに対応するが、マッピング関数に応じたコードレンジを有する）に直接量子化することができる。しかし、この直接適用技術では（線形表示、又は、少なくとも、例えばＸＹＺ画像の１対１線形直接の正確な色再現としてふるまうチェーンの残りの部分での較正を仮定）、実際には物体の輝度をレンジに沿ってシフトするマッピングは必要なく、単なる２進数への丸めが必要なだけである。

右に向かい、ＨＤＲ＿ｅｎｃｏｄｅｄ＿ａｓ＿ＬＤＲ符号化に到達するための可能な方法を示す。適切な見かけのＬＤＲレンダリングを得なければならないので、物体の画素の輝度をシフトするトーンマッピングＦ＿ＴＭ１を適用しなければならない。例えば、暗いバスケットを見やすくするために暗いバスケットのレンダリングディスプレイ出力輝度を伸長しなければならず、これはそれをより多くの低ルマ値に割り当てることによって実行される（第１のＬＤＲ予測のより大きなサブレンジにわたるより大きなバスケットによって概略的に示される）。窓はＬＤＲレンジの上端のより少ないＬＤＲルマに淡色化される。また、依然としていくらか暗い影の縞模様が見えるよう顔のコントラストを低減しなければならない可能性があるが、これらは平均で明るい縞模様より例えばわずか２倍暗いだけである。このＬＤＲ表現ＬＤＲ＿８ＢＩＴ＿ＡＵＴＯへの最初のトーンマッピングは、例えば画像の全ての（局所的物体）統計を見て、その後、物体サブローブのコード値の数を低減する不利益（例えば、ヒストグラムを更に分析してもよく、２つの値が最大あたりに存在しなくてはならず、ヒストグラム最大の間では、例えば空間勾配指標又はテキスチャ指標、例えば複雑性指標及び量子化における変形を量子化するパラメータ等から計算される整数値に基づいてコード数が決定され得る）対セミグローバルコントラストにおける変更の不利益を評価する数学的処理（例えば、あるサイズにかけて平均を取り、様々な輝度指標を決定する等）を考慮してマッピング関数を決定する自動的アルゴリズムによって実行され得る。これは多くのショットについて、特に実際の比色的（ｃｏｌｏｒｉｍｅｔｒｉｃａｌ）見かけがそれほど重要ではない場合（例えば、それほど見る必要がない暗い森と、光形状が高ければ何でもよい輝度の単一の値に容易に量子化され得る森の前方の電灯）に適切な結果を与え得る。しかし、他のショットでは、ＬＤＲグレード及びＨＤＲ／ＬＤＲ符号化（例えば、Ｂｌｕ−ｒａｙ（登録商標）ディスクに保存するための）の最終的な責任を負う人間のグレーダーは満足しない可能性がある。その場合、異なるグレーディング及びＬＤＲディスプレイ上での見かけに到達するために、グレーダーは画像グローバルトーンマッピングを微調整し得る。このために、グレーダーは、ＨＤＲ予測を復元するために可逆である必要があるマッピング関数に変更を加える。２つの部分関数３２０及び３２１からなるこのようなトーンマッピングの一例を図３ｂに示す。当業者は、例えばデジタルであろうと少数であろうと、又は数学的関数であろうとルックアップテーブルであろうと、任意の第１の輝度コード化Ｙ＿１（例えば、ガンマ０．４５によって定められるルマＹ＝Ｌ＾０．４５）と任意の第２のコード化Ｙ＿２との間のこのような関数が如何にして構築され得るかを理解する。この例において、Ｙ＿１をＨＤＲ＿ＯＲＩＧの小数符号化として、Ｙ＿２をＬＤＲ＿８ＢＩＴ＿ＡＵＴＯ符号化として仮定する。顔が３２１部分内に存在する場合、グレーダーは例えばその部分の傾きを小さくすることを検討し得る（単調可逆に保ちながら）。より多くのコード値を復元しなければならない場合、これは低い方のマッピング３２０にも影響を及ぼし得る。図３ａでは、グレーダーが、８ビットＬＤＲ＿８ＢＩＴ＿ＡＵＴＯ符号化を、自身のローカル代表的ＬＤＲディスプレイ上で最適な見かけを有する、自身が好む符号化ＬＤＲ＿ＣＯＮＴに変更すると仮定した。しかし、当然ながら、精度をより高めるために、グレーダーは通常、高精度小数点にマッピングを適用する。理想的には、グレーダーはこの問題を画像グローバルマッピング関数を正確に調整することによって解決することができ、これは自動アルゴリズムが定めたもの、及びそれが如何に微調整されたかによって得られる最終的な関数になる。しかし、グレーダーがそのような関数を決定できない又はそれに到達することができない理由が複数存在し得る（例えば、顔を微調整しているとき、グレーダーは画像内の又はそのマッピングは連続する画像のショットに使用する予定であれば他の画像内の他の色に悪影響を及ぼしているからである）。その場合、グレーダーはより複雑な比色的変更、例えば顔に対する局所的作業を適用し得る。グレーダーがＬＤＲ＿８ＢＩＴ＿ＡＵＴＯ内の画素の一部を変更して、髭が描かれている最終ＬＤＲ＿ＣＯＮＴをもたらすことにより、これを記号的に示した。当然ながら、オリジナルコンテンツ製作者は通常グレーダーが自身のコンテンツにこのような過激なことをすることを許さないが、単純な可逆チェーンＨＤＲ＿ＯＲＩＧ−＞ＬＤＲ＿ＣＯＮＴ−＞ＨＤＲ＿ＰＲＥＤに単純に従わない何らかの作業が実行可能であることを示すためのものである（作業ｃｒｒによって示す）。グレーダーは例えば暗がりの中の物体をもう少し知覚できるよう、又は、高品質のＬＤＲレンダリング及び完璧な品質のＨＤＲレンダリングの両方の要件を満たすためのソリューションとして、その物体に対して空間的鮮明化作業を実行してもよい。単純な可逆画像グローバルトーンマッピングの場合、ＨＤＲ＿ＯＲＩＧからＬＤＲ＿ＣＯＮＴに到達させるために最終的にマッピングされたものの全ての逆トーンマッピングを適用することにより、予測ＨＤＲ信号ＨＤＲ＿ＰＲＥＤとしてＨＤＲ＿ＯＲＩＧと全く同じ信号を得ることができ、又は少なくとも精度（及び（ＤＣＴ）動画圧縮）誤差まで可能である。しかし、論点は、ＨＤＲレンダリングの主要な品質ファクタは、通常、全ての物体が（大体）正しい輝度レベルに横たわるということであり、いくらかのマイナーな歪み又はアーティファクトはそれほど重要ではないということである。

ともかく、本発明によれば、誤差がＬＤＲ＿ＣＯＮＴにおける丸め（又は場合によってはクリッピング）であったにせよ、又は上記髭のような非可逆的変更であったにせよ、誤差はＨＤＲ＿ＰＲＥＤの少なくとも一部の画素、すなわち、典型的には誤差が生じると少なくとも許容できないと考えられる少数の画素（典型的には映画の少数のショットのみにおける非常に重要な物体）に乗算補正ｍｕｌｔｃｒｒを適用することによって補正され、これは最終的な高品質ＨＤＲ画像ＨＤＲ＿ＦＩＮをもたらす。

例えば例示的なＨＤＲ＿ｅｎｃｏｄｅｄ＿ａｓ＿ＬＤＲ（言い換えれば、ＨＤＲ表現のＬＤＲコンテナ符号化）に適用される場合に本発明が如何に作用するかをガマットの観点から見ると興味深い。この場合、符号化が、必ずしも画像が実際に表示されるディスプレイと同じ特性を有さなくてもよい何らかの基準ディスプレイに対応することが認識されるであろう。夫々の平行するカラー技術に属する全員がこれに関して同じように考えるわけではないので、これを明示する。当然ながら、どのＲＧＢ原色が選択されたかを知っている場合にのみ（例えば、古いＣＲＴのＥＢＵ原色、又は一部のＬＣＤのより明るい青色）、ＲＧＢ符号化はいくらかの明確な意味を有する。しかし、色符号化の究極的な意味に関連し得る更なる特徴が存在する（例えば、白色のピーク輝度、ルマと輝度との間の符号化マッピング関数（これは更に多くの異なる理由のためにそうであり得る）、環境を定めるパラメータなど視聴者の適合状態に関する側面等（更に、場合によっては特定のディスプレイ特性が別個に取得され、符号化に予め導入される））。しかし、全員がこれらのファクタが全ての適用シナリオに等しく関連すると考えているわけではなく、例えば、一部の人々はディスプレイ白色の色度は重要であるが、ピーク輝度についてはそれほど関連性がないと見なして（又は、色は相対比色的態様で適切にレンダリングされ得ると見なして、しばしばその関連性を無視して）必ずしも重要でないと考える可能性がある。例えば、印刷に関して、単一の最適印刷しか実行することができず、紙の白色が相対的最大輝度（１００％）のみを与える。しかし、印刷物内の色の実際の輝度（物理量）及び明るさ（心理視覚的な量）は、それが日向で、薄暗い室内で、又は場合によっては暗い夕方の環境内で見られるかに依存する。また、これは印刷された画像物体の彩度に特に影響する。図６ａは、（ＭＰＥＧ規格等の古典的なテレビカラー符号化の規定が準拠する）３原色ＣＲＴディスプレイのような種類の加色再現システムの典型的なガマットを示す。ほとんどの人が線形ＲＧＢ又はＸＹＺ色空間におけるＲＧＢカラーキューブに親しみがあるが、これが、そのようなディスプレイに対応するディスプレイガマット、又はそれを完全に及び線形に駆動する符号化の様子である。このテント形状は、底面を（ｘ，ｙ）等の何らかの色平面内の色三角として、「Ｚ軸」として線形輝度Ｌ＿ｏを取る場合に生じる。べき関数（例えばガンマ２．２等）又は類似の（比較的単純な）関数であるルマＹを使用する場合、いくらか変形された他のテントが得られる（典型的には、下部が伸長されて上部が圧縮されるが、ガンマ又はルマ符号化は実際には通常チャネル毎に作用するため、圧縮はどこでもいくらかは起こる（概略図なので、特定のルマ符号化関数の選択毎にテントをゆがめていないが、原理は同じで、各原色について真っ直ぐな柱を有し、その間で非線形な挙動を有し、これがディスプレイ又は符号化の白色に達するテント地を与えるテントであり、グレイ又は無彩色軸をテントの支柱として考えることができる））。間には、白色（及びルマ／ガンママッピングされたコードにおいて［１，１，０］の色符号化）よりいくらか低い輝度を有する黄色（Ｊ）等の色が存在する。図６ｂは、図６ａを符号化技術の観点から示す。（同じテント形状を有する）２つの８ビットコードがあるが、画像物体が異なる方法で符号化されている（特に輝度若しくは実際には符号化に関して論じる場合はルマと呼ばれるグレイ値。すなわち、その場合は、Ｙが無彩色のルマであり、ＣｒＣｂが主に色彩情報を有するチャネルであるＹＣｒＣｂコーディングと同様な用語を使用する）。これは、いくつかの物体の異なるサイズ及び位置によって示される。これは、符号化を（例えば、カメラから出力される）捕捉されたシーンの表現として見る場合、最初は奇妙に見えるかもしれないが、表現をディスプレイ指向性として考える場合、すなわち、特定のディスプレイのために画像物体カラーが最適な割り当てられたディスプレイ駆動（直接駆動されようと、又は最適出力画像レンダリングのための独自の最小の若しくは大幅なカラー処理を伴う駆動であろうと）のために使用される表現として考える場合、より理解可能である。例えば、より明るいディスプレイは明るくレンダリングできる色を多く有するので（ＬＤＲディスプレイは少数しか又は全く有さない）、ＨＤＲ符号化では明るい物体（太陽によって記号化されるが、実際には様々な反射率を有する複雑なテキスチャを備える物体であり得る）のためにより広いコード空間（すなわち、関連するガマット）を確保することが典型的であり得る。したがって、ＬＤＲ符号化は明るい物体のためにより少ない色を確保し得る。実際には、単なるＬＤＲ符号化の場合、一部のテレビ番組で現在起こるように、それらの色は厳しく（ソフト）クリップされ得る。しかし、我々の目的のためには、ＬＤＲコンテナ符号化（図６ｂでは８ｂＬＤＲ）から予測ＨＤＲ（８ｂＨＤＲ）への逆マッピングのために十分な詳細が保持されるべきであることに留意されたい。典型的には、顔によって示されるように、ＬＤＲレンジにて約１８％グレイの輝度を有する主要領域は、コードガマットの主要領域によって良好に表される。より暗いディスプレイ上での可視性を向上させるために、暗い物体はＬＤＲコンテナ符号化においてより多くの及び／又はより高いコードに割り当てられ得る（これにより、ＬＤＲ表示の視覚的品質に関する基準により重きを置く）。（ここでは色方向については詳述しないので、ルマ軸上の）コードレンジのサイズを変更することは、それらが互いにぶつかり、コード伸長物体（最終的なガマットマッピング及びディスプレイ特性にも依存するので、必ずしも色／輝度伸長ではない）の利益のために他の物体のレンジの一部が取り去られることを意味すると理解される。したがって、最小レンジを割り当てることが安全であり、例えば、低Ｙｌルマと高Ｙｕルマとの間に画像内の主要（良好に照らされる）物体に望ましい最小コード量を含む中央レンジＭＳＲを選択し、これに相補的に、光効果のための高レンジＨＳＲを定めることができる（及び、多くの場合は画像内の暗い領域を特別に取り扱うための低レンジＬＳＲも）。

図６ｃは、少なくとも色空間の一部の領域において他の／ディスプレイガマットＧＡＭ＿ＤＩＳではレンダリングされない可能性があるいくつかの色（例えば、純度／飽和度が高い）をレンダリング可能な第１のガマット（ＧＡＭ＿１）からマッピングしたい場合にガマットマッピングが典型的にはどのように見えるかを示す（単純さのために、１つの色相を通過する輝度及び飽和度の平面を示す断面図のみを示す）。このような技術では、通常、両方のガマットの白色を同じ点に固定する（単純さのために、白色点色温度には差がないと仮定する）。この場合、最適化タスクは、ガマット外の入力カラー（例えば、カラーＣｏｌ＿ｉｎ等）を、オリジナルの色から最小の視覚的色ずれでディスプレイガマット内の出力カラーに割り当てることである（又はその反対）。典型的には、依然として色の間にいくらかの違いが見られることが望ましいので、ディスプレイガマット境界を越える色範囲をディスプレイガマット境界に隣接し及びその内側の領域に移動させるために、何らかの圧縮割り当てプロフィールが使用される（但し、含まれる値を等しくする何らかの物理的又は視覚的量子化は存在し得る）。複数のガマットマッピングの種類が存在し、これらは異なる種類の色エラーをトレードオフする。例えば、ＧＡＭ＿ＤＩＳの上方に落ちるＧＡＭ＿１の領域については（特に、ＧＡＭ＿１の境界平行形状部分領域）、輝度軸に向かい、且つ低輝度Ｌ＿ｏに、例えば輝度軸上の選択されたグレイレベルに向かう投影が使用され得る。

本発明に係るＬＤＲコンテナＬＤＲ＿ＣＯＮＴ符号化では、図６ｄに示されるように、複数の異なる考慮事項が存在する。まず、当然ながらＬＤＲ＿ＣＯＮＴ符号化は任意のＨＤＲ符号化（このケースでは８ビットＨＤＲ予測）とは異なる原色色度によって定められ得るが、これは必須ではないので、ここではこれらの原色が同じであると仮定し、これは符号化に対応する基準ディスプレイガマットの両方が同じガマット底面を有することを意味する。ここでは、（輝度表現において）２つのピーク明るさ、及び原色信号に関して２つの最大輝度を有するディスプレイに対応するＨＤＲガマットを示す。これは例えば、ＬＥＤが調光可能であり、フルブースト時、例えばＴＬバックライトにより基準ピーク輝度（例えば５００ニット）に達するＬＤＲと同じＬＣＤパネルに２倍の輝度（例えば、１０００ニット）を与える白色２ＤＬＥＤバックライトを備えるＬＥＤディスプレイによって物理的に実現可能である。例えばバックライトの損失、非均一性、電力消費のための低減された駆動等の問題は、いずれも本発明の教示並びにその実施形態及び変形例から脱線する原理に基づく変更に対応するので、説明の単純さのために全て無視する。通常、ディスプレイは物理的駆動信号への符号化の最終的なマッピングにおいてこれらの全てに対処する。ＬＤＲが出力画像内でレンダリングする輝度領域の一部はＨＤＲディスプレイがレンダリングのために使用する輝度と重複するので、ＨＤＲレンダリングの物体を点線で示した。

本発明に係るアプリケーションでは、システムが輝度（及び対応するルマ）軸沿いに如何に挙動するかに主に関心を向ける。本アプローチをガマットの絶対輝度比較で表すのはこのためである。輝度又は明るさ／照度見かけを考慮して全ての符号化要素（例えば、グレーダーが使用するツール）を最適化し、これに関連する全てのファクタを包括的に特徴付ける。暗いバスケットは両ディスプレイでほぼ同様にレンダリングされるが、ＨＤＲバージョンにおいてやや暗い。依然として同レベルの環境照明下ではあり得るが、ＨＤＲレンダリングがＬＤＲレンダリングシステムよりやや暗い物体をレンダリング可能なレンダリングシナリオでＨＤＲ符号化が使用されることを仮定するからである。グレーダーが自身のＬＤＲコンテナ画像を定めるために、及び実際にはＨＤＲ＿ＰＲＥＤ画像が如何に解釈されるかを定めるために使用し得るマッピング（符号化規定マッピング）の多様性に基づき、バスケット画素のために要求される輝度に対応するルマはほとんど何でもよい。通常、ルマ符号化において、よってＬＤＲ＿ＣＯＮＴへの及びからのマッピングにおいても輝度間の順序が維持されると仮定する。しかし、これは、ＬＤＲバスケットがより多くの輝度値にわたるからと言って、ＨＤＲ符号化においてよりも多くのルマ値にわたることは示唆しない。８ビットＬＤＲ＿ＣＯＮＴでは例えば８ビットＨＤＲ＿ＰＲＥＤよりも小さいルマコードレンジに広がり得る。その場合、ＨＤＲ＿ＰＲＥＤバスケットはいくらかの欠損又は補間コードを有し得る。しかし、通常、２．２ガンマを介するＬＤＲディスプレイへの直接適用を予期するので、ＬＤＲ＿ＣＯＮＴ符号化ではＨＤＲ符号化でよりもより多くのルマコードが消費され得る。

良く照らされた顔等の中央領域物体は、ＬＤＲガマットの中央レンジあたりのどこかに通常符号化される（コード１２８、又は１８％グレイ、又はより大きい絞り）。ＨＤＲディスプレイではそれらが依然として普通に照らされた物体のように見えるよう同様の輝度でレンダリングされることが望ましい可能性がある。しかし、ＨＤＲディスプレイの高輝度レンジを主要物体をいくらか明るくするために分配し、いくらかのサブレンジを明るい物体のために残しておくことにより、ＨＤＲディスプレイの高輝度レンジを少し使用し得る。これは既に古典的なガマットマッピングとの更なる違いである。マッピングを視覚的類似性に従って、及びＬＤＲレンダリングと似た見かけ等の問題にのみ基づいて最適化したくない可能性がある。反対に、ＨＤＲ見かけを特定の方法でデザインすることによりマッピングをこれらのソリューションから遠ざけるように調整することが望ましい可能性がある。これは明るい物体に関して一層明確に理解される。その場合、図６ｃの背後の技術的理由においてのように、ＬＤＲレンダリング内の物体にＨＤＲレンダリング／符号化においてと同様な見かけを与えることはできない。更に、ＨＤＲはしばしば、物理的輝度記述が心理視覚的記述によって補われることが好ましい表示技術領域に関する（但し、駆動及び符号化技術については当然ながら輝度及びルマで十分であり、心理視覚的次元はスマートな自動アルゴリズムによってでなければ、通常は人間のグレーダーによって取り扱われる）。例えば、それ以上ではランプがＬＤＲでのように白色がかった反射物体（最善で意味認識のために脳内で明るいランプ物体として解されるが、とにかくそれは同じ知覚又は感覚ではない）ではなくＨＤＲレンダリングにおいて実際のランプのように見える特定のディスプレイ輝度が存在する。また、ＬＤＲガマット制約、及び好ましいＬＤＲ見かけの問題（何らかの理由のためグレーダーはＬＤＲが相当に異なって見えるようにすることを望む可能性がある）に加えて、当然ながらＨＤＲ＿ＰＲＥＤへの可逆マッピングの付加的ファクタがあり、これは、ＬＤＲ＿ＣＯＮＴ符号化においていくつのコードが特定の物体又はＨＤＲディスプレイの輝度／カラーレンジに割り当てられるべきか等の情報符号化に関する考慮事項に基づく更なる最適化制約を与える。

白熱電球は、相当に高い（ＨＤＲ）明るさを有し、またレンダリング時の物体テキスチャを前提にいくらかの明るさのばらつきを有するような物体を象徴する。全ての制約を前提として、これを顔を含む主要レンジに近いＬＤＲ＿ＣＯＮＴのサブレンジ上に符号化することが望まれる。ＬＤＲモニタ上では同じ見かけを与えない可能性があるが、これはいずれにせよ通常不可能であり、それでも少なくともＬＤＲでも良好な又は適切な見かけを与える方法で符号化される。例えば、その付近から出射する光線等、色の最終的な脳決定をもたらす好適に選択された周囲画素カラーとの組み合わせにより、ＬＤＲでも十分にランプのように見える可能性がある。ＨＤＲディスプレイガマットでは、そのような様々な明るい物体を顔等の主要物体の輝度レンジの十分上に配置する相当な自由があり、印象的なＨＤＲ見かけを与える。そして当然ながら、それらの輝度に対応するのはＨＤＲ＿ＰＲＥＤのルマである（８ビット符号化であろうと又は好ましくは小数点［０，１］符号化であろうと、単純さのために線形であると仮定し、すなわち、これは、例えば画像処理ＩＣの中間表現においてのように、ディスプレイレンダリング出力輝度に対して、コードの割り当てのために線形定義を有する）。

この明るい物体輝度レンジの上方には、ここでは太陽によって象徴される更に明るい物体が存在し、これは単一の色によってレンダリングされないと仮定する。ここで、ＬＤＲディスプレイ上でのＬＤＲ＿ＣＯＮＴ内の全てのより低いルマ物体の好ましいレンダリングを所与として（バスケット及び顔領域を上方に伸長する）、太陽のような少なくとも一部の物体をガマットの端に詰め込まなければならない可能性がある。その場合、逆マッピングは依然として太陽をＨＤＲディスプレイガマットの最も明るい領域に配置するが、ＬＤＲ＿ＣＯＮＴにおけるコーディングのより低い品質のため、逆マッピングはＨＤＲレンダリングで見られることが望まれる輝度／色をもたらさない可能性がある。ここで、太陽のＨＤＲ符号化においてより良い符号化、所望のＨＤＲレンダリングにより対応し、特にマスターＨＤＲ符号化において符号化された通りの符号化を作成するために、本発明に係る乗算変更ｍｕｌｔｃｒｒが役に立ち得る。

図５は可能な乗算変更の２つの有用な実施形態を概略的に示す。図５はデータユニットから構成されるように示される画像信号５００を概略的に示し、データユニットは通常ストリーミング中に連続して到着し、又はメモリの異なる空間セグメントに保存され得る。典型的には、例えば画像ヘッダー５０１の後に、又は場合によっては、ショット若しくは比色的再配置に関して同様に処理されるべき一連の連続画像の開始の指標の後に、画像の一部を変更するためのメタデータが存在する。リザーブコードワード５０２（例えばＰＯＳ）は乗算変更を適用する場所の情報を与え、また矩形の始点ｘ，ｙ及びその幅（リザーブコードワード５０５ではｗ）等の領域定義パラメータが存在し、それから、乗数テーブル５０６内の乗算係数のストリングを復号することができる。ＵＳ６１／６１５４９０のように、より正確な物体境界決定を可能にするルマ閾値等の他のコーディングが存在してもよいが、矩形アプローチが好まれ、補正の形状を乗算ファクタ又は係数内に定め得る。矩形は開始座標５０３及び５０４並びに幅５０５（すなわち、幅符号化コードワードを含むリザーブされた位置）によって指定され、これらは例えば現在画像の画像ヘッダー５０１の後に符号化され得る。また、ショットのどの画像で信号が適用されるべきかを示すタイムコード５１５が存在し（空間コードが既に特定の画像ヘッダーの後に存在し得るので、これは必須ではない）、更に当然ながら物体の追跡及び変形を可能にし得る複数の指定が存在し得る。当業者は、物体が画素精度で区分されることを可能にする閾値ルマｇ等の代替的なコーディングが存在し得ることを理解するだろうが、どのみちそれほど多くのデータを符号化する必要がない場合又は他の特別な要件が存在しない場合、通常は単純／ロバストな符号化が好まれ得る。当然ながら、例えばコントラスト伸長のために、画素の空間的集合に対して乗算係数が与えられてもよく、例えば物体の左側に１つ、物体の右側に別のものが与えられる（又は、例えば上記顔の明暗の縞模様）等してもよい。

興味深いことに、画像信号は通常更に、信号内でリザーブワードＭＵＬ＿ＴＰＹ等によって識別される乗算補正のタイプ指標５０７、及び少なくとも２つの値を有し得るその値を含む。

例えば、タイプ値５０８は「Ｍ＿ＮＯＲＭ」（又は「１」等の他の符号化）であり、その場合、乗算は基礎の画素ルマに単純に直接適用される。これは、例えば２５５にクリップされ、例えばＨＤＲへのマッピング後に１０１８にされるランプ内の構造を書くために使用され得る。その後、連続ルマ１０１８、１０１８、１０１８は、メタデータ内に符号化される典型的には画素ローカルファクタによって乗算される（例えば、ｘ１．２、ｘ１．４等）。ビットを節約するために、乗算係数が直接ではなく定義テーブル５２０を介して識別コードによって符号化されることが最適であり、これは他のメタデータ内に、例えばストリーム内に等間隔で又はディスク上のリザーブセクターに保存され得る。これは、何らかのＨＤＲ効果の深刻な劣化又は他の品質問題を有し得る予測と比較して画像をいくらか改良可能な場合、それはすでに良好なので最高の復元精度は必要ないため、また、画像に内在するノイズ等のファクタ、画像及びその物体の複雑性、及び人間の視覚の感度のためである。典型的には、人間のグレーダーは補正が行われるべきか否か及びその程度を決定し、典型的には乗算係数定義テーブル（５２０）に対する所定の識別コードを有するが、それがはるかに優れた改良を与える場合には、例えば所定のものの間のより正確な乗算係数を加える等、自身で微調整又は決定を行ってもよく、その後それらをシステム内にコード化してもよい（メタデータ内に符号化されていない事前合意されたものでなくてもよいが、それほど多くのデータが含まれていないのでどのみち含まれていてもよい）。典型的には、このようなテーブルの実施形態は何も行われないこと、すなわち１による乗算（同値）を意味するコードを１つ有し、そのために識別コード値０がリザーブされ得る。３２の可能な最適値が与えられる例えば６ビットコードワードの乗算係数の２次元ウィンドウの例（テーブル５０６）が与えられる。最も興味深い乗算係数は、当然ながらそれらをカラーオフセットするために使用するか（Ｍ＿ＮＯＲＭ）、又は物体のコントラストを伸長するために使用するか（ＡＶＧ＿Ｃ）に依存する。本例では、例えばＡ１はルマが１．２により乗算されるべきことを示し、Ａ２は１．４を示し、一部のコードは下方向の、すなわち０．９等の除算値を有してもよい。入力として空間的に隣接する画素の乗算結果の一部を取る関数式等、他の作業のために少数のコードがリザーブされていてもよく、値３０は第１のそのような関数又はアルゴリズムＦ１が使用されるべきことを示す。例えば、一部の画素が圧縮歪みを被っており、乗算によって修正する代わりに処理済みの隣接画素からスキップ及び補間されることが考えられる。最後に、セグメント５１０は例えば任意のＭＰＥＧ又はＪＰＥＣ標準規格等に従う例えば８ビット画像符号化のためのデータを従来通りに単に含む。

他の種類の乗算ＡＶＧ＿Ｃは、局所的平均を変化させない又はほとんど変化させないが、その周辺のテキスチャプロフィールを変化させるものである。これは例えば、比較的厳しい量子化及び／又は局所的グレイ値のためのトーンマッピング曲線の一部に小さい傾斜が存在する場合に有用である。正確な関数形状をコード化するコードの符号化は追加の値をもたらし得るが、ＬＤＲ＿ＣＯＮＴ内に符号化されたそれらの値を特定の方法で更に変更することにより、鮮明度及びコントラスト等の視覚的品質の大きな改良が容易に達成され得る。典型的には、移動平均と比較してブーストしてもよいし、又は個別のブースト値がそれほど変化しない場合、一連の画素の最初の画素の最初のルマを代表値として使用してもよい（但し平均の方がより正確である）。

その場合、一連の画素のルマをＡ＋ｄｌ１、Ａ＋ｄｌ２、Ａ＋ｄｌ３等と書き込むことができる。Ａはある領域のローカル平均である。その後ｄｌのみをブーストし、すなわち、Ｌｉ−Ａに一連の乗数ｍｉの対応するものを掛け、ここでＬｉは、ＨＤＲ＿ｅｎｃｏｄｅｄ＿ａｓ＿ＬＤＲ表現ＬＤＲ＿ＣＯＮＴのマッピングから得られたＨＤＲ予測の連続画素ｉ毎のルマである。その後、平均値を加えてコントラスト上昇（又は減少）ルマが得られ、すなわち連続出力ルマＬｏ＿ｉ＝Ａ＋ｍｉ＊（Ｌｉ−Ａ）が与えられる。

（フィルタベース定義）平均化符号化データ構造５１１は、上記発明の平均が如何にして符号化され得るかの第１の実施形態の例を与える（当然ながら所定の方法で、例えば、常に１１の画素にかけて計算を行うことも可能であり、更なる情報を符号化する必要がないよう、強力な境界を超える、平均化から差し引かれるべき不適切な値を考慮する）。９は、この画素に関して、その列沿いのローカル平均を決定するために９画素のウィンドウが使用されるべきであることを示し、すなわち、自身の画素ルマが前後の４つの画素ルマに加算される。０は、先に計算された平均がそれらの画素ルマの乗算変更に使用されることを示す。１１は、ローカル画素位置周辺の１１画素の平均化ウィンドウが使用されるべきことを示す。当然ながら、当業者は、例えば０のランレングス符号化等の他のデータ構造によっても符号化が行われ得ることを認識するであろう。

（区分ベース定義）平均化符号化データ構造５１２は、閾値を使用して、平均が如何にして計算され得るかを指定する他の方法を与える。例えば、現在のライン上で、典型的にはルマの縁部から次の物体に移動したことを示す値ｇ２に行き当たるまで、平均が実行される。ｇ１未満のルマ値は例えばノイズスパイクなので、平均化ウィンドウ沿いのそれらの値は差し引かれる（ある値以上の値を差し引くための同様な閾値が存在してもよい）。２列目の５は、このスキームが５つの連続する列に使用され、その後平均化処理を誘導するために新たなルマ閾値ｇ１１及びｇ１２が使用される。しかし、正確な平均を求めることはそれほど重要ではないことに留意されたい。不正確な周辺平均による不適切な明るさ変更等のアーティファクトを導入することなく構造がブーストされる限り、方法は機能する。グレーダーは、乗算パラメータを変更するか（最終的な見かけにも影響を及ぼす）、又は、より正確な符号化を選択する、例えばローカル平均が如何にして計算されるかの変更等のいずれかのオプションを有する。第３の代替的又は補助ローカル平均符号化データ構造は、特定の位置及びそれらの位置以降又はその周囲に使用するための平均値を直接符号化し得る。例えば、乗算変更が実行されるウィンドウ内の位置ｘ１，ｙ１とｘ２，ｙ２との間では平均Ａ１＝４５０が使用される。補助的な態様で、この符号化は、５１１内の符号化データよりも（直接位置平均定義）平均化符号化データ構造５１３内の符号化データを優先するアルゴリズムとして設計され、例えば、１１の位置では、そのようなウィンドウにかけて計算をする代わりに、５１３内のその位置のために符号化された最終的な平均値、例えばＡ２が使用される。グレーダーのためのユーザーインターフェイスにおいて、これらの乗算変更パラメータ値の大部分が、グレーダーが好むＬＤＲコンテナグレードを所与としたＨＤＲ予測とオリジナルＨＤＲとの間の差から自動的に計算される。当然ながら、これは、例えば顔ではより高品質の符号化、又は特定のグレーディングアクション若しくはモード等、異なる方法で取り扱われるべきウィンドウを選択するなど、グレーダーの特定のアクションによって誘導される。しかし、当然ながら、インターフェイスはグレーダーが様々な乗算補正パラメータをより直接的に、例えば大まか且つ容易にアクセス可能な態様で指定又は変更することも可能にする。例えば、グレーダーが不快な明るさ変更、例えば空間変更を確認する場合、グレーダーはその領域を選択して例えばわずかに暗くし、これにより、ＡＶＧ＿Ｃモードのモジュールが平均を例えばデータ構造５１３内で直接符号化することによって再定義し、それらを暗くさせる。

符号化の非常に重要な部分の１つは、乗算係数が如何に符号化されるかである。ＬＤＲにおいて非常に特殊にグレーディングされた領域を補正したい場合（ＬＵＴの特定の関数であり得る現在の例えば単純なトーンマッピングを所与としてオリジナルのＨＤＲの非常に近い近似に可逆的に予測され得ないよう）、要求されるローカルＨＤＲ信号の直線的な符号化によりそれを単純に置換できる。例えば、グレーダーは、完全に新しい画素が得られるようＬＤＲコンテナ内の顔を再配色した可能性があり、これは、オリジナルのＨＤＲに対して、ＨＤＲ予測における異なる顔をもたらす。この場合、例えばオリジナルのＬＤＲコンテナの画素カラー（すなわち、単純且つ容易に可逆なグローバルトーンマッピングによるオリジナルＨＤＲから８ビットＬＤＲへの第１のグレーディング）を部分的な第２の画像内に保存することにより、画像の例えばそれらのローカル部分（顔を含む）を単純に共符号化してもよい。しかし、本発明によれば、オリジナル画像を素早く近似する乗算値のみを保存することが好ましい。例えば、オリジナルＨＤＲが値４５０、４８２、３９０、５２０をローカルに保持し、ＨＤＲ予測がこれらの画素に対して４４０、４７０、３５０、５００を与える場合、それらを割り算することで容易に乗数を得ることができ、結果は１．０２３、１．０２６、１．１１４、１．０４となる。しかし、これらの乗数を直接符号化する必要はない。例えば、全てのローカルファクタが１．０２と可変の最後の桁によって変化する場合、あるインデックス、例えばその桁そのものによって最後の桁を符号化してもよい。したがって、この場合、例えば３は３による乗算ではなく１．０２３による乗算を意味する。したがって、ローカルに最適化を行うことができ、最適テーブルを定めることができる。しかし、予測値はどのみち正確である必要はなく、すなわち４５０、４８２ではなく４５３及び４８５等でもよく、それでも複雑且つダイナミックな動画にて良好な視覚的品質を与えるので、ＨＤＲ符号化に関してテーブルのより興味深い最適化が可能である。とはいえ、４５０に対して３の誤差は、より大きな誤差、例えば１０よりましであり、特に、大きな誤差が容易に又は更に不快なほどに視認可能で小さい誤差はそうでない場合はそうである。例えば、変色又は退色を与えるブロック歪みを、全てをオリジナルＨＤＲに又は少なくともより不快でない物体テキスチャに近づけるカウンターパターンで乗算することにより補正することができる（例えば、ブロックテキスチャを１より小さい係数で乗算してローカルコントラストを下げることによってより滑らかな色に）。しかし、更に、グレーダーはマッピングを特殊なＨＤＲ効果にさえ調整することができる。例えば、爆発は速い効果であり、炎のテキスチャは正確に再現されなくてもよいが、コントラスト等の一次の特性はそうされる必要がある。このため、グレーダーは、例えばそれらが特定の種類の物体又は特定の指定ウィンドウタイプ５３１のために使用されるべきことを示すテーブルの記述子５３０を有する、乗算変更のための１つ以上の最適テーブルを決定することができる。すなわち、ウィンドウの１つが炎タイプの場合、記述子＝炎又は＝１を有するテーブルが使用される。

したがって、この場合、乗数テーブル５０６は実際の乗数ではなく、定義テーブル５２０によって実際の乗数に変換される乗数のインデックスのみを含む。したがって、例えば、近似ファクタ２％（又は１．０２）、４％、１０％、５０％のみによってＨＤＲ予測値を補正することが可能であり得る。これは通常、所与の物体領域のために近似的に必要なものに最適化され、すなわち細かい補正及び粗い補正である。マッピングテーブルは、平均予測ＨＤＲルマと平均ＨＤＲオリジナルルマとの間の中間値を少なくとも１つ保持すべきであり、すなわち、オリジナルが４５０で予測が４４０の場合、乗数２％により既に大きく近づくことができる。これは、１．０２（又は、反対方向に補正をする必要がある場合は０．９８）×４４０＝４４８．８、すなわち４４９を与える。定義テーブル内に１％と３％の選択肢を符号化するだけで、乗数テーブル内に好ましい方の選択肢を符号化することを選択でき、すなわち、４４４より４５３の方が４５０に近いので、３％である。通常、定義テーブルは予測されるエラーの種類に応じて最適化される。小さい補正しか必要ない場合、３００％又は１０００％等の可能な補正は間違いなく定める必要がない。これは、例えば予測ＨＤＲ及びオリジナルＨＤＲの統計、特にそれらの画素毎のルマの差Ｙ＿ＨＤＲ＿ｏｒｉｇ＿ｉ−Ｙ＿ＨＤＲ＿ＰＲＥＤ＿ｉを見ることによって自動的に実行することができる。ヒストグラムが例えば多くのケースで平均４５０に対して差が１〜１０であり、わずかなケースで差がより大きいことを示す場合、定義テーブル５２０を０．５％、１％、２％、３％、４％・・・のためのコードによって定めることを決定してもよい（０．５％未満は適度な品質のために必要ない）。

テーブル内の乗算値（１より小さくても大きくてもよいし、又は正／負のパーセントでもよい）の他に、特別なコードが存在してもよい。例えば、ＨＤＲ＿ＰＲＥＤ内の現在の画素又は画素のセットが変更されるべきではないことを示すためにコード０が使用されてもよく、これは乗数１を符号化することと等価である。また、ある関数が使用されるべきことを示すコードが存在してもよく、例えば典型的には入力として周囲の乗算された／変更された画素値を取る。例えば、ＨＤＲ＿ＰＲＥＤ内の画素ルマ／カラーが要求値から大きく離れている可能性があり（例えば、定義テーブル５２０内に符号化されている範囲外の乗算を必要とする鋭いアーティファクトのために）、この場合、いくつかの周囲の画素を平均して再構築する方が良い可能性がある。しかし、これは異なるグレーディング、圧縮歪み等、ＬＤＲ＿ＣＯＮＴ信号の特異性を許容する。

図４は、画像レンダリングシステムにおけるＨＤＲ画像復号装置４０１の具体例の一例を示す。システムは、ディスプレイ４２０に接続され、画像処理、この場合は復号を取り扱うことができるボックスから構成されると見なす。当該復号装置は、例えばＢＤディスクプレイヤーであり、ディスプレイは２ＤのＬＥＤバックライトＬＣＤテレビであり得る。しかし、当業者は実施形態が多数の同等な変形形態によって実現され得ることを理解し、例えばいくつかを挙げると、復号装置４０１は他の国のネットワークサーバ上で動作してもよく（ＨＤＲ＿ＦＩＮは例えば特定の受信ディスプレイのための専用（及び場合よっては暗号化された）コードでもよく、フォーマッティング等は本特許の教示外とする）、ディスプレイはポータブルディスプレイ、又はレンダリング可能な輝度のより低い又はより高い輝度レンジのための別個のプロジェクタを有する投影システム等でもよい。実際には、復号装置４０１はディスプレイ自体に含まれてもよい。一実施形態では、ＨＤＲ画像を再構築するための符号化データはＢｌｕ−ｒａｙ（登録商標）ディスク４１０上に符号化されると仮定し、Ｂｌｕ−ｒａｙ（登録商標）ディスク４１０は、例えばＭＰＥＧ−ＡＶＣ、ＶＣ１、ＶＰ８、ｍｏｔｉｏｎＪＰＥＧ等によって符号化された、ＨＤＲ＿ｅｎｃｏｄｅｄ＿ａｓ＿ＬＤＲ（ＬＤＲ＿ＣＯＮＴ）符号化としての符号化画素画像データのための別個の第１のセクター４１１を含む。第２のセクター４１２は、典型的には映画のショット毎等に、そして例えばパラメータ関数、ルックアップテーブル、アルゴリズム指定など様々な態様で符号化され得る複数の参照トーンマッピング関数ＦＬ２Ｈ（色は自動的に処理されてもよいが、当然ながら、例えばＲＥＤチャネル上で色を取り扱う関数が存在してもよい）を典型的には含むメタデータを保持する。ＨＤＲ＿ＰＲＥＤへの１回の復号のみを説明するが、当然ながら、複数の最終信号、例えばＨＤＲ＿ＰＲＥＤが使用されるディスプレイよりも低いピーク明るさを有するディスプレイのためのＭＤＲ＿ＰＲＥＤを導出するためのデータが存在してもよい。第３のセクター４１３は、少なくともＨＤＲ＿ＰＲＥＤ内の画素のルマの乗算変更のための乗算データＡ＿ＭＵＬを保持する。上述したように、これは多様な態様で符号化され、例えば典型的には単一の又は一連の画素に対して乗数テーブル５０６が符号化され、乗数テーブル５０６は、何らかの符号化（例えば、Ｍ＿ｅｎｃ＝ｆ（Ｍ＿ｒａｗ）であり、ここでＭ＿ｒａｗは生の乗数（例えば１．４４）であり、ｆは、テーブル５０６内に直接符号化される係数Ｍ＿ｅｎｃを生成する所定の割り当て関数（例えば平方根）である）に従う乗数を直接保持してもよいし、又は、好ましくは同じ第３のセクター４１３内の近くに存在する他の定義テーブル５２０内に保存される係数のためのインデックスを保持してもよい。当然ながら、乗数テーブル５０６において特別なコードが付与される画素のために使用される第１の関数Ｆ１及び第２の関数Ｆ２（例えば、（Ｙ＿ｌｅｆｔ＿ｎｅｉｇｈｂｏｕｒ＋Ｙ＿ｒｉｇｈｔ＿ｎｅｉｇｈｂｏｕｒ）／２）等、他のメタデータが符号化されてもよい。このデータは少なくとも１つの入力部４０５を介して読み取られる。復号装置４０１は、典型的には、ＬＤＲ＿ＣＯＮＴ信号の典型的に画像圧縮されたバージョンを復号するよう構成されるデコーダ４０２を含み、復号は例えばランレンス復号、ＩＤＣＴ等を含み得る。トーンマッパー４０３は、トーンマッピング関数ＦＬ２Ｈを使用して要求されるＨＤＲ信号の予測ＨＤＲ＿ＰＲＥＤを導出する。その後、画素カラー変更部４０４は、Ａ＿ＭＵＬ内に符号化される通りに乗算変更を適用することにより、少なくともＨＤＲ＿ＰＲＥＤ内の画素のルマを変更する。これは、出力部を介して例えばディスプレイ（代わりに、これはストレージデバイス、クライアントコンピュータ等でもよい）に出力される最終信号をもたらす。その上、ディスプレイ４２０は、自身のディスプレイ画素カラー変更部４２１により、ＨＤＲ＿ＦＩＮ入力信号に独自の最適トーン／カラーマッピングを適用してもよく、これにより、このケースではＬＥＤバックライト及びＬＣＤ（２つのプロジェクタの例では、例えばそのＤＭＤの画素、また、例えばＯＬＥＤ等の単一のパネルソリューションのためには、その画素のための単一の駆動信号）のための駆動信号ＨＤＲ＿ＤＲＶの駆動値が最終的に与えられる。装置に第２の出力部４０６が存在し、例えばモバイルディスプレイ４３０に無線でＬＤＲ出力画像／映像ＬＤＲ＿ｏを提供してもよい。ディスプレイ４２０のハイダイナミックレンジ及びＬＤＲディスプレイ４３０がレンダリング可能なローダイナミックレンジＲ＿ｏＬＤＲが概略的に示されている。

図７は、ＨＤＲ画像符号化装置７０１の例示的な具体例を示す。重要なユニットの１つはグレーディングマネージャー７０２である。グレーディングマネージャー７０２は、グレーダーがグレーディングを実行することを可能にする。グレーディングマネージャー７０２は少なくともオリジナルＨＤＲファイルＨＤＲ＿ＯＲＩＧを取得し、これについては既にマスターＨＤＲグレーディングであると仮定し、すなわち、映画ディレクター等のコンテンツ製作者が美術スタッフと共に映画がどのように見えるべきかを決定したものを取得する（例えば、アクション映画の夕方のシーンにおいて、ディレクターは、建物に薄く濁った非常に暗い見かけを与え、通りにぶら下げられる看板の有色ＴＬチューブにはきつい高輝度且つ飽和した見かけを与えることを決定した）。通常、コンテンツ製作者は、当然ながら例えばＤＶＤ又はｙｏｕｔｕｂｅのグレーディングはその技術の制約及び特性を満たさなければならないが、全ての導出されたグレーディングが同様に見えることを望む。当然ながら、代替的な具体例は、ＨＤＲ＿ＯＲＩＧとして生のカメラ信号、例えば異なる露出時間が組み合わせられた２つのカメラ撮像の線形輝度色空間組み合わせを有してもよく、この場合、コンテンツ製作者はグレーディングマネージャー７０２を使用してマスターグレーディングを作成する。しかし、通常、これはワークフローの異なる時点で実行され得る。例えば、デジタル撮影の場合、（予備）グレーディングの一部は、ディレクターが自身の創作的構想及び実際のシーンがどのように見えたかの新鮮な記憶をまだ有する撮影日に既に移動している。しかし、グレーディングにおける膨大な作業及び多忙な撮影スケジュールのため、少なくともＢＤグレーディング等の下位のグレーディングに関する作業は、映画の完成後まで後回しにされる可能性がある。当然ながら、ＨＤＲ画像符号化装置７０１は、入力として複数のグレーディングを有してもよく、例えば、グレーダーが自身のＬＤＲ＿ＣＯＮＴグレーディングを多かれ少なかれ詳細に調整すべき第１のＬＤＲグレーディング、又は、異なるレンダリング条件下で若しくは映画の異なる美術バージョンのために使用される他のＨＤＲグレーディングであり得る他の任意のグレーディングＧＲＡＤＩＮＧ＿２等が既に存在してもよい。いずれにせよ、通常、グレーダーは、ＨＤＲ＿ＯＲＩＧに基づいてＬＤＲグレーディングを導出するためにグレーディングマネージャー７０２を使用する。したがって、通常、グレーディングマネージャーは、（例えばソフトウェア内で）第１のグレーディングと第２のグレーディングとの間でマッピングを適用することを可能にするユニットを含み、これは通常、任意のｘ位置にて曲線上の点をクリックして、それらを任意のｙ位置に移動させることにより任意のトーンマッピング曲線を作成することを含む。また、パラメータトーンマッピング曲線のファミリを循環する手段が存在してもよい。楕円等の領域を選択して（乗算変更を適用するための領域である必要はなく、それは楕円の包囲矩形等であり得る）、その後処理をローカルに行うための手段が存在してもよい。ＨＤＲ＿ｅｎｃｏｄｅｄ＿ａｓ＿ＬＤＲ又はＬＤＲコンテナグレーディングでは、典型的には、これらのマッピングは可逆性が保証されるよう制約が課されてもよい。例えば、グレーダーは、良好な質のＨＤＲ＿ＰＲＥＤを可能にする十分なデータ精度を残す関数、又は、少なくとも、可逆、すなわち区分的に単調な関数のみを構築してもよい。しかし、典型的には、グレーダーは可逆でないグレーディング作業を行うことが許され得るが、この場合、グレーダーが不可逆なグレーディングの量を制限するよう、それについて警告が発せられ得る。この場合、グレーダーは例えばいくつかの隔離された画素を任意にカラーリングすることにより続けることができる。グレーディングマネージャー７０２は、画像マッピング及び変更を実行するだけでなく、それに対応する変更データをトラックするよう構成され（例えば、トーンマッピング曲線の定義、変更された画素カラー等）、更なる処理、典型的にはオリジナルＨＤＲに戻ることを可能にし、上記データはＬＤＲ＿ＣＯＮＴグレーディング／符号化も定める。典型的には、ユーザーインターフェイスユニット７０３は、グレーダーが自身のユーザー入力ＵＳＲＩＮＰをグレーディングマネージャー７０２に与えることを可能にする。当業者はこれが何であるかを知るため、これの詳細については述べず、例えば、専用グレーディングコンソールが接続されてもよく、ソフトウェアが例えばユーザーがボタンを押したときにトーンマッピング関数が如何に変化するかをトラックする。美術グレーダーが通常ＬＤＲグレードＬＤＲ＿ＣＯＮＴの作成の全権を有し（但し、半自動的に導かれる可能性もあり、例えば、ショット内の画像のヒストグラム等の情報理論的考察に基づき、様々な画像物体／部分領域を良好に視認可能且つ適切な輝度サブレンジに配置する第１のトーンマッピングをアルゴリズムが既に導出してもよい）、よって輝度的に最適な見かけの画像、すなわち典型的には全ての物体構造が適切に視認可能であり、画像に特定の見かけを与えるよう物体内のコントラストが最適化された画像を作成するが、一方、グレーダーは乗算変更部分によって過度に悩まされることを望まない可能性がある。したがって、一部の実施形態はこの部分においても少なくともいくらかのグレーダー制御を提供し得るが、他の実施形態はこの乗算変更部分を自動的に実行し得る。これは、グレーディング差比較器７０４によって実行される。グレーディング差比較器７０４は、例えば、典型的には入力としてＬＤＲ＿ＣＯＮＴに基づく中間の又は最終的な予測ＨＤＲ＿ＰＲＥＤ及びＯＲＩＧ＿ＨＤＲを取り、両者がどのように異なるかを比較する。この比較アルゴリズムは、グレーダーが注目したローカル領域によって先導されてもよいが、通常は、グレーダーが個別に処理しなかった領域の予測の質も見てもよい。グレーディング差比較器７０４は、２つのＨＤＲグレーディング（ＨＤＲ＋ＰＲＥＤｖｓＨＤＲ＿ＯＲＩＧ）が過度に異なるために乗算変更が必要な複数の領域を選択するよう構成される。ここで、一部の実施形態では、例えば部分的色誤差の視認性の心理視覚的モデルを使用することにより、グレーダー入力が適切なグレーディング差を決定する数学的アルゴリズムを補完してもよい。ユーザーグレーディング変更ユニット７０６は、グレーディング差比較器７０４の少なくとも一部のパラメータを適合するよう構成される。例えば、単純な一実施形態では、グレーディング差比較器７０４は、自身が（Ａ＿ＭＵＬ内に符号化される）乗数アレイによって乗算変更を定める画像領域を例えば４つ決定し得る。グレーダーは、これらの領域のうちの２つがそれほど変化していないと、すなわち、予測ＨＤＲ＿ＰＲＥＤにおいて当初からそれほど悪くなかったと考え得る。このために、ユーザーグレーディング変更ユニット７０６は、グレーダーが、乗算変更された領域と当該例えば長方形等の符号化形状内のオリジナルＨＤＲ＿ＰＲＥＤとの間で切り替え、両者を基準ＨＤＲディスプレイ上に間欠的にレンダリングするときに視認性を見ることを可能にするソフトウェアモジュールを実装してもよい。グレーダーはその後、変更される領域のリストから２つの領域を消去してもよく、つまり、残りの２つだけが乗算変更データＡ＿ＭＵＬ内に符号化される。また、グレーダーは例えば、自身が改良変更が実行されるべきだと考える別の例えば長方形の領域を選択してもよい。典型的には、グレーディング差比較器７０４は乗算変更データＡ＿ＭＵＬを、特に乗算係数を決定し、データの基礎は乗算知識データベース７０５内に事前に保存される。これは、例えば１つ以上の定義テーブル５２０又は乗算係数を定めるための同等なもの、及び、例えばグレーディング差比較器７０４が差を乗数に変換する方法のためのモデル等を保存し得る。例えば、単純なモデル７０４は、画素毎のルマ差を見て、それらを乗算変更係数に変換し（例えば、Ｙ＿ＨＤＲ＿ＯＲＩＧ−Ｙ＿ＨＤＲ＿ＰＲＥＤ＝ｍ＊Ｙ＿ＨＤＲ＿ＰＲＥＤ；Ｙ＿ＨＤＲ＿ＯＲＩＧ＝Ｙ＿ＨＤＲ＿ＰＲＥＤ＋ｍ＊Ｙ＿ＨＤＲ＿ＰＲＥＤ）、そしてそれらの乗算係数を、具体的に選択された定義テーブル５２０において使用可能な最も近いものにマッピングする。具体的な定義テーブル５２０は、例えばグレーダーによって選択されてもよいし、又は、各テーブルが如何に適切かに依存してグレーディング差比較器７０４によって自動的に、例えば少なくとも１つの画像又は領域にわたる累積残存誤差指標を計算することにより（これは、例えば物体が顔である又は画像内のより中央に配置される等の重要性を考慮した係数によって重み付けされてもよい）選択されてもよい。より複雑なアルゴリズムは、例えば全物体にわたるカラー符号化又は見かけにおけるセミグローバルな差等を計算してもよい。これにより例えば第１のグローバル乗算係数が導出され、その後画素毎に微調整がされる等してもよい。上述したように、ユーザーは当然ながらそれらのパラメータに影響を及ぼすことができる。例えば、選択された定義テーブルが、乗算変更されたＨＤＲ＿ＦＩＮ（典型的には、出力される必要がない７０４内の又は７０４に関連する中間データ）のＨＤＲ＿ＯＲＩＧに対する類似性の十分な精度をもたらさない場合、ユーザーは新たな定義テーブル５２０を決定することができる。これは例えば「精度上昇」ボタンを押すことによって半自動的に行われ、この場合、定義テーブルはより高いビット配分を代償に、より多くの可能な乗算係数を保存することになる。又は、ユーザーが、例えば自身が正確にレンダリングされることを望む物体テキスチャの領域をクリックすることにより、独自の値を具体的に定める等してもよい。同じく上述したように、ローカル平均を定める方法を指定し得るオプションの平均化仕様データＡＶＧＤＡＴが更に存在してもよく、一部の実施形態では、グレーダーがこのデータに影響を及ぼすオプションも与えられ得る。最後に、符号化ユニット７１０が全てをまとめて（すなわち、任意に符号化された、例えばＭＰＥＧ＿ＡＶＧ圧縮されたＬＤＲ＿ＣＯＮＴ画像、トーンマッピング関数ＦＬ２Ｈ等の画像マッピングデータ、及び任意に符号化された乗算変更データＡ＿ＭＵＬ）、これを出力画像信号Ｓ＿ｉｍが規定する任意の方法で当該信号内に符号化する。当業者は、この厳密なメタデータフォーマッティングが本発明の重要な要素ではなく、典型的には、画像信号Ｓ＿ｉｍの特定のリザーブ位置、例えばより古いデコーダでは無視されていた部分に入れること、特定のデータ構造フォームを与えること、リザーブされていた名前及び／又はタイプコード等に関連付けることを含み得ることを理解する。この画像はその後例えば図４のＢＤディスク上に符号化されてもよいし、又はアンテナ７１１を介して送信される等してもよい。本発明を一般的に説明するためにいくつかの例を使用したが、当業者は同じことを実現する多様な態様が存在することを理解する。

図８は、オリジナルＨＤＲシーン取り込みの８ビット符号化のための他の可能なシナリオを示す。このケースでは、８ビットＨＤＲ画像（８ビットＨＤＲ）、すなわち、例えば３０００ニットのＨＤＲディスプレイ上で直接使用できる画像が作成される。画像は例えば［０，１］〜［０，２５５］の単純な線形マッピング及び量子化によって生成され得る。ここで、グレーダーはそれから単純なマッピング、例えばグローバルマッピングによって一次８ビットＬＤＲグレード（ＧＲＡＤ＿１ＬＤＲ）をマッピングし、これは異なるレンダリングダイナミックレンジグレーディングを単一の８ビット画像及びトーンマッピングによって関連付けるという原理に従い相当に有用であり、またＬＤＲディスプレイ上にレンダリングされたとき適度な画像を与え得るが、グレーダーは完全に満足しない可能性がある。この場合、グレーダーは少数の重要な領域に乗算変更を適用して、最終８ビットＬＤＲグレーディングＧＲＡＤ＿ＦＩＮＬＤＲに至ってもよい。この場合、８ｂｉｔ＿ＨＤＲ、下方マッピング単純トーンマッピング戦略（例えばグローバルトーンマッピング関数ＦＨ２Ｌ）、及び乗算係数データ（この場合はＧＲＡＤ＿ＦＩＮＬＤＲと８ｂｉｔ＿ＨＤＲ符号化に下方マッピングを適用することによって単純に得ることができるものとの間の差をコード化する）が符号化され得る。

本文書において開示されるアルゴリズム要素は、実践では（完全に又は部分的に）ハードウェア（例えば、特定用途向けＩＣの部分）として、又は特別なデジタル信号プロセッサ又は汎用プロセッサ等の上で動作するソフトウェアとして具体例され得る。これらは、少なくともいくらかのユーザー入力が存在し得る／した（例えば、工場で、又は消費者又は他者による入力）という意味で、半自動的であり得る。

当業者は、我々の提案から、どの要素がオプションの（選択任意の）改良であり、他の要素と組み合わせて実現され得るか、及び、方法の（オプションの）ステップが如何に装置の各手段に対応するか（及びその逆）を理解できるであろう。本発明において、いくつかの要素が特定の関係で（例えば、ある構造において単一の形態で）開示されるからといって、本明細書において特許のために開示された同じ発明的思考に基づく実施形態として他の構成が不可能であるとは限らない。また、実践的な理由から限られた範囲の例しか説明されていないことは、他の変形例が特許請求の範囲に含まれ得ないことを意味しない。実際には、本発明の構成要素は、任意のユースチェーンに沿って、様々な変形形態で実現可能であり、例えば、作成側のあらゆる変形例（例えばエンコーダ）は、分解されたシステムの消費側における対応する装置（例えばデコーダ）と同様又は同一であり、その逆も成立する。実施形態のいくつかの要素は、エンコーダとデコーダとの間の任意の伝送技術において、伝送用、又は協調等の他の用途の信号内に特定の信号データとして符号化され得る。本願において、用語「装置」はその最も広い意味、すなわち、特定の目的の実現を可能にする手段のグループを意味し、よって例えばＩＣ（の小さい一部）、専用器具（ディスプレイを有する器具等）、又はネットワークシステムの一部等であり得る。「構成」又は「システム」も最も広い意味で使用されるよう意図され、よって特に単一の物質的な購入可能な装置、装置の一部、連携する装置の（部分の）集合等を含み得る。

コンピュータプログラム製品という表記は、プロセッサにコマンドを入力するための一連のロードステップ（中間言語、及び最終的なプロセッサ言語への変換等の中間変換ステップを含み得る）の後、汎用又は特定用途向けプロセッサが、発明の特徴的機能のいずれかを実行することを可能にするコマンドの集合のあらゆる物質的具現化を含むと理解されたい。特に、コンピュータプログラム製品は、例えばディスク又はテープ等のキャリア上のデータ、メモリ内に存在するデータ、有線又は無線ネットワーク接続を介して伝送されるデータ、又は紙上のプログラムコードとして実現され得る。プログラムコードの他に、プログラムに必要な特徴的データもコンピュータプログラム製品として具現化されてもよい。かかるデータは（部分的に）任意の方法で供給され得る。

本発明、又はビデオデータ等の本実施形態の任意の哲学に基づいて使用可能なあらゆるデータは、光学ディスク、フラッシュメモリ、リムーバブルハードディスク、無線手段を介して書き込み可能な携帯型デバイス等のリムーバブルメモリであり得るデータキャリア上の信号として具現化されてもよい。

データ入出力ステップ、及び標準的なディスプレイ駆動等の周知の通常組み込まれる処理ステップ等、任意の提案される方法の動作に必要なステップの一部は、（本発明の実施形態の詳細とともに）本明細書で説明されるコンピュータプログラム製品若しくは任意のユニット、装置又は方法において説明される代わりに、本発明のプロセッサ又は任意の装置の実施形態の機能内に既に存在してもよい。また、例えば方法の任意のステップに又は装置の任意のサブ部分に含まれる（関与する）特定の新規の信号、及びかかる信号の新規な使用又は任意の関連する方法等の結果物及び同様の結果に関しても、保護を求める。

上記実施形態は本発明を限定ではなく説明することに留意されたい。当業者は、提案された例の特許請求の範囲の他の分野への転用を容易に認識することができるが、簡潔さのために、それらのオプションの全ては詳細に述べていない。特許請求の範囲において組み合わせられる本発明の要素の組み合わせの他に、要素の他の組み合わせも可能である。任意の要素の組み合わせが、単一の専用要素において実現され得る。

請求項における括弧間のあらゆる参照符号は請求項を限定することを意図せず、図面内の特定の参照符号も同様である。用語「含む（又は有する若しくは備える等）」は請求項内に列挙されていない要素又は特徴の存在を除外しない。要素は複数を除外しない。

Claims (15)

1. 第１の輝度ダイナミックレンジに対応する画像符号化を第２の輝度ダイナミックレンジ出力画像に復号する方法であって、前記画像符号化は、ハイダイナミックレンジシーンのオリジナル画像の符号化画素であり、前記方法は、
   −所定のトーンマッピング戦略により、前記画像符号化内の画素の少なくともルマを、前記第２の輝度ダイナミックレンジに対応する中間画像内の画素のルマにトーンマッピングするステップと、
   −前記中間画像の少なくとも一部の画素のルマに所定の乗算係数を掛けることにより当該ルマを変更し、前記出力画像を得るステップと
   を含み、
   前記所定の乗算係数は、前記第１の輝度ダイナミックレンジから前記第２の輝度ダイナミックレンジへの前記トーンマッピングの補正を得るための、前記中間画像の前記少なくとも一部の画素のルマに適用されるべき乗算補正を表す、画像符号化を復号する方法。
2. 前記第１の輝度ダイナミックレンジは、５００ニット以下のレンジのピーク輝度に対応するローダイナミックレンジであり、前記第２の輝度ダイナミックレンジは、少なくとも７５０ニットのピーク輝度を有するハイダイナミックレンジである、請求項１に記載の画像符号化を復号する方法。
3. 前記所定の乗算係数は、前記画像符号化に関連付けられたメタデータ内に保存され、前記復号する方法は、前記メタデータにおいて、空間領域のために前記メタデータ内に少なくとも１つの乗算係数が符号化されている前記画像符号化の当該空間領域を定める情報を読み取るステップを含み、前記空間領域の幾何学形状が前記メタデータ内に符号化されている、請求項１又は２に記載の画像符号化を復号する方法。
4. 前記所定の乗算係数は、画素又は画素のグループ毎に乗算係数を備える乗算係数アレイ内に含まれ、前記アレイは前記空間領域幾何学形状の符号化に対応して定められる、請求項３に記載の画像符号化を復号する方法。
5. 前記乗算係数アレイ内の前記乗算係数は、定義テーブルのインデックスとして符号化され、前記定義テーブルは前記インデックスに対する実際の乗算係数を保持する、請求項４に記載の画像符号化を復号する方法。
6. 前記定義テーブルは、どのようなルマ変更の場合に前記定義テーブルが使用されるべきかを特徴付ける記述子に関連付けられる、請求項５に記載の画像符号化を復号する方法。
7. 前記復号は更にウィンドウタイプを読み取り、前記ウィンドウタイプは、そのウィンドウタイプに関連付けられた空間領域が、当該ウィンドウタイプに対応する記述子に関連付けられた定義テーブルによって符号化された乗算係数を有することを示す、請求項６に記載の画像符号化を復号する方法。
8. 前記中間画像の少なくとも一部の画素のルマを変更する前記ステップは、前記乗算を、前記出力画像のローカル平均輝度が前記中間画像のローカル平均輝度から所定の割合のずれ内に含まれる乗算戦略に制約する態様で実行される、請求項１又は２に記載の画像符号化を復号する方法。
9. 前記乗算係数がそのような制約された乗算に関連して定められることを示すタイプ値が読み取られる、請求項８に記載の画像符号化を復号する方法。
10. 前記乗算係数は、一連の１次元又は２次元位置座標にわたる乗算係数の関数的定義として前記メタデータから読み取られる、請求項３に記載の画像符号化を復号する方法。
11. ハイダイナミックレンジシーンのオリジナル画像を第１の輝度ダイナミックレンジに対応する画像符号化として符号化する方法であって、
    −所定のトーンマッピング戦略により、前記画像符号化内の画素の少なくともルマを第２の輝度ダイナミックレンジに対応する中間画像内の画素のルマにトーンマッピングするステップと、
    −前記中間画像内の画素カラーと指定された第２の画像の画素カラーとの間の差を分析することにより、前記中間画像の少なくとも一部の画素のルマに掛けるための乗算係数を決定するステップであって、前記所定の乗算係数は、前記第１の輝度ダイナミックレンジから前記第２の輝度ダイナミックレンジへの前記トーンマッピングの補正を得るための、前記中間画像の前記少なくとも一部の画素のルマに適用されるべき乗算補正を表す、ステップと、
    −画像信号内に前記画像符号化、前記トーンマッピング戦略を指定するデータ、及び前記乗算係数を指定するデータを符号化するステップと
    を含む、ハイダイナミックレンジシーンのオリジナル画像を符号化する方法。
12. 前記第１の輝度ダイナミックレンジは、５００ニット以下のレンジのピーク輝度に対応するローダイナミックレンジであり、前記第２の輝度ダイナミックレンジは、少なくとも７５０ニットのピーク輝度を有するハイダイナミックレンジである、請求項１１に記載のハイダイナミックレンジシーンのオリジナル画像を符号化する方法。
13. −第１の輝度ダイナミックレンジに対応する画像符号化を取得するためのデコーダと、
    −トーンマッピング戦略の指定を取得して、前記トーンマッピング戦略を前記画像符号化に適用することにより、第２の輝度ダイナミックレンジに対応する中間画像を生成するためのトーンマッパーと、
    −少なくとも１つの乗算係数を含む乗算係数データを取得して、前記少なくとも１つの乗算係数を前記中間画像内の少なくとも１つの画素のルマと掛け合わせることにより、出力として出力画像を生成する画素カラー変更部と
    を含み、
    前記少なくとも１つの乗算係数は、前記第１の輝度ダイナミックレンジから前記第２の輝度ダイナミックレンジへの前記トーンマッピングの補正を得るための、前記中間画像の前記少なくとも１つの画素のルマに適用されるべき乗算補正を表す、ＨＤＲ画像復号装置。
14. −ハイダイナミックレンジシーンのオリジナル符号化を取得するための入力部と、
    −前記オリジナル符号化を第１の輝度ダイナミックレンジに対応する画像符号化に変換するための、及び、前記画像符号化をトーンマッピングデータ内に符号化されたトーンマッピング戦略を用いてトーンマッピングすることにより、第２の輝度ダイナミックレンジに対応する中間画像を決定するためのグレーディングマネージャーと、
    −前記中間画像を指定された第２の画像と比較し、両画像間の差に基づき、前記中間画像の少なくとも１つの画素のルマと掛け合せられると、前記中間画像内の画素のカラーより前記第２の画像内の対応する画素のカラーに近い出力画像の最終的画素カラーを生成し、これにより、前記第１の輝度ダイナミックレンジから前記第２の輝度ダイナミックレンジへの前記トーンマッピングの補正を得る、乗算補正を表す少なくとも１つの乗算係数を含む乗算係数データを導出するためのグレーディング差比較器と、
    −前記画像符号化、前記トーンマッピングデータ、及び前記乗算係数データを出力画像信号内に符号化するための符号化ユニットと
    を含む、ＨＤＲ画像符号化装置。
15. 人間のカラーグレーダーが少なくとも前記画像符号化及び前記トーンマッピング戦略を決定することを可能にするためのユーザーインターフェイスユニットを含む、請求項１４に記載のＨＤＲ画像符号化装置。
    
    

Images