Penguin
Blame: pnmtojpeg(1)
EditPageHistoryDiffInfoLikePages
Annotated edit history of pnmtojpeg(1) version 1, including all changes. View license author blame.
Rev Author # Line
1 perry 1 PNMTOJPEG
2 !!!PNMTOJPEG
3 NAME
4 SYNOPSIS
5 DESCRIPTION
6 OPTIONS
7 EXAMPLES
8 HINTS
9 SCAN SCRIPTS
10 ENVIRONMENT
11 SEE ALSO
12 LIMITATIONS
13 AUTHOR
14 ----
15 !!NAME
16
17
18 pnmtojpeg - convert PNM image to a JFIF (
19 !!SYNOPSIS
20
21
22 __pnmtojpeg__ [[ ''options'' ] [[ ''filename''
23 ]
24 !!DESCRIPTION
25
26
27 __pnmtojpeg__ converts the named PBM, PGM, or PPM image
28 file, or the standard input if no file is named, to a JFIF
29 file on the standard output.
30
31
32 __pnmtojpeg__ uses the Independent JPEG Group's JPEG
33 library to create the output file. See
34 __http://www.ijg.org__ for information on the
35 library.
36
37
38
39
40 EXIF is an image format that is a subformat of JFIF (to wit,
41 a JFIF file that contains an EXIF header as an APP1 marker).
42 __pnmtojpeg__ creates an EXIF image when you specify the
43 __-exif__ option.
44 !!OPTIONS
45
46
47 The basic options are:
48
49
50 __--exif=__''filespec''
51
52
53 This option specifies that the output image is to be EXIF (a
54 subformat of JFIF), i.e. it will have an EXIF header as a
55 JFIF APP1 marker. The contents of that marker are the
56 contents of the specified file. The special value __-__
57 means to read the EXIF header contents from standard input.
58 It is invalid to specify standard input for both the EXIF
59 header and the input image.
60
61
62 The EXIF file starts with a two byte field which is the
63 length of the file, including the length field, in pure
64 binary, most significant byte first. The special value of
65 zero for the length field means there is to be no EXIF
66 header, i.e. the same as no __-exif__ option. This is
67 useful for when you convert a file from JFIF to PNM using
68 __jpegtopnm__, then transform it, then convert it back to
69 JFIF with __pnmtojpeg__, and you don't know whether or
70 not it includes an EXIF header. __jpegtopnm__ creates an
71 EXIF file containing nothing but two bytes of zero when the
72 input JFIF file has no EXIF header. Thus, you can transfer
73 any EXIF header from the input JFIF to the output JFIF
74 without worrying about whether an EXIF header actually
75 exists.
76
77
78 The contents of the EXIF file after the length field are the
79 exact byte for byte contents of the APP1 marker, not
80 counting the length field, that constitutes the EXIF
81 header.
82
83
84 __--quality=__''n''
85
86
87 Scale quantization tables to adjust image quality. ''n''
88 is 0 (worst) to 100 (best); default is 75. (See below for
89 more info.)
90
91
92 __--grayscale__
93
94
95 __--greyscale__
96
97
98 Create gray scale JFIF file. With this option,
99 __pnmtojpeg__ converts color input to gray scale. If you
100 don't specify this option, The output file is in color
101 format if the input is PPM, and grayscale format if the
102 input is PBM or PGM.
103
104
105 In the PPM input case, even if all the colors in the image
106 are gray, the output is in color format. Of course, the
107 colors in it are still gray. The difference is that color
108 format takes up a lot more space and takes longer to create
109 and process.
110
111
112 __--optimize__
113
114
115 Perform optimization of entropy encoding parameters. Without
116 this, __pnmtojpeg__ uses default encoding parameters.
117 __--optimize__ usually makes the JFIF file a little
118 smaller, but __pnmtojpeg__ runs somewhat slower and needs
119 much more memory. Image quality and speed of decompression
120 are unaffected by __--optimize__.
121
122
123 __--progressive__
124
125
126 Create a progressive JPEG file (see below).
127
128
129 __--comment=__''text''
130
131
132 Include a comment marker in the JFIF output, with comment
133 text ''text''. Without this option, there are no comment
134 markers in the output.
135
136
137 The __--quality__ option lets you trade off compressed
138 file size against quality of the reconstructed image: the
139 higher the quality setting, the larger the JFIF file, and
140 the closer the output image will be to the original input.
141 Normally you want to use the lowest quality setting
142 (smallest file) that decompresses into something visually
143 indistinguishable from the original image. For this purpose
144 the quality setting should be between 50 and 95; the default
145 of 75 is often about right. If you see defects at
146 __--quality=75__, then go up 5 or 10 counts at a time
147 until you are happy with the output image. (The optimal
148 setting will vary from one image to another.)
149
150
151 __--quality=100__ generates a quantization table of all
152 1's, minimizing loss in the quantization step (but there is
153 still information loss in subsampling, as well as roundoff
154 error). This setting is mainly of interest for experimental
155 purposes. Quality values above about 95 are ''not''
156 recommended for normal use; the compressed file size goes up
157 dramatically for hardly any gain in output image
158 quality.
159
160
161 In the other direction, quality values below 50 will produce
162 very small files of low image quality. Settings around 5 to
163 10 might be useful in preparing an index of a large image
164 library, for example. Try __--quality=2__ (or so) for
165 some amusing Cubist effects. (Note: quality values below
166 about 25 generate 2-byte quantization tables, which are
167 considered optional in the JFIF standard. __pnmtojpeg__
168 emits a warning message when you give such a quality value,
169 because some other JFIF programs may be unable to decode the
170 resulting file. Use __--baseline__ if you need to ensure
171 compatibility at low quality values.)
172
173
174 The __--progressive__ option creates a
175 __Caution:__ progressive JPEG is not yet widely
176 implemented, so many decoders will be unable to view a
177 progressive JPEG file at all.
178
179
180 Options for advanced users:
181
182
183 __--dct=int__
184
185
186 Use integer DCT method (default).
187
188
189 __--dct=fast__
190
191
192 Use fast integer DCT (less accurate).
193
194
195 __--dct=float__
196
197
198 Use floating-point DCT method. The float method is very
199 slightly more accurate than the int method, but is much
200 slower unless your machine has very fast floating-point
201 hardware. Also note that results of the floating-point
202 method may vary slightly across machines, while the integer
203 methods should give the same results everywhere. The fast
204 integer method is much less accurate than the other
205 two.
206
207
208 __--restart=__''n''
209
210
211 Emit a JPEG restart marker every ''n'' MCU rows, or every
212 ''n'' MCU blocks if you append __B__ to the number.
213 __--restart 0__ (the default) means no restart
214 markers.
215
216
217 __--smooth=__''n''
218
219
220 Smooth the input image to eliminate dithering noise.
221 ''n'', ranging from 1 to 100, indicates the strength of
222 smoothing. 0 (the default) means no smoothing.
223
224
225 __--maxmemory=__''n''
226
227
228 Set a limit for amount of memory to use in processing large
229 images. Value is in thousands of bytes, or millions of bytes
230 if you append __M__ to the number. For example,
231 __--max=4m__ selects 4,000,000 bytes. If __pnmtojpeg__
232 needs more space, it will use temporary files.
233
234
235 __--verbose__
236
237
238 Print to the Standard Error file messages about the
239 conversion process. This can be helpful in debugging
240 problems.
241
242
243 The __--restart__ option tells __pnmtojpeg__ to insert
244 extra markers that allow a JPEG decoder to resynchronize
245 after a transmission error. Without restart markers, any
246 damage to a compressed file will usually ruin the image from
247 the point of the error to the end of the image; with restart
248 markers, the damage is usually confined to the portion of
249 the image up to the next restart marker. Of course, the
250 restart markers occupy extra space. We recommend
251 __--restart=1__ for images that will be transmitted
252 across unreliable networks such as Usenet.
253
254
255 The __--smooth__ option filters the input to eliminate
256 fine-scale noise. This is often useful when converting
257 dithered images to JFIF: a moderate smoothing factor of 10
258 to 50 gets rid of dithering patterns in the input file,
259 resulting in a smaller JFIF file and a better-looking image.
260 Too large a smoothing factor will visibly blur the image,
261 however.
262
263
264 Options for wizards:
265
266
267 __--baseline__
268
269
270 Force baseline-compatible quantization tables to be
271 generated. This clamps quantization values to 8 bits even at
272 low quality settings. (This switch is poorly named, since it
273 does not ensure that the output is actually baseline JPEG.
274 For example, you can use __--baseline__ and
275 __--progressive__ together.)
276
277
278 __--qtables=__''filespec''
279
280
281 Use the quantization tables given in the specified text
282 file.
283
284
285 __--qslots=n[[,...]__
286
287
288 Select which quantization table to use for each color
289 component.
290
291
292 __--sample=__''HxV[[,...]''
293
294
295 Set JPEG sampling factors for each color
296 component.
297
298
299 __--scans=__''filespec''
300
301
302 Use the scan script given in the specified text file. See
303 below for information on scan scripts.
304
305
306 The
307 don't use them__. These switches are documented
308 further in the file wizard.doc that comes with the
309 Independent JPEG Group's JPEG library.
310 !!EXAMPLES
311
312
313 This example compresses the PPM file foo.ppm with a quality
314 factor of 60 and saves the output as foo.jpg:
315
316
317 __pnmtojpeg --quality=60 foo.ppm
318 __
319
320
321 __cat foo.bmp | bmptoppm | pnmtojpeg
322 __
323 !!HINTS
324
325
326 JFIF is not ideal for cartoons, line drawings, and other
327 images that have only a few distinct colors. For those, try
328 instead __pnmtopng__ or __ppmtobmp__. If you need to
329 convert such an image to JFIF, though, you should experiment
330 with __pnmtojpeg__'s __--quality__ and __--smooth__
331 options to get a satisfactory conversion. __--smooth 10__
332 or so is often helpful.
333
334
335 JPEG compression is notable for being a
336
337
338 Because of this, you should do all the manipulation you have
339 to do on the image in some other format and convert to JFIF
340 as the last step. And if you can keep a copy in the original
341 format, so much the better. PNG is a good choice for a
342 format that is lossless, yet fairly compact. GIF is another
343 way to go, but chances are you can't create a GIF image
344 without owing a lot of money to Unisys and IBM, holders of
345 patents on the LZW compression used in the GIF
346 format.
347
348
349 The __--optimize__ option to __pnmtojpeg__ is worth
350 using when you are making a
351 __--optimize__ mode is
352 automatically in effect when you generate a progressive JPEG
353 file).
354
355
356 Another program, __cjpeg__, is similar. __cjpeg__ is
357 maintained by the Independent JPEG Group and packaged with
358 the JPEG library which __pnmtojpeg__ uses for all its
359 JPEG work. Because of that, you may expect it to exploit
360 more current JPEG features. Also, since you have to have the
361 library to run __pnmtojpeg__, but not vice versa,
362 __cjpeg__ may be more commonly available.
363
364
365 On the other hand, __cjpeg__ does not use the NetPBM
366 libraries to process its input, as all the NetPBM tools such
367 as __pnmtojpeg__ do. This means it is less likely to be
368 consistent with all the other programs that deal with the
369 NetPBM formats. Also, the command syntax of __pnmtojpeg__
370 is consistent with that of the other Netpbm tools, unlike
371 __cjpeg__.
372 !!SCAN SCRIPTS
373
374
375 Use the __-scan__ option to specify a scan script. Or use
376 the __-progressive__ option to specify a particular
377 built-in scan script.
378
379
380 Just what a scan script is, and the basic format of the scan
381 script file, is covered in the __wizard.doc__ file that
382 comes with the Independent JPEG Group's JPEG library. Scan
383 scripts are same for __pnmtojpeg__ as the are for
384 __cjpeg__.
385
386
387 This section contains additional information that isn't, but
388 probably should be, in that document.
389
390
391 First, there are many restrictions on what is a valid scan
392 script. The JPEG library, and thus __pnmtojpeg__, checks
393 thoroughly for any lack of compliance with these
394 restrictions, but does little to tell you how the script
395 fails to comply. The messages are very general and sometimes
396 untrue.
397
398
399 To start with, the entries for the DC coefficient must come
400 before any entries for the AC coefficients. The DC
401 coefficient is Coefficient 0; all the other coefficients are
402 AC coefficients. So in an entry for the DC coefficient, the
403 two numbers after the colon must be 0 and 0. In an entry for
404 AC coefficients, the first number after the colon must not
405 be 0.
406
407
408 In a DC entry, the color components must be in increasing
409 order. E.g.
410
411
412 In an entry for an AC coeffient, you must specify only one
413 color component. I.e. there can be only one number before
414 the colon.
415
416
417 In the first entry for a particular coefficient for a
418 particular color component, the
419
420
421 The script must ultimately specify at least some of the DC
422 coefficent for every color component. Otherwise, you get the
423 error message
424
425
426 There is a standard option in building the JPEG library to
427 omit scan script capability. If for some reason your library
428 was built with this option, you get the message
429 !!ENVIRONMENT
430
431
432 __JPEGMEM__
433
434
435 If this environment variable is set, its value is the
436 default memory limit. The value is specified as described
437 for the __--maxmemory__ option. An explicit
438 __--maxmemory__ option overrides any
439 __JPEGMEM__.
440 !!SEE ALSO
441
442
443 cjpeg(1), djpeg(1), jpegtran(1),
444 rdjpgcom(1), wrjpgcom(1)__
445 ppm__(5), pgm(5), jpegtopnm(1)
446 Wallace, Gregory K.
447 !!LIMITATIONS
448
449
450 Arithmetic coding is not supported for legal
451 reasons.
452
453
454 The program could be much faster.
455 !!AUTHOR
456
457
458 __pnmtojpeg__ and this man page were derived in large
459 part from __cjpeg__, by the Independent JPEG Group. The
460 program is otherwise by Bryan Henderson on March 07,
461 2000.
462 ----
This page is a man page (or other imported legacy content). We are unable to automatically determine the license status of this page.