背景

前回に引き続き $\displaystyle J_z a_z b_z$ Color Space の勉強をしている
筆者は過去の記事で CIELAB Color Space を使い Hue-Chroma パターンを作成した。今回はこれを $\displaystyle J_z a_z b_z$ Color Space を使って作ろうと考えた

目的

過去の記事で作成した CIELAB Color Space の Hue-Chroma パターンを $\displaystyle J_z a_z b_z$ Color Space で作り直す。 $\displaystyle J_z a_z b_z$ は HDR に対応しているため、ピーク輝度を変化させて以下の 3パターンを作成する。

Luminance	Transfer Characteristics	Gamut	White Point
100 nits	2.4	BT.2020	D65
1000 nits	ST 2084	BT.2020	D65
10000 nits	ST 2084	BT.2020	D65

結論

$\displaystyle J_z a_z b_z$ Color Space を使用して以下の3種類のテストパターンを作成した。結果を以下に示す。

（誰も欲しがらないと思うが）生成した画像はこのリンクからダウンロードできる。再配布をしなければ自由に使ってもらって構わない。

Luminance	Transfer Characteristics	Image without metadata (PNG)	Image with metadata (AVIF)
100 nits	2.4
1000 nits	ST 2084
10000 nits	ST 2084

一番右側のメタデータ付きの画像は AVIF形式で CICP として 9-16-9 (※1) を埋め込んである。 Windows OS で HDRを有効にした後で HDR対応の Webブラウザで本ページを開くと HDRとして表示が行われる。

※1 Color primaries: BT.2020, Transfer characteristics: ST 2084, Matrix coefficients: BT.2020

CICP を埋め込んだ AVIF の作成については以下の記事を参照して頂きたい。

trev16.hatenablog.com

理論

$\displaystyle J_z a_z b_z$ Color Space は HDRに対応しており、0～10000 nits の範囲で任意のピーク輝度の Color Space を作成することが可能である。今回は 100nits, 1000nits, 10000nits のテストパターンを作成する。

任意のピーク輝度の Color Space の作成方法を説明する。まずは $\displaystyle X Y Z$ to $\displaystyle J_z a_z b_z$ 変換のおさらいおする。変換の数式は以下の通りである[1]。

f:id:takuver4:20210606115516p:plain:w640

ここで (8)式の X_D65, Y_D65, Z_D65 に注目する。SDR の D65 は 100 nits をピーク輝度とするため[2]、D65 の xy色度を (0.3127, 0.3290) とすると X_D65, Y_D65, Z_D65 は (95.046, 100.00, 108.91) となる。同様に HDR の 1000 nits, 10000 nits に対して X_D65, Y_D65, Z_D65 を計算すると以下となる。

Peak Luminance	X_D65	Y_D65	Z_D65
100 nits	95.046	100.00	108.91
1000 nits	950.46	1000.0	1089.1
10000 nits	9504.6	10000	10891

100 nits, 1000 nits, 10000 nits がピーク輝度の $\displaystyle J_z a_z b_z$ Color Space を作成には、上の表に示した X_D65, Y_D65, Z_D65 を最大値とする Color Space を考えれば良い。

それでは各ピーク輝度での Color Space の作成方法を説明する。今回の場合では Color Space を作成するには Gamut Boundary を計算する必要があるため、以後は各ピーク輝度での Gamut Boundary の計算方法について述べる。

今回も前回に引き続き以下の方針で計算をした。

$\displaystyle J_z C_z h_z$ 空間において Hue を 4096個に分割し、4096枚の $\displaystyle C_z J_z$ 平面を用意する
各 $\displaystyle C_z J_z$ 平面で $\displaystyle J_z$ を 1024個に分割する
各 $\displaystyle J_z$ ついて $\displaystyle C_z$ を変化させて $\displaystyle J_z C_z h_z$ to $\displaystyle R G B$ 変換した結果が 0.0～1.0 の範囲に収まる最大の $\displaystyle C_z$ 値を計算し、それを Gamut Boundary とする。

