version 1 showing authors affecting page license.
.
Rev |
Author |
# |
Line |
1 |
perry |
1 |
rawtopgm |
|
|
2 |
!!!rawtopgm |
|
|
3 |
NAME |
|
|
4 |
SYNOPSIS |
|
|
5 |
DESCRIPTION |
|
|
6 |
OPTIONS |
|
|
7 |
SEE ALSO |
|
|
8 |
AUTHORS |
|
|
9 |
---- |
|
|
10 |
!!NAME |
|
|
11 |
|
|
|
12 |
|
|
|
13 |
rawtopgm - convert raw grayscale bytes into a portable graymap |
|
|
14 |
!!SYNOPSIS |
|
|
15 |
|
|
|
16 |
|
|
|
17 |
__rawtopgm__ [[__-bpp__ [[__1__|__2__]] |
|
|
18 |
[[__-littleendian__] [[__-maxval__ ''N''] |
|
|
19 |
[[__-headerskip__ ''N''] [[__-rowskip__ ''N''] |
|
|
20 |
[[__-tb__|__-topbottom__] [[''width height''] |
|
|
21 |
[[''imagefile''] |
|
|
22 |
!!DESCRIPTION |
|
|
23 |
|
|
|
24 |
|
|
|
25 |
Reads raw grayscale values as input. Produces a PGM file as |
|
|
26 |
output. The input file is just a sequence of pure binary |
|
|
27 |
numbers, either one or two bytes each, either bigendian or |
|
|
28 |
littleendian, representing gray values. They may be arranged |
|
|
29 |
either top to bottom, left to right or bottom to top, left |
|
|
30 |
to right. There may be arbitrary header information at the |
|
|
31 |
start of the file (to which __rawtopgm__ pays no |
|
|
32 |
attention at all other than the header's size). |
|
|
33 |
|
|
|
34 |
|
|
|
35 |
Arguments to __rawtopgm__ tell how to interpret the |
|
|
36 |
pixels (a function that is served by a header in a regular |
|
|
37 |
graphics format). |
|
|
38 |
|
|
|
39 |
|
|
|
40 |
The ''width'' and ''height'' parameters tell the |
|
|
41 |
dimensions of the image. If you omit these parameters, |
|
|
42 |
__rawtopgm__ assumes it is a quadratic image and bases |
|
|
43 |
the dimensions on the size of the input stream. If this size |
|
|
44 |
is not a perfect square, __rawtopgm__ fails. |
|
|
45 |
|
|
|
46 |
|
|
|
47 |
When you don't specify ''width'' and ''height'', |
|
|
48 |
__rawtopgm__ reads the entire input stream into storage |
|
|
49 |
at once, which may take a lot of storage. Otherwise, |
|
|
50 |
__rawtopgm__ ordinarily stores only one row at a |
|
|
51 |
time. |
|
|
52 |
|
|
|
53 |
|
|
|
54 |
If you don't specify ''imagefile'', or specify __-__, |
|
|
55 |
the input is from Standard Input. |
|
|
56 |
|
|
|
57 |
|
|
|
58 |
The PGM output is to Standard Output. |
|
|
59 |
!!OPTIONS |
|
|
60 |
|
|
|
61 |
|
|
|
62 |
__-maxval__ ''N'' |
|
|
63 |
|
|
|
64 |
|
|
|
65 |
''N'' is the maxval for the gray values in the input, and |
|
|
66 |
is also the maxval of the PGM output image. The default is |
|
|
67 |
the maximum value that can be represented in the number of |
|
|
68 |
bytes used for each sample (i.e. 255 or 65535). |
|
|
69 |
|
|
|
70 |
|
|
|
71 |
__-bpp__ [[__1__|__2__] |
|
|
72 |
|
|
|
73 |
|
|
|
74 |
tells the number of bytes that represent each sample in the |
|
|
75 |
input. If the value is __2__, The most significant byte |
|
|
76 |
is first in the stream. |
|
|
77 |
|
|
|
78 |
|
|
|
79 |
The default is 1 byte per sample. |
|
|
80 |
|
|
|
81 |
|
|
|
82 |
__-littleendian__ |
|
|
83 |
|
|
|
84 |
|
|
|
85 |
says that the bytes of each input sample are ordered with |
|
|
86 |
the least significant byte first. Without this option, |
|
|
87 |
__rawtopgm__ assumes MSB first. This obviously has no |
|
|
88 |
effect when there is only one byte per sample. |
|
|
89 |
|
|
|
90 |
|
|
|
91 |
__-headerskip__ ''N'' |
|
|
92 |
|
|
|
93 |
|
|
|
94 |
__rawtopgm__ skips over ''N'' bytes at the beginning |
|
|
95 |
of the stream and reads the image immediately after. The |
|
|
96 |
default is 0. |
|
|
97 |
|
|
|
98 |
|
|
|
99 |
This is useful when the input is actually some graphics |
|
|
100 |
format that has a descriptive header followed by an ordinary |
|
|
101 |
raster, and you don't have a program that understands the |
|
|
102 |
header or you want to ignore the header. |
|
|
103 |
|
|
|
104 |
|
|
|
105 |
__-rowskip__ ''N'' |
|
|
106 |
|
|
|
107 |
|
|
|
108 |
If there is padding at the ends of the rows, you can skip it |
|
|
109 |
with this option. Note that rowskip need not be an integer. |
|
|
110 |
Amazingly, I once had an image with 0.376 bytes of padding |
|
|
111 |
per row. This turned out to be due to a file-transfer |
|
|
112 |
problem, but I was still able to read the |
|
|
113 |
image. |
|
|
114 |
|
|
|
115 |
|
|
|
116 |
Skipping a fractional byte per row means skipping one byte |
|
|
117 |
per multiple rows. |
|
|
118 |
|
|
|
119 |
|
|
|
120 |
__-bt -bottomfirst__ |
|
|
121 |
|
|
|
122 |
|
|
|
123 |
By default, __rawtopgm__ assumes the pixels in the input |
|
|
124 |
go top to bottom, left to right. If you specify __-bt__ |
|
|
125 |
or __-bottomfirst__, __rawtopgm__ assumes the pixels |
|
|
126 |
go bottom to top, left to right. The Molecular Dynamics and |
|
|
127 |
Leica confocal format, for example, use the latter |
|
|
128 |
arrangement. |
|
|
129 |
|
|
|
130 |
|
|
|
131 |
If you don't specify __-bt__ when you should or vice |
|
|
132 |
versa, the resulting image is upside down, which you can |
|
|
133 |
correct with __pnmflip .__ |
|
|
134 |
|
|
|
135 |
|
|
|
136 |
This option causes __rawtopgm__ to read the entire input |
|
|
137 |
stream into storage at once, which may take a lot of |
|
|
138 |
storage. Ordinarly, __rawtopgm__ stores only one row at a |
|
|
139 |
time. |
|
|
140 |
|
|
|
141 |
|
|
|
142 |
For backwards compatibility, __rawtopgm__ also accepts |
|
|
143 |
__-tb__ and __-topbottom__ to mean exactly the same |
|
|
144 |
thing. The reasons these are named backwards is that the |
|
|
145 |
original author thought of it as specifying that the wrong |
|
|
146 |
results of assuming the data is top to bottom should be |
|
|
147 |
corrected by flipping the result top for bottom. Today, we |
|
|
148 |
think of it as simply specifying the format of the input |
|
|
149 |
data so that there are no wrong results. |
|
|
150 |
!!SEE ALSO |
|
|
151 |
|
|
|
152 |
|
|
|
153 |
pgm(5), rawtoppm(1), |
|
|
154 |
pnmflip(1) |
|
|
155 |
!!AUTHORS |
|
|
156 |
|
|
|
157 |
|
|
|
158 |
Copyright (C) 1989 by Jef Poskanzer. |
|
|
159 |
Modified June 1993 by Oliver Trepte, |
|
|
160 |
oliver@fysik4.kth.se |
|
|
161 |
---- |