Mixed SDR and HDR composition

This page describes the requirements, configuration, and validation of the SDR content dimming feature for mixed SDR and HDR composition.

Android 13 improves support for simultaneously presenting SDR and HDR composition on screen by introducing the following features:

  • Tone mapping HDR luminance to an SDR-compatible range.

    Using libtonemap, tone mapping can be made consistent between Hardware Composer (HWC), SurfaceFlinger, and apps. OEMs can implement their own tone mapping curves to be shared between vendor and framework components.

  • Dimming on-screen SDR content when presented simultaneously with HDR content.

    When HDR content is on screen, the screen brightness is increased to accommodate the increased luminance range of the HDR content. Any SDR content that is also on screen is seamlessly dimmed as the screen brightness increases so that the perceptual brightness of the SDR content doesn't change. OEMs can configure their built-in displays to dim on-screen SDR content when presented alongside HDR content.

OEM requirements

To use the improved composition for HDR and SDR content through SDR content dimming, follow these requirements:

  • Implement the AIDL version of the HWC, which includes support for hardware-accelerated dimming in the device’s color pipeline. Refer to AIDL for HWC for implementing the required capabilities.

  • Accurately dimming hardware overlays in the HWC requires specific hardware to scale the linear light of the overlays. Implementations without sufficient hardware are required to defer composition to the GPU by SurfaceFlinger, causing battery drain and possible low-quality dimming.

  • The device must support at least one HDR technology reported by Display.getHdrCapabilities.

Configuration

The mixed SDR and HDR content composition feature can be configured according to the built-in display device characteristics, so that the tradeoff between battery life, burn-in, and content fidelity is established.

Enabling and tuning the improved composition is done through a display configuration whose schema is located in display-device-config.xsd. The following new key elements are important in setting the display configuration:

  • The sdrHdrRatioMap element enables SDR dimming and defines a look-up table (LUT) for mapping the screen brightness for HDR to be displayed to the SDR white point when there's HDR content on screen.

    If sdrHdrRatioMap is defined, then as part of controlling the screen brightness, DisplayManagerService communicates the desired SDR white point to SurfaceFlinger so that SurfaceFlinger can send the appropriate dimming ratio per layer to the HWC.

    If sdrHdrRatioMap isn't defined, the SDR dimming isn’t enabled, even if the HWC implementation supports SDR dimming.

  • The minimumHdrPercentOfScreen element, with a value ranging from 0 to 100, controls when a panel’s high brightness mode is allowed to be turned on. With Android 13, this threshold is tunable to enable high brightness mode in more situations, such as picture-in-picture scenarios. Previous versions of AOSP have fixed this value to 50%.

See the following code block for the key elements of the display configuration:

<displayConfiguration>
    ...
    <highBrightnessMode>
        ...
        <!--Percentage of the screen that must be covered by HDR layers until high brightness mode is enabled.
        <minimumHdrPercentOfScreen>...</minimumHdrPercentOfScreen>
        <!--sdrHdrRatioMap, backed by spline, must have at least two entries -->
        <sdrHdrRatioMap>
            <point>
                <sdrNits>...</sdrNits>
                <hdrRatio>...</hdrRatio>
            </point>
            <point>
                <sdrNits>...</sdrNits>
                <hdrRatio>...</hdrRatio>
            </point>
            <!--More interpolation points may be added –->
            ...
        </sdrHdrRatioMap>
        ...
    </highBrightnessMode>
    ...
</displayConfiguration>

Caveats

Enabling the tone mapping and SDR content dimming features can lead to the following situations:

  • The fidelity of HDR content played on the device can increase, as the SDR content elements are dimmed.

  • The battery life can decrease in the following scenarios:

    • The HWC implementations that defer dimming operations to the GPU can cause increased GPU use.

    • Display configurations that allow for a lower threshold for enabling high brightness mode can increase power draw for running the screen at a higher brightness.

  • Screen health can be impacted due to the increased time spent in the high brightness mode, which can cause long-term problems such as burn-in with display health.

Validation

OEMs can use VTS tests, which are included as part of the HWC’s test suite, to check for dimming correctness and to validate the input dimming ratio.

Validation for this feature is device dependent, so there are no CTS or GTS tests to support this.

OEMS must run manual tests to validate that the image quality of dimmed SDR elements is acceptable. OEMs can play content for HDR standards that the device supports over SurfaceView to validate that any SDR elements played alongside the HDR content don’t become overly bright.

Issues

Dimming SDR images can result in black crush, or information loss in darker areas of the original image. This is due to darker color values collapsing onto a smaller set of dark codes.

An implementation for dimming that causes unacceptable black crush must implement dithering algorithms, which inject noise into the final image so that banding effects are reduced.

HWC implementations that are unable to dither the image in the appropriate location in the color pipeline must request that the SurfaceFlinger applies dimming and dithering on the GPU.

Implementations can also adjust the value of sdrHdrRatioMap to limit the amount of dimming for SDR elements. Dimming to very low brightness levels requires the use of the GPU, which improves image quality but can decrease battery life.