Really confused about how to create a 4444 PNG with transparency.

cocos2d for iPhone » Programming » cocos2d (graphics engine)

Really confused about how to create a 4444 PNG with transparency.

(5 posts) (2 voices)

Started 6 months ago by Questor
Latest reply from Questor

Tags:

Questor
Member

Greetings,

Apologies if this is a real newbie bunch of questions, but I really tried to get search for an answer but most articles and threads I have seen don't seem to be helping me understand this.

I understand the 4bit and 16bit PNG files are much faster than an 8bit png file. However, I can't seem to figure out how to make anything BUT an 8bit PNG file. I tried using PaintShop Pro (I have version 6) and whenever I try to save a 16bit image as a png, it says it must reduce the image to 256 colors (which to me means 8bit color).

I also tried using GIMP... I added a transparency channel and then (according to what I could glean from a few articles I read) I used the fuzzy selector to clear out the parts of the image I want to make transparent. Then I changed the mode to indexed...however, it then only gives me the option to have up to 256 colors again.

So I am kinda banging my head against the wall. I don't have a ton of graphics, but I have enough that 256 colors is going to make me need multiple AtlasSpriteManagers...which seems a waste simply for the sake of having more colors to use.

I have no idea if I am heading down the totally wrong road here but from what I have read it seems that PNG can have 4bits per color plus an alpha channel, which should be a 16bit image file. right? Or am I really missing something?

Any help would be greatly appreciated. Again, apologies if this a real newbie sounding problem, but graphic design is really not my strong suit.

Regards,
Q

Posted 6 months ago #
Karl
Member

16-bit PNG support is spotty at best in most applications. What I did is write a Java app that optimizes a 32-bit image so that it won't look much different when reduced to 16-bit (basically it selectively strips off 16 bits worth of information per pixel).
The images themselves are saved as 32-bit. Originally I tried to save them as 16-bit, but gave up because reliable information on this subject is hard to find, and also because an optimized PNG image will compress to about the same size on disk as an equivalent 16-bit image.

In Cocos2d, your image file gets loaded into a 32-bit image buffer, and then gets converted to whatever pixel format you specified. More specifically, it gets loaded via the Apple SDK as a 32-bit image, whose pixels then get copied to a raw buffer as RGBA8888. If you chose something other than RGBA8888 for the final format, that buffer then gets copied/converted to another buffer in the format you specified. So if you load an image into a 16-bit format, for example, you must have 5x the 16-bit image footprint in free memory available (i.e. a 100x100 16-bit image will take 100,000 bytes to load, and 20,000 bytes thereafter).

You can specify 16-bit RGB with 4-bit alpha channel like so:

[Texture2D setDefaultAlphaPixelFormat:kTexture2DPixelFormat_RGBA4444];

Posted 6 months ago #
Questor
Member

Thanks for the quick reply.

I am still a little confused. In the best Practices section of Cocos2d it says:
When possible, try to use 4-bit or 16-bit textures
16-bit textures for PNG/GIF/BMP/TIFF images
Use 32-bit textures as the last resort

But if the iphone is storing images in a 32-bit buffer, and all that conversion happens for a 16bit image, why is the 32 suggested only as a last resort?

Also, if I create an image in GIMP (with an alpha channel) and save it as a PNG file (without changing the mode to indexed) will that automatically save it as a 32bit image? (What I guess I am really asking here is, how do you create a 32bit PNG image? and should I even bother moving away from 8bit).

Ultimately, I have several spritesheets I would like to merge into as few as possible. The sprites have a good deal of color variations, and if I save them as 8bit PNG, I would have to create multiple CCSpritesheets (AtlasManagers) which from what I understand may impact performance (at least I think it does). Not too mention that I am not sure if the performance hit for several spritemanagers is worse than the performance hit for using 32 PNGs.

Which direction do you recommend I go? Should I stick with 8bit and multiple sprite managers, go thru the hassle of trying to convert to 16bit or even go with 32bit?

Regards,
Q

Posted 6 months ago #
Karl
Member

I believe the best practices guide is referring to the format of the buffer the image is loaded *into*, as in the format you want to load it as rather than the format it is stored in on disk. 4-bit is a special case, however.

By setting the pixel format to RGBA4444 in cocos2d, you are telling cocos to convert every image it loads into a 16-bit image. Cocos will ALWAYS load any image (except 4-bit) into a 32-bit buffer and then down-convert to whatever you specified.

Also, if you save as 8-bit indexed, you lose your alpha channel (well, it is reduced to a 1-bit channel), and it will STILL get loaded into a 32-bit buffer and then down-converted, so you gain nothing by it.

What I would recommend is: Save everything as 32-bit and run the images through an optimizer program (or make your own). Note that optimizing will only lower the number of bytes required to store it on DISK. If you load using kTexture2DPixelFormat_RGBA4444, for example, the final RAM usage will ALWAYS be that of a 16-bit image, and the format of the image in memory will be RGBA4444, regardless of whether the source image was 8, 16, or 32-bit, optimized or not.

I'd suggest loading into your app at 16-bit until you run into RAM issues. 4-bit textures require a bit more work to use, and optimizing early usually results in wasted effort.

Edit: By default, Gimp will store a PNG image in 32-bit. With most art programs, you have to specify 8-bit if you want to save in that format.

Posted 6 months ago #
Questor
Member

Karl,

Thanks so much, you really cleared that up for me.

Best Regards,
Q

Posted 6 months ago #

RSS feed for this topic

Reply

You must log in to post.