最近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中的色彩管理就是這樣自由簡單。