特許 7397798 複数のＨＤＲビデオフォーマットを扱うシステム

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

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

(11)【特許番号】

(24)【登録日】2023-12-05

(45)【発行日】2023-12-13

(54)【発明の名称】複数のＨＤＲビデオフォーマットを扱うシステム

(51)【国際特許分類】

   H04N 19/46 20140101AFI20231206BHJP

   H04N 19/85 20140101ALI20231206BHJP

【ＦＩ】

H04N19/46

H04N19/85

【請求項の数】 9

(21)【出願番号】P 2020542965

(86)(22)【出願日】2019-02-05

(65)【公表番号】

(43)【公表日】2021-05-20

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

(87)【国際公開番号】W WO2019158405

(87)【国際公開日】2019-08-22

【審査請求日】2022-02-02

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

(32)【優先日】2018-02-13

(33)【優先権主張国・地域又は機関】EP

(73)【特許権者】

【識別番号】590000248

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

【氏名又は名称原語表記】Ｋｏｎｉｎｋｌｉｊｋｅ Ｐｈｉｌｉｐｓ Ｎ．Ｖ．

【住所又は居所原語表記】Ｈｉｇｈ Ｔｅｃｈ Ｃａｍｐｕｓ ５２， ５６５６ ＡＧ Ｅｉｎｄｈｏｖｅｎ，Ｎｅｔｈｅｒｌａｎｄｓ

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100135079

【弁理士】

【氏名又は名称】宮崎 修

(72)【発明者】

【氏名】タルストラ，ヨハン コルネリス

(72)【発明者】

【氏名】シェパード，ニコル バーレイ

(72)【発明者】

【氏名】ファン デ ケルクホフ，レオン マリア

【審査官】間宮 嘉誉

(56)【参考文献】

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

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

【文献】特表２０１８－５０３２８３（ＪＰ，Ａ）

【文献】FRANCOIS, Edouard et al.，Signalling, Backward Compatibility and Display Adaptation for HDR/WCG Video Coding (Draft 3)，JCTVC-AB1012 (version 1)，ITU，2017年10月18日，pp.19-29，JCTVC-AB1012.docx

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

Ｈ０４Ｎ ７／１２

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

ＩＥＥＥ Ｘｐｌｏｒｅ

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

【請求項1】

ビデオデコーダであって、時間的に連続する画像で構成される高ダイナミックレンジビデオを復号するよう構成され、前記ビデオはピクセルカラーを有する多数の時間的に連続する画像で構成される連続時間セグメントを含み、異なる時間セグメント内のピクセルカラーは異なる電気光変換関数に従いピクセル輝度に対応するルマを有することにより定められ、前記時間セグメントの幾つかの中の画像は、時間的に連続する画像毎の個別関数として送信される動的可変電気光変換関数に従い定められ、他の時間セグメントの中の画像は、固定電気光変換関数により定められるルマを有し、該固定電気光変換関数の情報は前記時間的に連続する画像の反復レートより少ない頻度で送信されるデータパッケージ（DRAM）の中で同時通信され、第1セグメントと第2セグメントとの間の変化時点の後の画像ピクセルルマの前記固定電気光変換関数を特徴付ける前記データパッケージ（DRAM）のうちの少なくとも1つは、前記変化時点の前に送信され、当該ビデオデコーダは、メモリを有し、該メモリに、前記変化時点の前に受信された前記少なくとも1つのデータパッケージ（DRAM）を格納するよう構成される、ビデオデコーダ。

【請求項2】

前記メモリに前記変化時点より前に受信した最後のパッケージ（DRAM）を格納するよう構成される、請求項1に記載のビデオデコーダ。

【請求項3】

画像毎の動的可変電気光変換関数の存在または非利用可能性により、セグメントの変化を検出するよう構成されるビデオ変化検出器を含む請求項1または2に記載のビデオデコーダ。

【請求項4】

変更された方法であるHDRビデオ符号化により符号化された第1画像と同期的に受信される、メタデータの中のコーデック変化指示パケットの存在を検出するよう構成されるビデオ変化検出器を含む請求項1乃至3のいずれか一項に記載のビデオデコーダ。

【請求項5】

前記第2セグメントの連続して入力される画像の中で受信されたルマに対応して表示されるべき画像輝度の計算は、最後に受信したデータパッケージ（DRAM）の中の情報により定められる電気光変換関数を用いて前記ルマを輝度に復号するよう構成されるプロセッサにより計算される、請求項1乃至4のいずれか一項に記載のビデオデコーダ。

【請求項6】

HDMI（登録商標）またはDisplayPortケーブルで通信されるビデオを受信するよう構成されるビデオ入力を有する請求項1乃至5のいずれか一項に記載のビデオデコーダ。

【請求項7】

ビデオエンコーダであって、時間的に連続する画像で構成される高ダイナミックレンジビデオを符号化するよう構成され、前記ビデオはピクセルカラーを有する多数の時間的に連続する画像で構成される連続時間セグメントを含み、異なる時間セグメント内のピクセルカラーは異なる電気光変換関数に従いピクセル輝度に対応するルマを有することにより定められ、前記時間セグメントの幾つかの中の画像は、時間的に連続する画像毎の個別関数として送信される動的可変電気光変換関数に従い定められ、他の時間セグメントの中の画像は、固定電気光変換関数により定められるルマを有し、該固定電気光変換関数の情報は前記時間的に連続する画像の反復レートより少ない頻度で送信されるデータパッケージ（DRAM）の中で同時通信され、第1セグメントと第2セグメントとの間の変化時点の後の画像ピクセルルマの電気光変換関数を特徴付ける前記データパッケージ（DRAM）のうちの少なくとも1つは、前記変化時点の前に送信される、ビデオエンコーダ。

【請求項8】

ビデオ復号の方法であって、時間的に連続する画像で構成される高ダイナミックレンジビデオを復号するよう構成され、前記ビデオはピクセルカラーを有する多数の時間的に連続する画像で構成される連続時間セグメントを含み、異なる時間セグメント内のピクセルカラーは異なる電気光変換関数に従いピクセル輝度に対応するルマを有することにより定められ、前記時間セグメントの幾つかの中の画像は、時間的に連続する画像毎の個別関数として送信される動的可変電気光変換関数に従い定められ、他の時間セグメントの中の画像は、固定電気光変換関数により定められるルマを有し、該固定電気光変換関数の情報は前記時間的に連続する画像の反復レートより少ない頻度で送信されるデータパッケージ（DRAM）の中で同時通信され、第1セグメントと第2セグメントとの間の変化時点の後の画像ピクセルルマの前記固定電気光変換関数を特徴付ける前記データパッケージ（DRAM）のうちの少なくとも1つは、前記変化時点の前に送信され、前記変化時点より早い時点で受信された前記少なくとも1つのデータパッケージ（DRAM）が格納される、方法。

【請求項9】

ビデオ符号化の方法であって、時間的に連続する画像で構成される高ダイナミックレンジビデオを符号化するよう構成され、前記ビデオはピクセルカラーを有する多数の時間的に連続する画像で構成される連続時間セグメントを含み、異なる時間セグメント内のピクセルカラーは異なる電気光変換関数に従いピクセル輝度に対応するルマを有することにより定められ、前記時間セグメントの幾つかの中の画像は、時間的に連続する画像毎の個別関数として送信される動的可変電気光変換関数に従い定められ、他の時間セグメントの中の画像は、固定電気光変換関数により定められるルマを有し、該固定電気光変換関数の情報は前記時間的に連続する画像の反復レートより少ない頻度で送信されるデータパッケージ（DRAM）の中で同時通信され、第1セグメントと第2セグメントとの間の変化時点の後の画像ピクセルルマの電気光変換関数を特徴付ける前記データパッケージ（DRAM）のうちの少なくとも1つは、前記変化時点の前に送信される、方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ビデオ画像のダイナミックレンジの符号化時点の変化を扱い、特に符号化する方法および機器に関し、または高ダイナミックレンジ（high dynamic range：HDR）符号化方法に関する。

【背景技術】

【0002】

数年前まで、全てのビデオ（例えば、ブルーレイディスク上のテレビ番組または映画、または例えばビデオ電話（videophony）のような他の使用）、および大部分の静止画像は、所謂、標準ダイナミックレンジ（standard dynamic range：SDR）とも呼ばれる、所謂、低ダイナミックレンジ（low dynamic range：LDR）の原理に従い符号化されていた。これは、送信のためにYCbCr画像ピクセルカラーの8または10ビットルマ符号、および符号化ピーク明度（PB_C）を定めるRec.709OETFによる単一の方法が、画像を生成するために存在したことを意味する。つまり、ビデオの符号化され得る最も明るい白色ピクセルの輝度は、標準的に常に100ニトであり、最も暗い符号化可能な輝度は0．1ニトであった。末端の消費者建物内にある全ての実際のディスプレイ、およびコンテンツ制作者の場所にあるプレビューモニタは、対応する最も白い白色（PB_D＝10ニト）および最も暗い黒色を有する。その結果、プロデューサは、末端の消費者が見るものを、彼の同一の制作モニタで見るので、行われるビデオ制作および処理は、技術的チェーンを比較的単純にする。

