Page 1 of 1

possible bug LCH colorspace IM 6.8.4.6 Mac OSX

Posted: 2013-04-02T18:55:09-07:00
by 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

Image


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

Image

Re: possible bug LCH colorspace IM 6.8.4.6 Mac OSX

Posted: 2013-04-02T20:13:23-07:00
by 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.

Re: possible bug LCH colorspace IM 6.8.4.6 Mac OSX

Posted: 2013-04-02T22:52:14-07:00
by 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).

Re: possible bug LCH colorspace IM 6.8.4.6 Mac OSX

Posted: 2013-04-03T05:38:02-07:00
by magick
We'll support HCL in perhaps a week or two. Stand by...

Re: possible bug LCH colorspace IM 6.8.4.6 Mac OSX

Posted: 2013-04-03T09:54:48-07:00
by fmw42
magick wrote: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?

Re: possible bug LCH colorspace IM 6.8.4.6 Mac OSX

Posted: 2013-04-03T17:52:31-07:00
by 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