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...
- The decompression algorithm is usually very simple
- The bits per pixel value is fixed (unlike, say, JPG or GIF). This
makes random addressing far simpler.
- 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:
- Photographic images
- Typical game textures
- 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.