version 1 showing authors affecting page license.
.
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 |
---- |