2024-04-10

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'$ : 図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()

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 で暮らしている人は注意が必要である

2024-03-17

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

1. 背景

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

2. 目的

AW3225QF を使い FF7RB をプレイする際に生じる HDR表示のトレードオフについて、筆者が理解した点をまとめる
トレードオフ改善のアイデアを考えてみる

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''$ : 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 のこと

2024-02-28

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


図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.com や TFT Central などのレビューサイトには、多種多様な光学測定の結果が掲載されている[2][3]。そのためゲームを行うプレイヤーはモニターの購入時に自ら光学測定を行う必要はない。

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

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

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

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

筆者は DisplayHDR 400 True Black が保証する内容が気になり、VESA が公開している DisplayHDR CTS のドキュメントを読んでいた[4]。上から順に評価項目を読んでいたところ Minimum-white Luminance – 10% Center Patch Test と Minimum-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 を選択する方針とした。理由は不自然な輝度の歪みがあるとゲームのプレイ中に気が散る可能性があるからである。

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 の絶対的な色精度について述べた結果ではないことに注意して頂きたい。

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 CMS の spotread を利用して AW3225QF に表示されたカラーパッチの XYZ値を測定する

6.1.2. 測定の具体的な手順について

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

① 事前に測定用のテストパッチを全て作成しておく (図13)
② DaVinci Resolve に HDR10 出力を行うプロジェクトを作成する (図14)
③ 手順① で作成したパターンの中からを表示したいものを選択して AW3225QF に表示する (図14)
④ Argyll CMS のspotread を使って 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 CMS のspotread で 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 に示す。

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

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:ダウンロードには登録が必要です

2024-02-02

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

1. 背景

筆者は自宅でゲーミングモニターをメインモニターとして使っている
ゲーミング用途のため色ズレは気にしない方針だったが、今後のことを考えてモニターのキャリブレーションを行うことにした*1
そこで Calibrite製の Display Pro HL を購入してキャリブレーションを行った
キャリブレーションは Calibrite PROFILER を使ったが、効果確認は ArgyllCMS という別のソフトウェアを使った*2
作業行う中で色々と知見を得ることができたので記事にまとめることにした

2. 目的

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

3. 結論

モニターのキャリブレーションは Calibrite PROFILER を使うことで簡単に実施できた
- 注意点として最初にモニターの Technology Type の指定が必要であった (図1)
- 調査したところ Technology Type を指定することで EDRファイルを読み込んでいるようであった
- 更に調べたところ EDRファイルには図2 に示すスペクトルデータ*3が含まれることが分かった
- EDRファイルは Display Pro HL の測定値を補正するために使用しているようである*4
ArgyllCMS に含まれるspotreadというツールを活用することで人力で効果確認を行えることが分かった
- Photoshop とspotreadを使い画面にカラーパッチを表示して人力で効果確認を行った結果を図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。キャリブレーションを行うソフトウェアには DisplayCAL、ColourSpace、Calman など様々なものが存在するが、今回は購入した Display Pro HL の付属ソフトウェア*6である Calibrite PROFILER を使った (Calibrite PROFILER の使い方については公式の YouTube動画が参考となった[1][2])。

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

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

画面右側の説明を読むと「製造元のウェブサイトを見るか 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のようになった。

各データを観察すると、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 を読み込ませていない、というのがあった。

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

4.2.4. `spotread` に EDRファイルを読み込ませる方法

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

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コマンドを叩くという人力測定となったが、今後は自動で測定できるように環境を整えていくつもりである。

参考までに 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色度図上に色度をプロットしたものである。

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

2024-01-14

Davinci Resolve の Fusion ページのカラーマネジメントについて少し調べた

0. 更新履歴

日付 (YYYY/MM/DD)	内容
2023/1/14	新規作成
2023/1/16	4.4. DaVinci YRGB Color Managed の場合の DRT に関する補足を追記

1. 背景

筆者は画像処理を行う場合に Python を使うことが多い
簡単な処理の場合はコードを書かずに GUI で済ませたくなることもある
そうした場合 DaVinci Resolve の Fusionページが扱えると便利であるが、筆者は Fusionページのカラーマネジメントに関する知識が欠落していた
そのため少し調べてみることにした

2. 目的

Fusion ページのカラーマネジメントについて調べる
具体的には以下の4点に関する理解を深める
- DaVinci Resolve において Fusionページの画像処理はいつ行われるのか（Editページの後？）
- Linear ⇔ Non-linear の変換がどのように行われるのか (自動で変換される？)
- Linear 変換後の色域はどうなっているのか（ACES AP1固定？Timeline color space に変換？）
- Linear 空間をモニター表示する際の View LUT はどうなっているのか

3. 結論

Fusion ページのカラーマネジメントについて理解した内容を以下に示す。

3.1. Fusionページの画像処理が行われるタイミングについて

DaVinci Resolve において Fusion ページの処理は図1 の緑枠で示した箇所で行われることが分かった[1]。 Cut/Edit ページよりも手前で行われることに注意したい[2]。

図1. 全体の中で Fusionページの画像処理が行われる場所。図は公式マニュアルより借用 [1]

3.2. Linear ⇔ Non-linear の変換について

Fusionページで行うコンポジットの作業は Linear空間で行うため、Fusionページの前後で Linear ⇔ Non-linear の変換が必要である。調べたところ、この変換はプロジェクト設定の Color science *1 の設定値によって異なることが分かった[3]。まとめた結果を以下の表1 に示す。

表1. Linear ⇔ Non-linear 変換の方法

Color science 設定値	Linear化手順	利用するノードの例
DaVinci YRGB	作業者がノードを使い手動で変換	CineLog、Gamut、ColorSpaceTransform、 FileLUT、OCIOColorspace など
DaVinci YRGB Color Managed ACEScc、ACEScct	Resolve が自動で変換 *2	-

