That’s actually wrong. The only thing you are allowed to do without changing chromaticity (that is, the combination of hue and chroma), is multiplication. Adding or removing light (aka offsetting RGB) will hit the Abney effect.
Any angular component that you make appear from rewriting the cartesian RGB coordinates in some flavour of polar coordinates is only loosely related to hue. You can see what it yields to travel the HSV space at constant H angle: A perceptual color space for image processing. Notice how blue takes a leap into magenta.
It’s generally wrong to think that RGB is connected in any way to color. It’s actually misleading to call RGB spaces “color spaces”. You can write ugly numerical fits (like mine Engineering | Color saturation control for the 21th century) that try to connect tristimulus (RGB or CIE XYZ) to color correlates, but this ugly “data-science” more than actual colorimetry and it’s still inaccurate.
RGB spaces express light spectra in the shape of a 3D vector. That’s all. It’s generally wrong to start mixing RGB spaces with any concept of saturation, hue, chroma, brightness, lightness, etc. You need to heavily massage RGB spaces to start drawing some connection between RGB tristimulus and actual color attributes.
It is actually correct, for (I stress again) the simple arithmetical systems.
The only thing you are allowed to do without changing chromaticity (that is, the combination of hue and chroma), is multiplication. Adding or removing light (aka offsetting RGB) will hit the Abney effect.
I have been discussing the effect on hue only, not chroma. The Abney effect is a perceptual effect. I have not been discussing perceived hue.
There is no non-perceived hue. That’s by definition a perceptual attribute of color.
No. Just because RGB code values are numbers doesn’t mean that you can do whatever you want discarding the reality of what is encoded. Math here is only the language, not the reality, not the thing being described. The only thing that matters is the reality being represented, the rest is mere technicality. You can’t offset RGB values and say “hue is preserved”.
You are of course free to shit on 2 centuries of art theory and 1 century of color science and reuse words out of their context to make up alternative facts that hold true only in your unspecified framework where maths define reality.
I’m sorry if I didn’t make the context clear. I have been discussing “hue” mostly in the context of simple arithmetical systems: HSL, HSV, HSI, HCL etc.
Seems to me that’s exactly what @afre saw coming, a difference in definitions of the same term. I nearly replied about it too, but this is exactly what anyone learning about this subject is likely to encounter.
It’s possible to handle the ambiguity if you understand it from the perceptual layer up, so I recommend starting with the colour science. I started from the sRGB side and made lots of bad assumptions because of it!
I think I mentioned, I’m not after good looking pictures, but rather documenting facts. And I’m interested in astronomy, not landscapes or portraits.
And, at this point, rather just in “signal processing”.
And I’m aware that RGB covers colours as roughly as 12th roots cover musical scales.
Also, I’ve never heard of vawelength of brown colour.
Maybe it helps to specify, that the systems I’m dealing with are RGB-based, and I’m trying to learn to process RGB (and gray value) data.
Brown is essentially “dull, dark yellow”. So the predominant wavelength of brown is the same as that of yellow, but there is also a load of other wavelengths, spreading into the blue wavelengths.
But you have to distinguish RGB encoding (each pixel is stored as a triplet of R, G and B values), and the colour space in which you do your editing (which can use R, G, B as basic axes, or another system, like Lab). But at the end of the day, you will have to translate the values from your colour space to RGB triplets, as that’s what your screen works with.
So don’t confuse the way your image is encoded with what happens “under the hood” while you edit.
And another problem for you might be that you are not even working with “real colours” (depending on the kind of data you get in your astronomy images). As for the “signal processing” part, I’m not sure a photography forum is the best place to discuss that, as the aim of the treatment might be completely different.
Signal processing: get the important information visible, no matter how the final image looks;
photography: get a good looking image, as close to what you want as possible
(OK, that’s a bit extreme perhaps )
As for the “signal processing” part, I’m not sure a photography forum is the best place to discuss that, as the aim of the treatment might be completely different.
This is, by far, the most informative place I have come across, when it comes to my interests. Like I mentioned, I checked the contents of quite some classic books, but they seem to miss about half of what I’m interested in.
I’ve never done image processing with subtractive colour models, eg CMYK. On the rare occasions that I need to, I usually convert to a RGB model first, then do the processing, then convert back to CMYK.
)