【0003】

ここ数年、有意に異なるPB_Dを備える新しいディスプレイが現れている。例えば、SDRディスプレイより少なくとも20倍も明るい2000ニトPB_Dディスプレイである。そして、これは、画像がうるさい程に明るく見えることを意味する（例えば、ディスプレイPB_Dにマッピングされる符号化された白色により表示する相対輝度の制約下で、SDR画像をHDRディスプレイに直接にマッピングするとき）、または逆も同様であり、HDR画像（HDR TVのために推定される）は、HDR TVで直接レンダリングされるとき、画像を一層見やすくするために、画像に何らかの（非標準の）最適化を行うTVを有しないとき、暗すぎることがある。

【0004】

事態は、ここ4年の、多数の異なるHDR画像符号化および処理システムの導入により複雑になった。

【0005】

読者の便宜のために、図1の支援により、HDR符号化およびダイナミックレンジ適応の基本的特性の幾つかを紹介する。図1は、多くの可能なHDRシーンのうちの幾つかの典型的な説明のための例を示す。将来のHDRシステム（例えば、1000ニトのＰＢ＿ＤＨＲグレーディングディスプレイに接続される）は、画像内の全てのオブジェクト／ピクセルの適切な輝度を、例えばレンダリングすることにより正確に処理できる必要がある。HDR画像は、通常輝度の多くの通常色を有してよい（つまり、これは、よく日に照らされた人間の顔のように、SDRで符号化されることも可能である）。しかし、標準的にそれらは、極端に暗い領域および極端に明るい領域のうちの少なくとも1つを有し得る。

【0006】

例えば、ImSCN1は、西部映画（これは、大部分が明るい地領域（景色）を有し、理想的には100ニトより明るいディスプレイでレンダリングされて、雨の日の眺めより天気のよい眺めをより多く提供するべきである）からの晴れた屋外の画像である。一方で、ImSCN2は夜間の画像である（大部分が暗いピクセルを有し、同じ画像内であるが、非常に明るいピクセル、例えば街灯ピクセルも有する）。

【0007】

HDR画像のレンダリングを数年前に終了したばかりのSDRのみの時代では常であったものと異なるものにするのは、SDRがこのような限られたダイナミックレンジ（PB_C＝100ニト、約0．1～1ニトの表示可能な黒色レベル）を有し、主にオブジェクトの固有反射率のみがSDRで示され得ることである（これは、良好な白色での90％～良好な黒色での1％の間に含まれる）。これは、均一な技術的に制御される照度の下で、（そられの反射から、及び勿論、それらの色度から特定量の明度を有する）オブジェクトを認識するのには良いだろう。しかし、自然のシーンに与えることのできる照度自体の美しい変化、及び視聴者に与えることのできる影響は、それほど多くない。

【0008】

HDRでは、少なくとも、例えば1／10000と10000ニトの間に含まれ得る輝度を表示されるよう定義できる。興味深い第2の問題は、受信した画像内で定められたこのような輝度、つまり理想的に表示されるときの輝度が、必要なもの、例えば、制作側が太陽が理想的に意図したように太陽をレンダリングするために5000ニト、より低い表示ピーク明度PB_Dを有するいかなるディスプレイ上で表示されなければならないことである（および、望ましくは、例えば750ニトPB_Dディスプレイでの、太陽のための対応する低い表示輝度は、画像の見え方が完全なものでなくても、表示されるときの750ニトPB_C画像が、少なくとも正しいピクセル色度を有する少なくとも可能な限り多くの元のマスタ5000ニトPB_C HDRビデオ画像を伝達すると決定されなければならない）。

【0009】

幾つかのHDRコーデックは、マスタHDR画像に加えて、対応するSDR画像を定める（つまり、最適に定められた概観を備え、これは、より限られたSDR色域が可能なとき、画像ピクセルカラーがHDR画像ピクセルカラーと視覚的に同様であることを意味する）。幾つかのコーデックは、また、PB_Dディスプレイによる表示のために提供するために、マスタHDR画像のPB_D（例えば5000または10000ニト）とSDRの100ニトPB_Cとの間の、最適な概観の、所謂、メディアダイナミックレンジ画像を引き出す（または、マスタ画像のPB_Cよりも高いPB_Dの画像を引き出す）方法を定める。これは、標準的に、少なくとも輝度マッピング関数（図2のF_L、および例えば同じ空間位置にある対応するHDRピクセルカラーから導出したSDRピクセルカラーの彩度を変更するカラーマッピング仕様F_Cの場合もある）をメタデータの中で同時通信し、HDR画像内のピクセル輝度が何らかの対応するSDRピクセル輝度にどのように変換されるかを記述する（または、幾つかのコーデックでは、何からのMDRピクセル輝度への変換は、SDRへのマッピングが存在する必要がない）ことにより、行われる。

【0010】

左に見えるのは、5000ニトPB_CマスタHDR画像符号化のための輝度軸（および、対応するダイナミックレンジDR_hであり、これは、最も暗い輝度により分割された最も明るい輝度として定めることができる。しかしながら、読者は、良好なダイナミックレンジ画像がこれら2つの端点だけでなく、種々のHDRシーンオブジェクトの中間ピクセル輝度の各HDRシーン種類の最適な決定にも関係していることを理解すべきである）である。右に見えるのは、SDR輝度ダイナミックレンジDR_sに沿う標準的な画像オブジェクトの対応するピクセル輝度である。

【0011】

時には、輝度マッピングルールは「輝度を同じに保ち」、時には、より大きなHDR輝度範囲をより小さなSDR輝度範囲に圧縮するために、HDR輝度が調節される必要があることが分かる。また、同様に、メカニズムは、例えば受信したSDR画像または受信したHDR画像を、例えば750または1500ニトMDR画像にマッピングする二次輝度マッピング関数を導出できる（ディスプレイ適応とも呼ばれる）。以下に詳述するように、HDR画像処理は、各視聴者が彼の特定のディスプレイ上で元のHDRの芸術的創造のビデオの最適なまたは少なくとも妥当な提示を得るという、および表示する前に異なる最適化を必要とする異なるHDR効果および輝度分布を有する多くの異なる種類のHDRシーンを構成し可能にするという、要求により、異なる種類のPB_Dを有する多くの異なる種類のディスプレイが存在するために、複雑なだけでなく、HDRビデオのための異なる技術的符号化方法が開発されている。これは、異なるEOTFを有し、特に一時的に散在するとき、正しく復号され調整される必要がある。

【0012】

図2は、特に出願人のHDRの枠組みに従う、HDR画像符号化および復号チェーンの高レベルの概観を概略的に示す。

【0013】

全てのこのようなHDRビデオコーダは、HDR画像が「通常のSDR画像であるかのように」、つまり、例えばHEVCまたは同様のビデオ圧縮により、実際に通信可能な特性を有する（この特性は、SDR時代から既に展開されている膨大な量のビデオ処理技術が存在する場合に迅速な市場による採用を可能にするために、満たされるべき必須要件として理解される）。

【0014】

「～かのように（as if）」は、もちろん、問題になり得る複雑性であり、以下の発明およびその実施形態は、（スクラッチから100％新しく開発されたのではなく既存の制限の上に構築された本システムにおいて）実際に突然現れる非常に迷惑な問題の一例でもある。

【0015】

最も単純なコーデックはHDR10コーデックである。これは、Rec.709OETFよりも遙かに急勾配であり、したがって、より広い入力画像輝度範囲を符号化できる新しい光－電気変換関数（opto-electrical transfer function：OETF）を用いて、ピクセルカラーのルマYを生成する。しかし、ビデオ圧縮器203では、これらは単にルマであり、気にしない（正しいHDRピクセル輝度を再構成できるためには、デコーダは、OETFの正しい逆、所謂、EOTFを有するだけでよい）。EOTFの理解を単純に保つために、本明細書は、必ずしも、正規化されたルマおよび輝度の間の関数形状関係だけではなく、輝度の符号化ピーク明度PB_Cも考慮することがあることに留意する。

【0016】

