home *** CD-ROM | disk | FTP | other *** search
/ Internet File Formats / InternetFileFormatsCD.bin / graphics / tiff / unix / archive.z / archive / text0033.txt < prev    next >
Encoding:
Text File  |  1995-09-20  |  6.5 KB  |  157 lines
  1. Here is an interesting alternative to private TIFF IFD's which
  2. some of you may find useful in your own applications, especially
  3. if you need a *lot* of tags.
  4.  
  5. During the process of developing a new standard for storing
  6. geographic information in TIFF tags, we ran up against the
  7. following requirements:
  8.  
  9.   1) The need for a very large number of "Tagged" information
  10.      fields of various types (possibly hundreds), with an
  11.      easily extensible format.
  12.  
  13.   2) The implementation must be "TIFF-visible", so that a
  14.      naive TIFF-dump program would be able to display all
  15.      the values, in their correct format (i.e, it is not
  16.      good enough to just encode everthing into a large ASCII
  17.      string; LONG values should be in a LONG tag, etc.).
  18.  
  19.   3) The ability to implement (1) and (2) with only three or four
  20.      reserved public TIFF tags,
  21.  
  22.   4) Easy to understand approach, without dozens of complex
  23.      order-dependent structures, and no UNKNOWN byte-streams. 
  24.  
  25.   5) Must support the TIFF philosophy of data abstraction,
  26.      and be modular enough that TIFF I/O modules can operate
  27.      independently of the new data-storage implementation.
  28.       
  29.  
  30. The usual suggestion from Aldus is to take your 5 tags and make 
  31. one of them a LONG offset to a private IFD. This solution does
  32. not satisfy requirement (2), since a naive TIFF reader wont know
  33. to go to the private IFD and parse the entries, so you will not
  34. see all of the information. It also does not support (5) because
  35. the TIFF I/O module would have to be modified to make sure it
  36. doesn't overwrite invisible data referenced by the private IFD.
  37. Finally, with private IFD's you have to completely re-write the
  38. TIFF-directory parser module, including all of the byte-swapping
  39. procedures, etc, instead of letting the TIFF layer handle all of
  40. that for you. This makes code difficult to maintain.
  41.  
  42. The following is an intereresting alternative, which is described
  43. for others who may also have similar problems. It satisfies all of
  44. conditions 1-5, though (4) may be debatable to some.
  45.  
  46. The "Keyed Information" approach
  47. --------------------------------
  48.  
  49. We define a new entity called a "Key" which is virtually identical
  50. in function to a "Tag", but has one more level of abstraction above
  51. TIFF. If you like, it is a sort of "Meta-Tag". A Key works with formatted
  52. tag-values of a TIFF file the way that a TIFF file deals with the raw bytes
  53. of a data file. 
  54.  
  55. Recall that a TIFF directory consists of a header, indicating NumberOfTags,
  56. followed by a list of Tag-entries which look like this:
  57.  
  58.    TagID, Type, Count, Value_Offset,
  59.  
  60. which gives the Tag ID number, its data format, the number of
  61. bytes in data-array, followed by either the Value itself, or
  62. else an absolute offset in the file to the data. We do the
  63. same thing with Keys, but in place of "Type" we use a TIFF
  64. Tag ID to describe the data!
  65.  
  66. Implementation Details
  67. ----------------------
  68.  
  69. To set up a Keyed storage system,  you reserve one of your personal
  70. TIFF Tags to be a "KeyDirectoryTag", which is of type SHORT (or
  71. possibly LONG). This will contain several values of header information,
  72. followed by a list of KeyEntries. In our implementation there
  73. are four header values, which are:
  74.  
  75.    KeyDirectoryVersion, KeyVersion, NumberOfKeys, Reserved
  76.  
  77. where KeyDirectoryVersion is like the TIFFVersion (42), and will only change
  78. if this Tag's Key *structure* is changed. The KeyVersion merely
  79. indicates what version of Key-Sets are used. The next value, NumberOfKeys,
  80. indicates how many Keys are defined in this Tag, followed by a 
  81. "Reserved" value which only serves as padding.
  82.  
  83. The 4-SHORT header is immediately followed by a collection of
  84. <NumberOfKeys> KeyEntry sets, each of which is also 4-SHORTS
  85. long. Each KeyEntry is of the form:
  86.  
  87.   KeyID, TIFFTagLocation, Count, Value_Offset,
  88.  
  89. where KeyID gives the ID value of your Key (identical in function
  90. to TIFF tag ID), and the TIFFTagLocation indicates which TIFF tag
  91. contains the value(s) of the Key. The Type (format) of the Key-value
  92. is therefore implied by the Type of the TIFFTagLocation ID. Finally,
  93. the Count indicates the number of TIFF *values* (rather than the
  94. number of bytes) in this key.
  95.  
  96. Now here's the trick: if TIFFTagLocation is 0, then the 
  97. Value_Offset contains the actual (SHORT) value of the Key (and 
  98. Count=1 is implied), or else, Value_Offset indicates the 
  99. offset *into* the TagArray indicated by TIFFTagLocation.
  100.  
  101. Following the KeyEntry definitions, the KeyDirectory tag may
  102. also contain additional values. For example, if a Key requires
  103. multiple SHORT values, they could be placed at the end of this
  104. tag, and the KeyEntry will set TIFFTagLocation=KeyDirectoryTag,
  105. with the Value_Offset pointing to the end of the tag.
  106.  
  107. Thus, if you have only 5 real TIFF tags to play with, then you can
  108. define the first to be the KeyDirectory Tag, the next to be the
  109. LONGValuesTag, the next one ASCIIValuesTag, and perhaps another
  110. one as FLOATValuesTag (with one left over). The first tag defines 
  111. a collection of Keys, which may point to various places in
  112. the other three tag-value-arrays.
  113.  
  114. Here's an illustrative example, with three tags:
  115.  
  116.   KeyDirectoryTag=( 1,    1,4,0,
  117.                     1,    0,1,5,
  118.                     4,32764,2,3,
  119.                     5,32765,7,5 
  120.                     8,32765,5,0 
  121.                                 )
  122.   Tag32764=(10,20,30,40,50,60,70,80)
  123.   Tag32765=("ABLE\0BAKERS")
  124.  
  125. The first line indicates that this is a Verson 1 KeyDirectory tag,
  126. the keys are version 1, and there are 4 Keys defined in this tag.
  127.  
  128. The next line indicates that the first Key (ID=1) has the
  129. value 5, explicitly placed in the entry list (since TIFFLoc=0).
  130. The next two lines indicate that the Keys 4 and 5 have their
  131. values listed in Tags 32764 and 32765 respectively. Key 4
  132. has two integer values, starting at index 3 (the fourth in array), 
  133. which consist of (40,50), while Key 5 has a 7-character string value, 
  134. which is at offset 5 into 32765, and so has the value "BAKERS" (with
  135. a null character at the end). The value of Key 8 is "ABLE".
  136.  
  137. The TIFF layer handles all the problems of data structure, platform
  138. independence, format types, etc, by specifying byte-offsets, byte-order
  139. format and count, while the Key describes its key values at the
  140. TIFF level by specifying Tag number, array-index, and count. Since
  141. all TIFF information occurs in TIFF arrays of some sort, we have a
  142. robust method for storing anything in a Key that would occur
  143. in a Tag.
  144.  
  145. With this Keyed-value approach, you have 65536 Keys which have all
  146. the flexibility of TIFF tag, with the added advantage that a
  147. TIFF dump will provide you with all the information that exists
  148. in your private implementation.
  149.  
  150. We welcome your comments.
  151.  
  152.   --Niles.
  153.  
  154.  
  155.     
  156.  
  157.