Android 13 memperkenalkan pustaka statis yang dapat dikonfigurasi vendor bernama libtonemap
, yang mendefinisikan operasi pemetaan nada dan dibagikan dengan proses SurfaceFlinger dan implementasi Hardware Composer (HWC). Fitur ini memungkinkan OEM untuk menentukan dan membagikan algoritme pemetaan nada tampilan mereka antara kerangka kerja dan vendor, sehingga mengurangi ketidakcocokan dalam pemetaan nada.
Sebelum Android 13, operasi pemetaan nada khusus tampilan tidak dibagikan antara HWC, SurfaceFlinger, dan aplikasi. Bergantung pada jalur rendering, untuk konten HDR, hal ini menyebabkan ketidaksesuaian dalam kualitas gambar, yang mana konten HDR dipetakan nadanya ke ruang keluaran dengan cara yang berbeda. Hal ini terlihat jelas dalam skenario seperti rotasi layar, di mana strategi komposisi berubah antara GPU dan DPU, dan perbedaan perilaku rendering antara TextureView dan SurfaceView.
Halaman ini menjelaskan antarmuka, penyesuaian, dan detail validasi perpustakaan libtonemap
.
Antarmuka ke perpustakaan pemetaan nada
Pustaka libtonemap
berisi implementasi yang didukung CPU dan shader SkSL, yang dapat dipasang oleh SurfaceFlinger untuk komposisi backend GPU dan oleh HWC untuk menghasilkan tabel pencarian pemetaan nada (LUT). Titik masuk ke libtonemap
adalah android::tonemap::getToneMapper()
, yang mengembalikan objek yang mengimplementasikan antarmuka ToneMapper
.
Antarmuka ToneMapper
mendukung kemampuan berikut:
Hasilkan LUT pemetaan nada
Antarmuka
ToneMapper::lookupTonemapGain
adalah implementasi CPU dari shader yang ditentukan dalamlibtonemap_LookupTonemapGain()
. Ini digunakan oleh pengujian unit dalam kerangka kerja, dan dapat digunakan oleh mitra untuk mendapatkan bantuan dalam menghasilkan LUT pemetaan nada di dalam pipa warna mereka.libtonemap_LookupTonemapGain()
mengambil nilai warna dalam ruang linier absolut yang tidak dinormalisasi, baik dalam RGB linier maupun dalam XYZ, dan mengembalikan float yang menjelaskan berapa banyak warna input yang harus dikalikan dalam ruang linier.Hasilkan shader SkSL
Antarmuka
ToneMapper::generateTonemapGainShaderSkSL()
mengembalikan string shader SkSL, berdasarkan ruang data sumber dan tujuan. Shader SkSL dicolokkan ke implementasi Skia untukRenderEngine
, komponen pengomposisian yang dipercepat GPU untuk SurfaceFlinger. Shader juga dicolokkan kelibhwui
, sehingga pemetaan nada HDR-ke-SDR dapat dilakukan secara efisien untukTextureView
. Karena string yang dihasilkan dimasukkan ke dalam shader SkSL lain yang digunakan oleh Skia, shader harus mematuhi aturan berikut:- String shader harus memiliki titik masuk dengan tanda tangan
float libtonemap_LookupTonemapGain(vec3 linearRGB, vec3 xyz)
, denganlinearRGB
adalah nilai nit absolut piksel RGB dalam ruang linier danxyz
adalahlinearRGB
yang diubah menjadi XYZ. - Metode pembantu apa pun yang digunakan oleh string shader harus diawali dengan string
libtonemap_
sehingga definisi framework shader tidak bertentangan. Demikian pula, seragam masukan harus diawali denganin_libtonemap_
.
- String shader harus memiliki titik masuk dengan tanda tangan
Hasilkan seragam SkSL
Antarmuka
ToneMapper::generateShaderSkSLUniforms()
mengembalikan yang berikut ini, denganstruct
metadata yang menjelaskan metadata dari standar HDR dan kondisi tampilan yang berbeda:Daftar seragam yang terikat oleh shader SkSL.
Nilai seragam
in_libtonemap_displayMaxLuminance
danin_libtonemap_inputMaxLuminance
. Nilai-nilai ini digunakan oleh framework shader saat menskalakan masukan kelibtonemap
, dan menormalkan keluaran sebagaimana berlaku.
Saat ini proses pembuatan seragam bersifat agnostik terhadap ruang data input dan output.
Kustomisasi
Implementasi referensi perpustakaan libtonemap
memberikan hasil yang dapat diterima. Namun, karena algoritma pemetaan nada yang digunakan oleh komposisi GPU dapat berbeda dari yang digunakan oleh komposisi DPU, penggunaan implementasi referensi dapat menyebabkan kedipan dalam beberapa skenario seperti animasi rotasi. Kustomisasi dapat menyelesaikan masalah kualitas gambar khusus vendor tersebut.
OEM sangat dianjurkan untuk mengganti penerapan libtonemap
untuk menentukan subkelas ToneMapper
mereka sendiri, yang dikembalikan oleh getToneMapper()
. Saat menyesuaikan penerapannya, mitra diharapkan melakukan salah satu hal berikut:
- Ubah implementasi
libtonemap
secara langsung. - Tentukan perpustakaan statis mereka sendiri, kompilasi perpustakaan sebagai perpustakaan mandiri, dan ganti file
.a
perpustakaanlibtonemap
dengan yang dihasilkan dari perpustakaan khusus mereka.
Vendor tidak perlu mengubah kode kernel apa pun, tetapi beberapa vendor harus mengomunikasikan detail tentang algoritma pemetaan nada DPU untuk implementasi yang tepat.
Validasi
Ikuti langkah-langkah berikut untuk memvalidasi penerapan Anda:
Putar video HDR di layar standar HDR apa pun yang didukung sistem tampilan Anda, seperti HLG, HDR10, HDR10+, atau DolbyVision.
Alihkan komposisi GPU untuk memastikan tidak ada kedipan yang terlihat oleh pengguna.
Gunakan perintah
adb
berikut untuk mengganti 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 terjadi ketika target render yang digunakan oleh komposisi GPU memiliki presisi yang lebih rendah dibandingkan nilai tipikal untuk konten HDR. Misalnya, banding dapat terjadi ketika implementasi HWC mendukung format 10-bit buram untuk HDR seperti RGBA1010102 atau P010, namun mengharuskan komposisi GPU menulis ke format 8-bit seperti RGBA8888 untuk mendukung alfa.
Pergeseran warna yang halus disebabkan oleh perbedaan kuantisasi jika DPU beroperasi pada presisi yang berbeda dari GPU.
Masing-masing masalah ini terkait dengan perbedaan presisi relatif dari perangkat keras yang mendasarinya. Solusi umumnya adalah dengan memastikan bahwa ada langkah ragu-ragu di jalur dengan presisi lebih rendah, sehingga perbedaan presisi menjadi kurang terlihat oleh manusia.