数字色彩的艺术 | The Art Of Digital Color（修订）

翻译一篇来自2011年的文章，原链地址：https://www.fxguide.com/featured/the-art-of-digital-color/

在这个时期，DPX日渐式微，ACES方兴未艾，了解这一特殊时期会帮助你更好的理解线性工作流的用意。

原文长句较多，基础知识跨度较大，我在极力保证阅读流畅度的情况下牺牲了些许原意，并添加了一系列注解，希望能通过这段数字色彩演变的历史帮助看官们更好的理解ACES。

正文：

色彩管理和色彩工作流已经发展了多年。 这篇文章将沿着它的发展史，从Cineon开始，一路讲到场景相关（Scene Referred）的线性OpenEXR格式。Cineon支撑了这个行业18年，是时候让我们启用更为强大、更为灵活、更为准确的系统了。

为了能在视效流程中完美匹配实拍和CGI，我们需要知道我们工作软硬件所处的色彩空间。 若你不能复现电影图像的色彩空间，那你就很难生成色调一致的CGI图像并与电影图像无缝合成。如果不知道实拍镜头在色彩空间的表示方法和位置，你就无法在计算机中生成与实拍镜头一样的画面，你也不可能合成CGI镜头和实拍镜头。

Joshua Pines供职于Technicolor，同时也是学院科学技术委员会成员。下面来听听Mike和Joshua Pines的谈话吧。

Joshua Pines是Technicolor图像研究与开发副总裁，此次是以学院科学技术委员会成员的身份发言，不代表Technicolor。

现阶段，胶片介质只用于拍摄和放映，而整个后期制作部分都已数字化，两种介质的互相转换带来了很多的问题，行业一直致力于解决这些问题，以确保导演的画面能正确放映到大屏幕上。 行业努力的目标很简单：控制住数据大小和处理时间，避免图像色彩偏移或质量下降，同时推动电影制作技术的发展，从而制作出更多有吸引力、能感染观众的画面。 从女主侧脸的准确肤色到CG机器人的黑阶，再到特效和非特效镜头的交互，色彩管理的挑战需要有行业的专家来搞定。

色彩管理是一个很大的话题，它感兴趣的一个方向是8比特文件到场景线性相关浮点文件（scene linear referred floating point file）的转换。 摩尔定律提及的计算能力的提升与存储介质价格的下降带来了行业发展的契机。 曾经10比特文件看起来很大，需要存成32位（RGB x 10比特 + 2个占位比特）文件，它的存储空间比存成24位（RGB x 8比特）的8比特文件增加了40％，但在消耗的计算时间方面，电影制作流程相比数字视频制作流程更为夸张，位深越大，计算时间越长。不过在今天看来即使是64位文件都很合理，它能携带多个通道、遮罩和烘焙图在制作流程中流窜，大家已经对16比特半浮点的OpenEXR文件习以为常。

但DPX或OpenEXR文件只是容器载体。 色彩空间，伽玛和相关的数学方法才是我们解释世界的方式，它们也一直在发展演变。 Digital Domain曾组织过一批一线导演进行内部放映，看他们能否分辨出8比特电影流程（早期计算机性能差，还只能用8比特TIFF文件存储胶片扫描数据）中的镜头和全10比特对数电影流程（等价12比特线性流程）中的镜头。然而当一组相同的镜头放映出来时，只有一位导演分辨出不同，可见10比特并没有比8比特提高多少画质。 既然如此，为什么这个行业还要自找麻烦，不断地追求更大、更复杂的文件格式呢？

因为我们需要这些新的文件能满足新的需求。的确，来自胶片扫描数据的8比特文件与胶片原片对比确实看不出特别明显的差别，但那个时代也不需要我们在这些序列上做太多的特效处理。 早先的特效主要是实体特效和微缩模型。 配光在实验室用印片机灯光完成，人物特效也经常采用替身完成。比如施瓦辛格在《真实的谎言》的Bonaventure酒店大堂骑马的镜头就是使用相似体型的替身遮脸来完成。 所以在早期我们并不需要创造一个《本杰明巴顿奇事》中布拉德皮特的数字替身来展现返老还童的特效。

数字视频和8比特

