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，因为显示屏始终可以显示 HDR 白色，至少与 SDR 白色一样亮。

• 展示广告增强功能

  • 等于内容放大效果上限和显示放大效果上限中的较小者。此值始终大于等于 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 中，因此必须使用 [0, 255] 范围内的 8 位无符号整数值进行编码。每个值都代表一个 recovery(x, y) 值，并存储在辅助图片的一个像素中。

对于 8 位无符号整数存储，编码值的定义如下：

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

编码函数的计算是使用浮点数完成的，并在最后通过四舍五入转换为 8 位无符号整数结果，如图所示。

这种编码会将 recovery(x, y) 值编码为 8 位无符号整数，取值范围为 0.0 到 1.0。编码的增益映射必须以 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 文件解码增益映射。

格式信号

可以通过主要图片的 XMP 数据包中是否存在 hdrgm:Version="1.0" 来识别符合此格式的 JPEG 文件，其中 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 元数据，并用于定义容器中媒体内容的目录。媒体内容必须位于容器文件中，且与目录中的媒体内容元素顺序相同，同时必须要紧凑封装。

目录只能包含一个“主”图片内容，且该内容必须是目录中的第一个内容。

内容元素

内容元素说明应用如何使用每项媒体内容。

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

第一项媒体内容必须是主图片。且必须指定 内容 MIME 类型值中列出的 Item:Semantic = "Primary" 和 Item:Mime。

主图片项的长度是通过从文件容器开头处根据主图片的 MIME 类型解析主图片来确定的。

媒体内容可以包含 Item:Padding 属性，用于指定媒体内容结尾与下一项媒体内容开头之间的额外间距。如果 Item:Padding 出现在 Container:Directory 中的最后一项媒体内容中，则表示该项内容结尾与文件结尾之间的内边距。

每项媒体内容都必须包含 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 元数据的文件布局示例。

为了实现最大程度的跨平台兼容性，使用增益映射实现 JPEG 文件编码或解码的 Android 实现和应用应同时支持 Ultra HDR v1 和 ISO 21496-1 元数据的编码和解码。在编码操作期间，实现或应用应对这两种元数据格式进行编码。如果解码操作期间存在这两种元数据，实现或应用应优先使用 ISO 21496-1 元数据。

变更日志

本部分包含有关此规范各个版本之间变化的信息。

v1.1

此版本的 Ultra HDR 规范中的所有变更均仅供参考，与 ISO 21496-1 兼容性有关。实际文件格式没有任何变化。

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

v1.0

Ultra HDR 规范的初始发布内容。