Academy Color Encoding System(ACES)概览
引言
细心的读者可能已经注意到,大约在 2021 年左右,我对 ACES 的分析发生了相当大的变化。从“ACES 太棒了”变成了“ACES 存在问题和局限性”。但请不要误会:ACES 的理念(一个帮助专业人士的框架)是伟大的,而且 ACES 1.X 是我进入色彩管理的切入点。
在过去的五年里(自 2018 年 9 月我的第一篇帖子以来),我学到了很多,部分要归功于 ACES 社区。但我认为 ACES 1.X 是一个有缺陷的色彩管理工作流程,尤其是其输出变换。这是一个问题,因为它们是“图像形成链”中最关键的部分。
我担忧的一点是,许多对色彩管理不太熟悉的艺术家已经完全放弃了真正相信自己的眼睛。这有点像一种“诉诸权威”:“如果这是由电影艺术与科学学院完成的,并且用在 Lego 电影上,那它一定是好的。”你不信?好吧,看看这个:

015_ACES_0005_redshift_unreal_FHD
为什么一只蓝色的兔子会变成品红色?这两张图片来自 Redshift 和 Unreal 的文档,这是两个备受尊敬的渲染引擎。而 ACES 已在大多数 DCC 软件中实现的事实,更是为这种“潮流效应”火上浇油:“如果 ACES 到处都实现了,那它肯定能行。”
尽管如此,与其从我的网站上删除这个页面,我认为更具建设性和责任感的做法是精确地解释 ACES 是什么,以及需要避免哪些陷阱。即使随着最近 ACES 2.0 的发布,本文中描述的大部分挑战和流程仍然有效。
ACES 概述
ACES 1.X 是一个色彩管理工作流程 (CMW),由数十位专业人士在电影艺术与科学学院 的主持下开发,其目标是建立一个标准来帮助专业人士。许多 VFX 工作室,如 ILM、Framestore、Double Negative 和 Animal Logic,都使用它来交换文件,并且官方称有超过 300 部电影 是使用 ACES 制作的。
经过一些调查,我对之前的说法持谨慎态度。在一次 TAC 会议上已经确认,列表中一些电影并未使用 ACES 输出变换。
ACES 主要用于交换文件。
ACES 可以通过 OCIO 免费获得(这是官方 ACES 配置的链接),就像 spi-anim 配置一样。ACES 也已在 Resolve 中以 CTL 形式实现,并在 Unreal 和 Unity 中以 GLSL / HLSL 形式实现。
你可以在这里(在“贡献者”标签页中)查看贡献者和 TAC 成员。
我第一次接触 ACES 是在 2016 年的 Animal Logic。艺术家们正在制作一部名为“Lego Batman”的美丽且饱和度很高的电影。那是我第一天上班,我在显示器上看到了这个镜头(我想是 Nick Cross 打的灯光):
(第 2/9 段)

015_ACES_0010_lego_batman_FHD
我当时心想:“哇!这看起来真棒!他们是怎么弄出这些疯狂色彩的?” 色彩范围看起来确实比我之前的工作室要广得多。原因如下:
- 首先,Animal Logic 使用的是“P3”显示器,这是电影院的行业标准。
- 其次,Lego Batman 使用了 ACES 0.1.1,这是一个与 ACES 1.X 完全不同的版本。
- 最后,Grant Freckelton 的艺术指导无疑为达成这种色彩丰富的效果提供了帮助。
为什么需要 ACES?
在模拟相机时代,事情很简单,因为只有几种格式:35mm 和 70mm。拍摄在胶片上的 原始拷贝 可以永久保存。
但随着数字革命,多种相机和格式涌现出来。这些用于 数字源母版 的专有系统可能很快过时,甚至更糟的是,文档记录不充分。
问题是,当这些电影需要为新载体重新制作母版时,数字源母版 就不再适用,原始的创作意图就会丢失。因此,ACES 背后的初衷是以一种“标准”格式对这些档案进行编码,以减少歧义。ACES 最初的名字确实是“图像交换框架”。
什么是 ACES2065-1?
ACES 包含一系列色彩空间和转换工具,允许你操作它们。由美国电影艺术与科学学院开发的参考色彩空间称为 ACES2065-1:
- 超宽色域(非物理可实现的原色)
- 线性
- 高动态范围
- 标准化
- RGB