3.3. Linear 変換後の色域について

色関連の処理を行う場合、Linear化後の色域がどうなっているか理解しておくことも重要である。 Linear変換後の色域に関して調査したところ、こちらもプロジェクト設定の Color science の値によって方法が異なることが分かった。結果を以下の表2 に示す。

表2. Linear化後の色域の情報

Color science 設定値	Linear変換後の色域
DaVinci YRGB	Linear化で使用したノードの設定に従う（作業者が決める）
DaVinci YRGB Color Managed	Timeline color space となる
ACEScc、ACEScct	ACES AP1 となる

3.4. Linear 空間をモニター表示する際の View LUT について

Fusionページの画像をプレビューするためには、画像処理を行う Linear 空間からモニター表示用の色空間へ変換が必須である。 Fusionページにはこれを実現するための機能として LUT menu があり、ここで View LUT を設定できる[3]。

LUT menu から View LUT を選択した結果についてもプロジェクト設定の Color science の値によって挙動が異なることが分かった。結果を以下の表3 に示す。

表3. View LUT の選択について

Color science 設定値	View LUT について
DaVinci YRGB	LUT menu から任意の項目を選択可能
DaVinci YRGB Color Managed ACEScc、ACEScct	自動で sRGB への変換が適用される Managed 以外の項目を選ぶと View LUT が2重がけになる <要出典 *3>

3.5. まとめ

ここまで述べた内容を図にまとめた結果を以下に示す。

4. 補足

以下に補足情報を残す。

4.1. DaVinci Resolve の Color science 設定について

DaVinci Resolve には 4つの Color science 設定が存在する[4]。簡単な説明を表4 にまとめておく。

表4. Color science 設定の簡単な説明

Color science 設定	簡単な説明
DaVinci YRGB	デフォルトの設定。色変換の設定は原則として制作者が手動で行う
DaVinci YRGB Color Managed	RCM 4と呼ばれる Resolve 独自のカラマネが働く。ユーザーは Timeline color space と Output color space さえ設定すれば Resolve がいい感じにカラマネをしてくれる 5
ACEScc / ACEScct	ACES workflow 用のカラマネが働く。（筆者はガッツリと使った経験がなく細かいことは書けないです。すみません）

4.2. Linear 変換後の色域の確認方法

Linear 変換後の色域の調査は自作のテストパターンを使って行った。手順は以下の通りである。

ARRI LogC4 / ARRI Wide Gamut 4 をターゲットとした Color Checker を含むテストパターンを作成 (図3)
Color Checker の R, G, B のパッチを各種色域に変換した場合の RGB値を事前に計算 (表5)
Fusionページ下部の Status Bar に表示される RGB値 (図4) と表5 の内容を比較してどの色域に変換されたかを判断

図3 確認に使用したテストパターン

表5. Color Checker のR, G, B のパッチを各種色域に変換した結果

title	R patch	G patch	B patch
P3D65	(0.38119, 0.04522, 0.04725)	(0.09754, 0.29132, 0.08819)	(0.02500, 0.05063, 0.26642)
BT.2020	(0.29859, 0.06062, 0.04681)	(0.13558, 0.27992, 0.09176)	(0.04157, 0.05215, 0.26291)
ACES AP0 *6	(0.21993, 0.07017, 0.04703)	(0.15140, 0.25571, 0.09645)	(0.07916, 0.07142, 0.25774)
ACES AP1	(0.29251, 0.06101, 0.04833)	(0.13854, 0.27957, 0.09595)	(0.04261, 0.05226, 0.25738)

図4. Fusionページで Green のパッチの RGB値を確認している様子

4.3. View LUT の確認に関する補足

表3 で紹介したように Color science が DaVinci YRGB Color Managed、ACEScc および ACEScct の場合は LUT menu で Managed を選択すると Resolve 側で勝手に sRGB への変換が行われる。これをどう調査したのかを補足しておく。

やり方は単純で以下の手順を行っただけである。

図3 のテストパターンを sRGB に変換しておく (図6 参照)
Fusionページで View LUT が適用された状態の画面のスクリーンショットを撮る (図7 参照)
図6 と図7 の Color Checker の RGB値を比較する

8-bit 精度で 1CV 程度のズレはあったが、sRGB 以外に変換されているようには思えなかったので sRGBに変換されていると断定した。


図6. sRGB に変換した図3のテストパターン	図7. Fusion ページで View LUT が適用された状態のスクリーンショット

4.4. DaVinci YRGB Color Managed の場合の DRT に関する補足

DaVinci Resolve には Ver.17 より DRT (Display Rendering Transform) と呼ばれる機能が導入されている。これは DaVinci YRGB Color Managed が有効な場合はデフォルトで有効となる機能である。

DRT が有効な場合はFusionページよりも手前で Tome mapping が適用されるため[5]、 Fusionページでの Linear変換後の値が純粋な Linear 値からズレてることになる。

無効化する場合は Project Settings で下図のように Input DRT を None に設定すること。

図8. Project Settings で Input DRT を無効化している様子

5. 感想

後から統合した機能ということもあり、Fusionページは EDITページや Colorページと比較するとカラーマネジメントに対する考え方が異なることが分かった。しかし、テストパターンを使って変換後の値を注意深く観察することで、それなりに Fusionページのカラーマネジメントを理解できるようになった。 Fusionページが以前よりも親しく感じられるようになったと思っている。時間をかけて調べた価値はあった。

本記事では掘り下げなかったが View LUT 適用後の HDR表示が困難である点が個人的には気になった。 Fusionページを使った HDR表示については、また機会があれば挑戦してみたい。 *7

6. 参考資料

