Android 13 introduce un
libreria chiamata libtonemap
, che definisce le operazioni di mappatura dei toni ed è condivisa
con il processo SurfaceFlinger e le implementazioni di Hardware Composer (HWC).
Questa funzionalità consente agli OEM di definire e condividere la mappatura dei toni del display
algoritmi tra framework e fornitori, riducendo il disallineamento del tono
il mapping.
Prima di Android 13, mappatura dei toni specifica per il display operazioni non sono state condivise tra HWC, SurfaceFlinger e le app. A seconda nel percorso di rendering, per i contenuti HDR, si è verificato un'errata corrispondenza nella qualità dell'immagine il tono dei contenuti HDR è stato mappato in vari modi in uno spazio di output. Questo era percepibile in scenari come la rotazione dello schermo, in cui la composizione modifiche alla strategia tra GPU e DPU e differenze di rendering il comportamento normale tra TextureView e SurfaceView.
In questa pagina vengono descritti i dettagli dell'interfaccia, della personalizzazione e della convalida del
Raccolta libtonemap
.
Interfaccia con la libreria di tone mapping
La libtonemap
contiene implementazioni supportate dalla CPU e Shar SkSL, che possono essere
collegati da SurfaceFlinger per la composizione del backend GPU e dall'HWC per
generando una tabella di ricerca per la mappatura dei toni (LUT). Il punto di accesso a libtonemap
è android::tonemap::getToneMapper()
, che restituisce un oggetto
implementa l'interfaccia ToneMapper
.
L'interfaccia ToneMapper
supporta le seguenti funzionalità:
Generare una LUT di mappatura dei toni
L'interfaccia
ToneMapper::lookupTonemapGain
è una CPU implementazione dello snapshot definito inlibtonemap_LookupTonemapGain()
. Questo è utilizzato dai test delle unità nel framework e può essere utilizzato dai partner per assistenza per la generazione di una LUT di mappatura dei toni all'interno della pipeline dei colori.libtonemap_LookupTonemapGain()
assume i valori dei colori in assoluti, spazio lineare non normalizzato, sia in RGB lineare che in XYZ, e restituisce un numero in virgola mobile che descrive quanto moltiplicare i colori di input nello spazio lineare.Genera uno shaker SkSL
L'interfaccia
ToneMapper::generateTonemapGainShaderSkSL()
restituisce un Stringa shaker SkSL, con uno spazio dati di origine e di destinazione. Lo streamr SkSL è collegato all'implementazione di Skia perRenderEngine
il componente di composizione con accelerazione GPU per SurfaceFlinger. Lo Shader è anche collegato alibhwui
, in modo che la mappatura dei toni HDR-SDR possa essere eseguita in modo efficiente perTextureView
. Poiché la stringa generata è allineata con gli altri Shar SkSL utilizzati da Skia, lo shaker deve rispettare le seguenti regole:- La stringa shaker deve avere un punto di ingresso con
float libtonemap_LookupTonemapGain(vec3 linearRGB, vec3 xyz)
, dovelinearRGB
è il valore dei nit assoluti dei pixel RGB nello spazio lineare exyz
èlinearRGB
convertito in XYZ. - Tutti i metodi helper utilizzati dalla stringa shaker devono essere preceduti dal prefisso
la stringa
libtonemap_
in modo che le definizioni dello streamr del framework non entrino in conflitto. Allo stesso modo, le uniformi di input devono essere precedute dal prefissoin_libtonemap_
.
- La stringa shaker deve avere un punto di ingresso con
Genera uniformi SkSL
L'interfaccia
ToneMapper::generateShaderSkSLUniforms()
restituisce seguente, dato unstruct
di metadati che descrive metadati di diversi HDR standard e condizioni di visualizzazione:Un elenco di uniformi associate a uno shaker SkSL.
I valori uniformi
in_libtonemap_displayMaxLuminance
ein_libtonemap_inputMaxLuminance
. Questi valori vengono utilizzati dai framework Shaper quando si scala l'input inlibtonemap
e si normalizza l'output come applicabile.
Attualmente il processo di generazione delle uniformi è indipendente dall'input e di output.
Personalizzazione
L'implementazione di riferimento della libreria libtonemap
produce risultati accettabili. Tuttavia,
perché l'algoritmo di mappatura dei toni utilizzato dalla composizione della GPU può differire da
utilizzata dalla composizione DPU, l'utilizzo dell'implementazione di riferimento può causare
sfarfallio in alcuni scenari, ad esempio nell'animazione di rotazione. La personalizzazione può
i problemi di qualità delle immagini
specifici del fornitore.
Consigliamo vivamente agli OEM di sostituire l'implementazione di libtonemap
per
definiscono la propria sottoclasse ToneMapper
, restituita da getToneMapper()
.
Durante la personalizzazione dell'implementazione, i partner devono eseguire una delle
seguenti:
- Modificare direttamente l'implementazione di
libtonemap
. - Definire la propria libreria statica, compilare la libreria come autonoma e
sostituisci il file
.a
della librerialibtonemap
con quello generato dalla relativa libreria libreria.
I fornitori non devono modificare il codice kernel, ma più fornitori devono comunicare dettagli sugli algoritmi di mappatura dei toni delle DPU per una corretta implementazione.
Convalida
Per convalidare l'implementazione:
Riprodurre video HDR sullo schermo di tutti gli standard HDR supportati dal tuo sistema di visualizzazione, come HLG, HDR10, HDR10+ o DolbyVision.
Attiva/disattiva la composizione della GPU per assicurarti che non vi sia sfarfallio percepito dall'utente.
Usa 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:
La creazione a bande è causata quando il target di rendering utilizzato dalla composizione GPU è inferiore di precisione rispetto al valore tipico dei contenuti HDR. Ad esempio, le bande possono si verificano 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 alpha.
Una leggera variazione di colore è causata da differenze di quantizzazione se la DPU funziona con una precisione diversa rispetto alla GPU.
Ciascuno di questi problemi è correlato alle differenze di precisione relative del l'hardware sottostante. Una soluzione alternativa tipica è garantire la presenza di un dithering ogni passo nei percorsi con precisione inferiore, rendendo le eventuali differenze di precisione meno umane percepibile.