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.
Best Answer
It looks like the relative ordering of modifier arguments (-quality NN) and filenames does matter here, almost like it's doing what it's told in a very, very simplistic way.
So, the first time we run mogrify, we specify the
-qualityargument after the filename, and so it doesn't know that the quality specifier should apply to that image.Conversely, if we specify the quality setting before the image filename, it'll save the image with more compression, reducing the filesize.