背景

前回の記事で筆者は Color Space Transform エフェクトの OOTF オプションについて調べた

trev16.hatenablog.com

上記の記事で筆者は「Forward OOTF / Inverse OOTF は SDR でのみ設定可能」と述べたが、実は ARRI LogC4 などの Camera Log *1 *2 を使った場合は設定可能ということが分かった *3
Camera Log を使った場合の OOTF がどうなるか気になったので、軽く調べることにした
- なお、今回は映画制作を模倣（？）して ARRI Wide Gamut 4 - LogC4 to P3D65 - Gamma 2.6 の変換で確認した

図1. Camera Log を指定した場合は OOTF のチェックボックスが有効となる様子

目的

Davinci Resolve *4 の Color Space Transform エフェクトで Camera Log を使った場合の OOTF の特性を調べる
それだけだと物足りないので、ついでに Color Space Transform エフェクトを模倣した DCTL を作って遊ぶ
- ただし、全ての機能を模倣するのは不可能なので、色域変換、ガンマカーブ変換、OOTF適用の 3機能だけ模倣する

結論

Camera Log を使った場合でも OOTF の特性は前記事と同じであった
- Report ITU-R BT.2390-12 の 3.1節「3.1 HDTV as specified in Recommendations ITU-R BT.709 and BT.1886」に掲載されているものと同じであった
ただし、処理の流れが少し分かりづらかったのでブロック図としてまとめた（図2）
- OOTF は LogC4 から変換した Linear値に対して適用された
- 加えて Forward OOTF か Inverse OOTF かによって色域変換と OOTF の順序が逆転することも分かった

図2. 筆者が理解した Color Space Transform エフェクトの内部処理ブロック

それから Color Space Transform エフェクトの処理を模倣した DCTL の作成にも成功した
- Effects -> Generators -> Four Color Gradient のテストパターンに対して Color Space Transform エフェクトと DCTL をそれぞれ適用している様子を以下に示す


図3. Color Space Transform を適用した様子	図4. 自作の DCTL を適用した様子

おそらく誰も興味ないと思うが、せっかく作ったので DCTL は以下で公開しておく
- ARRI_LogC4_to_P3D65_Gamma2.6.dctl · GitHub
念のため、プロジェクトファイルのアーカイブも以下で公開しておく
- OOTF2.dra.zip - Google ドライブ

詳細

ここでは結論に至るまでに筆者が行った作業内容を以下の順に述べていく。

作業環境について
Grey Scale パターンを使った OOTF の特性調査について
Four Color Gradient パターンを使った色域変換と OOTF の処理順序の調査について
負の値に対する Gamma 計算について

作業環境について

まず DaVinci Resolve Studio のバージョンは 20.2.2 を使用した。

プロジェクトの Color Management は下図のように DaVinci YRGB とし、DaVinci Resolve 側で余計な変換が働かないようにした*5。

図5. Color Management 設定の Color science を DaVinci YRGB にした様子

また、Color Space Transform エフェクトは Tone Mapping Method および Gamut Mapping Method を None に設定し、余計な変換が働かないようにした。

図6. Tone Mapping Method と Gamut Mapping Method を None に設定した様子

Grey Scale パターンを使った OOTF の特性調査について

筆者はまず前回の記事と同様に Gray Scale を使い OOTF の特性を調査した。Gray Scale は無彩色であり、ARRI Wide Gamut 4 to P3D65 変換の影響を受けないので、OOTF の特性のみを観測することが可能であった。

前回の記事と同様に、Resolve の変換結果と Report ITU-R BT.2390-12 を参考に実装した処理結果をプロットし、筆者の推測が合っているかを確認した。結果を以下の図7、図8 に示す。


図7. ARRI Wide Gamut 4 - Log C4 to P3D65 - Gamma 2.6 変換	図8. P3D65 - Gamma 2.6 to ARRI Wide Gamut 4 - Log C4 変換

Resolve の処理結果と筆者の Pythonシミュレーション結果がピッタリと一致した。そのため筆者は OOTF の特性は前回の記事と同じだと判断した。

Four Color Gradient パターンを使った色域変換と OOTF の処理順序の調査について

OOTF の特性解析が完了したので、次は Color Space Transform エフェクトの色域変換・ガンマ変換・OOTF の特性を模倣した DCTL のコードを書いた。

この際に筆者が気になったのは「色域変換」と「OOTF」の処理順序である。OOTF は非線形な処理であるため処理順序が重要となってくる。これに関しては公式ドキュメントが無いので色々と処理順序を変えてみて Color Space Transform エフェクトと同一の結果が得られる処理順序を探索した。

その結果、結論欄の図2 の知見が得られた。

図2（再掲）. 筆者が理解した Color Space Transform エフェクトの内部処理ブロック

なお、検証の際に使用した Effects -> Generators -> Four Color Gradient のテストパターンは、そのままだとオーバーフローが多発したので、前処理として下図のように Fusion ページで 0.41 の Gain を適用した。

負の値に対する Gamma 計算について

筆者の書いた DCTL のコードは最初、Color Space Transform エフェクトの結果と一致しなかった。筆者の DCTL の実装は一部の色が黒色に変わってしまっていた。

筆者は「おそらくべき乗計算で Nan が生じているのだろうなぁ」と推測した。そこでべき乗計算で Nan が生じないようにすることを試みた。

参考にしたのは Report ITU-R BT.2380-2 の scRGB の計算式および colour-science の spow である。

scRGB を例に説明する。scRGB では入力が負の値であっても絶対値を取ることでべき乗計算を可能としている。

これをプロットすると以下となる。

数式を見れば分かるように、べき乗計算は絶対値に対して行い、その後に符号を与える処理となっている。今回はこの考え方を DCTL の計算に使用した。具体的には DCTL の標準関数_powfを使わずに、筆者が定義した_my_powfを使うことにした。

my_powfの定義は以下である。

__DEVICE__ inline float sign(float x)
{
    if (x == 0.0f) return 0;
    return signbit(x) ? -1 : 1;
}

__DEVICE__ inline float _my_powf(float v, float g) {
    return sign(v) * _powf(_fabs(v), g);
}