Uso de DirectX con pantallas de alto rango dinámico y color avanzado

En este tema se muestra cómo usar DirectX con escenarios de color avanzado, incluido un alto rango dinámico (HDR), una amplia gama de colores (WCG) con administración automática de colores del sistema y una profundidad de bits alta. Las pantallas premium para ordenadores personales (PC) con al menos una de las mejoras mencionadas se están generalizando y ofrecen una fidelidad cromática significativamente mayor que las pantallas tradicionales de rango dinámico estándar (SDR).

En este tema, obtendrá una visión general de los conceptos técnicos clave detrás de la compatibilidad con Color avanzado de Windows. Aprenderá los requisitos y las instrucciones para representar contenido HDR, WCG y DirectX de alta profundidad de bits en una de estas pantallas. Si tiene una aplicación administrada por colores (por ejemplo, mediante perfiles ICC), aprenderá cómo la administración automática de colores permite mejorar la precisión del color para sus escenarios.

Introducción al color avanzado en Windows

Color avanzado es un término general de tecnologías de sistemas operativos (SO) para pantallas con una fidelidad de color significativamente mayor que las pantallas estándar. Las funcionalidades extendidas predominantes se describen en las secciones siguientes. Las funciones de Color avanzado se introdujeron por primera vez para pantallas HDR con Windows 10, versión 1709 (Fall Creators Update) y para pantallas SDR especialmente aprovisionadas con la versión 22H2 (10.0; Build 22621) de Windows 11.

Rango dinámico alto

El rango dinámico se refiere a la diferencia entre la luminancia máxima y mínima de una escena; suele medirse en nits (candelas por centímetro cuadrado). Las escenas del mundo real, como esta puesta de sol, suelen tener rangos dinámicos de 10 órdenes de magnitud de luminancia; el ojo humano puede discernir un rango aún mayor tras la adaptación.

Desde Direct3D 9, los motores gráficos han sido capaces de representar internamente sus escenas con este nivel de fidelidad físicamente exacta. Sin embargo, una pantalla típica de rango dinámico estándar solo puede reproducir algo más de 3 órdenes de magnitud de luminancia, por lo que cualquier contenido renderizado en HDR tenía que ser mapeado tonalmente (comprimido) en el rango limitado de la pantalla. Las nuevas pantallas HDR, incluidas las que cumplen la norma HDR10 (BT.2100), superan esta limitación; por ejemplo, las pantallas autoemisivas de alta calidad pueden alcanzar más de 6 órdenes de magnitud.

Gama de colores anchos

La gama de colores hace referencia al rango y la saturación de los tonos que una pantalla puede reproducir. Los colores naturales más saturados que el ojo humano puede percibir constan de luz pura monocromática, como la producida por los láseres. Sin embargo, las pantallas de gran consumo solo pueden reproducir colores dentro de la gama sRGB, que representa aproximadamente el 35 % de todos los colores perceptibles por el ser humano. El diagrama siguiente es una representación del "locus espectral" humano, o de todos los colores perceptibles (a un nivel de luminancia determinado), donde el triángulo más pequeño es la gama sRGB.

Las pantallas de PC profesionales de gama alta admiten desde hace tiempo gamas de colores mucho más amplias que sRGB, como Adobe RGB y DCI-P3, que cubren aproximadamente la mitad de los colores perceptibles por el ser humano. Y estas pantallas de gama ancha son cada vez más comunes.

Administración automática de colores del sistema

La administración de colores es la tecnología y la práctica que garantizan una reproducción precisa y coherente del color en todos los dispositivos. Si es un creador de contenidos digitales, es crucial que los colores del contenido visual -como una foto, una imagen de producto o un logotipo- aparezcan igual en la pantalla que en la amplia variedad de dispositivos digitales de su audiencia.

Windows ha proporcionado API de apoyo a la administración de colores desde Windows 2000 con las API Image Color Management (ICM) y posteriormente Windows Color System (WCS). Sin embargo, esas API eran solo ayudas para las aplicaciones que deseaban o necesitaban administrar el color, mientras que la mayoría de las aplicaciones y contenidos digitales simplemente asumían el espacio de color sRGB estándar del sector y nunca eran gestionados por el sistema operativo. Antes era una suposición razonable, pero las pantallas de alta calidad y amplia gama son cada vez más comunes.

Las nuevas versiones de Windows admiten la administración automática de colores del sistema, lo que garantiza que todos los colores de todas las aplicaciones de Windows, sean o no compatibles con el color, se muestren de forma precisa y uniforme en todas las pantallas compatibles.

Nota:

La administración automática del color no es una propiedad del hardware de la pantalla, sino una función de Windows para admitir correctamente pantallas con gamas de colores más amplias que sRGB.

