Imaging supported DXT image/texture compression since one of the earliest releases. Quality of compressed images isn't very high though (at least the compression isn't too slow). For future Imaging versions I plan to ditch the current compression code and add a new one. To be precise, two new ones - fast and lower quality (still probably better than current Imaging's compression), and slow and higher quality mode. Fast one will be based on Real-Time DXT Compression by Id Soft. I'm not decided on high quality one yet, but probably something like cluster fit algorithm from Squish library.
Mainly for testing purposes during implementation of these new methods, I want to create extension for Imaging that compares two images (original and one reconstructed from compressed original) and measures PSNR and some other quality metrics.
I'm also thinking of implementing DXT5 based format using YCoCg colorspace and PVRTC (texture compression currently used in iPhone).
Few links if you're interested:
- Brief DXTC overview: http://en.wikipedia.org/wiki/S3_Texture_Compression
- More technical details: http://www.opengl.org/registry/specs/EXT/texture_compression_s3tc.txt
- YCoCg-DXT related: http://developer.nvidia.com/object/real-time-ycocg-dxt-compression.html
Here's some quick comparison of DXT compressors (click the image to see full size). Value in brackets is MSE (mean square error) - lesser number means compressed image is more similar to original.
Interesting that ATI’s compressor beats squish, have you tried with different patterns? it could be that some algorythms favor the gradients, so it should be tested with more patterns.
Well, ATI’s compressor is very good too. But yea, testing one image doesn’t really say anything.
I’ll be creating some automated tool for quality comparisons of batches of images for Imaging later, so this should give more interesting results.
There are also some tests of DXT compressors in “Real-Time DXT Compression” paper (link is in the article).