Mappatura dei toni Luminanza HDR su una gamma compatibile SDR

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

  • Genera uniformi SkSL

    L'interfaccia ToneMapper::generateShaderSkSLUniforms() restituisce quanto segue, data una struct 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 e in_libtonemap_inputMaxLuminance . Questi valori vengono utilizzati dagli shader del framework durante il ridimensionamento dell'input in libtonemap 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 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 una corretta implementazione.

Validazione

Segui questi passaggi per convalidare l'implementazione:

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

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