0

I need to procedurally generate color palettes consisting of several swatches. For each swatch the luminance is given as input, while chroma and hue are chosen using some algorithm.

Since luminance needs to be perceptually fixed I opted for working in LAB color space. I implemented a small C++ LAB class that converts to/from RGB. It appears to be working fine.

In order to manipulate chroma and hue I covert A and B components into polar coordinates where the angle of AB vector represents hue, while its length represents chroma (so called CIEHLC model).

chroma = sqrt(a*a + b*b);
hue = atan2(b, a);

Now rotating this vector shifts the hue while scaling it changes the chroma. So far so good.

The thing is now similar to HSL/HSV color wheel. However, it appears that rotating the AB vector by 180 degrees does not actually result in a complementary hue as it would in the HSL wheel.

So my question is how to go about calculating the correct complementary hue in the LAB color space?

nj16
  • 63
  • 5
  • `-a`, `-b` is not the same operation? – Giacomo Catenazzi Jan 12 '23 at 13:05
  • @GiacomoCatenazzi, It is. The problem, however, is that it doesn't result in a proper complementary hue. At least it appears so. – nj16 Jan 12 '23 at 13:32
  • Wikipedia uses: *hue angle, angle of the hue in the CIELAB color wheel*, so you are right, it is a different colour wheel, and like many others, they do not have the opposite colours at 180 degree. (but the hue is better distributed, useful for other cases, e.g. colour difference) – Giacomo Catenazzi Jan 12 '23 at 14:31
  • Yeah, it seems that CIELAB doesn't care much about hue. It ensures perceptive luminance stability at the expense of hue control, so to speak. Going around the LAB hue wheel doesn't perceptually feel "linear", for the lack of better word. For example if I generate a bunch of swatches distributed in 30 degree hue range, it will feel much more varied at some places in spectrum than in others. – nj16 Jan 12 '23 at 16:20
  • I guess the one way to handle this would be to convert from LAB to RGB to HSL, do the hue shift there, and then back the same way to LAB. For the final color combine the new LAB hue with luminance/chroma of the original color. – nj16 Jan 12 '23 at 16:26
  • You can use also CIE xy. Because color mixing is linear, and you should know x, y of your selected white, you can get the opposite colours (just that the distance is not maintained (so saturation should be calculated separately, but probably you should do it when you check out-of-gamut – Giacomo Catenazzi Jan 12 '23 at 16:33
  • Not sure if XYZ is any better in respect to hue shifts. To be honest, I don't fully understand it. It seems even less intuitive than LAB. The control I wish to have is rather simple - manipulating any of three components - hue, chroma or luminance, while other two stay perceptually intact. I guess this is not really possible solely inside one of the existing color spaces, without conversion from one space to other. This of course caries some information loss risk due to differences in gamut ranges. – nj16 Jan 12 '23 at 16:47
  • xy is not XYZ (but related). xy (of chromacity diagrams) has the properties of predicting colour mixing (but a line, not a point), and "complementary colour" is about colour mixing. The problem: most colour spaces are not created for hue angles as Munsell colour space, and forget colour space for colour mixing. And you can never define a hue angle with opposite colours at 180 degree and uniformity (eyes works with 3 colours, brain with 4 colours). – Giacomo Catenazzi Jan 13 '23 at 07:51

0 Answers0