png alpha.... again
polycounter lvl 10
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:
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:
Replies
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.
http://www.fnordware.com/superpng/
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.
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).
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).