他のビデオコーデックは、HDR画像を（SDR画像の外観の重要性がHDR画像の外観より大きいまたは同じ位であることを見い出す放送局のようなユーザのために、レガシーデコーダと後方互換性のある）対応するSDR画像として実際に送信する。そして、デコーダは、受信したSDR輝度を、制作側で生成されたマスタHDR画像の近い再構成へと変換して戻す方法を有する。このようなコーデックの一例は、変換のために固定関数を使用し（これは、色誤りのような欠点を有するが、本願ではあまり関係がない）、したがって、少なくとも理論的にはメタデータを送信する必要のない、Hybrid LogGamma（HLG）コーデックである。

【0017】

以下に、所謂、ダイナミックメタデータを用いる一例により一般的な原理を説明する。これは、異なる最適な形状の輝度マッピング関数F_Lが、時間的に連続する画像の各々について通信され得ることを意味する（しかし、全部の符号化体系がこのようなダイナミックメタデータを定めているのではなく、常に通信されるのではないことを理解することが重要である）。

【0018】

図2は、SDR通信タイプ、例えば、出願人のSL_HDR1コーデック（ETSI TS 103433-1 v1.2.1(AUG2017)）の標準的なシステムにより教示される。カラーマッピング関数F_ctは、少なくとも1つの輝度マッピング関数F_Lおよび任意的にF_Cであり（幾つかのシステムは、受信側において通信されたF_Lに対応する良好に動作するF_Cを定めてよいが）、人間のカラーグレーダ（または代替として自動画像分析ソフトウェア）により定められて、HDRマスタ画像MAST_HDRに対応する妥当な外観のSDR画像（Im_LDR）を得てよい。一方で、同時に、逆関数IF_ctを用いることにより、元のマスタHDR（MAST_HDR）画像は、十分な精度で、再構成HDR画像（Im_RHDR）として再構成できる。IF_ct関数は、通信されるように、順方向HDR－SDRマッピングF_ct関数から決定できる。又は、システムは、IF_ct関数を直接通信してもよい。

【0019】

色変換部202は、標準的にマスタHDR画像（MAST_HDR）ピクセルの相対輝度のF_ct輝度マッピングを適用する、つまり、最大輝度が1．0になるように正規化される。本発明の概念を単純な方法で理解するために、簡単のために、100ニトのPB_C SDR出力画像Im_LDR（つまり図1の右側）のピクセルの正規化SDR出力輝度を導出するために、4乗輝度マッピング関数（L_out_SDR＝power（(L_in_HDR;；1／4））を使用すると仮定し得る。つまり、このような関数は、SDRグレーディングされた対応する画像の妥当な外観を、シーンのマスタHDR画像に与える（「妥当な」は、SDR画像でも、例えば、陰の領域の大部分が暗く見え過ぎない、ランプ及び他の照明オブジェクトが、それらが依然として暗い画像領域に対して妥当な内部領域コントラストを有するので、望むように飛び出る、等のような態様の特定のシーンを意味する；他の画像では、他の因子が貢献してよいが、そのような詳細は本発明の技術的コンポーネントを教示するのに基本的でも限定的でもない）。明らかに、輝度マッピング関数は、通常、より複雑になり得るが、このような詳細は、本願の技術を理解するために必要ない。

【0020】

受信機は、受信した対応するSDR画像からマスタHDR画像の再構成又はいくらかの圧縮関連アーチファクトを有するが少なくとも近い再構成が可能でなければならないので、実際のピクセル化画像と別に、色マッピング関数F_ctもビデオエンコーダ203に入力しなければならない。限定無しに、私たちは、ビデオがMPEG HEVCビデオ圧縮器（または同様にAVS等）により圧縮されること、及び例えばSEIメカニズムまたは同様の技術を用いて関数がメタデータに格納されること、を仮定する。

【0021】

したがって、コンテンツ生成機器221の動作の後に、画像通信技術の観点から、ビデオ圧縮器203は、入力として正規のSDR画像を得たように装い、更に重要なことにRec.709標準SDRルマ仕様に従い、技術的に復号可能なSDR画像であるものを出力する。したがって、次に、更なる技術、例えば、全ての必要な変換を適用して何らかの伝送媒体205を介して出て行くデータをフォーマットする（例えば、BDディスクに格納するための符号化、又はケーブル送信のための周波数符号化、等）送信変換器204は、SDR符号化の枠組みの中で実行するために自身の使用した単に全ての標準的なステップを適用できるたけである。

【0022】

したがって、画像データは、伝送媒体205、例えば衛星またはケーブルまたはインターネット伝送を介して、例えばATSC3．0又はDVB、又はいかなるビデオ信号通信原理に従い、1つ以上の受信側に伝わる。

【0023】

いかなる消費者または専門家側において、例えばセットトップボックス、テレビジョン、又はコンピュータのような種々の物理機器に内蔵されてよい受信機206は、フォーマット解除及びチャネル復号を適用することにより、チャネル符号化を解除する。次に、ビデオ伸張器207は、例えばHEVC復号を適用して、復号SDR画像Im_RLDR、及び色変換関数メタデータF_ctを生成する。次に、色変換器208は、SDR画像をいかなる非SDRダイナミックレンジの画像に変換するよう構成される。例えば、5000ニトの元のマスタ画像Im_RHDRは、MAST_HDRからIm_LDRを生成するために符号化側で使用された色変換F_ctの逆色変換IF_ctを適用することにより、再構成されてよい。あるいは、ディスプレイ適応ユニット209は、SDR画像Im_RLDRを、接続されたディスプレイ210が3000ニトPB_Dディスプレイなどである場合に最適にグレーディングされる異なるダイナミックレンジ、例えばIm3000n（本例ではPB_C＝3000ニトだが、一般に、入力画像のPB_Cより通常少なくとも10％の差だけ低いまたは高いいかなるPB_Cを有する）に変換するよう構成されてよい。私たちは、ビデオデコーダ及び色変換器が単一のビデオ再決定機器220の中にあることを非限定的に仮定する。本例では、デコーダがビデオ使用エンドポイントにあり、コンテンツを閲覧するためにディスプレイ（例えば、HDRテレビ、またはポータブルディスプレイ、等）に接続されると仮定するが、同じ原理は、例えばトランスコーダにおいて構成できる。ここで、受信機はビデオ処理チェーンの中間点に、例えばケーブルテレビ事業者の再配信局に存在する。またはディスプレイ上で表示する代わりに、出力ビデオが不揮発性メモリに格納できる。

【0024】

世界中の全てのシステムがこのような動的に変化する輝度マッピング関数F_Lを画像毎に通信するならば、画像の符号化が変化しても、問題はないだろう。そして、例えば、受信側のディスプレイは、最大で例えば5000ニトのピクセル輝度の情報を有する通信された画像の、そのPB_Dが何であれ、HDR画像の供給されるディスプレイに対応する最適画像へのディスプレイ適応を行うことができるだろう（最適画像のPB_Cは特定のPB_Dに等しいが、全ての低い輝度は、どのオブジェクト構成が画像内に実際に存在するかに依存して、適切にマッピングされる）。

【0025】

しかしながら、問題は、先に述べたように、全ての符号化ビデオが関連するダイナミック輝度マッピング関数を有するのではないことである（例えば、HDR10符号化、および、再復号画像自体が、表示されるべき輝度に対応するそれ自体のルマを定める固定電気－光変換関数を有する可能性がある、あるいは、現在の課題の全部がその時に想像されなかったために、SDRビデオ画像が単独のEOTFに従い定められる）。したがって、私たちは、何らかのコンテンツプロバイダ（例えば、放送局、または中間のコンテンツ供給機器）が、ダイナミックメタデータを有しないで（つまり、個々の画像の対応するF_L関数を有しないで）、特定の時点で、画像のうちの幾つかを通信することを期待できる。受信機は、したがって、連続する画像を正しく表示する方法を決定する必要のあるときに、何をすべきか分からない。例えば、デコーダが誤ったルマ解釈モードに設定された場合に、明るいグリッチ（bright glitch）が生じることがある、または画像の幾つかの領域が見えないほど暗くなることがある、等である。

【0026】

WO2016/162095は、（カメラセンサによりキャプチャされたような）HDR入力画像が、幾つかの可能なOETF関数のうちの1つを適用して最終画像のルマコードを定めることにより、最終画像に符号化できることを教示している。例えば、べき関数の値ガンマは、例えば入力画像が深い黒色および明るいピクセルを含むために大きなダイナミックレンジを有する場合に、どんなピクセルコンテンツ（輝度またはRGB値）が入力画像の中に正確に存在するかに依存して選択できる。暗い輝度ほど高い勾配（例えば1／2ではなく1／4）のガンマ関数が使用されるならば、これらの深い黒色ピクセルは、より正確に、つまり人間の視覚系にとって視覚的により完全に、量子化できる。この文献は（別個の）ビデオ毎に最適なOETFを選択する可能性を教示しているが、特定のOETFがメタデータとして通信されなければならない。メタデータは、エンコーダにより選択された変形を示し、符号化されるとき、または場合によっては受信されるとき、同じビデオの中でOETFを変更することを教示していない。

【0027】

US2017/0026646は、最適に変形可能なOETFにより実現される最適な非線形量子化について教示している。何らかの前処理カラーマッピングとは別に、この教示の核は、符号化された変換関数208であり、適用可能ならば210でもある。

【0028】

210が固定OETF、例えばSMPTE2084を適用するとする。このような固定OETFは任意のHDRビデオにとって非常に良好であるが、幾つかの特定の輝度のみが符号化されるべき入力マスタビデオの特定の部分に存在することがわかるとき、前処理により更に向上され得る。例えば、10分40秒～12分20秒の間のショットが7個の太陽を有する明るく照らされた惑星であり、全輝度範囲（100～10000ニト）の上側部分に全てのピクセル輝度を有すると仮定する。固定2084OETFは、この範囲の明度に対して比較的少ない量子化されたコードを有することが分かると、変換関数208は、輝度をより広いサブ範囲に、より暗い輝度へと広げる、輝度のプレマッピングを行い得る。その結果、より多くのルマコードが、より高い精度を与えるならば、存在するピクセルのために最終的に使用される。これらの処理の全部を逆に行うことにより再構成されるとき、入力HDR画像のみが表示のために使用される場合、HEVC符号化品質を除き、最終結果の明度の外観に対して間には大きくは何も起こらない。

【0029】

この文献は、任意に変形されたプレマッピングが変換関数ユニット208（および、したがって、画像毎または画像セット毎の可変OETF）の中で生じ得ることを教示しているが、更なる可変符号化シナリオ、つまり幾つかの固定、単純、予め合意されたタイプ等、例えばHLG関数、のうちの特に可変ではない、つまり静的なタイプのOETFの状況が存在することの教示はない。さらに、この静的OETF定義が欠落した画像の時点が存在し得るという教示はなく、（静的OETFの逆がどんなに単純であっても）デコーダが受信したルマのピクセル輝度を再構成すべき方法を認識しないままである。

【0030】

反対に、（常に）変化可能なOETFおよび特にOETFの部分の教示がある場合、当業者は、このような必要な大きく変化可能な情報が変化する場合にはいつでも、つまり少なくとも画像時点毎に、通信されなければならないことが常に妥当であると信じている（画像ショットのうちの次のN個の画像に対して有効でない限り、これはこれらの画像全部について正しいOETFを実際に通信することと等価である）。欠落したOETFの問題はUS2017/0026646において特定されていないので、解決策に向かう着想を形成することについても何ら言及していない。

【発明の概要】

【0031】

この問題は、ビデオデコーダ（341）であって、時間的に連続する画像で構成される高ダイナミックレンジビデオを復号するよう構成され、前記ビデオはピクセルカラーを有する多数の時間的に連続する画像（I1,I2）で構成される連続時間セグメント（S1,S2）を含み、異なる時間セグメント内のピクセルカラーは異なる電気光変換関数に従いピクセル輝度に対応するルマを有することにより定められ、前記セグメントの幾つかの中の画像は、時間的に連続する画像毎の個別関数として送信される動的可変電気光変換関数に従い定められ、他のセグメントの中の画像は、固定電気光変換関数により定められるルマを有し、該固定電気光変換関数の情報は画像反復レートより少ない頻度で送信されるデータパッケージ（DRAM）の中で同時通信され、第1セグメントと第2セグメントとの間の変化時点（t1）の後の画像ピクセルルマの電気光変換関数を特徴付ける前記データパッケージ（DRAM）のうちの少なくとも1つは、前記変化時点（t1）の前に送信され、前記ビデオデコーダ（341）は、メモリ（343）を有し、該メモリに、ピクチャ反復回数（N)だけ前記変化時点（t1）より早い時点で受信された前記データパッケージのデータパッケージ（DRAM）を格納するよう構成される、ビデオデコーダにより扱われる。

