What does RGB working space actually do?

[stevek]

Hi all,

What does the RGB working space actually do and why do you need to use it?  I can never quite understand this tool.  When I apply it to an RGB image it doesn't seem to do anything...

Regards, Steve

[pfile]

well it gets pretty deep into color theory but for the purposes of PI it modifies the R/G/B channel weights for the purposes of extracting something closer to true Luminance when extracting L* from an RGB image. you want them to be weighted equally which is why you change the weights to 1,1,1.

the human eye is most sensitive to green so with default channel weighting in an RGB image the green channel participates more in the calculation of L* than the other channels. if you're trying to get an equivalent L image that might have come from an L filter, there's no green bias there - all wavelengths pass equally thru the filter.

it doesn't seem to do anything because it doesn't really change how the data is displayed, just how it is interpreted behind the scenes.

rob

[stevek]

hi Rob, thanks for that.
So, I process my RGB from the R,G, B greyscale images to create the RGB master.  Then I process my L.  Then I do LRGB combination.  Where do I apply RGB workspace to this in the workflow?  Or do I?

Thanks, Steve

[dld]

Thanks Steve for asking this since I have a similar question:

Some people suggest setting the RGBWorkingSpace coefficients at equal values. Is this necessary? And if yes, when and why?

Clear skies,
dld

[pfile]

i dont think you need the RGBWS in that flow - to my knowledge it is used if you want to extract a more L-like image from an RGB image. this, for instance if you want to make a pseudo-L image so you can do an LRGB flow on RGB data.

you would set the coefficients to 1,1,1 before extracting L* to get rid of the "perceptual" weighting when the L* is extracted.

ro

[Juan Conejero]

As Rob has explained, an RGB working space (RGBWS) defines how images are separated into color and brightness components (speaking more rigorously, how chrominance/luminance separations are performed). In general, this is useful mainly during the nonlinear phase of post-processing.

The RGBWS implementation in PixInsight comes from the early days of PixInsight LE, back in 2002-2004. Here is a quite complete description:

https://pixinsight.com/doc/legacy/LE/14_color_spaces/color_spaces.html

Please be aware that I wrote the above document (as well as the entire LE documentation) more than 15 years ago. All has changed dramatically since then, including me and how I understand image processing and the PixInsight project, and basically everything inside and outside PixInsight

The idea of using two separate RGBWS, one for color management (acquired through color profiles and implemented by a color management system (CMS)) and a second one for luminance/chrominance separations performed during image processing tasks (implemented as a global RGBWS and the possibility of defining a different RGBWS for each image), made a lot of sense at the beginning of this century. However, I think it is questionable today, at least in the way it is currently implemented. Definitely, this part of PixInsight is subject to a strong critical analysis in my head.

Some people suggest setting the RGBWorkingSpace coefficients at equal values. Is this necessary? And if yes, when and why?

In most occasions it is not necessary. A custom RGBWS can be useful to perform nonstandard RGB-to-grayscale conversions, or to apply the CurvesTransformation and ColorSaturation tools to modify lightness, chrominance and color saturation components with more control. Read the document linked above, where you'll find some examples (very old ones, but still useful to describe the fundamental underlying concepts).

[dld]

Thank you all for your answers, it seems that I have to study more but...

As far as I can understand, a properly integrated, background-corrected and color-calibrated (with PCC) linear image, obtained from properly reduced data should be observer-independent. Assume we want to perform a deconvolution operation on the luminance component of the image. The luminance component shouldn't be observer-independent i.e., obtained without making any assumptions on human vision and color perception?

How does RGBWorkingSpace coefficients enter in such operations during the linear stage? If the default coefficients are obtained from a standardized color perception model, we break the observer independence (because here enters the "average" observer). Is this desirable? Or it is unavoidable by the same definition of the term luminance, and the only way to standardize is to use the default/standardized RGBWorkingSpace settings?

If the above aren't obviously wrong, I'll dare to say that Juan probably has similar philosophical questions

Thank you again, especially Juan, given his limited time available!
dld

[stevek]

Thanks very much folks, I think I get it.

So if you'd captured say RGB on a subject and it was quite strong in Green, say, then if you wanted a synthetic luminance you'd apply RGBWS at 1:1:1 to the RGB image *prior* to extracting the synthetic lum in order to get a balanced - i.e. "colour neutral" luminance that is not Green biased (in that example)?

Does that sum it up?

[pfile]

well... maybe. sometimes it's hard to tell if the excess of green you have is real or is somehow caused by light pollution or just the fact that the green channel is stronger in an OSC because there are 2 green pixels per bayer quad.

i'd start by doing DBE followed by some kind of background neutralization and color calibration. then set the weights to 1 and extract the L, but after that i undo the RGBWS change to the RGB and move from there on each image separately.

rob