🎨

OCIOのメモ

2024/11/12に公開

Codespaces

ocio

aces

tech

随時更新

OCIO V2.4のマニュアルを元にメモ
2024/11/12現在

Github

Config

ocio.configのdefaultの設定を保存している場所

OpenColorIO の Config ファイル作成

Python

If you only need the Python binding and command-line tools, the simplest solution is to take advantage of the pre-built wheels in the Python Package Index (PyPI) here. It can be installed as follows, once you have Python installed.

pip install opencolorio

OCIOのinstall for Mac

brewからのinstall

Homebrew は Python バインディングや ocioconvert, ociodisplay, ociolutimage といった OpenImageIO や OpenEXR に依存するコマンドラインツールをインストールしません。

brew install opencolorio

画像に色変換を適用するだけなら、OpenImageIO の oiiotool が ocioconvert コマンドラインツールのほとんどの機能を持っていることに注意してください（GPU 処理などすべてではありませんが）。 OpenImageIO はいくつかのパッケージマネージャ (Homebrew や Vcpkg を含む) から入手できます。


brew install openimageio

Config file　Syntax

OCIOは基本的に設定したReference Color Spaceにinputから変換してoutputするというシステム

https://trev16.hatenablog.com/entry/2019/04/14/193845

Authoring Configurations
configファイルの設定についてのドキュメント

Configファイルの例

OCIO configファイルは基本的にYAML形式に従っている。
validation checkに関してはociocheckを使ったりすることが推奨されている。

Use the ociocheck command line tool to validate your config. It will inform you of YAML-syntax errors, but more importantly it performs various OCIO-specific validations. There are also validate methods on the Config class in the C++ and Python APIs, (although they do not do the role checking that ociocheck does).

OCIOは基本的に下記のようなセクションに分かれている。

Config header – The header contains the version and LUT search path.

Environment – The environment defines the context variables used in the config.

Roles – The roles define which color spaces should be used for common tasks.

File & Viewing rules – These rules define sensible defaults that help applications provide a better user experience.

Displays & Views – This section defines how color spaces should be viewed.

Looks – Looks are transforms used to adjust colors, such as to apply a creative effect.

Colorspaces – This section defines the scene-referred color space encodings available within the config.

Display Colorspaces – This section defines the display-referred color space encodings available within the config.

Named Transforms – Named Transforms are a way to provide transforms that do not have a fixed relationship to a specific reference space, such as a utility curve

利用可能なtansformのコレクションが用意されていてconfigファイル上で使用できるようになっている。

A collection of Available transforms is provided for use in the various sections of the config file.

Config header

ocio_profile_version

Reauired
慣習として、configファイルはocio_profile_versioinで始まる。
どのOCIOのsyntaxを使うかを判定するもので、現在は1,2のどちらか

ocio_profile_version: 2

description

optional
configurationの簡単な説明を記載できる。

description: This is the OCIO config for show: foo.

name

optional
configファイルに対してunique nameをつけることができて、
将来のOCIOバージョンではnamespace(名前空間)のように使えるかもしれない。

name: studio-config-v1.0.0_aces-v1.3_ocio-v2.1

search_path

optional
デフォルトではemptyになっている。

これはLUTを置いている場所のなどのsearch pathに使うことができる。
$PATHみたいな記述の仕方と一緒でcolon-separated list of directoriesになっている。

search_path is a colon-separated list of directories. Each directory is checked in order to locate a file (e.g. a LUT).

下記のようなフォルダ構成になっている場合

config.ocio
luts/
  lg10_to_lnf.spi1d
  lg10_to_p3.3dl

search_pathは以下のように設定すればいい

search_path: "luts"

color spaceの定義の部分ではFileTransformのようなLUTファイルは

In a color space definition, we might have a FileTransform which refers to the LUT lg10_to_lnf.spi1d. It will look in the luts directory, relative to the config.ocio file’s location.

複数のpathを設定するには
下記の例では絶対pathと相対pathの2つの書き方で2つのpathが設定されている。

search_path: "/mnt/path/to/my/luts:luts"

もしくは以下のようなYAMLの書き方にすることができる。

search_path:
  - luts1
  - luts2

OCIOのcontext variableを使うこともできる。
以下で言えば$SHOT

search_path: "/shots/show/$SHOT/cc/data:luts"

This allows for some clever setups, for example per-shot LUT’s with fallbacks to a default. For more information, see the examples in Looks Example
https://opencolorio.readthedocs.io/en/latest/guides/authoring/authoring.html

family_separator

optional
GUIやAPI上でcolor spaceのヒエラルキーメニューを作りたい時に使える。
階層構造を何で区切って定義するかというseparator

family_separatorが定義されていない場合は階層メニュー構造を作らない。

family_separator: /

family_separator: /

color_spaces:
  - !<ColorSpace>
    name: ACME_log4
    family: Log/Cameras/ACME
    equalitygroup: ACME_log4
    [...]

  - !<ColorSpace>
    name: ACEScct
    family: Log/ACES
    equalitygroup: ACEScct
    [...]

  - !<ColorSpace>
    name: Rec.709
    family: Video/Broadcast/SDR
    equalitygroup: Rec.709
    [...]




### inactive_colorspaces
optional
使用すべきでない色空間のリストを指定する。
これらの色空間はColorSpaceTransformsで動作するが、
アプリケーションメニューには追加されなくあんる。
これは環境変数 `$OCIO_INACTIVE_COLORSPACES`があればそれで上書きされる。
前のバージョンで定義されていたcolor spaceなどを非推奨にしたい時に使うときとかに便利。

inactive_colorspaces: [do_not_use_this_colorspace, prev_version_colorspace ]




### luma
Deprecated. optional
デフォルトではASCによって定義されたRec709プライマリ

luma: [0.2126, 0.7152, 0.0722]


> These are the luminance coefficients, which can be used by OCIO-supporting applications when adjusting saturation (e.g. in an image-viewer when displaying a single channel)
https://opencolorio.readthedocs.io/en/latest/guides/authoring/authoring.html

:::message
Note

While the API method is not yet officially deprecated, luma is a legacy option from Imageworks’ internal, closed-source predecessor to OCIO.

