RubyGems - exiftool_vendored - Versions diffs - 10.49.0 → 10.56.0 - Mend

exiftool_vendored 10.49.0 → 10.56.0

Potentially problematic release.

This version of exiftool_vendored might be problematic. Click here for more details.

Files changed (1010) hide show

data/bin/Image-ExifTool-10.49/html/style.css DELETED Viewed

@@ -1,31 +0,0 @@
-body      { font-family: helvetica; font-size: .9em;
-            color: black; background: white }
-a:link    { color: blue }
-a:visited { color: #508 }
-a:active  { color: red }
-.blk      { color: black }
-.red      { color: #c00 }
-.grn      { color: #080 }
-.blu      { color: blue }
-.com      { color: #a00 }
-.aside    { color: #864 }
-.lt       { color: #666 }
-.lg       { font-size: larger }
-.sm       { font-size: smaller }
-.up       { margin: 0 0 .5em 0 }
-p         { margin: 1em 1em }
-p.lf      { margin: 1em 0 }
-.code     { color: #800; }
-code      { color: #800; font-family: monaco, monospace;
-            font-size: 1em; white-space: nowrap }
-pre       { font-family: monaco, monospace; font-size: 1em }
-div.index { float: right; clear: both;
-            border-left: 1px solid gray;
-            margin: .5em 0 .5em .5em; padding: 0 .5em }
-table.box { padding: .2em; background: #ddd }
-table.norm     { border-collapse: collapse;
-                 border: 1px solid gray; }
-table.norm th  { border: 1px solid gray; background: #ddd }
-table.norm td  { border: 1px solid gray; padding: 2px 4px }
-table.clear td { border: 0; padding: 0 2px }
-table.tight td { padding: 1px 4px }

data/bin/Image-ExifTool-10.49/html/under.html DELETED Viewed

@@ -1,137 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
-        "http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">
-<html>
-<head>
-  <title>Under the Hood</title>
-<link rel=stylesheet type='text/css' href='style.css' title='Style'>
-<style type="text/css">
-<!--
-pre         { margin: 0 }
-ol.index    { margin: 0; padding: 0 0 0 2em }
--->
-</style>
-</head>
-<body>
-<div class='index'>
-<a href="#overview">Overview</a>
-<br><a href="#conversions">Value Conversions</a>
-<br><a href="#philophies">Underlying Philosophies</a>
-</div>
-<h1 class='up'>"Under the Hood" of ExifTool</h1>
-<p>This page is a work in progress, and will be used to explain some details
-of ExifTool's inner workings.</p>
-<a name="overview"></a>
-<h2>Overview of ExifTool</h2>
-<p>Below is a diagram showing the flow of information for the exiftool
-application.  Indicated outside the boxes on the diagram are some command-line
-options associated with the various stages of processing.  All of these options
-are directly associated with options or function calls available via the API
-(Application Programming Interface), with the exception of the output text
-formatting which is handled at the application level.</p>
-<center><img src="overview.png" alt="ExifTool Overview" width="680" height="460"></center>
-<p>The information flow is separated into two distinct modes: 1)
-<span class=blu>Reading or extracting information</span>, and 2)
-<span class=red>Writing or editing</span>.  The application runs in
-<b class=blu>read</b> mode by default, but switches to <b class=red>write</b> mode
-if a new value is assigned to any tag (via "<code>-TAG=</code>",
-"<code>-tagsFromFile</code>", "<code>-geotag</code>", "<code>-csv=</code>" or
-"<code>-json=</code>" on the command line).</p>
-<a name="conversions"></a>
-<h2>Value Conversions</h2>
-<p>When ExifTool reads or writes the value of a tag, there are 3 separate
-conversions applied to each value, resulting in 4 different levels for the value
-of each tag.  By default, users interact only with the human-readable
-("<b>PrintConv</b>") value, but other levels are exposed through various exiftool
-options:</p>
-<ol start=3><li>The "<b>PrintConv</b>" value is the final human-readable value
-which has been converted for display.  Often, the "PrintConv" conversion will
-translate numbers into words for better readability.  The <code>-lang</code>
-(Lang) option is used to specify the language for this conversion, and the
-<code>-c</code> and <code>-d</code> (CoordFormat and DateFormat) options specify
-this formatting for GPS coordinates and date/time values.</li></ol>
-<ol start=2><li>For numerical values, the "<b>ValueConv</b>" value is a
-machine-readable value suitable for use in calculations, typically converted to
-standard units (eg. degrees, meters, or seconds).  For date/time values the
-standard EXIF date/time format is used ("YYYY:mm:dd HH:MM:SS" plus decimal
-seconds and time zone of they exist).  For tags which are a closed choice of
-string, this is the stored value of the string.  The ValueConv value is
-returned for all tags when the <code>-n</code> option is used, or for individual
-tags by suffixing the tag name with a <code>#</code> character.</li></ol>
-<ol start=1><li>The "<b>Raw</b>" value is the value after initial formatting is
-applied to the binary data from the file.  Most tags have no separate "ValueConv"
-conversion, so for these tags the "Raw" value is the same as the "ValueConv"
-value.  This value may be seen by using the <code>-v</code> option.</li></ol>
-<ol start=0><li>The "<b>Binary</b>" value is actual binary data stored in the
-file.  This data is displayed in hexadecimal form with the <code>-v3</code>
-option, or by using the <code>-htmlDump</code> feature.  Note that this value is
-not related to the <code>-b</code> (<code>-binary</code>) option, which actually
-returns the "ValueConv" value and is used for tags where this value can not be
-presented in a simple text format.  The Writable column in the
-<a href="TagNames/index.html">Tag Name documentation</a>
-gives the format of this binary data for writable tags.</li></ol>
-<p>Below are some examples of these different values for a few tags:</p>
-<blockquote><table class=norm>
-<tr><th>Tag</th><th>3.&nbsp;PrintConv</th><th>2.&nbsp;ValueConv</th><th>1.&nbsp;Raw</th><th>0.&nbsp;Binary</th></tr>
-<tr align='center'><td>EXIF:Orientation</td><td>Horizontal (normal)</td><td>1</td><td>1</td><td><pre>00 01</pre></td></tr>
-<tr align='center'><td>EXIF:GPSLatitude</td><td>45 deg 20' 11.00"</td><td>45.3363888888889</td><td>45 20 11<br>(45/1 20/1 11/1)</td>
-  <td><pre>00 00 00 2d 00 00 00 01<br>00 00 00 14 00 00 00 01<br>00 00 00 0b 00 00 00 01</pre></td></tr>
-<tr align='center'><td>XMP:GPSLatitude</td><td>45 deg 20' 11.00"</td><td>45.3363888888889</td><td>45,20.183333N</td>
-  <td>"45,20.183333N"</td></tr>
-<tr align='center'><td>EXIF:ExposureTime</td><td>1/30</td><td>0.03333333333</td><td>0.03333333333<br>(1/30)</td>
-  <td><pre>00 00 00 01 00 00 00 1e</pre></td></tr>
-<tr align='center'><td>EXIF:ShutterSpeedValue</td><td>1/30</td><td>0.0333333334629176</td><td>4.90689059<br>(19868/4049)</td>
-  <td><pre>00 00 4d 9c 00 00 0f d1</pre></td></tr>
-<tr align='center'><td>EXIF:ModifyDate</td><td>(set by <code>-d</code> option)</td><td>2016:11:25 11:56:39</td><td>2016:11:25 11:56:39</td>
-  <td>"2016:11:25 11:56:39\0"</td></tr>
-<tr align='center'><td>XMP:ModifyDate</td><td>(set by <code>-d</code> option)</td><td>2016:11:25 11:56:39.00-05:00</td><td>2016-11-25T11:56:39.00-05:00</td>
-  <td>"2016-11-25T11:56:39.00-05:00"</td></tr>
-</table></blockquote>
-<a name="philophies"></a>
-<h2>Underlying Philosophies</h2>
-<p>You have the right to know about the metadata contained in your images.  A main
-goal of the Exiftool project is to make this information freely available, both to
-the general public and as a resource for other developers.</p>
-<p>In the design of exiftool, there have been a number of underlying philosophies
-which have helped to influence the overall development:</p>
-<ol>
-<li>Make <a href="ExifTool.html">Image::ExifTool</a> as independent as possible
-    from other libraries to make it portable and easy to install.  (Portable to
-    a wide range of systems and Perl versions.)</li>
-<li>Keep the interface simple for simple tasks (sometimes at the expense of making
-    it more complicated for complex tasks).</li>
-<li>The <a href="ExifTool.html#Methods">API functions</a> should be isolated from
-    the details of the metadata formats (otherwise the interface turns into a giant
-    hairball, like the metadata).</li>
-<li>Maintain flexibility to allow users the freedom to do what they want.</li>
-<li>Design the code to be efficient for batch processing, even if it increases the
-    initial overhead.</li>
-<li>When writing files, remember 3 things: 1) data integrity, 2) data integrity, and
-    3) data integrity.  If you can't do it right, don't do it at all.</li>
-<li>If possible, recognize file types by their structure, not by their extension.</li>
-<li>Maintain backward compatibility when making changes to the ExifTool API or
-    command line application.</li>
-</ol>
-<hr>
-<i>Created Jun. 24, 2009</i><br>
-<i>Last revised Nov. 25, 2016</i>
-<p class='lf'><a href="index.html">&lt;-- Back to ExifTool home page</a></p>
-</body>
-</html>

data/bin/Image-ExifTool-10.49/html/verbose.html DELETED Viewed

@@ -1,210 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
-        "http://www.w3.org/TR/html4/loose.dtd">
-<html>
-<head>
-  <title>ExifTool Verbose Option</title>
-<link rel=stylesheet type='text/css' href='style.css' title='Style'>
-<style type="text/css">
-<!--
-pre { padding: 0; margin: 0px 2px }
--->
-</style>
-</head>
-<body>
-<h2 class='up'>ExifTool Verbose Option</h2>
-<p>With the Verbose option enabled, ExifTool prints a verbose log to the console as
-it extracts the meta information from a file.</p>
-<p>The -v option of the exiftool application allows control of the Verbose
-setting.  A number between 0 and 5 may be specified with the -v option to set a
-specific Verbose level.  For example, -v2 sets Verbose = 2.  Without a number,
--v increments the current Verbose level by one. Multiple -v options are allowed,
-so the following two examples give the same result:</p>
-<blockquote><table class='box' width='100%'><tr><td><pre>
-exiftool -v -v -v t/images/Canon.jpg
-exiftool -v3 t/images/Canon.jpg
-</pre></td></tr></table></blockquote>
-<p>Below are example outputs for different Verbose settings.</p>
-<h3>Verbose = 1</h3>
-<p>Prints tag names and extracted values.  These are the raw values straight
-from the file, before any conversions are applied.  Also printed are details of
-the file and directory structure:</p>
-<blockquote><table class='box' width='100%'><tr><td><pre>
-  ExifToolVersion = 10.00
-  FileName = Canon.jpg
-  Directory = t/images
-  FileSize = 2697
-  FileModifyDate = 1159902631
-  FileAccessDate = 1439991906
-  FileInodeChangeDate = 1439903472
-  FilePermissions = 33188
-  FileType = JPEG
-  FileTypeExtension = JPG
-  MIMEType = image/jpeg
-JPEG APP1 (2442 bytes):
-  ExifByteOrder = II
-  + [IFD0 directory with 9 entries]
-  | 0)  Make = Canon
-  | 1)  Model = Canon EOS DIGITAL REBEL
-  | 2)  Orientation = 1
-  | 3)  XResolution = 180 (180/1)
-  | 4)  YResolution = 180 (180/1)
-  | 5)  ResolutionUnit = 2
-  | 6)  ModifyDate = 2003:12:04 06:46:52
-  | 7)  YCbCrPositioning = 1
-  | 8)  ExifOffset (SubDirectory) -->
-  | + [ExifIFD directory with 31 entries]
-  | | 0)  ExposureTime = 4 (4/1)
-  | | 1)  FNumber = 14 (14/1)
-  | | 2)  ISO = 100
-  | | 3)  ExifVersion = 0221
-  | | 4)  DateTimeOriginal = 2003:12:04 06:46:52
-  [etc...]
-</pre></td></tr></table></blockquote>
-<h3>Verbose = 2</h3>
-<p>Prints all of the information from Verbose = 1, plus additional information
-about the tag ID, data size and format:</p>
-<blockquote><table class='box' width='100%'><tr><td><pre>
-  ExifToolVersion = 10.00
-  FileName = Canon.jpg
-  Directory = t/images
-  FileSize = 2697
-  FileModifyDate = 1159902631
-  FileAccessDate = 1439991927
-  FileInodeChangeDate = 1439903472
-  FilePermissions = 33188
-  FileType = JPEG
-  FileTypeExtension = JPG
-  MIMEType = image/jpeg
-JPEG APP1 (2442 bytes):
-  ExifByteOrder = II
-  + [IFD0 directory with 9 entries]
-  | 0)  Make = Canon
-  |     - Tag 0x010f (6 bytes, string[6])
-  | 1)  Model = Canon EOS DIGITAL REBEL
-  |     - Tag 0x0110 (24 bytes, string[24])
-  | 2)  Orientation = 1
-  |     - Tag 0x0112 (2 bytes, int16u[1])
-  | 3)  XResolution = 180 (180/1)
-  |     - Tag 0x011a (8 bytes, rational64u[1])
-  | 4)  YResolution = 180 (180/1)
-  |     - Tag 0x011b (8 bytes, rational64u[1])
-  | 5)  ResolutionUnit = 2
-  |     - Tag 0x0128 (2 bytes, int16u[1])
-  | 6)  ModifyDate = 2003:12:04 06:46:52
-  |     - Tag 0x0132 (20 bytes, string[20])
-  | 7)  YCbCrPositioning = 1
-  |     - Tag 0x0213 (2 bytes, int16u[1])
-  | 8)  ExifOffset (SubDirectory) -->
-  |     - Tag 0x8769 (4 bytes, int32u[1])
-  | + [ExifIFD directory with 31 entries]
-  | | 0)  ExposureTime = 4 (4/1)
-  | |     - Tag 0x829a (8 bytes, rational64u[1])
-  | | 1)  FNumber = 14 (14/1)
-  | |     - Tag 0x829d (8 bytes, rational64u[1])
-  | | 2)  ISO = 100
-  | |     - Tag 0x8827 (2 bytes, int16u[1])
-  | | 3)  ExifVersion = 0221
-  | |     - Tag 0x9000 (4 bytes, undef[4])
-  | | 4)  DateTimeOriginal = 2003:12:04 06:46:52
-  | |     - Tag 0x9003 (20 bytes, string[20])
-  [etc...]
-</pre></td></tr></table></blockquote>
-<h3>Verbose = 3</h3>
-<p>Adds a hex dump of the binary data associated with each tag.  The hex offsets
-are relative to the start of the file, unlike the default HtmlDump output where
-offsets are relative to the start of the TIFF header (the native base for
-TIFF/EXIF offsets).  If the data is very long, only the first few lines of the
-dump are printed:</p>
-<blockquote><table class='box' width='100%'><tr><td><pre>
-  ExifToolVersion = 10.00
-  FileName = Canon.jpg
-  Directory = t/images
-  FileSize = 2697
-  FileModifyDate = 1159902631
-  FileAccessDate = 1439991933
-  FileInodeChangeDate = 1439903472
-  FilePermissions = 33188
-  FileType = JPEG
-  FileTypeExtension = JPG
-  MIMEType = image/jpeg
-JPEG APP1 (2442 bytes):
-    0006: 45 78 69 66 00 00 49 49 2a 00 08 00 00 00 09 00 [Exif..II*.......]
-    0016: 0f 01 02 00 06 00 00 00 7a 00 00 00 10 01 02 00 [........z.......]
-    0026: 18 00 00 00 80 00 00 00 12 01 03 00 01 00 00 00 [................]
-    0036: 01 00 00 00 1a 01 05 00 01 00 00 00 98 00 00 00 [................]
-    0046: 1b 01 05 00 01 00 00 00 a0 00 00 00 28 01 03 00 [............(...]
-    0056: 01 00 00 00 02 00 00 00 32 01 02 00 14 00 00 00 [........2.......]
-    0066: a8 00 00 00 13 02 03 00 01 00 00 00 01 00 00 00 [................]
-    [snip 2330 bytes]
-  ExifByteOrder = II
-  + [IFD0 directory with 9 entries]
-  | 0)  Make = Canon
-  |     - Tag 0x010f (6 bytes, string[6]):
-  |         0086: 43 61 6e 6f 6e 00                               [Canon.]
-  | 1)  Model = Canon EOS DIGITAL REBEL
-  |     - Tag 0x0110 (24 bytes, string[24]):
-  |         008c: 43 61 6e 6f 6e 20 45 4f 53 20 44 49 47 49 54 41 [Canon EOS DIGITA]
-  |         009c: 4c 20 52 45 42 45 4c 00                         [L REBEL.]
-  | 2)  Orientation = 1
-  |     - Tag 0x0112 (2 bytes, int16u[1]):
-  |         0036: 01 00                                           [..]
-  | 3)  XResolution = 180 (180/1)
-  |     - Tag 0x011a (8 bytes, rational64u[1]):
-  |         00a4: b4 00 00 00 01 00 00 00                         [........]
-  | 4)  YResolution = 180 (180/1)
-  |     - Tag 0x011b (8 bytes, rational64u[1]):
-  |         00ac: b4 00 00 00 01 00 00 00                         [........]
-  | 5)  ResolutionUnit = 2
-  |     - Tag 0x0128 (2 bytes, int16u[1]):
-  |         005a: 02 00                                           [..]
-  | 6)  ModifyDate = 2003:12:04 06:46:52
-  |     - Tag 0x0132 (20 bytes, string[20]):
-  |         00b4: 32 30 30 33 3a 31 32 3a 30 34 20 30 36 3a 34 36 [2003:12:04 06:46]
-  |         00c4: 3a 35 32 00                                     [:52.]
-  | 7)  YCbCrPositioning = 1
-  |     - Tag 0x0213 (2 bytes, int16u[1]):
-  |         0072: 01 00                                           [..]
-  | 8)  ExifOffset (SubDirectory) -->
-  |     - Tag 0x8769 (4 bytes, int32u[1]):
-  |         007e: bc 00 00 00                                     [....]
-  | + [ExifIFD directory with 31 entries]
-  | | 0)  ExposureTime = 4 (4/1)
-  | |     - Tag 0x829a (8 bytes, rational64u[1]):
-  | |         0242: 04 00 00 00 01 00 00 00                         [........]
-  | | 1)  FNumber = 14 (14/1)
-  | |     - Tag 0x829d (8 bytes, rational64u[1]):
-  | |         024a: 0e 00 00 00 01 00 00 00                         [........]
-  | | 2)  ISO = 100
-  | |     - Tag 0x8827 (2 bytes, int16u[1]):
-  | |         00ea: 64 00                                           [d.]
-  | | 3)  ExifVersion = 0221
-  | |     - Tag 0x9000 (4 bytes, undef[4]):
-  | |         00f6: 30 32 32 31                                     [0221]
-  | | 4)  DateTimeOriginal = 2003:12:04 06:46:52
-  | |     - Tag 0x9003 (20 bytes, string[20]):
-  | |         0252: 32 30 30 33 3a 31 32 3a 30 34 20 30 36 3a 34 36 [2003:12:04 06:46]
-  | |         0262: 3a 35 32 00                                     [:52.]
-  [etc...]
-</pre></td></tr></table></blockquote>
-<h3>Verbose = 4 and Verbose = 5</h3>
-<p>These Verbose levels give similar output to Verbose = 3, except that with level
-4 there is no limit on the length of data dumps of tag values, and with level 5
-the limit is also removed for dumps of JPEG segments.  Note that the output may
-be very long at these levels.</p>
-<hr>
-<p class='lf'><a href="index.html">&lt;-- Back to ExifTool home page</a></p>
-</body>
-</html>

