0. 更新履歴

日付	内容
2021.3.4	公開
2024.7.31	5.2. に `avifenc` v1.0.1 向けのコマンドライン引数を追記

1. 背景

以前から Windows OS 上で簡単に静止画の HDR を表示したいと考えていた
HDR の Metadata が付与された AVIF[1] 形式の静止画を用意すれば Google Chrome 上で静止画の HDR表示が可能との情報を得た[2]
気になったので簡単に確認することにした

2. 目的

AVIF 形式の静止画の HDR ファイルを作成する
HDR対応の表示デバイスに Google Chrome を使って表示して意図通りになるか確認する

3. 結論

AVIF 形式で静止画の HDRファイルを作成することに成功した
作成した AVIFファイルが Google Chrome 上で HDRとして表示されることを確認した
- その一方で、Chrome上で表示されるテストパターンの Code Value は想定よりも僅かに小さな値となることが分かった
- この現象は Chrome以外のアプリケーションでも発生しており、OS または GPU 側の処理の問題だと考える（要追加調査）

作成した AVIF形式のテストパターンを図1(※1)に、テストパターンの表示特性を図2に示す。

※1 PC版 Google Chrome 以外だと表示されない可能性があります。ご了承下さい。

図1ではテストパターンが縮小表示されているため、気になる方は右クリックして「Open image in new tab」で表示して頂きたい。


図1. 作成した AVIF形式のテストパターン。HDRモニターで表示すれば HDRとして表示される。

表示されない場合はお手数ですがこのリンクをクリックして保存した .avif ファイルを GoogleChrome にドラッグ＆ドロップしてください


図2. AVIF のテストパターンを Chrome で表示した場合の特性。理論値よりも少し値が小さくなる。

4. 理論

4.1. HDR の静止画ファイルに必要なメタデータについて

静止画ファイルを SDR ではなく ”HDR” としてアプリケーションに認識させるためには、静止画ファイルにメタデータを埋め込む必要がある。現時点で広く使われているメタデータの一つに CICP(Coding-independent code points) がある[3]。

CICP とは静止画と動画に対する Colour Primaries や Transfer Characteristics などの特性を1byteの整数型で表現したものである。 CICP は符号化方式に依存しない情報であるため Coding-independent code points という名称になっている。

CICP は ITU-T H.273[3] の中で以下の6種類が定義されている。

このうち SDR/HDR の判別を含めた "色に関する情報" として使用されるのは以下の3つである。

ColourPrimaries
TransferCharacteristics
MatrixCoefficients and VideoFullRangeFlag

さて、CICP の具体的な表記方法であるが、ColourPrimaries, TransferCharacteristics, MatrixCoefficients, VideoFullRangeFlag をハイフンで繋ぎ 1-1-1-0, 9-16-9-0 のようにする書き方がある[6]。本記事でもこの書き方を使用する。CICP の具体例を以下の表1 に示す。

表1. CICP の具体例

CICP	Colour Primaries	Transfer Characteristics	Matrix Coefficients	Video Full Range Flag
1-1-1-0	BT.709	BT.709	BT.709	Narrow Range
12-16-0-1	P3D65	SMPTE ST 2084	Identity	Full Range
9-16-9-1	BT.2020	SMPTE ST 2084	BT.2020nc	Full Range
9-18-9-1	BT.2020	HLG	BT.2020nc	Full Range

4.2. AVIF フォーマットを採用した理由

CICP を埋め込める静止画のフォーマットには HEIC[7] と AVIF がある（※2）。AVIF は Google Chrome でサポートされており Windows環境で簡単に取り扱うことができる。一方で HEIC は Google Chrome では非サポートである。こうした背景もあり、本記事では AVIF にのみ注目し静止画のHDR表示が行えるか検証することにした。

※2 筆者が知らないだけで他にも対応しているフォーマットがある可能性はある

5. AVIF の作成

今回は Alliance for Open Media の libavif[8] をビルドして作成される avifenc を使って AVIF を作成した。

5.1. avifenc のビルド

筆者の Dockerfile からビルド部分を引用したものを以下に示す。-DAVIF_BUILD_APPS=1 を指定すると avifenc, avifdec がビルドされる。

RUN mkdir -p /root/local/src \
    && cd /root/local/src \
    && git clone https://github.com/AOMediaCodec/libavif.git -b v0.8.4 libavif_aom \
    && cd /root/local/src/libavif_aom/ext \
    && $SHELL ./aom.cmd \
    && $SHELL ./libjpeg.cmd \
    && cd /root/local/src/libavif_aom/ \
    && mkdir build && cd build \
    && cmake .. -G Ninja -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=OFF -DAVIF_CODEC_AOM=ON -DAVIF_LOCAL_AOM=ON -DAVIF_LOCAL_JPEG=ON -DAVIF_BUILD_TESTS=1 -DAVIF_BUILD_APPS=1 \
    && ninja

