Legacy ImageMagick Discussions Archive

I'm trying to list some problems that can occur when writing PNGs in the last IM versions. Some problems were also addressed in other threads lately, e.g.:
viewtopic.php?f=1&t=16267
viewtopic.php?f=3&t=16309
viewtopic.php?f=3&t=16338
viewtopic.php?f=3&t=16238

I'm currently using IM v6.6.2-5 Q16 on Windows XP. Errors that I get in the last versions:
- "invalid background palette index"
- "invalid colormap index"
- "tRNS chunk has out-of-range samples for bit_depth"
- "cannot write image with defined PNG:bit-depth or PNG:color-type" - solved with version 6.6.2-9
- unwanted images, false colors etc. (with or without accompanying error messages)
- sometimes even crashes - solved with version 6.6.2-8
In some cases it's only warnings and sometimes it could be my own bad commands, but still...
I don't know if/how some cases are related, so I'll just list it all in one thread here. (Be warned: This could get long. ) Maybe the.. PNG developers can pick up some issues if they have some time. I hope, my test cases help a bit.
And don't wonder if some strange combinations are listed - I just tried a lot of things as I couldn't achieve the output files that were once possible with an older IM version...


1) 8bit palette PNG with invalid background palette index warning
Magick: Invalid background palette index `logop8.png' @ warning/png.c/PNGWarningHandler/1457.

It's only a warning and the logo image is fine here, but perhaps it hints to another problem..
When I run that command on an older IM version (6.5.8-5), there's no warning. The only difference between these files seems to be the size of the palette. The 6.5.8-5 output contains a 256 colors palette, while the 6.6.2-5 output contains a 232 colors palette - the image itself has these 232 colors. So maybe the index of the bKGD chunk had a too high number. By the way, on v6.6.2-5, the output of "convert logo: PNG:logo.png" doesn't seem to try to write a bKGD chunk, and there's also no warning. Don't know why it changes with the PNG8 ouput.


2) 8bit palette PNG with invalid colormap index error (and invalid background palette index)

First - as comparison - the writing of a 'normal' PNG file... # ImageMagick pixel enumeration: 2,2,255,rgb
0,0: (255,255,255) #FFFFFF white
1,0: (255,255,255) #FFFFFF white
0,1: (255,255,255) #FFFFFF white
1,1: (255,255,255) #FFFFFF white Magick: Invalid background palette index `-' @ warning/png.c/PNGWarningHandler/1457.
# ImageMagick pixel enumeration: 2,2,255,rgb
0,0: (255,255,255) #FFFFFF white
1,0: (255,255,255) #FFFFFF white
0,1: (255,255,255) #FFFFFF white
1,1: (255,255,255) #FFFFFF white
Magick: invalid colormap index `R:/Temp/magick-juCCUOwR' @ error/image.c/SyncImage/3906.

So the PNG8 output shows error messages, but IM still gives the correct pixel values at this point. (By the way: In older IM versions, I get a "memory allocation failed" in such cases.) Other programs already get some random pixel values when reading such an output file. If ones pipes the output through some formats, it even gets visible in IM: Magick: Invalid background palette index `-' @ warning/png.c/PNGWarningHandler/1457.
Magick: invalid colormap index `R:/Temp/magick-IXoV_gK5' @ error/image.c/SyncImage/3906.
# ImageMagick pixel enumeration: 2,2,255,rgb
0,0: (255,255,255) #FFFFFF white
1,0: ( 0, 0, 0) #000000 black
0,1: ( 0, 0, 0) #000000 black
1,1: ( 0, 0, 0) #000000 black

Output image with size 16x16 ("convert -size 16x16 xc:white PNG8:- | convert - BMP:- | convert - white16.png"):

(The upper left pixel is white.)
The output is fine (and without "invalid colormap index") only when the size is bigger than that - so when there are more than 256 pixels.


3) 8bit palette PNG with invalid colormap index error
# ImageMagick pixel enumeration: 2,2,255,rgb
0,0: (255,255,255) #FFFFFF white
1,0: (255,255,255) #FFFFFF white
0,1: ( 0, 0, 0) #000000 black
1,1: ( 0, 0, 0) #000000 black # ImageMagick pixel enumeration: 2,2,255,rgb
0,0: (255,255,255) #FFFFFF white
1,0: ( 0, 0, 0) #000000 black
0,1: ( 0, 0, 0) #000000 black
1,1: (255,255,255) #FFFFFF white
Magick: invalid colormap index `R:/Temp/magick-yL6goPHE' @ error/image.c/SyncIma
ge/3906.

