Ultra 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 位无符号整数结果。

这种编码方式将 recovery(x, y) 值表示为 0.0 到 1.0 之间的 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 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”图像项目，并且它必须是目录中的第一个项目。

项目元素

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

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 中的最后一个媒体项目上时，Item:Padding 表示项目末尾和文件末尾之间的填充。

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

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

容器中媒体项目资源的位置通过求和主图像编码的长度、前面辅助媒体项目资源的 Item:Length 值以及所有前面 Item:Padding 值来确定。在未指定 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 规范的首次发布。