Unexpected NaNs with HSV + toSRGB()

[iamcalledrob]

Not a bug per-se, but an unexpected developer API so leaving some feedback!

HSV with a NaN hue is convertible to a sane SRGB value

HSV(h = Float.NaN, s = 0f, v = 0f, alpha = 0f).toSRGB()
-> RGB(r=0.0, g=0.0, b=0.0, alpha=0.0, space=sRGB)

However, HSV with a NaN hue and a non-zero saturation component converts to (NaN, NaN, NaN, alpha)

HSV(h = Float.NaN, s = 0.1f, v = 0f, alpha = 0f).toSRGB()
-> RGB(r=NaN, g=NaN, b=NaN, alpha=0.0, space=sRGB)

I suppose this is technically correct (can't saturate a hue of NaN), but this is a source of unexpected runtime bugs whenever user input is involved.

I would propose that the s component is ignored when the hue is NaN, rather than returning a broken color. This is a particular issue when calling toComposeColor(), which will cause a crash.

In my case I had code like the following, which worked until someone chooses a monochrome color.

fun androidx.compose.ui.graphics.Color.withMaxSaturation() = toColormathColor().toHSV().copy(s = 1f).toComposeColor()

Color(0xFF5B7A63).withMaxSaturation() // OK
Color(0xFF6E6E6E).withMaxSaturation() // IllegalArgumentException: red = NaN, green = NaN, blue = NaN, alpha = 1.0 outside the range for sRGB IEC61966-2.1 (id=0, model=Rgb)