(By the way: In older versions, I got a "invalid number of colors in palette" error - a corrupt image with only a PNG header was written.)


Edit:
Updated status for versions 6.6.2-9 or newer.

Now, I will list some attempts at writing a transparent image as palette PNG. (Only the simplest binary transparency - I didn't even start with partial transparency...)

4) 16bit truecolor+alpha PNG with tRNS chunk warning
Magick: tRNS chunk has out-of-range samples for bit_depth `redblue.png' @ warning/png.c/PNGWarningHandler/1457.

IM apparently can't write it as PaletteMatte, so it reverts to full 16bit truecolor+alpha. The picture stays fine.

5) 8bit truecolor+alpha PNG with tRNS chunk warning
Magick: tRNS chunk has out-of-range samples for bit_depth `redblue.png' @ warning/png.c/PNGWarningHandler/1457.

Here, it still reverts to 8bit truecolor+alpha - the picture is fine.

6) 2bit palette PNG with tRNS chunk warning

Note: This is the output that I desire - but I want it as palette PNG: # ImageMagick pixel enumeration: 2,2,255,rgba
0,0: (255, 0, 0, 0) #FF000000 rgba(255,0,0,0)
1,0: (255, 0, 0, 0) #FF000000 rgba(255,0,0,0)
0,1: ( 0, 0,255,255) #0000FF blue
1,1: ( 0, 0,255,255) #0000FF blue
Magick: tRNS chunk has out-of-range samples for bit_depth `-' @ warning/png.c/PN
GWarningHandler/1457.
# ImageMagick pixel enumeration: 2,2,255,rgb
0,0: (255, 0, 0) #FF0000 red
1,0: (255, 0, 0) #FF0000 red
0,1: ( 0, 0,255) #0000FF blue
1,1: ( 0, 0,255) #0000FF blue

Transparency gets dropped!
In IM v6.6.2-5 it's not successful. But in IM v6.5.8-5, the above command successfully writes a palette PNG with transparency! (But sometimes I seem to get an invalid colormap index error there.)

7) 8bit palette PNG - no transparency and wrong pixel values (without error message)
# ImageMagick pixel enumeration: 2,2,255,rgb
0,0: (255,255,255) #FFFFFF white
1,0: (255,255,255) #FFFFFF white
0,1: ( 0, 0,255) #0000FF blue
1,1: (255,255,255) #FFFFFF white

(I can understand the first two white pixels. These probably get replaced with the background color - and the transparency gets lost. But the lower right white pixel?)

8bit palette PNG with tRNS chunk warning - no transparency and wrong pixel values
Magick: tRNS chunk has out-of-range samples for bit_depth `-' @ warning/png.c/PNGWarningHandler/1457.
# ImageMagick pixel enumeration: 2,2,255,rgb
0,0: ( 0, 0,255) #0000FF blue
1,0: ( 0, 0,255) #0000FF blue
0,1: ( 0, 0,255) #0000FF blue
1,1: ( 0, 0,255) #0000FF blue

OK, ok... The transparent pixels are not safe.
(By the way: My older version shows here a 'invalid colormap index error' and fails with 'cannot write image with defined PNG:bit-depth or PNG:color-type'.)


9) BiLevel

In my despair , I even made some wild tries with '-type BiLevel'. Doesn't make much sense in the above example, but I was interested if I would get an 'ok' image (monochrome of course). But instead I got again random colors!

