Ultra HDR Image Format v0.9.1

Introduction

This document defines the behavior of a new file format that encodes a logarithmic range gain map image in a JPEG image file. Legacy readers that don't support the new format read and display the conventional low dynamic range image from the image file. Readers that support the format combine the primary image with the gain map and render a high dynamic range image on compatible displays.

The remainder of this document describes the methods of the processes needed to make use of this format. At a high level, the life cycle of an image conforming to this format is:

1. Encoding

   1. Gain map generation
   2. Gain map compression
   3. Gain map container generation

2. Decoding

Figure 1. Example file layout and relevant metadata.

Motivation

The goal of this file format is to encode additional information in SDR image files that can be used in combination with the display technique to produce their optimal HDR renditions, in a single file.

For this to be practical, the file format must:

• Be backward compatible, so that on naive viewers, the conventional SDR image is displayed.
• Not take up too much extra space.

Additionally, the display technique must:

• Not require heavy processing to decode.
• Be able to adapt to any ratio between a display's HDR and SDR white points, which can vary significantly between devices, or even temporally on a single device.

And finally, the technique must be able to do all of the preceding actions without ever:

• Clipping highlights.
• Crushing shadows.
• Changing or compressing local contrast.
• Changing relative tonal relationships (between objects in the scene).

Dependencies

The following are normative references for this specification:

• Adobe XMP Specification Part 3: Storage in Files
• ISO 16684-1:2019 XMP Specification Part 1
• ISO/IEC 14496-12 ISO base media file format
• T.81 (09/92) Digital compression and coding of continuous-tone still images
• White Paper of CIPA DC-x 007-2009 Multi-Picture Format

Definitions

• SDR display

  • A conventional display, not designed for displaying HDR content. These displays typically produce a nominal peak brightness of about 400 cd/m² or less.

• HDR display

  • A display designed for HDR content. These displays typically produce a nominal peak brightness greater than that of an SDR Display, typically 800 cd/m² or greater, and typically also have better contrast ratios than SDR displays.

• Primary image

  • The first instance of an image in a GContainer file with secondary media files appended to it. The primary image contains GContainer XMP metadata defining the order and properties of subsequent secondary media item files in the file container.

• Secondary image

  • Subsequent media item files that are appended to the primary image in a GContainer file.

• Range compression

  • In photography, real-world scenes often have more dynamic range than an SDR display can represent. Operations such as Range compression, also called local tone mapping, are needed to reduce the dynamic range of an image. This reduction needs to avoid clipping highlights or crushing shadows, while preserving local contrast as much as possible. You try to reduce the size of large luminance edges in the image, which contribute more to its global contrast, while trying to preserve the size of the small luminance edges, which are the details. Although there are many different implementations, such an operation is standard on most modern digital cameras today.

• SDR white point

  • The maximum linear luminance of SDR content on a display at a certain point in time.

• HDR white point

  • The maximum linear luminance of HDR content on a display at a certain point in time. This value is typically higher than the SDR white point.

• Boost

  • The HDR white point divided by the SDR white point.

• Max content boost (max_content_boost in equations)

  • This value lets the content creator constrain how much brighter an image can get, when shown on an HDR display, relative to the SDR rendition.
  • This value is a constant for a particular image. For example, if the value is four, then for any given pixel, the linear luminance of the displayed HDR rendition must be, at the most, 4x the linear luminance of the SDR rendition. In practice, this means that the brighter parts of the scene can be shown up to 4x brighter.
  • Always greater than or equal to 1.0.

• Min content boost (min_content_boost in equations)

  • This value lets the content creator constrain how much darker an image can get, when shown on an HDR display, relative to the SDR rendition. This value is a constant for a particular image.
  • In practice, this value is typically close to 1.0.
  • If, for example, the value is 0.5, then for any given pixel, the linear luminance of the displayed HDR rendition must be (at the least) 0.5x the linear luminance of the SDR rendition.
  • Always in the range (0.0, 1.0].

