the tiff image file format.htm

Tiff Image File format(英文版)

<HR>
<I>
<P>Notes</I>:</P>
<DIR>
<P>a. <I>"Tag length"</I> is really the number of items of tag type to follow, 
not the length in bytes.</P>
<P>b. A question mark indicates a variable number of data items.</P>
<P>c. Some tags can be <I>short</I> or <I>long</I> according to the TIFF 
specification.</P>
<P>&nbsp;</P></DIR>
<HR>
<B>
<P>Figure 3.</B> TIFF tag summary.</P><FONT size=2>
<P align=justify>The "type" field indicates the data type of the image 
parameter. Five unique data types are currently defined by the TIFF 
specification. Each data type is assigned an integer number which is stored in 
the "type" field of a DE. The data types are as follows:</P>
<P align=justify>&nbsp;</P></FONT>
<HR>

<DIR>
<P><I>Tag Type Tag Enumeration Type Description</I></P>
<P>BYTE 1 An 8-bit unsigned integer</P>
<P>ASCII 2 8-bit ASCII codes terminated with a null (hex 0) character
<P>
<P align=justify>SHORT 3 A 16-bit (2-byte) unsigned integer</P>
<P align=justify>LONG 4 A 32-bit (4-byte) unsigned integer</P>
<P align=justify>RATIONAL 5 Two LONG values. The first represents the numerator 
of a fraction, the second the denominator</P></DIR>
<HR>
<FONT size=2>
<P align=justify>The DE "length" (sometimes called the "count") field contains 
the number of items of the specified data type provided. It is specified in 
terms of the data type, not the total number of bytes required for storage. A 
single SHORT tag (data type 3) has a length of one and not two, for example.</P>
<P align=justify>&nbsp;</P>
<P align=justify>The final field in a DE is the "value offset" field. This field 
usually contains the file offset to the actual data associated with the tag. In 
other words, the data associated with a DE does not have to be physically stored 
with the DE but can reside anywhere in the TIFF file. Again, data pointers must 
be followed to find the actual data. If the data associated with a DE is four 
bytes or less in length, it can be stored in the "value offset" field directly 
instead of at a location pointed to by the this field. This was done to increase 
TIFF performance when retrieving small data items. Any data stored in "value 
offset" must be left justified (stored toward the lower-numbered bytes). The 
"type" and "length" fields must be consulted to determine if the total amount of 
storage required by a data item is four or fewer bytes and therefore whether it 
can be stored directly in the "value offset" field.</P>
<P align=justify>&nbsp;</P>
<P align=justify>If the data type for a tag is ASCII, a null (hex 0) terminated 
string of characters is expected. No length byte is provided as is the case with 
Pascal strings. Of course, the null terminated string is exactly what "C" 
expects. The "length" field for an ASCII tag includes the null terminating 
character. The "length" field does not, however, include any padding of the 
ASCII string that may be required.</P>
<P align=justify>&nbsp;</P>
<P align=justify>The raster data contained in a TIFF file is organized into 
groups of scan lines (or rows) of image data called <I>strips.</I> This 
organization helps reduce the memory requirements of TIFF readers because the 
complete image file does not have to be resident in memory all at once. Only 
enough memory must be available to buffer a <I>single strip</I> of image data at 
a time. Many of the early TIFF writing programs produced single-strip images 
that are difficult for many readers to read because of memory constraints. While 
this is legal according to the specification, the specification recommends that 
strips be limited to 8 KB (8,192 bytes) or less in length. The code provided in 
the TIFF function library can handle strips with lengths to approximately 60,000 
bytes.</P>
<P align=justify>&nbsp;</P></FONT><FONT size=5>
<P align=justify>TIFF Data Compression</FONT> <FONT size=2></FONT>(For 
information only)</P><FONT size=2>
<P align=justify>&nbsp;</P>
<P align=justify>As pointed out earlier, bit-mapped images require an incredible 
amount of memory for storage. To reduce the size of TIFF image files, the TIFF 
specification recommends support for four different types of data compression. A 
TIFF writer must support at least one of the compression methods. A TIFF reader 
should be able to understand all of the compression methods. The method utilized 
to compress an image is stored in the "compression" tag. A TIFF reader must read 
the "Compression" tag to determine the type of data expansion to apply to the 
raster data contained in the TIFF file. Please note, data compression applies 
only to the image raster data. All other items of information contained in a 
TIFF file (the IFH, the IFDs, and the DEs) are <I>not</I> compressed in any way. 
The compression methods and their tag values are as follows:</P></FONT>
<HR>
<B>
<P align=justify>Compression</P>
<DIR>
<P align=justify>Tag Value Compression Type</P></DIR></B>
<HR>

