OCIO 显示变换与常见误解
引言
我经常想起 Doug Walker 在我们一次 OpenColorIO (OCIO) 会议上提出的那个绝佳问题:你试图解决什么问题? 那么,在我们的案例中,这篇文章是关于什么的呢?
在过去的一年(2021 年)里,我在线做了几次关于 OCIO 和 Academy Color Encoding System (ACES) 的演讲。我认为将这些幻灯片放到网上会很有用,原因有二:
- 如果存在任何不准确之处,任何人都可以纠正我,我将非常乐意更新此页面。
- 通过这些在线幻灯片,我希望能够接触到更多人,并提高大家对某些主题的认识。
我并不认为自己是一个专家。我不再相信这个词了。我们只是人类,尽我们所能去理解事物。我们会犯错,但希望我们能从中学习并继续前进。所以不,我不是任何方面的专家!
我唯一能提供的是一位艺术家对色彩管理的观点。很多时候,当涉及到 OCIO 和 ACES 时,我都不知该从何入手。因此,通过撰写这篇文章,我希望能与大家分享一些有用的信息。
我的书以两章关于色彩管理的内容开头是有原因的。它将为你创作美丽图像打下基础。 所以我认为,通过一系列视觉示例来比较各种 OCIO 配置,研究它们的优点和缺点,会很有趣。
真正的想法是回顾历史,但绝不评判这些历史上的 OCIO 配置。绝不! 向十多年前开发并与社区分享这些配置的所有人致以崇高的敬意。
一个伟大的社区
有些人可能会觉得这篇文章太浅显、无聊或过时。很可能!但我真的很有兴趣回到过去,撰写这篇关于 OCIO 和显示变换的历史分析。这篇文章主要是关于我自己的误解,但希望它也能帮助到其他人!
请注意,这里我只讨论 OCIOv1 配置。
首先,我要感谢美国电影艺术与科学学院 (AMPAS),因为没有他们,我可能永远不会发现色彩管理这个奇妙而精彩的世界。ACES 是我进入色彩管理的切入点,对此我永远感激不尽。
多亏了他们,我发现了这个由色彩爱好者和色彩科学家组成的惊人社区,我想亲自感谢以下各位的慷慨、分享以及对我问题的耐心解答:
- Troy Sobotka
- Jed Smith
- Daniele Siragusano
- Zach Lewis
- Sean Cooper
- Nick Shaw
- Alex Fry
- Kevin Wheatley
- Thomas Mansencal
- Shane Smith
拥有这样一群对色彩和显示变换充满热情、能够在午夜时分在线辩论 sRGB 或场景参考调色的人们,真的让人感到温暖。这是一个包容的社区,大家并非在所有事情上都意见一致,并且还有很多问题需要弄清楚……这真的很令人兴奋!
好了,名字就点到为止,让我们开始吧!耶!
术语的重要性
我怀着极大的谦卑写下这些文字,因为过去我完全错了,而且我可能对很多事情仍然不准确……但我正在学习,我认为我唯一的优势是能够把事情解释得足够简单,希望 CG 艺术家同行们能够理解我。
我将从这里开始介绍一些 OCIO 词汇,这样我们就能达成共识:
- 显示:具有其特性(原色、白点、EOTF、尼特值……)的显示器。
- 视图:我们观看图像的方式(ACES、Raw、Log、未色调映射……)。
- 外观:创意偏好或调色(在 ACES 术语中称为 LMT)。
这三个术语听起来可能非常基础,但对于接下来的内容来说至关重要。正如你可能知道的,我是一个相当务实的人。我喜欢用视觉和具体的例子来支持我的解释。因此,我们将从查看这两个 OCIO 配置 仓库开始,研究我们的不同选项:
(第 2/20 段)
- nuke-default
- spi-anim / spi-vfx
- Filmic Blender
- ACES
OCIO 配置示例
nuke-default
nuke-default 描述
为什么我们要从一个随 Nuke 6.3 在 2011 年发布的 OCIO 配置开始?首先,因为我相信它仍然在一些学校和小型工作室中使用。其次,因为它包含一个误导了我很久的选项。
displays:
default:
- !<View> {name: None, colorspace: raw}
- !<View> {name: sRGB, colorspace: sRGB}
- !<View> {name: rec709, colorspace: rec709}
- !<View> {name: rec1886, colorspace: Gamma2.4}
active_displays: [default]
active_views: [sRGB, rec709, rec1886, None]
这里我就不提“显示”是 default(什么?)以及“视图”实际上是传递函数这件事了……
让我们关注点别的!
启示 #1: 在这个配置中,重要的是要注意 Rec.709 传递函数是一个摄像机编码 OETF!它不是一个显示标准!我花了一段时间才弄明白这一点!所以大家所说的“Rec.709 显示器”实际上是一个“采用 BT.709 原色和 BT.1886 EOTF”的显示器。
这种摄像机编码设计用于直接驱动 CRT 广播显示器的输出,其 EOTF 约为 2.4。它的设计初衷是让画面在后来成为 BT.1886 和 sRGB 2.2 的显示器上看起来都合适。
来自一位色彩爱好者。
BT.709 与 BT.1886
这是我第一次接触 ACES 时的疑问之一。因为 Rec.709 (ACES) 输出变换比 sRGB (ACES) 的那个“对比度更低”(暂时找不到更好的词),这与 nuke-default 相反。以下是近似的 Gamma 值:
- BT.709 是摄像机编码 OETF(约 Gamma 1.95)。
- BT.1886 是 EOTF 输出显示(约 Gamma 2.4),并用于 Rec.709 (ACES) 输出变换中。
[…] 使用波浪号已成为区分纯幂函数和分段函数的常用简写方式,当指代显示 CCTF 时,有时是区分两者的唯一方法,如果作者没有明确使用“幂”或“分段”。例如,Baselight 区分“sRGB 显示 (2.2)”和“sRGB (~2.2)”。[…] 在用于 OCIO 的传递函数 LUT 的上下文中,BT.1886 就是精确的 Gamma 2.4。
感谢 Zach Lewis 的精确说明。
旧派 VS 新派
关于这一点,有几件事需要了解:
- 在你的查看器中使用“rec709”(“旧派”意图),你永远无法为所有值获得 1:1 的映射。因为通用幂函数的差异大致是一种“环境光/眩光补偿”!
- 如果你在纯 BT.1886 显示器上使用“rec1886”(“新派”意图),它就是 EOTF 的理想化逆变换。我们称之为无操作。
对于 BT.709/sRGB 分段编码通过适当的 2.2 幂函数转储的情况,也存在完全相同的问题。Daniele Siragusano 有一个关于这个具体问题的非常有趣的演讲。虽然有点技术性,但绝对值得一看!
在 2020 年,眩光补偿是显示渲染变换的一部分,不应存在于分发管道中。
Daniele Siragusano.
我们或许可以补充几点:我们永远不应该在没有进一步限定的情况下使用“Rec.709”或“BT.709”。因为“Rec.709”既可以指传递函数,也可以指一组原色。为了清晰起见,我们需要将传递函数与原色分开。
我还要快速提一下,“Gamma”这个词的使用是模糊的:它是一个希腊字母!它已经在太多不同的上下文中被使用。我现在尝试在适当的时候使用“幂函数/定律”或“传递函数”这些术语。
nuke-default 视觉示例
我们现在将使用这个配置查看一个 sRGB/BT.709 原色的渐变。它将展示一个被称为 “臭名昭著的 6 色” 的有趣现象。设置非常简单:在 Nuke 中,我垂直设置了一系列 sRGB/BT.709 原色,并且水平方向上每一列增加 1 档曝光。让我们来看看!

140_misconceptions_0010_srgb_sweep_FHD
启示 #2: 使用这个配置,无论你使用多少种颜色值,在显示时你总是会得到这六种颜色:红、绿、蓝、青、品红和黄。请注意这种行为,因为我们将在几种色彩管理工作流中观察到它。
对于 CGI 工作,应不惜一切代价避免使用此配置。它可能在某些边缘情况下有用,例如反照率纹理。但也就这些了!
一个友好的提醒……
spi-anim / spi-vfx
spi-anim 描述
在 OCIO 文档 中有一个关于 spi-vfx 配置的非常完整的描述(它就像是 spi-anim 的“姐妹”配置)。需要说明的是,这两个配置都来自 Sony Picture Imageworks (spi)。
由于本文重点关注显示变换,我们将看一下 spi-anim OCIO 配置中的“Film (sRGB)”视图。这里有一段简短的引用:
vd 空间是将线性图像数据映射到显示空间。变换的主要部分定义为一个单一的曲线,概念上分为两部分。第一部分是 ln 到 lg(线性到对数)的转换。第二部分是 lg 到 sRGB 的转换。这是基于配置文件中使用的 sRGB 胶片模拟 LUT 的中性通道响应。
spi-anim OCIO 配置为其“Film”视图使用一个 1D LUT。对于 sRGB 显示器,使用的 LUT 文件名为“vd16.spi1d”。以下是配置中的一个示例,我认为它使用了正确的 OCIO 术语:
(第 3/20 段)
displays:
DCIP3:
- !<View> {name: Film, colorspace: p3dci8}
- !<View> {name: Log, colorspace: lm10}
- !<View> {name: Raw, colorspace: nc10}
sRGB:
- !<View> {name: Film, colorspace: vd16}
- !<View> {name: Log, colorspace: lm10}
- !<View> {name: Raw, colorspace: nc10}
我们确实可以访问两种显示设备:“sRGB” 和 “DCIP3”。以及三种不同的渲染”查看”方式:“Film”、“Log” 和 “Raw”。这是一个简单且正确的 OCIO 设置,非常清晰易懂。
spi-anim 视觉示例
现在让我们来看一些渲染图!

140_misconceptions_0060_srgb_sweep_FHD
spi-vfx 描述
为了完整起见,我也使用了 spi-vfx OCIO 配置中的 “srgb8” 视图来处理相同的渲染。以下是来自 OCIO 文档 对其的描述:
srgb8 烘焙了 film3d 模拟 LUT。此表可用于 QuickTime 生成或输出到 sRGB 显示器。该变换是一个带有灰平衡补偿的 3D 胶片模拟表,因此 lg10 空间中的值 445,445,445 会被修改为 sRGB 中的等值 RGB。此外,LUT 经过缩放,使得最大白色上至少有一个颜色通道使用显示器的最大值。变换分三个部分进行。首先,线性数据被转换为显示对数空间。然后应用胶片模拟表。接着应用灰平衡和白点缩放补偿。此表设计用于在光线昏暗的办公室环境中,在 sRGB 显示器上进行评估。
spi-vfx 视觉示例
以下是我们用于对比的常规渲染图:

140_misconceptions_0110_srgb_sweep_FHD
供你参考,我的渲染没有使用任何合成技巧。光剑周围的”辉光”实际上是一个受网格光源影响的体积着色器。直接来自 Guerilla Render。
当我看到这些图像时,我真的真的真的非常惊讶……我没想到一个名为 “Film” 的显示变换会表现得那样!我的两个主要惊讶点是:
- sRGB/BT.709 原色并没有变成白色!
- 我们最终得到了”臭名昭著的 6”值,就像一个简单的 sRGB EOTF 一样!
这让我得出了这个震撼的结论……启示 #3:S 形曲线与”胶片感”行为毫无关系。当然,它会为图像增添漂亮的”对比度”并执行某种亮度查找。但这真的能被称为”胶片感”吗?我不确定……
对我来说,“胶片色调映射”意味着存在视觉上的”向白色过渡”(有些人称之为”高光去饱和”)。sRGB/BT.709 原色的光剑在使用”film3d 模拟 LUT”时没有变成白色,这在我看来是错误的。这告诉我也许这里还有其他因素在起作用!所以,是的,S 形曲线与”向白色过渡”无关。
我确实寻找了一个”胶片感”的参考来说明我的想法。而”Star Wars”是我能想到的最好例子。这是我期望我的光剑所具有的”外观”:一个白色的”核心”加上彩色的辉光。

(第 4/20 段)
140_misconceptions_0160_light_sabers_FHD
同意,这些 OCIO 配置有点旧了,但一些小型工作室仍在使用。而且我很喜欢做这种 OCIO 考古,因为在这个过程中我们能学到很多东西。
边界情况?
有人可能会说我的例子是边界情况:“嘿 Chris,你这个笨蛋,用 0.001 代替 0 不就行了!” 这确实没错。限制输入颜色的范围以获得某种“通向白色的路径”是一种常见且已知的做法。但这难道不揭示了什么吗?

140_misconceptions_0170_srgb_sweep_FHD
需要明确的是,在这些例子中,我甚至没有使用任何广色域渲染。而是使用了最低公分母:通过几种显示变换的 sRGB/BT.709 原色。由于激光是 BT.2020 原色,我认为使用 sRGB/BT.709 原色并不是边界情况。完全不是!
我认为,任何人都不应该为了规避错误而去克服刺激编码。
一位色彩爱好者。
但是,当然,我们需要把情况放回其背景中来看。索尼的这两个配置在 2011 年做得非常出色,为诸如《Cloudy with a chance of meatballs》等精彩电影提供了色彩管理。重申一下,我只是试图挖掘一点历史,以理解我自己的误解从何而来。仅此而已。
VFX 配置是基于胶片扫描 Cineon 的……而动画配置则使用每通道 1D LUT 进行显示渲染变换。spi-vfx 早已过了保质期……spi-anim 对于简单的动画制作仍有参考价值,但其简单的 RGB 色调曲线会让它们在多交付场景中感到不适。
Sean Cooper 的精彩总结。
更近一些,电影《My Little Pony》就是使用 spi-anim OCIO 配置完成的:
Filmic Blender
Filmic Blender 描述
这不是最容易上手的 OCIO 配置,但它实际上超级简单。而且是一个非常棒的选择!我强烈建议阅读 GitHub 上的 README,因为它准确地描述了“Filmic”的作用。
它将场景参考的线性辐射能量值压缩到显示/输出参考的范围。这个方面被称为传递函数或色调映射。Filmic Base Log 的形状具有一种对比度美学,大致模拟了摄影胶片曲线。
它压缩高亮度值的色域。随着颜色比值强度的增加,高饱和度的比值往往对传递函数压缩有抵抗力,这会导致图像感觉怪异,某些区域感觉曝光过度恰到好处,而其他区域则“滞后”。Filmic 将所有颜色值视为公平游戏,并尝试将颜色混合成一致的输出,以匹配我们从胶片乳剂类媒体中学到的预期。
Troy Sobotka 的精彩描述。
Filmic Blender 显示与视图
不用说,“Filmic” OCIO 配置可以在任何支持 OCIO 的 DCC 软件中工作。让我们快速看一下配置中可用的显示和视图:
displays:
sRGB:
- !<View> {name: sRGB OETF, colorspace: sRGB OETF}
- !<View> {name: Non-Colour Data, colorspace: Non-Colour Data}
- !<View> {name: Linear Raw, colorspace: Linear}
- !<View> {name: Filmic Log Encoding Base, colorspace: Filmic Log Encoding}
BT.1886:
- !<View> {name: BT.1886 EOTF, colorspace: BT.1886 EOTF}
- !<View> {name: Non-Colour Data, colorspace: Non-Colour Data}
- !<View> {name: Linear Raw, colorspace: Linear}
- !<View> {name: Filmic Log Encoding Base, colorspace: BT.1886 Filmic Log Encoding}
Apple Display P3:
- !<View> {name: sRGB OETF, colorspace: AppleP3 sRGB OETF}
- !<View> {name: Non-Colour Data, colorspace: Non-Colour Data}
- !<View> {name: Linear Raw, colorspace: Linear}
- !<View> {name: Filmic Log Encoding Base, colorspace: AppleP3 Filmic Log Encoding}
# VRay 用户应取消注释下面的 Filmic 视图,因为 VRay 不允许使用 Looks
# - !<View> {name: Filmic Very High Contrast, colorspace: Filmic Log Encoding, look: +Very High Contrast}
# - !<View> {name: Filmic High Contrast, colorspace: Filmic Log Encoding, look: +High Contrast}
# - !<View> {name: Filmic Medium High Contrast, colorspace: Filmic Log Encoding, look: +Medium High Contrast}
# - !<View> {name: Filmic Very Low Contrast, colorspace: Filmic Log Encoding, look: +Very Low Contrast}
# - !<View> {name: Filmic Medium Low Contrast, colorspace: Filmic Log Encoding, look: +Medium Low Contrast}
# - !<View> {name: Filmic Low Contrast, colorspace: Filmic Log Encoding, look: +Low Contrast}
# - !<View> {name: Filmic Base Contrast, colorspace: Filmic Log Encoding, look: +Base Contrast}
# - !<View> {name: Filmic False Colour, colorspace: Filmic Log Encoding, look: +False Colour}
# - !<View> {name: Debug, colorspace: Debug}
(第 5/20 段)
与 spi-anim/vfx OCIO 配置类似,其中的显示设备和视图也是根据 OCIO 术语正确设置的。但这里还有一个可用的元素:Looks。如果你不习惯它们,可能会感到不安。让我们再次查看文档:
这个基本视图(Filmic Log Encoding Base)的设计初衷是与其中一个对比度外观(Look)配合使用。
但这里有一个小问题。只有少数 DCC 软件允许交互式的“外观覆盖(Look Overrides)”:Blender 和 Renderman 24。因此,大多数用户会修改 OCIO 配置,将“Look”与“View”合并作为一种变通方法。
OCIO 观看体验与角色
在本文发布时,下面的揭示引起了一些波澜。因此我已尽力更新,使其尽可能准确。
如今,据我所知,OCIO 本身在所有 DCC 中的行为方式确实是相同的,至少自 2017 年以来一直如此——也就是说,观看体验在不同 DCC 之间是一致的。对于大多数人来说,这基本上是 OCIO 最重要的一点——一旦你为某个项目或设施设置了 OCIO 配置,你就可以依赖 DCC 对 OCIO 的实现,在整个流程中提供一致的观看体验,无需任何额外的技术干预。
由 Zach Lewis 提供的恰当解释。
揭示 #4:OCIO 并不是在所有软件中都以完全相同的方式实现的。是的,这很重要!随着 OCIOv2 的出现,正在努力尝试将其规范化。但如果你看看“color_picking”这个角色,它在 Maya 和任何其他 DCC 软件中的行为并不相同!
OCIO 实现与用户体验
为了清晰起见,我重申一遍:是的,OCIO 在不同 DCC 之间提供了一致的观看体验。但也值得注意的是:
在 OCIOv1 中,GPU 和 CPU 路径处理颜色的方式存在一些细微差异,因此如果一个 DCC 使用 GPU 路径而另一个仅使用 CPU 路径,这将在不同 DCC 之间造成细微的非视觉差异;但我认为,如果暗示 DCC 无法在不同 DCC 之间提供一致的观看体验,那是不诚实的。
Rv 是这种行为的一个明显例子。感谢 Zach!
所以,我认为我在“实现”这个术语中纠缠了几件事:
- 大多数 DCC 软件不允许交互式的“外观覆盖(Look Overrides)”,比如一个下拉菜单让你可以轻松地从列表中选择它们。这更多是一个用户体验问题。
- DCC 可能使用不同的 OCIO 角色,或者将相同的角色用于不同的目的(“reference”和“color_picking”是模糊的)。我个人认为这是一个实现问题。
- 在 OCIOv1 中,CPU 和 GPU 处理器之间存在一些视觉差异,可能会让你有点头疼。这在 OCIOv2 中已经修复。
编辑 OCIO 配置
因此,如果你想在 OCIO 配置中使用“Looks”,有一个简单的方法。大多数用户采用这种变通方法,看起来像这样:
displays:
sRGB:
- !<View> {name: sRGB OETF, colorspace: sRGB OETF}
- !<View> {name: Non-Colour Data, colorspace: Non-Colour Data}
- !<View> {name: Linear Raw, colorspace: Linear}
- !<View> {name: Filmic High Contrast, colorspace: Filmic Log Encoding, look: High Contrast}
active_displays: [sRGB]
active_views: [Filmic High Contrast, Non-Colour Data]
如你所见,根据你的需求修改 OCIO 配置非常简单。只需在记事本中打开它,你就可以直接编辑! 这就是我们的揭示 #5:建议编辑标准的 OCIO 配置。所以不要害怕深入其中!
这个帖子对此解释得非常清楚:
通过文本编辑器编辑标准 ACES 配置来制作自定义配置是非常常见的做法。[…] 不仅如此,而且是推荐的!ACES 配置的目标之一始终是作为人们根据自己需求进行定制的起点。
Nick Shaw 和 Thomas Mansencal 说得对!
Filmic Blender 视觉示例
让我们用 Filmic 来看看我们的图像!

