Standardised Gainmap
The previously mentioned Google UltraHDR, OPPO’s early proprietary format, and Apple’s former proprietary format may have different names, but they’re essentially the same approach: HDR images based on Gainmap.
To standardise such Gainmap-based images, Adobe, Apple and others jointly developed the ISO 21496-1 standard, formally published in July 2025. Its official title is: Gain map metadata for image conversion. It mainly defines the gain map and related metadata, and how to use it.
Compared to the previous Wild West of proprietary formats, this standard uses gain maps in much the same way; it mainly differs in how data is organised in the file. Today, almost all Gainmap HDR images use this standard. For example, UltraHDR added support in version 1.1; the same image file can carry both the UltraHDR XMP metadata and ISO 21496-1-compliant metadata.

In terms of display, as long as it’s detected and decoded correctly, it looks no different from the older proprietary formats — it’s just a different way of storing the metadata.
Identifying ISO 21496-1 metadata
For JPEG files, ISO 21496-1 content is stored in the JPEG APP2 marker segment. Both the main image and the gain map have this APP2 segment; the main image stores version info, and the gain map also stores the actual data.
Reference: https://www.iso.org/standard/86775.html
According to the table “C.4.6 Gain map metadata”, the APP2 segment is laid out as follows:
- APP2 marker (0xFFE2): 2 bytes
- Marker segment length: 2 bytes
- Unique identifier (URN): 28 bytes. The value must be
urn:iso:std:iso:ts:21496:-1, terminated by a null character. - Metadata: remainder (segment length minus 30 bytes)

Main image information
In the APP2 marker segment of the main image (called the Baseline Image in the ISO), the metadata takes four bytes, holding two unsigned 16-bit integers: minimum version and writer version. In the initial edition of ISO 21496-1, the minimum version should be 0, and the writer version must be greater than or equal to the minimum version.
Gain map data
In the gain map, besides the version info, you’ll find the core metadata needed to create and parse the gain map. In UltraHDR, this lives in an XMP packet in the APP1 segment, recorded as text tags, such as the gain map’s maximum and minimum values.
In the ISO standard, the storage differs: instead of XMP’s “name + value” pairs, the data is stored in a fixed field order and type, with the binary data packed directly. Most numeric values are stored as rational numbers using a pair of 32-bit integers: numerator and denominator. This keeps numerical precision and calculation accuracy, but it isn’t human-readable like XMP and needs dedicated parsing.
More concretely, the metadata that follows the URN identifier has the following content and order:
- Version information: just like the main image, the first 4 bytes are two unsigned 16-bit integers, the minimum version and the writer version.
- Control flags: 8 bits.
- The highest bit decides whether the gain map is multi-channel or single-channel.
- The next highest bit decides whether to use the baseline image’s colour space when rendering.
- The remaining 6 bits are reserved and currently unused.
- HDR headroom: this defines the relationship between the brightness SDR and HDR can show, i.e. the usual “headroom”. The standard defines two values:
- Baseline HDR headroom, usually 1.
- Alternate HDR headroom. Each value is made up of one 32-bit numerator and one 32-bit denominator.
- Per-channel metadata: based on the “control flags” above, this holds 1 set of data (single-channel) or 3 sets (multi-channel). Each set defines how to turn gain map pixel values into actual gain factors, using five key parameters, each stored as numerator and denominator:
gain_map_min/gain_map_max: the original data range of the gain map.gamma: the exponent applied to the normalised gain map value betweengain_map_minandgain_map_max.base_offset/alternate_offset: the offsets for linear SDR and HDR.
I wrote a simple Python script that parses the APP2 segment’s binary data into JSON strictly following this structure, for easier reading.
JacksBlog Example: ISO 21496-1 parsing script
Usage across standards
Images that contain only ISO 21496-1 metadata are fairly rare; most are extensions of earlier schemes, so they carry multiple kinds of metadata.
Images with only ISO 21496-1 metadata include:
- UltraHDR output from Phocus 4.0 (HNCS HDR): although it’s called UltraHDR, it doesn’t include the UltraHDR metadata, only ISO 21496-1.
- Adobe Sample Gallery: as a promoter of the standard, Adobe provides sample images that carry only the standard metadata.
Images with both UltraHDR and ISO 21496-1:
- Hasselblad X2D II out-of-camera JPEG.
Images with both Adobe Gainmap and ISO 21496-1:
- HDR JPEGs exported by Adobe Camera Raw: have XMP‑labelled metadata and ISO data, but no GContainer.
- Sigma BF out-of-camera JPEG.
- JPEGs shot via Project Indigo.
Images with only UltraHDR / Adobe Gainmap:
- OPPO Find X6 Pro / X8 Ultra JPEG.
Additionally, formats such as HEIF can also comply with ISO 21496-1, but how to detect that isn’t very clear — at least it’s not via the URN. For example, HEIF photos shot on iPhone can be recognised as ISO 21496-1 in the Gain Map Demo app.
What has long been divided will surely unite
The idea of storing HDR images with a Gainmap appeared long ago. For example, the 2007 paper below proposed a two-layer approach: one SDR layer plus a residual layer to encode HDR.
Okuda, M.; Adami, N. Two-Layer Coding Algorithm for High Dynamic Range Images Based on Luminance Compensation. Journal of Visual Communication and Image Representation 2007, 18 (5), 377–386. https://doi.org/10.1016/j.jvcir.2007.06.004.
Only in the past few years has the HDR trend reached the tiny phone screen. Early movers put forward their own ways to encode dual-layer images. It wasn’t until this year that the format finally achieved international standardisation, ending the era of a hundred competing approaches. Despite plenty of misunderstandings about HDR images and Gainmap, I believe adoption will only grow as standardisation progresses.