<DIR>
<P align=justify>1 No compression but bytes are tightly packed</P>
<P align=justify>2 CCITT Group 3 1-Dimensional modified Huffman RLE</P>
<P align=justify>3 Facsimile compatible CCITT Group 3</P>
<P align=justify>4 Facsimile compatible CCITT Group 4</P>
<P align=justify>5 LZW (Lempel-Ziv &amp; Welch) </P>
<P align=justify>32,773 PackBits (Macintosh)</P></DIR>
<P align=justify>&nbsp;</P>
<HR>

<P align=justify>&nbsp;</P><FONT size=2>
<P align=justify>The TIFF specification does not recommend storing images in 
non-compressed form because of the size of the file that results. However, we 
shall use <I>only</I> the un-compressed format.</P>
<P align=justify>&nbsp;</P>
<P align=justify>Method 1 provides no compression at all. With this method, the 
bytes that make up a row of image data are packed tightly together with no 
extraneous bits except possibly at the end of the row.)</P>
<P align=justify>&nbsp;</P>
<P align=justify>&nbsp;</P></FONT><FONT size=5>
<P align=justify>TIFF Classes</P></FONT><FONT size=2>
<P align=justify>&nbsp;</P>
<P align=justify>TIFF's extreme flexibility places a burden on software 
developers who support this format. It requires a considerable amount of code to 
handle all of the options available. An application program wanting to import 
any TIFF image has no choice other than to handle all of the options. That is 
the only way to guarantee the image can be displayed exactly as it was produced. 
To reduce some of this burden, TIFF version 5.0 has introduced the concept of 
<I>TIFF conformant classes</I>. An application program can now handle a specific 
TIFF class without needing to handle <I>all</I> classes. It is the 
responsibility of the application program to advertise which TIFF classes it 
supports.</P>
<P align=justify>&nbsp;</P>
<P align=justify>In general, three different categories of images can be 
contained in a TIFF file.</P>
<P align=justify>&nbsp;</P>
<P align=justify>These are:</P>
<P align=justify>&nbsp;</P>
<DIR><I>
<P align=justify>a. Black and white images.</I> These utilize one bit per pixel 
for display</P><I>
<P align=justify>b. Gray-scale images.</I> These utilize between two and eight 
bits per pixel, which results in 4 to 256 levels of gray available in an 
image.</P><I>
<P align=justify>c. Color images.</I> These are of both the palette and RGB 
varieties, with up to 24 bits of color data per pixel.</P>
<P align=justify>&nbsp;</P></DIR>
<P align=justify>The TIFF classes quantify which image types fit into which 
class along with the compliment of TIFF tags required by each class. The TIFF 
class concept results in a small reduction in TIFF flexibility with the added 
benefit that TIFF writers will be able to produce images that can be read by 
more application programs. TIFF classes are summarized in Figure 4.</P></FONT>
<HR>

