Tone Mapping HDR-Helligkeit in einem SDR-kompatiblen Bereich

Mit Android 13 wird eine vom Anbieter konfigurierbare statische libtonemap, die Tone Mapping-Vorgänge definiert und gemeinsam genutzt wird, mit dem SurfaceFlinger-Prozess und Hardware Composer (HWC)-Implementierungen. Mit dieser Funktion können OEMs ihre Tonabbildungen für Displays definieren und teilen. Algorithmen zwischen Framework und Anbietern zu treffen. Dadurch wird der Tonfall -Zuordnung.

Vor Android 13 wurde das bildschirmspezifische Tone Mapping Abläufe wurden nicht zwischen HWC, SurfaceFlinger und Apps ausgetauscht. Je nach im Rendering-Pfad, führten bei HDR-Inhalten zu Abweichungen bei der Bildqualität, bei dem der HDR-Inhalt auf unterschiedliche Weise einem Ausgaberaum zugeordnet wurde. Dieses in Szenarien wie der Bildschirmdrehung wahrnehmbar war, zwischen der GPU und der DPU sowie in Bezug auf das Rendering zwischen TextureView und SurfaceView.

Auf dieser Seite werden die Benutzeroberfläche, die Anpassung und die Validierung des libtonemap-Bibliothek.

Schnittstelle für die Tone Mapping-Bibliothek

Die libtonemap enthält CPU-gestützte Implementierungen und SkSL-Shader, die von SurfaceFlinger für die GPU-Back-End-Zusammensetzung und HWC eine Tone Mapping-Lookup-Tabelle (LUT) generiert. Der Einstiegspunkt zu libtonemap ist android::tonemap::getToneMapper(), wodurch ein Objekt zurückgegeben wird, das Implementiert die ToneMapper-Schnittstelle.

Die ToneMapper-Schnittstelle unterstützt die folgenden Funktionen:

  • Tone-Mapping-LUT generieren

    Die Schnittstelle ToneMapper::lookupTonemapGain ist eine CPU Implementierung des in libtonemap_LookupTonemapGain() definierten Shaders. Dieses wird von Einheitentests im Framework verwendet und kann von Partnern für Unterstützung beim Generieren einer Tonzuordnungs-LUT in ihrer Farbpipeline.

    libtonemap_LookupTonemapGain() akzeptiert Farbwerte in absoluten, nicht normalisierten linearen Raum, sowohl im linearen RGB- als auch in XYZ, und gibt eine Gleitkommazahl zurück. beschreibt, wie stark die Eingabefarben im linearen Raum multipliziert werden sollen.

  • SkSL-Shader generieren

    Die Schnittstelle ToneMapper::generateTonemapGainShaderSkSL() gibt ein SkSL-Shader-String mit Angabe eines Quell- und Zieldatenraums. Der SkSL-Shader an die Skia-Implementierung für RenderEngine angeschlossen ist, die GPU-beschleunigte Compositing-Komponente für SurfaceFlinger. Der Shader ist auch an libhwui angeschlossen, damit HDR-zu-SDR-Tone Mapping für TextureView effizient durchgeführt werden kann. Da der generierte String in andere von Skia verwendete SkSL-Shader eingebunden ist, Der Shader muss die folgenden Regeln einhalten:

    • Der Shader-String muss einen Einstiegspunkt mit der Eigenschaft float libtonemap_LookupTonemapGain(vec3 linearRGB, vec3 xyz)-Signatur, wobei linearRGB ist der Wert der absoluten cd/m2-Werte der RGB-Pixel im linearen Raum und xyz wird linearRGB in XYZ konvertiert.
    • Allen Hilfsmethoden, die vom Shader-String verwendet werden, muss das Präfix den String libtonemap_, damit die Framework-Shader-Definitionen nicht in Konflikt stehen. Ebenso müssen Eingabeuniformen das Präfix in_libtonemap_ haben.

  • SkSL-Uniformen erstellen

    Die Schnittstelle ToneMapper::generateShaderSkSLUniforms() gibt den Fehlerwert weiter unten mit einer Metadaten-struct, die Metadaten aus verschiedenen HDR- Standards und Anzeigebedingungen:

    • Eine Liste von Uniformen, die an einen SkSL-Shader gebunden sind.

    • Die einheitlichen Werte in_libtonemap_displayMaxLuminance und in_libtonemap_inputMaxLuminance. Diese Werte werden von Framework-Shadern verwendet beim Skalieren der Eingabe auf libtonemap und Normalisieren der Ausgabe als zutreffend sind.

    Derzeit ist der Prozess der Uniformen unabhängig vom Input und gibt.

Personalisierung

Die Referenzimplementierung der libtonemap-Bibliothek liefert akzeptable Ergebnisse. Sie können jedoch da der von der GPU-Zusammensetzung verwendete Tone Mapping-Algorithmus die von der Datenschutzaufsichtsbehörde verwendet wird, kann die Verwendung der Referenzimplementierung dazu führen, in einigen Szenarien wie z. B. bei der Rotationsanimation. Anpassung kann anbieterspezifische Probleme mit der Bildqualität beheben können.

OEMs wird dringend empfohlen, die Implementierung von libtonemap zu überschreiben, eigene ToneMapper-Unterklasse definieren, die von getToneMapper() zurückgegeben wird. Bei der Anpassung der Implementierung müssen Partner einen der folgenden Schritte ausführen: Folgendes:

  • Implementierung von libtonemap direkt ändern.
  • eine eigene statische Bibliothek definieren, die Bibliothek als eigenständige Bibliothek kompilieren und die Datei .a der libtonemap-Bibliothek durch die Datei ersetzen, die aus der benutzerdefinierten Bibliothek.

Anbieter müssen keinen Kernel-Code ändern, aber mehrere Anbieter müssen Informationen zu den DPU-Tone-Mapping-Algorithmen Implementierung.

Zertifizierungsstufe

So validieren Sie Ihre Implementierung:

  1. Spielen Sie HDR-Videos auf Bildschirmen mit einem beliebigen HDR-Standard ab, den Ihr Anzeigesystem unterstützt, wie HLG, HDR10, HDR10+ oder DolbyVision.

  2. Schalten Sie die GPU-Zusammensetzung ein, damit kein für Nutzer wahrnehmbares Flackern auftritt.

    Verwenden Sie den folgenden adb-Befehl, um die GPU-Zusammensetzung umzuschalten:

    adb shell service call SurfaceFlinger 1008 i32 <0 to enable HWC composition,
1 to force GPU composition>

Häufige Probleme

Bei dieser Implementierung können folgende Probleme auftreten:

  • Banding tritt auf, wenn das von der GPU-Zusammensetzung verwendete Renderingziel niedriger ist Precision als der typische Wert für HDR-Inhalte. Durch Banding können Sie z. B. treten auf, wenn eine HWC-Implementierung opaker 10-Bit-Formate für HDR unterstützt, z. B. RGBA1010102 oder P010, erfordert aber, dass die GPU-Zusammensetzung in ein 8-Bit-Format schreibt wie RGBA8888, um Alpha zu unterstützen.

  • Eine subtile Farbverschiebung wird durch Quantisierungsunterschiede verursacht, wenn die DPU mit einer anderen Genauigkeit als die GPU arbeitet.

Jedes dieser Probleme hängt mit der relativen Genauigkeitsunterschiede der zugrunde liegende Hardware. Eine typische Problemumgehung besteht darin, sicherzustellen, die Pfade mit geringerer Genauigkeit ein, wodurch Unterschiede bei der Genauigkeit weniger menschliche wahrnehmbar ist.