015_ACES_0020_aces_colorspace_FHD
ACES2065-1,也称为“ACES 色彩空间”,旨在用于文件交换和归档。但是,在这篇文章中已经解释得相当清楚,关于这种格式的使用仍然存在一些不确定性:
ST2065-1 文件格式远非 无歧义。……如果我给你一个 ST2065-1 文件,你并不知道它是用 ACES 的 ut33、0.1.1、0.2.1、0.71、1.03 还是 1.1 版本制作的。这些版本都会产生相当不同的电影版本。……我真正担心的是,我们的后代将修复严重受限的 ST2065-1 文件,因为我们把一些临时凑合的 LMT 渲染到了我们的母版中,这些母版先转到 709 然后又转回来,仅仅是因为实际的系统不够灵活。
归档的目的尚未实现。也许 ACES 元数据文件在这方面会有所帮助。
一张图看懂 ACES
ACES 由下图描述的三个主要步骤组成:

015_ACES_0030_ACES_autodesk_FHD
- A. IDT 是将纹理/图像/渲染导入/转换到 ACEScg 色彩空间。
- B. ACEScg 是渲染/工作空间。
- C. RRT + ODT 是到显示器或视频投影仪的输出变换。
我们过去常说“RRT”和“ODT”。我将把它们统称为“输出变换”。
在 ACES 1.1 中,RRT 和 ODT 已针对 HDR 输出变换合并。
ACES 背后的理念是处理你可能需要的任何色彩变换:
- 你的纹理是来自 互联网 的 sRGB 吗?或者它是在 P3 色域内的“线性”空间?ACES 提供了所有矩阵和 LUT,可以通过 IDT 将一个色彩空间转换为另一个。
- 你的显示器是 Rec.709 还是 P3?ACES 提供了所有 LUT,以便用适当的输出变换查看你的渲染。
这就是色彩管理的重要事项之一:你必须知道每个流程(输入、工作空间和输出)的色彩空间(原色、传递函数和白点)。
ACES 试图澄清这一点。
ACES 色彩空间
以下是主要的 ACES 色彩空间列表:
- ACES 2065-1 是场景线性,使用 AP0 原色。它是交换和归档格式。
- ACEScg 是场景线性,使用 AP1 原色(用于计算机图形的较小“工作”色彩空间)。
- ACEScc 和 ACEScct 使用 AP1 原色,并具有各自指定的对数传递函数。
| 原色 | 白点 | 传递函数 | 用途 | |
| ACES2065-1 | AP0 | ~D60 | 线性 | 交换和归档空间 |
| ACEScc | AP1 | ~D60 | 对数 | 工作空间(调色) |
| ACEScct | AP1 | ~D60 | 对数 | 工作空间(调色) |
| ACEScg | AP1 | ~D60 | 线性 | 工作空间(渲染、合成) |
(第 3/9 段)
ACES 白点并非精确的 D60(实际上很多人对此有误解)。选择这个白点是为了避免产生任何误解,即 ACES 仅兼容在 CIE 日光(相关色温 6000K)下拍摄的场景。
为什么是 ACEScg?
那么计算机图形学呢?早在 2014 年和 2016 年,Steve Agland(Animal Logic)和 Anders Langlands(Weta Digital)进行了一些在 ACES2065-1 色彩空间中进行渲染的测试。在 ACES2065-1 色彩空间中渲染时出现了一个意想不到的问题:它的色域如此之大,以至于会扰乱能量守恒。一些色彩专家将这一事件称为“伟大的发现”。

