Luminance HDR du mappage des tons sur une plage compatible SDR

Android 13 introduit une couche statique configurable par le fournisseur une bibliothèque appelée libtonemap, qui définit les opérations de mappage des tonalités et qui est partagée avec le processus SurfaceFlinger et les implémentations de Hardware Composer (HWC). Cette fonctionnalité permet aux OEM de définir et de partager leur mappage des tonalités d'affichage. entre le framework et les fournisseurs, ce qui permet de réduire les incohérences de ton le mappage.

Sous Android 13, mappage des tons spécifique à l'écran les opérations n'étaient pas partagées entre le HWC, SurfaceFlinger et les applications. En fonction sur le chemin de rendu, pour le contenu HDR, cela entraînait des incohérences au niveau de la qualité d'image, où les tons du contenu HDR étaient mappés sur un espace de sortie de différentes manières. Ce était perceptible dans des scénarios tels que la rotation de l'écran, où la composition des changements de stratégie entre le GPU et la DPU, et au niveau des différences de rendu entre TextureView et SurfaceView.

Cette page décrit l'interface, la personnalisation et les détails de validation du bibliothèque libtonemap.

Interface vers la bibliothèque de mappage des tonalités

libtonemap contient des implémentations reposant sur le processeur et des nuanceurs SkSL, qui peuvent être par SurfaceFlinger pour la composition du backend GPU et par le matériel pour la génération d'une table de consultation par mappage de tonalités (LUT). Le point d'entrée de libtonemap est android::tonemap::getToneMapper(), qui renvoie un objet implémente l'interface ToneMapper.

L'interface ToneMapper accepte les fonctionnalités suivantes:

  • Générer une LUT de mappage des tons

    L'interface ToneMapper::lookupTonemapGain est un processeur l'implémentation du nuanceur défini dans libtonemap_LookupTonemapGain(). Ce est utilisé par les tests unitaires dans le framework et peut être utilisé par les partenaires une assistance pour générer une LUT avec mappage des tons dans son pipeline de couleur.

    libtonemap_LookupTonemapGain() prend les valeurs de couleur en valeur absolue, espace linéaire non normalisé, en RVB linéaire et en XYZ, et renvoie une valeur flottante décrivant dans quelle mesure les couleurs d'entrée doivent être multipliées dans un espace linéaire.

  • Générer un nuanceur SkSL

    L'interface ToneMapper::generateTonemapGainShaderSkSL() renvoie une Chaîne de nuanceur SkSL, basée sur un espace de données source et de destination. Le nuanceur SkSL est dans l'implémentation Skia pour RenderEngine ; le composant de composition accéléré par GPU pour SurfaceFlinger. Le nuanceur est aussi branché sur libhwui, afin que le mappage des tons HDR/SDR soit efficace pour TextureView. Comme la chaîne générée est intégrée aux autres nuanceurs SkSL utilisés par Skia, le nuanceur doit respecter les règles suivantes:

    • La chaîne du nuanceur doit comporter un point d'entrée avec Signature float libtonemap_LookupTonemapGain(vec3 linearRGB, vec3 xyz), où linearRGB est la valeur des nits absolus des pixels RVB dans l'espace linéaire et xyz est linearRGB converti en XYZ.
    • Toutes les méthodes d'assistance utilisées par la chaîne du nuanceur doivent être précédées du préfixe la chaîne libtonemap_ afin d'éviter tout conflit entre les définitions du nuanceur de framework. De même, les variables uniformes d'entrée doivent comporter le préfixe in_libtonemap_.

  • Générer des variables uniformes SkSL

    L'interface ToneMapper::generateShaderSkSLUniforms() renvoie ci-dessous, à partir d'une métadonnée struct décrivant les métadonnées de différents formats standards et des conditions d'affichage:

    • Liste de variables uniformes liées par un nuanceur SkSL.

    • Les valeurs uniformes in_libtonemap_displayMaxLuminance et in_libtonemap_inputMaxLuminance Ces valeurs sont utilisées par les nuanceurs de framework lors du scaling de l'entrée en libtonemap, et en normalisant la sortie en tant que applicables.

    Actuellement, le processus de génération des variables uniformes est indépendant de l'entrée l'espace de données de sortie.

Personnalisation

L'implémentation de référence de la bibliothèque libtonemap produit des résultats acceptables. Toutefois, car l'algorithme de mappage des tons utilisé par la composition GPU peut différer de celui-ci utilisée par la composition DPU, l'utilisation de l'implémentation de référence peut entraîner clignoter dans certains scénarios, comme dans l'animation de rotation. La personnalisation peut résoudre ces problèmes de qualité d'image propres au fournisseur.

Nous recommandons vivement aux OEM de remplacer l'implémentation de libtonemap pour définir leur propre sous-classe ToneMapper, qui est renvoyée par getToneMapper(). Lorsqu'ils personnalisent l'implémentation, les partenaires doivent effectuer l'une des actions suivantes:

  • Modifiez directement l'implémentation de libtonemap.
  • définir leur propre bibliothèque statique, la compiler de manière autonome ; remplacez le fichier .a de la bibliothèque libtonemap par celui généré à partir de la bibliothèque bibliothèque.

Les fournisseurs n'ont pas besoin de modifier le code du noyau, mais plusieurs fournisseurs doivent communiquer des détails sur les algorithmes de mappage de tonalités DPU pour la mise en œuvre.

Validation

Procédez comme suit pour valider votre implémentation:

  1. Lire des vidéos HDR à l'écran dans n'importe quelle norme HDR compatible avec votre système d'affichage telles que HLG, HDR10, HDR10+ ou DolbyVision.

  2. Activez/Désactivez la composition GPU pour vous assurer qu'il n'y a pas de scepticulation perceptible par l'utilisateur.

    Utilisez la commande adb suivante pour activer/désactiver la composition GPU:

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

Problèmes courants

Cette implémentation peut présenter les problèmes suivants:

  • Des bandes apparaissent lorsque la cible de rendu utilisée par la composition GPU est inférieure à celle des contenus HDR habituels. Par exemple, l'ajout de bandes se produisent lorsqu'une implémentation HWC est compatible avec les formats 10 bits opaques pour le HDR, RGBA1010102 ou P010, mais nécessite que la composition GPU écrit dans un format 8 bits comme RGBA8888 pour prendre en charge la version alpha.

  • Un changement de couleur subtil est dû aux différences de quantification si la DPU fonctionne avec une précision différente de celle du GPU.

Chacun de ces problèmes est lié aux différences de précision relative des le matériel sous-jacent. Une solution de contournement typique consiste à s'assurer qu'il y a un tramage dans les chemins de précision inférieure. Les différences de précision sont ainsi moins humaines. perceptible.