闲话ACES（修订）

最近身边的人见面就聊ACES，ACES俨然已经是行业热点了。

ACES的确更高效的解决了色彩一致性的问题，这是符合历史进程的（+1s），无疑值得肯定。但由于色彩管理意识不强，关于ACES的认识就存在着不同程度的偏差。毫无疑问，脱离色彩管理孤立地学习ACES很容易产生偏颇。

ACES简介（口水话，可跳过）

色彩对人而言只是一种感觉，感觉会随参考和心情而变化，但色彩又是客观存在的，它由物体的物理特性和光照所决定，所以它又是可以量化的。

什么是色彩管理，通俗一点，色彩管理确保摄影机拍摄的原始数据在各类放映设备上都观感一致。DI环节、CG制作环节和放映环节观感一致，色彩管理的目的就达到了。

那么如何统一这些环节的色彩观感呢？首先这个色彩是需要被量化的，只有色彩被量化，才能进行计算，才能被控制。

当你把某些场景用数字摄影机记录下来的那一刻起，这些东西都是已经被量化的。它们是如何被量化的？在色彩科学（color science）发展的历史进程中出现了多个色彩模型，来规定色彩的向量空间，量化这些分量，并且限定色域。

随着摄影机型号及品牌日趋丰富，其能表达的色域和色彩编码的方式也越来越多，它们都可以涵盖到色彩空间这个概念中，要统一这些色彩空间，就需要有一个公共的色彩编码系统在这些色彩空间之间建立转换关系，而这个公共的色彩编码系统一定是与设备无关的。

有些摄影机输出的raw文件是场景相关的（可以认为是linear编码，比如RED摄影机），有些摄影机输出的raw文件是设备相关的（可以认为是log编码，比如ARRI摄影机），采用log编码方式的raw文件都可以通过LUT转换为linear编码，虽然linear的编码方式已经可以参与线性计算了，但此时的色彩空间依然处在不同子空间中，为了统一这些子空间，ACES色彩空间就横空出世了。

广义上讲ACES是学院色彩编码系统（Academy Color Encoding System），它是一套色彩空间及编码方式的转换体系；狭义上讲，ACES指的是这套体系中最为核心的、用作中间交换的色彩空间，这个色彩空间的全名是ACES2065-1，一般简称ACES。这个色彩空间色域极大，你几乎无法触及它的色域极限。放个ACES及其相关色彩空间的色域对比图：

ACES色彩空间宽阔的色域远超其他标准，OpenEXR格式提供了16比特浮点数据结构也刚好能支持这个色域的存储，这当然就为统一各类色彩空间创造了条件，各类色彩标准的色域几乎都在这个范围，完全不用担心某个raw文件的linear编码的色彩空间转换进ACES时会丢失色彩信息，也不用担心ACES转换回这些色彩空间时会造成临界色彩溢出（实际上这个问题还需要时间解决）。

ACES的出现就是历史的必然。

但大部分制作团队的问题在于缺乏色彩管理的理论知识和经验，而不是没有采用ACES这类新技术，即使采用了ACES，如果缺少色彩管理经验，问题一样无法解决。

由于我的工作重点并不在这里，我就不把相关知识再扒一遍了，简单举个Nuke的例子来谈谈色彩管理和ACES吧。

• 在未采用ACES方案进行色彩管理的情况下，想要统一DI环节和制作环节的色彩，只需要DI提供相应LUT即可。Nuke中的viewerprocess挂上该LUT（一般还要再转换到rec709色彩空间中），就可以统一DI环节和制作环节的色彩观感了。
• 在采用ACES方案进行色彩管理的情况下，ACEScc和ACEScg可以架起拍摄、DI环节与制作环节的桥梁，且配套工具内置大部分摄影机的LUT，DI也不需要额外提供LUT，确实省了功夫。
• 如果拍摄环节、DI环节采用ACES的色彩管理流程，且DI软件（Davince Resolve）的ACES Output Device Transform选择ACEScg，并输出为exr格式，再交付到后续环节，那么后续VFX制作环节就不需要做过多设置，因为ACEScg在这里就相当于挂载了LUT并以linear形式编码存储了，Nuke和Maya都能正确识别自动配置，这两个软件的工作空间都是在ACEScg中的，默认输出也是ACEScg的色彩空间，但值得注意的是：输出给下一个环节（Publish）的色彩空间需要根据情况选择ACES2065-1或者ACEScc，这依然需要和DI环节或者IO环节反复确认，商定方案。
  有三维的小伙伴会担心输出的ACES色彩空间的线性OpenEXR文件颜色过于艳丽，动态范围不足，色彩信息大幅损失。
  这其实是多虑了，因为ACES的色域足够大，几乎不会有溢出的情况。实际上你也可以把Maya输出的exr文件导入Nuke，再利用OICOFileTransform节点多次转换回默认linear色彩空间来验证这个特性。
  如果担心的是制作时不方便观察高亮区域和暗部细节，可以请技术部门或者DI部门提供预览HDR素材的LUT。你可以在多个view transform之间切换，以观看不同的效果。