在九十年代早期，Discreet公司率先发布了Flame软件，它是数字电影合成的先驱，也是那个时代在后期制作环节更精细分工的一个体现，那个时期许多电影流程都用LUTs把10比特Cineon胶片扫描文件转换成8比特的“线性”文件。LUTs是不可逆的（文章此处说的不可逆指的是10比特到8比特的过程数据有损失，其实LUTs的转换是可逆的），它会从胶片更大的色彩范围中采样出恰好8比特，并从Cineon印片机密度（Cineon Printer Density，简单来讲就是DPX文件的分辨率和色域。在这里密度不仅体现在扫描分辨率上，还体现在色域解析能力上，详细请参考论文：Grayscale Transformations of Cineon Digital Film Datafor Display, Conversion, and Film Recording）的色彩空间转换到数字视频的色彩空间，以便制作电影特效。

早期胶片和数字格式之间的隔阂比现在大的多。数字格式为了在电视或者电脑上播放，都有gamma校正的过程，但因为“线性”这个词看起来和Cineon文件的“log”编码方式（柯达通过这种编码方式把12位数据压缩进更小的10位的Cineon文件）相对应，所以数字格式的色彩又被很多人称为线性色彩。行业里有不少争论就是从这种术语和概念的混淆开始的，比如文件格式、比特深度、gamma、胶片与数字视频、真正的线性与gamma校正等，这些争论持续至今。

实际上，过去许多高质量数字视频都采用胶片拍摄，并且通过电视电影机实时转换过来。这些电视电影机早期有Cintel胶片记录仪，后期有Spirit DataCine胶转磁设备。但要谈电视电影机的历史还得回到John Logie Baird和电视广播的诞生，这里就不敷述了。

与Arriscan这样的胶片扫描设备不同，电视电影机主要用来把胶片转换为数字视频格式。而Arriscan胶片扫描设备则是为保护肉眼可见的胶片密度和复杂度而开发的，简而言之就是为了保真而开发的，最终扫描出的数据（Cineon文件）还要通过Arrilaser数字胶片记录设备记录回新的胶片拷贝。

Cineon和DPX文件：10比特log的时光

在有计算机操作系统的时候，胶片格式恰好就出现了，Cineon的生命从这里开始。Cineon被设计成一个全流程的数字胶片计算处理系统，它包括胶片扫描硬件和胶片记录硬件。Kodak也正是为了数字中间片的制作而设计Cineon的。它包括扫描设备，磁带机，带数字合成软件的工作站，和胶片记录设备。这个系统于1993年首次发布，1997年结束使用。

柯达的工程团队宣称全尺寸的胶片能用数字的方式录制并存储到一种10比特的log文件格式中，作为这个系统的一部分，这种文件格式与整个处理系统同名，也被称为Cineon（后缀为.cin）。重点是，这是一种中间格式，它被设计作为胶片之间的桥梁，它不是为CGI设计的，也不是最终的数字交付格式。它用来表示印片密度（printing density），即印片环节对胶片的分辨密度。Cineon文件作为胶片工序的一部分，它能确保无论从负片上扫描出什么数值，之后都能通过胶片记录设备转回胶片。它是为了保留原始负片的性质诸如色彩分量串扰、伽马而设计的，理解这一点非常重要。

与数字传感器不同，色光要到达记录其特定颜色的感光层，需要先穿过胶片中的其他感光层。蓝色光会被胶片的蓝色感光层所记录，但在此之前它需要穿透其他的感光层，包括绿色和红色感光层。这就涉及到胶片的一些关键特性。比如串扰或者RGB三色的互混特性，这种特性比在CMOS传感器上要严重的多，CMOS有互相独立的蓝绿红感光元件，而胶片某层的感光效果却会受其他层影响。当然CMOS也有自己的问题，之后会解释。

从胶片到数字格式的转换通常会涉及黑点（black point）、白点（white point）的概念。举个例子，纯白色（白点）在数字格式中相当于所有通道完全曝光，用8比特表示就是[256，256，256]，但在胶片上看则更接近白色哑光纸的那种白色。胶片所记录的真实亮度往往更高，比如汽车的闪光。如果这个超大的白光数值在转换成数字格式时被当作纯白色处理，胶片的宽容度就会导致为了把这些特别亮的白光涵盖进来，所有实际上正常的曝光都会被压的很暗，最终图像也会显得很暗。这也反映了一个现象，虽然客观上光线是均匀的，但事实上作为人类我们是使用非线的方式来理解真实的线性自然光的。举个例子，如果给你看一个从黑到白的渐变图，大部分非专业人士都会选择18%灰度作为中灰色。