<P align=justify>&nbsp;</P>
<DIR>
<P align=justify>Four TIFF Classes are defined:</P>
<P align=justify>&nbsp;</P>
<P align=justify>Class B (also called TIFF B) for bi-level, 1-bit images</P>
<P align=justify>Class G (also called TIFF G) for gray-scale images </P>
<P align=justify>Class P (also called TIFF P) for palette-color images </P>
<P align=justify>Class R (also called TIFF R) for RGB full-color images</P>
<P align=justify>&nbsp;</P>
<P align=justify>A TIFF X class combines all four of the above.</P>
<P align=justify>&nbsp;</P>
<P align=justify>All TIFF classes are required to support the following 
tags:</P>
<P align=justify>&nbsp;</P>
<P align=justify>1. NewSubfileType</P>
<P align=justify>2. lmageWidth</P>
<P align=justify>3. ImageLength</P>
<P align=justify>4. RowsPerStrip</P>
<P align=justify>5. StripOffsets</P>
<P align=justify>6. StripByteCounts</P>
<P align=justify>7. XResolution</P>
<P align=justify>8. YResolution</P>
<P align=justify>9. ResolutionUnit</P>
<P align=justify>&nbsp;</P></DIR>
<P align=justify>Additionally, <I>TIFF Class B</I> conformant images are 
required to have the following tags with the following values:</P>
<P align=justify>&nbsp;</P>
<P>1. SamplesPerPixel = 1</P>
<P>2. BitsPerSample = 1</P>
<P>3. Compression= 1, 2, or 32,773 (PackBits)</P>
<P>4. PhotometricInterpretation= 0 or 1</P>
<P>&nbsp;</P><I>
<P align=justify>TIFF Class G</I> conformant images are required to have the 
following tags with the following values:</P>
<P align=justify>&nbsp;</P>
<P>1. SamplesPerPixel = 1</P>
<P>2. BitsPerSample =4 or 8</P>
<P>3. Compression= 1 or 5 (LZW)</P>
<P>4. PhotometricInterpretation= O or 1</P>
<P>&nbsp;</P><I>
<P align=justify>TIFF Class P</I> conformant images are required to have the 
following tags with the following values:</P>
<P align=justify>&nbsp;</P>
<P>1. SamplesPerPixel = 1</P>
<P>2. BitsPerSample = 1,2,3,4,5,6,7 or 8</P>
<P>3. Compression = 1 or 5 (LZW)</P>
<P>4. PhotometricInterpretation = 3</P>
<P>5. ColorMap</P>
<P>&nbsp;</P><I>
<P align=justify>TIFF Class R</I> conformant images are required to have the 
following tags with the following values:</P>
<P align=justify>&nbsp;</P>
<P>1. SamplesPerPixel = 3</P>
<P>2. BitsPerSample =8, 8 and 8</P>
<P>3. PlanarConfiguration = 1 or 2</P>
<P>4. Compression= 1 or 5 (LZW)</P>
<P>5. PhotometricInterpretation=2</P>
<HR>
<B>
<P>Figure 4.</B> TIFF Classes.</P>
<P>&nbsp;</P><B><FONT face="Times New Roman" size=4>
<P align=center>There follows excerpts from a TIFF reader/writer library. This 
is provided for information only - to show you how someone else dealt with the 
format. You do not have to read this at all. Skip to the conclusions.</P>
<P align=center>&nbsp;</P></B></FONT><FONT face="Times New Roman" size=5>
<P align=justify>The <B>TIFF</B> Function Library</P></FONT><FONT 
face="Times New Roman">
<P align=justify>&nbsp;</P></FONT>
<P align=center>
<CENTER>
<TABLE borderColor=#000000 cellSpacing=2 cellPadding=11 width=624 border=1>
  <TBODY>
  <TR>
    <TD vAlign=top><FONT face="Times New Roman">
      <P>&nbsp;</P>
      <P>Almost all of the code that makes up the TIFF function library is part 
      of a <I>public domain</I> TIFF library written by Sam Leffler of the 
      University of California at Berkeley. The LZW compression/expansion code 
      was also written at the University of California at Berkeley. Because the 
      TIFF function library code is in the public domain, it can be used without 
      prior permission or restriction (as long as the original copyright notices 
      remain intact.)</P>
      <P>&nbsp;</P>
      <P>The code which is listed here is <U>not</U> intended for use, nor do I 
      have it compiled anywhere. It is simply an example of manipulations of 
      TIFF files, <U>which</U> might help you to get 
  started.</FONT></P></TD></TR></TBODY></TABLE></CENTER>
<P></P><FONT face="Times New Roman">
<P align=justify>&nbsp;</P>
<P align=justify>The code provided in the TIFF function library provides support 
for all TIFF classes. Class B, however, is not fully supported because the CCITT 
compression algorithms are not provided. They are not supported because they 
have limited usefulness with imaging. They are specifically tailored for 
bi-level, black and white images only. Black and white images can be written or 
read using the "PackBits" compression method, however. If CCITT compression is 
desired, it will have to be added by the reader.</P>
<P align=justify>&nbsp;</P>
<P align=justify>The code in the TIFF function library is designed to make 
reading and writing TIFF files as painless as possible. Most of the complexities 
of the file format are kept from the user/programmer. Many operations are 
performed automatically in the background that would have to be performed 
consciously by the programmer when using lesser TIFF implementations. Only the 
handful of functions declared in the file "tiffintf.h" are used to read and 
write any TIFF image file.</P>
<P align=justify>&nbsp;</P>
<P align=justify>Some of the files that make up the TIFF function library are 
shown here. A very short description of the contents of each file is 
provided.</P>
<P align=justify>&nbsp;</P>
<DIR><B>
<P align=justify>TIFFINFO.DOC</B> This file contains additional information 
about the internal functions of the TIFF function library. It should be read 
before attempting to utilize the library.</P>
<P align=justify>&nbsp;</P><B>
<P align=justify>TIFF.H &amp; TIFFIO.H</B> These files define all TIFF data 
structures and the internal data structures used in the TIFF support code. All 
tags that are supported in TIFF version 5.0 are enumerated in these files.</P>
<P align=justify>&nbsp;</P><B>
<P align=justify>IO.C</B> This file contains all of the code that performs 
reading and writing of TIFF data to disk. It also contains portions of the code 
used to initialize the TIFF package.</P>