Well, I’m learning too, so thanks back at you!
No, I think it’s all interrelated. Choosing a palette of colors, keeping colors within the palette while being able to freely choose colors within the palette, and modifying an already chosen color without going outside the palette, it all relates.
When you talk about “colorants” I’m not sure what you mean. To me “colorants” usually refers to the xyY/XYZ values that define a given RGB matrix color space.
I’m guessing that you are using the term “colorants” as the RGB equivalent of picking real-world paint pigments that will be mixed together to make various colors (which is basically what an RGB matrix profile is, a set of colorants, plus black and white, that can be mixed together to make various colors)? So one colorant combined with mixing with black and white would result in a monotone image? One or more colorants might be specified to define a palette? Or (and/or?) is there a “spectral rendering” meaning?
Like yourself with the straight-line gamut map, I also use straight lines to define a restricted color palette. But my straight lines are drawn on the LCH color wheel to choose a range of hues, a subset of all possible hues.
I think the LCH color space is a good way to choose a range of hues because the chosen Hues are independent of the particular RGB color space. So LCH Hue 20 is always a particular red Hue, and Hue 90 is always “true yellow, not green-yellow, not orange yellow”, and Hue 260 is always a plausible shade of sky blue, and so on. Whereas on the HS"X" color wheels, the “meaning” of any given hue varies from one RGB color space to the next, depending on the relative locations of the colorants.
A second reason why I like LCH for choosing colors is that the “Chroma” of a given RGB color as located on the LCH color wheel is constant, always the same, regardless of what RGB color space the painting or photograph might be painted/edited in.
The various HS"X" calculations for Saturation vary from one HS"X" color space to another, and the “same” HS"X" values for a given color in the sRGB color space doesn’t match the HS"X" value for that same color in, for example, Rec.2020 or AdobeRGB or etc - the larger the RGB color space, the more saturated any given HS"X" coordinates will be, though these coordinates also depend on the RGB color space TRC. To be strictly comparable, you have to compare RGB color spaces with the same TRC.
There is a problem with using LCH Chroma to modify colors, that I’ve been vaguely aware of, that is directly related to why GIMP-2.9’s “Colors/Saturation” keeps the “not really blue but looks blue” blue jeans still looking blue, and using the Chroma slider of the Hue-Chroma tool does not. I spent some time looking at the “Colors/Saturation” code and experimenting with the two ways to increase Chroma in an image, and wrote up the results in a tutorial:
Three ways to modify saturation using GIMP 2.9/2.10 LCH color tools:
While writing the tutorial I realized that I had almost certainly mixed up the “color appearance model” definitions of “saturation” and “colorfulness” in some previous tutorials I’ve written. LCH is not a color appearance model, but rather a color difference model. But one can define “saturation” in LCH as “Chroma divided by Lightness”, which more or less correlates with saturation in color appearance models such as CIECAM02.
I was hoping the @jdc might take a look at the final section of the tutorial (Modify saturation using GIMP's LCH color tools) and let me know how badly I might have mangled the concepts
Anyway, LCH Lightness/Chroma/Hue are probably not the best parameters for modifying an already selected color. Lightness and Hue are fine, but instead of Chroma, probably “Chroma divided by Lightness” would be a much more useful third parameter for modifying colors.