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. |
|