Gamasutra is part of the Informa Tech Division of Informa PLC
This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
Page 3 of 3
Possible Applications for VQ
Your project may benefit from VQ image compression if you have access to the renderer and you can implement decompression directly inside it. It is also helpful if you can't rely on your hardware renderer supporting a particular standard texture-compression format and still need to stream from disk significant amounts of image data.
What about DXTn texture compression, you might ask? Well, if you can count on hardware support for a texture-compression scheme on your minimum target platform, it is most certainly a good idea to stick with it: after all, somebody has already paid for the tens of thousands of transistors to implement it, and you'd better make good use of them, save tons of RAM on the video card, and keep its precious memory bandwidth down. However, if, for some reason—for example, software rendering (gasp!), texture preprocessing, or support for legacy hardware (where "legacy" may mean "older than nine months" in our business)—you need to have at some point in your application access to the decompressed pixels of your texture, VQ might provide a better answer. DXTn compresses textures to 4 bits/pixel (for fully opaque or single-bit-alpha images) or 8 bits/pixel (for images with alpha), while in our experiments we rarely needed more than about 3 bits/pixel with VQ. Decompression times for DXTn are much larger than those for VQ: in our experiments with a 1024x1024 true-color image, DXTn decompression took about 200ms, straight copying of uncompressed data took about 25ms, and VQ decompression from a 256-entry codebook took about 16ms. (Note: We didn't have access to DXTn decompression source code, so we did what most developers would do to decompress DXTn textures, we made the DirectX drivers do it for us. Driver code may or may not be optimized, so above figures should be taken with a grain of salt. Still, the nature of DXTn compression makes us believe that it's impossible to reach VQ decompression speeds.)
|
 |
 |
||
 |
||||
 |
FIGURE 7. "Lena" uncompressed. |
|||
|
|
 |
|
||
|
|
||||
|
|
FIGURE 8. VQ-compressed "Lena," codebook size 1,024, compression time 6 minutes, 2.6 bits/pixel. |
|||
Here's a quick summary of pros and cons of VQ for image compression:
Pros:
Cons:
Sample Code
This article is accompanied by sample code for a command-line compression tool and a minimalistic compressed file viewer. To build them you'd need Microsoft Visual C++. No libraries outside the Win32 API and the STL are used.
Two samples of images compressed with this tool are shown in Figures 5 through 9. Running times are for a 600MHz Pentium III for the SSE version of the algorithm. The bits-per-pixel ratios are for the case where 10- or 11-bit codebook indices are packed tightly, not padded to 16 bits.
|
|
 |
|
||
|
|
||||
|
|
FIGURE 9. VQ-compressed "Lena," codebook size 2,048, compression time 10 minutes, 2.9 bits/pixel. |
|||
Page 3 of 3
