possible bug [pixel:...] with hsb IM 6.7.1.0 Q16

[fmw42]

IM 6.7.1.0 Q16 Mac OSX Tiger.

I am getting strange results when converting colors such as white, red, etc (primary colors) to hsb and then trying to get the resulting values.


pcolor="white"

This gives strange results:
hsb=`convert xc:$pcolor -colorspace hsb -format "%[pixel:u.p{0,0}]" info:`
echo hsb="$hsb"
hsb=blue

This gives reasonable results:
hue=`convert xc:$pcolor -colorspace hsb -format "%[fx:100*u.r]" info:`
sat=`convert xc:$pcolor -colorspace hsb -format "%[fx:100*u.g]" info:`
bri=`convert xc:$pcolor -colorspace hsb -format "%[fx:100*u.b]" info:`
echo "hsb=hsb($hue%,$sat%,$bri%)"
hsb=hsb(0%,0%,100%)


Similarly:

pcolor="red"

hsb=`convert xc:$pcolor -colorspace hsb -format "%[pixel:u.p{0,0}]" info:`
echo hsb="$hsb"
hsb=cyan

hue=`convert xc:$pcolor -colorspace hsb -format "%[fx:100*u.r]" info:`
sat=`convert xc:$pcolor -colorspace hsb -format "%[fx:100*u.g]" info:`
bri=`convert xc:$pcolor -colorspace hsb -format "%[fx:100*u.b]" info:`
echo "hsb=hsb($hue%,$sat%,$bri%)"
hsb=hsb(0%,100%,100%)



From the above, it seems to take the hsb values and interpret them as if rgb values if it can match those values to a color name (without regard to the colorspace).



However, the following looks fine.

pcolor="gold"

hsb=`convert xc:$pcolor -colorspace hsb -format "%[pixel:u.p{0,0}]" info:`
echo hsb="$hsb"
hsb=hsb(14.052%,100%,100%)

hue=`convert xc:$pcolor -colorspace hsb -format "%[fx:100*u.r]" info:`
sat=`convert xc:$pcolor -colorspace hsb -format "%[fx:100*u.g]" info:`
bri=`convert xc:$pcolor -colorspace hsb -format "%[fx:100*u.b]" info:`
echo "hsb=hsb($hue%,$sat%,$bri%)"
hsb=hsb(14.052%,100%,100%)

So for this color it works fine and returns hsb values.

Thus it seems to only fail when trying to match the result to a color name. So perhaps one should change pixel: so that it only returns percent values and not color names when not using rgb colorspace/color values?

Does that cause other problems?

[magick]

We can reproduce the problem you reported and have a patch in ImageMagick 6.7.1-1 Beta available by sometime tomorrow. Thanks.

[anthony]

that is only the tip of the 'iceberg'


Colorspace handling problems (as I have come to know them)...

A "#xxxxx" color is non-specific to the colorspace and as such can be applied ASIS to any colorspace. That is the value has a undefined colorspace, though an functional extension may allow you to define a colorspace for that color.

There is no way of specifying a named color with some transparency level. EG: you can not specify a 50% transparent DodgerBlue color!

Named colors is actually defined as an SRGB color (it isn't actually an RGB!) and needs to be converted to the colorspace in which the color is being applied. This is closely related to the problem reported by the user!

That is when the color gets recorded for future use, the colorspace of that color should also be recorded so the color can be converted appropriatally when applied to, or compared against, some specific image. That is colors must be saved, not only with the 'values' but also the 'colorspace' of those values (unless undefined)

This is also related to the fact that IM currently (IMv6 that is) stores image by default as RGB colorspace when it is in fact really SRGB colorspace. Most image formats should actually read/save images by default to SRGB, unless specifically declared otherwise. GIF images especially should only save and load as SRGB! While NetPBM/PbmPlus images are sometimes SRGB (real images) and sometimes RGB (mathematical images and gradients).

Continuing this problem... is that -colorspace SRGB of an image (currently marked as RGB) actually converts from SRGB to linear RGB for processing (marked as SRGB internally). EG: the colorspace definations of RGB and SRGB in IMv6 is reversed! This should not be changed in IMv6, as it it too throughly embedded, but it should only be fixed in IMv7.

The problem with this is that 'draw' functions is designed to do its anti-aliasing of lines and circles in linear RGB space. At least that is what my tests are showing! However images which are loaded are using SRGB colorspace. If you (correctly) convert images to linear RGB (using -colorspace SRGB) before drawing on them, then convert back before saving the draw anti-aliasing works perfectly, producing nice smooth edge results.

See http://www.imagemagick.org/Usage/draw/#colorspace for examples and details of this.

However as the 'SRGB named colors' are applied by draw without regard to colorspace, a image converted to linear RGB colorspace and drawn to will have the applied named colors become out 'wrong', when the drawn image gets converted back to SRGB (using -colorspace RGB) for saving!

In IMv6 direct drawing with named colors works, but only because draw is drawing directly to a SRGB colorspace image, and thus getting incorrect anit-aliased results. Drawing correctly in linear RGB gets the anti-alising right but the colors wrong. A loose-loose situation at present.

Basically all these colorspace handling problems needs to be looked at and fixed in IMv7 (it is part of the IMv7 Change Recomendations)

this has been added to IM Examples, Bugs, Future Fixes, Colorspace
http://www.imagemagick.org/Usage/bugs/future/#colorpace

[fmw42]

Thansk. The issue with converting rgb to hsb or hsl colors and getting pixel: values appears fixed in IM 6.7.1.1