RGBA8888 vs RGBA8888

[gregmax17]

SORRY! I meant the topic to be "RGBA8888 vs RGBA4444".

 

I have used TexturePacker for a while and have always had Pixel Format set to RGBA8888. But just recently I noticed when switching this field value to RGBA4444 the overall file size is halved (the number in the bottom right corner). Is this better than TinyPNG or something different?

 

Does anyone have any input on this? Does it improve performance, lower memory usage, is there a way to measure memory usage for html5 games, etc

 

Lots of questions I know, but I would greatly appreciate it if anyone can share any and all info they know on this. Thanks in advance!

Edited May 28, 2015 by gregmax17

[Gio]

Hi

 

It doesn't improve performance nor memory usage, it just makes your files smaller saving you some bandwidth, so everything loads a bit faster. Ultimately the image is decoded into a non-compressed format (most of the time), so memory usage and performance are independent of the encoding.

 

I wouldn't use RGBA4444 though, there are much better ways of compressing your images. RGBA444 gives you half the size, but a much poorer quality. There are ways (with lossy palettized PNG's) to easily get a quarter of the size, with no visible differences.

 

My favorite compressor is PNGquant.

[AndreasLoew]

TexturePacker's RGBA4444 and the other 16 bit formats are for OpenGL / WebGL. They will not give you much benefit in standard web development. PNG will always be 32bit per color. (Maybe 8 bit while compressed as file with a palette, but extended to 32bit in RAM).

 

It reduces the amount of colours used to 4 bit per channel in RGBA4444. The reason for this is to allow loading the images directly into a texture for OpenGL by simply discarding the lower bits. It also allows applying dithering.  As I said: When using WebGL for rendering - e.g. with PixiJS - here it really has some advantage in performance and memory usage.

 

TexturePacker displays the amount of RAM required to store the sprite sheet. This is indeed reduced by 50% if you are using RGBA4444 textures. It's not about file size. The file size might even increase when using PNG + dithering since the dithering adds entropy making it harder to pack the data.

 

If you want to reduce the amount of memory transferred try using PngOpt (included in TexturePacker) or Jpg (if you don't need transparency).

 

If you want to use PngQuant you have to use it as a post processor for now. We've planned to add it to TexturePacker but it's not yet done. 

[Gio]

I believe that any performance benefits that you may get depend on what you do at runtime, and not on the encoding of the PNG.

 

It is true that using 16bit images can be faster than 32bit and use less memory on the GPU, but only if at runtime you set the texture type to GL_UNSIGNED_SHORT_4_4_4_4. Even if you have an RGB4444 encoded PNG, but keep using the default GL_UNSIGNED_BYTE, performance is the same. And even if you use an RGB8888 encoded PNG, and set the texture type to GL_UNSIGNED_SHORT_4_4_4_4, you get that performance benefit anyway.

 

However, if you are going to use GL_UNSIGNED_SHORT_4_4_4_4, then it makes sense to have an RGB4444 encoded image to start with, as you may benefit from a dithering algorithm that's tweaked to that particular bit depth.