pamtotiff man page on Scientific

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

Pamtotiff User Manual(0)			      Pamtotiff User Manual(0)

       pamtotiff - convert a Netpbm image to a TIFF file


       [-none | -packbits | -lzw | -g3 | -g4 | -flate | -adobeflate]









       [-indexbits=bitwidthlist] [-xresolution=xres]

       [-yresolution=yres]  [-resolutionunit={inch  | centimeter | none | in |
       cm | no}]





       You can use the minimum unique abbreviation of the  options.   You  can
       use  two	 hyphens instead of one.  You can separate an option name from
       its value with white space instead of an equals sign.

       This program is part of Netpbm(1).

       pamtotiff reads a PNM or PAM image as input and produces a TIFF file as

       Actually,  it handles multi-image Netpbm streams, producing multi-image
       TIFF streams (i.e. a TIFF stream	 with  multiple	 'directories').   But
       before  Netpbm  10.27 (March 2005), it ignored all but the first Netpbm
       image in the input stream.

   The Output File
       The output goes to Standard Output.  pamtotiff approaches  this	output
       file differently from Unix and Netpbm convention.  This is entirely due
       to pamtotiff's use of the TIFF library to do all TIFF output.

       ·      The output file must be seekable.	 pamtotiff does not  write  it
	      sequentially.   Therefore,  you can't use a pipe; you can't pipe
	      the output of pamtotiff to some other program.  But any  regular
	      file should work.

       ·      If the output file descriptor is readable, you must either spec‐
	      ify -append so as to add to the existing file, or make sure  the
	      file is empty.  Otherwise, pamtotiff will fail with an unhelpful
	      message telling you that a TIFF library function failed to  open
	      the TIFF output stream.

       ·      If  you  are  converting multiple images (your input stream con‐
	      tains multiple images), the output file must  be	both  readable
	      and writable.

       If  you're using a Unix command shell to run pamtotiff, you use facili‐
       ties of your shell to set up Standard Output.  In  Bash,	 for  example,
       you  would  set	up a write-only Standard Output to the file /tmp/myim‐
       age.tiff like this:

	   $ pamtotiff myimage.pnm >/tmp/myimage.tiff

       In Bash, you would set up a read/write  Standard	 Output	 to  the  file
       /tmp/myimage.tiff like this:

	   $ pamtotiff myimage.pnm 1<>/tmp/myimage.tiff

   TIFF Capability
       pamtotiff uses the TIFF library (or whatever equivalent you
       provide) to generate the TIFF output.  Details of the  format  it  pro‐
       duces are therefore controlled by that library.

       By default, pamtotiff creates a TIFF file with no compression.  This is
       your best bet most of the time.	If you want to try another compression
       scheme  or  tweak  some	of the other even more obscure output options,
       there are a number of options which which to play.

       Before Netpbm 8.4 (April 2000), the default was to use LZW compression.
       But then new releases of the TIFF library started omitting the LZW com‐
       pression capability due to concern about	 patents  on  LZW.   So	 since
       then,  the  default  has been no compression.  The LZW patents have now
       expired and new TIFF libraries  do  LZW,	 but  the  pamtotiff  behavior
       remains the same for compatibility with older TIFF libraries and appli‐
       cations of pamtotiff.

       The -none, -packbits, -lzw, -g3, -g4, -flate, and  -adobeflate  options
       are used to override the default and set the compression scheme used in
       creating the output file.

       The -predictor option is meaningful only with LZW compression:  a  pre‐
       dictor  value  of 2 causes each scanline of the output image to undergo
       horizontal differencing before it is encoded; a value of 1 forces  each
       scanline	 to  be	 encoded  without differencing.	 By default, pamtotiff
       creates a TIFF file with	 msb-to-lsb  fill  order.   The	 -msb2lsb  and
       -lsb2msb	 options  are  used  to	 override the default and set the fill
       order used in creating the file.

       With some older TIFF libraries, -lzw  doesn't  work  because  the  TIFF
       library	doesn't do LZW compression.  This is because of concerns about
       Unisys's patent on LZW which was then in force.	 Actually,  with  very
       old  TIFF  libraries,  -lzw  works  because no distributors of the TIFF
       library were sensitive yet to the patent issue.

       -flate chooses 'flate' compression, which is the	 patent-free  compres‐
       sion  common  in	 the Unix world implemented by the 'Z' library.	 It is
       what the PNG format uses.

       Fax Compression

       If you have bilevel data (e.g. PBM), you can generate a TIFF that  uses
       the same compression scheme specified for use by fax machines.  See the
       FaxFormat(1)pageformoreinformationonthese compression schemes.

       These formats all relate to ITU Group 3 and Group 4 fax	machine	 stan‐

       The  -g3	 option	 chooses  MH or MR compression: MR with the additional
       option -2d; MH without it.  -g4 selects MMR.  The option	 names	are  a
       little  unfortunate  and	 historical,  but are consistent with the TIFF

       MMR has a better compression ratio than the other two.

       -fill specifies that for MH or MR compression,  each  encoded  scanline
       shall be zero-filled to a byte boundary.

       -2d and -fill are meaningful only with -g3.

   Fill Order
       The -msb2lsb and lsb2msb options control the fill order.

       The  fill  order is the order in which pixels are packed into a byte in
       the Tiff raster, in the case that there are multiple pixels  per	 byte.
       msb-to-lsb means that the leftmost columns go into the most significant
       bits of the byte in the Tiff image.   However,  there  is  considerable
       confusion  about	 the  meaning  of  fill	 order.	 Some believe it means
       whether 16 bit sample values in the Tiff	 image	are  little-endian  or
       big-endian.  This is totally erroneous (The endianness of integers in a
       Tiff image is  designated  by  the  image's  magic  number).   However,
       ImageMagick  and	 older	Netpbm	both have been known to implement that
       interpretation.	2001.09.06.

       If the image does not have  sub-byte  pixels,  these  options  have  no
       effect  other  than  to	set the value of the FILLORDER tag in the Tiff
       image (which may be useful for those programs that misinterpret the tag
       with reference to 16 bit samples).

   Color Space
       -color  tells  pamtotiff	 to  produce a color, as opposed to grayscale,
       TIFF image if the input is PPM, even if	it  contains  only  shades  of
       gray.   Without	this option, pamtotiff produces a grayscale TIFF image
       if the input is PPM and contains only shades of gray, and at  most  256
       shades.	 Otherwise,  it produces a color TIFF output.  For PBM and PGM
       input, pamtotiff always produces grayscale TIFF output and this	option
       has no effect.

       The  -color option can prevent pamtotiff from making two passes through
       the input file, thus improving speed and memory	usage.	 See  Multiple
       Passes ⟨#multipass⟩ .

       -truecolor  tells pamtotiff to produce the 24-bit RGB form of TIFF out‐
       put if it is producing a color TIFF image.  Without this option, pamto‐
       tiff produces a colormapped (paletted) TIFF image unless there are more
       than 256 colors (and in the latter case, issues a warning).

       The -truecolor option can prevent  pamtotiff  from  making  two	passes
       through	the  input  file,  thus improving speed and memory usage.  See
       Multiple Passes ⟨#multipass⟩ .

       The -color and -truecolor options did  not  exist  before  Netpbm  9.21
       (December 2001).

       If  pamtotiff  produces	a  grayscale  TIFF  image,  this option has no

       The -minisblack and -miniswhite options force the output image to  have
       a  'minimum  is black' or 'minimum is white' photometric, respectively.
       If you don't specify either, pamtotiff uses  minimum  is	 black	except
       when using Group 3 or Group 4 compression, in which case pamtotiff fol‐
       lows CCITT fax standards and uses  'minimum  is	white.'	 This  usually
       results	in  better  compression and is generally preferred for bilevel

       Before February 2001, pamtotiff always produced 'minimum is black,' due
       to  a  bug.  In either case, pamtotiff sets the photometric interpreta‐
       tion tag in the TIFF output according to which photometric is  actually

       The  -indexbits	option is meaningful only for a colormapped (paletted)
       image.  In this kind of image, the raster  contains  values  which  are
       indexes	into  a table of colors, with the indexes normally taking less
       space that the color description in the table.  pamtotiff can  generate
       indexes of 1, 2, 4, or 8 bits.  By default, it will use 8, because many
       programs that interpret TIFF images can't handle any other width.

       But if you have a small number of colors, you can make your image  con‐
       siderably  smaller  by  allowing fewer than 8 bits per index, using the
       -indexbits option.  The value is a  comma-separated  list  of  the  bit
       widths  you allow.  pamtotiff chooses the smallest width you allow that
       allows it to index the entire color table.  If you don't allow any such
       width,  pamtotiff  fails.   Normally,  the  only	 useful value for this
       option is 1,2,4,8, because a program either understands the 8 bit width
       (default) or understands them all.

       In a Baseline TIFF image, according to the 1992 TIFF 6.0 specification,
       4 and 8 are the only valid widths.  There are no formal standards  that
       allow any other values.

       This  option  was  added in June 2002.  Before that, only 8 bit indices
       were possible.

   Extra Tags
       There are lots of tag types in the TIFF format that don't correspond to
       any  information	 in  the  PNM  format or to anything in the conversion
       process.	 For example, a TIFF_ARTIST tag names the artist  who  created
       the image.

       You  can	 tell pamtotiff explicitly to include tags such as this in its
       output with the -tag option.  You identify a list of tag types and val‐
       ues  and	 pamtotiff  includes a tag in the output for each item in your

       The value of -tag is the list of tags, like this example:


       As you see, it is a list of tag	specifications	separated  by  commas.
       Each  tag  specification	 is  a	name and a value separated by an equal
       sign.  The name is the name  of	the  tag  type,	 except	 in  arbitrary
       upper/lower  case.   One place to see the names of TIFF tag types is in
       the TIFF library's tiff.h file, where there is a macro defined for each
       consisting  of  'TIFF_'	plus  the  name.  E.g. for the SUBFILETYPE tag
       type, there is a macro TIFF_SUBFILETYPE.

       The format of the value specification for a tag (stuff after the	 equal
       sign) depends upon what kind of value the tag type has:

       ·      Integer: a decimal number

       ·      Floating point number: a decimal number

       ·      String: a string

       ·      Enumerated (For example, a 'subfiletype' tag takes an enumerated
	      value.  Its possible values are REDUCEDIMAGE, PAGE, and  MASK.):
	      The  name of the value.  You can see the possible value names in
	      the TIFF library's tiff.h foile, where there is a macro  defined
	      for  each	 consisting  of a qualifier plus the value name.  E.g.
	      for the REDUCEDIMAGE value of a SUBFILETYPE  tag,	 you  see  the

	      The TIFF format assigns a unique number to each enumerated value
	      and you can specify that number, in decimal, as an  alternative.
	      This is useful if you are using an extension of TIFF that pamto‐
	      tiff doesn't know about.

       If you specify a tag type with -tag that is not independent of the con‐
       tent  of your PNM source image and pamtotiff's conversion process (i.e.
       a tag type in which pamtotiff is	 interested),  pamtotiff  fails.   For
       example, you cannot specify an IMAGEWIDTH tag with -tag, because pamto‐
       tiff generates an IMAGEWIDTH tag that gives the	actual	width  of  the

       -tag was new in Netpbm 10.31 (December 2005).

       You  can	 use the -rowsperstrip option to set the number of rows (scan‐
       lines) in each strip of data in the output file.	 By default, the  out‐
       put  file  has  the  number  of rows per strip set to a value that will
       ensure each strip is no more than 8 kilobytes long.

       The -append option tells pamtotiff to add images to the existing output
       file  (a TIFF file may contain multiple images) instead of the default,
       which is to replace the output file.

       -append was new in Netpbm 10.27 (March 2005).

       There are myriad variations of the TIFF format, and this program gener‐
       ates  only  a  few of them.  pamtotiff creates a grayscale TIFF file if
       its input is a PBM (monochrome) or PGM (grayscale)  or  equivalent  PAM
       file.   pamtotiff  also	creates	 a  grayscale  file if it input is PPM
       (color) or equivalent PAM, but there is only one color in the image.

       If the input is a PPM (color) file and there are 256 colors  or	fewer,
       but  more  than	1,  pamtotiff generates a color palette TIFF file.  If
       there are more colors than that, pamtotiff generates an RGB (not	 RGBA)
       single  plane  TIFF  file.   Use	 pnmtotiffcmyk	to  generate the cyan-
       magenta-yellow-black ink color separation TIFF format.

       The number of bits per sample in the TIFF output is determined  by  the
       maxval  of  the Netpbm input.  If the maxval is less than 256, the bits
       per sample in the output is the smallest number	that  can  encode  the
       maxval.	 If  the  maxval is greater than or equal to 256, there are 16
       bits per sample in the output.

   Extra Channels
       Like most Netpbm programs, pamtotiff's function is mostly undefined  if
       the  input  is  PAM  image  with	 tuple	type other than BLACKANDWHITE,
       GRAYSCALE, or RGB.  Most of the statements in this  manual  assume  the
       input  is  not  such an exotic PAM.  But there is a little defined pro‐
       cessing of other PAM subformats.

       pamtotiff assumes any 1 plane PAM image is BLACKANDWHITE	 or  GRAYSCALE
       (and doesn't distinguish between those two).

       pamtotiff  assumes  a  PAM  with more than 1 plane is of tuple type RGB
       except with that number of planes  instead  of  3.   pamtotiff  doesn't
       really  understand  red,	 green,	 and blue, so it has no trouble with a
       2-component or 5-component color space.	 The  TIFF  format  allows  an
       arbitrary number of color compoonents, so pamtotiff simply maps the PAM
       planes directly to TIFF color components.  I don't know if the meanings
       of  5  components in a TIFF image are standard at all, but the function
       is there if you want to use it.

       Note that pamtotiff may generate	 either	 a  truecolor  or  colormapped
       image  with  an arbitrary number of color components.  In the truecolor
       case, the raster has that number of planes.  In the  colormapped	 case,
       the  raster  has of course 1 plane, but the color map has all the color
       components in it.

       The most common reason for a PAM to have extra planes is when the tuple
       type  is	 xxx_ALPHA, which means the highest numbered plane is a trans‐
       parency plane (alpha channel).  At least one user  found	 that  a  TIFF
       with an extra plane for transparency was useful.

       Note  that  the	grayscale detection works on N-component colors, so if
       your planes aren't really color components, you'll want to disable this
       via the -color option.

   Multiple Passes
       pamtotiff  reads	 the  input image once if it can, and otherwise twice.
       It needs that second pass (which	 happens  before  the  main  pass,  of
       course)	to  analyze  the  colors in the image and generate a color map
       (palette) and determine if the image is grayscale.  So the second  pass
       happens only when the input is PPM.  And you can avoid it then by spec‐
       ifying both the -truecolor and -color options.

	If the input image is small enough to fit in your system's file cache,
       the  second  pass  is very fast.	 If not, it requires reading from disk
       twice, which can be slow.

       When the input is from a file that cannot be rewound and reread, pamto‐
       tiff  reads the entire input image into a temporary file which can, and
       works from that.	 Even if it needs only one pass.

       Before Netpbm 9.21 (December 2001), pamtotiff always  read  the	entire
       image  into  virtual  memory  and  then	did  one, two, or three passes
       through the memory copy.	 The -truecolor and  -color  options  did  not
       exist.	The  passes  through  memory  would involve page faults if the
       entire image did not  fit  into	real  memory.	The  image  in	memory
       required	 considerably more memory (12 bytes per pixel) than the cached
       file version of the image would.

       A Tiff image may contain information about the resolution of the image,
       which  means  how big in real dimensions (centimeters, etc.) each pixel
       in the raster is.  That information is in the TIFF XRESOLUTION,	YRESO‐
       LUTION,	and  RESOLUTIONUNIT  tags.   By	 default,  pamtotiff  does not
       include any tags of these types, but you	 can  specify  them  with  the
       -tags option.

       There are also options -xresolution, -yresolution, and -resolutionunit,
       but those are obsolete.	Before	-tags  existed	(before	 Netpbm	 10.31
       (December 2005), they were the only way.

       Note  that  the	number of pixels in the image and how much information
       each contains is determined independently from the setting of the reso‐
       lution  tags.  The number of pixels in the output is the same as in the
       input, and each pixel contains the same information.  For your  resolu‐
       tion  tags to be meaningful, they have to consistent with whatever cre‐
       ated the PNM input.  E.g. if a scanner  turned  a  10  centimeter  wide
       image into a 1000 pixel wide PNM image, then your horizontal resolution
       is 100 pixels per centimeter, and if your XRESOLUTION tag says anything
       else,  something	 that prints your TIFF image won't print the proper 10
       centimeter image.

       The value of the XRESOLUTION tag is a  floating	point  decimal	number
       that  tells how many pixels there are per unit of distance in the hori‐
       zontal direction.  -yresolution is analogous for	 the  vertical	direc‐

       The  unit  of  distance	is  given  by  the value of the RESOLUTIONUNIT
       option.	That value is either INCH, CENTIMETER, or  NONE.   NONE	 means
       the unit is arbitrary or unspecified.  This could mean that the creator
       and user of the image have a separate agreement as to what the unit is.
       But  usually, it just means that the horizontal and vertical resolution
       values cannot be used for anything except  to  determine	 aspect	 ratio
       (because even though the unit is arbitrary or unspecified, it has to be
       the same for both resolution numbers).

       If you don't use a -tag option to specify the resolution	 tag  and  use
       the obsolete options instead, note the following:

       ·      If  you  don't  include  an specify -xresolution, the Tiff image
	      does not contain horizontal  resolution  information.   Likewise
	      for  -yresolution.   If  you  don't specify -resolutionunit, the
	      default is inches.

       ·      Before Netpbm 10.16 (June 2003), -resolutionunit did  not	 exist
	      and the resolution unit was always inches.

       pamtotiff  was  originally  pnmtotiff and did not handle PAM input.  It
       was extended and renamed in Netpbm 10.30 (October 2005).

       tifftopnm(1), pnmtotiffcmyk(1), pamdepth(1), pamtopnm(1), pam(1)

       Derived by Jef Poskanzer from ras2tiff.c, which is Copyright  (c)  1990
       by    Sun    Microsystems,    Inc.    Author:   Patrick	 J.   Naughton

netpbm documentation	       03 December 2008	      Pamtotiff User Manual(0)

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]
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