3 ms·

I'm not familiar with PVRTC, unfortunately. Here's one of the better articles I could find: http://www.kihongames.com/blog/labs/2011/04/labs-pvrtc-powervr-text

I'm not familiar with PVRTC, unfortunately. Here's one of the better articles I could find: http://www.kihongames.com/blog/labs/2011/04/labs-pvrtc-powervr-texture-compression/ http://www.kihongames.com/blog/labs/2011/04/labs-pvrtc-power... Some highlights from the article: - "Avoid using PVRTC when you have static images that are the focus of your content" - "images are 2-4x larger, but memory use is less" - "amazing memory improvement, but no real change in performance" - "textures must be power of two" It probably doesn't fit my use case, but it's fascinating.

kstenerud 14y ago
Right now you are using 32bpp images, and then falling back to 16bpp for slower devices. Because PNG uses zip-style compression, pictures of houses won't compress that well, so your size on disk and size in memory will be similar. PVRTC allows you to save at 4bpp or 2bpp, so you'll get sizes 8x or even 16x SMALLER than a full color image, both on disk and while loaded into memory (loading images are a major source of lag on iPhone, so a smaller on-disk footprint is always welcome). You can even zip compress it for further on-disk savings, though YMMV. The quality degradation is similar to what you'll get in JPEG, in that there will be some artifacting depending on the quality of the encoder and the source image (hard edges don't compress well, nor does text, but photorealistic images retain a lot of quality). The power-of-2 restriction is the only real pain point of PVRTC. But if you're making sprite sheets, that's probably not going to be a big issue for you anyway. Once it's in memory it's just a texture like any other, and you can use it sprite sheet style like you're already doing, chopping up the contents any way you choose. I suggest you try cropping one of your house images to a square sized power-of-2 as a quick test and convert it to PVRTC so you can see for yourself what the quality is like. It may yet be usable for your purposes, and the potential payoff is huge.
- kstenerud 14y ago
  Actually here you go: I took the first image from here: http://www.dwellable.com/h/8559/Cape-Cod/Upper-Cape-Cod/Falmouth/East-Falmouth/155-Teaticket-Path http://www.dwellable.com/h/8559/Cape-Cod/Upper-Cape-Cod/Falm... Cropped it to 1024x1024 (you'd of course make a sprite sheet instead). Then shrank it to 512x512 just for demonstration purposes. I then converted it using texturetool, also back-converting it to make a png with exactly the pixels produced in the PVRTC image: $ texturetool -e PVRTC --channel-weighting-perceptual --bits-per-pixel-2 -p converted2.png -o converted2.pvrtc original.png $ texturetool -e PVRTC --channel-weighting-perceptual --bits-per-pixel-4 -p converted4.png -o converted4.pvrtc original.png The PVRTC images are significantly smaller, both on disk and in memory: $ ls -l original.png -rw-r--r-- 1 kstenerud staff 571225 Jul 27 15:10 original.png $ ls -l converted*.pvrtc -rw-r--r-- 1 kstenerud staff 65536 Jul 27 15:12 converted2.pvrtc -rw-r--r-- 1 kstenerud staff 131072 Jul 27 15:12 converted4.pvrtc Here's the quality: Original image: http://i.imgur.com/flT7c.png http://i.imgur.com/flT7c.png 4bpp image (converted back to png): http://i.imgur.com/Itz4F.png http://i.imgur.com/Itz4F.png 2bpp image (converted back to png): http://i.imgur.com/tzqlw.png http://i.imgur.com/tzqlw.png
  - gurgeous 14y ago
    Ooh, cool! We're using JPGs, though. At quality 75: 67K flT7c.jpg 558K flT7c.png Once those JPGs make it across the network and arrive on the device, we're stuck with plain old CGImages, right?
    - kstenerud 14y ago
      Yeah. When you load a JPEG image, it gets decoded to a 32bpp image in memory on the device. PVRTC images, on the other hand, stay the same size (2bpp or 4bpp) when loaded into memory. Plus they don't need to be decoded. So this 512x512 image would take 64k of RAM using 2bpp pvrtc, 128k using 4bpp pvrtc, and a whopping 1MB using JPEG or PNG.
