H19.5以前よりOCIOを絡めた設定をちゃんとしておかないといけなくなっているのでちょっと面倒。
原則として、Rendering Working Space=Output Spaceになるワークフローとして話を進めます。
H20はRendering Working SpaceとOutput Spaceが別で設定できるように変更されています。
その際のOutput Colorspaceのデフォルト値がFile Rulesの該当形式のカラースペースになっています。（やっかいなことにViewportでのレンダリングではこの変換は反映されず、husk等で書き出した場合にのみ適応されます。）
この条件分岐で該当する項目を読んでください
graph LR;
A[OCIO Config] -- 使わない -->関係なし;
A[OCIO Config]-- 使う --> B[File Rules];
B{File Rules設定の有無}-- 設定されていない --> P1[目次：OCIOだけ設定へ];
B-- 設定されている --> C{File Rulesの変更};
C-- できない --> P3[目次：レンダリング設定での対応へ];
C-- できる --> P2[目次：OCIOとFile Rulesの書き換えへ];
OCIOだけ設定
これは従来と同様に環境変数OCIOを設定し、OCIO ConfigのRole:scene_linearの項目をRendering Working Spaceにしたいカラースペースに設定します。
環境変数設定例
OCIO: "OCIO_Config_File.ocio"
場合によってはOCIO_ACTIVE_DISPLAYSとOCIO_ACTIVE_VIEWSも設定します。
Correction Tool Barの順番（と表示項目）を制御できます。
OCIO_ACTIVE_DISPLAYS: "sRGB - Display, Rec.1886 Rec.709 - Display" OCIO_ACTIVE_VIEWS: "ACES 1.0 - SDR Video, Un-tone-mapped, Raw"
OCIO_ACTIVE_VIEWSに関してはOCIO Config内で以下の記述でもデフォルトを決められます。
#これはデフォルトがUn-tone-mappedになる設定 default_view_transform: Un-tone-mapped
OCIOとFile Rulesの書き換え
OCIOだけ設定、にさらに以下の設定をします。
OCIO ConfigのFile Rules欄、書き出しファイル形式と同じファイル形式の部分をOutput Spaceの設定にします。
つまり、画像をOpenEXRで書き出し、Output SpaceがACEScgにしたい場合は以下の部分を書き換える、もしくは削除します。
※File Rules設定なので、編集や削除をせずに独自のルール（ファイル名のパターンマッチング等）で書き出し画像のOutput Spaceを正しく設定しても問題はありません。
レンダリング設定での対応
OCIOだけ設定、にさらに以下の設定をします。
OCIO ConfigのFile Rulesが変更できない場合の対処ですが、Configがなにであろうと強制的に変更できるのでこちらでもいいかもしれません。
Render SettingsのAOVsの箇所にOutput Colorspaceを変更できる箇所があります。必要なAOVs全てに設定する必要があります。
たくさんあるとめんどうなので以下のようにRender Var Edit LOPで一括変更でもいいかもしれません。
Primitivesには以下のようなものを設定
%type:RenderVar & ({ usd_attrib(0, @primpath, 'dataType') == 'color4f' } + { usd_attrib(0, @primpath, 'dataType') == 'color3f' })
たとえばこのOutput Colorspaceも、以下のようなPythonで強制的にConfigのRole:scene_linearと一致させればトラブルは少ない。
import PyOpenColorIO as OCIO config = OCIO.GetCurrentConfig() colorSpace = config.getColorSpace('scene_linear').getName() return colorSpace
おまけ
Textureのカラースペース
これもデフォルトでFile Rulesが適応される。が、File RulesはImageがColor扱いの場合にのみ適応される。
しっかりワークフローなどで一定のファイルフォーマットとカラースペースが決まっていない場合は手動で変更できるようにしてテクスチャを読み込んでおくとトラブルを減らせる（代わりにカラースペースを意識する必要がある）
MaterialX Image
MaterialX Imageノードであれば、SignatureがColorの場合はFile Rulesのカラースペースが適応され、Vectorであれば無変換になる。
なのでFile Rulesに縛られたくない場合はSignatureをVectorにし、Karma OCIO Color Transformノードなどで個別に適宜設定できる。
USD UV Texture
USD UV TextureはAutoの場合がFile Rulesで変換、sRGBの場合はsRGB Textureとして変換、Rawは無変換
Karma OCIO Color Transform
ちなみにKarma OCIO Color Transformを使う場合のTo SpaceはTo Spaceは基本的にRendering Working Space（scene_linear）
Configの書き換え
今回の記事に度々出てくるConfigの書き換え処理に関しては環境変数OCIOを使っていない場合に限り、OCIO Editorから変更するほうが手軽です。
ただしこのOCIO Editorでの書き換えは過去記事に書いたとおり、ファイルを直接書き換える処理が走るため、チームやプロダクションでの使用は控えたほうがいいです。個人の場合は手軽なので使うと楽です。
OCIOとFile Rulesが一致していないとどうなるか
従来通りRendering Working Spaceだけ変更してFile Rulesが一致していない場合
Viewportは問題なく、テクスチャ等は各テクスチャのColorspaceをRendering Working Space（ここではACEScg）に変更すればいいです。
しかし保存されたファイルはOutput Spaceに変換されて保存されているので、Nukeなどに読み込む際にはOutput Space（ここではFile RulesのexrのColorspace）で読み込まないといけません。つまりここではLinear Rec.709 (sRGB)のレンダー画像になっているということです。
Rendering Working SpaceとOutput Spaceが一致している状態だとどうなるかというと、
Data系のAOVsはどうなるか
WorldPosition(P)やWorldNormal(N)には設定箇所はありませんが、ためした限りでは設定されてなくても適切に書き出されます。
これはRenderVarのData TypeがColor系ではない=データであるAOV=カラースペースは適応しないという処理になっているためです。新規に独自のAOVsを作成する場合はこのData Typeにも気をつけましょう。
もしくは、心配の場合はRenderVar LOPにH20から追加されている、Source ColorspaceとOutput ColorspaceをRawに設定します。データタイプかどうかに関わらず、Rawに設定されている場合はColorspaceを適応しないので問題は起きないはずです。
Rendering Working Space
H20からRender Settings LOPにもRendering Color Spaceの項目があるのでConfigのRole:scene_linear以外でもレンダリングする際のカラースペースを変更できます。が、非常にややこしくなるのでConfigで制御したほうがわかりやすいかなと思います。
情報元
Render Var LOPのhusk、Output Color Spaceの項目。 Render Var
OpenColorIO を使用してfile_rules出力カラースペースを自動的に決定します。通常、非カラー AOV (すなわちpointまたはnormal data) はデフォルトのrawカラー スペースになります。このオプションを使用すると、これらの AOV をカラー データとして強制的に解釈し、書き込む前にカラーを変換できます。
Changelog / Jornal
Houdini ビューポートは、デリゲートからの AOV バッファを表示するときに renderingColorSpace から変換します。 husk は画像を保存するときに renderingColorSpace から変換します。
Texture Colorspace
