commentary.html 16 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319
  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>Commentary on Meta Information Formats</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. .norm { font-weight: normal }
  12. -->
  13. </style>
  14. </head>
  15. <body>
  16. <div class='index'>
  17. <b>What sucks:</b>
  18. <br><a href="#EXIF">EXIF / TIFF</a>
  19. <br><a href="#Maker">EXIF Maker notes</a>
  20. <br><a href="#JPEG">JPEG</a>
  21. <br><a href="#IPTC">IPTC IIM</a>
  22. <br><a href="#XMP">XMP</a>
  23. <br><a href="#PDF">PDF</a>
  24. <br><a href="#PNG">PNG</a>
  25. <br><a href="#PICT">PICT</a>
  26. <br><a href="#FlashPix">FlashPix</a>
  27. <br><a href="#DICOM">DICOM</a>
  28. <br><a href="#AVCHD">AVCHD</a>
  29. <br><a href="#ISO">ISO</a>
  30. <br><b>What doesn't:</b>
  31. <br><a href="#CRW">CRW (CIFF)</a>
  32. <br><a href="#QuickTime">QuickTime</a>
  33. <br><a href="#MIE">MIE</a>
  34. </div>
  35. <h2 class='up'>Commentary on Meta Information Formats<br>
  36. <span class='sm'>(or <i>"Why this or that Format Sucks"</i>)</span></h2>
  37. <a name='EXIF'></a>
  38. <h3>EXIF / TIFF</h3>
  39. <p>EXIF uses the TIFF format to store information. The biggest problem with
  40. this format is that all pointers are absolute (ie. relative to the start of
  41. the file). This means that the pointers need fixing up if the position of
  42. any information changes. This is significant because pointers are often
  43. hidden inside proprietary structures which should remain opaque (such as
  44. maker notes). The result is that some EXIF information is easily corrupted
  45. when editing a file. This problem is ignored by many software packages.
  46. Much effort was required in the development of ExifTool to avoid the loss of
  47. information such as this.</p>
  48. <p>A significant problem is that an IFD (image file directory) pointer has
  49. the same format code as a long integer, so information in any non-recognized
  50. IFD is lost when the image is rewritten. There is a seldom-used format
  51. code of 13 that has been proposed to indicate an IFD, but this is not part
  52. of the EXIF/TIFF specification and is not in common usage. <i class=lt>[Hey!
  53. Olympus has just started using this code for the IFD's in the maker notes of
  54. their new Camera models! - 2007/03/08]</i></p>
  55. <p>Also, it was wrong to specify a count instead of a size for each
  56. directory entry because this makes it impossible to add new format types
  57. without requiring that older readers simply discard data of unknown type
  58. (since the data size isn't known, the old readers don't know how to copy the
  59. data).</p>
  60. <p>All these shortcomings make TIFF a very non-extensible format which by
  61. design will result in the loss of non-standard information.</p>
  62. <p>And we don't learn from our mistakes (OK, maybe some of us can, but
  63. apparently not big corporations like Adobe or Microsoft), because the new
  64. DNG and WDP formats are TIFF-based too.</p>
  65. <p>The EXIF specification also has some significant shortcomings to add to the
  66. TIFF problems, like minimal special character abilities, no language support,
  67. and no way to specify time zone.</p>
  68. <a name='Maker'></a>
  69. <h3>EXIF Maker Notes</h3>
  70. <p>Maker notes are a can of worms. The EXIF specification unfortunately
  71. made no mention about the information format of the maker notes. If
  72. properly designed, the specification would have provided a maker note IFD
  73. tag to allow IFD-style maker notes to be used. Many manufacturers
  74. implemented it this way, but each with a different technique and many with
  75. <a href="idiosyncracies.html">odd quirks</a>. This deficiency combined with
  76. problems in the TIFF (EXIF) format mean that most software will quite
  77. unknowingly scramble your maker notes when an image is rewritten. To
  78. prevent this, specific knowledge about files written by individual
  79. manufacturers is necessary, and of course the manufacturers are not prone to
  80. divulging this information to the public so it must all be reverse
  81. engineered.</p>
  82. <p>The official TIFF recommendation is to delete unknown information when
  83. rewriting an image<a class=ref href="#ref1">[1]</a>, and this irresponsible
  84. strategy has been adopted by some applications such as Adobe Photoshop,
  85. resulting in a total loss of maker note information. This is very
  86. unfortunate because even corrupted maker notes contain useful information,
  87. and smart utilities (like ExifTool) are often able to recover the
  88. information from damaged maker notes.</p>
  89. <a name='JPEG'></a>
  90. <h3>JPEG</h3>
  91. <p>The JPEG format acts only as a container for meta information, and
  92. defines no meta information format itself. But it sucks just a as a
  93. container format because it limits the maximum contiguous block size to
  94. 64kB. This causes problems because many cameras store more than 64kB of
  95. additional information in their JPEG images. Usually, this is due to the
  96. medium-sized JPEG image that many cameras embed for preview purposes. It
  97. would have been nice if there was a standard way to embed this preview in
  98. JPEG images (without the 64kB limitation). <i class=lt>[Update: In February
  99. 2009 CIPA released the MPF format specification which allows storage of
  100. preview images larger than 64kB, but unfortunately this specification
  101. <a href="standards.html#MPF">has problems of its own</a>.]</i></p>
  102. <p>Aside: The EXIF specification could have easily allowed the information
  103. to span multiple JPEG segments, which would have been smart, but still
  104. wouldn't have solved the problem entirely since it could result in a
  105. non-contiguous preview image (this would be a problem for cameras since they
  106. typically want to use this image for quick review of pictures, and
  107. re-mapping the image into a contiguous memory space would be costly).</p>
  108. <a name='IPTC'></a>
  109. <h3>IPTC IIM</h3>
  110. <p>IPTC IIM earns a few points because it is the easiest to process of the
  111. common meta information formats. However, the format is overly restrictive
  112. and not very extensible. Format information and human-readable tag names
  113. are not part of the specification, so it is not possible to meaningfully
  114. interpret unknown values. Also, there are many interdependencies between
  115. tags that make it very annoying for writing, and the special character
  116. support is ill-conceived.</p>
  117. <a name='XMP'></a>
  118. <h3>XMP</h3>
  119. <p>The XMP format is a good example of a designed-by-committee
  120. specification. It is based on XML, which is much more complicated than
  121. necessary and tries to make everyone happy by providing a multitude of
  122. format styles and features (shorthand format, etc, etc). This makes it very
  123. difficult to properly implement the complete specification. Not even the
  124. Adobe software supports all of the format options of their own XMP
  125. specification. And the format is exceedingly verbose, wasting disk space,
  126. bandwidth and time.</p>
  127. <p>Also, XMP only supports textual information. Binary information must be
  128. text-encoded if stored in XMP. This makes it very bulky, slow and
  129. completely unsuitable for storage of binary information.</p>
  130. <p>Mainly because of the complexity of the specification, and despite
  131. Adobe's best efforts, XMP still isn't very well supported by meta
  132. information editing tools. The best hope for small application developers
  133. is to link against an off-the-shelf XMP or XML library. Apparently Adobe
  134. realizes this and is now providing an XMP development kit, but this solution
  135. is only useful for those platforms and computer languages that they choose
  136. to support.</p>
  137. <a name='PDF'></a>
  138. <h3>PDF</h3>
  139. <p>...and I thought XMP was too complicated. PDF is just insane. Because
  140. of this, it is unlikely that ExifTool will ever support this format for
  141. writing. <i class=lt>[Dec. 18, 2007 Update: I have just added PDF write support
  142. using the incremental update feature of PDF. It was still a bit of work, but
  143. somewhat simpler (and MUCH faster!) than rewriting the entire PDF. But there
  144. are disadvantages: The resulting PDF is not "linearized", and there are privacy
  145. and security issues with leaving old metadata in the file.]</i></p>
  146. <a name='PNG'></a>
  147. <h3>PNG</h3>
  148. <p>PNG sucks because meta information can be stored only in text format.
  149. This was a huge mistake, and as a work-around software (eg. ImageMagick)
  150. must encode binary information in ASCII-hex, then compress it to offset the
  151. increase in size, and store it as a compressed text block. This adds
  152. unnecessary complexity, greatly slows down processing, and makes it much
  153. harder to develop software which supports PNG meta information.</p>
  154. <a name='PICT'></a>
  155. <h3>PICT</h3>
  156. <p>The PICT format just plain sucks. It is one of the worst-designed image
  157. formats in existence, second only to FlashPix. I don't believe that it was
  158. originally designed as a file format. Instead it appears to have emerged
  159. from the internal Apple QuickDraw structures. The files are not designed to
  160. be processed by any software other than the Mac OS. Intimate knowledge of
  161. the QuickDraw structures is required just to parse the PICT image, even if
  162. the reader doesn't care about the contained information. Because of this,
  163. PICT images are very fragile and a simple data error or programming bug will
  164. invalidate an entire image. Possibly for these reasons the PICT format
  165. never gained popularity outside the Apple world. Also, the concept of meta
  166. information is all but ignored in the PICT design.</p>
  167. <a name='FlashPix'></a>
  168. <h3>FlashPix</h3>
  169. <p>Oh. My. God. Don't get me started on this one. Let's just say that basing
  170. an image file format on the File Allocation Table (FAT) structure of a floppy
  171. disk with fixed 512-byte sectors is monumentally idiotic. Microsoft Word,
  172. Excel and PowerPoint documents also use this insane format.</p>
  173. <a name='DICOM'></a>
  174. <h3>DICOM Medical Images</h3>
  175. <p>The DICOM format is reasonably well designed. The UID's are cumbersome,
  176. but achieve their purpose. The biggest bungle in the design is the implicit
  177. VR syntax, which presumably exists for historical reasons to provide
  178. backward compatibility with pre-existing ACR-NEMA images. The DICOM
  179. specification document is horrible and obviously written by committee, and
  180. was possibly the single largest impediment to implementing support for this
  181. format.</p>
  182. <p>Technical: The files would be easier to parse if the transfer syntax
  183. became effective immediately after the transfer syntax data element instead
  184. of at the end of the meta information group. Also, the deflated data should
  185. have contained the zlib header, as in PNG and PDF images. This would make
  186. it easier to read and allow CRC validation of the datastream. -- Can you
  187. tell I wrote this just after adding DICOM support to ExifTool?</p>
  188. <a name='AVCHD'></a>
  189. <h3>AVCHD (.M2TS) <span class='sm norm'><i class=lt>(added 2009-10-29)</i></span></h3>
  190. <p>This format is used in .M2TS video files (and Blu-Ray HD DVD's). It is
  191. painfully obvious that this was never designed as a storage format. It uses
  192. MPEG-2 transport stream (M2TS) container, which is a communications protocol
  193. and never should have been used for storage. The M2TS format is based on a
  194. 188-byte packet size which makes no sense for modern filesystems. And to
  195. make things worse, metadata in AVCHD files is stored in the H.264 video
  196. stream (!!) which uses insane and convoluted data structures such as the
  197. variable-bit-length exponential-Golomb which are painful and inefficient to
  198. parse in software, and as far as I can tell the format for the metadata
  199. stored in these streams is proprietary and undocumented.</p>
  200. <a name='ISO'></a>
  201. <h3>ISO Considered Harmless</h3>
  202. <p>This is not a meta information format, but since many format
  203. specifications are imprisoned by the ISO it deserves mentioning...</p>
  204. <p>In my experience, the International Standards Organization is extremely
  205. counter-productive. Their goal is to promote standardization, but by
  206. charging too much money for copies of the standards documents they defeat
  207. their own purpose. The effect is that small companies and individuals
  208. developing software (including open source software such as ExifTool) do not
  209. have access to the official standard. Instead, software is often based on
  210. old, obsolete documents or drafts which are sometimes publicly available, or
  211. on 3rd party descriptions which are often incomplete. To sum things up: ISO
  212. sucks.</p>
  213. <hr>
  214. <h2>OK. So all those formats suck. What doesn't?</h2>
  215. <a name='CRW'></a>
  216. <h3>Canon CRW Images (CIFF format)</h3>
  217. <p>This format uses a directory structure similar to TIFF, but all offsets
  218. are relative and unknown information can handled properly when rewriting.
  219. Because of this, it is much more extensible than TIFF, but the format is
  220. still limited by 16-bit integer tag ID's among other TIFF weaknesses. It
  221. isn't great, but at least it doesn't suck.</p>
  222. <a name='QuickTime'></a>
  223. <h3>QuickTime Videos</h3>
  224. <p>The Apple QuickTime MOV format is very nice format. (Which is a breath
  225. of fresh air after the Apple PICT travesty.) It was a smart move to use
  226. this format for the MP4 specification. I would only change 2 things about
  227. this format: 1) Use longer tag names instead of the current 4 characters (I
  228. know that 4 characters is convenient because it can be used as an integer in
  229. lookup tables, but it would be nice if the tag names were a bit more
  230. meaningful). 2) Add a format code to the Atom definition so simple unknown
  231. information could be decoded properly. These changes would allow some
  232. unknown information to be interpreted, which would make it possible for
  233. information added by 3rd parties to be useful.</p>
  234. <p>I only have 2 problems with the QuickTime specification:</p>
  235. <p>1) The metadata organization is a mess because tags may be stored in more
  236. than one location (eg. UserData vs. InfoList), and conflicting metadata
  237. directories may exist, even in the same location (as written by iTunes).</p>
  238. <p>2) The length of 'udta' text strings with language codes is written
  239. incorrectly by many (most?) utilties, including Apple iTunes. The language
  240. strings are supposed to use a "small integer atom format" where the first
  241. two bytes give the size of the string including the length word and language
  242. codes. But often the size doesn't include these 4 bytes, which sort of
  243. defeats the purpose of the multiple languages because it is difficult to
  244. parse past the first entry if you don't know the size.</p>
  245. <a name='MIE'></a>
  246. <h3>My Format (Meta Information Encapsulation, or "MIE")</h3>
  247. <p>Now it is time to put my money where my mouth is: I have designed a
  248. format which doesn't suck. It is called "MIE", which stands for Meta
  249. Information Encapsulation.</p>
  250. <p>The MIE format is hierarchical like QuickTime, but it uses meaningful tag
  251. names and specifies a data format for all values. As well, this format
  252. offers a number of other features:</p>
  253. <ul>
  254. <li>Can be used as a wrapper around any type of file, as a trailer appended
  255. to other formats, or as a stand-alone meta information format
  256. <li>Extensible
  257. <li>Compact
  258. <li>Meaningful tag ID's
  259. <li>Streamable (and single-pass writing possible)
  260. <li>Relocatable data elements (ie. no fixed offsets)
  261. <li>Relatively simple to implement reader/writer
  262. <li>Supports large data lengths (up to 4GB*4GB)
  263. <li>Localized text feature
  264. <li>Built-in support for numerical units of measure
  265. <li>Multiple documents in a single file
  266. </ul>
  267. <p>The specification for this format can be found
  268. <a href="MIE1.1-20070121.pdf">here</a>, and is implemented in
  269. <a href="http://search.cpan.org/dist/Image-ExifTool/lib/Image/ExifTool/MIE.pm">Image::ExifTool::MIE.pm</a></p>
  270. <p>OK. Flame away. I can take it.</p>
  271. <a name="refs"></a>
  272. <h3>References</h3>
  273. <ol>
  274. <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>, page 26</li>
  275. </ol>
  276. <hr>
  277. <i>Created Nov. 15, 2005</i><br>
  278. <i>Last revised July 29, 2010</i>
  279. <p class='lf'><a href="index.html">&lt;-- Back to ExifTool home page</a></p>
  280. </body>
  281. </html>