- This topic has 15 replies, 3 voices, and was last updated 3 months ago by
.
-
Posts
-
Hello everyone,
I am facing a very persistent and elusive color management issue on Windows 11 that I cannot resolve despite extensive troubleshooting.
System Specs:
· OS: Windows 11 (Updates disabled)
· GPU: NVIDIA RTX 4070 (Studio Drivers, updates disabled)
· Calibration: DisplayCAL (ICC profile for system/Photoshop and 3D LUT for DaVinci Resolve)
The Problem: For about six months, my workflow was perfectly calibrated: I use a 3D LUT in DaVinci Resolve and the corresponding ICC profile in Photoshop. Suddenly, a significant gamma/black point mismatch occurred between the two applications, even though NO settings were changed in either Windows or Creative Cloud.
Symptoms:
· DaVinci Resolve (via Monitor 3D LUT) and iPhone (a truetone one disabled) (exported sRGB TIFF) match perfectly (1:1).
· Photoshop displays a “washed out” or shifted gamma (incorrect black point), making it impossible to match the Resolve viewer.
The “Ghost” Experiment:
1. I backed up the ICC profiles and Photoshop settings while the system was “glitched.”
2. I restored the entire OS from a clean disk image (made 6 months ago).
3. Crucial point: Even when I apply the “glitched” settings/profiles to the restored system, the problem DISAPPEARS. The shift is gone.
4. However, the fix only lasts until the first reboot. After restarting the PC, the gamma shift returns in Photoshop, while Resolve remains accurate.
· What I have already tried (with no success):
o Disabled “Fast Startup” in Power Options.
o Toggled “Black Point Compensation” in Photoshop.
o Reset Video Card Gamma Tables via DisplayCAL.
o Created a new Windows User Profile.
o Deleted all entries in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers\Configuration.
o Clean reinstallation of NVIDIA drivers.
o Re-calibrated the display and re-generated the 3D LUT.
Observation: It seems that Windows 11 (DWM/MPO) or the NVIDIA driver is overriding the Hardware LUT/Gamma Ramp upon reboot for windowed applications (like Photoshop), while DaVinci Resolve manages to bypass this via its own color engine/overlay.
How can I identify the specific process or registry trigger that causes this gamma shift after a reboot, especially since it doesn’t exist immediately after a disk image restoration?
Using ICC color mamagement (+VCGT for GPU applies system wide) + LUT3D for Resolve implies that your LUT3D for resolve cannot apply VCGT in LUT3D creation.
Maybe when you verifies Resolve’s output you were not using the exact same settings and on real word scenario (for example cleaning VCGT on verification by mistake).It does not matter how does it look on whatever color managed iphoen viewer if not tested with measurements, maybe gamma is a bit too low or too high on phone although primaries on phone and in its firmware /OS match so sRGB 255 primaries “looks good” upon visual inspection.
Guys, thanks for the input, but it’s not a ‘double profiling’ or ‘measurement’ issue.
The setup worked perfectly for 6 months with the SAME LUT and ICC.
Restoring the OS Image fixes it, but only until the first reboot.
DaVinci Resolve bypasses the Windows DWM/MPO gamma shift, while Photoshop is being ‘washed out’ by the OS.
It’s a Windows 11 OS-level bug (ACM/MPO etc), not a calibration workflow error. My ‘Ghost Experiment’ with the disk image proves that the hardware and files are fine, but the OS interpretation is broken.I think you are confusing Windows and macOS behavior regarding VCGT.
Your point about not including VCGT in a 3D LUT is valid for macOS (ColorSync), where the OS always applies the gamma ramp system-wide, and double-profiling occurs if it’s also baked into the LUT.
However, on Windows, especially in a pro workflow (DisplayCAL + Resolve), baking VCGT into the LUT is the standard way to ensure the Resolve viewer matches the calibrated Photoshop workspace, as Resolve can bypass the system’s GDI gamma ramp.DaVinci Resolve bypasses the Windows DWM/MPO gamma shift, while Photoshop is being ‘washed out’ by the OS.
It’s a Windows 11 OS-level bug (ACM/MPO etc), not a calibration workflow error. My ‘Ghost Experiment’ with the disk image proves that the hardware and files are fine, but the OS interpretation is broken.However, on Windows, especially in a pro workflow (DisplayCAL + Resolve), baking VCGT into the LUT is the standard way to ensure the Resolve viewer matches the calibrated Photoshop workspace, as Resolve can bypass the system’s GDI gamma ramp.
It should not and it did not work this way in the past. madVR/HCFR “may” clean VCGT by Resolve didint (and there is no reason to do it without leaving user option to disable it).
So unless this is a recent addition to Resolve, all your claim seem wrong…. and very easy to test. just grab a few rec709 MP4 samples IRE 0-100 on 5 steps and use spotread directly on Resolve.If raw/direct measurement, not through your supposedly “wrong settings” fr verification on DisplayCAL, but though spotread reports correct values, but exported sRGB image shows a gamma shift it would eman that export in Resolve is broken, not reencoding properly values in sRGB.
Of course this assumes that running that the same time Adobe and Resolve and making a profile verification in DisplayCAL to default profile verifies OK.
I appreciate the technical deep dive, but the ‘spotread’ test won’t address the core issue here: temporal inconsistency of the OS behavior.
The ‘Ghost’ Proof: If my LUT was ‘wrong’ or Resolve’s export was ‘broken,’ the issue would persist regardless of the OS state. But it doesn’t. After a disk image restore, Photoshop and Resolve match 1:1 using the EXACT same files and settings. The mismatch only triggers after a reboot or a system password change. A software export bug can’t be fixed by an OS image restore if the settings remain identical.
Windows 11 ACM/DWM Factor: My setup worked perfectly for 6 months. This isn’t about ‘cleaning VCGT’ by Resolve; it’s about Windows 11 Desktop Window Manager (DWM) or Advanced Color Management (ACM) overriding the gamma ramp for windowed GDI applications (Photoshop) while Resolve (via DirectX/MPO overlay) manages to maintain the original hardware LUT state.
The Password Factor: I should have mentioned this earlier: the entire issue coincided with me changing the password of my local Windows account. While it might seem unrelated, in Windows 11 this forces a re-indexing of security tokens (DPAPI), which could lead to a credential/registry conflict affecting how color profiles are associated with the hardware ID.
The Password Factor: I should have mentioned this earlier: the entire issue coincided with me changing the password of my local Windows account. While it might seem unrelated, in Windows 11 this forces a re-indexing of security tokens (DPAPI), which could lead to a credential/registry conflict affecting how color profiles are associated with the hardware ID.
Check if displayCAL loader icon shows error, check if some update enabled windows LUT loader and check if ArgyllCMS’ dispwin.exe (which should load VCGT) is blocked somehow by a secirity app/AV.
I mean, if you say your problems are caused by inconsistency on OS/LUT loader app, you must focus on the apps that do that thing rather than DisplayCAL whole app, which leads to the post above (athough there may be other things to check not listed)
Thanks for the suggestions (Really thanks!). But here is the status of my ‘investigation’:
Loader & Security: Windows Defender is completely disabled (via dControl), so it’s not a standard AV block.
Permissions: Even though I recalibrated and created a NEW profile after the password change, the gamma shift in Photoshop persists. I checked the spool\drivers\color folder permissions, and they are fine.
The dispwin.exe factor: Even if I manually force the VCGT load via dispwin.exe, Photoshop remains ‘washed out’ compared to the 1:1 match I see in DaVinci Resolve and on my iPhone.
The “Ghost” Dilemma:
If it were a simple app block or a wrong setting, it would not be fixed by an OS Image restoration. But when I restore the system from a 6-month-old image, the mismatch disappears instantly without changing a single file or setting in DisplayCAL or Photoshop.
However, as soon as I reboot the restored system with the new password session, the OS seems to trigger a ‘dirty’ hardware-ID association for GDI apps (like Photoshop), while DaVinci (via DirectX/MPO overlay) continues to bypass the DWM/ACM gamma compression.
It’s clear that Windows 11’s Desktop Window Manager (DWM) is overriding the Gamma Ramp for windowed applications after the security token change (password reset), and no amount of recalibration can fix an OS-level override. DaVinci is the only ‘source of truth’ left because it talks to the GPU differently.”Windows 11 adds features. Check system/display/advanced display. Dynamic refresh rate is something I did not see before. Make sure your GPU is locked by manualy selected the color format in the gpu app. There is a Windows application games setting in system/display/graphics. I do not use windowed applications though.
Thanks, but I’ve already checked Dynamic Refresh Rate (DRR) and GPU color format settings (it’s locked to RGB Full 0-255). Toggling ‘Optimizations for windowed games’ or ACM settings in Windows Graphics doesn’t help either.
The most disturbing part is the RegisteredProfiles registry key (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ICM\RegisteredProfiles). It shows active .gmmp and .camp (Global Media Management) profiles like Photo.gmmp. It seems Windows 11 forces these ‘enhancements’ on GDI apps (Photoshop) specifically after a local account password change, which likely re-indexed the DPAPI security tokens.
The issue is NOT resolved. My ‘Ghost Image’ experiment proves the hardware and LUT files are fine. The OS is silently overriding the Gamma Ramp for windowed apps while DaVinci (via DirectX overlay) bypasses this ‘fog’.Any ideas on how to completely kill these WCS (.gmmp) overrides or why a password change triggers this ‘untrusted’ state for the ICC profile?
A troubleshooting to a systematic Color Pipeline Audit. My ‘Ghost Image’ experiment proves that hardware and calibration files are 100% correct, yet the OS interpretation shifts after a reboot. And most importantly, this may not necessarily happen after the first reboot!
Application Layer (DirectX/MPO): DaVinci Resolve (via 3D LUT with baked VCGT) matches my iPhone reference 1:1. The file density and ‘cold’ tint are perfect here.
Application Layer (GDI/WCS): Photoshop/Lightroom (via ICC) show a significant Gamma Shift (washed out blacks) and a slight tint shift (approx. 5 degrees).
OS CMS Layer (WCS/ICM): My registry export shows active .gmmp and .camp profiles in HKEY_LOCAL_MACHINE\…\ICM\RegisteredProfiles (e.g., Photo.gmmp).
Driver/Hardware Layer: GPU is locked to RGB Full (0-255). Recalibrating or forcing VCGT via dispwin.exe does NOT fix the Photoshop ‘fog’, while Resolve remains unaffected.
The issue is localized in the Windows 11 DWM (Desktop Window Manager) / GDI pipeline. It appears that after a system session change (like a password reset or specific reboot), Windows 11 starts forcing SDR Tone Mapping or WCS Global Media Profiles on windowed applications, overriding the calibrated Gamma Ramp.
How can we completely isolate the GDI output from these WCS (.gmmp) overrides in Windows 11 without a full OS image restoration? Is there a way to force ‘Bit-Accurate’ output for the DWM composition layer specifically for Adobe apps?I would try checking the windows color management system. I use SDR so use device profile SRGB IEC61966-2.1 . Its in advanced display in advanced display settings. I remember it has a profile not srgb for default. It would not hurt to poke it in its color management for it to fix itself by writing new keys. Try toggle things for it to refresh its keys. Funny computers can lie.
Thanks, but look, I’ve been toggling profiles for two days—it’s a dead end. This isn’t about “refreshing” keys; it’s a systemic override. I don’t need a “what to click” advice, I need a proper audit: which logs to check or which ProcMon filters to use to catch that exact “security-to-color” handshake where Windows decides my ICC is “untrusted” after reboot. Computers lie, but they always leave a trail)