The luma value is not respected anywhere within the OCIO library. Also very few (if any) applications supporting OCIO will respect the value either.
>この API メソッドはまだ公式には非推奨ですが、luma は、Imageworks 社内のクローズドソースの前身である OCIO のレガシーオプションです。 luma 値は、OCIO ライブラリのどこでも尊重されません。 また、OCIOをサポートするアプリケーションでも、この値を尊重するものは（あったとしても）ほとんどありません。

:::

## Enviroment

### enviroment
optional
このenviromentセクションはconfigrationで使われる全てのContext Variableを宣言する場所。

environment:
SEQ: default_sequence
SHOT: $SHOT

2種類の宣言方法があり
SEQの方ではデフォルト値にdefault_sequenceというのが代入されている状態
SHOTの方ではデフォルト値がない宣言方法で、そういう場合はこの構文で宣言する。


## Roles

### roles
Required

`role`は色空間の代替名(alternate name)を表す。

>For example, the Nuke node OCIOLogConvert: instead of requiring the user to select the appropriate log color space, the node performs a transform between scene_linear and compositing_log, and the OCIO config specifies the project-appropriate color spaces. This simplifies life for artists, as they don’t have to remember which is the correct log color space for the current project - the OCIOLogConvert always does the correct thing.
>例えば、NukeノードのOCIOLogConvert：適切なログカラースペースを選択するようユーザーに要求する代わりに、このノードはscene_linearとcompositing_logの間で変換を実行し、OCIOコンフィグがプロジェクトに適したカラースペースを指定します。 OCIOLogConvertは常に正しい処理を行います。
https://opencolorio.readthedocs.io/en/latest/guides/authoring/authoring.html

config sampleの`spi-vfx`では以下のようになっている。

roles:
color_picking: cpf
color_timing: lg10
compositing_log: lgf
data: ncf
default: ncf
matte_paint: vd8
reference: lnf
scene_linear: lnf
texture_paint: dt16

この例で出てきている全ての値の`cpf`, `log10`, `ncf`などは後半のcolorspacesセクションで定義された色空間を参照している。

:::message
**Warning**

Unfortunately there is a fair amount of variation in how applications interpret OCIO roles. This section should be expanded to try and clarify the intended usage.

OCIOのroleをそれぞれのアプリケーションがどう解釈するかについてはアプリケーションによってバラツキがあるため、
意図する使い方を明確にするために下記にOCIOの意味合いを示す
:::

 - `aces_interchange`
SMPTE ST2065-1で定義されるACES AP0の色空間を実装するconfig内のcolorspaceを定義する。
 - `cie_xyz_d65_interchange`
標準 CIE XYZ colormetryを実装し D65 whiteに適合させたconfig内の色空間を定義する。

 - `color_picking`
color-selection UIの色をこの空間に表示
(e.g. scene_linear or texture_paint).
 - `color_timing`
Color Correctionの適用に使用される色空間
>e.g. user-specified grade within an image viewer (if the application uses the DisplayTransform::setDisplayCC API method)
 - `compositing_log`
特定の処理操作(plateのリサイズ、pulling keys, デグレイン...etc)に使用されるlogの色空間
>Used by the OCIOLogConvert Nuke node.
 - `data`
法線、深度データなどのその他の色以外のデータなどのデータ出力を書き込む時に使用する色空間。
このroleの色空間は一般に`data : true`が指定さrているはずで、色変換が適用されない。
 - `default`
