rawtopgm - convert raw grayscale bytes to a PGM image
This program is part of Netpbm(1).
rawtopgm reads raw grayscale values as input and produces a PGM image as output. The input file is just a sequence of pure binary numbers, either one or two bytes each, either bigendian or littleendian, representing gray values. They may be arranged either top to bottom, left to right or bottom to top, left to right. There may be arbitrary header information at the start of the file (to which rawtopgm pays no attention at all other than the header's size).
Arguments to rawtopgm tell how to interpret the pixels (a function that is served by a header in a regular graphics format).
The width and height parameters tell the dimensions of the image. If you omit these parameters, rawtopgm assumes it is a quadratic image and bases the dimensions on the size of the input stream. If this size is not a perfect square, rawtopgm fails.
When you don't specify width and height, rawtopgm reads the entire input stream into storage at once, which may take a lot of storage. Otherwise, rawtopgm ordinarily stores only one row at a time.
If you don't specify imagefile, or specify -, the input is from Standard Input.
The PGM output is to Standard Output.
The default is 1 byte per sample.
This is useful when the input is actually some graphics format that has a descriptive header followed by an ordinary raster, and you don't have a program that understands the header or you want to ignore the header.
Skipping a fractional byte per row means skipping one byte per multiple rows.
If you don't specify -bt when you should or vice versa, the resulting image is upside down, which you can correct with pamflip.
This option causes rawtopgm to read the entire input stream into storage at once, which may take a lot of storage. Ordinarly, rawtopgm stores only one row at a time.
For backwards compatibility, rawtopgm also accepts -tb and -topbottom to mean exactly the same thing. The reasons these are named backwards is that the original author thought of it as specifying that the wrong results of assuming the data is top to bottom should be corrected by flipping the result top for bottom. Today, we think of it as simply specifying the format of the input data so that there are no wrong results.
Copyright (C) 1989 by Jef Poskanzer. Modified June 1993 by Oliver Trepte, firstname.lastname@example.org