What are DXT and DDS?

DXT is a set of compression algorithms or codecs applied to raster/bitmap images. The set is also known as S3 Texture Compression (S3TC). They all convert 4x4 blocks of pixels to either 64-bits or 128-bits depending on the codec. All are lossy algorithms. The original codecs were created by S3 Graphics, but many non-encumbered alternatives exist now. There are many different codecs: DXT1, DXT3, DXT5, etc. I'll talk more about them in a moment.

DDS (Direct Draw Surface) is an image file format, rather like a container for storing image data compressed using one of the DXT codecs. It was developed by Microsoft and introduced with DirectX 7.

Together, a DDS file containing data organized using a DXT code creates an image file that can be used in most graphical applications, at least those that support DDS natively or via a plug-in. DDS files are very common in the game industry, where advantages in loading speed and video memory savings outweigh disadvantages.

How does it work?

DXT sees images as collections of 4x4 blocks of pixels called "texels". For every texel, DXT selects two colors from the texel, each determining one end of a color range of 4 colors. The middle two colors are interpolated. The sixteen pixels of the texel are then assigned a 2-bit index (0-3) that maps them to the color range. The two representative colors are stored as 16-bit RGB values (5:6:5). So each texel requires 2x16 bits for the colors, plus 16x2 bits for the indices, giving a total of 64 bits for each texel, which equates to 4 bits per pixel. So for any set of images having the same dimensions, compressed size will always be the same.

What if the image has an alpha channel? How DXT handles this depends on the codec used. In DXT5, the alpha channel is encoded using a second set of 64 bits for each texel. DXT5 stores alpha information in a way that is almost the same as color information. Two alpha values are selected and used as the extremes for a range of transparency values. The alpha values are represented by 8 bits each, and the range indices by 3 bits each, allowing for gradients of up to 8 shades.

DXT3 handles the alpha channel a little differently. Each pixel gets 4 bits to represent its alpha, for a total of 16 unique values of transparency. This allows the alpha channel to be represented more accurately than DXT5, but with less subtle transitions.

So, for an image with no alpha using DXT1, compression results in an image using 4 bpp (bits per pixel). For an image using DXT3 or DXT5 incorporating an alpha channel, the requirements will be 8 bpp. Note that the actual image size will likely be larger, as it will frequently include mipmap data.

What are the advantages of DDS files and DXT compression?

Fast load times. DDS files are ready to be used by the graphics system and can be read straight into graphics memory with little overhead. In situations where many files are being constantly swapped in/out of the graphics unit, this can be a substantial savings and can reduce "lag", especially with big texture files.

Mipmaps can be pre-generated and included in the DDS files. This is another savings in load times and gives the graphic designer control over mipmap construction. More on mipmaps in a moment.

Data remains compressed in video memory. All image formats except DDS/DXT are loaded into graphics memory in flat, uncompressed state. (And uncompressing them takes time and resources.) DDS/DXT files remain in their compressed state in video RAM, using special algorithms on the video card to retrieve data on demand. Compression ratio is 6:1 if no alpha channel is used, or 4:1 if an alpha channel is used. This can result in huge video memory savings.

What are the disadvantages?

DXT codecs are lossy. What is stored as compressed data is not the same as the original image, and on a fine level it may not even be close. Images with high contrast regions such as print or cartoon-like colors and borders will likely generate visible artifacts, particularly with smaller resolutions. For this reason DXT can be problematic when used with normal maps, though there are work-arounds. I'll come back to this issue. Never use DDS files for editing and archiving.

The compression degrades the original colors. It is not a good format where retention of the true color is critical, particularly in those situations where fine differences may have a large impact. DXT generates images using a 16 bit color depth. Where formats like JPG or PNG use 8 bits per channel per pixel (RGB 8:8:8) for a 24 bit color depth (32 bits with PNGs having an alpha channel), DXT reduces the spectrum down to 5:6:5 bits using an interpolation algorithm to arrive at the new color values. In short, you lose much of the original color range. But many graphic applications in games and sims don't require tight control over the colors, and good choice of color palette can eliminate any visible results of this DXT effect.

File size on disk can be large for DDS. For example, a 1024x1024 image with an alpha channel and mipmaps will result in a 1.37MB file. But file size is a relatively small consideration these days. Game/simulation performance matters far more.

Are there any image dimension limitations?

DDS/DXT images can be of any dimension expressed in powers of two up to the limits of your application or hardware, but no dimension can be less than 4. So 1024x512 is fine, but 2048x2 is not. Since DXT compression works with texels and each texel is a 4x4 block of pixels, it follows that DXT can't work with an image with a dimension smaller than 4.

DDS and Mipmaps

An object seen up close needs a relatively high-resolution texture so that it doesn't look pixelated. But an object seen in the distance needs much less resolution to look reasonable, and smaller resolutions require less resources. A mipmap is a set of pre-calculated versions of the same image progressively decreasing in size until the image reaches a dimension of 1x1. The idea is to have a handy set of smaller images that can be used to increase rendering speed and reduce aliasing effects while allowing the creator to optimize the appearance of the image at each stage. With mipmaps, the render engine can use the smaller, pre-processed version. This speeds things up significantly when you consider a scene of many objects at varying distances from the viewer.

With most image file formats, the render engine must generate the mipmaps when the image is loaded. This takes time, and the render engine may not make the best choices for the appearance of the image. DDS files give you control over this process, allowing you to pre-generate mipmaps and store them ready-to-go along side the source image in the same DDS file.

There is of course a penalty. Mipmaps take up space, increasing data size by 33% beyond that required to store the source image. This increases both size on disk and size in video memory. Unless your primary concern is file size, the benefits of mipmapping more than outweigh the costs.