Precisión profunda/profundidad de bits

La precisión numérica, o profundidad de bits, se refiere a la cantidad de información utilizada para identificar los colores de forma exclusiva. Una mayor profundidad de bits permite distinguir entre colores muy similares sin artefactos como el efecto de bandas. Las pantallas de PC convencionales admiten 8 bits por canal de color, mientras que el ojo humano necesita al menos 10-12 bits de precisión para evitar distorsiones perceptibles.

Antes de Color avanzado, Desktop Window Manager (DWM) limitaba las aplicaciones de ventana a 8 bits por canal de color, aunque la pantalla admitiera una profundidad de bits mayor. Cuando Color Avanzado está activado, DWM realiza su composición utilizando coma flotante de media precisión IEEE (FP16), lo que elimina cualquier cuello de botella y permite usar toda la precisión de la pantalla.

Arquitectura del sistema de color avanzado de Windows

La información de esta sección es opcional para la creación de aplicaciones de color avanzado, pero es útil para entender cómo funciona la tecnología con el fin de optimizar la representación y el comportamiento de su aplicación.

En esta sección, usaremos un diagrama simplificado para describir los componentes relevantes de la pila gráfica de Windows:

Windows existente: pantallas de 8 bits / sRGB

Durante décadas, las pantallas de consumo y la pila gráfica de Windows se basaron en contenidos sRGB de 8 bits por canal (24 bits por píxel). Las aplicaciones que usaban API gráficas como DirectX podían realizar renderizados internos con profundidades de bits elevadas y espacios de color ampliados; sin embargo, el sistema operativo solo admitía enteros de 8 bits con sRGB implícito y sin gestión del color del sistema:

Eso significaba que los datos de color adicionales representados por una aplicación se perderían al mostrarse; y que la aplicación tenía que realizar la administración de colores para garantizar una reproducción precisa en una pantalla.

Windows 10, versión 1703: pantallas HDR con color avanzado

Windows 10, versión 1703 introdujo la primera versión de las funcionalidades de color avanzado para pantallas HDR. Eso requería varios avances significativos en la pila de gráficos del sistema operativo:

• Compatibilidad con señalización de pantalla HDR
• Composición del sistema mediante un espacio de color canónico y de gran profundidad de bits
• Administración automática de colores del sistema

Cada avance se trata en las subsecciones siguientes. El resultado es que el sistema operativo conserva correctamente los datos de color de las aplicaciones ampliadas y los reproduce con precisión en pantallas HDR.

Compatibilidad con señalización de pantalla HDR

La señalización HDR a través de conectores de pantalla como DisplayPort y HDMI usa principalmente una precisión de 10 bits por canal (o superior) y el espacio de color BT.2100 ST.2084. El kernel de pantalla, el controlador de pantalla y el hardware de GPU subyacente deben detectar, seleccionar y controlar este modo de señalización.

Composición del sistema mediante un espacio de color canónico y de gran profundidad de bits

El espacio de color BT.2100 ST.2084 es un estándar eficaz para codificar colores HDR, pero no es adecuado para muchas operaciones de renderizado y composición (mezcla). También queremos que el sistema operativo sea compatible con tecnologías y espacios de color que vayan más allá de BT.2100, que cubre menos de dos tercios de los colores visibles para el ser humano. Por último, siempre que sea posible, queremos minimizar el consumo de recursos de GPU para mejorar la potencia y el rendimiento.

Cuando está en modo HDR, Desktop Window Manager (DWM) usa un espacio de color de composición canónica (CCCS) definido como:

• espacio de color scRGB (BT.709/sRGB principalmente con gamma lineal)
• Precisión media IEEE (profundidad de 16 bits FP16)

Esto proporciona un buen equilibrio entre todos los objetivos anteriores. El CCCS permite valores de color fuera de la gama numérica [0, 1]; dada la gama de valores FP16 válidos, puede representar órdenes de magnitud de más colores que la gama visual humana natural, incluidos valores de luminancia superiores a 5 millones de nits. FP16 tiene una precisión excelente para las operaciones de mezcla gamma lineal, pero cuesta la mitad de consumo de memoria y ancho de banda de la GPU que la precisión única tradicional (FP32) sin pérdida de calidad perceptible.

Administración automática de colores del sistema

Windows es un entorno multitarea en el que el usuario puede ejecutar cualquier número de aplicaciones SDR y HDR al mismo tiempo con ventanas superpuestas. Por lo tanto, es crucial que todos los tipos de contenido se vean correctamente y con la máxima calidad cuando se emitan a una pantalla; por ejemplo, una aplicación de productividad sRGB (SDR) con una ventana de vídeo BT.2100 ST.2084 (HDR) reproduciéndose sobre ella.

