toruのブログ

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

PlayStation 5 本体に HDRフォーマットで録画したプレイ動画を DaVinci Resolve で開くための手順

背景と目的

  • 1つ前の記事で筆者は PS5 本体に録画した HDRのプレイ動画の解析を行った

trev16.hatenablog.com

  • 解析は主に DaVinci Resolve を使って行ったのだが、いくつか事前準備が必要だった
  • その手順をメモとして残すことにした

結論

以下の手順で HDRフォーマットで録画したプレイ動画を DaVinci Resolve で開くことが可能となる。

PS5 側の設定

  • ① 事前に PS5 で利用可能な USBドライブを準備し、PS5背面の USBポートに挿しておく
  • ② 「設定」->「キャプチャーとブロードキャスト」->「ビデオクリップ形式」の画面を開く
  • ③ 「ファイル形式」を「効率を優先 (WebM)」に設定する (図1 参照)
    • 筆者が確認したところ MP4 形式で録画すると SDR でしか録画できなかった
    • なお録画解像度を 3840x2160 にすると自動で「効率を優先 (WebM)」になる
  • ④ PS5 でゲームを起動しコントローラーのクリエイトボタンを押して録画を行う
  • ⑤ PS5 のメディアギャラリーを開き、USBドライブにコピーする (動画1 参照)

図1. ビデオクリップ形式の画面


動画1. PS5 本体で録画したデータを USBドライブにコピーする様子

PC 側の設定

  • ① USBドライブの録画データを PC にコピーする
  • FFmpeg を使って mp4 コンテナに変換する
    • 変換しなくても DaVinci で開けるのだが、音声が消えてしまうため .webm -> .mp4 に変換する
    • 以下に示した FFmpeg パラメータのうち、大事なのは -color_range tv である。これがないとメタデータのミスマッチが発生した
ffmpeg -color_primaries bt2020 -color_trc smpte2084 -colorspace bt2020nc -color_range tv -i INPUT_FILE_NAME.webm -c:v copy -c:a copy -color_primaries bt2020 -color_trc smpte2084 -colorspace bt2020nc -color_range tv OUTPUT_FILE_NAME.mp4
  • ③ 変換した .mp4 ファイルを DaVinci で開く

注意事項

USBドライブから PC に .webm ファイルをコピーする際に、本当に HDR形式で録画できているか確認することをお勧めする。 筆者は MPC-BE という再生プレイヤーで .webm ファイルを開き、「File」-> 「Properties」を選択してメタデータを確認するようにしている。

図2 のように Color primaries と Transfer characteristics が BT.2020 と PQ となっていれば HDRフォーマットで録画できている。

図2. MPC-BE を使って .webm ファイルのメタデータを確認している様子

PS5 の「HDR調整」と「プレイ動画の録画機能」の関係を軽く調べた(FINAL FANTASY 16 を使用)

1. 背景

筆者は FINAL FANTASY 16 (以後 FF16 と略す) をプレイするために PlayStation 5 (以後 PS5 と略す) を購入した。 PS5 は HDR をサポートしたゲーム機であり、HDR に関して以下の特徴がある。

  • HDR調整という機能があり HDR対応ゲームの表示を表示デバイスに最適化できる
  • HDR のゲームプレイ動画を PS5本体に HDRフォーマットで録画できる
  • 録画した動画は YouTubeHDRフォーマットで投稿できる

筆者は個人的な興味から PS5 本体に録画したプレイ動画の解析を行っていたが、録画データを観察しているうちに HDR調整と録画データの関係が気になった。 具体的には 録画データに HDR調整の結果が反映されるのか、PS5 本体に録画したプレイ動画を YouTube にアップした際に、HDR調整の結果によって動画の見た目が変わるのか、といったことが気になった。

そうした背景があり簡単な調査を行うことにした。

2. 目的

  1. PS5の HDR調整結果が PS5本体のプレイ動画の録画データに反映されるか調べる
  2. 上記の結果を元に、録画した FF16の HDRプレイ動画を YouTube にアップロードする場合の注意点があれば記載する

3. 結論

3.1. 結論1

PS5の HDR調整結果は PS5本体のプレイ動画の録画データに反映される。

そのため、例えば複数人のプレイヤーが同じシーンを録画して YouTube にアップした場合には、 各プレイヤーの HDR調整結果によって動画の輝度レンジが異なる結果となる。

確認のために 4種類のパラメータで HDR調整を行い、同一のシーンを録画した結果を動画1 に示す。


動画1. 異なる複数のパラメータで HDR調整を行った場合の比較。動画の後半に輝度分布の分析あり。

3.2. 結論2

YouTube へ FF16 のHDRプレイ動画をアップする際、PS5 の HDR調整結果は殆ど気にする必要はないと考える。 なぜならば YouTube にアップロードした動画を各種 HDR対応デバイスで確認したところ、HDR調整の結果によらず HDR感のある動画として知覚できたからである。

一方で、データレベルでは高輝度のシーンの描画結果には差異があったため (図1参照)、気になるユーザーは録画をする時だけ HDR調整の Highlight側の Adjustment Index (※1) を 15 以上に設定することをオススメする。

※1 Adjustment Index については後述するが、一旦ここで Index とターゲット輝度の関係を図2 に示す。

図1. 異なる HDR調整結果での輝度の比較 図2. HDR調整の Adjustment Index と輝度(推測値)の関係

3.3. 使用機材、ソフトウェア

検証に使用した機材とソフトウェアは以下の通りである。

名称 バージョン
PlayStation 5 (CFI-1200B) 23.01-07.40.00.06-00.00.00.0.1
FINAL FANTASY 16 Version 1.02
Elgato 4K60 S+ (HDMI キャプチャ機材) 不明
Elgato 4K Capture Utility Version 1.7.6

4. 結論に至までの経緯

4.1. PS5 の HDR調整に関する調査

始めに PS5 の HDR調整に関する調査を行った。結果を以下に示す。

4.1.1. HDR調整の概要

HDR調整は PS5 の 「ホーム」->「設定」->「スクリーンとビデオ」にある設定項目である。

取扱説明書には テレビに合わせて明るさを構成することで、HDRを最適化してより美しい映像を体験できます との記載がある。 この「HDRを最適化して」という文言が具体的にどのような処理を意味するのかは不明だが(※2)、上記の文言から PS5 内部で HDR調整の結果に基づきゲーム映像に何らかの処理が適用されることが推測できる。

さて HDR調整の具体的な内容だが、調整は 図3~図5 に示す 3種類のパターンを使って行う。 プレイヤーは各パターンの明るさを変更して使用している表示デバイスに最適なポイントを探す。

図3. HDR調整 (1/3) 図4. HDR調整 (2/3) 図5. HDR調整 (3/3)

パターンの明るさ変更は 32段階 or 16段階で行うことができる。図3 と 図4 の調整は 32段階、図5 は 16段階の調整となっている。

4.1.2. HDR調整の用語整理

さて、突然だが本記事では 図3、図4 の調整を Highlight側の調整、図5 の調整を Shadow側の調整と呼ぶことにする。 理由は名前を付けないと記事が書きづらいからである。なお、これは筆者独自の呼び方であり一般的な呼び方ではないことに注意して頂きたい(※3)。

同様に 32段階 or 16段階の調整点を Adjustment Index と呼ぶことにする。

※2 そこそこ調べたのだが処理内容に言及している公式の文書は見つからなかった
※3 そもそも一般的な呼び方が分からなかったので筆者は独自の呼び方をすることにした、という背景がある

4.1.3. Adjustment Index と対応する輝度の関係の調査

さて、ここまで調べると Adjustment Index を変化させた際のパターンの輝度が気になってくる。 そこで筆者は自宅にある Elgato 4K60 S+ (以後はキャプチャ機材と呼ぶ) を使って調査した。

Adjustment Index を変化させた際の信号の生値をプロットした結果を図6に、それを輝度値に変換した結果を図7 に示す。

図6. 信号生値のプロット結果 図7. 輝度値に変換後のプロット結果

図6、図7 を細かく観察すると、グラフは歪んでおり また最大値も 10000 nits に達しておらず不自然なことが分かる。 筆者はこの原因はキャプチャ機材に問題があると考えた。そこで少々乱暴ではあるが上記のグラフを推測に基づき修正することにした。

