In addition to the options common to all programs based on libnetpbm (most notably -quiet, see Common
Options ), pnmtojpeg recognizes the following command line options:
BasicOptions-exif=filespec
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 convert 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.
-quality=n
Scale quantization tables to adjust image quality. n 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.
-grayscale-greyscale-rgb These options determine the color space used in the JFIF output. -grayscale (or -greyscale) means
to create a gray scale JFIF, converting from color PPM input if necessary. -rgb means to create
an RGB JFIF, and the program fails if the input is not PPM.
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.
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.
The testimg.ppm file that comes with Netpbm is 2.3 times larger with the -rgb option than with the
YCbCr default, and in one experiment pnmtojpeg 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.
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.
The -rgb option was added in Netpbm 10.11 in October 2002.
-density=density
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.
The density value takes the form xxy followed by an optional unit specifier of dpi or dpcm.
Examples: 1x1, 3x2, 300x300dpi, 100x200dpcm. 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
dpi for dots per inch or dpcm 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. 1x1 tells you the pixels are square.
3x2 tells you the pixels are vertical rectangles.
Note that if you specify different horizontal and vertical densities, the resulting JFIF image is
not a true representation of the input PNM image, because pnmtojpeg 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 -density=3x2, 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.
The default is 1x1 in unspecified units.
Before Netpbm 10.15 (April 2003), this option did not exist and the pnmtojpeg always created a
JFIF with a density of 1x1 in unspecified units.
-optimize
Perform optimization of entropy encoding parameters. Without 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.
-progressive
Create a progressive JPEG file (see below).
-comment=text
Include a comment marker in the JFIF output, with comment text text.
Without this option, there are no comment markers in the output.
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 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 -quality=75, 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.)
-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 of interest
mainly for experimental purposes. Quality values above about 95 are not recommended for normal use; the
compressed file size goes up dramatically 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
-quality=2 (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. 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.
If you're trying to control the quality/file size tradeoff, you might consider the JPEG2000 format
instead. See pamtojpeg2k(1).
Advancedoptions-dct=int
Use integer DCT method (default).
-dct=fast
Use fast integer DCT (less accurate).
-dct=float
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.
-arithmetic
Use arithmetic coding. Default is Huffman encoding. Arithmetic coding tends to get you a smaller
result.
You may need patent licenses to use this option. According to the JPEG FAQ , This method is
covered by patents owned by IBM, AT&T, and Mitsubishi.
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.
Most JPEG libraries, including any distributed by the Independent JPEG Group since about 1998 are
not capable of arithmetic encoding. pnmtojpeg uses a JPEG library (either bound to it when the
pnmtojpeg executable was built or accessed on your system at run time) to do the JPEG encoding.
If pnmtojpeg terminates with the message, "Sorry, there are legal restrictions on arithmetic
coding" or "Sorry, arithmetic coding not supported," this is the problem.
-restart=n
Emit a JPEG restart marker every n MCU rows, or every n MCU blocks if you append B to the number.
-restart0 (the default) means no restart markers.
-smooth=n
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.
-maxmemory=n
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 temporary files.
-verbose
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 transmitted 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 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.
WizardOptions-baseline
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.)
-qtables=filespec
Use the quantization tables given in the specified text file.
-qslots=n[,...]
Select which quantization table to use for each color component.
-sample=HxV[,...]
Set JPEG sampling factors for each color component.
-scans=filespec
Use the scan script given in the specified text file. See below for information on scan scripts.
-tracelevel=N
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.
The "wizard" options are intended for experimentation with JPEG. If you don't know what you are doing,
don'tusethem. These switches are documented further in the file wizard.doc that comes with the
Independent JPEG Group's JPEG library.
Install Now
PNG Icons