あまり良くない書き方だとは思うのですが、今回は同じドキュメントに対してページ番号を変えて参照する形をとっています。
将来的に公式マニュアルは公開が終わる可能性があるので、PDFのコピーを以下に貼っておきます。

DaVinci_Resolve_18_Reference_Manual.pdf - Google ドライブ

[1] Blackmagic Design, "December 2023 Reference Manual DaVinci Resolve 18.6", pp.3167-3169
[2] Blackmagic Design, "December 2023 Reference Manual DaVinci Resolve 18.6", p.1521
[3] Blackmagic Design, "December 2023 Reference Manual DaVinci Resolve 18.6", pp.1530-1542
[4] Blackmagic Design, "December 2023 Reference Manual DaVinci Resolve 18.6", p.140
[5] Blackmagic Design, "December 2023 Reference Manual DaVinci Resolve 18.6", pp.220-234

*1:Color science の概要については補足の「4.1. DaVinci Resolve の Color science 設定について」を参照

*2:DaVinci YRGB Color Managed の場合は Input DRT 設定を None にしないと理論通りの Linear値とならないので注意すること。補足を 4.4. に追記したので必要に応じて参照して頂きたい

*3:筆者の調査および Xで頂いた有識者のコメントにより2重がけとなるのは事実だが、それに言及している公式ドキュメントが見つからない

*4:Resolve Color Management の略称

*5:というのは理想であって実際はマニュアルで設定が必要な場合もある

*6:白色点は chromatic adaptation を使って D60 に変換した。AP1 も同様

*7:DeckLink の出力には View LUT が適用されない仕様っぽいが、デュアルモニター構成にして Clean Feed を有効にして表示すればワンチャン行ける予感はしている

2024-01-06

Apple/Adobe の Gain Map HDR について調べて軽く実装をしてみた

1. 背景

Google の Pixel 8 にて Ultra HDR という静止画の HDR 用の新フォーマットが導入された [1][2]
Pixel 8 を買った職場の同僚が HDR の写真を筆者に見せて自慢してきた
筆者が所有している iPhone 15 Pro も静止画の HDR をサポートしているのだが、恥ずかしいことに動作原理について殆ど理解していなかった
このままでは負ける（誰に？）と思っため、iPhone が採用している静止画の HDRのフォーマットについて簡単な調査をすることにした

2. 目的

iPhone 15 Pro で使用されている静止画の HDRフォーマットについて調べる
実際に実装して挙動を確認する

3. おことわり

本記事は Gain Map HDR の概要を理解することに注力しています。そのため Gain Map HDR に関する全ての仕様を網羅的に説明することはしていません。その点はご了承ください。

4. 結論

4.1. 静止画の HDR規格の種類に関する理解

静止画の HDR フォーマットとして以下の3種類が存在することを理解した
- Android 14 にてサポート開始となった Ultra HDR [1][2]
- ISO/TS 22028-5 として国際標準になっている ISO HDR [3][4]
- Apple/Adobe が ISO 化を進めている Gain Map HDR [5-7]

4.2. Gain Map HDR の仕様に関する理解

Gain Map HDR の仕様について以下を理解した
- ① Gain Map と呼ばれる2次元のデータを用いることで環境光やモニタースペックに応じて動的に HDR画像を生成できる
  - 概要については図1を参照
- ② Gain Map は SDR Rendition と HDR Rendition の差分を元に生成する *1
  - そのため事前に SDR Rendition と HDR Rendition の双方が完成している必要がある
- ③ 動的に生成する HDR画像は Gain Map から計算するため SDR Rendition と HDR Rendition の中間画像となる
  - 計算式も決まっているため、画像ビューアによって頓珍漢な変換が行われることはない
  - 制作者は動的に生成される HDR画像の見た目を予想できる
- ④ 動的な HDR画像の生成に関してはウェイトパラメータが非常に重要である
  - $W$ の計算時には HDR Capacity と呼ばれる、SDR White と HDR White の比から求まるパラメータを使用する
  - 制作者は Gain Map 用のメタデータを設定することで $W$ の挙動を制御できる
- ⑤ Gain Map HDR は輝度方向の変換は行うが色度方向の変換は行わない
  - つまり Tone mapping には対応するが Gamut mapping には対応しない
- ⑥ Gain Map HDR は後方互換性を維持しつつ、多くの画像フォーマットで利用が可能である
  - JPEG/JPEG XL/HEIF/AVIF/TIFF/DNG に Gain Map の埋め込みが可能 *2
  - 後方互換性として Gain Map に対応していない画像ビューアでは SDR Rendition or HDR Rendition の表示が行われる

Gain Map の生成処理および適用処理の全体像を理解した
- 生成処理の概要を図2 に、適用処理の概要を図3 に示す
- なお本記事で説明するのは図のオレンジ色の部分のみである。その他の詳細に関しては仕様書を参照して頂きたい

4.3. 実装の結果

実際の写真およびテストパターン画像に対して Gain Map を使い SDR 画像から HDR画像を生成した結果を以下に示す。

動画1. Gain Map を使い普通の写真を SDR から HDR に変換した様子

動画2. Gain Map を使いテストパターンを SDR から HDR に変換した様子
なお、右上のColorChecker は SDR Rendition と HDR Rendition で同じ輝度となるように Gain Map を作成してある

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

本記事を書くにあたり筆者が学習した内容を以下に記していく。

最初に静止画用の HDR規格について簡単に述べ、その後に Gain Map HDR の仕様について述べていく。

5.1. 静止画向けの HDRの規格の簡単なまとめ

まず静止画の HDR規格について簡単にまとめておく。

静止画における HDR というと、以前は露出を変えて連続撮影したデータを合成することで「明るい部分と影の細部がきれいに表現された画像」を意味することが多かった[8]。この画像には確かにハイダイナミックレンジの情報量は含まれるものの、表示は SDRレンジ のままであった。別の言い方をすると HDRレンジの撮影データにトーンマッピングを適用し SDRレンジに変換したものであった。

