Verwenden von DirectX mit erweiterter Farbe auf High/Standard Dynamic Range-Displays

Dieses Thema zeigt Ihnen, wie Sie DirectX mit Advanced Color-Szenarien verwenden können, einschließlich High Dynamic Range (HDR), Wide Color Gamut (WCG) mit automatischem Systemfarbmanagement und hoher Bittiefe. Premium PC-Displays mit mindestens einer der oben genannten Funktionen sind inzwischen weit verbreitet und bieten eine deutlich höhere Farbtreue als herkömmliche Standard Dynamic Range (SDR)-Displays.

In diesem Thema erhalten Sie einen Überblick über die wichtigsten technischen Konzepte hinter der Advanced Color-Unterstützung von Windows. Sie lernen die Anforderungen und Anweisungen für das Rendern von HDR-, WCG- und DirectX-Inhalten mit hoher Bittiefe auf einem dieser Bildschirme kennen. Wenn Sie eine farbverwaltete App haben (z. B. mit ICC-Profilen), dann erfahren Sie, wie die automatische Farbverwaltung eine bessere Farbgenauigkeit für Ihre Szenarien ermöglicht.

Einführung in Advanced Color in Windows

Advanced Color ist ein Oberbegriff für Betriebssystem-Technologien für Bildschirme mit deutlich höherer Farbtreue als bei Standardbildschirmen. Die wichtigsten erweiterten Funktionalitäten werden in den folgenden Abschnitten beschrieben. Advanced Color-Funktionalitäten wurden erstmals für HDR-Bildschirme mit Windows 10, Version 1709 (Fall Creators Update), und für speziell bereitgestellte SDR-Bildschirme mit der Windows 11, Version 22H2 (10.0; Build 22621), eingeführt.

High Dynamic Range (Hoher Dynamikbereich)

Der Dynamikbereich bezieht sich auf die Differenz zwischen der maximalen und minimalen Luminanz in einer Szene. Diese wird oft in Nits (Candela pro Quadratzentimeter) gemessen. In der realen Welt haben Szenen wie dieser Sonnenuntergang oft einen Dynamikbereich der Leuchtdichte in der Größenordnung von 10 Einheiten; das menschliche Auge kann nach Anpassung einen noch größeren Bereich wahrnehmen.

Seit Direct3D 9 sind Grafik-Engines in der Lage, ihre Szenen intern mit diesem Grad an physikalischer Genauigkeit zu rendern. Ein typischer Bildschirm mit Standard-Dynamikbereich kann jedoch nur etwas mehr als 3 Helligkeitsstufen wiedergeben. Daher mussten alle HDR-gerenderten Inhalte auf den begrenzten Dynamikbereich des Bildschirms gemappt (komprimiert) werden. Neue HDR-Bildschirme, einschließlich derjenigen, die dem Standard HDR10 (BT.2100) entsprechen, durchbrechen diese Beschränkung. Hochwertige selbstemittierende Bildschirme können beispielsweise mehr als 6 Größenordnungen erreichen.

Wide Color Gamut (breiter Farbraum)

Die Farbskala bezieht sich auf die Bandbreite und Sättigung der Farbtöne, die ein Bildschirm wiedergeben kann. Die am stärksten gesättigten natürlichen Farben, die das menschliche Auge wahrnehmen kann, bestehen aus reinem, monochromatischem Licht, wie es beispielsweise von Lasern erzeugt wird. Herkömmliche Bildschirme können jedoch oft nur Farben innerhalb der sRGB-Farbskala wiedergeben, die nur etwa 35 % aller vom Menschen wahrnehmbaren Farben umfasst. Das unten stehende Diagramm ist eine Darstellung des menschlichen „Spektralbereichs“ bzw. aller wahrnehmbaren Farben (bei einem bestimmten Leuchtdichtepegel), wobei das kleinere Dreieck den sRGB-Farbraum darstellt.

Professionelle High-End-PC-Bildschirme unterstützen seit Langem Farbräume, die deutlich breiter als sRGB sind, wie Adobe RGB und DCI-P3, die etwa die Hälfte der vom Menschen wahrnehmbaren Farben abdecken. Und diese Bildschirme mit einem größeren Farbraum werden immer häufiger verwendet.

Automatisches System-Farbmanagement

Farbmanagement ist eine Technologie und Methode, die eine genaue und konsistente Farbwiedergabe auf allen Geräten gewährleistet. Wenn Sie digitale Inhalte erstellen, ist es von entscheidender Bedeutung, dass die Farben Ihrer visuellen Inhalte – z. B. eines Fotos, eines Bildes oder eines Logos – auf Ihrem Bildschirm genauso dargestellt werden wie auf den zahlreichen digitalen Geräten Ihrer Zielgruppe.

Windows bietet seit Windows 2000 mit den APIs Image Color Management (ICM) und später mit Windows Color System (WCS) Unterstützung für das Farbmanagement. Diese APIs waren jedoch nur Hilfsmittel für Apps, die Farbmanagement betreiben wollten/brauchten. Die meisten Apps und digitalen Inhalte setzten einfach den Industriestandard sRGB-Farbraum voraus und wurden nie vom Betriebssystem farbverwaltet. Das war in der Vergangenheit eine vernünftige Annahme, aber hochwertige Bildschirme mit großem Farbraum werden immer häufiger eingesetzt.

Neue Versionen von Windows unterstützen die automatische Farbverwaltung des Systems. Dadurch wird sichergestellt, dass alle Farben in jeder Windows App, unabhängig davon, ob sie farbabhängig sind oder nicht, auf allen unterstützten Bildschirmen korrekt und konsistent dargestellt werden.

Hinweis

