Jump to content

RGBA8888 vs RGBA8888


Recommended Posts

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 by gregmax17
Link to comment
Share on other sites



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.

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...