Ultra HDR 圖片格式 1.1 版

簡介

本文件定義了新檔案格式的行為，該格式會在 JPEG 圖片檔案中編碼對數範圍增益地圖圖片。舊版讀取器不支援新格式，因此會讀取圖片檔案中的傳統低動態範圍圖片，並顯示該圖片。支援此格式的讀取器會將主要圖片與增益圖結合，並在相容的螢幕上算繪高動態範圍圖片。

本文件的其餘部分會說明如何使用這類格式所需的程序方法。大致來說，符合以下格式的映像檔生命週期為：

1. 編碼

   1. 產生增益地圖
   2. 取得地圖壓縮
   3. 產生地圖容器

2. 解碼中

圖 1. 檔案版面配置和相關中繼資料的範例。

動機

這個檔案格式的目標是在 SDR 圖片檔案中編碼額外資訊，以便與顯示技術搭配使用，在單一檔案中產生最佳 HDR 轉譯。

為確保實用性，檔案格式必須符合下列條件：

• 回溯相容，以便在一般檢視器中顯示傳統的 SDR 映像檔。
• 不會占用太多額外空間。

此外，顯示技巧必須符合下列條件：

• 不需要大量處理就能解碼。
• 能夠適應螢幕 HDR 和 SDR 白點之間的任何比例，因為不同裝置之間的比例可能會大幅不同，甚至單一裝置的比例也會隨時間變化。

最後，該技術必須能夠執行所有上述動作，且不會發生以下情況：

• 剪輯精選內容。
• 消除陰影。
• 變更或壓縮局部對比度。
• 變更相對色調關係 (場景中物件之間)。

依附元件

以下是本規格的規範參考資料：

• Adobe XMP 規格第 3 部分：檔案中的儲存空間
• ISO 16684-1:2019 XMP Specification Part 1
• ISO/IEC 14496-12 ISO 基本媒體檔案格式
• T.81 (09/92) 連續調色靜態圖片的數位壓縮和編碼
• CIPA DC-x 007-2009 多圖像格式白皮書

定義

• SDR 螢幕

  • 傳統螢幕，並非用於顯示 HDR 內容。這些螢幕通常會產生約 400 cd/m² 以下的名峰亮度。

• HDR 螢幕

  • 專為 HDR 內容設計的螢幕。這類螢幕的額定峰值亮度通常會高於 SDR 螢幕，通常為 800 cd/m² 以上，且對比度通常也優於 SDR 螢幕。

• 主要圖片

  • GContainer 檔案中圖片的第一個例項，其中附加了次要媒體檔案。主要圖片包含 GContainer XMP 中繼資料，定義檔案容器中後續次要媒體項目檔案的順序和屬性。

• 次要圖片

  • 後續媒體項目檔案，會附加至 GContainer 檔案中的主圖片。

• 範圍壓縮

  • 從攝影的角度而言，現實世界的場景通常比 SDR 螢幕所呈現的動態範圍更大。為了減少圖像的動態範圍，需要執行範圍壓縮 (也稱為本機色調對應) 等作業。這項縮減作業必須避免裁剪亮部或壓縮暗部，同時盡可能保留局部對比。您嘗試縮小圖片中的大亮度邊緣大小，藉此為全域對比提高亮度，同時嘗試保留細小亮度邊緣的大小，也就是細節。雖然實作方式有很多種，但這類操作已成為現今大多數數位相機的標準功能。

• SDR 白點

  • 在特定時間點的螢幕上 SDR 內容的最大線性亮度。

• HDR 白點

  • 在特定時間點，螢幕上 HDR 內容的最大線性亮度。這個值通常會高於 SDR 白點。

• 強化

  • HDR 白點除以 SDR 白點。

• 內容最高加成 (方程式中的 max_content_boost)

  • 這個值可讓內容創作者限制圖片在 HDR 螢幕上顯示時，相對於 SDR 呈現的亮度。
  • 這個值是特定圖片的常數。例如，如果值是 4，則任何指定像素的線性亮度，則必須不超過 SDR 路由的線性亮度的 4 倍。實際上，這表示場景中較亮的部分可顯示出高達 4 倍的亮度。
  • 實際上，這個值通常會大於 1.0。
  • 一律大於或等於「內容推升下限」。

