views:

943

answers:

2

Is there a standard mechanism or known library that will convert .png images to compressed PVRTC textures on the iPhone itself (not during development using the standard tools on OS X).

I have a number of .png textures in my application but swapping is an issue. I'd like to create PVRTC variants of the .pngs on the device, should the available memory be low on application startup (or perhaps on first load of the application).

A: 

I'd be careful assuming that this will help you. Once you reference the images once, i.e. load them into a UIImage, the iPhone will start to cache your pngs whether you like them or not. Compressing them will not serve you well to achieve what you're looking for here, in my opinion.

Chaos
I wasn't intending to load the .pngs if PVRTC was more appropriate. The first thing I want the app to do is examine the available memory and choose the correct format to use for the rest of applications execution. I just don't want to ship two variants of the same image in the original download.
bradhouse
+2  A: 

I haven't seen any information on the net regarding how to construct PVRTC images manually and to the best of my knowledge there is no support for this built into the iPhone (and it wouldn't be needed to read the PVRTC files).

For most applications, there is little sense to include or construct both versions of the files. Under optimal conditions, the PVRTC versions should be virtually indistinguishable from the PNG versions and are really just "pre-processed" versions of the files optimized for direct streaming into the video memory.

It is generally best to go through all of your images and make decisions regarding how to best package the image to balance memory conservation and quality for all users, not just under specific restricted memory situations.

A few things to consider (apologies if this is redundant knowledge):

  1. PVRTC files can have problems with complex alpha blended images as the pre-processing can cause unsightly artifacts along the blended edges.
  2. Opaque PNG files should have their alpha channel removed in the original image (saving memory and blending overhead).
  3. For images with a limited range of colors, reduce the image from PNG32 to PNG16 or PNG8 to save memory on disk.
  4. If this is for OpenGL based programs, consider using an enhanced version of Texture2D (such as from Cocos2D) which supports alternate pixel formats such as 565 and 4444. This can greatly reduce the overhead in the graphics card with minimal impact on image quality, by carefully choosing a pixel format which corresponds to the balance of colors in the original image.
  5. Additionally for OpenGL based programs, avoid individual images (320x480) for backgrounds as this will result in a 512x512 texture in memory for each one. Break the image into smaller pieces or make the image 512x512 and fill the extra space with other images so that only one texture needs to load.
  6. As with everything, focus on the largest images first to get the biggest bang for the buck.

It's also worth noting that since your application will be the only thing running (other than system applications), the only real memory overhead is going to be a limited amount of "disk" space. Making a second copy of all the image files will actually be working against you instead of helping.

Barney

Barney Mattox
Thanks for the reply. I was already familiar with those points (I also use Cocos2D). I already use a few 1024x1024 texture sprite sheets. I've tried alternative pixel formats and PVRTC. For regular use they degrade the quality of my UI more than I'm willing to allow. But for really low memory situations (e.g. where my app is launching with <10Mb free memory available) I wanted to run in a degraded quality mode.
bradhouse