Every Mac, whether it is a laptop screen or a professional monitor connected via a graphics card, runs its colour output through Apple's ColorSync - and there is no way to switch it off, other than via a dedicated video output device, such as BMD's UltraStudio.
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 a Mac. This page covers what macOS adds on top - and it is potentially substantially worse. On a PC instead? See Windows Colour Management for the equivalent Windows story - genuinely different in the detail, though capped by the same underlying limitations.
This page is not a claim that Mac colour management categorically cannot work within its own limits. It is a claim that whether it works, for any given application and any given macOS version, cannot be reliably known - which for professional use amounts to the same thing.
It also defines the limits of Mac colour management, and how those limits are equally unacceptable for professional colour use.
Why This Page Exists
Finding straight, verifiable answers on how colour management actually behaves on a Mac is genuinely difficult - far more difficult than it should be for a subject this important to professional colour work. Apple publishes no single, complete account of how ColorSync, the system compositor, and a display's assigned ICC profile actually interact. What exists instead is scattered across developer forum answers, third party calibration tool documentation, and years of user reports, much of it contradicting other parts of it.
Some of that contradiction is real. Apple's own developer support has, on the record, stated that certain profile types have "never been supported" - a claim other experienced developers have directly and publicly disputed in the same forum thread, pointing out those profiles demonstrably worked for years. Both sides are describing something true; they are just describing different things, or different points in time, without saying so. Working out which is genuinely difficult, and it is easy - we found this out ourselves while researching this page - to draw a broader conclusion than the evidence actually supports, simply because so little of this is written down clearly anywhere in one place.
Where this page states something as fact, it is because we found it stated plainly by Apple, demonstrated directly, or corroborated independently by more than one credible source. Where the evidence is thinner than that, we have said so rather than guessed. Our own SpaceMan documentation, and the wider testing behind it, is built the same way.
A Few Terms, in Plain Language, Before We Start
This page covers some genuinely technical ground, so here are the handful of terms it leans on, explained simply first. The fuller technical detail is still there for anyone who wants it - these are just the plain-language 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.
ColorSync - Apple's built-in colour management system. It is the thing that reads ICC profiles and does the actual colour correction, system-wide, on every Mac.
CMM (Colour Management Module) - the actual piece of software code doing the colour maths described by an ICC profile. Apple has its own; Adobe applications largely use their own instead.
VCGT - a simple correction, one dial each for red, green and blue, used mainly to fix grey scale and white point. It cannot touch colour saturation or gamut at all.
3D LUT (volumetric correction) - a far more detailed correction that can fix colour errors a simple VCGT dial physically cannot reach. This is what real, professional calibration relies on.
Gamut - the full range of colours a display is physically capable of showing.
ColorSync Is Always Active - There Is No Bypass
In plain terms: on a Windows PC, you can often get a fairly direct, unprocessed signal to the screen. On a Mac, you never can. Every single thing shown on a Mac's screen is adjusted by Apple's ColorSync first, whether the app asked for it or not.
On Windows, an application that is not colour managed simply sends its pixels through, more or less unmodified beyond whatever grey scale correction sits in the graphics card's VCGT. On macOS this is not true. Every application, whether it is aware of colour management or not, has its output passed through ColorSync's pipeline before it reaches the screen. There is no setting, no flag, and no application level opt-out that removes this.
Light Illusion has stated this for years across our documentation: ColorSync is always active, system wide, on every Mac. It is worth being clear this is not just our own observation. Blackmagic Design's own engineering team has confirmed exactly the same thing about DaVinci Resolve's Mac display path - Resolve's 'Use Mac Display Color Profile' option only changes whether Resolve itself compensates for what ColorSync is doing. Whether that option is on or off, Blackmagic have confirmed the underlying macOS colour transform is applied regardless. Turning off colour management inside your application does not get you a clean, uncorrected signal on a Mac. It never has.
The closest thing to a 'native' reading on a Mac is not a bypass at all - it is what we call an identity transform: the content being shown is deliberately tagged to match the currently assigned display profile, so ColorSync's conversion collapses to doing nothing - or more accurately, almost nothing. Think of it as ColorSync being asked to convert a colour into itself - technically a conversion still happens, it just doesn't change anything. This is a useful and legitimate technique during display characterisation. It is also very easy to leave in place by accident during verification, at which point it will make a calibration potentially look good, or look like it is doing nothing, regardless of whether it actually is. Anyone measuring a Mac display needs to know which of these two states they are actually in.
The two things ColorSync can adjust
Think of it like adjusting a photograph. A VCGT is like the brightness and contrast sliders - simple, global, one setting per colour channel. A 3D LUT is like selectively repainting individual colours anywhere in the image, however they interact with each other. macOS, for its own default display handling, only ever gives you the sliders - never the repainting tool.
Based on Apple's own current position, a macOS display profile can only ever do two things to your image: apply a single 3x3 matrix and tone curve for gamut, and load a separate 1D per-channel table - the VCGT - for grey scale and white point. Neither, alone or together, is a 3D LUT.
We say this because Apple's own developer support team has confirmed, in direct response to a professional user's query, that ICC profiles carrying 3D LUT data are not a supported mechanism for macOS display profiles - regardless of whether earlier macOS versions appeared to accept them.
A 3x3 matrix cannot correct volumetric colour errors. A VCGT cannot touch gamut at all. This is architecturally true, not a quality issue with any particular profile.
Two Different Colour Pipelines on One Mac
It is not widely understood that current Macs run one of two entirely different colour architectures, depending on the display involved, and the two behave very differently.
Standard ColorSync displays - any third party monitor connected via a graphics card, and any older or non-XDR built in screen - use the conventional model above: a matrix and tone curve description in the assigned ICC profile, plus a VCGT loaded into the graphics card at login.
Apple's XDR class displays - Pro Display XDR, Studio Display XDR, and the built in Liquid Retina XDR screens of 2021 and later MacBook Pro models - use something different again, called a Reference Mode. Here the calibration data is held at the display or hardware level, not primarily in an ICC profile at all, and System Settings no longer offers manual ICC selection for these screens as a result.
Neither pipeline is capable of true volumetric correction. The standard pipeline is capped by the matrix and VCGT limitation above. Apple's own Reference Mode architecture, while a genuine hardware level calibration, remains limited to a single tone curve and white point target, with no volumetric correction available at all - so it still cannot match a true 3D LUT calibration, regardless of how the display is being driven.
HDR on a Mac - What EDR Actually Is
HDR adds a second layer on top of everything above, and it genuinely confuses people, because Apple does not handle it the way most people expect. This section explains it from first principles, then covers the two very different ways it behaves depending on the display attached.
What "HDR" Even Means Here
A standard, non-HDR ("SDR") screen has a normal maximum brightness for white - call it 100%. Every colour and every highlight in an image has to fit somewhere between black and that 100% white, no matter how bright the original scene actually was. A photo of a sunny sky simply gets its brightest parts clipped down to the same white as a sheet of paper.
HDR (High Dynamic Range) is about giving specific bright highlights - a reflection, a light bulb, a sunset - room to go brighter than that normal white, closer to how bright they actually looked in real life, while everything else on screen stays exactly where it was. That "extra brightness above normal white" is usually called headroom.
Apple's own name for its implementation of this idea is EDR - Extended Dynamic Range. It is Apple's term for both the underlying technology and the way it is rendered, and it appears throughout Apple's own developer documentation. The core concept, in Apple's own words, is genuinely simple once stated plainly: ordinary "reference white" - the normal brightest white content would use - is treated as the value 1.0. Anything brighter than that, up to whatever the display can achieve, is expressed as a value above 1.0, up to the display's maximum. A display capable of showing highlights four times brighter than its own normal white has "4.0 EDR headroom" available to it, and so on.
The important part for calibration: EDR headroom is not fixed. Apple deliberately varies how much of it is available depending on the display's own brightness setting, the ambient lighting, and which specific display and Mac are involved. The same content can legitimately use different amounts of headroom from one moment to the next, on the same screen, with nothing wrong at all.
XDR Displays - HDR Handled at the Hardware Level
On Apple's own XDR class displays - Pro Display XDR, Studio Display XDR, and the built in Liquid Retina XDR screens - HDR is simply part of the Reference Mode already covered above. There is a specific HDR Video reference preset built in at the factory, alongside the standard SDR ones, and switching between them is a hardware level change to the display itself, not an ICC profile swap.
In practice this means there is nothing for the user to configure. The display already knows its own EDR headroom at every brightness level, because Apple calibrated it that way at the factory. There is no manual ICC profile involved in this process at all, for exactly the same reason manual ICC assignment is unavailable for these screens generally (see above) - the Reference Mode architecture governs it directly.
Third Party HDR Monitors - EIZO, ASUS, and Similar
This is the situation most likely to cause confusion, because it works on a genuinely different mechanism from Apple's own XDR displays above, and it also works differently from how Windows handles the same problem.
When a third party display advertises HDR10 support and is connected to a Mac, macOS shows a single system wide "High Dynamic Range" toggle in Displays settings - this option only appears at all once macOS has detected the connected screen supports it. There is no Reference Mode here, because Reference Mode is an Apple-only, factory-calibrated mechanism specific to XDR hardware.
The critical difference from Windows: on Windows, switching HDR on replaces the active display profile with a separate, dedicated HDR profile. On a Mac, switching HDR on does not change the assigned ICC profile at all. Your existing, normally assigned ICC profile keeps doing the colour management job throughout - HDR is simply layered on top of it via EDR, engaging only while HDR content is actually on screen.
This matters because it means, unlike on Windows, your Mac ICC profile has to be correct for HDR to even display properly in the first place - there is no separate, dedicated HDR profile macOS switches to on your behalf that might paper over an imperfect one.
Monitor manufacturers who support this are explicit about the requirement. EIZO's own official guidance for their ColorEdge range states plainly that macOS requires the connected display to conform to the DCI-P3 colour gamut for HDR display - if the profile currently assigned does not, the image is not just "a bit off," it is clipped back down to the SDR range entirely, with anything above roughly 100 cd/m² rendered as flat, blown out white. EIZO's documented fix is to hardware-calibrate a dedicated P3 HDR colour mode on the monitor itself, then manually assign the resulting Display P3 profile as the Mac's display profile before switching the system HDR toggle on - macOS will not select or build this profile automatically.
XDR Versus Third Party HDR - Side by Side
Apple XDR displays (Pro Display XDR, Studio Display XDR, Liquid Retina XDR)
- HDR governed by factory Reference Mode, at the hardware level
- No manual ICC profile involved, and none offered in System Settings
- Nothing to configure - the display already knows its own headroom
- Fails safe - Reference Mode enforces its own known state regardless
Third party HDR monitors (EIZO, ASUS, and similar)
- HDR is a single system wide toggle, layered on top of EDR compositing
- The existing, normally assigned ICC profile keeps doing the colour work - it is never swapped, unlike on Windows
- That profile must specifically be DCI-P3 compliant, or HDR will not display correctly
- Fails visibly - an unsuitable profile clips the image to flat white above roughly 100 cd/m²
One further, currently open wrinkle worth knowing about rather than relying on: Apple's own developer forums have an active, unresolved report of EDR headroom reporting breaking down specifically on third party HDR displays after sleep and wake on recent macOS versions, with the HDR effect fading out over 20 to 40 minutes until the screen simply looks dim. We flag this as a known current issue, not a stable technical fact to build a workflow around.
General Colour Conversion and Display Assignment Are Not the Same Thing
In short: ColorSync is perfectly capable of reading detailed, volumetric colour data - it always has been, for things like printing and file conversion. The specific thing it struggles with is using that same detailed data for what is currently showing live on your screen. Those are two different jobs, and it is very easy to prove one works and wrongly assume the other does too.
Before going further, one distinction matters enough to state plainly, because it is very easy to conflate the two and draw the wrong conclusion from real, correct experience.
ColorSync's colour matching engine has always been able to read and use volumetric LUT data (the AToB/BToA tags) perfectly well, for as long as ICC profiles have existed on the Mac. This is not in question, and never has been. It is how printer and scanner profiles work, almost without exception, and it is how any tool that explicitly converts an image or footage through a profile - a Look burn-in, a print simulation, a soft proof - has always handled volumetric data, correctly, going back decades. Light Illusion's own AlexICC, a Mac tool from some years ago that used QuickTime to burn SpaceMan generated ICC profiles directly into footage, relied on exactly this, and worked precisely because this part of ColorSync has never been restricted.
The restriction covered throughout this page is much narrower and more specific: whether the volumetric data in whichever profile is currently assigned as a display's live device profile gets used when the system compositor or Preview renders to that screen. That is a single, specific job - live display rendering against the assigned profile - not a statement about ColorSync's general ability to process LUT based profiles, which was never in doubt and remains exactly as capable as it always was.
Anywhere this page, or Light Illusion's other documentation, states that "Apple's own default colour handling does not use volumetric data," that statement is specifically about this live display assignment case, not about ColorSync generally.
Can a Volumetric ICC Profile Even Be Used on a Mac?
Short answer: not reliably, for Apple's own default screen display - but often yes, for specific applications with their own colour engine, Adobe's being the best evidenced example. The detail below explains why those two answers can both be true at once.
Software such as Light Illusion's SpaceMan can build a genuinely volumetric ICC profile, embedding real 3D LUT data via the modern v4/iccMAX profile format, generated from an accurate ColourSpace characterisation. The question that actually matters is whether assigning that profile on a Mac causes macOS to use the volumetric data at all.
Apple's own developer support has stated plainly that LUT based display ICC profiles are not a supported mechanism on macOS - though this has genuinely hardened over time rather than being a fixed, permanent rule. A professional photographer's own report to Apple's developer support describes such profiles as installable and usable on macOS Monterey and Ventura, with the restriction tightening in more recent releases; Apple's own reply corroborates this, describing the earlier acceptance as a bug that has since "been fixed in recent updates." DisplayCAL's long documented history of black crush and posterisation errors with this profile type on macOS adds to the picture, though as a record of things going wrong rather than working unreliably.
That is the position for macOS's own default colour handling specifically. A third party application with its own compliant colour engine is a genuinely different case, and not merely a theoretical one - Adobe's applications are the best evidenced example, with professional users describing years of practice deliberately maintaining a volumetric profile specifically for use with Adobe software, alongside a separate matrix only profile for general desktop use, precisely because the two behave differently. That is real, converging, first hand evidence, not speculation. It is not an unconditional guarantee either: Adobe's own colour engine has itself recently and demonstrably regressed on current macOS and application versions, with Apple's own engine being the working fallback in at least one documented case. Which engine actually handles a given profile correctly is worth verifying for your specific application and version, not assumed either way.
What determines the outcome for any given application is a chain of three separate conditions. For Apple's own default colour handling specifically, the second of these is a confirmed no. For a third party application with its own colour engine, it is a genuine, evidenced possibility rather than a fixed answer either way - see below.
-
macOS not using ICC volumetric data
1. The content has to be tagged to actually trigger a conversion
ColorSync only converts colour when a source tag differs from the assigned display profile. Content tagged to match the display profile directly - the same identity trick used for a clean native reading - triggers no conversion at all, volumetric or otherwise, and will silently appear to do nothing.
-
2. The CMM handling that conversion has to actually read the volumetric tag
When that conversion is rendering to a screen against the assigned display profile specifically, Apple's own default colour engine - the one behind Preview, and the system compositor generally - is confirmed not to read the volumetric tag for this purpose (ColorSync's general ability to process LUT based profiles elsewhere, for image conversion, printing, or Look burn-in, is unaffected and always has been - see above). A well built v4 profile includes a matrix/tone curve fallback for exactly this reason, so the profile degrades to that instead of failing outright. This means a profile can install without any error and still be silently used only in its flattened, non-volumetric form for anything relying on the Mac's own default handling. A separate application with its own colour engine is a genuinely different case - Adobe's applications have real, multi year community evidence of correctly reading the volumetric tag for on-screen display too, well enough that professional users build entire workflows around swapping to a volumetric profile specifically for Adobe software. That is not a guarantee for every application, or a permanent guarantee even for Adobe's - it is evidenced, current best practice, not certainty.
-
3. That result has to correctly combine with the separate VCGT
The volumetric conversion, when it happens at all, and the VCGT are two architecturally separate mechanisms in the pipeline, applied at different points. Whether macOS composes the two in the way the profile was built to expect is not something Apple documents anywhere, and is not something you can inspect from outside.
For the Mac's own default colour handling, this is not really a chain of three things that could each go wrong - the second one already has, reliably. The genuine, evidenced possibility sits specifically with whichever third party applications you use and whether their own colour engine honours the volumetric tag - Adobe's applications being the clearest, best evidenced case - not with the Mac's own desktop or default viewer.
What macOS's own colour handling actually does with this data
Apple's own default colour handling - Preview, and the system compositor generally - does not use volumetric ICC data when rendering to a live display against the assigned profile. Not sometimes. Reliably. This is not a statement about ColorSync's general ability to process LUT based profiles, which is unaffected - see above.
A third party application with its own compliant colour engine is a different case, and a genuinely evidenced one - Adobe's applications in particular have years of documented professional practice built around correctly reading the volumetric tag. That is real evidence, not a maybe. It is also not a permanent guarantee: Adobe's own colour engine has itself recently regressed on current macOS and application versions, with Apple's engine being the working fallback. For the Mac's own desktop, its own default viewer, and any application relying on the system's own colour handling rather than bringing its own, the volumetric data is not the thing determining what appears on screen, full stop. For everything else, verify for your specific application and version - do not assume either way.
The VCGT Does Not Reliably Stay Loaded
In plain terms: even the simple brightness/colour-balance correction can silently switch itself off - just from putting your Mac to sleep, or plugging a monitor back in - with no warning that it has happened.
Even setting the volumetric question aside entirely, the simple 1D VCGT correction that every Mac colour workflow depends on for grey scale and white point is not guaranteed to stay active. It is well documented, across many macOS releases, that the VCGT can be silently reset by ordinary, everyday events - logging in, waking from sleep, or reconnecting an external display. On Apple's XDR class displays this reset behaviour is real but only partial: detailed user testing has found the white balance component reset while other calibration data survived the same event, which is a genuinely stranger and harder to diagnose failure mode than a clean, total reset would be.
This is not a historic problem that has since been fixed. Two separate, currently open issues confirm the pipeline is still unstable version to version. Apple's own developer support has acknowledged a bug where an identical display profile is interpreted differently, producing materially incorrect colour, purely depending on which recent macOS release is running it. Separately, on the newest Apple Silicon hardware, the system call responsible for loading the VCGT into the display has been confirmed to silently fail - it reports success, and reads back as if it succeeded, while producing no actual change on screen at all.
An ICC profile with no VCGT tag at all does not tell you anything about whether a previously loaded VCGT is still active. The two are entirely separate pieces of state, and macOS gives you no reliable way to inspect the second one directly.
Calibrating Apple's Reference Mode Displays
Reference Mode itself, and how it relates to HDR specifically, is covered in full above. This section is about actually calibrating one of these displays. Apple's Pro Display Calibrator can fine tune white point and luminance on Pro Display XDR, Studio Display XDR, and the built in Liquid Retina XDR screens of 2021 and later MacBook Pro models, and can perform a fuller calibration on supported models using a small list of approved spectroradiometers, or a specific approved colorimeter.
The newest Studio Display XDR also introduces Apple's own colour matching function - a refinement to how colour is measured, intended to improve accuracy on the narrow band backlights used in modern displays over the older, century old CIE 1931 standard most measurement tools still assume. Where this applies, a standard filter based colorimeter cannot correctly measure the display at all - a spectrophotometer capable of the newer standard is required, and only a small number of third party calibration tools currently support it.
None of this changes the fundamental limitation. Reference Mode is a genuine hardware level calibration, but it remains a single tone curve and white point target, with no volumetric correction available at any point in the chain. A perfectly executed Reference Mode calibration and a poorly executed one share the same ceiling - neither can correct the kind of volumetric, gamut level errors a 3D LUT is designed to fix.
Testing This for Yourself
If you want to see how Apple's own colour management actually behaves on a specific Mac, without needing a dedicated test pattern generator, you can embed a known ICC profile as the source tag of a plain image and open it in Preview or Quick Look - both use Apple's own default colour engine directly, rather than an application's own. This is a genuinely useful diagnostic. It is not equivalent to a proper measurement workflow, as it offers no automation, no guaranteed pixel for pixel presentation, and no control over scaling.
For an actual controlled, repeatable test signal on a Mac, PatternSpace is built for exactly this, and is fully ColourSpace compatible.
