How to make RGBA-4444 pngs from 24-bit png?

cocos2d for iPhone » Programming » cocos2d internals

How to make RGBA-4444 pngs from 24-bit png?

(98 posts) (16 voices)

Started 1 year ago by mojo
Latest reply from Total Eclipse

Tags:

12…4 Next »

mojo
Member

Hello,

I had my art done in Adobe Flash and then exported the pngs using the tool provided by

http://marshgames.com/swftopng/

So I assume they were in the default flash format : 24-bit with alpha channel. I later used zwoptex to create my sprite-sheets.

I have recently started getting memory warnings in my game when I loaded too many sprite-sheets. First thing i did was to include :

[CCTexture2D setDefaultAlphaPixelFormat:kCCTexture2DPixelFormat_RGBA4444]; as recommended in the best practices.

Now I don't get memory warning but as discussed in thread http://www.cocos2d-iphone.org/forum/topic/9570, the images got discolored.

Is there any way for me to convert my sprite-sheets to 16-bit png?

Posted 1 year ago #
Karl
Member

There is no such thing as 16-bit png. Furthermore, cocos2d uses the system image libraries, which load everything as 32-bit, and then downsamples to whatever format you wanted when making the CCTexture.

What you need to do is choose colors that are RGBA4444-safe when making your graphics and avoid gradients.
Barring that, you'd need to downsample your image and use dithering with a program such as damage control.

http://www.google.com/search?q=+site:cocos2d-iphone.org+damage+control+maptunes

Posted 1 year ago #
Andreas Loew
Member

Right - there is no 16bit PNG but you can improve things.

What you can do: Reduce colors with high quality algorithms to RGBA4444-safe values, in some cases dithering might be useful. Damage Control (windows only tool) seems to be down.

I added a section to
http://www.cocos2d-iphone.org/wiki/doku.php/prog_guide:best_practices
about how you can use TexturePacker to do the reduction.

