Utiliser DirectX avec des couleurs avancées sur des affichages à plage dynamique étendues/standard

Cette rubrique montre comment utiliser DirectX avec des scénarios Couleur avancée, notamment une plage dynamique élevée (HDR), une large gamme de couleurs (WCG) avec gestion automatique des couleurs système et une profondeur de bits élevée. Les écrans d’ordinateurs personnels Premium avec au moins l’une des améliorations ci-dessus sont de plus en plus répandus, offrant une fidélité des couleurs nettement supérieure à celle des affichages à plage dynamique standard (SDR).

Dans cette rubrique, vous allez obtenir une vue d’ensemble des concepts techniques clés de la prise en charge de Windows Advanced Color. Vous découvrirez les exigences et les instructions pour le rendu du contenu HDR, WCG et DirectX à profondeur de bits élevée sur l’un de ces écrans. Si vous disposez d’une application gérée par les couleurs (par exemple, en utilisant des profils ICC), vous allez découvrir comment la gestion automatique des couleurs permet une meilleure précision des couleurs pour vos scénarios.

Présentation de la couleur avancée dans Windows

Advanced Color est un terme générique de technologies de système d’exploitation (OS) pour les écrans avec une fidélité des couleurs nettement supérieure à celle des affichages standard. Les fonctionnalités étendues prédominantes sont décrites dans les sections ci-dessous. Les fonctionnalités de couleur avancées ont d’abord été introduites pour les écrans HDR avec Windows 10, version 1709 (Fall Creators Update) et pour les affichages SDR spécialement provisionnés avec le Windows 11, version 22H2 (10.0; Build 22621) version.

Plage dynamique élevée

La plage dynamique fait référence à la différence entre la luminosité maximale et la luminosité minimale dans une scène ; cela est souvent mesuré en nits (candelas par centimètre carré). Les scènes du monde réel, telles que ce coucher de soleil, ont souvent des plages dynamiques de 10 ordres de grandeur de luminosité; l’œil humain peut discerner une plage encore plus grande après adaptation.

Depuis Direct3D 9, les moteurs graphiques ont été en mesure de restituer leurs scènes en interne avec ce niveau de fidélité physiquement précise. Toutefois, un affichage de plage dynamique standard ne peut reproduire qu’un peu plus de 3 ordres de grandeur de la luminance, et par conséquent, tout contenu rendu HDR a dû être tonmapped (compressé) dans la plage limitée de l’affichage. Les nouveaux écrans HDR, y compris ceux qui sont conformes à la norme HDR10 (BT.2100), franchissent cette limitation ; par exemple, les affichages auto-émissifs de haute qualité peuvent atteindre plus de 6 ordres de grandeur.

Large gamme de couleurs

La gamme de couleurs fait référence à la plage et à la saturation des teintes qu’un affichage peut reproduire. Les couleurs naturelles les plus saturées que l’œil humain peut percevoir se composent d’une lumière monochromatique pure telle que celle produite par les lasers. Toutefois, les affichages grand public peuvent souvent reproduire les couleurs uniquement dans la gamme sRGB, qui ne représente qu’environ 35 % de toutes les couleurs visibles par l’homme. Le diagramme ci-dessous est une représentation du « locus spectral » humain, ou toutes les couleurs perceptibles (à un niveau de luminance donné), où le plus petit triangle est la gamut sRGB.

Les écrans pc professionnels haut de gamme ont de longues gammes de couleurs prises en charge qui sont considérablement plus larges que sRGB, comme Adobe RGB et DCI-P3, qui couvrent environ la moitié des couleurs visibles par l’homme. Et ces affichages à large gamme sont de plus en plus courants.

Gestion automatique des couleurs système

La gestion des couleurs est la technologie et la pratique visant à garantir une reproduction exacte et cohérente des couleurs sur les appareils. Si vous êtes un créateur de contenu numérique, il est essentiel que les couleurs de votre contenu visuel( comme une photo, une image de produit ou un logo) apparaissent de la même façon sur votre écran que sur la grande variété d’appareils numériques de votre public.

Windows fournit des API de prise en charge de la gestion des couleurs depuis Windows 2000 avec les API ICM (Image Color Management) et ultérieures du Système de couleurs Windows (WCS). Toutefois, ces API étaient uniquement des aides pour les applications qui souhaitaient/nécessitaient d’effectuer une gestion des couleurs ; alors que la plupart des applications et du contenu numérique ont simplement assumé l’espace de couleurs sRGB standard et n’ont jamais été gérés par le système d’exploitation. C’était une hypothèse raisonnable dans le passé, mais les affichages à large gamme de haute qualité deviennent beaucoup plus courants.

Les nouvelles versions de Windows prennent en charge la gestion automatique des couleurs système ; qui garantit que toutes les couleurs de chaque application Windows, qu’elles soient ou non compatibles avec les couleurs, s’affichent avec précision et cohérence sur chaque affichage pris en charge.

Notes

La gestion automatique des couleurs n’est pas une propriété du matériel d’affichage ; au lieu de cela, il s’agit d’une fonctionnalité Windows pour prendre correctement en charge les affichages qui ont des gammes de couleurs plus grandes que sRGB.

Précision/profondeur de bits

La précision numérique, ou profondeur de bits, fait référence à la quantité d’informations utilisées pour identifier les couleurs de manière unique. Une profondeur de bits plus élevée signifie que vous pouvez faire la distinction entre des couleurs très similaires sans artefacts tels que les bandes. Les écrans PC standard prennent en charge 8 bits par canal de couleur, tandis que l’œil humain nécessite au moins 10 à 12 bits de précision pour éviter les distorsions perceptibles.

Avant La couleur avancée, le Gestionnaire de fenêtres de bureau (DWM) limitait les applications fenêtrés à la sortie du contenu à seulement 8 bits par canal de couleur, même si l’affichage prend en charge une profondeur de bits plus élevée. Lorsque la couleur avancée est activée, la DWM effectue sa composition à l’aide de la virgule flottante demi-précision IEEE (FP16), éliminant les goulots d’étranglement et autorisant l’utilisation de la précision complète de l’affichage.

Architecture système Windows Advanced Color

Les informations de cette section sont facultatives pour la création d’applications Advanced Color ; mais il est utile de comprendre le fonctionnement de la technologie afin d’optimiser le rendu et le comportement de votre application.

