ColorSaturation Changes Color

[georg.viehoever]

Hi,

I know that color management is a difficult topic. So this may not be a bug, but just a misinterpretation of what should happen.

- According to http://pixinsight.com/forum/index.php?topic=139.0, "ColorSaturation works in a colorimetrically-defined HSVL space, which prevents noise transferences from chrominance to luminance and ensures full preservation of color balance."
- The experiment I did in http://pixinsight.com/forum/index.php?topic=1689.msg10371#msg10371 (Last Row) uses RGBs values with low saturation, but constant hue. So I expected that a ColorSaturation boost would give me constant and more saturated colors. That is not the case, as can be seen in the bottom right picture.
- I also could not find information on the internet about the HSVL space that PI is using.

So the question is: Does ColorSaturation work as designed? What should be done to avoid the color fluctuations observed?

Cheers,

Georg

[Carlos Milovic]

Hi George

IMO what happened there is that the HSVL model generated pixel values that were out of the RGB range, so, when it had to be truncated, it generated a hue change.

To clarify this a little further. HSVL has a bigger data range than RGB, so there may be situations where a modification in that color space model yields out of range values for the RGB data. The same could happen with Curves and other processes. In fact, I've seen worse results from the same reason

[Niall Saunders]

Hi Georg, Carlos

Are we saying that the "HSVL" space is different from the "HSV" space or the "HSI" space?

I have always taken PI to be capable of working in the six colour spaces presented in the ColourExtraction / ColourCombination processes. If "HSVL" is, indeed, 'another' colour space available within PixInsight, then I would have automatically assumed that Juan would have made its individual components available to the user.

Am I missing something?

Cheers,

[georg.viehoever]

Hi Niall,

if HSVL=HSV, then there would be no possibility of exceeding the RGB color space. So HSVL must be something different. Unfortunately, I did not find it in Google...

Georg

[Carlos Milovic]

In this case, it is the same. In the ColorSaturation process the H and S values are calculated from the RGB ones, and then only the S value is changed. After that, we use the H and new S to get the new RGB (can't remember if we calculate the L or V too, or it is done internally by the PCL... I'll check the code later). Anyway, HSV has a bigger range than RGB, so that is the root of the problem.

[Niall Saunders]

Thanks for that information Carlos.

Georg,

What Carlos has said makes sense if you read the following
http://en.wikipedia.org/wiki/HSL_and_HSV

It makes even more sense if, unlike me, you can actually understand all of it 

Cheers,

[georg.viehoever]

Carlos, Niall,

I must admit,  I still don't get it.

- in my understanding, there is no way that pushing the S-value (as long as you stay between 0..1) will cause RGB to go out of range, even after re-reading Wikipedia.

- to verify, I made another of my infamous experiments (attached):
-- I created a color bar with constant constant saturation at 0.1 (using the script from previous posts)
-- First line: I treated it with Color Satuaration tool, pushing it by a factor of 2.8. The result is on the top right. Again, pink and yellow are very weak, and there seems to be quite a lot of variation in the color tones.
-- Second line: I treated the same image to an HSV ChannelExtraction, pushed the S image by a factor of 2.8, and recombined them. The result is on the bottom right. If you ask me, this is a more "trueful" representation of the color bar.

Where is the mistake in my thinking?

Georg

[Carlos Milovic]

Hi Georg

- There are some combinations of HSV that yields out of range values, even if all of them stay in the normalized range. It just a problem of the geometry of the color space (cilindrical). Cannot be avoided.

Even so, it doesn't seem to be the case in your example, at first sight.
I examined your test image, and found that S and V channels are almost the same for both results (in terms of homogeinity). The difference is on the luminance, V, or whatever channel you use to represent lightness. I'll check the source code of ColorSaturation to see how is handled the color recomposition. I guess that the algorithm is different from ChannelCombination.
Anyway, the variations of the lightness component seems to depend on the actual channel that we are seeing. In the I channel (intensity), ColorSaturation's looks less even, but it is more uniform at the CIE L. Again, it seems just a difference in the space model recombination. It does not look like a bug.

[Carlos Milovic]

Just checked the code. We are using HSVL in ColorSaturation.

BTW, please note that the saturation boost is quite similar to a scalar multiplication (but the factor is not the same), so there is no "prior" assurance that the S value will be in the 0-1 range. Out of range values are truncated (i.e. S=1 if S>1), and then the RGB combination is done. A 2.8 factor is like a 3.8 multiplication (for that particular hue).

So, returning to the issue here. When using the HSVL "space", what in fact is happening is that a HSV to RGB recomposition is done, and then the original luminance is incorporated again, thus, preserving that channel information. This is the reason for the changes you see.

[georg.viehoever]

Carlos,

I think  understand now. You use S to boost the saturation, but instead of using V in the recombination, you somehow mix in the Luminance. I am not sure if this is the best idea, since apparently (at least in my experiments) it changes the perceived color, which is just what -in my opinion- should not happen in the ColorSaturation process. Just using the original V seems to be the better choice in the cases that I tested. Maybe it be a good idea to add a "V-transform" mode to ColorSaturation?!?

Thanks for the explanation!

Georg

[Carlos Milovic]

Or just a "preserve luminance" checkbox. It is easy to add this.
Juan, do you do this, or do I send the code to you?

[georg.viehoever]

Or just a "preserve luminance" checkbox. It is easy to add this.

Seems to be a good idea ...  

Georg

[Niall Saunders]

Hi Georg, Carlos,

Here is a 'thought experiment' for you :-

Take a simple image - one of your 'synthetic' images will do Georg
MAKE SURE THAT YOU ARE WORKING IN A 1:1:1 colour working space for this image

Extract H, S, L, and V sub-images
Apply the ColourSaturaturation process, or use a SaturationCurve in 'Curves' to the original RGB image
Extract a second set of H, S, L and V sub-images
'Subtract' or 'Divide' the like-for-like images

To me, if the 'mainstream' processes are 'valid' then the ONLY differences that should be noticed should be in the two 'S' sub-images.

Is that what is observed?

Cheers,

[Carlos Milovic]

Hi Niall

This will not be the case. There will be changes in L or V (depending on wich process you are using), becouse H-S-L-V are not orthogonal vectors