015_ACES_0040_aces_colorspaces_FHD
除此之外,在 ACES2065-1 上进行调色感觉并不“自然”。因此,为计算机图形学创建了另一个色彩空间:ACEScg(AP1 原色),它与 Rec. 2020 相似。我要用粗体并强调重复一遍,因为这至关重要:你永远不应该在 ACES2065-1 中渲染。
ACEScg 的创建细节在 Digipro 2015 的这篇文章中有详细说明。
ACEScg:我们的工作/渲染空间
为什么我们要在一个色彩空间中渲染,却在另一个色彩空间中显示?这有什么意义?还记得第一章中的渲染空间和显示空间吗?我们已经看到它们不必相同。
但是,如果我告诉你在不同的原色下渲染将不会得到相同的结果呢?为了清晰起见,我再重复一遍:在“线性 – sRGB”或“ACEScg”中渲染不会得到相同的“美颜”exr 文件。光照计算以及最终结果将会不同。
在 Animal Logic,Lego Batman 和 Ninjago 是在“线性 – P3-D60”中渲染的,这完全取决于表面处理所使用的空间。Peter Rabbit forward 则是在 ACEScg 中渲染的。
渲染原色的选择绝对不是一个微不足道的决定……
首先,我们都应该同意,从基本原理上讲,RGB 渲染是有些问题的(与光谱渲染相比)。因此,我们希望使用一个能让它不那么“破碎”的色彩空间进行渲染,而 ACEScg 是一个很好的候选者。通过从“线性 – sRGB”切换到“ACEScg”,你将能够进行广色域渲染。
为了对渲染色彩空间进行适当的比较,我们需要一个称为“真实情况”的参考。在我们的案例中,这将是由光谱渲染引擎 Mitsuba 生成的无偏图像。否则,我们将无法正确比较渲染结果!
这里的论点并不是说 BT2020 或 ACEScg 是终极的色彩空间,事实上没有一个是,论点是与其它色彩空间相比,它们往往能更好地减少误差。它们恰好具有一种方向,是所有主要 RGB 色彩空间中的“万金油”。
Thomas Mansencal。
光谱、Rec.709 和 Rec. 2020 之间的比较
Anders Langlands 和 Thomas Mansencal 进行了一些有趣的测试和研究。他们在这篇文章中对此进行了解释。他们进行了三种不同的渲染:

015_ACES_0050_mitsuba_spectral_FHD
- sRGB/Rec.709 原色,所有色域中最小的。
- 光谱,使用波长进行计算的真实情况。
- Rec. 2020 原色,与 ACEScg 相似。
然后,将它们彼此相减。颜色越暗,表示越接近光谱渲染!所以,如果你看最下面一行,平均值总体上更暗,这意味着 Rec. 2020 让我们稍微“更接近”光谱渲染。
ACEScg 和 Rec. 2020 有什么区别?让 ACEScg 的三个原色位于 CIE 色度图之外有什么优势?主要是为了包含 P3,ACEScg 是一个接近 BT.2020 但包含 P3 的色域。这需要非物理上可实现的(虚拟)原色。
值得注意的是,ACEScg 原色的选择曾存在争议。
深入了解 ACEScg
根据我的个人经验,我可以分享在 ACEScg 中渲染:
- 并不比在“线性 – sRGB”中渲染“更好”。它是不同的,你应该自己测试,看看广色域渲染是否符合你的需求。
- 给出的结果稍微更接近光谱渲染,但这并不适合所有项目。
- 不会让你获得更明亮和更饱和的颜色。这些值并不会最终显示出来!
广色域渲染既有优点也有缺点。和往常一样,你应该自己测试。
来自 Thomas Mansencal:从严格的技术角度来看,渲染引擎确实是色彩空间无关的。它们只是处理你扔给它们的任何数据,而不考虑数据存储的色彩空间。然而,色彩空间及其原色的选择对于实现忠实的渲染至关重要。[…]
ACESCentral 上的这篇文章也清楚地解释了这一点。
(第 4/9 段)
输入设备变换 (IDT)
IDT 是将纹理/图像导入到你的工作/渲染空间的过程,这个空间很可能是 ACEScg。
康奈尔盒示例
以下是 Guerilla Render 中两个康奈尔盒的渲染图。我在这两个渲染中使用了相同的“线性 sRGB / BT.709 纹理”,其值如下:
- 绿色 sRGB 原色位于 (0, 1, 0)。
- 红色 sRGB 原色位于 (1, 0, 0)。
- 中灰位于 (0.18, 0.18, 0.18)。

