Testing Based on Gainmaps
This is a test image based on a Gainmap. The Baseline Image is pure blue, and the Alternate Image is pure red. The Baseline Image embeds a DCI-P3 colour space ICC profile, while the Alternate Image embeds a BT.2020 colour space ICC profile. The Gainmap and Metadata were calculated in accordance with the ISO 21496-1 standard.
If your device and viewer support HDR display, you should see a pure red image; otherwise, it will display as pure blue. An example of this is the iPhone’s Low Power Mode, where the system disables HDR display. By toggling the Low Power Mode switch, you can observe the change in the image’s colour.
During the process of calculating metadata and encoding this image, I gained a clearer understanding of the “Alternate HDR Headroom” section of the ISO 21496-1 standard.
Reviewing Gainmap Calculation
For specific details, please refer to my previous posts:
A Gainmap establishes a mapping relationship between a Baseline Image (usually SDR) and an Alternate Image (usually HDR). Calculating a Gainmap requires preparing both HDR and SDR images within the same linear space.
The calculation formula for the Gainmap is as follows:
$$ G = \frac{\text{Alternate} + k_{\text{alt}}}{\text{Baseline} + k_{\text{base}}} $$Here, $\textit{k}_{\textit{alt}}$ and $\textit{k}_{\textit{base}}$ are constants added to avoid division by zero. The result is then logged (base 2) and normalised to the $[0, 1]$ range. The maximum and minimum values before normalisation, $\textit{gainmap}_{\textit{max}}$ and $\textit{gainmap}_{\textit{min}}$, are recorded. Additionally, a gamma ($\gamma$) coefficient can be applied to the normalised map for better quantisation, and $\gamma$ is recorded.
Have you noticed? The entire calculation and encoding process only requires the following parameters:
- $\textit{k}_{\textit{alt}}$ and $\textit{k}_{\textit{base}}$: To avoid division by zero
- $\textit{gainmap}_{\textit{max}}$ and $\textit{gainmap}_{\textit{min}}$: To record the range of the Gainmap before normalisation
- $\gamma$: The gamma coefficient of the Gainmap
Therefore, it is not necessary to record Headroom to correctly encode and decode ISO Gainmap images. So, what role does this Headroom actually play?
Alternate HDR Headroom
In short, it simplifies the decoding calculation by allowing the direct computation of the Gainmap weight. Let’s first look at its specific definition:
Ratio of nominal peak luminance to reference diffuse white luminance expressed as a log base 2 value.
In the example above, if the luminance of the diffuse white point in linear space is 1.0, then the Headroom equals:
$$ \text{Headroom} = \log_2(\max(\text{Alternate})) $$This confirms our previous point: Headroom is not strictly mandatory, as it can be derived from the maximum luminance of the Alternate Image.
Its function lies in determining the weight of the Gainmap during decoding. The Gainmap weight is a value between 0 and 1, used to adaptively adjust the displayed image to match the HDR capabilities of the display device.
$$ \text{Alternate} = (\text{Baseline} + k_{\text{baseline}}) \cdot 2^{W \cdot G} - k_{\text{alternate}} $$Where G is the Gainmap, and W is the weight of the Gainmap. The weight is calculated based on the display device’s HDR capability and the Headroom.
$$ W = \text{clamp}\left( \frac{H_{\text{Target}} - H_{\text{Baseline}}}{H_{\text{Alternate}} - H_{\text{Baseline}}}, 0, 1 \right) $$Here, $H_{\text{Target}}$ is the HDR capability of the display device, $H_{\text{Baseline}}$ is the Headroom of the Baseline Image (usually equal to 0), and $H_{\text{Alternate}}$ is the Headroom of the Alternate Image.
When the display device has sufficient capability to display the full Alternate Image, the weight W equals 1, and the decoding result is the complete Alternate Image. When the display device is insufficient to fully display the Alternate Image, the weight W is less than 1, and the decoding result is a blend of the Baseline and Alternate images, achieving an adaptive display effect.
Without Headroom, one would first have to assume a weight of 1, decode the complete Alternate Image, then calculate the weight W based on the display device’s HDR capability and the maximum luminance of the Alternate Image, and finally decode again using the weight W to get the final display image.
With Headroom, however, one can directly calculate the weight W based on the display device’s HDR capability and the Headroom, decoding only once to obtain the final display image. This saves the computational overhead of one decoding pass.
Therefore, if an incorrect Headroom is written, it will lead to an incorrect calculation of the weight W during decoding, thereby affecting the final display result. For instance, if a huge Headroom is declared, even if the Alternate Image does not actually require such high HDR capability, the decoding process will lower the weight W, causing the display effect to skew towards the Baseline Image. For example, if a Headroom of approximately 4.46 is written into the test image above—implying that more than 21 times the HDR capability is needed to fully display the Alternate Image—most devices will calculate a lower weight, resulting in a mixed colour, such as purple.
This incorrect example can also be demonstrated by adjusting the HDR capability of the display device. By manually specifying the device’s HDR capability and increasing it from 0, one can see the image colour gradually change from blue to red.
About Huawei’s Unique Approach
I initially tested this image with the incorrect Headroom on a Huawei Mate 80 RS, and the result was that the Huawei phone was able to display red. This image has been circulating on the internet, with some KOLs (Key Opinion Leaders) stating that only Huawei phones can display red, while other devices show it as purple.
After fixing the incorrect Headroom value, all HDR devices were able to correctly display red. It seems that Huawei’s HDR display pipeline is somewhat different and bypasses the influence of Headroom.
A Small Detail in the Standard
The standard stipulates that the Alternate Headroom must not equal the Baseline Headroom. In this example, because the red luminance in the Alternate Image is also 1.0, the Headroom equals 0, which would match the Baseline Headroom. If written this way, red would not be displayed correctly, so a tiny offset was applied to the Alternate Headroom.