Dans cette section, nous allons utiliser un diagramme simplifié pour décrire les composants pertinents de la pile graphique Windows :

Windows existant : affichages 8 bits/sRGB

Pendant des décennies, les affichages grand public et la pile graphique Windows étaient basés sur environ 8 bits par canal (24 bits par pixel) contenu sRGB. Les applications utilisant des API graphiques telles que DirectX peuvent effectuer un rendu interne à l’aide de profondeurs de bits élevées et d’espaces de couleurs étendus ; Toutefois, le système d’exploitation ne prenait en charge que l’entier 8 bits avec sRGB implicite et aucune gestion des couleurs système :

Cela signifiait que toutes les données de couleur supplémentaires rendues par une application seraient perdues lors de l’affichage ; et que l’application devait effectuer elle-même la gestion des couleurs pour garantir une reproduction précise sur un écran.

Windows 10, version 1703 : affichages HDR avec couleur avancée

Windows 10, la version 1703 a introduit la première version des fonctionnalités Advanced Color pour les affichages HDR. Cela a nécessité plusieurs avancées significatives dans la pile graphique du système d’exploitation :

• Prise en charge de la signalisation d’affichage HDR
• Composition système utilisant un espace de couleur canonique de profondeur de bits élevé
• Gestion automatique des couleurs système

Chaque avancement est abordé dans les sous-sections ci-dessous. Le résultat net est que les données de couleur d’application étendues sont maintenant correctement conservées par le système d’exploitation et reproduites avec précision sur les écrans HDR.

Prise en charge de la signalisation d’affichage HDR

La signalisation HDR sur des connecteurs d’affichage tels que DisplayPort et HDMI utilise principalement 10 bits par précision de canal (ou supérieure) et l’espace de couleur BT.2100 ST.2084. Le noyau d’affichage, le pilote d’affichage et le matériel GPU sous-jacent doivent tous prendre en charge la détection, la sélection et la conduite de ce mode de signalisation.

Composition système utilisant un espace de couleur canonique de profondeur de bits élevé

L’espace de couleurs BT.2100 ST.2084 est une norme efficace pour l’encodage des couleurs HDR, mais il n’est pas bien adapté à de nombreuses opérations de rendu et de composition (fusion). Nous voulons également assurer la pérennisation du système d’exploitation pour prendre en charge les technologies et les espaces de couleurs bien au-delà de BT.2100, qui couvre moins de 2/3 de couleurs visibles par l’homme. Enfin, si possible, nous voulons réduire la consommation de ressources GPU afin d’améliorer la puissance et les performances.

En mode HDR, desktop Window Manager (DWM) utilise un espace de couleur de composition canonique (CCCS) défini comme suit :

• Espace de couleur scRGB (primaires BT.709/sRGB avec gamma linéaire)
• Demi-précision IEEE (profondeur de bits FP16)

Cela fournit un bon équilibre entre tous les objectifs ci-dessus. CCCS autorise les valeurs de couleur en dehors de la plage numérique [0, 1] ; étant donné la plage de valeurs FP16 valides, il peut représenter des ordres de grandeur plus de couleurs que la plage visuelle humaine naturelle, y compris les valeurs de luminance supérieures à 5 millions de nits. FP16 offre une excellente précision pour les opérations de fusion gamma linéaires, mais coûte la moitié de la consommation de mémoire gpu et de la bande passante de la précision unique traditionnelle (FP32) sans perte de qualité perceptible.

Gestion automatique des couleurs système

Windows est un environnement multitâche dans lequel l’utilisateur peut exécuter n’importe quel nombre d’applications SDR et HDR en même temps avec des fenêtres qui se chevauchent. Par conséquent, il est essentiel que tous les types de contenu soient corrects et de qualité maximale lors de la sortie vers un affichage ; par exemple, une application de productivité sRGB (SDR) avec une fenêtre vidéo BT.2100 ST.2084 (HDR) lue sur celle-ci.

En mode HDR, Windows effectue des opérations de gestion des couleurs en deux étapes :

1. Le DWM convertit chaque application de son espace de couleurs natif en CCCS avant la fusion.
2. Le noyau d’affichage convertit le framebuffer du système d’exploitation de CCCS en espace de couleur de format de fil (BT.2100 ST.2084).
   • Si vous le souhaitez, le noyau d’affichage fonctionne avec le pilote d’affichage pour effectuer un étalonnage supplémentaire des couleurs d’affichage ; Pour plus d’informations, consultez Pipeline d’étalonnage des couleurs d’affichage matériel Windows.

Notes

Dans les deux phases, l’opération de gestion des couleurs se compose d’une conversion d’espace de couleurs (matrice et 1DLUT). Les couleurs qui dépassent la gamme de couleurs cible de l’affichage sont découpées numériquement.

Windows 11, version 22H2 : affichageSDR avec couleur avancée

Bien que la prévalence des affichages HDR augmente rapidement, les affichages SDR resteront importants pour les années à venir. La prise en charge de HDR dans Windows 10 version 1703 a également posé la plupart des bases nécessaires pour améliorer les affichages SDR. Windows 11, la version 22H2 étend les fonctionnalités avancées de gestion des couleurs et des couleurs automatiques à certains affichages SDR éligibles. Le diagramme de blocs graphiques pour les affichages SDR Advanced Color ressemble beaucoup à HDR :

Prise en charge de la signalisation d’affichage SDR avec une profondeur de bits élevée

La signalisation sous-jacente pour les affichages SDR est inchangée, bien que la version 22H2 du Windows 11 prenne en charge 10 bits par canal et plus, en fonction des fonctionnalités de l’affichage.

Composition système utilisant un espace de couleur canonique de profondeur de bits élevé

La fonctionnalité de couleur avancée DWM, y compris la fusion dans CCCS, est presque entièrement inchangée par rapport aux écrans HDR. La différence main est que DWM utilise la luminance référencée par l’affichage avec des affichages SDR, et la luminance référencée par scène avec des affichages HDR. Cela change la façon dont le contenu rendu de votre couleur avancée est interprété par le système d’exploitation :