胶片到数字格式文件的常见转换点是0-1023范围里的95和685。大于685的像素值就会视作比白点亮，比如镀铬上的亮斑或明亮的高光；低于95的像素值则表示为负值的黑色，实际上这些像素数值能下降到20或30。

如你所见，在今天Cineon格式依然还在广泛使用，Cineon在电影特效和制作的发展中取得了巨大成功并具有极其重要的意义。但Cineon作为文件格式还是会有一些限制，于是在90年代DPX文件格式被开发出来。它可以被视作是Cineon文件的容器载体，在DPX文件里经常能看到Cineon数据的身影。DPX或称为数字图像交换格式（Digital Picture Exchange），遵循ANSI/SMPTE 标准 (268M-2003)，是现今后期制作和视效工作中最为普遍的文件格式。

最初的DPX文件格式随着时间推移得到了改进，最新的2.0版本在2011年前后由SMPTE以ANSI/SMPTE 268M-2003标准发布。由于文件格式的核心通常都是原汁原味的Cineon文件风格，DPX太过于表现被扫描的负片中每个颜色通道的密度了，同时这种由胶片扫描设备扫描得到的，采用无压缩“对数”编码的图像也保留了原始胶片的gamma信息。DPX文件通常用来调光，但最新的DPX格式也允许携带一定数量的元数据（metadata）在相同的文件中传递，像是图像分辨率、色彩空间细节（通道深度、颜色矩阵等等）、子图像的数量、创建日期、创建者名称、项目名称、版权信息等等。然而还有一个问题，头文件信息有时也不会太准确或者多余，这就是一个可信程度的问题。

OpenEXR：浮点 - 行业圣杯

虽然Cineon和DPX的可靠程度在制作中得到了反复的检验，但在千年伊始还是出现了新的格式：OpenEXR。 OpenEXR由工业光魔公司（Industrial Light and Magic简称ILM）于1999年创建，并于2003年向公众发布。

OpenEXR的相关历史和主力贡献团队都记录在了OpenEXR的社区文档中。 ILM的原始OpenEXR文件格式由Florian Kainz，Wojciech Jarosz和Rod Bogart设计实现。 PIZ压缩方案基于Christian Rouet的算法。 Josh Pines帮助扩展了16位PIZ算法，并找到了浮点与半浮点数据之间转换的最优方法。 Drew Hess封装并调整了ILM的内部源代码以便公开发布，并维护了OpenEXR软件分发。 PXR24压缩方法是基于Pixar员工Loren Carpenter的算法。

ILM开发了OpenEXR格式，以应对特效制作中对颜色精度和控制方法的更高更新的需求。 当项目在2000年开始时，ILM就评估了传统的文件格式，并以如下理由拒绝使用它们（openexr.com对此有记录），以下是否决的理由：

• 8位和10位格式缺乏存储HDR图像所需的动态范围。
• 基于16位整型的数据格式很典型，只能表示0（“黑色”）到1（“白色”）之间的数值，但不能记录超出上述范围的数值。 “如能保留原始图像中的超范围数值，就能让艺术家在调整曝光时尽可能少丢失一些数据”。
• 再反过来看，“32位浮点的TIFF文件对于视效工作又太小题大做了”。 虽然32位浮点对于视效影像具有足够的精度和动态范围，但与半浮点数相比，其存储成本要高出两倍，精度却提升的很少。

在现在的1.7版本中，OpenEXR得到业内大多数公司的支持。 现在OpenEXR最常见的数据类型就是半浮点数。作为浮点类型的补充，OpenEXR还支持32位无符号整型。

OpenEXR作为一种开源格式，不受任何制造商或公司的约束，并在以下几个方面都令人印象深刻。

首先最重要的是，它的文件格式是浮点类型的，确切的讲是半浮点类型。 它是16比特格式，其中1个比特表示正负符号，有5个比特表示科学计数法中的指数，10个比特表示科学计数法中的尾数。如图：

对于线性图像，这种格式在每档光圈每个颜色分量上都能提供1024（由尾数表示）个数值，并且提供30档光圈（幂范围从25到-2，由指数表示），以及额外10档低精度光圈。

其次，浮点的文件格式具有一个非常有用的数学属性，即它具有天然的、内在的对数性质。 这不是说它的编码采用了对数的形式，而是说数字在用浮点表示的时候，形式上与对数非常一致。

