Convert to grayscale color management?

[mschuster]

Hi, I have another newbie question. I opened a web jpg of a processed Ha exposure and converted the RGB view to Grayscale. I see a change in image contrast and also a change in the histogram. I expected a black&white jpg would be converted to grayscale without change.

My PI configuration is default, immediately prior to this test I ran "Reset PixInsight Settings". The current ICC profile of the jpg matches the monitor, default RGB and default Grayscale profiles in PI's color management settings.

I played with RGBWorkingSpace settings of the jpg prior to the convert to Gayscale, but I am unable to get want I want: no change in visualization and no change in histogram.

However, the PixelMath expression $target[1] gives me exactly what I want (ie, use the input green channel as the output Grayscale channel).

So this PixelMath is a work around, but I am wondering what PI color management operations can account for this behavior?

Thanks,
Mike

[Juan Conejero]

Hi Mike,

I expected a black&white jpg would be converted to grayscale without change.

If that happens, then the original JPEG file is an RGB image. If may _seem_ grayscale because it has been desaturated, but the image has three channels and is in the RGB color space.

If you convert one of these "monochrome" RGB images to the grayscale color space in PixInsight, the result won't be, in general, equal to the original RGB image. This happens because we apply a transformation in a colorimetric color space. Standard RGB to grayscale conversion consists of computing the L* (lightness) component of the CIE L*a*b* color space from the RGB components. Note that CIE L*a*b* is a nonlinear, perceptual color space, so the result won't be the same as the original green channel, even if the three RGB channels are identical.

Your workaround is correct. You can also extract just one of the channels with the ChannelExtraction process. The problem is that this is a grayscale image that has been incorrectly stored as an RGB image. Many poorly designed imaging applications make this mistake.

[mschuster]

Hi Juan,

Thank you for your reply. I have a follow up observation and question.

After converting my jpg to GrayScale, I applied a sequence of alternating conversions back to RGB Color and then again to Grayscale as a test. I expected idempotence (a sequence of operations applied multiple times without changing the result beyond the initial application) but rather I see a continuous sequence of changes to the image:

(1) Open jpg.
(2) Convert to Grayscale (histogram changed).
(3) Convert to RGB Color (no histogram change).
(4) Convert to Grayscale (histogram changed).
(5) Convert to RGB Color (no histogram change).
(6) Convert to Grayscale (histogram changed).
(7) Convert to RGB Color (no histogram change).
...

On each Convert to Grayscale operation I see an increase in image contrast.

This non-idempotence also occurs when I apply this conversion sequence to a subexposure. For example, I applied this sequence to my master dark (which was created with PI's ImageIntegration process) and found that its mean ADU decreases and its stddev ADU increases as each convert to Grayscale is applied. I find this non-idempotence on an initially monochrome image especially surprising.

Is this non-idempotence expected behavior?

Thanks,
Mike

[Juan Conejero]

Is this non-idempotence expected behavior?

Yes. RGB to grayscale conversion is a nonlinear transformation that will always change the image, even if it is applied to an RGB image whose three channels are identical. However, grayscale to RGB conversion is a no-op: it consists of making three identical copies of the original gray image. These transformations are non-invertible.

I applied this sequence to my master dark

Why? This is incorrect. If your master dark is an RGB image, that's because your raw data are (or should be) also RGB. In general, don't apply _any_ transformation to a master calibration frame, or it will be invalidated as such.

[mschuster]

In general, don't apply _any_ transformation to a master calibration frame, or it will be invalidated as such.

Yes I agree. I did this only as a test on an initially monochrome image generated directly by PI. The master dark was just a handy candidate.