その一方で、本記事で扱う静止画の HDR は 表示が HDRレンジ であるものを示す。これはザックリと言うと既に動画で利用されている HDR の技術[9] を静止画に適用したものである。

さて、静止画の HDRフォーマットは大きく以下の2種類に分けられる。

表示デバイスの性能や視聴環境に応じた補正を定義していないフォーマット
表示デバイスの性能や視聴環境に応じた補正を定義しているフォーマット

前者に ISO HDR が、後者に Gain Map HDR と Ultra HDR がある。

ISO HDR とは CICP等を使って HDR の色空間を定義する静止画 HDRの規格であり、ISO/TS 22028-5:2023 にて国際標準となっている。動画でいうと HDR10 に近い。

Gain Map HDR や Ultra HDR は更に利便性を向上させ、表示デバイスの性能や視聴環境に応じた補正も可能にしたものである。動画でいうと Dolby Vision や HDR10+ に近い。

以後、本記事では Gain Map HDR に注目して説明していく（Ultra HDR については残念ながら調査ができていないため言及しない）。

5.2. Gain Map HDR について筆者が理解した内容のまとめ

ここからは本題の Gain Map HDR について述べていく。

5.2.1 筆者の所感

はじめに所感を述べる。

細かい動作を確認していて分かったが、Gain Map HDR は筆者が以前より求めていたものに合致していた。少し前に書いた JPEG XL の記事で筆者は以下の意見を書いた。

色々と試していて思ったが tone mapping, gamut mapping がやはり鬼門だと思う。HDR/WCG は表示デバイスごとに表示性能の差があまりにも大きくて、一体全体どう変換するのが最適なのか未だに分からない。様々な実装が提案されているが国際標準に至るものはなく、輝度や色度が制限されたモニターにおける「正しい HDR表示」をどう定義すれば良いのか本当に分からない。

このうち Tone mapping については Gain Map HDR が一つの解になっていると考えている。ということで筆者が理解した内容を以下にまとめていく。

5.2.2. Gain Map HDR の概要

まず Gain Map HDR について数式ベースで概要を説明する。

Gain Map は SDR Rendition と HDR Rendition の差分（比率）から作成する。Gain Map を $G$ と置くと以下の式で作成される。

$\displaystyle \begin{aligned} G &= \log_2\left( \frac{HDR + k_{hdr}}{SDR + k_{sdr}}\right) \end{aligned} \tag{1}$

ここで $SDR, HDR$ はそれぞれ Linearスケールでの SDR Rendition の値、HDR Rendition の値を意味する。また $k_{sdr}, k_{hdr}$ は $\log_2$ の結果を安定させるための係数である。

(1)式を変換すると $G$ と $SDR$ と $HDR$ の関係は以下となることが分かる。

$\displaystyle \begin{aligned} HDR &= (SDR + k_{sdr}) \cdot 2^G - h_{hdr}\\ \end{aligned} \tag{2}$

$\displaystyle \begin{aligned} SDR &= (HDR + k_{hdr}) \cdot 2^{-G} - k_{sdr} \\ \end{aligned} \tag{3}$

さて (2)、(3)式を見ると分かるように Gain Map HDR では SDR Rendition から HDR Rendition を生成することも、その逆に HDR Rendition から SDR Rendition を生成することもできる。 Gain Map HDR では Gain Map をかける元の画像を Base Rendition と呼ぶ。上記の (2)式は SDR Rendition が、(3)式は HDR Rendition が Base Rendition となっている。

以後は説明の簡略化のため、Base Rendition を SDR Rendition に固定して 説明を行う。なお、Gain Map HDR の仕様では Base Rendition を HDR Rendition とした運用も可能である。詳細については仕様書を参照して頂きたい。

さて、改めて(2)式に注目する。この数式では Gain Map を使って SDR Rendition から HDR Rendition を作ることはできるが、 SDR Rendition と HDR Rendition の中間 の Adapted HDR Rendition *3 は作成できない。

Gain Map HDR ではウェイト $W$ を用いることで Adapted HDR Rendition の作成を可能としている。 $W$ は以下のように Gain Map $G$ にかける形で適用する。

$\displaystyle \begin{aligned} HDR &= (SDR + k_{sdr}) \cdot 2^{G \cdot W} - h_{hdr} \end{aligned} \tag{4}$

以上が Gain Map HDR の概要となる。以下で筆者が重要だと感じたウェイト $W$ について説明を続けていく。

5.2.3. ウェイト $W$ の詳細

ここでは (4)式で使用するウェイト $W$ の計算方法について説明する。 $W$ について理解するためには、まず Gain Map HDR に登場する HDR Capacity の概念を理解する必要がある。

HDR Capacity とは HDR成分を表示可能なヘッドルームがどの程度あるかを数値で示したものである（ヘッドルームの概念については WWDC 2023 および WWDC 2021 の動画が参考になる[3][10] ）。

HDR Capacity $H$ は以下の数式で計算できる。

$\displaystyle \begin{aligned} H &= \log_2 \left(\frac{HDR_{white}}{SDR_{white}}\right) \\ \end{aligned} \tag{5}$

ここで $SDR_{white}, HDR_{white}$ は画像を表示するデバイスの SDR White (Diffuse White) の輝度、ピーク輝度を意味する。

例としてピーク輝度が 600 nits と 1000 nits の表示デバイスの $H$ を何パターンか計算してみる。結果を以下の表に示す。

