Transparency in PNGs

Post by **Graf Zahl** » Thu Jan 26, 2006 22:20

Nash wrote:Cals, unfortunately that's where I wasn't impressed with PNGQUANT. It doesn't seem to do a good job at whatever it's doing.

I compared an in-game screenshot of my title graphic, and the same graphic that is converted to 8-bit from WITHIN Photoshop. The Photoshop-converted graphic looks better than what PNGQUANT does to my picture.

If you observe the screenshot I posted above, you'll see several black pixels scattered messily around the picture. I don't have any God damn black pixels in the first place.

Photoshop will convert the image to 8-bit fine, although transparency will be lost).

I've tried both dithering modes that PNQUANT uses - both yielded disappointing results.

If that is supposed to prove anything, heh.

That's the one problem I am having with PNGQUANT: You can't switch off the dithering. The only way to make sure it doesn't happen is to reduce the amount of colors before using it.

Caligari_87 · Post by **Caligari_87** » Thu Jan 26, 2006 23:12

It's not the dithering that bothers me. What I get in GZDoom is nothing like what the image looks like.

See my screenshot on the previous page, then compare it with how it should look (GIMP edited to show)

Post by **Enjay** » Thu Jan 26, 2006 23:15

I just tried a little experiment. I've always quite liked the fact that Legacy uses special palettes (or something) to make certain items translucent in areas. The torches are some of these items.

I made a png of the tall red torch in PSP. I made the flame translucent and the stand fully opaque (like Legacy does). I saved, and then double checked: the correct parts were translucent but the image was true colour (so, everything as expected at that stage). I then followed the instructions to the letter (not that pngquant is complex) and converted my graphics to 256 colour pngs. On checking in PSP, they no longer looked translucent, but undaunted I ran setpng on them and then loaded them up in GZdoom - they looked awful. Less colours than originally and very bright - like a kid had drawn them with crayons. I tried quite a few other variations and steps (including a DEH patch to make them not bright) but the result was always similar: bad looking sprites that were not translucent. Either I fail it or pngquant does.

Post by **wildweasel** » Thu Jan 26, 2006 23:26

Maybe it's Setpng overwriting the parts of the image that Pngquant needs for opacity?

Caligari_87 · Post by **Caligari_87** » Thu Jan 26, 2006 23:34

I skipped SetPNG on a test graphic and got the same results. Maybe GZDoom's interpritation of alpha-mapped pngs is faulty?

DaniJ · Post by **DaniJ** » Thu Jan 26, 2006 23:40

PNG could easily replace all of these without any hassle.

I really don't think so. The mere fact that the big name apps don't support it fully is much more of a problem then whether it CAN replace them. Use of TGA, PCX, RAW and the DX formats is far more common in modern game engines.

Neither 3DStudio nor Photoshop support PNG8bit+A (and with support missing in those two the format is rarely used outside of web graphics (but even then IE can't display them correctly...), from what I've seen).

You guys might want to look here for a tool
http://www.libpng.org/pub/png/pngapcv.html

Post by **Graf Zahl** » Fri Jan 27, 2006 0:18

DaniJ wrote:
PNG could easily replace all of these without any hassle.
I really don't think so. The mere fact that the big name apps don't support it fully is much more of a problem then whether it CAN replace them. Use of TGA, PCX, RAW and the DX formats is far more common in modern game engines.

The mere fact that this software is still behind the technical development only shows that these big companies are lazy, nothing more. And apparently their users don't mind. Good for you, if you don't need proper PNG support but for some applications it is essential.

For example, with cell phone games PNG is the mandatory graphics format for the Java API - and the shitty support by the big name tools has been a severe problem more than once. Every graphic has to be processed by some specialized tools because this software isn't flexible enough and the files they output are sub-optimal in some way.

Personally, I'd prefer a system in which I could load every graphic with the same code, not the convoluted mess we have now where PCX, TGA and other shitty format are mixed and you can never be sure what you really have.

Post by **Paul** » Fri Jan 27, 2006 0:47

Graf Zahl wrote: The mere fact that this software is still behind the technical development only shows that these big companies are lazy, nothing more.

In times where games are sold like warm buns out of the Baker's shop there's little time for such I believe. Time is money here, so they'd rather invest it in design/commercialisation. It's a fact unfortunately.

smg m7 · Post by **smg m7** » Fri Jan 27, 2006 2:39

Meh, Paint Shop Pro supports all of the image formats that are used nowadays. Quite well, if I may say so myself.

Post by **wildweasel** » Fri Jan 27, 2006 4:14

smg m7 wrote:Meh, Paint Shop Pro supports all of the image formats that are used nowadays. Quite well, if I may say so myself.

Yet the industry-standard graphics programs (like Photoshop, among others) still don't support most of them.

Post by **Nash** » Fri Jan 27, 2006 6:04

ALL THIS WOULD NOT HAPPEN AND WOULDN'T BE AN ISSUE...

If SetPNG supports true colour PNGs with alpha!

I have absolutely no problem using true colour PNGs with alpha for any Doom graphic. HOWEVER when it comes to setting offsets... :/

Post by **Graf Zahl** » Fri Jan 27, 2006 10:20

In that case your best way of action is to put a dummy 8 bit texture in the WAD and then replace it using HIRESTEX.

Post by **Nash** » Fri Jan 27, 2006 10:56

Will that work for sprites?

DaniJ · Post by **DaniJ** » Fri Jan 27, 2006 11:29

The mere fact that this software is still behind the technical development only shows that these big companies are lazy, nothing more. And apparently their users don't mind.

The users we are talking aout are very niche markets and as such there is no motivation for the big boys to include support. For example, what tends to happen in big development houses is that if you need format X for your game and Photoshop doesn't support it - they don't start telling their artists to use substandard apps (which wouldn't wash in a million years), they develop the support themselves in-house, as a Photoshop plugin.

Non of this helps you in your day job nor GZDoom users trying to do something simple like getting a graphic with alpha into their mod though.

Personally, I'd prefer a system in which I could load every graphic with the same code, not the convoluted mess we have now where PCX, TGA and other shitty format are mixed and you can never be sure what you really have.

I agree but thats not the way things are. Support for various formats is a necessity and it isn't always possible to be 100% sure what format the file is in. It shouldn't really matter though as they should all be treated the same internally anyway.

Since you're using DevIL, there must be another format you can use?

Post by **Graf Zahl** » Fri Jan 27, 2006 12:01

The problem here is that 8 bit PNGs are read differently than all the rest. They use ZDoom's default texture manager which is the only code that can handle the offset information. DevIL can't and as a result offset information from true color PNGs can't be read. I won't add support for it because that wouldn't help with other formats like JPG. I'd rather put the offset in the texture definition in HIRESTEX (and if it ever becomes reality NTEXTURE.)