【0032】

したがって、ビデオデコーダは、このような複雑な異なる方法で定義されたHDRビデオを扱うことが可能なように構成され、以下の態様により構成される。

【0033】

先ず、読者の便宜のために、近年、HDRビデオ時代では、EOTFは典型的なSDR EOTFより一層複雑になっているので、EOTFの概念が定められる。

【0034】

基本的にEOTFは、「電気的」コード（元々は、アナログテレビにおける電圧であるが、現在のデジタルビデオは標準的にMビットコードであり、Mは標準的に10以上であり、コードは、3×10R、G、Bルマ、またはYCbCr色符号化のような種々の色コードであり得る）は、関数計算により、光学コード、つまり表示されるべき輝度にマッピング可能である。したがって、
L=EOTF（Y'）、輝度LはCIE比色定量、およびY’ルマコードで定められる。

【0035】

逆は、光－電気変換関数と呼ばれ、例えばカメラにより測定された元の光学的値を、10ビットルマコード数値にマッピングする。
Y’=OETF(L)

【0036】

SDRでは、1つの単独のEOTFのみが存在し、SDRテレビシステムを定める。該システムは、入力電圧をTV画面上で表示される出力輝度へと変換するときに、蛍光体を放射するCRT電子銃が約2のべき乗の変換動作を有するために定められた。

【0037】

正確に言うと、Rec.709(SDR)OETFは、以下のように標準化された（入力輝度が[0．0～1．0]に正規化されるとき）：
Y’=IF(L<0.018; 4.5*L; else 1.099power(L; 0.45)-0.099) （式1）

【0038】

しかしながら、0～1023ルマコードに対応する輝度を計算することにより、このOETFが1000：1のダイナミックレンジ、またはより正確には0．1ニト～100ニトの間のLDR輝度を符号化できるだけであることが示される（これは、均一に照らされるときに妥当な外観の画像を得るのには十分であるが、例えば暗い洞窟の中の超高明度の光の剣を有する壮観なHDR画像では十分ではない。このようなHDR画像では、コンテンツ制作者に、新しいルマコードとして、1／0000～10000ニトの間のY'^＊輝度を指定することを望み得る。これは、自然の中に生じる全部の輝度をカバーしないが、ディスプレイ上で見えるべき画像を定めるためには十分に見える）。

【0039】

したがって、少なくとも1つの新しいHDR EOTFを定義すること開始する。これは、SMPTE ST．2084として標準化された知覚量子化器（Perceptual Quantizer）EOTFである：
Y’*=POWER((C1+C2*POWER(L;A))/(1+C3*POWER(L;A));B) （式2）
以下の定数を有する：C1=0,8359375; C2=18,8515625; C3=18,6875; A=0,1593017578125; B=78,84375。

【0040】

正当な理由により多くの種類のHDR EOTFが出現したが、PQ定義（静的）HDRによりインターリーブされたSDRのみのセグメントで構成されるビデオを有する場合でも、以下の問題がある。

【0041】

上述のように、HEVC圧縮器では、ルマが式1に従い計算されたSDRルマY'であるか、または式2に従い計算されたHDRルマY'^＊であるかに関わらず、入力は、10ビット数値であるルマYを有するピクセルである。しかしながら、同じルマコードを送信するデコーダ、例えば721は、それぞれの異なる画像符号化毎に、正しい復号EOTFを使用しなければならない。なぜなら、2つの異なるシナリオのルマコードは同じ可能性があるが、適切なEOTFを適用することにより、最終的に表示されるべき異なる輝度がデコーダにより計算されなければならないからである（実際には、PQ EOTFは遙かに明るいまたは暗い輝度を生成できるので、例えば、Rec.709OETFに従い符号化されたルマに対してPQ EOTFを不適切に適用すること、したがって、Rec.709EOTFにより復号されることは、これらの固定EOTFの可能性しかない場合でも、10倍より明るいまたは暗すぎる可能性のある復号された輝度を生じ得る）。

【0042】

留意すべきことは、簡単に言うと、HDRピクセルカラーを定義する種々の方法も存在することである。例えば、Hybrid LogGamma(HLG)は、3つのRGB色成分に対して別々にOETFを使用する。つまり、例えば赤色ルマR’^**=OETF_HLG(R)を生成し、RはRGB色定義の中で赤色の線形量である（近似レイマン（layman）項の中の赤色光子の割合である）。しかし、本発明の概念の教示を簡単にするために、以下の説明では、ピクセルカラーは伝統的なY'CbCrビデオカラー符号化で定義され、Y'は、元々定義された標準Rec.709OETFより多くの他のOETFにより定義されると仮定する（対応する色度CbおよびCrについても同様である）。

