Page 1 of 1

[RESOLVED] possible bug -compose copy_opacity IM 6.9.3.3 Q16 Mac OSX

Posted: 2016-02-08T20:50:20-07:00
by fmw42
.

I seem to get different results from the following two command lines. I do not understand why the second shows any transparency (faint checkerboard pattern). Perhaps I misunderstand what it should produce. But I expected the two results to be the same. Is this a bug or have I made some error in the command line or my understanding of what to expect?


Code: Select all

convert \( logo: -channel a -evaluate set 50% +channel \) +duplicate -compose over -composite logo_blend1.png
display logo_blend1.png

Code: Select all

convert logo: \( -clone 0 -fill "gray(50%)" -colorize 100% \) \
-alpha off -compose copy_opacity -composite +duplicate -compose over -composite logo_blend2.png
display logo_blend2.png

Re: possible bug -compose copy_opacity IM 6.9.3.3 Q16 Mac OSX

Posted: 2016-02-08T21:49:58-07:00
by snibgo
When we compose one pixel over another, if either is opaque then the result will be opaque. But if they are both (partially) transparent, the result will also be (partially) transparent.

Your first example doesn't have alpha enabled, so "-channel a -evaluate set 50%% +channel" does nothing. If you prefix that with "-alpha set", the result is partially transparent, as expected, and "compare" says the two results are the same.

"-compose copy_opacity -composite" doesn't need alpha to be enabled. Indeed, we often deliberately turn it off, as you have done.

Re: [RESOLVED] possible bug -compose copy_opacity IM 6.9.3.3 Q16 Mac OSX

Posted: 2016-02-08T23:50:47-07:00
by fmw42
Thanks snibgo. I had mistakenly assumed that alpha was enabled by default in the first case. I had forgotten to add -alpha on before -channel a.

In the second case, it works as really desired, if I turn alpha off at the end.

This was just a simple test for the more complicated case of trying to linear ramp blend two partially overlapping images. That was my real goal.