These pages present a very simple comparison of a few of the better known texture compression methods used in the popular pc graphics boards and  games console systems. The factors that generally distinguish texture compression from other image compression techniques include...
 
1. The decompression algorithm is usually very simple
2. The bits per pixel value is fixed (unlike, say, JPG or GIF). This makes random addressing far simpler.
3. Small blocks of texels (eg 1x1 or 4x4) can be decompressed independently. This again is important to allow simple random addressing of texel data.

 
Four compression methods are examined and evaluated using several test images .

Copyright: Simon Fenney 2000 -2003


---

Compression Methods

The four that have been evaluated are listed below in approximately decreasing order of storage cost. This order is only approximate because three of the methods employ lookup tables and so when the source texture is quite small,  the size of the table can become a significant cost. However, for the test images chosen the table cost is insignificant.

The methods are...
 

• 256 Colour Palettised       (8 bits per pixel + 256 entry table)

This is perhaps the best known compression method, with each image requiring 8 bits per pixel plus a 256 entry colour table. It is a form of  vector quantization (VQ) compression, in which each pixel is replaced by an index into a predetermined set of colours (i.e. 3 dimensional, RGB vectors). The use of dithering or error diffusion alleviates the appearance of banding which would otherwise result from the limited palette.
 
 
• 16 Colour Palettised         (4 bits per pixel + 16 entry table)

This is essenitally the same as the above, except the choice of colours is reduced to a mere 16. This format has often been used in games consoles because of the limited memory space. Warning: The compression tool that was used here is probably not 'state of the art'. Better results could probably be obtained by using alternative algorithms such as Xiaolin Wu's  ( source code ).
 
 
• DXTC-1 aka S3TC                  (4 bits per pixel)

This compression method compresses each 4x4 blocks of pixels separately as 64bit blocks. Each block is represented by two 16 bit base colours, along with two others that are linear combinations of the two base colours. Each pixel in the block is then quantised to one of these 4 colours, and so only 2 additional bits per pixel is required. In a sense, this method is yet another form of VQ, except that the vector quantisation is only done locally on each 4x4 block.
The compression tool used in this evaluation is one I wrote rather than the S3 standard tool. (Unfortunately, the S3 tool appears to have disappeared from their web site). On these test images I felt that the standard tool gave inferior results, but that may just be due to personal taste.
 
 
• 2x2 pixel VQ                      (2 bits per pixel + 256x4 entry table)

This is another form of Vector Quantisation, similar to the palettised methods, except each 2x2 block of pixels get replaced by a single 8 bit index into a global table of 2x2 blocks. A more complex variant of this scheme was described in this Siggraph paper .


Compression Methods Not Tested
Three texture compression scheme were deliberately not evaluated: These were...
 

• 3Dfx's Narrow Channel method "YIQ"     (8 bits per pixel + 3x3 matrix (???))

This method really only has one advantage over standard 8-bit palettised compression:  The 256 entry lookup table is replaced with a much smaller 3x3 matrix. Since we are not concerned about the size of the table anyway, this aspect is not an issue. Furthermore, 8-bit palettised should always produce a better result.
 
• 3Dfx's FXT1                           (4 bits per pixel)

This is very similar to the family of DXTC compression methods and will  produce comparable results. Its main advantage is that translucent textures are also compressed at a rate of 4 bits per pixel unlike the DXTC family which requires 8 bpp.
 
• TREC

This system was proposed by Microsoft as part of the Talisman project. At present it is not being used probably because it's just too costly to put into silicon.

---

Evalution Method:

The results have been evaluated in 3 ways:

• Visual Comparison at Equal Resolutions

Images been compressed and then decompressed using the various methods, and then displayed at the same resolution. The reader is invited to visually compare the results.
 
• RMS (Root Mean Square) Error

This is a numerical estimate of the difference between the original and compressed/decompressed results. The differences between each each pixel channel are squared and averaged, and then the square root is taken. Generally speaking, the smaller the value, the better the result.

Although the RMS error does give an indication of the quality of compression, it is a far from perfect metric as it does not take into account the eye's behaviour. For example, although dithering/error diffusion generally improves the representation of compressed images, it will usually increase the RMS error.
 
 

• Visual Comparison with Equal Storage Costs

An alternative way of looking at compression quality is to compare the images given a a fixed texture memory budget.

The test involves selecting the highest resolution texture that will fit into a particular amount of memory using the given texture compression method. Each image is expanded and displayed at the original resolution using bilinear filtering, which is typically available in 3D hardware. RMS values are also given which compare the bilinearly expanded image with the original full-resolution source data.

---

Test Images:
Since each compression method has various strengths and weakenesses, three categories of  images have been used:

1. Photographic images
2. Typical game textures
3. A synthetic test images

The images will be displayed using high quality JPG. Although this is a lossy compression format, I don't believe the differences are visibly significant. I had intended to store PNG (offering a lossless compressed 24 bit format) versions of the images, but unfortunately I don't have a lot of diskspace on this website and so this has been shelved.

Currently, due to time contraints, only one image of each type has been examined.

Photographic Source Image: Lena512
Game texture:Unreal512
Synthetic Test Image:synth256

Conclusions:
Since there is no good model for measuring the quality of image compression, the following must be regarded as being based on personal opinion.  My conclusions, in no particular order, are...
 
• Except for very special cases,  4 bpp palettised textures are effectively obsolete. DXTC gives the same compression rate at substantially better image quality, and VQ gives better (or at least no worse) results at a higher compression ratio.

 
• It appears that it takes  rare cases to make DXTC look bad, assuming identical resolutions. Of course, this may be influenced by the resolution of the display device.

 
• Given identical memory requirements, it appears that the VQ may be better than DXTC. What was interesting was that the RMS error for the "Equal storage costs" was almost identical for the 24bit, 8bit, and DXTC modes on all three test cases.