Mixed SDR and HDR Composition in Android 13

Content Dimming is the new standard of content presentation which is introduced in Android 13, you can use this to have a better user experience and a new user design overhaul. In this article, we will learn how to mix the SDR and HDR support in your Android 13 app, and then present it in front of the user so that it uses the full range of available system hardware to better show the contents, and standardize the content.

GeekTip #1: The launch of this functionality has no effect on devices updating to Android 13

The following capabilities are added to Android 13 to enhance support for simultaneously displaying SDR and HDR composition on screen:

1. Convert HDR brightness to a range that is compatible with SDR.
2. Tone mapping may be made consistent between Hardware Composer (HWC), SurfaceFlinger, and applications using libtonemap.
3. OEMs are able to put into practice their own tone mapping curves for use by vendor and framework components.

Current Issues with SDR & HDR Content Dimming

Android 13, still has a few things that don’t work as they should, and they will be addressed shortly in the future, with the other iterations, although they are small, still knowing them beforehand can help you avoid them.

1. HWC implementations must request that the SurfaceFlinger apply dimming and dithering on the GPU if they are unable to dither the image at the proper point in the color pipeline.
2. Dithering methods must be used in a dimming implementation that results in unsatisfactory black crushes because they introduce noise into the final image and lessen the impacts of banding.
3. Black crush or information loss in the original image’s darker parts can happen when SDR images are dimmed. Darker color values combined with a narrower set of dark codes are the cause of this.

How OEM Change things

If you are fond of custom OEMs or work developing apps for custom OEMs, then these are the requirements that you will need to satisfy in order to work towards enabling the content dimming functionality in your app:

1. Hardware that scales the linear light of the overlays is needed in order to accurately dim hardware overlays in the HWC. SurfaceFlinger forces implementations with insufficient hardware to defer composition to the GPU, resulting in battery waste and potential low-quality dimming.
2. Implement hardware-accelerated dimming in the color pipeline of the device using the AIDL version of the HWC. For information on how to build the necessary functionality, see AIDL for HWC.
3. At least one HDR technique must be supported by the device.

GeekTip #2: Although these requirements are not necessary, ensuring them would result in a great experience. 

How to develop content that supports dimming

To create content that supports content dimming you need to check a few things, also you need to have strict checks if you want the user to get a better experience.

• The built-in display device characteristics can be used to customize the mixed SDR and HDR content composition capability, allowing for the establishment of a trade-off between content fidelity, burn-in, and battery life.
• When HDR content is displayed on the screen, the sdrHdrRatioMap element allows SDR dimming and defines a look-up table (LUT) for mapping the screen brightness for HDR to be displayed to the SDR white point.
• The display configuration, whose schema is included in display-device-config.xsd, is used to enable and tune the better composition. 
  When configuring the display, the new main components listed below are crucial:
  • In order for SurfaceFlinger to deliver the proper dimming ratio per layer to the HWC, SurfaceFlinger must get the desired SDR white point from DisplayManagerService if sdrHdrRatioMap is specified.
  • Even if the HWC implementation allows SDR dimming, the SDR is not enabled if sdrHdrRatioMap is not defined.
• When a panel’s high brightness mode can be activated, it is determined by the minimumHdrPercentOfScreen element, which has a value that ranges from 0 to 100. With Android 13, you can adjust this threshold to make high brightness mode available in more circumstances, like picture-in-picture scenarios. This value was set to 50% in earlier iterations of AOSP.

Checks to ensure Content Dimming is working properly

VTS tests, which are a part of the HWC’s test suite, can be used by OEMs to validate the input dimming ratio and verify that dimming is done correctly. To confirm that the image quality of dimmed SDR elements is satisfactory, OEMs must conduct manual tests. OEMs can test that any SDR parts played alongside HDR material don’t become too bright by playing video for HDR standards that the device supports over SurfaceView.

How Content Dimming Affects Battery Life

1. Increased GPU consumption may result from HWC systems that postpone dimming tasks.
2. The longer periods of time spent in high brightness mode can have an adverse effect on the health of the screen and result in long-term issues like burn-in.
3. The power demand for operating the screen at a higher brightness can increase with display setups that permit a lower threshold for triggering high brightness mode.

Conclusion

Hope this article helped you learn something new, and how to work with getting content dimming in your application to achieve great results. You can add this to your app to give your users a better user experience.