As I mentioned in my previous post, PNGs on android can be pretty gnarly, and a large portion of the asset footprint, for example, over 180 APKs, here was the breakdown between texture formats:

From the graph above, you can see that PNG files make up 78% of the total texture footprint.

Note: I’m not saying that PNGs take up 78% of total asset footprint, but rather in the sub-section of.

To some, it may seem that I’m on a holy campaign to convince developers to avoid using PNGs; That’s because I am. I believe the overusage of PNG files in HTML/Android games can be directly attributed to a lack of understanding about the proper way to address / use / design your texture resources.

Does PNG size matter for android games?

If you consider that there seems to be some self-selecting market factors in place for the size of assets, then you can assume that the size of your APKs matter, and therefore, reducing the size of PNGs does, infact, matter.

Isn’t PNG a really good compression format?

matter. I've covered how complex PNG files can be, their potential to be problematic for developers, and how import it is to consider alternatives for web developers. But to further drive this point home, let's take a look at a visual example. In the image below, I've exported a pure red 16x16 24bpp image (no alpha) from Photoshop directly (using SaveAs function) vs exporting it using SaveForWeb.

The difference here is shocking. The Web-Exported version of the PNG is 96% smaller than the basic exported counterpart. This simplistic example illustrates the worst-case scenario for PNG exportation, a simple red square can easily be more bloated than you’d expect.

Android AAPT

The Android toolchain folks realize that PNGs are required for icons and other in-app formats, and as such, built in PNG compression processing into the toolchain. The Android Asset Packaging Tool (AAPT) will perform repacking of your PNG texture assets in order to attempt to reduce the filesize of your APK files. The tool itself doesn’t do anything too tricky, keeping it classy, and simple:

Bitmap files may be automatically optimized with lossless image compression by the aapt tool during the build process. For example, a true-color PNG that does not require more than 256 colors may be converted to an 8-bit PNG with a color palette. This will result in an image of equal quality but which requires less memory. So be aware that the image binaries placed in this directory can change during the build.

Which is great; Images that have a low number of unique colors are automatically translated to an indexed PNG format in a lossless form. (A lossy solution would introduce noise which may be unwanted). If however, the image has more than 256 colors, it’s left alone.

Thanks to my previous analysis, I can see how often this is this tool is successful in finding and converting textures. When you catalog all the PNG format types that come from our sample set, you can see that there’s quite a few that have this process run on them:

FMT	BPP	#Files
RGBA	32	29,081
Indexed	8+	18,805
RA	16	1,651
RGB	24	1055
R	8	235
		894

RGBA, 32bpp is the dominant form of PNG files being used by game developers. Which make sense, considering the dominant form of apps in my analysis were 2D games.

Palletized PNG images make up the 2nd most common form of PNG, mostly due to the fact that the AAPT tool will convert PNGs into that format directly. I’m happy to see such a bulk of the PNG files falling into this format, it means that AAPT is doing it’s job, and reducing memory footprint properly.

The stark contrast between RGBA32 and RGB24 textures makes me think that developers are easily wasting space in images through atlasing. For example, textures which may be completely opaque are being grouped with transparent textures, and wasting pixel space as a result.

More aggressive PNG optimization

PNG’s Deflate option is a lossless encoder, but that shouldn’t stop you from embracing a lossy preprocessor if you want one. Image processing tools, can compress your PNG image in a lossy method as a pre-process before passing it off to the final PNG format. This creates a two-step process where your lossy, and lossless compression are done by two separate applications. The results are impressive, the reduced color space allows the lossless compressor to find, and make, more frequent matches in the file, yielding to better compression.

A quick google search yields some easy-to-grasp apps that all do more aggressive PNG processing. Any of these apps would be fine, pick one that works well in your artists’ workflow, and adopt the hell out of it.

PNGQuant	ImageMagick	AdvDef
PNGOut	PNGCrush	OptiPNG
CryoPNG	PunyPNG	Yahoo Smush.it
PNG Optimizer	PNG rewrite	ZopfliPNG
PNGWolf	TruePNG	DeflOpt
Defluff	Huffmix	PNGKT
PNGnq-s9	Median Cut Posterizer	ScriptPNG

One of the most powerful (and impressive) of the lot is ScriptPNG, a tool which will cycle through several of the above applications, and choose the best one for the specific image. SO yea, start there!

Conclusion

Android developers do not get a free pass when it comes to incorrectly using texture files. Sure, they have a different profile when it comes to how users expect to download them, but that doesn’t forgive abuse. Plus, PNG files really only help with xfer times, not gpu residence size. So while you benefit in terms of distribution, you’re still taking up bloated space on the GPU. Even something as simple as adopting a 565 or 5551 format would cut your overall PNG texture footprint in half.

Remember developers, #everybitcounts

~Main

You can find Colt McAnlis here: