version 1 showing authors affecting page license.
.
Rev |
Author |
# |
Line |
1 |
perry |
1 |
JPEGTRAN |
|
|
2 |
!!!JPEGTRAN |
|
|
3 |
NAME |
|
|
4 |
SYNOPSIS |
|
|
5 |
DESCRIPTION |
|
|
6 |
OPTIONS |
|
|
7 |
EXAMPLES |
|
|
8 |
ENVIRONMENT |
|
|
9 |
SEE ALSO |
|
|
10 |
AUTHOR |
|
|
11 |
BUGS |
|
|
12 |
---- |
|
|
13 |
!!NAME |
|
|
14 |
|
|
|
15 |
|
|
|
16 |
jpegtran - lossless transformation of JPEG files |
|
|
17 |
!!SYNOPSIS |
|
|
18 |
|
|
|
19 |
|
|
|
20 |
__jpegtran__ [[ ''options'' ] [[ ''filename'' |
|
|
21 |
] |
|
|
22 |
!!DESCRIPTION |
|
|
23 |
|
|
|
24 |
|
|
|
25 |
__jpegtran__ performs various useful transformations of |
|
|
26 |
JPEG files. It can translate the coded representation from |
|
|
27 |
one variant of JPEG to another, for example from baseline |
|
|
28 |
JPEG to progressive JPEG or vice versa. It can also perform |
|
|
29 |
some rearrangements of the image data, for example turning |
|
|
30 |
an image from landscape to portrait format by |
|
|
31 |
rotation. |
|
|
32 |
|
|
|
33 |
|
|
|
34 |
__jpegtran__ works by rearranging the compressed data |
|
|
35 |
(DCT coefficients), without ever fully decoding the image. |
|
|
36 |
Therefore, its transformations are lossless: there is no |
|
|
37 |
image degradation at all, which would not be true if you |
|
|
38 |
used __djpeg__ followed by __cjpeg__ to accomplish the |
|
|
39 |
same conversion. But by the same token, __jpegtran__ |
|
|
40 |
cannot perform lossy operations such as changing the image |
|
|
41 |
quality. |
|
|
42 |
|
|
|
43 |
|
|
|
44 |
__jpegtran__ reads the named JPEG/JFIF file, or the |
|
|
45 |
standard input if no file is named, and produces a JPEG/JFIF |
|
|
46 |
file on the standard output. |
|
|
47 |
!!OPTIONS |
|
|
48 |
|
|
|
49 |
|
|
|
50 |
All switch names may be abbreviated; for example, |
|
|
51 |
__-optimize__ may be written __-opt__ or __-o__. |
|
|
52 |
Upper and lower case are equivalent. British spellings are |
|
|
53 |
also accepted (e.g., __-optimise__), though for brevity |
|
|
54 |
these are not mentioned below. |
|
|
55 |
|
|
|
56 |
|
|
|
57 |
To specify the coded JPEG representation used in the output |
|
|
58 |
file, __jpegtran__ accepts a subset of the switches |
|
|
59 |
recognized by __cjpeg__: |
|
|
60 |
|
|
|
61 |
|
|
|
62 |
__-optimize__ |
|
|
63 |
|
|
|
64 |
|
|
|
65 |
Perform optimization of entropy encoding |
|
|
66 |
parameters. |
|
|
67 |
|
|
|
68 |
|
|
|
69 |
__-progressive__ |
|
|
70 |
|
|
|
71 |
|
|
|
72 |
Create progressive JPEG file. |
|
|
73 |
|
|
|
74 |
|
|
|
75 |
__-restart__ ''N'' |
|
|
76 |
|
|
|
77 |
|
|
|
78 |
Emit a JPEG restart marker every N MCU rows, or every N MCU |
|
|
79 |
blocks if |
|
|
80 |
|
|
|
81 |
|
|
|
82 |
__-scans__ ''file'' |
|
|
83 |
|
|
|
84 |
|
|
|
85 |
Use the scan script given in the specified text |
|
|
86 |
file. |
|
|
87 |
|
|
|
88 |
|
|
|
89 |
See cjpeg(1) for more details about these switches. |
|
|
90 |
If you specify none of these switches, you get a plain |
|
|
91 |
baseline-JPEG output file. The quality setting and so forth |
|
|
92 |
are determined by the input file. |
|
|
93 |
|
|
|
94 |
|
|
|
95 |
The image can be losslessly transformed by giving one of |
|
|
96 |
these switches: |
|
|
97 |
|
|
|
98 |
|
|
|
99 |
__-flip horizontal__ |
|
|
100 |
|
|
|
101 |
|
|
|
102 |
Mirror image horizontally (left-right). |
|
|
103 |
|
|
|
104 |
|
|
|
105 |
__-flip vertical__ |
|
|
106 |
|
|
|
107 |
|
|
|
108 |
Mirror image vertically (top-bottom). |
|
|
109 |
|
|
|
110 |
|
|
|
111 |
__-rotate 90__ |
|
|
112 |
|
|
|
113 |
|
|
|
114 |
Rotate image 90 degrees clockwise. |
|
|
115 |
|
|
|
116 |
|
|
|
117 |
__-rotate 180__ |
|
|
118 |
|
|
|
119 |
|
|
|
120 |
Rotate image 180 degrees. |
|
|
121 |
|
|
|
122 |
|
|
|
123 |
__-rotate 270__ |
|
|
124 |
|
|
|
125 |
|
|
|
126 |
Rotate image 270 degrees clockwise (or 90 ccw). |
|
|
127 |
|
|
|
128 |
|
|
|
129 |
__-transpose__ |
|
|
130 |
|
|
|
131 |
|
|
|
132 |
Transpose image (across UL-to-LR axis). |
|
|
133 |
|
|
|
134 |
|
|
|
135 |
__-transverse__ |
|
|
136 |
|
|
|
137 |
|
|
|
138 |
Transverse transpose (across UR-to-LL axis). |
|
|
139 |
|
|
|
140 |
|
|
|
141 |
The transpose transformation has no restrictions regarding |
|
|
142 |
image dimensions. The other transformations operate rather |
|
|
143 |
oddly if the image dimensions are not a multiple of the iMCU |
|
|
144 |
size (usually 8 or 16 pixels), because they can only |
|
|
145 |
transform complete blocks of DCT coefficient data in the |
|
|
146 |
desired way. |
|
|
147 |
|
|
|
148 |
|
|
|
149 |
__jpegtran__'s default behavior when transforming an |
|
|
150 |
odd-size image is designed to preserve exact reversibility |
|
|
151 |
and mathematical consistency of the transformation set. As |
|
|
152 |
stated, transpose is able to flip the entire image area. |
|
|
153 |
Horizontal mirroring leaves any partial iMCU column at the |
|
|
154 |
right edge untouched, but is able to flip all rows of the |
|
|
155 |
image. Similarly, vertical mirroring leaves any partial iMCU |
|
|
156 |
row at the bottom edge untouched, but is able to flip all |
|
|
157 |
columns. The other transforms can be built up as sequences |
|
|
158 |
of transpose and flip operations; for consistency, their |
|
|
159 |
actions on edge pixels are defined to be the same as the end |
|
|
160 |
result of the corresponding transpose-and-flip |
|
|
161 |
sequence. |
|
|
162 |
|
|
|
163 |
|
|
|
164 |
For practical use, you may prefer to discard any |
|
|
165 |
untransformable edge pixels rather than having a |
|
|
166 |
strange-looking strip along the right and/or bottom edges of |
|
|
167 |
a transformed image. To do this, add the __-trim__ |
|
|
168 |
switch: |
|
|
169 |
|
|
|
170 |
|
|
|
171 |
__-trim__ |
|
|
172 |
|
|
|
173 |
|
|
|
174 |
Drop non-transformable edge blocks. |
|
|
175 |
|
|
|
176 |
|
|
|
177 |
Obviously, a transformation with __-trim__ is not |
|
|
178 |
reversible, so strictly speaking __jpegtran__ with this |
|
|
179 |
switch is not lossless. Also, the expected mathematical |
|
|
180 |
equivalences between the transformations no longer hold. For |
|
|
181 |
example, __-rot 270 -trim__ trims only the bottom edge, |
|
|
182 |
but __-rot 90 -trim__ followed by __-rot 180 -trim__ |
|
|
183 |
trims both edges. |
|
|
184 |
|
|
|
185 |
|
|
|
186 |
We also offer a lossless-crop option, which discards data |
|
|
187 |
outside a given image region but losslessly preserves what |
|
|
188 |
is inside. Like the rotate and flip transforms, lossless |
|
|
189 |
crop is restricted by the JPEG format: the upper left corner |
|
|
190 |
of the selected region must fall on an iMCU boundary. If |
|
|
191 |
this does not hold for the given crop parameters, we |
|
|
192 |
silently move the upper left corner up and/or left to make |
|
|
193 |
it so, simultaneously increasing the region dimensions to |
|
|
194 |
keep the lower right crop corner unchanged. (Thus, the |
|
|
195 |
output image covers at least the requested region, but may |
|
|
196 |
cover more.) |
|
|
197 |
|
|
|
198 |
|
|
|
199 |
Note: lossless-crop is an enhancement from |
|
|
200 |
http://sylvana.net/jpegcrop/ that may not be available on |
|
|
201 |
non-Debian systems. |
|
|
202 |
|
|
|
203 |
|
|
|
204 |
The image can be losslessly cropped by giving the |
|
|
205 |
switch: |
|
|
206 |
|
|
|
207 |
|
|
|
208 |
__-crop WxH+X+Y__ |
|
|
209 |
|
|
|
210 |
|
|
|
211 |
Crop to a rectangular subarea of width W, height H starting |
|
|
212 |
at point X,Y. |
|
|
213 |
|
|
|
214 |
|
|
|
215 |
Another not-strictly-lossless transformation switch |
|
|
216 |
is: |
|
|
217 |
|
|
|
218 |
|
|
|
219 |
__-grayscale__ |
|
|
220 |
|
|
|
221 |
|
|
|
222 |
Force grayscale output. |
|
|
223 |
|
|
|
224 |
|
|
|
225 |
This option discards the chrominance channels if the input |
|
|
226 |
image is YCbCr (ie, a standard color JPEG), resulting in a |
|
|
227 |
grayscale JPEG file. The luminance channel is preserved |
|
|
228 |
exactly, so this is a better method of reducing to grayscale |
|
|
229 |
than decompression, conversion, and recompression. This |
|
|
230 |
switch is particularly handy for fixing a monochrome picture |
|
|
231 |
that was mistakenly encoded as a color JPEG. (In such a |
|
|
232 |
case, the space savings from getting rid of the near-empty |
|
|
233 |
chroma channels won't be large; but the decoding time for a |
|
|
234 |
grayscale JPEG is substantially less than that for a color |
|
|
235 |
JPEG.) |
|
|
236 |
|
|
|
237 |
|
|
|
238 |
__jpegtran__ also recognizes these switches that control |
|
|
239 |
what to do with |
|
|
240 |
__ |
|
|
241 |
|
|
|
242 |
|
|
|
243 |
__-copy none__ |
|
|
244 |
|
|
|
245 |
|
|
|
246 |
Copy no extra markers from source file. This setting |
|
|
247 |
suppresses all comments and other excess baggage present in |
|
|
248 |
the source file. |
|
|
249 |
|
|
|
250 |
|
|
|
251 |
__-copy comments__ |
|
|
252 |
|
|
|
253 |
|
|
|
254 |
Copy only comment markers. This setting copies comments from |
|
|
255 |
the source file, but discards any other inessential |
|
|
256 |
data. |
|
|
257 |
|
|
|
258 |
|
|
|
259 |
__-copy all__ |
|
|
260 |
|
|
|
261 |
|
|
|
262 |
Copy all extra markers. This setting preserves miscellaneous |
|
|
263 |
markers found in the source file, such as JFIF thumbnails |
|
|
264 |
and Photoshop settings. In some files these extra markers |
|
|
265 |
can be sizable. |
|
|
266 |
|
|
|
267 |
|
|
|
268 |
The default behavior is __-copy comments__. (Note: in IJG |
|
|
269 |
releases v6 and v6a, __jpegtran__ always did the |
|
|
270 |
equivalent of __-copy none__.) |
|
|
271 |
|
|
|
272 |
|
|
|
273 |
Additional switches recognized by jpegtran are: |
|
|
274 |
|
|
|
275 |
|
|
|
276 |
__-maxmemory__ ''N'' |
|
|
277 |
|
|
|
278 |
|
|
|
279 |
Set limit for amount of memory to use in processing large |
|
|
280 |
images. Value is in thousands of bytes, or millions of bytes |
|
|
281 |
if |
|
|
282 |
-max 4m__ selects 4000000 bytes. If more space is |
|
|
283 |
needed, temporary files will be used. |
|
|
284 |
|
|
|
285 |
|
|
|
286 |
__-outfile__ ''name'' |
|
|
287 |
|
|
|
288 |
|
|
|
289 |
Send output image to the named file, not to standard |
|
|
290 |
output. |
|
|
291 |
|
|
|
292 |
|
|
|
293 |
__-verbose__ |
|
|
294 |
|
|
|
295 |
|
|
|
296 |
Enable debug printout. More __-v__'s give more output. |
|
|
297 |
Also, version information is printed at |
|
|
298 |
startup. |
|
|
299 |
|
|
|
300 |
|
|
|
301 |
__-debug__ |
|
|
302 |
|
|
|
303 |
|
|
|
304 |
Same as __-verbose__. |
|
|
305 |
!!EXAMPLES |
|
|
306 |
|
|
|
307 |
|
|
|
308 |
This example converts a baseline JPEG file to progressive |
|
|
309 |
form: |
|
|
310 |
|
|
|
311 |
|
|
|
312 |
__jpegtran -progressive__ ''foo.jpg'' ____ |
|
|
313 |
''fooprog.jpg'' |
|
|
314 |
|
|
|
315 |
|
|
|
316 |
This example rotates an image 90 degrees clockwise, |
|
|
317 |
discarding any unrotatable edge pixels: |
|
|
318 |
|
|
|
319 |
|
|
|
320 |
__jpegtran -rot 90 -trim__ ''foo.jpg'' ____ |
|
|
321 |
''foo90.jpg'' |
|
|
322 |
!!ENVIRONMENT |
|
|
323 |
|
|
|
324 |
|
|
|
325 |
__JPEGMEM__ |
|
|
326 |
|
|
|
327 |
|
|
|
328 |
If this environment variable is set, its value is the |
|
|
329 |
default memory limit. The value is specified as described |
|
|
330 |
for the __-maxmemory__ switch. __JPEGMEM__ overrides |
|
|
331 |
the default value specified when the program was compiled, |
|
|
332 |
and itself is overridden by an explicit |
|
|
333 |
__-maxmemory__. |
|
|
334 |
!!SEE ALSO |
|
|
335 |
|
|
|
336 |
|
|
|
337 |
cjpeg(1), djpeg(1), rdjpgcom(1), |
|
|
338 |
wrjpgcom(1) |
|
|
339 |
Wallace, Gregory K. |
|
|
340 |
!!AUTHOR |
|
|
341 |
|
|
|
342 |
|
|
|
343 |
Independent JPEG Group |
|
|
344 |
!!BUGS |
|
|
345 |
|
|
|
346 |
|
|
|
347 |
Arithmetic coding is not supported for legal |
|
|
348 |
reasons. |
|
|
349 |
|
|
|
350 |
|
|
|
351 |
The transform options can't transform odd-size images |
|
|
352 |
perfectly. Use __-trim__ if you don't like the results |
|
|
353 |
without it. |
|
|
354 |
|
|
|
355 |
|
|
|
356 |
The entire image is read into memory and then written out |
|
|
357 |
again, even in cases where this isn't really necessary. |
|
|
358 |
Expect swapping on large images, especially when using the |
|
|
359 |
more complex transform options. |
|
|
360 |
---- |