Hi,
I’m trying to understand why colors show up differently in Cocoa.
DigitalColor Meter reports the correct color within the Cocoa Color Picker
Once used for fillrect in a canvas it reports this;
It appears to be related to this Feedback case;
<https://xojo.com/issue/22436>
I was wondering if anyone has details on how to properly convert colors to the correct value?
Thanks,
Paul
Color Matching makes the difference. Your screen profile is not the same as the color space used in RB drawings.
Thanks Christian.
So what is the correct way to deal with this?
Learn how to use our LCMS plugin to convert color between screen profile and sRGB or whatever is used here. (or ColorSync)
This topic is not easy and we could have a few sessions on a conference to talk about this.
This is reported in a feedback case. As Christian says, this is because the IDE does color correction but your application doesn’t. In Cocoa theoretically you could load all colors through NSColor to get the “corrected” version, although I haven’t looked into it.
I personally think this should be built-in, but perhaps it’s not possible.
[quote=14420:@Eduardo Gutierrez de Oliveira]This is reported in a feedback case. As Christian says, this is because the IDE does color correction but your application doesn’t. In Cocoa theoretically you could load all colors through NSColor to get the “corrected” version, although I haven’t looked into it.
I personally think this should be built-in, but perhaps it’s not possible.
<https://xojo.com/issue/22980>[/quote]
When the Carbon framework added support for CoreGraphics, it had to mimic the QuickDraw rendering as closely as possible. To do this, all colors were drawn in the device’s colorspace. This meant that &cFF0000 drew at the output device’s absolute red, which could vary drastically across devices. Given this variance, Apple recommends that all colors are defined in a device independent colorspace [1, 2, 3].
Since we had the opportunity, the Cocoa framework follows their lead and defines all of its colors with NSCalibratedRGBColorSpace. This is generally the correct thing to do, but is definitely a change in behavior from Carbon. Also worth noting is that we also define our Picture objects as being in the same colorspace. When you save the picture to disk, it keeps this information around and you get a color matched image anywhere you take it.
If you want to draw in the device colorspace, you should be able to create an NSColor in the device colorspace, convert it to the generic colorspace, and then use that as your color in Xojo. I believe that this has the potential to be a lossy operation.
Disclaimer: color theory is complicated and I am far from an expert on the matter. I’m using terminology Apple has chosen and uses in their documentation and WWDC videos.
[1] Color Management Overview - Color Spaces
[2] Color Programming Topics - Working With Color Spaces
[3] WWDC 2012 Session Videos - Best Practices for Color Management
One thing I found, was that NSColor uses singles (or floats) for values and Xojo uses Uint8s, it’s possible to pick a color that doesn’t exist, so it’s rounded to the nearest Uint8 value. We’ve had a couple of complaints about this. I’ve logged a feedback request for more precision with colors.
The other way to do it is to use NSColor and the NSdrawing functions, which is laborious.
Do you have any sample code on how to do this?
I have reviewed a lot of these resources and I don’t quite understand how to convert colors properly.
I would really appreciate any help in doing this.
I’m out of the office at the moment, but when I get back (this weekend) I must get to work on app which uses this and then and I’ll present my findings.
That would be great, thanks!
