2020-08-30

BT.2446 Method C の Crosstalk matrix の効果を確認した

背景

前回の記事で Report ITU-R BT.2446 Method C の実装例の紹介を行った。

trev16.hatenablog.com

そこで以下の内容を書いた。

※3 Crosstalk matrix, Chroma correction に関しては筆者の理解が浅いため本記事では解説しない。できれば理解を深めた後に別記事で解説したいと思っている。

Crosstalk matrix に関して少しだけ理解が深まったので、この Matrix によって出力結果がどのように変化するか記録を残すことにした。

注意事項

本記事で用いる HDR to SDR 変換 (BT.2446 Method C の Tone mapping) という用語は輝度方向の変換のみを意味する。 BT.2020 to BT.709 などの色域の変換は含まないことに注意して頂きたい。

目的

Crosstalk matrix が HDR to SDR変換に与える効果をパラメータ ${\alpha}$ を変化させながら動画で確認する
目視レベルの簡単な考察を行う

結論

Crosstalk matrix のパラメータを 0.00～0.25 に変化させた場合の Gamut Boundary の変化を以下の動画に示す
- 外側の黒色の部分が Crosstalk matrix を適用し HDR to SDR 変換した後の Gamut Boundary である
- 図の詳しい意味は後述する

動画よりパラメータ ${\alpha}$ は 0.05 くらいでは色ズレの抑制に効果がありそうだが、0.20 などの大きな値では逆効果となることが分かる

Crosstalk matrix の概要

BT.2446 Method C において Crosstalk matrix および逆変換の Inverse crosstalk matrix は図1に示す通り、Tone mapping の前後の RGB空間で行う。XYZ空間で行う処理ではないことに注意したい。なお、以後の説明では簡略化のため Inverse crosstalk matrix に関しては「適用する・しない」を明記しない。Inverse crosstalk matrix は必要に応じて適切に適用されるものとする。

f:id:takuver4:20200730160158p:plain — 図1. BT.2446 Method C のブロック図

Crosstalk matrix の計算式を図2に示す。R, G, B の3色を混合するような処理なので白色点に近づく処理になっていそうである。

f:id:takuver4:20200829091456p:plain — 図2. Crosstalk matrix の計算式

実際に ColorChecker の24色パッチに適用して効果を確認してみる。今回は SDR の BT.2020 空間で ${\alpha = 0.10}$ 、 ${\alpha = 0.20}$ の Crosstalk matrix を適用した。結果を図3、図4 に示す。ColorChecker の各色は白色点に近づくように変化していることが分かる。



図3. ${\alpha = 0.10}$ の Crosstalk matrix を適用した結果	図4. ${\alpha = 0.20}$ の Crosstalk matrix を適用した結果

続いて xyY空間にて3次元的な変化量を確認する。ColorChecker の24色パッチに ${\alpha = 0.10}$ 、 ${\alpha = 0.20}$ の Crosstalk matrix を適用し xyY空間でプロットした結果を以下の動画に示す。

動画から Y値は増加・減少の双方のパターンがあり、その変化量は色によって異なることが分かる。

ここまでの内容をまとめる。

Crosstalk matrix を適用後の xy値は白色点方向に移動する
Crosstalk matrix を適用後の Y値は色によって増加したり減少したりする

HDR to SDR 変換への効果

ここまでで Crosstalk matrix の概要を説明した。ここからは Crosstalk matrix を HDR to SDR 変換と組み合わせた場合の効果の確認方法について説明していく。

効果を図で表現したいため今回は xyY空間で Gamut Boundary がどのように変化するかをプロットしてみる。順を追って説明する。

まず、図5に示す HDR10 の Gamut Boundary を準備する。これは Yの範囲が 0.0～100.0 (※1)、色域が BT.2020 の色空間の Gamut Boundary である。この Gamut Boundary に対して Crosstalk matrix を適用し HDR to SDR 変換を行った結果をプロットし効果を確認する。

※1 今回の検証では Y値は 1.0 が 100cd/m2 に相当するよう正規化しています。従って 100.0 が 10,000 cd/m2 に相当します。


図5. HDR10 の Gamut Boundary	図6. Crosstalk matrix 無しで HDR to SDR 変換した後の Gamut Boundary

参考例として Crosstalk matrix 無しの場合の例を図6に示す。BT.2446 Method C の Tone mapping は Y値のみへの適用であり xy値は固定のため変換後の Gamut Boundary は三角柱のような見た目になる。

それでは実際に Crosstalk matrix を適用してみる。パラメータ ${\alpha}$ を 0.00～0.25 に変化させた場合の Gamut Boundary の様子を以下の動画に示す（冒頭の結論に貼り付けたものと同じです）。

黒色が HDR10 の Gamut Boundary の変化後をプロットしたもの、内側の色付きの部分は SDR の BT.2020色域の Gamut Boundary である。BT.2446 Method C の HDR to SDR 変換では最後に xyY to RGB 変換が行われるため、内側の色付きの部分をはみ出した部分はクリップされてしまう、すなわち色ズレが生じることとなる。

動画を詳しく見ると ${\alpha = 0.05}$ では Gamut Boundary の形状が青領域で理想形に近づいており色ズレの抑制に効果がありそうである。一方で ${\alpha = 0.20}$ では逆に Gamut Boundary が拡大してしまっており、色ズレが発生する箇所が増加していそうである。

では最後の確認として、HDR10 で作成したテストパターン (白は 400cd/m2、BT.2020色域) に対して Crosstalk matrix および HDR to SDR 変換を行った結果を目視で確認してみよう。結果を図7～10 に示す。 ${\alpha = 0.05}$ では良さそうに変換できているが（主観でスミマセン） ${\alpha = 0.20}$ では彩度の高い箇所で色潰れが発生しており、Gamut Boundary のプロット結果と同じ印象を受ける。


図7. ${\alpha = 0.00}$ の場合	図8. ${\alpha = 0.05}$ の場合
図9. ${\alpha = 0.10}$ の場合	図10. ${\alpha = 0.20}$ の場合

考察というか感想

Crosstalk matrix の効果を無理やり図にすることで、なんとなくの雰囲気は理解できた。本当は数式から理論的な裏付けを行いたかったが自分の頭では無理だったので、プロットした結果から色々と考える方法でお茶を濁した。

こういうプロットはやっていて楽しかったし、他の色処理のデバッグなどにも流用できそうなので（流用できるようにコードを整備したので）なかなか良い勉強になったと考える。

2020-08-01

BT.2446 Method C (HDR to SDR 変換) を実装してみた

1. 背景

以前から個人でお手軽に使える HDR to SDR 変換の 3DLUT を作りたいと思っていた。2019年に Report ITU-R BT.2446[1] として 3種類の Tone mapping が公開されたので実装することにした。

