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.
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.
ColorSync Is Always Active - There Is No Bypass
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 an identity transform, where 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. 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
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.
General Colour Conversion and Display Assignment Are Not the Same Thing
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?
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.
-
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
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.
Apple's 'Reference Mode' Hardware Calibration
Apple's higher end displays - Pro Display XDR, Studio Display XDR, and the built in screens of 2021 and later MacBook Pro models - calibrate through Reference Modes rather than a conventional assigned ICC profile. Apple's Pro Display Calibrator can fine tune white point and luminance across all of these, 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, 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.
The Only Way to Actually Know
None of the mechanisms on this page can be confirmed from outside. Which ICC profile is assigned, and whether it contains a VCGT or volumetric data, can be checked. Whether that data is actually being used, by which application, cannot.
ColourSpace's own Active LUT function sidesteps this entire question, rather than trying to answer it. It applies a 3D LUT correction directly, within ColourSpace's own Colour Engine, forcing the result onto the output rather than depending on whether some unseen combination of application, CMM, and macOS version happens to honour an installed ICC profile correctly. That is a guarantee ColorSync, on any Mac, on any macOS version, simply cannot offer.
The most dependable approach on a Mac remains the same one we recommend on What's Wrong with ICCs?: calibrate the display itself, accurately, using a real 3D LUT, and reduce the Mac's own ICC profile to a simple, honest description of that result - a matrix and curve profile with no volumetric data to silently fail. If you still want to build a volumetric ICC for a Mac regardless, SpaceMan will build one to your data accurately - just do so with a clear understanding of everything on this page.
Performing a Mac Calibration, Step by Step
Given everything above, here are the real, practical options for calibrating a Mac connected display using ColourSpace, PatternSpace, and SpaceMan. This assumes a standard graphics card attached monitor, or a Mac's own built in screen, with no onboard hardware calibration of its own - the same scope as the rest of this page.
Both routes below share the same first stage: an accurate, volumetric characterisation of the display's actual behaviour. Where they differ is what SpaceMan is then asked to do with that data.
Stage One - Characterising the Display
ColourSpace itself does not currently run natively on a Mac, so PatternSpace takes the role of the pattern generator, with ColourSpace running as usual and driving the measurement.
-
Connect PatternSpace as the pattern source
At present this connection and its settings are configured directly within PatternSpace itself, rather than remotely from ColourSpace, pending fuller integration via PatternSpace's SDK.
-
Set PatternSpace to match the display's currently assigned colour space
This is the identity transform technique covered above - it obtains a clean, native reading for characterisation, provided the display's currently assigned profile has no active VCGT of its own left over from a previous calibration.
-
Characterise the display in ColourSpace
Run a full, volumetric patch set through the connected probe, exactly as for any other display. This is the measurement data both routes below are built from.
-
Generate the calibration 3D LUT and confirm it with Active LUT
Before touching an ICC at all, use ColourSpace's Colour Engine to generate the calibration LUT, and verify it directly with Active LUT. This confirms what an accurate calibration actually looks like on this display, entirely independent of ColorSync.
Route A - Embedding the 3D LUT Into an ICC
This route is a bet on a specific target application's own colour engine reading the volumetric data - not on macOS itself, which is a confirmed no, covered earlier on this page. It is a reasonable bet for Adobe applications specifically, given the real evidence covered above, though not a guaranteed one for any application or version.
SpaceMan's default Display Class export contains only the LUT tags, plus a VCGT if built. It does not add the separate matrix and TRC tags on its own - that is a deliberate extra step below, not something to assume has already happened.
-
Load the calibration LUT into SpaceMan and build the Display Class profile
Use the same 3D LUT generated and confirmed with Active LUT in Stage One. This produces a profile containing only the LUT tags (plus a VCGT, if that option is used) - no matrix or TRC data at all yet.
-
Build a matrix and TRC fallback, and copy it into the same profile
Build a second, separate profile containing only the matrix and TRC tags, using the same measured primaries as Route B below. Then use SpaceMan's tag export and import tools to copy those tags across into the LUT based profile from Step 1, so the one file ends up containing both representations. Without this step, macOS's own default colour handling has nothing to fall back on at all - see our SpaceMan manual for exactly how to do this.
-
Assign the profile as the Mac's display ICC
Via System Settings, or ColorSync Utility if System Settings does not offer the option for the display in question.
-
Verify with correctly tagged content, not an identity transform
Tag test content as the original target space against the newly assigned profile, so a genuine conversion is actually forced. Checking via Preview or Quick Look confirms the matrix fallback, not the volumetric data - that is expected, not a sign of a badly built profile. The verification that actually matters is within whichever application will be used day to day. Adobe applications have the best evidenced chance of correctly reading the volumetric tag, but check the specific application and version rather than assuming it from this page alone.
-
Treat any application specific result as provisional
Re-check after any macOS or application update. Apple's own position on volumetric ICC profiles has hardened over time rather than staying fixed, and there is no guarantee a given application's own colour engine continues to behave the same way release to release.
Route B - A Matrix Only ICC Built From the Display's Real Primaries
This route makes no assumption about ColorSync's handling of volumetric data at all, so it is fully reliable - at the cost of being capped at the same matrix and VCGT limitation covered throughout this page. The key difference from a typical manufacturer ICC is that the primaries used are the display's own actual measured values, not an assumed standard such as sRGB or Rec709.
-
Extract the display's real measured primaries
Either automatically from the Stage One characterisation, using ColourSpace's Library > Modify > Extract Space option, or manually - measure 100% Red, Green, Blue and White on the Calibration Interface and record the resulting xy values yourself, exactly as described in the Calibrating a Display to Itself section of What's Wrong with ICCs?
-
Enter the primaries and white point directly into SpaceMan's ICC tags
Rather than embedding any volumetric data, enter the measured xy values, white point, and target gamma directly into SpaceMan's matrix/colorant and TRC tag fields. The profile now describes the display's real colorant behaviour, not an assumed target.
-
Build the VCGT from the same characterisation data
The grey scale and white point correction still comes from the Stage One measurement, exactly as it would for the LUT in Route A.
-
Assign this profile as the Mac's display ICC
The same assignment step as Route A - but with no volumetric tag present at all for a CMM to interpret correctly, incorrectly, or not at all.
-
Understand what this profile is actually telling ColorSync
It is no longer claiming the display achieves a standard space such as sRGB or Rec709. It is honestly describing the display's own native gamut. Applications that respect the profile get an accurate conversion into that real gamut. Applications that do not still are not being corrected against a false assumption.
Which route to use
Route A can, when everything happens to line up, deliver more accurate colour than Route B - but it cannot tell you when it has not. Route B will never match a true volumetric correction, but it will do exactly what it says every single time.
For most Mac based Film & TV colour work, Route B is the dependable baseline, with Route A attempted only by those who understand and accept the caveats covered throughout this page. Either way, Active LUT within ColourSpace remains the only way to actually see and confirm a true 3D LUT calibration on that display, since it never depends on ColorSync at all.