• 最小內容加強功能 (方程式中的 min_content_boost)

  • 這個值可讓內容創作者限制圖像在 HDR 螢幕上顯示時，相對於 SDR 算繪時的黑暗程度。這個值是特定圖片的常數。
  • 例如，如果值為 0.5，則任何特定像素的線性亮度，必須 (至少) SDR 路由的線性亮度為 0.5 倍。
  • 實際上，這個值通常會等於或略低於 1.0。
  • 一律小於或等於內容加強功能上限。

• 最大顯示加成 (等式中的 max_display_boost)

  • 在特定時間點，螢幕支援的可用增強功能上限。這個值可能會隨著時間變化，取決於裝置設定和其他因素，例如環境光源條件或螢幕上亮面像素的數量。
  • 舉例來說，如果這個值為 4.0，螢幕顯示的像素亮度最多可達 SDR 白點的四倍。這個值一律會 >= 1.0，因為螢幕一律會顯示 HDR 白色，至少為 SDR 白色。

• 多媒體廣告加強

  • 等於最小值 (內容加成和顯示加成)。這個值一律會大於或等於 1.0。
  • 舉例來說，如果最高內容強化為 4.0，最大螢幕增強為 3.0，則螢幕強化為 3.0。顯示器功能是限制因素，因此顯示的像素亮度最多可達 SDR 的 3 倍。
  • 舉例來說，如果內容加成效果上限為 4.0，而多媒體加成效果上限為 5.0，則多媒體加成效果為 4.0。由於內容意圖是限制因素，因此像素的顯示亮度最多可達 SDR 的 4 倍。

• 目標 HDR 顯示效果

  • 根據內容創作者的說法，這是理想的高動態範圍呈現。

• 改編的 HDR 轉譯

  • 針對目前的顯示增強功能調整目標 HDR 算繪後，在螢幕上顯示的最終 HDR 算繪。

• 增益圖 (等式中的 recovery(x, y))

  • 這張對應圖會顯示，在 SDR 轉譯中，每個像素的亮度應調整多少，才能產生目標 HDR 轉譯。這張地圖可以是單一管道或多管道。多管道對應圖會顯示每個顏色管道 (例如紅、綠、藍) 的增益值。本文件說明單一管道地圖的情況。

• clamp(x, a, b)

  • 將值 x 限制在 [a, b] 範圍。

• exp2(x)

  • 以 2 為底的指數運算；2^x。

• floor(x)

  • 傳回最接近且小於 x 的整數。

• log2(x)

  • 以 2 為底的對數；log₂(x)

• pow(b, x)

  • 指數運算；b^x。

• XMP

  • 可擴充的中繼資料平台。這個標準定義了將中繼資料編碼至圖片容器的方法；由 ISO 16684-1:2011(E) XMP 規格第 1 部分定義。

• 多圖像格式

  • 多相片格式是 Camera and Imaging Products Association (CIPA) 開發的技術，可在單一 JPEG 檔案中儲存多個 JPEG 編碼圖片。
  • 如需更多資訊，請參閱相關依附元件：CIPA DC-x 007-2009 多相片格式的白皮書。

• GContainer

  • GContainer 是一種方法，可在一個圖片容器中儲存多張圖片，其中一個圖片視為主要圖片。任何其他圖片都視為替代版本或輔助圖片。XMP 中繼資料用於說明任何額外圖片的存在和意義。詳情請參閱「GContainer 詳細資料」一節。

編碼

本節說明如何編碼符合規範的 JPEG 檔案。如要進一步瞭解 JPEG 格式，請參閱依附元件一節中的 T.81 (09/92) 連續色調靜態影像的數位壓縮和編碼。

產生增益地圖

相機成像管道通常會執行範圍壓縮作業，將動態範圍較高的亮度資料壓縮至傳統 SDR 螢幕的較低範圍。增益圖提供一種機制，可儲存足以復原原始動態範圍亮度資料的資料。

本節的以下計算假設為浮點算術。

注意： 為說明以下公式，本文件假設您使用單一頻道增益對應圖。如果情況不同，則可推斷與這些屬性相關的公式，推估出每個色彩管道的值。您可以略過從 SDR(x, y) 和 HDR(x, y) 分別轉換至 Ysdr(x, y) 和 Yhdr(x, y) 的步驟，改為將 pixel_gain(x, y) 定義為相對於 SDR(x, y) 和 HDR(x, y) 的向量函式。您也可以視需要使用每個管道的中繼資料值。盡可能使用單一頻道增益圖。