015_ACES_0060_guerilla_cornellBox_FHD
这两个康奈尔盒的唯一区别在于渲染空间:
- 在第一个中,渲染空间是许多软件所称的“线性”,实际上指的是具有线性传递函数的“sRGB / BT.709”色域(“Utility – Linear – Rec.709”)。
- 在第二个中,渲染空间是 ACEScg。我相应地设置了 IDT 以正确测试广色域渲染。
这个测试需要注意的主要一点是我使用了一些纹理。如果你直接在软件中使用颜色,可能不会得到相同的结果。你还必须注意你的 mipmap 生成(tx 文件)。如果切换渲染空间,删除现有的 tx 文件会更安全。
为什么我们得到了不同的全局光照?
让我们在 Nuke 中使用 OCIO 来分析实际发生的情况:
- 在左侧,我们有一个纯绿色常量,位于 (0,1,0)。
- 我们使用一个 OCIOColorSpace 节点将其从 sRGB 转换为 ACEScg。
- 在 ACEScg 中表达的相同颜色在红色和蓝色通道中有一些信息。这真的只是一个转换: ACES 并没有“添加”任何东西。它是相同的色度,只是表达方式不同。

015_ACES_0180_primaries_conversion_FHD
这是另一种解释方式:
- 在左侧,我们有一个 sRGB/Rec.709 色彩空间中的绿色原色。
- 使用一个 Matrix 3×3 将参考空间从“sRGB”修改为“ACEScg”,这个具有唯一 XY 坐标的色度被“转换”了。
- 在 ACEScg 色彩空间中,该颜色不再是纯绿色(右侧图像)。

015_ACES_0200_primary_gamu_FHD
由于转换过程,光线不再被某些通道上的零值(在此例中是红色和蓝色)所阻挡。因此,光路被空通道阻挡的可能性降低了。
IDT 概述
ACES 提供了我们处理这些变换所需的所有 3D LUT 和矩阵。计算机图形学中最常见的 IDT 有:
- Utility – sRGB – Texture:如果你的纹理来自 Photoshop 或互联网。仅适用于使用 sRGB OETF 编码的、用于显示的纹理,如反照率贴图。
- Utility – Linear – Rec.709:如果你的纹理在 sRGB / BT.709 原色内是线性的,并且你想将其转换为 ACEScg,例如一个 exr 文件。
- Utility – Raw:如果你不希望对你的纹理应用任何变换,例如法线贴图。
请注意,如果你的渲染空间是 ACEScg,在这种特定情况下,“Utility – Raw”和“ACEScg”在上下文中是“相同”的 IDT。两种选项都不会应用任何变换。
绘制色域
绘制图像的色域可以让你将其像素映射到 CIE 1931 色度图上:
(第 5/9 段)
- 在第一张图中,我们绘制了在 sRGB 色彩空间下完成的渲染。像素点都位于 sRGB 色域范围内。
- 在第二张图中,我们绘制了在 ACEScg 色彩空间下完成的渲染。像素点覆盖了更广的色域。

