Page 1 of 1
[solved] Lab: "a" &" b" leaking into L in RGB round-trip?
Posted: 2013-03-29T15:30:15-07:00
by 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)
Re: LAB: A&B channels leaking into L?
Posted: 2013-03-29T16:52:38-07:00
by 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.
Re: LAB: A&B channels leaking into L?
Posted: 2013-03-29T20:10:33-07:00
by henrywho
I thought A and B control the "hue" and "saturation" only... having no effect on luminance.
Re: LAB: A&B channels leaking into L?
Posted: 2013-03-29T20:29:56-07:00
by snibgo
That is correct. (Except that they are called a and b, not A and B.)
Re: Lab: "a" &" b" channels leaking into L?
Posted: 2013-03-29T22:06:39-07:00
by 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.
Re: LAB: A&B channels leaking into L?
Posted: 2013-03-29T22:07:44-07:00
by henrywho
snibgo wrote: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".
Re: Lab: "a" &" b" channels leaking into L in RGB round-trip
Posted: 2013-03-29T23:09:18-07:00
by snibgo
henrywho wrote: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.
henrywho wrote: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.
Re: Lab: "a" &" b" channels leaking into L in RGB round-trip
Posted: 2013-03-29T23:47:49-07:00
by henrywho
henrywho wrote: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
Re: Lab: "a" &" b" channels leaking into L in RGB round-trip
Posted: 2013-03-29T23:58:37-07:00
by henrywho
henrywho wrote: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 .....
Re: Lab: "a" &" b" channels leaking into L in RGB round-trip
Posted: 2013-03-30T00:31:51-07:00
by snibgo
henrywho wrote:... 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.
Re: Lab: "a" &" b" channels leaking into L in RGB round-trip
Posted: 2013-03-30T00:43:26-07:00
by henrywho
snibgo wrote: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?
Re: [solved] Lab: "a" &" b" leaking into L in RGB round-trip
Posted: 2013-03-30T00:56:14-07:00
by 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.