Die automatische Farbverwaltung ist keine Eigenschaft der Bildschirm-Hardware, sondern eine Funktion von Windows, um Bildschirme mit einem größeren Farbraum als sRGB zu unterstützen.

Tiefenpräzision/Bit-Tiefe

Die numerische Präzision oder Bit-Tiefe bezieht sich auf die Menge der Informationen, die zur eindeutigen Identifizierung von Farben verwendet werden. Eine höhere Bit-Tiefe bedeutet, dass Sie zwischen sehr ähnlichen Farben unterscheiden können, ohne dass Artefakte wie Banding auftreten. Herkömmliche Bildschirme unterstützen 8 Bits pro Farbkanal, während das menschliche Auge mindestens 10-12 Bits an Präzision benötigt, um wahrnehmbare Verfälschungen zu vermeiden.

Vor Advanced Color beschränkte der Desktop Window Manager (DWM) die Ausgabe von Apps mit Fenstern auf nur 8 Bit pro Farbkanal, selbst wenn der Bildschirm eine höhere Bit-Tiefe unterstützte. Wenn Advanced Color aktiviert ist, führt der DWM seine Composites unter Verwendung von IEEE Half-Precision Floating Point (FP16) durch, wodurch jegliche Engpässe beseitigt werden und die Möglichkeit besteht, die volle Präzision des Bildschirms zu nutzen.

Windows Advanced Color-Systemarchitektur

Die Informationen in diesem Abschnitt sind optional für die Erstellung von Advanced Color-Apps, aber es ist hilfreich zu verstehen, wie die Technologie funktioniert, um das Rendering und das Verhalten Ihrer App zu optimieren.

In diesem Abschnitt verwenden wir ein vereinfachtes Diagramm, um die relevanten Komponenten des Windows-Graphics-Stacks zu beschreiben:

Bisheriges Windows: 8-Bit / sRGB-Bildschirme

Jahrzehntelang basierten Consumer-Bildschirme und der Windows-Graphics-Stack auf sRGB-Inhalten mit 8 Bit pro Kanal (24 Bit pro Pixel). Apps, die Grafik-APIs wie DirectX verwenden, konnten internes Rendering mit hohen Bit-Tiefen und erweiterten Farbräumen durchführen; das Betriebssystem unterstützte jedoch nur 8-Bit-Integer mit implizitem sRGB und kein Systemfarbmanagement:

Das bedeutete, dass alle zusätzlichen Farbdaten, die von einer App gerendert wurden, bei der Anzeige verloren gingen und dass die App selbst ein Farbmanagement durchführen musste, um eine genaue Wiedergabe auf einem Bildschirm zu gewährleisten.

Windows 10, Version 1703: HDR-Bildschirme mit Advanced Color

Windows 10, Version 1703 führte die erste Version der Advanced Color-Funktionalitäten für HDR-Bildschirme ein. Dies erforderte mehrere bedeutende Fortschritte im Graphics-Stack des Betriebssystems:

• Unterstützung für HDR-Bildschirm-Signale
• Systemkomposition unter Verwendung eines kanonischen Farbraums mit hoher Bit-Tiefe
• Automatisches System-Farbmanagement

Die einzelnen Entwicklungen werden in den folgenden Unterabschnitten behandelt. Das Endergebnis ist, dass die Farbdaten von erweiterten Apps jetzt vom Betriebssystem korrekt beibehalten und auf HDR-Bildschirmen präzise wiedergegeben werden.

Unterstützung für HDR-Bildschirm-Signale

Die HDR-Signalübertragung über Bildschirmanschlüsse wie DisplayPort und HDMI verwendet in erster Linie eine Präzision von 10 Bit pro Kanal (oder mehr) und den Farbraum BT.2100 ST.2084. Der Display-Kernel, der Bildschirmtreiber und die zugrunde liegende GPU-Hardware müssen alle die Erkennung, Auswahl und Steuerung dieses Signalmodus unterstützen.

Systemkomposition unter Verwendung eines kanonischen Farbraums mit hoher Bit-Tiefe

Der BT.2100 ST.2084-Farbraum ist ein effizienter Standard für die Kodierung von HDR-Farben, aber er eignet sich nicht gut für viele Rendering- und Composite (Blending)-Vorgänge. Außerdem möchten wir das Betriebssystem zukunftssicher machen, um Technologien und Farbräume zu unterstützen, die weit über BT.2100 hinausgehen, das weniger als 2/3 der für den Menschen sichtbaren Farben abdeckt. Und schließlich möchten wir den Verbrauch von GPU-Ressourcen so weit wie möglich minimieren, um die Leistung zu verbessern.

Im HDR-Modus verwendet der Desktop Window Manager (DWM) einen kanonischen Composite-Farbraum (CCCS), der wie folgt definiert ist:

• scRGB-Farbraum (BT.709/sRGB-Primärfarben mit linearem Gamma)
• IEEE Half Precision (FP16 Bit-Tiefe)

Das bietet ein gutes Gleichgewicht zwischen allen oben genannten Zielen. CCCS bietet die Möglichkeit, Farbwerte außerhalb des numerischen Bereichs [0, 1] darzustellen. Angesichts der Bandbreite gültiger FP16-Werte kann es um Größenordnungen mehr Farben darstellen als der natürliche menschliche Sehbereich, einschließlich Luminanzwerten über 5 Millionen Nits. FP16 bietet eine hervorragende Präzision für lineare Gamma-Blending-Vorgänge, benötigt aber nur die Hälfte des GPU-Speicherverbrauchs und der Bandbreite im Vergleich zu herkömmlicher einfacher Präzision (FP32), ohne dass ein Qualitätsverlust spürbar wäre.

Automatisches System-Farbmanagement

