• Last 5 Forum Topics
    Last post

The Web Only This Site



  • MARC

    Mailing list ARChives
    - Search by -


    Computing Dictionary

  • Text Link Ads

  • LINUX man pages
  • Linux Man Page Viewer

    The following form allows you to view linux man pages.





           tifftopnm  [-alphaout={alpha-filename,-}]  [-headerdump]  [-respectfil-
           lorder] [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.


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


                  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
                  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 repre-
           sented 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
           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   They
           are apparently created by a program called faxtotiff.
                                     02 April 2000                    tifftopnm(1)

  • Linux

    The Distributions


    The Software


    The News


  • Toll Free
Copyright © 1999 - 2016 by LinuxGuruz