À partir de 2026, pour nous aligner sur notre modèle de développement stable et garantir la stabilité de la plate-forme pour l'écosystème, nous publierons le code source sur AOSP au deuxième et au quatrième trimestre. Pour créer et contribuer dans AOSP, utilisez android-latest-release. La branche de fichier manifeste android-latest-release fera toujours référence à la version la plus récente envoyée à AOSP. Pour en savoir plus, consultez Modifications apportées à AOSP.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Mappage des tons de la luminance HDR sur une plage compatible avec le SDR

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

Dans Android 12 et versions antérieures, les opérations de mappage des tons spécifiques à l'affichage n'étaient pas partagées entre le HWC, SurfaceFlinger et les applications. Selon le chemin de rendu, cela entraînait des différences de qualité d'image pour le contenu HDR, où le contenu HDR était mappé sur un espace de sortie de différentes manières. Cela était perceptible dans des scénarios tels que la rotation de l'écran, où la stratégie de composition change entre le GPU et le DPU, ainsi que dans les différences de comportement de rendu entre TextureView et SurfaceView.

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

Interface de la bibliothèque de mappage des tons

La libtonemap bibliothèque contient des implémentations basées sur le processeur et des shaders SkSL, qui peuvent être branchés par SurfaceFlinger pour la composition de backend GPU et par le HWC pour générer une table de correspondance de mappage des tons (LUT). Le point d'entrée de libtonemap est android::tonemap::getToneMapper, qui renvoie un objet qui implémente l' ToneMapper interface.

L'interface ToneMapper est compatible avec les fonctionnalités suivantes :

Générer une LUT de mappage des tons

L'interface ToneMapper::lookupTonemapGain est une implémentation CPU du shader défini dans libtonemap_LookupTonemapGain. Elle est utilisée par les tests unitaires dans le framework et peut être utilisée par les partenaires pour générer une LUT de mappage des tons dans leur pipeline de couleurs.

libtonemap_LookupTonemapGain prend en compte les valeurs de couleur dans un espace linéaire absolu et non normalisé, à la fois en RVB linéaire et en XYZ, et renvoie un float décrivant le facteur de multiplication des couleurs d'entrée dans l'espace linéaire.
Générer un shader SkSL

L'interface ToneMapper::generateTonemapGainShaderSkSL renvoie une chaîne de shader SkSL, en fonction d'un espace de données source et de destination. Le shader SkSL est branché sur l'implémentation Skia pour RenderEngine, le composant de composition accéléré par GPU pour SurfaceFlinger. Le shader est également branché sur libhwui, de sorte que le mappage des tons HDR vers SDR peut être effectué efficacement pour TextureView. Étant donné que la chaîne générée est intégrée à d'autres shaders SkSL utilisés par Skia, le shader doit respecter les règles suivantes :
- La chaîne de shader doit avoir un point d'entrée avec la float libtonemap_LookupTonemapGain(vec3 linearRGB, vec3 xyz) signature, où linearRGB est la valeur des nits absolus des pixels RVB dans l'espace linéaire et xyz est linearRGB converti en XYZ.
- Tous les méthodes d'assistance utilisées par la chaîne de shader doivent être précédées de la chaîne libtonemap_ afin que les définitions de shader du framework ne soient pas en conflit. De même, les uniformes d'entrée doivent être précédés de in_libtonemap_.
Générer des uniformes SkSL

L'interface ToneMapper::generateShaderSkSLUniforms renvoie les éléments suivants, en fonction d'une struct décrivant les métadonnées de différentes normes HDR et conditions d'affichage :
- Une liste d'uniformes liés par un shader SkSL.
- Les valeurs uniformes in_libtonemap_displayMaxLuminance et in_libtonemap_inputMaxLuminance. Ces valeurs sont utilisées par les shaders du framework lors de la mise à l'échelle de l'entrée dans libtonemap et de la normalisation de la sortie, le cas échéant.
  
  Le processus de génération d'uniformes est indépendant de l'espace de données d'entrée et de sortie.

Personnalisation

L'implémentation de référence de la libtonemap bibliothèque produit des résultats acceptables. Toutefois, comme l'algorithme de mappage des tons utilisé par la composition GPU peut différer de celui utilisé par la composition DPU, l'utilisation de l'implémentation de référence peut entraîner un scintillement dans certains scénarios, comme l'animation de rotation. La personnalisation peut résoudre ces problèmes de qualité d'image spécifiques aux fournisseurs.

Les OEM sont fortement encouragés à remplacer l'implémentation de libtonemap pour définir leur propre sous-classe ToneMapper, qui est renvoyée par getToneMapper. Lors de la personnalisation de l'implémentation, les partenaires doivent effectuer l'une des opérations suivantes :

Modifier directement l'implémentation de libtonemap.
Définir leur propre bibliothèque statique, compiler la bibliothèque en tant qu'application autonome et remplacer le fichier .a de la bibliothèque libtonemap par celui généré à partir de leur bibliothèque personnalisée.

Les fournisseurs n'ont pas besoin de modifier le code du noyau, mais plusieurs fournisseurs doivent communiquer des informations sur les algorithmes de mappage des tons DPU pour une implémentation correcte.

Validation

Pour valider votre implémentation, procédez comme suit :

Lisez des vidéos HDR sur l'écran de toutes les normes HDR compatibles avec votre système d'affichage prend en charge, telles que HLG, HDR10, HDR10+ ou DolbyVision.
Activez la composition GPU pour vous assurer qu'il n'y a pas de scintillement perceptible par l'utilisateur.

Utilisez la commande adb suivante pour activer ou 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

Les problèmes suivants peuvent se produire avec cette implémentation :

L'effet de bande se produit lorsque la cible de rendu utilisée par la composition GPU est moins précise que la valeur typique du contenu HDR. Par exemple, l'effet de bande peut se produire lorsqu'une implémentation HWC est compatible avec les formats HDR 10 bits opaques tels que RGBA1010102 ou P010, mais nécessite que la composition GPU écrive dans un format 8 bits comme RGBA8888 pour prendre en charge l'alpha.
Un léger décalage de couleur est causé par des différences de quantification si le 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 du matériel sous-jacent. Une solution courante consiste à s'assurer qu'il existe une étape de tramage dans les chemins de précision inférieure, ce qui rend les différences de précision moins perceptibles par l'humain.