Cuando está en modo HDR, Windows realiza operaciones de administración de colores en dos fases:

1. DWM convierte cada aplicación de su espacio de color nativo en CCCS antes de mezclarse.
2. El kernel de pantalla convierte el framebuffer del SO de CCCS al espacio de color de formato con cable (BT.2100 ST.2084).
   • Opcionalmente, el kernel de pantalla trabaja con el controlador de pantalla para realizar una calibración adicional del color de la pantalla; para obtener más información, consulte Canal de calibración del color de la pantalla de hardware de Windows.

Nota:

En ambas etapas, la operación de gestión del color consiste en una conversión del espacio de color (matriz y 1DLUT). Los colores que superan la gama de colores de destino de la pantalla se recortan numéricamente.

Windows 11, versión 22H2: pantallas SDR con color avanzado

Aunque la prevalencia de las pantallas HDR está creciendo rápidamente, las pantallas SDR seguirán siendo importantes en los próximos años. La compatibilidad con HDR en Windows 10, versión 1703 sentó la mayor parte de las bases necesarias para mejorar también las pantallas SDR. Windows 11, versión 22H2 amplía las funciones de color avanzado y administración automática del color a determinadas pantallas SDR que cumplen los requisitos. El diagrama de bloques gráficos para pantallas de SDR de color avanzado tiene un aspecto muy similar a HDR:

Compatibilidad con señalización de pantalla SDR con profundidad alta de bits

La señalización subyacente para pantallas SDR no ha cambiado, aunque la versión 22H2 de Windows 11 admite 10 bits por canal y más, dependiendo de las capacidades de la pantalla.

Composición del sistema mediante un espacio de color canónico y de gran profundidad de bits

La funcionalidad de color avanzado de DWM, incluida la mezcla en CCCS, se mantiene prácticamente sin cambios con respecto a las pantallas HDR. La principal diferencia es que DWM usa la luminancia a la que se hace referencia a la pantalla con pantallas SDR y la luminancia a la que se hace referencia a la escena con pantallas HDR. Esto cambia la forma en que el sistema operativo interpreta el contenido representado de color avanzado:

Tipo de pantalla	Comportamiento de la luminancia	Cómo se interpreta 1.0f
SDR	Pantalla a la que se hace referencia	Como nivel blanco de referencia de la pantalla
HDR	Escena a la que se hace referencia	Como 80 nits (blanco nominal de referencia)

Administración automática de colores del sistema

Las capacidades de administración del color del sistema operativo también se mantienen prácticamente sin cambios con respecto a las pantallas HDR. La principal diferencia es que el kernel de la pantalla convierte al espacio de color referido a la pantalla según lo definido por los datos de colorimetría y calibración de la pantalla, en lugar del espacio de color estándar BT.2100 ST.2084 para pantallas HDR.

Mostrar el aprovisionamiento necesario

Se necesitan datos precisos de un perfil MHC ICC para definir la operación de administración del color de salida del kernel de pantalla. Por lo tanto, solo las pantallas SDR que han sido específicamente aprovisionadas por el fabricante o un proveedor de calibración de pantallas con un perfil válido son elegibles para la administración automática del color. Consulte Comportamiento del perfil ICC con color avanzado para obtener más información.

Requisitos del sistema y compatibilidad con sistemas operativos

Windows 10, versión 1709, primera compatibilidad con colores avanzados para pantallas HDR. La versión 22H2 de Windows 11 agrega compatibilidad con colores avanzados para pantallas de SDR que tienen datos de aprovisionamiento precisos.

En este tema se supone que la aplicación tiene como destino Windows 10, versión 2004 (o posterior) para pantallas HDR y la versión de Windows 11, versión 22H2 (o posterior) para pantallas de SDR.

Mostrar

Una pantalla de alto rango dinámico debe implementar HDR10, o BT.2100 ST.2084, estándar. La calidad de las pantallas HDR puede variar enormemente, por lo que recomendamos encarecidamente pantallas certificadas, como VESA DisplayHDR. A partir de la versión 22H2 de Windows 11, Windows muestra el estado de certificación de las pantallas conocidas en la aplicación Configuración.

Una pantalla de rango dinámico estándar debe tener datos de aprovisionamiento de colores precisos para la compatibilidad con colores avanzados. En la versión 22H2 de Windows 11, el único método admitido para anular estos datos es a través de un perfil MHC ICC; además, el usuario o el fabricante de la pantalla deben tener activada la administración automática del color. Para obtener más información, consulte Comportamiento del perfil ICC con color avanzado.

Procesador gráfico (GPU)

