すあまの備忘録

誰得内容の自分のための非営利目的備忘録ブログ(筆者がわかっても内緒にしてください)

OCIOとACESの知っている範囲メモ

OpenColor IOの知っている範囲メモ。

勉強中のため間違ってたら優しく指摘してください...

この記事をまとめている間にOCIOが更新されてしまった。大きくは変わらないので1.0.3でまとめます。

OCIOざっくり

映像制作における一貫した色変換を手軽に行えるようにするためのシステム。

ACESと一緒に使うことが多いので混乱しますが、ACESは色域の規格と色管理の仕組み、OCIOはそれを扱うためのツールみたいな感じ。

ざっくり図にすると以下のようなInputのカラースペースを1度特定のカラースペースに統一し、さらにOutputのカラースペースに変換するという処理を担ってくれる。

f:id:godofsuama:20200922004126j:plain

図のReference Color Spaceという部分でACES2065-1やACEScgという広範囲をカバーした色域を使い、あらゆるカラースペースへの変換を可能にする。

ACES2065-1(AP0)はCIE xyY仕様で定義されている可視光線を完全に包含するとなっているのでこの色空間に変換することで人が見える範囲は全てカバーできるという感じ。

Reference Color SpaceにsRGB等を指定することもできるが、情報の欠損や今まで同じ結果にしかならないため意味はない。

config.ocio

Nukeや各DCCでOCIOを使用す際に指定するファイル。

細かい説明は公式を参照

Config header

OCIOのバージョンや、OCIOを使用するために必要なLutファイルへのパス等が記載されている。

Roles

Nukeで言うところの以下の部分

f:id:godofsuama:20200922010309p:plain

reference:
rendering:
color_picking:

などの部分を介して、ツール側が読み取り、指定されたカラースペースへの自動変換をするための部分。

パイプライン等で統一されていれば、この部分を指定するだけで作業する側はsRGBなのか?Rec.709なのか?等細かいことを気にせず半自動で変換処理を行うことができる。

現時点で、NukeやHoudini等は、Roles部分のscene_linearの項目をレンダリング時の色域と認識するためこの部分でLinear sRGBを指定すると従来と同じLinear sRGB空間での作業になり変化がなくなる。

Nukeでの注意

NukeのColor Management設定にある、Working Spaceとfloat filesは同じscene_linearの項目を読み取ってしまうため、レンダリング画像がLinear sRGBなどの場合はNuke上でfloat filesの設定を変更する必要がある。 f:id:godofsuama:20200922011758p:plain

Working Spaceとfloat filesの設定が異なる場合、読み込まれたレンダリング画像のAOVsにも色補正がかかってしまうため注意が必要。両方が同じ場合はかからないっぽい。

やるとしたらこんな感じか?MergeのAlso MergeはONにする。 f:id:godofsuama:20200922012055p:plain

Houdiniでの注意

Houdiniはすべての画像のInputの色域もこのscene_linear部分と同じと認識するため、sRGB等で作成したTextureなどを使用している場合はOCIO Transformノードか、事前に画像を変換する必要がある。

数が多いと大変なので事前に変換するのが良い。

f:id:godofsuama:20200922011246p:plain

Displays

f:id:godofsuama:20200922012331p:plain

ここで指定されたものがNuke ViewやDCCツールのレンダー画面のカラースペースとして選べるようになる。

Colorspaces

f:id:godofsuama:20200922012844p:plain

この部分が各変換処理が記述されている部分。

nameは表示されるカラースペースの名前

familyはカラースペースのグループ

equalitygroup:ここに指定されているカラースペース名のものは変換処理をしない。同じ処理であるとする(色深度が違う場合等)

bitdepth:色深度

isdata:AOVsのデータ的な要素で使われるかどうか

allocation:allocationvars:GPUで処理するときとかの設定らしい。

from_reference:1行目、ACES 2065-1のRGB to CIE XYZに変換するためのカラーマトリックス。2行目はCIE XYZ to sRGBのカラーマトリックス。この部分で色の変換処理をしている。

to_referenceもある。from_reference:と同じ変換処理。

f:id:godofsuama:20200922014107p:plain
出典:https://en.wikipedia.org/wiki/Academy_Color_Encoding_System

上記はUtilityのsRGBだったためRRTの処理がないが、OutputのsRGBの方にはRRTの処理がはいっており、勝手にトーンマップ処理のようなものが入ってしまうため注意が必要。

実際に使用する場合は他のカラースペースでも勝手に入っていないかの確認が必須です。

f:id:godofsuama:20200922015632p:plain

このsRGBのRRTはNukeのColorLookupで近似再現すると以下の画像のようになり、ハイライト部分を圧縮し、暗部を締める処理が入っているのがわかります。

f:id:godofsuama:20200922020104p:plain

NukeのColor Managementを「Nuke」、OCIO Configを「nuke-default」にした状態でこのカーブをかけて書き出すとACES使用時とほぼ同じコントラストになります。

一時期流行った?Filmic Tonemapのような処理になり

見た目は個人的に好きですが本来のsRGBではなくなってしまうため、正確に変換する場合は外す必要があります。

人の見た目的にはこちらのほうが自然に見えるというやつです。

Filmic Color Management - Color Space • Maxime Roz

Filmic Color Management in Blender | HDR Tutorial (4/7) • Creative Shrimp

Color Grading and Filmic Tonemapper | Unreal Engine Documentation

Lut

lutにはいろいろな形式がある。OCIOをダウンロードした際にもBakedフォルダに各種入っている。

それ以外にもOCIOの変換もspi1dとspi3dというlutで変換している場合もある。

基本的にはどのLutもいくつからいくつまでの範囲の色を何分割かし、各値と同じ値を○○という値に変更するという記述が総当りで書いてある。

1dと3dの違いは、1dはRGB全てに同じ値の処理がされ、3dはRGB個別に違う値が設定できるというだけ。

OCIOは、値と値の間の補間をどうするか、というのもconfigに記述する。

例 3d lut

例えば画像のようになっていて、0-1を0-64の65分割し、RGBそれぞれどの値にするかが記述されている。

f:id:godofsuama:20200924011438p:plain

例 1d lut

こちらは記述方法が少し違うが、0-1を4096段階にわけ、それぞれの値の変更値が列挙されている。

f:id:godofsuama:20200924011607p:plain

簡略化したフロー図

f:id:godofsuama:20200922023241p:plain

v2.0から一部名称が変わったようで、図は古い名称が入ってます。

細かい各名称と役割は以下にあります。

Academy Color Encoding System - Wikipedia