data/bin/Image-ExifTool-10.49/html/writing.html DELETED Viewed

@@ -1,239 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
-        "http://www.w3.org/TR/html4/loose.dtd">
-<html>
-<head>
-  <title>Writing Meta Information</title>
-<link rel=stylesheet type='text/css' href='style.css' title='Style'>
-<style type="text/css">
-<!--
-pre  { color: #800; margin-left: 4em }
--->
-</style>
-</head>
-<body>
-<div class='index'>
-<a href="#Abstract">Abstract</a>
-<br><a href="#Background">Background</a>
-<br><a href="#Implementation">Current Implementation</a>
-<br><a href="#Mandatory">Mandatory Tags</a>
-<br><a href="#JPEG">The JPEG Segment Size Limitation</a>
-<br><a href="#Preview">The Preview Image Problem</a> (<i>updated 2009-06-12</i>)
-<br><a href="#IFD0">IFD0/ExifIFD Ambiguity</a>
-</div>
-<h1 class='up'>Writing Meta Information</h1>
-<a name='Abstract'></a>
-<h3>Abstract</h3>
-<p>Writing meta information is more complicated than it may appear at first
-glance, which may be one reason why there are very few utilities around that do
-it. ExifTool uses tag names to identify the different pieces of meta information
-that can be extracted from a file.  There are thousands of different tags that
-ExifTool recognizes, and many of these tag names are common between different
-metadata formats (the WhiteBalance tag is the worst offender, and can be found
-in 44 different places [ExifTool 8.33]), and sometimes the information can even
-be stored in different places within a single format.  Couple this with the fact
-that many manufacturers store meta information in undocumented formats which
-must be reverse engineered (and each of which have their particular quirks), and
-you have a very complex situation.</p>
-<p>ExifTool attempts to simplify this situation as much as possible by making
-reasonable decisions about where to write the information you specify, yet it
-maintains flexibility by allowing you to configure its priorities if necessary,
-or even override the decision making process entirely.</p>
-<a name='Background'></a>
-<h3>Background</h3>
-<p>For a long time, I resisted adding write abilities to ExifTool even though it
-was an oft-requested feature.  My concerns in adding this feature were:</p>
-<ol>
-<li>It would complicate the ExifTool interface and make it too confusing for
-typical users.</li>
-<li>It would complicate the code enough to slow down processing for normal use.</li>
-<li>It would take a LOT of work to implement.</li>
-</ol>
-<p>After thinking about this for a while, I was finally able to come up with some
-solutions:</p>
-<p>1. I designed an interface that I think is easy to use for people who
-don't want to know the details of the file structure, yet powerful enough for
-people who want to do very specific things to the information.</p>
-<p>2. I isolated all of the writing code as much as possible into separate files
-which autoload as required.  This keeps the compilation fast for people who
-don't require the write feature.  Also, I have left the reading routines
-unchanged, so they aren't slowed down by the extra code needed when writing
-information.  Unfortunately, this meant I couldn't borrow a lot of code from the
-read routines (even more work for me!), but it had the advantage that I could
-perform additional optimizations in the write routines that I couldn't do
-otherwise.  Although the startup costs of this implementation are fairly high
-(for writing only), it should be quite fast for batch writing of multiple files.</p>
-<p>3. I decided to bite the bullet and invest the time required (...guess what I
-did for my Christmas vacation!).  Although I thought that a big project like
-this would be better suited to C++ (faster execution and a broader potential
-user base), after programming this so far in Perl I have grown to really
-appreciate the automatic memory handling and other great features of Perl such
-as hash lookups and incredible flexibility in text manipulations afforded by
-regular expressions.</p>
-<a name='Implementation'></a>
-<h3>Current Implementation</h3>
-<p>Currently, ExifTool can write most of the EXIF tags that anyone could reasonably
-want to change (but some tags are protected because they describe physical
-characteristics of the image that you can not change with ExifTool, eg.
-Compression).  Also, all of the GPS, IPTC and XMP information and most of the
-MakerNotes information can be edited.  This gives you great power, but with
-great power, comes great responsibility...</p>
-<p>It is possible for you to write nonsense into a file, which could cause other
-image readers to throw up their hands in despair and refuse to read the image.
-For this reason, it is best to always preserve the original copy of your image
-file.  The "exiftool" script does this for you automatically by renaming the
-original file and always working on a copy.</p>
-<p>The writing logic for ExifTool is the reverse of the reading logic.  You
-provide human-readable values and ExifTool will perform the conversions for you.
-For instance, you can set "WhiteBalance" to "Daylight" and ExifTool will change
-the value of WhiteBalance in the image wherever the tag is found provided that
-"Daylight" is a valid value for that location.  ExifTool will even do some simple
-matching so that you could even just set it to "day", and ExifTool will search
-through the valid values and will choose the one that contains the string "day".
-If the value is ambiguous, the tag will not be set.  If no tags can be set with
-the specified value, ExifTool returns an error message.</p>
-<p>The tag values can also be specified at a numerical level by disabling the
-print conversions that are normally applied.  This can be done on a tag-by-tag
-basis or on a global basis through either the application or the API.</p>
-<p>As well as changing tag values wherever they are found in the image, exiftool
-will also create the tag in the preferred group if it didn't exist there before.
-By default, the preferred group is the first of the following where the tag is
-found: 1) EXIF, 2) IPTC, 3) XMP.  Alternatively, the desired group (in family 0
-or 1) can be specified so ExifTool only writes the tag to a single location. For
-example, with the command line interface, this is done using an argument like
-"<code>-EXIF:WhiteBalance=Manual</code>".</p>
-<p>If a tag is added to a group that doesn't exist, the new group is created in
-the file, and required mandatory tags may be created.  Conversely, if the last
-non-mandatory tag is deleted from a group, the group is removed from the file.</p>
-<a name='Mandatory'></a>
-<h3>Mandatory Tags</h3>
-<p>The EXIF and IPTC standards both specify some mandatory tags.  ExifTool will
-automatically create many of these mandatory tags as required when writing new
-information (and remove them again when deleting information if only mandatory
-tags remain).  However, some mandatory tags (particularly in the IPTC
-information) can not be easily added automatically, so it is left up to the user
-to add these tags if required.</p>
-<blockquote class='aside'>
-<b>Rant:</b> Let me say that the whole concept of mandatory tags is flawed.
-Instead of mandatory tags, the standard should specify default values to be
-assumed if the tags don't exist.  A robust reader has to do this anyway, so it
-is redundant to require that this information must be written.  In the case
-where there is no simple default value, the reader must be able to deal with the
-missing tag, otherwise it places the burden on the writer to magically pull a
-reasonable value out of thin air.  Of course, you may say that the writer could
-get this information from the user, but conditions like this add an unnecessary
-level complexity to the user interface.
-</blockquote>
-<a name='JPEG'></a>
-<h3>The JPEG Segment Size Limitation</h3>
-<p>An unfortunate aspect of the JPEG format is that the size of a single segment
-is limited to less than 64 kB.  With the 2-byte size word at the start of each
-segment, this leaves 65533 bytes for data.  The EXIF specification states that
-the data must fit within a single <b>APP1</b> segment (which results in the
-preview image problem discussed below), however <b>APP13</b> Photoshop and
-<b>APP2</b> ICC Profile and FPXR information may span multiple segments.  This
-multi-segment information is handled properly by ExifTool.</p>
-<p>JPEG comments may also exceed the size of a single <b>COM</b> segment. If
-necessary, comments are automatically split into separate segments when writing.
-However, when reading they are not joined together because some utilities store
-distinctly different comments in separate segments.  To extract all JPEG
-comments into a single file, and combine any comments that may have been split
-into multiple segments, use "<code>exiftool -a -b -comment src.jpg &gt;
-comment.out</code>".</p>
-<a name='Preview'></a>
-<h3>The Preview Image Problem</h3>
-<p>Writing the preview image in JPEG files poses many problems of its own.  These
-problems stem from the fact that the JPEG standard is inadequate for storing
-large preview images due to the 64kB limit on segment size as mentioned above.
-(Note that TIFF images don't have this problem since they have a 4GB limit.)
-Some manufacturers get around this by appending the preview after the normal end
-of the JPEG file (JPEG EOI), but this causes complications because it means that
-the preview image pointers in the EXIF information now point outside the EXIF
-segment.  This is truly unfortunate because it greatly complicates things for
-image writing software.  Most other software can't deal with a preview image and
-will simply remove a preview like this when rewriting the file.</p>
-<p>However, as of ExifTool version 5, the preview images are handled properly
-when writing EXIF information in JPEG files.  But for reasons of efficiency, the
-EXIF segment is not edited when writing information if no EXIF tags are being
-changed (eg. if only XMP or IPTC information is being edited).  In this case,
-the preview image pointers could be invalidated because the length of the data
-between the EXIF segment (which comes near the start of the file) and the
-preview image (at the end of the file) is likely to change.  ExifTool gets
-around this when reading JPEG images by looking for the preview at the end of
-the file and updating pointers if necessary, but the preview image may not be
-readable by other software (it should be noted though that very few image
-readers even know the preview image exists).  However, the preview pointers in
-such a file can be fixed if necessary by simply using ExifTool to edit any EXIF
-information.</p>
-<p><b>2009-05-26</b>: New Samsung cameras recently started embedding preview
-images larger than 64 kB, and of course they created a new technique to do so.
-If they were smart, they would have developed a simple technique that could be
-used by others in the future, but of course they were stupid, and didn't think
-that far ahead. (Such is the normal path of dumb camera manufacturers when it
-comes to metadata.)</p>
-<p>The new Samsung models simply split the preview and write it to separate APP2
-segments with no header. If they had written a header (like "PREVIEW\0" for
-example), then the technique could be portable and useful. But they didn't.
-Without a header, the data can not easily be distinguised from other random APP2
-data, so this technique is not generally useful.  Of course, there are
-disadvantages with splitting up a preview into separate JPEG segments, so this
-technique in general is not ideal.</p>
-<p><b>2009-06-12</b>:
-<a href="http://www.cipa.jp/english/hyoujunka/kikaku/cipa_e_kikaku_list.html">CIPA</a>
-has recently released a "<b>Multi-Picture Format</b>" standard for storing large
-images in JPEG files.  Again, there is a big problem with this standard:  It
-uses offsets that are relative to the start of the MPF header (in the new MPF
-APP2 segment) to reference images after the JPEG EOI.  These offsets will
-quickly be broken if any data after the MPF segment changes length.  This
-problem could have been avoided if offsets had been specified relative to the
-end of file, but it is too late for this now that the specification is
-public.</p>
-<p>The only workable alternative I can see is to enforce the rule that the MPF
-APP2 segment must come after all other APP segments.  (It would have been smart
-if this was specified in the CIPA standard, but sadly this isn't the case.)  If
-this is done, then metadata in the remaining APP segments (EXIF, IPTC, XMP, etc)
-can safely be edited without breaking the MPF offsets.  I suggest that all
-metadata editors employ this strategy, regardless of the segment order specified
-in the standard (which says that the MPF APP2 segment must come immediately
-after the EXIF APP1 segment).</p>
-<a name='IFD0'></a>
-<h3>IFD0/ExifIFD Ambiguity</h3>
-<p>ExifTool has a preferred location (IFD) where it writes all EXIF tags.
-However, a number of tags are written to different locations by various digital
-cameras or image editors.  Specifically, the following tags have been observed
-in both IFD0 and ExifIFD: Make, Model, Software, Artist, DateTimeOriginal,
-SensingMethod, CustomRendered, ExposureMode, WhiteBalance, DigitalZoomRatio and
-SceneCaptureType.  To handle this ambiguity, ExifTool will delete the tag if it
-exists in IFD0 when it is written to ExifIFD, and vice versa.</p>
-<hr>
-<i>Created Dec. 30, 2004</i><br>
-<i>Last revised Oct. 4, 2010</i>
-<p class='lf'><a href="index.html">&lt;-- Back to ExifTool home page</a></p>
-</body>
-</html>