À partir du 27 mars 2025, nous vous recommandons d'utiliser android-latest-release au lieu de aosp-main pour créer et contribuer à AOSP. Pour en savoir plus, consultez la section Modifications apportées à AOSP.
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Android 8.1 et les versions ultérieures prennent en charge la gestion des couleurs, qui peut être utilisée pour fournir une expérience cohérente entre les technologies d'affichage. Les applications exécutées sur Android peuvent accéder à toutes les fonctionnalités d'un écran à large gamme de couleurs pour exploiter tout le potentiel d'un appareil d'affichage.
Les versions précédentes d'Android n'incluaient pas la prise en charge de la gestion des couleurs et reposaient plutôt sur la compatibilité du contenu et des écrans (un objectif souvent facilité par l'industrie de la télévision). Toutefois, les technologies d'affichage récentes permettent d'afficher des écrans à gamme beaucoup plus large qui n'affichent pas le contenu existant comme prévu. Avec Android 8.1 ou version ultérieure, les appareils qui utilisent un écran à large gamme de couleurs (par exemple, une diode électroluminescente organique à matrice active ou AMOLED, certains écrans LCD) peuvent afficher des contenus à large gamme de couleurs à partir d'applications.
Déterminer la compatibilité de l'appareil
Les appareils équipés d'écrans à large plage de couleurs fonctionnant sous Android 8.1 ou version ultérieure doivent être compatibles avec la gestion des couleurs (large plage de couleurs). Avant d'activer cette fonctionnalité, assurez-vous que l'appareil remplit les conditions suivantes:
L'écran de l'appareil répond aux exigences matérielles, y compris un écran bien caractérisé compatible avec l'espace colorimétrique Display-P3. Si l'écran ne répond pas à cette exigence, n'activez pas la gestion des couleurs. Pour réduire l'impact du processeur et du GPU, il est souhaitable de prendre en charge sRGB étendu et HDR10 dans le pipeline d'affichage.
L'appareil est compatible avec un processus de calibrage en usine qui génère des données de calibrage (stockées sur l'appareil) pour ajuster la variance de fabrication du comportement de l'écran. Au minimum, les données de calibrage doivent permettre à l'écran d'afficher avec précision le contenu sRGB et les points blancs D65 et D73.
Si ces conditions sont remplies, vous pouvez activer la fonctionnalité de gestion des couleurs pour l'appareil.
Implémenter la gestion des couleurs
Pour implémenter la gestion des couleurs, commencez par mettre à jour le pilote Hardware Composer 2 (HWC2) afin de comprendre les modes de couleur et de les appliquer au matériel.
Plus précisément, le compositeur HWC2 doit signaler les modes de couleur Display-P3 et sRGB à l'aide de HWCDisplay::GetColorModes.
Activez ensuite les extensions OpenGL et la prise en charge des bibliothèques nécessaires pour traduire les espaces colorimétriques OpenGL en espaces de données HAL. Les extensions OpenGL requises incluent:
EGL_EXT_pixel_format_float.
Permet aux applications de créer des EGLSurfaces présentables avec des composants de couleur à virgule flottante 16 bits. Priorité: élevée (il s'agit probablement du format de pixel par défaut pour les applications compatibles avec les couleurs étendues). Nécessite la prise en charge des pilotes.
EGL_KHR_gl_colorspace.
Pour les applications qui souhaitent utiliser des framebuffers par défaut au format sRGB afin d'obtenir plus facilement un rendu sRGB sur les appareils d'affichage, cette extension permet de créer des EGLSurfaces qui seront affichées au format sRGB par les contextes OpenGL compatibles avec cette fonctionnalité. Nécessite la prise en charge du pilote pour le comportement sRGB.
Android fournit également les extensions facultatives suivantes:
EGL_EXT_colorspace_scrgb_linear.
Cette extension fournit une nouvelle option d'espace colorimétrique, scRGB, que les applications peuvent choisir lors de la création d'une EGLSurface. L'espace colorimétrique scRGB définit un espace de référence d'affichage linéaire avec le même point blanc et les mêmes couleurs primaires que sRVB (et est donc rétrocompatible avec sRVB). Cela ne devrait pas nécessiter de prise en charge par le pilote et peut être implémenté dans le wrapper EGL Android. Pour être utile, cette extension nécessite la prise en charge des nombres à virgule flottante 16 bits (FP16).
EGL_EXT_gl_colorspace_display_p3 et EGL_EXT_gl_colorspace_display_p3_linear. Pour les applications qui souhaitent utiliser les framebuffers par défaut au format Display P3 afin d'obtenir plus facilement un rendu sRGB sur les appareils d'affichage, cette extension permet de créer des EGLSurfaces qui seront affichées en Display P3 par les contextes OpenGL compatibles avec cette fonctionnalité.
Cela peut être implémenté dans le wrapper du pilote EGL.
VK_EXT_swapchain_colorspace (Vulkan) Permet aux applications de taguer les chaînes de remplacement avec l'espace colorimétrique qu'elles utilisent. Inclut un certain nombre d'espaces de couleurs courants tels que DCI-P3, Display-P3, Adobe RVB et BT2020.
Personnalisation
Vous pouvez personnaliser la fonctionnalité de gestion des couleurs en prenant en charge diverses normes de couleur telles que DCI-P3, AdobeRGB, Rec709 et Rec2020. Voici d'autres personnalisations:
Compatibilité matérielle avec la conversion des couleurs dans le pipeline d'affichage Permet la prise en charge de plusieurs transformations de couleur en mode matériel.
Compatibilité avec la transformation des couleurs indépendante sur plusieurs calques (par exemple, certaines calques peuvent être sRVB et d'autres sRVB étendu, chacune avec son propre pipeline de couleurs). Lorsqu'il y a plusieurs espaces colorimétriques visibles, certains doivent être convertis en espace colorimétrique de l'écran. Idéalement, cette transformation est mieux fournie par le moteur d'affichage (sinon, Android doit effectuer la composition du GPU).
Tests
Pour tester la gestion des couleurs, utilisez les ressources suivantes dans opengl/tests:
gl2_basic est une démonstration OpenGL simple qui demande un espace colorimétrique Display-P3.
EGL_test vérifie la compatibilité avec les extensions et les configurations nécessaires (10:10:10:2 et FP16).
test_wide_color crée une surface de la même manière que SurfaceFlinger (par exemple, configuration, espace de couleurs et format de pixel).
Implémentation de référence
Pour une implémentation de référence, consultez frameworks/native. Pour les en-têtes, consultez les articles suivants:
Le contenu et les exemples de code de cette page sont soumis aux licences décrites dans la Licence de contenu. Java et OpenJDK sont des marques ou des marques déposées d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/07/27 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/07/27 (UTC)."],[],[],null,["# Color management\n\nAndroid 8.1 and higher include support for color management that can be used to provide a\nconsistent experience across display technologies. Apps running on\nAndroid can access the full capabilities of a wide-gamut display to get the\nmost out of a display device.\n\nPrevious Android releases didn't include color management support and\ninstead relied on content and displays being compatible (a goal often aided by\nthe TV industry). However, recent display technologies allow for much larger\ngamut displays that don't display existing content as expected. With Android\n8.1 and higher, devices that use a wide-gamut display (for example, active-matrix organic\nlight-emitting diode or AMOLED, some LCDs) can see wide-gamut\ncontent from apps.\n\nDetermine device support\n------------------------\n\nDevices with wide-color displays running Android 8.1 or higher should support color\nmanagement (wide-color). Before enabling this feature, ensure that the device meets\nthe following requirements:\n\n- Device display meets the hardware requirements, which include a well-characterized display that supports the Display-P3 colorspace. If the display doesn't meet this requirement, don't enable color management. To reduce CPU and GPU impact, support for extended sRGB and HDR10 in the display pipeline is desirable.\n- Device supports a factory calibration process that generates calibration data (stored on the device) to adjust for manufacturing variance in display behavior. At a minimum, calibration data should allow the display to accurately display sRGB content and D65 and D73 white points.\n\nIf these requirements are met, you can enable the color management\nfeature for the device.\n\nImplement color management\n--------------------------\n\nTo implement color management, first update the\n[Hardware Composer 2 (HWC2)](/docs/core/graphics/implement-hwc) driver\nto understand color modes and to apply those modes to the hardware.\nSpecifically, the HWC2 composer must report the Display-P3 and sRGB\ncolor modes using `HWCDisplay::GetColorModes`.\n| **Key Term:** Display-P3 uses Digital Cinema Initiatives primaries and sRGB transfer function.\n\nNext, enable the necessary OpenGL extensions and library support to\ntranslate OpenGL color spaces to HAL data spaces. Required OpenGL extensions\ninclude:\n\n- [`EGL_EXT_pixel_format_float`](https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_pixel_format_float.txt). Allows apps to create presentable EGLSurfaces with 16-bit float color components. Priority: high (expect this is the default pixel format for wide-color aware apps). Requires driver support.\n- [`EGL_KHR_gl_colorspace`](https://www.khronos.org/registry/egl/extensions/KHR/EGL_KHR_gl_colorspace.txt). For apps that want to use sRGB format default framebuffers to more easily achieve sRGB rendering to display devices, this extension allows creating EGLSurfaces that will be rendered to in sRGB by OpenGL contexts supporting that capability. Requires driver support for sRGB behavior.\n\nAndroid also provides the following optional extensions:\n\n- [`EGL_EXT_colorspace_scrgb_linear`](https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_gl_colorspace_scrgb_linear.txt). This extension provides a new color space option, scRGB, that apps can choose when creating an EGLSurface. The scRGB color space defines a linear display referred space with the same white point and color primaries as sRGB (and thus is backward compatible with sRGB). This shouldn't require driver support and can be implemented in the Android EGL wrapper. To be useful, this extension requires support for 16-bit floating point (FP16).\n- [`EGL_EXT_gl_colorspace_display_p3`\n and `EGL_EXT_gl_colorspace_display_p3_linear`](https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_gl_colorspace_display_p3.txt). For apps that want to use Display-P3 format default framebuffers to more easily achieve sRGB rendering to display devices, this extension allows creating EGLSurfaces that will be rendered to in Display-P3 by OpenGL contexts supporting that capability. This can be implemented in EGL driver wrapper.\n- [`VK_EXT_swapchain_colorspace`](https://www.khronos.org/registry/vulkan/specs/1.0-extensions/html/vkspec.html#VK_EXT_swapchain_colorspace) (Vulkan). Enables apps to tag swap chains with the color space they're using. Includes a number of common color spaces such as DCI-P3, Display-P3, AdobeRGB, and BT2020.\n\nCustomization\n-------------\n\nYou can customize the color management feature by including support for a\nvariety of color standards such as DCI-P3, AdobeRGB, Rec709, and Rec2020. Other\ncustomizations include:\n\n- **Hardware support for color conversion in the display\n pipeline.** Enables support for multiple color transforms in hardware.\n- **Support for independent color transform on multiple layers** (for example, some layers could be sRGB and others extended-sRGB, each with their own color pipeline). When there's more than one color space visible, some color spaces need to be converted to the color space of the display. Ideally, this transform is best provided by the display engine (otherwise Android must perform GPU composition).\n\nTesting\n-------\n\nTo test color management, use the following resources in\n`opengl/tests`:\n\n- `gl2_basic` is a simple OpenGL demo that requests a Display-P3 colorspace.\n- [`EGL_test`](https://android.googlesource.com/platform/frameworks/native/+/android16-release/opengl/tests/EGLTest/EGL_test.cpp) tests for necessary extension and config support (10:10:10:2 and FP16).\n- `test_wide_color` creates a surface in same manner as SurfaceFlinger (for example, config, color space, and pixel format).\n\nReference implementation\n------------------------\n\nFor a reference implementation, refer to `frameworks/native`. For\nheaders, refer to:\n\n- [`system/core/include/system/graphics.h`](https://android.googlesource.com/platform/system/core/+/android16-release/libsystem/include/system/graphics.h)\n- [`system/core/include/system/graphics-base.h`](https://android.googlesource.com/platform/system/core/+/android16-release/libsystem/include/system/graphics-base.h)\n - `HAL_DATASPACE_*`\n - `HAL_COLOR_MODE_*`"]]