Color space: boundaries for C

[emmanuel-ichbiah]

Hi, I really love iWantHue and the HCL color space. Thank you for this wonderful website.

I wanted to point out that the boundaries for C should be: MIN 0 to MAX 134.

I found out using the following code where I convert all possible RGB values to their HCL counterpart in order to calculate min max values for H,C and L:

min H := max double
min C := max double
min L := max double

max H := min double
max C := min double
max L := min double

for R := 0 to 255 do
for G := 0 to 255 do
for B := 0 to 255 do
  begin
      convert (R,G,B) to (H,C,L)

      min H := MIN( min H, H);
      min C := MIN( min C, C);
      min L := MIN( min L, L);

      max H := MAX( max H, H);
      max C := MAX( max C, C);
      max L := MAX( max L, L);
  end;

The current GUI lets you think that 100 is a maximum for C.

And when you select color space All colors it sets the C range to 0 - 100 whereas it should set it to 0 - 134.

[michkowalczuk]

Also waiting for the answer. What C=100 means i your app? Do you make any normalization?

[Yomguithereal]

I am not really sure here, frankly. I have found in the wild at least 3 different bounds for the C parameter: 100, 134 and 180. So if someone wants to investigate a little bit to understand whether iwanthue implementation is correct or not, I'll be grateful.

[emmanuel-ichbiah]

I have looked at a code a long time ago and what I can say is:

• I don't recall that there is any normalization occuring for C. It is just the C range selector which is configured for a [0,100] range whereas it should be [0,~134].
• else the implementation seems correct to me

[Yomguithereal]

@emmanuel-ichbiah @michkowalczuk I have edited the range picker on the website to accept max chroma 134. Can you tell me whether this feels right, in which case I will also fix the color validation code in the npm package.

[emmanuel-ichbiah]

@emmanuel-ichbiah @michkowalczuk I have edited the range picker on the website to accept max chroma 134. Can you tell me whether this feels right, in which case I will also fix the color validation code in the npm package.

Seems perfect to me! Thank you!

[Yomguithereal]

Thanks @emmanuel-ichbiah. I cannot find any validation problem to accept cmax = 134 in the code of the npm package so I think I will leave it at that. Of course the all preset is a bit misleading because its cmax is set to 100 but you can override it and I feel it will annoy people if I change it without forcing a breaking change.

[michkowalczuk]

I have looked at a code a long time ago and what I can say is:

• I don't recall that there is any normalization occuring for C. It is just the C range selector which is configured for a [0,100] range whereas it should be [0,~134].
• else the implementation seems correct to me

It's not such a simple thing... Chroma maximum value depends on combination of Hue and Luminance , as you can find here and here.

There is no perfect solution here. The most correct solution seems to be that when selecting colors, it checks whether it is possible to convert the color to RGB for a given combination of l,c,h. You can read about color clamping for example here and here.

[emmanuel-ichbiah]

«Chroma maximum value depends on combination of Hue and Luminance» I perfectly know this.

But if you restrain the C selector to a 0 - 100 range you, depending on your H and L range selection you will NOT get all possible colors for that H and L ranges.

Overall I agree that there are not many colors with a C > 100 but nevertheless the former implementation was misleading. It gave the impression that there were NONE.

[michkowalczuk]

former

It's just a theoretical considerations ;-) Regardless of what the Chroma value is the theoretical upper limit, iWantHue is a great tool. I appreciate your work!