tifftopnm(1)						      General Commands Manual						      tifftopnm(1)

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 writ-
       ing.

       This program cannot read every possible TIFF file -- there are myriad variations of the TIFF format.  However,  it  does  understand  mono-
       chrome and gray scale, RGB, RGBA (red/green/blue with alpha channel), CMYK (Cyan-Magenta-Yellow-Black ink color separation), and color pal-
       ette 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 lit-
       tendian.

       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 resolu-
       tion 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.

SEE ALSO

       pnmtotiff(1), pnmtotiffcmyk(1), pnmcomp(1), pnm(5)

AUTHOR

       Derived by Jef  Poskanzer  from	tif2ras.c,  which  is  Copyright  (c)  1990  by  Sun  Microsystems,  Inc.   Author:  Patrick  J.  Naughton
       (naughton@wind.sun.com).

								   02 April 2000						      tifftopnm(1)