The PCX file (.pcx)

PCX is the native format of PC Paintbrush, a paint program for MS-DOS from ZSoft Corporation, first released in 1984. Microsoft published PC Paintbrush with its mouse drivers in 1985 and licensed versions of it for Windows: the original Windows Paint and, in Windows 3.0, Paintbrush. That spread PCX across early PCs, and it became one of the first widely accepted image formats on DOS.

Through the late 1980s and the 1990s, PCX was used for screenshots, clip art, scanned images, fax software and the graphics of DOS games. ZSoft extended it from the 2-, 4- and 16-colour displays of the time to 256-colour VGA and finally 24-bit colour, and the company itself was merged and sold several times from 1989 onwards.

Today PCX is a legacy format. You find it in old software, game files and archives, and some document and fax systems still use the multi-page DCX variant. Image editors and converters still read it, but browsers don't, and for new images PNG does everything PCX did, with better compression.

Every PCX file starts with a 128-byte header:

The bit depth and the number of planes together give the colour mode. Planes split each row into separate parts, one per colour component, a layout inherited from the way EGA and VGA graphics cards stored their memory:

PCX compresses each row with a byte-oriented run-length scheme:

1. 1Read a byte. If its top two bits are set (C0 to FF), the low six bits are a count from 1 to 63, and the next byte is repeated that many times.
2. 2Otherwise the byte is a single data byte.
3. 3Repeat until the row is complete: number of planes × bytes per line.

// decode one PCX row (all planes) from data, starting at pos
function decodeRow(data, pos, rowBytes) {
  const out = [];
  while (out.length < rowBytes) {
    let count = 1;
    let value = data[pos++];
    if ((value & 0xc0) === 0xc0) {
      count = value & 0x3f;
      value = data[pos++];
    }
    for (let i = 0; i < count; i++) out.push(value);
  }
  return { row: out, pos };
}

Two consequences are worth knowing. First, a single byte of C0 or more costs two bytes (C1 and the value), so images with many bright palette indices or lots of noise compress badly, and a photo can end up larger than uncompressed. Second, the encoding is the same for every kind of PCX, which made it fast on 1980s computers but leaves it far behind GIF's LZW or PNG's Deflate on anything but flat colour.

PCX has two places for a palette, because it grew with the graphics cards of its time:

• The 16-colour palette sits in the header at offset 16: 16 colours of 3 bytes. Images with 16 colours or fewer use it.
• The 256-colour palette was added for VGA. There was no room in the header, so ZSoft appended it to the end of the file: a byte with the value 12 (0C), then 768 bytes of red, green and blue. To find it, check that the version is 5, go to 769 bytes before the end of the file, and check for the 12.

The palette stores 8 bits per component, from 0 to 255. VGA hardware took values from 0 to 63, so old DOS programs divided each value by 4 before loading it into the card. A reader that skips this conversion is fine; a writer that stores the 0 to 63 values directly produces an image that looks very dark in modern software.

Converting a PCX to PNG loses nothing: every pixel and palette entry carries over, and the file almost always gets smaller. That's the usual way to preserve PCX images for modern use.

• Wrong or psychedelic colours. The reader missed the 256-colour palette (no 0C 769 bytes from the end, or a version other than 5), or the file uses the default 16-colour palette of version 3. Try another reader; IrfanView and ImageMagick handle most variants.
• Nearly black image. The palette holds VGA values from 0 to 63 instead of 0 to 255. Multiply the palette by 4 (or adjust levels) to recover it.
• An extra column or a shifted image. Bytes per line is even, so odd-width images carry a padding byte per row, and some readers draw it. Or the reader forgot the + 1 when computing the size from the window.
• The image is skewed or streaky. A decoder that stops runs at the end of each plane, or doesn't, when the file was written the other way. ZSoft's documentation says decoding breaks happen at the end of each row, not each plane.
• It opens as just one page. It may be a DCX file with several PCX pages inside. Use a viewer that supports DCX, or ImageMagick, which reads every page.
• It won't open at all. Make sure it really is a PCX: the first byte should be 0A, the third 01.

• Open it: GIMP (Windows, macOS, Linux), IrfanView, XnView, Photoshop and PaintShop Pro; GraphicConverter on a Mac.
• Convert to PNG: export from any of these, or run magick image.pcx image.png with ImageMagick or ffmpeg -i image.pcx image.png with FFmpeg.
• Make a PCX for old software: magick input.png -colors 256 output.pcx gives an 8-bit palette image, which old programs read more reliably than 24-bit PCX.
• Inspect it: identify -verbose image.pcx (ImageMagick) shows the size, depth and palette; the header is short enough to read in any hex editor.

PCX files hold only pixels, a palette and a resolution, with no other metadata, scripts or links. As with any old format, decoders that trust the header's sizes have had bugs; keep your software updated and check dimensions before processing uploaded files.