Has anyone else noticed that (on Mac) if you change the colour off a label from the UI and then close it and go back and edit the colour again the RGB numbers are not the same as what you set them to before. It is wrong each time you change it.
That’s because SelectColor doesn’t return the exact value the user selects. We (re)discovered this with the recent SelectColor problems, but Xojo seems to have ignored the color being wrong.
<https://xojo.com/issue/46296> [selectColor returns a different color that it shows]
<https://xojo.com/issue/57789> [SelectColor returns the wrong color]
[quote=461609:@Tim Parnell]That’s because SelectColor doesn’t return the exact value the user selects. We (re)discovered this with the recent SelectColor problems, but Xojo seems to have ignored the color being wrong.
<https://xojo.com/issue/46296> [selectColor returns a different color that it shows]
<https://xojo.com/issue/57789> [SelectColor returns the wrong color][/quote]
We didnt ignore it. On macOS, the color you get back is affected by the systems color profile in effect at the time the color is selected.
But this doesnt happen if you use Photoshop or Illustrator or other software that allows colour editing on the Mac so why cant the IDE do whatever they do?
.^.__________ Well… Killer argument detected.
And if possible, have the option to select “don’t use color profile correction” (the “pure” RGB with black 000000 and white FFFFFF, ignoring current “color corrections”), or “use it” (I don’t know who wants this). Interestingly, I do use 2 monitors, each one have a different “color profile” set, what “color profile” my app will pick when it runs? I need a neutral option and the Xojo IDE should be using it too. I want a FFFFFF white, and anything, as selected.
Most probably because they convert the color into the current colorspace before using it. Which is something the IDE could (and should, IMHO) do too.
@Rick Araujo : The monitor profiles are used for display purposes only and do not affect the color definition itself. A different topic is the color space that is used by the OS, and this should be matched against the Xojo representation. If you look closely, you will notice that some Xojo system colors are a bit off against their native values because of the lack of internal colorspace conversion.
A color profile correction should not be aplyed AFTER picking a color, but when showing it. So, you choose and pick a Gray 7F7F7F, and such color, in one display, the system will output it as a 7F8080 level after “color correction” and in another at a 7E7E7F level, for you to perceive both more equally due to “hardware” differences, but the color is 7F7F7F. The original RGB must be kept. Pick a color is one thing, displaying and printing it “adjusted”, is another. Same for CMYK in different printers and their inks.
I just tried a quick experiment and I’m beginning to wonder if the different panels of the color picker don’t necessarily stay in sync with one another.
For example, If you go to the Color Palettes list and choose Apple and then choose Green, there’s no obvious indication of what the hex values should be… so you think, oh I’ll click on the Color Sliders picker and look at the hex values. The problem I’m seeing is that the hex picker shows 00FF00, but Apple’s greenColor is actually not that… it’s actually &c22FF0600, which is what the picker returns.
I’m also seeing a case where certain color pickers are altering the color profile in use on the picker. For instance, I get consistent colors until I start using my “Developer” picker which requires you to choose a profile. Once I do that, all the other pickers seem to be returning colors adjusted by that profile too.
Tomorrow, with luck, after @Sam Rowlands winning his battle “AppWrapper vs Apple”, maybe he could give us insights, because he has deeper knowledge on Apples’ way of doing things, API’s, and color management.