possible bug LCH colorspace IM 6.8.4.6 Mac OSX

[fmw42]

I have been testing the following commands to compare LCH and HCL colorspaces. The following are simple round trips. It works fine for HCL but not for LCH.

This works fine for HCL

hue=1
chr=1
lum=1
convert rose: -set colorspace RGB -colorspace HCL -separate +channel \
\( -clone 0 -evaluate multiply $hue \) \
\( -clone 1 -evaluate multiply $chr \) \
\( -clone 2 -evaluate multiply $lum \) \
-delete 0-2 -set colorspace HCL -combine -colorspace RGB -set colorspace sRGB \
test_hcl_${hue}_${sat}_${lum}.png




This is not correct for LCH

lum=1
chr=1
hue=1
convert rose: -set colorspace RGB -colorspace LCH -separate +channel \
\( -clone 0 -evaluate multiply $lum \) \
\( -clone 1 -evaluate multiply $chr \) \
\( -clone 2 -evaluate multiply $hue \) \
-delete 0-2 -set colorspace LCH -combine -colorspace RGB -set colorspace sRGB \
test_lch_${hue}_${sat}_${lum}.png

[snibgo]

Colorspaces that fail a simple round-trip test in v6.8.4-6 are: LCH, LMS, YCC, YIQ, YUV. Of these, YIQ and YUV aren't much worse than 1% off.

My simple test is ...

Code: Select all

convert hald:8 src.png
convert src.png -colorspace XXXX -colorspace sRGB result.png
compare -metric RMSE src.png result.png NULL:

... and I regard an RMSE > 0.01 (ie 1%) as a failure.

[anthony]

I would just get rid of LCH colorspace -- it is just causing confusion.

HCL is meant to be equivalent to LCHab, but with a channel order equivalent to HSL and HSB so modulate can use it.


however I agree the above test in the original post from Fred should work as a round trip, but does not seem to.

of course in IMv7 the destination colorspace is an argument to -combine (as it should have been in the first place).

[magick]

We'll support HCL in perhaps a week or two. Stand by...

[fmw42]

We'll support HCL in perhaps a week or two. Stand by...

My interest in LCH is that the L be luma (such as in LAB or Y from YUV,etc) and not lightness. But if it still needs work, then perhaps you would also make it work with -modulate. You might also consider having the channel orders be HCY so that they now are consistent with HCL, HSL and HSB. But I can deal with it in either order.

Some references (though I am not sure how relevant):
http://chilliant.blogspot.com/2012/08/r ... -hlsl.html
http://api.kde.org/4.0-api/kdelibs-apid ... ource.html
http://statmath.wu-wien.ac.at/~zeileis/ ... l-2009.pdf
http://mmir.doc.ic.ac.uk/mmir2005/Camer ... ssaoui.pdf
http://en.wikipedia.org/wiki/CIELUV_color_space (see LCHuv)
http://cscheid.net/blog/hcl_color_space_blues
http://cran.r-project.org/web/packages/ ... (software)

The some of the reference says that HCL is obtained by simply transforming the UV coordinates of Luv to polar coordinates.

(There is also another colorspace that is LAB with ab convert to polar coordinates)


Some of these references indicate that LCH (HCY) may produce values out of gamut. If so then its utility may be limited?

[anthony]

Perhaps we need

HCL (cylindrical Lab)
HCLuv (cylindrical Luv)
HCY (cylindrical Yuv)

But Only the first is of interest to me. I just always assumed the L in HCL and Lab were equivalent as that is what was requested originally.

See, my discussion of the colorspace
http://www.imagemagick.org/Usage/color_ ... rwheel_HCL