[eridius]

It's not a bug. HSB is just a particular way to represent RGB colors, but it's not how the colors are stored. If you create an NSColor/UIColor with HSB, you end up with an RGB color (typically in the sRGB color space), so if you create a color with a saturation of zero, the resulting RGB color has no hue at all, which means you've lost the hue component entirely (and in fact, with the way HSB is defined, you try to get HSB values back out of a grayscale RGB color, the hue value is undefined, though I believe NSColor/UIColor will just report it as zero). Or to put it another way, there's no one-to-one correspondence between all RGB and all HSB values.

So basically, if you're writing an application that exposes HSB colors to the user, you should be storing the HSB values yourself rather than relying on UIColor/NSColor to preserve them, because it won't.

[rudedogg]

Thanks for explaining that, it makes sense. I ended up writing my own Color struct to store the values in HSB like you suggest.

It's odd I couldn't find information about this anywhere. The NSColor/UIColor docs don't mention it, but there is a clue I guess. They note that NSColor/UIColor is stored as CGColor internally, and CGColor doesn't have an HSB init.

Thanks again, I searched everywhere for the answer to this.

[eridius]

More specifically, UIColor and NSColor store a reference to a colorspace and a set of components (plus alpha). The colorspace defines the number of components and their meaning. So all of the RGB colorspaces define 3 components, Red, Green, and Blue, which means UIColor and NSColor need to store the color using those 3 components (plus alpha) whenever they're using an RGB colorspace.