環境	$SDR_{white}$ [nits]	$HDR_{white}$ [nits]	$H$ (HDR Capacity)
一般的な屋内	203	600	1.56
一般的な屋内	203	1000	2.30
暗い屋内	80	600	2.91
暗い屋内	80	1000	3.64
明るい屋外	400	600	0.58
明るい屋外	400	1000	1.00

このように HDR Capacity $H$ は表示デバイスのスペックや環境光の強さによって変化するパラメータである。 Gain Map HDR では $H$ を利用してウェイト $W$ を計算する。

さて (4)式を見ると分かるが $W$ は 0 ～ 1 の値が期待されているパラメータである。 $W=0$ の場合は生成される画像が SDR Rendition となり、 $W=1$ の場合は HDR Rendition となる。

ということで Gain Map HDR では $H$ を 0～1 に正規化してウェイト $W$ として用いる。 $W$ の計算は以下の式で行う。

$\displaystyle \begin{aligned} W &= clamp \left(\frac{H - M_{lo}}{M_{hi} - M_{lo}}, 0, 1\right) \\ \end{aligned} \tag{6}$

ここで $M_{lo}$ 、 $M_{hi}$ はそれぞれ HDR Capacity の下限と上限を意味するパラメータであり、制作者または制作ツールがメタデータとして Gain Map に付与するデータである。

説明が長くなったが、こうして HDR Capacity $H$ を正規化することでウェイト $W$ が得られる。

(6)式を見れば分かるように $M_{lo}$ , $M_{hi}$ の設定は重要である。例として $M_{hi}$ の値による Adapted HDR Rendition の違いを動画2 に示す。

動画2. 表示デバイスの輝度を 203 ～ 10000 nits と変化させた際の $M\_{hi}$ による描画結果の違い
左側は $M\_{hi} = \log_2 (1000/203) = 2.30$ 、右側は $M\_{hi} = \log_2 (10000/203) = 5.62$

動画を見ると表示デバイスの輝度設定は同じなのに、左右で明るさが異なっていることが分かる。これは、左側の画像は表示デバイスの輝度が 1,000 nits で $W=1$ となるのに対して右側は 10,000 nits で $W=1$ となるからである。

別の言い方をすると $M_{lo}$ , $M_{hi}$ を適切に設定することにより、画像の制作者は表示デバイスの HDR Capacity に応じたウェイト $W$ の変化を制御可能とも言える。これは非常に画期的であり、例えば 400 nits のピーク輝度をもつデバイスに表示される Adapted HDR Rendition に対して「白飛びが生じても良いので輝度優先で表示する」、「輝度は暗くなるが白飛びが生じないように表示する」といった点を制作者側がコントロール可能になる。そのため、ビューアソフトによって意図しないトーンマップが適用されるのを防ぐことができる。

とはいえ、全ての制作者が適切に $M_{lo}$ , $M_{hi}$ を設定するのは難しいと考える。実際のところは多くのシーンで制作ツールが自動で適切な値を設定すると考える。あるいは $M_{lo} = \log_2 \left(\frac{203}{203}\right) = 0.0$ , $M_{hi} = \log_2 \left(\frac{1000}{203}\right) = 2.30$ を決め打ちで指定した場合も大半の場合は適切な表示になると考える。なぜならば動画ではこの設定が標準となっているからである。*4

5.3. Gain Map HDR に関するその他のポイント

Gain Map HDR の概要説明はこれまで述べた通りである。以下に追加で筆者がポイントだと感じた点を記載する。なお、以下の文言は殆ど筆者のポエムのようなものなので読み飛ばしてもらって構わない。

5.3.1. Gain Map 生成時の SDR Rendition の輝度に関して

今回の筆者の実装では、Gain Map の計算前に SDR Rendition を 2.03倍する 処理を加えた。これは ITU-R BT.2305 にて定義されている SDR 用の Reference White (100 nits) を ITU-R BT.2408-7 で定義されている HDR用の Reference White (203 nits) に変換するためである[12][13]。

というのも、筆者は Adapted HDR Rendition について以下のように考えていたからである。

Adapted HDR Rendition は HDRモードの表示デバイス *5で表示される
$W = 0$ となった場合の SDR Rendition も HDRモードの表示デバイスで表示される
そのため SDR Rendition は 100 nits 基準ではなく 203 nits 基準として準備した上で Gain Map を作成するのが好ましい

なお、当然のことであるが 2.03倍の処理は Linear空間にて行った。

5.3.2. Gain Map 生成時の SDR Rendition および HDR Rendition の Color Gamut (色域) について

今回の筆者の実装では Gain Map 計算前の SDR Rendition および HDR Rendition の Color Gamut は事前に P3-D65 に変換しておいた。一般的には SDR は BT.709色域、HDR は P3-D65 or BT.2020色域を使うことが多いが、Gain Map HDR は (4)式から分かるように色域の変換 (Gamut Mapping) を行わない からである。そのため今回は色域方向の変換について考慮せずに済むように P3-D65 色域に事前に変換を行った。

6. おわりに

本記事の内容とは全然関係が無いのですが、私は石川県に住んでおります。ご存知の方も多いとは思いますが 2024年1月1日に能登半島にて地震が起こり、能登半島では甚大な被害が出ています。

私自身は家屋も身体も無事であり何不自由なく過ごせておりますが、被災地の復興には多くの支援が必要だと考えております。もしも可能であれば何らかの形で支援をして頂けると助かります。以下に支援用のリンクを記載しました。内容をよく確認の上、余力のある方がいればご協力をお願いいたします。

7. 参考資料

