toruのブログ

月1くらいで記事書きたい。

RGB to XYZ Matrix 算出時の White Point の XYZ値の求め方

背景

  • かつて筆者は RGB to XYZ Matirx *1 を計算する際に White Point の XYZ値をどう設定するべきか悩んだことがあった *2
  • 筆者は選択肢として以下の2つがあると考えていた
    • ① カラースペースの仕様書に記載の White Point の xy値から算出する *3
    • ② Illuminant(測色用の光)と Color Matching Function(等色関数) を使って算出する
  • 今はどちらが正解が分かっているのだが、別記事との関係により簡単に顛末を書いておくことにした

目的

  • 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]。

 \displaystyle
\begin{aligned}
   \begin{bmatrix} X \\ Y \\ Z \end{bmatrix} =
   \begin{bmatrix}
     x_r & x_g & x_b \\
     y_r & y_g & y_b \\
     z_r & z_g & z_b
   \end{bmatrix}
   \begin{bmatrix}
     T_r & 0 & 0 \\
     0 & T_g & 0 \\
     0 & 0 & T_b
   \end{bmatrix}
    \begin{bmatrix} R \\ G \\ B \end{bmatrix}
\end{aligned}
\tag{1}


 \displaystyle
\begin{aligned}
   \begin{bmatrix} T_r \\ T_g \\ T_b \end{bmatrix} &=
   \begin{bmatrix}
     x_r & x_g & x_b \\
     y_r & y_g & y_b \\
     z_r & z_g & z_b
   \end{bmatrix}^{-1}
   \begin{bmatrix} X_n \\ Y_n \\ Z_n \end{bmatrix}\\
\end{aligned}
\tag{2}


ここで  x_r, y_r, z_r x_g, y_g, z_g x_b, y_b, z_b はそれぞれ R、G、B 単色の色度を、  X_n, Y_n, Z_n は White Point の XYZ値を意味する。

付録2: 冒頭で挙げた 2手法を使った White Point の XYZ値の計算例

筆者は記事の冒頭で White Point の XYZ値の計算方法として以下の 2つを挙げた。

  • ① カラースペースの仕様書に記載の White Point の xy値から算出する
  • ② Illuminant と Color Matching Function を使って算出する

Google Colab にて、それぞれの方法で計算を行った。

colab.research.google.com

結果は以下となった。 Z の値がごくわずかに異なる結果となった。

  • ①の方式:  (X, Y, Z) = (0.9505, 1.0000, 1.0891)
  • ②の方式:  (X, Y, Z) = (0.9505, 1.0000, 1.0888)

付録3: 異なる White Point の XYZ値を設定した場合の RGB to XYZ Matrix の誤差について

付録2 で算出した 2種類の XYZ値を (1)式、(2)式に代入して実際に RGB to XYZ を求めて、その差異を確認した。 カラースペースは Rec.709 とし、手法① と手法② の XYZ値を指定して算出した Matrix をそれぞれ  M_1 M_2 とした。

計算は先ほどと同じく Google Colab にて行った。

colab.research.google.com

結果は以下となった。誤差は小数点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

*1:任意のカラースペースの RGB 3刺激値を CIE1931 の XYZ 3刺激値に変換する Matrix

*2:2017年ごろの話である

*3:Rec.709 を例に上げると仕様書には (x, y) = (0.3127, 0.3290) と記載されている [1]

*4:例えば Rec.709 や S-Log3/S-Gamut3 は議論対象だが ACES などは対象外とする

現実逃避のため白川郷に行き、撮った写真を AVIF (Rec.2100-PQ) にした

Windows の scRGB の挙動を確認するために DirectX のサンプルコード を読んでいましたが、 難しすぎて発狂してしまい、現実逃避のために白川郷に行きました。

撮影した写真の HDR版 を AVIF として現像したので載せておきます。 OSの HDR機能を有効にして Google Chrome or Microsoft Edge で見れば HDRとして表示されるはずです(たぶん)。

番号 画像
1 https://toru-ver4.github.io/pages_test/AVIF_test/img/DSC01820.avif
2 https://toru-ver4.github.io/pages_test/AVIF_test/img/DSC01825.avif
3 https://toru-ver4.github.io/pages_test/AVIF_test/img/DSC01849.avif
4 https://toru-ver4.github.io/pages_test/AVIF_test/img/DSC01837.avif
5 https://toru-ver4.github.io/pages_test/AVIF_test/img/DSC01850.avif
6 https://toru-ver4.github.io/pages_test/AVIF_test/img/DSC01880.avif
7 https://toru-ver4.github.io/pages_test/AVIF_test/img/DSC01883.avif

写真を添付してから気づきましたが、MacBook Pro (macOS) の XDR ディスプレイで見た場合と Windows PC で AW3225QF を使って見た場合とで明るさが全然違いますね。 なんとなくですが、macOS (MacBook Pro) の方は SDR White が 203 nits で Windows の場合は 80 nits になってる気がします(この辺りに言及した記事を近いうちに書きたいところです)。 これは筆者の環境では Windows の "SDR content brightness" を最小値に設定していたのが原因でした。失礼しました。"SDR content brightness" を最大値にすることで macOS と見た目が合いました。

現像は MacBook ProLightroom を使って行いました。

以上。

Windows で HDRのスクリーンショットを撮影した際に生成される JPEG XR (.jxr) ファイルの RAW値を Python で読む

結論

imagecodecs というライブラリを使えばよい。

筆者が試した例の紹介

インストール

python -m pip install -U imagecodecs[all]

サンプルコードと実行結果

サンプルコードを以下に示す。

# -*- coding: utf-8 -*-
import sys
from imagecodecs import JPEGXR, imread

if not JPEGXR.available:
    print("JPEG XR is not supported.")
    sys.exit()

jpeg_xr_fname = "./Windows_HDR_Capture/600.jxr"
image = imread(jpeg_xr_fname)
print(f"image.shape = {image.shape}")
print(f"image.dtype = {image.dtype}")
print(f"image[1080, 1920] = {image[1080, 1920]}")

実行結果は以下の通り。RGBA の half float 形式であることがわかる。

image.shape = (2160, 3840, 4)
image.dtype = float16
image[1080, 1920] = [4.914 4.91  4.914 1.   ]

上記のサンプルコードで使用した画像データも参考までに添付しておく。

drive.google.com

その他の情報

JPEG XR ファイルを開けるビューアソフト

  • Windows 11 標準の Photos App
  • Affinity Photo 2
    • ただし以下の手順が必要
      • Windowメニューから "32-bit Preview" を選択してメニューを表示する
      • "32-bit Preview" メニューの "Enable HDR" にチェックを入れる

参考資料

[1] GitHub, "cgohlke/imagecodecs", https://github.com/cgohlke/imagecodecs

Windows 11 にて ICC Profile に MHC2 タグを埋め込んで HDR信号の出力を変化させてみた

背景

  • 筆者は自宅で使っている OLEDモニター (AW3225QF) の表示特性に不満を持っていた(前回の記事で触れた[1])
    • HDR Peak 1000 モードでは APL の増加に伴う輝度低下が非常に大きい
    • 一方で DisplayHDR True Black モードでは高輝度領域の白飛びが激しい
  • 調べ物をしていたところ、Windows ではモニター用の ICC Profile に MHC2タグを追加することで HDR信号の出力を制御できることが分かった
  • これにより筆者の不満点をある程度解消できる可能性が出てきた
  • ということで実際に試してみた

目的

  • モニター用の ICC Profile に MHC2タグを追加して HDR信号の出力を変化させ、筆者の不満点の解消を試みる

