[總結] 漫談HDR和色彩管理（四）HDR标準和ACES

https://zhuanlan.zhihu.com/p/144775352

上一節講到了上古時代的SDR Color Pipeline以及最常見的兩種SDR顯示及其顔色空間标準（sRGB和Rec. 709）。然而，SDR顯示在色彩管理和顯示上有着天然的缺陷，随着對色彩顯示和存儲的更高需求，我們迎來了HDR顯示的時代。這些紛繁複雜的顯示器和顔色标準給整個pipeline增加了非常大的管理挑戰，ACES橫空出世來幫助我們在各個階段都能擷取一緻的顯示結果。

# SDR的缺陷

SDR最明顯的缺點就是它覆寫的色域範圍太小，隻占了CIE 1931顔色空間的大約35.9%區域：

來源：https://nick-shaw.github.io/cinematiccolor/common-rgb-color-spaces.html

一些飽和度非常高的顔色無法在這樣的低色域下表現出來，影響色彩表現的豐富度。同時，在低色域下計算光照和渲染會導緻顔色值被clip掉，影響色彩的準确性。

其次，從SDR的OETF函數到最終顯示器亮度之間存在一條不确定的鴻溝。這是因為，SRD OETF的輸出範圍為0到1，而顯示器的最大亮度是不确定的，這和具體的顯示器型号相關，例如HDTV顯示的亮度峰值通常要大于PC顯示器。我們使用的SDR Tonemapping曲線在較低亮度的PC顯示器上可能效果更好，而在有着更高亮度峰值的HDTV上顯示就顯得缺少細節，我們當然可以為更高亮度的顯示器使用一條不同的Tonemapper曲線來增加高亮區域的細節，但這也會增加色彩管理的複雜性。

為了解決這些問題，我們引入了HDR顔色空間标準。

# HDR顔色空間标準

最常見的HDR顔色空間标準是ITU-R Recommendation BT.2020（簡稱Rec. 2020或BT.2020）。Rec. 2020定義了一個HDR顔色空間的三原色（R (0.708, 0.292), G (0.170, 0.797), B (0.131, 0.046)）和白點（D65），它的色域範圍可覆寫CIE 1931顔色空間的75.8%：

來源：https://nick-shaw.github.io/cinematiccolor/common-rgb-color-spaces.html

和Rec. 709類似，Rec. 2020标準也指定了一個精确的OETF傳遞函數：

其中，α和β在32位全精度下的值為1.09929682680944和0.018053968510807 ，在12位精度下的值為1.0993和0.0181，在10位精度下的值為1.099和0.018。

Rec. 2020标準定義了在SDR顯示下其使用的EOTF函數，這個EOTF函數和Rec. 709一樣，即是由BT.1886定義的EOFT函數。而配合Rec. 2020使用的更常見的傳遞函數是在HDR顯示下使用的EOTF函數，這是由ITU-R BT.2100定義的ST 2084或HLG傳遞函數。

## ST 2084 / PQ傳遞函數

ST 2084全稱為SMPTE ST 2084（Society of Motion Picture and Television Engineers, 2014），它是一個配合Rec. 2020三原色使用的EOTF函數（即output-referred encoding function）。它最早是由杜比（Dolby）定義的一個名為PQ（Perceptual Quantizer）的編碼函數，最大可編碼高達10000 cd/m²（尼特）的高動态亮度值。PQ傳遞函數的本質是根據人眼視覺系統對亮度的感覺對比度來最大限度地利用編碼空間對數字信号進行量化，簡單來說，就是在盡量避免出現人眼可察覺的亮度色階（banding）的情況下對資料進行量化和編碼。

下面是由人眼視覺系統衍生出來的Barten Ramp模型，它描述了在目前亮度值（橫坐标）下，兩個亮度值之間的差别達到多大百分比時可以被人眼所察覺到。亮度差處于虛線上方時，人眼就可以察覺到亮度對比進而出現所謂的banding現象；當亮度差處于虛線下面時，在人眼看來它們就是沒有差別的是平滑漸變的：

來源：HDR in Call of Duty