Type d’affichage	Comportement de luminance	Comment la version 1.0f est-elle interprétée
SDR	Affichage référencé	En tant que niveau blanc de référence de l’affichage
HDR	Référence à la scène	80 nits (référence nominale blanche)

Gestion automatique des couleurs système

Les fonctionnalités de gestion des couleurs du système d’exploitation sont également pour la plupart inchangées par rapport aux affichages HDR. La main différence est que le noyau d’affichage est converti en espace de couleurs de référence à l’affichage tel que défini par les données de colorimétrie et d’étalonnage de l’affichage, au lieu de l’espace de couleurs STANDARD BT.2100 ST.2084 pour les affichages HDR.

Affichage obligatoire de l’approvisionnement

Des données précises d’un profil ICC MHC sont nécessaires pour définir l’opération de gestion des couleurs de sortie du noyau d’affichage. Par conséquent, seuls les affichages SDR qui ont été spécifiquement provisionnés par le fabricant ou un fournisseur d’étalonnage d’affichage avec un profil valide sont éligibles à la gestion automatique des couleurs. Pour plus d’informations, consultez Comportement du profil ICC avec Couleur avancée .

Configuration requise et prise en charge du système d’exploitation

Windows 10, la version 1709 a d’abord fourni la prise en charge des couleurs avancées pour les affichages HDR. La version 22H2 du Windows 11 ajoute la prise en charge des couleurs avancées pour les affichages SDR qui ont des données d’approvisionnement précises.

Cette rubrique part du principe que votre application cible Windows 10, version 2004 (ou ultérieure) pour les affichages HDR, et que l’Windows 11 version 22H2 (ou ultérieure) pour les affichages SDR.

Affichage

Un affichage à plage dynamique élevée doit implémenter la norme HDR10 ou BT.2100 ST.2084. La qualité d’affichage HDR peut varier considérablement, et nous vous recommandons vivement d’afficher des affichages certifiés, tels que VESA DisplayHDR. À compter de la version Windows 11, version 22H2, Windows affiche la status de certification des affichages connus dans l’application Paramètres.

Un affichage de plage dynamique standard doit avoir des données d’approvisionnement de couleurs précises pour la prise en charge des couleurs avancées. Dans la version Windows 11, version 22H2, la seule méthode prise en charge pour remplacer ces données est via un profil ICC MHC ; en outre, l’utilisateur ou le fabricant de l’affichage doit avoir activé la gestion automatique des couleurs. Pour plus d’informations, consultez Comportement du profil ICC avec couleur avancée.

Processeur graphique (GPU)

Pour une fonctionnalité couleur avancée complète sur les affichages SDR et HDR, un GPU récent est requis :

• AMD Radeon RX série 400 (Polaris), ou plus récente
• SÉRIE NVIDIA GeForce 10 (Pascal) ou plus récente
• Intel Core 10e génération (Ice Lake) sélectionné ou plus récent*

Notes

Les chipsets Comet Lake (code de modèle à 5 chiffres) nom de code Intel ne fournissent pas toutes les fonctionnalités.

Des exigences matérielles supplémentaires peuvent s’appliquer, selon les scénarios, notamment l’accélération du codec matériel (10 bits HEVC, 10 bits VP9, etc.) et la prise en charge de PlayReady (SL3000). Pour plus d’informations, contactez votre fournisseur DE GPU.

Pilote graphique (WDDM)

Le dernier pilote graphique disponible est fortement recommandé, soit à partir de Windows Update, soit à partir du site web du fournisseur de GPU ou du fabricant de PC. Cette rubrique s’appuie sur les fonctionnalités de pilote de WDDM 2.7 (Windows 10, version 2004) pour les affichages HDR et WDDM 3.0 (Windows 11, version 21H2) pour les affichages SDR.

API de rendu prises en charge

Windows 10 prend en charge un large éventail d’API et d’infrastructures de rendu. La prise en charge avancée des couleurs repose fondamentalement sur la capacité de votre application à effectuer une présentation moderne à l’aide de DXGI ou des API de couche visuelle.

• Infrastructure graphique DirectX (DXGI)
• Couche visuelle (Windows.UI.Composition)

Par conséquent, toute API de rendu qui peut générer une sortie vers l’une de ces méthodes de présentation peut prendre en charge la couleur avancée. Cela inclut (mais sans s’y limiter) les éléments ci-dessous.

• Direct3D 11
• Direct3D 12
• Direct2D
• Win2D
  • Nécessite l’utilisation des API CanvasSwapChain ou CanvasSwapChainPanel de niveau inférieur.
• Windows.UI.Input.Inking
  • Prend en charge le rendu d’encre sèche personnalisé à l’aide de DirectX.
• XAML
  • Prend en charge la lecture de vidéos HDR à l’aide de MediaPlayerElement.
  • Prend en charge le décodage d’images JPEG XR à l’aide de l’élément Image .
  • Prend en charge l’interopérabilité DirectX à l’aide de SwapChainPanel.

Gestion des fonctionnalités d’affichage dynamique

Windows 10 prend en charge une vaste gamme d’écrans avancés compatibles couleur, des panneaux intégrés à efficacité énergétique aux moniteurs et téléviseurs de jeu haut de gamme. Les utilisateurs Windows s’attendent à ce que votre application gère en toute transparence toutes ces variantes, y compris les affichages SDR existants omniprésents.

Windows 10 permet à l’utilisateur de contrôler les fonctionnalités HDR et Advanced Color. Votre application doit détecter la configuration de l’affichage actuel et répondre dynamiquement à toute modification de la fonctionnalité. Cela peut se produire pour de nombreuses raisons, par exemple, parce que l’utilisateur a activé ou désactivé une fonctionnalité, ou déplacé l’application entre différents affichages, ou parce que l’état d’alimentation du système a changé.

Option 1 : AdvancedColorInfo

Notes

L’API AdvancedColorInfo Windows Runtime est utilisable indépendamment de l’API de rendu, prend en charge les couleurs avancées pour les affichages SDR et utilise des événements pour signaler quand les fonctionnalités changent. Toutefois, il n’est disponible que pour les applications plateforme Windows universelle (UWP) ; les applications de bureau (qui n’ont pas de CoreWindow) ne peuvent pas l’utiliser. Pour plus d’informations, consultez Windows Runtime API non prises en charge dans les applications de bureau.

