Saturation operator

[celoyd]

One of the convert flags we want to replace is the second argument to -modulate, which adjusts saturation. (Pulled out of #5.) Braindumping some options, in order of increasing hackiness:

1. The conceptually straightest path here is to convert RGB to a radial colorspace that has a dedicated saturation channel, multiply that channel, and convert it back. Our default radial colorspace is LCH, because it combines a nicely grounded definition with a good approximation of perceptual uniformity. Unfortunately, the conversion is relatively complex and resource-hungry: skimage, for example, goes RGB → Lab → LCH and back.
2. We could use HSV, which has a simpler definition.* The 👎 I see is setting a precedent of using HSV, which isn’t our best practice. I think it’s wiser to keep rio color in a “gold standard” role instead of a “workable approximation” role – for that, you might as well write your own functions. *Though possibly not faster, given that it has a 6-part case, as opposed to the trig functions of the LCH route. I don’t have good intuition about numpy optimization.
3. We could work out an equivalent (ish) saturation operator that works directly on RGB pixels. I see this as even more of a hack: by the time it was well defined, it’d be doing 80% of the work of converting to and from a radial colorspace anyway. On the 👍, it would probably be very fast and do a fairly good job of matching any other saturation operator.

How do you see this, @perrygeo?

[perrygeo]

in order of increasing hackiness

😄

I say we start with skimage conversion to LCH since it's well tested. In the initial phases it's more important to be correct than fast. As we move on, we can swap out alternate techniques, benchmark them for performance improvements and use our test suite to ensure correctness.

[perrygeo]

Color noob question: in the LCH colorspace, adjusting Chroma is roughly equivalent to saturation, correct?

[perrygeo]

Of course the readme states

Some functions may be trivial (gamma) or already implemented elsewhere (for example, in skimage), but we want versions of them that are standard and light, without big dependencies.

And here we are talking about bringing in big dependencies like skimage. Hrm.

[celoyd]

in the LCH colorspace, adjusting Chroma is roughly equivalent to saturation

Exactly. Since saturation doesn’t have a single definition, it’s fine to refer to C as saturation. (Or possibly caturation, with a soft C.)

here we are talking about bringing in big dependencies like skimage

Yeah. I’m not eager to bring in big deps, but we are much better at doing so quickly and smoothly now than when we wrote the readme.

We could push this even further. Since skimage implements virtually everything we would want in rio color (other than the CLI interface), we could think of rio color as more of a skimage/rasterio bridge than anything else.

[perrygeo]

we could think of rio color as more of a skimage/rasterio bridge than anything else.

:thinking_face: