Imagemagick used to generate PPM's in Linux, PPM's are unreadable

Question

I need to generate PPM's as raw data sources for one program. I have a bunch of png's as Input, which I'm going to convert ppm's. When I try a tool like mogrify it generates files, but these are unreadable to any image viewer programs such as GIMP:

mogrify -format ppm *.png

I have installed netpbm package. I tried to open some other random PPM's from other places, any image viewer can open and read those files, the problem exists with my own generated files. The files created with mogrify seem to have the right size for their resolution and contains bits.

In hex file viewer working file header looks like:

P6 640 480 25

Mine generated with Imagemagick:

P7 WIDTH 640 HEIGHT 480 DEPTH 3 MAXVAL 255 TUPLTYPE RGB ENDHD

Probably I need to give Imagemagick some other parameters to make correct file format, but what? Or is there another tool which can easily convert png's to ppm's?

Answer 1

If you take a look at the wikipedia pages for PPM and PAM it says that the magic numbers for PPM are as follows:

excerpt from PPM wikipedia page

Each file starts with a two-byte magic number (in ASCII) that explains the type of file it is (PBM, PGM, and PPM) and its encoding (ASCII or binary). The magic number is a capital P followed by a single digit number.

Magic Number    Type           Encoding
P1           Portable bitmap    ASCII
P2           Portable graymap   ASCII
P3           Portable pixmap    ASCII
P4           Portable bitmap    Binary
P5           Portable graymap   Binary
P6           Portable pixmap    Binary

Whereas with the PAM format it's magic number is P7. Also it was the following differences from the older formats (PPM, PNM, PGM, PBM):

excerpt from PAM wikipedia page

The header for the PAM file format begins with P7, and (unlike in the other formats) ends in an explicit close: ENDHDR.

There is no plain (human-readable, ASCII-based) version of PAM. PAM files are always binary, and attempts to use the switch -plain with Netpbm programs that produce PAM output results in an error message.

For the black-and-white version of PAM (depth 1, tuple type BLACKANDWHITE), corresponding to PBM, PAM uses one byte per pixel, instead of PBM’s use of one bit per pixel (packing eight pixels in one byte). Also, the value 1 in such a PAM image stands for white (“light on”), as opposed to black in PBM (“ink on”).

Example

If I convert a PNG file to a PPM file using mogrify I get the following:

convert blah.png to blah.ppm:

mogrify -format ppm blah.png

file info:

$ ll |grep bla
-rw-rw-r--   1 saml saml      11870 May 29 21:36 blah.png
-rw-rw-r--   1 saml saml     530613 May 29 21:36 blah.ppm

identify info:

$ identify blah.png blah.ppm 
blah.png PNG 926x191 926x191+0+0 8-bit DirectClass 11.9KB 0.000u 0:00.000
blah.ppm[1] PNM 926x191 926x191+0+0 8-bit DirectClass 531KB 0.000u 0:00.000

hex header info:

$ xxd blah.ppm|head -3
0000000: 5036 0a39 3236 2031 3931 0a32 3535 0af2  P6.926 191.255..
0000010: f1f0 0000 0000 0000 0000 0000 0000 0000  ................
0000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................

$ xxd blah.png |head -3
0000000: 8950 4e47 0d0a 1a0a 0000 000d 4948 4452  .PNG........IHDR
0000010: 0000 039e 0000 00bf 0802 0000 0019 f594  ................
0000020: be00 0000 0373 4249 5408 0808 dbe1 4fe0  .....sBIT.....O.

As you can see, mogrify correctly generated a PPM file (see the P6).

So what's wrong?

I'm wondering if there is something special about your source images that you're converting to PPM, which the PPM format doesn't support, and mogrify is not able to handle that automatically.

I would suggest interrogating the source image using the identify command:

identify <original image>

Edit #1

The OP posted the original image here. Running this image through myself I couldn't reproduce his result where mogrify would return a PAM file rather than a PPM file.

generated ppm:

mogrify -format ppm some.png

original png & new ppm files:

 ll|grep some
-rw-rw-r-- 1 saml saml     387940 May 30 00:36 some.png
-rw-rw-r-- 1 saml saml     921615 May 30 07:00 some.ppm

$ identify some.p*
some.png PNG 640x480 640x480+0+0 8-bit DirectClass 388KB 0.000u 0:00.000
some.ppm[1] PNM 640x480 640x480+0+0 8-bit DirectClass 922KB 0.000u 0:00.009

header info from files:

$ xxd some.png |head -3
0000000: 8950 4e47 0d0a 1a0a 0000 000d 4948 4452  .PNG........IHDR
0000010: 0000 0280 0000 01e0 0802 0000 00ba b34b  ...............K
0000020: b300 0020 0049 4441 5478 0184 c181 b21c  ... .IDATx......

$ xxd some.ppm |head -3
0000000: 5036 0a36 3430 2034 3830 0a32 3535 0a65  P6.640 480.255.e
0000010: 6e6b 656e 6b62 6e6a 626e 6a5f 706a 5f70  nkenkbnjbnj_pj_p
0000020: 6a5e 726b 5e72 6b5a 6d66 596c 6559 6a64  j^rk^rkZmfYleYjd

The file converted successfully for me. Running display some.ppm displayed the file so I'm not sure what to make of this. I did notice that the OP's identify command showed the files as sRGB whlie on my system these files show up as "8-bit DirectClass". The differences between these 2 is detailed here, but I'm not sure what to make of it.

While researching this I came across several threads where there were bugs in ImageMagick related to sRBG and PNG. Here's a link to one example.