Para obtener una funcionalidad completa de color avanzado en pantallas SDR y HDR, se requiere una GPU reciente:

• AMD Radeon RX serie 400 (Polaris), o más reciente
• NVIDIA GeForce serie 10 (Pascal) o posterior
• Intel Core 10ª generación (Ice Lake) o más reciente* seleccionado

Nota:

Los chipsets Intel Comet Lake (código de modelo de 5 dígitos) no ofrecen una funcionalidad completa.

Es posible que se apliquen requisitos de hardware adicionales, en función de los escenarios, incluida la aceleración de códecs por hardware (HEVC de 10 bits, VP9 de 10 bits, etc.) y la compatibilidad con PlayReady (SL3000). Para obtener información más específica, póngase en contacto con su proveedor de GPU.

Controlador gráfico (WDDM)

Se recomienda usar el último controlador gráfico disponible, ya sea de Windows Update o del sitio web del fabricante de la GPU o del PC. Este tema se basa en la funcionalidad del controlador de WDDM 2.7 (Windows 10, versión 2004) para pantallas HDR y WDDM 3.0 (Windows 11, versión 21H2) para pantallas SDR.

APIs de representación admitidas

Windows 10 admite una amplia variedad de APIs y marcos de trabajo de representación. La compatibilidad avanzada con el color depende fundamentalmente de que la aplicación pueda realizar presentaciones modernas mediante DXGI o las API de Visual Layer.

• Infraestructura de gráficos de DirectX (DXGI)
• Visual Layer (Windows.UI.Composition)

Por lo tanto, cualquier API de representación que pueda generar en uno de esos métodos de presentaciones puede admitir color avanzado. Esto incluye (pero no se limita a) lo siguiente.

• Direct3D 11
• Direct3D 12
• Direct2D
• Win2D
  • Requiere el uso de las API CanvasSwapChain o CanvasSwapChainPanel de nivel inferior.
• Windows.UI.Input.Inking
  • Admite la representación personalizada de tinta seca mediante DirectX.
• XAML
  • Admite la reproducción de vídeos HDR mediante MediaPlayerElement.
  • Admite la descodificación de imágenes JPEG XR mediante el elemento Image.
  • Admite la interoperabilidad de DirectX mediante SwapChainPanel.

Control de las funcionalidades de visualización dinámica

Windows 10 es compatible con una enorme gama de pantallas compatibles con Advanced Color, desde paneles integrados de bajo consumo hasta monitores y televisores de gama alta para juegos. Los usuarios de Windows esperan que su aplicación gestione sin problemas todas esas variaciones, incluidas las omnipresentes pantallas SDR existentes.

Windows 10 ofrece al usuario el control de las funciones HDR y Color avanzado. La aplicación debe detectar la configuración actual de la pantalla y responder dinámicamente a cualquier cambio en su capacidad. Eso puede ocurrir por muchas razones, por ejemplo, porque el usuario activó o desactivó una función, o movió la aplicación entre diferentes pantallas, o el estado de energía del sistema cambió.

Opción 1: AdvancedColorInfo

Nota:

La API AdvancedColorInfo de Windows Runtime se puede usar independientemente de la API de representación, admite colores avanzados para pantallas SDR y usa eventos para indicar cuándo cambian las funcionalidades. Sin embargo, solo está disponible para aplicaciones de Plataforma universal de Windows (UWP); las aplicaciones de escritorio (que no tienen CoreWindow) no pueden usarlas. Para obtener más información, consulte APIs de Windows Runtime disponibles para aplicaciones de escritorio.

En primer lugar, debe obtener una instancia de AdvancedColorInfo desde DisplayInformation::GetAdvancedColorInfo.

Para comprobar qué tipo de color avanzado está activo actualmente, use la propiedad AdvancedColorInfo::CurrentAdvancedColorKind. Esta es la propiedad más importante que se va a comprobar y debe configurar la canalización de representación y presentación en respuesta al tipo activo:

Tipo de color avanzado	Funcionalidades de la pantalla
SDR	Pantalla SDR sin funcionalidades de color avanzadas
WCG	Pantalla SDR con alta profundidad de bits y administración automática de colores
HDR	Pantalla HDR con todas las funcionalidades de color avanzadas

Para comprobar qué tipos de colores avanzados que están admitidos, pero no necesariamente activos, llame a AdvancedColorInfo::IsAdvancedColorKindAvailable. Podría usar esa información, por ejemplo, para pedir al usuario que vaya a la aplicación Configuración de Windows para que pueda activar HDR o la administración automática del color.

