Alpha and RLE: How TGA Works Inside

File anatomy: three parts

Open a .tga in a hex editor and you'll see the format is surprisingly logical. Any TGA file (in the modern 2.0 version) consists of three big parts:

1. The header — a short block at the start describing the image.
2. The image data — the pixels themselves, compressed or not.
3. The footer — an optional "tail" at the end with metadata and the format signature.

No per-block checksums like PNG, and no entropy magic like JPEG. That simplicity is TGA's signature trait; if you want to understand where it came from historically, see "What Is TGA".

The 18-byte header

The heart of the format is a compact header of exactly 18 bytes. It packs everything a decoder needs to read the pixels correctly. Here are the key fields:

A curious quirk: there's no "magic" signature at the very start of the file. Most formats begin with identifying bytes (PNG with ‰PNG, JPEG with FF D8), but TGA starts straight away with the description length. So you can't reliably identify a TGA by its opening — you either look at the footer signature (see below) or trust the extension.

Image types: 2, 10 and the rest

The header's second byte — Image Type — is arguably the most important field. It decides exactly how pixels are stored. There are several values:

In practice you'll almost always meet two values: type 2 (uncompressed true-color) and type 10 (the same true-color but RLE-compressed). The other types are a legacy of the 1980s, when memory was expensive and images were often stored via a palette. Notice the symmetry: types 9, 10 and 11 are exactly types 1, 2 and 3 plus RLE.

RLE compression, simply put

RLE (Run-Length Encoding) in TGA is wonderfully simple to picture. The image is encoded not pixel by pixel but in packets. Each packet starts with one control byte, and its top bit decides what comes next:

The clever part is that the decoder never has to "guess": the first bit of each packet tells it directly whether this is a run or a set of distinct pixels. That's why RLE decodes instantly. The downside is that it's only effective where long runs of identical pixels exist: icons, logos, flat backgrounds. On a photograph, where almost every pixel is unique, RLE can even grow the size slightly (because of the control bytes). For more on how this affects file weight, see the comparison "TGA vs PNG".

Alpha channel: 8 bits for transparency

Now to transparency. How many bits go to the alpha channel depends on the pixel's color depth:

• 32-bit: 8 bits for red, 8 for green, 8 for blue and 8 for alpha. That's 256 levels of transparency — smooth semi-transparent shadows, glass, smoke.
• 16-bit: 5 bits per color and just 1 bit of alpha — a pixel is either fully visible or fully transparent, no in-between.
• 24-bit: color only, no alpha channel.

Exactly how many bits go to transparency is recorded in the low bits of byte 17 (the Image Descriptor). The same byte holds the row-order flag — which is what causes the classic "flipped TGA" problem: old files store rows bottom-to-top, and if a decoder ignores this field, the image ends up upside down.

The 2.0 footer and the TRUEVISION-XFILE signature

In 1989, version 2.0 of the format arrived and added an optional 26-byte footer to the end of the file. That's the line between old TGA 1.0 and modern 2.0. The footer stores:

• An offset to the extension area (4 bytes) — which holds the date, author name, gamma, and a thumbnail preview (the "postage stamp").
• An offset to the developer area (4 bytes) — a place for arbitrary data from a specific program.
• The signature — the ASCII string TRUEVISION-XFILE. with a trailing null byte (18 bytes).

That TRUEVISION-XFILE signature is TGA 2.0's "ID badge." Since there's no signature at the start of the file, programs use this string at the end to confirm they're looking at a genuine TGA version 2.0 rather than a truncated file or an older version.

Why this matters in practice

Understanding TGA's inner workings isn't just trivia. It helps in real situations:

• Deliberate export. Knowing about types 2 and 10, you understand that the "RLE" checkbox on save is a choice between "smaller size" and "no compression at all" — and both are lossless.
• 32 vs 24 bit. Need transparency — save 32-bit (with alpha). Don't — 24-bit saves space.
• A "flipped" image. Now you know the culprit is the row-order flag in the descriptor, and the fix is a vertical flip.

And if your task is simpler — just to open or publish a TGA — there's no need to dig into the bytes: convert the file to PNG and the decoder handles all those headers, types and footers for you.

Need to build a TGA from an image at a specific depth and compression? Use PNG → TGA. The full list of conversions is on the formats page. And to see where all this anatomy is put to use, read "TGA in games and graphics".