colorpicker

colorpicker copied to clipboard

This can be demonstrated on the additional demos page, under "Output Formatting".

Black:

1. Open the color picker
2. Set a Hue and Saturation other than 0, but leave Value at 0
3. Pick that color
4. Reopen the color picker

On reopening the colorpicker, the hue and saturation are back to 0. Compare to the same steps except set Value to 1 (or a value close to but greater than 0).

White:

1. Open the color picker
2. Set the Hue to something other than 0, set Value to 100 and Saturation to 0
3. Pick that color
4. Reopen the color picker

On reopening the colorpicker, the hue is back to 0. Compare to the same steps except set Value to 99 instead of 100, or Saturation to 1 instead of 0.

---

This behavior makes sense when the output is purely rgb (including hex), because rgb(0,0,0) and rgb(1.0,1.0,1.0) have no hue. But when the output is hsv this does not make sense any more.

I'll look into it.

As you mentioned, RGB conversion will logically cause this. As will CMYK and L_A_B conversion or pretty much any conversion to and from HSV (or HSL or HSB) colorspaces.

Internally, Colorpicker tries to preserve any explicitely set colorspace channel values in whatever colorspace is actively used. Sadly this means that ANY modification of non-HSV colorspaces will lose the H and/or S. It's actually quite hard to ensure this that this doesn't happen but it should be possible to trace the culprit down.

Could colorpicker be made to stick to one colorspace internally even if the user is actively using another colorspace? In the demo I mentioned, for example, the programmer might tell colorpicker to always use HSV internally since its input and output are in HSV. Then, even if the end user picks a Red value, the internal representation remains in HSV colorspace.

Colorspaces don't all cover the same possible range of colors, therefore it is impossible to map every color possible in the used colorspace to any other specific "internal" colorspace without loss of detail on the used colorspace. This is why Colorpicker switches the internal model dependant on the last used controls' colorspace representation; it's the only way to store the color exactly as the user specified.

I've tested a bit, but it seems that if you use a colorFormat that uses HSV (i.e. '#hxsxvx'), then nothing gets lost. It's only when you explicitely use non-HSV colors that HSV channels are reset. I'll see if I can think of a fix that won't mess with other operations, but it may take a while.