Author Topic: RGB working space  (Read 8225 times)

Offline mmirot

  • PixInsight Padawan
  • ****
  • Posts: 881
RGB working space
« on: 2009 November 18 07:49:23 »
I have played around with applying a different RGB working space to the image. Changing the gamma or color weights does not seem to change the apperience of the image. Should it ? ???

Max

Offline Nocturnal

  • PixInsight Jedi Council Member
  • *******
  • Posts: 2727
    • http://www.carpephoton.com
Re: RGB working space
« Reply #1 on: 2009 November 18 10:05:32 »
Actually I'd like to understand this better as well. If I simply pop in an RGB image why do I need to change my RGB working space at all?
Best,

    Sander
---
Edge HD 1100
QHY-8 for imaging, IMG0H mono for guiding, video cameras for occulations
ASI224, QHY5L-IIc
HyperStar3
WO-M110ED+FR-III/TRF-2008
Takahashi EM-400
PIxInsight, DeepSkyStacker, PHD, Nebulosity

Offline twade

  • PTeam Member
  • PixInsight Old Hand
  • ****
  • Posts: 445
    • http://www.northwest-landscapes.com
Re: RGB working space
« Reply #2 on: 2009 November 18 10:50:12 »
Sander and Max,

I think it has more to do when you want to extract/create a luminance channel (e.g. localized sharpening) from a RGB image.  Basically, in a RGB image, green has the highest ratio.  As most of our targets are red, it generally is a good idea to give more emphasis to the red channel when deriving the luminance channel.  I've been known to go as far as 3:1:1 when imaging the area around Cygnus.  I'm no expert so hopefully a more knowledgeable person will chime in.

Wade

Offline Juan Conejero

  • PTeam Member
  • PixInsight Jedi Grand Master
  • ********
  • Posts: 7111
    • http://pixinsight.com/
Re: RGB working space
« Reply #3 on: 2009 November 18 11:18:04 »
Quote
it has more to do when you want to extract/create a luminance channel

Exactly. RGB working spaces define the "rules" to perform luminance/chrominance separations in PixInsight.

This is part of the old PixInsight LE documentation:

http://pixinsight.com/doc/LE/14_color_spaces/color_spaces.html

(please be indulgent with my English in these documents; I wrote them in 2004)

Hope this helps!
Juan Conejero
PixInsight Development Team
http://pixinsight.com/

Offline Niall Saunders

  • PTeam Member
  • PixInsight Jedi Knight
  • *****
  • Posts: 1456
  • We have cookies? Where ?
Re: RGB working space
« Reply #4 on: 2009 November 18 15:11:36 »
So,

Is it fair to say that 'RGB Working Space' only really becomes a significant issue if you are trying to EXTRACT something like a Lum channel from an RGB image?

It presumably has little to offer if COMBINING individual channels to 'form' a colour image?

If I am correct, then there must be an issue whenever you are using some form of 'transient' or 'interim' Luminance extraction in another PI process (StarMask, ACDNR, HDRW all spring to mind). Am I right?

What is the 'simple' (one-liner) recommendation for setting the workspace. Juan, I know that your implementation is to be commended for offering just about every manner under the sun for implementing this process, but - surely - there must be an 'entry-level' setting that we 'should' be using, until such time as we (individually) learn enough to tweak settings further?

Cheers,
Cheers,
Niall Saunders
Clinterty Observatories
Aberdeen, UK

Altair Astro GSO 10" f/8 Ritchey Chrétien CF OTA on EQ8 mount with homebrew 3D Balance and Pier
Moonfish ED80 APO & Celestron Omni XLT 120
QHY10 CCD & QHY5L-II Colour
9mm TS-OAG and Meade DSI-IIC

Offline Nocturnal

  • PixInsight Jedi Council Member
  • *******
  • Posts: 2727
    • http://www.carpephoton.com
Re: RGB working space
« Reply #5 on: 2009 November 18 17:43:38 »
I always use default RGB working spaces and that seems to work fine. Thanks for picking good defaults Juan! :)
Best,

    Sander
---
Edge HD 1100
QHY-8 for imaging, IMG0H mono for guiding, video cameras for occulations
ASI224, QHY5L-IIc
HyperStar3
WO-M110ED+FR-III/TRF-2008
Takahashi EM-400
PIxInsight, DeepSkyStacker, PHD, Nebulosity

