Support for 8-bit textures with pre-multiplied Alpha

cocos2d for iPhone » Programming » cocos2d internals

Support for 8-bit textures with pre-multiplied Alpha

(10 posts) (5 voices)

Started 6 months ago by Total Eclipse
Latest reply from Simon F

Tags:

Total Eclipse
Member

I would like to propose the ability to load 8-bit images PNGs with pre-multiplied Alpha information as 8-bit textures in Cocos2D.

The suggestions in "Best practices" recommend working with 16-bit textures when trying to preserve quality, however we're missing A LOT by ignoring the power of 8-bit textures in memory savings.

There are applications capable of optimizing color palettes without any noticeable loss in visual quality and saving up over 66% of disk space in the process.

Please check the following image:

Can you tell which images are 24-bit and which are 8-bit?

Would someone be interested in making the RGBA222 texture format (at least I think that's what it should be) available in Cocos2D?

Thank you for reading!
Argiris

PS: I could offer such 8-bit PNGs for anyone to work with.

Posted 6 months ago #
Duckwit
Member

Looks fabulous - I mean I THINK the 24-bit ones are on the right but can't really tell.
I am far from the experience/wisdom level needed to achieve this but I am certainly interested in anyone who can - I look forward to seeing the results...

EDIT: I can see some whitish specks on the top of the ring on the right set of pictures, but I can't tell if that one is supposed to be like that or if they are artifacts (Too small to really make a difference :P)

:)

Posted 6 months ago #
riq
Key Master

@Total Eclipse PNG != Texture. 8-bit indexed PNG are great for reducing disk space, but OpenGL ES does not support indexed textures. So, it is not possible to have an 8-bit indexed textures in cocos2d (or in OpenGL ES).
Recently Apple added some new 8-bit textures in iOS5, but as far as I know they are not indexed textures.

Posted 6 months ago #
slembcke
Administrator

I've used 8 bit PNGs on projects in the past using libPNG. They work great, but are sort of a pain to work with.

I've never tried loading 8 bit paletted PNGs with UIKit, I assume it works fine though. I'm not sure if the alpha would be wonky though. You specifically mentioned "with pre-multiplied alpha" in the thread title, so I assume that you've tried it? The real problem is that the GPU doesn't support 8 bit textures. So you can save a little disk space by using using 8 bit PNGs, but would still need to load it into a texture format supported by the GPU (RGBA8888, RGBA5551, RGBA4444, etc). If you wanted to load it into one of the 16 bit texture formats, you'd have to convert the image to 16 bits before converting it to 8 bits or you would end up throwing away colors twice and possibly ruining any advantages of using an 8 bit PNG.

Also, an RGBA2222 texture would look really really awful. 2 bits per component is *definitely* not the same as using an optimized palette. If you want to see what that looks like, run posterize on an image in Photoshop with only 4 levels.

Posted 6 months ago #
slembcke
Administrator

@riq IIRC, iOS has supported 8 bit, single channel textures forever. I think what was new that was added in iOS 5 was the ability to use those textures as render textures, but only on the GPUs in the 4s and iPad 2.

Posted 6 months ago #
riq
Key Master

@slembcke: Yes, thanks. 8-bit single channel (A8) textures are supported in OpenGL ES (cocos2d supports them too). What's not supported in OpenGL ES are 8-bit palette/indexed textures.
There is an extension called GL_EXT_paletted_texture but I think it is not supported on iOS ( http://www.opengl.org/registry/specs/EXT/paletted_texture.txt )

Thinking out loud, I think it should not be difficult to support paletted textures using a custom shader with a lookup table. But it will affect a bit the rendering performance.

eg:
Texture Unit 0 = Will have an A8 texture (values from 0 to 255) will be the indexed texture.
Texture Unit 1 = Will be an RGBA8888 textures. This will be the "color" texture.

Perhaps the most difficult part (which is not that difficult) is to define a format for it. Parsing an 8-bit indexed PNG with libpng and creating the textures in runtime is another option.

Any volunteer to do the experiment ?

Posted 6 months ago #
slembcke
Administrator

Well, the shader idea isn't new. You can save a little bit of VRAM that way but the performance hit is pretty sizable. The problem is that you have to do an indirect texture lookup for every single texel. Generally that sort of thing is saved to used for effect shaders that use little fillrate or post-processing effects that have zero overdraw.

It also has a number of problems with interpolation as you end up interpolating the look up table values instead of the texel values so it must be used with nearest neighbor sampling. Given the limitations and [poor performance, it's not really a good way to save a little memory]. Edit: Apparently I forgot to finish that last sentence...

Posted 6 months ago #
Total Eclipse
Member

Thank you all for replying so far!

For anyone interested, here's a breakdown of one of the images's palette: http://i41.tinypic.com/w2nk38.png.

By the way, is RGBA4444 the current preferred pixel format for transparent images to save both memory and disk usage?

Posted 6 months ago #
slembcke
Administrator

Well, you can't make an RGBA4444 PNG file. You can load a PNG into such a texture at runtime, but it doesn't get dithered, can have pretty nasty banding and is slower to load because it needs to convert it on the fly. Unless you reduce the colors offline they don't save disk space either.

Gzip compressed PVR files are really the way to go for a released game IMO. They can actually hold the different texture format types natively and you can dither them offline. They also usually load faster because you basically decompress them straight into VRAM instead of needing a conversion step.

When possible, PVRTC is always going to be the best for filesize, loading speed and VRAM size. The compression artifacts can be pretty nasty depending on what sort of images you give it though.

Posted 6 months ago #
Simon F
Member

Just to follow up on riq's post - there's probably a good reason OpenGL ES doesn't support palette textures and that's because, to the best of my knowledge, no recent hardware supports it. With palette textures, you have to do two memory accesses (one to get the index and then another, dependent read, to access the palette) and it's painful enough in hardware trying to hide the latency of the first memory access.

Modern texture compression schemes, e.g. PVRTC, ETC, S3TC, thus avoid having a 2nd dependent read.

Posted 6 months ago #

RSS feed for this topic

Reply

You must log in to post.