1\ 2.\" This man page was generated by the Netpbm tool 'makeman' from HTML source. 3.\" Do not hand-hack it! If you have bug fixes or improvements, please find 4.\" the corresponding HTML page on the Netpbm website, generate a patch 5.\" against that, and send it to the Netpbm maintainer. 6.TH "Tifftopnm User Manual" 0 "02 January 2015" "netpbm documentation" 7 8.SH NAME 9 10tifftopnm - convert a TIFF file into a PNM image 11 12.UN synopsis 13.SH SYNOPSIS 14 15\fBtifftopnm\fP 16 17[\fB-alphaout=\fP{\fIalpha-filename\fP,\fB-\fP}] 18[\fB-headerdump\fP] 19[\fB-verbose\fP] 20[\fB-respectfillorder\fP] 21[\fB-byrow\fP] 22[\fB-orientraw\fP] 23[\fItiff-filename\fP] 24 25 26.UN description 27.SH DESCRIPTION 28.PP 29This program is part of 30.BR "Netpbm" (1)\c 31\&. 32.PP 33\fBtifftopnm\fP reads a TIFF file as input and produces a PNM image as 34output. The type of the output file depends on the input file - if it's black 35and white, \fBtifftopnm\fP generates a PBM image; if it's grayscale, it 36generates a PGM image; otherwise, the output is PPM. The program tells you 37which type it is writing. 38.PP 39If the TIFF file contains multiple images (multiple 40"directories"), \fBtifftopnm\fP generates a multi-image PNM 41output stream. Before Netpbm 10.27 (March 2005), however, it would 42just ignore all but the first input image. 43.PP 44The \fItiff-filename\fP argument names the file that contains the Tiff 45image. If you specify "-" or don't specify this 46argument, \fBtifftopnm\fP uses Standard Input. 47.PP 48In either case, before Netpbm 10.70 (March 2015), the file must be 49seekable. That means no pipe, but any regular file is fine. In current 50Netpbm, the file need not be seekable, but if it isn't, \fBtifftopnm\fP 51creates a temporary regular file containing the entire image, so you must have 52resources for that (and it may defeat your reason for using a pipe). 53 54 55.UN library 56.SS TIFF Capability 57.PP 58\fBpamtotiff\fP uses the Libtiff.org TIFF library (or whatever 59equivalent you provide) to interpret the TIFF input. So the set of files 60it is able to interpret is determined mostly by that library. 61.PP 62This program cannot read every possible TIFF file -- there are 63myriad variations of the TIFF format. However, it does understand 64monochrome and gray scale, RGB, RGBA (red/green/blue with transparency 65channel), CMYK (Cyan-Magenta-Yellow-Black ink color separation), and 66color palette TIFF files. An RGB file can have either single plane 67(interleaved) color or multiple plane format. The program reads 1-8 68and 16 bit-per-sample input, the latter in either bigendian or 69littlendian encoding. Tiff directory information may also be either 70bigendian or littlendian. 71.PP 72There are many TIFF formats that \fBtifftopnm\fP can read only if 73the image is small enough to fit in memory. \fBtifftopnm\fP uses the 74TIFF library's TIFFRGBAImageGet() function to process the TIFF image 75if it can get enough memory for TIFFRGBAImageGet() to store the whole 76image in memory at once (that's what TIFFRGBAImageGet() does). If 77not, \fBtifftopnm\fP uses a more primitive row-by-row conversion 78strategy using the raw data returned by TIFFReadScanLine() and native 79intelligence. That native intelligence does not know as many formats 80as TIFFRGBAImageGet() does. And certain compressed formats simply 81cannot be read with TIFFReadScanLine(). 82.PP 83Before Netpbm 10.11 (October 2002), \fBtifftopnm\fP never used 84TIFFRGBAImageGet(), so it could not interpret many of the formats it 85can interpret today. 86.PP 87There is no fundamental reason that this program could not read 88other kinds of TIFF files even when they don't fit in memory all at 89once. The existing limitations are mainly because no one has asked 90for more. 91 92.UN output 93.SS Output Image 94.PP 95The PNM output has the same maxval as the Tiff input, except that 96if the Tiff input is colormapped (which implies a maxval of 65535) the 97PNM output has a maxval of 255. Though this may result in lost 98information, such input images hardly ever actually have more color 99resolution than a maxval of 255 provides and people often cannot deal 100with PNM files that have maxval > 255. By contrast, a 101non-colormapped Tiff image that doesn't need a maxval > 255 doesn't 102\fIhave\fP a maxval > 255, so when \fBtifftopnm\fP sees a 103non-colormapped maxval > 255, it takes it seriously and produces a 104matching output maxval. 105.PP 106Another exception is where the TIFF maxval is greater than 65535, 107which is the maximum allowed by the Netpbm formats. In that case, 108\fBtifftopnm\fP uses a maxval of 65535, and you lose some information 109in the conversion. 110 111.UN options 112.SH OPTIONS 113.PP 114You may abbreviate any option to its shortest unique prefix. You may use 115two hyphens instead of one in options. You may separate an option and 116its value either by an equals sign or white space. 117 118 119.TP 120\fB-alphaout=\fP\fIalpha-filename\fP 121\fBtifftopnm \fPcreates a PGM file containing the alpha channel 122values in the input image. If the input image doesn't contain a 123transparency channel, the \fIalpha-filename\fP file contains all zero 124(transparent) transparency values. If you don't specify \fB-alphaout\fP, 125 126\fBtifftopnm\fP does not generate a transparency file, and if the input 127image has an transparency channel, \fBtifftopnm\fP simply discards it. 128.sp 129If you specify \fB-\fP as the filename, \fBtifftopnm\fP 130writes the transparency output to Standard Output and discards the image. 131.sp 132See 133.BR "pamcomp" (1)\c 134\& for one way to use 135the transparency output file. 136 137.TP 138\fB-respectfillorder\fP 139By default, \fBtifftopnm \fP ignores the "fillorder" 140tag in the TIFF input, which means it may incorrectly interpret the 141image. To make it follow the spec, use this option. For a lengthy 142but engaging discussion of why \fBtifftopnm\fP works this way and how 143to use the \fB-respectfillorder\fP option, see the note on fillorder 144below. 145 146.TP 147\fB-byrow\fP 148This option can make \fBtifftopnm\fP run faster. 149.sp 150\fBtifftopnm\fP has two ways to do the conversion from Tiff to PNM, using 151respectively two facilities of the TIFF library: 152 153 154 155.TP 156Whole Image 157Decode the entire image into memory at once, using 158\fBTIFFRGBAImageGet()\fP, then convert to PNM and output row by row. 159 160.TP 161Row By Row 162Read, convert, and output one row at a time 163using \fBTIFFReadScanline()\fP 164 165 166.sp 167Whole Image is preferable because the Tiff library does more of the 168work, which means it understands more of the Tiff format possibilities 169now and in the future. Also, some compressed TIFF formats don't allow 170you to extract an individual row. 171.sp 172Row By Row uses far less memory, which means with large images, it 173can run in environments where Whole Image cannot and may also run 174faster. And because Netpbm code does more of the work, it's possible 175that it can be more flexible or at least give better diagnostic 176information if there's something wrong with the TIFF. 177.sp 178The Netpbm native code may do something correctly that the TIFF 179library does incorrectly, or vice versa. 180.sp 181In Netpbm, we stress function over performance, so by default we 182try Whole Image first, and if we can't get enough memory for the 183decoded image or \fBTIFFRGBAImageGet()\fP fails, we fall back to Row By Row. 184But if you specify the \fB-byrow\fP option, \fBtifftopnm\fP will not 185attempt Whole Image. If Row By Row does not work, it simply fails. 186.sp 187See 188.UR #cmyk 189Color Separation (CMYK) TIFFs 190.UE 191\& for a 192description of one way Row By Row makes a significant difference in 193your results. 194.sp 195Whole Image costs you precision when your TIFF image uses more than 1968 bits per sample. \fBTIFFRGBAImageGet()\fP converts the samples to 8 bits. 197\fBtifftopnm\fP then scales them back to maxval 65535, but the lower 1988 bits of information is gone. 199.sp 200In many versions of the TIFF library, \fBTIFFRGBAImageGet()\fP does not 201correctly interpret TIFF files in which the raster orientation is 202column-major (i.e. a row of the raster is a column of the image). 203With such a TIFF library and file, you must use \fB-byrow\fP to get 204correct output. 205.sp 206Before Netpbm 10.11 (October 2002), \fBtifftopnm\fP always did Row 207By Row. Netpbm 10.12 always tried Whole Image first. \fB-byrow\fP 208came in with Netpbm 10.13 (January 2003). 209 210.TP 211\fB-orientraw\fP 212A TIFF stream contains raster data which can be arranged in the 213stream various ways. Most commonly, it is arranged by rows, with the 214top row first, and the pixels left to right within each row, but many 215other orientations are possible. 216.sp 217The common orientation is the same one the Netpbm formats use, so 218\fBtifftopnm\fP can do its jobs quite efficiently when the TIFF raster 219is oriented that way. 220.sp 221But if the TIFF raster is oriented any other way, it can take a 222considerable amount of processing for \fBtifftopnm\fP to convert it to 223Netpbm format. 224.sp 225\fB-orientraw\fP says to produce an output image that represents the raw 226raster in the TIFF stream rather than the image the TIFF stream is supposed to 227represent. In the output, the top left corner corresponds to the start of the 228TIFF raster, the next pixel to the right is the next pixel in the TIFF raster, 229etc. \fBtifftopnm\fP can do this easily, but you don't get the right image 230out. You can use \fBpamflip\fP to turn the output into the image the TIFF 231stream represents (but if you do that, you pretty much lose the benefit of 232\fB-orientraw\fP). 233.sp 234With this option, \fBtifftopnm\fP always uses the Row By Row method 235(see \fB-byrow\fP). 236.sp 237This option was new in Netpbm 10.42 (March 2008). Before that, 238\fBtifftopnm\fP generally produces arbitrary results with TIFF images 239that have an orientation other than the common one. 240 241.TP 242\fB-verbose\fP 243Print extra messages to Standard Error about the conversion. 244 245.TP 246\fB-headerdump\fP 247Dump TIFF file information to stderr. This information may be useful 248in debugging TIFF file conversion problems. 249 250 251 252.UN notes 253.SH NOTES 254 255.UN fillorder 256.SS Fillorder 257.PP 258There is a piece of information in the header of a TIFF image called 259"fillorder." The TIFF specification quite clearly states 260that this value tells the order in which bits are arranged in a byte 261in the description of the image's pixels. There are two options, 262assuming that the image has a format where more than one pixel can be 263represented by a single byte: 1) the byte is filled from most 264significant bit to least significant bit going left to right in the 265image; and 2) the opposite. 266.PP 267However, there is confusion in the world as to the meaning of 268fillorder. Evidence shows that some people believe it has to do with 269byte order when a single value is represented by two bytes. 270.PP 271These people cause TIFF images to be created that, while they use a 272MSB-to-LSB fillorder, have a fillorder tag that says they used LSB-to-MSB. 273A program that properly interprets a TIFF image will not end up with the 274image that the author intended in this case. 275.PP 276For a long time, \fBtifftopnm\fP did not understand fillorder itself 277and assumed the fillorder was MSB-to-LSB regardless of the fillorder 278tag in the TIFF header. And as far as I know, there is no legitimate 279reason to use a fillorder other than MSB-to-LSB. So users of 280\fBtifftopnm\fP were happily using those TIFF images that had 281incorrect fillorder tags. 282.PP 283So that those users can continue to be happy, \fBtifftopnm\fP today 284continues to ignore the fillorder tag unless you tell it not to. (It 285does, however, warn you when the fillorder tag does not say MSB-to-LSB 286that the tag is being ignored). 287.PP 288If for some reason you have a TIFF image that actually has LSB-to-MSB 289fillorder, and its fillorder tag correctly indicates that, you must 290use the \fB-respectfillorder\fP option on \fBtifftopnm\fP to get 291proper results. 292.PP 293Examples of incorrect TIFF images are at 294.UR ftp://weather.noaa.gov. 295ftp://weather.noaa.gov. 296.UE 297\& They are 298apparently created by a program called \fBfaxtotiff\fP. 299.PP 300This note was written on January 1, 2002. 301 302 303.UN cmyk 304.SS Color Separation (CMYK) TIFFs 305.PP 306Some TIFF images contain color information in CMYK form, whereas PNM 307images use RGB. There are various formulas for converting between these 308two forms, and \fBtifftopnm\fP can use either of two. 309.PP 310The TIFF library (Version 3.5.4 from libtiff.org) uses 311Y=(1-K)*(1-B) (similar for R and G) in its TIFFRGBAImageGet() service. 312When \fBtifftopnm\fP works in Whole Image mode, it uses that service, 313so that's the conversion you get. 314.PP 315But when \fBtifftopnm\fP runs in Row By Row mode, it does not use 316TIFFRGBAImageGet(), and you get what appears to be more useful: 317Y=1-(B+K). This is the inverse of what \fBpnmtotiffcmyk\fP does. 318.PP 319See the \fB-byrow\fP option for more information on Whole Image versus 320Row By Row mode. 321.PP 322Before Netpbm 10.21 (March 2004), \fBtifftopnm\fP used the 323Y=(1-K)*(1-B) formula always. 324 325 326.UN seealso 327.SH SEE ALSO 328.BR "pnmtotiff" (1)\c 329\&, 330.BR "pnmtotiffcmyk" (1)\c 331\&, 332.BR "pamcomp" (1)\c 333\&, 334.BR "pnm" (5)\c 335\& 336 337.UN author 338.SH AUTHOR 339.PP 340Derived by Jef Poskanzer from tif2ras.c, which is Copyright (c) 3411990 by Sun Microsystems, Inc. Author: Patrick J. Naughton (\fInaughton@wind.sun.com\fP). 342.SH DOCUMENT SOURCE 343This manual page was generated by the Netpbm tool 'makeman' from HTML 344source. The master documentation is at 345.IP 346.B http://netpbm.sourceforge.net/doc/tifftopnm.html 347.PP