修正後の値を以下のテーブルにて赤字で示す。また、グラフをプロットしなおした結果を図8、図9 に示す。

項目 生値(測定値) 生値(修正後の推測値) 輝度値(測定値) 輝度値(修正後の推測値)
Highlight 517 ~ 1006 520 ~ 1023 97 ~ 8536 100 ~ 10000
Shadow 0 ~ 144 0 ~ 152 0 ~ 0.832 0 ~ 1.00
図8. 信号生値のプロット結果 (修正後の推測値) 図9. 輝度値に変換後のプロット結果(修正後の推測値)

なお、図6~図9 は HDR調整時の Adjustment Index と輝度値の対応関係を示しただけである。 ゲームの出力輝度が Adjustment Index の輝度値に制限されるとは限らないので誤解のないようにして頂きたい (※4※5)。

※4 PS5 の説明書に書かれているのは「HDRを最適化してより美しい映像を体験できます」という点のみであり、出力輝度の範囲に関する明確な記述は無い
※5 筆者が確認したところ FF16 のゲーム画面は Adjustment Index で設定した輝度値よりも高い輝度値も出力されていた

4.2. HDR調整と PS5 の録画データの関係

さて、これまでの調査で HDR調整の概要は理解できた。続いて FF16 のゲーム画面がどのように変化するかを確認した。 まず筆者は PS5 本体にプレイ動画を録画した際に HDR調整の結果が適用されるか確認することにした。

なぜ、このような確認をしたかというと、筆者は HDR調整が適用されるのは HDMI出力のみで、内部録画データには適用されないと推測していたからである。 しかし確認したところ、HDR調整の結果は HDMI出力と内部録画データの両方に適用されていた。確認時のゲーム画面の輝度分布の比較を図10 に示す。

図10. HDMI出力結果と PS5 内部録画データの輝度比較

図10 の各ブロックの説明は以下の通り。右上と右下の輝度レンジが一致していることから、HDR調整の結果は内部録画データにも適用されることが分かる。

場所 Highlight側の Adjustment Index 対応する輝度 確認対象
左上 31 約10000 nits HDMI出力
右上 0 約100 nits HDMI出力
右下 0 約100 nits PS5 内部録画データ

4.3. PS5 の録画データの YouTube 投稿結果の目視確認

4.3.1. YouTube 投稿結果の目視確認を行う理由

ここまでの調査で PS5 の録画データに HDR調整の結果が適用されることが分かった。 最後に HDR調整が適用されたデータをそのまま YouTube にアップロードして問題がないか簡単な確認を行った。

なぜこのような確認を行ったかというと、ユーザーの使用している表示デバイスの輝度レンジの差によって以下の問題が生じることを恐れていたからである。

  • ユーザーA は ピーク輝度 400 nits の Display HDR 400 対応モニターを所有していた
    • ユーザーA は PS5 の HDR調整で Highlight側の Adjustment Index を 9 (約 400 nits) に設定した
    • ユーザーA は FF16 の HDRプレイ動画を PS5 内部に録画した
    • ユーザーA は 録画データを YouTube にアップロードして一般公開した
  • ユーザーB は ピーク輝度 1600 nitsiPad Pro を所有していた
    • ユーザーB は ユーザーA が投稿した FF16 のプレイ動画を視聴した
    • ユーザーB は「なんか高輝度が出ていなくてHDR感が少ないな~」という印象を持ってしまった
4.3.2. 確認手順

確認は以下の手順で行った。

  • ① 以下の表に示す通り Highlight側の Adjustment Index を 4種類用意した
Adjustment Index 対応する輝度 用意した理由
0 約100 nits 参考比較用に理論的な最低値を指定(目視評価のターゲットではない)
9 約400 nits 実用的な最低値を指定。Display HDR の最低グレードに合わせた
15 約1000 nits 映像制作市場における基準輝度が 1000 nits であるため指定
25 約4000 nits 個人的にありそうだと考える最大値を指定。Dolby Vision の基準輝度


  • ② それぞれのHDR調整が適用された FF16 の HDRプレイ動画を PS5にて録画した
  • ③ 比較しやすいよう DaVinci Resolve を使って 4つの録画データを結合し YouTube にアップロードした
  • ④ 輝度レンジの異なる 5種類のデバイスYouTube にアップロードした動画を視聴して問題ないか確認した

目視確認に使用したデバイスおよびスペックを以下の表に示す。

機材名 ピーク輝度 確認環境
Pixel 4 XL 約450 nits YouTube App Version 18.25.39
G3223Q 約600 nits Microsoft Edge Version 114.0.1823.67
BRAVIA 65X9500G 約1200 nits YouTube App Version 3.05.003
iPhone 13 Pro 約1200 nits YouTube App Version 18.25.1
iPad Pro 12.9-inch (第5世代) 約1600 nits YouTube App Version 18.25.1

なお、確認に使用した動画は結論欄に貼り付けた動画である。念のため以下に再掲する。


動画1 (再掲). 異なる複数のパラメータで HDR調整を行った場合の比較。動画の後半に輝度分布の分析あり。
4.3.3. 確認結果

さて、各デバイスで視聴した結果であるが、筆者が観察した限りでは Adjustment Index 9 (約400 nits) でも十分に明るさを知覚でき、特に暗いという印象は受けなかった。 もちろん、ごく一部に存在する高輝度領域では白飛びによりディテールが失われることもあったが、動画を一時停止してコマ送りしないと気づかないレベルであった。 そのため、筆者は冒頭の結論で述べた通り YouTube への動画のアップロード時に HDR調整の結果は気にする必要ないと考えている。

なお、この結果は FF16 の HDRプレイ動画の結果であり、他のゲームソフトでも同じ傾向にあるかは不明である。その点は注意して頂きたい。

5. 感想

HDR調整の内容が気になって FF16 のプレイを中断してブログを書いていたが、これでやっと FF16 のプレイを再開できるぜ。

DaVinci Color Transform Language (DCTL) を使った printf デバッグを試した

1. 背景

前回、筆者は以下の記事で DaVinci Color Transform Language (DCTL) を試し、得られた知見を記事にまとめた。

trev16.hatenablog.com

その中で筆者は「コンソール出力が無いので printf デバッグすらできない」という旨を書いた。

すると、記事を読んでくださった有識者の方から、少々トリッキーではあるが、printfデバッグの方法を教わることができた。 また非常にありがたいことに、その方からは DCTL のサンプルコードも頂いた(本当にありがとうございます🙏)。

ただ、サンプルコードの内容は難解であり、筆者は処理内容を理解することができなかった。 そこで、自己の理解を深めるためにスクラッチから printf デバッグ用の DCTL ファイルを作成することに決めた。

2. 目的

printf デバッグ用の DCTL ファイルを作成する。

3. 結論

指定した座標の RGB値を画面表示する DCTL ファイルの作成に成功した (本記事ではこの画面表示が printf デバッグを意味する)。 その様子を 図1 および 動画 1 に示す。

図1. printf デバッグ (という名の数値表示) をしている様子

動画1. printf デバッグ (という名の数値表示) をしている様子

4. やり方

やり方はシンプルである。 図1 を見れば分かるようにデバッグ情報(数値)を画面に描画することで実現している。

どのようにして図1 の描画に至ったのか、順を追って説明する。

4.1. DCTL を使った図形の描画

DCTL では画面出力の RGB データに直接アクセスできるため、任意の図形をプロットすることが可能である。 例えば以下のコードを書くと、画面左上に黄色の矩形を描画できる。

__DEVICE__ float3 transform(int p_Width, int p_Height, int p_X, int p_Y, float p_R, float p_G, float p_B)
{
    float3 out = make_float3(p_R, p_G, p_B);
    float3 rectangle_color = make_float3(1.0, 1.0, 0.0);
    float2 st_pos = make_float2(200, 100);
    float2 ed_pos = make_float2(1200, 300);
    
    if((st_pos.x <= p_X) && (p_X < ed_pos.x)){
        if((st_pos.y <= p_Y) && (p_Y < ed_pos.y)){
            out.x = rectangle_color.x;
            out.y = rectangle_color.y;
            out.z = rectangle_color.z;
        }
    }

    return out;
}

図2. 画面左上に矩形 (黄色) を描画した様子

4.2. 矩形を組み合わせた数値の描画