015_ACES_0210_plot_gamut_sRGB_ACEScg_FHD
此功能可在 colour-science 中找到。如果你想绘制图像的色域,Windows 和 Mac 上还有一款名为 Color Spatioplotter 的应用程序。我自己没有试过,但从我得到的反馈来看,它似乎能以非常实惠的价格正常工作。
作为对 IDT / ACEScg 部分的总结,我想补充几点:
- 康奈尔盒示例是最佳情况。 在实际制作中,面对更复杂的刺激源,差异并没有那么重要。
- “更接近光谱”的渲染应理解为 “间接反射后的色度更接近”,这同样不一定看起来“更好”。
- 广色域渲染在显示这些图像时增加了另一层复杂性,因为需要适当的色域压缩(这是 ACES 1.X 所不具备的)。
再次强调,请自行测试,相信你的眼睛,并权衡利弊。
输出变换
ACES 1.X 的输出变换由两个独立的步骤组成,称为 参考渲染变换 和 输出设备变换。对于 ACES 1.0.X 中的所有输出变换,这仍然是正确的。但 ACES 1.1 的发布引入了一些 新的 HDR 输出变换,作为单一步骤,称为单级色调缩放。
两步骤输出变换的起源可以在 Ed Giorgianni 的这份文档 中找到:
- RRT:渲染到一个理想化的、假设的参考显示器上。它是“ACES 外观”,就像一个虚拟的胶片库存。RRT 的输出称为输出色彩编码规范。
- ODT:为特定的现实世界显示设备(原色、电光转换函数和白点)进行最终渲染。它还考虑了观看环境(暗、微亮或正常环绕)和尼特值。
在接下来的段落中,你将找到对 ACES 1.X 输出变换的描述。请注意它们的限制和问题!
参考渲染变换
实际上,RRT + ODT 过程对用户来说是组合在一起的,但我认为在此描述 RRT 的一些组件是值得的。我对那些声名狼藉的“增甜剂”特别感兴趣:辉光模块、红色修正器和全局去饱和度。以下是关于它们历史的一些 引述:
[它们] 最初源于早期旨在实现“伪胶片感”的目标。[..] 辉光来自感知到的胶片感外观。[…] 红色修正器和辉光是不同的。辉光是美学上的。
Scott Dyer
我不认为 [红色修正器] 是“增甜剂”。它是在补偿 RGB 色调缩放带来的饱和度效应。[…] 它是在补偿“过热的”红色。
Doug Walker 和 Alex Forsythe
这些“增甜剂”引发了大量争论,关于它们应该属于哪里,以及是否应该成为外观修改变换的一部分。它们也导致了可逆性问题。
输出设备变换
ODT 是在你的显示器上显示参考图像的过程,学院建议使用适配你屏幕的 ODT。 它应该基于你的项目需求:
- 你为电视和互联网工作吗?你应该在 sRGB 或 Rec.709 下显示。
- 你在制作故事片吗?你应该在 P3 下显示。
Rec. 2020 是未来,但目前还没有投影仪能够覆盖该色彩空间的 100%。技术尚未达到。但也许十年后,它将成为新的标准。所以据我所知,在 2026 年,Rec.2020 实际上仅用作 P3 交付的容器。
目前还不行,除非你拥有一台 Christie。
输出变换的示例与比较
以下是一些比较“nuke-default” OCIO 设置与 ACES 1.1 的示例:

015_ACES_0220_cornell_rec709_ODT_FHD
(第 6/9 段)
请注意,Nuke 在其 OCIO 配置中存在错误。 Nuke 中实现的 “rec709” 视图(近似于 Gamma 值为 1.95)是一种摄像机编码 OETF!Rec.709 (ACES) 使用的是 BT.1886 EOTF(等效幂函数为 2.4),并且是参考 EOTF 输出显示的。
我还对 MacBeth 色卡进行了测试,以比较 spi-anim 配置中的 “Film (sRGB)” 与 ACES 配置:

015_ACES_0280_macBeth_sRGB_ODT_FHD
我在这里明确说明一下:如果你的显示器仅覆盖 sRGB 色域,那么使用 P3D65 ACES ODT 是毫无意义的。它不会让你的渲染效果看起来更漂亮。
基本上,你的 ODT 应该与你的显示器特性相匹配。
下面提供了更恰当和公平的比较(“nuke-default” 和 “spi-anim” 并非最先进的显示变换):