依靠Barten Ramp模型，我們可以評估一條亮度編碼曲線對資料的使用率。例如，下面綠線表示用16位精度（如OpenEXR格式）直接存儲亮度值所産生的亮度精度差，可見它的內插補點全在曲線以下是以在視覺上不會産生banding：

來源：HDR in Call of Duty

下面橙線和藍線分别表示15位和10位精度下使用伽馬編碼後的曲線。10位精度的伽馬編碼在0到1亮度範圍内的亮度差都在曲線以上，這意味着會出現人眼可見的色階問題。而15位精度的伽馬編碼雖然都在曲線以下，但它在高亮區域的編碼是一種資料浪費，也就是說在這些區域它存儲的大量不同亮度值在人眼看來其實是沒有差别的。紫線表示了13位精度的Log編碼，相比15位伽馬編碼來說它雖然更加充分地利用了高亮區域的資料編碼，但在低亮區域卻會造成資料浪費：

來源：HDR in Call of Duty

下面就是使用Dolby提出的PQ傳遞函數在12位精度下所得到的亮度差曲線，可見PQ傳遞函數的編碼方式在各個亮度區間範圍内都可以更加充分地利用編碼資料：

來源：HDR in Call of Duty

ITU-R BT.2100為PQ定義了它具體的EOTF傳遞函數。這個ST 2084 EOTF傳遞函數如下：

其中各常量數值如下：

其曲線表示如下：

來源：https://nick-shaw.github.io/cinematiccolor/common-rgb-color-spaces.html

可以看出，PQ OETF函數與之前見到的sRGB或Rec. 709的EOTF函數有很大不同。首先PQ傳遞函數輸出的是一個範圍在0到10000 cd/m²的絕對亮度值，而SDR輸出的則是一個在0到1範圍内的相對亮度值，SDR顯示器顯示的真正亮度值是未知的。這種确定性在我們debug時也很有幫助，例如PQ值為0.5時對應的亮度值大約為100尼特，它是老的LCD顯示器常見的亮度峰值；PQ為0.75時對應的亮度值大約為1000尼特，它是一部分HDR TV顯示器的亮度峰值。

PQ傳遞函數的視覺一緻性使得它很适合作為output-referred image的工作空間，可以最大限度地利用編碼資料減少視覺錯誤。事實上，很多遊戲引擎在HDR顯示時都會先使用PQ傳遞函數把場景線性亮度值轉換成0到1的編碼值并以此來采樣一張3D LUT做Color Grading和Tonemapping的操作。例如，UE4在為HDR顯示計算3D LUT時會使用ST2084ToLinear進行解碼來得到線性亮度值，并在此亮度值上做後續的顔色操作：

// Since ST2084 returns linear values in nits, divide by a scale factor to convert 
// the reference nit result to be 1.0 in linear. 
// (for efficiency multiply by precomputed inverse) 
LinearColor = ST2084ToLinear(LUTEncodedColor) * LinearToNitsScaleInverse;
           

在采樣這張3D LUT時，會進行上述計算的反函數來把線性亮度值轉換成0到1的紋理采樣坐标：

// ST2084 expects to receive linear values 0-10000 in nits. 
// So the linear value must be multiplied by a scale factor to convert to nits. 
float3 LUTEncodedColor = LinearToST2084(LinearColor * LinearToNitsScale);  

float3 UVW = LUTEncodedColor * ((LUTSize - 1) / LUTSize) + (0.5f / LUTSize); 
float3 OutDeviceColor = Texture3DSample( ColorGradingLUT, ColorGradingLUTSampler, UVW ).rgb; 
           

上述PQ傳遞函數需要兩次pow計算和一次rcp計算，在計算時要小心它的指令消耗：

// 
// Dolby PQ transforms 
// 
float3 ST2084ToLinear(float3 pq) 
{
     const float m1 = 0.1593017578125; // = 2610. / 4096. * .25;
     const float m2 = 78.84375; // = 2523. / 4096. *  128;
     const float c1 = 0.8359375; // = 2392. / 4096. * 32 - 2413./4096.*32 + 1;
     const float c2 = 18.8515625; // = 2413. / 4096. * 32;
     const float c3 = 18.6875; // = 2392. / 4096. * 32;
     const float C = 10000.;
     float3 Np = pow( pq, 1./m2 );
     float3 L = Np - c1;
     L = max(0., L);
     L = L / (c2 - c3 * Np);
     L = pow( L, 1./m1 );
     float3 P = L * C;

     return P;
} 
           

