1. 目的
- OpenColorIO(以後、OCIOと表記する) の Config ファイルを作成する
- ファイル作成で個人的に苦労した点をメモとして残す
2. 背景
- OCIO の名前は数年前から目にしており何となく気になっていた
- Nuke で HDRの勉強をする際に Nuke標準の Color Management だと ST2084 での HDR表示がやりにくかった
- 個人的に ACES の Config から RRT(※) のみを除外した環境が欲しかった
- ACES の Config は強制的に RRT が掛かるため基礎的な勉強をするのに都合が悪かった
- カスタムした OCIO の Config を作成すれば上記の問題が解決できると考えた
※ ACES および RRT に関する説明はFilmLightさんの資料[1] がとても分かりやすいです。
3. 結論
筆者オリジナルの OCIO Config ファイル(以後、config.ocio と表記する)の作成に成功
- 現時点での config.ocio ファイルはココに置いた
- Nuke での簡易動作確認が完了した
- ACES の RRT を経由しない ST2084 の出力が簡単にできるようになった
config.ocio の作成で個人的に苦労した点
- config.ocio の文法理解に時間がかかった。最初は何を書けば良いかサッパリだった。
- FileTransform で使用する spi1d データの中身。1.0 が Reference White だという認識が無かった。
Nukeでの動作例は以下(図1)。図中の数字が示す内容は以下の通り。
- ① カスタムした config.ocio の読み込み
- ② Read1 の dpx ファイルの Color Space を指定
- ③ ディスプレイ出力の Color Space を指定
4. OpenColorIO について
OpenColorIO は名前の通り、各種 Color Space の Input/Output 変換を行うツールである。基本的な考え方は一般的なカラーマネージメントシステムと同じである。図2に示す通り任意の Colo Space のデータを Reference Color Space を経由することで任意の Color Space に変換して出力できる。
5. config.ocio に記述する内容について
config.ocio に記述する内容について簡単に解説する。ここでは config.ocio を4領域に分割して解説する。より詳しい解説は公式ドキュメントを参照すること。
5.1. 冒頭(ここでは Header と呼ぶ) 部分
Header部分の例を以下に示す。
ocio_profile_version: 1 search_path: luts strictparsing: true luma: [0.2126, 0.7152, 0.0722]
config.ocio の冒頭には上記の情報を記載する。
search_path
には FileTransform で使用するLUTのディレクトリパスを指定する。config.ocio に対する相対パスとして指定する。
strictparsing
は未知のファイルフォーマットが来た時に、次の 5.2.で説明する role
の default
設定を使用するか否かの判断で使用する。詳細は公式ドキュメント参照。
luma
は適当に BT.709 の係数を書いておけば良い。実際は使われない(はず)。
5.2. role 部分
role 部分の例を以下に示す。
roles: color_picking: gamut_BT.709 - eotf_Gamma 2.4 color_timing: gamut_ALEXA Wide Gamut - eotf_ARRI LOG_C compositing_log: gamut_ALEXA Wide Gamut - eotf_ARRI LOG_C data: raw default: raw matte_paint: raw reference: raw scene_linear: raw texture_paint: raw
ここで用途に応じた Color Space を指定する。特に重要なのは reference
である。これが図2の Reference Color Space に該当する。今回は ACES2065-1
を reference
とし、 raw
という Color Space 名称で扱うことにした(aces_1.0.3 の config.ocio を参考にした)。
default
は未知のファイルフォーマットが来た際に、strictparsing
が false
だった場合に適用される Color Space である。今回は strictparsing
を true
としたので使われることは無い(はず)。
5.3. displays 部分
displays 部分の例を以下に示す。
displays: default: - !<View> {name: raw, colorspace: raw} - !<View> {name: gamut_sRGB - eotf_sRGB, colorspace: gamut_sRGB - eotf_sRGB} - !<View> {name: gamut_BT.709 - eotf_Gamma 2.4, colorspace: gamut_BT.709 - eotf_Gamma 2.4} - !<View> {name: gamut_BT.2020 - eotf_Gamma 2.4, colorspace: gamut_BT.2020 - eotf_Gamma 2.4} - !<View> {name: gamut_BT.2020 - eotf_SMPTE ST2084, colorspace: gamut_BT.2020 - eotf_SMPTE ST2084} - !<View> {name: gamut_DCI-P3 - eotf_SMPTE ST2084, colorspace: gamut_DCI-P3 - eotf_SMPTE ST2084} active_displays: [default] active_views: [gamut_BT.709 - eotf_Gamma 2.4]
Nuke だと Viewer での表示設定に該当する。<View>
タグで表示名(name) と対応する Color Space(colorspace) の紐づけを行う。今回は name の名称を考えるのが面倒だったので Color Space と全く同じにした。ここで設定した項目が Nuke の ViewerProcess でプルダウンメニューに表示される。実例は図1の③を参照。
5.4. colorspaces 部分
colorspaces 部分の例を以下に示す。全てを貼ると長くなるため、今回は BT.709色域、Gamma2.4 の Color Space の記述例のみを貼り付ける。
- !<ColorSpace> name: gamut_BT.709 - eotf_Gamma 2.4 family: "" equalitygroup: "" bitdepth: 32f description: | gamut: BT.709, gamma: 2.4 isdata: false allocation: uniform allocationvars: [0, 1] to_reference: !<GroupTransform> children: - !<FileTransform> {src: Gamma_2.4_to_Linear.spi1d, interpolation: linear} - !<MatrixTransform> {matrix: [0.439576, 0.383913, 0.176512, 0, 0.0896004, 0.814714, 0.0956855, 0, 0.0174155, 0.108734, 0.87385, 0, 0, 0, 0, 1]} from_reference: !<GroupTransform> children: - !<MatrixTransform> {matrix: [2.52193, -1.13702, -0.384911, 0, -0.275479, 1.36983, -0.0943495, 0, -0.0159829, -0.147789, 1.16377, 0, 0, 0, 0, 1]} - !<FileTransform> {src: Gamma_2.4_to_Linear.spi1d, interpolation: linear, direction: inverse}
ここでは文字通り Color Space の記述を行う。大事な箇所は to_reference
と from_reference
である。ここに Reference Color Space との変換方法を記述する。
まずは to_reference
に着目する。ここでは GroupTransform の形で以下の2種類の変換が行われる。
- Gamma Correction された non-linear データを 1DLUT を使って linear データへ変換(EOTFの適用と同義)
- Gamut および White Point を BT.709-D65 --> ACES_AP0-D60 に Matrix を使って変換
次に from_reference
に着目する。同様に2種類の変換が行われる。
- Gamut および White Point を ACES_AP0-D60 --> BT.709-D65 に Matrix を使って変換
- linear データを 1DLUT を使って non-linear データへ変換(OETFの適用と同義)
ここで注意して欲しいのは以下2点である。理由は別記事で解説する(予定)。
to_reference
とfrom_reference
とで同じ1DLUTファイルを参照しているfrom_reference
の場合はdirection: inverse
オプションを使用している
6. 備考
config.ocio の作成には PyOpenColorIO
を使うと便利である。インストール方法は公式サイトを参照。
使い方の例として以下3点を載せておく。
- 筆者のコード (注意:筆者のDocker環境以外では動作しないと思います)
- nuke-default
- aces_1.0.3
7. 今後の課題(理解が追いついてない点)
- spi1d 適用時の定義域外データの扱い(クリップ? or 変換されずに放置?)
- (2019/04/21追記) クリップされる
- spi3d 適用時の定義域外データの扱い(クリップ? or 変換されずに放置?)
- (2019/04/21追記) クリップされる
- MatrixTransform の 0埋めしている値は何に使うのか?
- spi1d の LUT数は幾つか良いのか。4096?16384?65536?
- 作成した config.ocio は Nuke 以外のツールでも同じように動作してくれるのか?
- aces_1.0.3 の config.ocio だと Color Space の選択UIがカテゴリごとにまとまっている。これはどうやれば実現できる?
- (2019/04/21追記) family タグを指定すれば良い
参考資料
[1] 松井 幸一, "もう一度ACES", http://filmlight.jp/files/20170907.pdf (2019/04/14 確認)