超高清 HDR 图像格式 v1.1

简介

本文件定义了一种新的文件格式的行为，该格式将对数范围增益映射图像编码到 JPEG 图像文件中。不支持新格式的旧版阅读器会读取并显示图像文件中的传统低动态范围图像。支持该格式的阅读器会将主图像与增益映射图组合起来，并在兼容的显示器上渲染高动态范围图像。

本文档的其余部分描述了使用此格式所需流程的方法。从高层次来看，符合此格式的图像生命周期如下：

1. 编码

   1. 增益映射生成
   2. 增益映射压缩
   3. 增益映射容器生成

2. 解码

图1. 示例文件布局及相关元数据。

动机

此文件格式的目标是将附加信息编码到 SDR 图像文件中，这些信息可以与显示技术结合使用，在一个文件中生成最佳的 HDR 渲染效果。

为了使这在实践中可行，文件格式必须：

• 向后兼容，以便在简单的查看器上显示传统的 SDR 图像。
• 不会占用太多额外空间。

此外，显示技术必须：

• 不需要繁重的处理来解码。
• 能够适应显示器的 HDR 和 SDR 白点之间的任何比率，这在不同设备之间，甚至在单个设备上的时间上也可能差异很大。

最后，该技术必须能够执行所有上述操作，而无需：

• 裁剪高光。
• 压暗阴影。
• 更改或压缩局部对比度。
• 更改相对色调关系（场景中的物体之间）。

依赖关系

以下是本规范的规范性参考文献：

• Adobe XMP 规范第 3 部分：文件存储
• ISO 16684-1:2019 XMP 规范第 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，则对于任何给定的像素，显示的 HDR 渲染的线性亮度最多为 SDR 渲染的线性亮度的 4 倍。实际上，这意味着场景中较亮的部位可以显示出高达 4 倍的亮度。
  • 实际上，此值通常大于 1.0。
  • 始终大于或等于最小内容提升。

• 最小内容提升（等式中为min_content_boost）

  • 此值允许内容创建者限制在 HDR 显示器上显示的图像相对于 SDR 渲染的亮度降低程度。此值对于特定图像是一个常数。
  • 例如，如果该值为 0.5，则对于任何给定的像素，显示的 HDR 渲染的线性亮度必须至少为 SDR 渲染的线性亮度的 0.5 倍。
  • 实际上，此值通常等于或略小于 1.0。
  • 始终小于或等于最大内容提升。

• 最大显示提升（等式中为max_display_boost）

  • 特定时间点上显示器支持的最大可用提升。此值会根据设备设置和其他因素（例如环境光照条件或屏幕上亮像素的数量）而随时间变化。
  • 例如，如果此值为 4.0，则显示器能够显示亮度最多为 SDR 白点四倍的像素。此值始终 >= 1.0，因为显示器始终能够显示至少与 SDR 白点一样亮的 HDR 白点。

• 显示提升

  • 等于最大内容提升和最大显示提升中的较小者。此值始终 >= 1.0。
  • 例如，如果最大内容提升为 4.0，而最大显示提升为 3.0，则显示提升为 3.0。像素显示的亮度比 SDR 高 3 倍，因为显示器的能力是限制因素。
  • 另一个例子是，如果最大内容提升为 4.0，而最大显示提升为 5.0，则显示提升为 4.0。像素显示的亮度比 SDR 高 4 倍，因为内容的意图是限制因素。

• 目标 HDR 渲染

  • 根据内容创建者设定的理想 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 部分定义。

• 多图格式

  • 多图格式是由相机和图像产品协会 (CIPA) 开发的一种技术，用于在一个 JPEG 文件中存储多个 JPEG 编码的图像。
  • 有关更多信息，请参见相关的依赖项，CIPA DC-x 007-2009 多图格式白皮书。

• GContainer

  • GContainer 是一种在一个图像容器中存储多个图像的方法，其中一个图像被认为是主图像。任何其他图像都被认为是替代版本或辅助图像。XMP 元数据用于传达任何其他图像的存在和含义。有关更多信息，请参见GContainer 详细信息部分。

编码

本节描述如何编码符合标准的 JPEG 文件。有关 JPEG 格式的更多信息，请参阅依赖关系部分中的T.81 (09/92) 连续色调静止图像的数字压缩和编码。

增益映射生成

相机成像流水线通常执行范围压缩操作，以将更高动态范围的亮度数据压缩到传统 SDR 显示器的较低范围内。增益映射提供了一种机制，可以存储足够的数据来恢复原始的更高动态范围的亮度数据。

本节中的以下计算假设使用浮点运算。

以下函数描述了 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)

当 Ysdr(x, y) 和 offset_sdr 都为零时，函数 pixel_gain(x, y) 的行为由实现定义。

例如，实现可以通过将 pixel_gain(x, y) 定义为 1.0 来处理 Ysdr(x, y) 和 offset_sdr 都为零的情况。或者，实现也可以通过使用非零的 offset_sdr 来避免这种情况。

实现可以选择 offset_sdr 和 offset_hdr 的值。

增益映射是一个标量函数，它在对数空间中编码 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)

