[LAB Space] Avg Color via 1x1 Scaling Bug Due to Forgot Sign

[cjmi]

ImageMagick 6.7.8-0, libtiff 4.0.2.

In the LAB colorspace, .green() values of [0, 0.996109] are translated into A* values by multiplying the 0-1 decimals by 256 (possibly 255, but I think 256), and if that is 128 or more, subtracting 256. Therefore, the A* values are translated into [0, -0.996096]. (Yes, it looks like we almost just made the value negative, but that's coincidence. 0.996109*256-256 = -0.996096.)

A* values of 0 and -0.996096 are the same, assuming you're not worried about variations less than 1 in A*.

There are 1,145 pixels with A* of 0, and 2,455 pixels with -0.996096. Therefore, they should average to -0.67928.

Instead, when scaling to 1 pixel, the original decimals are being averaged, ignoring that 0 and 0.996109 are right next to each other, due to the wrapping. These decimals are averaged to 67.9286%, which when translated to A* becomes -82.102784, which is no where near any of the colors in the original image.

NOTE: All of these colors are virtually identical in LAB colorspace, due to the wrapping nature at 0 and 1 to positive and negative values in A*.
Download this file at: http://www.filedropper.com/60x60 - You can only see slight variation in color with a well calibrated monitor, they're reasonably all the same color.

Histogram:
51: (16192, 0, 2304) #3F4000000900 cielab(24.7074%,0%,3.51568%)
389: (16192, 0, 2560) #3F4000000A00 cielab(24.7074%,0%,3.90631%)
111: (16192,65280, 2304) #3F40FF000900 cielab(24.7074%,99.6109%,3.51568%)
801: (16192,65280, 2560) #3F40FF000A00 cielab(24.7074%,99.6109%,3.90631%)
94: (16448, 0, 2304) #404000000900 cielab(25.098%,0%,3.51568%)
611: (16448, 0, 2560) #404000000A00 cielab(25.098%,0%,3.90631%)
168: (16448,65280, 2304) #4040FF000900 cielab(25.098%,99.6109%,3.51568%)
1375: (16448,65280, 2560) #4040FF000A00 cielab(25.098%,99.6109%,3.90631%)

Scale to 1x1 px, and you get:
Download this file at: http://www.filedropper.com/1x1 - You get a bright green, which isn't correct.

Histogram:
1: (16352,44517, 2530) #3FE0ADE509E2 cielab(24.9516%, 67.9286%, 3.86053%)

[magick]

Image processing algorithms won't work correctly on Lab because they are encoded to fit into an unsigned integer. Before you scale, convert the colorspace to sRGB, scale, then convert it back to Lab (e.g. -colorspace sRGB -scale 1x1 -colorspace Lab). We have another option. Build ImageMagick with HDRI enabled. You can then work directly in the Lab colorspace because HDRI can encode negative A/B, however, it then can't read LAB TIFF properly because the TIFF Lab values are encoded for unsigned integers. We need to adjust the A/B values in the TIFF coder for HDRI. If either of these options do not resolve the problem, provide us with a URL to your original image, what ImageMagick produces, and what ImageMagick should produce. We'll investigate further.

Update: We have a patch in ImageMagick 6.7.8-1 Beta available by sometime tomorrow where you can work directly with TIFF Lab images for HDRI-enabled versions of ImageMagick. With HDRI enabled, you get correct results with, for example, convert lab.tif -scale 50% scale.tif.

[anthony]

The reason why A and B values fail for LAB in non-HDRI is because the value was saving a signed integer format in unsigned integer memory. (upper bit one means negative).

You can make it work for most linear operations by changing the signed integers to a 50% Biased unsigned integers, much like we do for Displacement Maps (EG add QuantumRange/2, makign the upper bit on mean positive). It is a simpler conversion too.


Most 'averaging' operations (blurs, filters, distorts, resize, interpolations) do not have a problem with a biased zero.

Operations that do have a problem are multiplications of the bias channel, but they are less often used with images.

[anthony]

Looks as if Cristy has made this change already. As such LAB should now blur/resize/distort correctly in that colorspace.