前回は、scene-referred環境でのCDL/.cccファイル運用を実務目線で整理しました。
.cccファイルとCCCIDを使った補正値の管理と、Flameでの適用方法についても確認しました。

今回は、ACES空間でCDLをどう位置づけると整理しやすいのかをまとめます。

目次 [ close ]
  1. scene-referredとdisplay-referred
  2. ACES色空間の役割整理
  3. CDLの位置づけ
  4. intermediate-referred（中間基準）という考え方
  5. ACES 1.3のRRTで勘違いしやすいポイント

scene-referredとdisplay-referred

まずは基本の整理です。

観点scene-referreddisplay-referred
基準現実の（撮影された）光モニタ表示
役割物理的に正しい情報見た目として成立させる
扱い明るさ・色がそのままトーンマッピング済み
具体例ACEScg / カメラ入力RRT + ODT / Rec.709


この2つを分けて考えるのがACESの基本です。

ACES色空間の役割整理

観点ACES2065-1ACEScgACEScct
役割受け渡し・保存作業（合成・CG）調整（グレーディング）
特徴最も広い色域（AP0）実務向け（AP1）logで扱いやすい（AP1）
基準scene-referredscene-referredscene-referred
エンコードscene-linearscene-linearscene-log
一言で「保管用」「作業用」「調整用」

ACESではすべてscene-referredで統一されており、linearとlogはあくまでエンコードの違いです。

まとめると：

  • デリバリー → ACES2065-1
  • 合成 → ACEScg
  • グレーディング → ACEScct

CDLの位置づけ

ここで一つ目の重要ポイントです。

CDLは、素材をACESに変換してから行う補正と考えると整理しやすくなります。

つまり：

  • カメラlogに直接ベイクするものではない
  • LUTの代わりでもない
  • 最終ルックを決めるものでもない

scene-referredの流れの中で使う軽い補正です。

ただし、ここで一つ引っかかります。

CDLで調整しているのに、最終的な見た目はそれだけでは決まらない。

では、見た目はどこで決まるのか？

この疑問を整理するために、もう一段レイヤーを挟みます。

intermediate-referred（中間基準）という考え方

実務では、次の3つに分けて考えると理解しやすくなります。

観点scene-referredintermediate-referreddisplay-referred
イメージ現実の光ネガ（中間）プリント（表示）
基準レンズを通った光作業・調整の基準モニタ表示
特徴リニア（1+1=2が成立）log的(対数)な扱い見やすく調整された状態
役割物理的に正しい情報補正・調整最終的な見た目
関係元データCDLが作用する場所RRTで変換される結果

デジタル運用
scene → intermediate（CDL） → display（RRT）

フィルム（ネガ）運用
撮影された光（scene） → ネガ（intermediate） → プリント（display）

デジタルのACES運用は、フィルム時代のネガ運用と同じ構造で捉えると理解しやすくなります。

なぜintermediateが必要なのか

レンズを通った光は、そのままリニアで扱うことができます。

1 + 1 = 2 が成立する世界（scene-referred）

ただし、このままだと作業には向きません。

  • 明るさのレンジが広すぎる
  • コントラストが強すぎる
  • 人間の感覚と合わない

そこで、作業しやすい形に変換した領域として、intermediate-referredが必要になります。

ただし、この状態はあくまで作業用です。

このままでは「最終的な見た目」にはなりません。

display-referredの役割

sceneとintermediateを正確に参照するための変換です。

  • sceneはそのままでは見づらい
  • intermediateは作業用であり最終見た目ではない

人間が確認できる見た目に変換する必要がある

これがdisplay-referredです。

CDLはどこに属するのか

CDLは、intermediate-referredのレイヤーで扱う

  • sceneそのものではない
  • displayの最終結果でもない

CDLは“見た目そのもの”ではなく、displayを通して確認しながら調整するための値として扱うのが自然です。

ACES 1.3のRRTで勘違いしやすいポイント

RRT本来の役割

RRTは、intermediateからdisplayへ変換するための処理です。

具体的には：

  • ハイライトのロールオフ
  • ダイナミックレンジの圧縮
  • トーンマッピング

つまり、ルックではなく、表示として成立させるための処理です。

自分（私）が勘違いしていたこと

  • RRTはルックを決めるもの
  • CDLやLUTと同じレイヤー
  • 見た目はODTだけで決まる

CDLとの関係

  • CDL → intermediate-referred
  • RRT → displayへの変換

この2つは役割がまったく異なります。

そして重要なのが、

CDLで調整した結果は、RRTを通して最終的な見た目として成立するという点です。

ここまで分かると整理できた気になりますが、
実際にはこの部分が一番分かりづらいところです。

なぜ混乱するのか

見えているもの（display）と、
実際に調整しているデータ（intermediate）がズレているためです。

  • RRTはユーザーから見えない
  • 常に裏でかかっている
  • Viewの中に含まれている

存在を意識しないまま結果だけ見ている

この“分かれている構造”自体が、混乱の原因になっているとも言えます。

では、この構造は今も同じなのかというと、
最近のACESでは少し考え方が変わってきています。

ACES 2.0ではどうなったか

  • RRTは廃止方向
  • Output Transformに統合

scene → displayをまとめて扱う方向に整理されています。

また、この背景にはHDR（nits）環境の影響もあります。

表示デバイスごとに輝度や見え方が大きく異なるため、
共通のトーンマッピング（RRT）では対応しきれなくなり、

出力ごとに最適化された変換としてまとめて扱う必要が出てきました。

まとめ

scene → intermediate（CDL） → display（RRT）

この3つのレイヤーで考えると、
ACES環境での補正と見た目の関係が整理しやすくなります。

CDLは調整用のデータであり、
最終的な見た目はRRTを通して成立します。

見えているものと、実際に調整しているデータは別のものです。
このズレが混乱の原因になります。

ACES 2.0では、この構造は一体化される方向に整理されています。

次回は、この考え方をFlameでの実際の運用に落とし込みます。