ImageMagick-6.6.0-10 doesn't import bw png transparency

[nathanjd]

When converting/importing a grayscale png with transparency ImageMagick-6.6.0-10 makes all transparency white and opens the file with image type GrayscaleType, not GrayscaleMatteType. Any use of convert grayscaleTrans.png *, or use of RMagick causes this loss of transparency. Downgrading to 6.5.8-10 resolves this issue.

[fmw42]

post your command line and your input and output images so the IM folks and others can test.

[fracai]

I'm seeing the same (similar?) issue with 6.6.1-0 from MacPorts and 6.6.1-3 when compiled from source on Mac OS X 10.6.3 and RHEL 5.4

Code: Select all

convert IceAlpha-0.5.png IceAlpha-0.5.convert.png

Input:

Output:


This also manifests when trying to overlay a PNG on another image. The PNG looses transparency and completely covers the lower image.
Not all PNGs are affected however, notable the logo output converts fine:

Code: Select all

convert logo: -transparent white logo.png

[fmw42]

I confirm this on IM 6.6.1-3 Q16 Mac OSX Tiger.

One possibility is that this might be an issue related to the backwards identification of alpha in the verbose info, per my bug report at viewtopic.php?f=3&t=16031

from your original image:

identify -verbose IceAlpha-0.5.png
Image: IceAlpha-0.5.png
Format: PNG (Portable Network Graphics)
Class: DirectClass
Geometry: 480x430+0+0
Resolution: 72x72
Print size: 6.66667x5.97222
Units: Undefined
Type: PaletteMatte
Endianess: Undefined
Colorspace: RGB
Depth: 8-bit
Channel depth:
red: 8-bit
green: 8-bit
blue: 8-bit
alpha: 1-bit
Channel statistics:
Red:
min: 0 (0)
max: 255 (1)
mean: 95.1034 (0.372954)
standard deviation: 55.0421 (0.215852)
kurtosis: -0.076278
skewness: -0.196863
Green:
min: 0 (0)
max: 255 (1)
mean: 148.773 (0.583423)
standard deviation: 63.7851 (0.250137)
kurtosis: -0.323475
skewness: -0.955647
Blue:
min: 0 (0)
max: 255 (1)
mean: 189.696 (0.743905)
standard deviation: 81.003 (0.317659)
kurtosis: -0.238517
skewness: -1.14006
Alpha:
min: 255 (1)
max: 255 (1)
mean: 255 (1)
standard deviation: -0 (-0)
kurtosis: 0
skewness: 0


Alpha being 255 (1) means totally opaque, but the image is not and has some transparency


Another more likely possibility is that this appears to be an 8-bit palettematte image, which likely means that it does not have a real alpha channel, but some color has been set to transparent in the 8-bit color palette.


This will probably need to go to the PNG expert to figure out what is really happening.

How (what softwared) did you use to create this image and especially how did you set the transparency?


see discussion at viewtopic.php?f=1&t=15584&p=55396&hilit ... ncy#p55396 about such palette images with transparency set for a given color rather than as an overlay

[snibgo]

Under Windows 7, I get fracai's broken behaviour in IM 6.6.1-1 Q8, but not under 6.6.0-8 Q16.

[fracai]

How (what softwared) did you use to create this image and especially how did you set the transparency?

I grabbed this example from another thread on the IM boards: viewtopic.php?f=3&t=15482
The original comes from here: http://www.libpng.org/pub/png/png-IceAlpha.html

[fmw42]

It does not work in IM 6.6.1-4 Q16 Mac OSX tiger even after the bug in the verbose info has been fixed. So it is more likely the palettematte issue or some other problem.

[fracai]

Under Windows 7, I get fracai's broken behaviour in IM 6.6.1-1 Q8, but not under 6.6.0-8 Q16.

I recently tested several versions of 6.6.0-x and I'm seeing that 6.6.0-8 as the first to exhibit this problem (6.6.0-0 -- 6.6.0-7 are fine). The -8 release includes several changes to coders/png.c. I haven't determined a specific change that is causing the problem, though after a naive overview I suspect it involves ping_info->trans_alpha.

[magick]

We can reproduce the problem and will have a patch in ImageMagick 6.6.1-5 Beta by sometime tomorrow. Thanks.