• Max display boost (max_display_boost in equations)

  • The maximum available boost supported by a display, at a given point in time. This value can change over time based on device settings and other factors, such as ambient light conditions, or how many bright pixels are on the screen.
  • For example, if this value is 4.0, then the display is capable of displaying a pixel that is at most four times brighter than the SDR white point. This value is always >= 1.0, since the display can always display HDR white at least as bright as SDR white.

• Display boost

  • Equal to the lesser of max content boost and max display boost. This value is always >= 1.0.
  • For example, if max content boost is 4.0 and max display boost is 3.0, then display boost is 3.0. Pixels are displayed as much as 3x brighter than SDR, since the display capabilities are the limiting factor.
  • For another example, if max content boost is 4.0 and max display boost is 5.0, then display boost is 4.0. Pixels are displayed as much as 4x brighter than SDR, since the content's intent is the limiting factor.

• Target HDR rendition

  • The ideal HDR rendition, according to the content creator.

• Adapted HDR rendition

  • The final HDR rendition that is shown on the display, after adapting the Target HDR rendition for the current display boost.

• Gain map (recovery(x, y) in equations)

  • A map indicating how much to brighten each pixel, in the SDR rendition, to produce the target HDR rendition. This map can be single-channel or multi-channel. A multi-channel map indicates a separate gain for each color channel, such as red, green, and blue. This document illustrates the case of a single-channel map.

• clamp(x, a, b)

  • Clamp the value x to the range [a, b].

• exp2(x)

  • Base 2 exponentiation; 2^x.

• floor(x)

  • Returns the nearest integer equal to or less than x.

• log2(x)

  • Base 2 logarithm; log₂(x)

• pow(b, x)

  • Exponentiation; b^x.

• XMP

  • Extensible Metadata Platform. A standard that defines a method for encoding metadata into an image container; defined by ISO 16684-1:2011(E) XMP Specification Part 1.

• Multi-Picture Format

  • Multi-Picture Format is a technique developed by the Camera and Imaging Products Association (CIPA) for storing multiple JPEG encoded images in a single JPEG file.
  • For more information, see the related dependency, White Paper of CIPA DC-x 007-2009 Multi-Picture Format.

• GContainer

  • GContainer is a method for storing multiple images in one image container, where one image is considered to be the primary image. Any additional images are considered alternative versions or auxiliary. XMP metadata is used to communicate the presence and meaning of any additional images.

Encode

Gain map generation

Camera imaging pipelines commonly perform a range compression operation to compress higher dynamic range luminance data to the lower range of conventional SDR displays. The gain map provides a mechanism to store data sufficient to recover the original, higher dynamic range luminance data.

The following calculations in this section assume floating point arithmetic.

The following functions describe the SDR image:

• SDR’(x, y) is the three-channel, non-linear (typically gamma-encoded) primary image.
• SDR(x, y) is the linear version of the three-channel primary image, obtained by transforming to a linear version of the primary image color space. For example, from a color space with a sRGB transfer function to a linear color space that preserves sRGB color primaries.

The Ysdr(x, y) function is defined on the range of 0.0 to 1.0 and is the standard dynamic range primary image linear luminance:

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

Similar definitions exist for the HDR image.

• HDR’(x, y) is the three-channel non-linear, that is, a PQ or HLG encoded image.
• HDR(x, y) is the three-channel linear HDR image.

Yhdr(x, y) is the luminance at a given point of the HDR image:

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

Yhdr(x, y) is defined in the range 0.0 to max content boost.

The SDR and HDR images must be the same resolution. The color profile of the SDR image defines the color space of the HDR image.

For example, if the SDR primary image has a Display-P3 color profile, then the HDR image is defined relative to the primary colors of that profile. This means the HDR image also has Display-P3 primaries.

