I’m using SelectColor with the eye dropper. I select a color on the screen and the values of the sliders and the “hex” value change to the correct color values. However, the value returned by SelectColor is not the same as the one show in the palette. Any ideas?
2015r1/Mac 10.12.1 Sierra
Can you give an example of what you are clicking and what you are getting?
I suspect this has something to do with Xojo using 8-Bit colors as opposed to OS using unknown-bit color.
The values I get from a NSColor (from the color picker) tend to range 0.0 - 1.0 with fairly high precision (I don’t really know if it’s 16 or 32-bit), once converted to Xojo it’s close, but no cigar.
Maybe, but he talks about hex value and it should be an 8bit color
[quote=302858:@Chris Griffin]I’m using SelectColor with the eye dropper. I select a color on the screen and the values of the sliders and the “hex” value change to the correct color values. However, the value returned by SelectColor is not the same as the one show in the palette. Any ideas?
2015r1/Mac 10.12.1 Sierra[/quote]
You mean you select for instance &cFF0000 and you get something else ?
For example, I click on some color on the screen that shows in the picker as F2F2F2. I then click OK and the color that is assigned to the ByRef color var in my code is EEEEEE. I haven’t done extensive testing to see if there is a linear difference in the values or anything like that. If I type the numbers into the picker then I get the correct value in my code.
Now that I think about it it’s probably doing some kind of gamma conversion. The problem is that is shows the correct value for what the color is on the screen but returns a different value.
I could not reproduce the issue you describe in 2016R4.1.
I used the very basic example from the LR http://documentation.xojo.com/index.php/SelectColor
Dim c as Color
Dim b as Boolean
c=CMY(.35,.9,.6) //choose the default color shown in color picker
b=SelectColor(c,"Select a Color")
system.debuglog str(c)
You should try downloading 2016R4.1 and see if the problem persists.
Downloaded 2016R4.1. Copy and pasted your code and got the same incorrect result. I even tried changing the color profile for the monitor. 
I frankly don’t see how the result should be incorrect there and not here, on such a small snippet.
Have you changed anything ?
If I type F2F2F2 into the hex field or 242 into the RGB fields it works correctly. If I use the eye dropper OR select one of the colors in the little squares next to the eye dropper it fails. It seems once I click on something it fails from there on. So if I click on one of the saved colors and then type F2F2F2 into the hex box it still fails.
Probably OS is using two different functions: on to show the data on the panel and one to return the value.
Since colors have more depth than they used to have what you are seeing is a rounding problem.
If you write the hex color AND TAB OUT OF THE FIELD what you get is the written color in every case.
When you click on a spot color you see the values (rounded) but when you return you have a different one (floor) if the color component is on a edge case.
My guess is that you’re on the right track, but that it’s actually related to color management. Presumably the color chosen via the dropper is in the screen’s color space and the result from SelectColor is NSCalibratedRGBColorSpace.
46296 - selectColor returns a different color that it shows
Michel Bujardet Today at 10:05 AM
OS: OS X 10.12.2
Xojo: Xojo 2016r4.1
Steps: Run the attached project. It is extremely simple, just showing the result of selectColor.
1 - Click the sliders, and enter a color. Press OK. The very same color as what is displayed in the lower right side appears in the messages pane, as expected.
2 - Chose the preselected color (Apple), select one.
3 - Go back to sliders. The value is displayed Hex. Click OK. It shows the same value in the message pane.
4 - Select the Crayolas. Chose a color. Go back to sliders, note the color, click OK. Message pane displays the same.
5 - Select the spectrum. Chose a color, go back to sliders, note the color, click OK. Message pane shows something entirely different.
6 - go back to preselected, crayolas, do it again. The color reported is identical to that chosen.
7 - Go to the wheel, select a color, go back to slider, note the color and click OK. The value reported is not the same as displayed.
Now all colors are broken. Crayola, preselected or slider, all report different colors than displayed.
The bug is apparently not recent. It manifests since 2013R1.
File attached: selectcolor.xojo_binary_project.zip
The issue is that colors can’t be represented with just a 32-bit RGBA value in a color managed system. At a minimum they also need to have a color space that describes how to interpret the numeric values.
Due to binary compatibility constraints that are difficult to solve colors in Xojo are implicitly treated as being in the “generic” RGB color space. Creating a Xojo color from a color in a different color space will require conversion that likely results in different numeric values for the channels. Remember that the goal of color management is to preserve the perceived color and not absolute channel values for some specific device.
Could the returned colour be translated using the generic colour space, before being returned to Xojo?
I know that some colours simple cannot have their colorSpace converted because they are in fact not colours, but images.
[quote=307256:@Joe Ranieri]The issue is that colors can’t be represented with just a 32-bit RGBA value in a color managed system. At a minimum they also need to have a color space that describes how to interpret the numeric values.
Due to binary compatibility constraints that are difficult to solve colors in Xojo are implicitly treated as being in the “generic” RGB color space. Creating a Xojo color from a color in a different color space will require conversion that likely results in different numeric values for the channels. Remember that the goal of color management is to preserve the perceived color and not absolute channel values for some specific device.[/quote]
That does not explain why color profile would be applied to crayola and preselected colors be reported as raw on the beginning, and corrected only after using the wheel or the spectrum.
Moreover, why display the hex value if it is to not apply it in the end within the code ? I would expect the displayed Hex in the color picker to be already the result of conversion.
It is, actually. The SelectColor function is implemented via the ancient Carbon GetColor in order to have a modal picker. This is limited to RGB values with no color profile information and GetColor does the color conversion internally. It’s a bit of an academic thing, though, because Xojo would have to otherwise convert the color itself in order to be able to represent it as its Color type.
I wasn’t able to reproduce this behavior.
The hex value in the color picker is in a different color space.
[quote=307299:@Joe Ranieri]@Michel Bujardet That does not explain why color profile would be applied to crayola and preselected colors be reported as raw on the beginning, and corrected only after using the wheel or the spectrum.
I wasn’t able to reproduce this behavior.[/quote]
You must first select a color in Wheel or Spectrum. Afterward, preselected and crayola manifest the same issue. That is described in the bug report.
I also have tried & cannot reproduce this on 10.9, 10.10, 10.11 or 10.12
I hate it when I read “cannot reproduce”.
Have you really done exactly what I tried to describe ?
If you go directly to RGB, Crayola or preselected colors, the issue does not present. It happens only for colors initially selected in the wheel.
Note that first selecting a color in Spectrum, then switching to RGB and inserting from there produces the same issue as selecting in Wheel.
This movie was shot from 2016R4.1 under macOS Sierra 10.12.3.
The only way I see to work around that dreadful mess is by noting manually the Hex value, and apply it from the keyboard afterward.