目的
- YCbCrの係数誤り(※)が発生した場合、その誤りに気づけるテストパターンを作成する。
- 作成したテストパターンを用いて実際にYCbCrの係数誤りを検出してみる
※詳細は前回の記事を参照
結論
YCbCrの係数誤りを判別するテストパターン作成に成功した。作成したテストパターンを図1(オリジナル)に、全てのYCbCrの係数組み合わせで試した例を図2に示す。なお表示スペースの都合で図2はテストパターンの右半分のみを表示している。
このテストパターンには Gray, Red および Cyan のタイル状パターンが描かれている。ビデオレベルの低い方の具体的な値は、Red が (255, 0, 78), (247, 0, 78), (239, 0, 78), ... 、Cyan が (0, 255, 255), (0, 247, 247), (0, 239, 239), ... である。
このテストパターンは YCbCrの係数誤りがあった場合に Red または Cyan の タイル状パターンが高階調側で消える性質を持っている。YCbCrの係数が正しい場合はタイル状パターンが消えずに表示される。
なお、残念ながら本テストパターンには制約事項が存在しており誰もが簡単に利用できるものでは無い。 従って本テストパターンの利用は推奨しない(大変残念だが)。制約事項の詳細は本記事の後半を参照。
BT.601 | BT.709 | BT.2020 | |
---|---|---|---|
BT.601 | |||
BT.709 | |||
BT.2020 |
原理
YCbCr係数誤りの発生時に特定階調の信号が最大階調でクリップされる性質を利用している。例として RGB to YCbCr に BT.709 の係数が、YCbCr to RGB に BT.2020 の係数が使われた場合を取り上げる。ソースのRGB値を R, G, B、YCbCr係数誤りにより誤変換された RGB値を R', G', B' と置くと R', G', B' は以下の式で計算できる[1]。
ここで、(R, G, B) = (247, 0, 78) の場合の R', G', B' を求めてみる。
四捨五入すると (R', G', B') = (255, 0, 78) となる。この性質を利用して係数誤りが発生した際にタイル状パターンが潰れるようにした。実際に該当するタイル状パターン(図2の最下段の中央)を見てみると、Red のタイル状パターンがクリップにより見えなくなっている。
使用例
「こんな状況は起こらねーよ」と突っ込みが来そうですが、使用例を挙げたいので無理やり YCbCr 係数誤りを発生させます。 逆に言うと、普通にソフトや機材を使っていれば YCbCr の係数誤りが発生する例は非常に少ないと言えます。
使用例1. ffmpeg で色関連のオプションが不足していた
$ ffmpeg -framerate 60 -i src_img_%4d.png -c:v h264 -crf 18 -pix_fmt yuv420p ng_colorspace.mp4
作成した mp4 ファイルを再生プレイヤーで確認すると図3のようにYCbCr係数誤りが確認された。 これは ffmpeg が BT.601 の係数で RGB to YCbCr 変換し、再生ソフトが BT.709 の係数で YCbCr to RGB 変換しているのが原因である。
YCbCrの係数誤りを無くすには以下のようにパラメータを設定してエンコードすれば良い。
$ ffmpeg -framerate 60 -i src_img_%4d.png -c:v h264 -crf 18 \ -colorspace bt709 -color_trc bt709 -color_primaries bt709 \ -vf setparams=field_mode=prog:range=tv:color_primaries=bt709:color_trc=bt709:colorspace=bt709 \ -pix_fmt yuv420p ok_colorspace.mp4
使用例2. Davinci Resolve での設定ミス
Davinci Resolve で BT.709 のコンテンツを作る予定だったのだが、最近は BT..2020のコンテンツばかり作っていたので、うっかり Color Management 設定を Rec.2020 Gamma 2.4 にしてしまった(図4)。
しかし、素材は全て BT.709色域のものであったし、Windows上で BT.709のモニターを使っていたので特に違和感を覚えることなく最後まで作業して mov で出力した。 その後、色々あり Premiere Pro でその mov ファイルを編集することになった。しかし、Premiere は基本的に YCbCr の変換係数は BT.709 を期待しているのでYCbCr係数誤りが発生した(図5)。
これを修正するには Davinci Resolve で当該ファイルを開き直し、Color Management 設定を Rec.709 Gamma 2.4 に変更して改めてファイルを出力すれば良い。
(実際はこんなシチュエーションはありえないと思うが)。
テストパターンの制約事項
テストパターンの利用に関して現時点で判明している制約事項を示す。なお、他にも制約事項がある可能性は十分にある。
1. 表示デバイス側の色域設定がBT.2020の場合は使えない
2019年3月現在、量産されている表示デバイスで BT.2020色域を100%表示可能なものは存在しない。本テストパターンは彩度が極めて高いRGB値を使用しているため、表示デバイス側の色域設定が BT.2020 だと、YCbCr係数の正誤に関わらずパターンがクリップされてしまう。確認には手動で表示デバイス側の色域設定を BT.2020 --> BT.709 に変更する必要がある(手動で設定できない場合もある)。
2. PQカーブでは使えない
2019年3月現在、量産されている表示デバイスで PQカーブ(SMPTE ST2084) で定義する 10000nits を表示可能なものは存在しない。よって表示デバイス側の EOTF設定が ST2084 だと、YCbCr係数の正誤に関わらずパターンがクリップされてしまう。確認には手動で表示デバイス側のEOTF設定を ST2084 --> 2.4 に変更する必要がある(手動で設定できない場合もある)。
3. 業務用のビデオモニターでYCbCr表示している場合は使えない
RGB空間で暮らしていると、表示デバイスは 0~1023(10bit)、0~100% のレンジを表示するのが当然だと思うのが普通である。 しかし YCbCr空間には Narrow Range[2] および Super-white[3] という概念があり、ビデオモニターでは 0~100% ではなく 0~109% のレンジが表示される。本テストパターンは 100% でクリップされるように設計してあるため、109% まで表示されるとクリップが発生せず、YCbCr係数誤りが判別できない(なお、手元にそんな高価なモニターは無いので実機確認は出来てない)。
感想
念願の YCbCr係数誤り検出パターンがついに完成した。
今後は SDR/HDR が混在することとなり、YCbCr変換係数は BT.709とBT.2020 の双方が使われることとなる。今のところ身の回りで事故が起こったことはないが、事故の危険性は高くなると予想している。 本パターンを使い、新規に使用する機材やソフトに関しては入念なチェックを行うようにしたい。
参考文献
[1] toruのブログ, "YCbCr変換による画質劣化の可能性について", http://trev16.hatenablog.com/entry/2019/03/23/223834 (2019/03/31 参照)
[2] 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/rec/R-REC-BT.2100 (2019/03/31 参照)
[3] EBU, "USER REQUIREMENTS FOR VIDEO MONITORS IN TELEVISION PRODUCTION", https://tech.ebu.ch/docs/tech/tech3320.pdf (2019/03/31 参照)