I did the same thing for a color app I built for adjusting CSS values using a color wheel.
Dealing with color is tricky, I'm sure I made a lot of mistakes..
One interesting bug I think I found is with NSColor/UIColor. If you set the hue for a color, and then proceed to drop the saturation/brightness to 100%/0%, it'll wipe out the hue when you change the saturation/brightness back to sensible values. It could just be something with color spaces that I don't understand, but it seems like a bug to me (data is destroyed).
I read a lot about color working on that app, and it is a pretty deep subject. You can read all about the science aspects of color, light spectrums etc. Then you read something else and realize that color is just a human sense, that is all about perception and not set in stone. All the color spaces and representations seem to have their flaws and certain adjustments don't match expectations.
To summarize I tried to learn and understand color, but in the end it all seems like a mess. I don't have an academic background, so maybe this is just a lack of understanding.
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.
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.
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.
Dealing with color is tricky, I'm sure I made a lot of mistakes..
One interesting bug I think I found is with NSColor/UIColor. If you set the hue for a color, and then proceed to drop the saturation/brightness to 100%/0%, it'll wipe out the hue when you change the saturation/brightness back to sensible values. It could just be something with color spaces that I don't understand, but it seems like a bug to me (data is destroyed).
I read a lot about color working on that app, and it is a pretty deep subject. You can read all about the science aspects of color, light spectrums etc. Then you read something else and realize that color is just a human sense, that is all about perception and not set in stone. All the color spaces and representations seem to have their flaws and certain adjustments don't match expectations.
To summarize I tried to learn and understand color, but in the end it all seems like a mess. I don't have an academic background, so maybe this is just a lack of understanding.