1. 背景

筆者は手持ちの表示デバイスが 10bit で表示できているか目視で確認したくなる事がある
表示デバイスが HDR で表示している場合は簡単に 10bit表示の目視確認ができる。しかし SDR 表示の場合は目視確認は難しい
そこで簡単に判別するためのパターンを自作することにした

2. 目的

表示デバイスが 10bit表示かどうかを目視で確認するパターンを作成する
- なお表示デバイスは SDR（※1）で表示しているものとする

※1 Gamma: 2.4, Luminance: 80cd/m2～200cd/m2, Gamut: BT.709

3. 結論

目的を達成するパターンの作成に成功した。

作成したパターンを図1に示す。このパターンは 9つのブロックに分かれており、各ブロックの上側が 8bit 精度のパターン、下側が 10bit 精度のパターンとなっている。 10bit表示であれば上側と比較して下側が滑らかな変化となる。一方で 8bit表示であれば上側と下側で同じ見た目となる。

なお、それぞれのブロックは下に行くほど Lightness が高く、右に行くほど Chroma が高くなるよう調整した。ただし、Gamma=2.4 の特性上 Lightness が高くなるほど 1CV あたりの輝度差は小さくなるので、再下段のパターンでは目視の識別は少々厳しいかもしれない。


図1. 作成した 10bit表示確認パターン（ブログの画像は圧縮されてるので以下のリンクから可逆圧縮をお試しください）

パターンが欲しい方は以下からダウンロードして下さい。再配布をしなければ自由に使って頂いて構いません。

drive.google.com

加えて効果確認として自宅の TV（SONY BRAVIA KJ-65X9500G）で表示した結果を図2, 図3 に示す。図2 は 10bit 表示している場合の見え方、図3 は 8bit 表示の場合の見え方である（8bitとなるよう出力デバイスの設定を意図的に変更した）。図2 と図3 の差はごく僅かなので注意深く見比べて頂きたい。


図2. 10bit 表示時のパターンの見え方	図3. 8bit 表示時のパターンの見え方

4. 詳細

4.1. 10bit 確認用パターンを自作した理由

10bit 表示の確認パターンは既に ELSAのサイト [1]で .psd ファイルが公開されており、 Photoshop を所有するユーザーは誰でも簡単に確認が可能である。

その一方で筆者は .png 形式のファイルも欲しいと考えていた。理由は DaVinci Resolve などの映像制作ソフトウェアでも簡単に扱うためである。もちろん、自分で ELSA のパターンを .png に変換して使用すれば目的は達成できる。しかし ELSA のサイトには .psd ファイルの利用規約が明記されておらず、勝手に変換して使用すると権利関係のトラブルに発展する可能性があった。

そこで勉強も兼ねてパターンを自作することにした。

4.2. 作成するパターンの基本的な考え方

作成する 10bit 表示確認パターンは以下の特性を持たせることにした。

10bit 表示時はグラデーションにバンディングが見えない
8bit 表示時はグラデーションにバンディングが見える

この特性を分かりやすく示したものを図4, 図5 に示す（図は理解しやすいように加工してあり厳密な描画ではない）。


図4. 10bit 表示時に期待する見え方	図5. 8bit 表示時に期待する見え方

ここで1点問題がある。それはバンディングを目視確認可能なグラデーションを作るのは意外に難しい という点である。例えば図4 は実は 8bit精度で作成したパターンである。しかしバンディングは全く見えない。何も考えずランダムに色（Code Value）を選んだ場合、バンディングが目視可能となる可能性は非常に低い。 8bit でバンディングが目視可能なパターンを作成するには、理論的な裏付けをした上で使用する Code Value を選ぶ必要がある。

4.3. CIE DE2000 を利用したバンディングの見えやすい Code Value の探索

そこで筆者は CIE DE2000 [2] を用いて 8bit でバンディングが目視可能なグラデーションの探索を行うことにした。

細かい説明する前に「8bit でバンディングが見えるグラデーション」がどのような条件で生じるかを整理しておく。筆者の考える条件を以下に示す。

グラデーションでは Code Value が 1ずつ変化する
Code Value が 1変化した際の色差が JND（※2）を上回る

※2 Just-noticeable difference [3]

このような特徴を持つ場合、少々乱暴な表現になるが、以下の2ステップで目標を達成できると考える。

8bit の全ての RGB値（約1600万通り）に対して Code Value が1 変化した場合の色差を計算する
色差の値が大きい Code Value を基準としてグラデーションを作成する

例えば探索を行った結果、(R, G, B) = (110, 88, 63) に対して Green を 1変化させた際の色差が大きい、という事が分かったとする。この場合、グラデーションの Code Value を "(110, 88, 63), (110, 89, 63), (110, 90, 63), ..." と指定すればバンディングが目視可能となる可能性が高い（※3）。

ということで、8bit の RGB空間の約1600万色に対して色差を計算する処理を行った。

探索は任意の RGB値に対して、Code Value が増加する方向に隣接する 7種類のRGB値と色差を計算することで行った。文だと意味が分からないと思うので、具体的な例を以下に挙げる。

探索対象の RGB値を (64, 64, 64) とする。この RGB値に Code Value が増加方向で隣接する RGB値は以下の7種類である。

表1. 増加方向で隣接する7種類の RGB値の例

No.	RGB offset	RGB Value
1	(+0, +0, +1)	(64, 64, 65)
2	(+0, +1, +0)	(64, 65, 64)
3	(+0, +1, +1)	(64, 65, 65)
4	(+1, +0, +0)	(65, 64, 64)
5	(+1, +0, +1)	(65, 64, 65)
6	(+1, +1, +0)	(65, 65, 64)
7	(+1, +1, +1)	(65, 65, 65)

上記の例は RGB = (64, 64, 64) の場合だが、これを R: 0～254, G: 0～254, B: 0～254 の範囲で行うことで 8bit RGB空間で隣接する Code Value で色差が大きい場所を探索した。

計算した結果 255x255x255x7 = 約1億通りの色差のデータを得た。

※3 本当に厳密に検討するのであれば、環境光や表示デバイスのピーク輝度などを考慮して JND を超えるか否か判断が必要だと考えるが、今回は色差が大きい Code Value を選ぶだけでお茶を濁した（ガバガバな判断方法でゴメンナサイ）。

4.4. 色差の計算結果から Code Value を選ぶ

続いて先ほどの色差の計算結果から条件を設けて Code Value を選択した。なぜならば単純に色差の大きい Code Value を選ぶと得られる Code Value が低すぎて（暗すぎて）一般的な室内環境での確認が困難だからである。

今回は以下の9つの条件を設けて Code Value を選択した。条件を表2. に示す。ここで h idx, v idx は図1 のパターンのブロックのインデックスを意味する。また、L*, C* は CIELAB における Lightness, Chroma を意味している。

表2. グラデーションに使用する Code Value を選択する際の条件

	h idx = 0	h idx = 1	h idx = 2
v idx = 0	L* > 20 & C* > 0	L* > 20 & C* > 10	L* > 20 & C* > 20
v idx = 1	L* > 35 & C* > 0	L* > 35 & C* > 10	L* > 35 & C* > 20
v idx = 2	L* > 50 & C* > 0	L* > 50 & C* > 10	L* > 50 & C* > 20