standards.html 15 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286
  1. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
  2. "http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">
  3. <html>
  4. <head>
  5. <title>Problems with current Metadata Standards</title>
  6. <link rel=stylesheet type='text/css' href='style.css' title='Style'>
  7. <style type="text/css">
  8. <!--
  9. a.ref { text-decoration: none; font-size: x-small;
  10. font-weight: normal; vertical-align: super; }
  11. -->
  12. </style>
  13. </head>
  14. <body>
  15. <div class='index'>
  16. <a href="#TIFF">TIFF 6.0</a>
  17. <br><a href="#DNG">DNG 1.3</a>
  18. <br><a href="#EXIF">EXIF 2.3</a>
  19. <br><a href="#PhotoInfo">OffsetSchema</a>
  20. <br><a href="#JPEG">JPEG</a>
  21. <br><a href="#MPF">MPF</a>
  22. <br><a href="#refs">References</a>
  23. </div>
  24. <h1 class=up>Problems with current Metadata Standards</h1>
  25. <p>It seems that all metadata standards have their own unique problems. This
  26. page documents some significant structural problems found in some current
  27. metadata and file format specifications, and gives possible solutions to these
  28. problems. <i>[Also see my <a href="commentary.html">Commentary on Meta
  29. Information Formats</a>.]</i></p>
  30. <a name="TIFF"></a>
  31. <h3>TIFF 6.0 <a class=ref href="#ref1">[1]</a></h3>
  32. <p>A significant problem of the 1992 TIFF 6.0 specification is that there is no
  33. way to distinguish an IFD (image file directory) offset from a simple integer
  34. value. As a result, new IFD's may not be created without risking corruption of
  35. the files by unaware software. This is not only a problem for proprietary maker
  36. notes which commonly use a TIFF IFD structure, but is also a problem for
  37. extensibility of TIFF-based RAW image formats (as demonstrated by the DNG 1.3
  38. specification -- see below).</p>
  39. <p><b>A simple solution:</b></p>
  40. <p>Use a TIFF field type of 13 (IFD) instead of 4 (LONG) for IFD offsets.
  41. This was first proposed in 1995 by Adobe in their PageMaker
  42. 6.0 TIFF Technical Notes<a class=ref href="#ref2">[2]</a>,
  43. but unfortunately it never found its way into the TIFF specification. Even so,
  44. Olympus Optical Co. has shown some intelligence and is using this field type in
  45. the maker notes of their recent digital cameras.
  46. </p>
  47. <p><b>Another useful addition:</b> <i>(added 2009-09-27)</i></p>
  48. <p>A number of camera and cell phone manufacturers (Concord, Kodak, Motorola,
  49. Nokia, Olympus, Pentax, Ricoh, Samsung and Sony) leave blank IFD entries in the
  50. maker notes of images from some models. Presumably this simplifies the embedded
  51. software by allowing the output file structure to be kept constant even when the
  52. number of maker note IFD entries changes. It could be useful if this feature
  53. was added explicitly to the offical TIFF specification by defining a field type
  54. of 0 as a "free IFD entry" to be ignored. (Note that this ability already
  55. exists implicitly at a certain level in the specification, which states:
  56. <i>"Readers should skip over fields containing an unexpected field
  57. type"</i>.)</p>
  58. <a name="DNG"></a>
  59. <h3>DNG 1.3 <a class=ref href="#ref3">[3]</a></h3>
  60. <p>With the DNG 1.3 specification of June 2009, Adobe added a new Camera Profile
  61. IFD referenced by an offset using the standard (and unfortunate) TIFF LONG field
  62. type. This means that the new Profile IFD will be lost if the file is rewritten
  63. by any software which does not have explicit knowledge of the 1.3 specification.
  64. But to make things worse, Adobe didn't even use a standard IFD format for the
  65. data. Instead, the IFD begins with a TIFF-style header and uses relative instead
  66. of absolute offsets. This would have been a good idea if the IFD was stored as
  67. the value of an UNDEFINED tag rather than referenced from a LONG offset. (If
  68. done this way, the new information would have been preserved if the file was
  69. rewritten by unaware software.) But as implemented it just adds to the pain of
  70. parsing the file by requiring even more specialized code to be written in
  71. support of the DNG 1.3 format.</p>
  72. <p><b>A simple solution:</b></p>
  73. <p>Sack the Adobe developers who were responsible for this, and use field type
  74. 13 (as recommended above for TIFF 6.0) and a standard TIFF IFD structure when
  75. adding new IFD's in the future.</p>
  76. <a name="EXIF"></a>
  77. <h3>EXIF 2.3 <a class=ref href="#ref4">[4]</a></h3>
  78. <p>The EXIF specification has been the standard for digital camera metadata for
  79. many years, and while the digital camera technology has advanced significantly
  80. in these years, the EXIF specification has not. There are a number of
  81. significant problems with the EXIF specification which have never been
  82. addressed.</p>
  83. <p>Some current problems with the EXIF specification are:</p>
  84. <ol>
  85. <li>Maker note data structure has no restrictions and is easily invalidated when
  86. editing EXIF.</li>
  87. <li>No facility for storing the time zone for date/time values.</li>
  88. <li>Very limited support for alternate character sets (essentially only the
  89. UserComment tag has this feature).</li>
  90. <li>No alternate language support.</li>
  91. <li>Byte ordering for "Unicode" text strings, and the meaning of "Unicode"
  92. itself is not clearly specified.</li>
  93. <li>Mandatory tags are unnecessary and painful to implement.</li>
  94. <li>ApertureValue and MaxApertureValue are stored as unsigned RATIONAL, which
  95. means that lenses with F numbers faster than 1.0 (with equivalent APEX values of
  96. less than zero) can not be represented.</li>
  97. <li>MaxApertureValue is defined as "The smallest F number of the lens". This
  98. definition is unclear in the case of zoom lenses where the maximum aperture
  99. varies across the zoom range. Some manufacturers (Canon, Nikon, Sony) store the
  100. maximum aperture at the specific focal length, but others (Olympus, Pentax)
  101. store the absolute maximum aperture of the lens.</li>
  102. <li>EXIF is not extensible, and is missing definitions for storing some
  103. information that could be very useful to camera owners (eg. camera pitch/roll
  104. angles, sensor temperature, face detection, auto-focus points, image
  105. stabilization, flash exposure compensation, etc).</li>
  106. </ol>
  107. <p><b>Simple solutions:</b></p>
  108. <ol>
  109. <li>Specify that maker note data must be self-contained (ie. must not exceed the
  110. bounds of the maker note value data), and must be relocatable (ie. must not use
  111. absolute offsets). <i>[I would have suggested defining a new maker note tag
  112. with field type 13 (IFD) which references a standard format IFD, but I am afraid
  113. that no camera maker would ever jump on board with this suggestion now that they
  114. have already been seduced by the dark side.]</i></li>
  115. <li>Change the specification to allow an optional time zone of the format
  116. "-05:00" to be appended to the date/time string values.</li>
  117. <li>Change the specification to allow UTF-8 in ASCII-type values as recommended
  118. by the MWG<a class=ref href="#ref5">[5]</a>.</li>
  119. <li>No simple solution for this. XMP<a class=ref href="#ref6">[6]</a>
  120. is the only reasonable alternative if alternate language support is
  121. required.</li>
  122. <li>Specify that the Unicode byte order must be the same as the EXIF byte
  123. ordering. (This is the only reasonable choice, but for some reason both
  124. Microsoft and Apple seem to write Unicode using the native processor byte
  125. ordering. regardless of the EXIF byte order.) Also, it should be made clear
  126. that by "Unicode" the EXIF specification actually means UCS-2, although updating
  127. this to allow UTF-16 surrogate pairs may be a good idea.</li>
  128. <li>Define reasonable fallback values for required tags which are missing.</li>
  129. <li>Allow ApertureValue and MaxApertureValue to be stored as signed SRATIONAL.</li>
  130. <li>Define whether MaxApertureValue is taken at the current focal length of
  131. a zoom lens, or over the entire zoom range.</li>
  132. <li>Expand the standard to include additional useful information available from
  133. modern digital cameras.</li>
  134. </ol>
  135. <a name="PhotoInfo"></a>
  136. <h3>Microsoft "OffsetSchema" Tag <a class=ref href="#ref7">[7]</a></h3>
  137. <p>In February 2007 Microsoft proposed a new PhotoInfo tag called "OffsetSchema"
  138. (hex. 0xEA1D, dec. 59933) in an attempt to patch a deficiency in the EXIF maker
  139. note specification (see point 1 in EXIF 2.2 section above). This tag represents
  140. the offset difference between the original maker note location in the EXIF and
  141. the new location after editing, and is designed to allow the maker note tag
  142. values to be accessed after the location of the maker notes is changed by
  143. editing the EXIF. <i>[Bless their little hearts for trying to improve this
  144. situation, but while the idea is good the implementation is flawed and
  145. ultimately unworkable.]</i></p>
  146. <p>There are two main problems with the implementation, and the second is a show
  147. stopper:</p>
  148. <blockquote>1. For this new tag to be available to a single-pass metadata reader, it
  149. must come <i>before</i> the maker note data (hex. 0x927C, dec. 37500). But
  150. since the EXIF/TIFF format specifies that tags must be stored in numerical
  151. order, the maker note tag (hex. 0x927C) comes before the OffsetSchema tag
  152. (hex. 0xEA1D).</blockquote>
  153. <blockquote>2. The OffsetSchema tag will be invalidated by any software that
  154. rewrites the EXIF and moves the maker notes without properly updating the tag.
  155. In an ideal world all application developers would release an updated version
  156. of their software which treats the OffsetSchema properly, and all users would
  157. update to this new version. But since this is the real world it just won't
  158. happen, which makes the value of OffsetSchema unreliable. Too bad, because this
  159. wouldn't have been a problem if Microsoft had specified that the new tag
  160. represented the original offset of the maker notes instead of the difference
  161. from the original position. With this change, the tag wouldn't need updating
  162. when the EXIF is edited, and the information would be much more reliable. The
  163. only problem here would be editing software that explicitly changes the maker
  164. note offsets. However, software with this ability is rare, and it is more
  165. reasonable to ask that the OffsetSchema tag simply be deleted by any software
  166. that updates the maker note offsets. (Software must be fairly advanced in the
  167. first place if it parses the proprietary maker note data structures and changes
  168. these offsets.)</blockquote>
  169. <p><b>A simple solution:</b></p>
  170. <p>Create a new tag which comes before the maker notes (hex. 0x927B, dec. 37499
  171. would be good) and represents the original offset of the maker notes.</p>
  172. <a name="JPEG"></a>
  173. <h3>JPEG File Interchange Format <a class=ref href="#ref8">[8]</a></h3>
  174. <p>The JPEG File Interchange Format version 1.02 was released in 1992. The
  175. biggest structural problem with this standard is that metadata in these files in
  176. is stored in segments which have a maximum size of 65533 bytes. This limit has
  177. necessitated a number of creative solutions, each creating complications and
  178. problems of their own. <i>[See my comments on the <a
  179. href="writing.html#Preview">PreviewImage problem</a> for example.]</i></p>
  180. <p><b>A simple solution:</b></p>
  181. <p>Since the value of the segment size word includes the 2 bytes of the segment
  182. size word itself, a value of 0 or 1 is not allowed by the current JPEG standard.
  183. The standard could be enhanced so a value of 1 indicates an extended JPEG
  184. segment where the 2-byte size word (with value 0x0001) is followed immediately
  185. by a 4-byte integer giving the size of the extended JPEG segment. This would
  186. allow segment sizes of up to 4294967291 bytes (assuming the size includes these
  187. 4 bytes). Further, a value of 0 could be defined for an 8-byte integer if one
  188. really wanted to support huge metadata segments. Either change to an existing
  189. JPEG would break all current JPEG reader/writers, but the change is trivial and
  190. could easily be implemented.</p>
  191. <p><b>An alternative solution:</b></p>
  192. <p>Define a new application marker segment which uses a 4-byte size word. This
  193. technique is already used for the extended JPEG2000 codestream MCT, MCC and MIC
  194. marker segments.</p>
  195. <a name="MPF"></a>
  196. <h3>Multi-Picture Format (MPF) <a class=ref href="#ref9">[9]</a></h3>
  197. <p>In February 2009 CIPA<a class=ref href="#ref10">[10]</a> released a
  198. "Multi-Picture Format" standard for storing large images in JPEG files. This
  199. format is yet another attempt to bypass the JPEG segment-size limit (see above)
  200. to store large preview images. But again, there is a significant problem with
  201. this standard: Pointers in the new APP2 MPF segment use offsets relative to the
  202. start of the MPF header in this segment to reference image data after the JPEG
  203. EOI. Unfortunately, these offsets are quickly broken if any data after the MPF
  204. segment changes length. This problem could have been avoided if offsets had
  205. been specified relative to the end of file, but it is too late for this now that
  206. the specification is public. However, another problem is that information after
  207. the JPEG EOI is often discarded by software when the file is edited.</p>
  208. <p><b>A possible work-around:</b></p>
  209. <p>Enforce the rule that the MPF APP2 segment must come after all other APP
  210. segments. (It would have been smart if this was specified in the CIPA standard,
  211. but sadly this wasn't the case.) If this is done, then metadata in the remaining
  212. APP segments (EXIF, IPTC, XMP, etc) can safely be edited without breaking the
  213. MPF offsets. I suggest that all metadata editors employ this strategy,
  214. regardless of the segment order specified in the standard (which says that the
  215. MPF APP2 segment must come immediately after the EXIF APP1 segment).</p>
  216. <p>Unfortunately this work-around has the same problems as the Microsoft
  217. OffsetSchema tag because the MPF information may easily be invalidated by an
  218. unaware editor, and it doesn't address the problem of losing data stored after
  219. the JPEG EOI.</p>
  220. <p><b>A simple solution:</b></p>
  221. <p>Change the JPEG specification to allow larger segments (as mentioned above in
  222. the JPEG section), and change the MPF specification to store all information
  223. inside a JPEG segment.</p>
  224. <p><i>[2014-04-29: CIPA has changed the location of these standards documents,
  225. so the URL's referenced here are now broken.]</i></p>
  226. <a name="refs"></a>
  227. <h3>References</h3>
  228. <ol>
  229. <li><a name="ref1" href="http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf">http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf</a></li>
  230. <li><a name="ref2" href="http://partners.adobe.com/public/developer/en/tiff/TIFFPM6.pdf">http://partners.adobe.com/public/developer/en/tiff/TIFFPM6.pdf</a></li>
  231. <li><a name="ref3" href="http://www.adobe.com/products/dng/pdfs/dng_spec_1_3_0_0.pdf">http://www.adobe.com/products/dng/pdfs/dng_spec_1_3_0_0.pdf</a></li>
  232. <li><a name="ref4" href="http://www.cipa.jp/english/hyoujunka/kikaku/pdf/DC-008-2010_E.pdf">http://www.cipa.jp/english/hyoujunka/kikaku/pdf/DC-008-2010_E.pdf</a></li>
  233. <li><a name="ref5" href="http://www.metadataworkinggroup.org/pdf/mwg_guidance.pdf">http://www.metadataworkinggroup.org/pdf/mwg_guidance.pdf</a></li>
  234. <li><a name="ref6" href="http://www.adobe.com/devnet/xmp/">http://www.adobe.com/devnet/xmp/</a></li>
  235. <li><a name="ref7" href="http://support.microsoft.com/kb/927527">http://support.microsoft.com/kb/927527</a></li>
  236. <li><a name="ref8" href="http://www.jpeg.org/public/jfif.pdf">http://www.jpeg.org/public/jfif.pdf</a></li>
  237. <li><a name="ref9" href="http://www.cipa.jp/english/hyoujunka/kikaku/pdf/DC-X007-KEY_E.pdf">http://www.cipa.jp/english/hyoujunka/kikaku/pdf/DC-X007-KEY_E.pdf</a></li>
  238. <li><a name="ref10" href="http://www.cipa.jp/english/hyoujunka/kikaku/cipa_e_kikaku_list.html">http://www.cipa.jp/english/hyoujunka/kikaku/cipa_e_kikaku_list.html</a></li>
  239. </ol>
  240. <hr>
  241. <i>Created Sep 17, 2009</i><br>
  242. <i>Last revised Apr 23, 2015</i>
  243. <p class='lf'><a href="index.html">&lt;-- Back to ExifTool home page</a></p>
  244. </body>
  245. </html>