possible bug reporting LAB colors as pixel: values
- fmw42
- Posts: 25562
- Joined: 2007-07-02T17:14:51-07:00
- Authentication code: 1152
- Location: Sunnyvale, California, USA
possible bug reporting LAB colors as pixel: values
This give values that correspond to Bruce Lindbloom calculator for RGB=white (LAB=100,0,0)
convert xc:white -colorspace LAB txt:
# ImageMagick pixel enumeration: 1,1,65535,cielab
0,0: (99.9985%,0.0030518%,-0.00762951%) #FFFE00020000 cielab(99.9985%,0.0030518%,-0.00762951%)
which is within computation accuracy of 100%,0%,0% as expected.
But using pixel: to report the values, gives the 50% biased values.
convert xc:white -colorspace LAB -set colorspace LAB -format "%[pixel:u.p{0,0}]" info:
cielab(99.9985%,50.0038%,49.9931%)
Similarly with fx:
convert xc:white -colorspace LAB -set colorspace LAB -format "%[fx:u.r] %[fx:u.g] %[fx:u.b]" info:
0.999985 0.500038 0.499931
Is this what is to be expected expected or a bug?
convert xc:white -colorspace LAB txt:
# ImageMagick pixel enumeration: 1,1,65535,cielab
0,0: (99.9985%,0.0030518%,-0.00762951%) #FFFE00020000 cielab(99.9985%,0.0030518%,-0.00762951%)
which is within computation accuracy of 100%,0%,0% as expected.
But using pixel: to report the values, gives the 50% biased values.
convert xc:white -colorspace LAB -set colorspace LAB -format "%[pixel:u.p{0,0}]" info:
cielab(99.9985%,50.0038%,49.9931%)
Similarly with fx:
convert xc:white -colorspace LAB -set colorspace LAB -format "%[fx:u.r] %[fx:u.g] %[fx:u.b]" info:
0.999985 0.500038 0.499931
Is this what is to be expected expected or a bug?
-
- Posts: 12159
- Joined: 2010-01-23T23:01:33-07:00
- Authentication code: 1151
- Location: England, UK
Re: possible bug reporting LAB colors as pixel: values
If there is a bug, I think it is in your first example.
Incorrect:
Correct:
I suspect the incorrect version harks back to the time when IM considered 0% to be the "central value" of the a* and b* channels. Current IM considers the central value to be 50%.
Incorrect:
Code: Select all
convert xc:white -colorspace LAB txt:
# ImageMagick pixel enumeration: 1,1,65535,cielab
0,0: (99.9985%,0.0030518%,-0.00762951%) #FFFE00020000 cielab(99.9985%,0.0030518%,-0.00762951%)
Code: Select all
convert xc:white -colorspace LAB -set colorspace sRGB txt:
# ImageMagick pixel enumeration: 1,1,65535,srgb
0,0: (99.9985%,50.0038%,49.9931%) #FFFE80027FFB srgb(99.9985%,50.0038%,49.9931%)
snibgo's IM pages: im.snibgo.com
- fmw42
- Posts: 25562
- Joined: 2007-07-02T17:14:51-07:00
- Authentication code: 1152
- Location: Sunnyvale, California, USA
Re: possible bug reporting LAB colors as pixel: values
snibgo
Did you not write the following post, which shows cielab values with negative values? You were complaining about the hex values, but the cielab values coming from txt: have negative values.
I had assumed that txt: was outputting proper cielab values without the bias.
Did you not write the following post, which shows cielab values with negative values? You were complaining about the hex values, but the cielab values coming from txt: have negative values.
I had assumed that txt: was outputting proper cielab values without the bias.
-
- Posts: 12159
- Joined: 2010-01-23T23:01:33-07:00
- Authentication code: 1151
- Location: England, UK
Re: possible bug reporting LAB colors as pixel: values
What following post?
I think txt:, pixel: and fx: should return the same values as each other. And I think those values should be whatever is actually stored in the pixels. This ensures that operations like "-evaluate add 50%" work predictably.
If one or more returns are not what is stored in pixels, this needs to be documented.
I don't know how HDRI IM stores Lab. Perhaps the a* and b* channels are stored with the central value as zero. If so, then HDRI txt: will return different values to integer IM.
I think txt:, pixel: and fx: should return the same values as each other. And I think those values should be whatever is actually stored in the pixels. This ensures that operations like "-evaluate add 50%" work predictably.
If one or more returns are not what is stored in pixels, this needs to be documented.
I don't know how HDRI IM stores Lab. Perhaps the a* and b* channels are stored with the central value as zero. If so, then HDRI txt: will return different values to integer IM.
snibgo's IM pages: im.snibgo.com
-
- Posts: 12159
- Joined: 2010-01-23T23:01:33-07:00
- Authentication code: 1151
- Location: England, UK
Re: possible bug reporting LAB colors as pixel: values
EDIT: There is another condition I'd like: the round-trip to and from a "txt:" file should work. Currently, it doesn't. Eg:
The result, a.png, is wrong. "-colorspace sRGB" in the second command shouldn't make any difference, and doesn't.
EDIT2: For completeness, here is a workaround to make the round-trip work:
Code: Select all
convert -size 100x100 gradient:red-blue -colorspace Lab txt:a.txt
convert a.txt -colorspace sRGB a.png
EDIT2: For completeness, here is a workaround to make the round-trip work:
Code: Select all
convert -size 100x100 gradient:red-blue -colorspace Lab -set colorspace sRGB txt:b.txt
convert b.txt -set colorspace Lab -colorspace sRGB b.png
snibgo's IM pages: im.snibgo.com
Re: possible bug reporting LAB colors as pixel: values
We can reproduce the problem you posted and have a patch in ImageMagick 6.8.9-6 Beta available by sometime tomorrow. Thanks.
- fmw42
- Posts: 25562
- Joined: 2007-07-02T17:14:51-07:00
- Authentication code: 1152
- Location: Sunnyvale, California, USA
Re: possible bug reporting LAB colors as pixel: values
snibgo wrote:What following post?
Sorry, I forgot to include the link.
viewtopic.php?f=3&t=23923&p=101835&hilit=LAB#p101843
-
- Posts: 12159
- Joined: 2010-01-23T23:01:33-07:00
- Authentication code: 1151
- Location: England, UK
Re: possible bug reporting LAB colors as pixel: values
Ah, yes, I'd forgotten that thread. The final test I gave wasn't fixed:
The comparison result should be near zero.
Code: Select all
"%I%convert" ^
-size 1x10 ^
gradient:rgb(0%%,100%%,100%%)-rgb(100%%,100%%,0%%) ^
-write rgb0.png ^
-colorspace %COLSP% ^
-write txt:lab_text.txt ^
+delete ^
lab_text.txt ^
-set colorspace Lab ^
-colorspace sRGB ^
rgb1.png
"%I%compare" -metric RMSE rgb0.png rgb1.png NULL:
snibgo's IM pages: im.snibgo.com
- fmw42
- Posts: 25562
- Joined: 2007-07-02T17:14:51-07:00
- Authentication code: 1152
- Location: Sunnyvale, California, USA
Re: possible bug reporting LAB colors as pixel: values
My point there was that the txt values that were reported were relative to A and B centered at 0.
The question is which way should txt:, fx: and pixel: report the values and should they be consistent or should one properly report the zero-biased LAB values rather than the 50% biased ones.
The question is which way should txt:, fx: and pixel: report the values and should they be consistent or should one properly report the zero-biased LAB values rather than the 50% biased ones.
- fmw42
- Posts: 25562
- Joined: 2007-07-02T17:14:51-07:00
- Authentication code: 1152
- Location: Sunnyvale, California, USA
Re: possible bug reporting LAB colors as pixel: values
Testing with IM 6.8.9.6 beta Mac OSX, I am still getting different cielab values. The txt: format is zero-biased and the pixel: and fx: format is 50% biased.
Is this the way it is intended or should they all be 50% biased?
# ImageMagick pixel enumeration: 1,1,65535,cielab
0,0: (99.9985%,0.0030518%,-0.00762951%) #FFFE00020000 cielab(99.9985%,0.0030518%,-0.00762951%)
cielab(99.9985%,50.0038%,49.9931%)
Is this the way it is intended or should they all be 50% biased?
Code: Select all
im6896beta convert xc:white -colorspace LAB txt:
0,0: (99.9985%,0.0030518%,-0.00762951%) #FFFE00020000 cielab(99.9985%,0.0030518%,-0.00762951%)
Code: Select all
im6896beta convert xc:white -colorspace LAB -format "%[pixel:u.p{0,0}]" info:
Re: possible bug reporting LAB colors as pixel: values
Both outputs are correct. Internally its 50% bias so it fits in the quantum range. Externally the bias is removed since its not needed and presents the actual Lab color values to the consumer.
- fmw42
- Posts: 25562
- Joined: 2007-07-02T17:14:51-07:00
- Authentication code: 1152
- Location: Sunnyvale, California, USA
Re: possible bug reporting LAB colors as pixel: values
I think that will cause confusion if they are not consistent or alternately if it is not explained well on the http://www.imagemagick.org/script/color.php page, since, I do not get the correct conversions to sRGB by using the txt: valuesmagick wrote:Both outputs are correct. Internally its 50% bias so it fits in the quantum range. Externally the bias is removed since its not needed and presents the actual Lab color values to the consumer.
This works using 50% biased values from pixel:
im6896beta convert xc:white -colorspace LAB -set colorspace LAB -format "%[pixel:u.p{0,0}]" info:
cielab(99.9985%,50.0038%,49.9931%)
convert xc:"cielab(99.9985%,50.0038%,49.9931%)" -colorspace sRGB txt:[/code]
0,0: (100%,100%,100%) #FFFFFFFFFFFF white
Code: Select all
But this does not work using 0 biased values from txt:
0,0: (99.9985%,0.0030518%,-0.00762951%) #FFFE00020000 cielab(99.9985%,0.0030518%,-0.00762951%)
convert xc:"cielab(99.9985%,0.0030518%,-0.00762951%)" -colorspace sRGB txt:
0,0: (0%,100%,100%) #0000FFFFFFFF cyan
Re: possible bug reporting LAB colors as pixel: values
We can reproduce the problem you posted and have a patch in ImageMagick 6.8.9-6 Beta, available by sometime tomorrow. Thanks.
Re: possible bug reporting LAB colors as pixel: values
I am converting a green image (100 by 100 pixels) in jpeg format having RGB values of 0,255,0 using the command "-colorspace lab" to preform the conversion from RGB to Cielab colorspace. The result calculated by ImageMagick is 224,0,82 for L*, a* and b* respectively; the second value of 0 should be -86. I checked the ImageMagick calculated Cielab values for both blue (RGB: 0,0,255) and red (255,0,0) and found the IM calculated value to be correct.
-
- Posts: 12159
- Joined: 2010-01-23T23:01:33-07:00
- Authentication code: 1151
- Location: England, UK
Re: possible bug reporting LAB colors as pixel: values
What version of IM are you using, and how are you finding the result?
With IM 6.8.9-0, I get:
The 16-bit result is correct. The 8-bit result isn't. Perhaps this bug is fixed in the patches mentioned by magick, above.
With IM 6.8.9-0, I get:
Code: Select all
F:\web\im>%IM%convert xc:Lime -colorspace Lab txt:
# ImageMagick pixel enumeration: 1,1,65535,cielab
0,0: (87.7363%,-33.7972%,32.6192%) #E09A00005381 cielab(87.7363%,-33.7972%,32.
6192%)
F:\web\im>%IM%convert xc:Lime -colorspace Lab -depth 8 txt:
# ImageMagick pixel enumeration: 1,1,255,cielab
0,0: (224,0,83) #E00053 cielab(224,0,83)
snibgo's IM pages: im.snibgo.com