Hue composition operator not working as described

[mindplay.dk]

I'm using IM-6.4.8-Q8 on Windows, with RMagick 2.9.0 and Ruby 1.8.6.

The HueCompositeOp operator does not work as described/expected.

From the description, it is supposed to copy the hue from one image to another.

From the description of the "Hue" blendmode in photoshop, that's what this does, too.

But the actual result seems to be more like a blend of the two hues - I'm not sure what this operator does, but the hue of the resulting image is nothing like the hue of neither the source or destination image, it appears to be some sort of blend of the two hues.

So, for example, if "a.png" is solid red (#ff0000) and "b.png" is solid green (#00ff00), combining with the "Hue" blend mode in Photoshop gives you a brighter red (#ff6a6a), but with the exact hue of "a.png", as it should be.

Combining the images with IM, on the other hand, results in a solid yellow (#ffff00) - which does not resemble the hue of any of the source images.

Clearly this is wrong?

Here's my sample script:

Code: Select all

require 'rubygems'
require 'RMagick'
include Magick

a = Image.read('a.png').first
b = Image.read('b.png').first

a.alpha = ActivateAlphaChannel
b.alpha = ActivateAlphaChannel

a.composite(b, 0, 0, HueCompositeOp).write('test.png')

Also, I had a look at the PSD reader/writer source code, to see if I was using the right operator - and photoshop's "Hue" blend mode does map to this operator, so I expect layered photoshop images using this blendmode will not read correctly either.

[anthony]

It seems strange but from the command line I get black!

Code: Select all

convert xc:red xc:lime -compose Hue -composite txt:
# ImageMagick pixel enumeration: 1,1,65535,rgb
0,0: (    0,    0,    0)  #000000000000  black

Trying a brighter version I get a gray!

Code: Select all

convert xc:#FF5050 xc:#50FF50 -compose Hue -composite txt:
# ImageMagick pixel enumeration: 1,1,65535,rgb
0,0: (20560,20560,20560)  #505050505050  rgb(80,80,80)

I have no idea why photoshop gets a brighter red, that does not seem right either!

I found the fault in the code, it seems the HSB->RGB only saves the updated 'red' not the updated red,green, and blue, values!!!!

Yes that fixes it.

Code: Select all

convert xc:red xc:lime -compose Hue -composite txt:
# ImageMagick pixel enumeration: 1,1,65535,rgb
0,0: (    0,65535,    0)  #0000FFFF0000  lime

A similar bug was also found for 'Saturate' and 'Luminize'
Only the 'Colorize' operator (Hue+Saturate) in that group of compose methods was correct

Uploading to SVN now.


Good pickup! I have missed the existence of this problem for years in my compose tables
http://www.imagemagick.org/Usage/compose/tables/
The tables will update a few days with the change.

[mindplay.dk]

I have no idea why photoshop gets a brighter red, that does not seem right either!

No, that is the correct behavior - you should get a slightly brighter red, since yellow contains a lot more energy than, say, blue.

The energy coefficients for the three primaries are (roughly), 5.87 for green, 2.99 for red and only 1.14 for blue.

Hence, a full-intensity red (at 2.99 brightness) over a full-intensity green (at 5.87 brightness) needs some white in it, to bring it up to the same brightness.

Similarly, if you laid a full-intensity red (at 2.99) over a full-intensity blue (at 1.14), you should get a considerably weaker red.

In order to perform HSV calculations properly, you need to work in intensity maximums for at last the three primaries and three secondaries - ideally, you should work in the six tertiaries as well, and if I recall correctly, laying a sinus-curve through those points will give you accurate color conversion. (although many applications simply use linear interpolation between the six points...)

[mindplay.dk]

Looking at the source code, it appears to use linear interpolation between the three primaries and three secondaries, so that should be okay.

[anthony]

Looking at the source code, it appears to use linear interpolation between the three primaries and three secondaries, so that should be okay.

Yes, but that is not in the composite, but in the colorspace conversion.