Windows ist eine Multitasking-Umgebung, in der die Benutzer*innen eine beliebige Anzahl von SDR- und HDR-Apps gleichzeitig ausführen können, wobei sich die Fenster überlappen. Daher ist es wichtig, dass alle Arten von Inhalten bei der Ausgabe auf einem Bildschirm korrekt und in maximaler Qualität dargestellt werden, z. B. eine sRGB (SDR) Produktivitäts-App mit einem BT.2100 ST.2084 (HDR)-Videofenster, das darüber wiedergegeben wird.

Im HDR-Modus führt Windows die Vorgänge des Farbmanagements in zwei Stufen durch:

1. Der DWM konvertiert jede App vor dem Blending von ihrem nativen Farbraum in CCCS.
2. Der Display-Kernel konvertiert den Framebuffer des Betriebssystems von CCCS in den Wire-Format-Farbraum (BT.2100 ST.2084).
   • Optional arbeitet der Display-Kernel mit dem Bildschirmtreiber zusammen, um eine zusätzliche Farbkalibrierung des Bildschirms durchzuführen. Weitere Informationen finden Sie unter Windows Hardware Display Color Calibration Pipeline.

Hinweis

In beiden Stufen besteht der Vorgang des Farbmanagements aus einer Farbraumkonvertierung (Matrix und 1DLUT). Farben, die den Zielfarbraum des Bildschirms überschreiten, werden numerisch beschnitten.

Windows 11, Version 22H2: SDR-Bildschirme mit Advanced Color

Während die Verbreitung von HDR-Bildschirmen rapide zunimmt, werden SDR-Bildschirme auch in den kommenden Jahren wichtig bleiben. Der HDR-Support in Windows 10, Version 1703 hat die meisten Voraussetzungen geschaffen, um auch SDR-Bildschirme zu verbessern. Windows 11, Version 22H2 erweitert die Funktionalitäten von Advanced Color und der automatischen Farbverwaltung auf bestimmte qualifizierte SDR-Bildschirme. Das Grafikblockdiagramm für Advanced Color-SDR-Bildschirme sieht HDR sehr ähnlich:

Unterstützung der SDR-Bildschirm-Signalgebung mit hoher Bit-Tiefe

Die zugrunde liegende Signalisierung für SDR-Bildschirme ist unverändert, obwohl Windows 11, Version 22H2 je nach den Funktionalitäten des Bildschirms 10 Bit pro Kanal und mehr unterstützt.

Systemkomposition unter Verwendung eines kanonischen Farbraums mit hoher Bit-Tiefe

Die DWM Advanced Color-Funktionalität, einschließlich Blending in CCCS, ist gegenüber HDR-Bildschirmen fast völlig unverändert. Der Hauptunterschied besteht darin, dass DWM bei SDR-Bildschirmen eine auf den Bildschirm bezogene Luminanz und bei HDR-Bildschirmen eine szenenbezogene Luminanz verwendet. Dadurch ändert sich die Art und Weise, wie Ihre mit Advanced Color gerenderten Inhalte vom Betriebssystem interpretiert werden:

Art des Bildschirms	Luminanzverhalten	Interpretation von 1.0f
SDR	Display-referred	Als Referenzweißwert des Bildschirms
HDR	Scene-referred	Als 80 nits (nominales Referenzweiß)

Automatisches System-Farbmanagement

Die Funktionalitäten des Farbmanagements des Betriebssystems sind auch bei HDR Bildschirmen weitgehend unverändert. Der Hauptunterschied besteht darin, dass der Display-Kernel anstelle des Standardfarbraums BT.2100 ST.2084 für HDR-Bildschirme in den durch die Farbmess- und Kalibrierungsdaten des Bildschirms definierten bildschirmbezogenen Farbraum konvertiert.

Bildschirm-Bereitstellung erforderlich

Für die Definition des Vorgangs der Ausgabefarbverwaltung des Display-Kernels werden genaue Daten aus einem MHC-ICC-Profil benötigt. Daher kommen nur SDR-Bildschirme für das automatische Farbmanagement in Frage, die vom Hersteller oder einem Anbieter von Bildschirmkalibrierungen mit einem gültigen Profil bereitgestellt wurden. Weitere Informationen finden Sie unter ICC-Profilverhalten mit Advanced Color.

Systemvoraussetzungen und Unterstützung für das Betriebssystem

Windows 10, Version 1709, hat erstmals Advanced Color-Unterstützung für HDR-Bildschirme bereitgestellt. Mit Windows 11, Version 22H2, wird die Advanced Color-Unterstützung für SDR-Bildschirme mit genauen Versionsverwaltungsdaten hinzugefügt.

In diesem Thema wird davon ausgegangen, dass Ihre App für HDR-Bildschirme unter Windows 10, Version 2004 (oder höher), und für SDR-Bildschirme unter Windows 11, Version 22H2 (oder höher), eingesetzt wird.

Anzeige

Ein High Dynamic Range-Bildschirm muss den Standard HDR10 bzw. BT.2100 ST.2084 implementieren. Die Qualität von HDR-Bildschirmen kann sehr unterschiedlich sein. Wir empfehlen daher dringend Bildschirme, die zertifiziert sind, wie VESA DisplayHDR. Ab Windows 11, Version 22H2, zeigt Windows den Zertifizierungsstatus bekannter Bildschirme in der App Einstellungen an.

Ein Bildschirm mit Standard-Dynamikbereich muss über genaue Farbbereitstellungsdaten für die Unterstützung von Advanced Color verfügen. In Windows 11, Version 22H2, ist die einzige unterstützte Methode, diese Daten zu überschreiben, ein MHC ICC-Profil; außerdem müssen die Benutzer*innen oder der Hersteller des Bildschirms die automatische Farbverwaltung aktiviert haben. Weitere Informationen finden Sie unter ICC-Profilverhalten mit Advanced Color.

