एक एसडीआर-संगत रेंज के लिए टोन मैपिंग एचडीआर ल्यूमिनेंस

एंड्रॉइड 13 libtonemap नामक एक विक्रेता-कॉन्फ़िगर करने योग्य स्थिर लाइब्रेरी पेश करता है, जो टोन मैपिंग संचालन को परिभाषित करता है और सर्फेसफ्लिंगर प्रक्रिया और हार्डवेयर कंपोजर (एचडब्ल्यूसी) कार्यान्वयन के साथ साझा किया जाता है। यह सुविधा ओईएम को फ्रेमवर्क और विक्रेताओं के बीच अपने डिस्प्ले टोन मैपिंग एल्गोरिदम को परिभाषित करने और साझा करने में सक्षम बनाती है, जिससे टोन मैपिंग में बेमेल कम हो जाता है।

Android 13 से पहले, डिस्प्ले-विशिष्ट टोन मैपिंग संचालन HWC, SurfaceFlinger और ऐप्स के बीच साझा नहीं किए जाते थे। एचडीआर सामग्री के लिए रेंडरिंग पथ के आधार पर, इससे छवि गुणवत्ता में बेमेल हो गया, जहां एचडीआर सामग्री को अलग-अलग तरीकों से आउटपुट स्पेस में टोन मैप किया गया था। यह स्क्रीन रोटेशन जैसे परिदृश्यों में ध्यान देने योग्य था, जहां जीपीयू और डीपीयू के बीच संरचना रणनीति बदलती है, और टेक्सचर व्यू और सर्फेस व्यू के बीच रेंडरिंग व्यवहार में अंतर होता है।

यह पृष्ठ libtonemap लाइब्रेरी के इंटरफ़ेस, अनुकूलन और सत्यापन विवरण का वर्णन करता है।

टोन मैपिंग लाइब्रेरी का इंटरफ़ेस

libtonemap लाइब्रेरी में सीपीयू-समर्थित कार्यान्वयन और एसकेएसएल शेडर्स शामिल हैं, जिन्हें जीपीयू-बैकएंड संरचना के लिए सर्फेसफ्लिंगर द्वारा और टोन मैपिंग लुक-अप टेबल (एलयूटी) उत्पन्न करने के लिए एचडब्ल्यूसी द्वारा प्लग इन किया जा सकता है। libtonemap का प्रवेश बिंदु android::tonemap::getToneMapper() है, जो एक ऑब्जेक्ट लौटाता है जो ToneMapper इंटरफ़ेस को लागू करता है।

ToneMapper इंटरफ़ेस निम्नलिखित क्षमताओं का समर्थन करता है:

  • एक टोन-मैपिंग LUT उत्पन्न करें

    इंटरफ़ेस ToneMapper::lookupTonemapGain libtonemap_LookupTonemapGain() में परिभाषित शेडर का एक सीपीयू कार्यान्वयन है। इसका उपयोग फ्रेमवर्क में यूनिट परीक्षणों द्वारा किया जाता है, और इसका उपयोग साझेदारों द्वारा उनके रंग पाइपलाइन के अंदर टोन-मैपिंग LUT उत्पन्न करने में सहायता के लिए किया जा सकता है।

    libtonemap_LookupTonemapGain() रैखिक RGB और XYZ दोनों में पूर्ण, असामान्य रैखिक स्थान में रंग मान लेता है, और रैखिक स्थान में इनपुट रंगों को कितना गुणा करना है, इसका वर्णन करते हुए एक फ्लोट लौटाता है।

  • एक एसकेएसएल शेडर उत्पन्न करें

    इंटरफ़ेस ToneMapper::generateTonemapGainShaderSkSL() एक स्रोत और गंतव्य डेटास्पेस दिए गए, एक SkSL शेडर स्ट्रिंग लौटाता है। SkSL शेडर को RenderEngine के लिए Skia कार्यान्वयन में प्लग किया गया है, जो SurfaceFlinger के लिए GPU-त्वरित कंपोजिटिंग घटक है। शेडर को libhwui में भी प्लग किया गया है, ताकि TextureView के लिए HDR-टू-SDR टोन मैपिंग कुशलतापूर्वक की जा सके। चूँकि उत्पन्न स्ट्रिंग स्कीया द्वारा उपयोग किए जाने वाले अन्य SkSL शेडर्स में इन-लाइन है, इसलिए शेडर को निम्नलिखित नियमों का पालन करना होगा:

    • शेडर स्ट्रिंग में float libtonemap_LookupTonemapGain(vec3 linearRGB, vec3 xyz) हस्ताक्षर के साथ एक प्रवेश बिंदु होना चाहिए, जहां linearRGB लीनियर स्पेस में आरजीबी पिक्सल के निरपेक्ष निट्स का मान है और xyz linearRGB को XYZ में परिवर्तित किया गया है।
    • शेडर स्ट्रिंग द्वारा उपयोग की जाने वाली किसी भी सहायक विधि को स्ट्रिंग libtonemap_ के साथ उपसर्ग किया जाना चाहिए ताकि फ्रेमवर्क शेडर परिभाषाओं में टकराव न हो। इसी प्रकार, इनपुट यूनिफ़ॉर्म को in_libtonemap_ के साथ उपसर्ग किया जाना चाहिए।
  • एसकेएसएल वर्दी तैयार करें

    इंटरफ़ेस ToneMapper::generateShaderSkSLUniforms() विभिन्न HDR मानकों और प्रदर्शन स्थितियों से मेटाडेटा का वर्णन करने वाली मेटाडेटा struct देखते हुए, निम्नलिखित लौटाता है:

    • वर्दी की एक सूची जो एसकेएसएल शेडर से बंधी है।

    • in_libtonemap_displayMaxLuminance और in_libtonemap_inputMaxLuminance समान मान। इन मानों का उपयोग फ्रेमवर्क शेडर्स द्वारा libtonemap में इनपुट को स्केल करते समय और लागू होने पर आउटपुट को सामान्य करते समय किया जाता है।

    वर्तमान में वर्दी बनाने की प्रक्रिया इनपुट और आउटपुट डेटास्पेस के प्रति अज्ञेयवादी है।