Tout d’abord, obtenez une instance d’AdvancedColorInfo à partir de DisplayInformation::GetAdvancedColorInfo.

Pour case activée le type de couleur avancé actuellement actif, utilisez la propriété AdvancedColorInfo::CurrentAdvancedColorKind. Il s’agit de la propriété la plus importante à case activée, et vous devez configurer votre pipeline de rendu et de présentation en réponse au type actif :

Type de couleur avancé	Fonctionnalités d’affichage
SDR	Affichage SDR sans fonctionnalités de couleur avancées
WCG	Affichage SDR avec une haute profondeur de bits et une gestion automatique des couleurs
HDR	Affichage HDR avec toutes les fonctionnalités de couleur avancées

Pour case activée les types de couleurs avancés pris en charge, mais pas nécessairement actifs, appelez AdvancedColorInfo::IsAdvancedColorKindAvailable. Vous pouvez utiliser ces informations, par exemple, pour inviter l’utilisateur à accéder à l’application Paramètres Windows afin qu’il puisse activer la gestion hdr ou automatique des couleurs.

Les autres membres d’AdvancedColorInfo fournissent des informations quantitatives sur le volume de couleurs physiques du panneau (luminance et chrominance), correspondant aux métadonnées HDR statiques SMPTE ST.2086. Bien que ST.2086 ait été conçu à l’origine pour les affichages HDR, ces informations sont utiles et sont disponibles pour les affichages HDR et SDR. Vous devez utiliser ces informations pour configurer le mappage de tonalité et le mappage de gamut de votre application.

Pour gérer les modifications apportées aux fonctionnalités de couleur avancée, inscrivez-vous à l’événement DisplayInformation::AdvancedColorInfoChanged . Cet événement est déclenché si un paramètre des fonctionnalités de couleur avancée de l’affichage change pour une raison quelconque.

Gérez cet événement en obtenant une nouvelle instance d’AdvancedColorInfo et en vérifiant les valeurs qui ont changé.

IDXGIOutput6

Notes

L’interface IDXGIOutput6 de l’infrastructure graphique DirectX est disponible pour toutes les applications qui utilisent DirectX, qu’il s’agisse de bureau ou de plateforme Windows universelle (UWP). Toutefois, IDXGIOutput6ne prend pas en charge les affichages SDR avec des fonctionnalités de couleur avancées telles que la gestion automatique des couleurs ; il peut identifier uniquement les affichages HDR.

Si vous écrivez une application de bureau Win32 et que vous utilisez DirectX pour le rendu, utilisez DXGI_OUTPUT_DESC1 pour obtenir des fonctionnalités d’affichage. Obtenez une instance de ce struct via IDXGIOutput6::GetDesc1.

Pour case activée le type De couleur avancé actuellement actif, utilisez la propriété ColorSpace, qui est de type DXGI_COLOR_SPACE_TYPE et contient l’une des valeurs suivantes :

DXGI_COLOR_SPACE_TYPE	Fonctionnalités d’affichage
DXGI_COLOR_SPACE_RGB_FULL_G22_NONE_P709	Affichage SDR sans fonctionnalités de couleur avancées
DXGI_COLOR_SPACE_RGB_FULL_G2084_NONE_P2020	Affichage HDR avec toutes les fonctionnalités de couleur avancées

Notes

Les affichages SDR avec des fonctionnalités de couleur avancées sont également signalés comme DXGI_COLOR_SPACE_RGB_FULL_G22_NONE_P709 ; DXGI ne vous permet pas de faire la distinction entre les deux types.

Notes

DXGI ne vous permet pas de case activée les types de couleurs avancées qui sont pris en charge, mais pas actifs pour le moment.

La plupart des autres membres de DXGI_OUTPUT_DESC1 fournissent des informations quantitatives sur le volume de couleurs physiques du panneau (luminance et chrominance), correspondant aux métadonnées HDR statiques SMPTE ST.2086. Bien que ST.2086 ait été conçu à l’origine pour les affichages HDR, ces informations sont utiles et sont disponibles pour les affichages HDR et SDR. Vous devez utiliser ces informations pour configurer le mappage de tonalité et le mappage de gamut de votre application.

Les applications de bureau Win32 ne disposent pas d’un mécanisme natif pour répondre aux modifications de la fonctionnalité Couleur avancée. Au lieu de cela, si votre application utilise une boucle de rendu, vous devez interroger IDXGIFactory1::IsCurrent avec chaque image. S’il indique FALSE, vous devez obtenir une nouvelle DXGI_OUTPUT_DESC1 et case activée les valeurs qui ont changé.

En outre, votre pompe de messages Win32 doit gérer le WM_SIZE message, ce qui indique que votre application a peut-être déplacé entre différents affichages.

Notes

Pour obtenir une nouvelle DXGI_OUTPUT_DESC1, vous devez obtenir l’affichage actuel. Toutefois, vous ne devez pas appeler IDXGISwapChain::GetContainingOutput. En effet, les chaînes d’échange retournent une sortie DXGI obsolète une fois que DXGIFactory::IsCurrent est false ; et la recréation de la chaîne d’échange pour obtenir une sortie actuelle entraîne un écran noir temporaire. Au lieu de cela, nous vous recommandons d’énumérer les limites de toutes les sorties DXGI et de déterminer celle qui a la meilleure intersection avec les limites de votre fenêtre d’application.

L’exemple de code suivant provient de l’exemple d’application Direct3D 12 HDR sur GitHub.

// Retrieve the current default adapter.
ComPtr<IDXGIAdapter1> dxgiAdapter;
ThrowIfFailed(m_dxgiFactory->EnumAdapters1(0, &dxgiAdapter));

// Iterate through the DXGI outputs associated with the DXGI adapter,
// and find the output whose bounds have the greatest overlap with the
// app window (i.e. the output for which the intersection area is the
// greatest).

UINT i = 0;
ComPtr<IDXGIOutput> currentOutput;
ComPtr<IDXGIOutput> bestOutput;
float bestIntersectArea = -1;