值得注意的是，盡管PQ傳遞函數最大可支援高達10000尼特的絕對亮度值，但大多數顯示器的亮度峰值不會超過2000尼特，甚至很多HDR顯示器的亮度峰值大約在1000尼特。最簡單的做法當然就是直接對場景亮度值進行線性縮放使其對應某個特定顯示器的亮度值，再使用ST 2084 OETF函數進行編碼并發送給顯示器。但正如我們之前在SDR顯示裡看到的那樣，這種線性到線性的對應關系并不滿足視覺上的線性關系，這會造成高亮和較暗區域都缺少細節。是以，我們仍然需要某種Tonemapping操作來把我們場景裡高動态亮度值重新映射到顯示裝置可支援的亮度範圍内，在這個映射過程中可以适當提高高亮和陰影區域的對比度來得到更好的視覺效果。ACES中就提供了幾種最常見也是最通用的HDR曲線映射（View Transform），它們被分别用于1000 cd/m²、2000 cd/m²和4000 cd/m²标準的HDR顯示。這些映射函數的設計初衷是為了讓HDR顯示可以得到和SDR顯示在視覺上盡可能一緻的畫面效果。在後面講到ACES時我們會具體看到這些映射函數。

## HLG傳遞函數

HLG傳遞函數在遊戲引擎的HDR顯示管線中并不常用，在此為了完整性我們也簡單描述一下。HLG全稱是Hybrid Log Gamma，它是由BBC與NHK電視台合作設計的一個編碼函數。HLG傳遞函數的設計初衷主要是為了相容那些沒有能力進行HDR顯示的SDR顯示器，也就是說，如果我們把HLG信号發送給一台正常使用BT 1886 EOTF的SDR顯示器，也可以得到一個合理的顯示效果。

HLG編碼函數同樣是由ITU-R BT.2100定義的，這裡僅給出HLG EOTF的函數曲線：

來源：https://nick-shaw.github.io/cinematiccolor/common-rgb-color-spaces.html

# 世界主宰：ACES

由于存在大量不同型号的攝影裝置及其特定的編碼和顯示标準，加上制作流程中各個階段（如合成、CG、VFX等）資料輸入輸出的複雜性，影視制作中的色彩管理是一項非常容易出現問題的環節，很容易出現大量的猜測和瞎蒙的情況。ACES就是為了解決這個問題而存在的一套管理系統。

ACES的基本定義如下：

The Academy Color Encoding System (ACES) is a set of components that facilitates a wide range of motion picture and television workflows while eliminating the ambiguity of legacy file formats. The system is designed to support both all-digital and hybrid film-digital motion picture workflows.

—— From github

這個系統的核心組成部分包括如下幾個部分：

• 若幹規範
  • 顔色編碼和度量規範
  • 檔案格式規範
  • 顔色轉換，并為其提供了一個開源版本（使用CTL語言）的代碼實作
• 一組參考圖像和校準目标圖像，每個圖像對應了使用ACES裡某個顔色變換對參考圖像進行處理後的結果，以此來幫助使用者驗證他們對ACES系統實作的準确性
• 對系統和軟體工具的說明文檔

ACES的文檔非常詳盡，其命名和用處都有非常嚴格的說明。如果要詳細了解ACES的各個标準和實作細節，這些文檔是最好的參考。例如，TB-2014-001是綜述性文檔，它提供了對其他各個文檔大緻使用說明；TB-2014-002提供了一份使用者産品體驗指南，來指導那些需要把ACES內建到軟體中的開發人員如何更好地向使用者呈現ACES接口和概念；TB-2014-012給出了ACES各個元件（包括顔色空間，顔色轉換，檔案格式）的詳細名稱。

對實時渲染來說，與我們關系最為密切的是ACES系統規範中關于顔色編碼和顔色轉換的部分。

## 顔色編碼

ACES系統定義了若幹顔色空間，分别用于影視制作流程中的各個階段。這些顔色空間的三原色和轉換函數的定義都是為其應用場景而特别規定的，它們包括：