140_misconceptions_0220_srgb_sweep_FHD
一些观察:
- 光剑是白色的!耶!
- 我们最终还是落在了“臭名昭著的 6”上!不!为什么?
如果你想知道哪部动画长片电影是由 Troy 的 Filmic 进行色彩管理的,这里有一部很棒的电影“Next Gen”的预告片(我很喜欢它!):
另一个使用 Filmic 完成的非常令人印象深刻的项目是短片“The Witness”(来自“Love, Death & Robots):
让我们继续我们的调查,看看是否能找到更多问题的答案!
ACES
ACES 显示设备与视图
我已经写过关于 ACES 的完整章节……所以我将尝试在这里提供一些新信息。
首先,如果我们看一下 ACES 1.2 OCIO 配置,你可能会注意到一些奇怪的地方。揭示 #6:在 ACES OCIOv1 配置中,显示设备和视图被颠倒/互换了。这在我尝试学习 OCIO 时让我有点头疼。以下是当前配置中的一个示例:
displays:
ACES:
- !<View> {name: sRGB, colorspace: Output - sRGB}
- !<View> {name: DCDM, colorspace: Output - DCDM}
- !<View> {name: DCDM P3D60 Limited, colorspace: Output - DCDM (P3D60 Limited)}
- !<View> {name: DCDM P3D65 Limited, colorspace: Output - DCDM (P3D65 Limited)}
- !<View> {name: P3-D60, colorspace: Output - P3-D60}
- !<View> {name: P3-D65 ST2084 1000 nits, colorspace: Output - P3-D65 ST2084 (1000 nits)}
- !<View> {name: P3-D65 ST2084 2000 nits, colorspace: Output - P3-D65 ST2084 (2000 nits)}
- !<View> {name: P3-D65 ST2084 4000 nits, colorspace: Output - P3-D65 ST2084 (4000 nits)}
- !<View> {name: P3-DCI D60 simulation, colorspace: Output - P3-DCI (D60 simulation)}
- !<View> {name: P3-DCI D65 simulation, colorspace: Output - P3-DCI (D65 simulation)}
- !<View> {name: P3D65, colorspace: Output - P3D65}
- !<View> {name: P3D65 D60 simulation, colorspace: Output - P3D65 (D60 simulation)}
- !<View> {name: P3D65 Rec.709 Limited, colorspace: Output - P3D65 (Rec.709 Limited)}
- !<View> {name: P3D65 ST2084 108 nits, colorspace: Output - P3D65 ST2084 (108 nits)}
- !<View> {name: Rec.2020, colorspace: Output - Rec.2020}
- !<View> {name: Rec.2020 P3D65 Limited, colorspace: Output - Rec.2020 (P3D65 Limited)}
- !<View> {name: Rec.2020 Rec.709 Limited, colorspace: Output - Rec.2020 (Rec.709 Limited)}
- !<View> {name: Rec.2020 HLG 1000 nits, colorspace: Output - Rec.2020 HLG (1000 nits)}
- !<View> {name: Rec.2020 ST2084 1000 nits, colorspace: Output - Rec.2020 ST2084 (1000 nits)}
- !<View> {name: Rec.2020 ST2084 2000 nits, colorspace: Output - Rec.2020 ST2084 (2000 nits)}
- !<View> {name: Rec.2020 ST2084 4000 nits, colorspace: Output - Rec.2020 ST2084 (4000 nits)}
- !<View> {name: Rec.709, colorspace: Output - Rec.709}
- !<View> {name: Rec.709 D60 sim., colorspace: Output - Rec.709 (D60 sim.)}
- !<View> {name: sRGB D60 sim., colorspace: Output - sRGB (D60 sim.)}
- !<View> {name: Raw, colorspace: Utility - Raw}
- !<View> {name: Log, colorspace: Input - ADX - ADX10}
(第 6/20 段)
在上面的例子中,Display 显示为“ACES”,这是不正确的,因为我们并没有购买 ACES 显示器……而 Views 显示为“sRGB”、“Rec.709”或“P3D65”,这些基本上都是“显示器”。这应该反过来才对!
确实,OCIOv2 配置正在修复这些问题,这很棒!它们很快就会在这里提供。
谢谢你,Thomas!
好消息是,修复起来超级简单!如果你不想在 Nuke 或 Maya 中看到很长的“Display”菜单,你可以直接修改 OCIO 配置文件。让我们来看看!例如,以下是默认 ACES 1.2 OCIO 配置中的“active_displays”和“active_views”:
active_displays: [ACES]
active_views: [sRGB, DCDM, DCDM P3D60 Limited, DCDM P3D65 Limited, P3-D60, P3-D65 ST2084 1000 nits, P3-D65 ST2084 2000 nits, P3-D65 ST2084 4000 nits, P3-DCI D60 simulation, P3-DCI D65 simulation, P3D65, P3D65 D60 simulation, P3D65 Rec.709 Limited, P3D65 ST2084 108 nits, Rec.2020, Rec.2020 P3D65 Limited, Rec.2020 Rec.709 Limited, Rec.2020 HLG 1000 nits, Rec.2020 ST2084 1000 nits, Rec.2020 ST2084 2000 nits, Rec.2020 ST2084 4000 nits, Rec.709, Rec.709 D60 sim., sRGB D60 sim., Raw, Log]
所以,如果我们想缩短这个长长的选项列表并修复“Display/View”菜单,你可以简单地这样做:
displays:
sRGB:
- !<View> {name: ACES, colorspace: out_srgb}
- !<View> {name: Raw, colorspace: raw}
- !<View> {name: Log, colorspace: acescct}
active_displays: [sRGB]
active_views: [ACES, Raw, Log]
另外,如果你还不知道,有一个 ACES 1.1 OCIOv1 CG 配置(非常轻量,小于 48 MB)可以在 CAVE ACADEMY 网站上找到。例如,它可以用于全 CG 项目。
ACES 视觉示例
现在来看看我们的图像!

140_misconceptions_0270_srgb_sweep_FHD
嗯,发生了什么?有两个有趣的现象值得注意:
- 光剑是白色的!但红色的光剑变成了橙色,绿色的变成了黄色,蓝色的霓虹灯变成了品红色……这被称为色相偏移。它基本上是一种“Look”。
- 我们仍然观察到色相路径趋向于“臭名昭著的 6 个值”!不!为什么?
我们稍后会详细讨论“ACES Look”。但重要的是要注意,这个 Look 是嵌入在输出变换中的。你无法摆脱它。
为了完整起见,这次我将使用 ACEScg 原色运行相同的渲染。让我们看看!

140_misconceptions_0320_acescg_sweep_FHD
可以观察到相同的现象……通过使用 ACEScg 原色,我们可以看到:
- 色域裁剪。
- 我们最终仍然落在“臭名昭著的 6 个值”上,就像 sRGB EOTF 一样!为什么这种情况会持续发生?
启示 #7:与我过去可能写过的内容相反,ACES 输出变换并没有解决任何问题。我们在 ACES 中观察到的行为与其他 OCIO 配置类似。
很难确切知道哪些项目使用了 ACES 输出变换。所以我只添加一个链接到这个视频游戏,因为它已经在 ACESCentral 上得到确认:
(第 7/20 段)
位于阿维尼翁的法国学校 ENSI 也直接使用了 ACES。以下是他们的一部短片:
我花了一些时间才理解这一点:“变白”(例如光剑上的效果)本身并不是目的。我将用粗体并强调这一点,因为它至关重要……启示 #8:出现这些“变白”的扫光,并不一定意味着显示变换工作正常。路径本身才是关键! 这正是事情变得棘手又精彩的地方!
对比与总结
我们通过一些视觉示例比较了四种 OCIO 配置。以下是每种配置优缺点的小结。
| 优点 | 缺点 | 日期 | |
| nuke-default | 非常轻量,小于 3 MB。 | 在 CGI 工作中应不惜一切代价避免使用。在某些边缘情况下有用,例如反照率纹理。 | 2011 |
| spi-anim/vfx | 非常轻量,小于 30 MB。 用于多部 Sony 电影。免费。 | 在 sRGB/BT.709 原色下没有“变白”路径。“臭名昭著的 6”。无广色域渲染。无 HDR 显示变换。 | 2011 |
| Filmic Blender | 非常轻量,小于 20 MB。“变白”路径。对比度外观。免费。 | “臭名昭著的 6”。无广色域渲染。无 HDR 显示变换。 | 2017 |
| ACES 1.2 | 跨平台“标准”。广色域渲染。免费。 | 非常庞大,超过 1.89 GB。“臭名昭著的 6”。色相偏移。色域裁剪。色彩外观不匹配。 | 2014 – 2021 |
我们是不是可以就此打住了?我们已经比较了几种 OCIO 配置,指出了它们的优点和缺陷。因此,图像制作者在选择色彩管理工作流程时可以做出明智的选择。我们甚至可以用这句精彩的话来收尾:
每种方法都反映了一个时代的精神。
这是 Daniele Siragusano 的一句名言。Zeitgeist 指的是特定历史时期通过当时的思想和信仰所展现出的时代精神或氛围。
但是不……我们不能停在这里,我们只走了一半。我们需要更深入地挖掘,以理解“臭名昭著的 6”从何而来,以及色调映射的真正含义。
那么,到目前为止我们学到了什么?
- 我们比较了几种色彩管理的 OCIO 配置。
- 它们都表现出相同的“臭名昭著的 6”行为。
- 也许是因为它们都使用了相同的基本机制!
- 那么这些机制从何而来?让我们看看……
迷失在误解中
在 ACES 输出变换 VWG 的背景下,我们被挑战 去定义一些术语,例如“色调”或“胶片感”。由于我无法精确地定义它们,我想回到我第一次听到这些术语的时候。友情提醒:是的,我的目标仍然没变!理解我自己的误解是如何在过去 15 年里将我引向错误道路的。
以下是我在 2021 年一直折磨自己的几个问题:
- 我第一次听说色调映射是什么时候?
- 色调映射到底是什么意思?它做什么?
- S 曲线做什么?
- “胶片感”到底是什么意思?
所有这些概念可能看起来负载过重,但我很好奇,想质疑我对它们的全部认知。有趣的是,我对它们中的大多数都理解错了! 所以,让我们回到过去,开始另一段关于色彩的精彩旅程。
一点历史
我第一次听到“色调映射”这个词是在 2012 年的 Axis Studios……它们出现在这篇关于 Mass Effect 3 和 Digic Pictures 的 fx guide 文章中。当时让我非常困惑!
然后在 Illumination,我又听到了这些术语!它们来自 John Hable 在 GDC 上关于 Uncharted 2 的演讲(视频 和 幻灯片),这可能是行业内的一个游戏规则改变者!在他的演讲中,John Hable 描述了一个名为“Filmic”的 1D LUT,它最初来自 Haarm-Pieter Duiker(这是他的两个演讲:一个在 Electronic Arts 和 一个在 SIGGRAPH 2010)。
启示 #9:这个 1D s 曲线 LUT 并不是应用在开放域上,也就是无限值或场景线性值上。它是应用在对数值上的!

