issues with alpha when exporting for png32

[hilukasz]

I am exporting using layerName.png32 to get a full alpha PNG and it seems to be creating something wrong,specifically bKGD chunk has some weird stuff going on with it. If I open the file in photoshop it has alpha, but when bringing it into a game engine, I get error:

Converting Image 'item url here' from TEXFMT_BGR8 to TEXFMT_BGRA8

If I open the same PNG and resave it in photoshop manually, it seems to fix the error.

[joelrbrandt]

@hilukasz We're using ImageMagick's PNG writing code (we stream raw pixels to ImageMagick and let ImageMagick handle the conversion/compression). So, this is a bit curious.

If the exported image has < 256 colors (including gray values in the alpha channel), then ImageMagick will make an 8-bit png instead of a 32-bit png (because the file size is much smaller and the image content is identical). Perhaps this is what is happening in your case (and the game engine is expecting a 32-bit png)?

Do you have a PSD that exhibits this problem that you'd be willing to share?

[hilukasz]

Unfortunately not because its under NDA, however I do have the a working and non-working png here if that helps: http://imgur.com/mYDHD2e,9lo2DQM

the only thing I am doing in file is saying: LayerName.png32

and it exports from here, so I am definitely forcing png32 which has the extra 8 bits of alpha there. I can later open the png and resave via photoshop, and it fixes the issue. Here is some more details on the error I got from someone else:

Both files are perfectly fine PNGs (according to pngfix-32; no errors or warnings whatsoever). Closer examination shows that their IDATs (duh ;}) and some pixel values (may be caused by color management) differ. Besides that, the first has additional 5 chunks defined, that the second file is missing: bKGD, cHRM, gAMA and 2 text. The first of them declares the background color, so my guess is it could be misinterpreted by some half-baked PNG decoder. More could probably be said if we know some more details about the target app. Source: http://graphicdesign.stackexchange.com/questions/30822/is-it-possible-to-export-a-png-with-rgba8-in-photoshop?noredirect=1#comment43370_30822

We use pnglib to decode out PNGs into a 3D environment and it seems like a very reliable library other than this one thing. We commented the bit that reads the bKGD chunk, but it feels hacky.

[joelrbrandt]

I can't think of a way that this would be caused by any part of our pipeline other than ImageMagick's convert binary. (As I mentioned, we pipe raw RGBA pixels to convert and ask it to do the conversion.) Strangely, convert links against libpng, so I would have expected it to play nice with your libpng.

One cause could be an out-of-date/buggy convert binary on our side.

Here's one simple test that could help narrow things down:

1. start with a gif with some transparency
2. grab the convert binary from the Photoshop distribution. On the mac, it will be inside the app bundle at Adobe Photoshop CC.app/Contents/MacOS/convert. On the PC it will be at the same level as Photoshop.exe buried in the Program Files/Adobe/... folder.
3. Run convert on the gif with the following parameters ./convert -define "PNG:color-type=6" input.gif output.png
4. See if output.png works in your world.

As is probably obvious from the above, we're using PNG:color-type=6 to force 32-bit PNGs.

Once we have the answer to that, I can dig further.

[joelrbrandt]

Also, here's the documentation on the options that can be twiddled for convert's png output: http://www.imagemagick.org/Usage/formats/#png_formats

If one of those options solves your problem, and doesn't increase file size, I'd be glad to swap it in.

[lab101]

Aha had the same issue working on a OpenGL project when running the project on Windows. Could fix it when changing all my .png in .png32. To bad that didn't work for you