TGA File Documentation

---

Technical details

Feature	Value
Full name	Truevision TGA (TARGA) Image
File extension	.tga (also .icb, .vda, .vst)
MIME type	image/x-tga
Format type	Raster bitmap, uncompressed or RLE
Developer	Truevision, Inc.
Introduced	1984; v2.0 specification 1989
Compression	None, or lossless run-length encoding (RLE)
Colour depth	8-bit indexed, 15/16-bit, 24-bit RGB, 32-bit RGBA
Alpha channel	Yes — 8-bit alpha in 32-bit images (attribute bits)
Byte order	Little-endian
Header size	18 bytes (fixed)
Magic number	None at offset 0; v2 files end with TRUEVISION-XFILE.
Footer size	26 bytes (v2.0, optional)
Pixel origin	Bottom-up by default; top bit of descriptor flips it
Open standard	Yes — openly documented, patent-free
Related extensions	.png, .bmp, .dds, .psd, .tif
Specification	Truevision TGA File Format Specification v2.0 (1989)

What is a TGA file?

TGA stands for Truevision Advanced Raster Graphics Adapter, universally shortened to “Targa”. Truevision, Inc. created it in 1984 for the TARGA and VISTA video-capture boards, among the first PC hardware able to display true-colour (24-bit) images at a time when most cards managed 16 colours. The extension survives on .tga files, and the format is still met in video-render sequences and inside game and mod folders. The version 2.0 specification, published in 1989, is the one in wide use; it is openly documented and patent-free, which is why nearly every image tool reads it.

A TGA stores a rectangular grid of pixels at 8, 15, 16, 24 or 32 bits each, either raw or with a light lossless run-length encoding. Its enduring appeal was the clean 8-bit alpha channel in 32-bit mode: each pixel carries red, green, blue and a transparency value, with no palette tricks. That made it a natural fit for compositing and for textures that need a cut-out mask. Everything below describes how those bytes are laid out, starting with the 18-byte header.

The 18-byte header, field by field

Every TGA opens with a fixed 18-byte header. All multi-byte integers are little-endian, a legacy of the format’s x86 origin. Unlike PNG or GIF, there is no signature in these bytes, so a reader must interpret the fields directly.

Offset  Size  Field
  0      1    ID length          bytes of optional Image ID after the header
  1      1    Colour-map type    0 = none, 1 = palette present
  2      1    Image type         see table below
  3      2    Colour-map origin  first palette index stored
  5      2    Colour-map length  number of palette entries
  7      1    Colour-map depth   bits per palette entry (15/16/24/32)
  8      2    X origin           lower-left corner X
 10      2    Y origin           lower-left corner Y
 12      2    Width              image width in pixels
 14      2    Height             image height in pixels
 16      1    Pixel depth        bits per pixel (8/16/24/32)
 17      1    Image descriptor   alpha bits (0-3) + origin bit (5)

The image type byte at offset 2 selects the encoding. The low three values are uncompressed and the values 8 higher are the run-length-encoded equivalents, so type 10 is simply the RLE form of the type 2 true-colour image.

Code	Meaning
0	No image data
1	Uncompressed colour-mapped (palette)
2	Uncompressed true-colour (RGB/RGBA)
3	Uncompressed grayscale
9	RLE colour-mapped
10	RLE true-colour
11	RLE grayscale

The image descriptor byte: alpha bits and pixel origin

The last header byte, the image descriptor at offset 17, packs two things that trip up naive readers. Bits 0–3 hold the attribute (alpha) bit count: for a 32-bit image this is normally 8, telling the reader that the fourth channel is a real alpha, not padding. Bit 5 is the screen-origin flag. When it is 0 (the default), the first pixel in the file is the bottom-left corner and rows run upward; when it is 1, the first pixel is the top-left, the same order most other formats use.

That bottom-up default is the single most common cause of TGA images that load upside down. A converter that ignores bit 5 flips the picture. Bit 4 is a horizontal-order flag (right-to-left) that is almost never set, and bits 6–7 were an interleaving field that is obsolete. Note also that true-colour TGA stores channels in BGR(A) order on disk, not RGB, another byte-order detail a decoder must respect.

