tifftopnm man page on Scientific

Man page or keyword search:  
man Server   26626 pages
apropos Keyword Search (all sections)
Output format
Scientific logo
[printable version]

Tifftopnm User Manual(0)			      Tifftopnm User Manual(0)

NAME
       tifftopnm - convert a TIFF file into a PNM image

SYNOPSIS
       tifftopnm

       [-alphaout={alpha-filename,-}]  [-headerdump]  [-verbose] [-respectfil‐
       lorder] [-byrow] [-orientraw] [tiff-filename]

DESCRIPTION
       This program is part of Netpbm(1).

       tifftopnm reads a TIFF file as input and produces a PNM image  as  out‐
       put.   The  type of the output file depends on the input file - if it's
       black & white, generates a PBM image; if it's  grayscale,  generates  a
       PGM image; otherwise, a PPM image.  The program tells you which type it
       is writing.

       If the TIFF file contains multiple  images  (multiple  'directories,'),
       tifftopnm  generates  a	multi-image  PNM output stream.	 Before Netpbm
       10.27 (March 2005), however, it would just ignore  all  but  the	 first
       input image.

       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 seek‐
       able.  That means no pipe, but any regular file is fine.

   TIFF Capability
       pamtotiff uses the Libtiff.org TIFF library (or whatever equivalent you
       provide)	 to  interpret the TIFF input.	So the set of files it is able
       to interpret is determined mostly by that library.

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

       There  are  many TIFF formats that tifftopnm can read only if the image
       is small enough to fit in memory.  tifftopnm uses  the  TIFF  library's
       TIFFRGBAImageGet()  function  to	 process  the TIFF image if it can get
       enough memory for TIFFRGBAImageGet() to store the whole image in memory
       at  once (that's what TIFFRGBAImageGet() does).	If not, tifftopnm uses
       a more primitive row-by-row conversion  strategy	 using	the  raw  data
       returned	 by  TIFFReadScanLine()	 and native intelligence.  That native
       intelligence does not know as many formats as TIFFRGBAImageGet()	 does.
       And certain compressed formats simply cannot be read with TIFFReadScan‐
       Line().

       Before Netpbm 10.11 (October 2002), tifftopnm  never  used  TIFFRGBAIm‐
       ageGet(),  so  it could not interpret many of the formats it can inter‐
       pret today.

       There is no fundamental reason that this program could not  read	 other
       kinds  of  TIFF	files  even when they don't fit in memory all at once.
       The existing limitations are mainly because no one has asked for more.

   Output Image
       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  informa‐
       tion, 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  tifftopnm	sees a non-colormapped maxval > 255, it takes it seri‐
       ously and produces a matching output maxval.

       Another exception is where the TIFF maxval is greater than 65535, which
       is  the maximum allowed by the Netpbm formats.  In that case, tifftopnm
       uses a maxval of 65535, and you lose some information  in  the  conver‐
       sion.

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

       -alphaout=alpha-filename
	      tifftopnm creates a PGM 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 pamcomp(1)foronewaytouse 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.

       -byrow This option can make tifftopnm run faster.

	      tifftopnm	 has two different ways to do the conversion from Tiff
	      to PNM, using two different facilities of the TIFF library:

       Whole Image
	      Decode the entire image into memory at once,  using  TIFFRGBAIm‐
	      ageGet(), then convert to PNM and output row by row.

       Row By Row
	      Read,  convert, and output one row at a time using TIFFReadScan‐
	      line().

	      Whole Image is preferable because the Tiff library does more  of
	      the  work,  which	 means	it understands more of the Tiff format
	      possibilities now and in the future.  Also, some compressed TIFF
	      formats don't allow you to extract an individual row.

	      Row  By Row uses far less memory, which means with large images,
	      it can run in environments where Whole Image cannot and may also
	      run faster.  And because Netpbm code does more of the work, it's
	      possible that it can be more flexible or at  least  give	better
	      diagnostic information if there's something wrong with the TIFF.

	      The  Netpbm native code may do something correctly that the TIFF
	      library does incorrectly, or vice versa.

	      In Netpbm, we stress function over performance, so by default we
	      try Whole Image first, and if we can't get enough memory for the
	      decoded image or TIFFRGBAImageGet() fails, we fall back  to  Row
	      By  Row.	 But  if you specify the -byrow option, tifftopnm will
	      not attempt Whole Image.	If Row By Row does not work, it simply
	      fails.

	      See  Color Separation (CMYK) TIFFs ⟨#cmyk⟩  for a description of
	      one way Row By  Row  makes  a  significant  difference  in  your
	      results.

	      Whole  Image  costs you precision when your TIFF image uses more
	      than 8 bits per sample.  TIFFRGBAImageGet() converts the samples
	      to 8 bits.  tifftopnm then scales them back to maxval 65535, but
	      the lower 8 bits of information is gone.

	      In many versions of the TIFF  library,  TIFFRGBAImageGet()  does
	      not  correctly interpret TIFF files in which the raster orienta‐
	      tion is column-major (i.e. a row of the raster is	 a  column  of
	      the  image).   With  such	 a TIFF library and file, you must use
	      -byrow to get correct output.

	      Before Netpbm 10.11 (October 2002), tifftopnm always did Row  By
	      Row.   Netpbm 10.12 always tried Whole Image first.  -byrow came
	      in with Netpbm 10.13 (January 2003).

       -orientraw
	      A TIFF stream contains raster data which can be arranged in  the
	      stream  various  ways.   Most  commonly, it is arranged by rows,
	      with the top row first, and the pixels left to right within each
	      row, but many other orientations are possible.

	      The common orientation is the same on the Netpbm formats use, so
	      tifftopnm can do its jobs quite efficiently when the TIFF raster
	      is oriented that way.

	      But  if the TIFF raster is oriented any other way, it can take a
	      considerable amount of processing for tifftopnm to convert it to
	      Netpbm format.

	      -orientraw  says	to produce an output image that represents the
	      raw raster in the TIFF stream rather than	 the  image  the  TIFF
	      stream  is  supposed  to represent.  In the output, the top left
	      corner corresponds to the start of the  TIFF  raster,  the  next
	      pixel  to	 the  right is the next pixel in the TIFF raster, etc.
	      tifftopnm can do this easily, but you don't get the right	 image
	      out.   You can use pamflip to turn the output into the image the
	      TIFF stream represents (but if you do that, you pretty much lose
	      the benefit of -orientraw).

	      With  this  option,  tifftopnm always uses the Row By Row method
	      (see -byrow).

	      This option was new in Netpbm 10.42 (March 2008).	 Before	 that,
	      tifftopnm	 generally produces arbitrary results with TIFF images
	      that have an orientation other than the common one.

       -verbose
	      Print extra messages to Standard Error about the conversion.

       -headerdump
	      Dump TIFF file information to stderr.  This information  may  be
	      useful in debugging TIFF file conversion problems.

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 repre‐
       sented by a single byte: 1) the byte is filled  from  most  significant
       bit  to	least significant bit going left to right in the image; and 2)
       the opposite.

       However, there is confusion in the world as  to	the  meaning  of  fil‐
       lorder.	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,  how‐
       ever,  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.
       ⟨ftp://weather.noaa.gov.⟩    They  are  apparently created by a program
       called faxtotiff.

       This note was written on January 1, 2002.

   Color Separation (CMYK) TIFFs
       Some TIFF images contain color information in CMYK  form,  whereas  PNM
       images  use  RGB.   There  are  various formulas for converting between
       these two forms, and tifftopnm can use either of two.

       The TIFF library (Version 3.5.4 from  libtiff.org)  uses	 Y=(1-K)*(1-B)
       (similar	 for  R	 and  G)  in  its  TIFFRGBAImageGet()  service.	  When
       tifftopnm works in Whole Image mode, it uses that  service,  so	that's
       the conversion you get.

       But when tifftopnm runs in Row By Row mode, it does not use TIFFRGBAIm‐
       ageGet(), and you get what appears to be more useful: Y=1-(B+K).	  This
       is the inverse of what pnmtotiffcmyk does.

       See the -byrow option for more information on Whole Image versus Row By
       Row mode.

       Before Netpbm 10.21 (March 2004), tifftopnm used the Y=(1-K)*(1-B) for‐
       mula always.

SEE ALSO
       pnmtotiff(1), pnmtotiffcmyk(1), pamcomp(1), pnm(1)

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

netpbm documentation		 12 July 2009	      Tifftopnm User Manual(0)
[top]

List of man pages available for Scientific

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net