[RFE] Make the color panel picker "label" readable on light colors

[lphilpot]

The RGB value indicator on the color panel picker tool is unreadable for light colors:

It doesn't take a bright primary to be unreadable, but this illustrates the issue. Please make it switch automatically (like it does for white) or some other behavior that makes it readable for all colors.

Thanks.

[lepr]

It can be almost unreadable for dark colours, too:

 

 

 

In my opinion, v1 was far more readable - white text on a black capsule, regardless of the colour being sampled.

There are some bizarre software design decisions.

 

 

[Pšenda]

18 hours ago, lphilpot said:

Please make it switch automatically

Just make it white text with a black background (outline), or black text with a white outline, and it will be visible at all times.

[loukash]

21 hours ago, lphilpot said:

The RGB value indicator on the color panel picker tool is unreadable for light colors:

Is this a Windows-only issue/bug?
On Mac, it switches from black to white and vice versa automatically in v2.3 as expected.

[Dan C]

4 minutes ago, loukash said:

Is this a Windows-only issue/bug?

I'm not seeing this behaviour currently on Windows in 2.3 - the Colour Picker (from both Tool options) adjusts the values contrast such that it can be seen over different colours:

 

[HCl]

.

[Dan C]

Thanks for letting me know - I'm asking a colleague to test this further on Windows 11 as I note that the OP here is also using Win11, and therefore this may be the trigger for the bug.

@lepr, are you using Win10 or Win11 with Affinity, where these colour picker values are not changing contrast correctly please?

[Dan C]

Just to confirm, this issue has been logged with our dev team - it doesn't seem to be Windows 11 specific, but can vary depending on the exact colour values used and your monitor profile.

I hope this helps

[loukash]

35 minutes ago, Dan C said:

can vary depending on the exact colour values used and your monitor profile.

I just checked with a CMYK document on Mac, and e.g. some dark purple colors may also fail to switch from black to white text a bit too "late".

[lphilpot]

It appears to be related to the color (purity / value) itself (see below). But there's a larger question, IMO -- Why change the color of the label at all? There's zero positive functional reason but as we've seen, it can have a negative impact. Why not just make it white on black, black on white or some other sufficiently contrasting combination?

Also, unrelated question, but -- Why can't we tile (or cascade, etc.) two or more image windows in the AP UI? It's impossible to snap them into the UI without taking the whole space. It's only just about every other GUI on the planet that can tile, after all....

[Pšenda]

43 minutes ago, lphilpot said:

Why not just make it white on black, black on white or some other sufficiently contrasting combination?

Yes - that's why I wrote:

6 hours ago, Pšenda said:

Just make it white text with a black background (outline), or black text with a white outline, and it will be visible at all times.

The switching looks more effective/cool, but not only can it cause the mentioned problems, it can also be distracting if it changes too often according to the colors of the background.

 

 

Edited December 1, 2023 by Pšenda

[lphilpot]

1 minute ago, Pšenda said:

Yes - that's why I wrote:

Just agreeing with you.  🙂

2 minutes ago, Pšenda said:

The switching looks more effective/cool, but not only can it cause the mentioned problems, it can also be distracting if it changes too often according to the colors of the background, and if the color of the background is not uniform enough, it will not even suit the entire area of the picker.

In other words, it's a "solution" in search of a problem.

[loukash]

45 minutes ago, lphilpot said:

Why change the color of the label at all? There's zero positive functional reason

It displays the actual color we're sampling.
This is good as is, only the algorithm needs to be a bit smarter as when to switch from positive to negative text.

[loukash]

49 minutes ago, lphilpot said:

unrelated question

Please post in the many existing threads on that topic.  

[lepr]

3 hours ago, Dan C said:

@lepr, are you using Win10 or Win11 with Affinity, where these colour picker values are not changing contrast correctly please?

macOS 12.7.1

[lphilpot]

4 minutes ago, loukash said:

It displays the actual color we're sampling.
This is good as is, only the algorithm needs to be a bit smarter as when to switch from positive to negative text.

Technically I agree but as you say, it doesn't need to blindly follow that logic. Which means, it shouldn't display the selected color in all cases ...so why implement a feature that will be only partially useful at best? Beside, you can see the color in the circular magnifier anyway.

But it's a minor point at best, so no real argument from me.  🙂

[loukash]

Just now, lphilpot said:

it shouldn't display the selected color in all cases
[…]
you can see the color in the circular magnifier anyway

It should display the color because when you're sampling color e.g. from a photo, you may have only one lone pixel of that exact color to sample from, and you may want to see it in a "larger" context first. That how I understand the label was designed for: displaying the values and the actual color as background. I wouldn't want to miss this.