The colour map and the pixel data block

Immediately after the header (and after the optional Image ID field, whose length the header gave) comes the colour map, present only when the colour-map-type byte is 1. It is a flat array of colour-map length entries, each colour-map depth bits wide, and it is the palette that indexed (type 1 and 9) images look up. True-colour and grayscale images set the colour-map type to 0 and skip this block entirely.

The pixel data follows. Its size and meaning depend on the pixel depth: 8-bit values are palette indices or gray levels, 16-bit values pack 5 bits per channel plus one attribute bit, 24-bit values are BGR triples, and 32-bit values are BGRA quads. In an uncompressed image the pixels are stored straight, one after another, in the row order the origin bit specifies. There is no per-row filtering or prediction step of the kind PNG uses, which keeps decoding trivial but leaves files large.

Run-length encoding: raw and run packets

TGA’s only compression is a simple byte-oriented run-length encoding, used by image types 9, 10 and 11. The pixel stream is a series of packets, each introduced by a one-byte header whose top bit selects the packet kind and whose low seven bits hold a count.

Packet header byte:
  bit 7 = 1  → RLE packet:  next 1 pixel repeats (count+1) times
  bit 7 = 0  → RAW packet:  next (count+1) pixels are stored literally
  bits 0-6   → run length minus 1  (so 1..128 pixels)

An RLE packet stores one pixel value and a repeat count, expanding to up to 128 identical pixels; a raw packet stores a literal run of up to 128 pixels that do not compress well. This scheme shrinks flat colour and simple graphics effectively but does almost nothing for photographic or noisy images, since long identical runs are rare there. It is why a photo saved as RLE TGA is barely smaller than the raw version and many times larger than the same image as PNG, whose DEFLATE compression finds patterns RLE cannot. One subtlety: in strict TGA a run is not supposed to cross a scan-line boundary, though many encoders and decoders ignore that rule.

The version 2.0 footer and extension area

Version 1.0 files simply end after the pixel data, with nothing to mark them as TGA. Version 2.0 added a 26-byte footer at the very end of the file, which is the closest thing the format has to a signature.

Last 26 bytes of a v2.0 file:
  +0   4 bytes  extension-area offset   (little-endian, 0 if none)
  +4   4 bytes  developer-directory offset (0 if none)
  +8  18 bytes  "TRUEVISION-XFILE." + 0x00   signature

A reader detects the new format by seeking to 26 bytes before end-of-file and testing for the ASCII string TRUEVISION-XFILE. ending in a null. If the two offsets are non-zero they point to an extension area and a developer directory. The extension area is a fixed structure holding author name and comments, a date and time stamp, job name and time, a software ID and version, a gamma value, and colour-correction and postage-stamp (thumbnail) data. The developer directory is an open-ended table letting a vendor attach private tagged blocks. Both are optional, so a valid v2 file can carry the footer signature while setting both offsets to zero.

Where TGA sits against PNG and DDS, technically

TGA, PNG and DDS are all lossless raster formats with alpha, but they solve different problems. TGA is the simplest: fixed header, optional weak RLE, pixels essentially raw. PNG wraps its pixel data in DEFLATE plus per-row prediction filters, so it stores the same 32-bit RGBA image far smaller with no quality loss, which is why converting TGA to PNG is the standard way to keep the alpha and shrink the file. DDS is different again: it holds GPU-native block-compressed textures (BC1–BC7) with pre-computed mipmap levels, so a game engine can upload it straight to the graphics card. That is why texture pipelines that once used TGA now often ship DDS, while TGA lingers as an editing and interchange format because it is trivial to read and write and keeps every bit exactly.

References

• Truevision TGA File Format Specification v2.0
• Library of Congress — TGA (Truevision) format description
• Truevision TGA — format overview

Feedback

Was this page helpful?

Yes No

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.