矩形が書けてしまえば、矩形の組み合わせで任意の数字の描画が可能である。 筆者は下図のように A~H の 8個の矩形を用いて数値と小数点を描画することにした。

図3. 8個の矩形の組み合わせで数値と小数点を表現する様子

4.3. 表示用の数値の取得および描画

DCTL では _tex2D 関数を使う事で任意の座標の RGB 値を float型で取得できる。

取得値は float 型であるため、本来であれば 1.2345E-5 のような指数表記で描画するのが好ましかったのだが、 実装が面倒だったので、今回は固定小数点ライクな表示仕様とした。

その結果、正の数は6桁、負の数は5桁での表示となった。表示の様子を図4 に示す

図4. 色々な数値を描画がしている様子

表現可能な数値の範囲は以下の通りである (0を除く)。

  • 正の数: 0.00001 ~ 999999
  • 負の数: -0.0001 ~ -99999

5. ソースコード

一応、以下に置いときます。例によってコメントを全然書いて無いですが…。

printf デバッグに必要なのは 私のリポジトリ にある以下の2ファイルです。

6. 感想

この DCTLコードの実装は想像よりずっと楽しかった。満足したので元の作業に戻る。

DaVinci Color Transform Language (DCTL) を試してみた

0. 更新履歴

日付 Revision 内容
2023/05/20 rev.1 新規作成
2023/05/24 rev.2 DCTL の Syntax Error の確認方法を追記
2023/06/02 rev.3 DCTL の printf デバッグ方法を追記

1. 背景

諸事情により DaVinci CTL (DCTL) を使って動画コンテンツの解析をしたくなった。 しかし、筆者は DCTL を全く触ったことが無かったため、まずは簡単な DCTL のコードを書いてみることにした。

2. 目的

  • DCTL をとりあえず試してみる
  • 実装で苦労した点をまとめておく

3. 結論

簡単な DCTL のコードを書き DaVinci 用のエフェクトを作成することに成功した。成果物の紹介と苦労した点を以下に示す。

3.1. 成果物の紹介

2020年に作成した HDRコンテンツ解析用 Luminance Map の生成コードを DCTL で書き、 DaVinci Resolve のエフェクトとして利用可能にした。

ソースコードは以下で公開している。動作の様子を動画1 に示す。

github.com

動画1. 作成したエフェクトが動作する様子

3.2. 実装で苦労した点

  • ①エラーログが無く Syntax Error が出ないのでコードの文法誤りの検出が困難
    • 筆者は VS Code上でソースコード 1行ずつコメントアウト して問題のあるコードを検出していた
    • 2023/05/24 追記
      • ブログ公開後、複数の方にエラーログの確認方法を教えて頂いた🙏
      • 以下のフォルダにある davinci_resolve.log を見ると Syntax Error の内容が確認できる
        • Windows: C:\Users\<user_name>\AppData\Roaming\Blackmagic Design\DaVinci Resolve\Support\logs
        • macOS: /Users/<user_name>/Library/Application Support/Blackmagic Design/DaVinci Resolve/logs
      • エラーログの例は以下
C:\ProgramData\Blackmagic Design\DaVinci Resolve\Support\LUT\TY_DCTL\show_internal_value.dctl(3106): warning: parameter "rgb" was set but never used
C:\ProgramData\Blackmagic Design\DaVinci Resolve\Support\LUT\TY_DCTL\show_internal_value.dctl(3148): error: identifier "rgb" is undefined
2 errors detected in the compilation of "C:\ProgramData\Blackmagic Design\DaVinci Resolve\Support\LUT\TY_DCTL\show_internal_value.dctl".


  • ②動作確認時のデバッグが困難
    • コンソール出力が無いので printf デバッグすらできない
    • 仕方ないので閾値で出力を2値化するデバッグ用の DCTL を用意して内部値の推測を行った (図1~図3)
図1. DCTL Off 時の様子 図2. 閾値を 1.0 に設定した場合の様子 図3. 閾値を 10.0 に設定した場合の様子

2023/06/02 追記

ややトリッキーではありますが、DCTL で printf デバッグすることに成功しました。詳細は以下の記事を参照下さい。 trev16.hatenablog.com

4. DCTL について筆者が理解した点

以下で筆者が理解した点を参考情報として残しておく。 なお、今回作成した DCTL のプラグインは EDIT ページで実行する想定で作成した。 Colorページでの運用は今のところ考えていない(Colorページでも使えるとは思うが)。

4.1. DCTL のマニュアルは README.txt のみ

DaVinci Resolve の公式マニュアルには詳細の記述がない。

詳細マニュアルは DaVinci 起動時にメニューバーから Help --> Documentation --> Developer を選択した際に 開くウィンドウの先にある DaVinciCTL/README.txt のみである。

4.2. 生成した DCTLファイルは LUT と同じフォルダに配置する

作成した DCTL のコードは .dctl の拡張子で保存して、以下のフォルダに配置する。

  • Mac OS X: Library/Application Support/Blackmagic Design/DaVinci Resolve/LUT
  • Windows: C:\ProgramData\Blackmagic Design\DaVinci Resolve\Support\LUT
  • Linux: /home/resolve/LUT

意外なことに DCTL 用のフォルダではなく、LUT用のフォルダに配置 する仕様であった。 DaVinci 的には DCTL も LUT も内部的には似たような取り扱いなのかもしれない。

4.3. DCTL の処理は Timeline color space で行われる

非常に恥ずかしい話なのだが、筆者はこれまで DaVinci の EDITページで色処理を行う経験が殆どなく、 Timeline color space が何のために存在しているのか分かっていなかった(勝手に内部処理は Linear空間で行われると考えていた)。

今回 DCTL のコードを書くことで初めて Timeline color space の意味が理解できた。 筆者の理解は次の通りである。Timeline color space は Color Grading における ACEScct のように、信号処理の内容に応じて適切な色空間を選択するために存在している。

さて、そうなると Timeline color space の値域を正しく理解しておく必要がある。 なぜならば値域を理解しないことには DCTL のコードを書けないからである(HDR の場合は 1.0 を超える値を取り扱うので)。

筆者が調査したところ、0.0 ~ 1.0 に正規化された入力データを使用した場合の Timeline color space の値域は以下の表1となることが分かった。

表1. 入力の Gamma 設定と Timeline color space の Gamma 設定の組み合わせにおける値域の例
入力の Gamma Timeline の Gamma
Linear
Timeline の Gamma
PQ
Timeline の Gamma
2.4
2.4 0.0 ~ 1.0 0.0 ~ 0.508 0.0 ~ 1.0
PQ 0.0 ~ 100.0 0.0 ~ 1.0 0.0 ~ 6.81

設定によって値域が大きく異なるため、Timeline color space で処理を行う DCTL コードを書く際は、この点に注意する必要がある。

4.4. DCTL では CTL のコードをそのまま流用できない

筆者は当初、CTL のコードも include して使い回せると考えていたのだが、そんなことは無かった。

以下は SMPTE ST 2084 の EOTF を CTL から DCTL に書き換えた際の diff である。 見て分かるように様々な変更が入るため CTL をそのまま流用するのは不可能であった。

--- st2084.ctl  2023-05-14 11:48:03.867909400 +0900
+++ st2084.dctl 2023-05-14 11:50:22.216460100 +0900
@@ -6,23 +6,23 @@
 
 const float pq_C = 10000.0;
 
-float ST2084_2_Y( float N )
+__DEVICE__ float ST2084_2_Y( float N )
 {
-  float Np = pow( N, 1.0 / pq_m2 );
+  float Np = _powf( N, 1.0 / pq_m2 );
   float L = Np - pq_c1;
   if ( L < 0.0 )
     L = 0.0;
   L = L / ( pq_c2 - pq_c3 * Np );
-  L = pow( L, 1.0 / pq_m1 );
+  L = _powf( L, 1.0 / pq_m1 );
   return L * pq_C; // returns cd/m^2
 }
 
-float[3] ST2084_2_Y_f3( float in[3])
+__DEVICE__ float3 ST2084_2_Y_f3( float3 in )
 {
-  float out[3];
-  out[0] = ST2084_2_Y( in[0]);
-  out[1] = ST2084_2_Y( in[1]);
-  out[2] = ST2084_2_Y( in[2]);
+  float3 out;
+  out.x = ST2084_2_Y( in.x );
+  out.y = ST2084_2_Y( in.y );
+  out.z = ST2084_2_Y( in.z );
 
   return out;
 }

