A Bug
In 0.1.2 and earlier versions of HDR Conversion, when automatically generating ISO 21496-1 standard metadata, the default Baseline HDR Headroom was set to 1.0 instead of 0.0. Since this did not affect how the generated images were displayed in VS Code and the Gain Map Demo app, the issue went unnoticed for a long time.
During a recent code review, while comparing with the previous draft, I spotted this problem. It has now been fixed in the develop branch and will be included in the next release.
Because of this bug, some images were generated with a Baseline HDR Headroom value of 1.0, which led to some interesting observations.
Baseline HDR Headroom
“Headroom” in HDR images refers to the expansion space: the ratio between the Nominal Peak Luminance and the Reference Diffuse White Luminance, expressed as a $\log_2$ value so 1.0 actually means two times.
The Baseline HDR Headroom refers to the peak luminance without gainmap applied. At present, the vast majority of ISO 21496-1 images have a pure SDR baseline, so the Baseline HDR Headroom is 0. This indicates that the base image requires no brightness expansion.
The standard only stipulates that the Baseline HDR Headroom and Alternate HDR Headroom cannot be equal. Therefore, setting it to 1.0 is technically compliant with the standard, it is not completely wrong. But I will keep using “incorrect” in the text below.
The two headroom values in the standard only affect weight calculation, where Target represents the headroom of the display device. The weight formula is:
This is also why an “incorrect” Baseline Headroom does not affect the display result in most cases. Additionally, when the Baseline Headroom is greater than the Alternate Headroom, it indicates that the base image itself is HDR and the gain map is used for downward tone mapping. This scenario is extremely rare for now.
Fascinating Discoveries
The images generated by the code before and after the fix differ by only a single byte at the binary level, yet they can produce different display results in certain applications or operating systems.
Although the ISO 21496-1 HDR image format has been standardised, support and implementation details vary significantly across applications and operating systems. To avoid potential legal issues from ‘reverse-engineering’ discussions, I will no longer mention specific application or operating system names in future. Readers are welcome to test and explore on their own.
In many cases, the two images display identically, which aligns with the expected behaviour when fully complying with the ISO 21496-1 standard.
Images with a Baseline HDR Headroom of 0.0 always display correctly.
However, the image with the “incorrect” Baseline HDR Headroom of 1.0 fails to trigger HDR display in some applications or operating systems and only shows the SDR baseline image.
Interestingly, in certain album applications, something interesting appear:
- When opening the image from a thumbnail view, it displays in HDR. After swiping left or right to view other photos and returning, it switches to SDR.
- When tapping the “Edit” button to enter editing mode, the image appears in HDR. Once you exit editing mode, it reverts to SDR.
The image above shows the version with Baseline HDR Headroom “correctly” set to 0.0. It displays HDR correctly across all tested environments.
The image above shows the version with Baseline HDR Headroom “incorrectly” set to 1.0. In some test environments, it only displays as SDR. It seems the Chrome browser handles it without issue — you can try saving it to your photo album to test.
These observations suggest that image viewing and editing modes use different rendering or detection logic. Some of these implementations follow the expected behaviour of the ISO 21496-1 standard, while others do not. Such proprietary implementations are part of what contributes to the current fragmented state of HDR image support. Naturally, they may also reflect specific system characteristics and particular user experience considerations.