实际工作中如何说清楚色彩处理流程？
- Color
- 三十分钟系列
实际工作中如何说清楚色彩处理流程？
在实际的工作中，想要准确无误的说明色彩处理的流程，并且让对方可以看到“和你一样的画面色彩”，这其实是一件挺不容易的事情…… 主要的困难在于：
- 大家对色彩管理的认知水平是否在同一层面
- 不同软件的实现细节可能不同
- 沟通过程中一些隐藏信息的丢失
- 色彩标准的版本更新
如何才能更加准确无误地说明色彩处理流程，并且保证大家都可以准确无误的进行色彩还原？
我们来看实际项目中常见的各种沟通方式：
小剧场
甲方爸爸：我这个项目用了些LUT，你接收一下，然后套上开始干
小A：…… 好的，我先看看……
Level 0: 反手就是一个 LUT
LUT 作为色彩处理的重要工具，在项目中还是非常常见的。大家进行沟通的时候可能会来回发送一些LUT。
理论上LUT 可以让色彩结果一样，但是其黑盒子的特性隐藏了很多信息。
此时对方可能就需要进行第一层额外的发问：
LUT的输入色彩空间、输出色彩空间是什么啊？- 如果有多个
LUT，那么使用的先后顺序是什么？ - 哪些镜头分别应该用哪些
LUT？ - 怎么验证咱们看到的画面结果一样？
Level 1～10：LUT + 交接规范
既然只给LUT 很难说清楚，那么更专业一点的方法就是给一份交接规范文档。
这个文档里面会比较详细的说明LUT 的隐藏信息和处理过程。
理论上有了这个文档，大家就应该都能够相互理解和明白了吧？
但是这个文档还是有一些问题：
- 文档需要编写方、接收方对于色彩管理的理解在一个层面上
- 很多软件会有操作上的差异（例如
VFX软件内部大多是linear计算，如果不了解细节，可能会得到不正确的结果） - 如果想要写出非常专业的交接规范文档，这本身就已经又是一个大的话题了……
Level 11：LUT + 交接规范 + 参考图片
俗话说得好，图片胜过千言万语！那么我们再专业一些，给出一些对应的测试参考图片，这样总能保证大家看到的结果是一样的了吧？
没错！这样理论上已经是终极解决方案了！
但是这种理想方案，在现实中出现的可能性其实还是挺低的。主要原因：
- 优秀的交接规范写出来很费时间
- 文档中很难穷尽操作级别的细节（不同软件的设置、实现细节、各种
RAW文件的metadata调整） - 色彩管理的不同版本（例如：
ACES1.0、1.1、1.2……）
你可以花时间写出来？没问题，不过这份超长的规范文档，不知道有多少人可以真正用心的读完，并且理解其中的各种细节？
如果你能够收到一份这个级别的交接规范文档，别犹豫，快表白吧！
ACES Metadata File （AMF）
现在越来越多的项目使用ACES 作为色彩管理方案，本身就是看中了ACES 的通用性。
只要使用了ACES，那么至少色彩管理可以减少一些沟通和理解歧义。
ACES Metadata File 的出现就是希望能够进一步的减少沟通和歧义！
因为传统情况下，我们为了明确说明一次色彩处理流程，至少要明确下面的细节：
- 输入色彩空间（
Gamut+Gamma+White Point） - 转换过程
IDTLMTRRTODT
- 得到输出色彩空间
AMF 其实就是将ACES 的详细色彩处理流程以XML 的形式记录下来。 这样的话，只要有了AMF，那么整个色彩的处理过程就唯一的确定了下来。
只要按照AMF 中的处理过程，就一定可以得到相同的结果。 也可以认为，一个AMF 文件理论上就完成了交接文档的大部分内容。
如何使用AMF
这里不讨论如何生成AMF，着重讨论一下AMF 的使用场景。
目前可能有两个比较好的场景：
- 代替交接规范中的一部分内容，明确色彩处理的流程
- 所有人可以根据
AMF自动渲染得到最终的图片（用于参考、或者生成LUT）
这里介绍一个库，可以方便的将AMF 解读成人工阅读的色彩处理流程，并且可以根据AMF 进行渲染：
https://github.com/pomfort/amf-util
python3 amf-util.py info [AMF_FILE.amf]
输出示例: LogCEI800-LMT-Rec.709100nitsdim.amf
description: None
uuid: None
creationDateTime: 2020-01-21T09:30:29.53Z
modificationDateTime: 2020-01-21T09:30:29.53Z
IDT: IDT.ARRI.Alexa-v3-logC-EI800.a1.v2 (ACES 1.0 Input - ARRI V3 LogC (EI800))
LMT: LMT.Academy.BlueLightArtifactFix.a1.1.0 (ACES 1.0 Look - Blue Light Artifact Fix)
RRT: RRT.a1.0.3 (ACES 1.0 - RRT)
ODT: ODT.Academy.Rec709_100nits_dim.a1.0.3 (ACES 1.0 Output - Rec.709)
我们可以很方便的了解到这个AMF 文件实际的处理过程：
- 输入色彩空间是 Arri LogC -WideGamut EI800
- 在 ACES AP0 的色彩空间下，经过蓝色溢色的
LMT处理 - 使用ACES 1.0.3 的
RRT - 最终输出Rec 709 100nit
AMF 只是一个描述文件，但是更多人在实际项目中可能还是需要一个可以直接使用的LUT。
我们可以自己在各个软件中按照AMF 中的处理过程输出LUT，但是明显有点麻烦了。
amf-util 工具也是提供将输入图片经过AMF 的色彩处理过程，渲染一个最终输出图片的能力。
（实际渲染需要使用CTL，请自行学习如何编译安装 CTL）
> python3 amf-util.py render --help
Usage:
amf-util.py render [OPTIONS] FILEPATH CTLROOTPATH
Read an AMF file at a given path and output a ctlrender command
that renders the pipeline described in the AMF file.
总结
想要对数据进行描述，就需要用到元数据！ ACES Metadata File 就是这样的存在。
通过一套规范，强制将大家的定义、理解、实现细节统一，从而减少歧义和沟通。
从这个角度来看，AMF 也是又发明了一套“规范”。 希望以后标准正式确定后，软件厂商可以快速跟进，让色彩处理流程做到沟通无障碍！
小剧场「20XX 年的某一天」
甲方爸爸：这个片子，用 A 方案处理色彩
小A：？？？
甲方爸爸：AMF 发你了
小A：收到！明白！
