Android 13 introduce una libreria statica configurabile dal fornitore chiamata libtonemap
, che definisce le operazioni di mappatura dei toni ed è condivisa con il processo SurfaceFlinger e le implementazioni Hardware Composer (HWC). Questa funzionalità consente agli OEM di definire e condividere i propri algoritmi di mappatura dei toni di visualizzazione tra il framework e i fornitori, riducendo la mancata corrispondenza nella mappatura dei toni.
Prima di Android 13, le operazioni di mappatura dei toni specifiche del display non erano condivise tra HWC, SurfaceFlinger e le app. A seconda del percorso di rendering, per i contenuti HDR, ciò ha portato a discrepanze nella qualità dell'immagine, in cui il contenuto HDR veniva mappato in toni su uno spazio di output in modi diversi. Ciò era percepibile in scenari come la rotazione dello schermo, dove la strategia di composizione cambia tra GPU e 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 con la libreria di mappatura dei toni
La libreria libtonemap
contiene implementazioni supportate dalla CPU e shader SkSL, che possono essere collegati da SurfaceFlinger per la composizione del backend GPU e dall'HWC per generare una tabella di ricerca della mappatura dei toni (LUT). Il punto di ingresso a 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 CPU dello shader definito inlibtonemap_LookupTonemapGain()
. Viene utilizzato dai test unitari nel framework e può essere utilizzato dai partner per assistenza nella generazione di una LUT di mappatura dei toni all'interno della loro pipeline di colori.libtonemap_LookupTonemapGain()
accetta valori di colore nello spazio lineare assoluto e non normalizzato, sia in RGB lineare che in XYZ, e restituisce un float che descrive quanto moltiplicare i colori di input nello spazio lineare.Genera uno shader SkSL
L'interfaccia
ToneMapper::generateTonemapGainShaderSkSL()
restituisce una stringa shader SkSL, dato uno spazio dati di origine e di destinazione. Lo shader SkSL è collegato all'implementazione Skia perRenderEngine
, il componente di compositing accelerato dalla GPU per SurfaceFlinger. Lo shader è anche collegato alibhwui
, in modo che la mappatura dei toni da HDR a SDR possa essere eseguita in modo efficiente perTextureView
. Poiché la stringa generata è incorporata in 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 firma
float libtonemap_LookupTonemapGain(vec3 linearRGB, vec3 xyz)
, dovelinearRGB
è il valore dei nit assoluti dei pixel RGB nello spazio lineare exyz
èlinearRGB
convertito in XYZ. - Qualsiasi metodo di supporto utilizzato dalla stringa dello shader deve avere come prefisso la stringa
libtonemap_
in modo che le definizioni dello shader del framework non siano in conflitto. Allo stesso modo, le uniformi di input devono avere il prefissoin_libtonemap_
.
- La stringa dello shader deve avere un punto di ingresso con la firma
Genera uniformi SkSL
L'interfaccia
ToneMapper::generateShaderSkSLUniforms()
restituisce quanto segue, data unastruct
di metadati che descrive i metadati da diversi standard HDR e condizioni di visualizzazione:Un elenco di uniformi vincolate da uno shader SkSL.
I valori uniformi
in_libtonemap_displayMaxLuminance
ein_libtonemap_inputMaxLuminance
. Questi valori vengono utilizzati dagli shader del framework durante il ridimensionamento dell'input inlibtonemap
e la normalizzazione dell'output come applicabile.
Attualmente il processo di generazione delle uniformi è indipendente dallo spazio dati di input e output.
Personalizzazione
L'implementazione di riferimento della libreria libtonemap
produce risultati accettabili. Tuttavia, poiché l'algoritmo di mappatura dei toni utilizzato dalla composizione GPU può differire da quello utilizzato dalla composizione DPU, l'utilizzo dell'implementazione di riferimento può causare sfarfallio in alcuni scenari come l'animazione di rotazione. La personalizzazione può risolvere tali problemi di qualità dell'immagine specifici del fornitore.
Gli OEM sono fortemente incoraggiati a sovrascrivere l'implementazione di libtonemap
per definire la propria sottoclasse ToneMapper
, che viene restituita da getToneMapper()
. Quando si personalizza l'implementazione, i partner devono eseguire una delle seguenti operazioni:
- Modifica direttamente l'implementazione di
libtonemap
. - Definire la propria libreria statica, compilare la libreria come autonoma e sostituire il file
.a
della librerialibtonemap
con 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 una corretta implementazione.
Validazione
Segui questi passaggi per convalidare l'implementazione:
Riproduci video HDR sullo schermo di qualsiasi standard HDR supportato dal tuo sistema di visualizzazione , come HLG, HDR10, HDR10+ o DolbyVision.
Attiva/disattiva la composizione della GPU per garantire che non vi sia sfarfallio percepibile dall'utente.
Utilizza il seguente comando
adb
per 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 viene causato quando la destinazione di rendering utilizzata dalla composizione GPU ha una precisione inferiore rispetto al valore tipico per il contenuto 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 GPU scriva in un formato a 8 bit come RGBA8888 per supportare l'alfa.
Un leggero spostamento di colore è causato dalle differenze di quantizzazione se la DPU funziona con una precisione diversa rispetto alla GPU.
Ciascuno di questi problemi è correlato alle relative differenze di precisione dell'hardware sottostante. Una tipica soluzione alternativa consiste nel garantire che sia presente un passaggio di dithering nei percorsi di precisione inferiore, rendendo eventuali differenze di precisione meno percepibili dall'uomo.