Grafikprozessor (GPU)

Für die volle Funktionalität von Advanced Color auf SDR- und HDR-Bildschirmen ist eine aktuelle GPU erforderlich:

• AMD Radeon RX 400 Serie (Polaris) oder neuer
• NVIDIA GeForce 10-Serie (Pascal) oder neuer
• Ausgewählter Intel Core der 10. Generation (Ice Lake) oder neuer*

Hinweis

Die Chipsätze mit dem Intel Code-Namen Comet Lake (5-stelliger Modellcode) bieten nicht die volle Funktionalität.

Je nach Szenario können zusätzliche Hardwareanforderungen gelten, einschließlich Hardware-Codec-Beschleunigung (10 Bit HEVC, 10 Bit VP9 usw.) und PlayReady Unterstützung (SL3000). Wenden Sie sich an Ihren GPU-Hersteller, um genauere Informationen zu erhalten.

Grafiktreiber (WDDM)

Es wird dringend empfohlen, den neuesten verfügbaren Grafiktreiber zu verwenden, entweder von Windows Update oder von der Website des GPU-Herstellers oder PC-Herstellers. Dieses Thema stützt sich auf die Treiberfunktionalität von WDDM 2.7 (Windows 10, Version 2004) für HDR-Bildschirme und WDDM 3.0 (Windows 11, Version 21H2) für SDR-Bildschirme.

Unterstützte Rendering-APIs

Windows 10 unterstützt eine breite Palette von Rendering-APIs und Frameworks. Die Unterstützung für Advanced Color setzt voraus, dass Ihre App in der Lage ist, moderne Darstellungen mit DXGI- oder den Visual Layer-APIs durchzuführen.

• DirectX Graphics Infastructure (DXGI)
• Visual Layer (Windows.UI.Composition)

Daher kann jede Rendering-API, die eine dieser Präsentationsmethoden ausgeben kann, Advanced Color unterstützen. Dies umfasst (ist aber nicht beschränkt auf) die Folgenden.

• Direct3D 11
• Direct3D 12
• Direct2D
• Win2D
  • Erfordert die Verwendung der Low-Level-APIs CanvasSwapChain oder CanvasSwapChainPanel.
• Windows.UI.Input.Inking
  • Unterstützt angepasstes Dry-Ink-Rendering mit DirectX.
• XAML
  • Unterstützt die Wiedergabe von HDR-Videos mit MediaPlayerElement.
  • Unterstützt die Dekodierung von JPEG-XR-Bildern mit dem Image-Element.
  • Unterstützt DirectX-Interop mit SwapChainPanel.

Handling dynamischer Funktionalitäten des Bildschirms

Windows 10 unterstützt eine enorme Bandbreite an Advanced Color-fähigen Bildschirmen, von stromsparenden integrierten Panels bis hin zu High-End-Gaming-Monitoren und Fernsehern. Benutzer*innen von Windows erwarten, dass Ihre App nahtlos mit all diesen Varianten umgehen kann, einschließlich der allgegenwärtigen SDR-Bildschirme.

Windows 10 bietet den Benutzer*innen die Kontrolle über die Funktionalitäten von HDR und Advanced Color. Ihre App muss die aktuelle Konfiguration des Bildschirms erkennen und dynamisch auf alle Änderungen der Funktionalitäten reagieren. Das kann viele Gründe haben, z. B. weil der/die Benutzer*in eine Funktion aktiviert oder deaktiviert hat, die App zwischen verschiedenen Bildschirmen hin- und hergeschoben hat oder weil sich der Energiestatus des Systems geändert hat.

Option 1: AdvancedColorInfo

Hinweis

Die AdvancedColorInfo-Windows-Runtime-API ist unabhängig von der Rendering-API nutzbar, unterstützt Advanced Color für SDR-Bildschirme und verwendet Ereignisse, um zu signalisieren, wenn sich Funktionalitäten ändern. Sie ist jedoch nur für Universal Windows Platform (UWP)-Apps verfügbar. Desktop-Apps (die kein CoreWindow haben) können sie nicht verwenden. Weitere Informationen finden Sie unter Windows-Runtime-APIs, die in Desktop-Apps nicht unterstützt werden.

Rufen Sie zunächst eine Instanz von AdvancedColorInfo von DisplayInformation::GetAdvancedColorInfo ab.

Um zu überprüfen, welcher Advanced Color-Typ gerade aktiv ist, verwenden Sie die Eigenschaft AdvancedColorInfo::CurrentAdvancedColorKind. Das ist die wichtigste Eigenschaft, die Sie überprüfen müssen. Sie sollten Ihre Render- und Presentation-Pipeline in Abhängigkeit vom aktiven Typ konfigurieren:

Advanced Color-Typ	Funktionalitäten des Bildschirms
SDR	SDR-Bildschirm ohne Advanced Color-Funktionalitäten
WCG	SDR-Bildschirm mit hoher Bit-Tiefe und automatischem Farbmanagement
HDR	HDR-Bildschirm mit allen Advanced Color-Funktionalitäten

Um zu prüfen, welche Advanced Color-Typen unterstützt werden, aber nicht unbedingt aktiv sind, rufen Sie AdvancedColorInfo::IsAdvancedColorKindAvailable auf. Mit dieser Information können Sie die Benutzer*innen zum Beispiel auffordern, zur Windows Einstellungen-App zu navigieren, damit sie HDR oder die automatische Farbverwaltung aktivieren können.

Die anderen Mitglieder von AdvancedColorInfo liefern quantitative Informationen über das physische Farbvolumen des Panels (Luminanz und Chrominanz), die den statischen HDR-Metadaten nach SMPTE ST.2086 entsprechen. Auch wenn ST.2086 ursprünglich für HDR-Bildschirme entwickelt wurde, sind diese Informationen nützlich und sowohl für HDR- als auch für SDR-Bildschirme verfügbar. Sie sollten diese Informationen nutzen, um die Tonwertzuordnung und die Gamut-Zuordnung Ihrer App zu konfigurieren.