• ACES2065-1：一個使用線性轉換函數編碼的scene-referred顔色空間，它主要用于ACES流程中的圖像交換工作
  • 三原色：使用名為AP0（ACES Primaries 0）的三原色值，在1931 CIE xy色度圖中其值分别為R（0.7347, 0.2653）、G（0.0, 1.0）、B（0.0001, -0.077）。
  • 白點：與D60值類似但不完全一樣的一個白點值（0.32168, 0.33767），一些資料裡甚至直接将其說成是D60，這其實是不準确的。
• ACEScg：也是一個使用線性轉換函數編碼的scene-referred顔色空間，它主要用于CG、VFX和合成階段的working space
  • 三原色：使用名為AP1（ACES Primaries 1）的三原色值，在1931 CIE xy色度圖中其值分别為R（0.713, 0.293）、G（0.165, 0.830）、B（0.128, 0.044）。
  • 白點：白點值與ACES2065-1一樣，即（0.32168, 0.33767）。
• ACESproxy、ACEScc、ACEScct：這三個空間的三原色和白點值與ACEScg一樣，但使用了不同的編碼深度和傳遞函數。例如ACESproxy使用10-bit或12bit整型資料編碼、使用log作為傳遞函數的顔色空間。這幾個顔色空間主要用于影視制作流程，遊戲實時渲染裡很少接觸。

AP0和AP1三原色的值是一大批專家們為了它們的應用場景而嚴格設計和定義的。AP0的三個頂點所圍成的區域包含了整個光譜軌迹：

來源：https://nick-shaw.github.io/cinematiccolor/common-rgb-color-spaces.html

AP0的定義是為了能夠在AP0線性顔色空間下使用正值來編碼所有人眼可見的顔色值。盡管AP0對應的三原色顔色值在實體上是無法實作的，也就是說我們無法在真正的現實世界中創造出這樣的三種顔色（類似1931 CIE XYZ三原色），但這與它的應用場景有關，由于其色域之廣使得它非常适合作為各個制作流程之間圖像傳遞的中間顔色空間，可以最大程度地減少資訊丢失。

與AP0相比，AP1的色域範圍就顯得“保守”許多，它所圍成的色域範圍與Rec. 2020非常接近，雖然仍然略微越過了光譜軌迹：

來源：https://nick-shaw.github.io/cinematiccolor/common-rgb-color-spaces.html

與AP0為了最大限度儲存和編碼顔色資訊的目的不同，AP1更适合用于CG和VFX裡的渲染和光照計算工作。渲染使用的顔色空間選擇是非常重要的，這會影響光照的計算方式進而影響我們最終的渲染結果，尤其是間接光照的計算。可以說，盡管大家都是平等的，但某些顔色空間就是比其他顔色空間算出來的顔色更好更正确。

這就不得不提到顔色空間的比較了。在計算機渲染領域，我們任何的計算都是要基于顔色空間的三原色，也就是這個顔色空間在三維空間裡的三個基向量。考慮以下情況，我們在sRGB空間使用某些顔色進行一定光照計算後，将結果再轉換到CIE XYZ空間得到結果A；再把這些sRGB空間的顔色先轉換到ACEScg空間進行同樣的光照計算後，将結果也轉換到CIE XYZ空間得到結果B；令人警惕的是，結果A和結果B往往并不是等價的。在數學上我們可以更容易了解這個現象，各種顔色空間的三個基向量在XYZ空間下都不是正交基，在這些非正交基下做的計算，除了加法和減法等操作以外，乘除和取幂等常見的光照計算都不是等價的。那麼如何對比這些結果哪一種是更正确的呢？我們一般認為使用光譜渲染器（例如Mitsuba，使用波長進行顔色計算）得到的結果是ground truth，Ward and Eydelberg-Vileshin (2002)、Langlands and Mansencal (2014)、Mansencal (2014)等人分别做了若幹顔色空間的對比試驗，Anders Langlands和Thomas Mansencal在Computer Graphics的一篇文章裡對這些試驗結果進行了簡單的解釋，以下是他們的對比結果：

來源：https://chrisbrejon.com/cg-cinematography/chapter-1-5-academy-color-encoding-system-aces/

