Legacy ImageMagick Discussions Archive

Well something is odd...

comparing the outputs of...
convert rose: -colorspace LAB txt: > t1
convert rose: -colorspace HCL txt: > t2

and I can see no channel value in one, matching the channel value in the other.
The first channel in t1 output, should be matching the third channel value in t2 output -- it doesn't
Though it does seem to have some type of correlation.

At least to my understanding of HCL!
See Wikipedia... http://en.wikipedia.org/wiki/CIELUV#Cyl ... esentation

The L channel should left AS-IS, just maped from first to third channel.

Hmmm looks like the conversion has 'gamma' effects in the L of HCL.

I am using Win32 Q16 static compile:

Code: Select all

Version: ImageMagick 6.8.3-5 2013-02-24 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2013 ImageMagick Studio LLC
Features: DPC OpenMP

Code: Select all

convert.exe rose: -set colorspace srgb -colorspace hcl -channel R -gamma 1 +channel -colorspace lab -channel R -separate -colorspace srgb rose_L_h_g1.png
convert.exe rose: -set colorspace srgb -colorspace hcl -channel G -gamma 1 +channel -colorspace lab -channel R -separate -colorspace srgb rose_L_c_g1.png
convert.exe rose: -set colorspace srgb -colorspace hcl -channel B -gamma 1 +channel -colorspace lab -channel R -separate -colorspace srgb rose_L_l_g1.png
convert.exe rose: -set colorspace srgb                                              -colorspace lab -channel R -separate -colorspace srgb rose_L.png
convert.exe rose: -set colorspace srgb -colorspace hcl -channel R -gamma 2 +channel -colorspace lab -channel R -separate -colorspace srgb rose_L_h_g2.png
convert.exe rose: -set colorspace srgb -colorspace hcl -channel G -gamma 2 +channel -colorspace lab -channel R -separate -colorspace srgb rose_L_c_g2.png

I observed:
1) rose_L.png, rose_L_l_g1.png, rose_L_h_g1.png and rose_L_c_g1.png look almost the same. => This is expected.
2) rose_L_h_g2.png and rose_L_c_g2.png are rather different from rose_L.png. => This is not expected.

HCL in ImageMagick is hue, chroma, and lightness. There are other interpretations where the L corresponds to the L in Lab. You may be looking for the LCH colorspace which uses the L from Lab and chroma and hue. If you think HCL is wrong in ImageMagick, we need references to the correct algorithm to use as a basis for correcting the ConvertRGBToHCL() and ConvertHCLtoRGB() methods in magick/gem.c.

I also thought than HCL was using luma. It would be beneficial to have LCH where L is the same as in LAB (presumably luma). Lightness only considers the min and max (R,G,B) so is less precise than luma.

Just as another note, the following uses the average (R,G,B) for L in their HCL.
http://muscle.ercim.eu/images/DocumentP ... ry_PRL.pdf

This reference use YCH where Y is luma as in YIQ. If we use this, perhaps it would be called HCY to keep the order consistent
http://campusv.uaem.mx/cicos/imagenes/m ... culo21.pdf

ImageMagick already supports the LCH colorspace.

magick wrote:ImageMagick already supports the LCH colorspace.

can it be called from the -define modulate:colorspace=LCH -modulate ...

No. Modulate supports HCL, HSB, HSL, and HWB.

magick wrote:HCL in ImageMagick is hue, chroma, and lightness. There are other interpretations where the L corresponds to the L in Lab. You may be looking for the LCH colorspace which uses the L from Lab and chroma and hue. If you think HCL is wrong in ImageMagick, we need references to the correct algorithm to use as a basis for correcting the ConvertRGBToHCL() and ConvertHCLtoRGB() methods in magick/gem.c.

HCL is meant to be equivalent to cylic LAB! as in LCHab...

The channels is only ordered in HCL order to make it similar to HSL and HSB, so that -modulate can also use that colorspace without change.

At no time was a LCH colorspace requested as such a cyclic colorspace could not be used with modulate! Though you added it at the same as HCL. I always just assumed they were equivalent with just a re-ordering or color channels. A 'lightness' version was never requested or brought up in that discussion.

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

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

Is it implemented in 6.8.5.5?

henrywho wrote:
magick wrote:We'll support HCL in perhaps a week or two. Stand by...
Is it implemented in 6.8.5.5?

HCL in 6.8.5.5 is the same as it was (L=Y). see http://en.wikipedia.org/wiki/HSL_and_HSV

HCLp (L=Y) is new in 6.8.5.5 and is the projected version of HCL. See viewtopic.php?f=2&t=21663&p=88915&hilit=HCL#p88915 It seems to be a better match to HCL in Photoshop.

LCHab and LHuv are available in 6.8.5.5 with L from LAB and LUV, respectively using cylindrical coordinates and I think they are now correct. Anthony can confirm further.

HCLab and HCLuv, do not seem to do anything as far as I can tell in 6.8.5.5

HCLab and HCLuv no longer exist, and probably never really did exist (my bad)

I have not verified that LCHab and LCHuv are correct, and last I looked, Hue was not continuious..

Nope... Hues are still not continuous. and the Hue angles are wrong..
(red is where blue should be, and a green-blue discontinuation along the Hue wrap around point)

LCH is currently equivalent to LCHab (I believe it was supposed to be LCHuv)

There is some type of discontinuation in the darker colors of LCHuv, but I am starting to think it may be because I am directly generating colors in LCHuv colorspace and these fully saturated (chroma) colors don't exist in real life. Looking for better ways of demonstrating the colorspace.

LCHab does not seem to have that effect.

Legacy ImageMagick Discussions Archive

L in HCL is not Luminance! (my error)

L in HCL is not Luminance! (my error)

Re: L in HCL is not Luminance!

Re: L in HCL is not Luminance!

Re: L in HCL is not Luminance!

Re: L in HCL is not Luminance!

Re: L in HCL is not Luminance!

Re: L in HCL is not Luminance!

Re: L in HCL is not Luminance!

Re: L in HCL is not Luminance!

Re: L in HCL is not Luminance!

Re: L in HCL is not Luminance!

Re: L in HCL is not Luminance! (my error)