Conversion from RGB to HSV result in a NaN hue

I’m using your library to build an HSV style color picker which inputs and outputs RGB colors, thus the need for conversions. I’m running into an issue where converting a valid RGB color to HSV results in a NaN for the hue (RGB("#A9A9A9").toHSV() results in HSV(h=NaN, s=0.0, v=0.6627451, alpha=1.0). If I check the colormath color converter on the website, it converts it to HSV 0, 0, 0.66275.

Debugging the code, I see down in RGB.srgbHueMinMaxChroma calculations, min == max, so chroma is assigned 0 and thus h is set to NaN.

Is this a bug? or should I assume if a value is NaN to make it 0f

This is running on an Android emulator, Kotlin 1.5.31.

[ggrell]

Thank you, I now better appreciate the complexities of color math! And thanks again for building this great library.

[ajalt]

Monochromatic colors don’t have a defined hue. Assigning one arbitrarily may be desirable for some applications, like your color picker, but causes problems in others.

For example: 0° hue in HSV is red. So if try to draw a gradient in HSV from white to blue, if use 0° hue for white, you’ll see that the gradient will travel through red and magenta (or green, depending on the direction around the hue circle it travels), rather than just changing the lightness like you’d want:

HSV(0, 0, 1).interpolate(HSV(235, 1, 1), .5)
// #7d4080, dark magenta

HSV(NaN, 0, 1).interpolate(HSV(235, 1, 1), .5)
// #404580, dark blue

So we need a separate representation for undefined hues. Colormath uses NaN for this, since it makes it easier to write generic map functions on colors without performance penalty of boxing into Float?.

As for your example, HSV.toSRGB() should never result in NaN values in the RGB instance. Can you share the actual values you are using that caused that? RGB("#ffffff").toHSV().toSRGB().toHex() == "#ffffff". Certainly all hex values should round-trip.

I’ll definitely add an extension like you suggest.