今回は Method C の NHK が提案した方式を実装した。理由としては技研公開2019 で説明員の方に BT.2446 について聞いたところ「Methoc C は実装が簡単なのでオススメですよ」と教えてもらったからである。

2. 目的

Report ITU-R BT.2446 Methoc C の Tone mapping を実装する。なお筆者の独自拡張として以下2点の変更を加える。
- BT.2446 Methoc C が想定している HDR の特性は HLG だが、今回作るものは PQカーブ（ST2084）を想定したものとする
- BT.2446 Methoc C が想定している SDR の範囲は over-white 領域を含む 0～109% だが、筆者は over-white 領域が苦手なので 0～100% を対象とする。
先日に作成した Report ITU-R BT.2407 Annex 2 の Gamut mapping と組み合わせて HDR10 to BT.709 の HDR to SDR 変換 3DLUT を作る。

3. 結論

3.1. 結論1

Report ITU-R BT.2446 Methoc C の Tone mapping 実装に成功した
- SDRレンジ優先の 1000 cd/m2 用と高輝度レンジ優先の 4000 cd/m2 用の2種類を作成した。特性を図1と図2 に示す。


図1. 1000 cd/m2 コンテンツ用の Tone mapping の特性	図2. 4000 cd/m2 コンテンツ用の Tone mapping の特性

3.2. 結論2

BT.2446 Method C と BT.2407 Annex 2 を組み合わせた HDR10 to BT.709 変換の 3DLUT の作成に成功した
- 1000 cd/m2 用と 4000 cd/m2 用の2種類を作成した。テスト用のソース画像に適用した結果のまとめを図3 に示す。

	1000 cd/m2 用の 3DLUT を適用	4000 cd/m2 用の 3DLUT を適用	輝度マップ情報
①
② ※2
③ ※3
④ ※2

図3. HDR to SDR 変換の結果

①テストパターン、②暗い画(※2)、③スキントーンを含む画(※3)、④明るい画(※2)

※2 画像は "Mark Fairchild's HDR Photographic Survey"[2] より借用
※3 画像は "HdM-HDR-2014"[3] の Showgirl 1 より借用

作成した 3DLUT は以下に置いた。なお、今回作成したものは後述する通り幾つかの欠点がある。もしも利用したい方がいる場合は考察の図7 に示した欠点を事前に参照して頂きたい。

drive.google.com

4. 理論

4.1. 処理の大まかな流れ

Report ITU-R BT.2446[1] より引用した Block Diagram を図4に示す。BT.2446 Method C には以下の特徴がある。

Tone mapping は Linear 空間で行う（BT.2390 の Display Mapping[4] は Non Linear空間で行っているがそれとは異なる）
Tone mapping は xyY色空間の Y に対して行う
Crosstalk matrix を使って高輝度かつ彩度の高い色の色ズレを防いでいる（※3）
Chroma correction を使って Reference White より高い輝度の色を自然に白飛びさせることが出来る（※3）

※3 Crosstalk matrix, Chroma correction に関しては筆者の理解が浅いため本記事では解説しない。できれば理解を深めた後に別記事で解説したいと思っている。2020.08.30 追記：別記事を書きました。

trev16.hatenablog.com

4.2. 詳細

具体的な計算式の説明は Report ITU-R BT.2446[1] にキッチリと書かれている。よって、ここでは Tone mapping の設計時に変更可能なパラメータと、そのパラメータが Tone mapping にどう影響するかを解説することにする。

まず数式の変数(パラメータ)と Tone mapping の特性の対応関係を整理しておく。以下の数式および図5 を参照してほしい。

f:id:takuver4:20200730173709p:plain — BT.2446 Method C の数式

f:id:takuver4:20200730173725p:plain — 図5. 数式の変数と Tone mapping の特性の対応関係

数式および図5 から分かるように Tone mapping は Knee point までは直線、その先は Logカーブという特性になっている。この特性のうち Tone mapping 設計者が制御可能なのは以下の3点である。それぞれについて簡単に解説する。

Y_SDR,ip の値
Y_HDR,ip の値
Logカーブを使った高輝度領域の圧縮具合

まず Y_SDR,ip は SDR の Knee point の輝度を指定するパラメータである。オリジナルの BT.2446 Method C では 58.5 cd/m2 の固定値となっていたが筆者は変更したかったので可変とした。筆者は 40～60cd/m2 あたりを想定したパラメータだと考えている。

次に Y_HDR,ip は HDR の Knee point の輝度を指定するパラメータである。ここで指定した輝度までは Tone mapping の前後で歪むことが無い。理想を言えば 1000cd/m2 くらいを指定したい。しかしそれをやってしまうと全体の絵が暗くなり過ぎる。本アルゴリズムでは 50～80 cd/m2 あたりの値を想定したパラメータだと考える。

最後の Logカーブはどのくらいの高輝度領域まで圧縮対象とするかを設定できる。例えば 1000 cd/m2 以上の値は圧縮しない、といった制御ができる。

実際にそれぞれのパラメータを変更させた様子を以下の動画に示す（少し長いので必要に応じて早送りをして下さい）。

5. 他の HDR to SDR 変換方式との比較

今回は YouTube の HDR to SDR 変換と比較した。結果を図6 に示す。なお、YouTube の HDR to SDR 変換は以下の記事で作成した 3DLUT によるエミュレーションである。実際に YouTube にアップロードして変換してはいないので注意して頂きたい。

trev16.hatenablog.com

	1000 cd/m2 用の 3DLUT を適用	4000 cd/m2 用の 3DLUT を適用	YouTube の HDR to SDR 変換
①
② ※2
③ ※3
④ ※2

図6. YouTube の HDR to SDR 変換との比較した結果

①テストパターン、②暗い画、③スキントーンを含む画、④明るい画

少し意地悪なコンテンツの選び方をしたため、筆者の実装した BT.2446 Method C の方が性能が良く見える。しかし、実際はそんなことは無く筆者の実装にも問題点は存在する。次の考察で少し述べる。

6. 考察

注意：以後の考察は筆者が決定したパラメータを適用した BT.2446 Method C に対しての考察です。パラメータの決め方によって長所・短所は変わることにご注意下さい。

今回の記事では権利関係の問題で図6 の画像しか載せなかったが、筆者は他の HDRコンテンツ[5] でも比較を行った。その結果、筆者のパラメータを適用した BT.2446 Method C に関しては以下のような長所、短所があることが分かった。

長所

高輝度領域での色シフトが少ない。例えば図6 の最下段では YouTube は空の色がシアンに色がシフトしてしまっている。
スキントーン付近が明るくオリジナルのHDR表示に近い。一方で YouTube は少し暗く表示される。

短所

Reference White よりも下の輝度から Logカーブで丸めているため以下の現象が起こる。
- それほど輝度の高くないところでも白っぽくなる
- 輝度の高い領域でのシャープさが失われる

