📄 the tiff image file format.htm
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- saved from url=(0070)http://www.ee.cooper.edu/courses/course_pages/past_courses/EE458/TIFF/ -->
<HTML><HEAD><TITLE>The TIFF Image File Format</TITLE>
<META http-equiv=Content-Type content="text/html; charset=windows-1252">
<META content="MSHTML 6.00.2900.2963" name=GENERATOR></HEAD>
<BODY text=#000000 vLink=#000f80 aLink=#802000 link=#001eff
bgColor=#ffffff><FONT face="Times New Roman" size=5>
<P align=justify>The TIFF Image File Format</P></FONT><FONT
face="Times New Roman">
<P align=justify> </P></FONT><FONT face="Times New Roman" size=4>
<P align=justify>Introduction</P></FONT><FONT face="Times New Roman">
<P align=justify> </P>
<P align=justify>The Tagged Image File Format (TIFF) was designed from the
ground up to alleviate the problems associated with <U>fixed file formats</U>.
The key word here is <I>designed</I>. TIFF did not evolve from a de-facto
standard. It was created to become the industry standard for image-file
exchange. TIFF was a super-set of all existing graphics or image file formats.
TIFF incorporates enough flexibility to eliminate the need or justification for
proprietary image file formats. As a matter of fact, it is possible to store
proprietary information in a TIFF file without violating the intent of the
format. TIFF was designed with an eye toward the future, not just for use in the
present. The designers of the TIFF file format had three important goals in
mind:</P>
<P align=justify> </P>
<DIR><I>
<P align=justify>a. Extendibility.</I> This is the ability to add new image
types without invalidating older types and to add new informational fields to
the format without impacting the ability of older applications to read the image
files.</P>
<P align=justify> </P><I>
<P align=justify>b. Portability.</I> TIFF was designed to be independent of the
hardware platform and the operating system on which it executes. TIFF makes very
few demands upon its operating environment. TIFF should (and does) perform
equally well in both the "IBM PC" and Apple Macintosh's environments -- and
UNIX.</P>
<P align=justify> </P><I>
<P align=justify>c. Revisability.</I> TIFF was designed not only to be an
efficient medium for exchanging image information but also to be usable as a
native internal data format for image editing applications.</P>
<P align=justify> </P></DIR>
<DIR></DIR>
<P align=justify>The correctness and the accomplishment of these goals is
somewhat corroborated by the number of software vendors supporting the TIFF
format. Every major scanner manufacturer and every desktop publishing program
supports TIFF. More application programs support TIFF every day. Also, numerous
translator programs that translate other image-file formats to TIFF format are
becoming available. (We have GWS and Sunshow, among others, legally available
for EE 458).</P>
<P align=justify> </P>
<P align=justify>The richness of the TIFF format solves many problems, but at
the same time creates a few all its own. The TIFF file structure is necessarily
complex or (a better word) <I>variable</I>. It's more complex, in fact, than
many of the <I>proprietary</I> file formats it was designed to replace. The
added complexity of the TIFF format requires much more code to manage it than do
most other image-file formats. This results in slower execution times reading
and writing files and in longer TIFF code development cycles. However, since we
intend to concentrate on <I>image processing</I> -- we're not interested in
re-inventing a graphics file viewer -- we can make certain simplifying
assumptions which make most of the tougher problems quietly go away! I'll go
into those simplifying assumptions shortly.</P>
<P align=justify> </P>
<P align=justify>We shall support <I>uncompressed </I>TIFF revision 5.0, which
is what <I>Deskscan</I> produces. (<I>Deskscan</I> is the driving software that
we have for the HP scanners in the microprocessor lab). The TIFF format is
controlled by a specification jointly written by the <I>Aldus Corporation</I>
and <I>Microsoft</I>, although many other companies, in addition to these two,
contributed to its formulation. Version 5.0 of this specification is dated April
1988. Although the specification document itself is copyrighted by the Aldus
Corporation, the TIFF format is in the public domain. This means no fees or
royalties are required to use the format. </P>
<P align=justify> </P>
<P align=justify>The specification document is available <I>if you want it</I>;
unlike most other specifications, it is quite readable. The discussion to follow
only highlights TIFF functionality. Any other questions you might have about
TIFF will be answered somewhere in the spec.</P>
<P align=justify> </P>
<P align=justify>Finally, a few good articles have been written about the TIFF
file format. You should be able to locate a source of information from a
reasonable library if necessary.</P>
<P align=justify> </P></FONT><FONT face="Times New Roman" size=5>
<P align=justify>The TIFF File Structure</P></FONT><FONT face="Times New Roman">
<P align=justify> </P>
<P align=justify>TIFF files are made up of three unique data structures. These
structures along with their functions are illustrated in Figure 1.</P>
<P align=justify> </P>
<P align=justify>The first data structure found in every TIFF file is called the
<I>Image File Header</I>, or IFH. This structure is the only portion of a TIFF
file that has a fixed location. This 8-byte structure must be located at offset
zero in the file. The IFH contains important information necessary to correctly
interpret the remainder of the TIFF file. The first field within the IFH, and
possibly the most important, is the byte-ordering field. This field indicates
the byte-ordering that was used when the TIFF file was created. This is
especially important because TIFF files can be moved between the IBM PC world
(based upon Intel processors) and the (gulp) Macintosh world (based upon the
Motorola series of processors). As you may know, the byte ordering (within
16-bit integers and long 32-bit integers) used by Intel and Motorola processors
is quite different. Figure 2 shows how different it is. Without knowing the
order of bytes used when an image file was created, a TIFF file reader would
have little hope of recovering the image. This ordering affects any items read
from a TIFF file that are longer than one byte in length.</P>
<P align=justify> </P>
<P align=justify>The byte-ordering field in the IFH contains either two bytes of
M's ("MM", hex 4D4D), indicating Motorola integer format, or two bytes of I's
("II", hex 4949), indicating Intel format. Using the <I>dual</I> bytes allows
this field to be correctly read by either type of processor. (Clever, ain't it?)
If the byte ordering utilized in the file differs from that of the computer on
which the image file is being read, all subsequent 16- and 32-bit integer values
will have to have their byte ordering reversed. If the byte ordering is the
same, integer and long values can be read and used without modification.
Luckily, all current data-compression methods utilized by the TIFF standard are
<I>byte oriented</I>. If a word- or integer-oriented compression method were
utilized, byte ordering of the image data would have to be taken into
consideration as the data was read from the file. Swapping each word of
compressed image data as a file was being read would be a computationally
expensive process.</P>
<P align=justify> </P>
<P align=justify>The version field in the IFH always contains the decimal value
of 42<SUB>10</SUB>. This field can be used to further verify that a file is a
TIFF file. This number is not a TIFF software version number as one would
expect. In fact, this number will probably never change. If it does, it
indicates that the format of the TIFF file has changed radically and that TIFF
reader programs should not even attempt to read the file. Major changes to the
TIFF format that would necessitate changing the version field are in direct
conflict with the philosophy of TIFF extendibility. (However, I don't expect
that will stop them).</P>
<P align=justify> </P>
<P align=justify>The final field in the IFH contains the offset in bytes from
the start of the file to the Image File Directory, or IFD, structure. This is
the second of the three data structures contained in a TIFF file. Note that
although Figure 1 seems to indicate that the IFD immediately follows the IFH in
the TIFF file, this is not necessarily the case. TIFF readers should never
assume this but should seek to the offset value specified to find the first IFD
in the image file. It <I>may</I> or <I>may not</I> follow the IFH in the
file.</P><IMG src="The TIFF Image File Format_files/tiff1.gif" width="100%"> <I>
<P align=justify>Notes</P>
<DIR></I>
<P align=justify>1. Image file header must be located at offset 0 into file.</P>
<P align=justify>2. Byte ordering "II" (hex 4949) is for lntel-created image
file. "MM" (hex 4D4D) is for Motorola-created image file.</P>
<P align=justify>3. Version is always 42<SUB>10</SUB>; (hex 2A); should never
change.</P>
<P align=justify>4. First IFD may or may not follow Image File Header. TIFF
readers must follow the pointers to find it.</P>
<P align=justify>5. If value can fit into Value Offset field, it will be placed
there. It value cannot fit, Value Offset will contain a pointer (file offset
from file beginning) to where value is located.</P>
<P align=justify>6. IFD entries sorted in ascending order by Tag value.</P>
<P align=justify> </P></DIR><IMG
src="The TIFF Image File Format_files/tiff2.gif" width="100%">
<P align=justify> </P>
<P align=justify> </P>
<P align=justify>One or more IFD's can reside in a TIFF file. Each IFD must be
located on a word boundary. If more than one IFD exists, the file contains more
than one image. A full-blown TIFF reader should be able to access any number of
images in a TIFF file. Unfortunately, not many do. <I>Yours shouldn't</I>. </P>
<P align=justify> </P>
<P align=justify>An IFD consists of a count, N, of the number of directory
entries that follow, N 12-byte directory entries, and finally another offset
value. The offset storage location within the IFD will contain the offset from
the <I>beginning</I> of the TIFF file to the next IFD, or four bytes of zeros if
this IFD is the last in the file. The Directory Entries (DE's) within an IFD
must be sorted into ascending order by the value of the tag. This is a
requirement that helps reduce overhead as TIFF files are processed.</P>
<P align=justify> </P>
<P align=justify>The final data structure within the TIFF file format is the
Directory Entry, or DE. It is the format of the DE's that gives TIFF its
flexibility. As noted, each DE is exactly 12 bytes in length and is segmented
into the four fields shown in Figure 1. The first field of the DE is the tag
field. As the full name of this image-file format indicates, the tag is the
foundation on which this file structure is based. The raster data contained in a
TIFF file is defined by the tags to which it is attached. The advantages of a
tagged image file are:</P>
<DIR>
<P align=justify>a. Application programs such as TIFF readers can <I>safely
ignore any tags they do not understand</I>.</P>
<P align=justify>b. New tags can be added at any time without invalidating any
of the older tags. In a sense, this prevents the TIFF file format from becoming
obsolete.</P>
<P align=justify>c. Private tags can be defined to contain proprietary
information within a TIFF file without affecting other application programs. The
tags with values between 32,768 and 65,535 are reserved for just this
purpose.</P>
<P align=justify> </P></DIR>
<P align=justify>In all, 45 tags are defined in version 5.0 of the TIFF
specification. These tags are summarized in Figure 3.</P>
<P align=justify> </P>
<P align=justify>The numeric value of the tag indicates which image parameter is
contained in the DE. Tag values between zero and 32,767 are reserved for use by
TIFF public fields, while tags 32,768 to 65,535 are reserved for private fields.
Private fields must be allocated by <I>Aldus</I> and/or <I>Microsoft</I> to
prevent different software vendors from using the same tags in different
ways.</P>
<P align=justify> </P></FONT>
<HR>
<B>
<P>Num Tag Name Tag Value Tag Type Tag Length</P></B>
<HR>
<FONT size=4>
<P>Basic Tags</P></FONT>
<DIR>
<P>1. BitsPerSample 258 SHORT Samples per pixel</P>
<P>2. ColorMap 320 SHORT 3<SUP>*</SUP>(2<SUP>**</SUP>BitsPerSample)</P>
<P>3. ColorResponseCurve 301 SHORT
3<SUP>*</SUP>(2<SUP>**</SUP>BitsPerSample)</P>
<P>4. Compression 259 SHORT 1</P>
<P>5. GrayResponseCurve 291 SHORT 2<SUP>**</SUP>BitsPerSample</P>
<P>6. GrayResponseUnit 290 SHORT 1</P>
<P>7. ImageLength 257 SHORT/LONG 1</P>
<P>8. ImageWidth 256 SHORT/LONG 1</P>
<P>9. NewSubfileType 254 LONG 1</P>
<P>10. Photometriclnterp 262 SHORT 1</P>
<P>11. PlanarConfiguration 284 SHORT 1</P>
<P>12. Predictor 317 SHORT 1</P>
<P>13. PrimaryChromaticities 319 RATIONAL 6</P>
<P>14. ResolutionUnit 296 SHORT 1</P>
<P>15. RowsPerStrip 278 SHORT/LONG 1</P>
<P>16. SamplesPerPixel 277 SHORT 1</P>
<P>17. StripByteCounts 279 SHORT/LONG</P>
<P>Tag length = StripsPerlmage for PlanarConfig = 1</P>
<P>SamplesPerPixel * StripsPerImage for PlanarConfig = 2</P>
<P>18. StripOffsets 273 SHORT/LONG</P>
<P>Tag length = StripsPerlmage for PlanarConfig = 1</P>
<P>SamplesPerPixel * StripsPerlmage for PlanarConfig = 2</P>
<P>19. WhitePoint 318 RATIONAL 2</P>
<P>20. XResolution 282 RATIONAL 1</P>
<P>21. YResolution 283 RATIONAL 1</P></DIR>
<P> </P><FONT size=4>
<P>Information Tags</P></FONT>
<DIR>
<P>22. Artist 315 ASCII ?</P>
<P>23. DateTime 306 ASCII 20 "YYYY:MM:DD</P>
<P>HH:MM:SSO"</P>
<P>24. HostComputer 316 ASCII ?</P>
<P>25. ImageDescription 270 ASCII ?</P>
<P>26. Make 271 ASCII ?</P>
<P>27. Model 272 ASCII ?</P>
<P>28. Software 305 ASCII ?</P>
<P> </P></DIR><FONT size=4>
<P>Facsimile Tags</P></FONT>
<DIR>
<P>29. Group3options 292 LONG 1</P>
<P>30. Group4options 293 LONG 1</P>
<P> </P></DIR><FONT size=4>
<P>Document Storage and Retrieval Tags</P></FONT>
<DIR>
<P>31. DocumentName 269 ASCII ?</P>
<P>32. PageName 285 ASCII ?</P>
<P>33. PageNumber 297 SHORT 2</P>
<P>34. XPosition 286 RATIONAL 1</P>
<P>35. YPosition 287 RATIONAL 1</P>
<P> </P></DIR><FONT size=4>
<P>No Longer Recommended Tags</P></FONT>
<DIR>
<P>36. CellLength 265 SHORT 1</P>
<P>37. CellWidth 264 SHORT 1</P>
<P>38. FillOrder 266 SHORT 1</P>
<P>39. FreeByteCounts 289 LONG ?</P>
<P>40. FreeOffsets 288 LONG ?</P>
<P>41. MaxSampleValue 281 SHORT SamplesPerPixel</P>
<P>42. MinSampleValue 280 SHORT SamplesPerPixel</P>
<P>43. SubfileType 255 SHORT 1</P>
<P>44. Orientation 274 SHORT 1</P>
<P>45. Thresholding 263 SHORT 1</P>
<P> </P></DIR>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -