翻譯一篇來自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的談話吧。
現階段，膠片介質只用於拍攝和放映，而整個后期制作部分都已數字化，兩種介質的互相轉換帶來了很多的問題，行業一直致力於解決這些問題，以確保導演的畫面能正確放映到大屏幕上。 行業努力的目標很簡單：控制住數據大小和處理時間，避免圖像色彩偏移或質量下降，同時推動電影制作技術的發展，從而制作出更多有吸引力、能感染觀眾的畫面。 從女主側臉的准確膚色到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工具中看到激動人心的進步。