Page 1 of 2
possible bug reporting LAB colors as pixel: values
Posted: 2014-06-30T14:31:21-07:00
by fmw42
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?
Re: possible bug reporting LAB colors as pixel: values
Posted: 2014-06-30T15:01:12-07:00
by snibgo
If there is a bug, I think it is in your first example.
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%)
Correct:
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%)
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%.
Re: possible bug reporting LAB colors as pixel: values
Posted: 2014-06-30T16:14:27-07:00
by fmw42
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.
Re: possible bug reporting LAB colors as pixel: values
Posted: 2014-07-01T03:08:49-07:00
by snibgo
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.
Re: possible bug reporting LAB colors as pixel: values
Posted: 2014-07-01T03:32:06-07:00
by snibgo
EDIT: There is another condition I'd like: the round-trip to and from a "txt:" file should work. Currently, it doesn't. Eg:
Code: Select all
convert -size 100x100 gradient:red-blue -colorspace Lab txt:a.txt
convert a.txt -colorspace sRGB a.png
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 -set colorspace sRGB txt:b.txt
convert b.txt -set colorspace Lab -colorspace sRGB b.png
Re: possible bug reporting LAB colors as pixel: values
Posted: 2014-07-01T05:30:45-07:00
by magick
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
Posted: 2014-07-01T09:08:38-07:00
by fmw42
snibgo wrote:What following post?
Sorry, I forgot to include the link.
viewtopic.php?f=3&t=23923&p=101835&hilit=LAB#p101843
Re: possible bug reporting LAB colors as pixel: values
Posted: 2014-07-01T09:29:02-07:00
by snibgo
Ah, yes, I'd forgotten that thread. The final test I gave wasn't fixed:
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:
The comparison result should be near zero.
Re: possible bug reporting LAB colors as pixel: values
Posted: 2014-07-01T10:05:32-07:00
by fmw42
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.
Re: possible bug reporting LAB colors as pixel: values
Posted: 2014-07-02T14:21:26-07:00
by fmw42
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?
Code: Select all
im6896beta 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
im6896beta convert xc:white -colorspace LAB -format "%[pixel:u.p{0,0}]" info:
cielab(99.9985%,
50.0038%,49.9931%)
Re: possible bug reporting LAB colors as pixel: values
Posted: 2014-07-02T15:17:34-07:00
by magick
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.
Re: possible bug reporting LAB colors as pixel: values
Posted: 2014-07-02T16:01:03-07:00
by fmw42
magick 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.
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: values
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:
convert xc:
white -colorspace LAB
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
Posted: 2014-07-03T06:13:50-07:00
by magick
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
Posted: 2014-07-03T22:20:15-07:00
by jwtrexler
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.
Re: possible bug reporting LAB colors as pixel: values
Posted: 2014-07-04T07:36:20-07:00
by snibgo
What version of IM are you using, and how are you finding the result?
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)
The 16-bit result is correct. The 8-bit result isn't. Perhaps this bug is fixed in the patches mentioned by magick, above.