Windows Colour Management

Windows has always taken a different approach to display colour than macOS - historically much simpler, and more thoroughly documented. But that does not make it simple use or understand.

Between a legacy pipeline still active on many systems, a newer "Advanced Color" architecture, HDR, and a separate Auto Color Management feature for ordinary SDR screens, there are now several different mechanisms that can be correcting - or silently not correcting - what you see.

This page assumes you have already read What's Wrong with ICCs?, which covers the general limitations of ICC based display calibration. Everything on that page still applies to Windows. This page covers what is specific to Windows - old and new.


A Few Terms, in Plain Language, Before We Start

The fuller technical detail is below for anyone who wants it - these are just the plain versions to keep in mind while reading.

ICC profile - a small file describing how a specific device (your monitor, a printer, a scanner) actually reproduces colour, so software can correct for it.

Gamma ramp / VCGT - Windows' original, simple correction: one dial each for red, green and blue, used to fix grey scale and white point. It cannot touch colour saturation or gamut at all.

1D LUT - a more precise version of the same idea as a VCGT dial - still one channel at a time, still unable to perform genuine gamut correction.

3D LUT (volumetric correction) - a far more detailed correction that can fix colour errors a 1D dial physically cannot reach. This is what real, professional calibration relies on.

Advanced Color - Microsoft's umbrella term for the newer, GPU-accelerated colour architecture covering HDR, wide gamut SDR, and higher bit depth together.

Gamut - the full range of colours a display is physically capable of showing.


The Legacy Pipeline - What Windows Has Always Done

In plain terms: for about twenty years, Windows itself did no colour management at all. Individual applications - Photoshop being the classic example - did their own colour management using the ICC profile you assigned, using Windows only as a place to store that profile. Everything else was simply assumed to be sRGB.

When an app is not colour managed, Windows sends its pixels through mostly unmodified, beyond whatever grey scale correction sits in the graphics card's gamma ramp - the same VCGT style 1D per-channel table used on a Mac, loaded via a similar mechanism. This is fundamentally why, historically, "installing an ICC profile" on Windows was never enough on its own: unless the specific application you were using was itself ICC aware, most of what you saw on screen was not colour managed at all, gamma ramp aside.

This legacy behaviour has not gone away. It is still exactly how Windows behaves for any system, application, or display where the newer architecture below is not active.

The modern replacement is more capable, more precise, and GPU accelerated - but it has exactly the same architectural ceiling as the legacy pipeline it replaces, and the same ceiling ColorSync has on a Mac. Think of it like adjusting a photograph: a 3x3 matrix is like rotating and scaling the whole colour wheel at once - powerful, but it treats every pixel the same way. A 1D LUT is like the brightness and contrast sliders - simple, global, one setting per channel. Neither can selectively repaint individual colours the way a genuine 3D LUT can.

Per Microsoft's own technical documentation, the modern Windows colour transform pipeline (introduced in Windows 10, version 2004) consists of exactly two programmable stages: a 3x3 colour matrix, operating in linear CIEXYZ space, and a 1D LUT, applied after the display's transfer function. Nothing else. There is no volumetric, 3D LUT stage anywhere in this pipeline - by design, not by omission.

A 3x3 matrix cannot perform the kind of selective, saturation-dependent correction a 3D LUT is built for. A 1D LUT cannot touch gamut at all. This is architecturally true of Windows' modern pipeline, exactly as it is true of matrix-plus-VCGT on a Mac - not a shortcoming unique to either platform.

MHC2 - How the Modern Pipeline Is Actually Programmed

Windows provides no direct, real-time API for controlling this pipeline. Instead, per Microsoft's documentation, an application or calibration tool accesses it by writing a specially formatted ICC profile containing a private tag called MHC2 ("Microsoft Hardware Calibration") - conceptually the direct successor to the VCGT tag used by the legacy gamma ramp pipeline. A profile containing valid MHC2 data is referred to as an "MHC profile."

An MHC2 tag can contain the matrix and 1D LUT correction data described above - or, just as validly, no transform data at all (explicitly marked as an identity transform). Either way, per Microsoft's specification, an MHC profile must also always contain a defined set of ST.2086 HDR static metadata: peak luminance, minimum luminance, full-frame luminance, colour primaries, and white point. A profile containing only this metadata and no correction data is still valid, and is used specifically to give HDR content and apps more accurate information about the display, even where no active correction is being applied.

HDR on Windows - STANDARD and EXTENDED Profiles

This is the mechanism behind something many users have noticed but not necessarily understood: switching HDR on and off on Windows can visibly change which colour profile is actually in effect - unlike on a Mac, where the same profile keeps working throughout.

Per Microsoft's own documentation, every display profile association on Windows carries a subtype: STANDARD or EXTENDED. A profile intended for ordinary SDR use - including Advanced Color SDR, covered below - is subtype STANDARD, which is also the default if nothing else is specified. A profile intended for use while HDR is active is subtype EXTENDED. When HDR is switched on, only EXTENDED profiles are used at all; STANDARD profiles for that display are ignored outright, not merely deprioritised. This is what is actually happening when a "Windows HDR Calibration" or "Advanced Profile" appears to take over from your normal profile the moment HDR is enabled.

This is a genuinely different mechanism from macOS's approach. On a Mac, per our Mac Colour Management page, third party HDR displays keep using the same, single assigned ICC profile throughout, with HDR layered on top via EDR - the profile itself never switches. On Windows, HDR genuinely does switch to a separate profile association, by design, at the API level.