最后一点，也是非常重要的一点，OpenEXR图像支持存储任意数量的通道，每个都可以有不同的数据类型。所以OpenEXR是可扩展的，开发人员可以轻易添加新的压缩方法，层或者蒙版可以有任意数量的属性，例如OpenEXR文件可以添加相机的色彩平衡信息。再举一个2010年的例子，在Weta工作室的支持下，OpenEXR支持立体电影工作流了，这也是OpenEXR可扩展性的一个体现。

因此，OpenEXR可以代表当前的工业技术水平，行业专家、长期的高级色彩科学家Charles Poynton预见到，在未来的几年里OpenEXR仍然能够满足行业需求，它仍然会是行业的中心，他又说“很有可能至少会持续10到20年。”

场景线性工作流

现今大部分镜头都不再采用胶片拍摄了，因此重新审视从拍摄到放映之间的影像工艺是值得的。

场景线性（Scene Linear）概念或场景相关（Scene Referred，也翻译成‘对应场景’）概念通常与影片拍摄环节有关，也泛指像素亮度与场景原始亮度之间的线性关系。

我们没有采用记录光谱的方式来记录影像，我们只有三刺激值（ tristimulous values）或红绿蓝系统。大部分现代传感器都是RGB三通道CMOS芯片，也就是说这类芯片上有红绿蓝三种光敏元件。每种光敏元件只能读取一种颜色分量。所以你可以认为CMOS芯片制造了这样一个图像的世界：每个像素只能记录一个灰度数值，而不是RGB三值组成的常见数组。它实际上是一种古怪的黑白图的形式，而且是不可见的。我们只有逐个翻译这些光敏图元，知道它们过滤的是红绿蓝哪种光，再插值生成RGB三色图像，CMOS产生的原始图像才有用。即使如此，这个称为解拜耳（debayer）的阶段，也还没有编码进入色彩空间的概念。放一个CMOS的示意图：

一些人认为在第一阶段，通过解拜耳把原始图像转换为RGB三色图像，这个图像就已经进入“摄影机的色彩空间”了。但严格来讲，我们现在还没有色彩空间呢。在采集RGB数值的阶段里，最明智的做法就是标定一个三基色集，确保这个三基色集尽可能接近传感器的硬件基色集（硬件能捕获的真实的基色光谱组成的基色集），在这个阶段你没有裁剪色域，也没有缩小色域，只是尽可能的接近这个能保留更多原始信息的三基色集。你不能直接使用这个相机空间，但它能把传感器的电信号表达出来，这才是关键。所以第一阶段并没有真正意义上的色彩空间概念。

下一个阶段就是把矩阵传递给影像，通过线性运算进入色彩空间了。什么色彩空间才是正确的？

胶片对于场景线性工作流是不完美的，因为负片在影像中留下了“指纹”，并带进了Cineon文件，这个“指纹”指的不是Cineon文件的log编码特性。如果你有数字摄影机的知识背景，你可能会问“胶片会被扫描进什么色彩空间？”。但这个问题其实很有迷惑性，也很复杂。胶片扫描影像的色彩空间会受胶片的响应曲线的肩部和底部影响；它还受胶片的透光特性影响，胶片的多层结构会产生色彩的色度亮度干扰；它还会受胶片的加工过程（想想交叉处理或冲洗对图像会有什么影响！）影响；当然，还会受到柯达、日本富士两家公司的影响。但是别忘了Cineon是被设计为胶片数字中间片的，它设计的目的是把胶片感采集到数字文件中。

对于场景线性工作流来讲，数字拍摄绝对是一个更好的选择。场景线性工作流会告诉你：“让我们对应真实世界，而不是以显示设备为准”。最纯粹的场景线性指的是现场亮度与RGB数值之间的、无偏、且不做编码转换的线性关系。它不是用来直接预览的，它是一个图像的线性基准（base line linear，这个词源于Scene linear）。

相比之下，进入REC709色彩空间就完全不是场景线性了，与场景线性的理念相反，图像在高清显示器的工作空间中时，图像对应的是显示设备。 显示设备的能显示的色域远低于真实场景，在显示器上显示的图像也经过了gamma矫正，此时它的数值对应的是显示设备，而不是真实场景了。场景线性工作流不会这么做，它只对应镜头前的真实场景。

那么场景线性工作流会进哪个色彩空间？这是个好问题。