140_misconceptions_0370_log_color_FHD
所以早在 2010 年他的第二次演讲中,Haarm-Pieter Duiker 就已经承认了 1D LUT 的局限性,并提到了色域映射!
这个色域映射/压缩的事情似乎很重要……
逐通道方法
那么,以下是起作用的基本机制:
- “胶片感 s 曲线”是一个 1D LUT……
- 分别应用于 R、G、B 通道……
- 这被称为逐通道/RGB 查找……
- 并且它总是会导致“臭名昭著的 6”!
启示 #10:任何渐近线/收敛/饱和于 1 的曲线,比如这个“胶片感 s 曲线”,最终都会导致“臭名昭著的 6”。
通用的逐通道方法意味着获取光线发射数据,并通过某种曲线逐个通道地渲染它们。也就是目前普遍使用的有缺陷的现有方法。
一位色彩爱好者。
如果这还不够清楚:
逐通道(或 RGB)查找是一种扭曲且产生色阶的解决方案,它不尊重原始比例关系。它改变了预期光线混合的“色相”,改变了“饱和度”,也改变了“亮度”。
一位色彩爱好者。
(第 8/20 段)
没有什么比 CIE 1976 色度图更能说明正在发生什么了。但在那之前,我强烈建议阅读 Troy Sobotka 的 Question#15 和 Question#16。它非常清楚地解释了 CIE 1976 色度图是什么。并且它有一张 非常酷的图,展示了“光谱光能量”(即波长)与“数字”(即色度)之间的联系。必读!
图表与色度图
让我们看一些图表:

140_misconceptions_0400_chromaticity_paths_FHD
启示 #11:我过去 15 年打光、渲染和显示的所有场景,都带有“臭名昭著的 6 种”外观。是的,这是个重磅炸弹!我花了一段时间才接受它,几乎像是一种信仰的飞跃:我从未见过编码后的颜色。它们总是在显示时被一个“胶片化 S 曲线 1D LUT”扭曲了。天哪。
这就是我过去 15 年的工作方式:
大多数 CG 艺术家并不完全理解图像数据为显示设备渲染时会发生什么,并假设那就是“正确的颜色”。然后他们与那些不理解“奇怪的东西”作斗争,直到最终得到他们满意的东西。
Jed Smith。
冒着重复自己的风险,我在这里补充一个类似的解释:
但在最基本的层面上,是的,你可能从未见过与纹理艺术家投入大量心血的作品相匹配的刺激。他们只是在“LUT 下”查看他们的作品,并制作出他们认为可以接受的东西。
一位色彩爱好者。
图表使用的数值
为了非常清楚地说明每个图表使用了哪些数值,这里回顾一下“红色到黄色臭名昭著的 6 种渐变”中使用的颜色:
| 色彩管理 | 渐变原色 | R | 更多 G | 更多 G | 更多 G | 更多 G | Y |
| Filmic Hable | sRGB | 1, 0.00001, 0.00001 | 1, 0.0001, 0.00001 | 1, 0.0003, 0.00006 | 1, 0.0003, 0.0001 | 1, 0.0003, 0.0002 | 1, 1, 0.00001 |
| spi-anim | sRGB | 1, 0.00001, 0.00001 | 1, 0.0001, 0.00001 | 1, 0.0003, 0.00006 | 1, 0.0003, 0.0001 | 1, 0.0003, 0.0002 | 1, 1, 0.00001 |
| spi-vfx | sRGB | 1, 0.00001, 0.00001 | 1, 0.0001, 0.00001 | 1, 0.0003, 0.00006 | 1, 0.0003, 0.0001 | 1, 0.0003, 0.0002 | 1, 1, 0.00001 |
| Filmic High Contrast | ACEScg | 1, 0, 0 | 1, 0.003, 0 | 1, 0.01, 0 | 1, 0.05, 0 | 1, 0.2, 0 | 1, 1, 0 |
| sRGB (ACES) | ACEScg | 1, 0, 0 | 1, 0.05, 0 | 1, 0.2, 0 | 1, 0.5, 0 | 1, 0.8, 0 | 1, 1, 0 |
| sRGB (ACES) | ACEScg | 1, 0, 0 | 1, 0.005, 0 | 1, 0.015, 0 | 1, 0.03, 0 | 1, 0.1, 0 | 1, 1, 0 |
请注意,为了得到这些“清晰可读”的图表,我不得不使用多么疯狂的小数值……太疯狂了!我们稍后会使用常规步长做更多图表,这样你就能看到差异了!
更多关于每通道的信息
那么我们注定如此吗?既然所有这些开源方法都使用相同的机制。好吧,让我们看看其他的渲染解决方案?
等等,什么?渲染解决方案?你什么意思?像 Arnold、Renderman 或 Guerilla Render 吗?不,我在这里说的是一种完全不同的渲染操作。所以在我们研究这些其他可能性之前,我们需要谈谈一些超级重要且令人震惊的事情……系好安全带!
渲染 exr 文件
当我刚进入这个行业时,我的主管 Barbara Meyers 给了我关于“渲染”的这个绝佳定义:
渲染是从 3D 场景(你最喜欢的 DCC 应用程序)到 2D 图像的转换。
我花了 15 年才意识到这个定义可以一分为二,因为在 CG 世界中实际上有两种不同类型的渲染!是的!这非常重大!让我们深吸一口气,好好解释一下。
当你在 3D 软件中点击“渲染”并等待采样发生时,你生成的是什么?很可能,你会从批量渲染中保存 exr 文件。这个 exr 文件能被看作是一张图像吗?嗯,不完全是……只有当它在“显示器”上被“查看”时,它才成为一张图像。
启示 #12:一个“最终合成”exr 文件不是一张图像,它是一个包含光数据的文件。只有当它在你的显示器上显示时,它才成为一张图像。因此有了“图像形成链”这个说法:我们正试图从“光数据”中形成/创建一张可以在“显示器”上“查看”的图像。
EXR 是数据编码。它们可以包含法线、深度、随机光谱数据,你能想到的都可以。
一位色彩爱好者。
两种类型的渲染
因此,我们可以在 CG 中区分两种类型的渲染。就像这样:
3D 场景 -> 数据 -> 图像
启示 #13:CG 中有两种渲染操作。第一种是从场景到数据,第二种是从数据到图像。
这里有一些快速的定义,以防不够清楚:
- 场景渲染:这就是我过去十五年一直在做的事情……点击“渲染”,等待采样发生并生成一个 exr 文件。这可能需要几个小时。
- 显示渲染:然后加载这个 exr 并在你的渲染视图中显示它,可能使用 OCIO……是的!这是一个色彩渲染操作,很可能是实时的。
如果你不相信,只需想想我们从这篇文章开始以来一直在做的事情。同一个“最终合成”exr 可以生成许多不同的图像。它们只是光数据。
而最精彩的部分来了!这两种渲染操作都依赖于原色!是的,这很疯狂!启示 #14:在不同的原色上应用 S 曲线会产生不同的结果。砰!太震撼了!
(第 9/20 段)
自定义显示渲染原色实验
因此,当我们谈论“显示变换”或 Baselight 所称的“显示渲染变换”时……我们必须承认这些词有其特定含义:
- 显示:指监视器/屏幕。
- 渲染:从数据到图像的过程。
- 变换:我们需要将值从场景参考转换为显示参考(涉及原色、白点、EOTF 等的改变)。
Jed Smith 做了一个惊人的分通道实验,展示了原色对于“显示渲染”的重要性。这是一个基于 ARRI K1S1 模型的超级简单设置,Jed 在此描述道:
[ARRI K1S1 是] 本质上是在 Alexa Wide Gamut 中进行色调映射,并包含一个显示编码,其中包含一个自定义的 AWG → Rec.709 矩阵,该矩阵会稍微降低红色和绿色原色的饱和度。因此,我决定借鉴这种简单而高效的显示变换方法,创建自己的版本。我搭建了一个小装置,让你可以使用一个 2D 位置旋钮来定位三个原色的坐标,然后它会自动计算一个矩阵,将输入的图像转换到这个“自定义渲染色域”中。
Jed Smith 的另一个惊人实验!
以下是一些示例,比较了在 RED Wide Gamut 原色和 ACEScg 原色上应用色调映射的效果:

140_misconceptions_0520_srgb_sweep_FHD
很疯狂,对吧?这是完全相同的设置,只是使用了不同的“显示渲染”原色来应用色调曲线。以下是操作步骤列表:
- 首先,我们选择输入的源色域。在这个例子中,是 ACEScg。
- 然后,我们转换到某个“显示渲染”原色。使用一个简单的 3×3 矩阵。
- 接着,我们应用色调映射。在这个例子中,是“Siragusano”色调映射。
- 最后,我们再次使用一个简单的 3×3 矩阵转换回“显示色域”。
为了更清晰,这里有一句精彩的引言:
工作空间(原色)和显示渲染变换需要一起考虑。
Daniele Siragusano.
ARRI ALF-2
那么,回到我们的主线。让我们看看另一种渲染解决方案。我很想谈谈 ARRI K1S1,因为它可能是最著名的色彩渲染解决方案。但我无法基于它生成一个 OCIO 配置文件。所以,我将使用它的新版本作为例子:ARRI Look File 2 (ALF-2),它与 K1S1 非常相似。
ALF-2 变换在美学上与 K1S1 相差不远,并且包含了 HDR 版本。据我所知,K1S1 本身只有 SDR 版本。K1S1 非常简单。Harald 在这里几乎解释了它的全部内容。
来自 Nick Shaw。
Jed Smith 非常友好地在这里总结了整个 K1S1 过程:
场景线性 AWG -> 色调映射到显示线性 AWG -> 3x3 矩阵转换到 BT.709 -> 3x3 矩阵 10% BT.709 加权去饱和度 -> 带有线性延伸的自定义 2.4 幂次逆 EOTF
如果你好奇的话,这里是两个 K1S1 矩阵:
ALEXA Wide Gamut 到 ITU-R BT.709:
[[ 1.61752447 -0.53728621 -0.08023815]
[-0.07057271 1.33461286 -0.26404021]
[-0.02110205 -0.22695361 1.24805592]]
ALEXA Wide Gamut 到 ITU-R BT.709,90% 饱和度:
[[ 1.48496742 -0.40117349 -0.08379383]
[-0.03432004 1.28353567 -0.24921569]
[ 0.01020356 -0.12187415 1.11167083]]
好了,让我们看看我们的图像:

140_misconceptions_0620_srgb_sweep_FHD
(第 10/20 段)
这是一种有趣的色彩渲染解决方案,使用得非常频繁。它仍然使用偏向“臭名昭著的 6 色”的每通道机制。但基色的改变使其更“可接受”。为了更清晰地说明 ALF-2 图,这里回顾一下“红色到黄色臭名昭著的 6 色渐变”中使用的值:
| 色彩管理 | 渐变基色 | R | 更多 G | 更多 G | 更多 G | 更多 G | Y |
| Filmic Hable | sRGB | 1, 0, 0 | 1, 0.03, 0 | 1, 0.1, 0 | 1, 0.25, 0 | 1, 0.6, 0 | 1, 1, 0 |
我不需要使用疯狂的小数值就能得到一个清晰易读的图,这本身也是一个好迹象。
我们走对了路!
我之所以提到 ARRI K1S1,是因为它与 ACES 2.0 的讨论以及我去年的一次演讲(2020 年夏季)中的一些不准确之处有关。让我们深入探讨!
我的过错
ACES 历史
首先,分享一些我最近发现的关于 ACES 的信息:
- ACES 1.0 的制作过程“复杂”,因为存在“相互矛盾的设计要求”。
- 在构思 ACES 1.0 时,没有可用的 CG 图像。
- 最初 ACES 只是一个色彩空间和编码(IIF – 图像交换框架)。
- ACES 0.1.1 仍然可用,并且因其相当受欢迎而被一些调色师使用。
- 正如下图所示,ACES 0.1.1 可以说是一种有趣的色彩渲染解决方案。

140_misconceptions_0690_aces_example_FHD
所有这些示例都可以在这个 Dropbox Paper 链接中找到。这里是一篇提到《Spider-Man: Homecoming》中 ACES 问题的文章。紫色边缘问题可以在汽车前灯示例中看到。
这里是关于 ACES 0.1.1 输出变换的背景论文链接,由富士胶片的 Uchida 先生共同开发。它开发于 2011 年(正好十年前!),有些人可能会说这是唯一好的 ACES 渲染。它的外观相当“胶片感”,并被用于Lego 1。
Lego 电影和 ACES
在我提到的演讲中,提到了这个关于 ACES 的视频。不过,有几件事值得注意:
- Lego 电影是在 Linear – P3-D60 中渲染的,而不是 ACEScg。
- Lego 1 使用了 ACES 0.1.1。
- Animal Logic 有一位内部调色师使用 BaseLight…
- 他使用了 Baselight 5.0 的色域压缩工具来为 Lego Batman 创建 Rec.709 交付版本。
嗯,又一次提到了色域压缩… 这看起来像是输出变换的一个重要组成部分。
ACES 电影和输出变换列表
我在演讲中犯的另一个错误是提到了一个使用 ACES 制作的电影列表。以下是引述:
“ACES 已在 300 多部电影中使用,并且是 Netflix 的标准。目前被许多 VFX 工作室使用,如 ILM, Animal Logic…”
这不完全正确。Kevin Wheatley 在2021 年 2 月的 TAC 会议(1:02:28)中提到了这一点。如果我没理解错的话,ACES 主要用于文件交换和归档(使用 ACES 2065-1)。不一定用于显示端的色彩再现。 我想无论如何也不可能确切知道哪些电影使用了 ACES 输出变换。
VFX 工作流程和工作室要求
以下是引述:
我会从务实的“视觉特效世界中实际发生的情况”出发,我们看到的所有 ACES 项目都没有直接使用开箱即用的 RRT。或者我们遇到的任何项目都是如此。也许有一两个项目确实按照原意提供了 LMT 和 RRT。但这非常罕见,大多数情况下,他们只是全部抛弃,用别的东西替换。包括那些在 ACES 网站上宣传他们如何使用 ACES 的项目。
Kevin Wheatley。
天啊。我没想到会这样!而且情况还在继续:
从视觉特效的角度来看,我们得到了一堆查找表,它们完全不像 RRT,而且很可能不是从它衍生出来的。因此,我相信他们已经全心全意地替换了它们。然后我相信 DI 公司不得不试图逆向工程,看看如何能把这个硬塞进一个 ACES 项目里,以便他们能满足工作室的要求。所以他们为此苦苦挣扎。
Kevin Wheatley。

140_misconceptions_0790_aces_workflow_FHD
(第 11/20 段)
我记得 Joshua Pines 在 meeting#14 上也说过类似的话。这个确切的话题在 2021 年 9 月的 TAC 会议 上被广泛讨论过。值得一看!
ACES 看起来更好
最后,我在那次演讲中提供了两个例子(它们仍然在我的网站上),说 ACES 让它们看起来更好。这真是个糟糕的措辞!因为,我希望这篇文章能弥补这一点,如果你仔细观察这些渲染图:
- 过曝的绿色会变黄……
- 过曝的红色会变橙……
- 我们看不到,但过曝的蓝色会变品红!
这基本上是一种“外观”,它没有给你选择。输出变换中嵌入了一种你无法补偿的外观。你完全有权利喜欢“ACES 外观”,但我认为意识到这一点也很重要。

140_misconceptions_0810_aces_example_FHD
是的,在这些例子中,我使用了一个名为 “DisplayTransform_JzAzBz” 的显示变换。但你暂时不需要担心这个。这里的重点是比较一个会意外扭曲颜色的输出变换和一个不会的。
这只是 Jed 的 另一个伟大实验。
补偿这种行为?
有几个由 Nick Shaw 制作的动画 GIF 很好地展示了这个问题。我们能否调整数值来补偿 ACES 输出变换的行为?就像上面蓝色 SRGB 球体的例子那样:“嘿 Chris,你为什么不加点绿色来补偿呢?” 当然,让我们看看:

140_misconceptions_0850_hue_skew_FHD
那么,我们可能会认为加一点绿色就能解决问题?但这只会让颜色走一条不同的路径。在这种情况下,是走向青色而不是品红色。仅此而已。你无法逃脱“臭名昭著的 6 色”。

140_misconceptions_0860_hue_skew_FHD
(第 12/20 段)
启示 #15:由于显示变换的行为就像一个厨房水槽(或者你也可以说像一个漏斗),因此不可能有任何补偿。
这些动画 GIF 最初发布在 ACESCentral 这里。有趣的讨论!
在 ACEScg 中渲染
我最后的误解是关于 ACEScg 是“终极渲染空间”,或者认为 ACEScg 会让我的渲染看起来更好。首先,“看起来更好”没有任何意义。这只是一个“诱饵”词。
其次,我并不认为所有动画长片都应该在 ACEScg 中渲染。渲染原色(或工作空间)可以像显示变换一样,根据艺术指导来选择。
这就是我们的启示 #16:从基本原理上讲,RGB 渲染在某种程度上是存在缺陷的。不同的渲染空间只是试图让它不那么糟糕。
从光谱角度讲,RGB 渲染距离真实场景如此之远,以至于每个人都会同意基于 RGB 的渲染并不是我们真正想做的。但是约束迫使我们使用基于 RGB 的引擎 […]
Daniele Siragusano.
我唯一能说的是,在 ACEScg 中渲染让我们更接近光谱渲染。并不是说它看起来更好。这里有一些彩色球体的测试。我让你猜猜哪些是在 ACEScg 中渲染的,哪些是在“Linear_sRGB/Rec.709”中渲染的:

140_misconceptions_0870_acescg_rendering_FHD
ACEScg 是个万金油。
Thomas Mansencal,关于 RGB 场景渲染。
所以,是的,通常关于这些彩色球体的“典型”答案是:“简单!测试 B 是在 ACEScg 中渲染的!有更多的反弹和全局光照 (GI)。” 但不对!事实恰恰相反。所有这些“测试 B”图像都是在“Linear_sRGB/Rec.709”中渲染的,而所有“测试 A”都是在 ACEScg 中渲染的。疯狂吧?
但我不会在这里重复我过去的错误:我不能诚实地说一个色彩空间比另一个更好。它们给出不同的结果,而 ACEScg 更接近光谱渲染。这就是我能说的全部。
基准真相
那么,我们已经看到了不同的显示变换,它们都基于逐通道/RGB 查找。其中一些比另一些效果更好。但这让我们处于什么境地呢?是否存在某种中立的基准真相?我们怎么可能知道我们看到的是“正确”的呢?
我只想快速补充一点,即使逐通道方法可能给出“可接受”的结果(例如 ARRI ALF-2),如果你在一个项目中需要多种交付格式(例如 SDR/HDR),你可能会面临它的局限性。
参见 Daniele 的帖子 关于此事的讨论。
色度线性方法
到目前为止,我只能想到两种选择……还记得我们为每个输出变换所做的图表吗?我们可以将色度域中的直线视为“中性”,即通过显示变换时色度没有变形。
这些使用 Open DRT(使用 v0.0.83b2)绘制的图表是唯一一组我不需要设置极小的值来正确显示色度路径向消色差轴移动的图表。看看这些步进是多么规则和整洁。完全没有扭曲!

140_misconceptions_1030_chromaticity_paths_FHD
(第 13/20 段)
以下是用于绘制这些图表的值。采用更规律的步长来精确展示发生了什么:
| 色彩管理 | 扫描原色 | R | + 0.2 G | + 0.4 G | + 0.6 G | + 0.8 G | Y |
| Open DRT | sRGB | 1, 0, 0 | 1, 0.2, 0 | 1, 0.4, 0 | 1, 0.6, 0 | 1, 0.8, 0 | 1, 1, 0 |
| Filmic Hable | sRGB | 1, 0.00001, 0.00001 | 1, 0.2, 0.00001 | 1, 0.4, 0.00001 | 1, 0.6, 0.00001 | 1, 0.8, 0.00001 | 1, 1, 0.00001 |
| spi-anim | sRGB | 1, 0.00001, 0.00001 | 1, 0.2, 0.00001 | 1, 0.4, 0.00001 | 1, 0.6, 0.00001 | 1, 0.8, 0.00001 | 1, 1, 0.00001 |
| spi-vfx | sRGB | 1, 0.00001, 0.00001 | 1, 0.2, 0.00001 | 1, 0.4, 0.00001 | 1, 0.6, 0.00001 | 1, 0.8, 0.00001 | 1, 1, 0.00001 |
| Filmic High Contrast | ACEScg | 1, 0, 0 | 1, 0.2, 0 | 1, 0.4, 0 | 1, 0.6, 0 | 1, 0.8, 0 | 1, 1, 0 |
| sRGB (ACES) | ACEScg | 1, 0, 0 | 1, 0.2, 0 | 1, 0.4, 0 | 1, 0.6, 0 | 1, 0.8, 0 | 1, 1, 0 |
| sRGB (ACES) | ACEScg | 1, 0, 0 | 1, 0.2, 0 | 1, 0.4, 0 | 1, 0.6, 0 | 1, 0.8, 0 | 1, 1, 0 |
为了让“路径到白色”正常工作并获得正确的图表,我不得不对 spi-anim、spi-vfx 和 Hable 的 Filmic 使用 0.00001 而不是 0。希望比较仍然成立!
色度线性定义
或许值得花点时间来定义这些词的含义。在 ACESCentral 上曾有过一些非常有趣的辩论。人们使用了几个表达来描述我们试图实现的目标:“色调线性”、“色调保持”、“色度保持”或“主波长保持”……我不会讨论哪个表达更合适,因为更聪明的人已经在这里辩论过了。
所以我直接引用 Thomas 的话,因为他的解释简单有效:
我们所说的它的一个特性(即色度线性路径到白色)是,它保留了它所影响的任何色度坐标的主波长。
Thomas Mansencal 给出的绝佳定义。
消色差图像
我一直在尝试的第二个选项超级简单,甚至有点“傻”。我们可以将图像饱和度降低 100%,色调就回来了!这听起来很荒谬,但做起来却是一个有趣的练习。这个想法是受到 Peter Postma 的优秀视频(04:55 处的树木示例)的启发。
可能有更复杂的方法来计算图像的亮度/明度。我用了最简单的一种,因为……我不知道更好的方法!
让我们来看看!

