Ubuntu Manpage: tifftopnm - convert a TIFF file into a portable anymap

NAME

       tifftopnm - convert a TIFF file into a portable anymap

SYNOPSIS

       tifftopnm [-alphaout={alpha-filename,-}] [-headerdump] [-respectfillorder] [tiff-filename]

       You  may  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 space.

DESCRIPTION

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.

This program 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 itself.

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.

The 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.

OPTIONS

       -alphaout=alpha-filename
              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.

              See pnmcomp(1) for one way to use the alpha output file.

       -respectfillorder
              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.

       -headerdump
              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.

NOTES

Fillorder
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.

However, there 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 bytes.

These people 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.

Examples of incorrect TIFF images are at ftp://weather.noaa.gov. They are apparently created by a
program called faxtotiff.

This note was written on January 1, 2002.

AUTHOR