- geon 14y ago
  Another thing to look out for with PVRTC compression is that you tend to get compression artifacts along the edges of the texture. If you attempt to tile multiple texture to form a larger image, they will show up as very distracting lines. It can be fixed by discarding the last few pixels of each edge.

kstenerud 14y ago

Right now you are using 32bpp images, and then falling back to 16bpp for slower devices. Because PNG uses zip-style compression, pictures of houses won't compress that well, so your size on disk and size in memory will be similar. PVRTC allows you to save at 4bpp or 2bpp, so you'll get sizes 8x or even 16x SMALLER than a full color image, both on disk and while loaded into memory (loading images are a major source of lag on iPhone, so a smaller on-disk footprint is always welcome). You can even zip compress it for further on-disk savings, though YMMV. The quality degradation is similar to what you'll get in JPEG, in that there will be some artifacting depending on the quality of the encoder and the source image (hard edges don't compress well, nor does text, but photorealistic images retain a lot of quality). The power-of-2 restriction is the only real pain point of PVRTC. But if you're making sprite sheets, that's probably not going to be a big issue for you anyway. Once it's in memory it's just a texture like any other, and you can use it sprite sheet style like you're already doing, chopping up the contents any way you choose. I suggest you try cropping one of your house images to a square sized power-of-2 as a quick test and convert it to PVRTC so you can see for yourself what the quality is like. It may yet be usable for your purposes, and the potential payoff is huge.

kstenerud 14y ago
Actually here you go: I took the first image from here: http://www.dwellable.com/h/8559/Cape-Cod/Upper-Cape-Cod/Falmouth/East-Falmouth/155-Teaticket-Path http://www.dwellable.com/h/8559/Cape-Cod/Upper-Cape-Cod/Falm... Cropped it to 1024x1024 (you'd of course make a sprite sheet instead). Then shrank it to 512x512 just for demonstration purposes. I then converted it using texturetool, also back-converting it to make a png with exactly the pixels produced in the PVRTC image: $ texturetool -e PVRTC --channel-weighting-perceptual --bits-per-pixel-2 -p converted2.png -o converted2.pvrtc original.png $ texturetool -e PVRTC --channel-weighting-perceptual --bits-per-pixel-4 -p converted4.png -o converted4.pvrtc original.png The PVRTC images are significantly smaller, both on disk and in memory: $ ls -l original.png -rw-r--r-- 1 kstenerud staff 571225 Jul 27 15:10 original.png $ ls -l converted*.pvrtc -rw-r--r-- 1 kstenerud staff 65536 Jul 27 15:12 converted2.pvrtc -rw-r--r-- 1 kstenerud staff 131072 Jul 27 15:12 converted4.pvrtc Here's the quality: Original image: http://i.imgur.com/flT7c.png http://i.imgur.com/flT7c.png 4bpp image (converted back to png): http://i.imgur.com/Itz4F.png http://i.imgur.com/Itz4F.png 2bpp image (converted back to png): http://i.imgur.com/tzqlw.png http://i.imgur.com/tzqlw.png
- gurgeous 14y ago
  Ooh, cool! We're using JPGs, though. At quality 75: 67K flT7c.jpg 558K flT7c.png Once those JPGs make it across the network and arrive on the device, we're stuck with plain old CGImages, right?
  - kstenerud 14y ago
    Yeah. When you load a JPEG image, it gets decoded to a 32bpp image in memory on the device. PVRTC images, on the other hand, stay the same size (2bpp or 4bpp) when loaded into memory. Plus they don't need to be decoded. So this 512x512 image would take 64k of RAM using 2bpp pvrtc, 128k using 4bpp pvrtc, and a whopping 1MB using JPEG or PNG.
geon 14y ago
Another thing to look out for with PVRTC compression is that you tend to get compression artifacts along the edges of the texture. If you attempt to tile multiple texture to form a larger image, they will show up as very distracting lines. It can be fixed by discarding the last few pixels of each edge.