【0043】

読者にとって重要なことは、出願人のSL-HDR1（ETSI TS103 433-1 v1.2.1(AUG2017)）およびSL_HDR2（ETSI TS103 433-2）より高度な（より高い品質の、将来性のある）HDRビデオコーデックが、通信されたルマと最終的に表示されるべき輝度との間の関係を有することである。これは、可変関数により定義される。つまり、特定のHDR画像に依存して変化可能な形状である。これは、固定SDRまたはHDR10符号化と比べて非常に大きなステップである（並びに、このようなマッピングは、可変EOTFとして古い名称に従い定式化できる）。読者が新しい枠組みの複雑性を確実に理解するために、図4は一例を与える。

【0044】

入力HDR画像は幾らかより複雑な（しかし、あまりに異常なものではなく、生じる任意の場合に任意のHDR符号化または処理技術により正しく処理されるべき）HDRシーン画像であり、暗い洞窟領域と、明るい太陽に照らされた屋外領域および別の明るい領域Rsmとの間の平均的に照らされた領域で構成されるとする。これは、一般的に、ローカルに利用可能な照明状況の下でキャプチャされた何らかの見付かった環境か、または美しく芸術的に生成された画像（おそらくCGI）かに関わらず、HDRシーン画像がどのように構成されるかである。有意に低いSDR輝度範囲へのマッピングのための、例えばこの特定の画像時点（t1）に最適な輝度マッピング関数F_L(t1)がコンテンツ制作側で人間の色グレーダにより指定される幾つかの基準がある。マッピングは、標準的な輝度を用いて示される。なぜなら、読者が、このような輝度が、例えば水平軸上のPQルマ、および垂直SDR輝度軸のRec.709ルマにどのように対応するかを想像できるからである（これは、軸上の非線形な広がり、および輝度マッピング形状の対応する変形に対応するが、可変EOTFを構成するために必要な点は以下に例示されるものと同じである）。例えば、最も暗い画像領域Rdには、影に隠れた僅かに見えるナイフを持った男がいる。（一番下の輝度マッピンググラフの水平軸に輝度が示される）HDR画像符号化では、良好なHDRディスプレイシステムが例えば0．01～0．1ニトの間の輝度でこの男を視覚的に最適に表示できるという妥当な仮定に従い輝度を符号化している（0．1ニトは既にSDR輝度範囲の最小値であるので、SDRおよびHDRにおける輝度のアイデンティティに従いマッピングするべきではないことに留意する）。この男をSDR輝度範囲において正しく見える、つまり明白に見え過ぎないが全体的に黒くもない、ようにするために、HDR輝度サブ範囲HDを、SDR輝度サブ範囲RDに、本例では0．5～1ニトの間に最適に割り当てなければならない。その結果、画像輝度マッピング関数毎に動的に変化可能な部分（または対応するEOTF）を既に定めた。画像の平均的に照らされた領域に横たわる人物は、コントラストの強い明るくカラフルなSDR範囲に良好にマッピングされなければならない。つまり、これは標準的に約50ニトにある（SDR画像では、例えば、多かれ少なかれ顔の照らされた側で両方とも目のコントラストが強いことが好まれる）。実際に、これは単純にSDR生成であるなら、この人物の顔に、例えば60ニトの輝度を与え、この人物の白いシャツに90ニトの輝度を与えるだろう。しかし、全てが遙かに明るいHDR輝度は、残されたSDR範囲の10ニトだけで、全てを正しく表示させることは不可能だろう（標準的に、例えば晴れた屋外領域Rosの最大の白～ルマ1023または輝度100～までのクリッピングがあるので、木々や植え込みは均一な白色領域では見えないことがあり、明るく黄色がかった太陽だけになってしまう）。したがって、より明るいHDR画像領域のうちの幾らかがSDR画像の中で依然として妥当であることを示したいならば、範囲RWの最高の輝度を例えば最大でも50ニトにまで低くしなければならない（これは、横たわる人物の良好なカラフルさが多かれ少なかれ画像の明るい領域のカラフルさよりも好みを有するか否かに依存する）。明るい領域の問題は、明るい領域Rsmにより示されるように、非常に困難になり得る（このサブ範囲についてF_L曲線形状の部分的形状に関して特定の注意深さを必要とする）。曲線のこの部分は、非常に明るい霧の中にあるので、この男は明るい白色を変える低いコントラストの僅かに見える影として示される（「影の男」）。明らかに、SDRでも、男の体の暗いピクセルと周囲の霧の白色との間に、ちょうど知覚可能なさである2％より大きな差が存在するように、曲線のこの部分を調整する必要がある。しかしながら、静的曲線OOTF_fixの場合には、最も暗サブ範囲ＲＤの中のマッピングは、ナイフを持った男が見えすぎるSDR画像をもたらし得ることが分かる。ところが、サブ範囲ＨＳの曲線の上側部分の勾配は低すぎるので、影の男は見えなくなる。したがって、HDR画像輝度再グレーディングは、時にあまり難しくないが、時に非常に困難である。良好な品質を有する、全ての可能な状況を扱うことのできる解決策は、輝度マッピング関数を動的に調整可能である（しかし、これは、それをサポートできない画像に非常に極端なマッピングが適用される危険性を伴う可能性があるが、以下に示すように問題はない）。

【0045】

図4のグラフに、実際の光－光変換関数が示される。しかし、読者は、それが対応する電気－光変換関数にどのように変換され得るかを想像できる。L_SDR輝度は、Rec.709OETFに従い標準的なSDRルマに変換できる。次に、曲線F_L(t1)を、ピクセル明度値に適用する場合、例えばSL-HDR1に従い、HEVC解凍SDR画像で輝度として最初に伝達された場合、再構成HDR輝度を取得するために、入力SDRルマコードと出力HDR光学輝度との間の同等の電気－光変換関数を定義した（実際に、私たちの好適な色処理は、知覚的に不均一なルマによる変換も行うが、最終的な効果は可変EOTFであるので、それらの詳細は本発明にとって重要ではない）。

【0046】

SL-HDR2変形でも、等価なEOTFが存在する。これは、最初の例えばPQ定義ルマを、MDRディスプレイ上で表示されるべきディスプレイ適応された輝度である最終的な出力に変換する。これは、同様に可変EOTFの一例である。

【0047】

動的輝度マッピング関数のみにより動作することは、原理的になんら大きな問題を生じない。2つのビデオが異なるように照らされているが、少なくとも一方が2つの画像シーケンスを何らかの基準表現、例えばPB_C_xおよびPB_C_y再構成HDRに正しく復号できる場合に、該2つのビデオの輝度を調和させる際に依然として問題が生じ得る。これは、各画像が、（例えば、ETSI SL_HDR1またはSL_HDR2の実施形態のうちの幾つかにおける関数の形状を定めるパラメータとして、または他の実施形態における関数のLUTとして）例えば画像時点t00の動的輝度マッピング関数F_L(t00)情報を含むそれ自体の関連する動的メタデータパケット313を有するからである。

【0048】

しかしながら、固定関数によるHDR（またはSDR）の静的符号化は、それらの情報を不定期に、ビデオの全体のセグメント長について数回だけ、送信する必要がある。なぜなら、これは、固定関数であるため、情報が不必要に複製されるからである。

【0049】

したがって、幾つかのコーデックシステム、例えば、SDR（Rec709OETF定義された）ビデオ（または、PQ関数以外の別の静的OETFに従い符号化された他の静的DHRビデオ）の散在するこのようなHDRビデオを生成する純粋なHDR10に基づく（静的なPQ定義されたルマ）HDRビデオ通信システムでは、解決できない問題がある。つまり、セグメント（t1またはt2、等）の変化した後の第2のビデオセグメントの少なくとも幾つかのフレームの粗悪な復号が、例えば変化時の前後で画像の平均明度において（場合によっては深刻な）目に見えるグリッチをもたらす（SDRでは、例えばコンテンツ制作者が例えば暗い洞窟内のアクションと明るい屋外シーンとの間の、またはその逆の良好な遷移を生成しなかった場合、シーン変化が生じ得るが、洞窟は平均的に1ニトより遙かに暗く、明るい領域は100にとより数10倍明るくなり得るので、現在、例えば2000ニトのテレビで、これは、視聴者にとって非常に煩わしいものになり得る）。

【0050】