Perhaps the IM logo gives a better example here:
This works, but now:
??

But back to my normal example:

10) 8bit truecolor PNG - fully opaque and wrong pixel values
# ImageMagick pixel enumeration: 2,2,255,rgba
0,0: (255, 0, 0,255) #FF0000 red
1,0: ( 0,255, 0,255) #00FF00 lime
0,1: ( 0, 0,255,255) #0000FF blue
1,1: (255, 0, 0,255) #FF0000 red

A conversion with color-type 0 or 4 (Grayscale/GrayscaleMatte) gets refused, buth the conversion with type 2 (RGB) was done. OK, so the transparency was not taken, but why again random colors?

EDIT 2: Update for IM v6.6.2-8 or newer
Result is:
# ImageMagick pixel enumeration: 2,2,255,rgba
0,0: (255, 0, 0,255) #FF0000 red
1,0: (255, 0, 0,255) #FF0000 red
0,1: ( 0, 0,255,255) #0000FF blue
1,1: ( 0, 0,255,255) #0000FF blue

The colors are ok now. The 'transparency' could still lead to problems though, as the transparent color in the tRNS chunk is always set to black.

Next tries without transparency:

11) attempt at writing with color-type indexed
On my system, ImageMagick crashes.
(By the way: My older IM version shows a "valid palette required for paletted images" error here and creates a corrupt file.)

Update for v6.6.2-9:
creates a 8bit palette PNG - with false colors # ImageMagick pixel enumeration: 2,2,255,rgb
0,0: (255, 0, 0) #FF0000 red
1,0: ( 0, 0,255) #0000FF blue
0,1: ( 0, 0,255) #0000FF blue
1,1: (255, 0, 0) #FF0000 red
Magick: invalid colormap index `R:/Temp/magick-WR6vUc6w' @ error/image.c/SyncImage/3906.

12) 8bit palette PNG with invalid colormap index error
# ImageMagick pixel enumeration: 2,2,255,rgb
0,0: (255, 0, 0) #FF0000 red
1,0: ( 0, 0,255) #0000FF blue
0,1: ( 0, 0,255) #0000FF blue
1,1: (255, 0, 0) #FF0000 red
Magick: invalid colormap index `R:/Temp/magick-qZzn59mR' @ error/image.c/SyncImage/3906.

Next tries again with transparency:

13) 8bit palette PNG - no transparency and wrong pixel values (without error message)
# ImageMagick pixel enumeration: 2,2,255,rgb
0,0: (255,255,255) #FFFFFF white
1,0: (255,255,255) #FFFFFF white
0,1: ( 0, 0,255) #0000FF blue
1,1: (255,255,255) #FFFFFF white

14) 2bit palette PNG with tRNS chunk warning
Magick: tRNS chunk has out-of-range samples for bit_depth `-' @ warning/png.c/PNGWarningHandler/1457.
# ImageMagick pixel enumeration: 2,2,255,rgb
0,0: (255, 0, 0) #FF0000 red
1,0: (255, 0, 0) #FF0000 red
0,1: ( 0, 0,255) #0000FF blue
1,1: ( 0, 0,255) #0000FF blue

No transparency, but the pixel values are ok.

15) 1bit palette PNG - no transparency and wrong pixel values (without error message)
# ImageMagick pixel enumeration: 2,2,255,rgb
0,0: ( 0, 0, 0) #000000 black
1,0: ( 0, 0, 0) #000000 black
0,1: ( 0, 0,255) #0000FF blue
1,1: ( 0, 0,255) #0000FF blue

The background color (bKGD chunk) in this file is black. The transparent pixels are replaced with the background color. Apart from the dropped transparency, I don't understand why the color reduction changes something here. There are only 2 colors in the image. It almost seems that the palette got reduced, not the actual colors. Because up to '-colors 4', the palette contains 4 colors. Now, there are only 2 colors.

16) attempt with color reduction and PNG8 output
Magick: invalid colormap index `try.png' @ error/image.c/SyncImage/3906.
Magick: Cannot write image with defined PNG:bit-depth or PNG:color-type. `try.png' @ error/png.c/PNGErrorHandler/1437.

0 byte file. (without transparency in the input, it works)

Update for v6.6.2-9:
creates now a 8bit truecolor+alpha PNG - fully transparent and with false colors: Magick: invalid colormap index `-' @ error/image.c/SyncImage/3906.
# ImageMagick pixel enumeration: 2,2,255,rgba
0,0: ( 2, 2,203, 0) #0202CB00 rgba(2,2,203,0)
1,0: ( 40, 4,198, 0) #2804C600 rgba(40,4,198,0)
0,1: ( 1, 1,203, 0) #0101CB00 rgba(1,1,203,0)
1,1: ( 40, 4,198, 0) #2804C600 rgba(40,4,198,0)

