این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

نگاشت HDR Luminance به محدوده سازگار با SDR

Android 13 یک کتابخانه استاتیک قابل تنظیم توسط فروشنده به نام libtonemap را معرفی می‌کند که عملیات نگاشت آهنگ را تعریف می‌کند و با فرآیند SurfaceFlinger و اجرای Hardware Composer (HWC) به اشتراک گذاشته می‌شود. این ویژگی OEM ها را قادر می سازد تا الگوریتم های نگاشت تن صفحه نمایش خود را بین چارچوب و فروشندگان تعریف و به اشتراک بگذارند و عدم تطابق در نگاشت آهنگ را کاهش دهد.

قبل از Android 13، عملیات نگاشت آهنگ مخصوص نمایشگر بین HWC، SurfaceFlinger و برنامه ها به اشتراک گذاشته نمی شد. بسته به مسیر رندر، برای محتوای HDR، این منجر به عدم تطابق در کیفیت تصویر می‌شود، جایی که محتوای HDR به روش‌های مختلف به فضای خروجی نگاشت می‌شود. این در سناریوهایی مانند چرخش صفحه، که در آن استراتژی ترکیب بندی بین GPU و DPU تغییر می کند، و در تفاوت در رفتار رندر بین TextureView و SurfaceView قابل درک بود.

این صفحه جزئیات رابط، سفارشی سازی و اعتبار سنجی کتابخانه libtonemap را شرح می دهد.

رابط به کتابخانه نقشه برداری تن

کتابخانه libtonemap شامل پیاده‌سازی‌های مبتنی بر CPU و سایه‌زن‌های SkSL است که می‌توانند توسط 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 به پیاده‌سازی Skia برای RenderEngine ، مولفه ترکیب‌کننده با شتاب GPU برای SurfaceFlinger وصل شده است. سایه زن همچنین به libhwui وصل شده است، به طوری که نگاشت تون HDR به SDR می تواند به طور موثر برای TextureView انجام شود. از آنجایی که رشته تولید شده در سایر سایه زن های SkSL مورد استفاده Skia قرار می گیرد، شیدر باید قوانین زیر را رعایت کند:
- رشته سایه زن باید یک نقطه ورودی با امضای float libtonemap_LookupTonemapGain(vec3 linearRGB, vec3 xyz) داشته باشد، جایی که linearRGB مقدار nit مطلق پیکسل های RGB در فضای خطی است و xyz linearRGB است که به XYZ تبدیل می شود.
- هر روش کمکی که توسط رشته سایه زن استفاده می شود باید با پیشوند رشته libtonemap_ باشد تا تعاریف سایه زن فریمورک با هم تضاد نداشته باشند. به طور مشابه، یونیفرم های ورودی باید با in_libtonemap_ پیشوند شوند.
یونیفرم های SkSL را تولید کنید
رابط ToneMapper::generateShaderSkSLUniforms() موارد زیر را با توجه به struct ابرداده ای که متادیتا را از استانداردهای مختلف HDR و شرایط نمایش توصیف می کند، برمی گرداند:
- لیستی از یونیفرم هایی که توسط سایه زن SkSL محدود شده اند.
- مقادیر یکسان in_libtonemap_displayMaxLuminance و in_libtonemap_inputMaxLuminance . این مقادیر توسط سایه بان های فریم ورک هنگام مقیاس بندی ورودی در libtonemap و عادی سازی خروجی در صورت لزوم استفاده می شود.
در حال حاضر فرآیند تولید یونیفرم نسبت به فضای داده ورودی و خروجی آگنوستیک است.

سفارشی سازی

پیاده سازی مرجع کتابخانه libtonemap نتایج قابل قبولی را تولید می کند. با این حال، از آنجا که الگوریتم نگاشت تن مورد استفاده توسط ترکیب GPU می‌تواند با الگوریتم مورد استفاده در ترکیب DPU متفاوت باشد، استفاده از پیاده‌سازی مرجع می‌تواند در برخی سناریوها مانند انیمیشن چرخش باعث سوسو زدن شود. سفارشی‌سازی می‌تواند چنین مشکلات کیفیت تصویر خاص فروشنده را حل کند.

OEM ها به شدت تشویق می شوند تا اجرای libtonemap را برای تعریف زیرکلاس ToneMapper خود که توسط getToneMapper() برگردانده می شود، نادیده بگیرند. هنگام سفارشی سازی پیاده سازی، از شرکا انتظار می رود یکی از موارد زیر را انجام دهند:

اجرای libtonemap را مستقیماً تغییر دهید.
کتابخانه استاتیک خود را تعریف کنید، کتابخانه را به صورت مستقل کامپایل کنید و فایل .a کتابخانه libtonemap را با فایلی که از کتابخانه سفارشی آنها تولید شده است جایگزین کنید.

فروشندگان نیازی به اصلاح هیچ کد هسته ای ندارند، اما چندین فروشنده باید جزئیات الگوریتم های نگاشت صدای DPU را برای پیاده سازی مناسب به اشتراک بگذارند.

اعتبار سنجی

این مراحل را برای تایید اجرای خود دنبال کنید:

ویدیوهای HDR را روی صفحه نمایش با استانداردهای HDR که سیستم نمایشگر شما پشتیبانی می کند ، مانند HLG، HDR10، HDR10+ یا DolbyVision پخش کنید.
ترکیب 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 کار کند، تغییر رنگ ظریف به دلیل تفاوت های کوانتیزاسیون ایجاد می شود.

هر یک از این مسائل مربوط به تفاوت های دقت نسبی سخت افزار زیرین است. یک راه حل معمولی این است که اطمینان حاصل شود که در مسیرهای با دقت پایین تر، یک گام پراکنده وجود دارد که باعث می شود تفاوت های دقیق کمتر قابل درک توسط انسان باشد.