[lepr]

55 minutes ago, lphilpot said:

Why not just make it white on black, black on white or some other sufficiently contrasting combination?

Yes, I'd prefer it returning to how it was in v1 - white text on black. There could be an option so the user can choose the v2 style (but with improvement) or the v1 style.

[Pšenda]

21 minutes ago, loukash said:

It displays the actual color we're sampling.

13 minutes ago, lphilpot said:

Beside, you can see the color in the circular magnifier anyway.

Although it is a significantly smaller point, it is a matter of display in the context of the surrounding colors. Picking a color outside of the area where the color is displayed/used will completely change its character. Then what good is this display? The question is actually - why am I capturing color from some object/part of the image? Because of how this color looks/acts in a given location, or because it's the color "xyz".
Otherwise, the case where the captured color does not match the color inside the magnifying glass is captured here.

P.S. When picking a color using the eyedropper from the Color panel, the color is displayed in a picked circle that is larger.

Edited December 1, 2023 by Pšenda

[loukash]

3 hours ago, Dan C said:

can vary depending on the exact colour values used

I was now able to reproduce and also somewhat narrow and define the issue by experimenting with HSL sliders and came to approximately these results:

• if:
  • values S ≥ 94 and L ≥ 22
• then:
  • values H ≥ 180 will have black text
• if:
  • values S ≤ 93 and L ≤ 21
• then:
  • values H ≤ 179 will have white text

"H" values between 200 and 300 can thus become a "black text on dark background problem zone", depending on S and L values.

I haven't checked any values vice versa though, i.e. no data for "white text on light background problem zone" (yet).

[Dan C]

1 hour ago, loukash said:

It should display the color because when you're sampling color e.g. from a photo, you may have only one lone pixel of that exact color to sample from, and you may want to see it in a "larger" context first. That how I understand the label was designed for: displaying the values and the actual color as background. I wouldn't want to miss this.

This is why I understand the change was implemented also, to better display to the user the exact colour being sampled, when the 'picker' loupe itself may not be as clear - or if you have it set to sample from a larger pixel area, the label is now coloured with the colour that will be picked as a helpful reference to the user.

1 hour ago, lepr said:

Yes, I'd prefer it returning to how it was in v1 - white text on black. There could be an option so the user can choose the v2 style (but with improvement) or the v1 style.

I understand however this might not be the desired behaviour for all users and I'll be sure to pass this feedback through to our dev team, as I understand we're looking at further ways to continue to improve the colour picker tool (some of these changes were previously implemented and subsequently removed during a beta cycle, as our team wasn't yet happy with the changes internally.)

25 minutes ago, loukash said:

I was now able to reproduce and also somewhat narrow and define the issue by experimenting with HSL sliders and came to approximately these results:

• if:
  • values S ≥ 94 and L ≥ 22
• then:
  • values H ≥ 180 will have black text
• if:
  • values S ≤ 93 and L ≤ 21
• then:
  • values H ≤ 179 will have white text

"H" values between 200 and 300 can thus become a "black text on dark background problem zone", depending on S and L values.

I haven't checked any values vice versa though, i.e. no data for "white text on light background problem zone" (yet).

Many thanks for this information, I suspect out developers will know more about the actual specifics, however I'll be sure to link to this information within the development report also - as mentioned this is logged as a bug with our team, as this text should remain readable, when the picker is displaying the to-be-picked colour.

[loukash]

2 minutes ago, Dan C said:

Many thanks for this information

Hey, I just noticed that my "if, then" logic might be actually incorrect. I was a bit in a hurry while testing and then typing the post…  
I may need to repeat the test to confirm the above logic.
But the rough numerical values are still about right, nonetheless.

[Pšenda]

17 minutes ago, Dan C said:

This is why I understand the change was implemented also, to better display to the user the exact colour being sampled,

As I wrote above - for me the constant/dynamic change of the label with the color value is annoying. But I understand that for many users, displaying captured color in a larger area may be desirable and useful.
So that the picker behavior does not have to be turned on and off in the Preferences, I will allow myself a compromise proposal - the label still has the same color (depending on the UI dark/light mode, the text is white on a dark background, or black on a light background), and after pressing the modifier key (Alt is offered), the entire content magnifiers will filled with captured color, so the captured color will be displayed in a large area - compared to a small label even significantly larger, and the color will be displayed in the context of the location of the color and its surroundings.

[lepr]

1 hour ago, Dan C said:

I understand however this might not be the desired behaviour for all users

I know, and that is exactly why my second sentence, which you quoted, suggested providing an option rather than forcing something on people.

[Affinityconfusesme]

 check out this link and the comment from patrick.