With another simple image:

17) 8bit palette PNG - no transparency
# ImageMagick pixel enumeration: 1,2,255,rgb
0,0: (255,255,255) #FFFFFF white
0,1: (255,255,255) #FFFFFF white

It's a bit different here. Could be that ImageMagick only supports binary transparency in PNG8, if all pixels of one color are transparent (or opaque). But my other example - where this was the case - couldn't get written either.
Well, here, apart from dropping the transparency, the image is ok.

18) attempt at writing this image with color reduction and PNG8 output
Magick: tRNS chunk has out-of-range samples for bit_depth `try.png' @ warning/png.c/PNGWarningHandler/1457.
Magick: invalid colormap index `try.png' @ error/image.c/SyncImage/3906.
Magick: Cannot write image with defined PNG:bit-depth or PNG:color-type. `try.png' @ error/png.c/PNGErrorHandler/1437.

0 byte file.

Update for v6.6.2-9: Magick: tRNS chunk has out-of-range samples for bit_depth `-' @ warning/png.c/PN
GWarningHandler/1457.
Magick: invalid colormap index `-' @ error/image.c/SyncImage/3906.
# 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)



So.. Take this image:
convert -size 2x1 xc:red xc:blue -append -transparent red -depth 8 PNG:redblue.png
Is somebody able to write it as palette PNG with the transparency preserved - only with a current ImageMagick?
I couldn't - I only got a lot of errors.

I have also done some other tests with 'normal' palette PNGs (without transparency) and with the background color values.. But I think, this is more than enough now..

Hopefully, someone will be able to make something out of all these messages and images.


Edit 1:
I tried again with the latest IM v6.6.2-7 Q16 (for Windows) - of course, no change.
Edit 2:
Updated cases 10,11,16 and 18 with the results of versions 6.6.2-8 and 6.6.2-9.

On my IM 6.6.2-7 Q16 Mac OSX Tiger, this seems to work and the image is transparent on the red side (left side) and blue on the right side. I get no errors.

convert -size 100x100 xc:red xc:blue +append -transparent red tmp.png
identify -verbose tmp.png


Image: tmp.png
Format: PNG (Portable Network Graphics)
Class: DirectClass
Geometry: 200x100+0+0
Resolution: 72x72
Print size: 2.77778x1.38889
Units: Undefined
Type: PaletteMatte
Endianess: Undefined
Colorspace: RGB
Depth: 16/1-bit
Channel depth:
red: 1-bit
green: 1-bit
blue: 1-bit
alpha: 1-bit
Channel statistics:
Red:
min: 0 (0)
max: 65535 (1)
mean: 32767.5 (0.5)
standard deviation: 32767.5 (0.5)
kurtosis: -2
skewness: 1.33233e-14
Green:
min: 0 (0)
max: 0 (0)
mean: 0 (0)
standard deviation: -0 (-0)
kurtosis: 0
skewness: 0
Blue:
min: 0 (0)
max: 65535 (1)
mean: 32767.5 (0.5)
standard deviation: 32767.5 (0.5)
kurtosis: -2
skewness: 1.33233e-14
Alpha:
min: 0 (0)
max: 65535 (1)
mean: 32767.5 (0.5)
standard deviation: 32767.5 (0.5)
kurtosis: -2
skewness: 1.33233e-14
Image statistics:
Overall:
min: 0 (0)
max: 65535 (1)
mean: 24575.6 (0.375)
standard deviation: 31727 (0.484123)
kurtosis: -1.73333
skewness: 0.516398
Alpha: rgba(255,0,0,0) #FFFF000000000000
Histogram:
10000: ( 0, 0,65535,65535) #00000000FFFF blue
10000: (65535, 0, 0, 0) #FFFF000000000000 rgba(255,0,0,0)


I think this looks good, too.


convert -size 2x2 xc:red xc:blue +append -transparent red miff:- | convert - txt:
# ImageMagick pixel enumeration: 4,2,65535,rgba
0,0: (65535, 0, 0, 0) #FFFF000000000000 rgba(255,0,0,0)
1,0: (65535, 0, 0, 0) #FFFF000000000000 rgba(255,0,0,0)
2,0: ( 0, 0,65535,65535) #00000000FFFF blue
3,0: ( 0, 0,65535,65535) #00000000FFFF blue
0,1: (65535, 0, 0, 0) #FFFF000000000000 rgba(255,0,0,0)
1,1: (65535, 0, 0, 0) #FFFF000000000000 rgba(255,0,0,0)
2,1: ( 0, 0,65535,65535) #00000000FFFF blue
3,1: ( 0, 0,65535,65535) #00000000FFFF blue


Also at depth 8


convert -size 2x2 xc:red xc:blue +append -transparent red -depth 8 miff:- | convert - txt:
# ImageMagick pixel enumeration: 4,2,255,rgba
0,0: (255, 0, 0, 0) #FF000000 rgba(255,0,0,0)
1,0: (255, 0, 0, 0) #FF000000 rgba(255,0,0,0)
2,0: ( 0, 0,255,255) #0000FF blue
3,0: ( 0, 0,255,255) #0000FF blue
0,1: (255, 0, 0, 0) #FF000000 rgba(255,0,0,0)
1,1: (255, 0, 0, 0) #FF000000 rgba(255,0,0,0)
2,1: ( 0, 0,255,255) #0000FF blue
3,1: ( 0, 0,255,255) #0000FF blue

Most of the attempts in this thread have the goal of creating a (binary) transparent image and storing it as palette PNG (which needs a tRNS chunk then). This fails and can produce errors and wrong colors. I wouldn't have a problem if the ImageMagick documentation would say that palette PNGs are not possible with IM. But then, these options should be disabled.

fmw42 wrote:convert -size 100x100 xc:red xc:blue +append -transparent red tmp.png

This creates a 4x16 bit PNG.
You should be suspicious when you see such values:

fmw42 wrote: Depth: 16/1-bit
...
max: 65535 (1)
...

This couldn't get stored in a palette PNG.

I think I agree that it appears not to work. If it do


convert \( -size 100x100 xc:red xc:blue +append -transparent red +dither -colors 2 -depth 8 \) \
\( -clone 0 -alpha extract \) \
\( -clone 0 -background black -flatten -type palette \) \
-delete 0 +swap -alpha off -compose copy_opacity -composite -type palettematte PNG8:tmp1.png
identify -verbose tmp1.png


Image: tmp1.png
Format: PNG (Portable Network Graphics)
Class: PseudoClass
...
Type: Palette
...
Colorspace: RGB
Depth: 8/1-bit
Channel depth:
red: 1-bit
green: 1-bit
blue: 1-bit
Channel statistics:
Red:
min: 0 (0)
max: 0 (0)
mean: 0 (0)
standard deviation: -0 (-0)
kurtosis: 0
skewness: 0
Green:
min: 0 (0)
max: 0 (0)
mean: 0 (0)
standard deviation: -0 (-0)
kurtosis: 0
skewness: 0
Blue:
min: 0 (0)
max: 255 (1)
mean: 127.5 (0.5)
standard deviation: 127.5 (0.5)
kurtosis: -2
skewness: 1.33233e-14
...
Histogram:
10000: ( 0, 0, 0) #000000 black
10000: ( 0, 0,255) #0000FF blue
Colormap: 3
0: ( 0, 0, 0) #000000 black
1: ( 0, 0,255) #0000FF blue
2: (255,255,255) #FFFFFF white

Which has a color map, but is opaque and shows no transparency. Also when displaying the image, there is no transparency, only black where there was red.

Likewise with:

convert \( -size 100x100 xc:red xc:blue +append -transparent red +dither -colors 2 -depth 8 \) \
\( -clone 0 -alpha extract \) \
\( -clone 0 -background black -flatten -type palette \) \
-delete 0 +swap -alpha off -compose copy_opacity -composite PNG8:tmp2.png


and with

convert \( -size 100x100 xc:red xc:blue +append -transparent red +dither -colors 2 -depth 8 \) \
\( -clone 0 -alpha extract \) \
\( -clone 0 -background black -flatten -type palette \) \
-delete 0 +swap -alpha off -compose copy_opacity -composite -type palettematte tmp3.png
identify -verbose tmp3.png


But if I do:


convert \( -size 100x100 xc:red xc:blue +append -transparent red +dither -colors 2 -depth 8 \) \
\( -clone 0 -alpha extract \) \
\( -clone 0 -background black -flatten -type palette \) \
-delete 0 +swap -alpha off -compose copy_opacity -composite tmp4.png
identify -verbose tmp4.png

Image: tmp4.png
Format: PNG (Portable Network Graphics)
Class: DirectClass
...
Type: PaletteMatte
Endianess: Undefined
Colorspace: RGB
Depth: 8/1-bit
Channel depth:
red: 1-bit
green: 1-bit
blue: 1-bit
alpha: 1-bit
Channel statistics:
Red:
min: 0 (0)
max: 0 (0)
mean: 0 (0)
standard deviation: -0 (-0)
kurtosis: 0
skewness: 0
Green:
min: 0 (0)
max: 0 (0)
mean: 0 (0)
standard deviation: -0 (-0)
kurtosis: 0
skewness: 0
Blue:
min: 0 (0)
max: 255 (1)
mean: 127.5 (0.5)
standard deviation: 127.5 (0.5)
kurtosis: -2
skewness: 1.33233e-14
Alpha:
min: 0 (0)
max: 255 (1)
mean: 127.5 (0.5)
standard deviation: 127.5 (0.5)
kurtosis: -2
skewness: 1.33233e-14
...
Histogram:
10000: ( 0, 0, 0, 0) #00000000 none
10000: ( 0, 0,255,255) #0000FF blue

It has an alpha, but shows no color table.

Yeah, one either gets a wrong image or no palette file (or both of this).
Thanks for your confirmations!

PS My tests were on IM 6.6.2-7 Q16 Mac OSX Tiger.

Some PNG issues are also addressed here now:
viewtopic.php?f=1&t=16484

Apart from the crash in my test case #11 (png:color-type=3), one can also get crashes when one tries to write RGBA images as RGB (png:color-type=2).
Try this: Despite the crash on my system (IM v6.6.2-7 Q16, Windows XP), the file gets written:

If I addd '-debug all', it finishes without crash in this example.
This special combination of parameters doesn't make much sense, but perhaps some errors could be catched.

We can reproduce the problem you posted and have a patch in ImageMagick 6.6.2-8 Beta available by sometime tomorrow. Thanks.

Thank you!

Update with IM v6.6.2-8 Q16 (Windows XP):

Drarakel wrote:10) 8bit truecolor PNG - fully opaque and wrong pixel values

Code: Select all

convert -size 2x1 xc:red xc:blue -append -transparent red -depth 8 -define png:color-type=2 PNG:- | convert - txt:-

# ImageMagick pixel enumeration: 2,2,255,rgba
0,0: (255, 0, 0,255) #FF0000 red
1,0: ( 0,255, 0,255) #00FF00 lime
0,1: ( 0, 0,255,255) #0000FF blue
1,1: (255, 0, 0,255) #FF0000 red

A conversion with color-type 0 or 4 (Grayscale/GrayscaleMatte) gets refused, buth the conversion with type 2 (RGB) was done. OK, so the transparency was not taken, but why again random colors?

Drarakel wrote:Apart from the crash in my test case #11 (png:color-type=3), one can also get crashes when one tries to write RGBA images as RGB (png:color-type=2).
Try this:

Code: Select all

convert -size 17x8 xc:red xc:blue -append -transparent white -depth 8 -define png:color-type=2 redblue.png

Despite the crash on my system (IM v6.6.2-7 Q16, Windows XP), the file gets written:

If I addd '-debug all', it finishes without crash in this example.
This special combination of parameters doesn't make much sense, but perhaps some errors could be catched.

These two cases with color-type 2 show no crashes or wrong pixel values anymore, but I'm still not sure if the output is correct.

Example: # ImageMagick pixel enumeration: 2,2,255,rgba
0,0: ( 0, 0, 0, 0) #00000000 none
1,0: ( 0, 0, 0, 0) #00000000 none
0,1: (255, 0, 0,255) #FF0000 red
1,1: (255, 0, 0,255) #FF0000 red

Now the black pixels are transparent - not the red ones! Explanation: ImageMagick creates a RGB (3x8bit in this case) file, and if transparency is detected, an additional tRNS chunk gets written. But the value of the tRNS chunk isn't updated. It's always set to black. Perhaps the transparency of the actual input image could get used. Or - if transparency is not ok in IM with color-type 2, then the tRNS chunk shouldn't get written, I think.

Drarakel wrote:11) attempt at writing with color-type indexed

Code: Select all

convert -size 2x1 xc:red xc:blue -append -depth 8 -define png:color-type=3 PNG:try.png

On my system, ImageMagick crashes.
(By the way: My older IM version shows a "valid palette required for paletted images" error here and creates a corrupt file.)

No crash anymore. IM now fails with:
Magick: Valid palette required for paletted images `try.png' @ error/png.c/PNGErrorHandler/1437.
And creates only a PNG header.


