SDR-এর সাথে মানানসই রেঞ্জে HDR লুমিন্যান্স টোন ম্যাপ করা

Android 13-এ libtonemapনামের, ভেন্ডর-কনফিগার করা স্ট্যাটিক লাইব্রেরি আছে, যা টোন ম্যাপিং অপারেশনকে সংজ্ঞায়িত করে এবং SurfaceFlinger প্রসেস ও Hardware Composer (HWC) ইমপ্লিমেন্টেশনের সাথে শেয়ার করা হয়। এই ফিচার OEM-কে ফ্রেমওয়ার্ক ও ভেন্ডরের মধ্যে ডিসপ্লে টোন ম্যাপিং অ্যালগরিদম সংজ্ঞায়িত ও শেয়ার করতে দেয়, যার ফলে টোন ম্যাপিংয়ে অমিল কম হয়।

Android 12 এবং তার আগের ভার্সনে, ডিসপ্লে-নির্দিষ্ট টোন ম্যাপিং অপারেশনগুলি HWC, SurfaceFlinger এবং অ্যাপের মধ্যে শেয়ার করা হয়নি। রেন্ডারিং পাথের উপর নির্ভর করে, HDR কন্টেন্টের জন্য, এর ফলে ছবির কোয়ালিটিতে অমিল দেখা দেয়, যেখানে HDR কন্টেন্ট বিভিন্ন উপায়ে আউটপুট স্পেসে টোন ম্যাপ করা হয়। এটি স্ক্রিন রোটেশনের মতো পরিস্থিতিতে বোঝা যায়, যেখানে GPU ও DPU-এর মধ্যে কম্পোজিশন স্ট্র্যাটেজি পরিবর্তিত হয় এবং TextureView ও SurfaceView-এর মধ্যে রেন্ডারিং আচরণে পার্থক্য দেখা যায়।

এই পৃষ্ঠায় libtonemap লাইব্রেরির ইন্টারফেস, কাস্টমাইজেশন ও যাচাইকরণ সংক্রান্ত বিবরণ দেওয়া আছে।

টোন ম্যাপিং লাইব্রেরির ইন্টারফেস

libtonemap লাইব্রেরিতে CPU-ব্যাকড ইমপ্লিমেন্টেশন ও SkSL শেডার থাকে, যা GPU-ব্যাকএন্ড কম্পোজিশনের জন্য SurfaceFlinger এবং টোন ম্যাপিং লুক-আপ টেবিল (LUT) তৈরি করার জন্য HWC-এর মাধ্যমে প্লাগ-ইন করা যায়। libtonemap এন্ট্রি পয়েন্ট হলandroid::tonemap::getToneMapper, যা ToneMapper ইন্টারফেস প্রয়োগ করে এমন একটি অবজেক্ট রিটার্ন করে।

ToneMapper ইন্টারফেস নিম্নলিখিত কাজগুলি করতে পারে:

  • টোন-ম্যাপিং LUT তৈরি করা

    ইন্টারফেসটি ToneMapper::lookupTonemapGain হল libtonemap_LookupTonemapGain-এ সংজ্ঞায়িত শেডারের CPU প্রয়োগ। এটি ফ্রেমওয়ার্কে ইউনিট টেস্টের জন্য ব্যবহার করা হয়, এবং পার্টনাররা তাদের কালার পাইপলাইনের মধ্যে টোন-ম্যাপিং LUT তৈরি করার ব্যাপারে সহায়তা পাওয়ার জন্য এটি ব্যবহার করতে পারেন।

    libtonemap_LookupTonemapGain অ্যাবসলিউট, আননর্মালাইজড লিনিয়ার স্পেসে কালার ভ্যালু নেয়, লিনিয়ার RGB ও XYZ, দু'টিতেই এবং একটি ফ্লোট রিটার্ন করে যা বর্ণনা করে যে লিনিয়ার স্পেসে ইনপুট কালারকে কত দিয়ে গুণ করতে হবে।

  • SkSL শেডার তৈরি করা

    সোর্স ও ডেস্টিনেশন ডেটাস্পেস দেওয়া হলে, ইন্টারফেস ToneMapper::generateTonemapGainShaderSkSL একটি SkSL শেডার স্ট্রিং রিটার্ন করে। SkSL শেডারটি RenderEngine-এর জন্য Skia ইমপ্লিমেন্টেশনে প্লাগ-ইন করা আছে, SurfaceFlinger-এর জন্য GPU-অ্যাক্সিলারেটেড কম্পোজিটিং কম্পোনেন্ট। শেডারটি libhwui-এর সাথেও কানেক্ট করা আছে, যাতে TextureView-এর জন্য HDR থেকে SDR টোন ম্যাপিং দক্ষতার সাথে করা যায়। জেনারেট করা স্ট্রিং Skia-এর ব্যবহার করা অন্যান্য SkSL শেডারে ইন-লাইন করা থাকে, তাই শেডারকে নিম্নলিখিত নিয়ম মেনে চলতে হবে:

    • শেডার স্ট্রিংয়ে অবশ্যই float libtonemap_LookupTonemapGain(vec3 linearRGB, vec3 xyz) সিগনেচার সহ একটি এন্ট্রি পয়েন্ট থাকতে হবে, যেখানে linearRGB হল লিনিয়ার স্পেসে RGB পিক্সেলের অ্যাবসলিউট নিটসের ভ্যালু এবং xyz হল linearRGB-কে XYZ-এ কনভার্ট করা ভ্যালু।
    • শেডার স্ট্রিংয়ের মাধ্যমে ব্যবহার করা যেকোনও হেল্পার পদ্ধতিতে অবশ্যই স্ট্রিং libtonemap_-এর প্রিফিক্স থাকতে হবে যাতে ফ্রেমওয়ার্ক শেডার সংজ্ঞার মধ্যে কোনও দ্বন্দ্ব না হয়। একইভাবে, ইনপুট ইউনিফর্মের আগে in_libtonemap_ থাকতে হবে।
  • SkSL ইউনিফর্ম তৈরি করা

    ইন্টারফেস ToneMapper::generateShaderSkSLUniforms নিচে উল্লেখ করা তথ্য রিটার্ন করে, যেখানে মেটাডেটা struct বিভিন্ন HDR স্ট্যান্ডার্ড ও ডিসপ্লে কন্ডিশন থেকে মেটাডেটা বর্ণনা করে:

    • SkSL শেডার দ্বারা আবদ্ধ ইউনিফর্মের তালিকা।

    • ইউনিফর্ম ভ্যালু in_libtonemap_displayMaxLuminance এবং in_libtonemap_inputMaxLuminance. libtonemap-এ ইনপুট স্কেল করার সময় এবং প্রযোজ্য হলে আউটপুট নর্মালাইজ করার সময় ফ্রেমওয়ার্ক শেডার এইসব ভ্যালু ব্যবহার করে।

      ইউনিফর্ম জেনারেট করার প্রসেস ইনপুট ও আউটপুট ডেটাস্পেসের উপর নির্ভর করে না।

