writing.html 13 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239
  1. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
  2. "http://www.w3.org/TR/html4/loose.dtd">
  3. <html>
  4. <head>
  5. <title>Writing Meta Information</title>
  6. <link rel=stylesheet type='text/css' href='style.css' title='Style'>
  7. <style type="text/css">
  8. <!--
  9. pre { color: #800; margin-left: 4em }
  10. -->
  11. </style>
  12. </head>
  13. <body>
  14. <div class='index'>
  15. <a href="#Abstract">Abstract</a>
  16. <br><a href="#Background">Background</a>
  17. <br><a href="#Implementation">Current Implementation</a>
  18. <br><a href="#Mandatory">Mandatory Tags</a>
  19. <br><a href="#JPEG">The JPEG Segment Size Limitation</a>
  20. <br><a href="#Preview">The Preview Image Problem</a> (<i>updated 2009-06-12</i>)
  21. <br><a href="#IFD0">IFD0/ExifIFD Ambiguity</a>
  22. </div>
  23. <h1 class='up'>Writing Meta Information</h1>
  24. <a name='Abstract'></a>
  25. <h3>Abstract</h3>
  26. <p>Writing meta information is more complicated than it may appear at first
  27. glance, which may be one reason why there are very few utilities around that do
  28. it. ExifTool uses tag names to identify the different pieces of meta information
  29. that can be extracted from a file. There are thousands of different tags that
  30. ExifTool recognizes, and many of these tag names are common between different
  31. metadata formats (the WhiteBalance tag is the worst offender, and can be found
  32. in 44 different places [ExifTool 8.33]), and sometimes the information can even
  33. be stored in different places within a single format. Couple this with the fact
  34. that many manufacturers store meta information in undocumented formats which
  35. must be reverse engineered (and each of which have their particular quirks), and
  36. you have a very complex situation.</p>
  37. <p>ExifTool attempts to simplify this situation as much as possible by making
  38. reasonable decisions about where to write the information you specify, yet it
  39. maintains flexibility by allowing you to configure its priorities if necessary,
  40. or even override the decision making process entirely.</p>
  41. <a name='Background'></a>
  42. <h3>Background</h3>
  43. <p>For a long time, I resisted adding write abilities to ExifTool even though it
  44. was an oft-requested feature. My concerns in adding this feature were:</p>
  45. <ol>
  46. <li>It would complicate the ExifTool interface and make it too confusing for
  47. typical users.</li>
  48. <li>It would complicate the code enough to slow down processing for normal use.</li>
  49. <li>It would take a LOT of work to implement.</li>
  50. </ol>
  51. <p>After thinking about this for a while, I was finally able to come up with some
  52. solutions:</p>
  53. <p>1. I designed an interface that I think is easy to use for people who
  54. don't want to know the details of the file structure, yet powerful enough for
  55. people who want to do very specific things to the information.</p>
  56. <p>2. I isolated all of the writing code as much as possible into separate files
  57. which autoload as required. This keeps the compilation fast for people who
  58. don't require the write feature. Also, I have left the reading routines
  59. unchanged, so they aren't slowed down by the extra code needed when writing
  60. information. Unfortunately, this meant I couldn't borrow a lot of code from the
  61. read routines (even more work for me!), but it had the advantage that I could
  62. perform additional optimizations in the write routines that I couldn't do
  63. otherwise. Although the startup costs of this implementation are fairly high
  64. (for writing only), it should be quite fast for batch writing of multiple files.</p>
  65. <p>3. I decided to bite the bullet and invest the time required (...guess what I
  66. did for my Christmas vacation!). Although I thought that a big project like
  67. this would be better suited to C++ (faster execution and a broader potential
  68. user base), after programming this so far in Perl I have grown to really
  69. appreciate the automatic memory handling and other great features of Perl such
  70. as hash lookups and incredible flexibility in text manipulations afforded by
  71. regular expressions.</p>
  72. <a name='Implementation'></a>
  73. <h3>Current Implementation</h3>
  74. <p>Currently, ExifTool can write most of the EXIF tags that anyone could reasonably
  75. want to change (but some tags are protected because they describe physical
  76. characteristics of the image that you can not change with ExifTool, eg.
  77. Compression). Also, all of the GPS, IPTC and XMP information and most of the
  78. MakerNotes information can be edited. This gives you great power, but with
  79. great power, comes great responsibility...</p>
  80. <p>It is possible for you to write nonsense into a file, which could cause other
  81. image readers to throw up their hands in despair and refuse to read the image.
  82. For this reason, it is best to always preserve the original copy of your image
  83. file. The "exiftool" script does this for you automatically by renaming the
  84. original file and always working on a copy.</p>
  85. <p>The writing logic for ExifTool is the reverse of the reading logic. You
  86. provide human-readable values and ExifTool will perform the conversions for you.
  87. For instance, you can set "WhiteBalance" to "Daylight" and ExifTool will change
  88. the value of WhiteBalance in the image wherever the tag is found provided that
  89. "Daylight" is a valid value for that location. ExifTool will even do some simple
  90. matching so that you could even just set it to "day", and ExifTool will search
  91. through the valid values and will choose the one that contains the string "day".
  92. If the value is ambiguous, the tag will not be set. If no tags can be set with
  93. the specified value, ExifTool returns an error message.</p>
  94. <p>The tag values can also be specified at a numerical level by disabling the
  95. print conversions that are normally applied. This can be done on a tag-by-tag
  96. basis or on a global basis through either the application or the API.</p>
  97. <p>As well as changing tag values wherever they are found in the image, exiftool
  98. will also create the tag in the preferred group if it didn't exist there before.
  99. By default, the preferred group is the first of the following where the tag is
  100. found: 1) EXIF, 2) IPTC, 3) XMP. Alternatively, the desired group (in family 0
  101. or 1) can be specified so ExifTool only writes the tag to a single location. For
  102. example, with the command line interface, this is done using an argument like
  103. "<code>-EXIF:WhiteBalance=Manual</code>".</p>
  104. <p>If a tag is added to a group that doesn't exist, the new group is created in
  105. the file, and required mandatory tags may be created. Conversely, if the last
  106. non-mandatory tag is deleted from a group, the group is removed from the file.</p>
  107. <a name='Mandatory'></a>
  108. <h3>Mandatory Tags</h3>
  109. <p>The EXIF and IPTC standards both specify some mandatory tags. ExifTool will
  110. automatically create many of these mandatory tags as required when writing new
  111. information (and remove them again when deleting information if only mandatory
  112. tags remain). However, some mandatory tags (particularly in the IPTC
  113. information) can not be easily added automatically, so it is left up to the user
  114. to add these tags if required.</p>
  115. <blockquote class='aside'>
  116. <b>Rant:</b> Let me say that the whole concept of mandatory tags is flawed.
  117. Instead of mandatory tags, the standard should specify default values to be
  118. assumed if the tags don't exist. A robust reader has to do this anyway, so it
  119. is redundant to require that this information must be written. In the case
  120. where there is no simple default value, the reader must be able to deal with the
  121. missing tag, otherwise it places the burden on the writer to magically pull a
  122. reasonable value out of thin air. Of course, you may say that the writer could
  123. get this information from the user, but conditions like this add an unnecessary
  124. level complexity to the user interface.
  125. </blockquote>
  126. <a name='JPEG'></a>
  127. <h3>The JPEG Segment Size Limitation</h3>
  128. <p>An unfortunate aspect of the JPEG format is that the size of a single segment
  129. is limited to less than 64 kB. With the 2-byte size word at the start of each
  130. segment, this leaves 65533 bytes for data. The EXIF specification states that
  131. the data must fit within a single <b>APP1</b> segment (which results in the
  132. preview image problem discussed below), however <b>APP13</b> Photoshop and
  133. <b>APP2</b> ICC Profile and FPXR information may span multiple segments. This
  134. multi-segment information is handled properly by ExifTool.</p>
  135. <p>JPEG comments may also exceed the size of a single <b>COM</b> segment. If
  136. necessary, comments are automatically split into separate segments when writing.
  137. However, when reading they are not joined together because some utilities store
  138. distinctly different comments in separate segments. To extract all JPEG
  139. comments into a single file, and combine any comments that may have been split
  140. into multiple segments, use "<code>exiftool -a -b -comment src.jpg &gt;
  141. comment.out</code>".</p>
  142. <a name='Preview'></a>
  143. <h3>The Preview Image Problem</h3>
  144. <p>Writing the preview image in JPEG files poses many problems of its own. These
  145. problems stem from the fact that the JPEG standard is inadequate for storing
  146. large preview images due to the 64kB limit on segment size as mentioned above.
  147. (Note that TIFF images don't have this problem since they have a 4GB limit.)
  148. Some manufacturers get around this by appending the preview after the normal end
  149. of the JPEG file (JPEG EOI), but this causes complications because it means that
  150. the preview image pointers in the EXIF information now point outside the EXIF
  151. segment. This is truly unfortunate because it greatly complicates things for
  152. image writing software. Most other software can't deal with a preview image and
  153. will simply remove a preview like this when rewriting the file.</p>
  154. <p>However, as of ExifTool version 5, the preview images are handled properly
  155. when writing EXIF information in JPEG files. But for reasons of efficiency, the
  156. EXIF segment is not edited when writing information if no EXIF tags are being
  157. changed (eg. if only XMP or IPTC information is being edited). In this case,
  158. the preview image pointers could be invalidated because the length of the data
  159. between the EXIF segment (which comes near the start of the file) and the
  160. preview image (at the end of the file) is likely to change. ExifTool gets
  161. around this when reading JPEG images by looking for the preview at the end of
  162. the file and updating pointers if necessary, but the preview image may not be
  163. readable by other software (it should be noted though that very few image
  164. readers even know the preview image exists). However, the preview pointers in
  165. such a file can be fixed if necessary by simply using ExifTool to edit any EXIF
  166. information.</p>
  167. <p><b>2009-05-26</b>: New Samsung cameras recently started embedding preview
  168. images larger than 64 kB, and of course they created a new technique to do so.
  169. If they were smart, they would have developed a simple technique that could be
  170. used by others in the future, but of course they were stupid, and didn't think
  171. that far ahead. (Such is the normal path of dumb camera manufacturers when it
  172. comes to metadata.)</p>
  173. <p>The new Samsung models simply split the preview and write it to separate APP2
  174. segments with no header. If they had written a header (like "PREVIEW\0" for
  175. example), then the technique could be portable and useful. But they didn't.
  176. Without a header, the data can not easily be distinguised from other random APP2
  177. data, so this technique is not generally useful. Of course, there are
  178. disadvantages with splitting up a preview into separate JPEG segments, so this
  179. technique in general is not ideal.</p>
  180. <p><b>2009-06-12</b>:
  181. <a href="http://www.cipa.jp/english/hyoujunka/kikaku/cipa_e_kikaku_list.html">CIPA</a>
  182. has recently released a "<b>Multi-Picture Format</b>" standard for storing large
  183. images in JPEG files. Again, there is a big problem with this standard: It
  184. uses offsets that are relative to the start of the MPF header (in the new MPF
  185. APP2 segment) to reference images after the JPEG EOI. These offsets will
  186. quickly be broken if any data after the MPF segment changes length. This
  187. problem could have been avoided if offsets had been specified relative to the
  188. end of file, but it is too late for this now that the specification is
  189. public.</p>
  190. <p>The only workable alternative I can see is to enforce the rule that the MPF
  191. APP2 segment must come after all other APP segments. (It would have been smart
  192. if this was specified in the CIPA standard, but sadly this isn't the case.) If
  193. this is done, then metadata in the remaining APP segments (EXIF, IPTC, XMP, etc)
  194. can safely be edited without breaking the MPF offsets. I suggest that all
  195. metadata editors employ this strategy, regardless of the segment order specified
  196. in the standard (which says that the MPF APP2 segment must come immediately
  197. after the EXIF APP1 segment).</p>
  198. <a name='IFD0'></a>
  199. <h3>IFD0/ExifIFD Ambiguity</h3>
  200. <p>ExifTool has a preferred location (IFD) where it writes all EXIF tags.
  201. However, a number of tags are written to different locations by various digital
  202. cameras or image editors. Specifically, the following tags have been observed
  203. in both IFD0 and ExifIFD: Make, Model, Software, Artist, DateTimeOriginal,
  204. SensingMethod, CustomRendered, ExposureMode, WhiteBalance, DigitalZoomRatio and
  205. SceneCaptureType. To handle this ambiguity, ExifTool will delete the tag if it
  206. exists in IFD0 when it is written to ExifIFD, and vice versa.</p>
  207. <hr>
  208. <i>Created Dec. 30, 2004</i><br>
  209. <i>Last revised Oct. 4, 2010</i>
  210. <p class='lf'><a href="index.html">&lt;-- Back to ExifTool home page</a></p>
  211. </body>
  212. </html>