当 pixel_gain(x, y) 为零时，函数 recovery(x, y) 的行为由实现定义，因为 log2(0) 未定义。

map_gamma 是一个浮点数，必须大于 0.0，由实现选择。

最大内容提升和最小内容提升的值由实现定义，可以由内容创建者任意决定。最大内容提升必须大于或等于 1.0。最小内容提升必须在 (0.0, 1.0] 范围内。

recovery(x, y) 中的值限制在 [0.0, 1.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 的 recovery(x, y) 值的 8 位无符号整数表示。编码的增益映射必须作为 JPEG 存储在辅助图像项目中。实现选择在 JPEG 编码过程中使用的压缩量。

将增益映射存储在辅助图像中后，将其附加到具有 MPF 和 GContainer XMP 元数据的原始图像。原始图像 GContainer 目录必须包含增益映射图像的项目。

存储的增益映射的分辨率由实现定义，可以与原始图像的分辨率不同。如果增益映射被缩放为与原始图像不同的分辨率进行存储，则采样方法必须为双线性或更好，并且由实现定义。

增益映射的方向必须与原始图像的方向匹配。如果存在，则存储的增益映射图像中的任何方向元数据（如 EXIF 中的）都不会被使用。

如果存在，则不会使用增益映射的颜色配置文件。

增益映射容器

颜色配置文件

必须通过 ICC 配置文件为原始图像指示图像的颜色配置文件。

XMP 属性

原始图像包含 XMP 元数据，用于定义至少两个图像，其中包含 HDR 增益映射格式的额外语义信息。

以下小节包含特定于此格式的详细信息。GContainer 详细信息部分指定了关于与 GContainer 的一般一致性的其他信息。

下表中描述的属性值存储为指定 XMP 基本值类型的 XMP 简单值。

项目语义值

属性 Item:Semantic 定义容器目录中每个媒体项目的应用程序特定含义。

HDR 增益映射元数据

增益映射元数据编码有关如何解释和应用增益映射以产生原始图像的 HDR 表示的信息。

增益映射元数据 XMP 扩展的 XMP 命名空间 URI 为 http://ns.adobe.com/hdr-gain-map/1.0/。默认命名空间前缀为 hdrgm。

此元数据存储在增益映射图像的 XMP 数据包中，以下属性必须出现在增益映射图像 XMP 的 rdf:Description 中。

增益映射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多图格式（如依赖项部分所述）中定义的那样。

解码

本节介绍如何从符合规范的JPEG文件中解码增益映射。

格式的信号

符合此格式的JPEG文件可以通过主图像的XMP数据包中是否存在hdrgm:Version="1.0"来识别，其中hdrgm是命名空间URI http://ns.adobe.com/hdr-gain-map/1.0/。

找到增益映射图像

有关解析和解码图像的详细信息，请参阅以下GContainer详细信息部分。XMP rdf:Directory中的“GainMap”语义项目用于指示增益映射图像的位置。或者，使用MPF索引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)应用转换，以将数据置于显示器预期的空间中。任何此类转换都必须是色彩正确的。

GContainer详细信息

本节指定附加要求，以便此格式符合GContainer XML元数据。元数据按照ISO 16684-1: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元数据中，并定义容器中媒体项目的目录。媒体项目必须按照目录中媒体项目元素的顺序位于容器文件中，并且必须紧密排列。

目录只能包含一个“主”图像项目，并且它必须是目录中的第一个项目。

项目元素

项目元素描述应用程序如何使用每个媒体项目。

GContainer项目XMP扩展的XMP命名空间URI为http://ns.google.com/photos/1.0/container/item/。默认命名空间前缀为Item。

第一个媒体项目必须是主图像。它必须指定Item:Semantic = "Primary"和项目MIME类型值中列出的Item:Mime。

主图像项目的长度通过基于其MIME类型从文件容器的开头开始解析主图像来确定。

媒体项目可以包含一个Item:Padding属性，用于指定媒体项目结尾和下一个媒体项目开始之间的额外填充。当它出现在Container:Directory中的最后一个媒体项目上时，Item:Padding表示项目结尾和文件结尾之间的填充。

每个媒体项目都必须包含Item:Mime类型和Item:Semantic属性。次要图像媒体项目必须包含Item:Length属性。

顺序媒体项目可以在文件容器内共享资源数据。第一个媒体项目确定资源在文件容器中的位置，后续共享的媒体项目的Item:Length设置为0。如果资源数据本身是一个容器，则可以使用Item:URI来确定媒体项目数据在资源中的位置。

媒体项目资源在容器中的位置是通过将主图像编码的长度、前面次要媒体项目资源的Item:Length值以及所有前面Item:Padding值相加来确定的。Item:Padding在未指定其值的媒体项目资源上被认为是0。

项目 MIME 类型值

Item:Mime属性定义每个媒体项目数据的 MIME 类型。

示例 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 元数据。

更改日志

本节包含有关此规范不同版本之间更改的信息。

v1.1

此版本的 Ultra HDR 规范中的所有更改都是关于 ISO 21496-1 兼容性的信息性更改。文件格式本身没有任何更改。

• 添加ISO 21496-1 兼容性部分。

v1.0

最初的 Ultra HDR 规范出版物。