Windows 11 24H2 26100.2161 today; monitor profiling still broken

Having done some more reading up, purely out of interest, I am starting to get an understanding of what is going on with Windows ACM. It started of with introducing system color management for HDR displays in late Windows 10 builds, and was first expanded to SDR displays in Windows 22H2.

Unlike what may be the impression, the Windows development team does actually have a very clear oversight on what is needed and where things are going. For about 20 years, Windows did not do any color management OS wide, The destop manager as well as display kernel had no system color management, the color management was done by individual apps using the provided Windows API's.

Windows advanced color management ACM is progressing towards having a system that manges colors on the destop and in the display kernel with HDR, wide gamut and high bit depth support.

There are a few key modifications that applications have to implement to make things work. For one, the display profile under ACM needs to be a valid MHC ICC profile, containing specific information:

Windows doesn't provide an API for directly controlling the new color transform pipeline at runtime. Instead, your app accesses the pipeline by writing a properly formatted International Color Consortium (ICC) color profile with extra data stored in a new "Microsoft Hardware Calibration" ("MHC2") private tag

If the calibrated profile does not meet these needs, then it will be overrided and the hardware information about your display will be used, which means you have no access to your own calibration routine. I had this issue with Eizo color navigator, where it would reurn an error: "unable to apply the ICC profile". Only the latest update from three weeks ago fixed this, providing official Windows 11 24H2 support. I assume they updated the ICC profile creation to include this MHC2 tag, although this is speculation on my part.

In any case:

Windows 10, version 2004 exposes a GPU-accelerated display color transform pipeline consisting of a linear gamma color matrix and 1DLUT. Compared to the existing gamma ramp pipeline, it offers superior accuracy, precision, and support for wide color gamut displays. In addition, it adds support for new technologies such as HDR displays that use BT.2100 signaling.

The pipeline isn't directly programmable by apps, and instead is exposed only via MHC profiles


So even if an image editing application is updated to follow the new ACM guidelines, it will still require a valid MHC display profile to work properly.

Also, with ACM enabled, apps no longer have access to the full gamut of wide gamut displays, but are clamped down to sRGB. This is because the API's used by the apps to color manage the display will manage to sRGB when ACM is active:

Because the ICC profile management APIs return sRGB when Advanced Color is active, your ICC profile-based app will color-manage to sRGB, and Windows will correctly reproduce that as sRGB on the display.

And:

When Advanced Color is active, any calls to the color profile management APIs to get the default profile for a display will return "no profile", regardless of what profiles are actually installed. By convention "no profile" should be interpreted as sRGB.

This is intentional behavior, because the application should not attempt to color manage the display. Windows though provides a compatibility helper for display ICC profiles that provides access to the display's entire gamut, which is enabled on a per app basis via the legacy color management setting. But this is only atemporary solution:

That helper is available starting with Windows 11. It doesn't provide other benefits of Advanced Color including access to higher precision/bit-depth or high dynamic range—you'll need to modify your app to be Advanced Color-aware

Until applications like Photoshop and Capture One and DxO are updated to comply with the new color managment, the compatibility helper is your best friend.
 
Last edited:
Thank you for this informative post clarifying these matters. I am now slightly less confused than I was before about ACM. :-)

I hope the forum will continue to be updated about ACM as more is learned about what apps are supporting it.
 
Having done some more reading up, purely out of interest, I am starting to get an understanding of what is going on with Windows ACM. It started of with introducing system color management for HDR displays in late Windows 10 builds, and was first expanded to SDR displays in Windows 22H2.

Unlike what may be the impression, the Windows development team does actually have a very clear oversight on what is needed and where things are going. For about 20 years, Windows did not do any color management OS wide, The destop manager as well as display kernel had no system color management, the color management was done by individual apps using the provided Windows API's.

Windows advanced color management ACM is progressing towards having a system that manges colors on the destop and in the display kernel with HDR, wide gamut and high bit depth support.

There are a few key modifications that applications have to implement to make things work. For one, the display profile under ACM needs to be a valid MHC ICC profile, containing specific information:

Windows doesn't provide an API for directly controlling the new color transform pipeline at runtime. Instead, your app accesses the pipeline by writing a properly formatted International Color Consortium (ICC) color profile with extra data stored in a new "Microsoft Hardware Calibration" ("MHC2") private tag