while (dxgiAdapter->EnumOutputs(i, &currentOutput) != DXGI_ERROR_NOT_FOUND)
{
    // Get the retangle bounds of the app window
    int ax1 = m_windowBounds.left;
    int ay1 = m_windowBounds.top;
    int ax2 = m_windowBounds.right;
    int ay2 = m_windowBounds.bottom;

    // Get the rectangle bounds of current output
    DXGI_OUTPUT_DESC desc;
    ThrowIfFailed(currentOutput->GetDesc(&desc));
    RECT r = desc.DesktopCoordinates;
    int bx1 = r.left;
    int by1 = r.top;
    int bx2 = r.right;
    int by2 = r.bottom;

    // Compute the intersection
    int intersectArea = ComputeIntersectionArea(ax1, ay1, ax2, ay2, bx1, by1, bx2, by2);
    if (intersectArea > bestIntersectArea)
    {
        bestOutput = currentOutput;
        bestIntersectArea = static_cast<float>(intersectArea);
    }

    i++;
}

// Having determined the output (display) upon which the app is primarily being 
// rendered, retrieve the HDR capabilities of that display by checking the color space.
ComPtr<IDXGIOutput6> output6;
ThrowIfFailed(bestOutput.As(&output6));

DXGI_OUTPUT_DESC1 desc1;
ThrowIfFailed(output6->GetDesc1(&desc1));

Configuration de votre chaîne d’échange DirectX

Une fois que vous avez déterminé que l’affichage prend actuellement en charge les fonctionnalités de couleur avancées, configurez votre chaîne d’échange comme suit.

Utiliser un effet de modèle de présentation inversée

Lors de la création de votre chaîne d’échange à l’aide de l’une des commandes CreateSwapChainFor[Hwnd|Composition|Méthodes CoreWindow], vous devez utiliser le modèle de basculement DXGI en sélectionnant l’option DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL ou DXGI_SWAP_EFFECT_FLIP_DISCARD , ce qui rend votre chaîne d’échange éligible pour le traitement avancé des couleurs à partir de DWM et de diverses optimisations en plein écran. Pour plus d’informations, consultez Pour de meilleures performances, utilisez le modèle de basculement DXGI.

Option 1. Utiliser le format de pixels FP16 et l’espace de couleurs scRGB

Windows 10 prend en charge deux combinaisons main de format de pixels et d’espace de couleurs pour Couleur avancée. Sélectionnez-en un en fonction des exigences spécifiques de votre application.

Nous recommandons aux applications à usage général d’utiliser l’option 1. Il s’agit de la seule option qui fonctionne pour tous les types d’affichages couleur avancés, de contenu et d’API de rendu. Lors de la création de votre chaîne d’échange, spécifiez DXGI_FORMAT_R16G16B16A16_FLOAT dans votre DXGI_SWAP_CHAIN_DESC1. Par défaut, une chaîne d’échange créée avec un format de pixels à virgule flottante est traitée comme si elle utilisant l’espace de couleur DXGI_COLOR_SPACE_RGB_FULL_G10_NONE_P709. Il s’agit du même format de pixels et de l’espace de couleurs utilisés par le DWM.

Cette combinaison vous fournit la plage numérique et la précision pour spécifier n’importe quelle couleur physiquement possible et effectuer un traitement arbitraire, y compris le mélange.

Toutefois, cette option consomme 64 bits par pixel, ce qui double la consommation de bande passante et de mémoire GPU par rapport aux formats de pixels UINT8 traditionnels. En outre, scRGB utilise des valeurs numériques qui se trouvent en dehors de la plage normalisée [0, 1] pour représenter des couleurs qui se trouvent en dehors de la gamut sRGB et/ou qui sont supérieures à 80 nits de luminance. Par exemple, scRGB (1.0, 1.0, 1.0) encode le blanc D65 standard à 80 nits ; mais scRGB (12.5, 12.5, 12.5) encode le même blanc D65 à un 1000 nits beaucoup plus lumineux. Certaines opérations graphiques nécessitent une plage numérique normalisée, et vous devez soit modifier l’opération, soit normaliser à nouveau les valeurs de couleur.

La façon dont les valeurs de luminance sont interprétées avec cette option diffère entre les affichages SDR et HDR ; voir ci-dessous.

Option 2 : Utiliser le format de pixels UINT10/RVB10 et l’espace de couleur HDR10/BT.2100

L’option 2 est une optimisation des performances disponible uniquement si votre application remplit toutes les conditions suivantes :

• Cible un affichage HDR
• Utilise Direct3D 12 ou Direct3D 11
• La chaîne d’échange ne nécessite pas de fusion avec alpha/transparence

Si votre application ne remplit pas toutes ces conditions, vous devez utiliser l’option 1.

Toutefois, si votre application est éligible à l’option 2, cela peut offrir de meilleures performances si votre application consomme du contenu encodé en HDR10, tel qu’un lecteur vidéo, ou s’il sera principalement utilisé dans des scénarios en plein écran, tels qu’un jeu. Lors de la création de votre chaîne d’échange, vous devez envisager de spécifier DXGI_FORMAT_R10G10B10A2_UNORM dans DXGI_SWAP_CHAIN_DESC1. Par défaut, il est traité comme à l’aide de l’espace de couleurs sRGB ; Par conséquent, vous devez appeler explicitement IDXGISwapChain3::SetColorSpace1 et définir comme espace de couleurs DXGI_COLOR_SPACE_RGB_FULL_G2084_NONE_P2020, également appelé HDR10/BT.2100.

Cette option consomme les mêmes 32 bits par pixel que les formats de pixels SDR UINT8 traditionnels. En outre, sur certains GPU, cela élimine certains traitements nécessaires pour convertir le contenu au format filaire HDR10.

Utilisation d’une chaîne d’échange de couleurs avancée lorsque l’affichage est en mode SDR

Vous pouvez utiliser une chaîne d’échange de couleurs avancée même si l’affichage ne prend pas en charge toutes les fonctionnalités de couleur avancée. Dans ce cas, le Gestionnaire de fenêtres de bureau (DWM) inverse votre contenu pour qu’il s’adapte aux fonctionnalités de l’affichage en effectuant un découpage numérique. Par exemple, si vous effectuez un rendu sur une chaîne d’échange scRGB FP16 et que vous ciblez un affichage standard, tout ce qui se trouve en dehors de la plage numérique [0, 1] est coupé.

