Legacy ImageMagick Discussions Archive

My source image is a 96x96 png file with transparency:

creates a file that looks fine:

but actually appears to be corrupted when opened in PhotoShop:


However if I specify PNG32, the result is correct:

identify says:
source.png PNG 96x96 96x96+0+0 8-bit DirectClass 754B 0.000u 0:00.000
result.png PNG 48x48 48x48+0+0 8-bit PseudoClass 110c 1.13KB 0.000u 0:00.000
result32.png PNG 48x48 48x48+0+0 8-bit DirectClass 1.01KB 0.000u 0:00.000

ImageMagick 6.7.5-6 2012-02-16 Q8, Mac OSX 10.7.3, built using libpng 1.5.8

You need to specify either PNG32: or PNG8: for output to properly format the png so that PS can read it. The former is 32-bit color with an alpha channel. The latter is 8bit color with 1-bit transparency (similar to gif). Otherwise, you don't set the PNG information correctly at least for compatibility with PS.

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


From what I can see your resize is interpolating colors and alpha values (from 3 colors with 1 bit transparency to 159 colors with 8-bit transparency). Then you are getting type palettematte as it should be, but not getting a 1-bit alpha channel. So you don't have it properly as PNG32 (truecolor) or PNG8 with 1-bit transparency.

This may (?) have to do with the fact that your alpha channel in your original is acting both as an alpha channel for transparency and to set part of the resulting image for the letters. It might have been better to have made the underlying image contain everything, letters included and then used the alpha channel for transparency (preferably 1-bit). Alternately, you could threshold the alpha channel after resizing to make it binary and that might have worked, though you would have expanded the 3 colors to 159 values rather than your original 3 values. By setting the output to PNG8, you get back to your 3 colors with 1 bit transparency.


The IM PNG developer, glennrp, can probably explain better (or correct me) as to what is going on.

Yes that's about right. Try The define keeps IM from writing the create-time and modify-time chunks. -sample prevents
it from adding colors by interpolation, and png8: thresholds the alpha channel to 1-bit.

Thanks for your answers.

I don't see how the date is part of the problem, but I have no problem removing it.

As per -sample, I don't want to rely on a point filter and I would actually use -filter Lanczos in that case. Introducing new colors is fine by me if that helps anti-aliasing.

From what you say, it looks like I have to use png8: or png32: to get an image that is readable by PS. I guess this is the part that surprised me since I couldn't imagine a valid png file could not be properly opened by PS. Hence my classification as a bug, but I take from your comments that this is more a png format support issue. Am I correct?

bobinounet wrote: I don't see how the date is part of the problem, but I have no problem removing it.

It isn't part of the problem; it's just something that I usually do.

As per -sample, I don't want to rely on a point filter and I would actually use -filter Lanczos in that case. Introducing new colors is fine by me if that helps anti-aliasing.

OK. I don't know how much it helps with the anti-aliasing if it isn't used in combination with semitransparency, but I guess it helps some.

From what you say, it looks like I have to use png8: or png32: to get an image that is readable by PS. I guess this is the part that surprised me since I couldn't imagine a valid png file could not be properly opened by PS. Hence my classification as a bug, but I take from your comments that this is more a png format support issue. Am I correct?

It's a PS bug. There's nothing wrong with the PNG format. Fortunately IM can use the PNG8 subformat to create files that PS (and IE) can read properly.