140_misconceptions_1110_acescg_sweep_FHD
你需要使用正确的“亮度计算”方法,以便根据原色正确地去饱和。对于 ACEScg,你可以使用 Jed 的饱和度工具。
这就是我在这篇帖子中所做的。
我认为这是一个有趣的练习,因为要准确定义“彩色版本”看起来哪里“不对劲”可能非常困难。让我们试试:
“看起来很奇怪”、“看起来很平”、“看起来不自然”、“看起来被裁切了”……这些可能是我用来描述这些图像的几个说法。
什么是色调?
我们来到了一个关键点!之前所有的例子都使用 S 曲线进行色调映射。但这到底是什么意思?这两个词是什么意思?
- “Tone” 指的是“Tonality”,即图片中使用的色调范围(或系统)。
- 色调范围?比如亮度?或者明度?
那么色调映射(Tone-Mapping)又意味着什么呢?这是我在网上找到的最佳定义:
以模式化、可预测的方式处理灰度信息。
Rory Gordon 一语中的。
我也非常喜欢这个定义:
我们寻求将亮度(或明度)映射到显示器上。
这就是色调映射应该做的。一位色彩爱好者的定义。
启示 #17:根据这个定义,我们从未进行过色调映射。从未。是的,这是个重磅炸弹。很难相信,对吧?但如果你仔细跟随我的步骤,你应该看到并意识到,本文中描述的 OCIO 配置没有一个能正确地将明度映射到显示器上。一个都没有。
如果你难以相信我,我不怪你!但看看这两张图片,告诉我哪一张使用了简单的 sRGB EOTF,哪一张是“色彩管理”的?

140_misconceptions_1210_cornell_box_FHD
(第 14/20 段)
更棒的是,ACESCentral 上有一篇关于色调映射的精彩帖子,对我来说简直是颠覆性的!让我们来看看吧!
一篇历史性的帖子
那么,让我们深入研读一下Sean Cooper 的这篇精彩帖子:
我认为“色调映射”和“色调映射算子”这两个术语主要来自计算机图形学领域,而在历史术语中,整个主题被称为“色调再现”和“色调再现曲线”。前者主要用于图像到图像的“映射”场景:例如,从 HDR EXR 到 SDR JPEG。而后者的定义则主要用于指代场景到图像的“再现”,其中场景和生成的图像都有“色调”或“色调阶调”,但客观的质量度量标准是“色调”从一个领域到另一个领域的“再现”。
关于色调
Sean 继续写道:
“色调”这个术语本身并不科学。这就是为什么它没有出现在任何颜色外观模型中,也没有出现在CIE 词汇表中,它是媒体/成像领域独有的。我认为这个概念在我们社区/领域的起源,首先要归功于 Hurter 和 Driffield 在感光测定方面的开创性工作,后来是 L.A. Jones 对整个成像链中色调再现的研究。我建议读者自己去探索这些人的著作。
关于 Jones 图
这真是一篇历史性的帖子:
具体关于 Jones 和他 1920 年的论文《On the theory of tone reproduction, with a graphic method for the solution of problems》。他将问题空间定义为“……通过摄影过程制作物体图像再现的程度,使得观察者在观看时,能在其脑海中产生与直接观察物体时在视网膜上形成的图像所激发的相同主观印象……”。他接着说道:“对亮度和亮度差异的恰当再现……具有至高无上的重要性……”。
关于亮度
这真是一个绝妙的解释:
亮度在色彩科学界确实有定义,引用 Fairchild 的话来说就是“……一种视觉感觉,据此一个区域看起来发射或多或少的亮光”。Jones 使用了一个明确的简化假设,我相信这个假设在大多数关于“色调曲线”或“色调映射算子”的讨论中都是隐含的。那就是,场景中的所有物体都是非选择性的,成像机制也是非选择性的。非选择性意味着它同等地吸收/反射所有入射的电磁能量。他使用这个简化是因为“在这种条件下,视觉亮度的值与摄影亮度值成正比。”
还有更多内容。让我们继续!
当然,场景的感知亮度与再现之间存在许多因素导致的偏差,反射选择性就是其中之一,这打破了简化假设。然而,简化假设的使用既是为了方便,也是为了将分析集中在图像再现(或更具体地说是色调再现)的主要原则上。再加上一个假设,即场景中的主要光源和图像观看环境是采用的光源,你可以更具体地将这个空间称为“中性阶调再现”。
关于再现
总而言之,“色调再现”主要关注的是将非选择性物体的场景亮度(和相对亮度)再现到非选择性的图像媒介上。
关于“胶片”
我认为,大多数讨论这个话题的人都隐含地持有(中性/非选择性的)假设,而“胶片”这个提法比“色调”要模糊得多,定义也更不清晰。“胶片”是一种极其多样且复杂的量子力学技术,拥有超过一个世纪的无数表现形式。“胶片”做过很多事情,从牙医那里给我的牙齿拍片,到帮助证明爱因斯坦的广义相对论,再到被动画师用刀刮擦然后投影。
这是我感到最困惑的部分:定义“胶片”。
我们最好能以定义“色调”同样的严谨性来定义“胶片”,因为我不相信这里的目标是去模拟某一天处理的特定品牌光化学胶片的某一批次。
S 形曲线与路径到白色
最终,这直接引导我们进入下一个要点……我们之前解释过,“s 形曲线”与期望的“路径到白色”毫无关系。毫无关系!那么,这里起作用的到底是什么呢?
启示 #18:s 形曲线只是显示变换中众多模块中的一个。这一点也花了我不少时间才明白!如果没有Jed 这篇富有启发性的帖子,我可能永远也搞不清楚!
如果你仔细阅读了这篇文章,你可能已经注意到我暗示了一种非常特殊的成分。它如此特殊,以至于只在“Filmic Blender”和“OpenDRT”中使用。是的,我说的就是色域压缩/映射。看看这个演示:

140_misconceptions_1230_gamut_visualization_FHD
(第 15/20 段)
启示 #19: 在数字 RGB 的世界里,通往白色的路径必须经过精心设计。数值在数字显示器上不会神奇地变成白色。它们“只能达到” R、G 和 B 通道 100% 的发射亮度。
但是等等!如果所有这些 OCIO 配置都使用相同的机制(每通道或 RGB 查找),为什么有些配置会“趋向白色”,而有些则不会呢?这里有一些线索:
- 输出变换中基色的改变,例如 ACES。
- 色域压缩,例如 Filmic Blender。
- 一些“秘制酱料”也可能产生影响,比如 ACES 的“增甜剂”或“ARRI 去饱和矩阵”。
我不会在这里深入细节,但没错,这是一个大问题。通往白色的路径必须为数字显示器进行恰当的设计。我仍然对这个发现感到非常惊讶!
色度线性看起来很奇怪
好吧,让我们深吸一口气。我们说到哪儿了?是的,我们正在研究 Open DRT 及其在通往白色路径上的“色度线性”方法。那么,问题解决了吗?颜色没有失真……我们对此满意吗?嗯,并不完全满意!而这就是最迷人的部分开始的地方。
启示 #20: 即使“色度线性”方法是可取的,它也不一定能创造出悦目的图像。它只是我们可以在此基础上构建的一层“基本事实”。
听起来可能令人惊讶,我们不一定希望在色度域中显示图像时使用直线。因为如果你观察 BT.709 蓝色基色在 1976 CIE 图中沿直线走向白色,你可能会观察到我们所说的 Abney 效应。