Los otros miembros de AdvancedColorInfo proporcionan información cuantitativa sobre el volumen de color físico del panel (luminancia y crominancia), correspondiente a los metadatos HDR estáticos SMPTE ST.2086. Aunque ST.2086 se diseñó originalmente para pantallas HDR, esta información es útil y está disponible tanto para pantallas HDR como SDR. Debe usar esa información para configurar la asignación tonal y la asignación de gama de la aplicación.

Para controlar los cambios en las funcionalidades de color avanzado, regístrese al evento DisplayInformation::AdvancedColorInfoChanged. Este evento se activa si cualquier parámetro de las capacidades avanzadas de color de la pantalla cambia por cualquier razón.

Para controlar el evento, debe obtener una nueva instancia de AdvancedColorInfo y comprobar qué valores han cambiado.

IDXGIOutput6

Nota:

La interfaz IDXGIOutput6 de DirectX Graphics Infrastructure está disponible para cualquier aplicación que use DirectX, ya sea de escritorio o de Plataforma universal de Windows (UWP). Sin embargo, IDXGIOutput6 no admite pantallas SDR con funciones de color avanzadas, como la gestión automática del color; solo puede identificar pantallas HDR.

Si está escribiendo una aplicación de escritorio win32 y usa DirectX para representarla, use DXGI_OUTPUT_DESC1 para obtener funcionalidades de visualización. Puede obtener una instancia de esa estructura a través de IDXGIOutput6::GetDesc1.

Para comprobar qué tipo de color avanzado está activo actualmente, use la propiedad ColorSpace , que es de tipo DXGI_COLOR_SPACE_TYPE y contiene uno de los valores siguientes:

DXGI_COLOR_SPACE_TYPE	Funcionalidades de la pantalla
DXGI_COLOR_SPACE_RGB_FULL_G22_NONE_P709	Pantalla SDR sin funcionalidades de color avanzadas
DXGI_COLOR_SPACE_RGB_FULL_G2084_NONE_P2020	Pantalla HDR con todas las funcionalidades de color avanzadas

Nota:

Las pantallas SDR con funcionalidades de color avanzado también se notifican como DXGI_COLOR_SPACE_RGB_FULL_G22_NONE_P709; DXGI no permite distinguir entre los dos tipos.

Nota:

DXGI no permite comprobar qué tipos de colores avanzados son compatibles pero no están activos en este momento.

La mayoría de los demás miembros de DXGI_OUTPUT_DESC1 proporcionan información cuantitativa sobre el volumen de color físico del panel (luminancia y crominancia), correspondiente a los metadatos HDR estáticos SMPTE ST.2086. Aunque ST.2086 se diseñó originalmente para pantallas HDR, esta información es útil, y está disponible tanto para pantallas HDR como SDR. Debe usar esa información para configurar la asignación tonal y la asignación de gama de la aplicación.

Las aplicaciones de escritorio Win32 no disponen de un mecanismo nativo para responder a los cambios de capacidad de Advanced Color. En su lugar, si la aplicación usa un bucle de representación, debe consultar IDXGIFactory1::IsCurrent con cada marco. Si notifica FALSE, debe obtener un nuevo DXGI_OUTPUT_DESC1 y comprobar los valores que han cambiado.

Además, el bombeo de mensajes Win32 debe controlar el mensaje de WM_SIZE, lo que indica que la aplicación podría haberse movido entre diferentes pantallas.

Nota:

Para obtener un nuevo DXGI_OUTPUT_DESC1, debe obtener la pantalla actual. Sin embargo, no debe llamar a IDXGISwapChain::GetContainingOutput. Esto se debe a que las cadenas de intercambio devuelven una salida DXGI obsoleta una vez que DXGIFactory::IsCurrent es falso; y recrear la cadena de intercambio para obtener una salida actual resulta en una pantalla temporalmente negra. En su lugar, se recomienda enumerar a través de los límites de todas las salidas DXGI y determinar cuál tiene la mayor intersección con los límites de la ventana de la aplicación.

El código de ejemplo siguiente procede de la aplicación de ejemplo Direct3D 12 HDR en 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));

Configuración de la cadena de intercambio de DirectX

Una vez que haya determinado que la pantalla es compatible con las funciones de color avanzado, configure la cadena de intercambio del siguiente modo.

Uso de un efecto de modelo de presentación invertida

Cuando cree su cadena de intercambio utilizando uno de los métodos CreateSwapChainFor[Hwnd|Composition|CoreWindow], debe utilizar el modelo de volteo DXGI seleccionando la opción DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL o DXGI_SWAP_EFFECT_FLIP_DISCARD, lo que hace que su cadena de intercambio sea elegible para el procesamiento de color avanzado de DWM y varias optimizaciones de pantalla completa. Para obtener más información, consulte Para obtener el mejor rendimiento, use el modelo invertido DXGI.