• 如果拍摄环节、DI环节都没有采用ACES，而你想在制作环节中独立引入ACES进行色彩管理，就必须要考虑转换的问题，需要手动设置。以合成环节为例，如果你的素材是RED ONE拍摄的，以RedLogFilm的形式编码且文件格式为dpx，那就有必要修改default LUT settings中的log files选项，如图：
  
  实际上在拍摄环节、DI环节未采用ACES进行色彩管理的情况下，我是完全不推荐在VFX流程中强行使用ACES的，因为你无法确定你拿到的dpx序列（或者exr序列）与.r3d序列在色彩空间和编码上是否一致，你拿到的dpx序列极有可能是从RedLog转到Cineon的；而且很有可能DI环节并没有采用ACES的色彩管理方案，你的显示色彩与DI环节的显示色彩也不一定能一致。所以请一定与DI环节或者IO环节反复确认过此事。

  如果一定要在VFX环节用ACES，建议用.r3d文件或者.ari作为初始序列，自行做raw-->ACEScg的转换。官方也是这样推荐的。

下面再以阿莱RAW文件举两个例子。

• 如果拍摄环节、DI环节都没有采用ACES，你想在制作环节中独立引入ACES进行色彩管理，就必须要考虑转换的问题，需要手动设置。
  
  以合成环节为例，如果你的素材是阿莱摄影机拍摄的，原始文件就是.ari格式，就需要手动做一个色彩空间转换，如图：
  
  
• 如果拍摄环节、DI环节都没有采用ACES，你想在制作环节中独立引入ACES进行色彩管理，就必须要考虑转换的问题，需要手动设置。
  以合成环节为例，如果你的素材是阿莱摄影机拍摄的，而你从DI部门或者IO部门拿到的序列是exr文件格式，且并未经过编码转换，那还是需要做手动做这样一个色彩空间转换，如图：
  
  

下面再稍微谈谈合成外的环节。Maya中的情况就稍有不同，因为Maya并没有集成OICO（实际上Flame，Lustre，Houdini，Photoshop都没有集成OICO，依靠自身的色彩管理模块来实现ACES），所以在Maya中你不能做类似Nuke中的转换工作。想在Maya中采用ACES色彩方案你就需要打开Preferences面板，将其设置如下： 
     

这样的话，图片导入的色彩空间和渲染的工作空间以及显示、输出的色彩空间就都是ACEScg了。你可以通过为相机添加一个imagePlane并渲染出来与原序列做对比的方法来验证，此处略过。

显然，无论是否采用ACES，VFX环节都需要与DI环节密切配合，请反复与DI确认色彩管理方式，不要一味尝新。

关于ACES在Nuke中的实现（详情请看源码）

在Nuke安装目录中可以找到如下文件夹：”..\plugins\OCIOConfigs\configs\aces_1.0.3\python\aces_ocio\colorspaces“，里面有各类转换的实现代码。随便翻翻就能看到大部分色彩空间转换到ACES中都需要LUT来映射（RED除外，它的成像过程是典型的场景相关--Scene Refered，r3d文件的原始色彩空间几乎等价ACEScg），而且几乎都是先转到某线性空间再空间变换到ACES中。只不过这一部分封装的比较好，用户分分钟不明觉厉。而且其实这一套方法和Nuke的线性工作流是异曲同工的，换句话讲，ACES和Nuke默认色彩管理方案在实现上套路极为相似。更进一步，其实ACEScg和Nuke自身的默认线性工作色彩空间基本一致，这一点你可以通过勾选Read节点的raw data选项来确定。

至于ACES鼓吹的纯数学转换，仅限于坐标系变换，比如ACES2065-1<-->CIE XYZ、AP0<-->AP1。这都是线性计算，只是空间变换而已。其实一些能被拟合的LUT也可以通过数学计算实现正逆转换。

还有一些小伙伴认为只有在ACES中才能实现LUT的逆运算，但实际上ACES中LUT的反转是通过OICOFileTransform节点实现的，用这个节点你可以反转几乎所有LUT，实际上ACES就是在OICO色彩管理系统下运行的。更进一步，Nuke的OICO config设置为ACES时，色彩观感一样可以通过OICOFileTransform的多次转换回到nuke-default。所以ACES在实现层面上并不神奇，通过LUT的转换加简单的线性变换，提供一个统一的、中立的运算空间（你管它叫工作空间、work area、color space、working space都行）。它胜在提供了一个被各大软硬件厂商认可的色彩标准，这个标准具备作为中间色彩空间的实力，它能够统一现今大部分色彩空间。总结一下就是：OICOFileTransform提供了转换色彩空间的计算工具，而ACES提供了一个能存储任意色彩的数据结构，以确保转换过程不会溢出。

其实只要具备色彩管理的概念，知道OICO的相关知识，有一些阅读代码的能力，这类常识性的认识误区都是可以避免的。

（刚聊开两百字就匆匆结束，似乎也没怎么聊色彩管理）

最后再提一下，无论采用怎样的技术，都要充分理解它的应用场景和该场景背后的技术体系，尽量避免孤立的学习新技术。

一般在有DI部门的公司里，色彩管理工作都不差，可以找几个理论基础扎实的调色师问问，术业有专攻，此话不假。

再次强调，ACES不是银弹。

对新技术有兴趣是好事，但这是建立在对旧有知识体系的理解和尊重之上的。旧的没明白，就跃进搞新的，只会背负更多的技术债，以上。