[1] Android Open Source Project, "Ultra HDR", https://source.android.com/docs/core/camera/ultra-hdr
[2] Android Police, "Hands-on with Ultra HDR in Android 14: The future of photography", https://www.androidpolice.com/android-14-ultra-hdr-hands-on/
[3] Apple Developer, "Support HDR images in your app - WWDC23", https://developer.apple.com/videos/play/wwdc2023/10181
[4] ISO/TS 22028-5:2023, "Photography and graphic technology - Extended colour encodings for digital image storage, manipulation and interchange - Part 5: High dynamic range and wide colour gamut encoding for still images (HDR/WCG)", https://www.iso.org/standard/81863.html
[5] Adobe, "Gain Map Specification (1.0 draft 14, October 2023)", https://helpx.adobe.com/camera-raw/using/gain-map.html https://helpx.adobe.com/content/dam/help/en/camera-raw/using/gain-map/jcr_content/root/content/flex/items/position/position-par/table/row-io13dug-column-4a63daf/download_section/download-1/Gain_Map_1_0d14.pdf
[6] IS&T Electronic Imaging (EI) Symposium, "EI 2023 Plenary 2: Embedded Gain Maps for Adaptive Display of High Dynamic Range Images", https://youtu.be/HBVBLV9KZNI?si=iz7Z1Px1EjQtD6zu
[7] ISO/WD 21496-1, "Digital Photography - Gain map metadata for image conversion - Part 1: Dynamic Range Conversion", https://www.iso.org/standard/86775.html
[8] Apple サポート (日本), "iPhoneのHDRカメラ", https://support.apple.com/ja-jp/guide/iphone/iph2cafe2ebc/12.0/ios/12.0
[9] Wikipedia, "High-dynamic-range television", https://en.wikipedia.org/wiki/High-dynamic-range_television
[10] Apple Developer, "Explore EDR on iOS", https://developer.apple.com/videos/play/wwdc2022/10113/?time=364
[11] ITU-R BT.2100-2, "Image parameter values for high dynamic range television for use in production and international programme exchange", https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.2100-2-201807-I!!PDF-E.pdf
[12] ITU-R BT.2408-7, "Guidance for operational practices in HDR television production", https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2408-7-2023-PDF-E.pdf
[13] ITU-R BT.2305, "A reference viewing environment for evaluation of HDTV program material or completed programmes", https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.2035-0-201307-I!!PDF-E.pdf

*1:SDR Rendition, HDR Rendition という表現は Gain Map の仕様書に従ったものである。日本語だと SDRマスター、HDRマスターという言い方が合うと筆者は考える

*2:その一方で今後に全てのファイルフォーマットで Gain Map HDR が運用されるかは不透明。現時点では「技術的に可能」くらいの理解が良いかもしれない

*3:Adapted HDR Rendition という表現は Ultra HDR の Specification から拝借した呼び方である。Gain Map HDR の仕様書では固有名称が与えられておらず、本記事で扱いづらかったため名前を与えた

*4:ITU-R BT.2100-2 の Table 3 の Peak luminance of display および ITU-R BT.2408-7 の Table 1 の HDR Reference White を参照 [11][12]

*5:HDRモードとは Reference White が 100 nits ではなく 203 nits となっている状態を意味する

2023-10-22

DaVinci Resolve を使って Apple Log の特性を調べてみた

1. 背景

筆者は iPhone 15 Pro MAX を購入した
iPhone 15 では Blackmagic Cam App を使うことで Apple Log を使った HDR撮影が可能である
筆者はウキウキでテスト撮影をしたのだが、撮影中のモニター表示は Log のままであり露出調整が困難だった
そこで EL Zone System [1] を参考に露出調整用の View LUT を作成しようと考えた
しかし残念なことに Apple Log の特性は一般公開されていないため View LUT が作成できない状況にあった
View LUT を作らずに撮影を行うことは困難だったため DaVinci Resolve を使って Apple Log の特性を調査することにした

2. 目的

Apple Log の Encode/Decode の特性を調べる
Apple Log の色域を調べる
得られた特性を利用して撮影時の露出調整用の View LUT を作成する

3. 結論

Apple Log の Encode/Decode の特性

DaVinci Resolve を使うことで Apple Log の特性を得ることに成功した。 Apple Log 単体の Encoding Function (OETF) の特性を図1に、他の Encoding Function との比較を図2に示す。


図1. Apple Log の特性	図2. 様々な Log Encoding との比較

Apple Log の色域

DaVinci Resolve を使うことで Apple Log の色域が Rec.2020 であることが分かった。

撮影時の露出調整用の View LUT の作成

得られた Apple Log の特性を利用して露出調整用の View LUT を作成することに成功した。撮影に使用した様子を動画1 に示す。

動画1. 撮影用に EL Zone System を用いた Apple Log 用の View LUT を適用した様子

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

4.1. 作業環境

今回、筆者が作業を行った環境は以下の通りである。

名称	Version
Python 関連	リンク先の`pip list`の結果参照 (※)
iPhone	iPhone 15 Pro Max
iOS	17.0.3
Blackmagic Cam	1.1.00029

※ちゃんと確認したら自前でコンパイルしたライブラリはリストに表示されてなかったですね…

4.2. Apple Log の Encoding Function の調査

実は筆者は Resolve を利用した Cmera Log の特性調査を 4年前に一度行ったことがあった。そのため今回も同様の考え方を用いて調査を行った。

trev16.hatenablog.com

おおまかな確認手順は以下の通りである。

Resolve に読み込むテストパターン画像の作成
Resolve を使いテストパターンに対して Apple Log の Encoding Function を適用し EXR形式で保存
EXRファイルから Apple Log の Encoding Function を実現する 1DLUT を作成
1DLUT を使い Apple Log の特性をプロット

4.2.1. Resolve に読み込むテストパターン画像の作成

まず Resolve への入力となる Log2 スケールの Ramp パターン画像を作成した。ここで Log2 スケールとは水平方向に Log2 の空間で等間隔になるスケールを意味する。

例として 0～16 までを Log2 で刻んだ結果を以下に示す（比較対象として Linearスケールも併記した）。