140_misconceptions_1280_srgb_sweep_FHD
是的,我们刚刚打开了一个大麻烦:发生在我们大脑中的心理物理效应(或者更准确地说,是在“人类视觉系统”中)。你可以想象用数学来建模这些现象是多么具有挑战性!因为这不仅仅是 Abney 效应……还有一大堆其他效应!
正是 Abney 的实验表明,在色度域中,一条通往适配白色的直线并不能产生等色调线。
Sean Cooper 的另一篇精彩帖子。
色彩外观模型
我们现在已经进入了迷人的色彩外观模型世界,它分为四种类型:
- 对比度外观(Stevens 效应、同时对比……)
- 色彩度外观(Hunt 效应……)
- 色调外观(Abney 效应、Bezold-Brücke 效应……)
- 亮度外观(Helmholtz-Kohlrausch 效应、侧向亮度适应……)
而 Jed(在 v0.0.83b2 中)正在使用 ICtCp 色彩空间来解决这个感知方面的问题。太迷人了!这是支持“色度线性”方法的另一个论据。如果不首先确定刺激部分(色度),你如何构建一个基于感觉的感知系统呢?
我强烈建议每个人阅读 Sean 的回答,他在其中描述了 Dolby ICtCp 色彩空间中的等色调线。
真是大开眼界!
这就是每通道方法可能永远无法给你的东西:一个坚实的基础,让你可以在上面建造你的房子。它是一个幸运的工程意外。我找到一句关于色彩外观模型的引语,觉得非常有趣。它来自 Ed Giorgianni 的 Color Management for Digital Cinema。我稍微修改了一下以避免任何歧义:
启示 #21: 对于色彩外观,显示图像的色度总是必须以一种经过工程设计和控制的方式从原始实景的色度进行改变(渲染)。
因为每通道方法是以一种偶然的方式改变色度……
如果你想了解更多关于 ACES 输出变换和色彩外观模型的信息,我建议阅读这个 2017 年的帖子!
TCAMv2
那么,既然我们已经理解了显示变换是关于什么的(希望如此!),你可能会问自己:有没有一个 OCIO 配置解决了本文讨论的不同主题?答案是肯定的!确实有一个!
TCAMv2 描述
我想明确声明,TCAMv2 不是开源的。它是 Filmlight 工程师的工作成果,我之所以在本文中提到它,是因为我获得了许可。让我们看看配置本身:
displays:
TCAMv2 100 nits office:
- !<View> {name: "sRGB Display: 2.2 Gamma - Rec.709", colorspace: "sRGB Display: 2.2 Gamma - Rec.709"}
TCAMv2 100 nits video dim:
- !<View> {name: "Rec1886: 2.4 Gamma - Rec.709", colorspace: "Rec1886: 2.4 Gamma - Rec.709"}
TCAMv2 48 nits cinema dark:
- !<View> {name: "DCI: 2.6 Gamma - P3D65", colorspace: "DCI: 2.6 Gamma - P3D65"}
TCAMv2 48 nits cinema dark - MWP D65:
- !<View> {name: "DCI: 2.6 Gamma - XYZ", colorspace: "DCI: 2.6 Gamma - XYZ"}
TCAMv2 100 nits videoWide dim:
- !<View> {name: "Rec1886: 2.4 Gamma - Rec.2020", colorspace: "Rec1886: 2.4 Gamma - Rec.2020"}
TCAMv2 100 nits officeWide:
- !<View> {name: "AdobeRGB: 2.2 Gamma - AdobeRGB", colorspace: "AdobeRGB: 2.2 Gamma - AdobeRGB"}
TCAMv2 1000 nits videoWide dim - OOTF 1.2:
- !<View> {name: "Rec2100: HLG - 2020 - 1000 nits", colorspace: "Rec2100: HLG - 2020 - 1000 nits - OOTF 1.2"}
TCAMv2 1000 nits videoWide dim:
- !<View> {name: "Rec2100: PQ - 2020 - 1000 nits", colorspace: "Rec2100: PQ - 2020 - 1000 nits"}
TCAMv2 4000 nits videoWide dim:
- !<View> {name: "Rec2100: PQ - 2020 - 4000 nits", colorspace: "Rec2100: PQ - 2020 - 4000 nits"}
USE ONLY FOR CHECKING COMPS:
- !<View> {name: LowContrast, colorspace: "FilmLight: T-Log - E-Gamut"}
USE ONLY FOR COMPARING RENDERS:
- !<View> {name: ReferenceLINEAR, colorspace: "FilmLight: Linear - E-Gamut"}
(第 16/20 段)
“Displays”(显示设备)和“Views”(视图)这两个概念有点混淆。但这没什么大不了的,因为我们知道如何修复。以下是我在自己的自定义 TCAMv2 OCIO 配置中所做的修改:
displays:
sRGB 100 nits office:
- !<View> {name: TCAMv2, colorspace: TCAMv2 - sRGB - 2.2 Gamma}
- !<View> {name: Raw, colorspace: acescg}
- !<View> {name: Log, colorspace: acescct}
Rec.1886 100 nits video dim:
- !<View> {name: TCAMv2, colorspace: TCAMv2 - Rec.709 - 2.4 Gamma}
- !<View> {name: Raw, colorspace: acescg}
- !<View> {name: Log, colorspace: acescct}
P3D65 48 nits cinema dark:
- !<View> {name: TCAMv2, colorspace: TCAMv2 - P3D65 - 2.6 Gamma}
- !<View> {name: Raw, colorspace: acescg}
- !<View> {name: Log, colorspace: acescct}
active_displays: [sRGB 100 nits office, Rec.1886 100 nits video dim,
P3D65 48 nits cinema dark]
active_views: [TCAMv2, Raw, Log]
TCAM OCIO 配置在术语方面一个可能的改进(这也是我在自己的配置中所做的)是,“Views”的名称有些模糊不清……如果视图被命名为“sRGB Display: 2.2 Gamma – Rec.709”,我完全无法知道它使用的是“简单的”2.2 幂律函数还是实际的 TCAMv2 DRT。
TCAMv2 设置
我不止一次被问到这个配置的术语问题。是的,它与 ACES 的术语不同,这可能会让人感到不安……但请不要害怕这些旨在帮助你的术语!让我们看看是否能从配置中分类信息:
| 名称 | 屏幕亮度 | 类型 | 观看环境 | 原色 | 白点 | 传递函数 | ACES “等效”项 |
| sRGB Display | 100 nits | office | X | Rec.709 | X | 2.2 Gamma | Output – sRGB |
| Rec.1886 | 100 nits | video | dim | Rec.709 | X | 2.4 Gamma | Output – Rec.709 |
| DCI | 48 nits | cinema | dark | P3 | D65 | 2.6 Gamma | Output – P3D65 |
sRGB 和 Rec.709 色彩空间具有固定的 D65 白点。我猜这就是为什么它在 OCIO 配置中没有被指定的原因。我也不确定为什么“P3-D65”显示变换使用了“DCI”这个名称。……通常“DCI”会暗示一个 DCI 白点。……DCI 有一个偏绿的 DCI 白点(约 D63)作为“技术白点”。然而,你可以在该容器内编码任何你想要的白点。通常这是 DCI 容器中的 D60 白点。也可能是 D65 或 D55。
Zach 和 Jed 前来救援。
通过在 OCIO 配置中直接包含这些细节,你就不必猜测使用了哪种原色或 EOTF。TCAM OCIO 配置非常方便,因为在一个地方你就拥有了大部分重要信息。
对于 ACES 输出变换,如果你有任何疑问,可以查看 CTL 参考代码。它实际上非常易于阅读,并且包含大量有用信息。例如,它明确说明了 sRGB ODT:
// Display EOTF :
// The reference electro-optical transfer function specified in
// IEC 61966-2-1:1999.
// Note: This EOTF is *NOT* gamma 2.2
所以请注意,因为这极其重要,ACES Output – sRGB 使用的是 sRGB 分段函数,而 TCAMv2 sRGB Display 使用的是 Gamma 2.2。这是一个很大的区别。
TCAMv2 术语
TCAMv2 OCIO 配置非常轻量(26 MB),只包含两个系列:“SceneReferred”(场景参考)和“DisplayReferred”(显示参考)。简单明了!正如你在下面的比较中所看到的,色彩空间和“一般概念”是相同的。因此,从一个切换到另一个相当简单(特别是如果你正确使用“roles”的话):
| ACES OCIO 术语 | TCAM OCIO 术语 |
| ACES – ACEScg | “ACEScg: Linear – AP1” |
| Input – ARRI – Linear – ALEXA Wide Gamut | “ARRI: Linear – WG” |
| Output – sRGB | “sRGB Display: 2.2 Gamma – Rec.709” |
| Utility – sRGB – Texture | X |
| Utility – Linear – sRGB | “CGI: Linear – Rec.709” |
确实,TCAM 配置中缺少“Utility – sRGB – Texture”。你可以自己添加它,或者切换到完全的“场景线性”纹理工作流。
TCAMv2 视觉示例
太棒了!现在让我们看一些图像,看看 TCAMv2 的表现如何。

140_misconceptions_1320_srgb_sweep_FHD
几点评论:
- 这些渐变非常棒!在 sRGB 原色上的路径到白色,没有“Notorious6”!
- 这看起来是一个中性的显示渲染变换。终于!
以下是关于 TCAMv2 理念的 一个很好的解释:
TCAM 与其他色彩管理工作流不同,因为 它不会在显示渲染变换中施加创造性的“外观” 。所以创造性的外观属于调色堆栈,而不属于显示变换。
Daniele Siragusano.
这是这个色彩管理工作流的一大优势。在我职业生涯中,我将第一次能够以中性的方式进行资产的外观开发,没有任何任意的“意外惊喜”扭曲。然后,当我们进入灯光/渲染阶段时,我们可以根据自己的偏好选择一个“外观”。太棒了!如果你想了解更多关于 TCAMv2 的信息,这里有一个 很好的解释视频:
但是,等等……我们应该通过 TCAMv2 检查我们的 ACEScg 图像,看看它们看起来如何吗?当然,让我们这样做吧!但在那之前,先快速回顾一下不同的色彩管理工作流及其色彩空间。
(第 17/20 段)
不同的色彩空间
有人告诉我,为了在不同色彩管理工作流之间进行公平比较,我应该在其“原生原色”中进行扫描。但在这篇文章中,我决定主要基于两个原因进行 sRGB 扫描:
- sRGB/BT.709 原色是我们的最低共同标准(如上所述)。
- 在我曾工作过的那些工作室,纹理仍然是在这个色彩空间中制作的。可能出于以下原因:
当然,有些地方(如 Rising Sun Pictures)自 2017 年以来就一直在使用 ACEScg 进行纹理制作。我这里主要谈论的是我在几家动画工作室的“有限”经验。
但我觉得有趣的是,在构建这些 OCIO 配置时观察到,每个色彩管理工作流都附带一个“线性空间”和一个“对数空间”。我在这里列出它们供你参考:
| “线性”空间 | “对数”空间 | |
|---|---|---|
| ACES | ACES 2065-1 / ACEScg | ACEScc / ACEScct |
| ARRI | Linear – ALEXA Wide Gamut | LogC – ALEXA Wide Gamut |
| RED | Linear – REDWideGamutRGB | Log3G10 – REDWideGamutRGB |
| Sony | Linear – S-Gamut3 | S-Log3 – S-Gamut3 |
| TCAMv2 | Linear – E-Gamut | T-Log – E-Gamut |
“原生”原色扫描
是的,为了完整性,我也做了这些扫描。我不确定它们是否告诉了我们任何相关信息,尤其是在全 CG 的背景下。但结果如下:

140_misconceptions_1370_acescg_sweep_FHD
最后,这是使用 TCAMv2 查看的我们的 ACEScg 图像:

140_misconceptions_1410_acescg_sweep_FHD
一个主要观察结果:
- 通过使用 ACEScg 原色,我们确实看到了一些色域裁剪和色调偏移。这远非理想情况。
为什么会发生这种情况?嗯,这实际上是有原因的。让我们深入探讨!
TCAMv2 的理念
启示 #22:就像 Filmic Blender 一样,TCAMv2 的显示渲染变换不应该在没有“Look”的情况下使用。理想情况下,你不应该只使用其中一个而不使用另一个。正如 Daniele 所解释的:
TCAM 在设计上不包含首选色彩再现,但 PCR 对于成功的色彩管理工作流至关重要。
Daniele Siragusano。
因此,TCAMv2 做出了一个选择,即拥有一个“宽松”的显示变换,它只做最基础的工作,以给予调色师尽可能多的自由。否则,如果显示变换过于“严格”,要实现某种特定的“Look”可能会变得很痛苦。有一个很棒的视频很好地解释了这一点:
我们现在将描述 TCAMv2 成功的一个非常重要的组成部分:“Looks”。为了清晰起见,我想声明 TCAMv2 Looks 是 FilmLight 的专有财产,不应在购买许可证之前使用。
(第 18/20 段)
TCAMv2 外观
“外观”到底是什么?我们用它来做什么?它们不就是烘焙到 LUT 里的创意调色吗?生成它们能有多难?在很长一段时间里,我都是这么想的,直到 Daniele 在一次 VWG 会议上说:
构建一个好的 LMT 并非易事。
Daniele Siragusano,在 会议 #14 上。
嗯……那我可能误解了什么……这句话让我陷入了深深的思考!因为一个“外观”(或“LMT”)通常就是烘焙到 LUT 里的色彩校正,仅此而已。所以我问了,并得到了这个惊人的回答:
如果 LMT “只是一个调色”(在 ACES 中完成),那很简单。但如果你想匹配一个通过完全不同的方法实现的参考,并且通常还要定义那些在你的参考中可能不存在的值会发生什么(例如,匹配胶片打印的外观,同时不将动态范围限制在胶片打印的范围内),那就绝对不简单了。
Nick Shaw 前来救场。
好吧,这出乎我的意料。真的很有趣!启示 #23:一个外观所包含的内容,远不止一个烘焙进去的调色节点。你可以在一个 3D LUT 里放入比“简单”的调色节点复杂得多、经过精心设计的东西。
外观与工作室
我完全承认,我对“外观”的理解相当有限。我想说,在我工作过的大多数动画工作室里,“外观”并不常见。我在这里引用 Kevin Campbell 的话:
我想更明确地区分动画长片和视觉特效项目通常的工作流程。在动画项目(预算正常的情况下)中,我们通常只在接近尾声、选定 DI 公司时才开始考虑 LMT 的选择。而在视觉特效项目中,我预计 LMT 会在现场拍摄前就选定,并且该 LUT 的某个版本会用于现场每日样片。……我习惯于在视觉特效项目开始时,由客户提供外观/LMT,并且每个项目都不同。
感谢 Kevin 的精确说明。视觉特效和动画工作流程确实存在差异。
那么,让我们来研究一下 TCAMv2 中一个名为“C-105 Vision”的“外观”!我特意选择了这个外观,因为它是 TCAMv2 中最令人印象深刻的外观之一,并且网上有关于其诞生过程的 制作花絮。
C-105 Vision 外观
以下是它的描述:
C-105 Vision – 这个外观是对现代北美相机负片和胶片打印工艺的光谱模拟。与其他核心外观的主要区别在于对饱和深绿色调的准确渲染。
有一段关于这个外观的 制作花絮(在 00:26:25 处),Daniele 在其中解释了他光谱模拟胶片负片的方法。是的,这简直令人惊叹!这可能是目前最好的色彩渲染解决方案之一。请务必观看:
那么,让我们看看应用了 C-105 Vision 外观后的图像:

140_misconceptions_1460_acescg_sweep_FHD
你完全有权利喜欢或不喜欢这些图像:外观是一种创意和主观的选择。但关键是:你有选择权!所以你可以想象,对于每一部故事片,你可以和导演、艺术总监坐在一起,查看色阶图、图像、参考,然后选择你的“首选色彩再现”。
这个“外观”可以基于故事、角色或你想要传达的情感。它可以设定在电影、序列甚至镜头级别。由于你是从一个中性的显示变换开始的,可能性真的是无穷无尽的。将力量赋予影像创作者。
这正是 Robert Eggers 和 Jarin Blaschke 为他们的电影《The Lighthouse》所做的(预告片、文章 和关于其外观的 视频)。
启示 #24:在一部全 CG 动画长片中,选择 OCIO 配置(甚至渲染原色)对于实拍电影的摄影指导来说,其重要性不亚于选择相机、镜头和胶片!
确实;ARRI、RED 和 Sony 也为他们的色彩管理工作流程提供了一些外观。
感谢 Scott 提供的 链接!
质量与身份
作为工作室或自由艺术家,你可能在寻找两样东西:
- 质量。
- 视觉身份。
如果所有工作室和 3D 学校最终都使用相同的逐通道解决方案,我们可能永远无法同时拥有两者。因此,我做了一个小实验,以便更好地展示它们之间的差异,特别是不同显示变换之间的数值范围。其中大部分内容已经在 ACESCentral 上 描述过。
这个测试的灵感来源于 AC 上的 这个帖子。我一直在寻找为虚拟工作组 (VWG) 渲染一些“标志性”的东西。在阅读了关于色域压缩的笔记后,我想:还有什么比一罐可乐更标志性的呢?
(第 19/20 段)
因此,我做了一些研究,获取了 可口可乐的红色值,并将其 转换 为“线性 sRGB”,最终得到了一个 (0.9047, 0, 0) 的 exr 纹理。然后,我使用了一个 HDRI(“treasure island”那个)和一个平行光进行照明。结果如下:

140_misconceptions_1510_coke_can_FHD
为了避免任何混淆,以下是本次测试的确切步骤:
- 在 BT.709 色域范围内进行一次渲染。
- 然后将其带入 ACEScg 的更广色域工作空间(在 Nuke 中)。
- 每个结果都通过其各自的变换从 ACEScg 渲染而来。
结论
在过去的几年里,色彩对我来说已经成了一种真正的执念。我相当确定,为了理解这些东西,我已经损失了一些脑细胞。但希望这是值得的!分通道处理“免费”给了我们一种看似“胶片感”的行为(例如高光饱和度降低)……但希望我们现在知道了这种方法的局限性。
开源色彩管理工作流程的需求非常迫切,而 ACES 填补了这个空缺。尤其是对于 CG 社区。但我们不能忘记,ACES 只是众多解决方案中的一种。并且希望在不久的将来,随着研究的持续进行,会出现更多的解决方案。
启示 #25:数字色彩渲染尚未完成。它是一项正在进行的工作,仍有许多东西需要理解。
这是我的原罪,我通过艰难的方式学到了这一点:不存在完美的色彩管理工作流程。希望通过与你们分享这些新信息,我能弥补过去的错误。因为当一个人犯错时,你可以把头埋在沙子里,也可以从错误中学习并改正它们。
旅程
在个人层面上,我学到了很多关于自己以及如何真正研究事物的东西。几乎像一次哲学之旅。以下是一些经验教训:
- 我们需要的是头脑,而不是榜样。
- 用你的眼睛,相信你的直觉。
- 不要诉诸权威,自己测试!
- 这篇文章的目的是思考。请审视所说的内容!
正如“美国最危险的人”曾经说过:
为自己思考。质疑权威。
显然,我要感谢 Jed Smith 提供了所有这些精彩的 Nuke 脚本以及他在本文撰写过程中的支持。没有他,我无法生成任何图表!我想用我最喜欢的关于显示变换的引语来结束:
我无法理解为什么有人会希望限制他们所有的制作都使用相同的输出变换。这就像限制制作只能使用一台相机。纪录片、故事片、动画、手绘,它们都有自己独特的挑战。你认为如果学院标准化了化学配方,电影在过去 100 年里还会蓬勃发展吗?相反,学院标准化了传输机制。35mm 齿孔。而这正是正确的做法。人们可以创新和互换。
Daniele Siragusano.
最后,一旦你通过中性的显示变换看到了图像,就再也回不去了。就像第一次看到新的、真实的色彩。这是一次信仰的飞跃。你愿意接受它吗?

140_misconceptions_1530_morpheus_pills_FHD
总结
通过 25 条启示,希望我们已经理解了关于显示变换的一些东西:
- 在“nuke-default” OCIO 配置中,Rec.709 传递函数是一个相机编码 OETF!
- 使用“nuke-default” OCIO 配置,你最终总会得到“臭名昭著的 6”。
- S 形曲线与“胶片感”行为无关。
- OCIO 在所有软件中的实现方式并非完全相同。
- 更建议编辑标准的 OCIO 配置。
- 在 ACES OCIOv1 配置中,显示和视图被互换了。
- ACES 输出变换不能解决任何问题。它们本质上是一个 3×3 矩阵和一个色调曲线。
- 拥有通向白色的路径并不意味着显示变换是“正确”或“中性”的。
- 一维 S 形曲线 LUT 应用于对数(或半对数)值。
- 任何收敛于 1 的曲线最终都会导致“臭名昭著的 6”。
- 过去 15 年里我照明、渲染和显示的所有场景都具有“臭名昭著的 6”的外观。
- 一个“beauty” exr 文件不是图像,它是一个包含光数据的文件。
- CG 中有两个渲染操作:一个从场景到数据,另一个从数据到图像。
- 在不同的原色上应用 S 形曲线会产生不同的结果。
- 使用 ACES 输出变换不可能进行“补偿”。
- 从基本原理来看,RGB 渲染在某种程度上是破碎的(与真实/光谱光传输相比)。
- 我从未使用过合适的色调映射解决方案。它存在吗?
- S 形曲线只是“现代”显示变换中几个模块之一。
- 在数字 RGB 领域,通向白色的路径需要被设计。
- 即使“色度线性”方法是可取的,它也不一定能创造出令人愉悦的图像。
- 显示图像的色度必须始终与场景的色度不同。
- TCAMv2 的显示渲染变换不应在没有“Look”的情况下使用。
- 一个 Look 可以包含的内容远不止一个烘焙的调色节点。
- 选择 OCIO 配置与选择相机、镜头和胶片库存同样重要!
- 数字色彩渲染尚未实现。
参考资料
一系列在 ACESCentral 上讨论 ACES 2.0 输出变换的帖子:
- 输出变换虚拟工作组架构
- 关于问题与术语
- 选择你自己的方法
- ACES 背景文档
- 色域映射第二部分:到达显示设备
- 输出变换色调曲线
- 人类感知 vs. 胶片感再现
- Jed Smith 的 Open Display Transform。
一些关于 OCIO 考古学的链接:
- 色调映射与 S 曲线(关于 spi-anim OCIO 配置)
- spi 工作流(Google 站点,看起来是官方 OCIO 文档的预发布版)
- Timothy Lottes 的色调映射
- 将 CG 渲染集成到调色后的电影素材中
- 《蜘蛛侠》中使用 ACES 产生的紫色边纹
- ALEXA Log C 曲线 – 在 VFX 中的使用
- 使用 ACES 时的色彩伪影或断裂
- 色彩不准确性与配置文件
- ACES OpenColorIO-Configs(以及其他故事)
- OpenColorIO-Configs 的未来
- PR:ACES 1.1 与 ACES 1.2 支持
- 研究色域裁剪
输出变换虚拟工作组的重要会议:
- 第 20 次会议 (2021/06/09) :关于 S 形曲线和高斯分布的有趣会议。
- 第 26 次会议 (2021/09/15) :关于 Daniel 元框架的辩论。“原地打转”、“没有取得任何进展”以及重大启示:ACES 输出变换实际上是“一个 3×3 矩阵和一条色调曲线”,与 IDT 并没有太大不同!
- 第 27 次会议 (2021/09/27) :Netflix 对阵世界。这也是一个有趣的会议,看看人们是否“足够聪明和智慧”来使用 ACES。
- 技术咨询委员会会议 (2021/09/22) :什么是 ACES 项目?有人知道这个问题的答案吗?不太确定…
- 技术咨询委员会会议 (2021/11/17) :我们如何才能迫使人们为 ACES 工作?嗯,也许听听他们的意见?
- 有趣的是,色彩外观模型早在 2017 年 10 月就在 ACESCentral 上讨论过。值得一读 Daniele 的回答。
- 输出变换虚拟工作组的所有会议纪要都可以在这里找到。