If the calibrated profile does not meet these needs, then it will be overrided and the hardware information about your display will be used, which means you have no access to your own calibration routine. I had this issue with Eizo color navigator, where it would reurn an error: "unable to apply the ICC profile". Only the latest update from three weeks ago fixed this, providing official Windows 11 24H2 support. I assume they updated the ICC profile creation to include this MHC2 tag, although this is speculation on my part.

In any case:

Windows 10, version 2004 exposes a GPU-accelerated display color transform pipeline consisting of a linear gamma color matrix and 1DLUT. Compared to the existing gamma ramp pipeline, it offers superior accuracy, precision, and support for wide color gamut displays. In addition, it adds support for new technologies such as HDR displays that use BT.2100 signaling.

The pipeline isn't directly programmable by apps, and instead is exposed only via MHC profiles


So even if an image editing application is updated to follow the new ACM guidelines, it will still require a valid MHC display profile to work properly.

Also, with ACM enabled, apps no longer have access to the full gamut of wide gamut displays, but are clamped down to sRGB. This is because the API's used by the apps to color manage the display will manage to sRGB when ACM is active:

Because the ICC profile management APIs return sRGB when Advanced Color is active, your ICC profile-based app will color-manage to sRGB, and Windows will correctly reproduce that as sRGB on the display.

And:

When Advanced Color is active, any calls to the color profile management APIs to get the default profile for a display will return "no profile", regardless of what profiles are actually installed. By convention "no profile" should be interpreted as sRGB.

This is intentional behavior, because the application should not attempt to color manage the display. Windows though provides a compatibility helper for display ICC profiles that provides access to the display's entire gamut, which is enabled on a per app basis via the legacy color management setting. But this is only atemporary solution:

That helper is available starting with Windows 11. It doesn't provide other benefits of Advanced Color including access to higher precision/bit-depth or high dynamic range—you'll need to modify your app to be Advanced Color-aware

Until applications like Photoshop and Capture One and DxO are updated to comply with the new color managment, the compatibility helper is your best friend.
I agree with your analysis of what ACM seems to do.

It may be that as you say:
...the Windows development team does actually have a very clear oversight on what is needed and where things are going...
and:
This is intentional behavior...
However, in my view this is unreasonably not backwards compatible. Microsoft may be starting from a blank sheet of paper, but many other people aren't, and there is a great deal of legacy code for colour management.

The default position should be that legacy code just works, without modification, as well as it did before, even if it doesn't benefit from new features of ACM.

The requirement for an ACM-compatible profile is a kludge (just as the Adobe vcgt tag is a kludge). As such, they should provide code to make it easy to create the MHC2 tag, or even better: provide proper default behaviour for an icc profile that doesn't contain an MHC2 tag.

This isn't rocket science. It's providing proper compatility for legacy code that has worked for decades, rather than make everyone start again and dance to Microsoft's tune.
 
Having done some more reading up, purely out of interest, I am starting to get an understanding of what is going on with Windows ACM. It started of with introducing system color management for HDR displays in late Windows 10 builds, and was first expanded to SDR displays in Windows 22H2.

Unlike what may be the impression, the Windows development team does actually have a very clear oversight on what is needed and where things are going. For about 20 years, Windows did not do any color management OS wide, The destop manager as well as display kernel had no system color management, the color management was done by individual apps using the provided Windows API's.

Windows advanced color management ACM is progressing towards having a system that manges colors on the destop and in the display kernel with HDR, wide gamut and high bit depth support.

There are a few key modifications that applications have to implement to make things work. For one, the display profile under ACM needs to be a valid MHC ICC profile, containing specific information:

Windows doesn't provide an API for directly controlling the new color transform pipeline at runtime. Instead, your app accesses the pipeline by writing a properly formatted International Color Consortium (ICC) color profile with extra data stored in a new "Microsoft Hardware Calibration" ("MHC2") private tag

If the calibrated profile does not meet these needs, then it will be overrided and the hardware information about your display will be used, which means you have no access to your own calibration routine. I had this issue with Eizo color navigator, where it would reurn an error: "unable to apply the ICC profile". Only the latest update from three weeks ago fixed this, providing official Windows 11 24H2 support. I assume they updated the ICC profile creation to include this MHC2 tag, although this is speculation on my part.

In any case:

Windows 10, version 2004 exposes a GPU-accelerated display color transform pipeline consisting of a linear gamma color matrix and 1DLUT. Compared to the existing gamma ramp pipeline, it offers superior accuracy, precision, and support for wide color gamut displays. In addition, it adds support for new technologies such as HDR displays that use BT.2100 signaling.

The pipeline isn't directly programmable by apps, and instead is exposed only via MHC profiles


So even if an image editing application is updated to follow the new ACM guidelines, it will still require a valid MHC display profile to work properly.

Also, with ACM enabled, apps no longer have access to the full gamut of wide gamut displays, but are clamped down to sRGB. This is because the API's used by the apps to color manage the display will manage to sRGB when ACM is active:

Because the ICC profile management APIs return sRGB when Advanced Color is active, your ICC profile-based app will color-manage to sRGB, and Windows will correctly reproduce that as sRGB on the display.

And:

When Advanced Color is active, any calls to the color profile management APIs to get the default profile for a display will return "no profile", regardless of what profiles are actually installed. By convention "no profile" should be interpreted as sRGB.

This is intentional behavior, because the application should not attempt to color manage the display. Windows though provides a compatibility helper for display ICC profiles that provides access to the display's entire gamut, which is enabled on a per app basis via the legacy color management setting. But this is only atemporary solution:

That helper is available starting with Windows 11. It doesn't provide other benefits of Advanced Color including access to higher precision/bit-depth or high dynamic range—you'll need to modify your app to be Advanced Color-aware

Until applications like Photoshop and Capture One and DxO are updated to comply with the new color managment, the compatibility helper is your best friend.
I agree with your analysis of what ACM seems to do.

It may be that as you say:
...the Windows development team does actually have a very clear oversight on what is needed and where things are going...
and:
This is intentional behavior...
However, in my view this is unreasonably not backwards compatible. Microsoft may be starting from a blank sheet of paper, but many other people aren't, and there is a great deal of legacy code for colour management.

The default position should be that legacy code just works, without modification, as well as it did before, even if it doesn't benefit from new features of ACM.

The requirement for an ACM-compatible profile is a kludge (just as the Adobe vcgt tag is a kludge). As such, they should provide code to make it easy to create the MHC2 tag, or even better: provide proper default behaviour for an icc profile that doesn't contain an MHC2 tag.

This isn't rocket science. It's providing proper compatility for legacy code that has worked for decades, rather than make everyone start again and dance to Microsoft's tune.
For sure it takes an effort on the user side, and without that you are going to run into problems as a Windows user.

If I hadn't gotten a new high end display that I could not get to work at 10bit over displayport without running into errors with the calibration software, I would have not sought out what was going on, and might have hit a wall later on.

Apparently Microsoft leaves it up to the end user and the image editing software developers to visit their school pages on a regular basis and get enough up to date to be able to find the correct settings or push out the correct speed updates.

For an average user, this is not viable, and Windows can cause a lot of frustration at times. Personally I am glad though that they have started the advanced color development, wich should end up in decent system wide color management for hdr as well as sdr. I have found the lack of it annoying for years.
 
Last edited:
Having done some more reading up, purely out of interest, I am starting to get an understanding of what is going on with Windows ACM. It started of with introducing system color management for HDR displays in late Windows 10 builds, and was first expanded to SDR displays in Windows 22H2.

Unlike what may be the impression, the Windows development team does actually have a very clear oversight on what is needed and where things are going. For about 20 years, Windows did not do any color management OS wide, The destop manager as well as display kernel had no system color management, the color management was done by individual apps using the provided Windows API's.

Windows advanced color management ACM is progressing towards having a system that manges colors on the destop and in the display kernel with HDR, wide gamut and high bit depth support.

There are a few key modifications that applications have to implement to make things work. For one, the display profile under ACM needs to be a valid MHC ICC profile, containing specific information:

Windows doesn't provide an API for directly controlling the new color transform pipeline at runtime. Instead, your app accesses the pipeline by writing a properly formatted International Color Consortium (ICC) color profile with extra data stored in a new "Microsoft Hardware Calibration" ("MHC2") private tag

