Reference Formats
DDS
A Microsoft container for GPU-ready textures used in real-time 3D rendering, storing block-compressed pixel data plus precomputed mipmap chains, cube maps, or volume textures for games and 3D applications.
Extension
.dds
Full name
DirectDraw Surface
Introduced
2000, with DirectX 7.0
Vendor
Microsoft (DirectX team)
What is inside the container
DDS carries GPU-native block-compressed formats (DXT1-5 and, from Direct3D 10 onward, the newer BC4-7 compression schemes) along with pre-generated mipmap levels, so no CPU-side decompression to standard RGB is required at render time. It is an asset-pipeline format rather than a photographic one: it carries essentially no EXIF/IPTC/XMP metadata, and a DAM has to treat it as a technical 3D/game-texture type rather than a picture.
How to open it
For archives
Keep DDS as-is for game and 3D production pipelines, since re-encoding loses the GPU-specific block-compression tuning chosen for a given texture; a DAM that catalogs game assets needs a dedicated renderer or converter (to PNG, for instance) to generate previews, because DDS's compressed texture data is not directly viewable by generic image tools.
Microsoft introduced the DirectDraw Surface format with DirectX 7 in 2000 to give real-time 3D applications, chiefly games, a way to store textures already compressed into the block formats GPUs could decode directly in hardware. Subsequent DirectX releases extended it: DirectX 8.0 added volume-texture support, and Direct3D 10 brought texture arrays and the newer BC-series compression formats.
DDS sits outside the normal photographic-asset category that most DAM systems are built around, which makes it an outlier when game studios or 3D teams bring their asset libraries into a general-purpose DAM. The file is optimized for how a GPU consumes it, not for how a human browses it: there is no thumbnail convention built in, no descriptive metadata block, and the compressed pixel data cannot be interpreted by a standard image decoder without DDS-aware code. A DAM handling game textures needs either a dedicated DDS preview renderer or a conversion step to a browsable format, and should keep the original DDS untouched as the production-ready master since re-compressing it can visibly change how the texture looks in-engine.
Frequently asked
Can a DAM's generic thumbnail generator preview a DDS file?
No. DDS holds GPU-native block-compressed texture data that is not directly viewable by generic image tools, so a DAM needs a dedicated renderer or converter to generate a PNG-style preview.
Should DDS textures be re-encoded when ingested into a DAM?
No. Keep DDS as-is for game and 3D production pipelines, since re-encoding loses the GPU-specific block-compression tuning, such as DXT1-5 or BC4-7 from Direct3D 10 onward, chosen for that particular texture.
What metadata does DDS carry for cataloging purposes?
Essentially none. DDS carries no meaningful EXIF/IPTC/XMP metadata, so a DAM has to treat it as a technical 3D/game-texture asset type and track descriptive metadata externally.
What besides pixel data does a DDS file typically bundle?
Pre-generated mipmap chains, and it can also store cube maps or volume textures, all so no CPU-side decompression to standard RGB is required at render time.
How can a DAM open DDS inside Photoshop or GIMP?
Via a plugin: NVIDIA's or Intel's DDS plugin for Photoshop, or a DDS import/export plugin for GIMP; neither application reads DDS natively out of the box.
What command-line tooling handles DDS inspection and conversion?
Microsoft's DirectXTex tools inspect and convert DDS natively, and ImageMagick can convert it to standard raster formats with the appropriate delegate installed.
When was DDS introduced and why?
Microsoft introduced it in 2000 with DirectX 7.0 as a container for GPU-ready textures used in real-time 3D rendering for games and 3D applications.
Is DDS a photographic image format?
No. It is an asset-pipeline format for real-time 3D rendering, not a photographic one, and a DAM cataloging game assets should classify and handle it differently from camera-derived raster images.
Sources
- The DirectDraw Surface file format was introduced with DirectX 7.0 in 2000 to store uncompressed and compressed (DXTn) textures. checked 2026-08-07 — Wikipedia - DirectDraw Surface
- DDS supports mipmaps, cube maps, and volume maps, and Direct3D 10 extended the format to allow texture arrays and new Direct3D 10.x/11 texture formats. checked 2026-08-07 — Microsoft Learn - DDS overview
- DirectX 8.0 added support for volume textures to the DDS format. checked 2026-08-07 — FileInfo.com - DDS File