在这里我们需要考虑摄影机公司，因为他们才是这个问题的关键。

每个摄影机公司都希望摄影机卖的更好。但后期制作行业希望图像是一种通用的可交换的格式。试想一下，我们希望在后期环节用一套流程就能搞定任意厂商的文件格式，但相机生产商的想法截然相反。他们希望自己的摄影机与众不同，你才会无视其他便宜货，他们的摄影机才能卖高价。

所以相机生产商应该怎么做呢？

大部分的相机使用流程都很灵活，所以通常你很少会被局限在一个选项上，但实际上它们的偏好风格是非常明确的，这些偏好风格上就体现了每家公司独有的特点。

RED数字摄影机公司会推荐你采用REDcolor2色彩空间。这是他们自有的方案，你可以说这反映了他们的独特风格，他们渴望成为一种与众不同、富于开创精神、一种“特别且更好”的方法。RED的解决方案就是如此，他们会坚持他们的摄影机最好，这是他们摄影机上最好的方案，而且REDcolor2在RED摄影机上确实表现不错。

阿莱会推荐Alexa Log C色彩空间，它是带有Cineon风格的解决方案，它基本上涵盖了胶片从曲线底部到肩部的所有细节，而且不会有胶片特有的串扰现象。这也反映了德国电影摄影机的历史。他们热爱电影，他们更懂电影，他们一丝不苟的对待它。这就是阿莱的解决方案，他创新且高效，他建立在过去的优秀成果上，并对此保有敬意。

然而索尼从数字格式中找到了另一种方法，索尼确实比其他公司要更了解数字格式。索尼为他们畅销又强大的电子设备寻找色彩标准方面非常有日本人的做事风格。索尼并不关心解决方案是否是一个诸如CCIR 601或者REC 709的标准，索尼认为对于最专业的解决方式应该是能广泛适用的。短期内，索尼会支持他们的Log S格式，这个是log编码但不是模仿胶片的log性质。从长期来看，索尼可能会是第一家采用Academy ACES标准的摄影机公司。这是索尼的方案：应该有一个专业的高端标准，它应该是一个公平竞争的环境，之后它们还会不断寻找更好的新标准。

至于其他的公司，我们可以概括如下：松下追随索尼，佳能还在原地打转，Vision Research 在某种程度上追随RED （因为这不是他们的主要市场，而且他们只想从摄影机生意里多赚钱，无意深耕）。当然所有这些都是泛泛之谈，但也不是没有道理。

所有这些解决方案带来的难题已经很清楚了，那就是难以创建出一个流程来兼容这些格式。大多数制造商为图省事，建立了“基本都是他们自己的东西组成的流程”，Charles Poynton开玩笑道。“他们创建了流程所以你能在那个全流程系统里干活，所以你可以采用他们设定的数据制式作为摄影机的默认值，并接入监视器中来预览好看的图片”。接下来的挑战就是需要有一个工作流程来兼容真实的制作情况：大部分制作和大部分公司都不得不处理一大堆摄影机型号、文件格式以及不只一个工作流。

ACES：学院色彩编码规范（Academy Color Encoding Specification）

索尼已经采用的ACES工作流和IIF色彩空间是什么呢？尽管它还未被批准和完全发布。

不久前，电影艺术科学学院（Academy of Motion Picture, Arts and Sciences，缩写为AMPAS，也常被称为Academy）再次决定把工作重心调整到它们名称中的“科学”上，Charles Poynton沉思道。AMPAS正在提出一个主要用于电影制作和后期的标准，这将是一个新的中间地带。

ACES处在学院科学技术委员会的保护下。它实际上是图像交换框架（image interchange framework，简写为IIF）中的一部分。ACES确实拥有很多来自工业光魔的技术，目的是让ACES文件将成为支持场景线性工作流的图像。但想要ACES有所作为，它就需要放在更大的一个框架中，在这个框架中需要考虑摄影机的特性、渲染和显示的因素。

AMPAS并没有说这是一个数字中间片的标准（类似于Cineon），而是说“我们能创造一个有影响力的新流程吗？我们能把所有不同的数字原始素材转换到这个新的色彩空间中吗？我们能把这个新的色彩空间做的高端大气上档次吗？我们能在里面不做妥协游刃有余为所欲为吗？”

我们能做一个独立于设备厂商、不官僚不迟钝、且一视同仁、还能满足所有人需求的色彩管理流程吗？