Ce comportement de downconversion se produit également si votre fenêtre d’application chevauche au moins deux affichages avec différentes fonctionnalités de couleur avancée. AdvancedColorInfo et IDXGIOutput6 sont abstraits pour signaler uniquement les caractéristiques de l’affichage main (main étant défini comme l’affichage contenant le centre de la fenêtre).

Faire correspondre le blanc de référence de votre application au niveau blanc de référence SDR du système d’exploitation

Notes

Le blanc de référence s’applique uniquement aux affichages HDR ; pour les affichages SDR Advanced Color, (1.0, 1.0, 1.0) signifie toujours la luminance blanche maximale que l’affichage peut reproduire.

Dans de nombreux scénarios, votre application souhaite afficher à la fois du contenu SDR et HDR ; par exemple, le rendu des sous-titres ou des contrôles de transport sur une vidéo HDR ou une interface utilisateur dans une scène de jeu. Il est important de comprendre le concept de niveau blanc de référence SDR pour vous assurer que votre contenu SDR semble correct sur un affichage HDR. Le blanc de référence indique la luminosité à laquelle un objet blanc diffus (comme une feuille de papier ou parfois une interface utilisateur) apparaît dans une scène HDR. Étant donné que les valeurs de couleur HDR ont une luminosité de référence de scène, une valeur de couleur particulière doit être affichée à un niveau de luminance absolu, et non par rapport à la valeur maximale possible du panneau. Par exemple, scRGB (1.0, 1.0, 1.0) et HDR10 (497, 497, 497) encodent exactement D65 blanc à 80 nits luminance. Windows permet à l’utilisateur d’ajuster le niveau blanc de référence SDR à sa préférence ; c’est la luminance à laquelle Windows affichera sRGB (1.0, 1.0, 1.0) à. Sur les moniteurs HDR de bureau, les niveaux de blanc de référence SDR sont généralement définis sur environ 200 nits.

Votre application HDR doit permettre à l’utilisateur de définir le niveau blanc de référence souhaité ou de lire la valeur configurée par le système. Vous devez mapper vos valeurs de couleur blanche diffuse dans votre scène au niveau blanc de référence SDR. Cela implique de multiplier votre framebuffer d’application dans un espace gamma linéaire.

Notes

Sur un écran qui prend en charge un contrôle de luminosité, comme sur un ordinateur portable, Windows ajuste également la luminance du contenu HDR (référence à la scène) pour qu’il corresponde au niveau de luminosité souhaité par l’utilisateur, mais qui est invisible pour l’application. Sauf si vous essayez de garantir une reproduction précise du signal HDR, vous pouvez généralement l’ignorer.

Si votre application restitue toujours SDR et HDR sur des surfaces distinctes et s’appuie sur la composition du système d’exploitation, Windows effectue automatiquement l’ajustement correct pour augmenter le contenu SDR au niveau blanc souhaité. Par exemple, si votre application utilise XAML et restitue le contenu HDR dans son propre SwapChainPanel.

Toutefois, si votre application effectue sa propre composition de contenu SDR et HDR sur une surface unique, vous êtes responsable de l’ajustement du niveau blanc de référence SDR vous-même. Sinon, le contenu SDR peut apparaître trop faible dans les conditions d’affichage classiques du bureau. Tout d’abord, vous devez obtenir le niveau blanc de référence SDR actuel, puis vous devez ajuster les valeurs de couleur de tout contenu SDR que vous affichez.

Étape 1. Obtenir le niveau blanc de référence SDR actuel

Vous pouvez obtenir le niveau blanc de référence SDR actuel de l’une des manières suivantes :

• Dans une application de bureau. DISPLAYCONFIG_SDR_WHITE_LEVEL et QueryDisplayConfig.
• Dans une application UWP. AdvancedColorInfo.SdrWhiteLevelInNits (à l’aide d’un CoreWindow).

Étape 2. Ajuster les valeurs de couleur du contenu SDR

Windows définit le niveau de blanc de référence nominal ou par défaut à 80 nits. Par conséquent, si vous deviez rendre un sRGB standard (1.0, 1.0, 1.0) blanc sur une chaîne d’échange FP16, il serait reproduit à 80 nits luminance. Pour faire correspondre le niveau blanc de référence défini par l’utilisateur, vous devez ajuster le contenu SDR de 80 nits au niveau spécifié via AdvancedColorInfo.SdrWhiteLevelInNits.

Si vous effectuez un rendu à l’aide de FP16 et scRGB, ou d’un espace de couleurs qui utilise le gamma linéaire (1.0), vous pouvez simplement multiplier la valeur de la couleur SDR par AdvancedColorInfo.SdrWhiteLevelInNits / 80. Si vous utilisez Direct2D, il existe une constante prédéfinie D2D1_SCENE_REFERRED_SDR_WHITE_LEVEL, qui a la valeur 80.

D2D1_VECTOR_4F inputColor; // Input SDR color value.
D2D1_VECTOR_4F outputColor; // Output color adjusted for SDR white level.
auto acInfo = ...; // Obtain an AdvancedColorInfo.

float sdrAdjust = acInfo->SdrWhiteLevelInNits / D2D1_SCENE_REFERRED_SDR_WHITE_LEVEL;

// Normally in DirectX, color values are manipulated in shaders on GPU textures.
// This example performs scaling on a CPU color value.
outputColor.r = inputColor.r * sdrAdjust; // Assumes linear gamma color values.
outputColor.g = inputColor.g * sdrAdjust;
outputColor.b = inputColor.b * sdrAdjust;
outputColor.a = inputColor.a;

Si vous effectuez un rendu à l’aide d’un espace de couleur gamma non linéaire tel que HDR10, l’exécution du réglage du niveau blanc SDR est plus complexe. Si vous écrivez votre propre nuanceur de pixels, envisagez de convertir en gamma linéaire pour appliquer le réglage.

Adapter le contenu HDR aux fonctionnalités de l’affichage à l’aide du mappage de tonalités

Les affichages HDR et Advanced Color varient considérablement en termes de leurs fonctionnalités. Par exemple, dans la luminance minimale et maximale et la gamme de couleurs qu’ils sont capables de reproduire. Dans de nombreux cas, votre contenu HDR contient des couleurs qui dépassent les capacités de l’affichage. Pour une qualité d’image optimale, il est important d’effectuer un mappage de tonalité HDR, en compressant essentiellement la plage de couleurs pour s’adapter à l’affichage tout en préservant au mieux l’intention visuelle du contenu.

