Page 1 of 1
Lab color behaves incorrectly
Posted: 2016-04-11T10:53:55-07:00
by tom_dl
Code: Select all
Version: ImageMagick 6.9.3-7 Q16 x64 2016-04-11
I am convinced ImageMagick's text output of Lab is wrong. I've tried this in Q8, Q16 and Q32 versions, without HDRI:
Code: Select all
convert -size 1x1 xc:"cielab(L,a,b)" output.txt
where L,a,b are any 3 numbers.
- If entered as % L is clipped at 0% and 100% - AS EXPECTED
- If entered as % a and b are clipped at 0% and 50% (i.e. all minus values are clipped to 0%) - NOT EXPECTED
- If entered as a number, L is clipped at 0 and quantum depth - AS EXPECTED
- If entered as a number, a and b are clipped at 0 and half of quantum depth (i.e. all minus values are clipped to 0) - NOT EXPECTED
If minus a&b values are entered and the file is saved with as an image (e.g. .tif) Photoshop etc. read the negative values for a&b, so Imagemagick is not actually clipping the negative values, they are just reported as clipped in the txt output. I understand the workaround is to enable HDRI, but Imagemagick should surely either actually clip negatives to 0 or report them as negative? A strange range of 0%-50% for a & b is just confusing.
With HDRI enabled, the outputs are all as expected.
Re: Lab color behaves incorrectly
Posted: 2016-04-11T11:37:25-07:00
by snibgo
IM has always been a little inconsistent about how it inputs and outputs a* and b*, but it seems okay for this in v6.9.2-5 on Windows 8.1. For example:
Code: Select all
f:\web\im>%IM%convert xc:cielab(4%,-40%,-10%) txt:
# ImageMagick pixel enumeration: 1,1,65535,cielab
0,0: (2621,-26214,-6553) #0A3D00000000 cielab(3.99939%,-40%,-9.99924%)
f:\web\im>%IM%convert xc:cielab(10,-100,-25) txt:
# ImageMagick pixel enumeration: 1,1,65535,cielab
0,0: (2570,-25700,-6425) #0A0A00000000 cielab(3.92157%,-39.2157%,-9.80392%)
Re: Lab color behaves incorrectly
Posted: 2016-04-11T13:57:45-07:00
by tom_dl
I assume you are using a build of ImageMagick with HDRI enabled? When I copy your command with it enabled, I do get the same results. However, my bug report was for builds
without HDRI enabled. When I copy your command without HDRI, I get:
Code: Select all
convert xc:cielab(4%,-40%,-10%) txt:
# ImageMagick pixel enumeration: 1,1,65535,cielab
0,0: (2621,0,0) #0A3D00000000 cielab(4%,0%,0%)
yet an outputted image will have Lab values 4,-102,-26 in photoshop (i.e. L*1,a*2*-128,b*2*-128), showing that the pixel values themselves are not clipped, only the txt output.
Thanks
Re: Lab color behaves incorrectly
Posted: 2016-04-11T14:15:41-07:00
by snibgo
Sorry, I should have made that clear. My tests were on Q16, integer, without HDRI.
Code: Select all
f:\web\im>%IM%convert -version
Version: ImageMagick 6.9.2-5 Q16 x64 2015-10-31 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2015 ImageMagick Studio LLC
License: http://www.imagemagick.org/script/license.php
Visual C++: 180031101
Features: Cipher DPC Modules OpenMP
Delegates (built-in): bzlib cairo freetype jng jp2 jpeg lcms lqr openexr pangocairo png ps rsvg tiff webp xml zlib
So it seems to be new bug, introduced after v6.9.2-5.
Re: Lab color behaves incorrectly
Posted: 2016-04-11T14:39:33-07:00
by fmw42
If entered as % a and b are clipped at 0% and 50% (i.e. all minus values are clipped to 0%) - NOT EXPECTED
If entered as a number, a and b are clipped at 0 and half of quantum depth (i.e. all minus values are clipped to 0) - NOT EXPECTED
Since non-hdri IM does not support negative values, the a and b channels are shifted by half the quantumrange to keep them from having negative values. So a round trip works, because IM knows about the shift, but you may find a,b values that your do not expect. Shifting them the opposite amount by 50% should give you the values you want.
Re: Lab color behaves incorrectly
Posted: 2016-04-11T14:51:22-07:00
by snibgo
tom_dl reports a problem in v6.9.3-7 that txt output values are always in the range 0 to 50%. Negative values are clamped to zero. Hence, the round-trip to txt and back won't work.
In the older version that I currently use, v6.9.2-5, they are correctly reported as -50% to +50%.
Re: Lab color behaves incorrectly
Posted: 2016-04-11T15:00:10-07:00
by fmw42
OK. Thanks snibgo. Sorry I misunderstood. I am surprised that they are reported as negative for any non-hdri versions. I guess internally they are shifted, but txt: is then supposed to report the unshifted values.
Re: Lab color behaves incorrectly
Posted: 2016-04-11T15:28:00-07:00
by snibgo
Internally, the values are stored as zero to QuantumRange, for both HDRI and non-HDRI, where QuantumRange is 255 or 65535 or whatever. So a colour that is inside the CIELab gamut is a positive number between 0 and QuantumRange in all channels. (Likewise for all other colorspaces.)
For most colorspaces, all channels can be input and output as 0 to 100%. The only exceptions are the a* and b* channels of CIELab.
For some purposes, the values for the a* and b* channels are input and output not as 0 to 100% but as -50% to +50%. Personally, I find this a bit of a pain, but I don't much mind provided it is consistent. Apparently a bug has arisen meaning that half the possible values are wrong on txt: output.
Re: Lab color behaves incorrectly
Posted: 2016-04-11T15:49:24-07:00
by tom_dl
Thanks both for looking into this and confirming the bug.
Tom
Re: Lab color behaves incorrectly
Posted: 2016-04-11T15:58:48-07:00
by snibgo
Yes, it looks like a bug to me. Just for completeness, what do you get for my other test?
Code: Select all
f:\web\im>%IM%convert xc:cielab(10,-100,-25) txt:
# ImageMagick pixel enumeration: 1,1,65535,cielab
0,0: (2570,-25700,-6425) #0A0A00000000 cielab(3.92157%,-39.2157%,-9.80392%)
Re: Lab color behaves incorrectly
Posted: 2016-04-12T03:29:19-07:00
by tom_dl
I get:
Code: Select all
convert xc:"cielab(10,-100,-25)" txt:
# ImageMagick pixel enumeration: 1,1,65535,cielab
0,0: (2570,0,0) #0A0A00000000 cielab(4%,0%,0%)
Re: Lab color behaves incorrectly
Posted: 2016-04-12T04:00:47-07:00
by snibgo
Yes, as you said in the OP, the negative values are clamped to zero. Bug, IMHO.
Re: Lab color behaves incorrectly
Posted: 2016-04-12T16:39:28-07:00
by magick
Thanks for the problem report. We can reproduce it and will have a patch to fix it in GIT master branch @
https://github.com/ImageMagick/ImageMagick later today. The patch will be available in the beta releases of ImageMagick @
http://www.imagemagick.org/download/beta/ by sometime tomorrow.