اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release بدلاً من aosp-main لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
توضّح هذه الصفحة متطلبات ميزة "تعتيم محتوى SDR" وكيفية ضبطها والتحقّق منها لإنشاء تركيبة مختلطة من محتوى SDR وHDR.
يحسِّن نظام التشغيل Android 13 إمكانية عرض محتوى بنطاق عادي وديناميكي على الشاشة في الوقت نفسه من خلال تقديم الميزة التالية:
تحويل نطاق سطوع HDR إلى نطاق متوافق مع SDR
باستخدام libtonemap، يمكن جعل تحويل النغمات
متسقًا بين Hardware Composer (HWC) وSurfaceFlinger والتطبيقات. يمكن لمصنّعي المعدّات الأصلية
تنفيذ منحنيات ربط الدرجات اللونية الخاصة بهم لمشاركتها بين مكوّنات المورّد
والإطار.
تعتيم محتوى SDR المعروض على الشاشة عند عرضه في الوقت نفسه مع محتوى HDR
عندما يظهر محتوى بتقنية النطاق العالي الديناميكية على الشاشة، يتم زيادة سطوع الشاشة للتماشي مع نطاق الإضاءة المتزايد للمحتوى بتقنية النطاق العالي الديناميكية. يتم أيضًا تعتيم أي محتوى عادي
معروض على الشاشة بسلاسة مع زيادة سطوع الشاشة
كي لا يتغيّر السطوع المرئي للمحتوى العادي. يمكن لمصنّعي المعدّات الأصلية
ضبط شاشاتهم المدمَجة لتعتيم محتوى SDR المعروض على الشاشة عند عرضه
مع محتوى HDR.
متطلبات المصنّع الأصلي للجهاز
لاستخدام التركيب المحسّن للمحتوى بتقنية HDR وSDR من خلال ميزة dimming (تعتيم) المحتوى بتقنية SDR، اتّبِع المتطلبات التالية:
نفِّذ إصدار AIDL من HWC، والذي يتضمّن ميزة تضاؤل مدعوم بالأجهزة في مسار الألوان بالجهاز. يُرجى الرجوع إلى AIDL لميزة "المعالجة عالية السرعة" لتنفيذ الإمكانات المطلوبة.
يتطلب تعتيم العناصر المركّبة على الأجهزة بدقة في "العرض على الشاشة" (HWC) أجهزة معيّنة
لتوسيع نطاق الإضاءة الخطية للعناصر المركّبة. إنّ عمليات التنفيذ التي لا تتضمّن تجهيزات
كافية تتطلّب من SurfaceFlinger تأجيل عملية الدمج إلى وحدة معالجة الرسومات، ما يؤدي إلى
استنزاف البطارية وربما انخفاض جودة التعتيم.
يجب أن يكون الجهاز متوافقًا مع تقنية HDR واحدة على الأقل تم الإبلاغ عنها من قِبل
Display.getHdrCapabilities.
الإعدادات
يمكن ضبط ميزة تركيب المحتوى المختلط بتنسيق SDR وHDR وفقًا
لخصائص جهاز العرض المدمج، وذلك لتحقيق التوازن بين
عمر البطارية والاحتراق ودقة المحتوى.
يتم تفعيل التركيبة المحسّنة وضبطها من خلال إعدادات الشاشة
التي يمكن العثور على مخطّطها في display-device-config.xsd.
إنّ العناصر الرئيسية الجديدة التالية مهمة في ضبط إعدادات الشاشة:
يُمكِّن عنصر sdrHdrRatioMap من SDR
تعتيم وتحديد جدول مرجعي (LUT) لربط سطوع الشاشة لملف HDR المعروض بنقطة SDR البيضاء عند عرض محتوى HDR على الشاشة.
إذا تم تحديد sdrHdrRatioMap، يتم إرسال نقطة الأبيض المطلوبة لمعدل نقل البيانات المنخفض (SDR) إلى
SurfaceFlinger من خلال DisplayManagerService كجزء من التحكّم في سطوع الشاشة
كي يتمكّن SurfaceFlinger من إرسال نسبة التعتيم المناسبة لكل
طبقة إلى HWC.
في حال عدم تحديد sdrHdrRatioMap، لن يتم تفعيل ميزة "تعتيم SDR"، حتى إذا كان تنفيذ HWC يتيح ميزة "تعتيم SDR".
يتحكّم العنصر minimumHdrPercentOfScreen
، الذي تتراوح قيمته بين 0 و100، في الحالات التي يُسمح فيها بتفعيل وضع السطوع
العالٍ في اللوحة. في نظام التشغيل
Android 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" إلى المواقف التالية:
يمكن أن تزيد دقة المحتوى بنطاق عالي الديناميكية الذي يتم تشغيله على الجهاز، وذلك عندما يتم تعتيم عناصر المحتوى بتقنية SDR.
يمكن أن ينخفض عمر البطارية في السيناريوهات التالية:
إنّ عمليات تنفيذ HWC التي تؤجل عمليات التعتيم إلى وحدة معالجة الرسومات يمكن أن تؤدي إلى
زيادة استخدام وحدة معالجة الرسومات.
إنّ إعدادات الشاشة التي تسمح بمستوى أقل لتفعيل وضع السطوع العالي يمكن أن تزيد من استهلاك الطاقة لتشغيل الشاشة بمستوى سطوع أعلى.
يمكن أن تتأثر حالة الشاشة بسبب زيادة الوقت الذي تقضيه في وضع سطوع الشاشة العالي، ما قد يتسبب في مشاكل على المدى الطويل، مثل الاحتراق في شاشة
العرض.
يعتمد التحقّق من هذه الميزة على الجهاز، لذا لا تتوفّر اختبارات CTS أو GTS
للتحقّق من هذه الميزة.
على المصنّعين الأصليّين للأجهزة إجراء اختبارات يدوية للتحقّق من أنّ جودة الصورة لعناصر SDR
المعتمَدة مقبولة. يمكن لمصنّعي المعدّات الأصلية تشغيل محتوى بمعايير HDR متوافقة مع الجهاز ويتجاوز SurfaceView للتأكّد من أنّ أي عناصر SDR يتم تشغيلها مع
المحتوى بتقنية HDR لا تصبح شديدة السطوع.
المشاكل
يمكن أن يؤدي تعتيم صور SDR إلى تداخل اللون الأسود أو فقدان المعلومات في مناطق
الصورة الأصلية الأكثر قتامة. ويعود السبب في ذلك إلى تجميع قيم الألوان الداكنة في
مجموعة أصغر من الرموز الداكنة.
يجب أن يتضمّن تنفيذ ميزة التعتيم الذي يتسبب في حدوث تشويش غير مقبول للّون الأسود
خوارزميات التمويه التي تضخّ الضوضاء في الصورة النهائية كي يتم
تقليل تأثيرات التدرّج.
إنّ عمليات تنفيذ HWC التي لا يمكنها تمويه الصورة في
الموقع المناسب في مسار نقل الألوان يجب أن تطلب من SurfaceFlinger تطبيق
التعتيم والتمويه على وحدة معالجة الرسومات.
يمكن أيضًا لعمليات التنفيذ تعديل قيمة sdrHdrRatioMap للحد من
مقدار التعتيم لعناصر SDR. إنّ تقليل مستوى السطوع إلى مستويات منخفضة جدًا
يتطلب استخدام وحدة معالجة الرسومات، ما يؤدي إلى تحسين جودة الصورة، ولكن يمكن أن يقلل
من عمر البطارية.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","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 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],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."]]