Mappatura dei toni della luminanza HDR su un intervallo compatibile con SDR

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 in libtonemap_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 per RenderEngine il componente di composizione con accelerazione GPU per SurfaceFlinger. Lo Shader è anche collegato a libhwui, in modo che la mappatura dei toni HDR-SDR possa essere eseguita in modo efficiente per TextureView. 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), dove linearRGB è il valore dei nit assoluti dei pixel RGB nello spazio lineare e xyz è 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 prefisso in_libtonemap_.

  • Genera uniformi SkSL

    L'interfaccia ToneMapper::generateShaderSkSLUniforms() restituisce seguente, dato un struct 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 e in_libtonemap_inputMaxLuminance. Questi valori vengono utilizzati dai framework Shaper quando si scala l'input in libtonemap 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 libreria libtonemap 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:

  1. Riprodurre video HDR sullo schermo di tutti gli standard HDR supportati dal tuo sistema di visualizzazione, come HLG, HDR10, HDR10+ o DolbyVision.

  2. 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.