Lab color behaves incorrectly

[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.

[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%)

[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

[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.

[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.

[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%.

[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.

[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.

[tom_dl]

Thanks both for looking into this and confirming the bug.
Tom

[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%)

[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%)

[snibgo]

Yes, as you said in the OP, the negative values are clamped to zero. Bug, IMHO.

[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.