از 27 مارس 2025، توصیه می کنیم از android-latest-release به جای aosp-main برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
با مجموعهها، منظم بمانید
ذخیره و طبقهبندی محتوا براساس اولویتهای شما.
این صفحه الزامات، پیکربندی و اعتبار سنجی ویژگی کم نور محتوای SDR را برای ترکیب ترکیبی SDR و HDR توضیح می دهد.
اندروید 13 با معرفی ویژگی های زیر، پشتیبانی از ارائه همزمان ترکیب SDR و HDR روی صفحه را بهبود می بخشد:
نگاشت تون روشنایی HDR به محدوده سازگار با SDR.
با استفاده از libtonemap ، میتوان نگاشت تن را بین Hardware Composer (HWC)، SurfaceFlinger و برنامهها هماهنگ کرد. OEM ها می توانند منحنی های نگاشت تن خود را برای به اشتراک گذاشتن بین سازنده و اجزای چارچوب پیاده سازی کنند.
کاهش نور محتوای SDR روی صفحه هنگام ارائه همزمان با محتوای HDR.
هنگامی که محتوای HDR روی صفحه نمایش است، روشنایی صفحه افزایش می یابد تا محدوده روشنایی افزایش یافته محتوای HDR را در نظر بگیرد. هر محتوای SDR که روی صفحه نمایش نیز وجود دارد، با افزایش روشنایی صفحه به طور یکپارچه کم می شود تا روشنایی ادراکی محتوای SDR تغییر نکند. OEM ها می توانند نمایشگرهای داخلی خود را طوری پیکربندی کنند که محتوای SDR روی صفحه را در صورت ارائه در کنار محتوای HDR کم رنگ کند.
الزامات نصب شده
برای استفاده از ترکیب بهبود یافته برای محتوای HDR و SDR از طریق کم نور کردن محتوای SDR، این الزامات را دنبال کنید:
نسخه AIDL HWC را اجرا کنید، که شامل پشتیبانی از تیرگی تسریع شده سخت افزاری در خط لوله رنگ دستگاه است. برای اجرای قابلیت های مورد نیاز به AIDL for HWC مراجعه کنید.
کمنور کردن دقیق پوششهای سختافزاری در HWC به سختافزار خاصی برای مقیاسبندی نور خطی روکشها نیاز دارد. پیادهسازیهای بدون سختافزار کافی برای به تعویق انداختن ترکیب به GPU توسط SurfaceFlinger مورد نیاز هستند که باعث تخلیه باتری و کاهش تیرگی با کیفیت پایین میشود.
ویژگی ترکیبی محتوای SDR و HDR را می توان با توجه به ویژگی های دستگاه نمایش داخلی پیکربندی کرد، به طوری که تعادل بین عمر باتری، سوختن و وفاداری محتوا برقرار شود.
فعال کردن و تنظیم ترکیب بهبودیافته از طریق یک پیکربندی نمایشگر انجام می شود که طرح آن در display-device-config.xsd قرار دارد. عناصر کلیدی جدید زیر در تنظیم پیکربندی نمایشگر مهم هستند:
عنصر sdrHdrRatioMap کاهش نور SDR را فعال می کند و یک جدول جستجو (LUT) برای نگاشت روشنایی صفحه نمایش برای HDR تعریف می کند تا زمانی که محتوای HDR روی صفحه وجود دارد به نقطه سفید SDR نمایش داده شود.
اگر sdrHdrRatioMap تعریف شده باشد، به عنوان بخشی از کنترل روشنایی صفحه نمایش، DisplayManagerService نقطه سفید SDR مورد نظر را به SurfaceFlinger ارسال می کند تا SurfaceFlinger بتواند نسبت کم نور مناسب را در هر لایه به HWC ارسال کند.
اگر sdrHdrRatioMap تعریف نشده باشد، کم نور SDR فعال نمی شود، حتی اگر اجرای HWC از کم نور شدن SDR پشتیبانی کند.
عنصر minimumHdrPercentOfScreen ، با مقداری از 0 تا 100، زمانی را کنترل میکند که حالت روشنایی بالای پانل روشن شود. با اندروید 13، این آستانه برای فعال کردن حالت روشنایی بالا در موقعیتهای بیشتر، مانند سناریوهای تصویر در تصویر، قابل تنظیم است. نسخه های قبلی 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 میتواند منجر به شرایط زیر شود:
وفاداری محتوای HDR پخش شده در دستگاه می تواند افزایش یابد، زیرا عناصر محتوای SDR کم نور می شوند.
عمر باتری می تواند در حالات زیر کاهش یابد:
پیاده سازی HWC که عملیات کم نور را به GPU موکول می کند می تواند باعث افزایش استفاده از GPU شود.
پیکربندیهای صفحهنمایش که آستانه پایینتری برای فعال کردن حالت روشنایی بالا فراهم میکنند، میتوانند مصرف انرژی را برای اجرای صفحه نمایش با روشنایی بالاتر افزایش دهند.
به دلیل افزایش زمان صرف شده در حالت روشنایی بالا، سلامت صفحه می تواند تحت تأثیر قرار گیرد، که می تواند باعث مشکلات طولانی مدت مانند سوختگی با سلامت صفحه نمایش شود.
اعتبار سنجی
OEM ها می توانند از تست های VTS، که به عنوان بخشی از مجموعه آزمایشی HWC گنجانده شده است، برای بررسی صحت کم نور و اعتبار سنجی نسبت کم نور ورودی استفاده کنند.
اعتبارسنجی این ویژگی وابسته به دستگاه است، بنابراین هیچ تست CTS یا GTS برای پشتیبانی از آن وجود ندارد.
OEMS باید آزمایشهای دستی را اجرا کند تا تأیید کند که کیفیت تصویر عناصر SDR کمنور قابل قبول است. OEM ها می توانند محتوایی را برای استانداردهای HDR که دستگاه از طریق SurfaceView پشتیبانی می کند پخش کنند تا تأیید کنند که عناصر SDR پخش شده در کنار محتوای HDR بیش از حد روشن نمی شوند.
مسائل
کمنور کردن تصاویر SDR میتواند منجر به خرد شدن سیاهی یا از دست رفتن اطلاعات در مناطق تیرهتر تصویر اصلی شود. این به دلیل جمع شدن مقادیر رنگ تیره تر روی مجموعه کوچکتری از کدهای تیره است.
یک پیادهسازی برای کمنور کردن که باعث خرد شدن غیرقابل قبول سیاه میشود باید الگوریتمهای dithering را پیادهسازی کند، که نویز را به تصویر نهایی تزریق میکند تا اثرات باندینگ کاهش یابد.
پیادهسازیهای HWC که نمیتوانند تصویر را در مکان مناسب در خط لوله رنگ تغییر دهند، باید درخواست کنند که SurfaceFlinger کمنور کردن و دیترینگ را روی GPU اعمال کند.
پیادهسازیها همچنین میتوانند مقدار sdrHdrRatioMap را تنظیم کنند تا میزان تیرگی عناصر SDR را محدود کنند. کم نور کردن تا سطوح روشنایی بسیار کم نیاز به استفاده از GPU دارد که کیفیت تصویر را بهبود می بخشد اما می تواند عمر باتری را کاهش دهد.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","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-29 بهوقت ساعت هماهنگ جهانی."],[],[],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."]]