strictparsing: false の場合、この色空間がフォールバックとして使われる。(for more information, [see the guide on baking ICC profiles for Photoshop](https://opencolorio.readthedocs.io/en/latest/tutorials/baking_luts.html#userguide-bakelut-photoshop), and [spi-vfx](https://opencolorio.readthedocs.io/en/latest/configurations/spi_vfx.html#config-spivfx)).

 - `matte_paint`
マットペインティングが作成さrウェル色空間
 - `reference`
他の色空間を定義する際の基準となる色空間
:::message
The reference role has sometimes been misinterpreted as being the space in which “reference art” is stored in.
リファレンスの役割は、「リファレンス・アート」が保管される空間であると誤解されることがある。
https://opencolorio.readthedocs.io/en/latest/guides/authoring/authoring.html
:::
- `scene_linear`
scene-referred linear to light color space
多くの場合 reference spaceと同じ。
- `texture_paint`
`matte_paint`と似ているが、3Dオブジェクトのテクスチャをペイントするためのもの
(see the description of texture painting in [SPI’s pipeline](https://opencolorio.readthedocs.io/en/latest/concepts/overview/overview.html#config-spipipeline-texture)).

## File & Viewing rules

### file_rules

ファイル名に対して、どのcolorspaceに判定するかというfilenameのruleを指定できる場所。


---

:::message
**Warning**

Either the file_rules section or the default role are Required for configs of version 2 or higher.

file_rules sectionかdefault roleがversion2以上のconfigには必要
:::
ファイル規則を使用して、pathに基づいてファイルにデフォルトのcolor spaceを割り当てる。
下記が定義可能な様々なタイプのexample

file_rules:

!<Rule> {name: LogC, extension: "*", pattern: "LogC", colorspace: ARRI LogC}
!<Rule> {name: OpenEXR, extension: "exr", pattern: "*", colorspace: ACEScg}
!<Rule> {name: TIFF, regex: ".*\.TIF?F", colorspace: sRGB}
!<Rule> {name: ColorSpaceNamePathSearch}
!<Rule> {name: Default, colorspace: default}

file ruleはトップダウンで評価されるマッピングのセット。
最初にマッチするルールはどのcolorspaceが返されるか決定するもの。
利用可能なるルールには4タイプある。
書くルール・タイプにはアプリケーションがそのルールを参照するために使用できる `name key`がある。`Name value`は一意出なければならない。他のkyeはrule typeに依存する。

**1. basicルール**
Unix glob styleのpattern matchingを使用する。

- `name` : ruleの名前
- `pattern` : name/pathの主要部分に使用するGlob pattern。大文字と小文字は区別される。二重引用符で囲む必要あり。ruleにextensioinだけを考慮させたい場合は`"*"`を設定する。
- `extension`： ファイル拡張子に使用するグロブパターンまたは文字列。 グロブトークンを使用しない場合、デフォルトでは拡張子は大文字小文字を区別しない方法で使用されることに注意。 例えば、単純な文字列 "exr "は、"exr "と "EXR "にマッチする。 exr "だけにマッチさせたい場合は、グロブパターン"[e][x][r]"を使う。 二重引用符で囲む必要がある。 パターンを考慮するルールにしたい場合は、"*"を設定する。

- `colorspace` : returnするColorSpace name

**2. RegEx Rules**

basic ruleに似ているが、power-users向けの追加機能。keyが含まれる。

- `name` : ルールのname
- `regex` : 評価される正規表現。二重引用ふで囲む
- `colorspace` : returnするColorSpace name
- 
RegEx 式のバックスラッシュ文字は、Yaml 解析を通過するために、(上記の TIFF ルールの例に示すように)二重にする必要があることに注意してください。

**3. OCIO v1 style Rule**
このルールはOCIO v1syleの使用を許可し、文字列はconfigからColorSpace nameを検索する。このルールはリスト内で0回または1回出現する。リスト内の位置は他のルールに対する優先順位を示す。

- `name` : Must be `ColorSpaceNamePathSearch`.


**4. Default Rule**
file_rules secitionは常にこのルールで終わらないといけない。
それ以前のルールに一致するうものがない場合、このルール(default rule)がcolrospaceを指定する。

- `name`: must be Default.
-`colorspace`: ColorSpace name to be returned.

:::message alert
OCIO v1ではファイルを読み込むときに、デフォルトのcolor spaceを指定することを目的たとした`default` rolが定義されている。
しかし、このroleの使用法に関する混乱を考慮して、現在はDefault file ruleを示すのが好ましい方法となっている。
しかし、file_rulesセクションが存在しない場合、新しいAPIはDefault ruleの代わりにDefault roleをしようとする。
両方が存在する場合、default ruleが優先される。file_rulesセクションとdefault roleの両方が存在しない場合はconfigをloadする際に例外が発生する。
:::

:::message
`srictparsing` トークンは File rules APIの動作には影響しないことに注意。
言い換えると、
rule を評価するとアプリケーションは常にColorSpaceを利用できるようになる。
しかし、APIはどのルールがマッチしたかをアプリケーションに知らせることもできる。
したがって、"strict"モードで動作させたいアプリケーションはまず、`strictparsing`がtrueかどうかをチェックして、trueならマッチしたruleがdefault ruleかどうかをチェックする必要がある。
もしそうならユーザーに通知し、適切なアクションをとることができる。
(As an alternative to checking which rule number was matched, the API call filepathOnlyMatchesDefaultRule may be used instead.)
:::

rulesではColorSpace nameではなく、roleを使用することができる。

It is also legal for rules to have additional key:value pairs where the value may be an arbitrary string. The API provides access to getting/setting these additional pairs and will preserve them on a Config read/write. These may be used to define application-specific behavior.

Note to developers: The older parseColorSpaceFromString API call is now deprecated and should be replaced with getColorSpaceFromFilepath.

### strictparsing(OCIO v1)
optional

>strictparsing は未知のファイルフォーマットが来た時に、次の 5.2.で説明する role の default 設定を使用するか否かの判断で使用する。詳細は公式ドキュメント参照。
https://trev16.hatenablog.com/entry/2019/04/14/193845


ture か falseのどちらか
デフォルトではtrue

```yaml
strictparsing: true

OCIO v1はアプリケションがfilenameから colorspaceを抽出する仕組みが用意されている。
(the parseColorSpaceFromString API method).

つまり、 example_render_v001_lnf.0001.exrのようなファイルでは、lnf color spaceに決定する。(color space　nameを含む一番右の部分文字列)
ただし、colrospaceを決定できず、strictparsing:trueの場合は、空文字(empty string)を返す。
color spaceを決定できず、strictprasing:falseならば、 default roleが使用される。これにより処理されない画像は"non-color managed"モードで動作できる。

アプリケーションの作者は注意で、config が存在しない場合(e.g. $OCIO経由)、デフォルトの内部プロファイルはstrictparsing=falseを指定し、デフォルトのcolor space roleはrawとして解釈される。
これはOCIOに渡された文字列は全てデフォルトのrawとして解釈されることを意味する。
This is nice because in the absence of a config, the behavior from your application perspective is that the library essentially falls back to “non-color managed”.

viewing_rules

optional

ビューイングのカラースペースの設定
このあとのdisplaysと合わせて設定していく。
viewing_rulesではとりあえず、それぞれのcolorspaces:に対してviewing_rule名をとりあえず与えておく。

Viewing Rulesを使用して、デフォルトのviewをcolorspaceにわり当てる。

viewing ruleによって、config作成者は与えられた色空間に使用する適切なビューを指定することでアプリケーションがより良いユーザーエクスペリエンスを提供できるようになる。
例えば、アプリケーションはUIのサムネイル画像を作成する際に、デフォルトのビューを使用することができる。
同様にアプリケーションはviewportに画像を最初に表示する時にデフォルトのviewを選択することができる。

viewing_rules:
  - !<Rule> {name: video-spaces, colorspaces: [sRGB, Rec709]}
  - !<Rule> {name: data-spaces, colorspaces: [alpha, normals]}

displays:
  sRGB:
    - !<View> {name: Video, view_transform: colorimetry, display_colorspace: sRGB, rule: video-spaces}
    - !<View> {name: Raw, colorspace: nc10, rule: data-spaces}

これは、あるviewがいくつかの特定のcolor spaceでの使用を意図している場合に役立つ。しかし、他の状況ではより広範囲に使える色空間で使用するルールを定義できると便利。

color spaceは"scene-linear", "log", sdr-video
, "data"のようなグループに色空間をグループ化できるように"encoding"属性を持つことができるようになった。
viewing rulesでは名前付きカラスペースのセットではなく、color spaceのencoding attributeに基づいてルールを定義できるようになった。
example

viewing_rules:
  - !<Rule> {name: scene-linear-or-log, encodings: [scene-linear, log]}

displays:
  sRGB:
    - !<View> {name: ACES, view_transform: ACES-sdr-video, display_colorspace: sRGB, rule: scene-linear-or-log}

colorspacesとencodings attiributeは単一の値または、値のリストを含むことができる。
一つのruleがcolorspacesとencodingsの両方のリストを同時に定義するのは違反となる。

また、file_rulesと同様で、以下のようなcustomのkey:valueのペアを定義もできる。

- !<Rule> { name: scene-linear-rule, encodings: scene-linear, custom: {key1: value1, key2: value2} }

このkey nameは任意の文字列で、これはプリケーション固有の動作を制御するのに役立つかもしれない。

name: ルールの名前 (ユニークネームにする必要あり。)
encodings: ルールが使用するcolor space encodings
colorspaces: ルールが使用する color space name
custom : 任意のkey/valueのペアセット

このAPIはアプリケーションが指定されたcolor spaceのviewのリストを要求することを可能にする。
これはcolor spacce nameとencodingに基づいて指定されたdisplayのviewをフィルタリングするために使用される。
rules attributeを持たないviewは常に返される。(したがって、ruleが存在しない場合は、フィルタリングなしのAPI呼び出しと同じ結果になる。)

active_viewsを使用して指定されたユーザーまたはワークステーションに適切でないviewを削除することができることに注意。
active_viewsリストが空でない場合、そのリストにないビューはアプリケーションに提供される結果に表示されない。(viewがruleに表示されるかどうかに関係なく)

さらに、acrive_viewsは全てのAPIcallでのviewのリストをsortし続ける。(つまり、indexの順序を決定する)

colorspaceに対して最初に許可されるviewがデフォルト。

Displays & Views

displays

Required

viewing_rulesを使って、実際どのdisplayにはどう表示させたいかというのを決定する場所。

このセクションでは、使用する全てのdisplay devicesを定義する。例えば、artistのワークステーションにはsRGBのdisplay devicesを、試写室のプロジェクターにはDCIP3のdisplay devicesを使用する

各display deviceにはいくつかのviewがある。
これらのviewは選択されたdisplay deviceに画像を表示する様々な方法を提供する。

"Film"で現在のdisplayで投影された最終結果をエミュレートする。
"Log"で対数空間のピクセル値を直接ディスプレイに送信する。その結果、黒レベルをチェックするのに便利な"浮き上がった"画像がえらえる。
raw:yesでcolor spaceを指定した場合は"RAW"は変更されていない画像を表示する。

spi-vfx configのdisplayの例

displays:
  DCIP3:
    - !<View> {name: Film, colorspace: p3dci8}
    - !<View> {name: Log, colorspace: lg10}
    - !<View> {name: Raw, colorspace: nc10}
  sRGB:
    - !<View> {name: Film, colorspace: srgb8}
    - !<View> {name: Log, colorspace: lg10}
    - !<View> {name: Raw, colorspace: nc10}
    - !<View> {name: Film, colorspace: srgb8}

全てのcolorspacesは(p3cid8, srgb8)のようなconfigの後半で定義されるcolorspaceを参照している。

active_displaysセクションとactive_viewsセクションが定義されていないとき限り、最初のdisplayと最初のviewがデフォルトとなる。

viewは上述したように、scene-referred spaceからdisplayへの直接変換として定義されても良い。
あるいは、view transform とdisplay colorspaceの組み合わせを使用してviewを定義しても良い。
この場合,view transformはscene-referred spaceからdisplay -referred reference spaceへ変換し、display color spaceはdisplay-referred reference spaceからdisplayへの変換に使用される。

displays:
  DCIP3:
    - !<View> {name: Film, view_transform: FilmView, display_colorspace: DCIP3}

view_transforms:
  - !<ViewTransform>
    name: FilmView
    from_reference: <omitted for brevity>

display_colorspaces:
  - !<ColorSpace>
    name: DCIP3
    from_display_reference: <omitted for brevity>

name : viewの名前
colorspace: reference spaceからdisplayへの変換に使用される変換の色空間
view_transform:scene-referred refenceからdisplay-referred refence spaceへの変換、または、display-referred refernceで適用される変換。
display_colrospace:display-referred refenceからdisplayへの変換に使用されるdisplay
looks: 適用する1つ以上の Look Transform。この文字列はlookを順方向に適用する場合は+文字を,逆方向に適用する場合は-を使用する. Looksを参照
rule : このviewで使用するview rule. viewing_rules
description: Viewの説明の文字列

viewはcolorspace keyを使うか, view_transform keyとdisplay_colorspace keywの両方を使うかのどちらか。それ以外の組み合わせは許されていない。

view_transform

optional

displaysでview_transformを使用していた場合にそのview_transformの定義を書く場所
OCIO renference spaceに変換する変換を定義する。

OCIO config にはscene-referredとdisplay-referredの2つのreference spaceが含まれる。
view Transformはこれらのrenfece spaceのマッピングである。業界ではこれらのマッピングに足して様々な用語が使用されている。
ISO22028-1やACESでは"color-rendering transforms"と呼んでいて、HDR television(ITU-R BT.2100, BT.2390)では"Opto-optical tranfer Function" or "OOTF" と呼んでいる。

また、display-referred reference spaceの値を調整するためのview transformを指定することも可能である。
言い換えれば、それはdisplay referred reference spaceからそれ自体に戻るように変換することができる。これはHDRからSDR videoの変換,その逆で使用される変換を記述するのに便利。

name: View Transformの名前
description: View Transformの説明
family: family string　(ColorSpace同様)
categories: メニューのフィルタリングに使用可能(ColorSpace同様)
from_scene_reference: scene-referred refence space からdisplay rerred reference spaceへの変換
to_scene_reference: display rerred reference spaceからscene-referred refence space への変換
from_display_reference: display rerred reference spaceからdisplay rerred reference space への変換
to_display_reference: from_display_refernece変換の逆

default_view_transform

optional
デフォルトのview transform

デフォルトのview transformはColorSpaceTransformがScene referred とdisplay referred colrospaceの間で変換する必要がある場合に適用されるビュー変換
このkeyがない場合は設定内の最初のビュー変換が使用される。

default_view_transform: un-tone-mapped

shared_views

optional
一度定義したviewを複数のディスプレイで使用できるようにする

shared_views:
  - !<View> {name: Log, colorspace: lg10}
  - !<View> {name: Raw, colorspace: nc10}

displays:
  DCIP3:
    - !<View> {name: Film, colorspace: p3dci8}
    - !<Views> [ Log, Raw ]
  sRGB:
    - !<View> {name: Film, colorspace: srgb8}
    - !<Views> [ Log, Raw ]

つまり、これと同じこと

displays:
  DCIP3:
    - !<View> {name: Film, colorspace: p3dci8}
    - !<View> {name: Log, colorspace: lg10}
    - !<View> {name: Raw, colorspace: nc10}
  sRGB:
    - !<View> {name: Film, colorspace: srgb8}
    - !<View> {name: Log, colorspace: lg10}
    - !<View> {name: Raw, colorspace: nc10}

shared viewは特別なトークン<USE_DISPLAY_NAME>を使用して、display_colorspace nameをshared viewが使用されるdisplay nameと等しく設定するように要求することができる。
いかの例ではACES shared viewがsRGB displayで使用される場合、そのdisplay_colorspaceは"sRGB"に設定され、Rec709ディスプレイで使用される場合は、そのdisplay_colorspaceは"Rec709" に設定される。

shared_views:
  - !<View> {name: ACES, view_transform: ACES-sdr-video,
             display_colorspace: <USE_DISPLAY_NAME>}
  - !<View> {name: Log, colorspace: lg10}
  - !<View> {name: Raw, colorspace: nc10}

displays:
  sRGB:
    - !<Views> [ ACES, Log, Raw ]
  Rec709:
    - !<Views> [ ACES, Log, Raw ]

display_colorspaces:
  - !<ColorSpace>
    name: sRGB
    from_display_reference: <omitted for brevity>
  - !<ColorSpace>
    name: Rec709
    from_display_reference: <omitted for brevity>

他のviewと同様、shared viewはactive_viewsのリストにひょうじされる(されない)ことがある。

active_display

optional
デフォルトでは全てのdisplayが表示sれ、display sectionの項目の順序を尊重する。
ここでは、UIで表示するdisplay deviceを選択し表示順を変更することができる。

```yaml
active_displays: [sRGB, DCIP3]


`DCIP3`のみ表示するには以下のように

```yaml
active_displays: [DCIP3]

この値は$OCIO_ACTIVE_DISPLAYの環境変数で上書きすることができる。

sRGBを唯一のアクティブディスプレイにすることもできる。

active_displays: [sRGB]

次にDCI P3プロジェクターを搭載したレビューマシン上で以下のように環境変数を更新して、DCIP3唯一の表示デバイスとする。

export OCIO_ACTIVE_DISPLAYS="DCIP3"

:で区切って複数のアクティブディスプレイを指定することも

export OCIO_ACTIVE_DISPLAYS="DCIP3:sRGB"

active_views

optional
デフォルトでは全てのviewが表示され、displayの元にあるviewの順序を尊重する。
active_displaysと同様に動作するが、どのviewを表示するかを制御する。

環境変数の$OCIO_ACTIVE_VIEWSの環境変数で上書きすることもできる。

export OCIO_ACTIVE_VIEWS="Film:Log:Raw"

virtual_display

optional

OCIOがICCプロファイルからアタrしいdisplayをinstance化できるようにvirtual displayを定義することができる。
構文は従来のdisplayに似ている。viewとshared viewの両方を組み込むことができる。
1つのconfigには1つのvirtual displayしかない。
OCIOがICC monitor profileからdisplayをinstance化するとdisplay_colorspaceが<USE_DISPLAY_NAME>に設定されているviewで使用されるdisplay_colrospaceが作成される。

従ってこの例では、アプリケーションがOCIOにICCプロファイルからdisplayをinstance化するように依頼すると、ユーザには "sRGB"に加えて、ICC profileにちなんだ名前の2番目のdisplayが表示されることになる。その新しいディスプレイで利用可能なviewは virtual displayから取得される。

displays:
  sRGB:
    - !<View> {name: ACES, view_transform: ACES-sdr-video,
               display_colorspace: <USE_DISPLAY_NAME>}
    - !<View> {name: Log, colorspace: lg10}
    - !<Views> [ Raw ]

virtual_display:
  - !<View> {name: ACES, view_transform: ACES-sdr-video,
             display_colorspace: <USE_DISPLAY_NAME>}
  - !<View> {name: Log, colorspace: lg10}
  - !<Views> [ Raw ]

Looks

looks

optional

このセクションでは "looks"のリストを定義する。
lookとは色空間と同様に定義される色変換のことだが、いくつか重要な違いがある。

例えば、最終的なグレードの大まかな近似値でショットを表示するために使用される, "first pass DI beauty grade"のためにlookを定義することができる。

Lookがconfigで定義される時、name, color transform, gradingが実行される色空間("Process space")を指定する必要がある。
look transformが自明に反転できない場合(3D LUTを適用する場合など)のためにオプションで逆変換を指定できる。

アプリケーションがルックを適用する際、OCIOはグレードが正しい色空間で適用されるようにする。
(入力色空間からprocess spaceに変換し、look transformを適用し、画像を出力色空間に変換)

looks:
  - !<Look>
    name: beauty
    process_space: lnf
    transform: !<CDLTransform> {slope: [1, 2, 1]}

  - !<Look>
    name: neutral
    process_space: lg10
    transform: !<FileTransform> {src: 'neutral-${SHOT}-${SEQ}.csp', interpolation: linear }
    inverse_transform: !<FileTransform> {src: 'neutral-${SHOT}-${SEQ}-reverse.csp', interpolation: linear }

ここでは"beauty" lookでシンプルな静的なASC CDL gradeを適用し、画像を緑色に変換する。
beauty lookはscene-linear lnf colorspaceで適用される。(このlnfはconfigの別な場所で定義されている。)

"neutral" lookの定義はshot-specific CSP LUTを適用し、SEQとSHOT context variableに基づいて正しいLUTを動的に見つける。
例えばSEQ=ab、SHOT=1234の場合、search_pathで指定された場所でneutral-ab-1234.cspというLUTを検索する。

ここでのprocess_spaceはlg10である。つまり、lookが適用されると、OCIOは以下のステップを実行する：

画像を現在の色空間からlg10 process spaceに変換
FileTransformを適用する(grade LUTを適用)
グレーディングされた画像をprocess spaceからoutput color spaceに変換

この例では"neutral" CSPファイルに3D LUTが含まれているため、"beauty" lookではoptionのinverse_transformを指定する。多くの変換の場合OCIOは自動的に逆変換を計算しますが,3D LUTの場合は逆変換を定義する必要がある。

もしルックが逆に適用され、inverse_transformが指定されていなければ、OCIOはhelpfulなerror messageを出す。これは反転不可能なlookに対してよく行われる。

colorspaceの定義と同様にtransformはGroupTransformなどを使って一連transformとして指定することができる。

looks:
  - !<Look>
    name: beauty
    process_space: lnf
    transform: !<GroupTransform>
      children:
        - !<CDLTransform> {slope: [1, 2, 1]}
        - !<FileTransform> {src: beauty.spi1d, interpolation: nearest}

Colorspaces

colorspaces

required
あちこちに使われているcolorspaceの定義をここで行う。

config内のscene-referred colorspacesのリストとなる。
色空間はconfig内の他の場所(他の　
colorspaceの定義も含む)で参照されることがあり、OCIOをサポートするアプリケーション内で使用される。

colorspace は下記のkeyを使う
to_scene_reference と from_scene_reference

これらのkeyはcolorspaceとscene-referred reference spaceとの関係を定義する変換を指定する。

下記がspi-vfxのconfigを修正したもの

colorspaces:
  - !<ColorSpace>
    name: lnf
    bitdepth: 32f
    description: |
      lnf : linear show space

  - !<ColorSpace>
    name: lg16
    bitdepth: 16ui
    description: |
      lg16 : conversion from film log
    to_scene_reference: !<FileTransform> {src: lg16_to_lnf.spi1d, interpolation: nearest}

最初のlnf(linear floatの略) colorspaceはrenference colorspaceとして使われる
名前は何でも大丈夫だが、renference colorspaceという考え方はOCIO重要なコンセプト。

他の全ての色空間はこの色空間へのまたこの色空間からの変換として定義される。

lg16 colorspaceは16bit log colorspace。(see spi-vfx for an explanation of this colorspace)

lg16 colorspaceはlg16からreference colorspace(lnf)への変換として定義される。その変換はLUT lg16_to_lnf.spi1dを適用することである。このLUTはlg16 integerを入力として、linear 32bit float valueとして出力する。

1DLUTはOCIOによって自動的に反転可能なので、このcolorspaceを使用してlg16画像をlnfに変換したり、lnf画像をlg16に変換したりすることができる。

重要なのはreference colorspaceのコンセプトがあること。画像をlg16からreference colorspaceに変換し、さらに他の色空間に変換できること。

他のexampleとしてfrom_scene_referenceを使って定義されている。

- !<ColorSpace>
  name: srgb8
  bitdepth: 8ui
  description: |
    srgb8 :rgb display space for the srgb standard.
  from_scene_reference: !<FileTransform> {src: srgb8.spi3d, interpolation: linear}

ここでfrom_scene_referenceを使うのはrefernce colorspace(この例ではlnf)からsRGBに変換するLUTがあるから。
このケースではsrgb8.spi3dは反転できない複雑な3D LUTなので、"表示専用"のcolorspaceとみなされる。
逆変換を適用する2つ目の3D LUTがある場合は、　to_scene_reference と
from_scene_referenceの両方を指定できる。

- !<ColorSpace>
  name: srgb8
  bitdepth: 8ui
  description: |
    srgb8 :rgb display space for the srgb standard.
  from_scene_reference: !<FileTransform> {src: lnf_to_srgb8.spi3d, interpolation: linear}
  to_scene_reference: !<FileTransform> {src: srgb8_to_lnf.spi3d, interpolation: linear}

using multiple transforms

複数の変換を使って、colorspaceを定義する例

- !<ColorSpace>
  name: srgb8
  bitdepth: 8ui
  description: |
    srgb8 :rgb display space for the srgb standard.
  from_scene_reference: !<GroupTransform>
    children:
      - !<ColorSpaceTransform> {src: lnf, dst: lg16}
      - !<FileTransform> {src: lg16_to_srgb8.spi3d, interpolation: linear}

reference colorspaceから取得するためにまず、ColorSpaceTransformを使ってlnfからlg16に変換し、
それから3DLUTをlog encodeされた画像を適用する。

これは主に2つ以上のtransformを単純に1つにまとめるtransform
meta-transform GroupTransformを示している。
FiletransformやCDLTransform のようなtransformをつけつけるものはGroupTransformも受け付ける。

ColorSpaceTransformはlnfとlg16の間で変換する。(現在のconfigの中で定義されている。)

Example transform steps

ここでOCIOが内部的に全ての変換を適用する方法を説明する。
reference colorspaceがどのように機能するかを理解していればここの説明はスキップして問題なし。

colorspaces:
  - !<ColorSpace>
    name: lnf
    bitdepth: 32f
    description: |
      lnf : linear show space

  - !<ColorSpace>
    name: lg16
    bitdepth: 16ui
    description: |
      lg16 : conversion from film log
    to_scene_reference: !<FileTransform> {src: lg16.spi1d, interpolation: nearest}

  - !<ColorSpace>
    name: srgb8
    bitdepth: 8ui
    description: |
      srgb8 :rgb display space for the srgb standard.
    from_scene_reference: !<GroupTransform>
      children:
        - !<ColorSpaceTransform> {src: lnf, dst: lg16}
        - !<FileTransform> {src: lg16_to_srgb8.spi3d, interpolation: linear}

例えば、 linear EXRのようなlnf colorspaceの画像をsrgb8に変換する場合、変換手順は次のようになる。

ColorSpaceTransformが適用され,
lnfからlg16に変換される。
FileTransformが適用されlg16からsrgb8に変換される。

Note

OCIO has an transform optimizer which removes redundant steps, and combines similar transforms into one operation.

In the previous example, the complete transform chain would be “lg16 -> lnf, lnf -> lg16, lg16 -> srgb8”. However the optimizer will reduce this to “lg16 -> srgb”.
https://opencolorio.readthedocs.io/en/latest/guides/authoring/authoring.html

encoding

optional
colorspaceの-数値エンコード方法を指定する。

色空間の基本的な符号化のタイプをすることができるのはアプリケーションにとって非常に有益。
例えば、様々な種類の画像処理アルゴリズムの性能がencodingの種類によって異なることはよく知られていて、scene-linear画像に空間フィルタを適用すると、log colorspaceでエンコードされた同じ画像に適用した場合とは異なる結果がえらえる。
同様に、keying, trackingのようなある種のアルゴリズムはcolor encodingが知覚的にほぼ隠逸であることを全体としているためscene-linearの画像では困難な場合がある。

許容される定義と値は

scene-linear
数値表現が輝度に比例するscene-referred encoding
e.g. ACES2065-1, ACEScg

display-linear
数値表現がディスプレイの輝度に比例するエンコーディング
e.g. 　ディスプレイやprojection screenから測定したCIE XYZ values

log
scene-referred encodingで、数値表現はシーンの輝度の対数にほぼ比例する。(多くのカメラの対数encodingのようにシャドウで若干の発散があることが多い。)
e.g. ACEScct, ACEScc, ARRI LogC, Sony S-Log3/S-Gamut3

sdr-video
数値表現がSDRビデオ信号に比例する。display-referred enconding
e.g. Rec709/Rec.1886 video , sRGB

hdr-video
display-referred encodingで、数値表現がHDR video信号に比例する。　
e.g. rec.2100/PQ, Rec.2100/HLG

data
色以外のチャンネル。一般的にこのような色空間では、isdata attributeもtrueに設定されることに注意
e.g. alpha , normals, Z-depth

bitdepth

optional
Default : 32f

colorspaceに適切なbit depthを指定すると、アプリケーションはこれを使用して、自動的に正しいbit深度で画像をしゅつリュオクすることができる。

8ui
10ui
12ui
14ui
16ui
32ui
16f
32f

ui はunsigned integer
fはfloating point

- !<ColorSpace>
  name: srgb8
  bitdepth: 8ui

  from_scene_reference: [...]

isdata

optional
Default : false. Boolean

colorspaceのisdata keyはマルチパス3Dレンダリングの"法線"出力など、color data以外のチャンネルにこのカラースペースを使用することをOCIOに通知します。

spi-vfx configの "non-color" colorspace

- !<ColorSpace>
  name: ncf
  family: nc
  equalitygroup:
  bitdepth: 32f
  description: |
    ncf :nc,Non-color used to store non-color data such as depth or surface normals
  isdata: true
  allocation: uniform

equalitygroup

optional

2つのcolorspaceが"equality group"にある場合、それらの間の変換は非演算とみなされる。

同じ色空間が複数あるかもしれないがbit depthは異なるなど。

spi-vfxの例ではconfigにあるlg10とlg16のcolorspaceを参照すると、lg10画像を読み込んでlg16に変換する場合、変換は必要ない。これはもちろん高速だが、予期せぬ精度の向上を引き起こす可能性がある。(例として、LUTによって引き起こされる潜在的なclampingをスキップする)

- !<ColorSpace>
  name: lg16
  equalitygroup: lg
  bitdepth: 16ui
  to_scene_reference: !<FileTransform> {src: lg16.spi1d, interpolation: nearest}

- !<ColorSpace>
  name: lg10
  equalitygroup: lg
  bitdepth: 10ui
  to_scene_reference: !<FileTransform> {src: lg10.spi1d, interpolation: nearest}

Do not put different colorspaces in the same equality group. For

似たcolorspaceを論理的にグループ化したい場合は、family optionを使う。

family

optional

論理的なcolorspacenグルーピングに使う。UI上での

例えば、一連の"log" colorspaceを1つのfamilyにまとめることができる。
Nuke OCIOcolorspaceノードのようなUIではこれらはグループ化される。

Menu Helpers APIを使用すると、アプリケーションはfamily keyに基づいて色空間の階層メニューを構築できる。
configのfamily_separator keyはfamily stringwo
トークンに区切るために使用する文字を定義するために使用される。

family_separator: /

color_spaces:
  - !<ColorSpace>
    name: ACME_log4
    family: Log/Cameras/ACME
    equalitygroup: ACME_log4
    [...]

  - !<ColorSpace>
    name: ACEScct
    family: Log/ACES
    equalitygroup: ACEScct
    [...]

  - !<ColorSpace>
    name: Rec.709
    family: Video/Broadcast/SDR
    equalitygroup: Rec.709
    [...]

equalgroupとは異なり、faimilyは画像処理に影響を与えない。UI上の問題。

aliases

optional

colorspaceの代替名(alternate names)を定義するために使用する。例えば、テクスチャpath名に含めるのが簡単な短いバージョンの名前を定義すると便利な場合がある。あるいは広報互換性のために色空間の名前の古いバージョンを定義する必要性があるかもしれない。

aliases: [shortName, obsoleteName]

allocation and allocationvars

optional

OCIO v1ではtransformがGPU上で適用される場合、これらの2つのオプションが使用されました。
しかし、OCIOv2の新しいGPUレンダラーではこれらは必要ありません。

しかし、明示的に指定されない限り、LUTをベイクする際に、"shapre LUT"を自動的に生成するために使用される可能性があります。(全ての出力フォーマットがこれを利用するわけではない。)

For a detailed description, see How to Configure ColorSpace Allocation

Example of a “0-1” colorspace

allocation: uniform
allocationvars: [0.0, 1.0]

allocation: lg2
allocationvars: [-15, 6]

description

optional
colorspaceの人間が読むための説明
YAMLのsyntaxでは1行の記述も可能

- !<ColorSpace>
  name: kodaklog
  [...]
  description: A concise description of the kodaklog colorspace.

multiple-lines

- !<ColorSpace>
  name: kodaklog
  [...]
  description:
    This is a multi-line description of the kodaklog colorspace,
    to demonstrate the YAML syntax for doing so.

    Here is the second line. The first one will be unwrapped into
    a single line, as will this one.

| でブロック構文を使って、全ての改行を保持するのが一般的

- !<ColorSpace>
  name: kodaklog
  [...]
  description: |
    This is one line.
    This is the second.

Display Colorspaces

display_colorspaces

optional

Tool Overview

基本用されているコマンドには -helpが使えることが多い
そこで引数の説明などが紹介され知れる
-vでさらに詳細なlogなどの説明が出てくるモードにすることができる。

ほとんどのtoolは$OCIO環境変数によりconfigファイルの設定が必要

OCIO 環境変数

$OCIO

*****.ocioやconfig.ocioで書かれている設定ファイルのpath
OCIOをサポートしているNukeやAE,houdini...etcなどではUI上でpathが設定できるようになっている。

$OCIO_ACTIVE_DISPLAYS

active_displaysをconfig fileから
e.g sRGB:P3

$OCIO_ACTIVE_VIEWS

active_views
e.g internal:client:DI

$OCIO_INACTIVE_COLORSPACES

inactive_colorspaces
e.g previousColorSpace:tempSpace

$OCIO_LOGGING_LEVEL

Configures OCIO’s internal logging level. Valid values are none, warning, info, or debug (or their respective numeric values 0, 1, 2, or 3 can be used)

Logging output is sent to STDERR output by defau

$OCIO_OPTIMIZATION_FLAGS

Overrides the optimization settings being used by an application, for troubleshooting purposes. The complete list of flags is in OpenColorTypes.h.

$OCIO_USER_CATEGORIES

Specify the color space categories that the application should show in color space menus. Note that this requires the application developer to implement support for categories (the easiest way is to use the code in apphelpers/ColorSpaceHelpers.h).

ocioarchive

This command-line tool allows you to convert a config and its external LUT files into an OCIOZ archive file. A .ocioz file may be supplied to any command that takes the path to a config or set as the OCIO environment variable.

This example creates a file called myarchive.ocioz:

$ ocioarchive myarchive --iconfig myconfig/config.ocio

This command will expand it back out:

$ ocioarchive --extract myarchive.ocioz

The –list option may be used to see the contents of a .ocioz file.

ociocheck

$ ociocheck --help
ociocheck -- validate an OpenColorIO configuration

usage:  ociocheck [options]

    --help        Print help message
    --iconfig %s  Input .ocio configuration file (default: $OCIO)
    --oconfig %s  Output .ocio file

OCIO config fileのoverviewを表示することができる。
--iconfig %sで.ocioのファイルを任意で読み込んでcheckすることができる。それ以外の場合は$OCIOのpathで読み込まれる

This is a command-line tool which shows an overview of an OCIO config file, and checks for obvious errors.

For example, the following shows the output of a config with a typo - the colorspace used for compositing_log is incorrect:
https://opencolorio.readthedocs.io/en/latest/guides/using_ocio/using_ocio.html#overview-ociochecklut

$ ociocheck --iconfig example.ocio

OpenColorIO Library Version: 0.8.3
OpenColorIO Library VersionHex: 525056
Loading example.ocio

** General **
Search Path: luts
Working Dir: /tmp

Default Display: sRGB
Default View: Film

** Roles **
ncf (default)
lnf (scene_linear)
NOT DEFINED (compositing_log)

** ColorSpaces **
lnf
lgf
ncf
srgb8 -- output only

ERROR: Config failed validation. The role 'compositing_log' refers to a colorspace, 'lgff', which is not defined.

Tests complete.

configファイルに定義されてる色変換が「正しい」ということを検証することはできないが、設定ファイルがOCIOにてエラーなく読み込めることは検証される。
検証される問題点には以下のようなものがある

色空間名の重複
未定義の色空間へのreference
Required roleの未定義
少なくとも一つのディスプレイデバイスが定義されている
v1の構成でv2の機能が使用されていない

It cannot verify the defined color transforms are “correct”, only that the config file can be loaded by OCIO without error. Some of the problems it will detect are:

Duplicate colorspace names

References to undefined colorspaces

Required roles being undefined

At least one display device is defined

No v2 features are used in a v1 config

https://opencolorio.readthedocs.io/en/latest/guides/using_ocio/using_ocio.html#overview-ociochecklut

ociochecklut

OCIOでサポートされているLUTを読み込むことができて
そのLUTのerrorや警告チェックができるのと
RGB or RGBAの値を指定すればその値がLUTを通してどう変化するかを出力することができる。
また、-tを指定するとあらかじめ定義されたテストRGB値がセットされてLUTを通して送信される。

ociochecklut -- check any LUT file and optionally convert a pixel

usage:  ociochecklut <INPUTFILE> <R G B> or <R G B A>

Options:
    -t           Test a set a predefined RGB values
    -v           Verbose
    -s           Print the output after each step in a multi - transform LUT
    --help       Print help message
    --inv        Apply LUT in inverse direction
    --gpu        Use GPU instead of CPU
    --gpulegacy  Use the legacy (i.e. baked) GPU color processing instead of the CPU one (--gpu is ignored)
    --gpuinfo    Output the OCIO shader program

OCIOCHECKLUT loads any LUT type supported by OCIO and prints any errors
encountered.  Provide a normalized RGB or RGBA value to send that through
the LUT.  Alternatively use the -t option to evaluate a set of test values.
Otherwise, if no RGB value is provided, a list of the operators in the LUT is printed.
Use -v to print warnings while parsing the LUT.

$  ociochecklut -v acescct_to_rec709.clf  0.18 0.18 0.18

OCIO Version: 2.0.0dev

Input  [R G B]: [      0.18      0.18       0.18]
Output [R G B]: [0.05868321 0.0586832 0.05868318]

Github

Config

Python

OCIOのinstall for Mac

Config file Syntax

Config header

ocio_profile_version

description

name

search_path

family_separator

viewing_rules

Displays & Views

displays

view_transform

default_view_transform

shared_views

active_display

active_views

virtual_display

Looks

looks

Colorspaces

colorspaces

using multiple transforms

Example transform steps

encoding

bitdepth

isdata

equalitygroup

Do not put different colorspaces in the same equality group. For

family

aliases

allocation and allocationvars

description

Display Colorspaces

display_colorspaces

Tool Overview

OCIO 環境変数

$OCIO

$OCIO_ACTIVE_DISPLAYS

$OCIO_ACTIVE_VIEWS

$OCIO_INACTIVE_COLORSPACES

$OCIO_LOGGING_LEVEL

$OCIO_OPTIMIZATION_FLAGS

$OCIO_USER_CATEGORIES

ocioarchive

ociocheck

ociochecklut

Discussion

Config file　Syntax