HDR and User Interfaces

As explained in What is HDR?, we can think of HDR as only referring to a luminance range brighter than SDR. When integrating HDR content into a user interface, you must be careful when your user interface is primarily SDR colors and assets. The human visual system adapts to perceived color based on the surrounding environment, which can lead to surprising results. We’ll look at one pertinent example.

Simultaneous Contrast

Consider the following image:

This image shows two gray rectangles with different background colors. For most people viewing this image, the two gray rectangles appear to be different shades of gray: the topmost rectangle with a darker background appears to be a lighter shade than the bottommost rectangle with a lighter background.

But these are the same shades of gray! You can prove this to yourself by using your favorite color picking tool or by looking at the below image:

This illustrates a visual phenomenon called simultaneous contrast. Readers who are interested in the biological explanation may learn more here.

Nearby differences in color are therefore “emphasized”: colors appear darker when immediately next to brighter colors. That same color would appear lighter when immediately next to darker colors.

Implications on Mixing HDR and SDR

The effect of simultaneous contrast affects the appearance of user interfaces that need to present a mixture of HDR and SDR content. The peak luminance allowed by HDR will create an effect of simultaneous contrast: the eye will adapt* to a higher peak luminance (and oftentimes a higher average luminance in practice), which will perceptually cause SDR content to appear dimmer although technically the SDR content luminance has not changed at all. For users, this can be expressed as: my phone screen became “grey” or “washed out”.

We can see this phenomenon in the below image. The device on the right simulates how photos may appear with an SDR UI, if those photos were rendered as HDR. Note that the August photos look identical when compared side-by-side, but the quality of the SDR UI is visually degraded.

Applications, when designing for HDR, need to consider how “much” SDR is shown at any given time in their screens when controlling how bright HDR is “allowed” to be. A UI that is dominated by SDR, such as a gallery view where small amounts of HDR content are displayed, can suddenly appear to be darker than expected.

When building your UI, consider the impact of HDR on text legibility or the appearance of nearby SDR assets, and use the appropriate APIs provided by your platform to constrain HDR brightness, or even disable HDR. For example, a 2x headroom for HDR brightness may be acceptable to balance the quality of your HDR scene with your SDR elements. In contrast, a UI that is dominated by HDR, such as full-screen video without other UI elements on-top, does not need to consider this as strongly, as the focus of the UI is on the HDR content itself. In those situations, a 5x headroom (or higher, depending on content metadata such as UltraHDR's max_content_boost) may be more appropriate.

It might be tempting to “brighten” SDR content instead. Resist this temptation! This will cause your application to be too bright, especially if there are other applications or system UI elements on-screen.

How to control HDR headroom

Android 15 introduced a control for desired HDR headroom. You can have your application request that the system uses a particular HDR headroom based on the context around your desired UI:

• If you only want to show SDR content, simply request no headroom.
• If you only want to show HDR content, then request a high HDR headroom up to and according to the demands of the content.
• If you want to show a mixture of HDR and SDR content, then can request an intermediate headroom value accordingly. Typical headroom amounts would be around 2x for a mixed scene and 5-8x for a fully-HDR scene.

Here is some example usage:

// Required for the window to respect the desired HDR headroom.
// Note that the equivalent api on SurfaceView does NOT require
// COLOR_MODE_HDR to constraint headroom, if there is HDR content displayed
// on the SurfaceView.
window.colorMode = ActivityInfo.COLOR_MODE_HDR
// Illustrative values: different headroom values may be used depending on
// the desired headroom of the content AND particularities of apps's UI
// design.
window.desiredHdrHeadroom =
    if(/* SDR only */) {
        0f
    } else {
        if (/* Mixed, mostly SDR */) {
            1.5f
        } else {
            if ( /* Mixed, mostly HDR */) {
                3f
            } else { 
                /* HDR only */
                5f
            }
        }
    }

Other platforms also have APIs that allow for developers to have some control over constraining HDR content in their application.

Web platforms have a more coarse concept: The First Public Working Draft of the CSS Color HDR Module adds a constrained-high option to constrain the headroom for mixed HDR and SDR scenes. Within the Apple ecosystem, constrainedHigh is similarly coarse, reckoning with the challenges of displaying mixed HDR and SDR scenes on consumer displays.

If you are a developer who is considering supporting HDR, be thoughtful about how HDR interacts with your UI and use HDR headroom controls appropriately.

*There are other mechanisms the eye employs for light adaptation, like pupillary light reflex, which amplifies this visual phenomenon (brighter peak HDR light means the pupil constricts, which causes less light to hit the retina).