The gain map is computed from two linear images containing the wanted HDR image luminance, Yhdr(x, y), and the standard range luminance image, Ysdr(x, y).

The pixel_gain(x, y) function is defined as the ratio between the Yhdr(x, y) function and the Ysdr(x, y) function:

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

The pixel_gain(x, y) function behavior where Ysdr(x, y) and offset_sdr are both zero is implementation-defined.

For example, implementations can handle the case where Ysdr(x, y) and offset_sdr are both zero by defining pixel_gain(x, y) as 1.0. Alternatively, implementations also avoid this scenario by utilizing a non-zero offset_sdr.

The implementation might choose the values of offset_sdr and offset_hdr.

The gain map is a scalar function that encodes pixel_gain(x, y) in a logarithmic space, relative to max content boost and min content boost:

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)

The recovery(x, y) function behavior where pixel_gain(x, y) is zero is implementation defined, because log2(0) is undefined.

map_gamma is a floating point number that must be greater than 0.0 and is chosen by the implementation.

The values of max content boost and min content boost are implementation-defined, and can be arbitrarily decided by the content creator. Max content boost must be greater than or equal to 1.0. Min content boost must be in the range (0.0, 1.0].

Values in recovery(x, y) are limited to the range [0.0, 1.0].

The gain map is stored in a secondary image JPEG, and therefore must be encoded using 8-bit, unsigned integer values, thus in the range [0, 255]. Each value represents a recovery(x, y) value and is stored in one pixel of the secondary image.

For 8-bit unsigned integer storage, the encoded value is defined as the following:

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

Calculation of the encode function is done in floating point and converted at the end to the 8-bit unsigned integer result by rounding as indicated.

This encoding results in an 8-bit unsigned integer representation of recovery(x, y) values, from 0.0 to 1.0. The encoded gain map must be stored in a secondary image item as a JPEG. The implementation chooses the amount of compression to use during JPEG encoding.

After the gain map is stored in a secondary image, it is appended to a primary image with MPF and GContainer XMP metadata. The primary image GContainer directory must contain an item for the gain map image.

The resolution of the stored gain map is implementation-defined and can be different from the resolution from the primary image. In the case that the Gain Map is scaled to a different resolution from the primary image for storage, the sampling method must be bilinear or better, and is implementation defined.

The orientation of the gain map must match that of the primary image. If present, any orientation metadata in the stored gain map image, as in EXIF, isn't used.

If present, the gain map's color profile isn't used.

Gain map container

Color profile

The color profile of the image must be indicated via an ICC Profile for the primary image.

XMP attributes

The primary image contains XMP metadata to define at least two images with extra semantic information for the HDR gain map format.

The following subsections contain details specific to this format. Additional information regarding general conformance to GContainer is specified in the GContainer details section.

Attribute values described in the following tables are stored as XMP simple values of the specified XMP basic value types.

Item semantic values

The Item:Semantic property defines the application-specific meaning of each media item in the container directory.

HDR Gain map metadata

Gain map metadata encodes information about how to interpret and apply the gain map to produce the HDR representation of the primary image.

• The namespace URI is http://ns.adobe.com/hdr-gain-map/1.0/
• The default namespace prefix is hdrgm

This metadata is stored in the gain map image's XMP packet.

The following properties must appear in the gain map image XMP's rdf:Description:

Example gain map XMP

The following example of a valid gain map XMP packet contains metadata taken from the example file illustrated in the Introduction section.

<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 storage of the gain map

The gain map image must be stored as an additional image as defined in CIPA DC-x 007-2009 Multi-Picture Format, as referenced in the Dependencies section.

Decode

For details on parsing and decoding the image, see the following GContainer details section. A "GainMap" semantic item within the XMP rdf:Directory is used to signal the location of a gain map image. Alternatively, the MPF Index IFD and scanning images' XMP is used to determine the location of a gain map.

Display

Files encoded in the HDR gain map format might be rendered on either conventional SDR displays, or on HDR displays capable of higher-luminance output.