上述前三行分别是Rec. 709、Mitsuba、Rec. 2020對同一目标的渲染結果，後兩行是用Mitsuba減去Rec. 709和Rec. 2020得到的內插補點，顔色越暗表示內插補點越小也就意味着結果更接近ground truth更正确。可以看到，整體而言Rec. 2020的表現更接近光譜渲染的結果，但也可以看到在某些情況下，Rec. 709的表現的确更好。實際上，我們仍然無法拍胸部說存在一個顔色空間是最最合适用于計算機渲染的，但正如Thomas Mansencal說到的：

Some RGB colourspaces have gamuts that are better suited for CG rendering and will get results that overall will be closer to a ground truth full spectral rendering. ACEScg / BT.2020 have been shown to produce more faithful results in that regard.

—— From this article

前人的研究表明，那些三原色越接近光譜軌迹的色域空間渲染出來的結果往往更接近光譜渲染的正确結果，ACEScg就是這樣一個顔色空間，它的三原色AP1在光譜軌迹附近，且包含了Rec. 2020等常見的廣色域空間，是以它非常适合作為CG和VFX等計算機渲染的工作空間。

在十幾年前sRGB和Rec. 709是行業最通用的标準，但随着技術發展，Rec. 2020等HDR廣色域顔色标準大行其道，老的SDR色域空間退出曆史舞台是早晚的事。AP0和AP1的這些特性，使得即便在未來有更多廣色域的新顔色空間被提出來，它們也仍然具有非常強的相容性，短時間内不會被曆史淘汰，這也展現了ACES系統的強大之處。

## 顔色轉換

ACES還為影視制作的各個階段定義了一套完整而強大的顔色轉換。這些轉換包括：

• Input Transform：之前也被稱為Input Device Transform（IDT）。ACES 1.0裡的正式名稱是ACES Input Transform，簡稱Input Transform。它負責把輸入資料轉換到scene-referred顔色空間。例如，各種不同的攝影裝置采集到的相片都需要使用其專有的IDT來進行轉換。
• Look Transform：之前也被稱為Look Modification Transform（LMT）。ACES 1.0裡的正式名稱是ACES Look Transform，簡稱Look Transform。LMT提供了一個位于正式調色步驟之前的整體圖像外觀的變換，它的輸入輸出空間是一樣的，都是scene-referred圖像空間。
• Output Transform：之前也被稱為RRT（Reference Rendering Transform） + ODT（Output Device Transform），也就是ACES Viewing Transform。ACES 1.0裡的正式名稱是ACES Output Transform，簡稱Output Transform。其中，RRT負責把圖像從scene-referred空間轉換到high dynamic range output-referred空間，而ODT負責繼續把RRT的結果轉換到特定的輸出裝置的顔色空間下。RRT + ODT是一次把scene-referred圖像完整地呈現到特定顯示裝置的轉換操作，是以它被稱為Viewing Transform/Output Transform。

在影視制作領域，IDT的特别之處在于它們是由各個攝像裝置生産商提供的。RED、Alexa、Canon、Panasonic、Sony等各大廠商都有各自的顔色空間和編碼标準，在ACES工作流下，這些廠商無需公開自己秘方而隻需按照SMPTE裡的ACES标準制作它們各自的IDT，将其圖像資料統一轉換到ACES顔色空間下即可。這移除了影視制作流程中輸入資料的不确定性，這也是ACES的魅力所在。當然，在遊戲渲染裡，我們使用的IDT通常就是把sRGB圖像從伽馬空間轉換到線性空間。

LMT是一個由使用者定義的LUT轉換階段，它的輸入輸入空間都是scene-referred線性場景空間。它的作用很容易和調色混淆，與調色這種需要針對圖像不同區域進行不同類型的顔色操作不同，LMT是一種對圖像整體的改觀變換操作，起到一個“定基調”的作用。之是以要把它單獨分成一個特定的轉換，是因為某些整體的圖像操作是比較複雜的，LMT提供了這樣一個在影視各個制作流程之間共享的LUT轉換。在遊戲渲染裡，LMT的存在感就比較低了。