# Log2 Scale
[ 0.0625, 0.125, 0.25, 0.5, 1, 2, 4, 8, 16 ]

# Linear Scale
[ 0, 2, 4, 6, 8, 10, 12, 14, 16 ]

画像の作成には以下のようなコードを使用した（別途 OpenImageIO が必要かも？）。

import numpy as np
from colour.io import write_image

def create_test_pattern_for_apple_log_encoding_analysis():
    width = 1920
    height = 1080
    ref_val = 0.18
    exp_range = 12

    def create_log2_x_scale(
            sample_num=32, ref_val=1.0, min_exposure=-6.5, max_exposure=6.5):
        x_min = np.log2(ref_val * (2 ** min_exposure))
        x_max = np.log2(ref_val * (2 ** max_exposure))
        x = np.linspace(x_min, x_max, sample_num)
        return 2.0 ** x

    def h_mono_line_to_img(line, height):
        return line.reshape(1, -1, 1).repeat(3, axis=2).repeat(height, axis=0)

    x = create_log2_x_scale(
        sample_num=width, ref_val=ref_val,
        min_exposure=-exp_range, max_exposure=exp_range)
    img = h_mono_line_to_img(x, height)
    fname = f"./img/src_log2_-{exp_range}_to_{exp_range}_stops.exr"
    print(fname)
    write_image(img, fname)

4.2.2. Resolve を使いテストパターンに対して Apple Log の Encoding Function を適用し EXR形式で保存

生成した画像は前述のコードを見ればわかるように Linear データである。これを Resolve を使って Apple Log に変換した。 Resolve の Color Management 設定を図3 の通りに設定し、Apple Log に変換して EXR 形式で出力した (図4)。


図3. Color Management の設定	図4. 出力設定

4.2.3. EXRファイルから Apple Log の Encoding Function を実現する 1DLUT を作成

Resolve から出力された画像は Log2 スケール上の Linear データを Apple Log で Encode したデータ列 である。そのため、このデータ列は Shaper を適用済みの 1DLUT とみなすことができる。

ということで、今回はこのデータ列を Apple Log の Encoding function を得るための 1DLUT として利用した。具体的には以下のようなコードを準備して Apple Log の Encoding function を実現した。

import numpy as np
from colour.utilities import tstack
from colour.io import read_image

def save_apple_log_as_1dlut():
    resolve_out_exr= "./secret/apple_log_encode_out.exr"
    img = read_image(resolve_out_exr)
    width = img.shape[1]
    ref_val = 0.18
    exp_range = 12

    x = create_log2_x_scale(
        sample_num=width, ref_val=ref_val,
        min_exposure=-exp_range, max_exposure=exp_range)
    y = img[0, ..., 1]  # extract horizontal green line data 
    lut = tstack([x, y])
    np.save("./secret/apple_log_encode_lut.npy", lut)

def log_encoding_apple_log(x):
    """
    Scence linear to Apple Log.

    Parameters
    ----------
    x : ndarray
        Scene linear light (1.0 is SDR diffuse white)

    Examples
    --------
    >>> log_encoding_apple_log(0.18)
    0.488271418052

    Note
    ----
    Valid range of `x` is from 2^-12 to 2^12
    """
    lut_1d = np.load("./secret/apple_log_encode_lut.npy")
    y = np.interp(x, xp=lut_1d[..., 0], fp=lut_1d[..., 1])

    return y

簡単に説明すると log_encoding_apple_log をコールすると save_apple_log_as_1dlut にて作成した 1DLUT を参照し、 np.interp を使って LUT から Apple Log の値を得る仕組みになっている。

以上により Apple Log の Encoding Function を得ることができた。

4.2.4. 1DLUT を使い Apple Log の特性をプロット

作成した log_encoding_apple_log を使い、以下のようなコードを用いて特性をプロットした。結果は冒頭の図1、図2 を参照…なのだが見やすいように以下にも再掲しておく。

import matplotlib.pyplot as plt

def plot_apple_log_for_blog():
    x = create_log2_x_scale(
            sample_num=32, ref_val=0.18,
            min_exposure=-12, max_exposure=12)
    apple_log = log_encoding_apple_log(x)
    x_plot = x / 0.18  # To set 18% grey to 0.0 on a Log2 scale
    fig = plt.figure(figsize=(10, 6))
    ax = fig.add_subplot(111)
    ax.set_xscale('log', base=2)
    ax.plot(x_plot, apple_log, '-o')
    plt.show()


図1 (再掲) Apple Log の特性	図2 (再掲) 様々な Log Encoding との比較

図を見ると、Apple Log は S-Log3 や LogC4 などのシネマカメラで使用される Camera Log と比較すると収録可能なダイナミックレンジが狭いことがわかる (携帯用デバイスの Log なので実運用上は全く問題はないだろうが)。

4.3. Apple Log の Decoding Function の調査

Encoding Function の逆の作業を行っただけなので省略。

4.4. Apple Log の色域の調査

Apple Log の色域に関しても Resolve を使うことで簡単に調べることができた。色々とやり方はあるのだが、ここでは Video Scope にある CIE Chromaticity を使った確認方法を紹介する。

やり方は非常に簡単で、Color Management 設定で Output color space に Apple Log を指定した状態で Video Scope を CIE Chromaticity に変更するだけである。すると現在の Output color space の色域が右上に表示される (図5 の② を参照)

ということで Apple Log の色域は Rec.2020 であることが分かった。

4.5. Apple Log 用の撮影補助用 View LUT の作成

ここまでの内容により Apple Log の特性を理解することができた。ここから Apple Log 用の View LUT 作成の話をしていく。

4.5.1. そもそも View LUT が必要になった理由について

初めに View LUT が必要となった理由を簡単に述べておく。

