The PFM file (.pfm)

A Portable FloatMap is the simplest way to store an image whose pixels are floating-point numbers. It follows the spirit of the Netpbm PPM format: a few lines of text say what the image is, and the pixels follow with nothing in between. The difference is that each sample is a 32-bit float rather than a whole number from 0 to a maximum, so a pixel can hold 0.0001 or 5,000. That makes PFM a high-dynamic-range format, like Radiance HDR and OpenEXR, but with none of their packing or compression.

No standards body owns PFM. Its best-known description is a short page on Paul Debevec's website, and USC's HDRShop program used it. Netpbm added converters in April 2004 and documents a version of the format, but calls it unofficial: its manual says there are several similar formats known as PFM, none of them authoritatively documented. In practice the variants agree on almost everything except the row order (see below).

Where you'll meet PFM files:

• Computer vision. The Middlebury stereo benchmark distributes its ground-truth disparity maps as PFM, and expects results in the same format, so PFM is common in stereo-matching and depth-estimation code.
• HDR research and teaching. A program can write one with a printf and a single fwrite, with no library.
• Pipelines and tests. As a lossless go-between for floating-point data, and as test input for image libraries.

PF
768 512
-1.0

Each line ends with one whitespace character, normally a newline (0A), and the pixel data starts straight after the newline that ends line 3. Unlike PPM, the format doesn't allow comments.

Putting the byte order in the sign of a number is the format's one clever idea. A program that writes floats straight from memory writes -1.0 on a little-endian computer and 1.0 on a big-endian one, and the reader swaps bytes only if its own byte order differs. Tools differ in what they choose: in our tests on an x86 Linux machine, Netpbm's pamtopfm wrote little-endian files (its default is the computer's own byte order), while ImageMagick 6 wrote big-endian ones.

The scale factor is more loosely defined. Netpbm says it gives the units of the samples; Paul Bourke's description of the format treats the same number as the pixel aspect ratio. Most software writes 1 and ignores the value on reading, so don't rely on it to carry information.

Both main descriptions of PFM say the rows are stored from the bottom of the image to the top, left to right within each row. That's the opposite of PPM, so code adapted from a PPM writer produces upside-down PFM files unless it reverses the rows.

• Netpbm notes that a PFM variant it attributes to Adobe orders the rows top to bottom instead, and suggests flipping the image if one comes out upside down.
• There's nothing in the file to say which convention a writer followed. If a PFM looks upside down, it probably is: flip it once and check against a reference image.

# flip a PFM vertically, keeping the float values
oiiotool upside-down.pfm --flip -o fixed.pfm

PFM keeps full 32-bit precision and is trivial to read, but the files are large: a 1920 × 1080 colour PFM is about 24.9 MB, twice the size of a half-float EXR before compression and four times an 8-bit PPM. Use it inside a pipeline or for data where exact values matter, and EXR for anything you store or exchange.

On Windows, a PostScript Type 1 font usually comes as a pair: a .pfb file (PostScript Font Binary) with the glyph outlines, and a .pfm file with the font metrics: the character widths and other measurements that Windows and printer drivers use to lay out text. The two must stay together. Older fonts sometimes came as .pfb, .afm and .inf files instead, and installing them produced the .pfm.

To check, open the file in a text editor or run head -c 16 file.pfm | xxd. If it starts with PF or Pf it's an image; if the first two bytes are 00 01, it's a font. Type 1 fonts are a legacy format: for new work, use an OpenType font.

• ImageMagick reads and writes colour and greyscale PFM. Builds without HDRI support, such as the ImageMagick 6 packages of many Linux distributions, clip values above 1.0 to white when they read the file.
• Netpbm: pfmtopam converts PFM to an ordinary Netpbm image and pamtopfm goes the other way, with -endian=little or big to choose the byte order.
• OpenImageIO (pip install OpenImageIO) reads and writes PFM with full float values, and converts it to EXR or HDR without losing range.
• GIMP can export images as PFM.
• Pillow (Python) reads and writes greyscale PFM (Pf) as 32-bit float images (mode F). It doesn't read colour PFM, and in our test with Pillow 12 an RGB image saved with a .pfm name came out as an 8-bit PPM file.
• Browsers, Windows Photos and macOS Preview don't open PFM.

# PFM to half-float EXR, keeping the HDR values
oiiotool input.pfm -d half -o output.exr

# EXR or HDR back to PFM
oiiotool input.exr -o output.pfm

# PNG to PFM with Netpbm (values 0 to 1; grey PNGs become Pf)
pngtopam input.png | pamtopfm > output.pfm

# PFM to a Netpbm image with whole numbers
pfmtopam input.pfm > output.pam

Reading one yourself takes a few lines: split the header on whitespace, pick <f4 or >f4 from the sign of the scale, read width × height × channels floats, and reverse the order of the rows. In Python with NumPy that's np.frombuffer(data, dtype).reshape(h, w, c)[::-1].

• The image is upside down. The writer or the reader got the row order wrong. Flip it vertically.
• The image is random noise or a few huge values. The floats were read in the wrong byte order: the reader ignored the sign of the scale line. Swap every group of 4 bytes.
• It's black, or flat white. The values are linear light and may be far outside 0 to 1. Adjust the exposure in an HDR viewer, or scale the values before converting to an 8-bit format.
• Bright areas go strange after converting to PNG. Values above 1.0 can't fit in 8 bits: most tools clip them to white, but some converters wrap them around into wrong colours. Scale the image down first.
• Pillow says "cannot identify image file". It's a colour (PF) file, which Pillow doesn't read. Use OpenImageIO, ImageMagick or a few lines of NumPy.
• Nothing opens it at all. Look at the first two bytes. 00 01 means it's a font metrics file, not an image.

A PFM file is a header and numbers, nothing that runs. As with PPM, the risk is in readers that trust the header: a few bytes can claim an image of 100,000 × 100,000 pixels, which at 12 bytes per pixel is 120 GB. Check the dimensions against a limit, and the file length against width × height × channels × 4, before allocating memory. Values can also be infinities or NaN (not a number), which can break code that sums or divides them.