RRT是由ACES委員會制定的，它的來源可以通俗地了解成一個問句，“我們想要讓一張未經調色的圖像呈現出什麼樣子？”ACES收集一大批行業專家對這個問題的答案最終得到了這個RRT變換，它的具體實作可以參考ACES在github上給出的CTL實作版本。同樣類似的還有ODT的具體定義。可以看出，ODT和RRT的定義是有一定的主觀成分在的，是這些行業專家們認為的如何在各個顯示器上讓圖像呈現最好結果的變換。在遊戲渲染領域，我們最常打交道的就是sRGB和Rec. 709的ODT，這些ODT裡包含了一個類似tonemapping的操作來讓圖像變得視覺上“更好看”，雖然帶有一定主觀性，但這個tonemapp曲線裡的參數都是由行業裡那些最挑剔的眼睛驗證過的，是不應該被輕易更改的。我們應該使用前期調色，而不是直接更改RRT + ODT來達到我們對圖像畫面的外觀要求。

在ACES 1.0中，RRT和ODT是兩個獨立的階段，這兩個階段各存在一個Tone Scale操作（具體實作可參考github上給出的RRT源碼和ODT源碼部分）：

這種Two Stage Tone Scale的模式非常具有迷惑性，實作上也不太直覺，不利于從中制定HDR Output Device Transform的相關标準。是以，ACES委員會提出了ACES ODT改進計劃，選擇使用一個統一的Single Stage Tone Scale（SSTS）算法作為替代。統一後的流程管線如下所示：

從新的Output Transform源碼實作裡可以發現，它保留了原先RRT階段的色彩計算，同時使用一條SSTS曲線來完成Tonemapping操作。在命名上，新的Output Transform使用RRTODT作為字首，來差別于之前單獨的Output Transform（ODT）階段。

以下是影視領域使用ACES的一個較為完整的流程：

來源：https://z-fx.nl/ColorspACES.pdf

影視制作流程中的CG和VFX階段裡對ACES的應用和遊戲渲染很類似：

來源：https://z-fx.nl/ColorspACES.pdf

Christophe Brejon在他的書裡是這麼總結ACES在影視制作中的地位：

Everyone should work with ACES...I never had a case where ACES would not make something look better. It is such an improvement of quality: everything looks more real and behaves more correctly.

ACES是當之無愧的色彩管理之主宰。

## DCC裡的ACES

目前，在各個軟體裡使用ACES工作流最友善的途徑就是使用OpenColorIO。OpenColorIO是一個Sony Pictures Imageworks開發的開源顔色管理系統。諸如Nuke、Fusion、Maya等軟體都已支援OpenColorIO，我們可以使用OCIO配置檔案來進行色彩管理，最新的ACES OCIO檔案可以在github上下載下傳，這些配置檔案可以幫助我們對圖像做各種ACES顔色轉換。

可惜的是，一些軟體仍然不支援OpenColorIO，例如Substance Painter（Substance Designer在2019年末已宣布支援）。但這些軟體通常允許使用自定義的LUT進行顔色轉換，我們可以針對這些軟體需要的LUT格式為其生成特定的LUT檔案即可。例如，在Substance Painter裡我們可以使用一張LUT圖像完成從sRGB linear到ACES sRGB顯示的轉換。這張LUT可由Nuke制作，或者直接代碼生成也行。

Christophe Brejon在他的書裡給出了各個軟體使用ACES的流程和參考。使用OpenColorIO和自定義LUT也基本可以滿足我們在各個DCC軟體裡的顔色校準工作。

影視制作流程裡的ACES和遊戲裡的還是有些差別，要在遊戲裡實作HDR顯示需要在ACES流程上進行一些修改，并針對遊戲做一些特定的開發工作，下一節我們會看其他遊戲和引擎是怎麼完成這件事的。

# 參考文獻

1. Digital Dragons 2018: HDR in Call of Duty

2. https://nick-shaw.github.io/cinematiccolor/common-rgb-color-spaces.html

3. https://nick-shaw.github.io/cinematiccolor/academy-color-encoding-system-aces.html

4. https://nick-shaw.github.io/cinematiccolor/visual-effects-animation-and-games.html

5. https://www.oscars.org/science-technology/aces/aces-documentation

6. https://chrisbrejon.com/cg-cinematography/chapter-1-5-academy-color-encoding-system-aces/

編輯于 2020-06-27