短所が分かりやすい例を筆者が旅行先で撮影した以下の画像で示す。YouTube の方は陰影が維持されており画が破綻していない。一方で筆者の実装の方は陰影が潰れ気味であり、人によっては「画が破綻している」との判断が下ると考えている。

BT.2446 Method C での変換	YouTube での変換

図7. 今回使用したパラメータで見つかった短所の例

この辺りの短所についてはパラメータを変更することで改善する可能性は高い。今後の検討課題としたい。

7. 感想

BT.2407 Annex2 および BT.2446 Method C の実装を通じて Color Volume の変換がどのようなものが理解が深まった。もう少し勉強を進めて筆者オリジナルの変換方式を考案できるようになりたい。

個人的には Jzazbz 色空間で Tone mapping, Gamut mapping の双方を行うアルゴリズムを考えてみたい。

8. 参考資料

[1] Report ITU-R BT.2446-0, "Methods for conversion of high dynamic range content to standard dynamic range content and vice-versa", http://www.itu.int/pub/R-REP-BT.2446-2019

[2] Mark D. Fairchild, "Mark Fairchild's HDR Photographic Survey", http://rit-mcsl.org/fairchild//HDR.html

[3] Visual Media Lab, "HDM-HDR-2014", https://www.hdm-stuttgart.de/vmlab/hdm-hdr-2014

[4] Report ITU-R BT.2390-8, "High dynamic range television for production and international programme exchange", https://www.itu.int/pub/R-REP-BT.2390-8-2020

[5] Netflix, "OPEN SOURCE CONTENT", https://opencontent.netflix.com/

2020-07-05

テストパターン動画を作った

背景

急にテストパターン動画を作りたくなったので作った。本来であれば色彩工学に関する勉強を色々と進める必要があった。しかし我慢ができなかった…。

成果物

以下のようなテストパターン動画を作った。

良い点

Chroma Subsampling の 4:4:4, 4:2:2, 4:2:0 を目視で判別できるようなドットパターンを入れた（右端）
表示デバイスが 10bit 表示できているか目視で判別できるような Rampパターンを入れた（左端）
テストパターン動画のエンコード作業の自動化に成功した
- テストパターン動画はパラメータとして解像度、フレームレート、ダイナミックレンジの組み合わせが合計12通りある
- これまでは手作業でエンコードしていたが大変手間だった
- そこで DaVinci Resolve Studio で Python スクリプトを使った自動エンコード環境を整えた

悪い点

H.264 や H.265 で圧縮してしまうと、圧縮による画像劣化で Chroma Subsampling や 8bit/10bit の判別が極めて困難になる
- つまり実用性がかなり低い
- 言い訳をしておくと、ProRes や DNxHR などの業務用コーデックなら十分に目視判別が可能である
10bit 表示できているか確認するパターンは「真の 10bit表示」と「8bit + Dithering」の区別がつかない
- 特定環境では 8bit ディスプレイを使っているのに 10bit のように表示されてしまう
Python スクリプトを使った DaVinci での自動エンコードは不完全である
- 一部の設定は事前に手作業で済ませておく必要がある

Chroma Subsampling の判別パターン

テストパターン動画の右側に用意した "WYCGMRB" のドットパターンは 偶数ピクセルスタートと 奇数ピクセルスタートの 2種類がある。これにより Chroma Subsampling に応じた見え方が図1のように変化する。したがってビットレートが極めて高い動画であれば目視で Chroma Subsampling の判別が可能である。

なお、一般的なビットレートの動画では圧縮によってパターンが潰れてしまい目視判別は困難である。

f:id:takuver4:20200705141347p:plain — 図1 Chroma Subsampling による見え方の違い

Chroma Subsampling 確認用の動画

実際の動画で見比べたい場合は以下の動画をダウンロードして確認して欲しい（右クリックして「名前を付けてリンク先を保存」を推奨）。なお、以下の動画は可逆圧縮となるようにエンコード時に -c:v libx264 -qp 0 オプションを適用してある。

1920x1080_4:4:4 (702 KB)
1920x1080_4:2:2 (699 KB)
1920x1080_4:2:0 (806 KB)

なお上記の動画は 8bit でエンコードしてあるので、左側の 10bit パターンは参照しないこと。

10bit 表示の確認パターン

8bit/10bit の差はブログでは説明が困難なので解説は省略します。

なお、本パターンの作成では ELSAさんのサイトにある 10bit確認用の PSDファイルを参考にさせて頂きました。

www.elsa-jp.co.jp

DaVinci Resolve Studio での Python スクリプトを利用した自動エンコード

以下の動画のように自動エンコードするスクリプトを作成した。

しかし、現時点では DaVinci Resolve の Python スクリプトは制約が非常に多い。筆者は制約に悩まされて膨大な量の時間を無駄にした。よって Python スクリプトの使用はオススメしない。

なお、どうしても使ってみたい方は以下の手順で README.txt を参照して欲しい。

DaVinci Resolve Studio の画面から "Help --> Documentation --> Developer" を選択
表示されたウィンドウの "Scripting" フォルダを開く

感想

来週こそは色彩工学の勉強を進めたい。

2020-06-07

Report ITU-R BT.2407 の Annex2 を実装してみた

Color Science BT.2407実装

1. はじめに

この記事は「Report ITU-R BT.2407 の Annex2 を実装」シリーズの3回目です。かなり間が空きましたが失踪せずに少しずつ実装を進めていました。無事に実装が完了したので結果を報告したいと思います。

2. 目的

BT.2407 Annex2 に記載の BT.2020 to BT.709 の Gamut Mapping を実装する。

自身の環境を踏まえて以下の点を意識した実装とする。

①Limited Range の信号前提ではなく Full Range の信号を前提とした処理とする。

BT.2407 Annex2 は NHKが考案した方式ということもあり、現在のTV放送に使用されている Limited Range の信号（940Lv～1019Lv の Overwhite 領域も含む）で扱えるように、CIELAB色空間を拡張して処理を行っている。

一方で自分は基本的に RGB444 Full Range の信号処理にしか興味が無いため、Limited Range を考慮した処理は行わないこととした。

②DCI-P3 to BT.709 の変換も視野に入れた実装とする

BT.2407 Annex2 は BT.2020 to BT.709 変換に最適化したアルゴリズムとなっている。が、自分は BT.2020 以外にも DCI-P3 の信号も扱うことが多い。そのため将来的には本実装を DCI-P3 to BT.709 変換にも応用したいと考えている。

こうした背景もあり BT.2407 Annex2 の Hue Mapping は今回の実装には盛り込まないこととした。理由は BT.2020 to BT.709 に特化したマジックナンバーが複数あり、DCI-P3 to BT.709 変換への応用が困難だと判断したからである（※1）。