Um Änderungen in den Funktionalitäten von Advanced Color zu verarbeiten, registrieren Sie sich für das Ereignis DisplayInformation::AdvancedColorInfoChanged. Dieses Ereignis wird ausgelöst, wenn sich ein Parameter der Advanced Color-Funktionalitäten des Bildschirms aus irgendeinem Grund ändert.

Behandeln Sie dieses Ereignis, indem Sie eine neue Instanz von AdvancedColorInfo abrufen und überprüfen, welche Werte sich geändert haben.

IDXGIOutput6

Hinweis

Die DirectX-Grafikinfrastruktur IDXGIOutput6 ist für jede App verfügbar, die DirectX verwendet, unabhängig davon, ob es sich um eine Desktop- oder Universal Windows Platform (UWP)-App handelt. Allerdings unterstützt IDXGIOutput6 keine SDR Bildschirme mit Advanced Color-Funktionalitäten wie z. B. automatisches Farbmanagement; es kann nur HDR-Bildschirme erkennen.

Wenn Sie eine Win32-Desktop-App schreiben und DirectX zum Rendern verwenden, dann verwenden Sie DXGI_OUTPUT_DESC1, um Funktionalitäten für den Bildschirm zu erhalten. Rufen Sie eine Instanz dieser Struktur über IDXGIOutput6::GetDesc1 ab.

Um zu überprüfen, welcher Advanced Color-Typ gerade aktiv ist, verwenden Sie die Eigenschaft ColorSpace, die vom Typ DXGI_COLOR_SPACE_TYPE ist und einen der folgenden Werte enthält:

DXGI_COLOR_SPACE_TYPE	Funktionalitäten des Bildschirms
DXGI_COLOR_SPACE_RGB_FULL_G22_NONE_P709	SDR-Bildschirm ohne Advanced Color-Funktionalitäten
DXGI_COLOR_SPACE_RGB_FULL_G2084_NONE_P2020	HDR-Bildschirm mit allen Advanced Color-Funktionalitäten

Hinweis

SDR-Bildschirme mit Advanced Color-Funktionalitäten werden ebenfalls als DXGI_COLOR_SPACE_RGB_FULL_G22_NONE_P709 gemeldet; DXGI bietet Ihnen nicht die Möglichkeit, zwischen diesen beiden Typen zu unterscheiden.

Hinweis

DXGI bietet Ihnen keine Möglichkeit zu überprüfen, welche Advanced Color-Typen zurzeit unterstützt werden, aber nicht aktiv sind.

Die meisten anderen Elemente von DXGI_OUTPUT_DESC1 liefern quantitative Informationen über das physische Farbvolumen des Panels (Luminanz und Chrominanz), die den statischen HDR-Metadaten nach SMPTE ST.2086 entsprechen. Auch wenn ST.2086 ursprünglich für HDR-Bildschirme entwickelt wurde, sind diese Informationen nützlich und sowohl für HDR- als auch für SDR-Bildschirme verfügbar. Sie sollten diese Informationen nutzen, um die Tonwertzuordnung und die Gamut-Zuordnung Ihrer App zu konfigurieren.

Win32-Desktop-Apps verfügen nicht über einen nativen Mechanismus, um auf Änderungen der Advanced Color-Funktionalitäten zu reagieren. Wenn Ihre App eine Renderingschleife verwendet, sollten Sie stattdessen bei jedem Frame IDXGIFactory1::IsCurrent abfragen. Wenn es FALSCH liefert, sollten Sie ein neues DXGI_OUTPUT_DESC1 abrufen und überprüfen, welche Werte sich geändert haben.

Außerdem sollte Ihre Win32-Message-Pump die Nachricht WM_SIZE verarbeiten, die darauf hinweist, dass Ihre App möglicherweise zwischen verschiedenen Bildschirmen gewechselt hat.

Hinweis

Um ein neues DXGI_OUTPUT_DESC1 abzurufen, müssen Sie den aktuellen Bildschirm abrufen. Sie sollten jedoch nicht IDXGISwapChain::GetContainingOutput aufrufen. Das liegt daran, dass Swap-Chains eine veraltete DXGI-Ausgabe zurückgeben, sobald DXGIFactory::IsCurrent falsch ist; und die Swap-Chain neu zu erstellen, um eine aktuelle Ausgabe zu erhalten, führt zu einer vorübergehend schwarzen Seite. Stattdessen empfehlen wir Ihnen, die Begrenzungen aller DXGI-Ausgaben durchzugehen und festzustellen, welche die größte Schnittmenge mit den Begrenzungen Ihres App-Fensters hat.

Der folgende Beispiel-Code stammt aus der Direct3D 12 HDR-Beispiel-App auf 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));

Einrichten Ihrer DirectX Swap-Chain

Sobald Sie festgestellt haben, dass der Bildschirm die Funktionalitäten von Advanced Color unterstützt, konfigurieren Sie Ihre Swap-Chain wie folgt.

Verwenden Sie einen Flip Presentation Model-Effekt

Wenn Sie Ihre Swap-Chain mit einer der Methoden CreateSwapChainFor[Hwnd|Composition|CoreWindow] erstellen, müssen Sie das DXGI-Flip-Modell verwenden, indem Sie entweder die Option DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL oder DXGI_SWAP_EFFECT_FLIP_DISCARD auswählen, wodurch Ihre Swap-Chain für die Advanced Color-Verarbeitung von DWM und verschiedene Vollbild-Optimierungen infrage kommt. Weitere Informationen finden Sie unter Für beste Leistung verwenden Sie das DXGI-Flip-Modell.

