pnmtojpeg [ options ] [ filename ]
pnmtojpeg converts the named PBM, PGM, or PPM image file, or the stan-
dard input if no file is named, to a JFIF file on the standard output.
pnmtojpeg uses the Independent JPEG Group's JPEG library to create the
output file. See http://www.ijg.org for information on the library.
"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.
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). pnmtojpeg cre-
ates an EXIF image when you specify the -exif option.
The basic options are:
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 - 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.
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 -exif option. This is useful for when you convert a file
from JFIF to PNM using jpegtopnm, then transform it, then con-
vert it back to JFIF with pnmtojpeg, and you don't know whether
or not it includes an EXIF header. jpegtopnm 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.
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.
Scale quantization tables to adjust image quality. n is 0
(worst) to 100 (best); default is 75. (See below for more
this, pnmtojpeg uses default encoding parameters. --optimize
usually makes the JFIF file a little smaller, but pnmtojpeg runs
somewhat slower and needs much more memory. Image quality and
speed of decompression are unaffected by --optimize.
Create a progressive JPEG file (see below).
Include a comment marker in the JFIF output, with comment text
text. Without this option, there are no comment markers in the
The --quality 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 indistin-
guishable from the original image. For this purpose the quality set-
ting should be between 50 and 95; the default of 75 is often about
right. If you see defects at --quality=75, then go up 5 or 10 counts
at a time until you are happy with the output image. (The optimal set-
ting will vary from one image to another.)
--quality=100 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 mainly of
interest for experimental purposes. Quality values above about 95 are
not recommended for normal use; the compressed file size goes up dra-
matically for hardly any gain in output image quality.
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 --qual-
ity=2 (or so) for some amusing Cubist effects. (Note: quality values
below about 25 generate 2-byte quantization tables, which are consid-
ered optional in the JFIF standard. pnmtojpeg 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 --baseline if you need
to ensure compatibility at low quality values.)
The --progressive 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. Caution: progressive JPEG is not yet widely
implemented, so many decoders will be unable to view a progressive JPEG
file at all.
Options for advanced users:
results everywhere. The fast integer method is much less accu-
rate than the other two.
Emit a JPEG restart marker every n MCU rows, or every n MCU
blocks if you append B to the number. --restart 0 (the default)
means no restart markers.
Smooth the input image to eliminate dithering noise. n, ranging
from 1 to 100, indicates the strength of smoothing. 0 (the
default) means no smoothing.
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 M to the number. For example, --max=4m selects
4,000,000 bytes. If pnmtojpeg needs more space, it will use
Print to the Standard Error file messages about the conversion
process. This can be helpful in debugging problems.
The --restart option tells pnmtojpeg 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 --restart=1 for images that will be trans-
mitted across unreliable networks such as Usenet.
The --smooth option filters the input to eliminate fine-scale noise.
This is often useful when converting dithered images to JFIF: a moder-
ate 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, how-
Options for wizards:
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 --baseline and --progressive together.)
Use the quantization tables given in the specified text file.
Select which quantization table to use for each color component.
This example compresses the PPM file foo.ppm with a quality factor of
60 and saves the output as foo.jpg:
pnmtojpeg --quality=60 foo.ppm > foo.jpg
cat foo.bmp | bmptoppm | pnmtojpeg > foo.jpg
JFIF is not ideal for cartoons, line drawings, and other images that
have only a few distinct colors. For those, try instead pnmtopng or
ppmtobmp. If you need to convert such an image to JFIF, though, you
should experiment with pnmtojpeg's --quality and --smooth options to
get a satisfactory conversion. --smooth 10 or so is often helpful.
JPEG compression is notable for being a "lossy." This means that,
unlike with most graphics conversions, you lose information, which
means image quality, when you convert to JFIF. If you convert from PPM
to JFIF and back repeatedly, image quality loss will accumulate. After
ten or so cycles the image may be noticeably worse than it was after
Because of this, 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.
PNG is a good choice for a format that is lossless, yet fairly compact.
GIF is another way to go, but chances are you can't create a GIF image
without owing a lot of money to Unisys and IBM, holders of patents on
the LZW compression used in the GIF format.
The --optimize option to pnmtojpeg 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 percent-
age improvement is often a lot more than it is on larger files. (At
present, --optimize mode is automatically in effect when you generate a
progressive JPEG file).
Another program, cjpeg, is similar. cjpeg is maintained by the Inde-
pendent JPEG Group and packaged with the JPEG library which pnmtojpeg
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 pnmtojpeg, but not vice versa, cjpeg may be more com-
On the other hand, cjpeg does not use the NetPBM libraries to process
its input, as all the NetPBM tools such as pnmtojpeg 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 pnmtojpeg is con-
sistent with that of the other Netpbm tools, unlike cjpeg.
Use the -scan option to specify a scan script. Or use the -progressive
option to specify a particular built-in scan script.
script fails to comply. The messages are very general and sometimes
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
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".
In an entry for an AC coeffient, you must specify only one color compo-
nent. I.e. there can be only one number before the colon.
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.
The script must ultimately specify at least some of the DC coefficent
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.
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
If this environment variable is set, its value is the default
memory limit. The value is specified as described for the
--maxmemory option. An explicit --maxmemory option overrides
cjpeg(1), djpeg(1), jpegtran(1), rdjpgcom(1), wrjpgcom(1)
ppm(5), pgm(5), jpegtopnm(1)
Wallace, Gregory K. "The JPEG Still Picture Compression Standard",
Communications of the ACM, April 1991 (vol. 34, no. 4), pp. 30-44.
Arithmetic coding is not supported for legal reasons.
The program could be much faster.
pnmtojpeg and this man page were derived in large part from cjpeg, by
the Independent JPEG Group. The program is otherwise by Bryan Hender-
son on March 07, 2000.
Man Pages Copyright Respective Owners. Site Copyright (C) 1994 - 2019
All Rights Reserved.