主な変更箇所は以下の通りである。

  • 関数定義の冒頭に __DEVICE__ の接頭語がつく
  • pow_powf に変更
  • float in[3]float3 に変わる
    • それにともないメンバのアクセスに .x, .y, .z の記述が必要

5. 感想

思っていたより難易度が高かったが DCTL の基本的な書き方を理解できた。ここまで来れば応用は割と簡単なので、 今後は本来やりたかった処理を数週間かけて実装していきたい。

ocioconvert コマンドを使って画像ファイルの色変換を行う

1. 背景

  • ここ数ヶ月ほど OpenColorIO v2 (以後 OCIO v2 と略す) の configファイルを触っていた
  • これまで画像に対して OCIO v2 を使った色変換を行うには、毎回 Nuke や Affinity Photo などを起動していた
  • 流石に面倒になってきたのでコマンドラインでサクッと変換したくなった
  • ocioconvert というコマンドの存在を思い出したので試してみることにした

2. 目的

  • ocioconvert を使って画像ファイルの色変換を行う
  • その際に config.ocio のview_transformsも適用できるようにする

3. 結論

ocioconvert コマンドを使い、以下の通りにコマンドを入力すれば変換できることが分かった。

ocioconvert --view inputimage inputcolorspace outputimage displayname viewname

例として、以下の条件で ocioconvert を実行した様子を示す。

条件 項目
config ファイル OpenColorIO-Config-ACES で配布されている reference-config-v1.0.0_aces-v1.3_ocio-v2.1.ocio [1]
入力画像の colorspace ACES2065-1
出力画像の display colorspace Rec.1886 Rec.709
view_transform "ACES 1.0 - SDR Video
ocioconvert を実行した様子
export OCIO=/ocio_config_dir/reference-config-v1.0.0_aces-v1.3_ocio-v2.1.ocio  # ocio_config_dir は .ocio を保存したディレクトリ
ocioconvert --view ./src_aces2065-1.exr "ACES2065-1" ./dst_rec.1886-rec.709_aces-1.0-sdr.exr "Rec.1886 Rec.709 - Display" "ACES 1.0 - SDR Video"

4. 詳細

4.1. ocioconvert とは

ocioconvertは OCIO v2 に含まれるツールの1つである。OCIO v2 をソースコードからビルドすると自動で入る。 ocioconvert以外にもociocheckociochecklutなどのツールが存在する。詳細に関しては公式ドキュメントを参照して頂きたい [2]。

4.2. インストール

公式ドキュメントを読んで頑張ってソースコードからビルドする[3]。自分は Ubuntu 22.04 上でビルドした(業界的には RHEL だと思うが)。

4.3. ocioconvert のヘルプを読む

OCIO v2 の公式ドキュメントにはocioconvertコマンドに渡す具体的なパラメータについての記載が無かった。 そのためocioconvertコマンドのヘルプが唯一の手がかりである。

ocioconvert -h を実行した結果を以下に示す。

usage: ocioconvert [options] inputimage inputcolorspace outputimage outputcolorspace
   or: ocioconvert [options] --lut lutfile inputimage outputimage
   or: ocioconvert [options] --view inputimage inputcolorspace outputimage displayname viewname
   or: ocioconvert [options] --invertview inputimage displayname viewname outputimage outputcolorspace


Options:
    --lut                  Convert using a LUT rather than a config file
    --view                 Convert to a (display,view) pair rather than to an output color space
    --invertview           Convert from a (display,view) pair rather than from a color space
    --gpu                  Use GPU color processing instead of CPU (CPU is the default)
    --gpulegacy            Use the legacy (i.e. baked) GPU color processing instead of the CPU one (--gpu is ignored)
    --gpuinfo              Output the OCIO shader program
    --h                    Display the help and exit
    --help                 Display the help and exit
    -v                     Display general information

OpenImageIO or OpenEXR options:
    --float-attribute %L   "name=float" pair defining OIIO float attribute for outputimage
    --int-attribute %L     "name=int" pair defining an int attribute for outputimage
    --string-attribute %L  "name=string" pair defining a string attribute for outputimage

これを読むと、筆者の目的を果たすには --view オプションを使用すれば良さそうである。 また、その際はパラメータとして inputimageoutputimageinputcolorspacedisplaynameviewnameを指定すれば良いことが分かる。

4.4. inputimageoutputimageについて

基本的には OpenEXR のファイル形式を指定しておけば問題ない。 OpenImageIO がインストールされていれば、OpenImageIO がサポートしているファイル形式を扱えるようだが[2] 本記事では確認は割愛する。

4.5. inputcolorspacedisplaynameviewnameについて

inputcolorspacedisplaynameviewnameはそれぞれ config.ocio にて定義されている名称を使う。 例として reference-config-v1.0.0_aces-v1.3_ocio-v2.1.ocio にて記載されている場所のスクリーンショットを以下に示す。

inputcolorspace displayname viewname

4.6. config.ocio の指定について

ocioconvert コマンドでは config.ocio のパスを指定するオプションが存在しない。 そのため config.ocio のパスは環境変数OCIOを用意して事前に指定しておく必要がある[4]。

Linuxbash を動かしている環境であれば、以下のようにexportを使って指定すれば良い。

export OCIO=/ocio_config_dir/config.ocio  # ocio_config_dir は .ocio が存在するディレクトリ

4.7. 実行例

冒頭の結論とは条件を少し変え色変換を行った例を以下に示す。

条件 項目
config ファイル OpenColorIO-Config-ACES で配布されている reference-config-v1.0.0_aces-v1.3_ocio-v2.1.ocio [1]
入力画像の colorspace ACES2065-1
出力画像の display colorspace Rec.2100-PQ - Display
view_transform "Un-tone-mapped
ocioconvert を実行した様子
export OCIO=/ocio_config_dir/reference-config-v1.0.0_aces-v1.3_ocio-v2.1.ocio  # ocio_config_dir は .ocio を保存したディレクトリ
ocioconvert --view ./src_aces2065-1.exr "ACES2065-1" ./dst_rec.2100-pq_un-tone-mapped.exr "Rec.2100-PQ - Display" "Un-tone-mapped"

入力画像と出力画像は以下のようになり、想定通りの変換が行えていることを確認できた。

入力画像 出力画像

5. 感想

ということで ocioconvert の基本的な使い方が分かった。 本当は OpenImageIO を使った OpenEXR 以外のファイルフォーマットも試したかったが、それは別の機会に試そうと思う。

今まで ACES の Output Transform をコマンドラインで適用するには ctlrender を使ってきたが、今後は ocioconvert を積極的に使っていきたいと思う。

参考資料

[1] AcademySoftwareFoundation, "OpenColorIO-Config-ACES 1.0.0", https://github.com/AcademySoftwareFoundation/OpenColorIO-Config-ACES/releases/tag/v1.0.0

[2] OpenColorIO, "Tool overview", https://opencolorio.readthedocs.io/en/latest/guides/using_ocio/tool_overview.html#tool-overview

[3] AcademySoftwareFoundation, "OpenColorIO/installation.rst", https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/main/docs/quick_start/installation.rst

[4] OpenColorIO, "Using OCIO", https://opencolorio.readthedocs.io/en/latest/guides/using_ocio/using_ocio.html

After Effects Beta版で OpenColorIO v2 を使った HDR表示を試す

1. 背景

  • 筆者は映像制作ツールを使った HDR表示に異様に関心があり、これまで複数のツールで HDR表示を試してきた
    • ここで HDR表示とは SMPTE ST 2084 (PQカーブ) をサポートしたデバイスを使った表示を意味する
  • 2022年10月に Adobe は OpenColorIO (以後 OCIO と略す) をサポートした Beta版の After Effects を公開した[1]
    • 筆者が確認したところ OCIO v2 もサポートしていることが分かった
  • 筆者は OCIO v2 の config.ocio を自作 した経験があり、After Effects で OCIO v2 を利用した HDR表示を試したいと考えた
  • そこで実際に試すことにした (※1)

