Mulai 27 Maret 2025, sebaiknya gunakan android-latest-release, bukan aosp-main, untuk mem-build dan berkontribusi pada AOSP. Untuk mengetahui informasi selengkapnya, lihat Perubahan pada AOSP.

Halaman ini diterjemahkan oleh Cloud Translation API.

Pemetaan Nada HDR Luminance ke Rentang yang kompatibel dengan SDR

Android 13 memperkenalkan library statis yang dapat dikonfigurasi vendor yang disebut libtonemap, yang menentukan operasi pemetaan tone dan dibagikan dengan proses SurfaceFlinger dan implementasi Hardware Composer (HWC). Fitur ini memungkinkan OEM menentukan dan membagikan algoritma pemetaan tone tampilan antara framework dan vendor, sehingga mengurangi ketidakcocokan dalam pemetaan tone.

Sebelum Android 13, operasi pemetaan tone khusus layar tidak dibagikan antara HWC, SurfaceFlinger, dan aplikasi. Bergantung pada jalur rendering, untuk konten HDR, hal ini menyebabkan ketidakcocokan kualitas gambar, dengan konten HDR dipetakan tone ke ruang output dengan cara yang berbeda. Hal ini dapat dilihat dalam skenario seperti rotasi layar, saat strategi komposisi berubah antara GPU dan DPU, serta dalam perbedaan perilaku rendering antara TextureView dan SurfaceView.

Halaman ini menjelaskan antarmuka, penyesuaian, dan detail validasi library libtonemap.

Antarmuka ke library pemetaan tone

Library libtonemap berisi implementasi yang didukung CPU dan shader SkSL, yang dapat dipasang oleh SurfaceFlinger untuk komposisi backend GPU dan oleh HWC untuk membuat tabel pencarian (LUT) pemetaan tone. Titik entri ke libtonemap adalah android::tonemap::getToneMapper(), yang menampilkan objek yang menerapkan antarmuka ToneMapper.

Antarmuka ToneMapper mendukung kemampuan berikut:

Membuat LUT tone mapping

Antarmuka ToneMapper::lookupTonemapGain adalah implementasi CPU dari shader yang ditentukan di libtonemap_LookupTonemapGain(). Hal ini digunakan oleh pengujian unit dalam framework, dan dapat digunakan oleh partner untuk mendapatkan bantuan dalam membuat LUT tone-mapping di dalam pipeline warna mereka.

libtonemap_LookupTonemapGain() mengambil nilai warna dalam ruang linear absolut, yang tidak dinormalisasi, baik dalam RGB linear maupun XYZ, dan menampilkan float yang menjelaskan jumlah perkalian warna input dalam ruang linear.
Membuat shader SkSL

Antarmuka ToneMapper::generateTonemapGainShaderSkSL() menampilkan string shader SkSL, dengan ruang data sumber dan tujuan. Shader SkSL dipasang ke implementasi Skia untuk RenderEngine, komponen komposisi yang dipercepat GPU untuk SurfaceFlinger. Shader juga dihubungkan ke libhwui, sehingga pemetaan tone HDR ke SDR dapat dilakukan secara efisien untuk TextureView. Karena string yang dihasilkan digabungkan ke shader SkSL lain yang digunakan oleh Skia, shader harus mematuhi aturan berikut:
- String shader harus memiliki titik entri dengan tanda tangan float libtonemap_LookupTonemapGain(vec3 linearRGB, vec3 xyz), dengan linearRGB adalah nilai nits absolut piksel RGB dalam ruang linear dan xyz adalah linearRGB yang dikonversi menjadi XYZ.
- Setiap metode bantuan yang digunakan oleh string shader harus diawali dengan string libtonemap_ sehingga definisi shader framework tidak bertentangan. Demikian pula, seragam input harus diawali dengan in_libtonemap_.
Membuat seragam SkSL

Antarmuka ToneMapper::generateShaderSkSLUniforms() menampilkan hal berikut, dengan struct metadata yang menjelaskan metadata dari berbagai standar HDR dan kondisi tampilan:
- Daftar seragam yang terikat oleh shader SkSL.
- Nilai seragam in_libtonemap_displayMaxLuminance dan in_libtonemap_inputMaxLuminance. Nilai ini digunakan oleh shader framework saat menskalakan input ke libtonemap, dan menormalisasi output sesuai kebutuhan.
Saat ini, proses pembuatan seragam tidak bergantung pada ruang data input dan output.

Penyesuaian

Implementasi referensi library libtonemap menghasilkan hasil yang dapat diterima. Namun, karena algoritma pemetaan tone yang digunakan oleh komposisi GPU dapat berbeda dengan yang digunakan oleh komposisi DPU, penggunaan implementasi referensi dapat menyebabkan kelip dalam beberapa skenario seperti animasi rotasi. Penyesuaian dapat menyelesaikan masalah kualitas gambar khusus vendor tersebut.

OEM sangat disarankan untuk mengganti implementasi libtonemap guna menentukan subclass ToneMapper mereka sendiri, yang ditampilkan oleh getToneMapper(). Saat menyesuaikan penerapan, partner diharapkan melakukan salah satu hal berikut:

Ubah penerapan libtonemap secara langsung.
Menentukan library statis mereka sendiri, mengompilasi library sebagai mandiri, dan mengganti file .a library libtonemap dengan file yang dihasilkan dari library kustom mereka.

Vendor tidak perlu mengubah kode kernel apa pun, tetapi beberapa vendor harus menyampaikan detail tentang algoritma tone-mapping DPU untuk penerapan yang tepat.

Validasi

Ikuti langkah-langkah berikut untuk memvalidasi penerapan Anda:

Memutar video HDR di layar dengan standar HDR apa pun yang didukung sistem tampilan, seperti HLG, HDR10, HDR10+, atau DolbyVision.
Alihkan komposisi GPU untuk memastikan tidak ada kedipan yang terlihat oleh pengguna.

Gunakan perintah adb berikut untuk mengalihkan komposisi GPU:
```
adb shell service call SurfaceFlinger 1008 i32 <0 to enable HWC composition,
1 to force GPU composition>
```

Masalah umum

Masalah berikut dapat terjadi dengan penerapan ini:

Banding disebabkan saat target render yang digunakan oleh komposisi GPU memiliki presisi yang lebih rendah daripada nilai standar untuk konten HDR. Misalnya, banding dapat terjadi saat implementasi HWC mendukung format 10-bit buram untuk HDR seperti RGBA1010102 atau P010, tetapi mengharuskan komposisi GPU menulis ke format 8-bit seperti RGBA8888 untuk mendukung alfa.
Pergeseran warna yang halus disebabkan oleh perbedaan kuantisasi jika DPU beroperasi dengan presisi yang berbeda dari GPU.

Setiap masalah ini terkait dengan perbedaan presisi relatif hardware yang mendasarinya. Solusi umum adalah memastikan bahwa ada langkah dithering di jalur presisi yang lebih rendah, sehingga perbedaan presisi tidak terlalu terlihat oleh manusia.