Offline mmirot

  • PixInsight Padawan
  • ****
  • Posts: 881
Re: RGB working space
« Reply #6 on: 2009 November 18 18:29:04 »
I thought the default is space sRGB?
 This would be is bad for most since luminance is from green.
 How do set the default working space to something generally more appropriate for astro images?

Max

Offline Nocturnal

  • PixInsight Jedi Council Member
  • *******
  • Posts: 2727
    • http://www.carpephoton.com
Re: RGB working space
« Reply #7 on: 2009 November 18 18:36:56 »
sRGB is an ICC Color Profile. Not the same thing. From the page Juan linked to "Note that the concept of RGBWS has nothing to do in PixInsight with color management or ICC profiles."
Best,

    Sander
---
Edge HD 1100
QHY-8 for imaging, IMG0H mono for guiding, video cameras for occulations
ASI224, QHY5L-IIc
HyperStar3
WO-M110ED+FR-III/TRF-2008
Takahashi EM-400
PIxInsight, DeepSkyStacker, PHD, Nebulosity

Offline mmirot

  • PixInsight Padawan
  • ****
  • Posts: 881
Re: RGB working space
« Reply #8 on: 2009 November 18 18:47:43 »
Sure

I understand this Sander.
But what is the default RGBWS really ?
I would assume it is some standard either sRGB or weight of 1:1:1.
Can we set the default prior to using the global RGBWS process?


Max

Offline mmirot

  • PixInsight Padawan
  • ****
  • Posts: 881
Re: RGB working space
« Reply #9 on: 2009 November 18 19:05:36 »
The sRGB lum coeff are loaded when you first start RGBWs. So I would assume this is the default.

Max

Offline Juan Conejero

  • PTeam Member
  • PixInsight Jedi Grand Master
  • ********
  • Posts: 7111
    • http://pixinsight.com/
Re: RGB working space
« Reply #10 on: 2009 November 19 04:47:14 »
The default RGBWS is sRGB. It has been set as default to keep PixInsight compatible with the rest of imaging applications. If I had chosen a uniform RGBWS (1:1:1) as default, Google would be plenty of things like "guys, never use PixInsight to convert your images into grayscale", or "PI is a poor performer for daylight images", etc. PI's scope is broad ad as such I sometimes have to make a choice that is suboptimal for astronomy but reasonable as a "mean" for the largest possible set of scenarios. The default sRGB RGBWS is clearly one of those cases.

Quote
Thanks for picking good defaults Juan!

Thanks Sander but I'm affraid I don't deserve that in this occasion (it's nice to hear, though :angel:). The sRGB space isn't a good option for deep-sky images, basically due to its strongly green-biased luminance that mimics the human eye's chromatic response. This doesn't mean that you can't get good results using it, of course, but optimal choices are always preferable.

In general, a reasonable choice is what we call a uniform RGBWS. In a uniform RGBWS, all luminance weights are equal, so no particular color is given more importance. The RGBWorkingSpace tool allows you to specify three ones as the weights for red, green and blue; it rescales them internally to yield a unit vector (if the three weights are mutually equal, they are rescaled to 1/3).

Another good option can be 1:0.25:1, or something similar to decrease the relative weight of green, for deep-sky images where green transports little information. It depends on how you acquire your images. For one-shot color images (DSLR, OSCCD), I'd use a uniform RGBWS because these images have been acquired through broadband filters with extended superposition, that is, adjacent pairs of filters share a region of the spectrum.

Another thing to consider is linearity of the transformations performed in a RGBWS. We talk of a linear RGBWS when it has a gamma value of one. If we are going to perform luminance/chrominance separations on linear images (for deconvolution, for example), then the resulting luminance and chrominance components must also be linear. The CIE XYZ components are calculated as follows:



where M is the RGB-to-CIEXYZ conversion matrix. X and Z are the components of the linear chrominance, and Y is the linear luminance.

In the formula above, note that chrominance and luminance are linear functions of the coefficients Mij, but X, Y and Z can be nonlinear functions of the RGB components. To ensure that XYZ components are linear combinations of RGB, gamma must be equal to one. In this way, we can perform luminance/chrominance separations of linear RGB data where the resulting luminance and chrominance are also linear functions of incident light. This is what the "Linear" checkbox does in Deconvolution, for example: separate luminance and chrominance in the CIE XYZ space instead of CIE L*c*h*, and assume that the user knows what she is doing.
Juan Conejero
PixInsight Development Team
http://pixinsight.com/

Offline Niall Saunders

  • PTeam Member
  • PixInsight Jedi Knight
  • *****
  • Posts: 1456
  • We have cookies? Where ?
Re: RGB working space
« Reply #11 on: 2009 November 19 06:06:21 »
Hi Juan,

Thanks for taking the time to explain, in 'relatively simple' terms, how you approached the concept of 'RGB Working Space'. Again, this is the 'power' of PI - where what initially appears to be a a 'casual' question actually triggers a meaningful debate and discussion, so often leading to a better understanding of what PI is actually doing at a 'nuts and bolts' level.

OK - we may not understand ALL of the details, but even a 'novice' should be able to extract the 'bare bones' of the answer, or to at least feel confident to ask what 'minimum' information needs to be extracted from an otherwise detailed answer.

So, as a novice, I take it that 'default sRGB' values are NOT ideal, because they actually DO have a 'weighting factor' biased towards a certain Hue?

Instead, we would be better to set the RGBWS balance to 1:1:1 (especially for OSCCD and DSLR cameras) unless we have the skills to establish (probably empirically) an alternative set of RGBWS parameters.

If we want to try and understand what the effects of modifying the RGBWS parameters, then we could take a 'good' RGB image from the 'Net and extract the Luminance channel, using the 'default' sRGB parameters, and then repeat for 1:1:1, and maybe even 1:0.25:1 (which would give less emphasis to the green channel).

The resulting three Luminance channels should be noticeably different.

For an extreme example, you could set the G and B multipliers to something extremely small, say 0.01 each - and the extracted Luminance - if I now understand things more clearly - should then end up 'very similar' to an extracted Red channel from the same image.

Hmmm, I sense a quick Video Tutorial - Harry, are you there ?  ::)

