How Chromium Handles HDR and WCG Profiles Across Monitors

This article provides an overview of the architecture behind the Chromium web browser's color management system, specifically focusing on how it processes High Dynamic Range (HDR) color spaces and Wide Color Gamut (WCG) ICC profiles. It covers how Chromium reads operating system display data, utilizes its internal graphics engine for color transformations, manages luminance levels, and dynamically adapts rendering when browser windows move across different monitors with varying capabilities.

OS Integration and Reading ICC Profiles

Chromium does not manage hardware displays directly; instead, it queries the host operating system for display characteristics. On Windows, it utilizes DirectX Graphics Infrastructure (DXGI) and Windows Color System APIs. On macOS, it relies on CoreGraphics and ColorSync.

When a monitor is connected, the operating system reads its Extended Display Identification Data (EDID) or loads a user-calibrated ICC profile. Chromium retrieves this profile data from the OS to understand the exact color primaries, white point, and transfer function (gamma) of the target display. This serves as the destination profile for the browser's rendering pipeline.

The Internal Color Pipeline and Skia

By default, the web operates in the sRGB color space, and Chromium assumes all untagged web content is sRGB. However, when Chromium encounters CSS elements, images, or videos tagged with a Wide Color Gamut profile—such as Display P3, ProPhoto RGB, or Adobe RGB—it flags the content for color transformation.

Chromium uses its 2D graphics engine, Skia, to manage these conversions. Skia extracts the embedded ICC profile of the source content and converts the colors into an intermediate profile connection space (typically XYZ D50). From there, Skia maps the colors directly to the destination monitor's ICC profile. If a user has a WCG monitor, P3 colors are displayed natively. If the user is on a standard sRGB monitor, Skia compresses the wide gamut colors to fit within the sRGB boundaries, preventing oversaturation or color clipping.

Processing High Dynamic Range (HDR)

HDR content requires both a wider color gamut (typically Rec. 2020) and a much higher range of luminance, governed by Perceptual Quantizer (PQ) or Hybrid Log-Gamma (HLG) transfer functions.

To display HDR video or images alongside standard web text without blinding the user, Chromium changes how it composites the page. When HDR content is detected on an HDR-capable monitor, Chromium upgrades its internal compositing buffer to a 16-bit floating-point (FP16) linear color space.

Chromium queries the OS for the user's preferred "SDR white level" (e.g., 200 nits). It pins all Standard Dynamic Range (SDR) elements—such as the browser UI, text, and untagged images—to this maximum brightness. The remaining luminance capability of the monitor (the "HDR headroom," which might reach 1000 nits or more) is allocated exclusively to the HDR elements. If HDR content is viewed on an SDR monitor, Chromium applies tone mapping algorithms to compress the bright highlights into the standard luminance range so visual details are preserved.

Managing Multi-Monitor Environments

Modern computing setups frequently combine monitors with vastly different capabilities, such as pairing an SDR sRGB office monitor with an HDR-capable Display P3 monitor. Chromium handles this by treating color management on a per-window basis rather than globally.

The browser's compositor tracks the specific display on which each browser window resides and assigns a distinct target color space to that window.

When a user drags a Chromium window from an SDR monitor to an HDR/WCG monitor, the following sequence occurs:

  1. The operating system detects that the majority of the window's surface area has crossed into a new display boundary and fires a display change event.
  2. Chromium intercepts this event and queries the OS for the new monitor's ICC profile and HDR headroom capabilities.
  3. The browser updates the destination profile for that specific window's compositor.
  4. Skia and the GPU process immediately recalculate the color transformations and tone mapping for the new display, re-rendering the frame buffer in real-time.

This architecture ensures that colors do not appear washed out or overly saturated when moving between displays, adapting seamlessly without requiring the user to refresh the web page.