Legacy ImageMagick Discussions Archive

IM 6.6.8.5 Q16 Mac OSX Tiger

This used to give the opposite results:


Set opacity to 60% (so transparency is 40%)


convert logo: logo.jpg
convert logo.jpg -alpha on -channel o -evaluate set 60% logo_opacity60.png

# this used to give .6
convert logo_opacity60.png -format "%[fx:u.o]" info:
0.4

# this used to give .4
convert logo_opacity60.png -format "%[fx:u.a]" info:
0.6

I get the same result if I use a .txt instead of a .png
so I don't think it's a PNG change.

OK. I get the same results (backwards from what it should be) with TIF as well as PNG. So seems to be a change in the way IM is handling opacity vs transparency.

Magick, can you comment, please. Has -channel o (opacity) been changed to be the same as -channel a (i.e. transparency) ? Seems to me that -channel o should be the negate of -channel a!


convert logo.jpg -alpha on -channel o -evaluate set 60% logo_opacity60.tif
convert logo_opacity60.tif -format "%[fx:u.o]" info:
0.4
convert logo_opacity60.tif -format "%[fx:u.a]" info:
0.6

convert logo.jpg -alpha on -channel a -evaluate set 60% logo_transparency60.png
convert logo_transparency60.png -format "%[fx:u.o]" info:
0.4
convert logo_transparency60.png -format "%[fx:u.a]" info:
0.6

I believe it was changed when it was discovered that -evaluate did not work with alpha values at the time that -function was being developed. The -function was added to also deal with alpha values from the outset.

To my thinking the current behaviour is the correct behaviour.

On the other hand -level and -threshold operators handling of images transparency channel as matte is I feel stupid. But changing those VERY OLD operators would break too much backward compatibility, without a major version change.

could we not keep -channel o different (the negate) of -channel a? or does that cause problems elsewhere? if that is not possible, then a note should be added to the docs to say that they have the same meaning, i.e. both are alpha channel (or remove -channel o as that is confusing with the way it now works)?

Any idea at what IM version the change occurred? It would help me to modify my tidbits page.

fmw42 wrote:could we not keep -channel o different (the negate) of -channel a?

Internally (and I mention it a few times) -channel o and -channel a means exactly the same thing

Just as -channel C and -channel R means exactly the same thing, the red channel, which is also used for cyan and hue channels in the appropriate colorspace.

The order of the channel arguments also do not have any meaning.

So the channel flags that can be set are..
red, green, blue, alpha, sync

Sync is a flag that means operators should attempt to treat the pixels as a whole, rather than as separate channel values. That is transparency has no color, auto-level should mody channel values together. sync means channel values are 'synchronised' in action.

Note all operations obey it, just as not all operations make use of the channel setting.



I really would like to see -blur and -convolve obey the 'sync' flag with reagrds to transparency rather that the long running 'kludge' of setting channel to RGBA. That way blur understands transparency BY DEFAULT!

I would also like to make Lighten and Darken composition obey channel setting. that is compare colours by intensity if sync is set, or by channel value if -channel has been defined. But this breaks SVG definition, so I may have to create separate compose methods instead.