※1偉そうに書いていますが、別の言い方をすると自分の頭ではマジックナンバーの意味を正しく理解することが無理だったということです。おバカでごめんなさい…。

3. 結論

どうにか実装が完了した。加えて簡単に扱えるように 3DLUT化も行った。結果を図1～図6に示す。

図1は効果確認用のテストパターンである。水平方向が Hue の変化、垂直方向が Chroma の変化を意味する。また Chroma が BT.709 の Gamut Boundary を超えたブロックは左上に黒いポチを付けてある。本アルゴリズムは BT.709 の外側の色にのみ変換を行う方法のため、内側の色に影響が出ていないことの確認をしやすいよう黒ポチを付けた。

図2～図6 は図1を BT.2020 to BT.709 変換した結果である。より詳しい説明は以下を参照。（はてなブログの画像圧縮を嫌って Google Drive から画像を引っ張ってきています。表示に少し時間がかかる場合があります）

図1：BT.2020空間での評価用テストパターン（※2）
図2：BT.2020空間での Gamut Mapping の実行結果（※2）
図3：BT.2020 to BT.709 の Gamut Mapping したものを BT.709 色域で表示したもの（※3 ）
図4：筆者にとっての従来手法である 3x3 の Matrix で変換したものを BT.709 色域で表示したもの。図3との比較用（※3 ）
図5：図1と図2をアニメーションで切り替え（※2）
図6：図3と図4をアニメーションで切り替え。筆者にとっての従来手法と BT.2470 Annex2 との比較（※3 ）

※2 BT.2020カバー率100%の表示デバイスでご確認下さい
※3 一般的な BT.709色域の表示デバイスでご確認下さい



図1. 効果確認用テストパターン(BT.2020色域, Gamma=2.4)	図2. 図1 を Gamut Mapping した結果(BT.2020色域, Gamma=2.4)



図3. 図1 を Gamut Mapping した結果(BT.709色域, Gamma=2.4)	図4. 図1 を 3x3 の Matrix で BT.2020 to BT.709 変換した結果(BT.709色域, Gamma=2.4)



図5. 図1と図2をアニメーションで切り替え(BT.2020色域, Gamma=2.4) 表示されない場合はココをクリック	図6. 図3と図4をアニメーションで切り替え(BT.709色域, Gamma=2.4) 　表示されない場合はココをクリック

図5 より BT.709 の Gamut Boundary の外側のデータのみが Mapping されていることが分かる。BT.709 の Gamut Boundary の内側のデータは変化しておらず意図した結果となっている。

加えて図6 より筆者にとっての従来手法である 3x3 の Matrix 変換と比較して、本手法では Hue のズレや色潰れが無くなっていることが分かる。

作成した 3DLUT は以下に置いた。興味があれば自由に使って頂いて問題ない（自分で言うのも何ですが DaVinci Resove の OpenFX の Color Space Transform を使った方が安心・安全だと考えます）。

drive.google.com

4. 理論

4.1. 概要

BT.2407 Annex2 の Gamut Mapping について簡単に説明する。

まず大前提として Gamut Mapping は CIELAB色空間で行う。IPT や CIECAM02 などを使わない理由は、BT.709 の色域外の「彩度が高い」領域で人間の視覚特性とマッチしない箇所があるためである。

さて、Gamut Mapping は以下の3つの要素から成り立っている。このうち Hue Mapping は冒頭で述べた理由により実装しない。

Lightness Mapping
Chroma Mapping
Hue Mapping <-- 今回は実装しない

ここから Lightness Mapping と Chroma Mapping の概要を説明する。この2つの Mapping は CIELAB色空間から算出できる Chroma-Lightness平面上で行う。この平面上で処理を行うことにより、Mapping の前後で CIELAB色空間での Hue は維持される。

BT.2407 Annex2 の Mapping 方法を説明する前に、そもそも Mapping の方法にはどういったものが考えられるか例を挙げておく。

図7. Chroma-Lightness 平面上での Gamut Mapping の例

図7 では BT.2020 色域のある点 (A) を BT.709 色域に Mapping している。図から読み取れるように Mapping の方法にはバリエーションが存在する。例えば (B) は Lightness の保持を最優先して、Chroma が大幅に減少したとしても Lightness を保持するようにしている。一方で (C) は Chroma を最優先して、Lightness が大幅に減少したとしても、Chroma を保持するようにしている。他にも Chroma-Lightness平面上で Mapping 前後のユークリッド距離を最小化する、などの方法も考えることができる。

さて、今回実装した BT.2407 Annex2 は (D) に示した方法となっている。(B), (C) の中間のような感じである。この座標がどのように算出されるのか以降で説明していく。

4.2. 詳細

先程の図7 の (D) に示した Mapping を実現するために、BT.2407 Annex2 では L_focal, C_focal と呼ばれる点を設定し、この点を基準として Gamut Mapping を行う。順を追って説明する。

4.2.1. L_focal の生成

L_focal を求めるには以下のステップを経由する。

BT.709 cusp と BT.2020 cusp を計算
上記の2つの cusp から L_cusp を計算
L_cusp の範囲を制限することで L_focal を生成

BT.709 cusp と BT.2020 cusp はそれぞれ Chroma-Lightness平面で最も Chroma が大きい点を意味し、L_cusp は BT.709 cusp と BT.2020 cusp を通る直線と Lightness軸との交点を意味する。文章での説明よりも動画の方がわかりやすいと思うので以下の図8 を参照して頂きたい。

図8. BT.709 cusp と BT.2020 cusp と L_cusp の関係

L_cusp が求まったら L_cusp の値を制限することで L_focal が生成できる（※4）。制限した結果を図9 に示す(図は筆者が書いたものではなく BT.2407 の Figure2-4 をコピペしたもの)。

※4 制限する明確な理由はなんとなくしか理解できてないので本記事では言及しない。ちなみに自分の実装では制限しないと破綻が起こった。

4.2.2. C_focal の算出

次に C_focal の算出方法について説明する。C_focal は BT.709 cusp と BT.2020 cusp を通る直線と Chroma軸との交点の絶対値である。したがって、以下のように2パターンが存在する。

パターン	図 (a) は BT.2407 の Figure A2-3 をコピペしたもの。(b) は Figure A2-3 を加工したもの
図10. パターン (a)
図11. パターン (b)

(a) は Chroma軸との交点が正の値となるケース、(b) は Chroma軸との交点が負の値となるケースである。いずれにせよ絶対値を取るため最終的な C_focal は正の数のみとなる。

4.2.3. L_focal, C_focal を基準とした Mapping 処理

L_focal, C_focal が決まった後は、この点を基準に Mapping を行う。はじめに具体例を図12 に示す。

