<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>
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["必要な情報がない","missingTheInformationINeed","thumb-down"],["複雑すぎる / 手順が多すぎる","tooComplicatedTooManySteps","thumb-down"],["最新ではない","outOfDate","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["サンプル / コードに問題がある","samplesCodeIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-03-26 UTC。"],[],[],null,["# Mixed SDR and HDR composition\n\nThis page describes the requirements, configuration, and validation of the SDR\ncontent dimming feature for mixed SDR and HDR composition.\n\nAndroid 13 improves support for simultaneously\npresenting SDR and HDR composition on screen by introducing the following\nfeatures:\n\n- Tone mapping HDR luminance to an SDR-compatible range.\n\n Using [`libtonemap`](/docs/core/display/tone-mapping), tone mapping can be made\n consistent between Hardware Composer (HWC), SurfaceFlinger, and apps. OEMs can\n implement their own tone mapping curves to be shared between vendor and\n framework components.\n- Dimming on-screen SDR content when presented simultaneously with HDR\n content.\n\n When HDR content is on screen, the screen brightness is increased to\n accommodate the increased luminance range of the HDR content. Any SDR content\n that is also on screen is seamlessly dimmed as the screen brightness increases\n so that the perceptual brightness of the SDR content doesn't change. OEMs can\n configure their built-in displays to dim on-screen SDR content when presented\n alongside HDR content.\n\nOEM requirements\n----------------\n\nTo use the improved composition for HDR and SDR content through SDR content\ndimming, follow these requirements:\n\n- Implement the AIDL version of the HWC, which includes support for\n hardware-accelerated dimming in the device's color pipeline. Refer to\n [AIDL for HWC](/docs/core/graphics/aidl-hwc) for implementing the required\n capabilities.\n\n- Accurately dimming hardware overlays in the HWC requires specific hardware\n to scale the linear light of the overlays. Implementations without sufficient\n hardware are required to defer composition to the GPU by SurfaceFlinger, causing\n battery drain and possible low-quality dimming.\n\n- The device must support at least one HDR technology reported by\n [`Display.getHdrCapabilities`](https://cs.android.com/android/platform/superproject/+/android-latest-release:frameworks/base/core/java/android/view/Display.java;l=1086?q=f:display.java&ss=android).\n\n| **Note:** Introduction of this feature has no impact on upgrading devices to Android 13.\n\nConfiguration\n-------------\n\nThe mixed SDR and HDR content composition feature can be configured according to\nthe built-in display device characteristics, so that the tradeoff between\nbattery life, burn-in, and content fidelity is established.\n\nEnabling and tuning the improved composition is done through a display\nconfiguration whose schema is located in [`display-device-config.xsd`](https://android.googlesource.com/platform/frameworks/base/+/refs/heads/android16-release/services/core/xsd/display-device-config/display-device-config.xsd#1).\nThe following new key elements are important in setting the display\nconfiguration:\n\n- The [`sdrHdrRatioMap`](https://android.googlesource.com/platform/frameworks/base/+/refs/heads/android16-release/services/core/xsd/display-device-config/display-device-config.xsd#144) element enables SDR\n dimming and defines a look-up table (LUT) for mapping the screen brightness for\n HDR to be displayed to the SDR white point when there's HDR content on screen.\n\n If `sdrHdrRatioMap` is defined, then as part of controlling the screen\n brightness, `DisplayManagerService` communicates the desired SDR white point to\n SurfaceFlinger so that SurfaceFlinger can send the appropriate dimming ratio per\n layer to the HWC.\n\n If `sdrHdrRatioMap` isn't defined, the SDR dimming isn't enabled, even if\n the HWC implementation supports SDR dimming.\n- The [`minimumHdrPercentOfScreen`](https://android.googlesource.com/platform/frameworks/base/+/refs/heads/android16-release/services/core/xsd/display-device-config/display-device-config.xsd#138)\n element, with a value ranging from 0 to 100, controls when a panel's high\n brightness mode is allowed to be turned on. With\n Android 13, this threshold is tunable to enable high\n brightness mode in more situations, such as picture-in-picture scenarios.\n Previous versions of AOSP have fixed this value to 50%.\n\nSee the following code block for the key elements of the display configuration: \n\n \u003cdisplayConfiguration\u003e\n ...\n \u003chighBrightnessMode\u003e\n ...\n \u003c!--Percentage of the screen that must be covered by HDR layers until high brightness mode is enabled.\n \u003cminimumHdrPercentOfScreen\u003e...\u003c/minimumHdrPercentOfScreen\u003e\n \u003c!--sdrHdrRatioMap, backed by spline, must have at least two entries --\u003e\n \u003csdrHdrRatioMap\u003e\n \u003cpoint\u003e\n \u003csdrNits\u003e...\u003c/sdrNits\u003e\n \u003chdrRatio\u003e...\u003c/hdrRatio\u003e\n \u003c/point\u003e\n \u003cpoint\u003e\n \u003csdrNits\u003e...\u003c/sdrNits\u003e\n \u003chdrRatio\u003e...\u003c/hdrRatio\u003e\n \u003c/point\u003e\n \u003c!--More interpolation points may be added ---\u003e\n ...\n \u003c/sdrHdrRatioMap\u003e\n ...\n \u003c/highBrightnessMode\u003e\n ...\n \u003c/displayConfiguration\u003e\n\nCaveats\n-------\n\nEnabling the tone mapping and SDR content dimming features can lead to the\nfollowing situations:\n\n- The fidelity of HDR content played on the device can increase, as the SDR\n content elements are dimmed.\n\n- The battery life can decrease in the following scenarios:\n\n - The HWC implementations that defer dimming operations to the GPU can\n cause increased GPU use.\n\n - Display configurations that allow for a lower threshold for enabling\n high brightness mode can increase power draw for running the screen at a higher\n brightness.\n\n- Screen health can be impacted due to the increased time spent in the high\n brightness mode, which can cause long-term problems such as burn-in with display\n health.\n\nValidation\n----------\n\nOEMs can use VTS tests, which are included as part of the HWC's test suite, to\ncheck for\n[dimming correctness](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/graphics/composer/aidl/vts/VtsHalGraphicsComposer3_ReadbackTest.cpp#960) and to [validate the input dimming ratio](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/graphics/composer/aidl/vts/VtsHalGraphicsComposer3_TargetTest.cpp#1370).\n\nValidation for this feature is device dependent, so there are no CTS or GTS\ntests to support this.\n\nOEMS must run manual tests to validate that the image quality of dimmed SDR\nelements is acceptable. OEMs can play content for HDR standards that the device\nsupports over `SurfaceView` to validate that any SDR elements played alongside\nthe HDR content don't become overly bright.\n\n### Issues\n\nDimming SDR images can result in *black crush*, or information loss in darker\nareas of the original image. This is due to darker color values collapsing onto\na smaller set of dark codes.\n\nAn implementation for dimming that causes unacceptable black crush must\nimplement dithering algorithms, which inject noise into the final image so that\nbanding effects are reduced.\n\nHWC implementations that are unable to dither the image in the appropriate\nlocation in the color pipeline must request that the SurfaceFlinger applies\ndimming and dithering on the GPU.\n\nImplementations can also adjust the value of `sdrHdrRatioMap` to limit the\namount of dimming for SDR elements. Dimming to very low brightness levels\nrequires the use of the GPU, which improves image quality but can decrease\nbattery life."]]