結論

  • MHC2 タグの仕様を理解した
    • OS の出力信号に対して任意の 3x3 Matrix と 1DLUT 適用することができる *1
    • SMPTE ST 2086 のメタデータを含めることができる(詳細は本記事では省略する*2
    • MHC2タグが含まれる ICC Profile は MHC ICC Profile または MHC Profile と呼ばれる
    • MHC は Microsoft Hardware Calibration の略称である
  • MHC2 タグを使い Windows が出力する HDR信号を任意の値に変換することに成功した
    • OLEDモニターの DisplayHDR True Black モードとの組み合わせにより「白飛びの軽減」と「 APL増加にともなう輝度低下の軽減」を実現した
  • 作成した MHC Profile を参考データとして以下に添付する *3

drive.google.com

  • ただし、現状では以下の問題があるため実運用には向いていない

    • Windows のログイン直後は MHC2 タグの内容が反映されない(ログイン後にプロファイルの再設定が必要)
    • Photoshop 2024 にて SDR 画像の色ズレが発生する *4
  • 確認に使用したソフトウェアのバージョンは以下の通り。

Software Version
Windows Windows 11 Pro 23H2 Build 22631.3374
Photoshop 25.6.0
Affinity Photo 2.4.1

詳細

筆者が所有している OLEDモニター(AW3225QF)の不満点

冒頭でも述べた通り、筆者は AW3225QF に対して以下の不満点を持っている。

  • HDR Peak 1000 モードでは APL*5 の増加に伴い急激な輝度低下が発生する(図1 参照)
  • DisplayHDR True Black モードでは高輝度領域の白飛びが激しくディテールが消えてしまう(図2 参照)
図1. 急激な輝度低下が発生している様子
XDR Display は比較用の表示。撮影は同一条件で実施
図2. 高輝度領域が白飛びする様子
XDR Display は比較用の表示。撮影は同一条件で実施

輝度低下および白飛びが発生するのは AW3225QF が特殊な表示特性を有しているからである。 以前に筆者が測定したデータを以下に再掲する[2]。

図3. HDR Peak 1000 の測定結果 図4. DisplayHDR True Black の測定結果

図3 と図4 から以下のことが分かる。

  • 図3: HDR Peak 1000 では APL の増加に伴い急激に輝度が低下する
  • 図4: DisplayHDR True Black では 300 nits 以降のデータに強めのトーンマッピングが適用され白飛びしやすい

筆者はこの問題への対処方法の 1つとして「DisplayHDR True Black で表示しつつ、入力信号の輝度を半分に低下させる」手法を試したいと考えていた。そうすることで以下の効果が得られると考えたからである。

  • 画面全体は暗くなるものの、600 nits 程度までのデータに対して強いトーンマッピングの適用を避けられる
  • HDR Peak 1000 で観測した「APL に応じた急激な輝度変化」を避けられる

ということで、後述の MHC2 タグを使って輝度を下げることを試した。

ICC Profile の MHC2 タグについて

Windows 10 (20H1) 以降、Windows にはモニターのキャリブレーションの仕組みが導入されている[3]。 図5 の 2b, 3b にある通り Windows の出力信号に対して 3x3 の Matrix と 1DLUT を適用することができる。

図5. Window に用意されているカラーパイプライン。緑色の部分がユーザー開放されている箇所。参考資料[3] より引用

3x3 の Matrix と 1DLUT はモニターの ICC Profile に MHC2 タグを埋め込むことで有効化できる。

MHC2 タグの詳細は以下の通り[3]。なお、MHC2 タグは Windows 独自のタグであり ICC の仕様書 には存在しないので注意して頂きたい。

"MHC2" private tag definition
Byte Position Field Length (bytes) Content Data type
0 to 3 4 'MHC2' (4D484332h) Type Signature MHC2Type
4 to 7 4 Offset to beginning of tag data element uint32Number
8 to 13 4 Size of tag data element uint32Number
MHC2Type structure definition
Byte Position Field Length (bytes) Content Data type
0 to 3 4 'MHC2' (4D484332h) Type Signature
4 to 7 4 Reserved, set to 0
8 to 11 4 Number of 1DLUT entries (4096 or less) ※a
OPTIONAL: 0 = Identity Transform
uint32Number
12 to 15 4 ST.2086 min luminance in nits S15Fixed16Number
16 to 19 4 ST.2086 peak luminance in nits S15Fixed16Number
20 to 23 4 Offset in bytes to matrix ※b
OPTIONAL: 0 = Identity Transform
uint32Number
24 to 27 4 Offset in bytes to red 1DLUT ※b uint32Number
28 to 31 4 Offset in bytes to green 1DLUT ※b uint32Number
32 to 35 4 Offset in bytes to blue 1DLUT ※b uint32Number

※a OS はハードウェアがサポートするエントリの数にデータを補間する
※b オフセットは、ファイルの始まりからではなく、MHC2 タグの開始位置からのオフセットである

Matrix definition
Byte Position Field Length (bytes) Content Data type
0 to 23 24 3x4 XYZ to XYZ adjustment matrix stored in row major order, column 4 is ignored ※c ※d s15Fixed16Number

※c Matrix は 3x3 なのだが MHC2 タグのデータ上は 3x4 として定義する必要がある(最後の1要素は 0 で良い)
※d 例えば何も変換を行わない単位行列を宣言する場合は [0x00010000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00010000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00010000, 0x00000000] となる(S15Fixed16Number にて記述)

1DLUT definition
Byte Position Field Length (bytes) Content Data type
0 to 3 4 'sf32' (73663332h) Type Signature
4 to 7 4 Reserved, set to 0
8 to end Variable (0 to 16384) Calibration LUT values normalized to [0.0, 1.0] ※e s15Fixed16Number

※e この 1DLUT は Non-Linear 空間に対して適用される。Linear 空間ではないので注意が必要である

MHC2タグ用のデータ作成 (1DLUT)

タグの仕様を理解したところで筆者は MHC2タグ用のデータ作成を行った。今回は輝度低下が目的であったため図5 (3b) の 1DLUT の値のみ変えることにして、図5 (2b) の Matrix にはデータ変換を行わない単位行列を設定することにした。

図5 (3a) を見ると分かる通り、1DLUT が適用される空間は Linear 空間ではなく Non-Linear 空間である。具体的には SMPTE ST 2084 の EOTF^-1 が適用された後の空間である。 そのため 1DLUT は以下の計算式で作成した。

  •  E'' = F^{-1}\left(F(E') \times g \right)
    •  E': 図5 (3a) の出力信号
    •  E'': 1DLUT 適用後の信号
    •  F: SMPTE ST 2084 EOTF
    •  g: 輝度の低下率。今回は 0.5 とする

少し分かりづらいかもしれないので、3ステップに分けて処理内容を書いておく。

  •  E' に対して SMPTE ST 2084 EOTF を適用して Linear化
  • ② Linear空間でゲイン  g を適用
  • ③ SMPTE ST 2084 EOTF^-1 を適用して Non-Linear化

実際に 1DLUT を計算した様子を以下に示す。

from colour.models import eotf_ST2084, eotf_inverse_ST2084
import numpy as np
import matplotlib.pylab as plt

num_of_sample = 256
gain = 0.5
step1 = np.linspace(0, 1, num_of_sample)
step2 = eotf_ST2084(step1) * gain
step3 = eotf_inverse_ST2084(step2)

plt.plot(step1, step3)
plt.grid(True)  # Enable grid
plt.xlim(0.0, 1.0)  # Set x-axis range
plt.ylim(0.0, 1.0)  # Set y-axis range
plt.show()

図6. 1DLUT をプロットした様子

MHC2タグを埋め込んだ ICC Profile の作成

データができたので、あとは仕様通りに ICC Profile にデータを埋め込めば良い。 筆者は過去に ICC Profile を作った経験があったので、今回もその環境を流用して MHC2タグの埋め込みを行った。

なお、SMPTE ST 2086 のメタデータは以下の値を設定した*6

Item Value
Peak luminance (nits) 10000
Max full frame luminance (nits) 10000
Min luminance (nits) 0.001
RGB color primaries (xy coordinates) BT.2020 の値
White point (xy coordinates) いつもの D50

trev16.hatenablog.com

MHC2タグを埋め込んだ ICC Profile の確認

作成した MHC2タグは Microsoft独自のタグであり、ICC が提供する公式のツールではデータの正当性を確認できない。 やむを得ず筆者はバイナリエディタを使って目視確認することにした。

1DLUT のエントリ数を 8、輝度低下のゲインを 0.5 とした際の ICC Profile についてバイナリエディタで確認を行った様子を以下に示す*7

図番号と詳細
図7
①MHC2のデータ開始アドレスは 0x0260
図8
②1DLUTのエントリ数は 8

③Matrix の開始位置は 0x0260+0x0024=0x0284

④1DLUT (R) の開始位置は 0x0260+0x0054=0x02B4

⑤1DLUT (G) の開始位置は 0x0260+0x007C=0x02DC

⑥1DLUT (B) の開始位置は 0x0260+0x00A4=0x0304
図9
⑦3x4 Matrix データ (色変換を行わないスルー設定)
図10
⑧1DLUTデータ。それっぽい単調増加データとなっている

図7~図10 の確認を経て、筆者は正しく ICC Profile が作成できたと判断した。

Windows 上で ICC Profile の適用

Color Management のダイアログボックスを表示後、「Add...」ボタンから作成したプロファイルを登録し、その後に「Set as Default Profile」で Default のプロファイルに設定すれば良い。gain=0.5 のプロファイルを設定している様子を図11 に示す。

図11. 作成した ICC Profile を Windows に適用している様子

実コンテンツを使った効果確認

Netflix が評価用に無償公開している Sol Levante を使って確認した。

opencontent.netflix.com

主観評価で大変申し訳ないのだが確認結果は以下の通りである。

  • 筆者は MHC2 タグで輝度を半分に落とすことで以下の問題を改善できたと知覚した
    • APL の増加に伴う急激な輝度低下
    • 高輝度領域の白飛び
  • よって目的を達成できたと判断した

なお、HDR動画の再生プレイヤーには MPC-BE を使用した。また MPC-BE の Video renderer には MPC Video Renderer を使用した。

現状の問題点

目的を達成できた一方で、冒頭でも述べた通り現状では少なくとも 2点の問題がある。

  • Windows のログイン直後は MHC2 タグの内容が反映されない
    • ログイン後に図11 のダイアログを表示してプロファイルの再設定が必要
  • Photoshop 2024 にて SDR 画像の色ズレが発生する
    • Photoshop と Affinity Photo 2 の比較を図12、図13 に示す
    • なぜこのような結果になるかは不明(筆者の作成したプロファイルに問題がある可能性もある)
図12. Photoshop で画像を開いた様子 図13. Affinity Photo 2 で画像を開いた様子

こういった状況のため、一般的なユーザーが使うのは少し難しいと考えている。 一方で自分のような人間が趣味で使う分には問題ないと考える。

感想

MHC2タグのデータを色々と変えて信号の変化を観察するのは面白かった。 しかし、一般的なユーザーが使いこなすのは相当に困難だと感じている。

今回の記事では述べなかったが Windows OS を経由した HDRの表示は「OS側の色変換」「アプリの色変換」「モニターの色変換」が複雑に絡み合うため挙動を理解するのが大変難しい。とても他の人にはオススメできない。

Windows がこんな状況なので、やはり現時点では iPhone, iPad, MacBook Pro が自分の中でのオススメ製品になってしまう。 うーん、何とかこの複雑な状況を整理してあらゆるユーザーが安心して HDR表示できる環境を整えたい…。

参考資料

[1] toruのブログ, "AW3225QF を使い FINAL FANTASY VII REBIRTH をプレイする際に生じる HDR表示のトレードオフについて", https://trev16.hatenablog.com/entry/2024/03/17/222252
[2] toruのブログ, "DaVinci Resolve と Argyll CMS を使ってゲーミングモニター (AW3225QF) の特性を測ってみた", https://trev16.hatenablog.com/entry/2024/02/28/215831
[3] Microsoft Learn, "Windows hardware display color calibration pipeline", https://learn.microsoft.com/en-us/windows/win32/wcs/display-calibration-mhc

*1:後ほど軽く述べるがモニターのキャリブレーションを行うための仕組みである

*2:次の記事でアプリケーションのトーンマッピングの話と絡めて詳しく解説するかも

*3:筆者は MHC2_10000-10000-nits_gain-0.50.icm を日常的に使っている

*4:ちなみに Affinity Photo 2 は問題なかった

*5:APL は Average Picture Level の略語

*6:ピーク輝度を 10000 nits としたのは意図しないトーンマッピングの適用を避けるためである。詳細は次の記事で述べる…かもしれない

*7:ICC Profile は Big Endian である。そのため普段は Little Endian で暮らしている人は注意が必要である

AW3225QF を使い FINAL FANTASY VII REBIRTH をプレイする際に生じる HDR表示のトレードオフについて

1. 背景

  • 筆者は FINAL FANTASY VII REBIRTH (以後 FF7RB と略す) をプレイするためにゲーミングモニター AW3225QF を購入した
    • FF7RB を遊ぶ前に AW3225QF の特性を確認した結果は前回の記事を参照
  • FF7RB を 18時間ほどプレイして、筆者は HDR表示にトレードオフがあることを理解した
  • 今後のことを考えて、現時点で理解したトレードオフの内容を簡単にまとめることにした

2. 目的

3. 結論

3.1. トレードオフについて

筆者が理解した内容を以下に示す。

Smart HDR設定 *1 欠点 利点
DisplayHDR True Black 高輝度部分が白飛びしてしまい本来の色が表示されない 空などの APL が高いシーンを見ても輝度変化を知覚しない
HDR Peak 1000 空などの APL が高いシーンを見ると強烈に輝度の低下を知覚する 高輝度部分が白飛びせずに本来の色で表示される

合わせてトレードオフを視覚的に確認できるようにした GIFアニメーションを図1、図2 に(GIFは画質が悪いので動画1 を推奨)、注目して欲しいポイントを図3、図4 に、高画質版を動画1 に示す *2 *3

図1. フィールドで海を見た様子。
DisplayHDR True Black では雲のディテールが白飛びで失われている。
HDR Peak 1000 では輝度が異様に低下してしまっている。
Reference として用意した MBP の XDR Display では破綻がない。
図2. 日差しの強い街の様子。
DisplayHDR True Black では衣服のディテールが白飛びで失われている。
HDR Peak 1000 では輝度が異様に低下してしまっている。
Reference として用意した MBP の XDR Display では破綻がない。


図3. 図1 で注目して欲しいポイントを赤枠で示したもの 図4. 図2 で注目して欲しいポイントを赤枠で示したもの



動画1. 図1、図2 の高画質版の動画

この結果を受けて、筆者は悩みに悩んだ末、今後は HDR Peak 1000 を選択して FF7RB をプレイすることに決めた。 筆者は輝度低下よりも色ズレを嫌う傾向にあるからである*4

3.2. トレードオフ解消のアイデア(本末転倒・他力本願・非現実的なものを含む)

殴り書きレベルだが筆者が考えたアイデアを以下に並べておく。

  • OLEDモニターを使うのを諦める
    • 1000 cd/m2 を安定して表示できる液晶モニター or TV を使って FF7RB をプレイする *5
  • FF7RB のアップデートでゲーム画面の露出調整が可能になることを期待する
    • 現状のゲーム内の「グラフィックス設定」では露出調整はできないため白飛び問題を解決することができない *6
    • 余談だが筆者が調べたところ FF7RB では PS5 で行った HDR調整の結果が反映されていなかった
      • こちらもアプデで対応されることを期待する *7
      • FF16 は PS5 の HDR調整の結果が反映されていたので当然 FF7RB も反映されるものだと思っていた( FF16 での調査結果は過去記事を参照)
  • PS5 の出力信号をいじって輝度を半分程度まで下げる
    • DisplayHDR True Black で白飛びが発生している原因の一つに、FF7RB はゲーム画面の平均輝度が高い、という点がある *8
    • そのため HDR Reference White に対する HDR表示領域のヘッドルーム *9 が不足してしまっている
    • これを改善するために輝度を 0.5倍する 1DLUT を PS5 の出力信号に適用する
      • 1DLUT の計算式は右の通り  E'' = F^{-1}\left(F(E') \times g \right)
        •  E'': 1DLUT 適用後の信号
        •  F: SMPTE ST 2084 EOTF
        •  E': PS5 の出力信号
        •  g: 輝度の低下率。今回は 0.5 とする
    • DaVinci Resolve 上で予備実験をしたところ、平均輝度は下がるものの白飛びが改善する結果を得られた(当然だが)
    • 現状では PS5 の出力信号に 1DLUT を適用する仕組みは存在しないため非現実的な提案ではあるが、参考までに筆者が作った 1DLUT をここに置いておく

4. ソフトウェアバージョン

この調査を行った際のソフトウェアバージョンは以下の通りである。

  • PS5本体: 24.02-09.00.00.45-00.00.00.0.1
  • FF7RB: 1.010.000

5. 感想

筆者は本記事を書きながら少し反省した。本来であればこのトレードオフは前回の記事を書いている時に気づいて言及するべきであった。

(みっともないとは思いつつも)言い訳をすると、筆者は 2020年に BRAVIA KJ-65X9500G (液晶TV) を、2021年に 第5世代の iPad Pro (液晶タブレット) を購入し、 比較的安定して高輝度を表示できる環境に浸っていたため、OLED で生じるこうしたトレードオフを甘く見てしまっていた。今後は注意したい。

その一方で、現時点では大枚をはたいて高価なモニターを買っても、満足の行く HDR表示結果を得られないというのは少し悲しいと思った。 この状態が早く改善されると良いのだが…。

*1:AW3225QF の HDR表示設定

*2:撮影条件は次の通り。Camera: ILCE-7M4, F-stop: f/10, Exposure time: 1/5 sec, ISO: 800, Picture Profile: No.9 の S-Gamut3/S-Log設定

*3:撮影は HDRレンジであったが画像処理で 輝度を 0.21倍にして SDRレンジに変換している。SDR変換時にトーンマッピングは適用していない

*4:なお、輝度低下の影響を最小化するため FF7RB のプレイ時は遮光カーテンを閉め、照明も消してプレイすることにした

*5:実際、筆者の所有する BRAVIA でゲームをプレイした場合はこの問題は解決した。が、今度は液晶特有の視野角が狭い問題や、直下型バックライトの制御に起因する Blooming の発生などが起こるため片手落ちの対策にしかならない

*6:「画面輝度:まぶしさ」という設定項目があるが、これは FF7RB 側で高輝度領域にトーンマッピングを適用する処理のようで、パラメータを変更しても白飛びは改善されなかった

*7:というかゲームソフトが PS5 の HDR調整結果を無視することって可能だったんですね…

*8:主観評価ではあるが、少なくとも FF16 と比較すると明らかに明るい

*9:筆者の過去記事で紹介した HDR Capacity のこと

DaVinci Resolve と Argyll CMS を使ってゲーミングモニター (AW3225QF) の特性を測ってみた

0. 更新履歴

日付(YYYY-MM-DD) 内容
2024-02-28 新規作成
2024-03-09 図4 のラベルの誤記を修正
2024-03-17 4.1. に DisplayHDR True Black の利用に関数
5.2.2 の 図12 に対する見解を修正

1. 背景

  • 2024年2月29日に Final Fantasy VII Rebirth(以後 FF7RB と略す)が発売する
  • 良い環境でゲームをプレイするため筆者は OLED のゲーミングモニター(AW3225QF) を購入した
  • OLED は優れた表示性能を有しているが、同時にいくつかの欠点も有しているデバイスである
  • そのため FF7RB をプレイする前に表示性能を確認しておく必要があると考えた
  • そこで DaVinci Resolve と Argyll CMS を組み合わせた測定環境を構築し、表示特性を軽く確認することにした

2. 目的

  • 第3世代の QD-OLED を搭載した AW3225QF の表示特性を確認し、以下の疑問を解決する
    • AW3225QF は高輝度の表示を一定期間(例えば 60秒程度)維持できるのか
    • AW3225QF には様々な HDR表示の設定が存在するが、筆者が選択すべき設定はどれか
    • AW3225QF は入力信号の APL*1 の増加に伴い輝度が低下するが*2 その際に xy色度のズレは生じるのか
  • 上記の調査のための測定システムを DaVinci Resolve と Argyll CMS を組み合わせて作成する

3. 機材について

本記事では以下のハードウェア、ソフトウェアを使用した。

3.1. ハードウェア
項目 型番 FW or Driver バージョン
ゲーミングモニター AW3225QF M2B102 *3
テスト信号の出力デバイス DeckLink Mini Monitor 4K 12.8
色彩計 (Colorimeter) Display Pro HL *4 -
3.2. ソフトウェア
項目 型番 バージョン
テスト信号の出力ソフト DaVinci Resolve Studio 18.6.5 BUILD 7
測色用ソフト Argyll CMS の spotread 3.1.0

4. 結論

4.1. AW3225QF について

  • AW3225QF は高輝度の表示を少なくとも 70秒は維持できる
    • 高輝度の白色パッチを画面に表示して 70秒ほど輝度を測定した結果を図1 に示す
  • 筆者は FF7RB をプレイするにあたり DisplayHDR True Black という設定を選択すべきだと判断した
    • 各種設定の表示特性を図2 に示す。DisplayHDR True Black はピーク輝度が 500 nits 弱だが歪が少ない特性となっている
    • 当初は HDR Peak 1000 の使用を考えていたが Windowサイズによって大きな歪が生じるため一旦除外した *5 *6
    • 2024年3月17日追記: FF7RB を18時間 ほどプレイして、筆者は DisplayHDR True Black の使用をやめて HDR Peak 1000 を使うことに方針を変えた。詳細はリンク先の記事を参照
  • AW3225QF は入力信号の APL の増加に伴う輝度低下発生時に色ズレを起こさない
    • 18種類のカラーパッチを使い APL(と比例関係のある Windowサイズ) を変化させた際の xy色度の変化を図3 に示す
    • xy色度の誤差は概ね 0.001未満、大きくても 0.002未満に収まっているため色度のズレは起きていないと判断する *7
      • 図3 は APL変化時の相対的な色ズレについて調査した結果であり、絶対的な色精度の調査結果ではないので、その点は注意して頂きたい
    • 加えて、参考データとして APL を変化させた場合の輝度を図4 に示す*8

図1. 高輝度の白色パッチを 70秒間表示した際の輝度の変化

図2. 各種HDRプリセットでの輝度の表示特性

図3. Windowサイズを変化させた際の xy色度の変化の様子 図4. Windowサイズを変化させた際のパッチの輝度の変化の様子

4.2. 測定環境について

今回の調査では、予備実験を含めると約3000回もカラーパッチをモニターに表示して測定を行う必要があった。 効率化および人為的なミスの混入防止のため、以下の仕様を満たす自動測定環境を DaVinci Resolve と Argyll CMS を使って構築した。

  • 任意のタイミングでカラーパッチをモニターに表示可能
    • カラーパッチには HDR10形式で任意の RGB値*9を指定可能
    • カラーパッチの Windowサイズは任意の値を指定可能
  • 任意のタイミングでモニターが表示しているカラーパッチの XYZ値を測定可能

システムの接続図を図5 に、システムのアーキテクチャ図(のようなもの)を図6に、実際に測定している様子を 動画1 に示す。

図5. 接続図 図6. アーキテクチャ図(のようなもの)


動画1. 測定している様子

5. 結論に至るまでの経緯

5.1. なぜ自分で測定を行おうとしたのか

AW3225QF は DisplayHDR 400 True Black という Tier を取得した製品である。そのためリンク先に記載のスペックはメーカー側で保証されている[1]。

加えて RTINGS.comTFT Central などのレビューサイトには、多種多様な光学測定の結果が掲載されている[2][3]。そのためゲームを行うプレイヤーはモニターの購入時に自ら光学測定を行う必要はない。

しかし、筆者は中途半端に色彩光学に関する知識を有しており、上記のレビューサイトの結果だけでは満足できなかったため追加調査を行うことにした。

以下で詳細について述べていく。

5.2. 各測定を行うに至った背景と詳細

5.2.1. 高輝度の表示の維持の測定

筆者は DisplayHDR 400 True Black が保証する内容が気になり、VESA が公開している DisplayHDR CTS のドキュメントを読んでいた[4]。 上から順に評価項目を読んでいたところ Minimum-white Luminance – 10% Center Patch TestMinimum-white Luminance – Full-screen Flash Test の試験内容が非常に気になった。

これらは簡単にまとめると以下の内容を評価するための試験である(合わせて試験の概要を図7~図10 に示す)。

  • ピーク輝度で表示した 10 % Window を 30分間維持できるか (10% Center Patch Test)
  • ピーク輝度で表示した 100 % Window を 2秒間維持できるか (Full-screen Flash Test)
図7. 10% Center Patch Test の試験方法。資料[4]より引用 図8. 10% Center Patch Test に合格するための条件。資料[4]より引用
図9. Full-screen Flash Test の試験方法。資料[4]より引用 図10. Full-screen Flash Test に合格するための条件。資料[4]より引用

筆者は性格が非常に悪いので、試験内容を見て以下のことを考えてしまった。

  • ピーク輝度で表示した 3% Window や 20 % Window は輝度を維持できるのか?
  • ピーク輝度で表示した 100 % Window は 60秒程度は輝度を維持できるのか?

ということで筆者は測定を行った。結果は冒頭に掲載した図1 の通りであり、70秒程度であれば途中で急に輝度が変わることはなかった。

参考までに、測定に使用した DaVinci Resolve のアーカイブデータ (.dra) を以下に添付しておく。 もしも再現実験をしたいと思う人がいれば参考にして頂きたい。

drive.google.com

5.2.2. 各種プリセットの表示特性の測定

筆者が購入した AW3225QF には Smart HDR という名称で以下に示す6種類の HDR設定が存在している。 *10

  • Desktop
  • Movie HDR
  • Game HDR
  • Custom Color HDR
  • DisplayHDR True Black
  • HDR Peak 1000

HDR設定の数の多さにやや圧倒されるが、多くの設定項目があるのは良いことだと考えている。 なぜならばゲームをプレイするユーザーは、各々が色に対する様々な好みを有しており、かつ様々な環境光の中でゲームをプレイするからである。 ただ残念なことに各設定の表示特性の詳細が取扱説明書には掲載されていなかった。

筆者は表示特性が分からないと安心してゲームをプレイできない性格のため、各設定に対する表示特性を調べた。その結果が冒頭に掲載した図2 である。

なかなか興味深い結果だったため DisplayHDR True Black と HDR Peak 1000 の 2項目について図11、図12 として再掲する。

図11. DisplayHDR True Black の測定結果 図12. HDR Peak 1000 の測定結果

個人的には HDR Peak 1000 での 20% ~ 100% Window の表示において、AW3225QF の表示特性に不自然な歪が生じているのが大変残念だった。 この結果を見ると筆者は、モニターを開発したメーカーが

  • 3% Window は最高輝度が出る Window サイズであるため真面目に調整した
  • 10% Window はモニターの測定でよく使われる Window サイズであるため真面目に調整した
  • それ以外は測定されないだろうと高をくくってテキトーに調整した

のように邪推してしまう…。

2024年3月17日追記: 実際に FF7RB のゲーム画面を見ていると話はそうも単純ではなく、図12 で観測された歪は実際のゲーム画面では感じられなかった。 テストパターンを使い追加実験を行っているのだが、なぜ 図12 の特性と実際のゲーム画面の表示に差異が生じているかは分かっていない…。

さて、性格の悪い筆者の感想はさておき、結論として筆者はゲームのプレイ時に DisplayHDR True Black を選択する方針とした。 理由は不自然な輝度の歪みがあるとゲームのプレイ中に気が散る可能性があるからである。

参考までに、測定に使用した DaVinci Resolve のアーカイブデータ (.dra) を以下に添付しておく。 もしも再現実験をしたいと思う人がいれば参考にして頂きたい。

drive.google.com

5.2.3. APL が変化した際の色ズレ

冒頭でも軽く述べたが OLEDモニターには入力信号の APL が増えると表示される輝度が下がってしまう欠点がある。 この欠点は以前から様々な場所で述べられており、最近だと TFT Central の記事 に詳しい説明がある[5]。

筆者はこの欠点を以前から知っていたため*11、購入した AW3225QF が API増加に伴う輝度低下時に xy色度(色味)を維持できるのか非常に気になった。 なぜならばゲームプレイ中にゲーム内の演出によって APL が増加した際、輝度だけならともかく xy色度まで変わってしまったら非常に悲しいからである。

そのため xy色度がズレるか確認を行うことにした。

筆者はこの検証を行うにあたり以下の方針を立てた。

  • 彩度の高い RGBの原色ではなく ColorChecker のような実用的な色について確認を行う
  • ColorChecker に含まれる 18種類の有彩色のカラーパッチを用意する
  • APL の増加を表現するため、18種類のカラーパッチは 5種類の Windowサイズを持つことにする
    • Windowサイズはそれぞれ 3%, 10%, 20%, 50%, 100% とする
  • APL の増加に伴い確実に輝度低下を起こすため 1000 nits 基準でカラーパッチを作成する

ということで測定用のパッチとして、SDR基準で作られている ColorChecker の xyY値に対して Y値だけ高輝度に置換したものを準備した。 具体的には以下の表に示す xyY値を持つ HDRカラーパッチを用意した(参考情報として SDRの値も併記した)*12 *13

Index x (SDR) y (SDR) Y (SDR) x (HDR) y (HDR) Y (HDR)
1 0.3992 0.3582 9.957 0.3992 0.3582 99.57
2 0.3867 0.3533 34.582 0.3867 0.3533 345.82
3 0.2475 0.2672 18.656 0.2475 0.2672 186.56
4 0.3408 0.4295 13.142 0.3408 0.4295 131.42
5 0.2685 0.2536 23.376 0.2685 0.2536 233.76
6 0.2565 0.3560 41.993 0.2565 0.3560 419.93
7 0.5088 0.4019 30.412 0.5088 0.4019 304.12
8 0.2086 0.1823 11.768 0.2086 0.1823 117.68
9 0.4683 0.3112 18.994 0.4683 0.3112 189.94
10 0.2963 0.2202 6.464 0.2963 0.2202 64.64
11 0.3729 0.4925 43.893 0.3729 0.4925 438.93
12 0.4746 0.4405 42.644 0.4746 0.4405 426.44
13 0.1858 0.1463 6.158 0.1858 0.1463 61.58
14 0.2978 0.4824 23.042 0.2978 0.4824 230.42
15 0.5437 0.3211 12.197 0.5437 0.3211 121.97
16 0.4485 0.4726 58.671 0.4485 0.4726 586.71
17 0.3760 0.2445 20.025 0.3760 0.2445 200.25
18 0.1936 0.2638 19.799 0.1936 0.2638 197.99

xyY 値は RGB値に変換する際、Transfer Characteristics が SMPTE ST 2084 (PQカーブ)、Color Primaries が BT.2020 となるように変換した。 これを測定した結果が冒頭で表示した図3、図 4 である。

なお、輝度を見てわかるように AW3225QF の HDR設定は HDR Peak 1000 とした。 理由は APL増加時に大きな輝度低下が起こる環境で評価をしたかったからである。

図3 を見ると分かるように色ズレは発生しておらず(もしくは無視できる程度に十分小さいため)非常に安心できる結果となった。 なお、図3 の結果は 3% Window の xy色度を基準としたズレ量を評価した結果であり、 AW3225QF の絶対的な色精度について述べた結果ではないことに注意して頂きたい。

参考までに、測定に使用した DaVinci Resolve のアーカイブデータ (.dra) を以下に添付しておく。 もしも再現実験をしたいと思う人がいれば参考にして頂きたい。

drive.google.com

6. 付録

6.1. DaVinci Resolve と Argyll CMS を組み合わせた測定環境の補足

ここでは今回の検証に使用した測定環境について補足する。

6.1.1. DaVinci Resolve と Argyll CMS の役割について

まず、それぞれのツールの役割について説明する。

DaVinci Resolve の役割は以下である。

  • カラーパッチを任意のタイミングで画面に表示する
  • AW3225QF が HDR信号だと認識できるように HDMI出力に HDR10 のメタデータを付与する

Argyll CMS の役割は以下である。

  • 任意のタイミングで Argyll CMSspotread を利用して AW3225QF に表示されたカラーパッチの XYZ値を測定する
6.1.2. 測定の具体的な手順について

細かな制御は Python スクリプトを使って行った。具体的な手順は以下の通り。

  • ① 事前に測定用のテストパッチを全て作成しておく (図13)
  • ② DaVinci Resolve に HDR10 出力を行うプロジェクトを作成する (図14)
  • ③ 手順① で作成したパターンの中からを表示したいものを選択して AW3225QF に表示する (図14)
  • ④ Argyll CMSspotread を使って AW3225QF を測定する (図15)
  • ⑤ 手順③~④ を必要な測定するパッチの数だけ繰り返す
図13 手順① 図14 手順②~③ 図15 手順④

手順②~③ について補足する。DaVinci Resolve には Python を使って制御するための Scripting と呼ばれる機能がある。 今回はこの機能を使って DaVinci Resolve に対して以下の命令を行った。

  • プロジェクトを新規作成する (HDR10信号を出力するよう設定を実施)
  • 表示するカラーパッチをメディアプールへ登録する
  • 表示するカラーパッチをタイムラインに配置する
  • タイムライン上の再生位置を変更して表示するカラーパッチを切り替える

DaVinci Resolve の Scripting 機能の詳細については以下の README.txt を参照すること。

Windows: C:\ProgramData\Blackmagic Design\DaVinci Resolve\Support\Developer\Scripting\README.txt
macOS: /Library/Application Support/Blackmagic Design/DaVinci Resolve/Developer/Scripting/README.txt

ネット上で「DaVinci Resolve Python」などで検索すると、上記の README.txt を転記したサイトが引っかかることもあるが、 Scripting機能は定期的にアップデートされており、ネット上の情報は古くなっていることが多い。 そのため、もし Scripting機能を試したい方がいるのであれば、上記の README.txt を直接読むことを強く推奨する。

なお測定に際して、筆者は1点だけ DaVinci Resolve に追加の設定を行った。以下の図16 に示す通り Preferences において静止画をタイムラインに配置した際の長さを 5秒 -> 1フレームに変更した。 理由はカラーパッチ切り替えの制御を Python から行いやすくするためである。カラーパッチの切り替えはタイムラインの「再生位置のタイムコードを指定」して行うため、 上記の設定を適用するとタイムコードの計算が行いやすかった。

図16. Preferences 設定で静止画の長さを 1フレームに設定した様子

6.1.3. 測定に使用した Python スクリプト

参考データとして、今回の測定に使用したサンプルスクリプトへのリンクを添付しておく。 例によって筆者のローカル環境でしか動作しないと思うが、何かの役に立つかもしれないので載せておく。

カラーパッチ生成スクリプト github.com

DaVinci Resolve & spotread 制御スクリプト github.com

6.1.4. Resolve でテストパッチを表示する際のプロジェクト設定

今回は以下のプロジェクト設定で測定を行った。

図17 Timeline Format の設定 図18 Color Space & Transforms の設定

注意点としては赤枠で囲った箇所の設定を忘れないことである。 筆者は最初のうち「HDR mastering if for 1000 nits」の設定を忘れており、AW3225QF が 1000 nits の輝度を出してくれず焦る経験をした。 もしも同様の検証をする方がいる場合は注意して頂きたい。

6.1.5. DaVinci Resolve の Scripting のサンプルコード

少し前に某所で「DaVinci Resolve の Scripting のサンプルコードが欲しい」と要望があったのでサンプルコードを作成した。 参考資料として本記事に添付しておく(筆者のメインPC (Windows) でしか動作確認していないので、他の環境で動かなかったらゴメンナサイ)。

drive.google.com

6.2. Display Pro HL の補正に使用した CCSS ファイルについて

前回の記事で詳しく解説したが、Argyll CMSspotread で Display Pro HL を使用する場合は 測定値の補正用に CCSS ファイルを指定することができる。

trev16.hatenablog.com

今回筆者は AW3225QF の測定でRGBLEDFamily_07Feb11.ccssを使用した。 理由は AW3225QF の分光特性が近かったからである。

CCSSファイルの分光分布と AW3225QF の分光特性の比較を下図に示す。なお、データとしてOLEDFamily_20Jul12.ccssとの比較結果も掲載しておく。

図19. RGBLEDFamily_07Feb11.edr との比較 図20. OLEDFamily_20Jul12.ccssとの比較

見て分かる通りスペクトルは完全には一致していない。あまり良くない選び方だとは分かっていたが、他に近いスペクトルがなく消去法でRGBLEDFamily_07Feb11.ccssを選択した。

理想を言うと Spectroradiometer を準備し、どの CCSSファイルを使えば誤差を最小化できるか調査した上で、使用する CCSSファイルを決めるのが良いと考える。

6.3. AW3225QF の色の絶対精度について

冒頭の図3 が示すデータは 3% Window を基準とした相対精度の情報であり、絶対精度についてはこれまで述べてこなかった。 理由は筆者が Display Pro HL の測定データを 100% 信用できなかったからである*14

先ほど述べた通り、今回筆者は消去法でRGBLEDFamily_07Feb11.ccssを選択した。 そのため、Display Pro HL の吐き出した測定値が真の値から大きくズレている可能性を捨てきれない。

例えば、筆者が本記事で Display Pro HL を使い「AW3225QF は平均で⊿xy として±0.015 の誤差がありました」と結論付けたとしても、 数百万円する別の機材を使って再測定した場合に「AW3225QF は平均で⊿xy として±0.001 の誤差しかありませんでした」となる可能性がある *15

そのため冒頭の結論には絶対精度の結果は添付しなかった。しかし、せっかく測定したので(かつ、こんな記事の末尾は誰も読んでいないと思うので)参考データとして 絶対精度の測定結果のデータを載せておく。

ColorChecker のカラーパッチを 100 nits 表示想定、200 nits 表示想定として作成し、それを HDR Peak 1000 設定で表示しているモニター上に表示して測定した。 別の言い方をすると、ピーク輝度 1000 nits で表示するモニター上にあえて SDRレンジの 100 nits, 200 nits のパッチを表示して測定をした。

HDRモードで表示している時に人の肌などが正しく表示できるか確認するため、このカラーパッチを使って測定をした。結果を図21 に示す。

図21 【参考】ColorChecker のパッチを使用した絶対精度の確認結果

まあまあズレている。良し悪しは自分には判断がつかない(用途に依ると考える)。

7. 感想

まさか Final Fantasy 7 Rebirth をプレイするための事前準備にここまで時間がかかるとは思わなかった。 が、そのおかげでもあり AW3225QF がどのような挙動をするかは概ね理解することができた。

これでゲーム中に急激な輝度の変化が生じた場合でも、それが「ゲーム側の演出」なのか「モニターの表示特性」なのか簡単に切り分けできるため、ストレスなくゲームをプレイできそうである。

参考資料

[1] DisplayHDR, "Summary of DisplayHDR Specs under CTS 1.1", https://displayhdr.org/performance-criteria-cts1-1
[2] RTINGS.com, "Dell Alienware AW3225QF Monitor Review", https://www.rtings.com/monitor/reviews/dell/alienware-aw3225qf
[3] TFTCentral, "Dell Alienware AW3225QF Review", https://tftcentral.co.uk/reviews/dell-alienware-aw3225qf
[4] VESA, "VESA High-performance Monitor and Display Compliance Test Specification (DisplayHDR CTS), Rev. 1.1" https://fs16.formsite.com/VESA/form714826558/secure_index.html *16
[5] TFTCentral, "Exploring OLED Brightness – Improvements, WOLED vs QD-OLED and the Need for New Metrics and Specs", https://tftcentral.co.uk/articles/exploring-oled-brightness-improvements-woled-vs-qd-oled-and-the-need-for-new-metrics-and-specs

*1:Average Picture Level のこと

*2:この現象の詳細は後述する

*3:記事を書いているうちに新ファームウェアの M2B103 がリリースされたが、モニターの表示特性は変わっていないようであった

*4:CCSSファイルには RGBLEDFamily_07Feb11.edr を変換したものを使用した

*5:筆者の測定ミスかと思って別日に改めて設定を確認した上で再測定したが同じ結果だった

*6:ファームウェアアップデートで歪が消えたりしませんかね?

*7:なお当たり前だが輝度(Y) はズレるので ⊿E としては大きな値が生じている

*8:輝度が下がり始める Windowサイズがパッチ毎に異なるため参考データとして掲載することにした

*9:信号帯域によっては YCbCr に変換されても良いとする

*10:厳密にいうと Dolby Vision なるモードも存在しているので合計7種類?

*11:この手の知識は TVやゲーミングモニターのレビュー記事を見続けていると自然に身につくと考えている

*12:なお、筆者は有彩色のズレに興味があったため、今回は無彩色のパッチは除外した (Index 19 ~ 24)

*13:なお、上記の xyY値のオリジナルは D50光源下のデータだったが、D65 のモニターで表示することを考えて Chromatic Adaptation の Matrix を適用して D50 to D65 を実施済みである

*14:95% は信用している

*15:これは万が一、億が一の話であり、実際はそんなに測定結果に差異は生じないと思うが…

*16:ダウンロードには登録が必要です

Display Pro HL を購入してゲーミングモニターのキャリブレーションを行い、その後に ArgyllCMS を使った効果確認を行った

1. 背景

2. 目的

  • Calibrite製の Display Pro HL を使いゲーミングモニターのキャリブーレションを行う
  • ArgyllCMS という別ソフトを使いキャリブレーション後の効果確認を行う
    • Photoshop にカラーパッチを表示し Display Pro HL で測定して理論値との誤差を確認する

3. 結論

  • モニターのキャリブレーションは Calibrite PROFILER を使うことで簡単に実施できた
    • 注意点として最初にモニターの Technology Type の指定が必要であった (図1)
    • 調査したところ Technology Type を指定することで EDRファイルを読み込んでいるようであった
    • 更に調べたところ EDRファイルには 図2 に示すスペクトルデータ*3が含まれることが分かった
    • EDRファイルは Display Pro HL の測定値を補正するために使用しているようである*4
  • ArgyllCMS に含まれるspotreadというツールを活用することで人力で効果確認を行えることが分かった
    • Photoshopspotreadを使い画面にカラーパッチを表示して人力で効果確認を行った結果を図3 に示す
    • spotreadの実行時は Display Pro HL の測定値を補正するための CCSSファイルの指定が必要である
    • CCSSファイルは ArgyllCMS に含まれるoeminstというツールを使うことで EDR ファイルから変換できる
      • CCSS ファイルを使わない場合、図4に示すように誤差が大きく出るので注意が必要である
図1. Calibrite PROFILER で Technology Type を指定する様子 図2. EDR ファイルに含まれるスペクトルデータの例
(左から順に RGBLEDFamily, WGCCFLFamily, CCFLFamily, WLEDFamily)
図3. Photoshop 上で ColorChecker のパッチを表示しつつ
Display Pro HL でパッチを測定して理論値との誤差を確認した様子
図4. CCSS ファイルを使わない場合の理論値との誤差。
測定値に補正が適用されないため誤差が大きくなる


  • 参考: spotread で白色パッチを測定する例
> spotread.exe -x -X ./ccss/WLEDFamily_07Feb11.ccss -O
Result is XYZ: 57.840705 60.831540 66.190299, Yxy: 60.831540 0.312885 0.329064

4. 詳細

4.1. Calibrite PROFILER を使ったゲーミングモニターのキャリブレーションについて

4.1.1. キャリブレーション手順の概要

初めにゲーミングモニターのキャリブレーション手順について述べる*5キャリブレーションを行うソフトウェアには DisplayCALColourSpaceCalman など様々なものが存在するが、今回は購入した Display Pro HL の付属ソフトウェア*6である Calibrite PROFILER を使った (Calibrite PROFILER の使い方については公式の YouTube動画が参考となった[1][2])。

Calibrite PROFILER の UI は全体的に分かりやすかった一方で、唯一 Technology Type の選択だけ分かりづらかったので、ここだけ少し詳しく述べようと思う。

Technology Type は図5 の画面で選択する。左側のリストから適切な項目を選択する必要があるのだが、筆者は最初どの項目を選べば良いか分からなかった。

図5. Technology Type を選択する様子

画面右側の説明を読むと「製造元のウェブサイトを見るか calibrite.com/display-typeを見て下さい」との記述があった。 製造元のウェブサイトを見ても特に記述がなかったため、筆者は calibrite.com/display-type にて確認を行った。 すると図6 に示すデータが出てきたため、今回は Technology Type に White LED を使って Calibration を行った。

図6. 筆者所有のゲーミングモニターの Technology Type を調べた様子

参考までに筆者が設定したパラメータの一覧を以下の表に示す。

項目 設定値
Technology Type White LED
White Point CIE D65
Luminance 61 cd/m2
Contrast Ratio Native
Gamma 2.2
Ambient Light Auto Adjust Off
Flare Correct Off
Chromatic Adaptation Bradford
ICC Profile Version Version 4
Profile Type Matrix Based
Color Patches Standard 118 Patches

以上が筆者が行ったキャリブレーション手順の概要である。以後は筆者が疑問に感じた点について調べた結果を述べていく。

4.1.2. Technology Type の追加調査

キャリブレーションの工程で筆者は前述の Technology Type の指定が気になった。そのため追加調査を行った。結果として以下の2点が分かった。

  • Calibrite の公式ドキュメントには Technology Type がキャリブレーション結果に与える影響 について言及しているものがない*7
  • 図1、図5 に出てくる Technology Type は Calibrite PROFILER のインストールフォルダに存在する EDRファイルを参照している可能性が高い*8 *9
    • EDR ファイルが存在するフォルダについては以下のlsコマンド実行結果を参照*10
> ls *.edr

    Directory: C:\Program Files\calibrite PROFILER\resources\app.asar.unpacked\node_modules\@calibrite-org\i1displayjs\
    build.win\calibrations

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----        2023/12/15     18:24          43868 CCFLFamily_07Feb11.edr
-a----        2023/12/15     18:24          12456 OLEDFamily_20Jul12.edr
-a----        2023/12/15     18:24          12456 PlasmaFamily_20Jul12.edr
-a----        2023/12/15     18:24          39068 ProjectorFamily_07Feb11.edr
-a----        2023/12/15     18:24          30412 RGBLEDFamily_07Feb11.edr
-a----        2023/12/15     18:24          59880 RG_Phosphor_Family_25Jul12.edr
-a----        2023/12/15     18:24          30412 WGCCFLFamily_07Feb11.edr
-a----        2023/12/15     18:24          43868 WLEDFamily_07Feb11.edr

ということで、存在する手がかりは EDRファイルしかなかったので、EDRファイルについて調べることにした。EDR ファイルについての公式ドキュメントは見つからなかったが X-Rite のサイトを参照するとスペクトルデータが入っているようであった[3]。

試しにファイルを開いたところ以下のようなバイナリデータであった。データ形式が分からないため、このままでは内容を読むことができなかった。

$ hexdump -C WLEDFamily_07Feb11.edr | head -n 36
00000000  45 44 52 20 44 41 54 41  31 00 00 00 00 00 00 00  |EDR DATA1.......|
00000010  01 00 00 00 01 00 00 00  b3 7a 2b 4d 00 00 00 00  |.........z+M....|
00000020  45 44 52 45 64 69 74 6f  72 20 56 31 2e 30 20 28  |EDREditor V1.0 (|
00000030  6d 7a 20 30 31 2d 31 30  2d 32 30 31 30 29 00 30  |mz 01-10-2010).0|
00000040  30 30 29 00 00 00 00 00  00 00 00 00 00 00 00 00  |00).............|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000060  57 4c 45 44 20 41 43 20  4c 47 20 53 61 6d 73 75  |WLED AC LG Samsu|
00000070  6e 67 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |ng..............|
00000080  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000160  09 00 00 00 0c 00 00 00  53 79 6e 63 4d 61 73 74  |........SyncMast|
00000170  65 72 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |er..............|
00000180  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001a0  00 00 00 00 00 00 00 00  53 41 4d 00 00 00 00 00  |........SAM.....|
000001b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001e0  00 00 00 00 00 00 00 00  30 35 43 34 00 00 00 00  |........05C4....|
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000220  00 00 00 00 00 00 00 00  4c 2d c4 05 01 00 01 00  |........L-......|
00000230  00 00 00 00 00 c0 77 40  00 00 00 00 00 60 88 40  |......w@.....`.@|
00000240  00 00 00 00 00 00 f0 3f  00 00 00 00 00 00 00 00  |.......?........|
00000250  00 00 00 00 00 00 00 00  44 49 53 50 4c 41 59 20  |........DISPLAY |
00000260  44 41 54 41 00 00 00 00  00 00 00 00 00 00 00 00  |DATA............|
00000270  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000002a0  00 00 00 00 00 00 00 00  ff 00 ff 00 ff 00 63 00  |..............c.|
000002b0  9a 99 99 99 99 69 71 40  ac 1c 5a 64 3b df d3 3f  |.....iq@..Zd;..?|
000002c0  77 be 9f 1a 2f dd d4 3f  00 00 00 00 00 00 00 00  |w.../..?........|
000002d0  a0 73 76 00 00 00 00 00  53 50 45 43 54 52 41 4c  |.sv.....SPECTRAL|
000002e0  20 44 41 54 41 00 00 00  91 01 00 00 c8 53 78 00  | DATA........Sx.|
000002f0  00 00 00 00 00 00 00 00  00 c4 b2 3e 00 00 00 00  |...........>....|
00000300  00 00 00 00 00 00 00 00  20 76 aa 3e 00 00 00 00  |........ v.>....|
00000310  c0 1b d1 3e 00 00 00 00  60 55 91 3e 00 00 00 00  |...>....`U.>....|
00000320  c0 af e3 3e 00 00 00 00  00 00 00 00 00 00 00 00  |...>............|
4.1.3. EDRファイルを CCSSファイルに変換して解析

EDRファイルについて調査を続けていたところ ArgyllCMS のoeminstというツールを使うことで EDRファイルを CCSSファイル(テキストファイル) に変換できることが分かった。

変換するためのコマンドの例を以下に示す。

oeminst.exe -c WLEDFamily_07Feb11.edr

早速oeminstを使って変換をしたところ、EDRファイルから変換して生成した CCSSファイルは以下のようなテキストデータであることが分かった*11

CCSS   

ORIGINATOR "X-Rite"
CREATED "Tue Jan 11 06:31:31 2011"
DISPLAY "WLED AC LG Samsung"
TECHNOLOGY "LCD White LED IPS"
DISPLAY_TYPE_REFRESH "NO"
UI_SELECTORS "e"
REFERENCE "CS1000"
OEM "YES"
SPECTRAL_BANDS "401"
SPECTRAL_START_NM "380.000000"
SPECTRAL_END_NM "780.000000"
SPECTRAL_NORM "1.000000"
DESCRIPTOR "Not specified"

NUMBER_OF_FIELDS 402
BEGIN_DATA_FORMAT
SAMPLE_ID SPEC_380 SPEC_381 SPEC_382(中略)SPEC_779 SPEC_780 
END_DATA_FORMAT

NUMBER_OF_SETS 12
BEGIN_DATA
1 0.00131034 0.00000 0.000920547(中略)0.238889 0.240713
2 0.000832910 0.000406201 0.00000(中略)0.171608 0.164913
3 0.0131662 0.0139073 0.00000(中略)0.0973706 0.0973323 
4 0.00000 0.00000 0.00316831 (中略) 0.0327373 0.0312437
5 0.0138432 0.0163205 0.00000(中略)0.0677657 0.0623742
6 0.00000 0.00000 0.00887114(中略)0.0462179 0.0370600
7 0.00474713 0.00000 0.0116117(中略)0.0510705 0.0412320 
8 0.00493657 0.0100973 0.00565295(中略)0.0130143 0.0105508
9 0.00000 0.00000 0.00000(中略)0.181141 0.191957
10 0.00000 0.00000 0.00000(中略)0.128260 0.128074
11 0.00000 0.00000 0.00000(中略)0.0779678 0.0894414
12 0.000549494 0.00701861 0.000938994(中略)0.0550132 0.0408447
END_DATA

CCSSファイルには 380~780 nm まで 1nm ステップのスペクトルデータが 12個存在することが分かる。プロットすると図7のようになった。

図7. WLEDFamily_07Feb11.ccss をプロットした様子

各データを観察すると、White、Red、Green、Blueの4色を1組としたものが合計3組あることが分かる。 ただし、これは WLEDFamily_07Feb11.ccss の場合であり、ファイルによっては 1組だったり5組だったりとバラツキがあることが分かった。

参考までに8種類の CCSSファイル*12に含まれる全てのスペクトルデータをプロットした結果を図8に示す。

図8. 8種類の CCSSファイルをプロットした様子。縦の1列が1つの CCSSファイルに該当する

以上が EDRファイルを解析した結果である。

4.1.4. Calibrite PROFILER が EDRファイルを何に使っているのか

これまでの調査で以下のことが分かった。

  • Calibrite PROFILER での Technology Type の選択は EDRファイルを選択するために行っている可能性が高い
  • EDRファイルにはスペクトルデータが含まれる

さて、ここで気になるのは Calibrite PROFILER が EDRファイルを使って何をしているかである。

だが、残念なことに Calibrite の各種ドキュメントを参照しても EDRファイルの取り扱いに関して言及している説明文は見つからなかった。 唯一見つけたのは X-Rite i1Profiler に関する以下の文言である[5]。

When calibrating an LCD display, i1Profiler provides the option to optimize your measurement for different types of backlit technologies. (中略) In this case you will need to consult your display’s documentation for more information about your technology type.


LCDディスプレイを調整する際、i1Profilerは異なるタイプのバックライト技術に対する計測を最適化するオプションを提供します。(中略)この場合、technology type についての詳細情報を得るために、ディスプレイのドキュメントを参照する必要があります。(ChatGPT による日本語訳)

根拠としてはやや弱いが、EDRファイルは Display Pro HL の測定値を補正するために使用していると思われる。 なぜ補正が必要となるのかについては、本記事の後半で ArgyllCMS のドキュメントを引用して説明する。

4.2. ArgyllCMS を使った効果確認について

4.2.1. ArgyllCMS を使うに至った経緯

Calibrite PROFILER にはキャリブレーション後の効果確認のための Validation 機能がある。Validation 機能を実行するとリンク先のようなレポートが発行され、キャリブレーション後の画面品位を確認できる。

しかし、筆者は Calibrite PROFILER のレポートを 100% 信用することができなかった。なぜならば、このレポートは Calibrite PROFILER というアプリケーション内での測定結果であり、Photoshop などの別のアプリケーションが介在しないからである*13。そのため筆者は Photoshop などの別アプリ上で同等の性能が出るか確認する必要があると考えていた。

ということで筆者は Photoshop を使って効果確認を行うことにしたのだが、ここで1つ問題が発生した。それは製造元である Calibrite から Display Pro HL を計測器として扱うためのツールが提供されていない、という点である。 筆者は Display Pro HL を使い Calibrite PROFILER 上で測定を行うことはできるが、任意のアプリで任意のカラーパッチを測定することができない状態であった。

しかし、世の中には偉大な先人がいるもので調査の結果 ArgyllCMS を使うことで Display Pro HL を計測器として使えることが分かった。

4.2.2. ArgyllCMS とは

最初に ArgyllCMS がどういったツールなのか簡単に説明する。説明の上手い ChatGPT先生による紹介を以下に示す。

ArgyllCMSは、精密な色管理を可能にするオープンソースカラーマネジメントシステムです。このソフトウェアは、モニター、スキャナー、プリンターの色校正を行うために広範囲にわたるツールを提供し、ICCプロファイルの作成や編集を行うことができます。プロフェッショナルな写真家やデザイナーから、色精度を重視するユーザーまで、幅広い分野で利用されています。

ArgyllCMS はオープンソースであるが、開発をサポートするための寄付をすることができる。 もしも ArgyllCMS を頻繁に使うのであればぜひ寄付を検討して頂きたい*14

4.2.3. ArgyllCMS の spotread について

ArgyllCMS には様々なツールが内包されているのだが、その中の spotread を使うことで Display Pro HL を XYZ値を測定する計測器として使うことができる。

やり方は簡単で、Display Pro HL を USB接続した状態で以下のコマンドを実行すれば良い。すると測定結果が標準出力として表示される。

> spotread.exe -x -O
Result is XYZ: 57.372348 60.843378 65.880597, Yxy: 60.843378 0.311643 0.330498

さて、確かに測定はできたのだが、上記の結果は筆者が想定した値からはずいぶんと誤差が大きかった。 上記の (Y, x, y) = (60.843378, 0.311643, 0.330498) は白色パッチを測定したものだが、理論値の (Y, x, y) = (61.000, 0.3127, 0.3290) と比較すると誤差が異様に大きいことが分かる*15

思い当たる点として、Calibrite PROFILER では Technology Type として WLED を指定し WLEDFamily_07Feb11.edr を読み込ませたが、 spotreadには WLEDFamily_07Feb11.edr を読み込ませていない、というのがあった。

そこで spotreadEDRファイルを読み込ませる方法を調べることにした。

4.2.4. spotreadEDRファイルを読み込ませる方法

調べた結果、以下のことが分かった。

  • spotread には EDRファイルを読み込む機能はない
  • ただしoeminstを使って EDRファイルを CCSSファイルに変換すれば -X オプションで CCSSファイルを読み込み可能

ということで oeminst を使い WLEDFamily_07Feb11.edr を WLEDFamily_07Feb11.ccss に変換し、-X オプションをつけて測定をやり直すと以下となった。

> spotread.exe -x -X ./ccss/WLEDFamily_07Feb11.ccss -O
Result is XYZ: 57.840705 60.831540 66.190299, Yxy: 60.831540 0.312885 0.329064

理論値の (Y, x, y) = (61, 0.3127, 0.3290) に近くなったことが分かる(xy色度の誤差が±0.001 未満となった!)。

4.2.5. 効果確認の実施

ということで Photoshop に 24色のカラーパッチを表示してspotreadを使い XYZ値の測定を行った。測定結果と理論値との誤差を比較したものが冒頭の図3である(以下に再掲)。

図3(再掲). Photoshop 上で ColorChecker のパッチを表示しつつ Display Pro HL でパッチを測定して理論値との誤差を確認した様子

併せて測定の様子を図9 に示す。今回は初めての試みであっため、筆者がマウスでパッチを選択し、その後にコンソールで毎回spotreadコマンドを叩くという人力測定となったが、今後は自動で測定できるように環境を整えていくつもりである。

図9. 人力で効果測定を行っている様子

参考までに Photoshop での表示に使ったパッチや、測定用の Pythonコード一式が入った zipファイルを本記事に添付しておく。

drive.google.com

4.3. CCSSファイルを使った測定値の補正について

さて、駆け足で ArgyllCMS のspotreadコマンドについて述べてきたが、ここまで幾つかの技術的な説明を省略してきた。 最後に、筆者が ArgyllCMS のドキュメントを読むことで理解した Display Pro HL の測定値補正について述べていこうと思う。

具体的には以下の内容を述べていく。

  • なぜ Display Pro HL は測定値を補正する必要があるのか
  • spotreadは内部で CCSSファイルを使いどのような補正を行っているのか
4.3.1. なぜ Display Pro HL は測定値を補正する必要があるのか

測定値に補正が必要な理由は ArgyllCMS の Wide Gamut Displays & Colorimeters に詳しく書かれていた[7]。

簡単にまとめると以下となる。

  • 筆者が購入した Display Pro HL は colorimeter である
  • colorimeter はCIE1931の等色関数を模倣した物理フィルタを使って3刺激値を測定値して XYZ値を得る
  • colorimeter は安価だが測定の精度は低い
  • 精度が低い理由は物理フィルタの特性が CIE1931 の等色関数と完全に一致しないからである

なお(疑って申し訳ないが)ArgyllCMS が誤った情報を書いている可能性もゼロではないので、念のため Google Scholar で関連論文の確認も行った。 引用件数の多い Four-Color Matrix Method for Correction of Tristimulus Colorimeters を読むと、確かに Colorimeter では補正が必要であることが述べられていた[8]。そのため ArgyllCMS の主張は正しいと筆者は判断した。

4.3.2. spotreadは内部で CCSSファイルを使いどのような補正を行っているのか

続いてspotreadが行っている測定値補正の内容について調べた結果を述べる。

本件については残念ながらドキュメントを読んでも詳細が書かれていなかった。そのため ArgyllCMS のソースコードを読んで確認した*16

ArgyllCMS のソースコードをダウンロードし内容を確認したところ spectro/i1d3.c のi1d3_comp_calmatで測定値の補正を行う 3x3 の Matrix を計算していた。 i1d3_comp_calmat では以下の手順で 3x3 の Maxtirx を算出していた。

  • 事前に Display Pro HL の EEP から Display Pro HL の分光感度特性を取得しておく*17
  • 事前に CIE1931 の等色関数を準備しておく
  • CCSS ファイルから表示デバイスの分光特性を取得する
  • 以下の2つの計算を行う
    • ① CIE1931の等色関数と表示デバイスの分光特性を使い、CCSSファイルの表示デバイスを測定した場合の理論値を算出する
    • ② Display Pro HL の分光感度特性と表示デバイスの分光特性を使い、DIsplay Pro HL が CCSSファイルの表示デバイスを測定した場合の仮想的な測定値を算出する
  • ①と②の誤差が最小となる 3x3 の Matrix を求める *18

この 3x3 の Matrix を測定値に適用しているようであった。

4.3.3. CCSS ファイルを誤選択した場合の色ズレの例

最後に参考データとして、誤った CCSSファイルを指定した場合に測定結果にどの程度のズレが生じるのかをお見せしようと思う。

Calibrite PROFILER のインストールにより手に入った 8種類の EDRファイルを CCSSファイルに変換し、 それぞれの CCSSファイルを補正に使用した場合の結果を図10に示す。図10 は白色のパッチを測定し xy色度図上に色度をプロットしたものである。

図10. 8種類の CCSSファイルを使って測定値を補正した場合の結果

誤った CCSSファイルを使うと予期せぬ誤差が生じることが分かる。 なお、図を見れば分かるように Calibrite PROFILER の Display Tehcnology には WLEDFamily を指定した。

5. 感想

Display Pro HL はサイズがコンパクトなだけでなく測定時間も短いため手頃に扱える良いデバイスである。 一方で、高額な Spectroradiometer と比較すると測定精度は劣るところがあり、測定値の補正は必須であることも分かった。 (ただ、筆者が使っているようなゲーミングモニターでそこまでの補正をする意味があるかは疑問であるが…)

今回の調査で、ひとまずの動作原理は理解することができた。今後は Display Pro HL を活用して色々な測定をして遊んでいきたい。

6. 参考資料

[1] Calibrite, "Calibrite PROFILER Monitor Module Advanced", https://youtu.be/oYf2i2NJo1A?si=90pOcPTXxmDCkxjt
[2] Calibrite, "Calibrite PROFILER User Guide Basic Mode", https://youtu.be/U-gVvBmh9jk?si=DhpKVAtPwm0oTcdM
[3] X-Rite, "Display Color Services", https://www.xrite.com/industry-solutions/display-and-printer-manufacturers/display-manufacturers/display-color-services
[4] ArgyllCMS, "spectro/ccxxmake", https://www.argyllcms.com/doc/ccxxmake.html
[5] X-Rite, "Monitor profiling with i1Profiler", https://xritephoto.com/documents/literature/en/DisplayProfilingi1ProfilerNTK_EN.pdf
[6] ArgyllCMS, "spectro/oeminst", https://www.argyllcms.com/doc/oeminst.html
[7] ArgyllCMS, "Wide Gamut Displays & Colorimeters", https://www.argyllcms.com/doc/WideGamutColmters.html
[8] Yoshihiro Ohno and Jonathan E. Hardis, " Four-Color Matrix Method for Correction of Tristimulus Colorimeters", https://chromapure.com/fourcolorcorrection.pdf [?] Calibrite, "Selecting the Correct Backlight Technology", https://calibrite.com/us/learning-centre/selecting-the-correct-backlight-technology

*1:Windows 11 が Auto Color Management 機能を搭載したのが主な要因

*2:筆者は Validation はキャリブレーションを行ったツールとは別ツールで行うべきだと考えているため

*3:表現として「スペクトルパワー分布」「分光分布」などがあると思うが、本記事では「スペクトルデータ」と呼ぶことにした

*4:測定値の補正を示唆する情報は複数のサイトで見つけることができたのだが、残念ながら Calibrite社の公式ドキュメントでは見つけられなかったため「~ようである」という表現にした

*5:ゲーミングモニターはソフトウェアキャリブレーションとなるため成果物はモニターの ICC Profile となる

*6:厳密には付属ではないが、同じメーカーの推奨ソフトウェアであるため「付属ソフトウェア」と表現した

*7:筆者が調べた限りでは。もしかしたら見落としている可能性もある

*8:ここに至るまで経緯を簡単に記載しておく。本記事の記載とは順番が前後してしまうのだが、筆者は調査の初期段階から ArgyllCMS のドキュメント[6]を読んでいた。そしてその中で ①Display Pro HL の測定値を補正する仕組みがあること、②EDRファイルやCCSSファイルが補正に使われること、を知った。加えて "*.edr" でCドライブを全検索したところ Calibrite PROFILER のインストールフォルダに EDRファイルが存在するのを見つけた。更にそのファイル名称が Technology Type の文字列と類似していることを掴んだ。…というのが経緯である。長くてゴメンナサイ

*9:Calibrite Profiler に表示される文言と EDRのファイル名称は微妙に異なるのだが、EDRファイルが置いてあるフォルダに存在する「I1D3Mapping.txt」と「TechnologyStrings.txt」を参照すると文言とファイル名称の対応関係が分かる

*10:macOSの場合は /Applications/calibrite PROFILER.app/Contents/Resources/app.asar.unpacked/node_modules/@calibrite-org/i1displayjs/build.darwin/calibrations にある

*11:量が多いので一部の中間データは(中略)と書いて省略している

*12:細かく書くと「Calibrite PROFILER と一緒にインストールされた 8種類の EDRファイルを oeminst を使って変換した 8種類の CCSSファイル」である

*13:これは筆者が病的にあらゆることを疑っているからであり、一般的には Calibrite PROFILER の結果を信じて全く問題ないと考える

*14:ということで筆者も寄付をしようとしたのだが「この国ではサポートされていません」というエラーが出てしまって寄付ができずにいる😢

*15:補足すると"キャリブレーション直後に測定したにも関わらず"誤差が大きい、という意味である

*16:あくまでもコードを読んだだけである。デバッグビルドした上での動作確認はしていない。もしも筆者のコード読解が間違っていたらゴメンナサイ

*17:筆者も驚いたのだが i1d3_decode_extEE という関数内では Display Pro HL の EEP にアクセスしているようであった。アドレス情報等はどこにも公開されてないのにどこから入手したんだろう…?

*18:なお筆者の貧弱な頭では、ソースコード上の計算式を見ても なぜこの方法で誤差が最小となるのか分からなかった…