If the calibrated profile does not meet these needs, then it will be overrided and the hardware information about your display will be used, which means you have no access to your own calibration routine. I had this issue with Eizo color navigator, where it would reurn an error: "unable to apply the ICC profile". Only the latest update from three weeks ago fixed this, providing official Windows 11 24H2 support. I assume they updated the ICC profile creation to include this MHC2 tag, although this is speculation on my part.

In any case:

Windows 10, version 2004 exposes a GPU-accelerated display color transform pipeline consisting of a linear gamma color matrix and 1DLUT. Compared to the existing gamma ramp pipeline, it offers superior accuracy, precision, and support for wide color gamut displays. In addition, it adds support for new technologies such as HDR displays that use BT.2100 signaling.

The pipeline isn't directly programmable by apps, and instead is exposed only via MHC profiles


So even if an image editing application is updated to follow the new ACM guidelines, it will still require a valid MHC display profile to work properly.

Also, with ACM enabled, apps no longer have access to the full gamut of wide gamut displays, but are clamped down to sRGB. This is because the API's used by the apps to color manage the display will manage to sRGB when ACM is active:

Because the ICC profile management APIs return sRGB when Advanced Color is active, your ICC profile-based app will color-manage to sRGB, and Windows will correctly reproduce that as sRGB on the display.

And:

When Advanced Color is active, any calls to the color profile management APIs to get the default profile for a display will return "no profile", regardless of what profiles are actually installed. By convention "no profile" should be interpreted as sRGB.

This is intentional behavior, because the application should not attempt to color manage the display. Windows though provides a compatibility helper for display ICC profiles that provides access to the display's entire gamut, which is enabled on a per app basis via the legacy color management setting. But this is only atemporary solution:

That helper is available starting with Windows 11. It doesn't provide other benefits of Advanced Color including access to higher precision/bit-depth or high dynamic range—you'll need to modify your app to be Advanced Color-aware

Until applications like Photoshop and Capture One and DxO are updated to comply with the new color managment, the compatibility helper is your best friend.
I agree with your analysis of what ACM seems to do.

It may be that as you say:
...the Windows development team does actually have a very clear oversight on what is needed and where things are going...
and:
This is intentional behavior...
However, in my view this is unreasonably not backwards compatible. Microsoft may be starting from a blank sheet of paper, but many other people aren't, and there is a great deal of legacy code for colour management.

The default position should be that legacy code just works, without modification, as well as it did before, even if it doesn't benefit from new features of ACM.

The requirement for an ACM-compatible profile is a kludge (just as the Adobe vcgt tag is a kludge). As such, they should provide code to make it easy to create the MHC2 tag, or even better: provide proper default behaviour for an icc profile that doesn't contain an MHC2 tag.

This isn't rocket science. It's providing proper compatility for legacy code that has worked for decades, rather than make everyone start again and dance to Microsoft's tune.
For sure it takes an effort on the user side, and without that you are going to run into problems as a Windows user.

If I hadn't gotten a new high end display that I could not get to work at 10bit over displayport without running into errors with the calibration software, I would have not sought out what was going on, and might have hit a wall later on.

Apparently Microsoft leaves it up to the end user and the image editing software developers to visit their school pages on a regular basis and get enough up to date to be able to find the correct settings or push out the correct speed updates.

For an average user, this is not viable, and Windows can cause a lot of frustration at times. Personally I am glad though that they have started the advanced color development, wich should end up in decent system wide color management for hdr as well as sdr. I have found the lack of it annoying for years.
All agreed. The positive thing is that they are doing something both for application programs and the desktop, after years of largely ignoring colour management.

Even with the lack of backwards compatibiltiy, it would be much better if they gave more up-front guidance for users on getting legacy programs working they way they used to, rather than leaving it for users to find that colour management stops working. The information needed about legacy behaviour is buried in multiple long documents. As it is, discovering how to get legacy programs working is likely to be a real battle for most users of colour-managed programs, as threads on here have demonstrated.
 
I haven't studied your post yet, but it looks quite informative.

A question, though:

I seem to see an interaction between ACM and 30bit color in Photoshop (26.2.0).