5.2. 静止画 PNG ファイルから AVIF への変換

2024.7.31 追記: ここのコマンドライン引数は現在では上手く動作しないかもしれません。その場合は少し後ろの追記を参照ください。

事前に作成しておいた PNG のテストパターン画像を以下のコマンドで AVIF に変換した。 --cicp オプションで指定している 9/16/9 が ColourPrimaries, TransferCharacteristics, MatrixCoefficients に該当する。今回は HDR10 ライクな静止画を作成したかったので 9-16-9 (BT.2020 - SMPTE ST 2084 - BT.2020nc) を指定した。なお VideoFullRangeFlag は avifenc では -r オプションで別途指定する必要がある。

avifenc ./png/SMPTE_ST2084_ITU-R_BT.2020_D65_1920x1080_rev04_type1.png -d 10 -y 444 --cicp 9/16/9 -r full --min 0 --max 0 ./avif/aom_10-bit_yuv444_cicp-9-16-9_full-range.avif

2024.7.31 追記

上記のコマンドライン引数は avifencは最新版 (v1.0.1) 向けではないため、改めて推奨するコマンドライン引数を書いておく。

2024年7月時点での筆者推奨のコマンドライン引数は以下である。

avifenc ./png/SMPTE_ST2084_ITU-R_BT.2020_D65_1920x1080_rev04_type1.png -y 444 --cicp 9/16/0 -r full --lossless --ignore-exif ./avif/aom_10-bit_rgb444_cicp-9-16-9_full-range.avif

変更点は以下の 4点である。

① bit depth を 10-bit --> 12-bit に変更
- ソースの PNG が 16-bit であるため、bit 欠損を最小化するために 12-bit とした
② cicp を 9/16/9 --> 9/16/0 に変更
- YCbCr 444 ではなく RGB 444 でのエンコードとなり画質の劣化を抑えられる
③ --min 0 --max 0 を --lossless に変更
- 一括でロスレスに必要な設定をしてくれて、問題がある場合は警告表示もしてくれる
④ --ignore-exifを追加
- これを付けないとエラーになった。残念ながら必要な理由はよくわかっていない

6. AVIF の表示確認

まず、作成した AVIF ファイルを BRAVIA KJ-65X9500G に表示して HDRとなっていることを目視で確認した。次に、本当に意図取りの Code Value となっているかを確認するためにPCから出力している HDMI信号をキャプチャすることにした。

筆者は諸事情により elgato製の 4K60 S+ というキャプチャデバイスを所有している。このデバイスはHDR信号を受信可能だったため、このデバイスを使用して Code Value のキャプチャを行った。

キャプチャしたのは図3 の黄色枠で示したグレーパッチの部分である。ここには 0, 16, 32, ..., 992, 1008, 1023 CV の合計65種類のパッチがある。このパッチをキャプチャして想定する Code Value と一致するか確認した。

なお、キャプチャは H.265 で行ったため ProRes や DNxHR 形式でキャプチャできる業務用デバイスと比較すると若干精度が劣る。ご了承頂きたい（※3）。

※3 当該製品は精度確認用途のデバイスではないため、筆者の使い方が悪いだけである。メーカー側には何の非も無い。

こうして Code Value を確認した結果が冒頭の図2 である（以下に再掲する）。


図2. AVIF のテストパターンを Chrome で表示した場合の特性。理論値よりも少し値が小さくなる。

理想値と比較すると若干のズレが生じている。しかし本症状は Windows10 標準の Movies & TV アプリや MPC-BE などでも観測されており、 AVIF とは関係の無い OS or GPU 側の処理が原因だと推測している。本件については現在調査中である。もし何らかの事実が判明した場合は本ブログで報告する。

最後に筆者のPC環境を記載しておく。今回の検証は以下のバージョンで行った。

項目	値	バージョン
OS	Windows10	20H2
Browser	Google Chrome	Version 88.0.4324.190 (Official Build) (64-bit)
GPU	GeForce GTX 1660 SUPER	461.72

7. 感想

購入してからずっと自宅で文鎮と化していた 4K60 S+ が役立つ時が遂に来た！本記事では全く紹介できなかったが 4K60 S+ はカスタムした EDID を設定することが可能である。これにより Windows 10 が表示デバイスのスペックに応じた処理を行うことについても考察が可能となった。これは夢が広がる！！（本編とあまり関係のない感想でした）。