図12 では BT.2020 色域の src point を BT.709 色域の dst point に Mapping している。図から分かるように、L_focal, C_focal を結ぶ直線よりも上側のデータは L_focal へ収束する直線上で、下側のデータは C_focal から発散する直線上で Mapping を行う。これが BT.2407 Annex2 の方式である（※5）。

Mapping先は BT.709 の Gamut Boundary である。この方法だと focal を基準とした直線上のデータは同一の Chroma, Lightness値に Mapping されるため色潰れが生じることを懸念するかもしれない。しかし色潰れが生じる可能性は極めて低い。実画像では Chroma が変化するとともに Lightness も変化するが、その変化が focal を基準とした直線に乗り続ける可能性が低いからである。この直線から外れると Mapping 後の値にも差が生じるため色潰れが生じることはない。

※5 この Mapping 方法が BT.2020 to BT.709 で適切な理由は分かっていない。個人的には L_focal を BT.709 cusp と BT.2020 cusp の中間の Lightness値にしても良いのでは？と思っている。

5. 実装

ここまでに述べてきた理論を実際に実装する。

5.1. 処理の大まかな流れ

初めに処理の大まかな流れを説明しておく。以下の図を参照して欲しい。

入力のRGB(Gamma=2.4)を Lab, LCH(Lightness, Chroma, Hue) に変換
該当する Hue の Chroma-Lightness平面をプロット
BT.709 cusp, BT.2020 cusp を算出
L_cusp, L_focal, C_focal を算出
入力の LCH から L_focal を使うのか C_focal を使うのか判別
判別した focal 基準で BT.709 の Gamut Boundary に Mapping
Mapping 後の LCH から RGB(Gamma=2.4)を算出する

項目	L_focal 基準の変換例	C_focal 基準の変換例
1
2
3, 4, 5
6
7

さて、上記の処理はそれなりにボリュームのある処理である。画像の全RGB値に対してバカ正直に処理すると重くなってしまう。

そこで今回の実装では Mapping処理を「入力のRGB値に依存しない処理」と「入力のRGB値に依存する処理」に分け、前者に関しては事前に計算しておき LUT化することにした。

具体的には以下のLUTを作成した。

Gamut Boundary 2DLUT
- BT.709, BT.2020 の Gamut Boundary 情報の入った 2DLUT
L_focal 1DlUT
- L_focal 情報の入った 1DLUT
C_focal 1DLUT
- C_focal 情報の入った 1DLUT
Chroma Mapping 2DLUT for L_focal
- 任意の Chroma-Lightness 平面での L_local からの角度 D_l のデータに対する L_focal からの距離 R_l の入った 2DLUT
Chroma Mapping 2DLUT for C_focal
- 任意の Chroma-Lightness 平面での C_local からの角度 D_c のデータに対する C_focal からの距離 R_c の入った 2DLUT

以降では、LUTの作成および使用方法を交えながら実装内容について説明していく。

5.2. BT.709, BT.2020 の Gamut Boundary を算出

基本的な理論は前回のブログで記した通り。ただし、この記事で書いた手法は遅すぎたため現在は別の手法を使用している。

trev16.hatenablog.com

5.3. BT.709 cusp, BT.2020 cusp の算出

4.2.1. で説明した条件を満たす点を算出するだけであり特記事項はない。5.2. で作った LUT から簡単に求めることが出来る。

5.4. L_focal LUT, C_focal LUT の算出

基本的には 5.3. で求めた BT.709 cusp, BT.2020 cusp を使って、4.2.1. , 4.2.2. で述べたとおりに機械的に求めるだけで良い。

ただし今回の実装では 5.2. で作成した Gamut Boundary の LUT の量子化誤差の影響で Hue に対して高周波成分が発生してしまった。真の値はガタついてないと推測されるため、LPF を適用して高周波成分を除去した。

また、C_focal に関しては LPF に加えて以下の2点の追加処理を実行した。

無限大になる値(※6)は付近の値から適当に補間
最大値を5000以下に制限(※7)

※6 これもLUT値の量子化誤差の影響。図では Zero Division Error として値を0にしてある
※7 C_focal の変化が一定値を超えた場合に後の線形補間計算での致命的な誤差が生じたため

結果を以下に示す。


図13. L_focal LUT (オレンジの線)	図14. C_focal LUT (オレンジの線)

計算した L_focal, C_focal は LUT化した。Hue を入力すると focal 値が出力される LUT とした。

5.5. focal を基準とした Mapping 先の算出

5.5.1. 方針

L_focal, C_focal が決まれば、次は Mapping 先の算出となる。繰り返しになるが図12 で示した通り Mapping 先は focal を基準とした直線と BT.709 の Gamut Boundary の交点である。したがって Mapping 処理の際は全ての入力RGB値（を変換した LCH値）に対して直線の数式を求めて BT.709 の Gamut Boundary との交点を計算する必要がある。しかし、これはかなり面倒である。

そこで今回は事前に focal から 1024本の直線を引き、 BT.709 の Gamut Boundary との交点を計算して LUT化しておくことにした。こうすることで、本番の計算時は単純な三角関数の計算とLUTの参照だけで Mapping 先の座標計算が可能となった。

以下で、生成した LUT の詳細を述べる。

5.5.2. 2D-LUT の作成

生成した LUT が概要は以下の通り。

LUT の入力は入力RGB値から計算した Hue と、focal からの角度 D とする
LUT の出力は focal からの距離 R とする
LUT の入力の D は最大値と最小値が存在し Hue によって値が変わる

上記から分かるように 2入力1出力の 2D-LUT である。また focal は L_focal, C_focal と2種類存在するので LUT も2種類作成した。各種パラメータを図にしたものを以下に示す。添字の "l" と "c" はそれぞれ L_focal用、C_focal 用のパラメータであることを意味する。

説明	図
図15. L_focal 用 LUT の説明
図16. C_focal 用 LUT の説明

focal からの角度 D は図にあるとおり、最小値と最大値を設けてある。当初は以下の通り固定値とすることを検討していた。

L_focal の D の範囲: -pi/2 ～pi/2
C_focal の D の範囲: 0 ～ pi

しかし、この範囲だと全く参照されない LUTデータの割合が多く補間計算の精度が低下した。そこで最小値と最大値が Hue に応じて動的に変わる仕様とした。 focal からの角度 D の範囲の詳細は以下の通り。

D_l_min: L_focal と C_focal を結ぶ直線に対する角度
D_l_max: pi/2 固定
D_c_min: C_focal と BT.2020 cusp を結ぶ直線に対する角度(※8)
D_c_max: pi 固定

※8 C_focal と L_focal ではなく、C_focal と BT.2020 cusp を結ぶ直線にした理由は C_focal の変化量が大きい Hue での計算誤差を防ぐため。本記事では詳細は言及しない。あくまでも筆者の実装上の都合である。