以下函式可說明 SDR 圖片：

• SDR'(x, y) 是三通道非線性 (通常為伽瑪編碼) 的初始圖像。
• SDR(x, y) 是三通道原始圖片的線性版本，可透過轉換為原始圖片色彩空間的線性版本來取得。例如，從具有 sRGB 轉移函式的色域，轉換為可保留 sRGB 原色調的線性色域。

Ysdr(x, y) 函式定義的範圍為 0.0 到 1.0，是標準動態範圍主要圖像的線性亮度：

Ysdr(x, y) = primary_color_profile_to_luminance(SDR(x, y))

HDR 圖片也有類似的定義。

• HDR'(x, y) 是三通道非線性，也就是 PQ 或 HLG 編碼的圖片。
• HDR(x, y) 是三通道線性 HDR 圖片。

Yhdr(x, y) 是 HDR 圖片特定點的亮度：

Yhdr(x, y) = primary_color_profile_to_luminance(HDR(x, y))

Yhdr(x, y) 是在內容增強上限的 0.0 範圍內定義。

SDR 和 HDR 圖像的解析度必須相同。SDR 圖片的色彩剖析檔會定義 HDR 圖像的色域。

舉例來說，如果 SDR 主要圖片具有 Display-P3 色彩設定檔，HDR 圖片會根據該設定檔的主要顏色定義。也就是說，HDR 圖片也具有 Display-P3 原色。

增益圖是由兩張線性圖像計算而得，其中包含所需 HDR 圖像亮度 Yhdr(x, y)，以及標準範圍亮度圖像 Ysdr(x, y)。

pixel_gain(x, y) 函式的定義為 Yhdr(x, y) 函式與 Ysdr(x, y) 函式之間的比率：

pixel_gain(x, y) = (Yhdr(x, y) + offset_hdr) / (Ysdr(x, y) + offset_sdr)

pixel_gain(x, y) 函式行為 (Ysdr(x, y) 和 offset_sdr 都為零) 是由實作定義。

舉例來說，實作項目可以將 pixel_gain(x, y) 定義為 1.0，處理 Ysdr(x, y) 和 offset_sdr 皆為零的情況。或者，實作項目也可以利用非零值 offset_sdr 避免這種情況。

實作可能會選擇 offset_sdr 和 offset_hdr 的值。

提示： 如果是 offset_sdr 和 offset_hdr，請使用 0.015625 (1/64) 的值。這些值的目的在於平衡提升黑色附近亮度的能力，以及精確編碼較小增益值的能力。增加這些偏移值可提高近黑色區域的復原能力，同時維持 map_max_log2 的合理值。調高的值可能會降低地圖的精確度。

增益地圖是純量函式，可根據最大內容增強和最小內容增強，在對數空間中編碼 pixel_gain(x, y)：

map_min_log2 = log2(min_content_boost)
map_max_log2 = log2(max_content_boost)

log_recovery(x, y) = (log2(pixel_gain(x, y)) - map_min_log2)
                   / (map_max_log2 - map_min_log2)
clamped_recovery(x, y) = clamp(log_recovery(x, y), 0.0, 1.0)
recovery(x, y) = pow(clamped_recovery(x, y), map_gamma)

由於 log2(0) 未定義，因此已實作 pixel_gain(x, y) 為零的 recovery(x, y) 函式行為。

提示： 如果 pixel_gain(x, y) 為零，請將 recovery(x, y) 定義為 0.0。這是因為 recovery(x, y) 值為 0.0 時，代表可儲存在增益圖中的最大可能衰減。

map_gamma 是必須大於 0.0 的浮點數，且會由實作選擇。

提示： 請使用 1.0 的 map_gamma。如果增益圖的 log_recovery(x, y) 值分布不均，您可以使用其他值。舉例來說，如果取得圖的細節遠高於 SDR 範圍 (以小 log_recovery(x, y) 值表示)，且 map_max_log2 在 HDR 轉譯設定的頂端末端 (以大 log_recovery(x, y) 值表示)，就可能適用。在這種情況下，您可以使用大於 1.0 的 map_gamma，讓 recovery(x, y) 能夠精確地對 log_recovery(x, y) 的低端和高端編碼細節。