কাস্টমাইজেশন

libtonemap লাইব্রেরির রেফারেন্স ইমপ্লিমেন্টেশন গ্রহণযোগ্য ফলাফল প্রদান করে। তবে, GPU কম্পোজিশনের দ্বারা ব্যবহৃত টোন ম্যাপিং অ্যালগরিদম DPU কম্পোজিশনের দ্বারা ব্যবহৃত টোন ম্যাপিং অ্যালগরিদম থেকে আলাদা হতে পারে। এর ফলে, রেফারেন্স ইমপ্লিমেন্টেশন ব্যবহার করলে, কিছু পরিস্থিতিতে ফ্লিকার হতে পারে, যেমন রোটেট অ্যানিমেশন। কাস্টমাইজেশন এই ধরনের বিক্রেতা-নির্দিষ্ট ছবির কোয়ালিটি সংক্রান্ত সমস্যার সমাধান করতে পারে।

libtonemap-এর প্রয়োগ ওভাররাইড করে নিজের ToneMapper সাবক্লাস তৈরি করার জন্য OEM-কে অত্যন্ত উৎসাহিত করা হয়, যা getToneMapper-এর মাধ্যমে রিটার্ন করা হয়। ইমপ্লিমেন্টেশন কাস্টমাইজ করার সময়, পার্টনারদের নিম্নলিখিতগুলির মধ্যে কোনও একটি করতে হবে:

  • libtonemap-এর প্রয়োগ সরাসরি পরিবর্তন করুন।
  • তাদের নিজস্ব স্ট্যাটিক লাইব্রেরি সংজ্ঞায়িত করুন, লাইব্রেরিটিকে একটি স্বতন্ত্র হিসাবে কম্পাইল করুন এবং libtonemap লাইব্রেরির .a ফাইলটি তাদের কাস্টম লাইব্রেরি থেকে তৈরি করা ফাইলের সাথে প্রতিস্থাপন করুন।

ভেন্ডরদের কোনও কার্নেল কোড পরিবর্তন করতে হবে না, তবে একাধিক ভেন্ডরকে অবশ্যই সঠিকভাবে প্রয়োগ করার জন্য DPU টোন-ম্যাপিং অ্যালগরিদম সম্পর্কে বিশদ বিবরণ যোগাযোগ করতে হবে।

যাচাইকরণ

আপনার প্রয়োগ যাচাই করতে এইসব ধাপ অনুসরণ করুন:

  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-এর মতো অস্বচ্ছ ১০-বিট ফর্ম্যাট সাপোর্ট করে, কিন্তু আলফা সাপোর্ট করার জন্য GPU কম্পোজিশনকে RGBA8888-এর মতো ৮-বিট ফর্ম্যাটে লিখতে হয়।

  • DPU যদি GPU-এর থেকে আলাদা প্রিসিশনে কাজ করে, তাহলে কোয়ান্টাইজেশন পার্থক্যের কারণে রঙের সামান্য পরিবর্তন হয়।

এইসব সমস্যার প্রতিটিই অন্তর্নিহিত হার্ডওয়্যারের আপেক্ষিক নির্ভুলতা সংক্রান্ত পার্থক্যের সাথে সম্পর্কিত। সাধারণত, কম প্রিসিশন পাথে ডিদারিং স্টেপ আছে কিনা তা নিশ্চিত করা হয়, এর ফলে প্রিসিশনের পার্থক্যগুলি মানুষের পক্ষে কম বোঝা যায়।