מיפוי גוונים של בהירות HDR לטווח תואם SDR

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

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

דף זה מתאר את פרטי הממשק, ההתאמה האישית והאימות של ספריית libtonemap .

ממשק לספריית מיפוי הגוונים

ספריית libtonemap מכילה יישומים מגובים CPU ו-SkSL shaders, אותם ניתן לחבר על ידי SurfaceFlinger עבור הרכב GPU-backend ועל ידי ה-HWC ליצירת טבלת חיפוש מיפוי גוונים (LUT). נקודת הכניסה ל- libtonemap היא android::tonemap::getToneMapper() , שמחזירה אובייקט שמיישם את ממשק ToneMapper .

ממשק ToneMapper תומך ביכולות הבאות:

• צור LUT למיפוי גוונים

  הממשק ToneMapper::lookupTonemapGain הוא מימוש CPU של הצללה המוגדרת ב- libtonemap_LookupTonemapGain() . זה משמש על ידי בדיקות יחידה במסגרת, והוא יכול לשמש את השותפים לסיוע ביצירת LUT למיפוי גוונים בתוך צינור הצבעים שלהם.

  libtonemap_LookupTonemapGain() לוקח ערכי צבע במרחב ליניארי מוחלט, לא מנורמל, הן ב-RGB ליניארי והן ב-XYZ, ומחזיר ציפה המתארת ​​כמה להכפיל את צבעי הקלט במרחב ליניארי.

• צור הצללה של SkSL

  הממשק ToneMapper::generateTonemapGainShaderSkSL() מחזיר מחרוזת הצללה SkSL, בהינתן מרחב נתונים של מקור ויעד. ה-SkSL Shader מחובר למימוש Skia עבור RenderEngine , רכיב ה-GPU המואץ עבור SurfaceFlinger. הצללה מחוברת גם ל- libhwui , כך שניתן לבצע מיפוי גוונים HDR-to-SDR ביעילות עבור TextureView . מכיוון שהמחרוזת שנוצרה משולבת בשורה ב-SkSL shaders אחרים המשמשים את Skia, ההצללה חייבת לציית לכללים הבאים:

  • למחרוזת הצללה חייבת להיות נקודת כניסה עם החתימה float libtonemap_LookupTonemapGain(vec3 linearRGB, vec3 xyz) , כאשר linearRGB הוא הערך של ה-nits המוחלט של פיקסלים RGB במרחב ליניארי ו- xyz הוא linearRGB המרה ל-XYZ.
  • כל שיטות העזר המשמשות את המחרוזת של הצללה חייבת להיות קדומה עם המחרוזת libtonemap_ כדי שהגדרות הצללה של מסגרת לא יתנגשו. באופן דומה, יש להקדים את מדי הקלט עם in_libtonemap_ .

• צור מדי SkSL

  הממשק ToneMapper::generateShaderSkSLUniforms() מחזיר את הדברים הבאים, בהינתן struct מטא נתונים המתאר מטא נתונים מתקני HDR ותנאי תצוגה שונים:

  • רשימה של מדים הכרוכים ב-SkSL shader.

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

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

התאמה אישית

יישום ההתייחסות של ספריית libtonemap מייצר תוצאות מקובלות. עם זאת, מכיוון שאלגוריתם מיפוי הגוונים המשמש את הרכב ה-GPU יכול להיות שונה מזה המשמש את הרכב ה-DPU, השימוש ביישום ההפניה עלול לגרום להבהוב בתרחישים מסוימים, כגון אנימציית הסיבוב. התאמה אישית יכולה לפתור בעיות כאלה באיכות תמונה ספציפית לספק.

יצרני OEM מעודדים מאוד לעקוף את היישום של libtonemap כדי להגדיר תת מחלקה ToneMapper משלהם, המוחזרת על ידי getToneMapper() . בעת התאמה אישית של היישום, השותפים צפויים לבצע אחת מהפעולות הבאות:

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

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

מַתַן תוֹקֵף

בצע את השלבים הבאים כדי לאמת את היישום שלך:

1. הפעל סרטוני HDR על המסך בכל תקני HDR שמערכת התצוגה שלך תומכת בהם , כגון HLG, HDR10, HDR10+ או DolbyVision.

2. החלף את הרכב ה-GPU כדי להבטיח שאין הבהוב מורגש על ידי המשתמש.

   השתמש בפקודת adb הבאה כדי לשנות את הרכב ה-GPU:

   adb shell service call SurfaceFlinger 1008 i32 <0 to enable HWC composition,
   1 to force GPU composition>
   
   

בעיות נפוצות

הבעיות הבאות יכולות להתרחש ביישום זה:

• פסים נגרמת כאשר יעד העיבוד המשמש את הרכב ה-GPU הוא בעל דיוק נמוך מהערך הטיפוסי לתוכן HDR. לדוגמה, פסים יכולים להתרחש כאשר מימוש HWC תומך בפורמטים אטומים של 10 סיביות עבור HDR כגון RGBA1010102 או P010, אך דורש שהרכב GPU יכתוב לפורמט של 8 סיביות כמו RGBA8888 כדי לתמוך באלפא.

• שינוי צבע עדין נגרם על ידי הבדלי קוונטיזציה אם ה-DPU פועל בדיוק שונה מזה של ה-GPU.

כל אחת מהנושאים הללו קשורה להבדלי הדיוק היחסיים של החומרה הבסיסית. דרך טיפוסית לעקיפת הבעיה היא להבטיח שיש שלב חילוף בנתיבי הדיוק הנמוכים יותר, מה שהופך את כל הבדלי הדיוק לפחות אנושיים.