이 페이지에서는 SDR과 HDR 혼합 구성의 SDR 콘텐츠 어둡게 하기 기능의 요구사항, 구성, 유효성 검사에 관해 설명합니다.
Android 13에서는 다음 기능을 도입해 SDR과 HDR 구성을 화면에 동시에 표시하는 기능에 대한 지원을 개선하였습니다.
HDR 휘도를 SDR 호환 범위에 톤 매핑
libtonemap을 사용하여 하드웨어 컴포저(HWC), SurfaceFlinger, 앱 간에 일관된 톤 매핑을 구현할 수 있습니다. OEM은 공급업체 구성요소와 프레임워크 구성요소 간에 공유할 자체 톤 매핑 곡선을 구현할 수 있습니다.
HDR 콘텐츠와 동시에 표시될 때 화면에서 SDR 콘텐츠를 어둡게 하기
HDR 콘텐츠가 화면에 표시되면 HDR 콘텐츠의 높은 휘도 범위에 맞게 화면이 밝아집니다. 동일한 화면에 표시된 SDR 콘텐츠는 화면이 밝아짐에 따라 적절하게 어두워지므로 SDR 콘텐츠의 체감 밝기는 달라지지 않습니다. OEM은 SDR 콘텐츠가 HDR 콘텐츠와 함께 표시될 때 SDR 콘텐츠가 어두워지도록 내장 디스플레이를 구성할 수 있습니다.
OEM 요구사항
SDR 콘텐츠 어둡게 하기를 통해 HDR 및 SDR 콘텐츠의 구성을 개선하려면 다음 요구사항을 따르세요.
기기의 색상 파이프라인에 하드웨어를 통해 빠르게 어둡게 하는 기능 지원이 포함된 HWC의 AIDL 버전을 구현합니다. 필수 기능을 구현하는 방법은 HWC용 AIDL을 참고하세요.
HWC에서 하드웨어 오버레이를 정확하게 어둡게 하려면 특정 하드웨어가 오버레이의 선형 빛을 늘려야 합니다. 하드웨어가 충분하지 않은 구현에서는 SurfaceFlinger에 의해 구성을 GPU로 넘겨야 하므로 배터리가 소모되고 어둡게 하기의 품질이 낮아질 수 있습니다.
SDR과 HDR 콘텐츠 혼합 구성 기능은 배터리 수명, 번인 및 콘텐츠 품질 사이의 균형을 잡을 수 있도록 내장 디스플레이 기기의 특성에 따라 구성할 수 있습니다
개선된 구성을 사용 설정하고 조정하는 작업은 스키마가 display-device-config.xsd에 있는 디스플레이 구성을 통해 이루어집니다.
다음 새 키 요소는 디스플레이 구성을 설정하는 데 있어 중요합니다.
sdrHdrRatioMap 요소는 SDR 어둡게 하기를 사용 설정하고 화면에 HDR 콘텐츠가 있을 때 SDR 화이트 포인트에 표시할 HDR의 화면 밝기를 매핑하는 룩업 테이블(LUT)을 정의합니다.
sdrHdrRatioMap이 정의된 경우, DisplayManagerService는 화면 밝기를 제어하는 작업의 일부로 SurfaceFlinger가 HWC에 적정 수준의 레이어당 어둡게 하기 비율을 보낼 수 있도록 SurfaceFlinger에 원하는 SDR 화이트 포인트를 알려줍니다.
sdrHdrRatioMap이 정의되지 않은 경우, HWC 구현이 SDR 어둡게 하기를 지원하더라도 SDR 어둡게 하기가 사용 설정되지 않습니다.
0~100 사이의 값을 갖는 minimumHdrPercentOfScreen 요소는 패널의 높은 밝기 모드를 사용 설정할 수 있는 시점을 제어합니다. Android 13에서는 이 기준점을 조정하여 PIP 모드와 같은 더 많은 상황에서 높은 밝기 모드를 사용 설정할 수 있습니다.
이전 버전의 AOSP에서는 이 값이 50%로 고정되었습니다.
디스플레이 구성의 주요 요소는 다음 코드 블록을 참고하세요.
<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>
주의사항
톤 매핑 및 SDR 콘텐츠 어둡게 하기 기능을 사용 설정하면 다음과 같은 상황이 발생할 수 있습니다.
SDR 콘텐츠 요소가 어두워지면 기기에서 재생되는 HDR 콘텐츠의 품질이 좋아질 수 있습니다.
다음과 같은 경우에 배터리 수명이 단축될 수 있습니다.
어둡게 하기 작업을 GPU에 넘기는 HWC 구현으로 인해 GPU 사용량이 늘어날 수 있습니다.
보다 낮은 기준점에서 높은 밝기 모드를 사용 설정할 수 있도록 하는 디스플레이 구성을 하면 더 높은 밝기로 화면을 실행할 때 전력 소비량이 늘어날 수 있습니다.
높은 밝기 모드를 사용하는 시간이 길어짐에 따라 화면 상태가 영향을 받아 디스플레이 번인과 같은 장기적인 문제가 발생할 수 있습니다.
이 기능의 유효성 검사는 기기에 따라 달라지므로 이를 지원하는 CTS 또는 GTS 테스트는 없습니다.
OEM은 수동 테스트를 실행하여 어두워진 SDR 요소의 이미지 품질이 적절한지 확인해야 합니다. OEM은 기기가 SurfaceView에서 지원하는 HDR 표준 콘텐츠를 재생하여 HDR 콘텐츠와 함께 재생되는 SDR 요소가 지나치게 밝지 않은지 확인할 수 있습니다.
문제
SDR 이미지를 어둡게 하면 블랙 크러시(원본 이미지의 어두운 부분에서 정보가 손실되는 현상)가 발생할 수 있습니다. 이는 일부 어두운 코드에서 어두운 색상 값이 줄어들기 때문입니다.
허용되지 않는 수준의 블랙 크러시를 유발하는 어둡게 하기를 구현할 때는 최종 이미지에 노이즈를 삽입하는 디더링 알고리즘을 구현해 밴딩 효과를 줄여야 합니다.
색상 파이프라인의 적절한 위치에서 이미지를 디더링할 수 없는 HWC 구현은 SurfaceFlinger가 GPU에서 어둡게 하기와 디더링을 적용하도록 요청해야 합니다.
sdrHdrRatioMap의 값을 조정하여 SDR 요소의 어둡게 하기 양을 제한하는 방법도 있습니다. 밝기 수준을 매우 낮추려면 GPU를 사용해야 합니다. GPU를 사용하면 이미지 품질이 개선되지만 배터리 수명이 단축될 수 있습니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-07-27(UTC)
[[["이해하기 쉬움","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-07-27(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."]]