※1 After Effects は現時点では Windows OS 上の HDR表示はサポートしていない。そのため今回は Video I/O の DeckLink Mini Monitor 4K を使い Video Monitor 上で HDR表示を試す

2. おことわり

本記事は OCIO v2 を利用した HDR表示が 技術的に可能かどうか 検証することを目的としています。そのため実際の制作現場での利便性などは一切考慮しておりません。従って本記事を読むと「そんな設定(やり方)は実際はやらないでしょ」と感じるかもしれません。が、その点については何卒ご容赦ください。

また、本記事の検証は After EffectsBeta版 を利用して行いました。あくまでも Beta版を使った動作確認ですので、正式版では仕様が変わっている可能生があります。その点もご了承ください。使用したバージョンは v23.3.0 (Build 18) です。

3. 目的

After Effects 上で OCIO v2 を使った色変換を行い、変換後の映像を HDR対応のデバイスで表示する。合わせて複数の色空間へのファイル出力も試す。具体的には以下の図1 の処理が可能であるかを確認する。

図1. 筆者が期待していた色変換の様子

図1 は以下の処理を想定したものである。

  • 色空間が異なる複数のソースを Input Transform で Working Color Space (ACEScg) に変換する
  • Working Color Space 上でコンポジット(図では Merge と表現)を行う
  • ファイル出力のために Output Transform を行う。以下の 2つの色空間に出力する
    • ACES 2065-1
    • P3D65 - SMPTE ST 2084
  • 画面表示のために Display View Transform を行う。画面表示は以下の2デバイスに対して行う
    • PC Monitor (SDR) (※2)
    • Video Monitor (HDR) (※3)

※2 PC Monitor (SDR) と Video Monitor (HDR) に同じ映像信号を送ることになるため、PC Monitor (SDR) はミスマッチが発生して表示がおかしくなる。今回はこのミスマッチは許容することにする
※3 本記事では SDI や HDMI の入力 I/F を備えた映像確認用のモニターを Video Monitor と呼ぶ。残念ながら筆者の自宅には存在しないので今回は SONY BRAVIA で代用する

また、各機材は図2 の通りに接続するものとする。

図2. 各種機材の接続図

4. 結論

4.1. 結論(3行)

  • 図1 に示した色変換は実現できなかった
  • Video Monitor への出力は Display View Transform が適用されておらず ACEScg のまま出力だった
  • しかし、手動で OCIO Color Space Transformエフェクトを適用することで目的の HDR表示を実現できた

4.2. 結論(詳細)

図1 に示した処理は概ね可能であることは分かった。しかし、Display View Transform に関しては想定と異なることが分かった。結果を図3 に示す。

残念ながら画面表示用の Display View Transform (※4) は PC Monitor にしか適用されなかった。 そのため Video Monitor への出力は ACEScg のままであり表示のミスマッチが生じる結果となった。

図3. 実際の色変換の様子

その一方で追加調査の結果、手動でエフェクトを適用することで表示のミスマッチを解決できることが分かった。図4 に示すように Display View Transform の代わりに OCIO Color Space Transform エフェクト(※5) を使用することで解決できた。これにより、筆者の当初の目的であった HDR表示は無事に達成できた。

図4. Video Monitor での HDR表示のために筆者が処理を追加した様子

※4 Display View Transform は After Effects では Display Color Space として設定する (5.2.5 を参照)。Display View Transform の詳細に関しては OCIO v2 の過去記事 を参照

※5 After Effects の OCIO Color Space Transform は In/Out の Color Space に Display Color Space を指定することができない。そのため Video Monitor に伝送する映像を Display Color Space に変換するには、事前に Display Color Space と同様の変換が行われる Color Space を config.ocio のcolorspacesブロックに事前に記述しておく必要がある

4.3. その他

  • 前回の記事でも実感したが、入出力のファイル形式は OpenEXR にしておくのが無難である
    • 例えば PNG の静止画に対して P3D65 - PQ の Input Transform を適用すると、なぜか 1.0 以上の値はクリップされてしまった
  • DNxHR の動画ファイルは今のところ After Effects では使わない方が良いと考える
    • DNxHR のテストパターン動画を読み込んだところ 64-940 CV の Limited Range のまま Working Color Space に変換されてしまった
    • ProRes や H.265 を使った場合は問題がなかった

5. 詳細

以下で筆者が結論に至るまでに行った作業内容を記す。

5.1. 事前準備

5.1.1. config.ocio

今回は検証用に自作した OCIO v2 の config.ocio を使用した。参考までにファイルのリンクを以下に示す。

drive.google.com

上記ファイルのdisplaysブロックに定義してある色変換の多くは、色域変換の 3x3 Matrix と単純な OETF で構成されている(別の言い方をすると RRT を意図的に消している)。そのため様々な解析が行いやすく筆者は愛用している。

なお、一般的な用途の場合は After Effects に標準で組み込まれている config.ocio の利用を強く推奨する(筆者の作成した config.ocio は検証用なので)。 カスタマイズを行う場合でも Academy Software Foundation からリリースされている config.ocio をベースに改良することを強く推奨する。

github.com

5.1.2. 画像ファイル

今回の検証で筆者は合計7つの動画・静止画ファイルを合成し、ACEScg 空間で図5 に示す画像を作成した。

図5. After Effects で合成した絵(BT.2020 - SMPTE ST 2084 で出力)

合成に使用したファイルは以下に置いてある。

images_for_Ae_rev2.zip - Google ドライブ

上記リンクの中身は以下の通り。

  • 背景として使用したテストパターン動画 (ファイル名: P3D65_ST2084_1920x1080_HEVC.mov)
  • Working Color Space での合成確認のための矩形パッチ6種類。矩形パッチの ACEScg 空間での値は以下の通り
    • (R, G, B) = (0.10, 0.10, 0.10)
    • (R, G, B) = (0.08, 0.08, 0.08)
    • (R, G, B) = (1.00, 1.00, 1.00)
    • (R, G, B) = (9.00, 9.00, 9.00)
    • (R, G, B) = (100, 100, 100)
    • (R, G, B) = (-99, -99, -99)

5.2. After Effects 上で行った作業

5.2.1. OCIO v2 のカラーマネジメント有効化

File --> Project Settings を開き、Colorタブの Color Management と Color Settings の項目を図6 のように変更した。 この設定をすることで OCIO v2 を使ったカラーマネジメントが有効になる。また、Working Color Space が ACEScg となる。

5.2.2. Video Monitor への出力有効化

Edit --> Preferences を開き、図7 に示すように Video Previewタブの Transmit Device Playback にて Blackmagic Playback にチェックを入れ、その後に設定画面を開き DeckLink Mini Monitor 4K を選択した。この設定をすることで DeckLink から Video Monitor へ信号が出力されるようになる。

図6. Project Settings の Colorタブの設定内容 図7. Preferences の Video Previewタブの設定内容

5.2.3. 準備した画像ファイルの色空間の設定

準備した画像ファイルを画面左上の Project パネルにドラッグ&ドロップして読み込ませた。次に各画像ファイル上で右クリックを行い、Interpret Footage --> Main を選択した。 出てくるダイアログで Colorタブを選択し、Override Media Color Space の項目で画像に適した Color Space を選択した。

Color Space は 図8、図9 に示すようにP3D65_ST2084_1920x1080_HEVC.movではInput/P3D65-PQ_ColorSpaceを、それ以外の画像ではACES/ACEScgを選択した。

図8. P3D65_ST2084_1920x1080_HEVC.mov の設定 図9. その他の画像の設定

5.2.4. ACEScg 空間上で準備した画像ファイルを合成

新規 Composition を作成し、先ほど読み込んだ画像ファイルの合成を行った。この作業は OCIO v2 とは関係が薄い箇所なので詳細は省略する。 筆者はごくごく一般的と思われる方法で各種画像を合成した(結果は図5 を参照)

なお、Composition Settings の内容は図10 の通りである。フレームレートは諸事情により 29.97 fps とした(解析用にHDMIキャプチャデバイスと接続したため)

図10. Composition Settings の様子

5.2.5. 外部ファイル出力

今回は図1 に示したように 2種類の色空間へのファイル出力を試した (ACES 2065-1P3D65 - SMPTE ST 2084)。手順を以下に示す。

まず、メニューバーから Composition --> Add to Render Queue を選択し、Render Queue への追加を行った(2回行って2個追加した)。

