(牛帖)PVRTC compression increasing the file sizes of PNG


For iPhone game development, I switched from PNG format to PVRTC format for the sake of performance. But PVRTC compression is creating files that are much bigger than the PNG files.. So a PNG of 140 KB (1024x1024) gets bloated to 512 KB or more in the PVRTC format.. I read somewhere that a PNG file of 50KB got compressed to some 10KB and all, in my case, its the other way around..

Any reason why it happens this way and how I can avoid this.. If PVRTC compression is blindly doing 4bpp conversion (1024x1024x0.5) irrespective of the transparencies in the PNG, then whats the compression we are achieving here..

I have 100s of these 1024x1024 images in my game as there are numerous characters each doing some complex animations.. so in this rate of 512KB per image, my app would get more than 50MB.. which is unacceptable for my customer.. ( with PNG, I could have got my app to 10MB)..

link | improve this question
Do you mean that you have animation sequences saved as 1024x1024 PNGs?Will Nov 6 '09 at 19:16
yes.. most of them are 1024x1024 sized PNGs.. altho mostly it has gotta to do with the PVRTC requiring the images to be in square.. otherwise they can be smaller sized PNGs..Sankar Nov 9 '09 at 5:22
feedback

4 Answers

up vote 9 down vote accepted

In general, uncompressed image data is either 24bpp (RGB) or 32bpp (RGBA) flatrate. PVRTC is 4bpp (or 2bpp) flatrate so there is a compression of 6 or 8 (12 or 16) times compared to this.

A requirement for graphics hardware to use textures natively is that the format of the texture must be random accessible for the hardware. PVRTC is this kind of format, PNG is not and this is why PNG can achieve greater compression ratios. PVRTC is a runtime, deployment format; PNG is a storage format.

PVRTC compression is carried out on 4x4 blocks of pixels at a time and at a flat bit rate so it is easy to calculate where in memory to retrieve the data required to derive a particular texel's value from and there is only one access to memory required. There is dedicated circuitry in the graphics core which will decode this 4x4 block and give the texel value to your shader/texture combiner etc.

PNG compression does not work at a flat bitrate and is more complicated to retrieve specific values from; memory needs to be accessed from multiple locations in order to retrieve a single colour value and far more memory and processing would be required every single time a texture read occurs. So it's not suitable for use as a native texture format and this is why your textures must be decompressed before the graphics hardware will use them. This increases bandwidth use when compared to PVRTC, which requires no decompression for use.

So for offline storage (the size of your application on disk), PNG is smaller than PVRTC which is smaller than completely uncompressed. For runtime memory footprint and performance, PVRTC is smaller and faster than PNG which, because it must be decompressed, is just as large and slow as uncompressed textures. You might gain some advantage with PNG at initialisation for disk access, but then you'd lose time for decompression.

If you want to reduce the storage footprint of PVRTC you could try zip-style compression on the texture files and expand these when you load from disk.

link | improve this answer
Actually PNGs are a zipped internally. So zipping your PVRTCs you ought to end up with smaller files. However, as the answer points out PVRTC is all about reducing memory size in VRAM and not about disk space. PNG is just opposite, small disk space but MB's when expanded in VRAM . deft_code Aug 21 '10 at 22:21
Great answer! Solves many about PVRTC.Eonil Mar 27 '11 at 10:06
feedback

PVRTC (PowerVR Texture Compression) is a texture compression format. On devices using PowerVR e.g. most higher end mobile phones including the iPhone and other ARM-based gadgets like the iPod it is very fast to draw since drawing it is hardware accelerated. It also uses much less memory since images are represented in their compressed form and decoded each draw, whereas a PNG needs to be decompressed before being drawn.

PNG is lossless compression.

PVRTC is lossy compression meaning it approximates the image. It has a completely different design criteria.

PVRTC will 'compress' (by approximating) any type of artwork, giving a fixed bits per texel, including photographic images.

PNG does not approximate the image, so if the image contains little redundancy it will hardly compress at all. On the other hand, a uniform image e.g. an illustration will compress best with PNG.

Its apples and oranges.

link | improve this answer
I know what PNG and PVRTC compressions are.. I was asking why PVRTC compression creates a bigger file inspite of doing the approximations and 4bpp thing..Sankar Nov 6 '09 at 11:06
so 4bpp means take the original image and for each pixel, store in 4 bits. So lets do the maths: 1024x1024x0.5 = 524288 = 512KB. What were you expecting? Will Nov 6 '09 at 11:25
1
Bloat? The decoded PNG will take 1024x1024 x3 or x4 depending on whether its RGB or RGBA. Thats... 3 or 4MB of RAM. The same image in PVRTC will take 512KB (0.5MB) of RAM at all times. Will Nov 6 '09 at 11:28
Thanks for that info.. However, most of my PNG was transparent.. so its size was small.. of 140KB.. which means PVRTC does not treat transparency differently and does simple 4bpp on all the pixels?? I dont understand why they call this as a compression technique. its plainly stupid.. except that it has hardware acceleration.. Then how would I reduce the size of my eventual iPhone application using PVRTC? cos I would have close to 100 images of these size.. with PNGs, the app would be around 10MB.. but PVRTC may make my app size to some 50MB..Sankar Nov 6 '09 at 13:15
1
@Sankar update your question to ask about this more specifically, perhaps give some upvotes, and I'll think about a new answer, as the question seems to be a moving targetWill Nov 6 '09 at 13:25
show3more comments
feedback

dramaticallyreduce your memory consumption.

If you images are, say, 64x64, then you can place 256 of them on a 1024x1024 texture in a 16x16 arrangement.

With a little effort, images do not need to be all the same size, just so long as you keep track in the code of the rectangle in the texture that each image is at.

This is how iPhone game developers do it.

link | improve this answer
feedback

I agree with Will. There is no point in the question. I read the question 3 times, but I still don't know what Sankar want to know. It's just a complain, no question.

The only thing I can advice, don't use PVRTC if you mind to use it.It offers performance gain and saves VRAM, but it won't help you in this case. Because what you want is just reducing game volume, not a consideration about trade-off between performance and quality.

link | improve this answer
Thanks for reading the question 3 times and finding the point that there is no point in the question and still finally answering it in a generic manner.. anyway.. I have got my answer.. that there is nothing called PVRTC 'compression' cos it does not 'compress', it is just a format.. my confusion was due to generic usage of the word 'compression' in regards to PVRTC. SankarFeb 8 '10 at 5:03
The term 'compression' means making data volume smaller by special encoding. Not for specific algorithm. Sometimes it indicates 'encoding' action itself. (decompression for decoding in this case)Eonil Feb 8 '10 at 7:13
In the case of PVRTC, the term 'compression' just applied for in-memory volume. PNG takes less volume, but it's only case of in-disk situation. PNG must be decompressed in memory as plain bitmap to be used by GPU. Because GPU cannot understand and handle PNG. So it takes larger space than PVRTC in memory. Memory and disk are different space. Each format has their own values in each spaces. If you think the 'compression' is possible only in disk, PVRTC is a new concept to you. It's an in-memory compression. This is possible because GPU supports it directly.Eonil Feb 8 '10 at 7:18

你可能感兴趣的:(compression)