PBM

No. The PBM header carries only three plain-text fields — magic number (P1 or P4), width, and height — leaving no reserved block for embedded EXIF, IPTC, XMP, or ICC data. There's no chunk mechanism like PNG's ancillary chunks or TIFF's tag directory to bolt metadata onto. A DAM ingesting PBM must store rights, creator, and descriptive fields externally in its own catalog record, since the file itself carries none of it.

No. PBM should never be used as an archival master; its 1-bit-per-pixel depth throws away tonal information, and it should be treated strictly as a pipeline intermediate for fax, OCR, or print-mask workflows.

Convert it on ingest rather than archive it as-is. TIFF or PNG are the natural targets: both support embedded metadata (TIFF tags or PNG ancillary chunks) and both can preserve grayscale or full-color tonal data that PBM's 1-bit depth cannot represent. Keep the original PBM only if it's evidentiary (e.g., a fax record), and treat the converted file as the asset the catalog actually manages, with the source retained as a linked derivative.

A short ASCII header — a magic number ("P1" for plain text or "P4" for raw binary), whitespace, the width, whitespace, the height, then a whitespace delimiter — followed immediately by the bitmap data. In raw form each pixel is a single bit (1 for black, 0 for white), packed eight to a byte, most-significant-bit first, with each row padded out to a full byte. Plain form spells the same bits out as ASCII '1' and '0' characters instead. There's no compression, no color, no layers, and no transparency.

The plain (P1) format was designed in the 1980s so a bitmap could be pasted directly into an email body and still be reconstructed correctly. Representing every pixel as a literal ASCII '1' or '0' character, with whitespace ignored and lines capped at 70 characters, kept the data within plain 7-bit text — the only kind pre-MIME mail systems could reliably carry intact. It's wasteful by modern standards, but it reflects PBM's origin as a lowest-common-denominator exchange format from Jef Poskanzer's Pbmplus toolkit.

The Netpbm toolkit itself (conversion utilities such as pnmtopng and pnmtotiff) is the reference implementation and the most reliable choice for batch pipelines. ImageMagick reads and converts PBM natively via its convert/magick commands, making it a common scripting choice for automated ingest. Desktop viewers GIMP, IrfanView, and XnView also open PBM for manual inspection. For a DAM pipeline, Netpbm or ImageMagick run headless are the practical picks since both support command-line batch conversion.

No. PBM is strictly 1-bit monochrome — every pixel is either pure black or pure white, with no gray levels and no color channels at all. It sits at the bottom of the Netpbm family: PGM adds grayscale, PPM adds full RGB color, and PBM stays reserved for pure bilevel line art, faxes, and masks. A DAM that needs to preserve any tonal or color information from a source image cannot use PBM as the storage format — it must convert to PGM, PPM, PNG, or TIFF instead.

PBM shows up most often as an intermediate output rather than a final deliverable: fax transmission (which is inherently bilevel), OCR preprocessing where a scanner binarizes a page before text recognition, and print-mask or dithering workflows that need a pure black/white stencil layer. Legacy document scanning pipelines and some bitmap-font or line-art tools also emit it. A DAM encountering PBM in an ingest queue is usually looking at pipeline exhaust from one of these processes, not a final asset meant for distribution.