1つ目に追加したアイテムの Output Module を選択し Output Module Settings ダイアログを表示した。 Output Module Settings の Color タブで Displays/HDR/P3D65-PQ を選択した (図11)。

2つ目に追加したアイテムの Output Module を選択し Output Module Settings ダイアログを表示した。 Output Module Settings の Color タブで ACES/ACES2065-1 を選択した (図12)。

ファイル形式はそれぞれ QuickTime (ProRes 422HQ)、OpenEXR Sequence とした (図13)。

その後に Render ボタンを押下してファイル出力を行った。ファイル出力に関しては期待通りの結果であった。

図11. 出力の色空間としてDisplays/HDR/P3D65-PQを選択した様子 図12. 出力の色空間としてACES/ACES2065-1を選択した様子 図13. Render Queue の様子

5.2.6. PC Monitor と Video Monitor への表示

ここではモニター出力用の色変換処理について述べる。

OCIO を有効にした After Effects では Composition パネルの下部にある Display Color Space メニューからモニターの表示に適用したい Color Space を選択する。 今回は BT.2020 - SMPTE ST 2084 の出力を行うため、図14 に示すように BT.2100-PQ/Simple を選択した。

図14. Composition パネル下部のメニューから表示用の Color Space を選択している様子

さて、ここで1つ問題が発生した。PC Monitor に対しては意図通りの変換が働いたのだが、Video Monitor に対しては意図通りの変換が働かなった。 表示の様子を図15、図16 に示す。

図15. PC Monitor の表示 図16. Video Monitor の表示

以降で、この問題の対応策について述べる。

5.2.7. Video Monitor に表示されている信号の解析

Video Monitor への出力信号について調べたところ以下の3点が分かった。

  • OETF が適用されていない Linear となっている
  • Composition パネルの Display Color Space メニューで Color Space を BT2100-PQ/Simple ⇔ BT709-BT1886/Simple と切り替えても Video Monitor 側の映像には変化がない
  • 現在の破綻している映像に対して ACEScg to BT2100-PQ 変換を行うと、PC Monitor の映像に近くなる (図17、図18)
図17. 破綻している映像に ACEScg to BT2100-PQ 変換を行った結果 図18. PC Monitor の表示 (比較用に図13 を再掲)

以上のことから、筆者は Video Monitor には Working Color Space (ACEScg) のデータがそのまま伝送されていると判断した。 冒頭の図3 はそれを示した物である。

状況整理のために 図1 と 図3 の内容を切り取って再掲する(図19、図20)。筆者は図19 の動作を期待していたが、実際は図20 に書いた通りであり Display View Transform は PC Monitor出力にしか適用されなかった。

図19. 期待していた動作 図20. 実際の動作

5.2.8. Video Monitor の表示の改善

このままでは当初の目的であった HDR表示が試せなくなってしまうため、筆者は問題を解決すべく調査を行った。

After Effects の公式ドキュメントを読んでいたところ以下の記述が目に入った[2]。

Note:

To manage colors in a dynamically linked composition or for video previews, create a new composition and nest your composition within it; then apply the Color Profile Converter effect to the nested composition, with Input Profile set to Project Working Space. For video previews, then set the Output Profile to match the color space of the video preview device.

筆者は上記の内容を参考にOCIO Color Space Transformエフェクトを使って Working Color Space から Display Color Space への変換を強制的に行えば良いと考えた。ということで以下の作業を行った。

  • 新規に Compositionを作成 (名前を to_video_monitor とする)
  • これまでの作成した Composition を to_video_monitor にネストする形で入れる
  • Display View Transform を無効化するために Display Color Space メニューで None を指定 (図21)
  • ネストしれ入れた Composition に OCIO Color Space Transformエフェクトを適用 (図22)
    • Input Color Space: ACES/ACEScg
    • Output Color Space: Displays/HDR/BT2100-PQ (※6)

※6 本当は Display Color Space のリストに存在する BT2100-PQ/Simple を選択したかったが、残念ながら Output Color Space として選択することは不可能だった。そのため今回は同様の変換が行われる Color Space を事前に config.ocio のcolorspacesブロックに記述して参照した。

図21. Display Color Space で'None'を指定した様子 図22. OCIO Color Space Transform の設定

この設定を行うことで以下の図23 の通り、意図通りの変換を Video Monitor 出力に適用することができた。

図23. OCIO Color Space Transformエフェクト適用後の Video Monitor の表示 図24. PC Monitor の表示 (比較用に図13 を再掲)

6. 感想

今回の調査を通じて OCIO v2 は本当に便利だと改めて実感した。After Effects は色変換部分を完全に OCIO v2 に任せることができたので、 前回の記事のようにツール内部の自動変換に苦しめられることが無かった。OCIO v2 バンザイ!

OCIO v2 が楽しすぎたので次の記事は OCIO v2 の config.ocio の改良について書くかもしれない。その一方でそろそろ論文を読んで何かを実装する系の記事も書きたいと考えている。 いずれにせよ定期的に記事を書いていきたい。

7. 参考資料

[1] Adobe Help Center, "OpenColorIO and ACES color management (Beta)", https://helpx.adobe.com/after-effects/using/opencolorio-aces-color-management.html

[2] Adobe Help Center, "Managing color in After Effects", https://helpx.adobe.com/after-effects/using/color-management.html

OpenColorIO を利用して Photoshop や Affinity Photo 2 で静止画の HDR表示(HDR10) を試したが失敗に終わった

1. 背景

  • 2022年12月に Adobe Camera Raw が HDR Output に対応し、Windows および macOS で 静止画の HDR表示が可能になった[1]
    • ただし Technology Preview のため正式な機能ではない
  • 加えて PhotoshopHDR表示に対応した[1]。(ただし macOS のみの対応で Windows は非対応)
  • 筆者は Photoshop を使った HDR表示を試したかったのだが、残念なことに自宅に macOS のマシンが無かった
  • 悔しかったので Windows マシンで OpenColorIO (以後 OCIO と略す) を使った 静止画の HDR表示を試すことにした

2. 目的

以下の制作ツール上で OCIO を使った色変換を行い Windows 環境で静止画の HDR表示を試す。

  • Photoshop
  • Affinity Photo 2 (※1)
  • Krita (※1)

具体的には以下の図0 の処理を上記ツールで行う。Input Transform, Output Transform は OCIO を使って行い、Color Correct の処理は上記のツールで行う。

図0. 今回の検証環境における色処理と OCIO の関係

※1 これらのツールは OCIO を使わずとも標準で HDR10 の表示をサポートしているが、今回はその確認は行わない

3. 結論

図0 に示す処理内容で HDR表示をすることは非常に困難ということが分かった。残念ながらどの制作ツールでも意図通りの表示はできなかった。

今回の検証で得られた教訓は以下の通りである。

  • 全ての色変換処理を OCIO のみで完結させるのは困難
    • どこかの工程で制作ツール側の色変換処理が適用されてしまい想定通りの結果が得られなかった
  • 画像ファイルには OpenEXR など 32-bit の float 型で保存できるフォーマットを使うべき
    • 最初、筆者は 16-bit int型のファイルを使って検証していたが、失敗が続く結果となった
    • 制作ツール内部で 16-bit int --> 32-bit float に変換すると、制作ツール内部で自動的に EOTF が適用されてしまった (※2, ※3)
    • OCIO のみで色変換処理を完結させるためには、この EOTF をキャンセル必要がある
  • その一方で残念ながら 32-bit float 型の画像ファイルを使っても、ツール内部で自動的に OETF が適用される傾向にあった (※2, ※3)
    • 表示デバイスへの出力用に Linear to Non-linear の OETF が自動的に適用されてしまう
    • OCIO のみで色変換処理を完結させるためには、この OETF をキャンセルする必要がある

※2 ツール側で自動的に EOTF/OETF を適用するのは、一般的な色処理のフローを考えると理に適っている。今回は筆者が無理矢理に OCIO を使ったリニアワークフローおよび HDR表示を試そうとしたため不都合が生じた
※3 筆者の推測する、制作ツール内部での Non-Linear to Linear (EOTF) と Linear to Non-Linear (OETF) 変換の様子を図1 に示す。

