A fast, easy to use, free, and community supported 2D game engine
markww
Member
Hi,
Can anyone recommend a tool to create RGBA-4444 png images (16 bit pngs)? I'm using photoshop which only outputs 32 bit pngs (RGBA-8888). The output size is massive when loaded into memory (for iPhone). I'm looking around for some conversion tools but can't find any,
Thanks
gnomesgames
Member
Witch version of photoshop have you ?
With mine (Photoshop CS4) when i create an image, i can choose the "color mode" including color depth...
Moreover, you can choose the color depth of an image in : image=>mode (8 bits/channel,16 bits/channel,32 bits/channel).
markww
Member
Yeah I have CS2, and I have the same options, but none of those align with an RGBA-4444 png? I mean 8 bits per channel means you'll get a 32 bit png, we would need to be able to specify 4 bit-mode instead?
I tried using ImageMagick and can use a "-depth 4" option to (supposedly) force each channel to use 4 bits, instead of 8. I can see the output png has a more lossy look to it, so it seems to have worked.
Inside cocos2d, it seems like there is no auto-detection of the RGBA-4444 png, the Texture2D class simply uses whatever you set the "defaultAlphaPixelFormat" global variable to (which by default is set to RGBA-8888 format). So if I'm reading this correctly, cocos2D will still allocate your textures in the larger format if you don't change that to use RGBA-4444.
Thanks
markww
Member
Oh shoot I see - ok so actually are we just supposed to be feeding this thing 32bit pngs (RGBA-8888), then the Texture2D class actually crushes down the image data on the fly? If you look at Texture2D.m, initWithImage(), it seems to actually assume that your image data is 32 bits per pixel - then if you chose one of the 'compressed' formats, it will rescale all the pixels for that texture right inside on the fly:
if (pixelFormat == kTexture2DPixelFormat_RGB565) {
// rescales..
}
else if (pixelFormat == kTexture2DPixelFormat_RGB4444) {
// rescales here..
}
else if (pixelFormat == kTexture2DPixelFormatRGB5A1) {
// rescales here..
}If we're already prepared our pngs in one of the above formats, would it be possible to skip this internal compression step? I wonder how much extra time it adds every time you need to load the image from disk?
Thanks
gnomesgames
Member
Most of time i thinks it's not a problem, because all your images "have" to be loaded during in your init method, not at every frame, so 0.1s more of loading isn't this bad...
Moreover if the image is already in the good format, i don't think that the operation waste a lot of time :), but i could be wrong.
@markww :
actually are we just supposed to be feeding this thing 32bit pngs (RGBA-8888), then the Texture2D class actually crushes down the image data on the fly?
No. The 32-bit images are not crushed down on the fly is you specify kTexture2DPixelFormat_RGB4444. The code you extracted (3 posts above) only repack the image data. Any image (except pvr), when first loaded from a file, is treated as 32 bits. The image takes up width * height * 32 bits of data in memory. If your image is 16-bit (eg. RGBA-4444); it means one bit out of two (4 bits out of 8 in our example) is (are) unused in the loaded data. So basically, the above code repacks the bits so that only the useful ones are kept. This shrinks down the array holding the image data. It now takes up width * height * 16 bits in memory.
markww
Member
Clain,
Ok I *think* I see what you mean.
So if we want to use RGB-4444, we really should be saving our images in that format, because whatever tool we use to save them will/should place the used bits 'first' (maybe it will look like the first 4 bits are used, the last 4 are all zeros for example). The file size (might) stay the same as an RGB-8888 since it's still treating it as 8 bits per pixel when writing to disk.
Now when we give this image to Texture2D, the repacking will work as expected.
If I were to give Texture2D a true RGB-8888 image, and use the RGB-4444 flag on it, the operation will still 'work', but the colors will basically come out differently since the last 4 bits of each pixel are discarded during repacking.
Is that right?
Thanks
Hey, you're almost right. Let me clarify a bit.
So if we want to use RGB-4444, we really should be saving our images in that format
Yes, this part is right.
because whatever tool we use to save them will/should place the used bits 'first' (maybe it will look like the first 4 bits are used, the last 4 are all zeros for example). The file size (might) stay the same as an RGB-8888 since it's still treating it as 8 bits per pixel when writing to disk.
This part is wrong. When you save your file as RGBA-4444, it's really "RGBA-4444" and not "RGBA-8888 with half of the bits being zeros". So the file should be about half the size as the RGBA-8888 image. In fact, when cocos loads an image file for the first time, it is loaded in an RGBA-8888 "container", so this is when you get 4 bits with useful values followed (or preceded, whatever) by 4 bits which are all zeros (or other random values). But right after that, the repacking happens and the image takes the amount of memory it should.
If I were to give Texture2D a true RGB-8888 image, and use the RGB-4444 flag on it, the operation will still 'work', but the colors will basically come out differently since the last 4 bits of each pixel are discarded during repacking.
Exactly. I've never tried it but yes, you should expect a completely different image.
Hope it's all clear now.
Did anyone ever figure out how to get 16-bit PNGs from photoshop? I found a plug in ( http://www.fnordware.com/superpng/ ) but it does not seem to work with recent versions.
Barring that, does someone have another tool they could recommend?
I use TexturePacker which is great , http://texturepacker.com/
I would not recommend using PNG for 16 bit but instead PVR.CCZ.
The format was invented to be a PNG replacement. It bests it in size and loading speed.
TexturePacker also has an included viewer for this file format.
You must log in to post.