內容增強和最低內容增加的價值由實作決定，並且可由內容創作者任意決定。內容加強功能的上限值必須大於或等於 1.0。內容加強功能的下限必須介於 [0.0, 1.0] 之間。

注意：舉例來說，假設圖片來自相機，而相機的圖像處理管道會對較高動態範圍的輸入內容執行範圍壓縮，進而產生 SDR 圖片。接著，最大內容增強和最小內容增強可能會取決於執行的範圍壓縮量，以及影響的亮度區域。

這類管道若不想對相對於 SDR 圖像的 HDR 圖像進行編碼，則可選擇最低內容增強 1.0 (1.0)。或者，如果您是根據 SDR 和 HDR 轉譯結果產生增益圖，則可根據兩種轉譯結果之間轉換所需的最大和最小增益值，判斷內容的最大增益和最小增益。

內容創作者或編輯者也可以調整內容強化上限，藉此控制 SDR 和 HDR 亮度在圖像顯示時的最大差異。

recovery(x, y) 中的值必須介於 [0.0, 1.0] 之間。

注意： 圖片最亮區域的 recovery(x, y) 值通常接近 1.0，圖片較暗區域的值則約為 0.0。

增益圖會儲存在次要圖片 JPEG 中，因此必須使用 8 位元未簽署整數值進行編碼，因此介於 [0, 255] 之間。每個值代表一個 recovery(x, y) 值，並儲存在次要圖片的一個像素中。

對於 8 位元無符號整數儲存空間，編碼值的定義如下：

encoded_recovery(x, y) = floor(recovery(x, y) * 255.0 + 0.5)

編碼函式的計算作業會以浮點運算，並在結尾以四捨五入方式轉換為 8 位元無符號整數結果。

此編碼會在 0.0 到 1.0 之間，以 8 位元無正負號整數表示 recovery(x, y) 值。編碼增益圖必須以 JPEG 格式儲存在次要圖片項目中。實作會選擇 JPEG 編碼期間要使用的壓縮量。

提示： 首先，實作定義的 JPEG 演算法品質參數為 85 至 90 (滿分 100)，或類似參數，適用於大多數的 JPEG 編碼實作。

增益圖儲存在次要映像檔中後，會附加到包含 MPF 和 GContainer XMP 中繼資料的主要映像檔上。主要映像檔 GContainer 目錄必須包含取得地圖圖片的項目。

儲存的增益圖解析度是由實作定義，可能與主要圖片的解析度不同。如果 Gain Map 縮放至與儲存主要圖片不同的解析度，取樣方法必須為雙線性或更佳，且已定義實作方式。

提示： 儲存前，請將增益圖按比例縮小至主要圖片的 ¹⁄₁₆ 大小 (每個維度的 ¼)，例如 1920x1080 主要圖片的 480x270 增益圖。增益圖需要與主要圖片具有相似的顯示比例。

取得地圖的方向必須與主要圖片的方向相符。如果存在，則不會使用儲存的增益對應圖像 (例如 EXIF) 中的任何方向中繼資料。

如果存在，系統就不會使用增益圖的色彩設定檔。

取得地圖容器

色彩設定檔

圖片的色彩設定檔必須透過主要映像檔的 ICC 設定檔指定。

提示： 使用 Display-P3 色彩設定檔。

XMP 屬性

主要圖片包含 XMP 中繼資料，可定義至少兩張圖片，並提供 HDR 增益圖格式格式的額外語意資訊。

以下各小節將說明此格式的詳細資訊。如要進一步瞭解 GContainer 的一般相容性，請參閱「GContainer 詳細資料」一節。

下表說明的屬性值會儲存為指定 XMP 基本值類型的 XMP 簡單值。

項目語意值

Item:Semantic 屬性會定義容器目錄中每個媒體項目的應用程式專屬意義。

值	說明
Primary	表示媒體項目是容器中已準備好顯示的主要圖片。目錄必須包含一個「Primary」項目。
GainMap	表示媒體項目是增益圖。目錄最多可包含一個「GainMap」項目。

HDR Gain 地圖中繼資料

增益圖中繼資料會編碼資訊，說明如何解讀及套用增益圖，以產生主要圖片的 HDR 表示法。

取得地圖中繼資料 XMP 擴充功能的 XMP 命名空間 URI 為 http://ns.adobe.com/hdr-gain-map/1.0/。預設命名空間前置字串為 hdrgm。

