I ran into two problems when using both PNGOUT (version as of 29 March 2010) and PNGOUTWin (current trial v1.0.1 Build 70509).
Issue #1:
Retention of the alpha channel, as ensured in the PNGOUT tutorial: "It won't convert a PNG file with Alpha information to a non-Alpha type." Well, unfortunately that's exactly what does happen if I
pngout.exe SampleFile1.png SampleFile1_out.png
I have expressly to force the retaining of the alpha channel by making use of the /c6 switch - for no obvious reason, since this is not needed with the second sample file, which is also a PNG24+8 bit alpha channel.
Issue #2:
I was really impressed when I saw PNGOUT diminishing the second sample PNG from originally 537.229 down to 351.240 Bytes. However, all PNGOUTWin manages to produce is a 506.516 Bytes version !? I've read somewhere in this board a statement of the developer saying PNGOUT and PNGOUTWin share the same engine. So, how do I get the same results ?
Thank you for paying attention!
Sample files here (520 kB): http://home.arcor.de/shld/krimskrams/ShinaRobot_SampleFiles.zip
Awesoken at
Re: PNGOUT removes alpha channel / far better results (with alpha) than PNGOUTWin ?!
1. This is not a bug in PNGOUT. All color modes in the PNG standard support alpha to some degree. /c3 supports a different alpha value for each palette index. Even /c0 and /c2 modes can support alpha if they all happen to be behind a common RGB color. Only when all other options fail will PNGOUT choose /c4 or /c6 mode. That line in the tutorial is inaccurate and misleading. I have fixed it.
2. Look at the options that PNGOUT selects. You should get the same file size if you manually pick the same options in PNGOUTWin.
ShinaRobot at
Well, I simply dropped files and assumed that PNGOUTWin will 'auto' the settings at least as good as (the free) PNGOUT does, if not better. But using "Filter:auto", PNGOUTWin sticks to "Filter:None", while PNGOUT makes use of "Adaptive (mixed)", which leads to the far more better result mentioned in my first post.
Concerning issue #1: I do understand now that because of the <256 colors which are actually used PNGOUT does convert the 24 bit color+8 bit alpha SampleFile1 into an 8 bit palette PNG . However, this step doesn't (AFAIK can't) preserve the 8 bit alpha channel. Which is why the baby becomes thrown out with the bathwater, making the statement that PNGOUT won't remove alpha information from a PNG file still wrong.
Awesoken at
The alpha is not lost when converting to /c3 mode. I suggest you read about the tRNS chunk in the PNG specification: http://www.libpng.org/pub/png/spec/1.2/PNG-Chunks.html#c.tRNS
counting_pine at
The best filter/color type combination will vary between images, so the only way an "auto" option can guarantee better results is to brute-force the options.
It's not unknown for programs that read PNGs to treat the transparency differently depending on the color type used. So while, e.g. a -c6 image might appear with the correct transparency effect, an identical -c3 image might not. This should probably be considered a bug in other programs. That said though, it can be difficult for image editors - for example, how should you load a -c3 image with transparency? Should you discard the palette and treat it as an RGBA image, or discard the transparency and treat it as a palette image? I'm not sure if there any image editors that allow PNG's paletted transparency.
Anyway, if you take an image that you suspect has the transparency removed, try converting it to a different color type, using e.g. "pngout -force -c6", you should be able to confirm that the transparency is still there. Or for a simpler test, "pngout -v" should list the chunks, and confirm that there is a tRNS chunk in the palette image.
ShinaRobot at
counting_pine said at
It's not unknown for programs that read PNGs to treat the transparency differently depending on the color type used. So while, e.g. a -c6 image might appear with the correct transparency effect, an identical -c3 image might not. This should probably be considered a bug in other programs.
You've hit the bull's eye. I discovered today that my fairly old version of Corel Photo Paint simply doesn't support this PNG subtype (which myself wasn't aware of as well). Though Photo Paint does import the image without complaints, it cuts dead the 8 bit transparency information, which turned out to be present within other applications. http://www.schildersmilies.de/noschild/jackgrin.gif
Thank you for pointing this out, counting_pine!
@ Awesoke/Ken: Thank you for PNGOUT, the link, and for both your assistance and resistance! ;)
David at
counting_pine said at
I'm not sure if there any image editors that allow PNG's paletted transparency.
Photoshop's default PNG handler ignores the tRNS chunk, but the PNGOUT plug-in for Photoshop can read it in correctly using Open As and setting the file type to PNGOUT. The plug-in chagnes the color mode for Photoshop to RGB since Photoshop does not support transparency when in indexed color mode.