The sRGB Trap for Non-Aware Applications

When Advanced Color is active - whether that is HDR, or Auto Color Management on an SDR display, covered next - Microsoft's documentation is explicit that any application asking Windows for "the default ICC profile" the traditional way is simply told "no profile," which by convention means sRGB - regardless of what profile is actually installed and assigned for that display.

This is deliberate, not a bug: it exists so that an application which has not been updated for Advanced Color cannot accidentally over-saturate a wide gamut or HDR display by applying its own colour management on top of Windows' now doing the job automatically. But the practical effect for anyone relying on a traditional ICC workflow is real - your application can end up quietly working in sRGB, on a wide gamut display, with no error or warning.

Windows 11 does provide a per-application "Use legacy display ICC color management" compatibility option (Settings, or the app's Compatibility properties tab) that gives such an app a synthetic profile matching the display's real characteristics instead - but it is off by default, and has to be turned on per application.

Auto HDR - A Separate, Gaming Only Mechanism

Auto HDR is easy to confuse with everything above, but it is architecturally unrelated to display calibration entirely. It is a real time tone mapping pass, applied by Windows to the output of DirectX 11 and DirectX 12 games specifically, that expands an SDR game's brightness and colour range to make use of HDR headroom on an HDR capable display - without the game itself needing to support HDR natively.

Microsoft's own description of the underlying approach, from the Xbox team that originally built it, is a tone mapper placed in the display pipeline that takes an existing SDR frame and raises brightness in the appropriate regions, without altering colour. It cannot restore fine detail that was already lost when the original SDR image was rendered - it can only redistribute and expand what survived that process. Exactly how much additional information it draws from a game's rendering buffers, beyond the final frame, is still debated in some technical communities and is not something Microsoft documents in detail.

The important point for calibration purposes: Auto HDR has nothing to do with your display profile, MHC2 data, or STANDARD/EXTENDED profile switching. It only affects supported games, and only while HDR is active.

Auto Color Management (ACM) - Advanced Color Comes to Ordinary SDR Screens

Introduced with the Windows 11 2022 Update, Auto Color Management extends the same Advanced Color architecture used for HDR to perfectly ordinary, non-HDR, wide gamut SDR displays - hardware accelerated, system level colour management that applies whether or not the application in use is itself colour aware.

The intent, per Microsoft, is straightforward: content that does not explicitly target a wider gamut gets consistently mapped into sRGB, while content and applications that do target a wider gamut get access to it - all without every individual application needing its own colour management. It uses the same STANDARD profile subtype and the same MHC2 mechanism described above; it is simply no longer limited to HDR.

The setting is visible in Windows Settings as "Automatically manage color for apps," under Display > Color management, and can be switched on or off per display.

A Current, Practical Problem - ACM Versus Calibration Software

This is not something Microsoft documents as a known issue, but it is genuinely widely reported, by both users and calibration vendors themselves, and worth taking seriously if you calibrate displays on Windows 11.

Since Windows 11 version 24H2 extended Auto Color Management's reach, a consistent, repeated pattern has been reported across multiple independent sources: with "Automatically manage color for apps" switched on, third party profiling software - including Calibrite's own Profiler and DisplayCAL/ArgyllCMS - can fail to correctly detect a wide gamut display's actual characteristics during profiling, in some cases defaulting to treating it as a standard sRGB panel, or in others failing outright with an error while saving the resulting profile.

The practical guidance, until this is resolved one way or the other: before calibrating any display on Windows 11 with SpaceMan, ColourSpace, or any other third party calibration tool, switch HDR off and switch "Automatically manage color for apps" off for that display, calibrate as normal, and only re-enable either afterwards if you specifically need them and have verified your resulting profile still behaves as expected.

Windows Versus macOS - Side by Side

Windows

  • Legacy pipeline: no OS level colour management at all unless the app does its own, plus a simple VCGT-style gamma ramp
  • Modern pipeline: matrix + 1D LUT, programmed via the MHC2 ICC tag - GPU accelerated
  • HDR genuinely switches to a separate EXTENDED-subtype profile at the API level
  • Auto Color Management extends the same architecture to ordinary SDR wide gamut displays
  • Non-aware apps risk being silently clamped to sRGB under Advanced Color

macOS

  • ColorSync is always active for every app, system wide - no legacy "unmanaged" state exists
  • Standard pipeline: matrix + VCGT, via the assigned ICC profile
  • XDR displays use factory Reference Modes; third party HDR displays keep the same, single assigned profile throughout - it never switches
  • No equivalent of Auto Color Management - the same ICC mechanism covers SDR and HDR alike on non-XDR screens

Neither platform's modern architecture supports genuine volumetric, 3D LUT correction for live display output. Both cap out at matrix-plus-1D-channel-correction, whatever that mechanism happens to be called. This is the reason Active LUT within ColourSpace exists as a separate path entirely - see below.

The Only Way to Actually Know

As with macOS, nothing above supports genuine volumetric correction for live display output, on either the legacy or the modern Windows pipeline. Matrix and 1D LUT - whatever it happens to be called - remains the ceiling.

ColourSpace's own Active LUT function sidesteps this entirely, applying a genuine 3D LUT correction directly within ColourSpace's own Colour Engine, rather than depending on Windows' own colour pipeline, whichever version of it happens to be active on a given system. That is a guarantee neither the legacy gamma ramp nor the modern Advanced Color architecture can offer, on any version of Windows.