這項中繼資料會儲存在增益圖像的 XMP 封包中，且增益圖像 XMP 的 rdf:Description 中必須顯示下列屬性：

名稱	類型	說明
hdrgm:Version	文字	使用的增益圖格式版本。這個版本為「1.0」。 必要。
hdrgm:BaseRenditionIsHDR	布林值	表示主要圖片的動態範圍。「False」表示主要圖片為 SDR，且增益圖可與該圖片結合，產生 HDR 呈現。「True」表示主要圖片為 HDR，且增益圖可能會與該圖片結合，產生 SDR 呈現。必須為「False」。 選用；預設值為「False」。
hdrgm:GainMapMin	實數或實數有序陣列	儲存 map_min_log2 的值。這是 log2 的內容調高值下限，也就是在指定 HDR 轉譯的情況下，目標 HDR 轉譯的線性亮度與 SDR 圖片的線性亮度比率 (除以) 的最低允許值。可以是單一實數，也可以是排序的實數陣列。當 Reals 是排序陣列時，可能會包含一個適用於所有通道的項目，或是分別適用於紅、綠、藍通道的三個項目。必須小於或等於 hdrgm:GainMapMax。選用，預設值為 0.0。
hdrgm:GainMapMax	實數或已排序的實境陣列	儲存 map_max_log2 的值。這是內容增強的最大比率 log2，是指定像素中 SDR 圖像的目標 HDR 圖像的線性亮度上限 (除以 SDR 圖像後)，允許的線性亮度上限。可以是單一實數，也可以是排序的實數陣列。當 Reals 是排序陣列時，可能會包含一個適用於所有通道的項目，或是分別適用於紅、綠、藍通道的三個項目。必須大於或等於 hdrgm:GainMapMin。必填。
hdrgm:Gamma	實數或已排序的實境陣列	儲存 map_gamma 的值。這是要套用至儲存地圖值的 Gmama 值。可以是單一實數，也可以是排序的實數陣列。當已排序的 Reals 陣列包含一個項目，這些項目分別套用至所有管道，或三個代表紅色、綠色和藍色管道的項目。必須大於 0.0。選用；預設值為 1.0。
hdrgm:OffsetSDR	實數或實數有序陣列	儲存 offset_sdr 的值。這是在產生和套用增益圖時，套用至 SDR 像素值的偏移量。可以是單一 Real，也可以是 Real 的排序陣列。當 Reals 是排序陣列時，可能會包含一個項目，適用於所有通道，或三個項目，分別適用於紅、綠和藍通道。不得小於 0.0。選用；預設值為 0.015625 (1/64)。
hdrgm:OffsetHDR	實數或已排序的實境陣列	儲存 offset_hdr 的值。這是在產生和套用增益圖時，套用至 HDR 像素值的偏移量。可以是單一 Reals 陣列，也可以是經過排序的 Reals 陣列。當已排序的 Reals 陣列包含一個項目，可分別套用至所有管道，或分別代表紅色、綠色和藍色管道的三個項目。必須等於或大於 0.0。選用；預設值為 0.015625 (1/64)。
hdrgm:HDRCapacityMin	真的	儲存 hdr_capacity_min 的值。這是地圖一律套用的最小顯示加成值的 log2。這個值也會影響系統根據顯示增強功能套用增益圖的程度。必須等於或大於 0.0。選用；預設值為 0.0。
hdrgm:HDRCapacityMax	真的	儲存 hdr_capacity_max 的值。這是地圖完全套用時，最大顯示加強值的 log2。這個值也會影響根據顯示強化效果套用增益貼圖的程度。必須大於 hdrgm:HDRCapacityMin。必填。

提示：盡可能只在允許單一值或值陣列的屬性中，為每個屬性使用單一 Real 值，每個色彩通道一個。將 HDRCapacityMax 等於 GainMapMax，並將 HDRCapacityMin 設為較大的 GainMapMin 或 0.0。本文件的其餘部分假設您會為所有可能含有 Real 值陣列的屬性使用單一 Real 值。如果實際並非如此，則可推斷這些屬性的公式。

增益地圖 XMP 範例

以下有效增益對應 XMP 封包的範例包含從範例檔案取得的中繼資料 (如簡介一節所示)。