Opción 1. Uso del formato de píxel FP16 y el espacio de colores scRGB

Windows 10 admite dos combinaciones principales de formato de píxel y espacio de color para color avanzado. Seleccione uno en función de los requisitos específicos de la aplicación.

Se recomienda que las aplicaciones de uso general usen la Opción 1. Es la única opción que funciona para todos los tipos de pantallas de color avanzado, contenido y API de representación. Al crear la cadena de intercambio, especifique DXGI_FORMAT_R16G16B16A16_FLOAT en DXGI_SWAP_CHAIN_DESC1. De forma predeterminada, una cadena de intercambio creada con un formato de píxel de punto flotante se trata como si usara el espacio de color DXGI_COLOR_SPACE_RGB_FULL_G10_NONE_P709. Es el mismo formato de píxel y espacio de color que usa DWM.

Esta combinación proporciona el rango numérico y la precisión necesarios para especificar cualquier color físicamente posible y realizar procesamientos arbitrarios, incluida la mezcla.

Sin embargo, esa opción consume 64 bits por píxel, lo que duplica el ancho de banda de la GPU y el consumo de memoria en comparación con los formatos de píxel UINT8 tradicionales. Además, scRGB usa valores numéricos que están fuera del rango normalizado [0, 1] para representar colores que están fuera de la gama sRGB o superior a 80 nits de luminancia. Por ejemplo, scRGB (1.0, 1.0, 1.0) codifica el blanco D65 estándar a 80 nits; pero scRGB (12.5, 12.5, 12.5) codifica el mismo blanco D65 a 1000 nits mucho más brillantes. Algunas operaciones gráficas requieren un rango numérico normalizado, por lo que deberá modificar la operación o volver a normalizar los valores de color.

La forma en que se interpretan los valores de luminancia con esa opción difiere entre las pantallas SDR y HDR; consulte más abajo.

Opción 2: Usar el formato de píxel UINT10/RGB10 y el espacio de color HDR10/BT.2100

La Opción 2 es una optimización de rendimiento que solo está disponible si la aplicación cumple todas las condiciones siguientes:

• Tiene como destino una pantalla HDR
• Usa Direct3D 12 o Direct3D 11
• La cadena de intercambio no requiere la mezcla con alfa/transparencia

Si la aplicación no cumple todas esas condiciones, debe usar la Opción 1.

Pero si su aplicación cumple los requisitos para la Opción 2, entonces podría proporcionar un mejor rendimiento si la aplicación consume contenido codificado en HDR10, como un reproductor de vídeo, o si se va a utilizar principalmente en escenarios de pantalla completa, como un juego. Al crear su cadena de intercambio, debe considerar la posibilidad de especificar DXGI_FORMAT_R10G10B10A2_UNORM en DXGI_SWAP_CHAIN_DESC1. De forma predeterminada, se considera que utiliza el espacio de color sRGB; por lo tanto, debe llamar explícitamente a IDXGISwapChain3::SetColorSpace1 y establecer como espacio de color DXGI_COLOR_SPACE_RGB_FULL_G2084_NONE_P2020, también conocido como HDR10/BT.2100.

Esta opción consume los mismos 32 bits por píxel que los formatos de píxel UINT8 SDR tradicionales. Además, en determinadas GPU, esto elimina parte del procesamiento necesario para convertir el contenido al formato de cable HDR10.

Uso de una cadena de intercambio de color avanzada cuando la pantalla está en modo SDR

Puede usar una cadena de intercambio de color avanzado incluso si la pantalla no admite todas las funcionalidades de color avanzado. En estos casos, Desktop Window Manager (DWM) reducirá el contenido para ajustarlo a las capacidades de la pantalla mediante un recorte numérico. Por ejemplo, si representa a una cadena de intercambio FP16 scRGB, y tiene como objetivo una pantalla estándar, todo lo que esté fuera del rango numérico [0, 1] se recortará.

Este comportamiento de conversión a la baja también se producirá si la ventana de su aplicación se encuentra entre dos o más pantallas con diferentes capacidades de color avanzado. AdvancedColorInfo e IDXGIOutput6 se abstraen para notificar solo las características de la pantalla principal (siendo principal la pantalla que contiene el centro de la ventana).

Coincidencia del blanco de referencia de la aplicación con el nivel de blanco de referencia SDR del sistema operativo.

Nota:

El blanco de referencia solo se aplica a las pantallas HDR; para las pantallas SDR Advanced Color, (1.0, 1.0, 1.0) siempre significa la luminancia blanca máxima que la pantalla puede reproducir.

