最近Colorspace成为了一个很高频的问题，很多Compositor为这个概念感到纠结，其实这是很正常的，因为Colorspace发展了很多年，也有很多种标准，最后还要落地到合成软件中，中间自然就增加了理解难度。
我决定将这篇释疑文分为两个部分：
一：Colorspace的来龙去脉
二：Nuke是如何利用colorspace进行色彩管理的
这篇文章尽量避开繁琐的术语和生硬的技术细节，力求浅显易懂，梳理出一条清晰简单的思路，有些比喻会不专业，但这是为了方便理解而做出妥协。
也希望这篇文章能够帮助业内人士更好的完成色彩管理。
COLORSPACE的来龙去脉：
要理解Colorspace就必须和采样设备与输出设备联系起来，简单举一个栗子：现在有一个正常工作的数码相机（采样设备），按下快门的瞬间相机会将光信号转变为电信号，再将电信号转变为数字信号，最后再以数据信息的方式记录在存储介质上。那么问题来了，这些强度不等的电信号该如何记录为数据信息？把这个问题转化一下，即投射在CMOS上的光信号该如何记录成数据信息？
这时候我们就会想到制定一个规则，打个比方，一个感光单元上接受的光照强度为0nt，则将这个感光单元所对应的像素值记录为0；若该感光单元上接受的光照强度为100nt，则将对应的像素值纪录为1；那么我们就很自然的就把光照亮度为[0nt,100nt]的区间映射到了像素值为[0,1]的区间上。在这里，我们在光照亮度与像素值之间建立了一个最简单的联系，通过这个联系，我们将镜头所见成功的记录为一种名为数字图片的数据格式。这个数据格式由一系列像素构成，每个像素记录了镜头视野中对应位置的光照强度。
讲到这里，我们已经成功的将镜头中的场景记录成了数据信息，下一步就要思考了，我们怎样将这个数据信息真实的呈现在屏幕（输出设备）上？在这里我们只需要将上文提到了光照亮度与像素值之间的映射关系反过来即可：[0,1]区间的像素值对应[0nt,100nt]的光照亮度。我们让值为0的像素在屏幕上不发光，让值为1的像素在屏幕发强度为100nt的光不就可以了吗。这种映射方式在我们的日常工作中就被称为Calibrtion Lut（矫正曲线），该曲线主要用于在色彩管理工作中校准显示设备或其他硬件，这也是本文中我们接触到的第一种Lut。
再进一步，我们都知道显示器的显示亮度并不是无限大的，举个例子，太阳的亮度在显示器上能还原出来吗，答案是否定的。显示器也有显示范围，这个范围不是无限大的，不同厂家的显示器显示范围不一样，显示质量也不同，这也是专业显示器的一个卖点。显示器厂商为了让自己的显示器显色范围与该标准一致，就会通过Calibrtion Lut来进行矫正。我们看到，显示器厂家多如牛毛，就需要统一显示效果，拍摄设备也是同样的境地，并且在技术不断发展的过程当中，视效环节作为一个重要的中间过程也参与进来。为了将这三个部分统一起来，便有了Colorspace这个标准，而Lut就成了连接采样，视效环节与输出的一把钥匙。
实际上Colorspace作为一个标准会有很多技术细节，在这里我们只提及三点：位深，记录方式，通道类型。
位深：该特性决定了Colorspace的精度。比如1和1.111111111111相比精确度就差了很多；
记录方式：采用何种映射方式来记录数据。在实际的摄像机记录拍摄数据的过程中通常会使用这两种记录方式：linear，log。简单的来说，linear会把亮度信息原原本本的记录下来，log则会对原本的亮度信息进行压缩以尽可能的节约存储空间，这个映射关系可以参考log曲线。这也是为什么大部分的linear记录方式下位深是16bit，而log的记录方式下位深只需要12bit或者10bit。log记录方式记录的拍摄素材因为对高光部分做了压缩，中间调部分提升很大，所以我们观看的时候会觉得很灰。为了正常观看log记录方式记录的拍摄素材，我们就需要有对应的lut矫正回来，这个lut称为Technical Lut（转换曲线），这个转换曲线与Calibrtion Lut对比只是用途不同，这个曲线我们在稍后也会提及。
色彩结构：一般情况下我们都会采用RGB三通道的方式作为色彩结构，将对应色相上的亮度信息记录在对应通道中，但在视效环节我们也常常会用到HSV这样的通道类型。
通过上文我们可以很快的对Colorspace有一个简单的理解：位深与通道类型决定了colorspace的数据格式，而与记录方式密切相关的Lut则是一把连接采样，视效环节，输出的钥匙。
Nuke是如何利用Colorspace进行色彩管理的：
首先我们引入第一个概念：Nuke是线性的工作流程
在Nuke的官方说明文档中有这样一句：
Nuke products support multiple file formats, such as Cineon, TIFF, OpenEXR, HDRI, and RAW camera data (using the dcraw command line program), and allows you to mix them all within the same composite. By default, Nuke products convert all imported sequences to their native 32-bit linear RGB colorspace.
大意是nuke为了对不同色彩空间的文件进行统一管理和运算，它会将导入的序列转换成位深为32bit，记录数据的方式为linear，色彩结构为RGB通道的色彩空间。
这一步发生在我们导入图片序列的时候，此时Nuke会创建一个Read节点来读取该序列。这个Read节点的Colorspace选项会有对应的默认值，这个默认值就是用来将导入序列转换到32-bit linear RGB色彩空间的Technical Lut。在这里必须详细解释一下，Nuke在导入图片素材的时候会根据图片的格式在Read节点中设置对应的默认值。通过这个步骤，无论什么格式图片都被转换成32bit的线性数据，再以这种数据来进行合成运算。在这里放置一个tips：Cineon格式的文件其实就是DPX文件，其记录数据的方式是log，所以导入DPX文件的Read节点无论是保持Colorspace选项的默认值，还是将Colorspace设置为Linear再添加一个Log2Lin，本质是一样的。
通过Read节点的默认值设置，Nuke支持的图片格式都会被转换成线形的数据，而且我们平时所做的大部分合成步骤，都建立在这个线形数据基础上。
你也可以通过Colorspace节点将已有的线性数据转换为其他类型的数据类型，或者通过vectorfield节点挂载一个新的lut来获取一个不同凡响的效果。最终这些节点产生的数据都会以相同的方式参与合成计算。
再引入第二个概念：viewerProcess
关于这个概念相信Compositor们不会陌生，它就在Viewer面板的这个位置：
在Nuke的官方说明文档中有这样一句：
Viewer Process can be used to modify the image from the viewed node before it is displayed on your monitor. Viewer Process only affect the Viewer in which it is activated and do not affect your rendered output.
大意是Viewer节点对应的合成流在显示器上显示之前会被viewerProcess修改，在哪里修改呢，在Viewer节点的属性面板中有这样一个选项：viewer process，Viewer节点就是通过这个选项修改显示结果的，而这个选项与viewer面板上的viewerProcess是一致的。viewerProcess只会影响到我们观看的画面，不会影响渲染的结果。
这就意味着我们可以很自由的在这里挂载各类Lut来预览效果，我们都知道影院放映的色彩空间标准是rec709，如果我们想在制作过程中提前预览影院中的色彩效果，就可以在在viewerProcess处选择rec709来实现，同时这个操作并不会影响我们实际的渲染结果。当然你也可以在此处选择调色部门提供的lut来预览目标效果，这一切都取决于你。
通过以上两个概念，相信诸位也不难发现，在Nuke的工作流中，如果要在某一个节点下做色彩空间的转换，就要考虑第一个概念；如果只是想预览一个lut的效果而不影响最终结果，就考虑第二个概念。如果有更复杂的情况，那就需要对这两种概念进行组合。Nuke中的色彩管理就是这样自由简单。
