Legacy ImageMagick Discussions Archive

I really don't know what is happening or how long it has been broken, but HSL colorspace does not have a 'hex-cone' distribution of colors.

The basic colorwheel example from IM Examples, Color Basics, Generating a HSL Color Wheel
just does not have a 60 degree equal angle spread of the primary colors, Blue, Red, and Green as it is supposed to
but looks more like a cylindrical LAB/LUV spread of colors. The intensity also appears to be not what is traditionally produced.
What it produces...

What it should be producing (hex-cone color spread)


The same is happening with HCL, with greens and yellows being squeezed into a very small tight band. HCL is supposed to generate something almost identical to the hex-cone but with more realistic RGB intensity levels. I am not certain it uses exactly a Hex-Cone hue distribution, as the main page at http://hclcolor.com/ says blue is at and angle of 260, and not 240. That however may be due to the more realistic intensity levels pushing off blue colors more to one side.


Basically something very basic is wrong.

I get the same result in IM 6.8.6.9 Q16 Mac OSX. Unfortunately, I can no longer use my older versions of IM after recently upgrading my delegates from MacPorts. So I cannot tell when there was a change.

It is possible that the code is using the H2,C2 format as described at http://en.wikipedia.org/wiki/HSL_and_HSV under the section on Hue Chroma. But that is just a wild guess.

HSB also shows the same distortion (and rotation of the colors).

HCLp looks about right for color distribution (no rotation of red from 0 degrees, i.e. x axis)

fmw42 wrote:HCLp looks about right for color distribution (no rotation of red from 0 degrees, i.e. x axis)

Not for me -- color hues looks very skewed! I gather HCLp is the HSL equivelent, where HCL is the HSB. that is HCLp has white for all maximum intensities.



The H2,C2 does not appear very different to hex-cone H values. Primary colors are in the same location, it is just a minor 'hex to circle' vector modification that I have never actually seen used by anyone!

Yes, HCLp is the projected version of HCL such that it is like HSL with white as the extreme. See viewtopic.php?f=2&t=21646


These are what I get in IM 6869 Q16 Mac OSX:

HSL:



HSB:



HCLp:




HCL




Note the first two seem to be rotated about 45 degrees to the north if not even more wrong.

Your HCL are completely different. I only just compiled using SVN updated just now.
ImageMagick 6.8.6-10 2013-09-12 Q16

SVN revision 13198

Well then something has been changed in the subversion or beta of 6.8.6.10! But that does not explain the change to HSL and HSB

Wish I knew how to down grade my MacPorts delegates to get back to where I could run all the old versions of IM. I could then tell when it changed.

Perhaps it occurred at:

2013-07-24 6.8.6-7 Cristy <quetzlzacatenango@image...>
Missing case for HCLpColorspace (reference viewtopic.php?f=3&t=23811).

or

2013-06-26 6.8.6-3 Cristy <quetzlzacatenango@image...>
Improve HCL to RGB roundtrip (reference viewtopic.php?f=3&t=22384).

or


2013-06-16 6.8.6-1 Cristy <quetzlzacatenango@image...>
Improve LCHab and LCHuv roundtrip to / from sRGB (reference viewtopic.php?f=1&t=23596).

I'll have to look at this harder when I'm awake, but I question the final convert. I would think a better convert would be ... ... which gives the correct result in v6.8.6-9 on Windows 7.

The problem with Anthony's final convert is that the images are set to RGB before the "-combine". But "-combine" wants its input to be sRGB, so this forces a RGB->sRGB conversion.

For a simple demonstration of this automatic conversion, in v6.8.6-9 on Windows:
0,0: ( 6554,13107,19661) #199A33334CCD srgb(10.0008%,20%,30.0008%) <-- correct
0,0: (22885,31754,38262) #59657C0A9576 rgb(34.9203%,48.4535%,58.3841%) <-- incorrect

"-set colorspace RGB" was required before about v6.8.5, when IM would otherwise do a sRGB->RGB conversion. In more recent versions, including "-set colorspace RGB" gives an incorrect result.

Anthony's final convert finishes with "-colorspace RGB -set colorspace sRGB". I can't see why we would want to convert to RGB but pretend this is sRGB. The resulting tones (but not hues) will be wrong. A simple "-colorspace sRGB" will suffice.

I conclude that Anthony is not correct that "Basically something very basic is wrong."

(Incidentally, I don't know why "-combine" insists on having its inputs as sRGB. But we can ensure it never converts by preceding it with "-set colorspace sRGB".)

-combine should be accepting grayscale images AS it is currently. No data changes.

It is a data operator, and any colorspace aspects should only involve the output (combined) image. Which is why I also say that combine should also take a colorspace as an argument.

I have said these things many times, and it is provides the greatest freedom to the users doing work with channel (raw data) image work.


Idealy in the above I should be able to use the grayscale input image data 'AS IS' without modification.

Now I have had to add the -colorspace setting for the input image in the past. I should not need to do this as the image
data is ment to be RAW linear grayscale data. That is the data in the svaed file should be linear. not sRGB.

Obviously this is what is going wrong. So how should the example look like now?

This seems to work for current versions of IM post 6.8.5.4 (viewtopic.php?f=4&t=21269#p102016)


convert angular.png solid.png radial.png \
-combine -set colorspace HSL -colorspace sRGB colorwheel_HSL.png

Yes, I think that's how the example should be written.

I would be happy if "-combine" didn't convert any of its inputs to sRGB before combining. However, that would raise other issues:

1. If all of its inputs are, say in Lab colorspace, should it simply combine the values into pixels and then set the colorspace of the output as Lab? That seems reasonable to me.

2. What if the inputs are in different colorspaces? Perhaps it should throw an error. Perhaps it should combine the values into pixels and set the colorspace of the output as "unknown". I don't know.

I would also be happy is combine only accepts grayscale images. Perhaps output a 'convertion warning' and use the current '-intensity' method (whcih is probably what it is doing now).

However grayscale is tricky in IMv6 which does not have a 'real' definition of grayscale. Though if sRGB or RGB image is greyscale (all color channels tha same) then it should not produce a error and just use data AS IS.

That I think would make it logical. The same should be true for any operator that actually requires a greyscale image.
be it for a MASK (such as three image composition) or image index look (use alpha or black channel, but index image has no alpha or black channel).

This is actually probably the internal job of -intensity, as apposed to its external counterpart -grayscale