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

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

    • I valori uniformi in_libtonemap_displayMaxLuminance e in_libtonemap_inputMaxLuminance. Questi valori vengono utilizzati dagli shader del framework durante il ridimensionamento dell'input in libtonemap e 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 .a della libreria libtonemap 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 un'implementazione corretta.

Convalida

Segui questi passaggi per convalidare l'implementazione:

  1. Riproduci video HDR sullo schermo di qualsiasi standard HDR supportato dal sistema di visualizzazione, ad esempio HLG, HDR10, HDR10+ o DolbyVision.

  2. Attiva/disattiva la composizione della GPU per assicurarti che non ci siano sfarfallii percepibili 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 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.