5.5.3. 2D-LUT の使用

作成した 2D-LUT は次のようにして使用した。

入力RGB値を LCH値に変換
Chroma-Lightness 平面上で D_l, D_c を計算
L_focal 用の 2D-LUT と C_focal 用の 2D-LUT に Hue, D_l, D_c を入力して focal からの距離 R_l, R_c を求める
入力LCH値が L_focal と C_focal を結ぶ直線の上側か下側かを判別。適切な方の結果を最終結果として採用
簡単な三角関数で Mapping 先の LCH値を計算
元の入力 LCH値が BT.709 Gamut Boundary の内側だった場合は計算結果を捨てる。

手順で書いた通り、最初は L_focal を使うか C_focal を使うか判別しない。両方の LUTから距離 R を求めている。これは筆者の実装上の都合であり別に最初に判別しても構わない。同様に入力RGB値が BT.709 Gamut Boundary の内側だった場合でも処理は一通り行う。これも筆者の実装上の都合である。

手順 3.と 4. の様子を可視化した動画を以下に示す。上段の途中計算の段階では LUT の想定範囲外の角度のデータは異常値となっているが、最終的には左下のように想定範囲内のデータのみが採用されるため問題ない。

図17. Gamut Mapping の途中経過の可視化

5.6. ソースコード

参考までにソースコードを載せておく。以下のリンクの bt2407_gamut_mapping_for_rgb_linear が該当の処理である。

github.com

6. 検証

65x65x65 の RGBパッチに対して本処理を適用し、異常が無いことを確認した。確認用の動画を図18に示す。

図18. 65x65x65 の RGBパッチに対する変換結果

動画で矢印が書かれいている点は実際に Gamut Mapping が行われたサンプルである。矢印が書かれていない点は Gamut Mapping が行われなかったサンプルである。BT.709 の Gamut Boundary の外側のデータは BT.709 の Gamut Boundary に Mapping されていることが分かる。また Gamut Boundary の内側のデータは Mapping されていないことが分かる。この結果から本実装が正しく行われていると判断する。

7. 考察というか感想

半年以上もかかってしまったがようやく Gamut Mapping を一つ実装できた。何も分かっていない素人の状態から少しは知識が身に付いたと思う。まだまだやりたいことが沢山あるので1つずつ着実にこなして行きたい。

今後の展望としては以下の点がある。

BT2446 と組み合わせた HDR10 to BT.709 変換の3DLUT の作成
- これは絶対にやる。すぐやる。たぶん1ヶ月以内にできる。
既に世の中に存在する既存のツールとの比較
- YouTube や DaVinci Resolve の Gamut Mapping との差異を確認したい
- 実は DaVinci Resolve との比較は軽く行っている。かなり近い変換結果になった。詳しく調べて結果をまとめたい。
任意の色域への拡張(DCI-P3 to BT.709 も実現できるようにする、など)
- 個人的には L_focal の値をもう少し制限すれば汎用化が可能だと推測している
- アイデアはあるので色々と試したい
高速化の検討
- 処理の後半で使用した 2D-LUT まわりの計算は LUTの生成方法も含めて簡易化をしたい

8. 参考文献

Report ITU-R BT.2407, "Colour gamut conversion from Recommendation ITU-R BT.2020 to Recommendation ITU-R BT.709", https://www.itu.int/pub/R-REP-BT.2407

2020-04-26

HDRコンテンツの輝度マップ生成用の3DLUTを作る

背景

HDTVTest に Star Wars: The Rise of Skywalker の解析動画が上がっていた[1]。この解析で利用されていた輝度マップは 低輝度領域はモノクロ、高輝度領域はカラーと輝度レンジが明確に分かれるタイプで、今まで見たことが無かった。

この輝度マップは3DLUTを使えば簡単に作れると考え、実際に自分で作ることにした。

目的

HDRコンテンツの輝度マップ生成用の 3DLUTを作る
- HDRコンテンツの低輝度領域(0～100nits) はモノクロにする
- HDRコンテンツの指定した範囲の高輝度領域(100～1000nits)はカラーの輝度マップを適用する
対象とする HDRコンテンツは以下のいずれかとする
- Transfer characteristics: SMPTE ST2084, Gamut: ITU-R BT.2020, White point: D65
- Transfer characteristics: SMPTE ST2084, Gamut: DCI-P3, White point: D65

結論

3DLUT の作成に成功した。作成した3DLUTをHDRコンテンツおよび自作のテストパターンに適用した例を図1～図3に示す。

各図には4つの画像が貼り付けてある。内訳は以下の通りである。

左上：オリジナルのHDRコンテンツ
右上：以前にブログで作成した輝度マップ[2]
左下：【今回作成】Y成分に準じた輝度マップ
右下：【今回作成】RGBの各チャネルの Code Value 最大値に相当する輝度に準じた輝度マップ

従来(右上)と比較すると高輝度領域の細かな輝度変化が格段に認識しやすくなった。高輝度領域の解析には、こういった輝度マップが有用かもしれない。

名称	図
図1
図2
図3

作り方

概要

大したことはしてないので簡潔に説明する。以下の図4に示す通りである。

f:id:takuver4:20200426180832p:plain — 図4. 作成した輝度マップの処理内容

図4から分かるように輝度マップは3つの領域に分けて作成した。

①SDRの輝度領域(0～100nits)
②HDRの指定した輝度領域(100～1000nits)
③HDRの指定外の超高輝度領域(1000～10000nits)

まず、Linear に戻した後で Y成分を計算した。係数は RGB to XYZ 変換の Y の係数を利用した。

その後、①のSDRはグレースケールとして処理し、②のHDRは Turbo を使って色を塗り、③のHDRは Majentaでベタ塗りした。なお、図中の Turbo とは Google AI Blog にて紹介されていた Rainbow Colormap のことである[3]。

コードは make_luminance_map_3dlut.py の make_3dlut_for_luminance_map のところである。最初は30行くらいで書けると思っていたのだが、全然そんなことはなかった。色々と調整しているうちに難解なコードになってしまった…。

各チャネルの最大 Code Value 値に基づいたマップ

HDRコンテンツを解析する上では、Y成分だけでなく R, G, B の各チャネルの最大値について調べることも重要である（理由は…申し訳ありませんが省略させて下さい）。そこで R, G, B の各チャネルの最大値の Code Value から算出した輝度のマップも作成した。

図1～図3 の右下の結果がそれに該当する。作成の際は図4の「RGB to Y 変換」で Y を算出するのではなく、R, G, B チャネルのうちの最大値の Code Value に相当する ST2084 の輝度を算出するようにした。

3DLUTのダウンロード

作成した 3DLUT 一式は以下に置いてある。もしも興味のある方がいれば自由に使って頂いて構わない（トラブル発生しても責任は取れません）。

