背景
- かつて筆者は RGB to XYZ Matirx *1 を計算する際に White Point の XYZ値をどう設定するべきか悩んだことがあった *2
- 筆者は選択肢として以下の2つがあると考えていた
- 今はどちらが正解が分かっているのだが、別記事との関係により簡単に顛末を書いておくことにした
目的
- RGB to XYZ Matrix を算出する際の White Point の XYZ値の指定方法を示す
- なお、議論を簡潔にするため本記事で取り扱うカラースペースは White Point が D65 である前提とする *4
結論
- White Point の XYZ値の算出は手法①の「仕様書に記載の xy値 から算出」を採用すれば良い
理由は「カラースペースの仕様書に記載の RGB to XYZ Matrix がそのように算出されているから」である [2]
- 自分だけ異なる方法で算出するとカラーパイプライン上で意図しない誤差を生じる可能性がある
- と書いたが、実際のところは①と②の差はごくわずかなので、実運用上の問題が生じる可能性は少ないと考える
結論を補う情報として以下を本記事に添付する
- 付録1: RGB to XYZ Matrix の算出方法について
- 付録2: 冒頭で挙げた 2手法を使った White Point の XYZ値の計算例
- 付録3: 異なる White Point の XYZ値を設定した場合の RGB to XYZ Matrix の誤差について
付録1: RGB to XYZ Matrix の算出方法について
RGB to XYZ Matrix は以下の (1)式 と (2)式 から算出できる。
具体的な導出方法については 筆者の過去記事の 5.3 または Report ITU-R BT.2380-2 の Chapter 2 を参照して頂きたい [3][4]。
ここで 、、 はそれぞれ R、G、B 単色の色度を、 は White Point の XYZ値を意味する。
付録2: 冒頭で挙げた 2手法を使った White Point の XYZ値の計算例
筆者は記事の冒頭で White Point の XYZ値の計算方法として以下の 2つを挙げた。
- ① カラースペースの仕様書に記載の White Point の xy値から算出する
- ② Illuminant と Color Matching Function を使って算出する
Google Colab にて、それぞれの方法で計算を行った。
結果は以下となった。 の値がごくわずかに異なる結果となった。
- ①の方式:
- ②の方式:
付録3: 異なる White Point の XYZ値を設定した場合の RGB to XYZ Matrix の誤差について
付録2 で算出した 2種類の XYZ値を (1)式、(2)式に代入して実際に RGB to XYZ を求めて、その差異を確認した。 カラースペースは Rec.709 とし、手法① と手法② の XYZ値を指定して算出した Matrix をそれぞれ 、 とした。
計算は先ほどと同じく Google Colab にて行った。
結果は以下となった。誤差は小数点4桁以降にしか存在していないため、ごくごく僅かな差異しか生じないことが分かる。
M1 = [[ 0.41239578 0.35758296 0.18048126] [ 0.21264157 0.71516592 0.0721925 ] [ 0.01933105 0.11919432 0.95053463]] M2 = [[ 0.41245644 0.35757608 0.18043748] [ 0.21267285 0.71515216 0.07217499] [ 0.0193339 0.11919203 0.95030408]] M1 - M2 = [[ -6.06586345e-05 6.88353414e-06 4.37751004e-05] [ -3.12771084e-05 1.37670683e-05 1.75100402e-05] [ -2.84337349e-06 2.29451138e-06 2.30548862e-04]]
試しに以下のシミュレーションを 10-bit の ST2084 の Code Value に対して実行してみたが、誤差は 1-bit も発生しなかった。
- Rec.709 --> Rec.2020 の Color Gamut 変換を 手法①を使って作成した Matrix を使って実施
- Rec.2020 --> Rec.709 の Color Gamut 変換を 手法②を使って作成した Matrix を使って実施
- Rec.709 --> Rec.2020 --> Rec.709 と変換を行って誤差が生じたか確認
そのため実環境において手法①と手法②が混在しても大きな問題は起こらないと考える(混在しない方が好ましいのは当然だが)。
あとがき
筆者は現在「Windows OS に対して HDR コンテンツをオジリナルのまま加工せずに出力させる (2024年5月時点)」というタイトルの記事を書いている。 そこで遭遇した不可思議な現象の原因追及の一貫として本記事を書いた。色彩工学の勉強を始めた 2016~2017年は分からないことだらけだったが、 最近は色々と分かるようになったな、と振り返って少し思った。引き続き、色彩工学の勉強に励んでいきたい。
参考資料
[1] Recommendation ITU-R BT.709-6, "Parameter values for the HDTV standards for production and international programme exchange ", https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.709-6-201506-I!!PDF-E.pdf
[2] colour-science / colour, "About illuminant chromaticity coordinates calculation.", https://github.com/colour-science/colour/issues/220
[3] Report ITU-R BT.2380-2, "Television colorimetry elements", https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2380-2-2018-PDF-E.pdf
[4] toruのブログ, "表示デバイスの広色域化と観測者メタメリズムの組み合わせで生じる色ズレに関するシミュレーションの実施", https://trev16.hatenablog.com/entry/2022/09/25/135322