compose alpha broken on 6.6.5-10 & 6.6.6-3? 6.6.4-10 OK

[geep999]

Hi,
I'm using ImageMagick within a script to build DVD menus on Linux Slackware-current x86_64 & Slackware-13.0 x86_64.h (The script is the makemenu script within tovid from: http://tovid.wikia.com/wiki/Tovid_Wiki)

I recently upgraded to ImageMagick 6.6.6-3 and have problems; it seems the alpha channel handling with compose is broken. I have created 2 sample commands based on tovid's makemenu script which shows the problem:

Code: Select all

composite -compose Src -gravity center 03_active-highlight.png bg_canvas.png highlight.png
composite -compose Over -gravity center highlight.png menu.ppm result.png

A copy of all my files and results are here: http://jtv.voila.net/imbug/index.html

The last good version for me is 6.6.4-10. Both 6.6.5-10 & 6.6.6-3 show the same problem visually, but the files produced have wildly different sizes.

Code: Select all

  2759 2010-12-10 12:32 6.6.4-10/highlight.6.6.4-10.png
496799 2010-12-10 12:32 6.6.4-10/result.6.6.4-10.png
  3742 2010-12-10 12:33 6.6.5-10/highlight.6.6.5-10.png
  2024 2010-12-10 12:33 6.6.5-10/result.6.6.5-10.png
   822 2010-12-10 12:34 6.6.6-3/highlight.6.6.6-3.png
   519 2010-12-10 12:34 6.6.6-3/result.6.6.6-3.png

At the above link I also included the results of "identify -verbose", which seems to point to alpha channel problems.

highlight.png should be transparent with 4 orange triangles.
It is now black with 4 orange triangles.

result.png should be white with a photo in the centre, some text and 4 orange triangles.
It is now black with 4 orange triangles.

I think this is a bug, unless the functionality of compose has been deliberately changed.

Cheers,
Peter

[fmw42]

It might be related to PNG problems that have been worked on for the last few releases. See changelog at http://www.imagemagick.org/script/changelog.php

Perhaps try a different output format.

[anthony]

Or save using PNG32:image.png to force it away from the buggy area, until it is fixed.
Please keep your IM up to date as it is being worked on.

[glennrp]

I've just checked a fix in to the SVN repository. Look for it in 6.6.6-5.

[geep999]

1/ I just installed the svn version 3279. No change - the problem still exists.
I did an "identify -verbose" and compared the results from svn 3279 & 6.6.6-4 - they are functionally identical.
ImageMagick reports itself as: Version: ImageMagick 6.6.6-5 2010-12-11 Q16 http://www.imagemagick.org

2/ Forcing the type with PNG32:xxx.png worked OK for all versions tested, including svn 3279.

Cheers,
Peter

[glennrp]

The fix I referred to was SVN revision 3283. I made further mods in 3284 and 3291 but all 3 should produce the same good result.

[geep999]

svn-3284 gives good results visually. I couldn't find 3291:
svn co -r 3291 https://www.imagemagick.org/subversion/ ... gick/trunk ImageMagick
svn: No such revision 3291

Taking 6.6.4-10 as my reference point, the filesizes are thus:

Code: Select all

  2759 2010-12-10 12:32 6.6.4-10/highlight.6.6.4-10.png
496799 2010-12-10 12:32 6.6.4-10/result.6.6.4-10.png
  2759 2010-12-12 12:31 6.6.svn-3284/highlight.6.6.svn-3284.png
548014 2010-12-12 12:31 6.6.svn-3284/result.6.6.svn-3284.png

Comparing "identify -verbose" output I see no functional differences between:
1 <! Image: 6.6.4-10/highlight.6.6.4-10.png
and
2 !> Image: 6.6.svn-3284/highlight.6.6.svn-3284.png

But there are functional differences between:
107 <! Image: 6.6.4-10/result.6.6.4-10.png
and
109 !> Image: 6.6.svn-3284/result.6.6.svn-3284.png
thus:
116 <! Type: TrueColor
117 !> Type: TrueColorMatte
125 !> alpha: 1-bit
148 !> Alpha:
149 !> min: 255 (1)
150 !> max: 255 (1)
151 !> mean: 255 (1)
152 !> standard deviation: 0 (0)
153 !> kurtosis: 0
154 !> skewness: 0
159 <! mean: 145.919 (0.57223)
160 <! standard deviation: 74.3434 (0.291543)
161 <! kurtosis: -0.992045
162 <! skewness: -0.00533859
163 !> mean: 109.439 (0.429172)
164 !> standard deviation: 64.3832 (0.252483)
165 !> kurtosis: 3.8061
166 !> skewness: 0.648305
170 <! Border color: rgb(223,223,223)
171 !> Border color: rgba(223,223,223,1)
173 <! Transparent color: black
174 !> Transparent color: none

