অ্যান্ড্রয়েড ১৩-এ libtonemap নামে একটি ভেন্ডর-কনফিগারযোগ্য স্ট্যাটিক লাইব্রেরি চালু করা হয়েছে, যা টোন ম্যাপিং অপারেশনগুলো সংজ্ঞায়িত করে এবং সারফেসফ্লিঙ্গার প্রসেস ও হার্ডওয়্যার কম্পোজার (HWC) ইমপ্লিমেন্টেশনের সাথে শেয়ার করা হয়। এই ফিচারটি OEM-দেরকে ফ্রেমওয়ার্ক এবং ভেন্ডরদের মধ্যে তাদের ডিসপ্লে টোন ম্যাপিং অ্যালগরিদম সংজ্ঞায়িত ও শেয়ার করার সুযোগ দেয়, যা টোন ম্যাপিংয়ের অমিল কমিয়ে আনে।
অ্যান্ড্রয়েড ১৩-এর আগে, ডিসপ্লে-নির্দিষ্ট টোন ম্যাপিং অপারেশনগুলো HWC, SurfaceFlinger এবং অ্যাপগুলোর মধ্যে শেয়ার করা হতো না। রেন্ডারিং পাথের ওপর নির্ভর করে, HDR কন্টেন্টের ক্ষেত্রে এর ফলে ছবির গুণমানে অমিল দেখা দিত, যেখানে HDR কন্টেন্টকে একটি আউটপুট স্পেসে ভিন্ন ভিন্ন উপায়ে টোন ম্যাপ করা হতো। এটি স্ক্রিন রোটেশনের মতো পরিস্থিতিতে লক্ষণীয় ছিল, যেখানে GPU এবং DPU-এর মধ্যে কম্পোজিশন স্ট্র্যাটেজি পরিবর্তিত হয়, এবং TextureView ও SurfaceView-এর মধ্যে রেন্ডারিং আচরণের ভিন্নতার ক্ষেত্রেও এটি বোঝা যেত।
এই পৃষ্ঠায় libtonemap লাইব্রেরির ইন্টারফেস, কাস্টমাইজেশন এবং ভ্যালিডেশন সংক্রান্ত বিস্তারিত তথ্য বর্ণনা করা হয়েছে।
টোন ম্যাপিং লাইব্রেরির ইন্টারফেস
libtonemap লাইব্রেরিতে সিপিইউ-সমর্থিত ইমপ্লিমেন্টেশন এবং SkSL শেডার রয়েছে, যা SurfaceFlinger দ্বারা জিপিইউ-ব্যাকএন্ড কম্পোজিশনের জন্য এবং HWC দ্বারা একটি টোন ম্যাপিং লুক-আপ টেবিল (LUT) তৈরির জন্য প্লাগ-ইন করা যায়। libtonemap এর এন্ট্রি পয়েন্ট হলো android::tonemap::getToneMapper() , যা ToneMapper ইন্টারফেস ইমপ্লিমেন্ট করে এমন একটি অবজেক্ট রিটার্ন করে।
ToneMapper ইন্টারফেস নিম্নলিখিত ক্ষমতাগুলো সমর্থন করে:
একটি টোন-ম্যাপিং LUT তৈরি করুন
ToneMapper::lookupTonemapGainইন্টারফেসটি হলোlibtonemap_LookupTonemapGain()-এ সংজ্ঞায়িত শেডারটির একটি সিপিইউ ইমপ্লিমেন্টেশন। এটি ফ্রেমওয়ার্কের ইউনিট টেস্টগুলোতে ব্যবহৃত হয় এবং পার্টনাররা তাদের কালার পাইপলাইনের মধ্যে একটি টোন-ম্যাপিং LUT তৈরি করার জন্য সহায়তার উদ্দেশ্যে এটি ব্যবহার করতে পারেন।libtonemap_LookupTonemapGain()পরম, অপরিবর্তিত রৈখিক স্পেসে (linear RGB এবং XYZ উভয় এককে) রঙের মান গ্রহণ করে এবং রৈখিক স্পেসে ইনপুট রঙগুলোকে কতটুকু গুণ করতে হবে তা বর্ণনা করে একটি ফ্লোট মান ফেরত দেয়।একটি SkSL শেডার তৈরি করুন
ToneMapper::generateTonemapGainShaderSkSL()ইন্টারফেসটি একটি সোর্স এবং ডেস্টিনেশন ডেটাস্পেসের উপর ভিত্তি করে একটি SkSL শেডার স্ট্রিং রিটার্ন করে। SkSL শেডারটিRenderEngineজন্য Skia ইমপ্লিমেন্টেশনে প্লাগ-ইন করা থাকে, যা SurfaceFlinger-এর GPU-অ্যাক্সিলারেটেড কম্পোজিটিং কম্পোনেন্ট। শেডারটিlibhwuiতেও প্লাগ-ইন করা থাকে, যাতেTextureViewজন্য HDR-to-SDR টোন ম্যাপিং দক্ষতার সাথে করা যায়। যেহেতু জেনারেট করা স্ট্রিংটি Skia দ্বারা ব্যবহৃত অন্যান্য SkSL শেডারগুলিতে ইন-লাইন করা হয়, তাই শেডারটিকে অবশ্যই নিম্নলিখিত নিয়মগুলি মেনে চলতে হবে:- শেডার স্ট্রিং-এর একটি এন্ট্রি পয়েন্ট অবশ্যই `
float libtonemap_LookupTonemapGain(vec3 linearRGB, vec3 xyz)` সিগনেচারের হতে হবে, যেখানেlinearRGBহলো লিনিয়ার স্পেসে RGB পিক্সেলের অ্যাবসোলিউট নিট-এর মান এবংxyzহলোlinearRGB`XYZ`-এ রূপান্তর করার পরের মান। - শেডার স্ট্রিং দ্বারা ব্যবহৃত যেকোনো হেল্পার মেথডের শুরুতে অবশ্যই
libtonemap_স্ট্রিংটি যুক্ত করতে হবে, যাতে ফ্রেমওয়ার্ক শেডার ডেফিনিশনগুলোর মধ্যে কোনো সংঘাত না হয়। একইভাবে, ইনপুট ইউনিফর্মগুলোর শুরুতেওin_libtonemap_যুক্ত করতে হবে।
- শেডার স্ট্রিং-এর একটি এন্ট্রি পয়েন্ট অবশ্যই `
SkSL ইউনিফর্ম তৈরি করুন
ToneMapper::generateShaderSkSLUniforms()ইন্টারফেসটি, বিভিন্ন HDR স্ট্যান্ডার্ড এবং ডিসপ্লে কন্ডিশন থেকে প্রাপ্ত মেটাডেটা বর্ণনা করে এমন একটি মেটাডেটাstructপেলে, নিম্নলিখিত আউটপুটটি প্রদান করে:SkSL শেডার দ্বারা আবদ্ধ ইউনিফর্মগুলির একটি তালিকা।
in_libtonemap_displayMaxLuminanceএবংin_libtonemap_inputMaxLuminanceহলো অভিন্ন মান। এই মানগুলো ফ্রেমওয়ার্ক শেডার দ্বারা ব্যবহৃত হয়, যখনlibtonemapএ ইনপুট স্কেল করা হয় এবং প্রযোজ্য ক্ষেত্রে আউটপুট নর্মালাইজ করা হয়।
বর্তমানে ইউনিফর্ম তৈরির প্রক্রিয়াটি ইনপুট এবং আউটপুট ডেটাস্পেসের ওপর নির্ভরশীল নয়।
কাস্টমাইজেশন
libtonemap লাইব্রেরির রেফারেন্স ইমপ্লিমেন্টেশনটি গ্রহণযোগ্য ফলাফল দেয়। তবে, যেহেতু GPU কম্পোজিশনে ব্যবহৃত টোন ম্যাপিং অ্যালগরিদমটি DPU কম্পোজিশনে ব্যবহৃত অ্যালগরিদম থেকে ভিন্ন হতে পারে, তাই রেফারেন্স ইমপ্লিমেন্টেশনটি ব্যবহার করলে কিছু ক্ষেত্রে, যেমন রোটেশন অ্যানিমেশনে, ফ্লিকার দেখা দিতে পারে। কাস্টমাইজেশনের মাধ্যমে এই ধরনের ভেন্ডর-নির্দিষ্ট ছবির মানের সমস্যা সমাধান করা সম্ভব।
OEM-দেরকে libtonemap এর ইমপ্লিমেন্টেশন ওভাররাইড করে তাদের নিজস্ব ToneMapper সাবক্লাস সংজ্ঞায়িত করার জন্য জোরালোভাবে উৎসাহিত করা হচ্ছে, যা getToneMapper() দ্বারা রিটার্ন করা হয়। ইমপ্লিমেন্টেশন কাস্টমাইজ করার সময়, পার্টনারদের নিম্নলিখিত কাজগুলোর মধ্যে একটি করতে হবে বলে আশা করা হচ্ছে:
- সরাসরি
libtonemapএর বাস্তবায়ন পরিবর্তন করুন। - তারা তাদের নিজস্ব স্ট্যাটিক লাইব্রেরি সংজ্ঞায়িত করবে, লাইব্রেরিটিকে একটি স্বতন্ত্র প্রোগ্রাম হিসেবে কম্পাইল করবে এবং তাদের কাস্টম লাইব্রেরি থেকে তৈরি করা ফাইলটি দিয়ে
libtonemapলাইব্রেরির.aফাইলটি প্রতিস্থাপন করবে।
বিক্রেতাদের কোনো কার্নেল কোড পরিবর্তন করার প্রয়োজন নেই, কিন্তু সঠিক বাস্তবায়নের জন্য একাধিক বিক্রেতাকে অবশ্যই ডিপিইউ টোন-ম্যাপিং অ্যালগরিদমগুলোর বিস্তারিত তথ্য আদান-প্রদান করতে হবে।
বৈধতা
আপনার বাস্তবায়ন যাচাই করতে এই ধাপগুলো অনুসরণ করুন:
আপনার ডিসপ্লে সিস্টেম যে কোনো HDR স্ট্যান্ডার্ড সমর্থন করে , যেমন HLG, HDR10, HDR10+, বা DolbyVision, সেই অনুযায়ী HDR ভিডিও স্ক্রিনে চালান।
ব্যবহারকারীর চোখে পড়ার মতো কোনো ফ্লিকার যাতে না থাকে, তা নিশ্চিত করতে জিপিইউ কম্পোজিশন টগল করুন।
জিপিইউ কম্পোজিশন টগল করতে নিম্নলিখিত
adbকমান্ডটি ব্যবহার করুন:adb shell service call SurfaceFlinger 1008 i32 <0 to enable HWC composition, 1 to force GPU composition>
সাধারণ সমস্যা
এই বাস্তবায়নের ফলে নিম্নলিখিত সমস্যাগুলো দেখা দিতে পারে:
জিপিইউ কম্পোজিশন দ্বারা ব্যবহৃত রেন্ডার টার্গেট যখন এইচডিআর কন্টেন্টের সাধারণ মানের চেয়ে কম প্রিসিশনের হয়, তখন ব্যান্ডিং দেখা দেয়। উদাহরণস্বরূপ, ব্যান্ডিং তখন হতে পারে যখন কোনো এইচডব্লিউসি ইমপ্লিমেন্টেশন এইচডিআর-এর জন্য RGBA1010102 বা P010-এর মতো অপেক ১০-বিট ফরম্যাট সমর্থন করে, কিন্তু আলফা সমর্থনের জন্য জিপিইউ কম্পোজিশনকে RGBA8888-এর মতো ৮-বিট ফরম্যাটে লিখতে হয়।
ডিপিইউ যদি জিপিইউ-এর চেয়ে ভিন্ন প্রিসিশনে কাজ করে, তবে কোয়ান্টাইজেশন পার্থক্যের কারণে রঙের একটি সূক্ষ্ম পরিবর্তন ঘটে।
এই সমস্যাগুলোর প্রত্যেকটিই অন্তর্নিহিত হার্ডওয়্যারের আপেক্ষিক নির্ভুলতার পার্থক্যের সাথে সম্পর্কিত। এর একটি সাধারণ সমাধান হলো কম নির্ভুলতার পাথগুলোতে একটি ডিথারিং স্টেপ নিশ্চিত করা, যা নির্ভুলতার যেকোনো পার্থক্যকে মানুষের কাছে কম বোধগম্য করে তোলে।