Image format

PAM

Portable Arbitrary Map: simple uncompressed raster samples for image-processing pipelines.

Explore the format

Convert PAM to

Choose a target format for your PAM images.

All 21 conversions

Marked paths may need steps such as flattening, rasterization, tone mapping or animation loss.

Convert to PAM

Choose a source format to convert to PAM.

All 36 conversions

Marked paths may need steps such as flattening, rasterization, tone mapping or animation loss.

About PAM

Portable Arbitrary Map

PAM extends Netpbm raster interchange with explicit tuple depth and type. Pixels contain a declared number of samples, which can represent grayscale, RGB, alpha-bearing data or an application-defined tuple. This makes channel meaning more explicit than the separate older PBM, PGM and PPM layouts.

A P7 text header declares WIDTH, HEIGHT, DEPTH, MAXVAL and optional TUPLTYPE, followed by binary samples. Values use one or two bytes according to maxval, up to 65535. Defined tuple types include RGB_ALPHA and GRAYSCALE_ALPHA; arbitrary tuples do not guarantee that an image viewer knows how to display them.

Use PAM for channel-aware processing, transparent Netpbm intermediates and agreed custom raster tuples. Storage is uncompressed and does not provide a general ICC/Exif metadata system. Keep tuple meaning, precision and colour interpretation documented; a tool built only for PPM may reject PAM or remove extra channels on export.

Key capabilities

Compression
Uncompressed
Transparency
Yes
Animation
No
Extensions
.pam
MIME type
image/x-portable-arbitrarymap · Unregistered Netpbm convention
Metadata
Header, Comments
Best for
Channel-aware image pipelines
Colour depth
maxval up to 65535

Netpbm stores these samples without compression. Reducing colour, thresholding or changing maxval can still lose information before storage; text and binary representations change the layout, not its image meaning.

History of PAM

This format belongs to the documented Pbmplus/Netpbm evolution. The history distinguishes the original bitmap idea, later channel models and library development.

  1. 1980s

    A simple interchange language

    Jef Poskanzer invents PBM to exchange bitmaps using a representation simple enough for text-only email. Its aim is robust interchange between otherwise incompatible graphics tools.

  2. 1988

    Pbmplus and colour formats

    Poskanzer distributes Pbmplus in 1988 and adds PGM and PPM by the end of that year. The toolkit extends the original bitmap exchange to grayscale and RGB images.

  3. 1993

    Netpbm replaces Pbmplus

    Netpbm begins as a new release of the unmaintained Pbmplus package, with fixes and improvements contributed over the network. The format family remains a bridge among graphics tools.

  4. 2000-04

    Two-byte samples

    The maintained Netpbm distribution documents two-byte samples up to a maxval of 65535 and a defined byte order for PGM and PPM. This resolves ambiguity between earlier extensions.

  5. 2000-08

    PAM adds explicit tuples

    PAM appears in August 2000, adding explicit depth and tuple-type information. Library support grows over time, so a classic PNM tool is not automatically a PAM reader.

PAM compared

Different formats, different trade-offs. Choose for the image and the workflow.

PPM

PAM vs PPM

PPM stores three RGB samples per pixel without compression or alpha. It is easy to inspect in processing pipelines, but sacrifices compactness and rich metadata; select it when direct sample interchange is the priority.

PGM

PAM vs PGM

PGM stores one grayscale sample per pixel. It is suitable for grayscale processing and masks; exporting a colour image requires a deliberate luminance conversion and removes colour information.

PBM

PAM vs PBM

PBM stores only black and white, one bit per pixel in its binary form. It fits bitonal masks and line art; tonal images need thresholding or dithering, so gradients cannot remain as continuous gray levels.

PNG

PAM vs PNG

PNG preserves decoded pixels losslessly and can carry alpha. It is useful for transparent graphics and screenshots; it does not preserve editable document layers or camera sensor data, and photographic files can be large.

PAM FAQ

What does this format store?

PAM extends Netpbm raster interchange with explicit tuple depth and type. Pixels contain a declared number of samples, which can represent grayscale, RGB, alpha-bearing data or an application-defined tuple. This makes channel meaning more explicit than the separate older PBM, PGM and PPM layouts.

How does compression affect quality?

Netpbm stores these samples without compression. Reducing colour, thresholding or changing maxval can still lose information before storage; text and binary representations change the layout, not its image meaning.

Does every PAM contain alpha?

No. Alpha depends on DEPTH and TUPLTYPE, for example RGB_ALPHA. An arbitrary fourth sample is not automatically alpha unless the tuple definition says so.

What should I check before opening the file?

Check the magic number, sample precision and tuple or channel meaning. Many simple readers accept only one binary image and 8-bit samples even though the specifications permit more.

What changes when I export to another format?

Preserve maxval and colour interpretation when creating the rendered output. Grayscale and bitonal targets remove information deliberately; alpha requires an alpha-bearing tuple or a separate mask. Optional comments may not transfer.

When is this format useful?

Use PAM for channel-aware processing, transparent Netpbm intermediates and agreed custom raster tuples. Storage is uncompressed and does not provide a general ICC/Exif metadata system. Keep tuple meaning, precision and colour interpretation documented; a tool built only for PPM may reject PAM or remove extra channels on export.

Sources