Trying a roundtrip using `image` crate with `.pbm` file fails

Hello everyone,

I’m still learning Rust, so most probably I’ve just made an easy mistake. However, since I was so far unable to solve my issue on my own, I hope to get help here.

My ultimate goal is to create and modify black-and-white (i.e. 1-bit in memory corresponds to 1 black dot on the display) bitmap graphics for an LCD display. When I came across 0.19.0 of the img crate and read that the PNM module now supports also the PBM format (Netpbm’s Portable BitMap, see the Netpbm article on Wikipedia for info) I wanted to give it a try.

So I generated a 10x10 pixel test.pbm file (attached as a PNG, since PBM’s are not allowed here) to get a feel for the crate. I wanted to start with a simple roundtrip, i.e. load the image and write it back to a new pbm file using the crates methods. Yet, I didn’t succeed.


extern crate image;

use std::fs::File;
use image::{

fn main() {
    let img = image::open("test.pbm").unwrap();
    let color = img.color();
    let enc = img.write_to(&mut File::create("out.pbm").unwrap(),
    println!("{:?}", img.raw_pixels().len());
    println!("{:?}", color);
    println!("{:?}", enc);


I get

Err(IoError(Custom {kind: InvalidInput, error: StringError("Image buffer does not correspond to size and colour")}))

printed out.

I don’t really understand why reading in a 10x10 bitmap results in a 668 bytes long Gray(8) array (I didn’t post the full debug output of img.raw_pixels(), but if you try for yourself, you’ll see that the 0 and 255 values in that struct don’t really correspond to the pixel pattern in the pbm file).

I assume that I have an error somewhere (i.e. didn’t use the right methods in the beginning), but perhaps this might also be a bug in img::pnm?


This sounds like a bug in the PNM decoder. You can report it to the issue tracker and/or try debugging the image crate to see why it is apparently reading the wrong number of bytes.

After further testing it seems pretty obvious to me now that there is a bug somewhere, so I’ve opened an issue for this.

Apparently the issue is related to the ColorType being wrongly recognized as a Gray(8) instead of a Gray(1).