<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="XMP Core 5.5.0">
  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
    <rdf:Description rdf:about=""
     xmlns:hdrgm="http://ns.adobe.com/hdr-gain-map/1.0/"
     hdrgm:Version="1.0"
     hdrgm:GainMapMin="-0.57609993"
     hdrgm:GainMapMax="4.7090998"
     hdrgm:Gamma="1"
     hdrgm:OffsetSDR="0.015625"
     hdrgm:OffsetHDR="0.015625"
     hdrgm:HDRCapacityMin="0"
     hdrgm:HDRCapacityMax="4.7090998"
     hdrgm:BaseRenditionIsHDR="False"/>
  </rdf:RDF>
</x:xmpmeta>

增益圖的 MPF 儲存空間

增益圖像必須儲存為額外圖像，如 CIPA DC-x 007-2009 多圖片格式中所定義，如依附元件一節所述。

Decode

本節說明如何從符合標準的 JPEG 檔案解碼取得地圖。

格式的訊號

符合此格式的 JPEG 檔案可透過主要圖片的 XMP 封包中是否有 hdrgm:Version="1.0" 來辨識，其中 hdrgm 是命名空間 URI http://ns.adobe.com/hdr-gain-map/1.0/。

找出增益圖片

如要進一步瞭解如何剖析及解碼圖片，請參閱下方的「GContainer 詳細資料」一節。XMP rdf:Directory 中的「GainMap」語意項目會用來指出增益圖片的位置。或者，您也可以使用 MPF Index IFD 和掃描圖片的 XMP，判斷增益圖的位置。

處理無效的中繼資料

如果缺少必要欄位，或是任何欄位含有無效值，中繼資料就會視為無效。值可能無效，因為無法解析為指定類型，或是超出預期範圍。

如果遇到無效中繼資料，應忽略取得對應，並應顯示 SDR 圖片。

螢幕

以 HDR 增益圖格式編碼的檔案，可在傳統 SDR 螢幕或可輸出更高亮度的 HDR 螢幕上算繪。

使用增益圖建立經過調整的 HDR 渲染圖

本節的以下計算假設為浮點算術。

encoded_recovery(x, y) 是增益圖像圖片中的單一通道、8 位元、無符號整數值。

如果增益圖的解析度與主要圖片不同，則 encoded_recovery(x, y) 會根據 x 和 y 的增益圖圖片，分別在主要圖片的寬度和高度範圍內進行篩選取樣。篩選方法必須是雙線性或更高，且由實作定義。

map_gamma 取決於 hdrgm:Gamma 中繼資料欄位。

log_recovery(x, y) 是對數空間中經過正規化的浮點像素增益：

recovery(x, y) = encoded_recovery(x, y) / 255.0
log_recovery(x, y) = pow(recovery(x, y), 1.0 / map_gamma)

顯示器最大增益值是純量浮點值，定義為目前 HDR 白點與目前 SDR 白點的比率。這個值由顯示系統提供，可能會隨時間變動。

hdr_capacity_max 是由 hdrgm:HDRCapacityMax 中繼資料欄位決定。hdr_capacity_min 取決於 hdrgm:HDRCapacityMin 中繼資料欄位。

當 hdrgm:BaseRenditionIsHDR 為「False」時，weight_factor 會依下列方式決定：

unclamped_weight_factor = (log2(max_display_boost) - hdr_capacity_min)
                        / (hdr_capacity_max - hdr_capacity_min)
weight_factor = clamp(unclamped_weight_factor, 0.0, 1.0)

如果 hdrgm:BaseRenditionIsHDR 為「True」，則第二個方程式會改為：

weight_factor = 1.0 - clamp(unclamped_weight_factor, 0.0, 1.0)

gain_map_max 是由 hdrgm:GainMapMax 中繼資料欄位決定。gain_map_min 是由 hdrgm:GainMapMin 中繼資料欄位決定。offset_sdr 是由 hdrgm:OffsetSDR 中繼資料欄位決定。offset_hdr 是由 hdrgm:OffsetHDR 中繼資料欄位決定。

線性調整的 HDR 轉譯作業可按以下方式計算：

log_boost(x, y) = gain_map_min * (1.0f - log_recovery(x, y))
                + gain_map_max * log_recovery(x, y)
HDR(x, y) = (SDR(x, y) + offset_sdr) * exp2(log_boost(x, y) * weight_factor)
          - offset_hdr