下面是现阶段的一些思索：

每台摄影机都是不同的，每台摄影机都有必要保持差异，但应该可以发布一个公共的高端标准，再让摄影机厂商参与进来，以容许用户把图像渲染或转换到这个标准空间。更进一步，这个空间应该是场景线性的，它不应该有魔法数字，从真实场景到这个空间的转换应该可以通过数学的方式完成。在这个新的空间里渲染的CGI图像的数值精度也可以很高。每个摄影机公司都需要了解自己的摄影机硬件再做这个转换，只要在这个公共的标准空间里，甚至无论原素材的分辨率、噪点、动态范围如何，只要在这个公共的空间里，所有的文件就都是场景线性。导演关于蓝色的构想不会受放映方式影响，这个蓝色也不会被裁剪或限制在一个很小的色域中。事实上， ACES / IIF色彩空间的色域非常宽广，甚至会略微受限于OpenEXR的当前版本，因为影响不大，所以其实我们也不必重新编译OpenEXR。

一旦我们在ACES中对电影进行了调光、配光、或图像处理的操作，我们就有必要摒弃一些感性的、灵活的想法。我们的真正目标只有一个，那就是电影院、高清显示器或其他设备。为此，AMPAS又起草了一份关于渲染器的规定，渲染器会把文件转换到与显示设备相关的图像，比如标准Rec 709色彩空间。需要重点说明的是，这个最终转换依然是标准化的，每个公司都不能利用这个渲染规定回到之前略有不同的创意性版本。即使是不同的公司，相同的转换都要确保结果一致。

ACES工作流的阶段

像素数值与真实场景成正比关系，在摄影机前的光子数量和IIF / ACES工作流中的像素数值之间有一个线性对应关系。所以这个工作流的秘诀之一就是要懂得抛掉那些让影片看起来更炫酷、在摄影机厂商眼里更好的“特殊调味料”，比如各种LUT。

IIF工艺流程

开始阶段:  IDT / 输入设备转换 / (Input Device Transform)

传感器应该是线性的，但有时候传感器也会有类似S-log或Log C这样的响应曲线，所以第一步就是输入设备转换，也称为IDT。IDT会还原这条曲线。每一种摄影机都会开发自己的IDT，只有通过IDT，传感器获取的原始图像才能被转换到ACES色彩空间中。值得注意的是，RAW文件存在于这个阶段之前，这个阶段还包含了上文提到的解拜耳（debayer）工序。

中间阶段: ACES

超级大的ACES色域

这是流程图的中间环节。在这儿我们可以认为色域是巨大无比的（与Rec 709或Adobe RGB对比），而且实际上是无限大的。这听起来会比较奇特，但由于ACES的色彩空间很大因此在做数学运算的时候非常有用。如果你要在在ACES色彩空间中调色、或是图像处理，你会发现想要到达它的边界或者越过去简直不可能！因为它的色域就是那么大！

ACES的色彩空间是一个非常宽的色彩空间，“它不仅仅是宽阔，而是难以置信的宽，它的色彩空间超过了可见光的范围”，Joshua Pines（作为AMPAS的成员）解释道。

最后阶段：参考渲染转换（RRT， Reference Rendering Transform） / 输出设备色彩转换（ODCT， Output Device Color Transform）

最后一个阶段是一个逆变换，这个阶段不仅会把图像从ACES空间中渲染出来，还会针对观看设备的特性，提供像是在电影院里看电影一样的类似电影质感的图像。虽然中间ACES图像有着理论上无限大的色域和动态范围，但最终输出还是会因为特定设备的特定编码有一些限制。这是为了适应屏幕比原始场景更暗的客观情况。举个例子，阳光下的光线亮度比拍下这个场景并在室内播放出来的亮度要高得多。我们认为两者看起来一样是因为在室内即使开着电视，光线也比户外要少，这对于准确观影是至关重要的。这一步对ACES文件进行逆变换，渲染图像并进入显示的色彩空间，再输出到显示设备上。RRT与ODCT的区别大家自己查吧，我就不提了。

它行之有效吗？

这是一个很有价值的问题，但答案还没有结论。毕竟草案还需要从Academy向SMPTE提交并通过才能称为标准。Academy还不是一个标准机构。

