Android 13 introduce una libreria statica configurabile dal fornitore chiamata libtonemap, che definisce le operazioni di mappatura tonale ed è condivisa con il processo SurfaceFlinger e le implementazioni di Hardware Composer (HWC).
Questa funzionalità consente agli OEM di definire e condividere i propri algoritmi di mappatura tonale del display tra il framework e i fornitori, riducendo la mancata corrispondenza nella mappatura tonale.
Prima di Android 13, le operazioni di mappatura dei toni specifiche del display non venivano condivise tra HWC, SurfaceFlinger e le app. A seconda del percorso di rendering, per i contenuti HDR, ciò ha portato a mancate corrispondenze nella qualità dell'immagine, in cui i contenuti HDR sono stati mappati in uno spazio di output in modi diversi. Questo era percepibile in scenari come la rotazione dello schermo, in cui la strategia di composizione cambia tra la GPU e la DPU, e nelle differenze nel comportamento di rendering tra TextureView e SurfaceView.
Questa pagina descrive l'interfaccia, la personalizzazione e i dettagli di convalida della libreria libtonemap.
Interfaccia alla libreria di mappatura tonale
La libtonemap
libreria contiene implementazioni basate sulla CPU e shader SkSL, che possono essere
collegati da SurfaceFlinger per la composizione del backend della GPU e da HWC per
generare una tabella di ricerca della mappatura tonale (LUT). Il punto di ingresso di libtonemap
è android::tonemap::getToneMapper(), che restituisce un oggetto che
implementa l'interfaccia ToneMapper.
L'interfaccia ToneMapper supporta le seguenti funzionalità:
Genera una LUT di mappatura dei toni
L'interfaccia
ToneMapper::lookupTonemapGainè un'implementazione della CPU dello shader definito inlibtonemap_LookupTonemapGain(). Viene utilizzata dai test delle unità nel framework e può essere utilizzata dai partner per assistenza nella generazione di una LUT di mappatura dei toni all'interno della pipeline dei colori.libtonemap_LookupTonemapGain()accetta valori di colore in uno spazio lineare assoluto e non normalizzato, sia in RGB lineare sia in XYZ, e restituisce un float che descrive di quanto moltiplicare i colori di input nello spazio lineare.Genera uno shader SkSL
L'interfaccia
ToneMapper::generateTonemapGainShaderSkSL()restituisce una stringa dello shader SkSL, dato uno spazio dati di origine e di destinazione. Lo shader SkSL è collegato all'implementazione Skia perRenderEngine, il componente di composizione con accelerazione GPU per SurfaceFlinger. Lo shader è collegato anche alibhwui, in modo che la mappatura tonale da HDR a SDR possa essere eseguita in modo efficiente perTextureView. Poiché la stringa generata è in linea con altri shader SkSL utilizzati da Skia, lo shader deve rispettare le seguenti regole:- La stringa dello shader deve avere un punto di ingresso con la
float libtonemap_LookupTonemapGain(vec3 linearRGB, vec3 xyz)firma, dovelinearRGBè il valore dei nit assoluti dei pixel RGB nello spazio lineare exyzèlinearRGBconvertito in XYZ. - Tutti i metodi di assistenza utilizzati dalla stringa dello shader devono essere preceduti dalla stringa
libtonemap_in modo che le definizioni degli shader del framework non entrino in conflitto. Allo stesso modo, le uniformi di input devono essere precedute dain_libtonemap_.
- La stringa dello shader deve avere un punto di ingresso con la
Genera uniformi SkSL
L'interfaccia
ToneMapper::generateShaderSkSLUniforms()restituisce quanto segue, dato unstructdi metadati che descrive i metadati di diversi standard HDR e condizioni di visualizzazione:Un elenco di uniformi associate a uno shader SkSL.
I valori uniformi
in_libtonemap_displayMaxLuminanceein_libtonemap_inputMaxLuminance. Questi valori vengono utilizzati dagli shader del framework durante il ridimensionamento dell'input inlibtonemape la normalizzazione dell'output, se applicabile.
Al momento, il processo di generazione delle uniformi è indipendente dallo spazio dati di input e output.
Personalizzazione
L'implementazione di riferimento della libtonemap libreria produce risultati accettabili. Tuttavia, poiché l'algoritmo di mappatura tonale utilizzato dalla composizione della GPU può differire da quello utilizzato dalla composizione della DPU, l'utilizzo dell'implementazione di riferimento può causare sfarfallio in alcuni scenari, ad esempio l'animazione di rotazione. La personalizzazione può risolvere questi problemi di qualità dell'immagine specifici del fornitore.
Gli OEM sono vivamente invitati a sostituire l'implementazione di libtonemap per
definire la propria sottoclasse ToneMapper, restituita da getToneMapper().
Quando personalizzano l'implementazione, i partner devono eseguire una delle seguenti operazioni:
- Modificare direttamente l'implementazione di
libtonemap. - Definire la propria libreria statica, compilare la libreria come standalone e sostituire il file
.adella librerialibtonemapcon quello generato dalla libreria personalizzata.
I fornitori non devono modificare alcun codice del kernel, ma più fornitori devono comunicare i dettagli sugli algoritmi di mappatura dei toni della DPU per un'implementazione corretta.
Convalida
Segui questi passaggi per convalidare l'implementazione:
Riproduci video HDR sullo schermo di qualsiasi standard HDR supportato dal sistema di visualizzazione, ad esempio HLG, HDR10, HDR10+ o DolbyVision.
Attiva/disattiva la composizione della GPU per assicurarti che non ci siano sfarfallii percepibili dall'utente.
Utilizza il seguente comando
adbper attivare/disattivare la composizione della GPU:adb shell service call SurfaceFlinger 1008 i32 <0 to enable HWC composition, 1 to force GPU composition>
Problemi comuni
Con questa implementazione possono verificarsi i seguenti problemi:
Il banding si verifica quando la destinazione di rendering utilizzata dalla composizione della GPU ha una precisione inferiore al valore tipico per i contenuti HDR. Ad esempio, il banding può verificarsi quando un'implementazione HWC supporta formati opachi a 10 bit per HDR come RGBA1010102 o P010, ma richiede che la composizione della GPU scriva in un formato a 8 bit come RGBA8888 per supportare l'alfa.
Una leggera variazione di colore è causata da differenze di quantizzazione se la DPU opera con una precisione diversa rispetto alla GPU.
Ognuno di questi problemi è correlato alle differenze di precisione relative dell'hardware sottostante. Una soluzione alternativa tipica consiste nell'assicurarsi che nei percorsi di precisione inferiore sia presente un passaggio di dithering, in modo che le differenze di precisione siano meno percepibili dall'uomo.