(You can see this more clearly by copy and pasting:
http://jtv.voila.net/imbug/identify.6.6.4-10.txt & http://jtv.voila.net/imbug/identify.6.6.svn-3284.txt
into: http://solidcodingarchive.appspot.com/r ... etDiff.htm
or just look at:
http://jtv.voila.net/imbug/6.6.4-10.vs. ... -3284.diff using KDE's kompare )

All results are here: http://jtv.voila.net/imbug/index.html

Cheers,
Peter

[glennrp]

The filesize of result.png should be OK now, about 497.8k as before, with SVN revision 3395

[geep999]

Broken again in 6.6.7-0
Was OK in 6.6.6-5
See examples: http://jtv.voila.net/imbug/index.html

Cheers,
Peter

[glennrp]

It seems to be working for me, both 6.6.7-0 and 6.6.7-1 (your "first command tested").
For the "second command" it's not clear where is the source for "highlight.png". Is
it the same as "03_active_highlight.png"?

[geep999]

The commands are:
composite -compose Src -gravity center 03_active-highlight.png bg_canvas.png highlight.png
# highlight.png from above is then used in the command below. Of course, if highlight.png is bad, then result.png is bad too.
# On my web pages I put the ImageMagick version into the filenames. e.g. highlight.6.6.7-0.png result.6.6.7-0.png
composite -compose Over -gravity center highlight.png menu.ppm result.png

I have rebuilt 6.6.7-0 on several different Slackwares and always get bad results.
Just now built 6.6.6-9 on Slackware 13.0 x86_64 and get good results with it.
And 6.6.6-9 which is pre-installed on Slack Current is good too.
And re-rebuilt 6.6.7-0 on Slackware 13.0 x86_64 - still bad.
For building I am using the SlackBuild scripts that come with the Slackware distribution.

Noticed an anomaly with filesizes - the bad files on my web page from 15 Jan are bigger than today's. I can't explain this.

Used: Slackware 13.0 64bit, Slackware 13.1 32bit, Slackware Current 64 bit. The red ones are good.
819 2011-01-17 12:47 highlight.6.6.6-9.slack13.0.64bit.png
819 2011-01-17 10:45 highlight.6.6.6-9.slackcurrent.64bit.png
806 2011-01-17 12:58 highlight.6.6.7-0.slack13.0.64bit.png
806 2011-01-17 10:34 highlight.6.6.7-0.slack13.1.32bit.png
806 2011-01-17 11:21 highlight.6.6.7-0.slackcurrent.64bit.png
496817 2011-01-17 12:47 result.6.6.6-9.slack13.0.64bit.png
496817 2011-01-17 10:46 result.6.6.6-9.slackcurrent.64bit.png
482 2011-01-17 12:58 result.6.6.7-0.slack13.0.64bit.png
482 2011-01-17 10:34 result.6.6.7-0.slack13.1.32bit.png
482 2011-01-17 11:21 result.6.6.7-0.slackcurrent.64bit.png

Below are diffs between "identify -verbose" for highlight.6.6.6-9.slack13.0.64bit.png & highlight.6.6.7-0.slack13.0.64bit.png.
Also md5 sums. I get exactly the same results from 6.6.7-0 and 6.6.6-9 on all version of Slackware used.

Cheers,
Peter

1 <! Image: highlight.6.6.6-9.slack13.0.64bit.png
2 !> Image: highlight.6.6.7-0.slack13.0.64bit.png
4 <! Class: DirectClass
5 !> Class: PseudoClass
10 <! Type: PaletteMatte
11 !> Type: Palette
19 <! alpha: 1-bit
42 <! Alpha:
43 !> Image statistics:
44 !> Overall:
47 <! mean: 0.590278 (0.00231481)
48 <! standard deviation: 12.2545 (0.0480568)
49 <! kurtosis: 427.002
50 <! skewness: -20.7124
51 <! Image statistics:
52 <! Overall:
53 <! min: 0 (0)
54 <! max: 255 (1)
55 <! mean: 63.8455 (0.250374)
56 <! standard deviation: 9.52916 (0.0373693)
57 <! kurtosis: 41996.3
58 <! skewness: 1793.33
59 <! Alpha: none #00000000
60 !> mean: 0.324074 (0.00127088)
61 !> standard deviation: 8.42709 (0.0330474)
62 !> kurtosis: 753.145
63 !> skewness: 27.0551
65 <! 413760: ( 0, 0, 0, 0) #00000000 none
66 <! 960: (255,165, 0,255) #FFA500 orange
67 !> 413760: ( 0, 0, 0) #000000 black
68 !> 960: (255,165, 0) #FFA500 orange
69 !> Colormap: 2
70 !> 0: ( 0, 0, 0) #000000 black
71 !> 1: (255,165, 0) #FFA500 orange
75 <! Border color: rgba(223,223,223,1)
76 !> Border color: rgb(223,223,223)
78 <! Transparent color: none
79 !> Transparent color: black
88 <! date:create: 2011-01-17T12:56:42+00:00
89 <! date:modify: 2011-01-17T12:47:19+00:00
90 !> date:create: 2011-01-17T13:07:07+00:00
91 !> date:modify: 2011-01-17T12:58:22+00:00
106 <! signature: 8c1c5ad20f0a604d4b5c8655d7e24be3864eb5c2a3ab8f4659d5c6226674f213
107 !> signature: c03b46f31ba0b1517b8db3e71fe4ac4314bf9a659643ca5282c8d635fffb0208
113 <! Filesize: 819BB
114 !> Filesize: 806BB
117 <! User time: 0.010u
118 !> User time: 0.000u

md5sum *png
a988473370a63528ee8dd7aeac93a946 highlight.6.6.6-9.slack13.0.64bit.png
a988473370a63528ee8dd7aeac93a946 highlight.6.6.6-9.slackcurrent.64bit.png
10dd090bdf7c05cb17d217dc0a78bb65 highlight.6.6.7-0.slack13.0.64bit.png
10dd090bdf7c05cb17d217dc0a78bb65 highlight.6.6.7-0.slack13.1.32bit.png
10dd090bdf7c05cb17d217dc0a78bb65 highlight.6.6.7-0.slackcurrent.64bit.png
2c87d9f6babffd02d0240b28a7bbd377 result.6.6.6-9.slack13.0.64bit.png
2c87d9f6babffd02d0240b28a7bbd377 result.6.6.6-9.slackcurrent.64bit.png
7b4afa26fd0405796938f0322203a47d result.6.6.7-0.slack13.0.64bit.png
7b4afa26fd0405796938f0322203a47d result.6.6.7-0.slack13.1.32bit.png
7b4afa26fd0405796938f0322203a47d result.6.6.7-0.slackcurrent.64bit.png

[glennrp]

I can reproduce your result. What's happening is that in 6.6.7 the PNG decoder examines the input file and if it has no transparent pixels, image->matte is turned off. That doesn't work with -compose Src when the base image is opaque and the change image has transparency, which is the case here. I could fix it by removing the new code, but that breaks the much more usual case where people convert a PNG32 to png, when the PNG32 actually doesn't have any transparent pixels. So I need to come up with a more comprehensive fix. Hopefully it's just a matter of leaving image->matte turned on if it's already on when we enter the PNG decoder. I'll try to get that ready for 6.6.7-2 but I'm not guaranteeing that.

[anthony]

I would consider this a usage fault not a fault in the PNG coder.

Compose SRC could generate transparency where none existed. As such the user should be making sure alpha
is enabled on the images involved. The same goes for many other Duff-Porter Composition methods.

I even specifically mention the use of -alpha set in the section on 'Src' compose method

This problem is mentioned many times in many situations, and it typically obvious when it happens.

See IM Examples, Duff Porter Composition...
http://www.imagemagick.org/Usage/compose/#duff-porter

and specifically on 'Src' Composition
http://www.imagemagick.org/Usage/compose/#src

Both the -alpha and -matte operators are available in "composite" and should be used when transparency problems from the composition is possible as it is with many compose methods.

[glennrp]

This works for me:

Code: Select all

composite -compose Src -gravity center 03_active-highlight.png bg_canvas.png -matte highlight.png

I did manage to prevent the png encoder from losing the transparency, but the change broke several other test cases so I haven't checked in the change.

[geep999]

With 6.6.7-0 using both -matte and -alpha set give me identical results according to md5sum:
composite -compose Src -gravity center 03_active-highlight.png bg_canvas.png -matte highlight.matte.png
composite -compose Src -gravity center 03_active-highlight.png bg_canvas.png -alpha set highlight.alphaset.png
a988473370a63528ee8dd7aeac93a946 highlight.alphaset.png
a988473370a63528ee8dd7aeac93a946 highlight.matte.png

This is the same result as I was getting with 6.6.6-9 without either -matte or -alpha set
a988473370a63528ee8dd7aeac93a946 highlight.6.6.6-9.slack13.0.64bit.png
a988473370a63528ee8dd7aeac93a946 highlight.6.6.6-9.slackcurrent.64bit.png

I think I'll suggest to the author of the DVD titleing script "tovid" to make a change so that it doesn't break with some ImageMagicks. Does it matter which option to use -matte vs -alpha set? I'm a bit hazy on all this transparency stuff!

Cheers,
Peter