The work now i am doing is transplanting a project from iOS to Android. The problem is the resource is too big, both the file size and memory usage.
After do search in the internet and consult some friends, i am focusing on the ect1 format of compressed texture. Since it is the basic format of texture compression of OpenGL ES 2.0,
almost all the android machines support it.
The tool i have used is Mali Texture Compression Tool v4.0.1. Just at the begining, some problem happend:
the transformed ".ktx" file size is too bigger against the imagination.
The original image format is png-24.
I found some ktx file sizes are about the half of png, and some unexpectedly are bigger than png files. And i also did the compression of the whole resource, and the total size is also bigger than png format. What a puzzled!
To my opinion, if the etc1 represent a pixel with 4 bits(0.5 byte), the transformed ".ktx" file size should be more or less with png-8(4 bits depth).
The order i used is:
etcpack.exe input_filename out_directory -s fast -e perceptual -c etc1 -ktx
Is there some wrong with the arguments?
Or my imagination of the compression ratio is not right?
PNG is a lossless compression which can take state from the whole image, but which requires a lot of state to decompress even a single pixel. Even though the color fidelity in PNG is 24-bit, in some cases it will perform much better than a real-time texture compression at 4-bits per pixel. For example on my desktop a 1024x1024 PNG image which is a single color compresses to only 5KB - or 0.04bpp.
Real-time texture compression schemes such as ETC, ASTC, etc are designed for very fast decode of random samples, so they have very different design constraints to traditional compression formats such as PNG or JPEG. Please don't compare them, as you are not comparing like with like.
> too bigger against the imagination
The standard ETC compression provided by Khronos is always 4bpp, so all implementations of that will have identical bitrate. The the proprietary PVRTC compression provided by Imagination also has a 2bpp mode, which is lower quality than ETC1 4bpp but half the bitrate. There is no 2bpp mode for ETC1/2.
Khronos have now release a new Khronos-approved texture compression extension for a format called ASTC *, designed by ARM, which is available as an extension on Android. It is relatively new, but it is available today ** for ARM Mali devices from Mali-T624 onwards, and many other hardware vendors will also be supporting it, it just takes a bit of time to get consumer devices to market. ASTC provides a large amount of flexibility in bitrate with 12 levels ranging from 8bpp for high fidelity compression, all the way down to 0.89bpp for space sensitive resources which can survive being compressed heavily, as well as support for 1,2, 3 or 4 color channels. At 2bpp ASTC beats PVRTC significantly in terms of image quality, so it is a good step forwards.
*EDIT* One thing to check ... the KTX file format has some overheads such as a header block. For very small images most of the cost will be in the KTX header, rather than the texture data itself. In addition the KTX file format can store multiple mipmap levels in one file, so if you have mipmap generation enabled then you would expect to see the file size increase by ~35%.
Hope that helps, Pete
* GDC Booth Presentation by ARM - ASTC: the future of texture compression - YouTube
** ASTC-capable Devices Hit the Streets « Mali Developer Center