PNG00 not working

[auday]

Hi,

I'm trying to 50%-resize a number of PNG files in a folder with the same script. The files have different formats, 24bit no-alpha, 32bit with alpha, 8bit alpha only, ....etc.
I want to use a Point filter (Nearest) so I use -sample instead of resize. I want to keep the format of the original files as is, basically keep everything the way it is except the size. I thought PNG00 will give me that, but in some cases I get the result files changed to Indexed Palette (color_type becomes 3) although the source is 32bit fullcolor (color_type 6).

Here is the command I'm using for all images:

convert sourceFile -sample 50% PNG00:destFile

Any idea why this is happening? Does PNG00 preserve the color_type? if not is there a way to preserve the color_type?

Thanks,

Auday

[fmw42]

I thought PNG00 will give me that, but in some cases I get the result files changed to Indexed Palette (color_type becomes 3) although the source is 32bit fullcolor (color_type 6).

...

Does PNG00 preserve the color_type? if not is there a way to preserve the color_type?

Post one of these files that fail to dropbox.com (public folder) and put a link here. Also identify your version of IM and platform. If you are using an old version of IM, then you might try upgrading and see if that fixes the issue.

If you want a point filter, you could also try

Code: Select all

convert sourceFile -filter point -resize 50% PNG00:destFile

also, try leaving off the PNG00: and just use .png extension or try PNG:destfile and see what happens.

Ultimately, if we can duplicate your results, then the PNG developer, glennrp, will have to look at it or respond to your question.

[auday]

Thanks for the quick reply. Here is more details:

- Mac OSX 10.9.1
- ImageMagick-6.8.8
- I tried all your suggestions nothing helped.


Here is a sample file link to Dropbox, as you could see the file has only 5 colors, but I still want to preserve the original format.

https://www.dropbox.com/s/7yd95jek679xqg6/test.png

[fmw42]

Your image has a fully opaque alpha channel for palette type png rather than a color transparency. IM probably sees that and simply removes it since it is not needed. It has nothing to do with the resizing, since

Code: Select all

convert -channel rgba -alpha on test.png test2.png 

also removes the alpha channel. I think that a palette PNG with alpha channel is either new to IM or not properly supported yet. I recall some post not too long ago. I think that was going to be called PNG88: if I recall. But I do not know if it was implemented or relates to this issue. See viewtopic.php?f=2&t=25234

This may be a bug in the PNG reader or writer. Glennrp, needs to look at this an let us know more.

[auday]

Thanks for the explanation. Yes I have a non-used alpha channel in some images (for a reason), but regardless of that, I just want the resize/sample function to scale down my image and keep everything else untouched, which should be a reasonable expectation.

Glennrp, is there a quick work around? and do you have an eta for the fix.

Thanks

[fmw42]

As I said above, I think it is an issue with the type of PNG file -- namely a palette with an alpha channel rather than a palette with a transparency color. I do not think IM can create such a format and when reading it, it seems to ignore the alpha channel. It has nothing to do with the resize. I have sent PM to glennrp. So once he sees it, he can comment on the true nature of the issue.

[auday]

fmw42, I'm kind of confused, as far as I can tell here, the original image is not a palette image, it's truecolor with alpha/ The header shows this (in hex):

Width: 0400
Height: 0400
Bit depth: 8
Color type: 6
Compression method: 0
Filter method: 0
Interlace method: 0

6 is truecolor isn't it?

so why are you assuming that the original has palette? I'm I missing something about how to interpret the header?

[fmw42]

I am not sure about the PNG specific meta data but using

Code: Select all

identify -verbose test.png

I get type=palettealpha rather than truecoloralpha

Format: PNG (Portable Network Graphics)
Mime type: image/png
Class: DirectClass
Geometry: 1024x1024+0+0
Units: Undefined
Type: PaletteAlpha
Endianess: Undefined
Colorspace: sRGB
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: 111.297 (0.43646)
standard deviation: 34.8248 (0.136568)
kurtosis: 11.097
skewness: 1.94034
Green:
min: 0 (0)
max: 255 (1)
mean: 110.849 (0.434701)
standard deviation: 36.9638 (0.144956)
kurtosis: 9.9663
skewness: 1.44365
Blue:
min: 0 (0)
max: 255 (1)
mean: 106.153 (0.416287)
standard deviation: 33.5612 (0.131612)
kurtosis: 10.8904
skewness: 0.344108
Alpha:
min: 255 (1)
max: 255 (1)
mean: 255 (1)
standard deviation: 0 (0)
kurtosis: 0
skewness: 0
...

