Open tomchambers2 opened 7 years ago
I think that this also ties in with #1517 (i.e. making Colors mutable).
Ideally there would be a canonical array that describes the RGB screen colour (currently p5.Color.levels
), and all of the other colour descriptors (red, green, hue, saturation, etc.) would be scaled and calculated/interpreted on the fly using the global colorMode
at the time that the corresponding getter/setter/constructor is called.
This would make Colors completely transparent to the user (so you don’t have to keep track of e.g. whether saturation
is HSL-style or HSB-style for a particular Color, or whether it is scaled from 0 to 100 or 0 to 255 for that Color…), but it would also be quite a breaking change – even from Processing – which is not necessarily desirable.
I've been having some headaches with Color today - trying to get pixel colors from two images and then combining them using the hue value of one and the saturation and brightness from another. In the end I had to use this slightly circuitous code to get it:
It seems to me like it would be simpler generally to store a mode-agnostic representation of the color in Color and then export it via hue(), red() etc according to the currently set colorMode, simplifying the example to:
I might have a niche use case, so fair enough if this isn't an issue! But this seems to me to be closer to how colors are done in Processing. For me it's unintuitive to have the colorMode attached to the color when it isn't passed as an argument to the constructor.