しかしながら、動的メタデータを有するシステムは、復号問題を良好に解決できる。したがって、動的メタデータパケットは、画像毎に可変輝度マッピングに適用すべき全ての情報を含む。したがって、各画像は、正しく復号できる（または場合によっては、受信側装置の代替の目的である場合には、更に若しくは異なる方法で処理される。受信側装置は、例えば特定の基準状況に調和され、異なるローカルに最適化された輝度マッピング関数を要求し得るが、ルマを意味する入力データがいかなる場合にも明らかに明確でなければならない。したがって、このような二次的なローカルに最適化された調和輝度マッピング関数は、標準的に、デコーダ基準HDR画像に、つまり例えば、受信したSDRルマから、5000ニトPB_C基準輝度範囲にあるHDR輝度へとマッピングする、同時通信される動的に変化する輝度マッピング関数に基づき決定される）。したがって、変化時（t1）の前の静的に決定された（HDR10のような）HDRまたはSDRと、動的に決定された（出願人のSL-HDR1またはSL_HDR_2のような）HDRとの間の変化が存在する場合、変化後に、第1画像は正しく処理できる。なぜなら、それは、適切に定義された予約パケットの中で、同時通信されたそれ自体の動的ルマ関数を有するからである。この詳細は、どのビデオ通信標準が使用されるかに依存する（受信機が、t1前のビデオのビデオセグメントの復号EOTFが何であるかを、その最後のセグメントの時間により良好に決定するので、t1前のビデオも通常復号可能である）。

【0051】

しかし、興味深い状況は、新しい静的に定義されたHDRまたはSDRセグメントが開始するときである。なぜなら、このようなビデオの生成者は、動的メタデータを生成せず、結合された出力ビデオの最終的な放送事業者が問題を良好に解決することを容易にすることも保証することもしないからである。したがって、標準的に、第1画像が、それを復号するための十分なデータを有しない状況が生じる。このようなデータは、最終的に受信されるが、それは、動的HDRの新しいデコーダに、HDR-10型のHDRデコーダと同様に問題ある動作をさせる。

【0052】

このような（静的）データパッケージ（例えばDRAM11）は、標準的に、実際に少なくともEOTF、つまり変化時（t1）との新しいセグメントのルマが復号されるべき静的EOTFを含む。

【0053】

新しい動的HDRデコーダは、DRAM11パケットを変化時間t1より幾らか前に予め送信している対応する新しいHDRエンコーダと共に動作するよう定義される（ビデオを実装する通常の方法は、ビデオがそれ自体のメタデータを含むことであるので、これは少し風変わりに見える。したがって、どこからかセグメントをミキシングすると、DRAMパケットが変更時間の後にそれらの論理的な場所に存在する）。新しいHDRデコーダは、このようなパケットを絶えず探し、突然に予期せず動的メタデータ（313）が消失するときのために、それらをメモリ343に置く。その結果、変化時間t1の後に画像を復号するための適切なEOTFが、ダイナミックレンジ変化デコーダ（プロセッサ（344））の色計算ユニットの輝度処理サブブランチに瞬時にロードするために、利用可能である。

【0054】

実際に、デコーダは、プロセッサ（344）により計算されるセグメントの連続して入力される画像の中で受信されたルマに対応して表示されるべき画像輝度の計算を有し、該プロセッサは、最後に受信したデータパッケージ（DRAM）の中の情報により定められる電気光変換関数を用いてルマを輝度に復号するよう構成される。

【0055】

セグメント変化が生じたか否かを検出するための代替方法が存在し得る。例えば、デコーダは、入力される画像に関連するメタデータまたはヘッダの中の特定のビデオ符号化タイプデータを探してよい。しかし、画像毎の動的に変化可能な電気－光変換関数の存在または非利用可能性によりセグメントの変化を検出するよう構成されるビデオ変化検出器（346）を有するHDRビデオデコーダの実施形態を有することが有利である。

【0056】