I can't display 30bit color in PS unless ACM is enabled. (nVidia GPU set to 10 bit, monitor is 10 bit native.)

If I set the GPU to 8 bit color, but leave PS set to 30 bit color, I still see a stepless 10 bit gradient in PS. Whiskey tango foxtrot?

Can you offer any insight?
 
(snip)

All agreed. The positive thing is that they are doing something both for application programs and the desktop, after years of largely ignoring colour management.

Even with the lack of backwards compatibiltiy, it would be much better if they gave more up-front guidance for users on getting legacy programs working they way they used to, rather than leaving it for users to find that colour management stops working. The information needed about legacy behaviour is buried in multiple long documents. As it is, discovering how to get legacy programs working is likely to be a real battle for most users of colour-managed programs, as threads on here have demonstrated.
The lag is discouraging.

I attempted to get some clarity from Adobe a week or so ago by live chat with their tech support.

They were completely unfamiliar with Automatic Color Management in Windows 24H2.

I don't expect much from their outsourced tech support, but that was surprising. Adobe should be embarrassed.
 
(snip)

All agreed. The positive thing is that they are doing something both for application programs and the desktop, after years of largely ignoring colour management.

Even with the lack of backwards compatibiltiy, it would be much better if they gave more up-front guidance for users on getting legacy programs working they way they used to, rather than leaving it for users to find that colour management stops working. The information needed about legacy behaviour is buried in multiple long documents. As it is, discovering how to get legacy programs working is likely to be a real battle for most users of colour-managed programs, as threads on here have demonstrated.
The lag is discouraging.

I attempted to get some clarity from Adobe a week or so ago by live chat with their tech support.

They were completely unfamiliar with Automatic Color Management in Windows 24H2.

I don't expect much from their outsourced tech support, but that was surprising. Adobe should be embarrassed.
I can confirm that switching from 8 > 10 bit clor in the Nvidia configuration screen enables Windows ACM and when you consequently turn off ACM, 30bit color in Photoshop will not work, it will drop to 8 bit without dithering.

I think that 10-bit color is no longer a setting exclusively in the graphics card configuration, but Windows is taking control of bit depth with ACM, as part of the system color management. The Nvidia control panel setting should work in tandem with ACM, I at least accept that 10-bit color now requires ACM enabled. There is some interesting info on the Nvidia site describing Deep Color Depth on Windows 11 Desktops which indicates that ACM impacts output color depth.

Deep Color Depth on Windows 11 Desktops | NVIDIA

I don't yet see the SDR (64bit) on my system though with the latest Nvidia studio driver...

On a good note: after enabling 10-bit color over displayport, enabling Windows ACM, and setting all color editing apps, including Edge to "legacy color managment", I recalibrated the Eizo CG2700X and colors and contrast now do look very good in all apps as well as on the desktop, and prints look spot-on, so Eizo proper support seems to have come quickly, and with the generated profiles, I cannot see any conflicts with Windows ACM. Hopefully color editing apps will also take notice and work on support, your story about Adobe is very discouraging.
 
Last edited:
I find that the legacy setting works for Calibrite Profiler.

Haven't gotten it to work in DisplayCal, perhaps because of the large number of .exe files in Argyll CMS. Haven't messed tih it much. It's simpler to disable ACM. I know that works.
 
I just found this thread after hours of frustration trying to troubleshoot failed calibration. There’s so much to read. My windows icons were washed out and photos in editing apps became saturated.

Can I check that I should disable ACM? I am able to set 10 bits in nvidia control panel and ACM is off.

With ACM on and manually setting photo editing apps to use legacy ICC management, photos look correct but my windows icons look washed out.
 
I just found this thread after hours of frustration trying to troubleshoot failed calibration. There’s so much to read. My windows icons were washed out and photos in editing apps became saturated.

Can I check that I should disable ACM? I am able to set 10 bits in nvidia control panel and ACM is off.

With ACM on and manually setting photo editing apps to use legacy ICC management, photos look correct but my windows icons look washed out.
Personally I have ACM disabled as it isn't ready yet. You shouldn't need to work around with legacy colour management settings and with ACM on you can't actually use that nice shiny profile you custom made for your screen.
 