Cheers,
Cheers,
Niall Saunders
Clinterty Observatories
Aberdeen, UK

Altair Astro GSO 10" f/8 Ritchey Chrétien CF OTA on EQ8 mount with homebrew 3D Balance and Pier
Moonfish ED80 APO & Celestron Omni XLT 120
QHY10 CCD & QHY5L-II Colour
9mm TS-OAG and Meade DSI-IIC

Offline mmirot

  • PixInsight Padawan
  • ****
  • Posts: 881
Re: RGB working space
« Reply #12 on: 2009 November 19 07:30:38 »


If we want to try and understand what the effects of modifying the RGBWS parameters, then we could take a 'good' RGB image from the 'Net and extract the Luminance channel, using the 'default' sRGB parameters, and then repeat for 1:1:1, and maybe even 1:0.25:1 (which would give less emphasis to the green channel).

The resulting three Luminance channels should be noticeably different.

For an extreme example, you could set the G and B multipliers to something extremely small, say 0.01 each - and the extracted Luminance - if I now understand things more clearly - should then end up 'very similar' to an extracted Red channel from the same image.

Hmmm, I sense a quick Video Tutorial - Harry, are you there ?  ::)

Cheers,

I did this last night. It shows how this works very nicely the effects of RGBWs if work on a HA dominated RGB image.

Ideally you need to set Coeff. for each type of image.
Remember, a narrow band hubble palate image would have a lot of Green data from HA mapping into green.

Max

Offline Juan Conejero

  • PTeam Member
  • PixInsight Jedi Grand Master
  • ********
  • Posts: 7111
    • http://pixinsight.com/
Re: RGB working space
« Reply #13 on: 2009 November 19 08:37:35 »
Quote
For an extreme example, you could set the G and B multipliers to something extremely small, say 0.01 each - and the extracted Luminance - if I now understand things more clearly - should then end up 'very similar' to an extracted Red channel from the same image.

Correct. Although luminance weights cannot be zero, you can set two of them to the minimum allowed value of 0.000001 in RGBWorkingSpace, and the other weight to 1. If you also set gamma=1, then the Y component (after applying the RGBWS to the image) will be virtually identical to the remaining channel (the channel whose weight is 1). Note also that in this case the three CIE XYZ components are virtually identical, which is coherent with a "perfect" separation (to numerical representation limits) between luminance and chrominance. In other words, if you set two luminance weights to ~0 and gamma=1, the results are fully consistent with a grayscale image whose pixels come exclusively from the channel with unit weight. Nice, isn't it :)
Juan Conejero
PixInsight Development Team
http://pixinsight.com/