（CIELAB空間ではあるが）図で雰囲気を確認できるものが以下の記事の図5～図11 にある。必要に応じて参照して頂きたい。

BT.2020 色域確認用の Hue-Chroma テストパターンの改善 - toruのブログ

概要は上記の通りであるが、手順 3. の $\displaystyle J_z C_z h_z$ to $\displaystyle R G B$ 変換の際にピーク輝度を考慮する必要がある。続いてこの点について説明する。

$\displaystyle J_z C_z h_z$ to RGB 変換の具体例を下図の Chroma - Lightness 平面（Hue = 0°）で説明する。図には $\displaystyle P_0, P_1, P_2, P_3$ の 4点がプロットしてある。

f:id:takuver4:20210711125445p:plain:w600 — Gamut Boundary の判定の例

この 4点を 10000 nits, 1000 nits, 100 nits のピーク輝度で $\displaystyle J_z C_z h_z$ to $\displaystyle R G B$ 変換すると以下の表の通りになる。ここで1列目の $\displaystyle P_n, m$ の $\displaystyle n, m$ はそれぞれ点Pのインデックス、各チャネルのインデックスを意味している。例えば XYZ の列の $\displaystyle P_0, 2$ は、ポイント $\displaystyle P_0$ の $\displaystyle J_z C_z h_z$ を XYZ に変換した後の Z チャネルの値を意味している。

f:id:takuver4:20210711125011p:plain

さて、ここでのポイントは XYZ to RGB 変換後に RGB値を対象のピーク輝度で除算していることである。この処理により任意の輝度レンジで $\displaystyle J_z C_z h_z$ が Color Space の内側か外側かを判断することができる。

上の表で対象の RGB値が 0.0～1.0 をオーバーする箇所を赤色で塗りつぶした。1つでも赤色が含まれている点 $\displaystyle P_n$ は Color Space の外側の点と判断できる。この性質を使用して Gamut Boundary の計算を行った。

100 nits, 1000 nits, 10000 nits の Gamut Boundary を計算した後は、以前の記事と同様に Focal Point を求めた。その後に冒頭に示したテストパターンを作成した。

おまけ1

デバッグ用に Gamut Boundary および Focal Point をプロットした様子を以下の動画に示す。

おまけ2

自宅の BRAVIA で作成したテストパターンを確認していたのだが、TV の BT.2020色域カバー率が低く、BT.2020 Cups 付近では色はズレが発生しているように見えた。そこで、対象の色域を DCI-P3 としたバージョンのテストパターンを作成した。参考までに添付しておく。

Luminance	Transfer Characteristics	Image without metadata (PNG)	Image with metadata (AVIF)
100 nits	2.4
1000 nits	ST 2084
10000 nits	ST 2084

DCI-P3 の Gamut Boundary および Focal Point をプロットした様子も以下の動画に示す。

感想

記事を書くのに想定以上に時間がかかってしまった。記事では触れなかったが以下の3点で時間を消費した。

BT.2020 Cups 付近で急激に Code Value が変化する原因の調査（ST 2084 の特性であり、そもそも疑問視する必要性が無かった）
Hue が 252°～260° の範囲で BT.709 の Gamut Boundary の計算に失敗する問題の対応（暫定アルゴリズムを組んだが計算に17時間必要＆計算精度も低い。次の記事までに改善する予定）
Python の Multiprocessing で思うように性能が出ない（解決できず…）

この手の計算には慣れてきたつもりだったが、まだまだ勉強が足りていないと感じた1ヶ月であった。引き続き継続的に勉強を続けていきたい。

参考資料

[1] Muhammad Safdar, Guihua Cui, Youn Jin Kim, Ming Ronnier Luo, "Perceptually uniform color space for image signals including high dynamic range and wide gamut", Opt. Express, 25(13):15131, June 2017.

[2] Report ITU-R BT.2408-4, "Guidance for operational practices in HDR television production", https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2408-4-2021-PDF-E.pdf

[3] toruのブログ, "BT.2020 色域確認用の Hue-Chroma テストパターンの改善", https://trev16.hatenablog.com/entry/2021/05/29/095614