これは、依然としてセグメント変化問題のロバストな識別をもたらす、より少ないメタデータしか必要としない。しかし、これは、信号処理と密に統合できる（例えば、通常はデータをパースする、例えば輝度マッピングLUTを輝度処理サブブランチにロードするメタデータ受信受ニットは、特定の画像時間t1についてF_L(t01）のような動的輝度マッピング関数が突然消失したと発見すると、輝度プロセッサLUTに格納されたDRAMパッケージからEOTFを直ちにロードする）。

【0057】

代替として、ビデオ変化検出器（346）は、メタデータ内のコーデック指示パケットの存在を検出するよう構成されてよい（エンコーダがこのようなパケットを同時に供給される場合、これは、例えばバイナリYes／Noにより変化を単に示すだけでよい）。これは、次に、変更された方法で符号化された第1画像、HDRビデオ符号化と同期して受信されなければならない。これは、メタデータ誤りの他のメカニズムが頻繁に生じると予想される場合に、追加のロバスト性を提供する（種々のデコーダの実施形態も、例えばHDR符号化状況に関する追加情報として、それらが受信している画像タイプが何であるかを分析するための他のメカニズムを有してよいが、他の実施形態はそうしなくてよい）。

【0058】

デコーダがメモリに、変化時点(t1)の前に受信した最後のデータパッケージ（DRAM）を格納するよう構成され、その結果、正しいEOTFが使用されるならば、有利である。

【0059】

ビデオデコーダの実施形態は、HDMI（登録商標）またはDisplayPortケーブルで通信されたビデオを受信するよう構成されるビデオ入力（342）を有してよい。例えば、HDMI（登録商標）は、そのメタデータパケット定義において、画像最適化輝度マッピング関数F_L(t0)を含み得る動的な画像毎のパケットと、固定EOTFを定義できる静的（粗い）パケットとの両方を通信する可能性を有する。このHDMI（登録商標）ビデオ通信メカニズムは、それ自体の問題を導入することがある。例えば、セットトップボックスに入力されている放送事業者からの入力ストリームが、比較的良好に構造化されている場合でも、DRAMパッケージの密な同時通信により、ビデオがテレビへと出力されるとき、セットトップボックスの上流では、このようなビデオ通信技術の幾つかの（例えば古い）バージョンが良好な同期を提供しないので、良好な同期が失われることがある。そして、デコーダは、DRAMパッケージを取り入れ、例えばビデオストリーム画像番号に対して指定されていない時点での復号のための使用のためにメモリに入れる。

【0060】

デコーダの新しい能力に対応して、ビデオエンコーダ（3010）は、時間的に連続する画像で構成される高ダイナミックレンジビデオを符号化するよう構成され、ビデオはピクセルカラーを有する多数の時間的に連続する画像（I1,I2）で構成される連続時間セグメント（S1,S2）を含み、異なる時間セグメント内のピクセルカラーは異なる電気光変換関数に従いピクセル輝度に対応するルマを有することにより定められ、セグメントの幾つかの中の画像は、時間的に連続する画像毎の個別関数として送信される動的可変電気光変換関数に従い定められ、他のセグメントの中の画像は、固定電気光変換関数により定められるルマを有し、該固定電気光変換関数の情報は画像反復レートより少ない頻度で送信されるデータパッケージ（DRAM）の中で同時通信され、第1セグメントと第2セグメントとの間の変化時点の後の画像ピクセルルマの電気光変換関数を特徴付けるデータパッケージ（DRAM）のうちの少なくとも1つは、変化時点の前に送信される。このようなエンコーダは、新しいデコーダを含む末端装置が（例えばHDMI（登録商標）ケーブルを介して受信する）混合HDRビデオを正しく復号できる限り、標準的なHDRビデオ通信チェーンの中の様々な場所に置かれてよい。したがって、例えば、それは、テレビ信号放送事業者、例えば英国放送会社のエンコーダであってよい。または、エンコーダは、（セットトップボックスまたはコンピュータのような、あるいは場合によってはBDプレイヤのようなメモリ読み取り機器、等のような）中間ビデオ処理装置321の中に存在してよく、この場合には、エンコーダは、本発明およびその実施形態に従い、粗悪な一時的混合HDRビデオを復号可能な混合ビデオに修正できる。

【0061】

また、興味深いことに、時間的に連続する画像で構成される高ダイナミックレンジビデオを復号するよう構成されるビデオ復号の方法では、ビデオは、ピクセルカラーを有する多数の時間的に連続する画像（I1,I2）で構成される連続時間セグメント（S2,S2）で構成される。異なる時間セグメントの中のピクセルカラーは、異なる電気－光変換関数に従いピクセル輝度に対応するルマを有することにより、定められる。セグメントのうちの幾つかの中の画像は、時間的に連続する画像毎に別個の関数として送信される動的に可変な電気－光変換関数に従い定められる。他のセグメント内の画像は、固定電気－光変換関数により定められるルマを有し、その情報は、画像反復レートより少ない頻度で送信されるデータパッケージ（DRAM）と同時通信される。該データパッケージ（DRAM）のうちの、第1および第2セグメントの間の変化時点（t1）の後の画像ピクセルルマの電気－光変換関数を特徴付ける少なくとも1つのデータパッケージは、変化時点(t1)より前に送信される。該データパッケージのうちの、変化時点(t1)よりピクチャ反復回数(N)だけ早い時点に受信されたデータパッケージ（DRAM）は格納される。時間的に連続する画像で構成される高ダイナミックレンジビデオを符号化するよう構成されるビデオ符号化の方法では、ビデオは、ピクセルカラーを有する多数の時間的に連続する画像(I1,I2)で構成される連続時間セグメント（S1,S2）で構成される。異なる時間セグメント内のピクセルカラーは、異なる電気－光変換関数に従いピクセルルマに対応するルマを有することにより、定められる。セグメントのうちの幾つかの中の画像は、時間的に連続する画像毎に別個の」関数として送信される動的に可変な電気－光変換関数に従い定義される。他のセグメントの中の画像は、固定電気－光変換関数により定められたルマを有し、その情報は、画像反復レートより少ない頻度で送信されるデータパッケージ（DRAM）の中で同時通信される。該データパッケージ（DRAM）のうちの、第1および第2セグメントの間の変化時点(t1)の後の画像ピクセルルマの電気－光変換関数を特徴付ける少なくとも1つのデータパッケージは、変化時点(t1)より前に送信される。

【0062】

技術に依存して、1つのみのDRAMパッケージが、HDR符号化方法の変化時点の前に通信される場合、パッケージが変化時間に近すぎない、または変化前より早すぎないよう送信されるならば最適である。標準的に、4分の1秒、2分の1秒、および／または1秒は、良好な送信時間である。したがって、これは、例えば50Hzビデオでは、新しい静的HDR符号化方法に従い符号化される第1フレームの前の例えば10フレーム、25フレーム、または50フレームに対応し得る。以下の説明は、デコーダがこのような予め送信されたDRAMの属する画像時点をどのように容易に決定できるかを詳細に説明する。

【図面の簡単な説明】

【0063】

本発明による方法及び機器の上述及び他の態様は、より一般的な概念を例示し単に非限定的な特定の説明として機能する、以下に記載する実装及び実施形態及び添付の図面から明らかであり、それらを参照して教示される。種々の実施形態または使用に依存して図中の破線はコンポーネントが任意であることを示すために使用され、破線ではないコンポーネントは必ずしも必須ではない。破線は、必須であると説明された要素がオブジェクトの内部に隠されていることを示すため、または例えばオブジェクト／領域の選択のような無形の事柄（それらがディスプレイ上にどのように示され得るか）のためにも使用され得る。

【0064】

以下の図がある。

【図1】高ダイナミックレンジ画像を対応する最適な色グレーディングされた同様の外観の（それぞれ第1および第2ダイナミックレンジDR_hおよびDR_sにおける所望の妥当な所与の差と同様に）低いまたはより正確には標準的なダイナミックレンジ画像に最適にマッピングするときに生じる多数の標準的な色変換を概略的に示す。可逆性の場合に、HDRシーンを符号化したSDR画像の、該シーンの再構成HDR画像へのマッピングにも対応し得る。

【図2】高ダイナミックレンジ画像、つまり少なくとも700ニトまで（つまり少なくともSDR画像の7ｘPB_C）又は標準的にそれより高い（実際に、現在は、HDR画像は標準的に1000ニト以上のPB_Cを有する）ピクセル輝度を有することの可能な画像を符号化する技術の一例を概略的に示す。当該技術は、HDR画像を、SDR画像、及びピクセル色について少なくとも適切な決定された輝度変換F_Lを含む色変換関数を符号化するメタデータとして実際に通信可能である。これらは、受信したSDR画像をHDR画像に変換するためにデコーダにより使用される。このHDR画像は、画像生成側で生成された元のマスタHDR画像の忠実な再構成である。標準的な画像通信技術の再利用は、例えばHEVC符号化のようなSDR通信のために既に開発されている。

【図3】時間的に混合されたビデオ3010の新しいデコーダ341およびエンコーダを有する、本発明に従うシステムの一例を概略的に示す。

【図4】動的EOTF（およびOETF）に対応する、本発明の枠組みにおける、動的に変化する輝度マッピング関数の概念を概略的に示す。

【図5】本発明に従うエンコーダの実施形態を概略的に示す。

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

【0065】

図3は、全ての生じるHDRセグメント符号化方法（および散在するSDRビデオ）を復号できる新しいデコーダ314を有する新しいHDRコーデックエコシステムの一例を示す。コンテンツ制作者、またはより正確には再配信者は、もちろん、全ての入力ビデオを共通の輝度範囲にマッピングし、これを単一のコードにより送信しようとするが、これは他の必須ではない容易な技術を必要とし、常に行われるものではない。標準的に、将来数年のうちに確実に、例えばスポーツテレビ放送は、イベントをキャプチャする高品質HDRを放送するだろう。しかし、間には、コマーシャルが例えばSDRで存在するだろう（このコンテンツの制作者は、HDR領域にまで明るくされたとき彼のSDR録画の中でクリッピングする明るい領域に何が起こるかと言うと満足しないので、HDRへの変換を望まないか禁止することもある）。また、必ずしも全ての配信技術が、実際のコーデック変換を行うことができるのではない。特に、幾つかの新しいコーデックは、それら自体の原理および技術的特性を持ち続けているからである（特に、例えば消費者携帯電話機よりも頻繁に変更されない高価な業務用機器）。

【0066】

ビデオ配信機器の一例として（読者は、例えばインターネットに基づくOTT配信等のような他の実施形態を同様に想像できる）、テレビ放送事業者がある。テレビ放送事業者は、その設備で、第1ビデオソース302（例えば、HDR10で符号化された予め録画されたsoap）および第2ビデオソース303（例えば、この時点で放送されるべきローカルに格納されたコマーシャル）からのビデオをミキシングできるビデオミキサ301を運用する。最も単純な実施形態におけるビデオミキサは、時間において種々の符号化されたセグメントを連結するだけである。原理的に、これは（SDR時代におけるように、全ての可能なビデオに対して一意に定められたSDRルマのみが存在するとき）符号化されたビデオ色空間で生じるならば、悪くない。つまり、HDR10セグメントのHEVC画像はY'^*CbCr色を有し通信され、これらの色成分は、SMPTE ST.2084において定義されるPQ OETFに従う元の線形RGBピクセルカラーにおよびRec.709に従うSDRルマ、等について計算される。上述のように、連続的に生じる同じ10または12ビットのルマコードは、したがって、連続するセグメントにおいて実際の線形RGB色とは何からの非常に異なるものを意味し得る。しかし、良好に行う場合には、これらの最終的なRGB色は任意の受信機において正しく決定できる（良好に行われない場合には、正しく決定できない）。ビデオエンコーダ3010は、例えばHEVC圧縮を、全ての連続する画像の中のピクセルの全てのYCbCr色に適用するだけであり得るが、エンコーダが本発明に従い機能する場合、復号関数方法の生成に関して注意しなければならない。つまり、パケット313のような動的輝度マッピング関数メタデータパケット、および本例ではPQ EOTFを通信するパケットDRAM11のような適切なEOTFコード化（codification）による静的パケットである。動的関数F_L(t00）、F_L(t01）、等は、本例のSL-HDR1セグメントのような動的に符号化されたHDRでは、それぞれの画像I1,I2毎に通信される。静的パケット、DRAM11、および幾つかの他の反復は、標準的に、同期化されたまたは同期化可能なメタデータに種々の方法で、しかし少なくとも1つの従うべき原理に従い符号化されてよい。少なくとも1つのDRAM11パケットは、HDR10符号化ビデオが開始する変化時間t1より画像反復回数Nだけ前に（例えば、システムまたは標準的に何を行うかに依存して、2画像または10画像だけ前に）、つまり前の時点T0Xで、出力ストリームに挿入されるべきである。例えば結合DHRビデオ信号Scmbとしてアンテナ304により送信されるようなビデオエンコーダの出力は、したがって、時間に渡り3つの部分として送信される。つまり、セグメントS1～S4を有するビデオストリーム310、動的メタデータストリーム311（もちろん、動的輝度関数を送信する場合、十字はこのような動的メタデータの存在しない時間を示す）、および第2メタデータストリーム312の中に1個の固定EOTFだけの情報を有する不規則データパッケージ（DRAM）である。例えば、2個のパケットDRAM31およびDRAM32が示され、これらは、HLG符号化HDRビデオセグメントを特徴付ける、つまりそれらのメタデータの中でHLG EOTFを示す（当業者は、これを行う種々の方法があるが、標準的に動的関数はそれらの形状を定義される必要があり、一方で、固定EOTFはいくつかの種類（flavor）にのみ存在するため、DRAMパケットにはEOTFバージョン番号のみが含まれる場合があり、例えば、1はHDR10を意味し、2はHLGを意味する、等であることを理解できる）。

【0067】

図5に新しいビデオエンコーダ510の一例が示される（一般性を失わずに、以下では読者がセットトップボックス内にあり、自身の出力521により例えばHDMI（登録商標）ケーブルを介して非圧縮混合HDRビデオデータを出力する前に入力混合HDRストリームを「修正すると」想定する一例）（明確に言うと、非圧縮は、線形RGBである標準的な付加的な色符号化と異なる色符号化により、色が符号化できないことを意味しない；非圧縮は、単に、HDMI（登録商標）ケーブルを介して伝搬するビデオがHEVCまたはAVC圧縮されていないことを意味するが、受信機、例えばテレビは、依然として、自身のディスプレイパネル345を駆動するために適切な線形RGB色への色変換を必要とし得る）。

【0068】

入力520への入力トリプル混合DHRビデオ（つまり、ピクセル化された（pixellized）ビデオ画像データ、および画像ピクセルルマコードを正しく復号するための情報を含む2つのメタデータストリーム、または一般にそれらの色コード）は、図3により説明されたように、不正確なタイプのものである。なぜなら、DRAMパケットは、その対応するHDR10ビデオデータセグメントS2と例えば時間的に重なり合うからである（放送事業者は、ビデオが入力するとき、例えば単純なスイッチにより、ビデオを互いの間で単にシャッフルすると仮定する）。

【0069】

出力521で、新しいHDR混合ビデオ信号が生成される。これは正しく、2つの例示的な可能性が与えられる。パケットDRAM11は、前の通信時点へと単にシフトされる。これは、t1の後の点線パケットにより示されるように、その元の位置で再送信れないことを意味する。HLGについて、複製の可能性が示される。コピーDRAM11は、変化時間ｔ3の前に通信されるが、元のDRAM31パケットも、その元の時間に送信される。これは、静的パケットを複数回複製することが有利であるためである。

【0070】

図3に戻ると、例示的な受信側の実施形態が示される。図3は、中間ビデオ処理装置321を含む。中間ビデオ処理装置321は、その入力320により、例えば衛星放送（復調、等）を受信し、復調した標準的には伸張されたビデオを、自身の出力322により、例えばHDMI（登録商標）ケーブル、無線確立リンク、等である場合もあるビデオ通信リンク330を介して、ディスプレイシステム340へと通信する。当業者は、不揮発性メモリ機器がディスプレイシステムの代わりに用いられる場合、例えば正しくフォーマットされた混合ビデオが後の使用のために格納される場合、等に、別の実施形態がどのように動作するかを想像できる。

【0071】

ディスプレイシステムは、ビデオ処理部を含む。ビデオ処理部は、ビデオデコーダの入力を介して混合HDRビデオを受信し、プロセッサ344により後に使用されるためにDRAMのうちの少なくとも1つを格納するメモリ343を含む。プロセッサ344は、これを用いて、入力画像と異なるダイナミックレンジの画像に例えばビデオ復号のダイナミックレンジ変換を標準的に含む正しい色変換を、または同じ符号化の範囲内、つまり同じダイナミックレンジ、例えばSDR等のルマから輝度への復号自体を適用する。このようなデコーダは、復号が少なくとも1つのDRAMパケットからの情報を依然として必要とする全ての状況を扱うことができる（何からの情報が動的であり、良好な復号を行うのに十分な量の情報がなかったとしても）。私たちは、簡単のため、動的メタデータが、現在入力画像をSDRおよびHDR画像を含むいかなるMDR画像に復号することを可能にする完全な情報を意味し、静的が復号のために少なくとも何らかの静的情報を必要とすることを意味し、この静的情報が粗に利用可能なおよび／または非同期のDRAM情報に含まれ得ると仮定する。幾つかの実施形態は、有用なことに、ビデオ変化検出器（346）を有してよい。ビデオ変化検出器（346）は、動的メタデータ、つまり標準的には連続画像の動的輝度マッピング関数の消失または出現を見分けることにより、このようなセグメント変化を検出するよう構成される。

【0072】

代替として、デコーダは、変化を示す同期した新しいメタデータパケットの存在を検出することにより、後の新しい静的（つまり入力ビデオと常に同期した全ての情報を有しない）画像コーデックの変化が生じると、トリガ（または同期化）されてよい（送信機により送信される場合には、このような改良された実施形態の任意的特性のために、コーデック変化指示パケット（change-of-codec indication packet：CHOC）は図5で点線で示される）。例えば、ビデオ変化検出器（346）の実施形態は、動的メタデータ輝度マッピング関数またはCHOCパケットまたはその両者の非利用可能性をテストしてよい。幾つかの実施形態は、受信したビデオデータの他の特性を更にテストしてよい。CHOCパケットがその入力時に既に利用可能である場合、本発明のエンコーダの対応する実施形態を含むいかなる元のまたは中間機器は、CHOC2パケットのような自身の出力ストリームの中で単にそれを同時コピーしてよく、その他の場合、このような正しく同期化されたCHOC2パケットを生成（コーデック変化指示パケットを出力）してよい。

【0073】

私たちは、理解を簡単にするために関数を教示し、幾つかの実施形態では、画像（時点）のための関数のセットが通信でき、該関数のセットは連結されて適用されるが、私たちの新しい技術の基礎を大きく変更しないことに留意する。

【0074】

本明細書で開示されたアルゴリズムのコンポーネントは、（全体的に又は部分的に）実際にハードウェアとして（例えば特定用途向けＩＣの部分）、又は専用デジタル信号プロセッサ又は汎用プロセッサ等で実行するソフトウェアとして実現されてよい。

【0075】

私たちの提示から、どのコンポーネントが任意の改良であってよく、他のコンポーネントと組み合わせて実現可能であり、及び方法のどんな（任意の）ステップが機器のそれぞれの手段に対応するか、及びその逆が、当業者に理解されるべきである。本願における用語「機器」は、その広義の意味で使用される。つまり、特定の目的の実現を可能にする手段のグループであり、したがって、例えばＩＣの（小回路部分）、又は専用機器（例えば、ディスプレイを備える機器）、又はネットワーク接続されたシステムの部分、等である。「構成」も広義の意味で使用されることを意図している。したがって、これは、特に、単一の機器、機器の部分、協働する機器の（部分の）集合、等を含んでよい。

【0076】

コンピュータプログラムプロダクトの表記は、汎用又は専用プロセッサを、コマンドをプロセッサに入力するための一連のロードステップ（これは、中間言語及び最終プロセッサ言語への変換のような中間変換ステップを含んでよい）の後に、いかなる発明の特徴的機能を実行可能にするコマンドの集合のいかなる物理的実現も包含すると理解されるべきである。特に、コンピュータプログラムプロダクトは、例えばディスクまたはテープのような担体上のデータ、ネットワーク接続（有線又は無線）を介して伝搬するデータ、又は紙上のプログラムコードとして実現されてよい。プログラムコードとは別に、プログラムのために必要な特性データも、コンピュータプログラムプロダクトとして具現化されてよい。

【0077】

方法の動作のために必要なステップのうちの幾つかは、データ入力及び出力ステップのようにコンピュータプログラムプロダクトに記載される代わりに、既にプロセッサの機能に存在してよい。

【0078】

理解されるべきことに、上述の実施形態は本発明を限定するのではなく説明する。当業者が特許請求の範囲の他の領域への提示の例のマッピングを容易に実現できる場合、私たちは、簡潔さのために、全てのこれらの選択肢を深く言及しない。特許請求の範囲の中で結合されたような本発明の要素の組み合わせとは別に、要素の他の組み合わせが可能である。要素のいかなる組み合わせも、単一の専用要素で実現できる。

【0079】

特許請求の範囲の中の括弧内のいかなる参照符号も、請求項を限定することを意図しない。用語「有する」又は「含む」は、請求項に列挙されない要素又は態様の存在を排除しない。要素の前の用語「1つの」は、該要素の複数の存在を排除しない。

【図1】

【図2】

【図3】

【図4】

【図5】