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

Android 13 introduce una libreria statica configurabile dal fornitore denominata 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 gli algoritmi di mappatura dei toni del display tra il framework e i fornitori, riducendo le mancate corrispondenze nella mappatura dei toni.

Prima di Android 13, le operazioni di mappatura tonale specifiche del display non erano condivise tra HWC, SurfaceFlinger e le app. A seconda del percorso di rendering, per i contenuti HDR si verificava una mancata corrispondenza nella qualità dell'immagine, con la conseguente mappatura di un tono in uno spazio di output in modi diversi. Questo è stato percepito in scenari come la rotazione dello schermo, dove la strategia di composizione varia tra la GPU e la DPU, e nelle differenze di comportamento nel rendering tra TextureView e SurfaceView.

Questa pagina descrive l'interfaccia, la personalizzazione e i dettagli di convalida della librerialibtonemap.

Interfaccia con la libreria di mappatura tonale

La libreria libtonemap contiene implementazioni basate su CPU e shader SkSL, che possono essere collegate da SurfaceFlinger per la composizione del backend GPU e dall'HWC per generare una tabella di ricerca (LUT) per la mappatura tonale. L'entry point di libtonemap è android::tonemap::getToneMapper(), che restituisce un oggetto che implementa l'interfaccia ToneMapper.

L'interfaccia ToneMapper supporta le seguenti funzionalità:

  • Generare una LUT di mappatura dei toni

    L'interfaccia ToneMapper::lookupTonemapGain è un'implementazione della CPU dello Shar definito in libtonemap_LookupTonemapGain(). Questo viene utilizzato dai test di unità nel framework e può essere utilizzato dai partner per ricevere assistenza per la generazione di una LUT di mappatura tonale all'interno della pipeline di colori.

    libtonemap_LookupTonemapGain() acquisisce i valori del colore nello spazio lineare assoluto e non normalizzato, sia in RGB lineare che in XYZ, e restituisce un numero in virgola mobile che descrive di quanto moltiplicare i colori di input nello spazio lineare.

  • Genera uno shader SkSL

    L'interfaccia ToneMapper::generateTonemapGainShaderSkSL() restituisce una stringa Shar SkSL, in base a 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 Shar è anche collegato a libhwui, per consentire una mappatura dei toni da HDR a SDR in modo efficiente per TextureView. Poiché la stringa generata è integrata in altri Shar SkSL utilizzati da Skia, lo shaker deve rispettare le seguenti regole:

    • La stringa dello shader deve avere un punto di contatto con la firma 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 del framework shaker non entrino in conflitto. Allo stesso modo, le uniformi di input devono essere precedute dal prefisso in_libtonemap_.

  • Generare uniformi SkSL

    L'interfaccia ToneMapper::generateShaderSkSLUniforms() restituisce quanto segue, dato un struct di metadati che descrive i metadati di diversi standard HDR e condizioni di visualizzazione:

    • Un elenco di uniformi vincolate da uno shaker SkSL.

    • I valori uniformi in_libtonemap_displayMaxLuminance e in_libtonemap_inputMaxLuminance. Questi valori vengono utilizzati dagli shader del framework per eseguire la scalatura dell'input in libtonemap e normalizzare l'output, se applicabile.

    Al momento, il processo di generazione delle uniformi è indipendente dallo spazio dati di input e di output.

Personalizzazione

L'implementazione di riferimento della libreria libtonemap produce risultati accettabili. Tuttavia, poiché l'algoritmo di mappatura tonale utilizzato dalla composizione GPU può essere diverso da quello utilizzato dalla composizione DPU, l'utilizzo dell'implementazione di riferimento può causare sfarfallio in alcuni scenari, ad esempio nell'animazione di rotazione. La personalizzazione può risolvere questi problemi di qualità delle immagini specifici del fornitore.

Consigliamo vivamente agli OEM di sostituire l'implementazione di libtonemap per definire la propria sottoclasse ToneMapper, che viene restituita da getToneMapper(). Durante la personalizzazione dell'implementazione, i partner devono:

  • Modificare direttamente l'implementazione di libtonemap.
  • Definire la propria libreria statica, compilare la libreria come autonoma e sostituire il file .a della libreria di libtonemap con quello generato dalla libreria personalizzata.

I fornitori non devono modificare alcun 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. Riproduci i video HDR sullo schermo con qualsiasi standard HDR supportato 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.

    Utilizza il seguente comando adb per attivare/disattivare la composizione 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 banda a bande si verifica quando il target di rendering utilizzato dalla composizione GPU è di precisione inferiore rispetto al valore tipico per i contenuti HDR. Ad esempio, la creazione di bande 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 alpha.

  • Una leggera variazione di colore è causata da differenze di quantizzazione se la DPU opera con una precisione diversa rispetto alla GPU.

Ciascuno di questi problemi è correlato alle differenze di precisione relative dell'hardware sottostante. Una soluzione alternativa tipica è garantire che ci sia una fase di dithering nei percorsi di precisione inferiori, rendendo le eventuali differenze di precisione meno percepibili da parte dell'uomo.