3DLUT一式のダウンロード

2020/04/29 追記 3DLUT一式のダウンロードその2※

※オリジナルの HDR動画と sRGB のカラーマップを Side By Side で比較しやすいように、sRGBのカラーマップを ST2084 の箱に入れる版の3DLUTを追加した（意味が解らない人は使わないで下さい）

考察というか感想

動画に対して複数の3DLUTを適用して同時再生すると楽しい！

参考資料

[1] HDTVTest, "[HDR] Star Wars: The Rise of Skywalker 4K Blu-ray HDR Analysis", https://www.youtube.com/watch?v=Hssiak8c4Js&feature=youtu.be

[2] toruのブログ, "Turbo を利用した HDR10 画像の輝度マップ作成", https://trev16.hatenablog.com/entry/2019/08/25/131001

[3] Google AI Blog, "Turbo, An Improved Rainbow Colormap for Visualization", https://ai.googleblog.com/2019/08/turbo-improved-rainbow-colormap-for.html

2020-03-22

HDR の映画に関する Technical Paper を読んだ

背景

最近、全然 Technical Paper を読んでなかったので久しぶりに読むことにした。今回読んだのは Predicting HDR Cinema Requirements from HDR Home Master Statistics である[1]。

隔月で発行される SMPTE の Motion Imaging Journal には幾つかの Technical Paper が寄稿？されるのだが、その中の1つである。なお、自分は SMPTE のメンバではないため IEEE Xplore でバラ買いした。$33であった。

以下、読んで気になった点のメモを残しておく。個人的に興味を惹かれた箇所のまとめであり、Technical Paper の翻訳では無い。注意して頂きたい。

Technical Paper の背景と目的

HDR が規格化され家庭用向けを中心に HDRコンテンツが増えてきた
Cinema に関しては Dolby Cinema があるものの、最大輝度が 108 cd/m2 と大幅に制限されている
今後、デバイスの進化により高輝度な HDR Cinema(Dolby Cinema とは異なる) の実現が予想される
その HDR Cinema に関して以下のスペックを見積もる
- Peak Luminance (このブログでは以後 ピーク輝度 と呼ぶ)
- Display Power Budget (このブログでは以後 平均輝度※ と呼ぶ)
そのために、Warner Bros. の 41タイトルの HDR作品を分析した

※フルスクリーンで最大の Video Signal を表示した場合にどれだけの輝度を出せるか、という指標のため平均輝度と呼ぶことにした（例えば Technical Paper では「SONY の BVM-X300 の Peak Luminance は 1000cd/m2、Display Power Budget は 170cd/m2 だ」といった使い方をしている）

用語整理

以後の説明で使用する特殊な用語を列挙する。なおこれらの用語は最後を除き「配信システム全体」を示す用語ではなく、「ピーク輝度」・「平均輝度」のスペックを示す用語として使用する。

用語	ピーク輝度	説明
SDR Cinema	48 cd/m2	DCI が規格化した現行の Digital Cinema[2]
EDR Cinema	108 cd/m2	Dolby が行っている Dolby Cinema。ここでは後述の HDR Cinema と区別するため、EDR(Enhanced Dynamic Range) という言葉を使う
SDR Home	100 cd/m2	BT.709 規格の SDR
HDR Home	4000 cd/m2	HDR10 などに代表される家庭向けの HDR。ピーク輝度はここでは 4000cd/m2 とする
FALL	-	Frame Average Light Level の略。フレームの平均輝度

Technical Paper で興味深かった点

以下の3点である。それぞれについて詳しく書いていく。

HDRコンテンツで高い輝度(500cd/m2以上)が使われる割合は少ない
HDRコンテンツを表示するデバイスはフルスクリーンでピーク輝度を出せなくて良い
(かなり個人的な話だが) ACES V1.1 の 108cd/m2 用の RRT+ODT は横軸を HDR Home の輝度値にしてプロットすると分かりやすい

1. HDRコンテンツで高い輝度が使われる割合は少ない

HDR作品と聞くと1000 cd/m2 オーバーの高輝度でビカビカと光る画をイメージする人もいるが、実際のところ高輝度が使われるシーンは限定的である。Technical Paper では、41タイトルの HDR Home 作品を分析してそれを示している。

Technical Paper の FIGURE2 を以下に示す。図の見方について説明する。

まず、あるフレーム(3840x1600px)に対して、各ピクセルの輝度値を算出する。次に、各ピクセルの輝度値の統計を取る。そして「99.9% のピクセルが X cd/m2 未満」という条件を満たす X の値を求める。

これを、41タイトルの 7,124,685 フレームについて行い、X を横軸としてヒストグラムを作った結果が FIGURE2 である。

f:id:takuver4:20200322150741p:plain:w640 — FIGURE2

FIGURE2 を見ると多くのフレームでは高輝度を必要としていないことが分かる。例えば、81.5% のフレームは 99.9% のピクセルが 500cd/m2 未満である。このことから、多くのフレームの大部分はピーク輝度が 500cd/m2 程度の表示デバイスでも十分に表示できることが分かる。

2. HDRコンテンツを表示するデバイスはフルスクリーンでピーク輝度を出せなくて良い

意外と知らない人も多いのだが、昨今のHDR対応表示デバイスは全画面でピーク輝度を維持することができない。例として RTINGS.com での評価結果[3] の一部を以下の図1に示す。

一番右側が全画面で最大の Video Signal を表示した場合の輝度である。2% Window を表示した場合と比較して大きく輝度が落ちることが分かる。

f:id:takuver4:20200322150814p:plain — 図1. OLED TV の表示面積と最大輝度の関係

この数字だけを見ると「欠陥品じゃないか！」と怒り出す人もいそうだが、実は輝度が下がってもそれほど問題ではない、という事実が Technical Paper で示されている。

それを示したのが FIGURE1 である。図の見方について説明する。

まず、あるフレーム(3840x1600px)に対して、各ピクセルの輝度値を算出する。それを全ピクセル数で割って平均値(FALL)を求める。これを、41タイトルの 7,124,685 フレームについて行い FALL を横軸としてヒストグラムを作った結果が FIGURE1である。

f:id:takuver4:20200322150901p:plain:w640 — FIGURE1

FIGURE1 を見ると多くのフレームでは平均輝度がさほど高くないことが分かる。170 cd/m2 あれば 98.6% のフレームは問題なく表示できることが分かる(極端に高いピーク輝度が要求されていなければ)。

こうした分析により、先ほどの図1のような特性をもつ表示デバイスでもHDRコンテンツの表示に大きな問題が生じないことが分かる。

3. ACES V1.1 の 108cd/m2 用の RRT+ODT は横軸を HDR Home の輝度値にしてプロットすると分かりやすい

ここは完全に自分用のメモなので少し雑に書く。