Option 1. Verwenden des FP16-Pixelformats und des scRGB-Farbraums

Windows 10 unterstützt zwei Hauptkombinationen von Pixelformat und Farbraum für Advanced Color. Wählen Sie eine davon je nach den spezifischen Anforderungen Ihrer App aus.

Wir empfehlen, dass Apps für allgemeine Zwecke die Option 1 verwenden. Dies ist die einzige Option, die für alle Arten von Advanced Color Bildschirmen, Inhalten und Rendering-APIs funktioniert. Wenn Sie Ihre Swap-Chain erstellen, geben Sie DXGI_FORMAT_R16G16B16A16_FLOAT in Ihrem DXGI_SWAP_CHAIN_DESC1 an. Standardmäßig wird eine Swap-Chain, die mit einem Fließkomma-Pixelformat erstellt wurde, so behandelt, als ob sie den DXGI_COLOR_SPACE_RGB_FULL_G10_NONE_P709-Farbraum verwendet. Das ist dasselbe Pixelformat und derselbe Farbraum, der von der DWM verwendet wird.

Diese Kombination bietet Ihnen den numerischen Bereich und die Präzision, um jede physisch mögliche Farbe anzugeben und beliebige Verarbeitungen einschließlich Blending durchzuführen.

Allerdings verbraucht diese Option 64 Bits pro Pixel, wodurch sich die GPU-Bandbreite und der Speicherverbrauch im Vergleich zu den traditionellen UINT8-Pixelformaten verdoppelt. Darüber hinaus verwendet scRGB numerische Werte, die außerhalb des normalisierten [0, 1]-Bereichs liegen, um Farben darzustellen, die außerhalb des sRGB-Farbraums liegen und/oder eine Leuchtdichte von mehr als 80 Nits aufweisen. Zum Beispiel kodiert scRGB (1.0, 1.0, 1.0) das Standard-Weiß D65 mit 80 Nits, aber scRGB (12.5, 12.5, 12.5) kodiert das gleiche D65-Weiß mit viel helleren 1000 Nits. Einige Grafikoperationen erfordern einen normalisierten Zahlenbereich, und Sie müssen entweder den Vorgang ändern oder die Farbwerte neu normalisieren.

Die Art und Weise, wie die Luminanzwerte bei dieser Option interpretiert werden, unterscheidet sich zwischen SDR- und HDR-Bildschirmen; siehe unten.

Option 2: Verwenden Sie das Pixelformat UINT10/RGB10 und den Farbraum HDR10/BT.2100

Bei Option 2 handelt es sich um eine Leistungsoptimierung, die nur verfügbar ist, wenn Ihre App alle der folgenden Bedingungen erfüllt:

• Ziel ist ein HDR-Bildschirm
• Verwendet Direct3D 12 oder Direct3D 11
• Swap-Chain erfordert kein Blending mit Alpha/Transparenz

Wenn Ihre App nicht alle diese Bedingungen erfüllt, müssen Sie Option 1 verwenden.

Wenn Ihre App jedoch für Option 2 in Frage kommt, könnte dies eine bessere Leistung bieten, wenn Ihre App HDR10-kodierte Inhalte verwendet, wie z. B. einen Videoplayer, oder wenn sie hauptsächlich in Vollbildszenarien verwendet wird, wie z. B. ein Spiel. Wenn Sie Ihre Swap-Chain erstellen, sollten Sie die Angabe von DXGI_FORMAT_R10G10B10A2_UNORM in DXGI_SWAP_CHAIN_DESC1 in Betracht ziehen. Standardmäßig wird das so behandelt, als würde der sRGB-Farbraum verwendet. Daher müssen Sie IDXGISwapChain3::SetColorSpace1 explizit aufrufen und als Farbraum DXGI_COLOR_SPACE_RGB_FULL_G2084_NONE_P2020 festlegen, auch bekannt als HDR10/BT.2100.

Diese Option verbraucht dieselben 32 Bits pro Pixel wie traditionelle UINT8-SDR-Pixelformate. Darüber hinaus entfällt auf bestimmten GPUs ein Teil der Verarbeitung, die für die Konvertierung der Inhalte in das HDR10-Wire-Format erforderlich ist.

Verwendung einer Advanced Color-Swap-Chain, wenn sich der Bildschirm im SDR-Modus befindet

Sie können eine Advanced Color-Swap-Chain auch dann verwenden, wenn der Bildschirm nicht alle Funktionalitäten von Advanced Color unterstützt. In diesen Fällen konvertiert der Desktop Window Manager (DWM) Ihre Inhalte herunter, um sie an die Funktionalitäten des Bildschirms anzupassen, indem er numerische Beschneidungen vornimmt. Wenn Sie z. B. auf eine FP16-scRGB-Swap-Chain rendern und einen Standard-Bildschirm als Ziel haben, wird alles, was außerhalb des numerischen Bereichs [0, 1] liegt, abgeschnitten.

Dieses Abwärtskonvertierungsverhalten tritt auch auf, wenn sich Ihr App-Fenster über zwei oder mehr Bildschirme mit unterschiedlichen Advanced Color-Funktionalitäten erstreckt. AdvancedColorInfo und IDXGIOutput6 sind abstrahiert, um nur die Eigenschaften des Hauptbildschirms zu liefern (Hauptbildschirm ist definiert als der Bildschirm, der den Mittelpunkt des Fensters enthält).

