1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.3//EN">
<html><head><title>Pnmtojpeg User Manual</title></head>
<body>
<h1>pnmtojpeg</h1>
Updated: 23 April 2007
<br>
<a href="#index">Table Of Contents</a>
<h2>NAME</h2>
pnmtojpeg - convert PNM image to a JFIF ("JPEG") image
<h2 id="synopsis">SYNOPSIS</h2>
<b>pnmtojpeg</b>
[<b>-exif=</b><i>filespec</i>]
[<b>-quality=</b><i>n</i>]
[{<b>-grayscale</b>|<b>-greyscale</b>}]
[<b>-density=</b><i>n</i><b>x</b><i>n</i>[<b>dpi</b>,<b>dpcm</b>]]
[<b>-optimize</b>|<b>-optimise</b>]
[<b>-rgb</b>]
[<b>-progressive</b>]
[<b>-comment=</b><i>text</i>]
[<b>-dct=</b>{<b>int</b>|<b>fast</b>|<b>float</b>}]
[<b>-arithmetic</b>]
[<b>-restart=</b><i>n</i>]
[<b>-smooth=</b><i>n</i>]
[<b>-maxmemory=</b><i>n</i>]
[<b>-verbose</b>]
[<b>-baseline</b>]
[<b>-qtables=</b><i>filespec</i>]
[<b>-qslots=n[,...]</b>]
[<b>-sample=</b><i>H</i><b>x</b><i>V</i>[,...]]
[<b>-scans=</b><i>filespec</i>]
[<b>-tracelevel=</b><i>N</i>]
<i>filename</i>
<p>Minimum unique abbreviation of option is acceptable. You may use double
hyphens instead of single hyphen to denote options. You may use white
space in place of the equals sign to separate an option name from its value.
<h2 id="description">DESCRIPTION</h2>
<p>This program is part of <a href="index.html">Netpbm</a>.
<p><b>pnmtojpeg</b> converts the named PBM, PGM, or PPM image file, or
the standard input if no file is named, to a JFIF file on the standard
output.
<p><b>pnmtojpeg</b> uses the Independent JPEG Group's JPEG library to
create the output file. See <b><a
href="http://www.ijg.org">http://www.ijg.org</a> </b> for information
on the library.
<p>"JFIF" is the correct name for the image format commonly
known as "JPEG." Strictly speaking, JPEG is a method of
compression. The image format using JPEG compression that is by far
the most common is JFIF. There is also a subformat of TIFF that uses
JPEG compression.
<p>EXIF is an image format that is a subformat of JFIF (to wit, a JFIF
file that contains an EXIF header as an APP1 marker).
<b>pnmtojpeg</b> creates an EXIF image when you specify the
<b>-exif</b> option.
<h2 id="options">OPTIONS</h2>
<p>In addition to the options common to all programs based on libnetpbm
(most notably <b>-quiet</b>, see <a href="index.html#commonoptions">
Common Options</a>), <b>pnmtojpeg</b> recognizes the following
command line options:
<h3 id="basicopts">Basic Options</h3>
<dl compact>
<dt><b>-exif=</b><i>filespec</i>
<dd>
This option specifies that the output image is to be EXIF (a subformat
of JFIF), i.e. it will have an EXIF header as a JFIF APP1 marker.
The contents of that marker are the contents of the specified file.
The special value <b>-</b>
means to read the EXIF header contents from standard input. It is
invalid to specify standard input for both the EXIF header and the
input image.
<p>
The EXIF file starts with a two byte field which is the length of
the file, including the length field, in pure binary, most significant
byte first. The special value of zero for the length field means there
is to be no EXIF header, i.e. the same as no <b>-exif</b>
option. This is useful for when you convert a file from JFIF to PNM
using <b>jpegtopnm</b>,
then transform it, then convert it back to JFIF with
<b>pnmtojpeg</b>, and you don't know whether or not it includes an EXIF header.
<b>jpegtopnm</b>
creates an EXIF file containing nothing but two bytes of zero when
the input JFIF file has no EXIF header. Thus, you can transfer
any EXIF header from the input JFIF to the output JFIF without
worrying about whether an EXIF header actually exists.
<p>
The contents of the EXIF file after the length field are the exact
byte for byte contents of the APP1 marker, not counting the length
field, that constitutes the EXIF header.
<dt><b>-quality=</b><i>n</i>
<dd>Scale quantization tables to adjust image quality. <i>n</i> is 0
(worst) to 100 (best); default is 75. Below about 25 can produce images
some interpreters won't be able to interpret. See below for more info.
<dt><b>-grayscale</b>
<dt><b>-greyscale</b>
<dt><b>-rgb</b>
<dd>These options determine the color space used in the JFIF output.
<b>-grayscale</b> (or <b>-greyscale</b>) means to create a gray scale
JFIF, converting from color PPM input if necessary. <b>-rgb</b> means to
create an RGB JFIF, and the program fails if the input is not PPM.
<p>If you specify neither, The output file is in YCbCr format if the
input is PPM, and grayscale format if the input is PBM or PGM.
<p>YCbCr format (a color is represented by an intensity value and two
chrominance values) usually compresses much better than RGB (a color
is represented by one red, one green, and one blue value). RGB is
rare. But you may be able to convert between JFIF and PPM faster with
RGB, since it's the same color space PPM uses.
<p>The <b>testimg.ppm</b> file that comes with Netpbm is 2.3 times
larger with the <b>-rgb</b> option than with the YCbCr default, and in
one experiment <b>pnmtojpeg</b> took 16% more CPU time to convert it.
The extra CPU time probably indicates that processing of all the extra
compressed data consumed all the CPU time saved by not having to
convert the RGB inputs to YCbCr.
<p>Grayscale format takes up a lot less space and takes less time to create
and process than the color formats, even if the image contains nothing
but black, white, and gray.
<p>The <b>-rgb</b> option was added in Netpbm 10.11 in October 2002.
<dt><b>-density=</b><i>density</i>
<dd>This option determines the density (aka resolution) information
recorded in the JFIF output image. It does not affect the raster in
any way; it just tells whoever reads the JFIF how to interpret the
raster.
<p>The density value takes the form <i>x</i><b>x</b><i>y</i> followed
by an optional unit specifier of <b>dpi</b> or <b>dpcm</b>. Examples:
<b>1x1</b>, <b>3x2</b>, <b>300x300dpi</b>, <b>100x200dpcm</b>. The
first number is the horizontal density; the 2nd number is the vertical
density. Each may be any integer from 1 to 65535. The unit specifier
is <b>dpi</b> for dots per inch or <b>dpcm</b> for dots per
centimeter. If you don't specify the units, the density information
goes into the JFIF explicitly stating "density unspecified" (also
interpreted as "unknown"). This may seem pointless, but note that
even without specifying the units, the density numbers tell the aspect
ratio of the pixels. E.g. <b>1x1</b> tells you the pixels are square.
<b>3x2</b> tells you the pixels are vertical rectangles.
<p>Note that if you specify different horizontal and vertical
densities, the resulting JFIF image is <em>not</em> a true
representation of the input PNM image, because <b>pnmtojpeg</b>
converts the raster pixel-for-pixel and the pixels of a PNM image are
defined to be square. Thus, if you start with a square PNM image and
specify <b>-density=3x2</b>, the resulting JFIF image is a horizontally
squashed version of the original. However, it is common to use an
input image which is a slight variation on PNM rather than true PNM
such that the pixels are not square. In that case, the appropriate
-density option yields a faithful reproduction of the input pseudo-PNM
image.
<p>The default is 1x1 in unspecified units.
<p>Before Netpbm 10.15 (April 2003), this option did not exist and the
<b>pnmtojpeg</b> always created a JFIF with a density of 1x1 in
unspecified units.
<dt><b>-optimize</b>
<dd> Perform optimization of entropy encoding parameters. Without
this, <b>pnmtojpeg</b> uses default encoding parameters.
<b>-optimize</b> usually makes the JFIF file a little smaller, but
<b>pnmtojpeg</b> runs somewhat slower and needs much more memory.
Image quality and speed of decompression are unaffected by
<b>-optimize</b>.
<dt><b>-progressive</b>
<dd>
Create a progressive JPEG file (see below).
<dt><b>-comment=</b><i>text</i>
<dd>
Include a comment marker in the JFIF output, with comment text
<i>text</i>.
Without this option, there are no comment markers in the output.
</dl>
<p>The <b>-quality</b> option lets you trade off compressed file size
against quality of the reconstructed image: the higher the quality
setting, the larger the JFIF file, and the closer the output image
will be to the original input. Normally you want to use the lowest
quality setting (smallest file) that decompresses into something
visually indistinguishable from the original image. For this purpose
the quality setting should be between 50 and 95 for reasonable
results; the default of 75 is often about right. If you see defects
at <b>-quality=75</b>, then go up 5 or 10 counts at a time until you
are happy with the output image. (The optimal setting will vary from
one image to another.)
<p><b>-quality=100</b> generates a quantization table of all 1's,
minimizing loss in the quantization step (but there is still
information loss in subsampling, as well as roundoff error). This
setting is of interest mainly for experimental purposes. Quality
values above about 95 are <em>not</em> recommended for normal use; the
compressed file size goes up dramatically for hardly any gain in
output image quality.
<p>In the other direction, quality values below 50 will produce very
small files of low image quality. Settings around 5 to 10 might be
useful in preparing an index of a large image library, for example.
Try <b>-quality=2</b> (or so) for some amusing Cubist effects. (Note:
quality values below about 25 generate 2-byte quantization tables,
which are considered optional in the JFIF standard. <b>pnmtojpeg</b>
emits a warning message when you give such a quality value, because
some other JFIF programs may be unable to decode the resulting file.
Use <b>-baseline</b> if you need to ensure compatibility at low
quality values.)
<p>The <b>-progressive</b> option creates a "progressive
JPEG" file. In this type of JFIF file, the data is stored in
multiple scans of increasing quality. If the file is being
transmitted over a slow communications link, the decoder can use the
first scan to display a low-quality image very quickly, and can then
improve the display with each subsequent scan. The final image is
exactly equivalent to a standard JFIF file of the same quality
setting, and the total file size is about the same -- often a little
smaller.
<p><strong>Caution:</strong> progressive JPEG is not yet widely
implemented, so many decoders will be unable to view a progressive
JPEG file at all.
<p>If you're trying to control the quality/file size tradeoff, you
might consider the JPEG2000 format instead. See <a
href="pamtojpeg2k.html">pamtojpeg2k</a>.
<h3 id="advancedopts">Advanced options</h3>
<dl compact>
<dt><b>-dct=int</b>
<dd>Use integer DCT method (default).
<dt><b>-dct=fast</b>
<dd>Use fast integer DCT (less accurate).
<dt><b>-dct=float</b>
<dd>Use floating-point DCT method. The float method is very slightly
more accurate than the int method, but is much slower unless your
machine has very fast floating-point hardware. Also note that results
of the floating-point method may vary slightly across machines, while
the integer methods should give the same results everywhere. The fast
integer method is much less accurate than the other two.
<dt><b>-arithmetic</b>
<dd>Use arithmetic coding. Default is Huffman encoding. Arithmetic coding
tends to get you a smaller result.
<p>You may need patent licenses to use this option. According to
<a href="http://www.faqs.org/faqs/jpeg-faq">the JPEG FAQ</a>,
This method is covered by patents owned by IBM, AT&T, and Mitsubishi.
<p>The author of the FAQ recommends against using arithmetic coding (and
therefore this option) because the space savings is not great enough to
justify the legal hassles.
<p>Most JPEG libraries, including any distributed by the Independent
JPEG Group since about 1998 are not capable of arithmetic encoding.
<b>pnmtojpeg</b> uses a JPEG library (either bound to it when the
<b>pnmtojpeg</b> executable was built or accessed on your system at
run time) to do the JPEG encoding. If <b>pnmtojpeg</b> terminates
with the message, "Sorry, there are legal restrictions on
arithmetic coding" or "Sorry, arithmetic coding not
supported," this is the problem.
<dt><b>-restart=</b><i>n</i>
<dd>
Emit a JPEG restart marker every <i>n</i> MCU rows, or every <i>n</i>
MCU blocks if you append <b>B</b> to the number. <b>-restart 0</b>
(the default) means no restart markers.
<dt><b>-smooth=</b><i>n</i>
<dd>
Smooth the input image to eliminate dithering noise. <i>n</i>,
ranging from 1 to 100, indicates the strength of smoothing. 0 (the
default) means no smoothing.
<dt><b>-maxmemory=</b><i>n</i>
<dd>
Set a limit for amount of memory to use in processing large images. Value is
in thousands of bytes, or millions of bytes if you append
<b>M</b> to the number. For example, <b>-max=4m</b>
selects 4,000,000 bytes. If <b>pnmtojpeg</b>
needs more space, it will use temporary files.
<dt><b>-verbose</b>
<dd>
Print to the Standard Error file messages about the conversion process.
This can be helpful in debugging problems.
</dl>
<p>The <b>-restart</b> option tells <b>pnmtojpeg </b> to insert extra
markers that allow a JPEG decoder to resynchronize after a
transmission error. Without restart markers, any damage to a
compressed file will usually ruin the image from the point of the
error to the end of the image; with restart markers, the damage is
usually confined to the portion of the image up to the next restart
marker. Of course, the restart markers occupy extra space. We
recommend <b>-restart=1</b> for images that will be transmitted
across unreliable networks such as Usenet.
<p>The <b>-smooth</b> option filters the input to eliminate
fine-scale noise. This is often useful when converting dithered
images to JFIF: a moderate smoothing factor of 10 to 50 gets rid of
dithering patterns in the input file, resulting in a smaller JFIF file
and a better-looking image. Too large a smoothing factor will visibly
blur the image, however.
<h3 id="wizardopts">Wizard Options</h3>
<dl compact>
<dt><b>-baseline</b>
<dd>Force baseline-compatible quantization tables to be generated.
This clamps quantization values to 8 bits even at low quality
settings. (This switch is poorly named, since it does not ensure that
the output is actually baseline JPEG. For example, you can use
<b>-baseline</b> and <b>-progressive</b> together.)
<dt><b>-qtables=</b><i>filespec</i>
<dd>Use the quantization tables given in the specified text file.
<dt><b>-qslots=n[,...]</b>
<dd>Select which quantization table to use for each color component.
<dt><b>-sample=</b><i>H</i><b>x</b><i>V</i>[,...]
<dd>Set JPEG sampling factors for each color component.
<dt><b>-scans=</b><i>filespec</i>
<dd>Use the scan script given in the specified text file. See below
for information on scan scripts.
<dt><b>-tracelevel=</b><i>N</i>
<dd>This sets the level of debug tracing the program outputs as it runs.
0 means none, and is the default. This level primarily controls tracing
of the JPEG library, and you can get some pretty interesting information
about the compression process.
</dl>
<p>The "wizard" options are intended for experimentation
with JPEG. If you don't know what you are doing, <strong>don't use
them</strong>. These switches are documented further in the file
wizard.doc that comes with the Independent JPEG Group's JPEG library.
<h2 id="examples">EXAMPLES</h2>
<p>This example compresses the PPM file foo.ppm with a quality factor
of 60 and saves the output as foo.jpg:
<pre>
<b>pnmtojpeg -quality=60 foo.ppm > foo.jpg</b>
</pre>
<p>Here's a more typical example. It converts from BMP to JFIF:
<pre>
<b>cat foo.bmp | bmptoppm | pnmtojpeg > foo.jpg</b>
</pre>
<h2 id="loss">JPEG LOSS</h2>
<p>When you compress with JPEG, you lose information -- i.e. the resulting
image has somewhat lower quality than the original. This is a characteristic
of JPEG itself, not any particular program. So if you do the usual
Netpbm thing and convert from JFIF to PNM, manipulate, then convert back
to JFIF, you will lose quality. The more you do it, the more you lose.
Drawings (charts, cartoons, line drawings, and such with few colors
and sharp edges) suffer the most.
<p>To avoid this, you can use a compressed image format other than
JPEG. PNG and JPEG2000 are good choices, and Netpbm contains converters
for those.
<p>If you need to use JFIF on a drawing, you should experiment with
<b>pnmtojpeg</b>'s <b>-quality</b> and <b>-smooth</b> options to get a
satisfactory conversion. <b>-smooth 10</b> or so is often helpful.
<p>Because of the loss, you should do all the manipulation you have to
do on the image in some other format and convert to JFIF as the last
step. And if you can keep a copy in the original format, so much the
better.
The <b>-optimize</b> option to <b>pnmtojpeg</b> is worth using when
you are making a "final" version for posting or archiving.
It's also a win when you are using low quality settings to make very
small JFIF files; the percentage improvement is often a lot more than
it is on larger files. (At present, <b>-optimize</b> mode is
automatically in effect when you generate a progressive JPEG file).
<p>You can do flipping and rotating transformations losslessly with
the program <b>jpegtran</b>, which is packaged with the Independent
Jpeg Group's JPEG library. <b>jpegtran</b> exercises its intimate
knowledge of the way JPEG works to do the transformation without ever
actually decompressing the image.
<h2 id="otherprog">OTHER PROGRAMS</h2>
<p>Another program, <b>cjpeg</b>, is similar. <b>cjpeg</b> is
maintained by the Independent JPEG Group and packaged with the JPEG
library which <b>pnmtojpeg</b> uses for all its JPEG work. Because of
that, you may expect it to exploit more current JPEG features. Also,
since you have to have the library to run <b>pnmtojpeg</b>, but not
vice versa, <b>cjpeg</b> may be more commonly available.
<p>On the other hand, <b>cjpeg</b> does not use the NetPBM libraries
to process its input, as all the NetPBM tools such as <b>pnmtojpeg</b>
do. This means it is less likely to be consistent with all the other
programs that deal with the NetPBM formats. Also, the command syntax
of <b>pnmtojpeg</b> is consistent with that of the other Netpbm tools,
unlike <b>cjpeg</b>.
<h2 id="scanscripts">SCAN SCRIPTS</h2>
<p>Use the <b>-scan</b> option to specify a scan script. Or use the
<b>-progressive</b> option to specify a particular built-in scan
script.
<p>Just what a scan script is, and the basic format of the scan script
file, is covered in the <b>wizard.doc</b> file that comes with the
Independent JPEG Group's JPEG library. Scan scripts are same for
<b>pnmtojpeg</b> as the are for <b>cjpeg</b>.
<p>This section contains additional information that isn't, but
probably should be, in that document.
<p>First, there are many restrictions on what is a valid scan script.
The JPEG library, and thus <b>pnmtojpeg</b>, checks thoroughly for any
lack of compliance with these restrictions, but does little to tell
you how the script fails to comply. The messages are very general and
sometimes untrue.
<p>
To start with, the entries for the DC coefficient must come before any
entries for the AC coefficients. The DC coefficient is Coefficient 0;
all the other coefficients are AC coefficients. So in an entry for
the DC coefficient, the two numbers after the colon must be 0 and 0.
In an entry for AC coefficients, the first number after the colon must
not be 0.
<p>
In a DC entry, the color components must be in increasing order.
E.g. "0,2,1" before the colon is wrong. So is "0,0,0".
<p>
In an entry for an AC coefficient, you must specify only one color
component. I.e. there can be only one number before the colon.
<p>
In the first entry for a particular coefficient for a particular color
component, the "Ah" value must be zero, but the Al value can be any
valid bit number. In subsequent entries, Ah must be the Al value from
the previous entry (for that coefficient for that color component),
and the Al value must be one less than the Ah value.
<p>
The script must ultimately specify at least some of the DC coefficient
for every color component. Otherwise, you get the error message
"Script does not transmit all the data." You need not specify all of
the bits of the DC coefficient, or any of the AC coefficients.
<p>
There is a standard option in building the JPEG library to omit scan
script capability. If for some reason your library was built with
this option, you get the message "Requested feature was omitted at
compile time."
<h2 id="environment">ENVIRONMENT</h2>
<dl compact>
<dt><b>JPEGMEM</b>
<dd>If this environment variable is set, its value is the default
memory limit. The value is specified as described for the
<b>-maxmemory</b> option. An explicit <b>-maxmemory </b> option
overrides any <b>JPEGMEM</b>.
</dl>
<h2 id="seealso">SEE ALSO</h2>
<b><a href="jpegtopnm.html">jpegtopnm</a></b>,
<b><a href="pnm.html">pnm</a></b>,
<b>cjpeg</b> man page,
<b>djpeg</b> man page,
<b>jpegtran</b> man page,
<b>rdjpgcom</b> man page,
<b>wrjpgcom</b> man page
<p>Wallace, Gregory K. "The JPEG Still Picture Compression
Standard", Communications of the ACM, April 1991 (vol. 34,
no. 4), pp. 30-44.
<h2 id="author">AUTHOR</h2>
<b>pnmtojpeg</b> and this manual were derived in large part from
<b>cjpeg</b>, by the Independent JPEG Group. The program is otherwise
by Bryan Henderson on March 07, 2000.
<hr>
<h2 id="index">Table Of Contents</h2>
<ul>
<li><a href="#synopsis">SYNOPSIS</a>
<li><a href="#description">DESCRIPTION</a>
<li><a href="#options">OPTIONS</a>
<ul>
<li><a href="#basicopts">Basic Options</a>
<li><a href="#advancedopts">Advanced options</a>
<li><a href="#wizardopts">Wizard Options</a>
</ul>
<li><a href="#examples">EXAMPLES</a>
<li><a href="#loss">JPEG LOSS</a>
<li><a href="#otherprog">OTHER PROGRAMS</a>
<li><a href="#scanscripts">SCAN SCRIPTS</a>
<li><a href="#environment">ENVIRONMENT</a>
<li><a href="#seealso">SEE ALSO</a>
<li><a href="#author">AUTHOR</a>
</ul>
</body>
</html>
|