但它看起来真的要起飞了。甚至在它发布之前，一些公司就已经添加好了ACES选项，你可以直接使用。举个例子，即使以后RED可能会有更好的解决方案，但你现在已经可以在RedCineX中把.r3d文件导出成ACES/OpenEXR文件了。

ACES代表一切吗？显然不是，明白这点很重要。它不是RAW格式。转换到ACES之前你需要确定一个原始的定义好的色彩空间，诸如色温、白平衡、饱和度等都需要确定好。可能有人会认为这是在吹毛求疵，因为在他们的观点里把RAW文件（比如Arri-RAW或者RED RAW文件）转换成浮点ACES文件，文件就进入了灵活的浮点空间，看起来它依然可以调整和编辑，所以它应该还是RAW格式，但实际上这种观点是错误的。不像转换到Rec709很多属性就定死了，一旦转换到OpenEXR ACES文件，它依然能够无压力的调光，能无压力的调整成其他风格（就像你在RAW文件上随意修改色温一样）。但OpenEXR ACES文件确实不是RAW文件，而且还是有许多人还喜欢把它保存成RAW格式，这必然是错误的。在这里再强调一点，RAW文件指的是传感器在第一阶段未解拜耳的原始数据，所以RAW和ACES有着本质区别。

Ray Feeney，AMPAS的科学技术委员会的联席主席，也是科技行业领袖之一，在今年的国际图形学年会（Siggraph）上讨论了色彩空间和色彩管理的ACES / IIF计划，可以肯定地说，科学技术委员会以及 SMPTE都在积极寻找行业切入口来完成这个工作。

它怎样实现？

ColorOpenIO (OCIO) and Nuke

多年来Sony Pictures Imageworks都在用ColorOpenIO管理他们的色彩流程。基于2003年开始的开发工作，OCIO用一种统一的、跨多个图形应用的方式解决色彩变换和图像显示的问题。不像其他的色彩管理解决方案，OCIO面向电影后期制作，且着重于视效和动画的色彩管理。

OpenColorIO很快就会出现在Foundry的产品中并成为标准，例如Nuke 6.3 v3。

值得注意的是，OpenColorIO广泛支持包括ACES / IIF学院标准或ACES1.0标准草案在内的色彩管理方法和流程。

这就意味着Foundry的全产品线都支持ACES，这些软件的色彩管理工作流也是相互畅通的，而且这个工作流是建立在Sony Pictures Imageworks的实景制作经验之上的，这个工作流恰好还与他们内部的OpenEXR-Nuke流程完美契合。我们还没有机会去测试RRT的实现，但Sony Pictures Imageworks已经承诺开源并做了一个安全的赌注：他们关于RRT的实现必然会完全遵守ACES/IIF草案。

Nuke会把每幅图像转化到浮点的线性色彩空间，并把这个功能作为Read节点的一部分。Read节点允许选择LUT移除gamma校正、调整对数空间。虽然Foundry也在gamma校正和线性色彩计算上做了很多工作，但它的色彩空间的色域映射能力没那么强，启用OCIO将改善这个问题。

Autodesk Flame

Autodesk最新发布的Flame也支持场景线性工作流。Autodesk偏好场景线性工作流和ACES风格的方案有一个最强烈的原因，Autodesk是三维动画软件、视效CGI软件行业的主要玩家，他们对这种风格的工作流有着最强烈的使用动机。

Autodesk也是调光系统Lustre的生产商，所以关于这个工作流的每一场狗斗都少不了它。如果Flame2011和2012顺利实现了这个工作流，那么Autodesk就是唯一提供全流程解决方案的厂商了，Autodesk非常清楚这一点。Flame最近的线性工作流功能大幅提升了Autodesk的合成战斗力。

Flame'的最新LUT编辑器和Photomap

Flame为场景相关的工作方式提供了新的工作流，包含了增强的LUT编辑器和新的Photomap工具，作为相关功能之一，“色调映射”是使用这个工作流的关键。

色调映射的过程规定了场景相关的图像应该如何转换到显示相关，因为图像最终需要在显示设备上观看！“摄影技术就是一个很常见的色调映射系统的例子。它获取场景信息，再进行了一系列色彩变换，照片一旦打印在纸上（或投影在电影屏幕上），在特定观看环境中就会接近于原始场景”，Autodesk的系统产品人员Philippe Soeiro解释道。

