@agriggio Alberto, I am using ART with Win11.
Its my understanding that apps need to be “ACM aware” in Windows otherwise they default to sRGB and I am not sure what that involves ie to be ACM aware ( at some point there was mention of some tag inserted into the ICC??)… At least that is what I took home when this first was announced. I’m glad to be corrected and or to get a better understanding if someone has clear understanding of this option.
In the last paragraph here…
It basically says at least as I understand it that there is a compatibility process/helper app to use in ACM for apps that are not ACM aware but that this is basically the same as having it turned off… at least this is how I read the section provided below.
" ICC profile behavior with Advanced Color
We’ve also published a new documentation that describes the changes in ICC (International Color Consortium) profile behavior with Advanced Color. In addition, if your color-managed app needs to continue using display ICC profiles, then this topic will show how to adapt your app to incrementally leverage Advanced Color benefits.
Automatic system color management necessarily impacts the way that existing ICC profile-based apps behave, since they’re performing many actions themselves that are now handled by the OS. Windows applies the default behavior (explained in the new documentation) to ICC profile-based apps. That ensures that those apps don’t have incorrect behavior. However, without further work, they won’t get access to any of the extended color capabilities.
In particular, by default your ICC profile-based app is restricted to the sRGB gamut, even if the monitor is actually wider gamut. Windows also provides an ICC compatibility helper that can give your ICC app access to the display’s entire gamut. For more info, see the Display ICC profile compatibility helper section in this topic."
I use ART and other CM applications with Win11. I found the explanation of that CM process confusing enough that I didnt’ want to introduce it into my workflow with these various programs. I also had no idea but figured it was fair to assume that ART was not an ACM compliant windows application and so might have been set fixed to srgb or somehow otherwise impacted.
Currently I stick to a standard ICC workflow in Win11. I use either displaycal or the updated Calibrite software that comes with my device to calibrate my screen to make display profiles. I copy those profiles in the Windows OS profile directory and I install and set as default the most current or a chosen icc profile if I want to change.
I then set this explicitly, ie the display profile in all the CM Windows apps that let you specify it including ART.
When it comes to some windows apps and viewers they will not offer any CM settings or let you select the display profile. You have to test them to know how they behave. Currently, Win11 photos is like that. It does CM using the OS default display profile but there are no settings. Some other 3rd party Windows apps will let you enable CM in their settings and they use the system display profile in theory howerver in the past apparently many apps would ignore or not use it… Likely this sort of thing is why they are trying to come up with a system to clean this up using ACM.
For now I prefer to use apps that will let you explicitly specify a display profile… like ART and for viewing Xnview. As long as you confirm the CM and profiles that you have set match between apps things seem to behave.
I don’t feel like I have any bad color mismatches with ART when comparing previews in Xnview but I have noted that in Xnview and in darktable that the test images from displaycal will behave differently when you are not at 100%. In other words the scaling aligos impact things… For example using none or bilinear scaling in Xnview did not cause the images to indicated failed CM but using bicubic or any of the lanzcos ones did and color seemed degraded. In DT it was similar but using the full HQR preview removed this as did zooming to 100%. I’m not sure if this translates to noticable changes in actual photos or is just a side effect of the nature of the test image.
I didn’t see this behaviour in ART with scaling. I’m not sure if there are settings for scaling of the preview or if it uses a set method…perhaps you could clarify but I didn’t see the same impact of scaling.
Finally most of the default export profiles are I think matrix profiles not supporting rendering intents and bp compensation but if you do use one that does then the viewing app might have settings that will be different from the ART preview. Xnview has options for rendering intent and bp compenation and if you use one of the icc profiles from color.org that has lut tables then these settings will kick in…if you use the standard matrix profiles there is no change…
Art seems to be one of the few programs that when you change the bp or rendering intent that you actually see it in the preview if the output profile supports it… Likely because as you pointed out yesterday to me that the preview comes after the output profile and not from the working space… So if you use one of those profiles in ART and change the bp compensation or rendering intent then you see it reflected in the preview…
I would have to test but it might be that in a viewer like Xnview if you change the rendering intent that it uses it might not be the one that you used in ART for preview or export and that might be a source of variation…
To me ART seems solid and if the preview is different at least in the Windows OS then some investigation into how that viewer handles CM is important to fully qualify any observed differences… as well as knowing about the properties of the icc file that you are using for export.