iPhone 15 Pro で動作する Blackmagic Cam App は Color Space に「Apple Log - HDR」を指定した場合、以下の図6 のような表示となる。これは SDRモードで表示している iPhone のディスプレイに Apple Log が表示される形となっており、自分のような素人にとっては露出調整が極めて困難であった。

一応、Blackmagic Cam App には標準でフォルスカラー表示も用意されていたのだが、 Apple Log の Code Value の 0～100% に対して色付けをする仕様となっており、やはり自分のような素人には扱いが困難であった。

そこで今回は EL Zone System を利用した View LUT を自作して適用することにした。

4.5.2. EL Zone System の概要および本記事での実装方針

ここで EL Zone System について補足説明しておく。EL Zone System は Webページを見ると分かるように Linear値の 18% Gray を基準したフォルスカラー表示を行う技術である。そのため Log Encoding の特性に依らず、HLG でも S-Log3 でも LogC4 でも一貫したフォルスカラー表示が可能となる素晴らしい技術である。

当然、Apple Log に関しても Decoding Function の特性が分かっていれば利用可能である。しかし EL Zone System は詳細仕様が公開されていないため、今回は筆者の独自解釈による実装を行うことにした (そのため作成した View LUT は非公開とする)。

4.5.3. View LUT の作成および動作確認

ということで、以下で EL Zone System を用いた View LUT の生成方法および動作確認の方法について述べていく。

View LUT は 65x65x65 の 3DLUT として作成した。アルゴリズムの説明は非常に簡単なので省略する。生成用のサンプルコードはリンク先に掲載した。興味のある方は確認して頂きたい。

続いて作成した View LUT の動作確認を行った。動作確認用に「水平方向に Log2 スケールで増加する Scene Linear Light」を「Apple Log で Encode」したテストパターンを作成し、 Resolve 上でテストパターンに View LUT を適用して 18% Grey基準のフォルスカラー表示となるか確認した。

テストパターンの生成コードを以下に、テストパターンの様子を図7に、Resolve上で View LUT を適用した結果を図8 に示す。

def create_tp_for_verify_el_zone_system_lut_apple_log():
    width = 1920
    height = 1080
    num_of_sample = width
    ref_val = 0.18
    exp_range = 8
    x = create_log2_x_scale(
        sample_num=num_of_sample, ref_val=ref_val,
        min_exposure=-exp_range, max_exposure=exp_range)
    y = log_encoding_apple_log(x)
    img = h_mono_line_to_img(y, height)
    fname = "./img/src_apple_log_log2_"
    fname += f"-{exp_range}_to_{exp_range}_stops.exr"
    print(fname)
    write_image(img, fname)


図7. テストパターンの見た目	図8. テストパターンに View LUT を適用した様子

今回、このテストパターンは 18% Grey 基準で -8 stops ～ +8 stops のレンジで作成した。そのため EL Zone System の黒色～白色までの 17色が等間隔で表示されれば良い (-0.5, 0.0, +0.5 stops は 1/2 の間隔)。

右端が白色 (Over Exposed) にならずに 16色表示となってしまっているが、これは図1 を見ればわかるように Apple Log が +6 Stops までのレンジしかないことが原因である。よって問題ではない。

よって図8 の結果から View LUT は狙い通りに作成できたと判断した。

作成した View LUT は iPhone 15 Pro にコピーを行い、Blackmagic Cam で読み込んで View LUT として使用した。実際に適用している様子が冒頭の動画である。こちらの動画も以下に再掲しておく。

動画1. 撮影用に EL Zone System を用いた Apple Log 用の View LUT を適用した様子

4.6. ソースコード

確認に使用したソースコード一式は以下にある。例によって筆者の環境でないと正常に動作しないと思われるが、参考データとして提供する。

github.com

5. 感想

筆者の知的好奇心は満たされた。満足した。

次は Gain Map HDR について調査してまとめる予定である（スペクトルの勉強はどうした？センサーも買ったのに全然使ってないぞ？？）。

6. 参考資料

[1] Cinecam Inc. "EL Zone System", https://www.elzonesystem.com/

背景

目的

結論

詳細

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

ICC Profile の MHC2 タグについて

"MHC2" private tag definition

MHC2Type structure definition

Matrix definition

1DLUT definition

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

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

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

Windows 上で ICC Profile の適用

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

現状の問題点

感想

参考資料

1. 背景

2. 目的

3. 結論

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

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

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

5. 感想

0. 更新履歴

1. 背景

2. 目的

3. 機材について

3.1. ハードウェア

3.2. ソフトウェア

4. 結論

4.1. AW3225QF について

4.2. 測定環境について

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

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

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

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

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

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

6. 付録

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

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

6.1.2. 測定の具体的な手順について

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

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

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

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

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

7. 感想

参考資料

1. 背景

2. 目的

3. 結論

4. 詳細

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

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

4.1.2. Technology Type の追加調査

4.1.3. EDRファイルを CCSSファイルに変換して解析

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

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

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

4.2.2. ArgyllCMS とは

4.2.3. ArgyllCMS の spotread について

4.2.4. spotread に EDRファイルを読み込ませる方法

4.2.5. 効果確認の実施

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

4.3.1. なぜ Display Pro HL は測定値を補正する必要があるのか

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

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

5. 感想

6. 参考資料

0. 更新履歴

1. 背景

2. 目的

3. 結論

3.1. Fusionページの画像処理が行われるタイミングについて

3.2. Linear ⇔ Non-linear の変換について

3.3. Linear 変換後の色域について

3.4. Linear 空間をモニター表示する際の View LUT について

4.2.3. ArgyllCMS の `spotread` について

4.2.4. `spotread` に EDRファイルを読み込ませる方法

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

5.2.3. ウェイト $W$ の詳細