Support for other color spaces

[csimo005]

I would like to include more color spaces in the pixel representation. I come from a CV background, and for a lot of thresholding operations, I find that HSV in particular is particularly useful. I think I have seen other open issues asking how to do this, and it strikes me as something that ought to be more generally supported. Is there a reason for its absences or is it something that no one has gotten around to yet?

[197g]

See #786 , yes. No one has gotten around to something that actually works without being too much overhead in the type system given the generality of the problem space. A lot of formats, a lot of different representations. So we have RGB which is the common denominator.

Getting an implementation of color spaces out the door is a goal this year.

[kornelski]

However, HSV in particular is not a color space used by any image formats. It sits in an awkward space between better than nothing, but not being good at anything.

If you want to measure perceptible differences between colors, then Lab/Oklab are way more accurate.

If you want color space actually aware of saturation, then Okhsl/Okhsv are way better.

If you just want something quick with separate lightness channel, then YUV/YCbCr are going to be more readily available directly from image formats and probably supported before any HSL/HSV colors.

[csimo005]

It's a good point that image formats don't use HSV & HSL, perhaps they would be more appropriate to include in the imageproc crate. From my background, I'm most used to thinking of RGB as always implicitly meaning sRGB. From other discussions linked, it seems like the important part of colorspaces for the main image crate is ensuring consistent capture and display across different devices, not different analyses that are easier in a particular colorspaces.