अनुकूलन

libtonemap लाइब्रेरी का संदर्भ कार्यान्वयन स्वीकार्य परिणाम उत्पन्न करता है। हालाँकि, क्योंकि GPU संरचना द्वारा उपयोग किया जाने वाला टोन मैपिंग एल्गोरिदम DPU संरचना द्वारा उपयोग किए जाने वाले से भिन्न हो सकता है, संदर्भ कार्यान्वयन का उपयोग करने से रोटेशन एनीमेशन जैसे कुछ परिदृश्यों में झिलमिलाहट हो सकती है। अनुकूलन ऐसे विक्रेता-विशिष्ट छवि गुणवत्ता मुद्दों को हल कर सकता है।

ओईएम को अपने स्वयं के ToneMapper उपवर्ग को परिभाषित करने के लिए libtonemap के कार्यान्वयन को ओवरराइड करने के लिए दृढ़ता से प्रोत्साहित किया जाता है, जो getToneMapper() द्वारा लौटाया जाता है। कार्यान्वयन को अनुकूलित करते समय, भागीदारों से निम्नलिखित में से एक कार्य करने की अपेक्षा की जाती है:

  • libtonemap के कार्यान्वयन को सीधे संशोधित करें।
  • अपनी स्वयं की स्थिर लाइब्रेरी को परिभाषित करें, लाइब्रेरी को एक स्टैंडअलोन के रूप में संकलित करें, और libtonemap लाइब्रेरी की .a फ़ाइल को उनकी कस्टम लाइब्रेरी से उत्पन्न फ़ाइल से बदलें।

विक्रेताओं को किसी भी कर्नेल कोड को संशोधित करने की आवश्यकता नहीं है, लेकिन कई विक्रेताओं को उचित कार्यान्वयन के लिए डीपीयू टोन-मैपिंग एल्गोरिदम के बारे में विवरण बताना होगा।

मान्यकरण

अपने कार्यान्वयन को सत्यापित करने के लिए इन चरणों का पालन करें:

  1. किसी भी HDR मानक की स्क्रीन पर HDR वीडियो चलाएं, जिसे आपका डिस्प्ले सिस्टम समर्थन करता है , जैसे HLG, HDR10, HDR10+, या DolbyVision।

  2. यह सुनिश्चित करने के लिए GPU संरचना को टॉगल करें कि कोई उपयोगकर्ता को ध्यान देने योग्य झिलमिलाहट न हो।

    GPU संरचना को टॉगल करने के लिए निम्नलिखित adb कमांड का उपयोग करें:

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

सामान्य मुद्दे

इस कार्यान्वयन के साथ निम्नलिखित समस्याएँ हो सकती हैं:

  • बैंडिंग तब होती है जब GPU संरचना द्वारा उपयोग किया जाने वाला रेंडर लक्ष्य HDR सामग्री के लिए विशिष्ट मान से कम परिशुद्धता का होता है। उदाहरण के लिए, बैंडिंग तब हो सकती है जब HWC कार्यान्वयन HDR के लिए RGBA1010102 या P010 जैसे अपारदर्शी 10-बिट प्रारूपों का समर्थन करता है, लेकिन इसके लिए आवश्यक है कि GPU संरचना अल्फा का समर्थन करने के लिए RGBA8888 जैसे 8-बिट प्रारूप में लिखे।

  • यदि डीपीयू जीपीयू से भिन्न परिशुद्धता पर काम करता है तो परिमाणीकरण अंतर के कारण सूक्ष्म रंग परिवर्तन होता है।

इनमें से प्रत्येक समस्या अंतर्निहित हार्डवेयर के सापेक्ष सटीक अंतर से संबंधित है। एक सामान्य समाधान यह सुनिश्चित करना है कि कम परिशुद्धता पथों में एक ढुलमुल कदम हो, जिससे कोई भी परिशुद्धता अंतर कम मानवीय बोधगम्य हो।