如有需要，實作作業可能會將轉換套用至 HDR(x, y)，將資料放入螢幕預期的空間。任何這類轉換都必須符合色彩測量準則。

注意：必須按照前述方式 (使用指數運算) 套用增益圖，才能在任何所需的顯示增強功能下，正確產生所需的相對色調關係 (圖片中不同亮度區域之間)。如果以其他方式 (例如透過簡單的線性內插) 套用增益圖，圖片中的相對色調關係只會在內容增強至最大值時正確，在其他增強因子下則會受到影響。

如上所述，復原已調整的 HDR 呈現方式的方法，是指在最大顯示增強功能變更時，顯示結果會順暢轉換。這個方法一律會產生與內容創作者意圖最相符的顯示結果，並符合「動機」一節列出的所有圖片品質規定。

在最小內容加成值小於 1.0 的情況下，系統會根據最大顯示加成值和最大內容加成值之間的關係，調整所採用的衰減量。舉例來說，如果內容增強上限是 4.0，內容增強下限為 0.5，最大螢幕增強程度為 2.0，則顯示圖片的最高亮度為 0.7071，如果最大顯示強化為 4.0 或更高，則為 0.5。

GContainer 詳細資料

本節將說明其他規定，讓這個格式符合 GContainer XML 中繼資料。中繼資料會依據 ISO 166841:2011(E) XMP 規格第 1 部分進行序列化，並按照 Adobe XMP 規格第 3 部分「檔案儲存空間」所述，嵌入主要圖像檔案中。主要圖片檔案包含以下項目，格式為 RDF/XML。

XMP 封包需求

XMP 封包應透過命名空間 URI http://ns.adobe.com/hdr-gain-map/1.0/，納入增益圖中繼資料 XMP 擴充功能。預設的命名空間前置字串為 hdrgm。

XMP 封包應定義 hdrgm:Version="1.0"。

容器元素

GContainer XMP 擴充功能的 XMP 命名空間為 http://ns.google.com/photos/1.0/container/。預設命名空間前置字串為 Container。

主要圖片在 XMP 中繼資料中包含 Container:Directory 元素，定義檔案容器中後續媒體檔案的順序和屬性。容器中的每個檔案在 Container:Directory 中都有對應的媒體項目。媒體項目會說明檔案容器中的位置，以及每個連接檔案的基本屬性。

容器元素會編碼至主要圖片的 XMP 中繼資料，並定義容器中的媒體項目目錄。媒體項目必須位於容器檔案中，且必須與目錄中的媒體項目元素順序相同，且必須緊密封裝。

目錄只能包含一個「Primary」圖片項目，且必須是目錄中的第一個項目。

元素名稱	類型	說明
容器：目錄	結構體的排序陣列	排序的結構體陣列，每個陣列都包含一個 Container:Item 結構體，用於定義容器的版面配置和內容。

項目元素

項目元素會說明應用程式如何使用每個媒體項目。

GContainer Item XMP 擴充功能的 XMP 命名空間 URI 為 http://ns.google.com/photos/1.0/container/item/。預設命名空間前置字串為 Item。

第一個媒體項目必須是主要圖片。它必須指定 Item:Semantic = "Primary" 和項目 MIME 類型值中列出的 Item:Mime。

主要圖片項目的長度是由剖析主要圖片決定，剖析方式是根據主要圖片的 MIME 類型，從檔案容器的開頭開始。

媒體項目可包含 Item:Padding 屬性，指定媒體項目結尾和下一個媒體項目開頭之間的額外邊框間距。當 Container:Directory 出現在 Container:Directory 中的最後一個媒體項目時，Item:Padding 會指出項目結尾和檔案結尾之間的邊框間距。

每個媒體項目都必須包含 Item:Mime 類型和 Item:Semantic 屬性。次要圖片媒體項目必須包含 Item:Length 屬性。

連續媒體項目可在檔案容器中共用資源資料。第一個媒體項目會決定資源在檔案容器中的位置，後續的共用媒體項目則會將 Item:Length 設為 0。如果資源資料本身就是容器，您可以使用 Item:URI 判斷媒體項目資料在資源中的所在位置。

媒體項目資源在容器中的位置取決於主要圖片編碼的長度、前一個次要媒體項目資源的 Item:Length 值，以及所有前一個 Item:Padding 值的總和。如果媒體項目資源未指定 Item:Padding 的值，系統會將其視為 0。