Use the gain map to create the adapted HDR rendition 

The following calculations in this section assume floating-point arithmetic.

encoded_recovery(x, y) is the single-channel, 8-bit, unsigned integer value from the gain map image.

If the gain map is a different resolution than the primary image, then encoded_recovery(x, y) is instead determined by a filtered sampling of the gain map image for x and y over the range of the primary image width and height, respectively. The filtering method must be bilinear or better and is implementation defined.

map_gamma is determined by the hdrgm:Gamma metadata field.

log_recovery(x, y) is the normalized floating point pixel gain in a logarithmic space:

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

Max display boost is a scalar floating point value defined as the ratio between the current HDR white point and divided by the current SDR white point. This value is provided by the display system and can change over time.

hdr_capacity_max is determined by the hdrgm:HDRCapacityMax metadata field. hdr_capacity_min is determined by the hdrgm:HDRCapacityMin metadata field.

weight_factor is determined as follows when hdrgm:BaseRenditionIsHDR is "False":

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)

When hdrgm:BaseRenditionIsHDR is "True", the second equation is instead:

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

gain_map_max is determined by the hdrgm:GainMapMax metadata field. gain_map_min is determined by the hdrgm:GainMapMin metadata field. offset_sdr is determined by the hdrgm:OffsetSDR metadata field. offset_hdr is determined by the hdrgm:OffsetHDR metadata field.

The linear adapted HDR rendition can be computed as follows:

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

If needed, the implementation might apply a transform to HDR(x, y), to put the data in the space expected by the display. Any such transformations must be colorimetrically correct.

GContainer details

This section specifies additional requirements such that this format conforms with GContainer XML metadata. The metadata is serialized following ISO 166841:2011(E) XMP Specification Part 1 and embedded inside the primary image file as described in Adobe XMP Specification Part 3 Storage in Files. The primary image file contains the following items, formatted as RDF/XML.

Container element

The XMP namespace for the GContainer XMP extension is: http://ns.google.com/photos/1.0/container/

The default namespace prefix is Container.

The primary image contains a Container:Directory element in XMP metadata defining the order and properties of the subsequent media file in the file container. Each file in the container has a corresponding media item in the Container:Directory. The media item describes the location in the file container and the basic properties of each concatenated file.

The container element is encoded into the XMP metadata of the primary image and defines a directory of media items in the container. Media items must be located in the container file in the same order as the media item elements in the directory and must be tightly packed.

The directory can contain only one "Primary" image item and it must be the first item in the directory.

Item element

Item elements describe how each media item is used by the application.

The XMP namespace for the GContainer Item XMP extension is: http://ns.google.com/photos/1.0/container/item/

The default namespace prefix is Item.

The first media item must be the primary image.  It must specify Item:Semantic = “Primary” and an Item:Mime listed in Item MIME type values.

The length of the primary image item is determined by parsing the primary image based on its MIME type starting at the beginning of the file container.

The first media item can contain an Item:Padding attribute specifying additional padding between the end of the encoded primary image and the beginning of the first secondary image. Subsequent media items for secondary images don't contain Item:Padding attributes.

Each media item must contain Item:Mime type and Item:Semantic attributes. The secondary image media items must contain Item:Length attributes.

Sequential media items can share resource data within the file container. The first media item determines the location of the resource in the file container, and subsequent shared media items have Item:Length set to 0. In the case that the resource data is itself a container, Item:URI might be used to determine the location of the media item data within the resource.

The location of media item resources in the container is determined by summing the Item:Lengths of the preceding secondary image item resources to the length of the primary image encoding plus Item:Padding if specified.

Item MIME type values

The Item:Mime attribute defines the MIME type of each media item data.

Example GContainer XMP

The following example of a valid GContainer XMP packet has metadata taken from the example file illustrated in the Introduction section.

  <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/">
    <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>