Usare DirectX con colore avanzato su schermi di intervallo dinamico standard/elevato

Questo argomento illustra come usare DirectX con scenari a colori avanzati, tra cui hdr (High Dynamic Range), wide color gamut (WCG) con gestione automatica dei colori del sistema e profondità elevata in bit. I display Premium personal computer (PC) con almeno uno dei miglioramenti sopra elencati stanno diventando diffusi, offrendo una fedeltà di colore significativamente superiore rispetto ai tradizionali display SDR (Standard Dynamic Range).

In questo argomento si otterrà una panoramica dei concetti tecnici principali relativi al supporto di Windows Advanced Color. Si apprenderanno i requisiti e le istruzioni per il rendering di contenuti HDR, WCG e DirectX ad alta profondità a una di queste visualizzazioni. Se si dispone di un'app gestita dal colore (ad esempio, usando i profili ICC), si apprenderà come la gestione automatica dei colori consente una migliore accuratezza dei colori per gli scenari.

Introduzione al colore avanzato in Windows

Advanced Color è un termine generico di tecnologie del sistema operativo per i display con una fedeltà del colore significativamente superiore rispetto agli schermi standard. Le funzionalità estese predominanti sono descritte nelle sezioni seguenti. Le funzionalità avanzate color sono state introdotte per la prima volta per i display HDR con Windows 10, versione 1709 (Fall Creators Update) e per i display SDR con provisioning speciale con Windows 11 versione 22H2 (10.0; Versione build 22621.

Intervallo dinamico elevato

L'intervallo dinamico si riferisce alla differenza tra la luminanza massima e minima in una scena; questo è spesso misurato in nits (candela per centimetro quadrato). Scene del mondo reale, come questo tramonto, spesso hanno intervalli dinamici di 10 ordini di grandezza di luminanza; l'occhio umano può discernere una gamma ancora più grande dopo l'adattamento.

Sin da Direct3D 9, i motori grafici sono stati in grado di eseguire internamente il rendering delle loro scene con questo livello di fedeltà fisicamente accurata. Tuttavia, un tipico display di intervallo dinamico standard può riprodurre solo un minimo di 3 ordini di grandezza di luminanza, e pertanto qualsiasi contenuto sottoposto a rendering HDR deve essere tono compresso (compresso) nell'intervallo limitato dello schermo. Nuovi display HDR, inclusi quelli conformi allo standard HDR10 (BT.2100), superano questa limitazione; ad esempio, le visualizzazioni auto-emissive di alta qualità possono raggiungere un valore superiore a 6 ordini di grandezza.

Ampia gamma di colori

La gamma di colori si riferisce all'intervallo e alla saturazione delle tonalità che un display può riprodurre. I colori naturali più saturi che l'occhio umano può percepire sono costituiti da luce pura e monocromatica come quella prodotta dai laser. Tuttavia, i display consumer mainstream spesso possono riprodurre i colori solo all'interno della gamma sRGB, che rappresenta solo circa il 35% di tutti i colori percepibili dall'uomo. Il diagramma seguente è una rappresentazione del "locus spettrale" umano o di tutti i colori percepibili (a un determinato livello di dominanza), dove il triangolo più piccolo è la gamma sRGB.

Gli schermi pc professionali di fascia alta hanno lunghe gamut di colori supportati che sono significativamente più ampi rispetto a sRGB, come Adobe RGB e DCI-P3 che coprono circa la metà dei colori percepibili dall'uomo. E queste ampie visualizzazioni di gamut stanno diventando più comuni.

Gestione automatica dei colori del sistema

La gestione dei colori è la tecnologia e la pratica di garantire una riproduzione accurata e coerente dei colori tra i dispositivi. Se sei un creatore di contenuti digitali, è fondamentale per i colori del contenuto visivo, ad esempio una foto, un'immagine del prodotto o un logo, per apparire nello stesso modo del tuo display, come nei dispositivi digitali del pubblico.

Windows ha fornito API di supporto per la gestione dei colori a partire da Windows 2000 con le API ICM (Image Color Management) e versioni successive di Windows Color System (WCS ). Tuttavia, queste API erano solo helper per le app che desideravano/richiedevano di eseguire la gestione dei colori; mentre la maggior parte delle app e del contenuto digitale presuppone semplicemente lo spazio dei colori sRGB standard del settore e non sono mai stati gestiti dal sistema operativo. Questo è stato un presupposto ragionevole in passato, ma i display di gamma di alta qualità stanno diventando molto più comuni.

Le nuove versioni di Windows supportano la gestione automatica dei colori del sistema; che garantisce che tutti i colori in ogni app di Windows, indipendentemente dal fatto che siano con riconoscimento del colore, vengano visualizzati in modo accurato e coerente su ogni display supportato.

Profondità di precisione/bit profonda

La precisione numerica o la profondità di bit si riferisce alla quantità di informazioni usate per identificare in modo univoco i colori. Maggiore profondità bit significa che è possibile distinguere tra colori molto simili senza artefatti come la banding. I PC mainstream supportano 8 bit per canale di colore, mentre l'occhio umano richiede almeno 10-12 bit di precisione per evitare distorsioni percepibili.

Prima di Colore avanzato, le app con finestra con restrizioni Desktop Window Manager (DWM) per l'output del contenuto a soli 8 bit per canale colore, anche se lo schermo supportava una profondità di bit superiore. Quando Advanced Color è abilitato, DWM esegue la sua composizione usando il virgola mobile a metà precisione IEEE (FP16), eliminando eventuali colli di bottiglia e consentendo l'uso della precisione completa dello schermo.

Architettura del sistema Windows Advanced Color

Le informazioni contenute in questa sezione sono facoltative per la creazione di app a colori avanzate; ma è utile comprendere il funzionamento della tecnologia per ottimizzare il rendering e il comportamento dell'app.

In questa sezione si userà un diagramma semplificato per descrivere i componenti pertinenti dello stack di grafica di Windows:

Windows esistente: display a 8 bit/sRGB

Per decenni, gli schermi consumer e lo stack di grafica Di Windows si basavano su circa 8 bit per canale (24 bit per pixel) contenuto sRGB. Le app che usano API grafiche come DirectX possono eseguire il rendering interno usando profondità di bit elevata e spazi di colore estesi; Tuttavia, il sistema operativo supporta solo l'intero a 8 bit con sRGB implicito e nessuna gestione dei colori di sistema:

Ciò significa che tutti i dati di colore aggiuntivi visualizzati da un'app andrebbero persi quando vengono visualizzati; e che l'app doveva eseguire la gestione dei colori stessa per garantire una riproduzione accurata su uno schermo.

Windows 10, versione 1703: display HDR con colore avanzato

Windows 10, versione 1703 ha introdotto la prima versione delle funzionalità Advanced Color per gli schermi HDR. Ciò richiedeva diversi progressi significativi nello stack di grafica del sistema operativo:

• Supporto per la segnalazione dello schermo HDR
• Composizione del sistema con una profondità di bit elevata, spazio colore canonico
• Gestione automatica dei colori del sistema

Ogni avanzamento è trattato nelle sezioni secondarie seguenti. Il risultato netto è che i dati di colore dell'app estesi vengono ora mantenuti correttamente dal sistema operativo e riprodotti accuratamente nei display HDR.

Supporto per la segnalazione dello schermo HDR

La segnalazione HDR su connettori di visualizzazione come DisplayPort e HDMI usa principalmente 10 bit per precisione del canale (o superiore) e lo spazio dei colori BT.2100 ST.2084. Il kernel di visualizzazione, il driver di visualizzazione e l'hardware GPU sottostante devono supportare il rilevamento, la selezione e la guida di questa modalità di segnalazione.

Composizione del sistema con una profondità di bit elevata, spazio colore canonico

Lo spazio dei colori BT.2100 ST.2084 è uno standard efficiente per la codifica dei colori HDR, ma non è adatto per molte operazioni di rendering e composizione (fusione). Vogliamo anche una prova futura del sistema operativo per supportare tecnologie e spazi di colore ben oltre BT.2100, che copre meno di 2/3 di colori visibili dall'uomo. Infine, laddove possibile, si vuole ridurre al minimo il consumo di risorse GPU per migliorare la potenza e le prestazioni.

Quando si usa la modalità HDR, Desktop Window Manager (DWM) usa uno spazio colore di composizione canonico (CCCS) definito come:

• spazio colore scRGB (primari BT.709/sRGB con gamma lineare)
• Precisione a metà IEEE (profondità FP16 bit)

Ciò garantisce un buon equilibrio tra tutti gli obiettivi precedenti. CCCS consente valori di colore al di fuori dell'intervallo numerico [0, 1] ; dato l'intervallo di valori FP16 validi, può rappresentare ordini di grandezza maggiore di colori rispetto all'intervallo visivo umano naturale, inclusi i valori di dominanza oltre 5 milioni di nit. FP16 offre una precisione eccellente per le operazioni di fusione gamma lineare, ma costa metà del consumo di memoria GPU e della larghezza di banda della precisione singola tradizionale (FP32) senza perdita di qualità percepibile.

Gestione automatica dei colori del sistema

Windows è un ambiente multitasking in cui l'utente può eseguire un numero qualsiasi di app SDR e HDR contemporaneamente con finestre sovrapposte. Pertanto, è fondamentale che tutti i tipi di contenuto siano corretti e alla massima qualità quando l'output viene restituito a uno schermo; ad esempio, un'app per la produttività sRGB (SDR) con una finestra video BT.2100 ST.2084 (HDR) riprodotta su di essa.

Quando si usa la modalità HDR, Windows esegue operazioni di gestione dei colori in due fasi:

1. DWM converte ogni app dallo spazio dei colori nativo a CCCS prima della fusione.
2. Il kernel di visualizzazione converte il framebuffer del sistema operativo da CCCS allo spazio colore formato filo (BT.2100 ST.2084).
   • Facoltativamente, il kernel di visualizzazione funziona con il driver di visualizzazione per eseguire una calibrazione del colore di visualizzazione aggiuntiva; per altre info, vedi Pipeline di calibrazione dei colori per la visualizzazione hardware di Windows.

Windows 11, versione 22H2: display SDR con colore avanzato

Mentre la prevalenza dei display HDR è in rapida crescita, i display SDR rimarranno importanti per anni a venire. Il supporto HDR in Windows 10, versione 1703, ha posto la maggior parte delle basi necessarie per migliorare anche gli schermi SDR. Windows 11, versione 22H2 estende le funzionalità avanzate di gestione dei colori e dei colori automatici a determinati schermi SDR idonei. Il diagramma a blocchi grafici per i display SDR a colori avanzati ha un aspetto molto simile a HDR:

Supporto per la segnalazione SDR con profondità elevata

La segnalazione sottostante per le visualizzazioni SDR rimane invariata, anche se la versione 22H2 di Windows 11 supporta 10 bit per canale e versioni successive, a seconda delle funzionalità dello schermo.

Composizione del sistema con una profondità di bit elevata, spazio colore canonico

La funzionalità DWM Advanced Color, inclusa la fusione in CCCS, è quasi completamente invariata dai display HDR. La differenza principale è che DWM usa la luminanza a cui fa riferimento lo schermo con display SDR e la luminanza a cui fa riferimento la scena con schermi HDR. Questo cambia il modo in cui il contenuto di cui è stato eseguito il rendering dei colori avanzati viene interpretato dal sistema operativo:

Tipo di visualizzazione	Comportamento della luminanza	Come viene interpretato 1.0f
SDR	Visualizzazione a cui si fa riferimento	Come livello bianco di riferimento della visualizzazione
HDR	A cui fa riferimento la scena	Come 80 nit (bianco riferimento nominale)

Gestione automatica dei colori del sistema

Le funzionalità di gestione dei colori del sistema operativo sono anche per lo più invariate rispetto agli schermi HDR. La differenza principale è che il kernel di visualizzazione converte nello spazio dei colori definito dai dati di colori e calibrazione dello schermo, anziché lo spazio dei colori standard BT.2100 ST.2084 per i display HDR.

Visualizzare il provisioning necessario

Per definire l'operazione di gestione dei colori di output del kernel di visualizzazione, sono necessari dati accurati da un profilo ICC MHC. Di conseguenza, solo le visualizzazioni SDR di cui è stato effettuato il provisioning specifico dal produttore o da un provider di calibrazione dello schermo con un profilo valido sono idonee per la gestione automatica dei colori. Per altre informazioni, vedi Comportamento del profilo ICC con Colore avanzato.

Requisiti di sistema e supporto del sistema operativo

Windows 10 versione 1709 è stato fornito per la prima volta il supporto di Colori avanzati per le visualizzazioni HDR. La versione di Windows 11, versione 22H2 aggiunge il supporto dei colori avanzati per le visualizzazioni SDR con dati di provisioning accurati.

Questo argomento presuppone che l'app sia destinata a Windows 10, versione 2004 (o successiva) per gli schermi HDR e la versione di Windows 11, versione 22H2 (o successiva) per le visualizzazioni SDR.

Schermo

Uno schermo ad alta gamma dinamica deve implementare lo standard HDR10 o BT.2100 ST.2084. La qualità dello schermo HDR può variare notevolmente e consigliamo vivamente di visualizzare certificati, ad esempio VESA DisplayHDR. A partire dalla versione di Windows 11, versione 22H2, Windows visualizza lo stato di certificazione delle visualizzazioni note nell'app Impostazioni .

Una visualizzazione di intervallo dinamico standard deve avere dati accurati sul provisioning dei colori per il supporto dei colori avanzati. Nella versione di Windows 11, versione 22H2, l'unico metodo supportato per eseguire l'override di questi dati è tramite un profilo ICC MHC; Inoltre, l'utente o il produttore dello schermo deve avere abilitato la gestione automatica dei colori. Per altre info, vedi Comportamento del profilo ICC con Colore avanzato.

Processore di grafica (GPU)

Per la funzionalità Colori avanzata completa nei display SDR e HDR, è necessaria una GPU recente:

• AMD Radeon RX serie 400 (Polaris) o versioni successive
• Nvidia GeForce 10 serie (Pascal) o versione successiva
• Intel Core 10th gen selezionato (Ice Lake) o versione successiva*

Potrebbero essere applicati requisiti hardware aggiuntivi, a seconda degli scenari, tra cui l'accelerazione codec hardware (HEVC a 10 bit, VP9 a 10 bit e così via) e il supporto playReady (SL3000). Per informazioni più specifiche, contattare il fornitore della GPU.

Driver grafico (WDDM)

Il driver grafico più recente disponibile è fortemente consigliato, sia da Windows Update che dal fornitore GPU o dal sito Web del produttore del PC. Questo argomento si basa sulle funzionalità dei driver di WDDM 2.7 (Windows 10, versione 2004) per gli schermi HDR e WDDM 3.0 (Windows 11, versione 21H2) per gli schermi SDR.

API di rendering supportate

Windows 10 supporta un'ampia gamma di API e framework di rendering. Il supporto dei colori avanzato si basa fondamentalmente sulla tua app per eseguire una presentazione moderna usando DXGI o le API del livello visivo.

• DirectX Graphics Infrastructure (DXGI)
• Livello visivo (Windows.UI.Composition)

Di conseguenza, qualsiasi API di rendering che può restituire uno di questi metodi di presentazione può supportare Il colore avanzato. Ciò include (ma non è limitato a) quanto segue.

• Direct3D 11
• Direct3D 12
• Direct2D
• Win2D
  • Richiede l'uso delle API CanvasSwapChain o CanvasSwapChainPanel di livello inferiore.
• Windows.UI.Input.Inking
  • Supporta il rendering dell'input penna secco personalizzato tramite DirectX.
• XAML
  • Supporta la riproduzione di video HDR con MediaPlayerElement.
  • Supporta la decodifica delle immagini XR JPEG usando l'elemento Image .
  • Supporta l'interoperabilità DirectX tramite SwapChainPanel.

Gestione delle funzionalità di visualizzazione dinamica

Windows 10 supporta un'enorme gamma di schermi con supporto per i colori avanzati, da pannelli integrati efficienti per l'alimentazione a monitor di gioco e TELEVISORi di fascia alta. Gli utenti di Windows si aspettano che l'app gestisca senza problemi tutte queste varianti, incluse le visualizzazioni SDR esistenti onnipresenti.

Windows 10 offre il controllo sulle funzionalità HDR e Colore avanzato per l'utente. L'app deve rilevare la configurazione della visualizzazione corrente e rispondere dinamicamente alle eventuali modifiche apportate alla funzionalità. Ciò può verificarsi per molti motivi, ad esempio, perché l'utente ha abilitato o disabilitato una funzionalità o ha spostato l'app tra diversi schermi o lo stato di alimentazione del sistema è cambiato.

Opzione 1: AdvancedColorInfo

Prima di tutto, ottenere un'istanza di AdvancedColorInfo da DisplayInformation::GetAdvancedColorInfo.

Per verificare il tipo di colore avanzato attualmente attivo, utilizzare la proprietà AdvancedColorInfo::CurrentAdvancedColorKind. Questa è la proprietà più importante da controllare ed è necessario configurare la pipeline di rendering e presentazione in risposta al tipo attivo:

Tipo di colore avanzato	Funzionalità di visualizzazione
SDR	Visualizzazione SDR senza funzionalità avanzate di colore
WCG	Visualizzazione SDR con profondità elevata e gestione automatica dei colori
HDR	Display HDR con tutte le funzionalità Avanzate colore

Per verificare quali tipi di colori avanzati sono supportati, ma non necessariamente attivi, chiamare AdvancedColorInfo::IsAdvancedColorKindAvailable. Puoi usare queste informazioni, ad esempio, per chiedere all'utente di passare all'app Impostazioni di Windows in modo che possano abilitare HDR o la gestione automatica dei colori.

Gli altri membri di AdvancedColorInfo forniscono informazioni quantitative sul volume di colori fisici del pannello (luminanza e dominanza), corrispondenti ai metadati HDR statici SMPTE ST.2086. Anche se ST.2086 è stato originariamente progettato per i display HDR, queste informazioni sono utili ed è disponibile sia per schermi HDR che SDR. È consigliabile usare queste informazioni per configurare il mapping del tono e il mapping di gamut dell'app.

Per gestire le modifiche apportate alle funzionalità Advanced Color, registrarsi per l'evento DisplayInformation::AdvancedColorInfoChanged . Questo evento viene generato se un parametro delle funzionalità Avanzate colore della visualizzazione cambia per qualsiasi motivo.

Gestire l'evento ottenendo una nuova istanza di AdvancedColorInfo e verificando quali valori sono stati modificati.

IDXGIOutput6

Se stai scrivendo un'app desktop Win32 e usi DirectX per eseguire il rendering, usa DXGI_OUTPUT_DESC1 per ottenere funzionalità di visualizzazione. Ottenere un'istanza di tale struct tramite IDXGIOutput6::GetDesc1.

Per verificare quale tipo di colore avanzato è attualmente attivo, utilizzare la proprietà ColorSpace , di tipo DXGI_COLOR_SPACE_TYPE e contiene uno dei valori seguenti:

DXGI_COLOR_SPACE_TYPE	Funzionalità di visualizzazione
DXGI_COLOR_SPACE_RGB_FULL_G22_NONE_P709	Visualizzazione SDR senza funzionalità avanzate di colore
DXGI_COLOR_SPACE_RGB_FULL_G2084_NONE_P2020	Display HDR con tutte le funzionalità Avanzate colore

La maggior parte degli altri membri di DXGI_OUTPUT_DESC1 forniscono informazioni quantitative sul volume di colore fisico del pannello (luminanza e dominanza), corrispondente ai metadati HDR statici SMPTE ST.2086. Anche se ST.2086 è stato originariamente progettato per i display HDR, queste informazioni sono utili ed è disponibile sia per schermi HDR che SDR. È consigliabile usare queste informazioni per configurare il mapping del tono e il mapping di gamut dell'app.

Le app desktop Win32 non hanno un meccanismo nativo per rispondere alle modifiche alle funzionalità avanzate del colore. Se invece l'app usa un ciclo di rendering, è consigliabile eseguire una query su IDXGIFactory1::IsCurrent con ogni fotogramma. Se restituisce FALSE, è necessario ottenere un nuovo DXGI_OUTPUT_DESC1 e verificare quali valori sono stati modificati.

Inoltre, il message pump Win32 deve gestire il messaggio WM_SIZE , che indica che l'app potrebbe essere stata spostata tra diversi schermi.

Il codice di esempio seguente proviene dall'app di esempio HDR Direct3D 12 su 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));

Configurazione della catena di scambio DirectX

Dopo aver determinato che la visualizzazione supporta attualmente le funzionalità Colore avanzato, configurare la catena di scambio come indicato di seguito.

Usare un effetto flip presentation model

Quando si crea la catena di scambio usando una delle proprietà CreateSwapChainFor[Hwnd|Composizione |I metodi CoreWindow] devono usare il modello di scorrimento DXGI selezionando l'opzione DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL o DXGI_SWAP_EFFECT_FLIP_DISCARD , che rende la catena di scambio idonea per l'elaborazione avanzata dei colori da DWM e varie ottimizzazioni a schermo intero. Per altre informazioni, vedere Per ottenere prestazioni ottimali, usare il modello di flip DXGI.

Opzione 1. Usa il formato di pixel FP16 e lo spazio colore scRGB

Windows 10 supporta due combinazioni principali di formato pixel e spazio colori per Il colore avanzato. Selezionare una in base ai requisiti specifici dell'app.

È consigliabile che le app per utilizzo generico usino l'opzione 1. È l'unica opzione che funziona per tutti i tipi di API avanzate per la visualizzazione, il contenuto e il rendering. Quando si crea la catena di scambio, specificare DXGI_FORMAT_R16G16B16A16_FLOAT nel DXGI_SWAP_CHAIN_DESC1. Per impostazione predefinita, una catena di scambio creata con un formato pixel a virgola mobile viene considerata come se usa lo spazio colore DXGI_COLOR_SPACE_RGB_FULL_G10_NONE_P709 . Si tratta dello stesso formato di pixel e dello spazio dei colori usato da DWM.

Tale combinazione fornisce l'intervallo numerico e la precisione per specificare qualsiasi colore fisicamente possibile ed eseguire un'elaborazione arbitraria, inclusa la fusione.

Tuttavia, questa opzione usa 64 bit per pixel, che raddoppia la larghezza di banda della GPU e il consumo di memoria rispetto ai formati di pixel UINT8 tradizionali. ScRGB usa inoltre valori numerici esterni all'intervallo normalizzato [0, 1] per rappresentare i colori esterni alla gamma sRGB e/o superiori a 80 nit di luminanza. Ad esempio, scRGB (1.0, 1.0, 1.0) codifica il bianco D65 standard a 80 nit; ma scRGB (12.5, 12.5, 12.5) codifica lo stesso bianco D65 a 1000 nits molto più luminoso. Alcune operazioni grafiche richiedono un intervallo numerico normalizzato ed è necessario modificare l'operazione o normalizzare nuovamente i valori di colore.

Il modo in cui i valori di luminanza vengono interpretati con tale opzione differisce tra i display SDR e HDR; vedere di seguito.

Opzione 2: usa il formato pixel UINT10/RGB10 e lo spazio colori HDR10/BT.2100

L'opzione 2 è un'ottimizzazione delle prestazioni disponibile solo se l'app soddisfa tutte le condizioni seguenti:

• È destinato a un display HDR
• Usa Direct3D 12 o Direct3D 11
• La catena di scambio non richiede la fusione con alfa/trasparenza

Se l'app non soddisfa tutte queste condizioni, devi usare l'opzione 1.

Tuttavia, se l'app è idonea per l'opzione 2, ciò potrebbe offrire prestazioni migliori se l'app usa contenuto con codifica HDR10, ad esempio un lettore video o se verrà usato principalmente in scenari a schermo intero, ad esempio un gioco. Quando si crea la catena di scambio, è consigliabile specificare DXGI_FORMAT_R10G10B10A2_UNORM in DXGI_SWAP_CHAIN_DESC1. Per impostazione predefinita, viene considerato come usato lo spazio dei colori sRGB; pertanto, devi chiamare in modo esplicito IDXGISwapChain3::SetColorSpace1 e impostare come spazio colore DXGI_COLOR_SPACE_RGB_FULL_G2084_NONE_P2020, noto anche come HDR10/BT.2100.

Questa opzione usa gli stessi 32 bit per pixel dei formati pixel UINT8 SDR tradizionali. Inoltre, su determinate GPU questo elimina alcune elaborazioni necessarie per convertire il contenuto nel formato di collegamento HDR10.

Uso di una catena di scambio colori avanzata quando lo schermo è in modalità SDR

È possibile usare una catena di scambio colori avanzata anche se lo schermo non supporta tutte le funzionalità Avanzate colore. In questi casi, Desktop Window Manager (DWM) renderà inattivo il contenuto in base alle funzionalità dello schermo eseguendo il ritaglio numerico. Ad esempio, se si esegue il rendering in una catena di scambio FP16 scRGB e si fa riferimento a uno schermo standard, tutti gli elementi esterni all'intervallo numerico [0, 1] vengono ritagliati.

Questo comportamento di downconversion si verificherà anche se la finestra dell'app si allontana da due o più schermi con funzionalità avanzate di colore diverse. AdvancedColorInfo e IDXGIOutput6 vengono astratti in modo da segnalare solo le caratteristiche della visualizzazione principale (il principale da definire come visualizzazione contenente il centro della finestra).

Trova la corrispondenza tra il bianco di riferimento dell'app e il livello bianco del riferimento SDR del sistema operativo

In molti scenari, la tua app vuole eseguire il rendering del contenuto SDR e HDR; ad esempio il rendering di sottotitoli o controlli di trasporto su video HDR o interfaccia utente in una scena di gioco. È importante comprendere il concetto di livello bianco di riferimento SDR per assicurarsi che il contenuto SDR sia corretto su uno schermo HDR. Il bianco di riferimento indica la luminosità in corrispondenza della quale viene visualizzato un oggetto bianco diffuso (ad esempio un foglio di carta o a volte l'interfaccia utente) in una scena HDR. Poiché i valori dei colori HDR hanno una luminosità con riferimento alla scena, un particolare valore di colore deve essere visualizzato a un livello di luminanza assoluto e non rispetto al valore massimo possibile del pannello. Ad esempio, scRGB (1.0, 1.0, 1.0) e HDR10 (497, 497, 497) codificano entrambi il bianco D65 esattamente a 80 nits luminanza. Windows consente all'utente di modificare il livello bianco di riferimento SDR in base alle proprie preferenze, ovvero la luminanza in cui Windows eseguirà il rendering di sRGB (1.0, 1.0, 1.0) in corrispondenza di . Nei monitor HDR desktop, i livelli bianchi di riferimento SDR sono in genere impostati su circa 200 nit.

L'app HDR deve consentire all'utente di impostare il livello bianco di riferimento desiderato o di leggere il valore configurato dal sistema. È necessario eseguire il mapping dei valori di colore bianco diffusi nella scena al livello bianco di riferimento SDR. Ciò comporta la moltiplicazione del framebuffer dell'app nello spazio gamma lineare.

Se l'app esegue sempre il rendering di SDR e HDR in superfici separate e si basa sulla composizione del sistema operativo, Windows eseguirà automaticamente la regolazione corretta per aumentare il contenuto SDR al livello bianco desiderato. Ad esempio, se l'app usa XAML ed esegue il rendering del contenuto HDR nel proprio SwapChainPanel.

Tuttavia, se la tua app esegue la propria composizione di contenuto SDR e HDR in una singola superficie, sei responsabile di eseguire manualmente la regolazione del livello bianco di riferimento SDR. In caso contrario, il contenuto SDR potrebbe sembrare troppo dim in condizioni di visualizzazione desktop tipiche. Prima di tutto, è necessario ottenere il livello bianco di riferimento SDR corrente e quindi è necessario modificare i valori di colore di qualsiasi contenuto SDR di cui si esegue il rendering.

Passaggio 1: Ottenere il livello bianco di riferimento SDR corrente

È possibile ottenere il livello bianco di riferimento SDR corrente in uno dei modi seguenti:

• In un'app desktop. DISPLAYCONFIG_SDR_WHITE_LEVEL e QueryDisplayConfig.
• In un'app UWP. AdvancedColorInfo.SdrWhiteLevelInNits (tramite CoreWindow).

Passaggio 2. Regolare i valori di colore del contenuto SDR

Windows definisce il livello bianco nominale, o predefinito, a 80 nit. Pertanto, se si dovesse eseguire il rendering di un sRGB standard (1.0, 1.0, 1.0) in una catena di scambio FP16, verrà riprodotto a 80 nit di luminanza. Per trovare la corrispondenza con il livello bianco di riferimento definito dall'utente effettivo, è necessario modificare il contenuto SDR da 80 nit al livello specificato tramite AdvancedColorInfo.SdrWhiteLevelInNits.

Se si esegue il rendering usando FP16 e scRGB o qualsiasi spazio colore che usa la gamma lineare (1,0), è sufficiente moltiplicare il valore del colore SDR per AdvancedColorInfo.SdrWhiteLevelInNits / 80. Se si usa Direct2D, è presente una costante predefinita D2D1_SCENE_REFERRED_SDR_WHITE_LEVEL, che ha un valore pari a 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;

Se si esegue il rendering usando uno spazio colore gamma non lineare, ad esempio HDR10, l'esecuzione della regolazione del livello bianco SDR è più complessa. Se stai scrivendo un pixel shader personalizzato, valuta la possibilità di convertire in gamma lineare per applicare la regolazione.

Adattare il contenuto HDR alle funzionalità dello schermo usando il mapping dei toni

I display HDR e Advanced Color variano notevolmente in termini di capacità. Ad esempio, nella luminanza minima e massima e nella gamma di colori che sono in grado di riprodurre. In molti casi, il contenuto HDR conterrà colori che superano le funzionalità dello schermo. Per la migliore qualità dell'immagine è importante eseguire il mapping dei toni HDR, comprimendo essenzialmente l'intervallo di colori per adattarsi allo schermo mantenendo al meglio la finalità visiva del contenuto.

Il parametro singolo più importante da adattare per è max luluminanza, noto anche come MaxCLL (livello di luce del contenuto); Matrici di tono più sofisticate adatteranno anche min luluminanza (MinCLL) e/o primarie di colore.

Passaggio 1: Ottenere le funzionalità del volume dei colori dello schermo

App UWP (Universal Windows Platform)

Usare AdvancedColorInfo per ottenere il volume di colori dello schermo.

App DirectX Win32 (desktop)

Usare DXGI_OUTPUT_DESC1 per ottenere il volume di colori dello schermo.

Passaggio 2. Ottenere le informazioni sul volume dei colori del contenuto

A seconda della provenienza del contenuto HDR, esistono diversi modi per determinare la luminanza e le informazioni sulla gamma di colori. Alcuni file video HDR e immagine contengono metadati SMPTE ST.2086. Se il rendering del contenuto è stato eseguito in modo dinamico, è possibile estrarre informazioni sulla scena dalle fasi di rendering interne, ad esempio la sorgente di luce più luminosa in una scena.

Una soluzione più generale ma costosa dal livello di calcolo consiste nell'eseguire un istogramma o un altro passaggio di analisi sul frame sottoposto a rendering. L'app di esempio di rendering avanzato delle immagini a colori Direct2D in GitHub illustra come eseguire questa operazione usando Direct2D. Di seguito sono inclusi i frammenti di codice più rilevanti:

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

Passaggio 3. Eseguire l'operazione di tono hdr

Tonemapping è intrinsecamente un processo di perdita e può essere ottimizzato per una serie di metriche percettive o obiettivo, quindi non esiste un singolo algoritmo standard. Windows offre un effetto tonomapper HDR incorporato come parte di Direct2D e nella pipeline di riproduzione video HDR di Media Foundation. Alcuni altri algoritmi comunemente usati includono ACES Filmic, Reinhard e ITU-R BT.2390-3 EETF (funzione di trasferimento elettrico-elettrico).

In questo esempio di codice seguente viene illustrato un operatore reinhard tonemapper semplificato.

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

Acquisizione del contenuto dello schermo HDR e WCG

Le API che supportano la specifica dei formati pixel, ad esempio quelli nello spazio dei nomi Windows.Graphics.Capture, e il metodo IDXGIOutput5::D uplicateOutput1, offrono la possibilità di acquisire contenuto HDR e WCG senza perdere informazioni sui pixel. Si noti che, dopo l'acquisizione di frame di contenuto, è necessaria un'elaborazione aggiuntiva. Ad esempio, il mapping del tono HDR-to-SDR (ad esempio, la copia dello screenshot SDR per la condivisione Internet) e il salvataggio del contenuto con un formato appropriato (ad esempio, JPEG XR).

Modifiche alla gestione dei colori legacy e al comportamento del profilo ICC

La gestione avanzata dei colori e dei colori automatica garantisce colorimetricamente accurati e coerenti per il colore di visualizzazione per tutte le app, legacy e moderne. Tuttavia, alcune app possono eseguire la propria gestione esplicita dei colori usando profili di colore International Color Consortium (ICC).

Quando Il colore avanzato è attivo nei display SDR o HDR, il comportamento dei profili ICC visualizzati cambia in modi non compatibili con le versioni precedenti. Se l'app funziona con i profili ICC visualizzati, Windows offre helper di compatibilità per garantire che l'app continui a ottenere un comportamento corretto.

Altre informazioni sulle modifiche apportate al comportamento del profilo ICC e su come adattare la tua app per ottimizzare la compatibilità con Il colore avanzato, fai riferimento al comportamento del profilo ICC con colore avanzato.

Risorse aggiuntive

• In GitHub, uso del rendering HDR con DirectX Tool Kit per DirectX 11 / DirectX 12. Procedura dettagliata su come aggiungere il supporto HDR a un'app DirectX usando DirectX Tool Kit (DirectXTK).
• App di esempio di rendering avanzato delle immagini a colori Direct2D. App di esempio UWP SDK che implementa un visualizzatore di immagini HDR e WCG con riconoscimento dei colori avanzato con Direct2D. Illustra la gamma completa di procedure consigliate per le app UWP, inclusa la risposta alle modifiche alle funzionalità di visualizzazione e la regolazione per il livello bianco SDR.
• App di esempio desktop HDR direct3D 12. Esempio di Desktop SDK che implementa una scena HDR direct3D 12 di base.
• App di esempio UWP DIRECT3D 12 HDR. Equivalente UWP dell'esempio precedente.
• SimpleHDR_PC. Un'app di esempio pc SimpleHDR di Xbox ATG (un'app di esempio desktop) che implementa una scena HDR Direct3D 11 di base.