1Pamflip User Manual(0) Pamflip User Manual(0)
2
3
4
6 pamflip - flip or rotate a PAM or PNM image
7
8
10 pamflip { -leftright | -lr | -topbottom | -tb | -transpose | -xy |
11 -rotate90 | -r90 | -cw | -rotate270 | -r270 | -ccw | -rotate180 | -r180
12 -null | -xform=xform1,xform2... } [-memsize=mebibytes] [-page‐
13 size=bytes] [pamfile]
14
15 All options can be abbreviated to their shortest unique prefix. You
16 may use two hyphens instead of one to designate an option. You may use
17 either white space or an equals sign between an option name and its
18 value.
19
20
21
23 This program is part of Netpbm(1).
24
25 pamflip flips a PAM or PNM image top for bottom or left for right, or
26 transposes it horizontal for vertical, or rotates it 1, 2, or 3 quarter
27 turns.
28
29 To rotate at other angles, use pnmrotate. It is much slower, though.
30
31 The input image is pamfile, or Standard Input if pamfile is not speci‐
32 fied.
33
34 To flip/rotate a JFIF (JPEG) image losslessly, use jpegtran. jpegtran
35 is part of the Independent Jpeg Group's compression library package,
36 not part of Netpbm. The normal Netpbm way to flip a JFIF file would be
37 to convert it to PNM, use pamflip, and convert back to JFIF. But since
38 JPEG compression is lossy, the resulting image would have less quality
39 than the original. jpegtran, on the other hand, can do this particular
40 transformation directly on the compressed data without loss.
41
42
43
45 You must supply exactly one of the following options:
46
47 pamflip's predecessor (before Netpbm 10.7 - August 2002) pnmflip did
48 not have the -xform option and instead allowed you to specify any num‐
49 ber of the other options, including zero. It applied all the indicated
50 transformations, in the order given, just like with pamflip's -xform
51 option. (Reason for the change: this kind of interpretation of options
52 is inconsistent with the rest of Netpbm and most of the Unix world, and
53 thus hard to understand and to implement).
54
55
56
57 -leftright
58
59 -lr Flip left for right.
60
61
62 -topbottom
63
64 -tb Flip top for bottom.
65
66
67 -transpose
68
69 -xy Transpose horizontal for vertical. I.e. make the pixel at (x,y)
70 be at (y,x).
71
72
73 -rotate90
74
75 -r90
76
77 -ccw Rotate counterclockwise 90 degrees.
78
79
80 -rotate180
81
82 -r180 Rotate 180 degrees.
83
84
85 -rotate270
86
87 -r270
88
89 -cw Rotate counterclockwise 270 degrees (clockwise 90 degrees)
90
91
92 -null No change. (The purpose of this option is the convenience of
93 programs that invoke pamflip after computing the kind of trans‐
94 formation desired, including none at all).
95
96 This option was new in Netpbm 10.13 (December 2002).
97
98
99 -xform=xform1,xform2...
100 Apply all the transforms listed, in order. The valid values for
101 the transforms are as follows and have the same meanings as the
102 identically named options above.
103
104
105 · leftright
106
107 · topbottom
108
109 · transpose
110
111
112 This option was new in Netpbm 10.13 (December 2002).
113
114
115
116 The following options help pamflip use memory efficiently. Some flip‐
117 ping operations on very large images can cause pamflip to have a very
118 large working set, which means if you don't have enough real memory,
119 the program can page thrash, which means it takes a ridiculous amount
120 time to run. If your entire image fits in real memory, you don't have
121 a problem. If you're just flipping top for bottom or left for right,
122 you don't have a problem. Otherwise, pay attention. If you're inter‐
123 ested in the details of the thrashing problem and how pamflip
124 approaches it, you're invited to read a complete explanation in com‐
125 ments in the source code.
126
127
128
129 -memsize=mebibytes
130 mebibytes is the size in mebibytes (aka megabytes) of memory
131 available for pamflip. It is the lesser of the amount of real
132 or virtual memory available.
133
134 pamflip does nothing special to allocate real memory or control
135 it's allocation -- it gets whatever it gets just by referencing
136 virtual memory normally. The real memory figure in question is
137 the maximum amount that pamflip can be expected to end up with
138 by doing that. This is just about impossible for you to know,
139 of course, but you can estimate. The total real memory in your
140 system should be a major factor in your estimate.
141
142 If pamflip cannot fit the entire image in the amount of memory
143 you specify, it does the transformation in chunks, using tempo‐
144 rary files for intermediate results.
145
146 In strict horizontal transformations (left for right) or the
147 null transformation, pamflip never keeps more than one row in
148 memory, so the memory size is irrelevant and pamflip doesn't use
149 temporary files.
150
151 In strict vertical transformations (top for bottom), even when
152 you allow pamflip enough memory to keep the entire image in vir‐
153 tual memory, it accesses it in a single pass, which does not
154 cause any thrashing; the chunks in temporary files thus don't
155 help.
156
157 The real memory is important when you do a column for row type
158 of transformation (e.g. -rotate90). In that case, even if pam‐
159 flip can fit the entire image in virtual memory at once, if it
160 does not also fit in real memory, the program will thrash like
161 crazy because of the order in which pamflip accesses the pixels,
162 and that means it will take a ridiculously long time to run. A
163 proper -memsize drastically reduces the paging.
164
165 If you specify -memsize too large, pamflip may attempt to get
166 more virtual memory than the system allows it and fail. If it
167 can get the virtual memory, but -memsize is larger than the
168 amount of real memory the system allows it and the transforma‐
169 tion is row for column, it will page thrash and run very slowly.
170 A value even slightly too high is the same as infinity.
171
172 If you specify -memsize too small, the program will run slightly
173 more slowly because of extra overhead in manipulating temporary
174 files. Also, if your environment isn't set up to make temporary
175 files possible, pamflip will fail.
176
177 Doing the entire transformation "in memory" doesn't speed things
178 up as much as you might think, because even with the temporary
179 files, the data is just as likely to be in memory. Virtual mem‐
180 ory gets paged to disk and disk files get cached in memory. In
181 fact, the pixels fit much more compactly into memory when stored
182 in a temporary file than when stored "in memory" because pamflip
183 uses a more efficient format. So you're likely to have less
184 disk I/O when you allow pamflip less memory.
185
186 If you do not specify -memsize, pamflip assumes infinity.
187
188 This option did not exist before Netpbm 10.7 (August 2002).
189
190 Before Netpbm 10.42 (March 2008), this option applied only to
191 real memory. pamflip would always keep the entire image in vir‐
192 tual memory and if it could not get enough virtual memory, it
193 failed. pamflip accessed the pixels in an order designed to
194 keep real memory use within the specified amount.
195
196
197 -pagesize=bytes
198 bytes is the size in bytes of a paging unit -- the amount of
199 memory that gets paged in or out as an indivisible unit -- in
200 your system. The default is 4KiB.
201
202 This option has no effect.
203
204 Before Netpbm 10.42 (March 2008), pamflip used it to control its
205 use of real memory.
206
207 This option did not exist before Netpbm 10.7 (August 2002).
208
209
210
211 Miscellaneous options:
212
213
214 -verbose
215 This option causes pamflip to issue messages to Standard Error
216 about its progress.
217
218
219
220
222 pnmrotate(1), pnm(1), pam(1), jpegtran manual
223
224
226 pamflip replaced pnmflip in Netpbm 10.13 (December 2002). pamflip is
227 backward compatible, but also works on PAM images.
228
229
230
232 Copyright (C) 1989 by Jef Poskanzer.
233
235 This manual page was generated by the Netpbm tool 'makeman' from HTML
236 source. The master documentation is at
237
238 http://netpbm.sourceforge.net/doc/pamflip.html
239
240netpbm documentation 20 January 2008 Pamflip User Manual(0)