015_ACES_0840_aces_odt_limitations_rec709_aces_FHD
我使用了这个实验性的 OCIO 配置来比较不同的输出变换。
在这些示例中,我们可以看到,向白色的过渡路径只是一种 “happy accident”,即颜色收敛到原色及其补色(工作空间中的光混合并未得到尊重)。

015_ACES_0880_aces_odt_limitations_rec709_aces_FHD

一个经常被注意到的问题是我们所说的 蓝光伪影。这在 ACEScentral 的 这篇帖子 中有描述。在找到更长期的解决方案之前,也提供了一个临时修复方法,例如 Jed Smith 的 Gamut Compress。
输出变换澄清
许多艺术家 对 Nuke 的默认显示变换感到困惑:
- 为什么 sRGB 显示变换和 sRGB (ACES) 不匹配?
- 因为 sRGB (ACES) 输出变换包含了一些色调映射!
在 ACES 中,我们称这一步为“渲染”步骤。从 ACEScg(场景参考)到你的显示器,这不仅仅是一个简单的色彩空间转换。它实际上是一个“复杂的”(色彩和色调)渲染操作。
Nick Shaw 也在 ACEScentral 上对此进行了解释。
输出变换概述
一些 人抱怨 输出变换中包含的 色调映射。论坛上给出了这些回答:
- ACES 的色调映射并非“中性”,它带有一种“观感”。其数值 并非随意设定,但 确实是主观的。
- RRT/ODT 的对比度 经过了众多经验丰富的行业专业人士 在精心设置的投影环境下的验证。
- 在 HDR ODT 中,色调映射的 阴影和高光压缩要少得多。
- ACES 观看变换是在 不同观看条件下的每种设备上 的“尽力而为”方案。
关于 RRT/ODT 过程的更多解释,来自 这篇帖子。
事实上,ACES 1.X 输出变换的创建面临着 “相互矛盾的设计需求”,并且其核心技术(逐通道查找)已被证明 是不充分且过于复杂 的(SSTS 代码超过一千行)。因此,我认为上述所有抱怨都是合理的,尤其是那些关于需要一个更“中性”的起点和整体对比度的抱怨。
例如,如下面的截图所示,ACES 1.X 输出变换实际上阻止了我们显示某些颜色:

015_ACES_0960_eiskoLouise_concert_sRGB_FHD
这个与 openDRT 的对比最初来自 这篇帖子。
交付
在动画工作室,我们通常将场景线性 EXR 文件交付给数字实验室,例如 这家。使用 ACES 时,概念大致相同,但有一些重要的注意事项,因为 建议交付符合 ACES 标准的 EXR 文件。
这是学院制定的用于在不同机构之间交换文件的标准。你的渲染输出将是 ACEScg (AP1),但 你的合成输出必须是带有正确元数据的 ACES2065-1 (AP0)。
在 ACEScg 中渲染使用的色域原色更接近实际设备——比 Rec2020 稍大一些,但 AP0 是文件输出(存档和交换)的目标。当完全在你自己机构内部工作而不共享文件时,有时为了方便会使用 ACEScg,但需要在文件名中使用格式来区别于 ACES 标准(在 EXR 中放入 ACEScg 并指定原色——设备或 AP1——意味着它不是 ACES 文件)。不应设置文件头中的 ACES 标志。
解释 来自 Jim Houston。

015_ACES_0380_nuke_delivery_FHD
交换和存档文件应写成符合 SMPTE 2065-4 标准的 OpenEXR。在 Nuke 中,你应该将 Write 节点的色彩空间设置为 ACES2065-1,并勾选“write ACES compliant EXR”复选框以获得正确的元数据。
如 Doug Walker 在 ACEScentral 上解释的那样。
ACES 1.X 的局限性
在我们深入探讨之前,我想让你知道,我在 2021 年 9 月写过 一篇关于显示变换(包括 ACES 1.x)的文章。这是 对本章内容的补充,也是更详细的阅读材料。请随时按你自己的节奏阅读!
ACES 回顾与改进
2017 年 3 月,一项研究列出了 ACES 1.X 的一些可能改进:ACES 回顾与改进,并得到了 ACES 领导层的 官方回应。论坛上发布了一份 包含 48 个改进点的清单,几个 虚拟工作组 试图为该体系提出一些可能的“修复”方案。
色相偏移与色域裁剪
我在使用 ACES 时遇到的两个最大问题被称为“色相偏移”和“色域裁剪”。一些影像制作者认为观众已经习惯了这些现象,并不觉得困扰,而另一些人则认为它们确实很糟糕。所以,我认为最好让你们自己来判断:

015_ACES_0690_volumetric_skews_posterization_FHD
在这些幻灯片中,我将此问题命名为“色调分离”。它已在 ACESCentral 上讨论过,并被描述为“色域裁剪”。
这类问题有不同的原因。它们相当技术性,但我已在下面列出:
- 一个 3×3 矩阵只能模拟线性变换,这可能会引起 阿布尼效应,因为它们都是直线(就像粗暴的色域裁剪一样)。
- 离散的逐通道查找(也称为“RGB 色调映射”)会扭曲原始意图。任何在 1.0 处渐近的美学传递函数都会受此影响。
- 美学传递函数最终会将许多不同的值压缩成同一个值,从而导致色域裁剪。ACEScg 的非物理可实现原色可能也是原因之一。
ODT 会裁剪数值
这些概念大多最终都与我们所说的色域映射有关。这是 ACES 1.X 中缺失的关键要素(我曾长期以为 ODT 会以某种聪明的方式重新映射色域)。不幸的是,情况并非如此,它只是进行一个 3×3 矩阵变换、一个色调缩放和一个钳位!

015_ACES_0730_red_ramp_exposure_FHD
正如你在下面的代码中看到的,一个 ODT 通过一个 3×3 矩阵和一个钳位将数值带回其色域内,这会导致一些色域裁剪。这是我们处理高饱和度值时面临的问题之一:
// 处理超出色域的值
// 将小于 0 或大于 1 的值进行裁剪(即投影到显示原色之外)
linearCV = clamp_f3( linearCV, 0., 1.);
所有 ODT 都会钳位到目标色域,因此不可能有超出色域的内容。在此过程之后,所有值都被假定在 0 到 1 之间,并且这是应用传递函数之前的倒数第二步。
我们可以说,ACES 1.X 中的色域映射非常“粗糙”或完全缺失。这真的取决于你如何看待事物……
总结
以下是我们在本章中看到的关键点:
- ACES 是一种尝试,旨在建立一个标准化的色彩管理工作流程。
- 它围绕三个步骤设计:输入变换(用于输入/导入)、ACEScg(工作/渲染空间)和输出变换(用于显示)。
- ACES 本身由四个不同的色彩空间组成:ACES2065-1、ACEScc、ACEScct 和 ACEScg。
- ACES 存在诸如色相偏移和色域裁剪等问题,这些问题难以解决。
在下面的幻灯片中,你将看到 ACES 工作流程的不同步骤:

015_ACES_0920_geometry_sRGB_FHD
(第 9/9 段)
作为一项个人练习,我尝试梳理了 ACES 1.X 输出变换的一些内容。我对结果感到满意,并将其作为 一个 OCIO 配置文件分享在我的 GitHub 上。欢迎尝试!
结论
理论上,ACES 的理念很有趣:一个旨在帮助专业人士进行色彩管理的标准。但在实践中,它是一个过于复杂的系统,实际上并不太受色彩专业人士推荐,甚至也不常被使用(除了用于交换文件)。
ACES 2.0 已经针对多个方面进行了研究,旨在构建一个更健壮、更可靠的系统。例如,ACES 1.X 中 SDR 与 HDR 输出变换之间缺乏可预测性的问题已得到改进。
在 2025 年 6 月,我在 这篇关于图像形成的文章 中完整地研究了 ACES 2.0。如果你想了解对最新 ACES 主要版本的最新分析,不妨去看看。感谢阅读!