All other cases/errors stay the same.

We can reproduce the problem you posted and have a patch in ImageMagick 6.6.2-9 Beta available by sometime tomorrow. Thanks.

Thanks for the new version.
Could you describe the (next) changes that you apply to a new IM version a bit more? Just a wish... Because otherwise, I always have to wait for the new release version and re-check all my cases. And then this could become a very long thread - for me and you.

Update with IM v6.6.2-9 Q16 (Windows XP) - for case 11:

Drarakel wrote:No crash anymore. IM now fails with:
Magick: Valid palette required for paletted images `try.png' @ error/png.c/PNGErrorHandler/1437.
And creates only a PNG header.

The above error is gone - another error takes its place: # ImageMagick pixel enumeration: 2,2,255,rgb
0,0: (255, 0, 0) #FF0000 red
1,0: ( 0, 0,255) #0000FF blue
0,1: ( 0, 0,255) #0000FF blue
1,1: (255, 0, 0) #FF0000 red
Magick: invalid colormap index `R:/Temp/magick-NLz1Q-T0' @ error/image.c/SyncImage/3906.

See posts 1 and 2 for all updated cases!


By the way:
"png:bit-depth" settings 4,2 and 1 are 'working' now - but I'm not sure if it's the intended behaviour:
http://www.imagemagick.org/Usage/formats/#png_write

-define png:bit-depth={depth}
[...]In the case of colormapped images, this is the depth of the colormap indices, not of the color samples.

At the moment, settings 4,2 and 1 alway seem to create 8bit indices (not smaller) in a palette PNG.

some information is posted (though rather terse) at http://www.imagemagick.org/script/changelog.php after each release

Yeah, sure, but I just wish I could directly know which problem was fixed with a "the problem you posted" sentence.