<< Unity3D iPhone Player and JIRA Connect Integration | Home | Application Icon for Mac Store submission >>

How to get the best out of PVRTC for iOS

In case you didn't know Apple's mobile products use a chipset based on PowerVR technology. This technology had a brief period of being available on the desktop but it was never performant enough to make real headway on the desktop. It was also used by Sega's, largely considered a failure, last attempt at a console; the Dreamcast.

The Power VR technology received it's redemption with the surge in demand for capable mobile graphics. In this regards it's ahead of the competition, it provides a lot of bang for your battery life. We see it today in the hugely successful Apple mobile lineup.

For the mobile developer one of the quirks of working with PowerVR is it's textures compression. Power VR Texture Compression or PVRTC is pretty much the only texture compression available on the platform (although arguably RGB(A) 16 bit is texture compression). While the scheme provides pretty good compression results it can be tricky to get the best out of for the developer.

Details of how the compression works is not really for the casual user, as far as I can tell it operates in the frequency domain (using FFT?) and filters out "unnecessary" information out before being converted back to the spacial domain. If you don't understand it doesn't really mater. The short story is one is lumped with some caveats when using PVRTC.

The first caveat is you need to use square textures, and they need to be power of two in dimension. i.e. 32x32, 64x64, 128x128, 256x256, 512x512 and so on. Secondly, the result for textures with transparency isn't all that great. Thirdly at the texture edges you can get some bleeding around to the other side of the texture. This is particularly noticeable when using transparency in your textures.

Unity 3D when targeting iOS attempts to convert textures that seem suitable for PVRTC to this compression format. Historically the result are ok, but not as good as the image quality created by Power VR's own texture tools. If you're working heavily with PVRTC you might want to check out the official PVRTC tools. You find them here at the PVRTexTool page. I hear in Unity 3.5 that PVRTC is much improved. I haven't check this out for myself so I can't comment.

When working with PVRTC there are some things to keep in mind to get the best our PVRTC. Certainly the space you save alone make it work trying to use PVRTC on your iOS title. So below are some simple tips to heed when creating content bound for PVRTC.

  1. Stay away from the edges. As stated above PVRTC just doesn’t respect edges and bleeds off the side around to the corresponding other side. It's just a side effect of the way the compression works. It's not going to change. Pad the edges with a little alpha on all four sides. If you are doing a tiled texture, pad it out with the wrapped edge from the other side of the texture
  2. For the same reason as point 1; in a texture dictionary, do not place two textures right beside each other.
  3. Plan your gradients and lines. PVRTC is a lossy format and what is lost is some of this high frequency information. PVRTC is probably optimised for the photographs where loss of high frequency information is not so noticeable. PVRTC doesn't often play nice with gradient and hard lines. Try it out but if it's not pretty enough, do it differently. Gradients in an image can often be composited at runtime using a simple ramp texture. Lines can be small RGB textures, also composited. Experiment to get the result you want.
  4. Tweak and experiment. PVRTC result can vary a fair bit depending on starting texture. If you have particularly bad bleeding on one texture, sometimes just moving a component a few pixels in relation to another component on the texture can improve things dramatically when the image is compressed using PVRTC.
  5. Try using a slightly larger texture than you need. Sometimes a slightly larger texture will minimise the artefacts you find distasteful. With PVRTC you're often still saving space over a full RGB texture of the original resolution. Again, experimentation is required. Note the PVRTC compressed size and repeat.

Avatar: Alexandru Voica

Re: How to get the best out of PVRTC for iOS


Thanks for mentioning our texture compression format and tools!

For those who want to find out more about PVRTC and PVRTC2, I’ve also written two blog posts on the topic, including a comparison against other texture compression formats:




Re: How to get the best out of PVRTC for iOS

 Hi Alex. Thanks for dropping by point out those useful links. Much appreciated!

Avatar: Paulius

Re: How to get the best out of PVRTC for iOS

 Could you explain why that bleeding around the edges happens? Is there something in the format? Is there a reason why someone could not implement compressor which doesn't have that problem?

Avatar: Chris Kruger

Re: How to get the best out of PVRTC for iOS

Paulius. To the best of my knowledge (and hopefully somebody more knowledgeable will explain better on this thread) it is because the algorithm works in the frequency domain. The image data is converted to frequency data (the concept of the edge of the texture is lost) and then runs through whatever filtering it uses to simplify the data (thereby compressing it). While this creates a result that to the eye looks pretty good while maintaining a smaller file size, the edge of the texture is not respected. The edge is only re-introduced when the data is converted back to the spatial domain.

Compressors that work in the frequency domain likely all suffer from this problem. I suspect like a of compression algorithms the choice of end result is a bunch of tradeoffs. For PVRTC one of the tradeoffs for small size is bleeding.

Note that bleeding occurs all time in graphics, be it through mippmapping or other processes.

Avatar: Paulius

Re: How to get the best out of PVRTC for iOS


As far I understood that conversion from frequncy to spatial domain happens during compression, i.e. the format itself does not hold frequency information, but a "regular" spatial information. So it theory one could do some post-compression fixes to fix the edges, right?