home *** CD-ROM | disk | FTP | other *** search
/ gondwana.ecr.mu.oz.au/pub/ / Graphics.tar / Graphics / graphics.formats / tiff.doc.4.0.Z / tiff.doc.4.0
Text File  |  1991-09-24  |  55KB  |  1,469 lines
  1.  
  2.  
  3. Tag Image File Format  Rev 4.0
  4. April 31, 1987
  5.  
  6. This memorandum has been prepared jointly by Aldus and Microsoft in conjunction
  7. with leading scanner and printer manufacturers.  This document does not
  8. represent a commitment on the part of either Microsoft or Aldus to provide
  9. support for this file format in any application.  When responding to specific
  10. issues raised in this memo, or when requesting additional tag or field
  11. assignments, please address your correspondence to either:
  12.  
  13.           Tim Davenport                       Manny Vellon
  14.           Aldus Corporation                   Windows Marketing Group
  15.           411 First Ave. South                Microsoft Corporation
  16.           Suite 200                           16011 NE 36th Way
  17.           Seattle, WA  98104                  Box 97017
  18.                                               Redmond, WA  98073-9717
  19.  
  20.  
  21. Revision Notes
  22.  
  23. This release of the TIFF specification has been given a Revision number.  It is
  24. really the fourth major revision, so the Revision number was set to 4.0.
  25.  
  26.  
  27. Abstract
  28.  
  29. This document describes TIFF, a tag based file format that is designed to
  30. promote the interchange of digital image data.
  31.  
  32. The fields were defined primarily with desktop publishing and related
  33. applications in mind, although it is conceivable that other sorts of imaging
  34. applications may find TIFF to be useful.
  35.  
  36. The general scenario for which TIFF was invented assumes that applications
  37. software for scanning or painting creates a TIFF file, which can then be read
  38. and incorporated into a document or publication by an application such as a
  39. desktop publishing package.
  40.  
  41. The intent of TIFF is to organize and codify existing practice with respect to
  42. the definition and usage of desktop digital data, not to blaze new paths or
  43. promote unproven techniques.  Yet a very high priority has been given to
  44. structuring the data in such a way as to minimize the pain of future additions.
  45. TIFF was designed to be a very extensible interchange format.
  46.  
  47. TIFF is not a printer language or page description language, nor is it intended
  48. to be a general document interchange standard.  It may be useful as is for some
  49. image editing applications, but is probably inappropriate for and would thus
  50. need to be translated into some intermediate data structures by other image
  51. editing applications.  The primary design goal was to provide a rich
  52. environment within which the exchange of image data between application
  53. programs can be accomplished.  This richness is required in order to take
  54. advantage of the varying capabilities of scanners and similar devices.  TIFF is
  55. therefore designed to be a superset of existing image file formats for desktop
  56. scanners (and paint programs and anything else that produces images with pixels
  57. in them) and will be enhanced on a continuing basis as new capabilities arise.
  58.  
  59. Although TIFF is claimed to be in some sense a rich format, it can easily be
  60. used for simple scanners and applications as well, since the application
  61. developer need only be concerned with the capabilities that he requires.  The
  62. mechanisms for accomplishing this goal are discussed in the next section.
  63.  
  64. TIFF is intended to be independent of specific operating systems, filing
  65. systems, compilers, and processors.  The only significant assumption is that
  66. the storage medium supports something like a file, defined as a sequence of
  67. 8-bit bytes, where the bytes are numbered from 0 to N.  The largest possible
  68. TIFF file is 2**32 bytes.  Since pointers (byte offsets) are used liberally, a
  69. TIFF file is most easily read from a random access device, although it is
  70. possible to read and write TIFF files on sequential media such as magnetic
  71. tape.
  72.  
  73. The recommended MS-DOS file extension for TIFF files is .TIF.  The recommended
  74. Macintosh filetype is TIFF.  Conventions in other computing environments have
  75. not yet been established.
  76.  
  77.  
  78. 1) Conformance
  79.  
  80. Many of the application programs that read the contents of TIFF image files
  81. will not support all of the features described in this document.  In some
  82. cases, little more than the default options will be supported.  It is up to
  83. each organization to determine the costs and benefits associated with different
  84. levels of conformity.  Therefore, claims of conformity to this specification
  85. should be interpreted with a certain amount of caution.
  86.  
  87. It follows that the usage of this specification does not preclude the need for
  88. coordination between image file writers and image file readers.  It is up to
  89. the application designer that initially writes a file in this format to verify
  90. that the desired file options are supported by the applications that will read
  91. the file.
  92.  
  93.  
  94. 2) Structure
  95.  
  96. In TIFF, individual fields are identified with a unique tag.  This allows
  97. particular fields to be present or absent from the file as required by the
  98. application.
  99.  
  100. Some TIFF files will have only a few fields in them; others will have many.
  101. Software that creates TIFF files should write out as many fields as it believes
  102. will be meaningful and useful (and no more).  Software that reads TIFF files
  103. should do the best it can with the fields that it finds there.
  104.  
  105. See Appendix A: Tag Structure Rationale.
  106.  
  107. There are many ways in which a tag-oriented file format scheme can be
  108. implemented.  TIFF uses the following approach:
  109.  
  110. There are three main parts to a TIFF file.  First is a short image file header.
  111. Next is a directory of all the fields that are to be found in this file.
  112. Finally, we have the data for the fields.
  113.  
  114.  
  115. 3) Header and Directory
  116.  
  117. A TIFF file begins with a small amount of positionally defined data, containing
  118. the following information:
  119.  
  120. Bytes 0-1:
  121.  
  122. The first word of the file serves to specify the byte order used within the
  123. file.  The currently defined values are:
  124.  
  125.      II        (hex 4949)
  126.      MM        (hex 4D4D)
  127.  
  128. In the II format, byte order is always from least significant to most
  129. significant, for both 16-bit and 32-bit integers.
  130.  
  131. In the MM format, byte order is always from most significant to least
  132. significant, for both 16-bit and 32-bit integers.
  133.  
  134. In both formats, character strings are stored into sequential byte locations.
  135.  
  136. It is certainly not required that all applications software be able to handle
  137. both formats.  It should be apparent which is the native format for a
  138. particular machine.
  139.  
  140. Bytes 2-3:
  141.  
  142. The second word of the file is the TIFF version number.  This number shouldnt
  143. change.  This document describes Version 42, so 42 (2A in hex) should be stored
  144. in this word.
  145.  
  146. Bytes 4-7:
  147.  
  148. This long word contains the offset (in bytes) of the first Image File
  149. Directory.  The directory may be at any location in the file after the header
  150. but must begin on a word boundary.
  151.  
  152. (The term byte offset is always used in this document to refer to a location
  153. with respect to the beginning of the file.  The first byte of the file has an
  154. offset of 0.)
  155.  
  156. An IFD consists of a 2-byte count of the number of entries (i.e., the number of
  157. fields), followed by a sequence of 12-byte field entries, followed by a 4-byte
  158. offset of the next Image File Directory (or 0 if none).  Each 12-byte field
  159. entry has the following format:
  160.  
  161. Bytes 0-1 contain the Tag for the field.  Bytes 2-3 contain the field Type.
  162. Bytes 4-7 contain the Length (Count might have been a better term) of the
  163. field.  Bytes 8-11 contain the file offset (in bytes) of the Value for the
  164. field.  The Value is expected to begin on a word boundary; the corresponding
  165. file offset will thus be an even number.
  166.  
  167. The entries in an IFD must be sorted in ascending order by Tag.  Note that this
  168. is not the order in which the fields are described in this document.  The
  169. Values to which directory entries point need not be in any particular order in
  170. the file.
  171.  
  172. If the Value fits within 4 bytes, the Offset is interpreted to contain the
  173. Value instead of pointing to the Value, to save a little time and space.  If
  174. the Value is less than 4 bytes, it is left-justified.  Whether or not it fits
  175. within 4 bytes can be determined by looking at the Type and Length of the
  176. field.
  177.  
  178. The Length part is specified in terms of the data type.  A single 16-bit word
  179. (SHORT) has a Length of 1, not 2, for example.  The data types and their
  180. lengths are described below:
  181.  
  182.      1 = BYTE.      8-bit unsigned integer.
  183.      2 = ASCII.     8-bit bytes that store ASCII codes; the last byte must
  184.                      be null.
  185.      3 = SHORT.     A 16-bit (2-byte) unsigned integer.
  186.      4 = LONG.      A 32-bit (4-byte) unsigned integer.
  187.      5 = RATIONAL.  Two LONGs: the first represents the numerator of a
  188.                      fraction, the second the denominator.
  189.  
  190. The value of the Length part of an ASCII field entry includes the null.  If
  191. padding is necessary, the Length does not include the pad byte.
  192.  
  193. The reader should check the type to ensure that it is what he expects.  TIFF
  194. currently allows more than 1 valid type for a given field.  For example,
  195. ImageWidth and ImageLength were specified as having type SHORT.  Very large
  196. images with more than 64k rows or columns are possible with some devices even
  197. now.  Rather than add parallel LONG tags for these fields, it is cleaner to
  198. allow both SHORT and LONG for ImageWidth and similar fields.  Writers of TIFF
  199. files are, however, encouraged to use the default type values as indicated in
  200. this document to insure compatbility with existing TIFF reader applications.
  201.  
  202. Note that there may be more than one IFD.  Each IFD is said to define a
  203. subfile.  One potential use of subsequent subfiles is to describe a sub-image
  204. that is somehow related to the main image, such as a reduced resolution or
  205. screen resolution image.  Another use is to represent multiple page images -
  206. for example, a facsimile document requiring more than one page.  Subsequent
  207. IFDs will in general contain many of the same fields as the first IFD but will
  208. usually point to or contain different Values for those fields.
  209.  
  210.  
  211. 4) Definitions
  212.  
  213. The TIFF structure itself is not specific to imaging applications in any way.
  214. It is only the definitions of the fields themselves that jointly describe an
  215. image.  Before we begin describing the fields, a few image related definitions
  216. may be useful.
  217.  
  218. An image is defined to be a rectangular array of pixels, each of which consists
  219. of one or more samples.  With monochromatic data, we have one sample per pixel,
  220. and sample and pixel can be used interchangeably.  Color data usually contains
  221. three samples per pixel, as in, for example, an RGB scheme.
  222.  
  223.  
  224. 5) The Fields
  225.  
  226. The following fields are defined in this version of TIFF.  More will be added
  227. in future versions, if possible in such a way so as not to break old software
  228. that encounters a newer TIFF file.  An attempt has been made to group related
  229. fields, although the grouping is necessarily somewhat arbitrary.
  230.  
  231. The documentation for each field contains the name of the field (quite
  232. arbitrary, but convenient), the Tag value, the field Type, the Number of Values
  233. (N) expected (per IFD, in the case of multiple subfiles), comments describing
  234. the field, and the default, if any.  The default value is used if the field
  235. does not exist.
  236.  
  237. A fairly large number of fields has already been defined, and the number will
  238. grow.  Please keep in mind that many common images can be described using only
  239. a handful of these fields (see the Examples section).
  240.  
  241.  
  242. General Description
  243.  
  244. SubfileType
  245. Tag  = 255  (FF)
  246. Type = SHORT
  247. N    = 1
  248.  
  249. A general indication of the kind of data that is contained in this subfile.
  250. Currently defined values are:
  251. 1 = full resolution image data  ImageWidth, ImageLength, and StripOffsets are
  252. required fields.
  253. 2 = reduced resolution image data ImageWidth, ImageLength, and StripOffsets
  254. are required fields.  It is further assumed that a reduced resolution image is
  255. a reduced version of the entire extent of the corresponding full resolution
  256. data.
  257. 3 = Single page of a multi-page image (see the PageNumber tag description).
  258.  
  259. If your kind of image data doesnt fit nicely into either description, contact
  260. either Aldus or Microsoft to define an additional value.  Note that both image
  261. types can be found in a single TIFF file, with each subfile described by its
  262. own IFD.
  263. No default.
  264.  
  265.  
  266. Data Architecture
  267.  
  268. ImageWidth
  269. Tag  = 256  (100)
  270. Type = SHORT
  271. N    = 1
  272.  
  273. The images width, in pixels (X: horizontal).  The number of columns in the
  274. image.
  275. No default.
  276.  
  277.  
  278. ImageLength
  279. Tag  = 257  (101)
  280. Type = SHORT
  281. N    = 1
  282.  
  283. The images length (height) in pixels (Y: vertical).  The number of rows
  284. (sometimes described as scan lines) in the image.  ImageLength and ImageWidth
  285. refer only to how the pixels are stored in the file and do not imply anything
  286. about where the visual top or left side of the image may be.  See Orientation
  287. for this information.
  288. No default.
  289.  
  290.  
  291. RowsPerStrip
  292. Tag  = 278  (116)
  293. Type = SHORT or LONG
  294. N    = 1
  295.  
  296. The number of rows per strip.  The image data is organized into strips for fast
  297. access to individual rows when the data is compressed (though this field is
  298. valid even if the data is not compressed).
  299.  
  300. Note that either SHORT or LONG values can be used to specify RowsPerStrip.
  301. SHORT values may be used for small TIFF files.  It should be noted, however,
  302. that earlier TIFF specifications required LONG values and that some software
  303. may not expect SHORT values.
  304.  
  305. Default is 2**32 - 1, which is effectively infinity.  That is, the entire image
  306. is one strip.
  307.  
  308.  
  309. [StripsPerImage]
  310. N    = 1
  311.  
  312. The number of strips per image.  This value is not a field, since it can be
  313. computed from two other fields, but it is convenient to give it a name in order
  314. to clarify the use of other fields.  The equation to use is StripsPerImage =
  315. (ImageLength + RowsPerStrip - 1) / RowsPerStrip, assuming integer arithmetic.
  316.  
  317.  
  318. StripOffsets
  319. Tag  = 273  (111)
  320. Type = SHORT or LONG
  321. N    = StripsPerImage for PlanarConfiguration equal to 1.
  322.      = SamplesPerPixel * StripsPerImage for PlanarConfiguration equal to 2
  323.  
  324. For each strip, the byte offset of that strip.  The offset is specified with
  325. respect to the beginning of the TIFF file.  Note that this implies that each
  326. strip has a location independent of the locations of other strips.  This
  327. feature may be useful for certain editing applications.  This field is the only
  328. way for a reader to find the image data, and hence must exist.
  329.  
  330. Note that either SHORT or LONG values can be used to specify the strip offsets.
  331. SHORT values may be used for small TIFF files.  It should be noted, however,
  332. that earlier TIFF specifications required LONG strip offsets and that some
  333. software may not expect SHORT values.
  334. No default.
  335.  
  336.  
  337. StripByteCounts
  338. Tag  = 279  (117)
  339. Type = LONG
  340. N    = StripsPerImage for PlanarConfiguration equal to 1.
  341.      = SamplesPerPixel * StripsPerImage for PlanarConfiguration equal to 2
  342.  
  343. For each strip, the number of bytes in that strip.
  344. No default.
  345.  
  346.  
  347. SamplesPerPixel
  348. Tag  = 277  (115)
  349. Type = SHORT
  350. N    = 1
  351.  
  352. The number of samples per pixel.  Usually 1 for monochromatic data and 3 for
  353. color data (i.e. one sample for each of the color planes.)
  354. Default = 1.
  355.  
  356.  
  357. BitsPerSample
  358. Tag  = 258  (102)
  359. Type = SHORT
  360. N    = SamplesPerPixel
  361.  
  362. Number of bits per sample.  Note that this tag allows a different number of
  363. bits per sample for each sample corresponding to a pixel.  For example, RGB
  364. color data could use a different number of bits per sample for each of the
  365. three color planes.
  366. Default = 1.
  367.  
  368.  
  369. PlanarConfiguration
  370. Tag  = 284  (11C)
  371. Type = SHORT
  372. N    = 1
  373.  
  374. 1 = the sample values for each pixel are stored contiguously, so that there is
  375. a single image plane.  See PhotometricInterpretation to determine the order of
  376. the samples within the pixel data.
  377. 2 = the samples are stored in separate sample planes.  The values in
  378. StripOffsets and StripByteCounts are then arranged as a 2-dimensional array,
  379. with SamplesPerPixel rows and StripsPerImage columns.  (All of the columns for
  380. row 0 are stored first, followed by the columns of row 1, and so on.)
  381. PhotometricInterpretation describes the type of data that is stored in each
  382. sample plane.
  383.  
  384. If SamplesPerPixel is 1, a PlanarConfiguration value of 1 is equivalent to a
  385. value of 2.
  386. No default.
  387.  
  388.  
  389. Compression
  390. Tag  = 259  (103)
  391. Type = SHORT
  392. N    = SamplesPerPixel for PlanarConfiguration equal to 1 or 2.
  393.  
  394. Note that a value is provided for each sample, allowing different compression
  395. schemes to be applied to different planes of data.
  396.  
  397. 1 = No compression, but pack data into bytes as tightly as possible, with no
  398. unused bits except at the end of a row.  See also FillOrder.  The bytes are
  399. stored as an array of type BYTE, for BitsPerSample <= 8, SHORT if BitsPerSample
  400. > 8 and <= 16, and LONG if BitsPerSample > 16 and <= 32.  The byte ordering of
  401. data >8 bits must be consistent with that specified in the TIFF file header
  402. (bytes 0 and 1).  Intel format files will have the least significant bytes
  403. preceeding the most significant bytes while Motorola format files will have the
  404. opposite.
  405.  
  406. If the number of bits per sample is not a power of 2, and you are willing to
  407. give up some space for better performance, you may wish to use the next higher
  408. power of 2.  For example, if your data can be represented in 6 bits, you may
  409. wish to specify that it is 8 bits deep.  If you take this approach, you should
  410. be sure that MinSampleValue and MaxSampleValue are given correct values
  411. (probably 0 and 63 for intrinsically 6-bit data.)  TIFF file readers should use
  412. MinSampleValue and MaxSampleValue to determine the range of values in the data
  413. rather than BitsPerSample.
  414.  
  415. Rows are required to begin on byte boundaries.
  416.  
  417. 2 = CCITT Group 3 1-Dimensional Modified Huffman run length encoding.  See
  418. Appendix B: Data Compression Scheme 2.  BitsPerSample must be 1, since this
  419. type of compression is defined only for binary images.
  420.  
  421. 3 = Facsimile-compatible CCITT Group 3, exactly as specified in Standardization
  422. of Group 3 facsimile apparatus for document transmission, Recommendation T.4,
  423. Volume VII, Fascicle VII.3, Terminal Equipment and Protocols for Telematic
  424. Services, The International Telegraph and Telephone Consultative Committee
  425. (CCITT), Geneva, 1985, pages 16 through 31.  Each strip must begin on a byte
  426. boundary.  (But recall that an image can be a single strip.)  Rows that are not
  427. the first row of a strip are not required to begin on a byte boundary.  The
  428. data is stored as bytes, not words byte-reversal is not allowed.  Note that
  429. the FillOrder field still applies.  See the Group3Options field for Group 3
  430. options such as 1D vs 2D coding.
  431.  
  432. 4 = Facsimile-compatible CCITT Group 4, exactly as specified in Facsimile
  433. Coding Schemes and Coding Control Functions for Group 4 Facsimile Apparatus,
  434. Recommendation T.6, Volume VII, Fascicle VII.3, Terminal Equipment and
  435. Protocols for Telematic Services, The International Telegraph and Telephone
  436. Consultative Committee (CCITT), Geneva, 1985, pages 40 through 48.  Each strip
  437. must begin on a byte boundary.  Rows that are not the first row of a strip are
  438. not required to begin on a byte boundary.  The data is stored as bytes, not
  439. words.  Note that the FillOrder field still applies.  See the Group4Options
  440. field for Group 4 options.
  441.  
  442. 32771 = the same thing as Compression type 1 (no compression), except that each
  443. row begins on the next available word boundary, instead of byte boundary.
  444.  
  445. 32773 = PackBits compression, a relatively simple byte-oriented run-length
  446. scheme.  See Appendix C.
  447.  
  448. Data compression only applies to pixel data, as pointed to by StripOffsets.
  449. All other TIFF information is unaffected.
  450.  
  451. To be determined are additional compression schemes for gray and colored
  452. images.  We encourage your suggestions, especially if accompanied by full
  453. specifications and performance information.  It is of course desirable to
  454. minimize the number of compression schemes that are being used, but this is
  455. clearly an area in which extremely significant time and space tradeoffs exist.
  456. Default = 1.
  457.  
  458.  
  459. Group3Options
  460. Tag  = 292  (124)
  461. Type = LONG
  462. N    = 1
  463.  
  464. This field is made up of a set of 32 flag bits.  Unused bits are expected to be
  465. 0.  Bit 0 is the low-order bit.  It is probably not safe to try to read the
  466. file if any bit of this field is set that you dont know the meaning of.
  467.  
  468. Bit 0 is 1 for 2-dimensional coding (else 1-dimensional is assumed).  For 2-D
  469. coding, if more than one strip is specified, each strip must begin with a
  470. 1-dimensionally coded line.  That is, RowsPerStrip should be a multiple of
  471. Parameter K as documented in the CCITT specification.
  472.  
  473. Bit 1 is 1 if uncompressed mode is used.
  474.  
  475. Bit 2 is 1 if fill bits have been added as necessary before EOL codes such that
  476. EOL always ends on a byte boundary, thus ensuring an eol-sequence of a 1 byte
  477. preceded by a zero nibble: xxxx-0000 0000-0001.
  478.  
  479. Default is 0, for basic 1-dimensional coding.
  480.  
  481.  
  482. Group4Options
  483. Tag  =  293  (125)
  484. Type = LONG
  485. N    = 1
  486.  
  487. This field is made up of a set of 32 flag bits.  Unused bits are expected to be
  488. 0.  Bit 0 is the low-order bit.  It is probably not safe to try to read the
  489. file if any bit of this field is set that you dont know the meaning of.  Gray
  490. scale and color coding schemes are under study, and will be added when
  491. finalized.
  492.  
  493. For 2-D coding, each strip is encoded as if it were a separate image.  In
  494. particular, each strip begins on a byte boundary; and the coding for the first
  495. row of a strip is encoded independently of the previous row, using horizontal
  496. codes, as if the previous row is entirely white.  Each strip ends with the
  497. 24-bit end-of-facsimile block (EOFB).
  498.  
  499. Bit 0 is unused.
  500.  
  501. Bit 1 is 1 if uncompressed mode is used.
  502.  
  503. Default is 0, for basic 2-dimensional binary compression.
  504.  
  505.  
  506. FillOrder
  507. Tag  = 266  (10A)
  508. Type = SHORT
  509. N    = 1
  510.  
  511. The order of data values within a byte.
  512. 1 = most significant bits of the byte are filled first.  That is, data values
  513. (or code words) are ordered from high order bit to low order bit within a byte.
  514.  
  515. 2 = least significant bits are filled first.
  516. Default is FillOrder = 1.
  517.  
  518.  
  519. Threshholding
  520. Tag  = 263  (107)
  521. Type = SHORT
  522. N    = 1
  523.  
  524. 1 = a bilevel line art scan.  BitsPerSample must be 1.
  525. 2 = a halftone or dithered scan, usually of continuous tone data such as
  526. photographs.  BitsPerSample must be 1.
  527. 3 = Error Diffused.
  528. Default is Threshholding = 1.
  529.  
  530.  
  531. CellWidth
  532. Tag  = 264  (108)
  533. Type = SHORT
  534. N    = 1
  535.  
  536. The width, in 1-bit samples, of the dithering/halftoning matrix.  Assumes that
  537. Threshholding = 2.  That is, this field is only relevant if Threshholding = 2.
  538.  
  539. No default.
  540.  
  541.  
  542. CellLength
  543. Tag  = 265  (109)
  544. Type = SHORT
  545. N    = 1
  546.  
  547. The length, in 1-bit samples, of the dithering/halftoning matrix.  Assumes that
  548. Threshholding = 2.  This field and the previous field may be useful for
  549. converting from halftoned to true gray level data.
  550. No default.
  551.  
  552.  
  553. Photometrics
  554.  
  555. These fields are useful in determining the visual meaning of the sample data.
  556.  
  557.  
  558. MinSampleValue
  559. Tag  = 280  (118)
  560. Type = SHORT
  561. N    = SamplesPerPixel
  562.  
  563. The minimum valid sample value.
  564. Default is 0.
  565.  
  566.  
  567. MaxSampleValue
  568. Tag  = 281  (119)
  569. Type = SHORT
  570. N    = SamplesPerPixel
  571.  
  572. The maximum valid sample value.
  573. Default is 2**(BitsPerSample) - 1.
  574.  
  575.  
  576. PhotometricInterpretation
  577. Tag  = 262  (106)
  578. Type = SHORT
  579. N    = 1
  580.  
  581. 0 = MinSampleValue should be imaged as white.  MaxSampleValue should be imaged
  582. as black.  If the bit-map represents gray scale, then the values between the
  583. minimum and maximum sample values should be interpreted according to either the
  584. gray scale response curve information (if included) or according to the result
  585. of some more arbitrary rule.  See GrayResponseCurve.
  586.  
  587. 1 = MinSampleValue should be imaged as black.  MaxSampleValue should be imaged
  588. as white.  If the bit-map represents gray scale, then the values between the
  589. minimum and maximum sample values should be interpreted according to either the
  590. gray scale response curve information (if included) or according to the result
  591. of some more arbitrary rule.
  592.  
  593. 2 = RGB.  In the RGB model, a color is described as a combination of the three
  594. primary colors of light (red, green, and blue) in particular concentrations.
  595. For each of the three samples, MinSampleValue represents minimum intensity, and
  596. MaxSampleValue represents maximum intensity.  For PlanarConfiguration = 1, the
  597. samples are stored in the indicated order within a pixel: first Red, then
  598. Green, then Blue.  For PlanarConfiguration = 2, the sample planes are stored in
  599. the indicated order: first the Red sample plane, then the Green plane, then
  600. the Blue plane.
  601.  
  602. The Red, Green and Blue intensity values are defined according to the NTSC
  603. specifications for primary color chromaticity.  These specifications assume the
  604. illumination to be CIE D6500.  See the Red, Green and Blue color response curve
  605. tags.
  606.  
  607. Note: some compression schemes, such as the CCITT schemes, imply a particular
  608. PhotometricInterpretation.  Therefore, when reading such data, TIFF readers
  609. should ignore PhotometricInterpretation.  And, ideally, TIFF writers should not
  610. write out the field when using one of these schemes.
  611.  
  612. No default.
  613.  
  614.  
  615. GrayResponseUnit
  616. Tag  = 290 (122)
  617. Type = SHORT
  618. N    = 1
  619.  
  620. 1 = number represents tenths of a unit.
  621. 2 = number represents hundredths of a unit.
  622. 3 = number represents thousandths of a unit.
  623. 4 = number represents ten-thousandths of a unit.
  624. 5 = number represents hundred-thousandths of a unit.
  625. Default is 2.
  626.  
  627.  
  628. GrayResponseCurve
  629. Tag  = 291 (123)
  630. Type = SHORT
  631. N    = 2**BitsPerSample
  632.  
  633. The purpose of the gray response curve and the gray units is to further provide
  634. photometric interpretation information for gray scale image data.  The gray
  635. response curve specifies for given levels of gray between the minimum and
  636. maximum sample values the actual photometric gray level of the value.  It
  637. represents this gray level in terms of optical density.
  638.  
  639. The GrayScaleResponseUnits specifies the accuracy of the information contained
  640. in the curve.  Since optical density is specified in terms of fractional
  641. numbers, this tag is necessary to know how to interpret the stored integer
  642. information.  For example, if GrayScaleResponseUnits is set to 4
  643. (ten-thousandths of a unit), and a GrayScaleResponseCurve number for gray level
  644. 4 is 3455, then the resulting actual value is 0.3455.
  645.  
  646. If the gray scale response curve is known for the data in the TIFF file, and if
  647. the gray scale response of the output device is known, then an intelligent
  648. conversion can be made between the input data and the output device.  For
  649. example, the output can be made to look just like the input.  In addition, if
  650. the input image lacks contrast (as can be seen from the response curve), then
  651. appropriate contrast enhancements can be made.
  652.  
  653. The purpose of the grey scale response curve is to act as a lookup table
  654. mapping values from 0 to 2**BitsPerSample-1 into specific intensity values.
  655. Refer to the PhotometricInterpretation tag to determine how the mapping should
  656. be done.
  657.  
  658.  
  659. ColorResponseUnit
  660. Tag  = 300 (12C)
  661. Type = SHORT
  662. N    = 1
  663.  
  664. 1 = number represents tenths of a unit.
  665. 2 = number represents hundredths of a unit.
  666. 3 = number represents thousandths of a unit.
  667. 4 = number represents ten-thousandths of a unit.
  668. 5 = number represents hundred-thousandths of a unit.
  669. Default is 2.
  670.  
  671.  
  672. ColorResponseCurves
  673. Tag  = 301 (12D)
  674. Type = SHORT
  675. N    = 2**BitsPerSample (for Red samples) +
  676.                 2**BitsPerSample (for Green samples) +
  677.                 2**BitsPerSample (for Blue samples)
  678.  
  679. This tag defines three color response curves (one each for Red, Green and Blue
  680. color information).  The curves are stored sequentially (in red-green-blue
  681. order).  The size of each table is 2**BitsPerSample, using the BitsPerSample
  682. value corresponding to the respective color.  The ColorResponseUnit further
  683. specifies how each entry in the table is to be interpreted.
  684.  
  685. The purpose of the color response curves is to act as a lookup table mapping
  686. values from 0 to 2**BitsPerSample-1 into specific intensity values.  The
  687. intensity values are as specified by the NTSC color strandard assuming
  688. illumination to be CIE D6500.
  689.  
  690.  
  691. Correspondence to the Physical World
  692.  
  693. XResolution
  694. Tag  = 282  (11A)
  695. Type = RATIONAL
  696. N    = 1
  697.  
  698. The number of pixels per ResolutionUnit (see below) in the X direction, i.e.,
  699. in the ImageWidth direction.  It is, of course, not mandatory that the image be
  700. actually printed at the size implied by this parameter.  It is up to the
  701. application to use this information as it wishes.
  702.  
  703. As is the case for many of these fields, XResolution may be invalid and
  704. irrelevant for some images (e.g., images made with a hand-held digitizing
  705. camera, which has a three-dimensional nature) and should therefore be absent
  706. from the image file.
  707. No default.
  708.  
  709.  
  710.  
  711. YResolution
  712. Tag  = 283  (11B)
  713. Type = RATIONAL
  714. N    = 1
  715.  
  716. The number of pixels per ResolutionUnit in the Y direction, i.e., in the
  717. ImageLength direction.
  718. No default.
  719.  
  720.  
  721. ResolutionUnit
  722. Tag  = 296 (128)
  723. Type = SHORT
  724. N    = 1
  725.  
  726. To be used with XResolution and YResolution.
  727. 1 = no absolute unit of measurement.  Used for images that may have a
  728. non-square aspect ratio, but no meaningful absolute dimensions.
  729. 2 = inch
  730. 3 = centimeter
  731. Default is 2
  732.  
  733.  
  734. Orientation
  735. Tag  = 274 (112)
  736. Type = SHORT
  737. N    = 1
  738.  
  739. 1 =  The 0th row represents the visual top of the image, and the 0th column
  740. represents the visual left hand side.
  741. 2 =  The 0th row represents the visual top of the image, and the 0th column
  742. represents the visual right hand side.
  743. 3 =  The 0th row represents the visual bottom of the image, and the 0th column
  744. represents the visual right hand side.
  745. 4 =  The 0th row represents the visual bottom of the image, and the 0th column
  746. represents the visual left hand side.
  747. 5 =  The 0th row represents the visual left hand side of the image, and the 0th
  748. column represents the visual top.
  749. 6 =  The 0th row represents the visual right hand side of the image, and the
  750. 0th column represents the visual top.
  751. 7 =  The 0th row represents the visual right hand side of the image, and the
  752. 0th column represents the visual bottom.
  753. 8 =  The 0th row represents the visual left hand side of the image, and the 0th
  754. column represents the visual bottom.
  755. Default is 1.
  756.  
  757.  
  758. Document Context
  759.  
  760. DocumentName
  761. Tag  = 269  (10D)
  762. Type = ASCII
  763.  
  764. The name of the document from which this image was scanned.
  765. No default.
  766.  
  767.  
  768. PageName
  769. Tag  = 285  (11D)
  770. Type = ASCII
  771.  
  772. The name of the page from which this image was scanned.
  773. No default.
  774.  
  775.  
  776. XPosition
  777. Tag  = 286  (11E)
  778. Type = RATIONAL
  779.  
  780. The X offset of the left side of the image, with respect to the left side of
  781. the page, in inches.
  782. No default.
  783.  
  784.  
  785. YPosition
  786. Tag  = 287  (11F)
  787. Type = RATIONAL
  788.  
  789. The Y offset of the top of the image, with respect to the top of the page, in
  790. inches.  In the TIFF coordinate scheme, the positive Y direction is down, so
  791. that YPosition is always positive.
  792. No default.
  793.  
  794.  
  795. PageNumber
  796. Tag  = 297  (129)
  797. Type = SHORT
  798. N    = 2
  799.  
  800. This tag is used to specify page numbers of a multiple page (e.g. facsimile)
  801. document.  Two SHORT values are specified.  The first value is the page number;
  802. the second value is the total number of pages in the document.
  803.  
  804. Note that pages need not appear in numerical order.
  805.  
  806.  
  807.  
  808. Miscellaneous Strings
  809.  
  810. ImageDescription
  811. Tag  = 270 (10E)
  812. Type = ASCII
  813.  
  814. Useful or interesting information about the image.
  815. No default.
  816.  
  817.  
  818. Make
  819. Tag  = 271  (10F)
  820. Type = ASCII
  821.  
  822. The name of the scanner manufacturer.
  823. No default.
  824.  
  825.  
  826. Model
  827. Tag  = 272  (110)
  828. Type = ASCII
  829.  
  830. The model name/number of the scanner.
  831. No default.
  832.  
  833.  
  834. Storage Management
  835.  
  836. These fields may be useful in certain dynamic editing situations.  Software
  837. that merely reads TIFF files will probably not need to care about these fields.
  838. And, of course, software that creates TIFF files is by no means required to
  839. write these fields.
  840.  
  841. FreeOffsets
  842. Tag  = 288  (120)
  843. Type = LONG
  844.  
  845. For each free block in the file, its byte offset.
  846. No default.
  847.  
  848.  
  849. FreeByteCounts
  850. Tag  = 289  (121)
  851. Type = LONG
  852.  
  853. For each free block in the file, the number of bytes in the block.
  854.  
  855.  
  856.  
  857. 6) Examples
  858.  
  859. A binary image from a paint program might contain only SubfileType, ImageWidth,
  860. ImageLength, StripOffsets, and PhotometricInterpretation fields.
  861.  
  862. A typical line art scan might require that XResolution and YResolution be added
  863. to the above list.
  864.  
  865.  
  866.  
  867. 7) Private Fields
  868.  
  869. An organization may wish to store with the image file information that is
  870. meaningful only to that organization.  Tags numbered 32768 or higher are
  871. reserved for that purpose.  Upon request, the administrator will allocate and
  872. register a block of private tags for an organization, to avoid possible
  873. conflicts with other organizations.
  874.  
  875. Private enumerated values can be accommodated in a similar fashion.
  876. Enumeration constants numbered 32768 or higher are reserved for private usage.
  877. Upon request, the administrator will allocate and register a block of
  878. enumerated values for a particular field, to avoid possible conflicts.
  879.  
  880. Tags and values which are allocated in the private number range are not
  881. prohibited from being included in a future revision of this specification.
  882. Several such instances can be found in this revision.
  883.  
  884.  
  885. 8) A List of Possible Future Enhancements
  886.  
  887. In the future TIFF will very likely be expanded to support more compression
  888. schemes, more photometric schemes, color lookup tables, and non-rectangular
  889. images.  Please refer all questions regarding enhancements to TIFF to the
  890. contacts listed at the beginning of the document.  Written submissions should
  891. be in Microsoft Windows Write format, to ensure timely and error-free
  892. incorporation into the specification.
  893.  
  894. Tag Image File Format  Rev 4.0
  895. April 31, 1987
  896.  
  897. Appendix A: Tag Structure Rationale
  898.  
  899.  
  900. A file format is defined by both form (structure) and content.  The content
  901. of TIFF consists of definitions of individual fields.  It is therefore the
  902. content that we are ultimately interested in.  The structure merely tells us
  903. how to find the fields.
  904.  
  905. Yet the structure deserves serious consideration for a number of reasons that
  906. are not at all obvious at first glance.  Since the structure described herein
  907. departs significantly from several other approaches, it may be useful to
  908. discuss the rationale behind it.
  909.  
  910. The simplest, most straightforward structure for something like an image file
  911. is a positional format.  In a positional scheme, the location of the data
  912. defines what the data means.  For example, the field for number of rows might
  913. begin at byte offset 30 in the image file.
  914.  
  915. This approach is simple and easy to implement and is perfect for static
  916. environments.  But if a significant amount of ongoing change must be
  917. accommodated, some subtle problems start showing up.  For example, suppose
  918. that a field must be superseded by a new, more general field.  You could bump
  919. a version number to flag the change.  Then new software has no problem doing
  920. something sensible with old data, and all old software will reject the new
  921. data, even software that didnt care about the old field.  This may seem like
  922. no more than a minor annoyance at first glance, but causing old software to
  923. break more often than it would really need to can be very costly and,
  924. inevitably, causes much gnashing of teeth among customers.
  925.  
  926. Furthermore, it can be avoided.  One approach is to store a valid flag bit
  927. for each field.  Now you dont have to bump the version number, as long as you
  928. can put the new field somewhere that doesnt disturb any of the old fields.
  929. Old software that didnt care about that old field anyway can continue to
  930. function.  (Old software that did care will of course have to give up, but
  931. this is an unavoidable price to be paid for the sake of progress, barring
  932. total omniscience.)
  933.  
  934. Another problem that crops up frequently is that certain fields are likely to
  935. make sense only if other fields have certain values.  This is not such a
  936. serious problem in practice; it just makes things more confusing.
  937. Nevertheless, we note that the valid flag bits described in the previous
  938. paragraph can help to clarify the situation.
  939.  
  940. Field-dumping programs can be very helpful for diagnostic purposes.  A
  941. desirable characteristic of such a program is that it doesnt have to know
  942. much about what it is dumping.  In particular, it would be nice if the
  943. program could dump ASCII data in ASCII format, integer data in integer
  944. format, and so on, without having to teach the program about new fields all
  945. the time.  So maybe we should add a data type component to our fields, plus
  946. information on how long the field is, so that our dump program can walk
  947. through the fields without knowing what the fields mean.
  948.  
  949. But note that if we add one more component to each field, namely a tag that
  950. tells what the field means, we can dispense with the valid flag bits, and we
  951. can also avoid wasting space on the non-valid fields in the file.  Simple
  952. image creation applications can write out several fields and be done.
  953.  
  954. We have now derived the essentials of a tag based image file format.
  955.  
  956. Finally, a caveat.  A tag based scheme cannot guarantee painless growth.  But
  957. is does provide a useful tool to assist in the process.
  958.  
  959.  
  960.  
  961.  
  962.                       Table 1/T.4
  963.  
  964.                      Make-up codes
  965.  
  966.                    Terminating codes
  967.  
  968.  
  969. White run        Code word       Black run       Code word
  970.  length                                           length
  971.  
  972.      0           00110101           0            0000110111
  973.      1           000111             1            010
  974.      2           0111               2            11
  975.      3           1000               3            10
  976.      4           1011               4            011
  977.      5           1100               5            0011
  978.      6           1110               6            0010
  979.      7           1111               7            00011
  980.      8           10011              8            000101
  981.      9           10100              9            000100
  982.     10           00111             10            0000100
  983.     11           01000             11            0000101
  984.     12           001000            12            0000111
  985.     13           000011            13            00000100
  986.     14           110100            14            00000111
  987.     15           110101            15            000011000
  988.     16           101010            16            0000010111
  989.     17           101011            17            0000011000
  990.     18           0100111           18            0000001000
  991.     19           0001100           19            00001100111
  992.     20           0001000           20            00001101000
  993.     21           0010111           21            00001101100
  994.     22           0000011           22            00000110111
  995.     23           0000100           23            00000101000
  996.     24           0101000           24            00000010111
  997.     25           0101011           25            00000011000
  998.     26           0010011           26            000011001010
  999.     27           0100100           27            000011001011
  1000.     28           0011000           28            000011001100
  1001.     29           00000010          29            000011001101
  1002.     30           00000011          30            000001101000
  1003.     31           00011010          31            000001101001
  1004.     32           00011011          32            000001101010
  1005.     33           00010010          33            000001101011
  1006.     34           00010011          34            000011010010
  1007.     35           00010100          35            000011010011
  1008.     36           00010101          36            000011010100
  1009.     37           00010110          37            000011010101
  1010.     38           00010111          38            000011010110
  1011.     39           00101000          39            000011010111
  1012.     40           00101001          40            000001101100
  1013.     41           00101010          41            000001101101
  1014.     42           00101011          42            000011011010
  1015.     43           00101100          43            000011011011
  1016.     44           00101101          44            000001010100
  1017.     45           00000100          45            000001010101
  1018.     46           00000101          46            000001010110
  1019.     47           00001010          47            000001010111
  1020.     48           00001011          48            000001100100
  1021.     49           01010010          49            000001100101
  1022.     50           01010011          50            000001010010
  1023.     51           01010100          51            000001010011
  1024.     52           01010101          52            000000100100
  1025.     53           00100100          53            000000110111
  1026.     54           00100101          54            000000111000
  1027.     55           01011000          55            000000100111
  1028.     56           01011001          56            000000101000
  1029.     57           01011010          57            000001011000
  1030.     58           01011011          58            000001011001
  1031.     59           01001010          59            000000101011
  1032.     60           01001011          60            000000101100
  1033.     61           00110010          61            000001011010
  1034.     62           00110011          62            000001100110
  1035.     63           00110100          63            000001100111
  1036.  
  1037.  
  1038.  
  1039.                       Table 2/T.4
  1040.  
  1041.                      Make-up codes
  1042.  
  1043.  
  1044. White run        Code word       Black run       Code word
  1045.  length                                           length
  1046.  
  1047.     64           11011             64            0000001111
  1048.    128           10010            128            000011001000
  1049.    192           010111           192            000011001001
  1050.    256           0110111          256            000001011011
  1051.    320           00110110         320            000000110011
  1052.    384           00110111         384            000000110100
  1053.    448           01100100         448            000000110101
  1054.    512           01100101         512            0000001101100
  1055.    576           01101000         576            0000001101101
  1056.    640           01100111         640            0000001001010
  1057.    704           011001100        704            0000001001011
  1058.    768           011001101        768            0000001001100
  1059.    832           011010010        832            0000001001101
  1060.    896           011010011        896            0000001110010
  1061.    960           011010100        960            0000001110011
  1062.   1024           011010101        1024           0000001110100
  1063.   1088           011010110        1088           0000001110101
  1064.   1152           011010111        1152           0000001110110
  1065.   1216           011011000        1216           0000001110111
  1066.   1280           011011001        1280           0000001010010
  1067.   1344           011011010        1344           0000001010011
  1068.   1408           011011011        1408           0000001010100
  1069.   1472           010011000        1472           0000001010101
  1070.   1536           010011001        1536           0000001011010
  1071.   1600           010011010        1600           0000001011011
  1072.   1664           011000           1664           0000001100100
  1073.   1728           010011011        1728           0000001100101
  1074.   EOL            000000000001     EOL            000000000001
  1075.  
  1076.  
  1077.  
  1078. Note  it is recognized that machines exist which accommodate larger paper
  1079. widths whilst maintaining the standard horizontal resolution.  This option
  1080. has been provided for by the addition of the Make-up code set defined as
  1081. follows:
  1082.  
  1083.  
  1084.                      Run length              Make-up codes
  1085.                   (black and white)
  1086.  
  1087.                         1792                  00000001000
  1088.                         1856                  00000001100
  1089.                         1920                  00000001101
  1090.                         1984                  000000010010
  1091.                         2048                  000000010011
  1092.                         2112                  000000010100
  1093.                         2176                  000000010101
  1094.                         2240                  000000010110
  1095.                         2304                  000000010111
  1096.                         2368                  000000011100
  1097.                         2432                  000000011101
  1098.                         2496                  000000011110
  1099.                         2560                  000000011111
  1100.  
  1101.  
  1102.  
  1103.  
  1104. Appendix B: Data Compression Scheme 2
  1105.  
  1106.  
  1107. Abstract
  1108.  
  1109. This document describes a method for compressing bilevel data that is based
  1110. on the CCITT Group 3 1D facsimile compression scheme.  It is intended that it
  1111. be used in conjunction with the Tag Image File Format.
  1112.  
  1113.  
  1114. References
  1115.  
  1116. 1.  Standardization of Group 3 facsimile apparatus for document transmission,
  1117. Recommendation T.4, Volume VII, Fascicle VII.3, Terminal Equipment and
  1118. Protocols for Telematic Services, The International Telegraph and Telephone
  1119. Consultative Committee (CCITT), Geneva, 1985, pages 16 through 31.
  1120.  
  1121. 2.  Facsimile Coding Schemes and Coding Control Functions for Group 4
  1122. Facsimile Apparatus, Recommendation T.6, Volume VII, Fascicle VII.3, Terminal
  1123. Equipment and Protocols for Telematic Services, The International Telegraph
  1124. and Telephone Consultative Committee (CCITT), Geneva, 1985, pages 40 through
  1125. 48.
  1126.  
  1127.  
  1128. Relationship to the CCITT Specifications
  1129.  
  1130. The CCITT Group 3 and Group 4 specifications describe communications
  1131. protocols for a particular class of devices.  They are not by themselves
  1132. sufficient to describe a disk data format.  Fortunately, however, the CCITT
  1133. coding schemes can be readily adapted to this different environment.  The
  1134. following is one such adaptation.
  1135.  
  1136.  
  1137. Coding Scheme
  1138.  
  1139. A line (row) of data is composed of a series of variable length code words.
  1140. Each code word represents a run length of either all white or all black.
  1141. (Actually, more than one code word may be required to code a given run, in a
  1142. manner described below.)  White runs and black runs alternate.
  1143.  
  1144. In order to ensure that the receiver (decompressor) maintains color
  1145. synchronization, all data lines will begin with a white run length code word
  1146. set.  If the actual scan line begins with a black run, a white run length of
  1147. zero will be sent (written).  Black or white run lengths are defined by the
  1148. code words in Tables 1 and 2.  The code words are of two types: Terminating
  1149. code words and Make-up code words.  Each run length is represented by zero or
  1150. more Make-up code words followed by exactly one Terminating code word.
  1151.  
  1152. Run lengths in the range of 0 to 63 pels (pixels) are encoded with their
  1153. appropriate Terminating code word.  Note that there is a different list of
  1154. code words for black and white run lengths.
  1155.  
  1156. Run lengths in the range of 64 to 2623 (2560+63) pels are encoded first by
  1157. the Make-up code word representing the run length that is nearest to, not
  1158. longer than, that required.  This is then followed by the Terminating code
  1159. word representing the difference between the required run length and the run
  1160. length represented by the Make-up code.
  1161.  
  1162. Run lengths in the range of lengths longer than or equal to 2624 pels are
  1163. coded first by the Make-up code of 2560.  If the remaining part of the run
  1164. (after the first Make-up code of 2560) is 2560 pels or greater, additional
  1165. Make-up code(s) of 2560 are issued until the remaining part of the run
  1166. becomes less than 2560 pels.  Then the remaining part of the run is encoded
  1167. by Terminating code or by Make-up code plus Terminating code, according to
  1168. the range mentioned above.
  1169.  
  1170. It is considered an unrecoverable error if the sum of the run lengths for a
  1171. line do not equal the value of the ImageWidth field.
  1172.  
  1173. New rows always begin on the next available byte boundary.
  1174.  
  1175. No EOL code words are used.  No fill bits are used, except for the ignored
  1176. bits at the end of the last byte of a row.  RTC is not used.
  1177.  
  1178.  
  1179.  
  1180.  
  1181. Appendix C: Data Compression Scheme 32773 PackBits
  1182.  
  1183.  
  1184. Abstract
  1185.  
  1186. This document describes a compression scheme for paint type files.  It is
  1187. intended for use in conjunction with the Tag Image File Format.
  1188.  
  1189.  
  1190. 1) Motivation
  1191.  
  1192. The current TIFF specification allows for two compression schemes.
  1193. Compression type 1 is really no compression, other than basic pixel packing.
  1194. Compression type 2, based on CCITT 1D compression, is powerful, but not
  1195. trivial to implement and is designed for scanned data more than data
  1196. generated by paint programs.  Simple byte-oriented run length schemes tend to
  1197. work well with paint data, since paint data often has large areas of white
  1198. space and areas filled with 8-bit patterns.
  1199.  
  1200.  
  1201. 2) Description
  1202.  
  1203. Since several good schemes already exist, we may as well use one of them.  We
  1204. somewhat arbitrarily pick the Macintosh PackBits scheme.  It is byte
  1205. oriented, so there is no problem with word alignment.  And it has a good
  1206. worst case behavior (at most 1 extra byte for every 128 input bytes).  For
  1207. Macintosh users, there are toolbox utilities PackBits and UnPackBits that
  1208. will do the work for you, but it is easy to implement your own.
  1209.  
  1210. A pseudo code fragment to unpack it might look like this:
  1211.  
  1212. Loop until you get the number of unpacked bytes you are expecting:
  1213.     Read the next source byte into n.
  1214.     If n is between 0 and 127 inclusive, copy the next n+1 bytes literally.
  1215.     Else if n is between -127 and -1 inclusive, copy the next byte -n+1 times.
  1216.     Else if n is 128, noop.
  1217. Endloop
  1218.  
  1219. In the inverse routine, its best to encode a 2 byte repeat run as a replicate
  1220. run except when preceded and followed by a literal run, in which case its
  1221. best to merge the three into one literal run.  Always encode 3 byte repeats
  1222. as replicate runs.
  1223.  
  1224. So thats the algorithm.  Other rules:
  1225.  
  1226. Each row must be packed separately.  Do not compress across row boundaries.
  1227.  
  1228. The number of uncompressed bytes per row is defined to be (ImageWidth + 7) /
  1229. 8.  If the uncompressed bitmap is required to have an even number of bytes
  1230. per row, decompress into word-aligned buffers.
  1231.  
  1232. If a run is larger than 128 bytes, simply encode the remainder of the run as
  1233. one or more additional replicate runs.
  1234.  
  1235. When PackBits data is uncompressed, the result should be interpreted as per
  1236. compression type 1 (no compression); i.e. the SamplesPerPixel, BitsPerSample
  1237. and PlanarConfiguration tags should be consulted to interpret the image.
  1238.  
  1239.  
  1240.  
  1241.  
  1242. Appendix D: Using the Microsoft Windows Clipboard
  1243.  
  1244. The Microsoft Windows Clipboard provides a mechanism that allows applications
  1245. to pass information to each other.  Pictures created in Microsoft Paint, for
  1246. example, may be passed as bitmaps to Microsoft Write.
  1247.  
  1248. In general, the Clipboard is not recommended as a way of passing TIFF
  1249. information between applications.  The amount of data associate with image
  1250. data can be very large.  Currently, data passed through the Microsoft Windows
  1251. Clipboard is limited to 64K bytes.  It is suggested that applications employ
  1252. file-based mechanisms to exchange TIFF data.  Aldus PageMaker, for example,
  1253. implements a File Place command to allow TIFF files to be imported.
  1254.  
  1255. For images requiring less than 64K bytes of TIFF data, a new Clipboard format
  1256. has been defined:
  1257.  
  1258.            CF_TIFF             Microsoft Tag Image File Format
  1259.  
  1260. (this symbol will be defined in the windows.h file distributed with the
  1261. Microsoft Windows Software Development Kit.)
  1262.  
  1263. The data associated with this format is a handle to a block of global memory
  1264. containing the same data as would be stored in a disk TIFF file.  When
  1265. interpreting this memory, TIFF readers should interpret file offsets as
  1266. offsets from the beginning of the memory block.
  1267.  
  1268. Applications that are capable of passing TIFF information through the
  1269. Microsoft Windows Clipboard should preferably not render the TIFF information
  1270. until requested to do so.  In addition to passingTIFF data, these
  1271. applications should also place bitmaps (Clipboard format CF_BITMAP) on the
  1272. Clipboard corresponding to the TIFF data.  Applications should judge whether
  1273. to render these bitmaps formatted for the display or for the currently
  1274. selected output device.  Placing a bitmap on the Clipboard will allow the
  1275. Clipboard viewer application (CLIPBRD.EXE) to display a likeness of the image
  1276. and will allow non-TIFF applications to import, at least, an approximate
  1277. bitmap.  These and other Clipboard techniques are described in the Microsoft
  1278. Windows Programming Guide, a document in the Microsoft Windows Software
  1279. Development Kit.
  1280.  
  1281.  
  1282.  
  1283.  
  1284. Appendix E: Numerical List of TIFF Tags
  1285.  
  1286.  
  1287. SubfileType
  1288. Tag     = 255  (FF)
  1289. Type    = SHORT
  1290. N       = 1
  1291.  
  1292. ImageWidth
  1293. Tag     = 256  (100)
  1294. Type    = SHORT
  1295. N       = 1
  1296.  
  1297. ImageLength
  1298. Tag     = 257  (101)
  1299. Type    = SHORT
  1300. N       = 1
  1301.  
  1302. BitsPerSample
  1303. Tag     = 258  (102)
  1304. Type    = SHORT
  1305. N       = SamplesPerPixel
  1306.  
  1307. Compression
  1308. Tag     = 259  (103)
  1309. Type    = SHORT
  1310. N       = SamplesPerPixel for PlanarConfiguration equal to 1 or 2.
  1311.  
  1312. PhotometricInterpretation
  1313. Tag     = 262  (106)
  1314. Type    = SHORT
  1315. N       = 1
  1316.  
  1317. Threshholding
  1318. Tag     = 263  (107)
  1319. Type    = SHORT
  1320. N       = 1
  1321.  
  1322. CellWidth
  1323. Tag     = 264  (108)
  1324. Type    = SHORT
  1325. N       = 1
  1326.  
  1327. CellLength
  1328. Tag     = 265  (109)
  1329. Type    = SHORT
  1330. N       = 1
  1331.  
  1332. FillOrder
  1333. Tag     = 266  (10A)
  1334. Type    = SHORT
  1335. N       = 1
  1336.  
  1337. DocumentName
  1338. Tag     = 269  (10D)
  1339. Type    = ASCII
  1340.  
  1341. ImageDescription
  1342. Tag     = 270 (10E)
  1343. Type    = ASCII
  1344.  
  1345. Make
  1346. Tag     = 271  (10F)
  1347. Type    = ASCII
  1348.  
  1349. Model
  1350. Tag     = 272  (110)
  1351. Type    = ASCII
  1352.  
  1353. StripOffsets
  1354. Tag     = 273  (111)
  1355. Type    = SHORT or LONG
  1356. N       = StripsPerImage for PlanarConfiguration equal to 1.
  1357.         = SamplesPerPixel * StripsPerImage for PlanarConfiguration equal to 2
  1358.  
  1359. Orientation
  1360. Tag     = 274 (112)
  1361. Type    = SHORT
  1362. N               = 1
  1363.  
  1364. SamplesPerPixel
  1365. Tag     = 277  (115)
  1366. Type    = SHORT
  1367. N       = 1
  1368.  
  1369. RowsPerStrip
  1370. Tag     = 278  (116)
  1371. Type    = SHORT or LONG
  1372. N       = 1
  1373.  
  1374. StripByteCounts
  1375. Tag     = 279  (117)
  1376. Type    = LONG
  1377. N       = StripsPerImage for PlanarConfiguration equal to 1.
  1378.         = SamplesPerPixel * StripsPerImage for PlanarConfiguration equal to 2
  1379.  
  1380. MinSampleValue
  1381. Tag     = 280  (118)
  1382. Type    = SHORT
  1383. N       = SamplesPerPixel
  1384.  
  1385. MaxSampleValue
  1386. Tag     = 281  (119)
  1387. Type    = SHORT
  1388. N       = SamplesPerPixel
  1389.  
  1390. XResolution
  1391. Tag     = 282  (11A)
  1392. Type    = RATIONAL
  1393. N       = 1
  1394.  
  1395. YResolution
  1396. Tag     = 283  (11B)
  1397. Type    = RATIONAL
  1398. N       = 1
  1399.  
  1400. PlanarConfiguration
  1401. Tag     = 284  (11C)
  1402. Type    = SHORT
  1403. N       = 1
  1404.  
  1405. PageName
  1406. Tag     = 285  (11D)
  1407. Type    = ASCII
  1408.  
  1409. XPosition
  1410. Tag     = 286  (11E)
  1411. Type    = RATIONAL
  1412.  
  1413. YPosition
  1414. Tag     = 287  (11F)
  1415. Type    = RATIONAL
  1416.  
  1417. FreeOffsets
  1418. Tag     = 288  (120)
  1419. Type    = LONG
  1420.  
  1421. FreeByteCounts
  1422. Tag     = 289  (121)
  1423. Type    = LONG
  1424.  
  1425. GrayResponseUnit
  1426. Tag     = 290 (122)
  1427. Type    = SHORT
  1428. N       = 1
  1429.  
  1430. GrayResponseCurve
  1431. Tag     = 291 (123)
  1432. Type    = SHORT
  1433. N       = 2**BitsPerSample
  1434.  
  1435. Group3Options
  1436. Tag     = 292  (124)
  1437. Type    = LONG
  1438. N       = 1
  1439.  
  1440. Group4Options
  1441. Tag     =  293  (125)
  1442. Type    = LONG
  1443. N       = 1
  1444.  
  1445. ResolutionUnit
  1446. Tag     = 296 (128)
  1447. Type    = SHORT
  1448. N       = 1
  1449.  
  1450. PageNumber
  1451. Tag     = 297  (129)
  1452. Type    = SHORT
  1453. N       = 2
  1454.  
  1455. ColorResponseUnit
  1456. Tag     = 300 (12C)
  1457. Type    = SHORT
  1458. N       = 1
  1459.  
  1460. ColorResponseCurves
  1461. Tag     = 301 (12D)
  1462. Type    = SHORT
  1463. N       = 2**BitsPerSample (for Red sample)+
  1464.                 2**BitsPerSample (for Green sample)+
  1465.                 2**BitsPerSample(for Blue sample)
  1466.  
  1467.  
  1468.  
  1469.