0
|
1 |
USAGE instructions for the Independent JPEG Group's JPEG software
|
|
2 |
=================================================================
|
|
3 |
|
|
4 |
This file describes usage of the JPEG conversion programs cjpeg and djpeg,
|
|
5 |
as well as the utility programs jpegtran, rdjpgcom and wrjpgcom. (See
|
|
6 |
the other documentation files if you wish to use the JPEG library within
|
|
7 |
your own programs.)
|
|
8 |
|
|
9 |
If you are on a Unix machine you may prefer to read the Unix-style manual
|
|
10 |
pages in files cjpeg.1, djpeg.1, jpegtran.1, rdjpgcom.1, wrjpgcom.1.
|
|
11 |
|
|
12 |
|
|
13 |
INTRODUCTION
|
|
14 |
|
|
15 |
These programs implement JPEG image compression and decompression. JPEG
|
|
16 |
(pronounced "jay-peg") is a standardized compression method for full-color
|
|
17 |
and gray-scale images. JPEG is designed to handle "real-world" scenes,
|
|
18 |
for example scanned photographs. Cartoons, line drawings, and other
|
|
19 |
non-realistic images are not JPEG's strong suit; on that sort of material
|
|
20 |
you may get poor image quality and/or little compression.
|
|
21 |
|
|
22 |
JPEG is lossy, meaning that the output image is not necessarily identical to
|
|
23 |
the input image. Hence you should not use JPEG if you have to have identical
|
|
24 |
output bits. However, on typical real-world images, very good compression
|
|
25 |
levels can be obtained with no visible change, and amazingly high compression
|
|
26 |
is possible if you can tolerate a low-quality image. You can trade off image
|
|
27 |
quality against file size by adjusting the compressor's "quality" setting.
|
|
28 |
|
|
29 |
|
|
30 |
GENERAL USAGE
|
|
31 |
|
|
32 |
We provide two programs, cjpeg to compress an image file into JPEG format,
|
|
33 |
and djpeg to decompress a JPEG file back into a conventional image format.
|
|
34 |
|
|
35 |
On Unix-like systems, you say:
|
|
36 |
cjpeg [switches] [imagefile] >jpegfile
|
|
37 |
or
|
|
38 |
djpeg [switches] [jpegfile] >imagefile
|
|
39 |
The programs read the specified input file, or standard input if none is
|
|
40 |
named. They always write to standard output (with trace/error messages to
|
|
41 |
standard error). These conventions are handy for piping images between
|
|
42 |
programs.
|
|
43 |
|
|
44 |
On most non-Unix systems, you say:
|
|
45 |
cjpeg [switches] imagefile jpegfile
|
|
46 |
or
|
|
47 |
djpeg [switches] jpegfile imagefile
|
|
48 |
i.e., both the input and output files are named on the command line. This
|
|
49 |
style is a little more foolproof, and it loses no functionality if you don't
|
|
50 |
have pipes. (You can get this style on Unix too, if you prefer, by defining
|
|
51 |
TWO_FILE_COMMANDLINE when you compile the programs; see install.doc.)
|
|
52 |
|
|
53 |
You can also say:
|
|
54 |
cjpeg [switches] -outfile jpegfile imagefile
|
|
55 |
or
|
|
56 |
djpeg [switches] -outfile imagefile jpegfile
|
|
57 |
This syntax works on all systems, so it is useful for scripts.
|
|
58 |
|
|
59 |
The currently supported image file formats are: PPM (PBMPLUS color format),
|
|
60 |
PGM (PBMPLUS gray-scale format), BMP, Targa, and RLE (Utah Raster Toolkit
|
|
61 |
format). (RLE is supported only if the URT library is available.)
|
|
62 |
cjpeg recognizes the input image format automatically, with the exception
|
|
63 |
of some Targa-format files. You have to tell djpeg which format to generate.
|
|
64 |
|
|
65 |
JPEG files are in the defacto standard JFIF file format. There are other,
|
|
66 |
less widely used JPEG-based file formats, but we don't support them.
|
|
67 |
|
|
68 |
All switch names may be abbreviated; for example, -grayscale may be written
|
|
69 |
-gray or -gr. Most of the "basic" switches can be abbreviated to as little as
|
|
70 |
one letter. Upper and lower case are equivalent (-BMP is the same as -bmp).
|
|
71 |
British spellings are also accepted (e.g., -greyscale), though for brevity
|
|
72 |
these are not mentioned below.
|
|
73 |
|
|
74 |
|
|
75 |
CJPEG DETAILS
|
|
76 |
|
|
77 |
The basic command line switches for cjpeg are:
|
|
78 |
|
|
79 |
-quality N Scale quantization tables to adjust image quality.
|
|
80 |
Quality is 0 (worst) to 100 (best); default is 75.
|
|
81 |
(See below for more info.)
|
|
82 |
|
|
83 |
-grayscale Create monochrome JPEG file from color input.
|
|
84 |
Be sure to use this switch when compressing a grayscale
|
|
85 |
BMP file, because cjpeg isn't bright enough to notice
|
|
86 |
whether a BMP file uses only shades of gray. By
|
|
87 |
saying -grayscale, you'll get a smaller JPEG file that
|
|
88 |
takes less time to process.
|
|
89 |
|
|
90 |
-optimize Perform optimization of entropy encoding parameters.
|
|
91 |
Without this, default encoding parameters are used.
|
|
92 |
-optimize usually makes the JPEG file a little smaller,
|
|
93 |
but cjpeg runs somewhat slower and needs much more
|
|
94 |
memory. Image quality and speed of decompression are
|
|
95 |
unaffected by -optimize.
|
|
96 |
|
|
97 |
-progressive Create progressive JPEG file (see below).
|
|
98 |
|
|
99 |
-targa Input file is Targa format. Targa files that contain
|
|
100 |
an "identification" field will not be automatically
|
|
101 |
recognized by cjpeg; for such files you must specify
|
|
102 |
-targa to make cjpeg treat the input as Targa format.
|
|
103 |
For most Targa files, you won't need this switch.
|
|
104 |
|
|
105 |
The -quality switch lets you trade off compressed file size against quality of
|
|
106 |
the reconstructed image: the higher the quality setting, the larger the JPEG
|
|
107 |
file, and the closer the output image will be to the original input. Normally
|
|
108 |
you want to use the lowest quality setting (smallest file) that decompresses
|
|
109 |
into something visually indistinguishable from the original image. For this
|
|
110 |
purpose the quality setting should be between 50 and 95; the default of 75 is
|
|
111 |
often about right. If you see defects at -quality 75, then go up 5 or 10
|
|
112 |
counts at a time until you are happy with the output image. (The optimal
|
|
113 |
setting will vary from one image to another.)
|
|
114 |
|
|
115 |
-quality 100 will generate a quantization table of all 1's, minimizing loss
|
|
116 |
in the quantization step (but there is still information loss in subsampling,
|
|
117 |
as well as roundoff error). This setting is mainly of interest for
|
|
118 |
experimental purposes. Quality values above about 95 are NOT recommended for
|
|
119 |
normal use; the compressed file size goes up dramatically for hardly any gain
|
|
120 |
in output image quality.
|
|
121 |
|
|
122 |
In the other direction, quality values below 50 will produce very small files
|
|
123 |
of low image quality. Settings around 5 to 10 might be useful in preparing an
|
|
124 |
index of a large image library, for example. Try -quality 2 (or so) for some
|
|
125 |
amusing Cubist effects. (Note: quality values below about 25 generate 2-byte
|
|
126 |
quantization tables, which are considered optional in the JPEG standard.
|
|
127 |
cjpeg emits a warning message when you give such a quality value, because some
|
|
128 |
other JPEG programs may be unable to decode the resulting file. Use -baseline
|
|
129 |
if you need to ensure compatibility at low quality values.)
|
|
130 |
|
|
131 |
The -progressive switch creates a "progressive JPEG" file. In this type of
|
|
132 |
JPEG file, the data is stored in multiple scans of increasing quality. If the
|
|
133 |
file is being transmitted over a slow communications link, the decoder can use
|
|
134 |
the first scan to display a low-quality image very quickly, and can then
|
|
135 |
improve the display with each subsequent scan. The final image is exactly
|
|
136 |
equivalent to a standard JPEG file of the same quality setting, and the total
|
|
137 |
file size is about the same --- often a little smaller. CAUTION: progressive
|
|
138 |
JPEG is not yet widely implemented, so many decoders will be unable to view a
|
|
139 |
progressive JPEG file at all.
|
|
140 |
|
|
141 |
Switches for advanced users:
|
|
142 |
|
|
143 |
-dct int Use integer DCT method (default).
|
|
144 |
-dct fast Use fast integer DCT (less accurate).
|
|
145 |
-dct float Use floating-point DCT method.
|
|
146 |
The float method is very slightly more accurate than
|
|
147 |
the int method, but is much slower unless your machine
|
|
148 |
has very fast floating-point hardware. Also note that
|
|
149 |
results of the floating-point method may vary slightly
|
|
150 |
across machines, while the integer methods should give
|
|
151 |
the same results everywhere. The fast integer method
|
|
152 |
is much less accurate than the other two.
|
|
153 |
|
|
154 |
-restart N Emit a JPEG restart marker every N MCU rows, or every
|
|
155 |
N MCU blocks if "B" is attached to the number.
|
|
156 |
-restart 0 (the default) means no restart markers.
|
|
157 |
|
|
158 |
-smooth N Smooth the input image to eliminate dithering noise.
|
|
159 |
N, ranging from 1 to 100, indicates the strength of
|
|
160 |
smoothing. 0 (the default) means no smoothing.
|
|
161 |
|
|
162 |
-maxmemory N Set limit for amount of memory to use in processing
|
|
163 |
large images. Value is in thousands of bytes, or
|
|
164 |
millions of bytes if "M" is attached to the number.
|
|
165 |
For example, -max 4m selects 4000000 bytes. If more
|
|
166 |
space is needed, temporary files will be used.
|
|
167 |
|
|
168 |
-verbose Enable debug printout. More -v's give more printout.
|
|
169 |
or -debug Also, version information is printed at startup.
|
|
170 |
|
|
171 |
The -restart option inserts extra markers that allow a JPEG decoder to
|
|
172 |
resynchronize after a transmission error. Without restart markers, any damage
|
|
173 |
to a compressed file will usually ruin the image from the point of the error
|
|
174 |
to the end of the image; with restart markers, the damage is usually confined
|
|
175 |
to the portion of the image up to the next restart marker. Of course, the
|
|
176 |
restart markers occupy extra space. We recommend -restart 1 for images that
|
|
177 |
will be transmitted across unreliable networks such as Usenet.
|
|
178 |
|
|
179 |
The -smooth option filters the input to eliminate fine-scale noise. This is
|
|
180 |
often useful when converting dithered images to JPEG: a moderate smoothing
|
|
181 |
factor of 10 to 50 gets rid of dithering patterns in the input file, resulting
|
|
182 |
in a smaller JPEG file and a better-looking image. Too large a smoothing
|
|
183 |
factor will visibly blur the image, however.
|
|
184 |
|
|
185 |
Switches for wizards:
|
|
186 |
|
|
187 |
-baseline Force baseline-compatible quantization tables to be
|
|
188 |
generated. This clamps quantization values to 8 bits
|
|
189 |
even at low quality settings. (This switch is poorly
|
|
190 |
named, since it does not ensure that the output is
|
|
191 |
actually baseline JPEG. For example, you can use
|
|
192 |
-baseline and -progressive together.)
|
|
193 |
|
|
194 |
-qtables file Use the quantization tables given in the specified
|
|
195 |
text file.
|
|
196 |
|
|
197 |
-qslots N[,...] Select which quantization table to use for each color
|
|
198 |
component.
|
|
199 |
|
|
200 |
-sample HxV[,...] Set JPEG sampling factors for each color component.
|
|
201 |
|
|
202 |
-scans file Use the scan script given in the specified text file.
|
|
203 |
|
|
204 |
The "wizard" switches are intended for experimentation with JPEG. If you
|
|
205 |
don't know what you are doing, DON'T USE THEM. These switches are documented
|
|
206 |
further in the file wizard.doc.
|
|
207 |
|
|
208 |
|
|
209 |
DJPEG DETAILS
|
|
210 |
|
|
211 |
The basic command line switches for djpeg are:
|
|
212 |
|
|
213 |
-colors N Reduce image to at most N colors. This reduces the
|
|
214 |
or -quantize N number of colors used in the output image, so that it
|
|
215 |
can be displayed on a colormapped display or stored in
|
|
216 |
a colormapped file format. For example, if you have
|
|
217 |
an 8-bit display, you'd need to reduce to 256 or fewer
|
|
218 |
colors. (-colors is the recommended name, -quantize
|
|
219 |
is provided only for backwards compatibility.)
|
|
220 |
|
|
221 |
-fast Select recommended processing options for fast, low
|
|
222 |
quality output. (The default options are chosen for
|
|
223 |
highest quality output.) Currently, this is equivalent
|
|
224 |
to "-dct fast -nosmooth -onepass -dither ordered".
|
|
225 |
|
|
226 |
-grayscale Force gray-scale output even if JPEG file is color.
|
|
227 |
Useful for viewing on monochrome displays; also,
|
|
228 |
djpeg runs noticeably faster in this mode.
|
|
229 |
|
|
230 |
-scale M/N Scale the output image by a factor M/N. Currently
|
|
231 |
the scale factor must be 1/1, 1/2, 1/4, or 1/8.
|
|
232 |
Scaling is handy if the image is larger than your
|
|
233 |
screen; also, djpeg runs much faster when scaling
|
|
234 |
down the output.
|
|
235 |
|
|
236 |
-bmp Select BMP output format (Windows flavor). 8-bit
|
|
237 |
colormapped format is emitted if -colors or -grayscale
|
|
238 |
is specified, or if the JPEG file is gray-scale;
|
|
239 |
otherwise, 24-bit full-color format is emitted.
|
|
240 |
|
|
241 |
-gif Select GIF output format. Since GIF does not support
|
|
242 |
more than 256 colors, -colors 256 is assumed (unless
|
|
243 |
you specify a smaller number of colors). If you
|
|
244 |
specify -fast, the default number of colors is 216.
|
|
245 |
|
|
246 |
-os2 Select BMP output format (OS/2 1.x flavor). 8-bit
|
|
247 |
colormapped format is emitted if -colors or -grayscale
|
|
248 |
is specified, or if the JPEG file is gray-scale;
|
|
249 |
otherwise, 24-bit full-color format is emitted.
|
|
250 |
|
|
251 |
-pnm Select PBMPLUS (PPM/PGM) output format (this is the
|
|
252 |
default format). PGM is emitted if the JPEG file is
|
|
253 |
gray-scale or if -grayscale is specified; otherwise
|
|
254 |
PPM is emitted.
|
|
255 |
|
|
256 |
-rle Select RLE output format. (Requires URT library.)
|
|
257 |
|
|
258 |
-targa Select Targa output format. Gray-scale format is
|
|
259 |
emitted if the JPEG file is gray-scale or if
|
|
260 |
-grayscale is specified; otherwise, colormapped format
|
|
261 |
is emitted if -colors is specified; otherwise, 24-bit
|
|
262 |
full-color format is emitted.
|
|
263 |
|
|
264 |
Switches for advanced users:
|
|
265 |
|
|
266 |
-dct int Use integer DCT method (default).
|
|
267 |
-dct fast Use fast integer DCT (less accurate).
|
|
268 |
-dct float Use floating-point DCT method.
|
|
269 |
The float method is very slightly more accurate than
|
|
270 |
the int method, but is much slower unless your machine
|
|
271 |
has very fast floating-point hardware. Also note that
|
|
272 |
results of the floating-point method may vary slightly
|
|
273 |
across machines, while the integer methods should give
|
|
274 |
the same results everywhere. The fast integer method
|
|
275 |
is much less accurate than the other two.
|
|
276 |
|
|
277 |
-dither fs Use Floyd-Steinberg dithering in color quantization.
|
|
278 |
-dither ordered Use ordered dithering in color quantization.
|
|
279 |
-dither none Do not use dithering in color quantization.
|
|
280 |
By default, Floyd-Steinberg dithering is applied when
|
|
281 |
quantizing colors; this is slow but usually produces
|
|
282 |
the best results. Ordered dither is a compromise
|
|
283 |
between speed and quality; no dithering is fast but
|
|
284 |
usually looks awful. Note that these switches have
|
|
285 |
no effect unless color quantization is being done.
|
|
286 |
Ordered dither is only available in -onepass mode.
|
|
287 |
|
|
288 |
-map FILE Quantize to the colors used in the specified image
|
|
289 |
file. This is useful for producing multiple files
|
|
290 |
with identical color maps, or for forcing a predefined
|
|
291 |
set of colors to be used. The FILE must be a GIF
|
|
292 |
or PPM file. This option overrides -colors and
|
|
293 |
-onepass.
|
|
294 |
|
|
295 |
-nosmooth Use a faster, lower-quality upsampling routine.
|
|
296 |
|
|
297 |
-onepass Use one-pass instead of two-pass color quantization.
|
|
298 |
The one-pass method is faster and needs less memory,
|
|
299 |
but it produces a lower-quality image. -onepass is
|
|
300 |
ignored unless you also say -colors N. Also,
|
|
301 |
the one-pass method is always used for gray-scale
|
|
302 |
output (the two-pass method is no improvement then).
|
|
303 |
|
|
304 |
-maxmemory N Set limit for amount of memory to use in processing
|
|
305 |
large images. Value is in thousands of bytes, or
|
|
306 |
millions of bytes if "M" is attached to the number.
|
|
307 |
For example, -max 4m selects 4000000 bytes. If more
|
|
308 |
space is needed, temporary files will be used.
|
|
309 |
|
|
310 |
-verbose Enable debug printout. More -v's give more printout.
|
|
311 |
or -debug Also, version information is printed at startup.
|
|
312 |
|
|
313 |
|
|
314 |
HINTS FOR CJPEG
|
|
315 |
|
|
316 |
Color GIF files are not the ideal input for JPEG; JPEG is really intended for
|
|
317 |
compressing full-color (24-bit) images. In particular, don't try to convert
|
|
318 |
cartoons, line drawings, and other images that have only a few distinct
|
|
319 |
colors. GIF works great on these, JPEG does not. If you want to convert a
|
|
320 |
GIF to JPEG, you should experiment with cjpeg's -quality and -smooth options
|
|
321 |
to get a satisfactory conversion. -smooth 10 or so is often helpful.
|
|
322 |
|
|
323 |
Avoid running an image through a series of JPEG compression/decompression
|
|
324 |
cycles. Image quality loss will accumulate; after ten or so cycles the image
|
|
325 |
may be noticeably worse than it was after one cycle. It's best to use a
|
|
326 |
lossless format while manipulating an image, then convert to JPEG format when
|
|
327 |
you are ready to file the image away.
|
|
328 |
|
|
329 |
The -optimize option to cjpeg is worth using when you are making a "final"
|
|
330 |
version for posting or archiving. It's also a win when you are using low
|
|
331 |
quality settings to make very small JPEG files; the percentage improvement
|
|
332 |
is often a lot more than it is on larger files. (At present, -optimize
|
|
333 |
mode is always selected when generating progressive JPEG files.)
|
|
334 |
|
|
335 |
GIF input files are no longer supported, to avoid the Unisys LZW patent.
|
|
336 |
Use a Unisys-licensed program if you need to read a GIF file. (Conversion
|
|
337 |
of GIF files to JPEG is usually a bad idea anyway.)
|
|
338 |
|
|
339 |
|
|
340 |
HINTS FOR DJPEG
|
|
341 |
|
|
342 |
To get a quick preview of an image, use the -grayscale and/or -scale switches.
|
|
343 |
"-grayscale -scale 1/8" is the fastest case.
|
|
344 |
|
|
345 |
Several options are available that trade off image quality to gain speed.
|
|
346 |
"-fast" turns on the recommended settings.
|
|
347 |
|
|
348 |
"-dct fast" and/or "-nosmooth" gain speed at a small sacrifice in quality.
|
|
349 |
When producing a color-quantized image, "-onepass -dither ordered" is fast but
|
|
350 |
much lower quality than the default behavior. "-dither none" may give
|
|
351 |
acceptable results in two-pass mode, but is seldom tolerable in one-pass mode.
|
|
352 |
|
|
353 |
If you are fortunate enough to have very fast floating point hardware,
|
|
354 |
"-dct float" may be even faster than "-dct fast". But on most machines
|
|
355 |
"-dct float" is slower than "-dct int"; in this case it is not worth using,
|
|
356 |
because its theoretical accuracy advantage is too small to be significant
|
|
357 |
in practice.
|
|
358 |
|
|
359 |
Two-pass color quantization requires a good deal of memory; on MS-DOS machines
|
|
360 |
it may run out of memory even with -maxmemory 0. In that case you can still
|
|
361 |
decompress, with some loss of image quality, by specifying -onepass for
|
|
362 |
one-pass quantization.
|
|
363 |
|
|
364 |
To avoid the Unisys LZW patent, djpeg produces uncompressed GIF files. These
|
|
365 |
are larger than they should be, but are readable by standard GIF decoders.
|
|
366 |
|
|
367 |
|
|
368 |
HINTS FOR BOTH PROGRAMS
|
|
369 |
|
|
370 |
If more space is needed than will fit in the available main memory (as
|
|
371 |
determined by -maxmemory), temporary files will be used. (MS-DOS versions
|
|
372 |
will try to get extended or expanded memory first.) The temporary files are
|
|
373 |
often rather large: in typical cases they occupy three bytes per pixel, for
|
|
374 |
example 3*800*600 = 1.44Mb for an 800x600 image. If you don't have enough
|
|
375 |
free disk space, leave out -progressive and -optimize (for cjpeg) or specify
|
|
376 |
-onepass (for djpeg).
|
|
377 |
|
|
378 |
On MS-DOS, the temporary files are created in the directory named by the TMP
|
|
379 |
or TEMP environment variable, or in the current directory if neither of those
|
|
380 |
exist. Amiga implementations put the temp files in the directory named by
|
|
381 |
JPEGTMP:, so be sure to assign JPEGTMP: to a disk partition with adequate free
|
|
382 |
space.
|
|
383 |
|
|
384 |
The default memory usage limit (-maxmemory) is set when the software is
|
|
385 |
compiled. If you get an "insufficient memory" error, try specifying a smaller
|
|
386 |
-maxmemory value, even -maxmemory 0 to use the absolute minimum space. You
|
|
387 |
may want to recompile with a smaller default value if this happens often.
|
|
388 |
|
|
389 |
On machines that have "environment" variables, you can define the environment
|
|
390 |
variable JPEGMEM to set the default memory limit. The value is specified as
|
|
391 |
described for the -maxmemory switch. JPEGMEM overrides the default value
|
|
392 |
specified when the program was compiled, and itself is overridden by an
|
|
393 |
explicit -maxmemory switch.
|
|
394 |
|
|
395 |
On MS-DOS machines, -maxmemory is the amount of main (conventional) memory to
|
|
396 |
use. (Extended or expanded memory is also used if available.) Most
|
|
397 |
DOS-specific versions of this software do their own memory space estimation
|
|
398 |
and do not need you to specify -maxmemory.
|
|
399 |
|
|
400 |
|
|
401 |
JPEGTRAN
|
|
402 |
|
|
403 |
jpegtran performs various useful transformations of JPEG files.
|
|
404 |
It can translate the coded representation from one variant of JPEG to another,
|
|
405 |
for example from baseline JPEG to progressive JPEG or vice versa. It can also
|
|
406 |
perform some rearrangements of the image data, for example turning an image
|
|
407 |
from landscape to portrait format by rotation.
|
|
408 |
|
|
409 |
jpegtran works by rearranging the compressed data (DCT coefficients), without
|
|
410 |
ever fully decoding the image. Therefore, its transformations are lossless:
|
|
411 |
there is no image degradation at all, which would not be true if you used
|
|
412 |
djpeg followed by cjpeg to accomplish the same conversion. But by the same
|
|
413 |
token, jpegtran cannot perform lossy operations such as changing the image
|
|
414 |
quality.
|
|
415 |
|
|
416 |
jpegtran uses a command line syntax similar to cjpeg or djpeg.
|
|
417 |
On Unix-like systems, you say:
|
|
418 |
jpegtran [switches] [inputfile] >outputfile
|
|
419 |
On most non-Unix systems, you say:
|
|
420 |
jpegtran [switches] inputfile outputfile
|
|
421 |
where both the input and output files are JPEG files.
|
|
422 |
|
|
423 |
To specify the coded JPEG representation used in the output file,
|
|
424 |
jpegtran accepts a subset of the switches recognized by cjpeg:
|
|
425 |
-optimize Perform optimization of entropy encoding parameters.
|
|
426 |
-progressive Create progressive JPEG file.
|
|
427 |
-restart N Emit a JPEG restart marker every N MCU rows, or every
|
|
428 |
N MCU blocks if "B" is attached to the number.
|
|
429 |
-scans file Use the scan script given in the specified text file.
|
|
430 |
See the previous discussion of cjpeg for more details about these switches.
|
|
431 |
If you specify none of these switches, you get a plain baseline-JPEG output
|
|
432 |
file. The quality setting and so forth are determined by the input file.
|
|
433 |
|
|
434 |
The image can be losslessly transformed by giving one of these switches:
|
|
435 |
-flip horizontal Mirror image horizontally (left-right).
|
|
436 |
-flip vertical Mirror image vertically (top-bottom).
|
|
437 |
-rotate 90 Rotate image 90 degrees clockwise.
|
|
438 |
-rotate 180 Rotate image 180 degrees.
|
|
439 |
-rotate 270 Rotate image 270 degrees clockwise (or 90 ccw).
|
|
440 |
-transpose Transpose image (across UL-to-LR axis).
|
|
441 |
-transverse Transverse transpose (across UR-to-LL axis).
|
|
442 |
|
|
443 |
The transpose transformation has no restrictions regarding image dimensions.
|
|
444 |
The other transformations operate rather oddly if the image dimensions are not
|
|
445 |
a multiple of the iMCU size (usually 8 or 16 pixels), because they can only
|
|
446 |
transform complete blocks of DCT coefficient data in the desired way.
|
|
447 |
|
|
448 |
jpegtran's default behavior when transforming an odd-size image is designed
|
|
449 |
to preserve exact reversibility and mathematical consistency of the
|
|
450 |
transformation set. As stated, transpose is able to flip the entire image
|
|
451 |
area. Horizontal mirroring leaves any partial iMCU column at the right edge
|
|
452 |
untouched, but is able to flip all rows of the image. Similarly, vertical
|
|
453 |
mirroring leaves any partial iMCU row at the bottom edge untouched, but is
|
|
454 |
able to flip all columns. The other transforms can be built up as sequences
|
|
455 |
of transpose and flip operations; for consistency, their actions on edge
|
|
456 |
pixels are defined to be the same as the end result of the corresponding
|
|
457 |
transpose-and-flip sequence.
|
|
458 |
|
|
459 |
For practical use, you may prefer to discard any untransformable edge pixels
|
|
460 |
rather than having a strange-looking strip along the right and/or bottom edges
|
|
461 |
of a transformed image. To do this, add the -trim switch:
|
|
462 |
-trim Drop non-transformable edge blocks.
|
|
463 |
Obviously, a transformation with -trim is not reversible, so strictly speaking
|
|
464 |
jpegtran with this switch is not lossless. Also, the expected mathematical
|
|
465 |
equivalences between the transformations no longer hold. For example,
|
|
466 |
"-rot 270 -trim" trims only the bottom edge, but "-rot 90 -trim" followed by
|
|
467 |
"-rot 180 -trim" trims both edges.
|
|
468 |
|
|
469 |
Another not-strictly-lossless transformation switch is:
|
|
470 |
-grayscale Force grayscale output.
|
|
471 |
This option discards the chrominance channels if the input image is YCbCr
|
|
472 |
(ie, a standard color JPEG), resulting in a grayscale JPEG file. The
|
|
473 |
luminance channel is preserved exactly, so this is a better method of reducing
|
|
474 |
to grayscale than decompression, conversion, and recompression. This switch
|
|
475 |
is particularly handy for fixing a monochrome picture that was mistakenly
|
|
476 |
encoded as a color JPEG. (In such a case, the space savings from getting rid
|
|
477 |
of the near-empty chroma channels won't be large; but the decoding time for
|
|
478 |
a grayscale JPEG is substantially less than that for a color JPEG.)
|
|
479 |
|
|
480 |
jpegtran also recognizes these switches that control what to do with "extra"
|
|
481 |
markers, such as comment blocks:
|
|
482 |
-copy none Copy no extra markers from source file. This setting
|
|
483 |
suppresses all comments and other excess baggage
|
|
484 |
present in the source file.
|
|
485 |
-copy comments Copy only comment markers. This setting copies
|
|
486 |
comments from the source file, but discards
|
|
487 |
any other inessential data.
|
|
488 |
-copy all Copy all extra markers. This setting preserves
|
|
489 |
miscellaneous markers found in the source file, such
|
|
490 |
as JFIF thumbnails and Photoshop settings. In some
|
|
491 |
files these extra markers can be sizable.
|
|
492 |
The default behavior is -copy comments. (Note: in IJG releases v6 and v6a,
|
|
493 |
jpegtran always did the equivalent of -copy none.)
|
|
494 |
|
|
495 |
Additional switches recognized by jpegtran are:
|
|
496 |
-outfile filename
|
|
497 |
-maxmemory N
|
|
498 |
-verbose
|
|
499 |
-debug
|
|
500 |
These work the same as in cjpeg or djpeg.
|
|
501 |
|
|
502 |
|
|
503 |
THE COMMENT UTILITIES
|
|
504 |
|
|
505 |
The JPEG standard allows "comment" (COM) blocks to occur within a JPEG file.
|
|
506 |
Although the standard doesn't actually define what COM blocks are for, they
|
|
507 |
are widely used to hold user-supplied text strings. This lets you add
|
|
508 |
annotations, titles, index terms, etc to your JPEG files, and later retrieve
|
|
509 |
them as text. COM blocks do not interfere with the image stored in the JPEG
|
|
510 |
file. The maximum size of a COM block is 64K, but you can have as many of
|
|
511 |
them as you like in one JPEG file.
|
|
512 |
|
|
513 |
We provide two utility programs to display COM block contents and add COM
|
|
514 |
blocks to a JPEG file.
|
|
515 |
|
|
516 |
rdjpgcom searches a JPEG file and prints the contents of any COM blocks on
|
|
517 |
standard output. The command line syntax is
|
|
518 |
rdjpgcom [-verbose] [inputfilename]
|
|
519 |
The switch "-verbose" (or just "-v") causes rdjpgcom to also display the JPEG
|
|
520 |
image dimensions. If you omit the input file name from the command line,
|
|
521 |
the JPEG file is read from standard input. (This may not work on some
|
|
522 |
operating systems, if binary data can't be read from stdin.)
|
|
523 |
|
|
524 |
wrjpgcom adds a COM block, containing text you provide, to a JPEG file.
|
|
525 |
Ordinarily, the COM block is added after any existing COM blocks, but you
|
|
526 |
can delete the old COM blocks if you wish. wrjpgcom produces a new JPEG
|
|
527 |
file; it does not modify the input file. DO NOT try to overwrite the input
|
|
528 |
file by directing wrjpgcom's output back into it; on most systems this will
|
|
529 |
just destroy your file.
|
|
530 |
|
|
531 |
The command line syntax for wrjpgcom is similar to cjpeg's. On Unix-like
|
|
532 |
systems, it is
|
|
533 |
wrjpgcom [switches] [inputfilename]
|
|
534 |
The output file is written to standard output. The input file comes from
|
|
535 |
the named file, or from standard input if no input file is named.
|
|
536 |
|
|
537 |
On most non-Unix systems, the syntax is
|
|
538 |
wrjpgcom [switches] inputfilename outputfilename
|
|
539 |
where both input and output file names must be given explicitly.
|
|
540 |
|
|
541 |
wrjpgcom understands three switches:
|
|
542 |
-replace Delete any existing COM blocks from the file.
|
|
543 |
-comment "Comment text" Supply new COM text on command line.
|
|
544 |
-cfile name Read text for new COM block from named file.
|
|
545 |
(Switch names can be abbreviated.) If you have only one line of comment text
|
|
546 |
to add, you can provide it on the command line with -comment. The comment
|
|
547 |
text must be surrounded with quotes so that it is treated as a single
|
|
548 |
argument. Longer comments can be read from a text file.
|
|
549 |
|
|
550 |
If you give neither -comment nor -cfile, then wrjpgcom will read the comment
|
|
551 |
text from standard input. (In this case an input image file name MUST be
|
|
552 |
supplied, so that the source JPEG file comes from somewhere else.) You can
|
|
553 |
enter multiple lines, up to 64KB worth. Type an end-of-file indicator
|
|
554 |
(usually control-D or control-Z) to terminate the comment text entry.
|
|
555 |
|
|
556 |
wrjpgcom will not add a COM block if the provided comment string is empty.
|
|
557 |
Therefore -replace -comment "" can be used to delete all COM blocks from a
|
|
558 |
file.
|
|
559 |
|
|
560 |
These utility programs do not depend on the IJG JPEG library. In
|
|
561 |
particular, the source code for rdjpgcom is intended as an illustration of
|
|
562 |
the minimum amount of code required to parse a JPEG file header correctly.
|