I just found this thread after hours of frustration trying to troubleshoot failed calibration. There’s so much to read. My windows icons were washed out and photos in editing apps became saturated.

Can I check that I should disable ACM? I am able to set 10 bits in nvidia control panel and ACM is off.

With ACM on and manually setting photo editing apps to use legacy ICC management, photos look correct but my windows icons look washed out.
My current situation is that I leave ACM enabled most of the time. Last I checked, it had to be enabled to get a 10 bit (30 bit color) is Photoshop CC. Mysterious.

I have a number of photo apps set to use legacy display ICC color management.

Calibrite's Profiler runs OK with the legacy setting, but I need to disable ACM for DisplayCal/Argyll CMS to produce a profile whose gamut matches my OLED monitor. I re-enable ACM after.

My desktop and icons are displayed properly.

I hope that Microsoft takes an approach to ACM soon that is more consistent with wide gamut monitors soon.
 
I just found this thread after hours of frustration trying to troubleshoot failed calibration. There’s so much to read. My windows icons were washed out and photos in editing apps became saturated.

Can I check that I should disable ACM? I am able to set 10 bits in nvidia control panel and ACM is off.

With ACM on and manually setting photo editing apps to use legacy ICC management, photos look correct but my windows icons look washed out.
What others say.

Your last point: I assume you have a wide-gamut monitor? The result is that with legacy colour management (what we all used pre-24H2), desktop icons are not colour managed, and appear over-saturated (as they're designed on the assumption that the monitor is roughly sRGB). So the washed out icons are how they're meant to look!

With ACM on, legacy apps are clamped to sRGB unless you set legacy icc color management in the compatibility setting of every single program that uses colour management. For me that's Lightroom, Photoshop, Bridge, every browser I use, every viewer I use... In due course some of those will get rewritten to use the MS ASM APIs, but I suspect most won't be in any hurry.

Or turn ACM off, which works as before but with some bugs, such as arbitrary resetting of LUTs in the driver, and I don't think 10 bit colour works in legacy mode.
 
I just found this thread after hours of frustration trying to troubleshoot failed calibration. There’s so much to read. My windows icons were washed out and photos in editing apps became saturated.

Can I check that I should disable ACM? I am able to set 10 bits in nvidia control panel and ACM is off.

With ACM on and manually setting photo editing apps to use legacy ICC management, photos look correct but my windows icons look washed out.
What others say.

Your last point: I assume you have a wide-gamut monitor? The result is that with legacy colour management (what we all used pre-24H2), desktop icons are not colour managed, and appear over-saturated (as they're designed on the assumption that the monitor is roughly sRGB). So the washed out icons are how they're meant to look!

With ACM on, legacy apps are clamped to sRGB unless you set legacy icc color management in the compatibility setting of every single program that uses colour management. For me that's Lightroom, Photoshop, Bridge, every browser I use, every viewer I use... In due course some of those will get rewritten to use the MS ASM APIs, but I suspect most won't be in any hurry.

Or turn ACM off, which works as before but with some bugs, such as arbitrary resetting of LUTs in the driver, and I don't think 10 bit colour works in legacy mode.
Oh yes you are right! But I guess I’ll still turn ACM off for now in case I forgot to enable legacy ICC for new apps.

By the way does legacy ICC setting work for games?
 
Last edited:
As I have found this thread very helpful after recalibrating my devices and getting them to match across Windows, MacOS and Linux (Wayland), I am posting my observations as of mid-March 2025 for NVIDIA & AMD GPUs in case others find them helpful.

All profiles were generated using the Calibrite Profiler 2.0; all other apps & drivers are the most recent stable ones as of today.

NVIDIA (desktop GPU + 10bit SDR display; discrete mobile GPU + 10bit SDR display with no pass-through through iGPU)
  • ACM on works rather well incl. 10-bit support in relevant applications.
  • Non-colour managed applications incl. desktop are clamped to sRGB, which also includes HW-accelerated video (incl. playback in browsers).
  • Chromium browsers (tested Chrome, Vivaldi and Edge):
    • work according to standards with the legacy ICC option off - non-tagged elements are interpreted as sRGB (as stipulated by W3C), and tagged elements and items tagged with the respective colour profile are interpreted correctly (tested using wide-gamut.com).
    • legacy ICC option on results in non-tagged & sRGB (?!) elements being displayed using wide gamut (test on wide-gamut.com results in untagged/sRGB elements looking the same as the wider gamut counterparts).
  • Photoshop has left me a bit puzzled and I would appreciate feedback on whether the soft-proofing method used for testing is sound:
    • legacy ICC option on supports a wide-gamut workflow and experiments with soft-proofing (where I went from a Pro Photo working space to monitor profile in areas that were not covered by the gamuts of both the Win display and Mac display, and visually observed changes) exhibited similar behaviour on Windows as on Mac.
    • legacy ICC option off seems not to have necessarily resulted in an sRGB clamp, but the soft-proofing experiment yielded different results in the most extreme shades of red, green and blue. I therefore assume this is not ready yet, but I am not able to explain what the exact issue is (and would appreciate feedback from somebody well-versed in this part of PS as I have not found it on the Adobe forum yet).
AMD (iGPU + 8bit SDR laptop display & 10bit SDR external display)

After hours of troubleshooting of inconsistent behaviour (which included the picture going completely off through restarts and repeated re-enabling of ACM), I have reinstalled the Adrenaline driver (and went from minimal to full install, but I doubt that should make a difference) and finally got consistent results. The display also seems to flash one or two times after log-in to Windows, but colour rendition is consistent after that.
  • ACM works partially here.
  • Non-colour managed applications incl. desktop are clamped to sRGB in "non-GPU accelerated scenarios", this does not include HW-accelerated tasks such as video (incl. playback in browsers), where decoding on the iGPU results in a wide-gamut rendition + saturation loss when scrolling; decoding on the discrete NVIDIA GPU keeps the saturation steady while scrolling but the wide-gamut rendition remains. Wide-gamut rendition also takes place in games (tested a windowed Unity game) which are clamped to sRGB on Nvidia.
    edit: clarified GPU-accelerated scenarios
  • Chromium browsers (tested Chrome, Vivaldi and Edge) behave similarly to NVIDIA with the exception of HW-accelerated video.
  • Photoshop behaviour is the same as with NVIDIA.
As for the increased battery consumption mentioned in the ACM setting description, I have not experienced anything significant after the AMD driver reinstall (differences were with 0.1-0.2 W during browsing & video playback, which seems to be well within run-to-run variance), but one should keep in mind that the video seems to have "bypassed" ACM.

After enabling ACM and legacy ICC for Photoshop (and not browsers), I have consistent reproduction for sRGB & untagged elements as well as wide-gamut elements (notwithstanding gamut differences between displays) across all devices & displays except for GPU-accelerated scenarios on AMD while maintaining the option to use 10-bit workflow on supported devices.
On a side note, I am wondering whether the increasing use of wide-gamut monitors among enthusiasts who do not colour manage/tag their content and the ACM sRGB clamp is going to result in people treating ACM too harshly (which a cursory Google search seems to suggest now) or colour management becoming more "mainstream". :)
 
A minor (?) thing:

I'm not certain, but I believe that the Windows version ofCalibrite Profiler 2.0 installs with legacy ICC profile compatibility enabled by default.

A simple solution on their part for compatibility with Win11 24H2.
 
A minor (?) thing:

I'm not certain, but I believe that the Windows version ofCalibrite Profiler 2.0 installs with legacy ICC profile compatibility enabled by default.

A simple solution on their part for compatibility with Win11 24H2.
Not in my case...

d304116c8ddb4ba3a8948709f25376ad.jpg

Peter
 
A minor (?) thing:

I'm not certain, but I believe that the Windows version ofCalibrite Profiler 2.0 installs with legacy ICC profile compatibility enabled by default.

A simple solution on their part for compatibility with Win11 24H2.
Not in my case...

d304116c8ddb4ba3a8948709f25376ad.jpg

Peter
It may have carried over from 1.3.3.

It was also set when I uninstalled 1.3.3 and directly installed 2.0.0, not as an update. But some settings may have remained, even though I tried to hunt them down and eliminate them.

I would have set it, regardless.
 
Last edited:
  • Like
Reactions: PMB

Keyboard shortcuts

Back
Top