2.2 HDR內容存儲（Advanced High Dynamic Range Imaging ）
生成HDR內容後，就需要存儲，分發和處理這些圖像。 假設使用RGB顏色的三個波段，則使用三個單精度浮點數[173]表示未壓縮的HDR像素。 這意味着一個像素使用12個字節的內存，在1920×1080的高清（HD）分辨率下，單個圖像將佔用大約24 MB。 這比不壓縮就存儲等效LDR映像所需的大約6 MB大得多。 研究人員一直在研究有效的方法來存儲HDR內容，以滿足高內存需求。 最初，僅使用浮點數的緊湊表示形式來存儲HDR。 這些方法仍然在HDR應用程序中普遍使用，並將在本節中介紹。 最近，研究人員將精力集中在壓縮方法上，這將在第8章和第9章中介紹。
HDR值通常使用單精度浮點數存儲。 LDR成像中廣泛使用的整數對於存儲HDR值不切實際。 例如，一個32位無符號整數可以表示[0,2^23-1]範圍內的值，這不足以覆蓋HVS經歷的整個範圍。 它還不適用於兩個或多個HDR圖像之間的圖像處理操作； 例如，在加法或乘法時，精度很容易丟失，並且可能會發生溢出。 對於實際值，這種情況使浮點數優於整數。[173]
使用單精度浮點數，圖像每像素（bpp）佔據96位。 Ward [405]提出了第一個解決方案，即RGBE，它最初是爲存儲由Radiance渲染系統[407]生成的HDR值而創建的。 假設這三種顏色之間的變化不大，則此方法將存儲三種顏色之間的共享指數。 格式的編碼定義爲。
然後將紅色，Rm，綠色，Gm和藍色Bm的尾數以及指數E分別存儲在無符號字符（8位）中，最終格式爲32 bpp。 RGBE編碼涵蓋76個數量級，但編碼不支持全部色域和負值。 爲了解決這個問題，可以在編碼之前將圖像轉換爲XYZ顏色空間。 這種情況稱爲XYZE格式。 圖形硬件供應商和計算機圖形API支持RGBE格式的修改版本（即，每個顏色通道的尾數爲9位，共享指數爲5位）。 在Direct3D和OpenGL中，該格式分別稱爲DXGI FORMAT R9G9B9E5 SHAREDEXP [267]和GL RGB9 E5。 此外，這種格式可以在空間上適應有效的圖像壓縮[74]。
圖像2.3和清單2.4展示了用於對本地存儲的HDR圖像（由每個顏色通道中的浮點數組成）中的RGBE值進行編碼和解碼的MATLAB代碼。
沃德提出了另一種HDR圖像格式，一種基於感知的24/32 bpp格式，名爲LogLuv [214]。 與線性域中的顏色相比，此圖像格式將更多位分配給對數域中的亮度。 第一步，將圖像轉換爲XYZ顏色空間，並計算CIE（u'，v'）色度座標（請參閱附錄B）。 然後，32 bpp格式將15位分配給亮度，將16位分配給色度，並將其定義爲：
其中u'和v'是色度座標。 根據位的分佈，24 bpp格式的公式（2.14）和公式（2.15）的常數略有變化：10位分配給亮度，14位分配給色度。 32-bpp格式覆蓋38個數量級，而24-bpp格式僅覆蓋4.8個數量級。 與RGBE / XYZE相比，LogLuv的主要優點是該格式分別存儲亮度和顏色信息，使這些值可直接用於諸如色調映射（請參閱第3章），顏色處理等應用程序。此外，可以通過以下方式改進此格式： 利用圖像統計數據（即最大和最小）[274]。 清單2.5中顯示了基於公式（2.14）的LogLuv編碼的MATLAB代碼。 同樣，清單2.6給出了使用公式（2.15）進行解碼的MATLAB代碼。
另一種常見的HDR圖像格式是單浮點格式，這是OpenEXR文件格式的規範的一部分[180]。 在這種表示形式中，每種顏色都使用半精度浮點數編碼，這是IEEE 754標準[173]的16位實現，並且定義爲
其中S代表符號，佔1位，M是尾數，佔10位，E是指數，佔5位。 因此，最終格式爲48 bpp，覆蓋大約10.7個數量級。 儘管尺寸很大，但主要優點是該格式是在圖形硬件中實現的，允許實時應用程序使用HDR圖像。 這種格式被認爲是電影行業中的事實上的標準[112]。 娛樂業已經提出了幾種中等動態範圍格式，其目的是覆蓋2-4個數量級之間的經典電影範圍。 但是，它們不適用於HDR圖像/視頻。 皮克斯創建的日誌編碼圖像格式就是這樣的一個例子[112]。