关于Photomap工具，Soeiro解释说它“实际上使用了类似摄影技术的方式来驱动这个过程（从场景相关到显示相关）。Photomap允许你创建自己的摄影工序，解藕摄影系统的特性与显示设备的特性，再在色调映射时把两者结合起来。这种编码过程定义了（来自于DCI放映机，sRGB显示器等设备的）显示特性和暗含的观看条件。”

RED: RedCineX

上文提到， RedCineX支持输出ACES编码的OpenEXR文件。这是一个非常有趣的工作流。RED数字电影摄影机公司已经率先推出了支持HDRx方案的多重采样HDR电影制作技术。这个解决方案合并两次不同曝光，获得了更大的动态范围，并能在5k分辨率下高帧速率拍摄。RedCineX可以通过Magic Motion功能把这两条序列合并为一条具有广阔调色范围的单一序列。这个文件很适合场景线性工作流，同时它可以输出成色彩空间是REDcolor2的OpenEXR文件，也可以输出成色彩空间是ACES的OpenEXR文件。当然也有一些不确切证据表明，大部分RED用户还没有用过这种工作流，但如果用户越来越多，后期流程全面支持ACES，那将是非常喜闻乐见的。

RED过去所面临的一个问题是RED工作流被一些人诟病太过复杂，无论这个工作流是不是对的。但转向ACES-OpenEXR就能确保工作流更简单更稳定，所有图像格式都被扔进到后期制作后，从RED工作流转码到多种格式就不再是一个大问题。一个场景线性的工作流能够减少一些人搞砸RED流程的可能性，同时还舍弃了原生.r3d格式，并采用更为广泛的OpenEXR格式。

In production

今年，Encore Hollywood参与后期制作的《火线警探》第二季是首个真正采用IIF/ACES工作流程的情景剧。

《火线警探》由写过《生死时速》的Graham Yost编剧

Jaclynne Gentry在Film&Video的文章中引用了美国电影摄影师协会（ASC）技术委员会主席Curtis Clark的一句话，“如果你有动态范围像胶片一样宽的数字摄影机，但之后你把它转换到一个色域有限的空间比如Rec. 709，那你将丢失亮部细节”。他又补充道，“所有细节你知道都在那但突然就消失了。所以你怎样才能在一个工作流中保留全部的细节直到最终输出？”

“这是主要的差异”，ASC的电影摄影师Francis Kenny说到，“这种差异不仅仅局限在亮部和暗部。在中间调的范围里你也能看到渐变和灰阶的不同。”

Encore是好莱坞最受尊敬的后期工作室，他们的工作流是这样的。情景剧会用Sony F35或SRW-9000PL拍摄，并从相机的RGB图像转换到10比特的4:4:4压缩率的S-Log/S-Gamut编码的色彩空间中，以便记录到录像磁带（或者10比特的DPX文件）。

在调光环节，这些10比特图像通过IDT转换成16比特OpenEXR文件。在这个过程中，S-log编码的拍摄数据会被线性化（用一维LUT实现），S-Gamut的色域信息会通过3x3的矩阵色彩转换到ACES的色域。从这里开始，除了Lustre不能原生读取OpenEXR ACES文件之外，后期流程就都是OpenEXR (ACES)了。对Lustre来讲，16比特的线性ACES编码文件会“被快速的重编码成log格式”，Clark说，这样Lustre的log工具集才能参与调光，这种调光方式和围绕数字视频展开的线性调整方式（包含lift、gain、gamma三个操作）不一样，这种调光方式对有着宽广色域的ACES数据不合适。在调光结束后，数据会被重新线性化。

显然，一旦Autodesk这样的公司采用了ACES的套路，这道转出线性空间的工序就不需要了。

总结

柯达公司的Cineon为行业做了很多贡献，但即使是柯达自己的胶片也已经进步了，现代胶片的表现能力早已超越了10比特线性并且比Cineon更好，Cineon已经落后于时代了。而且计算机存储和计算机性能都已提升，我们有更强的能力和更大的磁盘空间来解决后期制作问题。同时OpenEXR对GPU也非常友好，而且和现在的硬件能力与当年柯达被迫采用10比特整型对数文件格式时不一样了，在现代芯片中浮点型计算和整型计算性能一样好。

基于OpenEXR的场景线性工作流似乎正在成为整个行业的前进方向。很有可能但不打包票的说，ACES/IIF方案将会引人注目，并在未来12到18个月里，我们将在ACES工具中看到激动人心的进步。