En muchos escenarios, la aplicación querrá representar contenido SDR y HDR; por ejemplo, representar subtítulos o controles de transporte sobre vídeo HDR, o IU en una escena de juego. Es importante comprender el concepto de nivel blanco de referencia de SDR para asegurarse de que el contenido de SDR es correcto en una pantalla HDR. El blanco de referencia indica el brillo con el que aparece un objeto blanco difuso (como una hoja de papel, o a veces una IU) en una escena HDR. Dado que los valores de color HDR tienen un brillo referido a la escena, un valor de color concreto debe mostrarse a un nivel de luminancia absoluto, y no relativo al valor máximo posible del panel. Por ejemplo, tanto scRGB (1.0, 1.0, 1.0) como HDR10 (497, 497, 497) codifican exactamente el blanco D65 a 80 nits de luminancia. Windows permite al usuario ajustar el nivel de blanco de referencia SDR a su preferencia; esa es la luminancia a la que Windows representará sRGB (1.0, 1.0, 1.0). En los monitores HDR de sobremesa, los niveles de blanco de referencia SDR suelen ajustarse a unos 200 nits.

La aplicación HDR debe permitir al usuario establecer el nivel de blanco de referencia deseado o leer el valor configurado por el sistema. Debe asignar los valores de color blanco difuso de su escena al nivel de blanco de referencia SDR. Esto implica multiplicar el framebuffer de la aplicación en el espacio gamma lineal.

Nota:

En una pantalla que admita un control de brillo, como en un portátil, Windows también ajusta la luminancia del contenido HDR (referido a la escena) para que coincida con el nivel de brillo deseado por el usuario, pero eso es invisible para la aplicación. A menos que esté intentando garantizar una reproducción exacta de bits de la señal HDR, por lo general puede ignorarlo.

Si la aplicación siempre renderiza SDR y HDR en superficies separadas y depende de la composición del sistema operativo, Windows realizará automáticamente el ajuste correcto para aumentar el contenido SDR al nivel de blanco deseado. Por ejemplo, si su aplicación usa XAML y representa contenido HDR en su propio archivo SwapChainPanel.

Sin embargo, si la aplicación realiza su propia composición de contenido SDR y HDR en una única superficie, será responsable de realizar el ajuste del nivel de blanco de referencia SDR. De lo contrario, el contenido de SDR puede aparecer demasiado atenuado en condiciones típicas de visualización del escritorio. En primer lugar, debe obtener el nivel de blanco de referencia de SDR actual y, a continuación, debe ajustar los valores de color de cualquier contenido de SDR que esté representando.

Paso 1. Obtener el nivel de blanco de referencia de SDR actual

Puede obtener el nivel de blanco de referencia de SDR actual de una de estas maneras:

• En una aplicación de escritorio. DISPLAYCONFIG_SDR_WHITE_LEVEL y QueryDisplayConfig.
• En una aplicación UWP. AdvancedColorInfo.SdrWhiteLevelInNits (mediante CoreWindow).

Paso 2. Ajustar los valores de color del contenido de SDR

Windows define el nivel de blanco nominal o predeterminado en 80 nits. Por lo tanto, si tuviera que representar un blanco sRGB estándar (1.0, 1.0, 1.0) en una cadena de intercambio FP16, se reproduciría con una luminancia de 80 nits. Para que coincida con el nivel de blanco de referencia definido por el usuario real, debe ajustar el contenido de SDR de 80 nits al nivel especificado a través de AdvancedColorInfo.SdrWhiteLevelInNits.

Si está representando con FP16 y scRGB, o cualquier espacio de color que use gamma lineal (1.0), simplemente puede multiplicar el valor de color SDR por AdvancedColorInfo.SdrWhiteLevelInNits / 80. Si utiliza Direct2D, existe una constante predefinida D2D1_SCENE_REFERRED_SDR_WHITE_LEVEL, que tiene un valor de 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 está representando un espacio de color gamma no lineal como HDR10, realizar el ajuste del nivel de blanco SDR es más complejo. Si está escribiendo su propio sombreador de píxeles, considere la conversión a gamma lineal para aplicar el ajuste.

Adaptar el contenido HDR a las funcionalidades de la pantalla mediante la asignación tonal

Las pantallas HDR y Color avanzado varían mucho en cuanto a sus capacidades. Por ejemplo, en la luminancia mínima y máxima y en la gama de colores que son capaces de reproducir. En muchos casos, el contenido HDR contendrá colores que superen las capacidades de la pantalla. Para obtener la mejor calidad de imagen, es importante realizar un asignación tonal HDR, que básicamente comprime la gama de colores para adaptarla a la pantalla, preservando al mismo tiempo la intención visual del contenido.