屬性名稱	類型	說明
項目：Mime	文字	簡單的字串，表示容器中媒體項目的 MIME 類型。如需定義，請參閱「項目 MIME 類型值」一節。必填。
項目：Semantic	文字	簡單的字串，指出媒體項目的應用程式專屬意義。如需定義，請參閱「項目語意值」一節。必填。
項目：長度	整數	包含項目正整數長度的簡單字串。長度 0 表示媒體項目資源與先前的媒體項目共用。次要媒體項目的必要屬性。主要圖片媒體項目的選用屬性。
項目：標籤	文字	實作定義的字串，用於區分具有相同 Item:Semantic 的多個項目元素。選用。
項目：邊框間距	整數	字串包含以位元組為單位的正整數長度，用於在媒體項目結尾和下一個媒體項目開頭之間，或檔案結尾處的額外邊框間距。如果用於 Container:Directory 中的最後一個媒體項目，則會用於檔案結尾處。如未提供，則假設值為 0。選用。
項目：URI	文字	符合 ISO/IEC 14496-12 8.11.9 節規定的 URI 字串，其中包含媒體項目資源中媒體資料的相對 URI。預設為主要圖片資源。適用於 ISO 基本媒體檔案格式 ISO/IEC 14496-12 MIME 類型。 不得使用。

項目 MIME 類型值

Item:Mime 屬性會定義每個媒體項目資料的 MIME 類型。

值	說明
圖片/jpeg	JPEG 圖片。

GContainer XMP 範例

以下範例為有效的 GContainer XMP 封包，其中的中繼資料取自「簡介」一節中的範例檔案。

<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 5.1.2">
  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
    <rdf:Description
     xmlns:Container="http://ns.google.com/photos/1.0/container/"
     xmlns:Item="http://ns.google.com/photos/1.0/container/item/"
     xmlns:hdrgm="http://ns.adobe.com/hdr-gain-map/1.0/"
     hdrgm:Version="1.0">
      <Container:Directory>
        <rdf:Seq>
          <rdf:li rdf:parseType="Resource">
            <Container:Item
             Item:Semantic="Primary"
             Item:Mime="image/jpeg"/>
          </rdf:li>
          <rdf:li rdf:parseType="Resource">
            <Container:Item
             Item:Semantic="GainMap"
             Item:Mime="image/jpeg"
             Item:Length="66171"/>
          </rdf:li>
        </rdf:Seq>
      </Container:Directory>
    </rdf:Description>
  </rdf:RDF>
</x:xmpmeta>

ISO 21496-1 相容性

ISO 21496-1 提供另一種封裝機制，用於在圖片檔中編碼取得地圖中繼資料。您可以使用檔案中的單一增益圖像，在一個 JPEG 檔案中編碼 Ultra HDR 中繼資料和 ISO 21496-1 中繼資料。

圖 2. 使用 Ultra HDR 和 ISO 21496-1 中繼資料的檔案版面配置範例。

為達到最大跨平台相容性，Android 實作及應用程式如為取得地圖的自行實作編碼或解碼 JPEG 檔案，應支援 Ultra HDR v1 和 ISO 21496-1 中繼資料的編碼和解碼功能。在編碼作業期間，實作或應用程式應編碼兩種中繼資料格式。如果解碼作業期間同時出現兩種中繼資料，實作或應用程式應優先使用 ISO 21496-1 中繼資料。

注意：從 Android 15 (API 級別 35) 開始，Android 支援從 JPEG 轉碼至 Bitmap，並從 Bitmap 解碼至 JPEG。Android 15 從 Bitmap 物件編碼 Ultra HDR JPEG 檔案時，會同時編碼 Ultra HDR v1 中繼資料和 ISO 21496-1 中繼資料。此外，在啟用適當的標記時，AOSP 中的 libultrahdr 程式庫可支援 ISO 21496-1 編碼。

變更紀錄

本節提供本規格不同版本之間的變更資訊。

v1.1

這個版本的 Ultra HDR 規格中的所有變更都是提供資訊，且與 ISO 21496-1 的相容性有關。實際的檔案格式維持不變。

• 新增 ISO 21496-1 相容性部分。

1.0 版

初始 Ultra HDR 規格出版品。