Le paramètre unique le plus important pour lequel s’adapter est la luminance maximale, également appelée MaxCLL (niveau de lumière du contenu) ; les mappeurs de tonalité plus sophistiqués adapteront également la luminance minimale (MinCLL) et/ou les primaires de couleur.

Étape 1. Obtenir les fonctionnalités de volume de couleur de l’affichage

Applications de la plateforme Windows universelle (UWP)

Utilisez AdvancedColorInfo pour obtenir le volume de couleur de l’affichage.

Applications DirectX Win32 (bureau)

Utilisez DXGI_OUTPUT_DESC1 pour obtenir le volume de couleur de l’affichage.

Étape 2. Obtenir les informations de volume de couleur du contenu

Selon l’origine de votre contenu HDR, il existe plusieurs façons potentielles de déterminer sa luminance et ses informations sur la gamme de couleurs. Certains fichiers vidéo et image HDR contiennent des métadonnées SMPTE ST.2086. Si votre contenu a été rendu dynamiquement, vous pourrez peut-être extraire des informations de scène à partir des phases de rendu internes, par exemple, la source de lumière la plus brillante d’une scène.

Une solution plus générale, mais coûteuse en calcul, consiste à exécuter un histogramme ou un autre passage d’analyse sur le cadre rendu. L’exemple d’application de rendu d’image couleur avancée Direct2D sur GitHub montre comment procéder à l’aide de Direct2D ; les extraits de code les plus pertinents sont inclus ci-dessous :

// Perform histogram pipeline setup; this should occur as part of image resource creation.
// Histogram results in no visual output but is used to calculate HDR metadata for the image.
void D2DAdvancedColorImagesRenderer::CreateHistogramResources()
{
    auto context = m_deviceResources->GetD2DDeviceContext();

    // We need to preprocess the image data before running the histogram.
    // 1. Spatial downscale to reduce the amount of processing needed.
    DX::ThrowIfFailed(
        context->CreateEffect(CLSID_D2D1Scale, &m_histogramPrescale)
        );

    DX::ThrowIfFailed(
        m_histogramPrescale->SetValue(D2D1_SCALE_PROP_SCALE, D2D1::Vector2F(0.5f, 0.5f))
        );

    // The right place to compute HDR metadata is after color management to the
    // image's native colorspace but before any tonemapping or adjustments for the display.
    m_histogramPrescale->SetInputEffect(0, m_colorManagementEffect.Get());

    // 2. Convert scRGB data into luminance (nits).
    // 3. Normalize color values. Histogram operates on [0-1] numeric range,
    //    while FP16 can go up to 65504 (5+ million nits).
    // Both steps are performed in the same color matrix.
    ComPtr<ID2D1Effect> histogramMatrix;
    DX::ThrowIfFailed(
        context->CreateEffect(CLSID_D2D1ColorMatrix, &histogramMatrix)
        );

    histogramMatrix->SetInputEffect(0, m_histogramPrescale.Get());

    float scale = sc_histMaxNits / sc_nominalRefWhite;

    D2D1_MATRIX_5X4_F rgbtoYnorm = D2D1::Matrix5x4F(
        0.2126f / scale, 0, 0, 0,
        0.7152f / scale, 0, 0, 0,
        0.0722f / scale, 0, 0, 0,
        0              , 0, 0, 1,
        0              , 0, 0, 0);
    // 1st column: [R] output, contains normalized Y (CIEXYZ).
    // 2nd column: [G] output, unused.
    // 3rd column: [B] output, unused.
    // 4th column: [A] output, alpha passthrough.
    // We explicitly calculate Y; this deviates from the CEA 861.3 definition of MaxCLL
    // which approximates luminance with max(R, G, B).

    DX::ThrowIfFailed(histogramMatrix->SetValue(D2D1_COLORMATRIX_PROP_COLOR_MATRIX, rgbtoYnorm));

    // 4. Apply a gamma to allocate more histogram bins to lower luminance levels.
    ComPtr<ID2D1Effect> histogramGamma;
    DX::ThrowIfFailed(
        context->CreateEffect(CLSID_D2D1GammaTransfer, &histogramGamma)
        );

    histogramGamma->SetInputEffect(0, histogramMatrix.Get());

    // Gamma function offers an acceptable tradeoff between simplicity and efficient bin allocation.
    // A more sophisticated pipeline would use a more perceptually linear function than gamma.
    DX::ThrowIfFailed(histogramGamma->SetValue(D2D1_GAMMATRANSFER_PROP_RED_EXPONENT, sc_histGamma));
    // All other channels are passthrough.
    DX::ThrowIfFailed(histogramGamma->SetValue(D2D1_GAMMATRANSFER_PROP_GREEN_DISABLE, TRUE));
    DX::ThrowIfFailed(histogramGamma->SetValue(D2D1_GAMMATRANSFER_PROP_BLUE_DISABLE, TRUE));
    DX::ThrowIfFailed(histogramGamma->SetValue(D2D1_GAMMATRANSFER_PROP_ALPHA_DISABLE, TRUE));

    // 5. Finally, the histogram itself.
    HRESULT hr = context->CreateEffect(CLSID_D2D1Histogram, &m_histogramEffect);
    
    if (hr == D2DERR_INSUFFICIENT_DEVICE_CAPABILITIES)
    {
        // The GPU doesn't support compute shaders and we can't run histogram on it.
        m_isComputeSupported = false;
    }
    else
    {
        DX::ThrowIfFailed(hr);
        m_isComputeSupported = true;

        DX::ThrowIfFailed(m_histogramEffect->SetValue(D2D1_HISTOGRAM_PROP_NUM_BINS, sc_histNumBins));

        m_histogramEffect->SetInputEffect(0, histogramGamma.Get());
    }
}

