现在的位置: 首页 > 综合 > 正文

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

2018年05月17日 ⁄ 综合 ⁄ 共 7256字 ⁄ 字号 评论关闭

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

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 target
 – Will Nov
6 '09 at 13:25

show 3 more
comments

feedback

dramatically reduce 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.
 
– Sankar Feb
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
 

抱歉!评论已关闭.