Egad! There are tons of DXT codecs! Which should I use?

DXT comes in a lot of flavors as shown to the right. Fortunately most are specialty applications. For common situations you'll probably need to consider only three: DXT1, DXT3 and DXT5. Let's briefly overview each one to get an idea when they might be used.

DXT1 (BC1)

RGB, 4 bits per pixel, no alpha or 1 bit (black or white) alpha
DXT1 is a fixed 8:1 compression ratio

If your image does not require an alpha channel, use the no-alpha DXT1. It uses the same compression algorithm as DXT3/5 for color data, and will get you half the file size. I've never used this one with an alpha channel. Sometimes referred to as BC1 (Block Compression 1).

DXT3 (BC2)

ARGB, 8 bits per pixel, explicit alpha
DXT3 is a fixed 4:1 compression ratio

DXT3's method for storing alpha is better for files that have clearly delineated defined alpha regions and values. It may result in banding artifacts if used on images with smooth blended alpha regions-- use DXT5 for these cases. I rarely use DXT3.

DXT5 (BC3)

ARGB, 8 bits per pixel, interpolated alpha
DXT5 is same 4:1 compression ratio as DXT3

DXT5 is the go-to codec for most images that include an alpha channel. The cost is double the file size of a DXT1 image. If you do not need an alpha channel (and I suggest that you not include an alpha channel unless you absolutely must), use DXT1.

DDS Files: editing and archiving

DDS images are just a regular images with or without an alpha channel. They can be created in GIMP or Photoshop or whatever you have. To export your image as a DDS file, you'll need a plugin. NVIDIA offers a free tool for importing/exporting DDS files into Photoshop:

https://developer.nvidia.com/nvidia-texture-tools-adobe-photoshop

http://code.google.com/p/gimp-dds/

Learning to use these plugins is beyond the scope of this article, but I have a few observations. In my experience using the tool with Photoshop CS5, I've found that exporting images to the DDS format can take time, particularly when using DXT1 for reasons I've yet to figure out. A 1024x1024 image with no alpha channel often takes about a full minute or longer to export to DXT1 with mipmaps on my Core 2 Duo, 4GB RAM machine. From time to time the process appears to hang-- sometimes this can be waited out with eventual success, and sometimes it really does seem to be stuck. It depends on the nature of the image. I've sometimes worked with images that simply refuse to export to DXT1. Exporting to DXT5 tends to be much faster and less problematic. NVIDIA hasn't updated this tool in quite a while, which may be part of the problem.

Don't include an alpha channel if you don't absolutely need one. An alpha channel will double the file size of your DDS file and significantly add to game or simulation video processing workload. I commonly find images created by others that include an unnecessary, fully-transparent alpha channel. Don't do that.

Since DDS files are lossy and rather badly so, you should not use them as an archive format. Don't edit DDS files if there is any possibility of using a non-lossy source, especially if the DDS file is serving as a normal map. Always begin your edits by opening a file saved in a non-lossy format. If you /must/ edit a DDS file as your only option, first save the file in a non-lossy format, thus preserving at least that version as a standard, and create all subsequent versions from that source. If you do not, subsequent saves and editing will quickly corrupt the image into something unusable.

DXT and Normal Maps

A normal map stores information that allows lighting calculations to be done at the per-pixel level rather than interpolating between vertices. This can make lighting much smoother and more graduated, or it can make significant changes how lighting affects a given point. The common use of a normal map is to tweak surface data to give the illusion of having extra detail. It's not real detail-- it doesn't actually change the geometry, but it does change the lighting and can give very realistic results without adding polygonal complexity.

Normal map data is essentially a normal vector for each pixel. The normal gives an indication of the "facing" of the pixel. Normal maps use the RGB color space to store the data needed for the effect-- the 24 bits for each pixel are used to encode the pixel's vector. Given that a color in this context is really a vector, changing a color can significantly alter the scale and direction of that vector, thus altering the effects at any given location. Since DXT compression does not exactly preserve the colors, DXT images can make a real mess of normal maps.

You can still use DXT compression for normal maps. In fact it's common to do so in games and sims, where resolutions are fairly low and resources come at a premium. Just be aware that the end result is likely to be rather mangled. For low-res situations it's usually not a big problem. But consider saving the normal map in a non-lossy format. You'll lose the load-time and video RAM advantages of DDS, but you can compensate by going to a quarter-size resolution. In general for normal maps, you'll get better appearance with a non-lossy format one-quarter the resolution of the DXT image. For example, a 512x512 PNG normal map will likely look better than a 1024x1024 DDS/DXT normal map.

DDS/DXT and Flightgear

Because some DXT compression algorithms are proprietary (or are contested), some codecs may not be part of a video driver sets associated with open-source Linux distributions. In those cases it's up to the user to install them separately. If you do not have the codecs installed as part of your driver set, you will not be able to use DDS images in your applications. I do graphical development in the Windows world so I have no experience with this issue. It doesn't seem to come up much with users on the Flightgear forums, despite the increasing use of DDS images with Flightgear.

The issue of whether distribution of content containing DDS files is compatible with the spirit of Flightgear and open source is hotly debated by a few Flightgear core developers, particular those with rather more extreme or restrictive interpretations of open source. The issue is not with the DDS files themselves, but with the algorithms used by drivers for the graphic cards. Algorithms are not distributed with DDS files. Since some of the algorithms are (or may be) proprietary, they cannot be distributed with Flightgear. But this is video card codec issue and has no bearing on files distributed with the Flightgear package itself, or the content in any DDS file.

In any case, you are free to create and distribute your own DDS/DXT files consisting of your own content or content otherwise released under the GPL license.