এই পৃষ্ঠাটি Cloud Translation API অনুবাদ করেছে।

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

অ্যান্ড্রয়েড 13 libtonemap নামে একটি বিক্রেতা-কনফিগারযোগ্য স্ট্যাটিক লাইব্রেরি প্রবর্তন করে, যা টোন ম্যাপিং অপারেশনগুলিকে সংজ্ঞায়িত করে এবং সারফেসফ্লিংগার প্রক্রিয়া এবং হার্ডওয়্যার কম্পোজার (HWC) বাস্তবায়নের সাথে ভাগ করা হয়। এই বৈশিষ্ট্যটি OEM-গুলিকে ফ্রেমওয়ার্ক এবং বিক্রেতাদের মধ্যে তাদের ডিসপ্লে টোন ম্যাপিং অ্যালগরিদমগুলিকে সংজ্ঞায়িত করতে এবং ভাগ করতে সক্ষম করে, টোন ম্যাপিংয়ের অমিল কমিয়ে দেয়৷

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

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

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

libtonemap লাইব্রেরিতে CPU-ব্যাকড ইমপ্লিমেন্টেশন এবং SkSL শেডার রয়েছে, যা GPU-ব্যাকএন্ড কম্পোজিশনের জন্য SurfaceFlinger এবং HWC দ্বারা টোন ম্যাপিং লুক-আপ টেবিল (LUT) তৈরির জন্য প্লাগ ইন করা যেতে পারে। 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-to-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 কম্পোজিশনের দ্বারা ব্যবহৃত থেকে ভিন্ন হতে পারে, তাই রেফারেন্স বাস্তবায়ন ব্যবহার করা কিছু পরিস্থিতিতে যেমন ঘূর্ণন অ্যানিমেশনে ঝাঁকুনি সৃষ্টি করতে পারে। কাস্টমাইজেশন এই ধরনের বিক্রেতা-নির্দিষ্ট ছবির গুণমানের সমস্যা সমাধান করতে পারে।

OEMগুলিকে তাদের নিজস্ব ToneMapper সাবক্লাস সংজ্ঞায়িত করতে libtonemap বাস্তবায়নকে ওভাররাইড করার জন্য দৃঢ়ভাবে উত্সাহিত করা হয়, যা getToneMapper() দ্বারা ফেরত দেওয়া হয়। বাস্তবায়ন কাস্টমাইজ করার সময়, অংশীদারদের নিম্নলিখিতগুলির মধ্যে একটি করার আশা করা হয়:

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

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

বৈধতা

আপনার বাস্তবায়ন যাচাই করতে এই পদক্ষেপগুলি অনুসরণ করুন:

আপনার ডিসপ্লে সিস্টেম যেমন HLG, HDR10, HDR10+, বা DolbyVision সমর্থন করে এমন যেকোনো HDR স্ট্যান্ডার্ডের স্ক্রিনে HDR ভিডিও চালান।
কোন ব্যবহারকারীর বোধগম্য ফ্লিকার নেই তা নিশ্চিত করতে GPU কম্পোজিশন টগল করুন।
GPU কম্পোজিশন টগল করতে নিম্নলিখিত adb কমান্ড ব্যবহার করুন:
```
adb shell service call SurfaceFlinger 1008 i32 <0 to enable HWC composition,
1 to force GPU composition>
```

সাধারণ সমস্যা

এই বাস্তবায়নের সাথে নিম্নলিখিত সমস্যাগুলি ঘটতে পারে:

ব্যান্ডিং হয় যখন GPU কম্পোজিশন দ্বারা ব্যবহৃত রেন্ডার টার্গেট HDR কন্টেন্টের জন্য সাধারণ মানের চেয়ে কম নির্ভুলতার হয়। উদাহরণস্বরূপ, ব্যান্ডিং ঘটতে পারে যখন একটি HWC বাস্তবায়ন HDR-এর জন্য অস্বচ্ছ 10-বিট ফর্ম্যাটগুলিকে সমর্থন করে যেমন RGBA1010102 বা P010, কিন্তু GPU রচনাটি আলফা সমর্থন করার জন্য RGBA8888-এর মতো একটি 8-বিট ফর্ম্যাটে লেখার প্রয়োজন৷
ডিপিইউ যদি জিপিইউ-এর চেয়ে ভিন্ন নির্ভুলতায় কাজ করে তবে পরিমাপকরণের পার্থক্যের কারণে একটি সূক্ষ্ম রঙের পরিবর্তন ঘটে।

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