ACES の RRT+ODT については過去に記事で簡単な調査を行ったことがある。

trev16.hatenablog.com

当時は図2のようなグラフを書いた。で、ここの横軸は ACES空間の値となっており、0.18 が 18% Gray に相当するが実際の輝度値ではない。そのため、頭で色々と考えるのが少し難しい。

そこで視点を変えて図3のように横軸を HDR Home 4000nits 基準でプロットしてみると分かりやすくなる。これは横軸が PQ の EOTF で Luminance に変換された値なので、実際の輝度値である。なので「Dolby Cinema だと xxx nits が yyy nits にマッピングされる」といった分析がしやすくなる……気がした。

f:id:takuver4:20200322152802p:plain:w640 — 図2. ACES の RRT+ODT

f:id:takuver4:20200322151024p:plain:w640 — 図3. EDR Cinema 108 nits を横軸 HDR Home 4000 nits でプロットしたもの

感想

久しぶりに Technical Paper を読んだら面白かった。本当は FALL とピーク輝度の相関関係の話についても本ブログで言及したかったのだが、作業時間が無くなってしまったので断念した。興味のある方はオリジナルの Technical Paper を読んで欲しい。

次は BBC の WHP 369 「Display of High Dynamic Range Images Under Varying Viewing Conditions」を読みたいと思った。

参考資料

[1] Ronan Boitard, Michael Smith, Michael Zink, Gerwin Damberg, and Anders Ballestad, "Predicting HDR Cinema Requirements from HDR Home Master Statistics", SMPTE Motion Imaging Journal, vol. 128, pp. 1-12, 2019.

[2] SMPTE RP 431-2, "D-CINEMA QUALITY - REFERENCE PROJECTOR & ENVIRONMENT"

[3] RTINGS.com, "Peak Brightness of TVs", https://www.rtings.com/tv/tests/picture-quality/peak-brightness

2020-02-22

BRAVIA の「バックライト分割制御」の挙動を軽く調べた

1. 背景

諸事情によりTVを買い換えたため、色々とパラメータを変更して見た目がどう変わるかを確認している。その中で「バックライト分割制御」の設定はHDRコンテンツの表示品位に大きな影響を与えていたためメモを残すことにした。

2. 調査対象の TV

調査対象となるTVは SONY製 BRAVIA KJ-65X9500G である。購入理由は色が正確と評価されていたから（RTINGS.com にて Best TV For Color Accuracy として紹介されていた）。

3. 用語解説

このあと専門用語が出てくるので簡単にチョットだけ解説しておく。

3.1. Local Dimming

「黒の締まり」や「輝き」などを液晶パネルで表現する際に使われる技術。具体的には液晶のバックライトを複数のブロックに分割してブロック毎に制御する。以下の動画が分かりやすい(手前左側のTV)。

3.2. Blooming

Local Dimming の分割ブロック数の制約により、高輝度の表示対象の周りがボヤッと光ってしまう現象。以下の動画が分かりやすい。

3.3. コントラスト比

表現可能な明暗差の比率を意味する。

例えば表示デバイスAと表示デバイスBのスペックが以下だったとする。

A: 0.01 cd/m2～1000 cd/m2 まで表現可能
B: 0.5 cd/m2～500 cd/m2 まで表現可能

この場合、Aはコントラスト比 100,000:1、Bはコントラスト比 1,000:1 と表現できる。なお、近年の表示デバイスは設定するパラメータに依ってコントラスト比は変化する。

4. 結論

「バックライト分割制御」設定では Local Dimming の効き具合を制御可能
- 設定を「中」or「強」にするとコントラスト比が高くなるが Blooming が発生する
- 設定を「切」or「弱」にするとコントラスト比は低くなるが Blooming を抑制できる
- Blooming とコントラスト比はトレード・オフの関係にある
個人的にコンテンツに応じてパラメータ調整できるのは有り難いと思った。知識のある人にとっては扱いやすい製品だと考える。

5. 調査方法

まず、図1のカラーパッチを作成した(ST2084, BT.2020, D65 想定)。このパッチは低輝度かつBT.709の色域内に収まるように調整したパッチである。また、静止画のパッチに加えて高輝度の動く玉(※1)を合成した動画も用意した。

※1 こういうのって一般的には何て言うんですかね？ Reflective Moving Balls?

f:id:takuver4:20200222123534p:plain:w360 — 図1. 低輝度領域での彩度確認用パッチ(5x5) ※はてなブログだと見えないかも…

パッチに動く玉を合成した動画

次に、図2の環境を構築してTV にカラーパッチおよび動く玉の動画を表示した。この状態で「バックライト分割制御」の設定を変更し画面の変化を調べた。なお、画面の記録にはミラーレス一眼カメラの α6500 を使用した。

f:id:takuver4:20200222134604p:plain:w640 — 図2. 検証環境

6. 調査結果

静止画のカラーパッチを表示しつつ「バックライト分割制御」の設定を「切」→「弱」→「中」→「強」に変更した際の測定結果を図3～図6に示す。

概要	図
図3. 「切」
図4. 「弱」
図5. 「中」
図6. 「強」

また、動く玉の動画を表示しつつ「バックライト分割制御」の設定を「切」→「弱」→「中」→「強」に変更した際の測定結果を図7～図10に示す。

概要	図
図7. 「切」
図8. 「弱」
図9. 「中」
図10. 「強」

7. 考察

まず図3～図7 の右側の黒背景に注目する。「切」→「弱」→「中」の順に黒の輝度が下がっていくことが分かる。次に画面左側のパッチに注目すると、彩度が上がっていることが分かる。これはコントラスト比が上がり低輝度領域の表示性能が向上したからである。

このことから「バックライト分割制御」のパラメータを「切」→「中」に変えることで、HDRコンテンツの暗いシーンの表示性能が向上することが分かる。例えばドラマの暗いシーンでの役者さんの肌の見え方などが大きく変わる。

次に図7～図10 の高輝度の玉の周辺に注目する。「切」→「弱」→「中」の順に Blooming が視認しやすくなっていることが分かる。

このことから「バックライト分割制御」のパラメータを「中」→「切」に変えることで Blooming を抑制できることが分かる。例えばドラマの暗いシーンで字幕の周辺がボヤッと明るくなることが防げる。

以上よりコントラスト比と Blooming にはトレード・オフ関係があり、それを「バックライト分割制御」設定でコントロールできることが分かった。従ってコンテンツに合わせて最適なパラメータを設定すれば（ちょっと面倒だけど）良い視聴体験ができると考える。

なお余談だが「中」と「強」のパラメータの違いは今回の検証では分からなかった。

8. 感想

たった1機能を調べるのに随分と時間が掛かってしまった。もう少し効率よく作業ができるように努力したい。レビューサイトの中の人たちは本当に凄いな…。