El parámetro individual más importante que debe adaptarse es la luminancia máxima, también conocida como MaxCLL (nivel de luz de contenido); los asignadores tonal más sofisticados también adaptarán la luminancia mínima (MinCLL) y/o las primarias de color.

Paso 1. Obtener las funcionalidades de volumen de color de la pantalla

Aplicaciones de la Plataforma universal de Windows (UWP)

Use AdvancedColorInfo para obtener el volumen de color de la pantalla.

Aplicaciones DirectX de Win32 (escritorio)

Use DXGI_OUTPUT_DESC1 para obtener el volumen de color de la pantalla.

Paso 2. Obtener la información del volumen de color del contenido

Dependiendo de la procedencia del contenido HDR, existen varias formas de determinar la luminancia y la gama de colores. Algunos archivos de vídeo e imagen HDR contienen metadatos SMPTE ST.2086. Si el contenido se renderiza dinámicamente, es posible que pueda extraer información de la escena a partir de las etapas internas de renderizado, por ejemplo, la fuente de luz más brillante de la escena.

Una solución más general, pero costosa desde el punto de vista de cálculo, es ejecutar un histograma u otro pase de análisis en el fotograma representado. La aplicación de ejemplo de representación avanzada de imágenes en color Direct2D en GitHub muestra cómo hacerlo mediante Direct2D; a continuación se incluyen los fragmentos de código más relevantes:

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

Paso 3. Realizar la operación de asignación tonal HDR

La asignación tonal es un proceso con pérdidas y puede optimizarse para una serie de parámetros perceptivos u objetivos, por lo que no existe un único algoritmo estándar. Windows proporciona un efecto de mapa tonal HDR integrado como parte de Direct2D, así como en el canal de reproducción de vídeo HDR de Media Foundation. Otros algoritmos usados habitualmente son ACES Filmic, Reinhard y ITU-R BT.2390-3 EETF (función de transferencia eléctrica-eléctrica).

En el siguiente ejemplo de código se muestra un operador de asignador tonal Reinhard simplificado.

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

Captura de contenido de pantalla HDR y WCG

Las API que admiten la especificación de formatos de píxeles, como las del espacio de nombres Windows.Graphics.Capture y el método IDXGIOutput5::DuplicateOutput1 , proporcionan la capacidad de capturar contenido HDR y WCG sin perder información de píxeles. Tenga en cuenta que después de adquirir marcos de contenido, se requiere un procesamiento adicional. Por ejemplo, asignación tonal de HDR a SDR (por ejemplo, copia de capturas de pantalla SDR para compartir en Internet) y guardado de contenidos con el formato adecuado (por ejemplo, JPEG XR).

Cambios en la administración de colores heredada y el comportamiento del perfil ICC

La gestión avanzada del color y el color automático garantizan un color de pantalla homogéneo y preciso desde el punto de vista colorimétrico para todas las aplicaciones, ya sean antiguas o modernas. Sin embargo, algunas aplicaciones pueden realizar su propia gestión explícita del color utilizando perfiles de color de International Color Consortium (ICC).

Cuando Color Avanzado está activo en pantallas SDR o HDR, el comportamiento de los perfiles ICC de pantalla cambia de forma no compatible. Si su aplicación funciona con perfiles ICC de pantalla, Windows ofrece ayudas de compatibilidad para garantizar que su aplicación siga teniendo un comportamiento correcto.

Para obtener más información sobre los cambios en el comportamiento de los perfiles ICC y cómo puede adaptar su aplicación para maximizar la compatibilidad con Color avanzado, consulte Comportamiento de los perfiles ICC con Advanced Color..

Recursos adicionales

• En GitHub, Usar representación HDR con el kit de herramientas de DirectX para DirectX 11 / DirectX 12. Tutorial sobre cómo agregar compatibilidad HDR a una aplicación DirectX mediante el Kit de herramientas de DirectX (DirectXTK).
• Aplicación de representación avanzada de imágenes de color de Direct2D. Aplicación de ejemplo del SDK UWP que implementa un visor de imágenes HDR y WCG avanzado y sensible al color mediante Direct2D. Demuestra toda la gama de mejores prácticas para aplicaciones UWP, incluida la respuesta a los cambios de capacidad de pantalla y el ajuste del nivel de blanco SDR.
• Aplicación de ejemplo de escritorio HDR de Direct3D 12. Ejemplo de SDK de escritorio que implementa una escena básica de Direct3D 12 HDR.
• Aplicación de ejemplo HDR UWP de Direct3D 12 Equivalente de UWP del ejemplo anterior.
• SimpleHDR_PC. Una aplicación de muestra para PC Xbox ATG SimpleHDR (una aplicación de muestra de escritorio) que implementa una escena básica Direct3D 11 HDR.