png alpha.... again

sir-knight

okay... has anyone run into this?

I have an indexed palette of 256 colors on a png file... this is normal.

this png file has a 4 bit transparency channel. This is not normal.

This is SO not normal that there seems to be some confusion as to how these files draw in different software.

windows fax viewer sees what is intended... indexed color graphics with antialiasing.

photoshop shits a brick and shows the raw colors with bleed off that's hidden and no transparency at all (that's correct).

graphics gale can load the image as intended, it can even separate the 4 bit transparency off the image to be edited... but I can't merge it back in.

paint.net seems to load these images just fine.

so here I am with a ton of sprite sheets that need to be resized up 150% while retaining the indexed palette for palette swap purposes and needs to keep the 4bit transparency for anti aliasing.

Oh and did I mention all these sprites are curved chunks that all fit together to form walls, and I have no method of assembling the pieces as they display in game to smooth the curves.

mobile porting is fun. :poly142::poly127:

so what the hell happened here and what kind of spaghetti factory did these graphics go through to be created? Were these created in photoshop with layers with a proper alphachannel, and then exported separately as indexed palette and alpha channel, and somehow frankensteined together with some png hack?

Who do I punch in the face for wasting 3 weeks of my time? :poly127:

Mark Dygert

Yea there are seems to be zero standard for png. Photoshops png support is horrid... Programs like XnView and ACDsee seem to display a wider range of PNG's correctly but you should probably give up on photoshop opening forgien file formats, even when it gets it as right as it can, it still screws up.

What we've been doing at work, is work in PSD, save as TGA (or bmp with a specific pallet) and using an in house PNG converter. You can probably use the batch concert feature in XnView to do the same thing if it makes good PNGs.

Also know that in newer versions of photoshop, there are more settings available then "interlaced" if you do ctrl-alt-shift-S or File > Save for Web & Devices. Then go with PNG-8 instead of the default of PNG-24.

Vrav

Not sure if this helps, but this is the plugin I use to export PNG in Photoshop. I had to use it because Photoshop was doing something stupid with its color profiles and saving things darker than they were in the program - unchecking 'save metadata' using this plugin was easiest solution I could find... maybe it'll work better for you.

http://www.fnordware.com/superpng/

sir-knight

thanks guys, I'm about to strangle the head dev that keeps sending this back to me, he thinks he has a solution, but even his workaround with paint.net produces a full 32bit png, not an 8 with 4... I think I might have it licked now, I've used graphics gale to pull the 8bit alpha off the resized images as a separate image file, touched up the bleed over in the non alpha graphics, now I'm just going to use another process we've used in house to mux the two back together... only if I can confirm that the stupid palette swap code the head dev came up with still works.

Hey vig, I know it's not exactly the most effective way to be working, but since we're porting an external title, and the licensor decided it was unnecessary to send along the source artwork, I'm stuck working with what we got. If the test with the non alpha files works, I'm keeping my fingers crossed for the muxed versions.

pior

Hi!

I don't know if that helps, but the few times I had to deal with PNGs in production, we realized it was just a very bad idea. This mostly comes from the transparency not being handled as a *channel* (what us gamedevs want) in the actual format specs, but as *transparent pixels* instead (like the purple stuff in gifs). So its seems like photoshop opens the file properly (no fourth channel, even if there is transparency), but obviously this is nothing we can really work with properly (since as opposed to gif where stuff is either opaque or transparent, we need to finely control the look of the pixels 'under' their transparency)

So yeah I'd say avoid PNGs and use a format that explicitely hanldes a fourth *channel* for transparency instead of a pixel value.

The irony is that TGA is supposed to work transparent pixels, not a fourth channel, but at some point it started to be implemented the fourth channel way. When adobe went back to the original specs, there was an outrage (ps7.0) so they quickly went back to the unaccurate, CG art friendly way (7.1) because we are the only ones using that dead format after all!

What about DDS?
Or do what Vig suggest, keeping the art pipeline full PSD and having a conversion on export. You just have to agree on a norm for psd transparency (avoiding deleted pixels and the eraser brush as much as possible, and relying on alpha channels or alphas on layer groups as much as you can).

sir-knight

muxed versions didn't work... their palettes were stripped in the process and they became png24 rather than staying some weird hybrid png8.

Unfortunately, for the devices in question, png is the only economical option. This would not be an issue if we had the source files or a document saying where the artwork came from and how it was produced, but sadly, we gots what we gots to work with.

Our regular production graphics don't suffer from this problem. This external title is using pngs that are outside of spec apparently. A little digging revealed that the files may have come out of fireworks as that package can export 8 bit png with multi level pixel transparency (basically 4 bit alpha).