Legacy ImageMagick Discussions Archive

Any news on the PNG bugs?
There can be still a lot of errors (see posts 1 and 2) in the current PNG output and PNG8 for example doesn't seem to be able to handle transparency at all.
If this causes a lot of work, then I think the affected options should be disabled. (Maybe indexed PNGs should be disabled completely? With that, PNGs could still be written, but the creation of potentially corrupted files could be avoided.) Or at least the documentation should be updated with some warnings in the meantime..?

On ubuntu lucid, 6.5.9-10 creates proper PNG8s using

convert -size 200x100 xc:red xc:blue -append -transparent red -type palettematte -depth 8 PNG8:redblue.png

6.6.0-10 breaks the PNG8 transparency support, and the failure continues to 6.6.3-4.

If I replace the 6.6.0-10 version of coders/png.c with that from 6.5.9-10 and rebuild, PNG8 transparency functions correctly. Since the delta between the two versions is extensive, I was not able to trivially isolate the root cause.

Update for IM v6.6.3-5 (Q16):
All the errors are the same. I only get some varying random colors in some of the cases. And there's an additional warning message (that also pops up in two of my former examples).

Drarakel wrote:16) attempt with color reduction and PNG8 output
[...]
Update for v6.6.2-9:
creates now a 8bit truecolor+alpha PNG - fully transparent and with false colors:

Code: Select all

convert -size 2x1 xc:red xc:blue -append -transparent red -depth 8 +dither -colors 3 PNG8:- | convert - txt:-

The output from this command is now:
Magick: invalid colormap index `-' @ error/image.c/SyncImage/3936.
Magick: Cannot write image with defined PNG:bit-depth or PNG:color-type. `-' @ warning/png.c/PNGWarningHandler/1503.
# ImageMagick pixel enumeration: 2,2,255,rgba
0,0: ( 2, 2, 0, 0) #02020000 rgba(2,2,0,0)
1,0: (136, 1,198, 0) #8801C600 rgba(136,1,198,0)
0,1: ( 1, 1, 0, 0) #01010000 rgba(1,1,0,0)
1,1: (136, 1,198, 0) #8801C600 rgba(136,1,198,0)

Drarakel wrote:18) attempt at writing this image with color reduction and PNG8 output
[...]
Update for v6.6.2-9:

Code: Select all

convert xc:"rgba(255,255,255,0.0)" xc:"rgba(255,255,255,1.0)" -append -depth 8 -colors 256 PNG8:- | convert - txt:-

With a modified version of this example (so that the pixels of one color have only one transparency value), the error stays the same (there's only this additional "cannot write image" warning - as IM reverts to a 8bit truecolor+alpha PNG, but again a corrupt one): Magick: tRNS chunk has out-of-range samples for bit_depth `-' @ warning/png.c/PNGWarningHandler/1503.
Magick: invalid colormap index `-' @ error/image.c/SyncImage/3936.
Magick: Cannot write image with defined PNG:bit-depth or PNG:color-type. `-' @ warning/png.c/PNGWarningHandler/1503.
# ImageMagick pixel enumeration: 1,2,255,rgba
0,0: ( 2, 1,198, 0) #0201C600 rgba(2,1,198,0)
0,1: ( 1, 1,198, 0) #0101C600 rgba(1,1,198,0)

Another simple example for this behaviour (of course, this shows only some of the possible PNG errors - not all of them): Magick: invalid colormap index `logo2.png' @error/image.c/SyncImage/3936.
Magick: Cannot write image with defined PNG:bit-depth or PNG:color-type. `logo2.png' @ warning/png.c/PNGWarningHandler/1503.

Result:



Some of the issues in this thread have already been fixed. Thanks!
Are there any plans to address the remaining main PNG errors in the next IM versions?
Can we normal users help somehow in finding the cause of these issues?

I found a work around for this issue. If you call

convert input.png -colors 256 output.png

identify -vebose output.png

then check the identify output for "
Transparent color: none"

if Transparent color: black then call

convert input.png -colors 255 output.png

so far this has worked and the image has Transparent color: none

does anybody know a better way to do this? Maybe in one command/call?

This in many ways is what GIF transparency handling should do.

It is also what should happen for PNG8 image file format. So this
should be the equivelent... The PNG image however will be a smaller 8 bit/pixel indexed image, rather a 24 bit/pixel RGB image.
NOTE the 'bits' given here is not the same as depth, which is in termes of bits/value, not bits/pixel.
See IM Examples, Depth
http://www.imagemagick.org/Usage/basics/#depth

If it is not doing this correctly make a bug report in the bugs forum.

see http://www.imagemagick.org/Usage/formats/#png_formats and http://www.imagemagick.org/Usage/formats/#png_write

Several of the problems you posted seem to be working now (1, 2, 3, 4, 11, 12). Some are working better but not entirely correctly yet (6, 13, 14). One is worse--it fails an asserition now (8). The fixes are in the svn repository and should appear in the next beta release. Thanks for the test cases; they are quite useful.

I am currently struggling with converting png image to black&white. I've took a peek at the link fmw42 gave ( http://www.imagemagick.org/Usage/formats/#png_write ) and there is an example:

And for a simple two color image...
convert {input_image} -type BiLevel bitmap.png

So I tested this call, and in effect I get RGB file, with image squeezed into left half, the right half was entirely black. IM 6.6.5-4.

Either the example is wrong, or IM.

post a link to your image so others can test. did you try -monochrome or -threshold before -type bilevel?

No, I didn't try it -- I prepared the test image using Gimp. Steps how to reproduce it:

For blank image:
1. create white, blank image
2. set the color space to RGB
3. save

For image with content:
1. open any image
2. convert it to indexed colorspace, black&white
3. convert it to RGB color space
4. save

At this point you will have image with max. 2 colors used with RGB color space. If you run IM now with options:
convert {input_image} -type BiLevel bitmap.png

You will get the strange effects I described above.

Btw. my understanding of threshold and monochrome is it "prepares" image to further convertion to indexed b&w image. I.e. it limits colors usage to 2 colors, but it does not convert the colorspace.

Just in case -- I tried bilevel also in conjunction with other options, namely:
-type bilevel -define png:color-type=3 -define png:bit-depth=1

Which should give me indexed, b&w image, but instead I get error:
convert: Cannot write image with defined PNG:bit-depth or PNG:color-type.

Most of the numbered test cases above are now working. Transparency is no
longer lost, and only cases 15 and 16 are producing incorrect colors. Both produce
the expected result with "-colors 4" instead of "-colors 3".

The SVN repository has been fixed and the next beta and point release will
contain the fixes.

Ok, now I test IM 6.6.6-4

Both calls (see previous post) produce correct (visually) outputs now, however the second call still gives error/warning:
convert: Cannot write image with defined PNG:bit-depth or PNG:color-type. `x.png' @ warning/png.c/PNGWarningHandler/1350.

Despite this, the image is written.

But now what is inside the images:
* first case -- the image is still grayscale, same size
* second case -- the image is indexed (good), but the size is much bigger than grayscale (!) -- I checked the depth, and it was 8bpp instead of 1

So, still something is wrong -- IM cannot convert the image which contains b&w data to b&w png (i.e., indexed, 2 colors).