// Uses a histogram to compute a modified version of MaxCLL (ST.2086 max content light level).
// Performs Begin/EndDraw on the D2D context.
void D2DAdvancedColorImagesRenderer::ComputeHdrMetadata()
{
    // Initialize with a sentinel value.
    m_maxCLL = -1.0f;

    // MaxCLL is not meaningful for SDR or WCG images.
    if ((!m_isComputeSupported) ||
        (m_imageInfo.imageKind != AdvancedColorKind::HighDynamicRange))
    {
        return;
    }

    // MaxCLL is nominally calculated for the single brightest pixel in a frame.
    // But we take a slightly more conservative definition that takes the 99.99th percentile
    // to account for extreme outliers in the image.
    float maxCLLPercent = 0.9999f;

    auto ctx = m_deviceResources->GetD2DDeviceContext();

    ctx->BeginDraw();

    ctx->DrawImage(m_histogramEffect.Get());

    // We ignore D2DERR_RECREATE_TARGET here. This error indicates that the device
    // is lost. It will be handled during the next call to Present.
    HRESULT hr = ctx->EndDraw();
    if (hr != D2DERR_RECREATE_TARGET)
    {
        DX::ThrowIfFailed(hr);
    }

    float *histogramData = new float[sc_histNumBins];
    DX::ThrowIfFailed(
        m_histogramEffect->GetValue(D2D1_HISTOGRAM_PROP_HISTOGRAM_OUTPUT,
            reinterpret_cast<BYTE*>(histogramData),
            sc_histNumBins * sizeof(float)
            )
        );

    unsigned int maxCLLbin = 0;
    float runningSum = 0.0f; // Cumulative sum of values in histogram is 1.0.
    for (int i = sc_histNumBins - 1; i >= 0; i--)
    {
        runningSum += histogramData[i];
        maxCLLbin = i;

        if (runningSum >= 1.0f - maxCLLPercent)
        {
            break;
        }
    }

    float binNorm = static_cast<float>(maxCLLbin) / static_cast<float>(sc_histNumBins);
    m_maxCLL = powf(binNorm, 1 / sc_histGamma) * sc_histMaxNits;

    // Some drivers have a bug where histogram will always return 0. Treat this as unknown.
    m_maxCLL = (m_maxCLL == 0.0f) ? -1.0f : m_maxCLL;
}

Étape 3. Effectuer l’opération de mappage de tonalité HDR

Le tonemapping est par nature un processus avec perte et peut être optimisé pour un certain nombre de métriques perceptives ou objectives. Il n’existe donc pas d’algorithme standard unique. Windows fournit un effet de tonmapper HDR intégré dans le cadre de Direct2D ainsi que dans le pipeline de lecture vidéo HDR Media Foundation. D’autres algorithmes couramment utilisés incluent ACES Filmic, Reinhard et ITU-R BT.2390-3 EETF (fonction de transfert électrique).

Un opérateur reinhard tonemapper simplifié est illustré dans cet exemple de code suivant.

// This example uses C++. A typical DirectX implementation would port this to HLSL.
D2D1_VECTOR_4F simpleReinhardTonemapper(
    float inputMax, // Content's maximum luminance in scRGB values, e.g. 1.0 = 80 nits.
    float outputMax, // Display's maximum luminance in scRGB values, e.g. 1.0 = 80 nits.
    D2D1_VECTOR_4F input // scRGB color.
)
{
    D2D1_VECTOR_4F output = input;

    // Vanilla Reinhard normalizes color values to [0, 1].
    // This modification scales to the luminance range of the display.
    output.r /= inputMax;
    output.g /= inputMax;
    output.b /= inputMax;

    output.r = output.r / (1 + output.r);
    output.g = output.g / (1 + output.g);
    output.b = output.b / (1 + output.b);

    output.r *= outputMax;
    output.g *= outputMax;
    output.b *= outputMax;

    return output;
}

Capture de contenu d’écran HDR et WCG

Les API qui prennent en charge la spécification des formats de pixels, tels que ceux de l’espace de noms Windows.Graphics.Capture , et la méthode IDXGIOutput5::D uplicateOutput1 , permettent de capturer du contenu HDR et WCG sans perdre d’informations de pixels. Notez qu’après l’acquisition des trames de contenu, un traitement supplémentaire est nécessaire. Par exemple, le mappage de tonalité HDR à SDR (par exemple, copie d’écran SDR pour le partage Internet) et l’enregistrement de contenu au format approprié (par exemple, JPEG XR).

Modifications apportées à la gestion des couleurs héritée et au comportement des profils ICC

La gestion avancée des couleurs et automatique des couleurs garantit une couleur d’affichage cohérente et précise du point de vue colorimétrique pour toutes les applications, héritées et modernes. Toutefois, certaines applications peuvent effectuer leur propre gestion explicite des couleurs à l’aide de profils de couleur ICC (International Color Consortium).

Lorsque la couleur avancée est active sur les affichages SDR ou HDR, le comportement des profils ICC d’affichage change de manière non compatible avec les versions descendantes. Si votre application fonctionne avec les profils ICC d’affichage, Windows offre des assistances de compatibilité pour s’assurer que votre application continue d’obtenir un comportement correct.

Pour plus d’informations sur les modifications apportées au comportement du profil ICC et sur la façon dont vous pouvez adapter votre application pour optimiser la compatibilité avec les couleurs avancées, consultez Comportement du profil ICC avec Couleur avancée.

Ressources supplémentaires

• Sur GitHub, utilisation du rendu HDR avec le kit d’outils DirectX pour DirectX 11 / DirectX 12. Procédure pas à pas pour ajouter la prise en charge HDR à une application DirectX à l’aide du Kit d’outils DirectX (DirectXTK).
• Exemple d’application de rendu d’image couleur avancée Direct2D. Exemple d’application du KIT de développement logiciel (SDK) UWP implémentant une visionneuse d’images HDR et WCG avec Direct2D. Illustre l’ensemble des meilleures pratiques pour les applications UWP, notamment la réponse aux modifications de la fonctionnalité d’affichage et l’ajustement du niveau blanc SDR.
• Exemple d’application de bureau Direct3D 12 HDR. Exemple de KIT de développement logiciel (SDK) de bureau implémentant une scène Direct3D 12 HDR de base.
• Exemple d’application UWP Direct3D 12 HDR. UWP équivalent de l’exemple ci-dessus.
• SimpleHDR_PC. Exemple d’application PC Xbox ATG SimpleHDR (exemple d’application de bureau) implémentant une scène Hdr Direct3D 11 de base.