− convert a TIFF file into a portable anymap
abbreviate any option to its shortest unique prefix. You may
use two hyphens instead of one in options. You may separate
an option and its value either by an equals sign or white
Reads a TIFF
file as input. Produces a portable anymap as output. The
type of the output file depends on the input file - if
it’s black & white, generates a pbm file;
if it’s grayscale, generates a pgm file;
otherwise, a ppm file. The program tells you which
type it is writing.
cannot read every possible TIFF file -- there are myriad
variations of the TIFF format. However, it does understand
monochrome and gray scale, RGB, RGBA (red/green/blue with
alpha channel), CMYK (Cyan-Magenta-Yellow-Black ink color
separation), and color palette TIFF files. An RGB file can
have either single plane (interleaved) color or multiple
plane format. The program reads 1-8 and 16 bit-per-sample
input, the latter in either bigendian or littlendian
encoding. Tiff directory information may also be either
bigendian or littendian.
One reason this
program isn’t as general as TIFF programs often are is
that it does not use the TIFFRGBAImageGet() function of the
TIFF library to read TIFF files. Rather, it uses the more
primitive TIFFReadScanLine() function and decodes it
There is no
fundamental reason that this program could not read other
kinds of TIFF files; the existing limitations are mainly
because no one has asked for more.
The PNM output
has the same maxval as the Tiff input, except that if the
Tiff input is colormapped (which implies a maxval of 65535)
the PNM output has a maxval of 255. Though this may result
in lost information, such input images hardly ever actually
have more color resolution than a maxval of 255 provides and
people often cannot deal with PNM files that have maxval
> 255. By contrast, a non-colormapped Tiff image that
doesn’t need a maxval > 255 doesn’t
have a maxval > 255, so when we see a
non-colormapped maxval > 255, we take it seriously and
produce a matching output maxval.
tiff-filename argument names the regular file that
contains the Tiff image. If you specify "-" or
don’t specify this argument, tfftopnm uses
Standard Input. In either case, the file must be seekable.
That means no pipe, but any regular file is fine.
tifftopnm creates a PGM
(portable graymap) file containing the alpha channel values
in the input image. If the input image doesn’t contain
an alpha channel, the alpha-filename file contains
all zero (transparent) alpha values. If you don’t
specify -alphaout, tifftopnm does not generate
an alpha file, and if the input image has an alpha channel,
tifftopnm simply discards it.
If you specify
- as the filename, tifftopnm writes the alpha
output to Standard Output and discards the image.
pnmcomp(1) for one way to use the alpha output
By default, tifftopnm
ignores the "fillorder" tag in the TIFF input,
which means it may incorrectly interpret the image. To make
it follow the spec, use this option. For a lengthy but
engaging discussion of why tifftopnm works this way
and how to use the -respectfillorder option, see the
note on fillorder below.
Dump TIFF file information to
stderr. This information may be useful in debugging TIFF
file conversion problems.
All options can
be abbreviated to their shortest unique prefix.
There is a piece of information in the header of a TIFF
image called "fillorder." The TIFF specification
quite clearly states that this value tells the order in
which bits are arranged in a byte in the description of the
image’s pixels. There are two options, assuming that
the image has a format where more than one pixel can be
represented by a single byte: 1) the byte is filled from
most signficant bit to least signficant bit going left to
right in the image; and 2) the opposite.
is confusion in the world as to the meaning of fillorder.
Evidence shows that some people believe it has to do with
byte order when a single value is represented by two
cause TIFF images to be created that, while they use a
MSB-to-LSB fillorder, have a fillorder tag that says they
used LSB-to-MSB. A program that properly interprets a TIFF
image will not end up with the image that the author
intended in this case.
For a long
time, tifftopnm did not understand fillorder itself
and assumed the fillorder was MSB-to-LSB regardless of the
fillorder tag in the TIFF header. And as far as I know,
there is no legitimate reason to use a fillorder other than
MSB-to-LSB. So users of tifftopnm were happily using
those TIFF images that had incorrect fillorder tags.
So that those
users can continue to be happy, tifftopnm today
continues to ignore the fillorder tag unless you tell it not
to. (It does, however, warn you when the fillorder tag does
not say MSB-to-LSB that the tag is being ignored).
If for some
reason you have a TIFF image that actually has LSB-to-MSB
fillorder, and its fillorder tag correctly indicates that,
you must use the -respectfillorder option on
tifftopnm to get proper results.
incorrect TIFF images are at ftp://weather.noaa.gov. They
are apparently created by a program called
This note was
written on January 1, 2002.
Derived by Jef
Poskanzer from tif2ras.c, which is Copyright (c) 1990 by Sun
Microsystems, Inc. Author: Patrick J. Naughton