Page 1 of 1
possible bug or misunderstanding with -composite
Posted: 2010-04-30T09:16:37-07:00
by fmw42
IM 6.6.1-5 Q16 Mac OSX Tiger
I am getting some inconsistent results with composite. Perhaps I misunderstand.
#This works as expected and produces the correct result for tmp3a.png
convert -size 20x360 gradient: -rotate 90 tmp1a.png
convert -size 20x20 xc:red -background none -gravity east -extent 360x20 tmp2a.png
convert tmp1a.png tmp2a.png -compose over -composite tmp3a.png
#This does not produce the correct final result for tmp3b.png. It is mostly black rather than mostly gradient.
convert -size 20x360 gradient: -rotate 90 tmp1b.png
convert -size 20x20 xc:gray -background none -gravity east -extent 360x20 tmp2b.png
convert tmp1b.png tmp2b.png -compose over -composite tmp3b.png
Is this a bug, or am I misunderstanding or missing something here?
Re: possible bug or misunderstanding with -composite
Posted: 2010-05-01T10:20:44-07:00
by rockcreekdan
Just a couple of data points:
It works as you expect with the ImageMagick in Ubuntu 8.10, which is this version:
Version: ImageMagick 6.3.7 06/04/09 Q16
http://www.imagemagick.org
Also this version accessed via wine:
Version: ImageMagick 6.4.8-8 2009-01-22 Q16 OpenMP
http://www.imagemagick.org
But fails with version this accessed via wine:
Version: ImageMagick 6.6.1-5 2010-04-23 Q16
http://www.imagemagick.org
Re: possible bug or misunderstanding with -composite
Posted: 2010-05-01T10:38:24-07:00
by fmw42
Thanks for confirming. I had a feeling this was a recent issue.
Re: possible bug or misunderstanding with -composite
Posted: 2010-05-01T12:09:49-07:00
by snibgo
It works fine in 6.6.0-8 Q16 and 6.6.1-1 Q8, and 6.5.8-8 Q16 (all on Windows 7).
Re: possible bug or misunderstanding with -composite
Posted: 2010-05-02T00:33:32-07:00
by anthony
I don't know if this is the issue or it was a failed attempt to correct the issue but greyscale PNG images with transparencies are now failing.
This works... Black rectangle with transparency
convert -size 64x64 xc:none -draw 'rectangle 0,20 63,43' miff:- | display -
This does not -- all black!
convert -size 64x64 xc:none -draw 'rectangle 0,20 63,43' png:- | display -
This problem is especially difficult for me as I was just starting to do some programming of compose mathemathics methods (nothing submitted yet) where a special flag gets compose to ignore the default SVG color-transparency linkages, and just treat all -channel specified channels as independant greyscale images.
This ability is needed for correct handling of some more complex morphology operators such as the 'difference' morphology operators.
http://www.imagemagick.org/Usage/morphology/#difference
The same flag could also be used for the 'blur', gaussian, and 'convolve' handling for transparency, so that by default -blur would correctly blur images containing transparency, unless otherwise specified, the same goes for -negate so it ignores transparency by default. These things has always been a 'problem' for correct 'default' handling of images, especially by 'novice' users who has never previously used '-channel', and to me that may be good thing in the long term.
Re: possible bug or misunderstanding with -composite
Posted: 2010-05-04T11:40:39-07:00
by fmw42
Has glennrp looked into the PNG issue?
Re: possible bug or misunderstanding with -composite
Posted: 2010-05-04T18:21:26-07:00
by anthony
Cristy said he will look into it for the next weekend.
The issue however appears to be more than just PNG but also MIFF..
output PNG with greyscale and transparency ==> PNG with no transparency.
Code: Select all
convert -size 64x64 xc:none -fill white -draw 'rectangle 0,20 63,43' \
png:- | display -
Any color in the PNG and all is fine.
Code: Select all
convert -size 64x64 xc:none -fill red -draw 'rectangle 0,20 63,43' \
png:- | display -
however output and read a miff image containing only greyscale, then draw color
and the whole image goes crazy!
Code: Select all
convert -size 64x64 gradient: miff:- |-
convert - -stroke blue -draw 'line 60,5 5,60' show:
If I draw any gray color - no problem...
Code: Select all
convert -size 64x64 gradient: miff:- |-
convert - -stroke grey -draw 'line 60,5 5,60' show:
I have modified my compose method testing script "compose_tables"
http://www.imagemagick.org/Usage/scripts/compose_tables
to work around both problems and I am now debugging new Compose changes.
Compose Changes....
- ALL mathematical operations by default are now SVG complient, using 'Over' blending
to determine Alpha channel handling and its effects on Semi-transparent Colors.
That includes Plus, Minus, Add, and Subtract
(Note that also means by default Plus and LinearDodge are equivelent except... see below)
- Add and Subtract are renamed ModulusAdd and ModulusSubtract to avoid confusion.
The old names will still work but will be removed from all documentation and '-list compose' output.
- Use of special flag 'sync' for -channel settings (present by default) to be understood by
all mathematical compose methods (not lighting methods)
This flag means 'handle colors in sync with each other and alpha'.
If not set (such as when you specifically change the -channel setting) then each channel will
be composed without any inter-channel effects. Color channels are treated as separate grey scale
images, and alpha does not effect colors.
For mathematical compositions, the channels specified (including alpha) will be simply composed using the appropriate mathematical operation. If the 'sync' flag is present, then channels are ignored and SVG compliant composition will be used.
This same effect of 'sync' should eventually be used for other things including 'blur' and convolve.
That is by default (sync channel flag is set) alpha channel effects color channels. If the flag is not set channels are separate. Much better than the current need to set RGBA for what should be normal image blur transparency handling.
Re: possible bug or misunderstanding with -composite
Posted: 2010-05-04T18:28:26-07:00
by fmw42
actually in my script, I was using mpc and having the same problem. I got around it by inserting a color and then at the end replacing the color with gray values. But it is an extra unnecessary step. But I can leave it until it is properly fixed. I just wanted to point out the problem.