The main advantage is that the PNG file size also drops dramatically - see the comparison chart
.
(But this does only change PNG size on the file system - not in RAM! After decompression it'll still use width*height*bits_per_pixel)

Posted 1 year ago #
Karl
Member

FYI, here's a bunch of examples of dithering techniques: http://bisqwit.iki.fi/jutut/colorquant/index16.html

They all look awful because the source image makes such heavy use of gradients. If you want images to look good in RGBA4444, then have your artist draw the image using only RGBA4444-safe colors (0, 15, 31, 47, 63, 79, 95, 111, 127, 143, 159, 175, 191, 207, 223, 239, 255 in each color band).

When your art is specifically drawn for a low color palette, you can get much nicer results:

If your artist is REALLY good, you can get some amazing results, such as this 16 color image (dithering is used here, but notice how it was selectively applied by the artist from the start, not as a final filter):

Posted 1 year ago #
Andreas Loew
Member

I agree that reducing color makes images look worse - but sometimes you have no choice.

But if you use it on moved sprites the difference is not too bad. The images on your link sure look bad - its a color reduction to 16 colors. Converting to RGBA4444 still lets you use 4096 colors - which delivers much better quality.

Look at this:

The left image is the original in RGBA8888
The center image is converted to RGBA4444 without dithering
The right image is RGBA4444 with transparency preserving dithering

All images converted with TexturePacker.

In the center image you see strong banding while the dithered version gives you a smooth gradient. If the sprite is moved with a decent speed you don't see any difference to RGBA8888.

Posted 1 year ago #
Karl
Member

Yes, that's fine for non-animated moving sprites, but once you start frame animating, it will cause the dithering artifacts to stand out even more to the user.

Bottom line: Avoid dithering whenever possible.

Posted 1 year ago #
Andreas Loew
Member

Rotating dithered sprites is usually still ok, making them smaller is acceptable making them bigger is usually no good idea.
But this also depends on the images, how strong the dithering is and on the settings you chose for aliasing. It is also a difference what kind of framebuffer you use.

So: Don't reduce colors if you don't need to and do only dither if absolutely necessairy...

Currently I am working on a solution for TexturePacker to only dither sprites which need dithering. So you will have non dithered color reduction for most images but could select some of them wich improve...

By the way TexturePacker's dither algorithm does not let sprites "bleed". The borders of the sprites are kept crisp without additional pixels ruining the sharpness of the borders...

Posted 1 year ago #
riq
Key Master

Also, since v0.99.5-beta, cocos2d supports non compressed PVR images. So, it is possible to pack 16-bit images in a file.
http://www.cocos2d-iphone.org/wiki/doku.php/release_notes:0_99_5#textures

Posted 1 year ago #
Andreas Loew
Member

Good to know.
I'll add pvr export soon ;-)

Posted 1 year ago #
Tim Knauf
Member

If you want images to look good in RGBA4444, then have your artist draw the image using only RGBA4444-safe colors (0, 15, 31, 47, 63, 79, 95, 111, 127, 143, 159, 175, 191, 207, 223, 239, 255 in each color band).

@Karl - Thanks for that. I had been wondering about what the exact 'safe' values were.

Posted 1 year ago #
Karl
Member
@riq - Could you add in support for uncompressed pvr files compressed ala gzip using zlib?

I'm doing something similar already in my programs and the gzip compressed raw images load in less than half the time required for loading PNGs, even with 32-bit images. Plus, the compressed file sizes are usually smaller than the PNGs (even the 32-bit ones) since it's all drawn art that compresses better with gzip's simpler run-length encoding.

In CCTextureCache you can just check for the extension ".pvrz" and then load the data, run it through a decompressor, then pass it as regular pvr data to a CCPVRTexture.

Google Toolbox for Mac includes a zlib category for NSData at http://code.google.com/p/google-toolbox-for-mac/

Decompression is super simple:
```
NSData* pvrData = [compressedData gtm_dataByInflating];
```
Would be nice to see support for this in spritesheet generators as well, though technically I could just run gzip on the pvr file output.
Posted 1 year ago #
Andreas Loew
Member

Do you have any loading / memory usage statistics for that?

I mean how much memory does an optimized PNG consume vs compressed PVR? How fast is loading them?
Just wonder if its worth the efford since PNG uses ZLib for compression, too.

Posted 1 year ago #
mojo
Member

Karl and Andreas, thanks a lot guys.

I am not so familiar with image formats so all this was really very helpful.

Posted 1 year ago #
nickbit
Member

Hi Andreas,
Is it possible to call TexturePacker to optimize and dither all the pngs in a given directory and replace the source files.
I don't want to create any plist or spritesheet, just opt4444 and dither.

Posted 1 year ago #
Andreas Loew
Member

Not yet - but this feature is planned.

Posted 1 year ago #
Karl
Member

I already use a gzip-compressed raw texture format in my games. The images on disk are on average 30% smaller than their PNG counterparts, and loading images from disk to memory takes half the time as loading from PNG (I cut my scene loading time from 17 seconds to 8 seconds just by doing this). It also uses less working RAM during loading (one less 32-bit representation of the data) since there's no copying from a system-supplied image object.

Posted 1 year ago #
Andreas Loew
Member

Which settings?
PVR with RGBA4444 vs non optimized PNG?

See figure above: TexturePacker reduces PNG size from about 55% compared to RGBA8888.

I'll try what I can do to on PVR.

One question (since I currently don't use PVRs): The format only allows square images or is it only when using compression?

Posted 1 year ago #
Karl
Member

PVR with RBGA4444 vs regular image (I'm talking individual images here, not spritesheets).
RGBA8888 can also compress better with gzip (not always), though not as well as an RGBA4444 optimized version. Of course, it all depends on what kind of image you're compressing. PNG in general doesn't do as well compressing sprite-type images as straight-up run-length encoding does. Plus, run-length encoding decompresses much faster.

That's also size-on-disk, which is nowhere near as important as load time in game.

Raw textures need to have sides that are a power of 2, so 1024x1024, 512x128, 256x1024, etc. It's only PVRTC that requires square textures.

Also, with PVRTC you are storing the compressed texture in a PVR container. With pvrz, you are storing uncompressed data in a PVR container, then gzipping the entire thing, container and all.

Posted 1 year ago #
riq
Key Master

@Karl: Could you open a ticket ? Thanks.

Posted 1 year ago #
Karl
Member

Done.

Posted 1 year ago #
Andreas Loew
Member

I'll try to put it in the next TexturePacker update.

Should we add some more data like a header with size of the decompressed image or at least some magic ID to be able to detect the file format?

Posted 1 year ago #
riq
Key Master

@andreas loew:

I wouldn't add an special header. I would just zip the .pvr image, and parse it according to the file extension:

Proposed extensions:
- fileimage.pvrz
- fileimage.pvr.gz

any other one ?

Posted 1 year ago #
Karl
Member

.pvz

Also, be sure to gzip it and not use the pkzip container format, since it's not an archive of files and the extra overhead is unnecessary.

Posted 1 year ago #
MikeSz
Member

you mean .pvrz ? that's what you said in your previous post ;)

I must say I really like the idea. I wanted to move from .png to .pvr in the new game, but was worried about space issues. With this... well, hopefully no problems no more ;)

Posted 1 year ago #
Andreas Loew
Member
It is done!!!!

TexurePacker 2.0.1 comes with support for PVR and PVZ!

And I am deeply impressed by the gain that comes from the new format.

In my tests PVZ turned out to be nearly twice as fast as PNG with even less memory usage for RGBA8888.

The real power comes when using RGBA4444 optimized textures: The size with my test texture is only 55% of my already optimized(!!) png file. Loading time drops to 36% !!!!!!!!!!!

In contrast to Karl's proposal I changed 2 things
- I added the length of the decompressed file at the start
- I use my own decompression and do not use the google implementation
The google implementation seems to be simple to use but it comes with impact on performance. It does not know the file's size and increases the destination buffer's size while decompressing. It also does additional redundantent copying of the decompressed data. This is why I added the destination size and use my own loading routine.

I added my modifications to the wiki for everybody to test - including my measured values and a documentation how to use TexurePacker to create the file.

http://www.cocos2d-iphone.org/wiki/doku.php/prog_guide:sprites#speedup_sprite_sheet_loading_with_pvz
Posted 1 year ago #
jordo
Member

so, let me get this straight...

PVZ results in smaller files AND increased loading time with both RGBA8888 and RGBA4444?

Posted 1 year ago #
araker
Moderator

@Andreas, nice work. TexturePacker is improving fast lately. One thing is a bit unclear to me though, what do you mean with that pvz has less memory usage compared to png for RGBA8888? When loaded all same sized RGBA8888 textures will have the same memory footprint, so are you referring to the loading process or to the disk space?

Did you also send your cocos changes to Riq, it would be easier if this made it into the development branch.

Posted 1 year ago #
jordo
Member

can I use texture packer straight from the command line just to process png's? If it's possible, I would love to be able to convert all my game's art to pvz's...

Posted 1 year ago #
Andreas Loew
Member

@jordo: No - it makes smaller files and less loading time.

@araker: Sure: memory usage on flash, not RAM. Using RGBA4444 improves both...

I did not yet send it to riq since I currently don't exactly know how to contact him. I tried it once with the forum but got no response...

But I guess he read's his wiki ;-)

TexturePacker is improving fast - your right. This is because I get a fast increasing community and see the needs from the point of view of a coder: I use it for my own game I am currently developing. The PVZ format was a real must-have for me - I was near to 20MB file size which I didn't want to break - now I am back at 12MB :-)

Posted 1 year ago #
Andreas Loew
Member

@jordo: I promise to add single file conversion for the next version ;-)
But you should better consider using sprite sheets - less memory usage, faster loading. There is really no reason to stay with single sprites...

You can already use it: Just disable trimming and add only one sprite to your sheet.
The only disadvantage is that it is expanded to a power of 2. But this is something that will happen if you load the file on iPhone too. zlib should compensate the additional 0-bytes.

Posted 1 year ago #

RSS feed for this topic

12…4 Next »

Reply »

You must log in to post.