[glennrp]

Yes, verified that PNG00 is not working when the input image is a PNG32 or PNG64.

[fmw42]

Glenn,

Is this image PNG32? It seems to be palettealpha with an alpha channel rather than a color transparency. Just trying to copy this file removes that alpha channel. So I thought perhaps IM does not know about this type of PNG.

Fred

[glennrp]

Glenn,
Is this image PNG32? It seems to be palettealpha with an alpha channel rather than a color transparency. Just trying to copy this file removes that alpha channel. So I thought perhaps IM does not know about this type of PNG.
Fred

The provided test.png is a PNG32, without any actual transparent pixels. Reminder: Don't use "identify" to figure out what the original format was. "identify" characterizes the image, by its contents, after it has been read.

glenn.rp> od -c test.png | head -3
0000000 211 P N G \r \n 032 \n \0 \0 \0 \r I H D R
0000020 \0 \0 004 \0 \0 \0 004 \0 \b 006 \0 \0 \0 177 035 +
0000040 203 \0 \0 004 $ i C C P

The "006" in the middle of the second line is the colortype. The \b (8) is the bit depth.

[auday]

Thanks for clarifying this out Glenn and Fred, yeah I was confused by seeing the info in identify as palette, while when I read the file in my code it shows trueColot, now at least I know why.
Is there a work around? I tried using -type trueColor, but it didn't help.

[glennrp]

A workaround is to use PNG32:file.png as the output. But that will convert *all* of your images to PNG32 which is probably not what you want.
The bugfix won't be trivial. ImageMagick normally writes output PNGs in the smallest possible format. In this case, test.png is 44071 bytes
while test00.png is 4988 bytes (nearly a 90 percent lossless reduction, that you want to defeat). Even a forced conversion to png32
results in an output that has less than 50 percent of the original size.

[auday]

I understand the benefit of the size reduction, which is cool. But I don't understand why it would be forced. Ideally the tool should specify something like -optimize to allow it to do the format change for the best fitting format.
There could be many reasons why you want to keep the original format especially in a game pipeline, and it's totally unexpected that applying a simple size reduction would cause the file format to change IMO.

[fmw42]

it's totally unexpected that applying a simple size reduction would cause the file format to change IMO.

I do not think it is the resize.

Code: Select all

convert test.png test2.png

test.png

Code: Select all

  Properties:
    date:create: 2014-04-19T09:42:14-07:00
    date:modify: 2014-04-19T09:42:14-07:00
    icc:copyright: Copyright 2007 Apple Inc., all rights reserved.
    icc:description: Generic RGB Profile
    icc:manufacturer: Generic RGB Profile
    icc:model: Generic RGB Profile
    png:iCCP: chunk was found
    png:IHDR.bit-depth-orig: 8
    png:IHDR.bit_depth: 8
    png:IHDR.color-type-orig: 6
    png:IHDR.color_type: 6 (RGBA)
    png:IHDR.interlace_method: 0 (Not interlaced)
    png:IHDR.width,height: 1024, 1024
    signature: b04bebde3968459030e87e609cbd8dbcdf5ae96668c9abda1e504e6b0cf1a0bd

test2.png

Code: Select all

 Properties:
    date:create: 2014-04-21T12:31:01-07:00
    date:modify: 2014-04-21T12:31:01-07:00
    icc:copyright: Copyright 2007 Apple Inc., all rights reserved.
    icc:description: Generic RGB Profile
    icc:manufacturer: Generic RGB Profile
    icc:model: Generic RGB Profile
    png:bKGD: chunk was found (see Background color, above)
    png:cHRM: chunk was found (see Chromaticity, above)
    png:iCCP: chunk was found
    png:IHDR.bit-depth-orig: 4
    png:IHDR.bit_depth: 4
    png:IHDR.color-type-orig: 3
    png:IHDR.color_type: 3 (Indexed)
    png:IHDR.interlace_method: 0 (Not interlaced)
    png:IHDR.width,height: 1024, 1024
    png:PLTE.number_colors: 9
    png:text: 6 tEXt/zTXt/iTXt chunks were found
    signature: 0c469cd15dbe5409c00643e4ca883bc01d63bf562da07fbab0b2a05563ae1c01

It has gone from color_type 6 to color_type 3. So it has nothing to do with the resize.