[solved] Lab: "a" &" b" leaking into L in RGB round-trip?

[henrywho]

Found something strange....

Code: Select all

convert.exe -respect-parentheses \
 rose: -set colorspace sRGB -colorspace LAB \
 -channel R -separate placebo_%d.png

Code: Select all

convert.exe -respect-parentheses \
 rose: -set colorspace sRGB -colorspace LAB \
 -channel G -sigmoidal-contrast 9,50% \
 -channel B -sigmoidal-contrast 9,50% \
 -channel R -separate case1_%d.png

Code: Select all

convert.exe -respect-parentheses \
 rose: -set colorspace sRGB -colorspace LAB \
 -channel G -sigmoidal-contrast 9,50% \
 -channel B -sigmoidal-contrast 9,50% \
 +channel \
 -colorspace RGB -colorspace LAB -channel R -separate case2_%d.png

case1_0.png looks the same as placebo_0.png but case2_0.png (which runs through a LAB-RGB-LAB trip) looks rather different.

Is it by design?

(both "6.8.3-5 2013-02-24 Q16 Win32 Static" and "6.8.4-1 2013-03-25 Q16 Win64 Static" tried)

[snibgo]

It doesn't seem strange to me.

The "-sigmoidal-contrast" has fully saturated the red of the rose. While it is in LAB space, the tones are unchanged; only the a and b channels are changed.

When you convert the pixels to RGB (or sRGB; the effect is the same), all the fully-saturated red tones become the same colour: rgb(255,0,0). You can see this by inserting "-write x.png" after "-colorspace RGB". Convert that back to LAB, and these become the same grey tone.

In general, with integer arithmetic, there isn't a 1:1 mapping between colorspaces. There will be times when two or more pixels that are different in one space map to the same colour in the other.

[henrywho]

I thought A and B control the "hue" and "saturation" only... having no effect on luminance.

[snibgo]

That is correct. (Except that they are called a and b, not A and B.)

[snibgo]

Put it another way: your second command (case1) gives the same channel L as your first (placebo). This shows that changing a and b (in this case, increasing saturation) has no effect on L.

What is different in your third command (case2)? You convert to RGB, then back again to Lab. That is the only difference to the second command, so logically this is where the tones are being changed. If you change "-colorspace RGB" to "-colorspace RGB -write x.png", and look at x.png, you can see what has happened.

[henrywho]

That is correct. (Except that they are called a and b, not A and B.)

And I thought "fully saturated" have different implications in "Lab" and "RGB".

Under "Lab", no matter how we manipulate "a" and "b", "L" should not be affected.
Even if it is converted to 8-bit RGB and got rounded or truncated, it should not change the overall "brightness".

[snibgo]

Under "Lab", no matter how we manipulate "a" and "b", "L" should not be affected.

Correct. It shouldn't and, as far as I know, it isn't.

Even if it is converted to 8-bit RGB and got rounded or truncated, it should not change the overall "brightness".

No. Lab can represent colours that RGB cannot, such as different tones of fully-saturated red. When you convert these colours to RGB, you have to lose something -- either the full saturation or the tones.

[henrywho]

Even if it is converted to 8-bit RGB and got rounded or truncated, it should not change the overall "brightness".

No. Lab can represent colours that RGB cannot, such as different tones of fully-saturated red. When you convert these colours to RGB, you have to lose something -- either the full saturation or the tones.[/quote]

Yes, I have to lose something, but that should be rounding, truncation or limiting. NOT overflowing to overall brightness

[henrywho]

Yes, I have to lose something, but that should be rounding, truncation or limiting. NOT overflowing to overall brightness

Just checked the formulae .... such "leaking" is built-in .... period .....

[snibgo]

... but that should be rounding, truncation ...

Yes, that's another way of putting it. See my first reply: "In general, with integer arithmetic, there isn't a 1:1 mapping between colorspaces."

Try non-integer arithmetic, ie IM with HDRI. Your three commands then give identical results.

[henrywho]

Try non-integer arithmetic, ie IM with HDRI. Your three commands then give identical results.

I dun know that limiting would appear in this manner

I have an old 6.7.6 HDRI compile only. Do you know where we can find an updated windows HDRI compile?

[snibgo]

Using integer arithmetic, what is eleven divided by ten, multiplied by ten? Ten.

What is nineteen divided by ten, multiplied by ten? Also ten.

Two different numbers have both done the round trip, yielding the same result. That is what you are seeing. You could say the tones have shifted, but that is because a load of different colours (in Lab space) map to one colour (in RGB space), so the return trip to Lab space also creates just one colour.

A updated Windows HDRI version of IM: http://www.imagemagick.org/download/alp ... 64-dll.exe

Be aware that this is IM v7.