קומפוזיציה משולבת של SDR ו-HDR

קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

בדף הזה מוסבר על הדרישות, ההגדרה והאימות של התכונה 'הכהיית תוכן SDR' ליצירת סרטונים עם שילוב של SDR ו-HDR.

ב-Android 13 יש שיפור בתמיכה בהצגה בו-זמנית של קומפוזיציה של SDR ו-HDR במסך, באמצעות התכונות הבאות:

• מיפוי טונוס של בהירות HDR לטווח תואם ל-SDR.

  בעזרת libtonemap, אפשר ליצור עקביות במיפוי הטונים בין Hardware Composer‏ (HWC),‏ SurfaceFlinger ואפליקציות. יצרני ציוד מקורי יכולים להטמיע עקומות מיפוי גוונים משלהם, שיהיו משותפות בין רכיבי הספק לבין רכיבי המסגרת.

• האפלה של תוכן SDR במסך כשמוצג בו בו-זמנית תוכן HDR.

  כשתוכן HDR מוצג במסך, בהירות המסך מוגדלת כדי להתאים לטווח הבהירות המוגדל של תוכן ה-HDR. כל תוכן SDR שמוצג במסך יאטם בצורה חלקה ככל שהבהירות של המסך תגדל, כך שהבהירות החזותית של תוכן ה-SDR לא תשתנה. יצרני ציוד מקורי יכולים להגדיר את המסכים המובנים שלהם כך שהתוכן ב-SDR יוצג עם עמעום כשמוצג לצד תוכן HDR.

דרישות OEM

כדי להשתמש בהרכב משופר של תוכן HDR ו-SDR באמצעות עמעום של תוכן SDR, צריך לעמוד בדרישות הבאות:

• הטמעת גרסת ה-AIDL של HWC, שכוללת תמיכה בהכהיה שמואצלת בחומרה בצינור עיבוד הנתונים של צבעי המכשיר. במאמר AIDL ל-HWC מוסבר איך מטמיעים את היכולות הנדרשות.

• כדי להכהות שכבות-על של חומרה ב-HWC באופן מדויק, נדרשת חומרה ספציפית כדי לשנות את עוצמת התאורה הליניארית של השכבות העליונות. הטמעות ללא חומרה מספקת נדרשות לדחות את הרכבת התמונה ל-GPU על ידי SurfaceFlinger, וכתוצאה מכך יש ירידה בחיי הסוללה ויכול להיות גם עמעום באיכות נמוכה.

• המכשיר חייב לתמוך בטכנולוגיית HDR אחת לפחות שדווחה על ידי Display.getHdrCapabilities.

הגדרות אישיות

אפשר להגדיר את התכונה של שילוב תוכן ב-SDR וב-HDR בהתאם למאפיינים של מכשיר המסך המובנה, כדי למצוא את האיזון בין חיי הסוללה, שריפה ב-OLED ומידת הנאמנות של התוכן.

כדי להפעיל את התכונה ולכוונן את ההרכב המשופרת, צריך להשתמש בהגדרת תצוגה שהסכימה שלה נמצאת ב-display-device-config.xsd. הרכיבים החדשים הבאים חשובים להגדרת תצורת התצוגה:

• האלמנט sdrHdrRatioMap מאפשר עמעום של SDR ומגדיר טבלת חיפוש (LUT) למיפוי בהירות המסך כדי להציג HDR בנקודת הלבן של SDR כשיש תוכן HDR במסך.

  אם sdrHdrRatioMap מוגדר, כחלק מהשליטה בהירות המסך, DisplayManagerService מעביר את נקודת הלבן הרצויה ב-SDR ל-SurfaceFlinger כדי ש-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' עלולה להוביל למצבים הבאים:

• איכות התוכן ב-HDR שתופעל במכשיר עשויה להשתפר, כי רכיבי התוכן ב-SDR יהיו כהים יותר.

• חיי הסוללה עשויים להתקצר בתרחישים הבאים:

  • הטמעות HWC שמעבירות את פעולות ההכהה ל-GPU עלולות לגרום לשימוש מוגבר ב-GPU.

  • הגדרות תצוגה שמאפשרות להגדיר ערך סף נמוך יותר להפעלת מצב בהירות גבוהה עלולות להגדיל את צריכת החשמל של המסך במצב בהירות גבוהה יותר.

• זמן השימוש הממושך במצב בהירות גבוהה עלול להשפיע על תקינות המסך, ולגרום לבעיות לטווח ארוך כמו 'צריבה' במסך.

אימות

יצרני ציוד מקורי יכולים להשתמש בבדיקות VTS, שנכללות בחבילת הבדיקות של HWC, כדי לבדוק את הנכונות של העמעום ולאמת את יחס העמעום של הקלט.

האימות של התכונה הזו תלוי במכשיר, ולכן אין בדיקות CTS או GTS שתומכות בה.

יצרני ציוד מקורי צריכים לבצע בדיקות ידניות כדי לוודא שאיכות התמונה של רכיבי SDR מעומעמים היא סבירה. יצרני ציוד מקורי יכולים להפעיל תוכן בתקני HDR שהמכשיר תומך בהם מעל SurfaceView כדי לוודא שאלמנטים של SDR שמתנגנים לצד תוכן HDR לא יהיו בהירים מדי.

בעיות

האפלה של תמונות SDR עלולה לגרום לדחיסה של שחור או לאובדן מידע באזורים כהים יותר בתמונה המקורית. הסיבה לכך היא שערכים של צבעים כהים יותר מתכווצים לקבוצה קטנה יותר של קודים כהים.

הטמעה של עמעום שגורמת ל-black crush בלתי קביל חייבת לכלול הטמעה של אלגוריתמים של דיטירציה, שמחדירים רעש לתמונה הסופית כדי לצמצם את ההשפעות של פסים.

הטמעות של HWC שלא יכולות לבצע דיטיר (dither) של התמונה במיקום המתאים בצינור עיבוד הצבעים צריכות לבקש מ-SurfaceFlinger להחיל עמעום ודיטיר ב-GPU.

אפשר גם לשנות את הערך של sdrHdrRatioMap כדי להגביל את מידת ההכהה של רכיבי SDR. כדי להפחית את הבהירות לרמות נמוכות מאוד, צריך להשתמש ב-GPU. הפעולה הזו משפרת את איכות התמונה, אבל יכולה לקצר את חיי הסוללה.