Legacy ImageMagick Discussions Archive

This command gets an image that has a partial gradient surrounded by transparency.

But if you autolevel that image...

The sudden appearance of 'black' instead of transparency in the above IS a bug! the default -channel setting should be preventing any change to the alpha channel values.

Replacing the PNG output with 'show:' shows a correct image on screen, so alpha channel is actually correct,
So it looks like the bug is in the PNG coder.

Thanks. However, I'm seeing a black border on both images when I run the commands.

Annoyingly, when I reduced the dimensions for easier debugging (to 8x2 with 1x1 border)
it works as it is supposed to, with a transparent border. On the other hand, 80x2 with
a 1x1 border exhibits the problem. It seems to have something to do with the presence
of 16-bit grey levels that can't be reduced losslessly to 8 bits. ../glennrp

I've checked in a partial fix to the SVN repository for version 6.6.5-10. The Q16 build works properly but the Q8 build still loses the transparency.

Hi,
I discovered the same bug on the Mac OS X binary port, when I found this thread.
A simple on a transparent 32 bit png doesn't retain alpha channel.

I had to install an older version that I had on my hard disk (6.5.0) to fix the problem.

Hoping that it will be fixed soon, a big hello to all the developers and the users as this is my first post here.

Giacomo

I have NO problem with copying a 32-bit PNG with transparency. The result still has its alpha channel. This is IM 6.6.5-10 Q16 (hdri) Mac OSX Tiger

On my system I tryed the two original commands again.

The first again produces an image with correct transparency

The second again produced no transparency.
Using show: instead of saving to PNG for the second command, display transparency so the image being saved does have transparency. PNG is just not saving it!

The problem is NOT fixed in the latest development update.

I have another example of this problem from IM examples...
Image works fine and has transparency (fuzzy transparency)

Cropping and enlarging produces a image whcih has no transparency!
The transparency is definitely missing. however even the colors are not quite correct there should only be perfectly square boxes (pixels) of colors in the above enlarged image, but that is not what is visible in the resulting image. It looks like some type of data corruption is present, beyond simple loss of transparency.

Increasing the crop size to 20x20+0+0 so as to include some more color, and the transparency returns (left column is semi-transparent, top row is near total transparent)


PS: using a crop of 15x15+0+0 also loses transparency, and also includes some of the blue in the output image. so it isn't the lack of color in the image that triggered the problem.

Neither Q8 nor Q16 builds from SVN head are working for me with these cropped rose images.

It certainly appears to have some randomness to it, so I am not surprised we get different results
from the SVN build. The mild corruption of the pixel data itself is also a worry.

I posted a fix for the loss of transparency in the gradient image to the SVN repository (IM-6.6.6-0). I still don't see any transparency in the cropped rose image, however.
The number of colors does have something to do with it. The 10x10 crop has 88 colors and the 15x15 crop has 199 colors so the PNG encoder writes them as paletted
images while the 20x20 has more and is written as an RGBA png. Disabling palette-optimization in the png encoder doesn't affect the result (although the number
of colors is 59 and 132, so the PLTE chunk gets shortened when optimization is enabled). Also, using -sample instead of -scale doesn't change anything.

You may be right about the palette being the case as I only see it when a limited color set is being used.

However... Note that none of the transparency in the later example is fully-transparent. It is ALL semi-transparent. Pallette may not work well in this case! Not unless you are trying to add the multiple semi-transparent color pallette addition (which I believe was a later add on to the PNG implementation).

I believe the cropped-rose image is now being properly converted to PNG,
using the SVN head (will be IM-6.6.6-0). The problem was caused by
transparency being lost in some cases by

• SetImageType(image,PaletteMattetype);

The fix (hopefully temporary) in coders/png.c is to make a clone of
the image, set its ImageType, see if any RGBA colors were lost,
and, if so, don't try to change the ImageType of the basic image.

Glenn,

Also see viewtopic.php?f=1&t=17541&p=66044#p66044

Is that a related issue as Anthony suggests?

The very first set of commands that started this topic are however still not working properly with the later IM from the SVN repository...
convert -version

Version: ImageMagick 6.6.6-2 2010-11-30 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2010 ImageMagick Studio LLC
Features: OpenMP

Note this is really 6.6.6-1 (with whatever has changed since it was released)

That is... Produces a image with transparency but still produces a black outline, though the image output with "show:" does show that the image being saved should have transparency.

The stop gap measure that has been added only works for some images, but not all.

PS: doing both command together also produces an image with transparency, though it should be the same image as the 'failure' one above.

The original problem still produces the same results. Loss of transparency for the second image.

That is reading PNG and writing it again, and the transparency is lost! You don't even need the -auto-level. The taint option does nothing except prevent IM from short circuiting the read and write (converting it into a simple file copy), internally it is just a flag on the image.