Color picker picks the color *after* browser/application color management

[patrickhlauke]

On both Windows and macOS, some browsers (and other applications) apply their own color management to CSS color values before displaying them. This means that, depending on the user's specific color profile, the actual colors displayed don't necessarily match the CSS values. But the CCA's picker picks up the displayed (already color managed) colors...leading to inaccurate picks.

On Windows, it seems that currently only Chrome applies color management for CSS colors. Edge and Firefox don't.

a background color value of #00f is correctly picked using CCA color picker from Edge and Firefox, but in Chrome - on my monitor - it's color profile managed to #3800FF, which is what CCA's color picker picks up in the end...

On macOS, Chrome and Safari apply color management, while Firefox doesn't.

a background color value of #00f is correctly picked using CCA on macOS Firefox, but Chrome and Safari - on my monitor - the color management shifts it to #0b24fb, which is what CCA's color picker picks up in the end...

Not sure if there's a simple workaround for this. Just testing in macOS using a graphics app and firing up its (native) color selection dialog, the eyedropper there corrects for this. Perhaps there's a way to trigger the platform's own picker - but I'm not aware of a similar OS-level native picker on Windows.

using Pixelmator's color selection, using macOS's native system-level picker, the value of #00f is correctly picked from Chrome

[aardrian]

https://twitter.com/davatron5000/status/1129397925409415168

Reduced test case: https://codepen.io/davatron5000/pen/JqJYob

From tweet:

Okay, Internet. I have an #a11y conundrum. What rules? The specified color value in CSS? Or what the user sees with their given color profile?

Here's Colour Contrast Analyser returning 4 different values from 4 different Macs (Safari) https://t.co/uaurP6pvSi

Follow-up tweet:

I have 7 macs with 7 different values right now in CCA (100% variance). This is a somewhat untenable testing situation.

[ferllings]

I did some research and testing today.
I don't think there is any way around it: The lib basically takes a screenshot of the screen and get the pixel color value. Some app, like Chrome or Safari modify the rendered color, based on the user color profile.
I don't see how we can get the initial color values before color profile is applied
(The problem was similar in the old Native OSX app.)

The only solution I found to get correct values is to set my screen color profile to sRGB.
Maybe in the future we can detect and warn the user if he doesn't use sRGB

[patrickhlauke]

suggest in worst case removing the picker then...as it's misleading/inaccurate otherwise (and forcing users to change their color profile is a no-go i'd say)

[ferllings]

I'm also investigating some other possibilities:
Add an ICCProfile option, in the CCA app, so we may be able to convert the actual real value (except for apps like Firefox who doesn't apply ICC)
And maybe, if possible automatically detect the IIC Profile from the user.

[aardrian]

suggest in worst case removing the picker then...as it's misleading/inaccurate otherwise (and forcing users to change their color profile is a no-go i'd say)

Do not like. The picker is the feature that I rely on with this tool, particularly when grabbing colors from images and gradients. Yes, I can rely on other tools for a picker, but then I have no reason to use this one any longer.

Suggest a warning with the picker, assuming no other solution available.

[patrickhlauke]

@aardrian so you'd rather have a picker that's not guaranteed to be correct, and tells you so when you use it?

personally, i'd posit that if the picker cannot be fixed, we may gracefully retire the tool...because yes i agree the picker is the selling point here really...

[aardrian]

Yes. Because as a user I can adjust the color profile or jump to a browser (Firefox) that does not use the profile. Provided the warning is clear and actionable.

[andreasbossard]

@ferllings Did you find a way to switch the color profile? The Digital Color Meter by Apple also has such an option to select sRGB instead of Native Values.

The picker is the feature that I rely on with this tool

+1 from me.

[ferllings]

@andreasbossard Sorry, I have to admit I haven't found the time to work on CCA since July. But this is on top of my todo list.

[ferllings]

Slow progress:

I have difficulties to get the appropriate colorProfile information in order to make the conversion.

The new Electron v6 introduced a new display attribute "colorSpace",
but robotjs (which is the lib that grabs the color from screen) only supports electron v5. And worse the fork I'm using to support multi-screen, only supports electron v4.

So I decided to find an alternative way for the picker, and get rid of robotjs.
The solution I'm currently testing is to use a little external native app, only for the picker.
So far it gives good results: fast to launch, no latency, and already implemented with zooming (for #122).
By default it returns color in sRGB color space, but I have good hope to be able to access all information I need to force or convert in other colorSpaces.
It's not movable using keyboard, but that shouldn't be to complicated to add.

[jnurthen]

Any chance a warning can be added to the tool to let people know what is going on - this causes considerable issues.

[deviantintegral]

Is this still a current issue? I upgraded from an old release (1.2.1) to 3.3.0 on macOS and that fixed it for me.

[patrickhlauke]

purely testing with #0000FF (as in the opening screenshots here), it seems that Edge/Firefox on Win, and Firefox on macOS, now do their colour management the same way ... the issue "may" have resolved itself /cc @ferllings

[ferllings]

I believe it also depends of your monitor colorspace. I need to do more tests

[jeremy-w]

macOS: Firefox seems impacted now, and switching the display color profile to sRGB is still a functional workaround.

I recently ran into this on macOS 14.4, including when using Firefox 124.0 esr, on the build-in display of a recent MacBook Pro 16-inch, Nov 2023. It was not detectable using the earlier-shared Contrast Tester Tester codepen as-is, but it was when I tweaked the background color to be 00EE00, which gets read as 07EE00.

It seemed to be related to the default Display P3 colorspace of the laptop monitor at fault. Switching to sRBG made the display really dim, with display brightness control locked out, but it did give the expected readings of 00EE00. (Another fun gotcha to watch out for on a smaller screen is the shadow that macOS places around windows, which can darken the picked color if you don't move the CCA window well clear first.) TrueTone surprisingly did not seem to have any impact, on or off.