図1. 制作ツール内部で EOTF/OETF が適用される様子(筆者の推測

4. 詳細

4.1. ツールのバージョン

使用したツールのバージョンは以下の通りである。

ツール名 バージョン 備考
Photoshop v24.1.0 プラグインとして OpenColorIO for Photoshop v2.1.1 も利用
Affinity Photo 2 v2.0.3
Krita v5.1.4

なお、OS に関しては Windows 11 Pro 22H2 OS build 22621.1105 を使用した。

4.2. 事前準備

検証を行うにあたり以下3点の事前準備を行った。それぞれ詳細を述べる。

  • OCIO の config ファイル
  • 確認用のテストパターン
  • Windows OS の Color Management

4.2.1. OCIO の config ファイル

今回の検証用に以下のリンクの config_v1.ocio を作成した。これは筆者オリジナルの config ファイルである。

drive.google.com

記載内容は必要最小限になっており、以下の Colorspace しか定義していない。

  • ACES - ACES2065-1
  • BT.709 - Gamma 2.4
  • BT.2020 - SMPTE ST2084
  • P3D65 - SMPTE ST2084

また、内部処理は全て Display referred で行っている (RRT は存在しない)。本来は ACES2065-1 を Scene referred として扱うべきなのだが、 Scene referred と Display referred の変換を config.ocio に記述するのが面倒だったので省略した。ご容赦頂きたい。

また、本記事では OCIO の色変換に関して以下の用語を定義して使用することとした。

  • Input Transform: Non-linear 空間から ACES - ACES2065-1 への変換
  • Output Transform: ACES - ACES2065-1 から Non-linear 空間への変換

4.2.2. 確認用のテストパターン

筆者が日常的に使っている P3D65 - SMPTE ST 2084 のテストパターンを使用した。 名前から分かるように以下の特性を持ったテストパターンである。

  • Gamut: BT.2020
  • Transfer Characteristic: SMPTE ST 2084
  • White point: D65

16-bit int型のテストパターン P3D65_ST2084_1920x1080.png は以下のリンクからダウンロードできる。

drive.google.com

加えて、上記の画像データを 32-bit の float型 (OpenEXR形式) に変換した P3D65_ST2084_1920x1080.exr も準備した。 こちらも以下のリンクからダウンロードできる。これらのファイルは再配布さえしなければ自由に使って貰って構わない。

drive.google.com

32-bit float型のファイルを用意した理由は 16-bit int型だと OCIO の変換を行う際に不都合があったからである。 具体的な内容は 4.3.3. および 4.4.2. を参照。

なお、大変ややこしいが P3D65_ST2084_1920x1080.exr の Transfer Characteristic は SMPTE ST 2084 である。 .exr ファイルではあるが Non-linear であることに注意して頂きたい。

4.2.3. Windows OS の Color Management

図2 の通りに sRGB IEC61966-2.1 を指定した。目的は各種ツールの色変換機能が働くリスクを最小にすることである。

筆者は以下の3つのプロファイルを全て sRGB IEC61966-2.1 に設定すればツール上の色変換が無効化できると考え、準備の1つとして図2 の設定を行った。

  • 画像のプロファイル
  • 作業スペースのプロファイル
  • ディスプレイのプロファイル

図2. Display Profile を sRGB とした様子

4.3. Photoshop

ここから各種ツールでの検証内容を述べていく。 まずは Adobe Photoshop の検証内容を報告する。

なお、冒頭で述べたとおり PhotoshopWindows版では HDR表示には非対応である。 従って Windows OS側の HDR設定を On にした場合の HDR表示は不可能である。 しかし筆者は WindowsHDR設定 が Off の状態でも強引な手を使えば HDR表示は可能であると考えていたため試すことにした。

4.3.1. 事前準備

Color Settings

メニューの Edit --> Color Settings の内容は図3 のようにした。RGB の Working Space を Monitor RGB -sRGB IEC61966-2.1 にした。 これは Photoshop 側で OCIO 以外の色変換が働くリスクを下げるためである。

図3. Color Settings の内容

OCIO

Photoshop は標準では OpenColorIO をサポートしていないため、fnord software blog にて公開されていたプラグイン[2] を導入した。 Photoshop において OpenColorIO のプラグインを利用して図0 の色処理を行うためには、事前に LUT を作成する必要がある。そのため以下の作業を行った。

  • Photoshopプラグイン用フォルダにプラグインのファイル一式を置く
  • Photoshop のメニューバーから「Filter --> OpenColorIO --> OpenColorIO」を選択する
  • ③ 図4 を参考に以下の設定を行う
    • Configuration に config_v1.ocio を指定
    • ラジオボタンで Convert を選択
    • プルダウンメニューの Input Space と Output Space をそれぞれ P3D65 - SMPTE ST2084ACES - ACES2065-1 とする
    • Export を押下し P3D65_ST2084_to_ACES2065-1.cube として保存
    • Cancel を押下してウィンドウを閉じる
  • Photoshop のメニューバーから「Filter --> OpenColorIO --> OpenColorIO」を選択する
  • ⑤ 図5 を参考に以下の設定を行う
    • Configuration に config_v1.ocio を指定
    • ラジオボタンで Convert を選択
    • プルダウンメニューの Input Space と Output Space をそれぞれ ACES - ACES2065-1BT.2020 - SMPTE ST2084 とする
    • Export を押下し ACES2065-1_to_BT2020_ST2084.cube として保存
    • Cancel を押下してウィンドウを閉じる
図4. Input Transform の設定 図5. Output Transform の設定

4.3.2. OCIO を用いた HDR 表示の検証を実施

事前準備が終わったので、いよいよ OCIO を使った色変換を試していく。

ファイルを開く
  • P3D65_ST2084_1920x1080.png を開く
  • メニューから Image --> Mode --> 32 Bits/Channel を選択
Input Transform、Output Transform、Color Correct を Layer として追加する
  • メニューから Layer --> New Adjustment Layer --> Color Lookup を選択
  • 名前を Input Transform に設定
  • Load 3D LUT のプルダウンメニューから Load 3D LUT を選択し、事前準備で作成した P3D65_ST2084_to_ACES2065-1.cube を選択


  • メニューから Layer --> New Adjustment Layer --> Color Lookup を選択
  • 名前を Output Transform に設定
  • Load 3D LUT のプルダウンメニューから Load 3D LUT を選択し、事前準備で作成した ACES2065-1_to_BT2020_ST2084.cube を選択


  • メニューから Layer --> New --> Layer を選択
  • 名前を Color Correct に設定
  • Color Correct Layer を Input Transform と Output Transform の間に配置 (図6)

図6. 各Layer を準備した様子

ブラシツールで何か書いてみる
  • Color Picker (Foreground Color, 32-bit) のウィンドウで (R, G, B) = (0.18, 0.18, 0.18) を指定 (図7 参照)
  • ブラシツールで何か描画する
  • Color Picker (Foreground Color, 32-bit) のウィンドウで (R, G, B) = (10.0, 10.0, 10.0) を指定 (図8 参照)
  • ブラシツールで何か描画する
図7. Color Picker で 0.18 を指定 図8. Color Picker で 10.0 を指定
保存する
  • メニューから File --> Export --> Export As を選択して保存する
    • Export As ダイアログボックスの Color Space の Convert to sRGBEmbed Color Profile のチェックは外す(図9)参照

図9. Export 時の Color Space 設定

4.3.3. 結果と考察

結果

Photoshop にて OCIO を利用した HDR画像の表示、および編集後の画像の保存結果は以下となった。見て分かるとおり大失敗である。

図10. モニターで見る画像の様子 図11. 保存した画像の様子
考察

筆者は失敗の原因は 2つあると考えている。

  • Photoshop 内部で 16-bit int型から 32-bit float型への変換を行った
  • ② Output Transform を 3DLUT で行った

① に関して言うと、筆者は Photoshop が float で画像処理を行うように、メニューから Image --> Mode --> 32 Bits/Channel の設定を行った。 色々と観察して分かったが、どうやらこの操作により (おそらく sRGB の) EOTF/OETF が適用されて全体の色変換に破綻が発生するようである。

若干の推測が入るが、Photoshop側の処理も含めた今回の色処理の全体像を図12 に示す。

図12. Photoshop側の処理も含めた色変換の様子(一部は想像)

それでは、最初から 32 bit のファイル (例えば OpenEXR形式) を使えばどうなるだろうか。もしかすると成功するかもしれないと考え、筆者は試してみた。 しかしこれもイマイチだった。sRGB の EOTF らしきものは回避できたが、sRGB の OETF らしきものが自動で適用されるため思ったような表示が出来なかった。

更に確認を続けたところ、メニューの View --> Proof Colors にて Monitor RGB を設定すれば、Photoshop側で自動的に適用される EOTF/OETF を無効化することができた。 が、後述の②の問題があるため、結局のところ想定通りの色変換はできなかった。

② に関しては冷静に考えれば当然の結果であった。Linear空間から任意の空間へのマッピングに 3DLUT を使う際は Shaper と呼ばれる 1DLUT も併用しないと暗部の変換精度が著しく落ちてしまう。

trev16.hatenablog.com

今回は Shaper を使っていなかったため暗部が黒つぶれする結果となってしまった。 なお、Photoshop で 1DLUT を Adjustment Layer として追加できるかは調べてみたが分からなかった…。

4.3.4. 総評

Photoshop にて OCIO を利用した HDR の表示は難しいことが分かった。OCIO を使って 32-bit の Linear 空間で作業をする場合は、Photoshop側が自動で適用する EOTF/OETF の影響を考慮する必要がある。

4.4. Affinity Photo 2

次に Affinity Photo 2 の検証内容を報告する。

Affinity Photo は Photoshopとは異なり 1.0 を超える HDRレンジの信号を表示できる[3]。そのためには 32-bit Preview panel にて Enable HDR を有効にすればよい。

しかし、いきなり Enable HDR を有効にするのではなく、まずは OCIO が想定通りに動作するか確認するため、最初は Enable HDR は無効化して検証を行った。

4.4.1. 事前準備

  • メニューから Window --> 32-bit Preview を選択して 32-bit Preview panel を表示する
  • メニューから Edit --> Preferences --> Color --> Select を選択し config_v1.ocio を指定する (図13参照)
  • その他の項目は図13 の通りにしておく

図13. Affinity Photo 2 の Color設定

4.4.2. OCIO を用いた色変換の確認 (Enable HDR Off) (1回目)

事前準備ができたので、早速 OCIO の動作確認を行う。なお1回目と書いてあることから推測できると思うが、後ほど2回目も行う。

筆者は以下の操作を行った。

  • P3D65_ST2084_1920x1080.png を開く
  • 32-bit float型に変換するためにメニューから Document --> Convert Format / ICC Profile を選択し以下の通りに設定
    • Format: RGB/32 (HDR)
    • Profile: sRGB IEC61966-2.1 (Linear)

と、ここまで行って筆者は 16-bit int型から 32-bit float 型への変換の際に sRGB の EOTF が画像に適用されることに気づいた。 なぜならば Profile として sRGB IEC61966-2.1 (Linear) を指定することになるからである (なお色変換が働かないようにプロファイルを選択することは不可能だった)。

このまま検証を進めると Photoshop の時と同じように失敗することは確実である。 そのため、この段階で 16-bit int型の画像ファイルを使うことは断念し、以後は入力画像として 32-bit float型の OpenEXR の画像ファイルを使う事にした。

4.4.3. OCIO を用いた色変換の確認 (Enable HDR Off) (2回目)

画像を開く
  • P3D65_ST2084_1920x1080.exr を開く
  • 32-bit Preview パネルにて Display Transform を Unmanaged に設定 (図14)

図14. 32-bit Preview の設定

OCIO を適用
  • Input Transform を用意
    • メニューから Layer --> New Adjustment Layer --> OCIO を選択
    • Source Color Space と Destination Color Space にそれぞれ P3D65 - SMPTE ST2084ACES - ACES2065-1 を設定 (図15)
    • Layer の名前を Input Transform にしておく
  • Output Transform を用意
    • メニューから Layer --> New Adjustment Layer --> OCIO を選択
    • Source Color Space と Destination Color Space にそれぞれ ACES - ACES2065-1BT.2020 - SMPTE ST2084 を設定 (図16)
    • Layer の名前を Output Transform にしておく
  • Layer の順番を 図17 のように整理しておく
図15. Input Transform の設定 図16. Output Transform の設定 図17. Layer の順序
ブラシツールで何か書いてみる
  • メニューから Layer --> New Layer を選択
  • Layer を Input Transform と Output Transform の間に置く
  • Color Chooser のウィンドウで (R, G, B) = (0.18, 0.18, 0.18) を指定 (図18 参照)
  • ブラシツールで何か描画する
  • Color Chooser のウィンドウで (R, G, B) = (10.0, 10.0, 10.0) を指定 (図19 参照)
  • ブラシツールで何か描画する
図18. 0.18 の色を指定 図19. 10 の色を指定
保存
  • メニューから File --> Export を選択
  • ファイル形式を EXR にして Export を実行 (図20 参照)

図20. Export の設定

結果

Affinity Photo 2 での画面表示の見た目および Exportしたファイルの見た目をそれぞれ図21、図22に示す。

想定通りの変換になっていることが分かる。0.18 と 10.0 の文字はそれぞれ 10-bit で 356 CV、769 CV となっており理論値と一致している。

図21. Affinity Photo2 上での見た目 図22. Export した結果

4.4.4. OCIO を用いた色変換の確認 (Enable HDR On)

OCIO の動作確認が済んだので、いよいよ Enable HDR を有効にして HDR10 の表示を試す。

手順

殆どの手順は先ほどの Enable HDR Off の時と同じである。差分は以下の2点のみ。

  • ① 事前に Windows の System --> Display --> Use HDR の設定を On にしておく
  • P3D65_ST2084_1920x1080.exr を開いた直後に 32-bit Preview パネルにて Enable HDR にチェックを入れる (図23)

図23. Enable HDR を有効にした様子

結果

Affinity Photo 2 にて OCIO を利用した HDR画像の表示を行った結果、および編集後の画像の保存結果は以下となった。

図24. HDRモニターに表示した様子 図25. 保存したファイルの様子

図24 を見ると分かるとおり異常に黒浮きしている。これはHDRの画像を SDRモニター向けに変換したからではなく、ST2084 をサポートしたモニターや TV で見ても黒浮きして表示された。その一方で Export した OpenEXR ファイルは想定通りの表示となった。

4.4.5. 考察

Photoshop の時と比較すると良い結果となった。ただ残念ながら HDR対応モニターや HDR対応TV で想定通りの表示を実現することは出来なかった。

色々と追加検証を行った結果、筆者は Affinity Photo 2 にて Enable HDR を有効にした場合は、以下の図26 のように Output Transform 後に意図しない SMPTE ST2084 の OETF が適用されると推測している。この OETF さえ無効化できれば OCIO を利用した静止画のHDR表示は行えそうなのだが、残念ながら無効化の方法は見つからなかった。

図26. Affinity Photo 2 で Enable HDR を有効にした場合の内部処理の推測

4.5. Krita

最後に Krita の結果を示す。

Krita に関してはそもそも OpenColorIO を使った色変換が想定通りに働かなかった。そのため細かい内容の記述は行わないでおく。

原因についても残念ながら何も推測できなかった。 例えば 図27 のように Input ColorSpace と View に同じ設定を行った場合、筆者は何も変換が行われないと想定していたのだが、なぜか変換が働いてしまった。 謎である。

図27. Krita での OpenColorIO の設定(スルー出力想定)

Krita に関しては「失敗した」という結果だけ記しておく。

5. 感想

完全に思いつきで始めた作業だったこともあり、残念ながら良い結果を出すことができなかった。 ただ、こういう作業は個人的には大好きなので没頭して作業することができた(その結果、自分が行うべき勉強をサボり続けることになったが…)。

次は After Effects で同様のことを調査してみたいと考えている。最近 OCIO に対応したようなので。

6. 参考資料

[1] Adobe, "HDR Output (Technology Preview)", https://helpx.adobe.com/camera-raw/using/hdr-output.html

[2] fnord software blog, "OpenColorIO for Photoshop", http://fnordware.blogspot.com/2017/02/opencolorio-for-photoshop.html

[3] Affinity Photo 2 Help, "32-bit Preview panel", https://affinity.help/photo2/en-US.lproj/index.html?page=pages/HDR/hdr_editing.html?title=32-bit%20HDR%20editing