Abstimmung des Referenzweiß` Ihrer App auf den SDR-Referenzweißwert des Betriebssystems

Hinweis

Referenzweiß gilt nur für HDR-Bildschirme; für SDR Advanced Color-Bildschirme bedeutet (1.0, 1.0, 1.0) immer die maximale weiße Leuchtdichte, die der Bildschirm wiedergeben kann.

In vielen Szenarien wird Ihre App sowohl SDR- als auch HDR-Inhalte rendern wollen, z. B. Untertitel oder Steuerelemente über HDR-Video oder die Benutzeroberfläche in einer Spielszene. Es ist wichtig, das Konzept des SDR-Referenzweißwertes zu verstehen, um sicherzustellen, dass Ihre SDR-Inhalte auf einem HDR-Bildschirm korrekt aussehen. Referenzweiß gibt die Helligkeit an, bei der ein diffuses weißes Objekt (z. B. ein Blatt Papier oder manchmal auch die Benutzeroberfläche) in einer HDR-Szene erscheint. Da HDR-Farbwerte eine szenenbezogene Helligkeit haben, sollte ein bestimmter Farbwert auf einem absoluten Luminanzniveau angezeigt werden und nicht relativ zum maximal möglichen Panelwert. Zum Beispiel kodieren scRGB (1.0, 1.0, 1.0) und HDR10 (497, 497, 497) beide genau D65 Weiß bei 80 Nits Luminanz. Windows bietet den Benutzer*innen die Möglichkeit, den SDR-Referenzweißwert nach ihren Wünschen einzustellen. Das ist die Leuchtdichte, mit der Windows sRGB (1.0, 1.0, 1.0) wiedergibt. Bei Desktop-HDR-Monitoren wird der SDR-Referenzweißwert in der Regel auf etwa 200 Nits festgelegt.

Ihre HDR-App muss den Benutzer*innen die Möglichkeit bieten, entweder ihren gewünschten Referenzweißwert festzulegen oder den vom System konfigurierten Wert zu übernehmen. Sie müssen Ihre diffusen weißen Farbwerte in Ihrer Szene dem SDR-Referenzweißwert zuordnen. Dazu müssen Sie den Framebuffer Ihrer App im linearen Gamma-Raum multiplizieren.

Hinweis

Auf einem Bildschirm, der eine Helligkeitsregelung unterstützt, wie z. B. auf einem Laptop, passt Windows auch die Luminanz von HDR-Inhalten (szenenbezogen) an die Benutzer-Helligkeit an, aber das ist für die App nicht sichtbar. Sofern Sie nicht versuchen, eine bitgenaue Wiedergabe des HDR-Signals zu garantieren, können Sie das im Allgemeinen ignorieren.

Wenn Ihre App SDR und HDR immer auf getrennte Flächen rendert und sich auf die Composite-Funktion des Betriebssystems verlässt, nimmt Windows automatisch die richtige Anpassung vor, um SDR-Inhalte auf den gewünschten Weißwert anzuheben. Zum Beispiel, wenn Ihre App XAML verwendet und HDR-Inhalte in ihr eigenes SwapChainPanel rendert.

Wenn Ihre App jedoch eine eigene Komposition von SDR- und HDR-Inhalten in einer einzigen Oberfläche durchführt, sind Sie selbst dafür verantwortlich, die Anpassung des SDR-Referenzweißwertes vorzunehmen. Andernfalls könnten die SDR-Inhalte unter typischen Desktop-Betrachtungsbedingungen zu dunkel erscheinen. Zunächst müssen Sie den aktuellen SDR-Referenzweißwert abrufen und dann die Farbwerte der SDR-Inhalte, die Sie rendern, anpassen.

Schritt 1. Abrufen des aktuellen SDR-Referenzweißwerts

Sie können den aktuellen SDR-Referenzweißwert auf eine der folgenden Arten abrufen:

• In einer Desktop-App. DISPLAYCONFIG_SDR_WHITE_LEVEL und QueryDisplayConfig.
• In einer UWP-App. AdvancedColorInfo.SdrWhiteLevelInNits (unter Verwendung eines CoreWindow).

Schritt 2. Farbwerte von SDR-Inhalten anpassen

Windows definiert den nominalen oder standardmäßigen Referenzweißwert mit 80 Nits. Wenn Sie also ein standardmäßiges sRGB-Weiß (1.0, 1.0, 1.0) auf eine FP16 Swap-Chain rendern würden, würde es mit einer Luminanz von 80 Nits wiedergegeben werden. Um dem tatsächlichen benutzerdefinierten Referenzweißwert zu entsprechen, müssen Sie SDR-Inhalte von 80 Nits auf den über AdvancedColorInfo.SdrWhiteLevelInNits angegebenen Wert anpassen.

Wenn Sie mit FP16 und scRGB oder einem anderen Farbraum rendern, der ein lineares (1.0) Gamma verwendet, können Sie den SDR-Farbwert einfach mit AdvancedColorInfo.SdrWhiteLevelInNits / 80 multiplizieren. Wenn Sie Direct2D verwenden, gibt es eine vordefinierte Konstante D2D1_SCENE_REFERRED_SDR_WHITE_LEVEL, die einen Wert von 80 hat.

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;

Wenn Sie mit einem nichtlinearen Gamma-Farbraum wie HDR10 rendern, ist die Anpassung des SDR-Weißpegels etwas komplexer. Wenn Sie Ihren eigenen Pixel-Shader schreiben, sollten Sie eine Konvertierung in lineares Gamma in Betracht ziehen, um die Anpassung vorzunehmen.

Anpassen von HDR-Inhalten an die Funktionalitäten des Bildschirms mit Hilfe von Tone-Mapping

HDR- und Advanced Color-Bildschirme unterscheiden sich stark in ihren Funktionalitäten. Zum Beispiel in Bezug auf die minimale und maximale Luminanz und die Farbskala, die sie wiedergeben können. In vielen Fällen werden Ihre HDR-Inhalte Farben enthalten, die die Funktionalitäten des Bildschirms übersteigen. Für eine optimale Bildqualität ist es wichtig, dass Sie eine HDR-Tonwertzuordnung vornehmen, d. h. die Farbpalette so komprimieren, dass sie auf den Bildschirm passt und gleichzeitig die visuelle Absicht des Inhalts bestmöglich erhalten bleibt.

Der wichtigste Parameter, der angepasst werden muss, ist die maximale Luminanz, auch bekannt als MaxCLL (Content Light Level). Anspruchsvollere Tonemapper passen auch die minimale Luminanz (MinCLL) und/oder die primären Farben an.

Schritt 1. Abrufen der Farbvolumeneigenschaften des Bildschirms

Universelle Windows-Plattform-Apps (UWP)

Verwenden Sie AdvancedColorInfo, um das Farbvolumen des Bildschirms zu ermitteln.

Win32 (Desktop) DirectX-Apps

Verwenden Sie DXGI_OUTPUT_DESC1, um das Farbvolumen des Bildschirms zu ermitteln.

Schritt 2. Informationen zum Farbvolumen des Inhalts abrufen

Je nachdem, woher Ihre HDR-Inhalte stammen, gibt es mehrere Möglichkeiten, ihre Luminanz- und Farbrauminformationen zu ermitteln. Bestimmte HDR-Video- und Bilddateien enthalten SMPTE ST.2086-Metadaten. Wenn Ihre Inhalte dynamisch gerendert wurden, können Sie möglicherweise Szeneninformationen aus den internen Renderingstufen extrahieren – zum Beispiel die hellste Lichtquelle in einer Szene.

Eine generellere, aber rechenintensivere Lösung ist das Ausführen eines Histogramms oder eines anderen Analysedurchlaufs für das gerenderte Bild. Die App Direct2D Advanced Color Image Rendering auf GitHub demonstriert, wie dies mit Direct2D möglich ist; die wichtigsten Code-Snippets finden Sie unten:

// 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;
}

Schritt 3. Ausführen des HDR-Tonemapping-Vorgangs

Tonemapping ist von Natur aus ein verlustbehafteter Prozess und kann für eine Reihe von subjektiven oder objektiven Metriken optimiert werden. Es gibt also keinen einheitlichen Standardalgorithmus. Windows bietet einen integrierten HDR-Tonemapper-Effekt als Teil von Direct2D sowie in der Media Foundation HDR Video Playback Pipeline. Zu den anderen allgemein verwendeten Algorithmen gehören ACES Filmic, Reinhard und ITU-R BT.2390-3 EETF (Electrical-Electrical Transfer Function).

Ein vereinfachter Reinhard-Tonemapper-Operator wird in dem folgenden Code-Beispiel gezeigt.

// 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;
}

Erfassen von HDR- und WCG-Bildschirminhalten

APIs, die die Angabe von Pixelformaten unterstützen, wie die im Windows.Graphics.Capture-Namespace und die IDXGIOutput5::DuplicateOutput1-Methode, bieten die Funktionalität, HDR- und WCG-Inhalte ohne Verlust von Pixelinformationen zu erfassen. Beachten Sie, dass nach der Erfassung von Inhaltsframes eine zusätzliche Verarbeitung erforderlich ist. Zum Beispiel die Zuordnung von HDR- zu SDR-Tönen (z. B. SDR-Screenshot-Kopie für die Weitergabe im Internet) und das Speichern von Inhalten im richtigen Format (z. B. JPEG XR).

Änderungen am veralteten Farbmanagement und ICC-Profilverhalten

Advanced Color und das automatische Farbmanagement sorgen für eine konsistente und farbmetrisch genaue Darstellung des Bildschirms für alle Apps, veraltete und moderne. Einige Apps können jedoch ihr eigenes explizites Farbmanagement unter Verwendung von ICC-Farbprofilen (International Color Consortium) durchführen.

Wenn Advanced Color auf SDR- oder HDR-Bildschirmen aktiviert ist, ändert sich das Verhalten von ICC-Profilen auf dem Bildschirm auf nicht abwärtskompatible Weise. Wenn Ihre App mit Bildschirm-ICC-Profilen arbeitet, bietet Windows Kompatibilitätshilfen an, um sicherzustellen, dass Ihre App weiterhin das richtige Verhalten zeigt.

Weitere Informationen über die Änderungen am Verhalten von ICC-Profilen und wie Sie Ihre App anpassen können, um die Kompatibilität mit Advanced Color zu maximieren, finden Sie unter ICC-Profilverhalten mit Advanced Color.

Zusätzliche Ressourcen

• Auf GitHub, Using HDR Rendering with the DirectX Tool Kit for DirectX 11 / DirectX 12. Exemplarische Vorgehensweise zum Hinzufügen von Unterstützung für HDR in einer DirectX App mit dem DirectX Tool Kit (DirectXTK).
• Direct2D Advanced Color Image Rendering Beispiel-App. UWP SDK-Beispiel-App zur Implementierung eines Advanced Color-fähigen HDR- und WCG-Bildbetrachters mit Direct2D. Demonstriert die gesamte Bandbreite bewährter Verfahren für UWP-Apps, einschließlich der Reaktion auf Änderungen der Funktionalitäten des Bildschirms und der Anpassung an den SDR-Weißwert.
• Direct3D 12 HDR Desktop Beispiel-App. Desktop-SDK-Beispiel für die Implementierung einer grundlegenden Direct3D 12 HDR-Szene.
• Direct3D 12 HDR UWP Beispiel-App. UWP-Entsprechung des obigen Beispiels.
• SimpleHDR_PC. Eine Xbox ATG SimpleHDR PC Beispiel-App (eine Desktop Beispiel-App) zur Implementierung einer grundlegenden Direct3D 11 HDR-Szene.