Turn a Raw Bayer Plane into RGB with pambayer

pambayer takes a raw one-plane Bayer sensor image and turns it into a proper PAM RGB file, without touching your source. Allow about fifteen minutes if the input is ready, longer if you still have to track down the sensor's layout.

You need Netpbm and a pseudo-PNM or PAM file containing one sample plane per sensor position. This is not a general raw-camera decoder: the input must already be a Netpbm-style image, and you must already know the Bayer arrangement. No elevated privileges needed.

1. Check the installed command

Confirm the command and package are present before you touch an image:

$ command -v pambayer
/usr/bin/pambayer
$ dpkg-query -W -f='${Package} ${Version}\n' netpbm
netpbm 2:11.05.02-1.1build1

The version line is machine-specific. If your distribution reports a different Netpbm version, read its local pambayer(1) page before relying on a newer or older option.

2. Identify the Bayer arrangement

The mandatory -type option tells pambayer which colour sits at each position in the repeating two-by-two pattern. These four values are not quality settings: pick the wrong one and colours swap or shift across the whole image.

Use whichever value is documented for the camera, or for the conversion that produced the pseudo-PNM file. Do not infer it from the filename. A common trap is treating -type=1 as a default: there is no default, and this option is mandatory.

3. Convert with interpolation

Run the conversion into a new file. Swap in your own paths and the verified pattern value:

$ pambayer -type=2 camera-bayer.pam > camera-rgb.pam
$ pamfile camera-rgb.pam
camera-rgb.pam: PAM, 4000 by 3000 by 3 maxval 4095
    Tuple type: RGB

The dimensions and maximum value in that output depend on your input. What stays constant is depth 3 and tuple type RGB. pambayer produces one output pixel per sensor position. Where two colour components are missing from the Bayer input at a given position, its normal mode estimates them by averaging adjacent samples that do contain those components.

That averaging is interpolation, not a recovery of measurements the sensor actually made. It gives you a viewable colour image, but the result still depends on the pattern you chose and the edge behaviour of the input. Keep the original camera-bayer.pam as the source of record.

4. Make a sparse, non-interpolated version

For analysis where you want the measured colour samples rather than estimates, add -nointerpolate:

$ pambayer -type=2 -nointerpolate camera-bayer.pam > camera-samples.pam
$ pamfile camera-samples.pam
camera-samples.pam: PAM, 4000 by 3000 by 3 maxval 4095
    Tuple type: RGB

The output still has RGB depth and the same dimensions, but each pixel carries only the component its sensor position actually supplied. The other two components are zero. It can look very dark or patterned on screen; that is expected, not a sign the conversion failed.

The option was added in Netpbm 10.49, according to the installed manpage, so the installed 2:11.05.02 package has it. A script meant for older Netpbm installations should still check the target version rather than assume it exists.

5. Inspect one colour channel when you need it

If you only need one primary colour from the interpolated result, pipe the PAM stream to pamchannel, the separate Netpbm tool for channel extraction:

$ pambayer -type=2 camera-bayer.pam | pamchannel 1 > camera-red.pam
$ pamfile camera-red.pam
camera-red.pam: PAM, 4000 by 3000 by 1 maxval 4095

Channel numbering and the exact pamchannel syntax belong to that command's own manual page: read it before changing the channel number. If your next tool wants PPM rather than PAM, convert the RGB result with pamtopnm, as pambayer(1) itself recommends:

$ pambayer -type=2 camera-bayer.pam | pamtopnm > camera-rgb.ppm

These pipelines write to standard output. A failed command can still leave a partial destination file if the shell already opened the redirection target. For anything that matters, write to a temporary name on the same filesystem, verify it with pamfile, then rename it over a deliberately chosen destination. Renaming is a state-changing step, so never point it at the only copy of the source.

Common failures and what they mean

• Missing -type value. The invocation is incomplete. Add exactly one of 1, 2, 3 or 4. The program takes the usual Netpbm option conventions: a double hyphen works, whitespace can replace the equals sign, and a unique abbreviation may too. Prefer the full option in scripts, because a future option could make an abbreviation ambiguous.
• Input error. Usually means the file is not a one-plane Netpbm image, the header does not describe what you think it does, or a binary payload got damaged in an earlier conversion. Inspect the header with a suitable Netpbm reader and compare against the camera or conversion documentation. Do not repair a suspicious file by editing its header blindly: that changes how every sample gets interpreted.
• Technically valid but strangely coloured. Usually a wrong Bayer type. Recheck the camera documentation, then repeat the conversion into a different destination. Do not overwrite the first result until you have compared the pattern choice and kept a reproducible command line.