File: faq.html

package info (click to toggle)
libimage-exiftool-perl 8.60-2
links: PTS
area: main
in suites: wheezy
size: 16,160 kB
sloc: perl: 167,865; xml: 120; makefile: 2
file content (1153 lines) | stat: -rw-r--r-- 57,343 bytes
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
        "http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">
<html>
<head>
  <title>ExifTool FAQ</title>
<link rel=stylesheet type='text/css' href='style.css' title='Style'>
<style type="text/css">
<!--
pre      { color: #800; margin-left: 2em }
ol.index { margin: 0; padding: 0 0 0 2em }
-->
</style>
</head>
<body>
<div class='index'>
<ol class='index'>
<li><a href="#Q1">Discussion forum</a></li>
<li><a href="#Q2">Determining tag names</a></li>
<li><a href="#Q3">Problems with duplicate tags</a></li>
<li><a href="#Q4">Aperture and shutter speed</a></li>
<li><a href="#Q5">Date and time formats</a></li>
<li><a href="#Q6">"Can't convert TAG" errors</a></li>
<li><a href="#Q7">Deleting all EXIF from a TIFF</a></li>
<li><a href="#Q8">Writing Make, Model &amp; MakerNotes</a></li>
<li><a href="#Q9">Tag locations when copying</a></li>
<li><a href="#Q10">Coded character sets</a></li>
<li><a href="#Q11">User-defined tags</a></li>
<li><a href="#Q12">Export to database</a></li>
<li><a href="#Q13">Output file size</a></li>
<li><a href="#Q14">GPS coordinate format</a></li>
<li><a href="#Q15">MakerNote errors</a></li>
<li><a href="#Q16">Some files not renamed</a></li>
<li><a href="#Q17">List-type tags</a></li>
<li><a href="#Q18">Windows character encoding</a></li>
<li><a href="#Q19">Formatting tag values</a></li>
<li><a href="#Q20">Write errors (repair corrupted EXIF)</a></li>
<li><a href="#Q21">Newlines in values</a></li>
<li><a href="#Q22">Order of operations</a></li>
<li><a href="#Q23">"0 image files updated"</a></li>
</ol>
</div>

<h1 class='up'>ExifTool FAQ</h1>

<a name="Q1"></a>
<p>1. <b>"Is there a forum for discussing ExifTool issues?"</b></p>

<blockquote>
ExifTool issues can be discussed on the ExifTool forum at
<a href="http://owl.phy.queensu.ca/~phil/exiftool/forum/">http://owl.phy.queensu.ca/~phil/exiftool/forum/</a>
</blockquote>

<a name="Q2"></a>
<p>2. <b>"How do I determine the tag name for some information?"</b></p>

<blockquote>When you run exiftool, by default it prints descriptions, not tag
names, for the information it extracts.  (The language of these descriptions is
English by default, but may be changed with the <code>-lang</code> option.)  As
well as other differences, descriptions often contain spaces between words but
tag names never do.  To print the tag names instead instead of descriptions, use
the <code>-s</code> option when extracting information.  Also, see the
<a href="TagNames/index.html">tag names documentation</a> for a complete list of
available tag names.</blockquote>

<blockquote>Tag names may be optionally prefixed by a family 0 or 1 group name
to specify a particular information type or location.  Use the
<code>-g0</code> and <code>-g1</code> (or
<code>-G0</code> and <code>-G1</code>) options when extracting
information to see the corresponding group names.
</blockquote>

<a name="Q3"></a>
<p>3a. <b>"ExifTool reports the wrong value or doesn't extract a tag"</b>,
<br>3b. <b>"ExifTool doesn't write a tag properly"</b>, or
<br>3c. <b>"Other software can't read information written by ExifTool"</b></p>

<blockquote><i>[Also see <a href="#Q23">FAQ number 23</a> for reasons why
ExifTool may not write some tags to certain file types.]</i></blockquote>

<blockquote>
Make sure you are looking at the right information.  Information may be
duplicated in different locations within an image.  When in doubt, use
"<code>exiftool -a -G1 FILENAME</code>" to show all information and the
locations in the file.  In this command, <code>-a</code> allows
duplicate tags to be extracted, <code>-G1</code> shows the family 1
group name (ie. the location) of each tag, and "<code>FILENAME</code>" is
the name of your image file.  Also, it may be helpful to add
<code>-s</code> to show the actual tag names instead of the
descriptions (and possibly <code>-D</code> or <code>-H</code> to
show the tag ID numbers if you are familiar with these).</blockquote>

<blockquote>When duplicate tags exist, only one is extracted unless the
<code>-a</code> option is used. Beware that options like <code>-EXIF:all</code>
select all EXIF tags from the extracted tags, so EXIF tags hidden by duplicate
tags in other locations will not appear in the output for
<code>-EXIF:all</code>.  For example, the command

<pre>exiftool -gps:all image.jpg</pre>

will NOT necessarily extract all GPS tags because some GPS tags may have been
suppressed by same-named tags in other groups.  To be sure all GPS tags are
extracted, the <code>-a</code> option must be used:

<pre>exiftool -a -gps:all image.jpg</pre>

If you are having problems with other software reading information written by
ExifTool, if possible try first writing the information from the other software,
then use ExifTool to determine where the information was written. Once you know
where it should go, you can use ExifTool to write to this location. You can read
or write information in a specific location by prefixing the tag name on the
command line with the desired group name.  ie)
"<code>-ExifIFD:DateTimeOriginal</code>"
</blockquote>

<blockquote>This problem may also occur if contradictory information exists
in different meta information formats within the same file.  The
<a href="http://www.metadataworkinggroup.org/">Metadata Working Group</a>
recommends techniques to keep the EXIF, IPTC and XMP metadata synchronized. 
These recommendations are implemented by the ExifTool
<a href="TagNames/MWG.html">MWG tags</a>.  For maximum compatibility with the
widest range of applications, it is suggested that these MWG tags be used
whenever possible.</blockquote>

<a name="Q4"></a>
<p>4. <b>"ExifTool reports more than one shutter speed or aperture value, and
they are slightly different"</b></p>

<blockquote>
There are a number of different ways that aperture and shutter speed information
are stored in many images.  The standard EXIF values (EXIF:FNumber and
EXIF:ExposureTime) should correspond to the values displayed by your camera,
but these values may have been rounded off.  The corresponding EXIF APEX
values (EXIF:ApertureValue and EXIF:ShutterSpeedValue) may be different due
to their own round-off errors.  If available, the MakerNotes values may be
the most accurate because they haven't been rounded off to nice even values
for display, so with these you may see odd values like 1/102 instead of
1/100, etc.
</blockquote>

<a name="Q5"></a>
<p>5. <b>"How do I format date and time information for writing?"</b></p>

<blockquote>All information (including date/time information) is written in the
same format as it is read out.  When reading, ExifTool converts all date and
time information to standard EXIF format, so this is also the way it is
specified when writing. The standard EXIF date/time format is "<code>YYYY:mm:dd
HH:MM:SS</code>", and some meta information formats such as XMP also allow
sub-seconds and a timezone to be specified.  The timezone format is
"<code>+HH:MM</code>", "<code>-HH:MM</code>" or "<code>Z</code>". For
example:

<pre>exiftool -xmp:dateTimeOriginal="2005:10:23 20:06:34.33-05:00" a.jpg
</pre>

When writing XMP or other information types which allow incomplete date/time
values, the following input formats are also accepted:

<pre>YYYY
YYYY:mm
YYYY:mm:dd
YYYY:mm:dd HH:MM
</pre>

Having said this, ExifTool is very flexible about the actual format of input
date/time values when writing, and will attempt to reformat any values into the
standard format unless the <code>-n</code> option is used.  Any separators may
be used (or in fact, none at all).  The first 4 consecutive digits found in the
value are interpreted as the year, then next 2 digits are the month, and so on.
For EXIF date/time values, all 6 date/time fields must exist
("<code>YYYYmmddHHMMSS</code>"), but XMP date/time values require only the year
("<code>YYYY</code>").
</blockquote>

<a name="Q6"></a>
<p>6. <b>"I get '<code>Can't convert TAG (not in PrintConv)</code>' errors when
writing a tag"</b></p>

<blockquote>
By default, ExifTool applies a print conversion (PrintConv) to extracted
information to make the output more human-readable.  Some conversions involve
lookup tables which are documented in the <b>Values</b> column of the
<a href="TagNames/index.html">Tag Name documentation</a>.  For example, the
GPSAltitudeRef tag defines the following conversions:
<pre>0 = Above Sea Level
1 = Below Sea Level
</pre>
For this tag, a value of '0' is printed as 'Above Sea Level', and '1' is printed
as 'Below Sea Level'.  Reading and writing with ExifTool is symmetrical <i>[with
the possible exception of List-type tags -- see <a href="#Q17">FAQ number 17</a>
below]</i>, so a value that is printed as 'Above Sea Level' must also be written in
that form.  (In other words, the inverse print conversion is applied when writing
values.)  For example, to write GPSAltitudeRef you can type:
<pre>exiftool -gpsaltituderef="Above Sea Level" image.jpg
</pre>
or any unambiguous short form may be used and ExifTool will know what you mean, ie)
<pre>exiftool -gpsaltituderef=above image.jpg
</pre>
Alternatively, the print conversion can be disabled for all tags with the
<code>-n</code> option, or for individual tags by suffixing the tag name with a
'<code>#</code>' character.  In either case the printed value of GPSAltitudeRef
will be '0' or '1' when extracting information, and the value is written in the
same way. So following two commands have exactly the same effect as above:
<pre>exiftool -gpsaltituderef=0 -n image.jpg
exiftool -gpsaltituderef#=0 image.jpg
</pre>
Integer values may also be specified in hexadecimal (with a leading '0x').  For
example, the following commands are all equivalent:
<pre>exiftool -flash=1 -n image.jpg
exiftool -flash=0x1 -n image.jpg
exiftool -flash#=1 image.jpg
exiftool -flash#=0x1 image.jpg
exiftool -flash=fired image.jpg
</pre>
<b>Programmers</b>: These techniques look like this when calling Image::ExifTool
functions from a Perl script:
<pre>$exifTool->SetNewValue(flash => 1, Type => 'ValueConv');
$exifTool->SetNewValue(flash => 0x1, Type => 'ValueConv');
$exifTool->SetNewValue('flash#' => 1);
$exifTool->SetNewValue('flash#' => 0x1);
$exifTool->SetNewValue(flash => 'fired');
</pre>
</blockquote>

<a name="Q7"></a>
<p>7. <b>"I can't delete all EXIF information from a TIFF file using
'<code>exiftool -exif:all= img.tif</code>'"</b></p>

<blockquote>This is because of the way a TIFF file is structured.  With a JPEG
image, this command removes IFD0 (the main Image File Directory) as well as any
subdirectories, thus removing all EXIF information.  But with the TIFF format,
the main image itself is stored in IFD0, so deleting this directory would
destroy the image.  The same is true for any TIFF-based RAW file such as DNG,
CR2, NEF, etc.  For these types of files, ExifTool just deletes the ExifIFD
subdirectory, so any information stored in other directories is preserved.
</blockquote>

<blockquote>Use "<code>exiftool -a -G1 -s img.tif</code>" to see where the
information is stored.  Any tags remaining in other IFD's must be deleted
individually from a TIFF-format file if desired.  For convenience, a
<a href="TagNames/Shortcuts.html">shortcut tag</a> is provided to simplify the
deletion of common metadata tags from IFD0 by adding "<code>-CommonIFD0=</code>"
to the command line.
</blockquote>

<a name="Q8"></a>
<p>8a. <b>"All maker note information is lost if I change the Make or Model tag"</b>, or
<br>8b. <b>"I can't copy maker note information to an image"</b></p>

<blockquote>
The Make and Model tags are used by some image utilities (including ExifTool) to
determine the format of the maker note information.  Deleting or changing either
of these tags may prevent these utilities from recognizing or properly
interpreting the maker notes.  Also beware that the maker notes information may
be damaged if an image is edited when the maker notes are not properly
recognized. So it is a good idea not to edit the Make and Model tags in the
first place.</blockquote>

<blockquote>If you really want to delete the Make and Model information, you
might as well delete the maker notes too.  You can do this with either of the
following commands:
<pre>exiftool -make= -model= -makernotes:all= image.jpg
exiftool -make= -model= -makernotes= image.jpg
</pre>
For the same reason, maker notes can not be copied to an image with an
incompatible Make or Model.  To do this, the Make and Model tags must also be
copied.  ie)
<pre>exiftool -tagsfromfile src.jpg -makernotes -make -model dst.jpg
</pre>
(Note that in this case the "<code>-makernotes:all</code>" syntax does not
work because it attempts to copy the maker note tags individually, but they
must be copied as a block with "<code>-makernotes</code>".)
</blockquote>

<a name="Q9"></a>
<p>9a. <b>"The information is different when I copy all tags to a new file"</b>, or
<br>9b. <b>"The tag locations change when I use <code>-tagsfromfile</code>
to copy information"</b></p>

<blockquote>
This feature is explained under the <code>-tagsFromFile</code> option in
the <a href="exiftool_pod.html">exiftool application documentation</a>, but the
question is common enough that it is discussed here in more detail.</blockquote>

<blockquote>By default, ExifTool will store information in preferred locations
when either writing new information or copying information between files. This
freedom allows ExifTool to write or copy information to files of different
formats without requiring the user to know details about where the information
is stored.</blockquote>

<blockquote>The preferred locations for information written to JPEG images are
1) EXIF, 2) IPTC and 3) XMP.  As an example, information extracted from the
maker notes will be preferentially written (on a tag-by-tag basis) in EXIF
format when copying information between two JPEG images.  But if a specific tag
doesn't exist in EXIF, then the tag is written to the first valid group in the
order specified above.  The advantage of "translating" the information to EXIF
is that it then becomes readable by applications which only support standard
EXIF.  The disadvantage is that you don't get an exact copy of the original
information structure.</blockquote>

<blockquote>But ExifTool gives you the ability to customize this behaviour to
write the information to wherever you want.  This is done by specifying a group
name for the tag(s) to be copied.  This applies even if the group name is
"<code>all</code>", in which case the original group is preserved.  So to copy
all information and preserve the original structure, use this syntax:

<pre>exiftool -tagsfromfile src.jpg -all:all dst.jpg
</pre>

By specifying a group name with "<code>-all:all</code>", the location of the
information is preserved.  (Specifically, since no destination tag was
specified the source group "<code>all</code>" was assumed, thus preserving
the original group.)</blockquote>

<blockquote>Here are some examples to show you the type of control you have over
where the information is written. All commands in each example are equivalent:

<pre><span class='blk'># copy all tags to preferred groups (no destination group)</span>
exiftool -tagsfromfile src.jpg dst.jpg
exiftool -tagsfromfile src.jpg -all dst.jpg
exiftool -tagsfromfile src.jpg "-all&gt;all" dst.jpg
exiftool -tagsfromfile src.jpg "-all:all&gt;all" dst.jpg

<span class='blk'># copy all tags, preserving original group (destination group 'all')</span>
exiftool -tagsfromfile src.jpg -all:all dst.jpg
exiftool -tagsfromfile src.jpg "-all&gt;all:all" dst.jpg
exiftool -tagsfromfile src.jpg "-all:all&gt;all:all" dst.jpg

<span class='blk'># copy all tags to EXIF group only (destination group 'exif')</span>
exiftool -tagsfromfile src.jpg "-all&gt;exif:all" dst.jpg
exiftool -tagsfromfile src.jpg "-all:all&gt;exif:all" dst.jpg

<span class='blk'># copy XMP tags to XMP group (destination group 'xmp' or 'all')</span>
exiftool -tagsfromfile src.jpg "-xmp:all" dst.jpg
exiftool -tagsfromfile src.jpg "-xmp:all&gt;xmp:all" dst.jpg
exiftool -tagsfromfile src.jpg "-xmp:all&gt;all:all" dst.jpg

<span class='blk'># copy XMP tags to preferred groups (no destination group)</span>
exiftool -tagsfromfile src.jpg "-xmp:all&gt;all" dst.jpg

<span class='blk'># copy XMP tags to EXIF only (destination group 'exif')</span>
exiftool -tagsfromfile src.jpg "-xmp:all&gt;exif:all" dst.jpg
</pre>

The same rules illustrated above also apply when copying individual tags.</blockquote>

<blockquote>Note: If no destination group is specified, a new tag is created if
necessary only in the preferred group, but if the same tag already exists in
another group, then this information is also updated.  (Otherwise inconsistent
values for the same information would exist in different locations. Of course,
you can always generate inconsistencies like this if you really want to by
specifically writing contradictory information to different groups.)
</blockquote>

<a name="Q10"></a>
<p>10. <b>"How does ExifTool handle coded character sets?"</b></p>
<!-- NOTE: Changes to this section must also be reflected in ExifTool.pod! -->

<blockquote><i>[Also see <a href="#Q18">FAQ number 18</a> for help on displaying
special characters in a Windows console.]</i></blockquote>

<blockquote>
Certain meta information formats allow coded character sets other than plain
ASCII.  When reading, 8&#8209;bit encodings are passed straight through ExifTool
without re-coding unless specified otherwise below, and multi-byte encodings are
converted according to the exiftool <code>-charset</code> option, or to
UTF&#8209;8 by default.  The <code>-L</code> option is equivalent to
"<code>-charset Latin</code>", "<code>-charset Latin1</code>" and
"<code>-charset cp1252</code>".  When writing, the inverse conversions are
performed.  Alternatively, special characters may be converted to/from HTML
character entities when reading/writing with the <code>-E</code> option.
</blockquote>

<blockquote>Valid <code>-charset</code> values are (with aliases given in
brackets):

<blockquote><table class=clear>
<tr><td>UTF8</td><td>(cp65001, UTF-8)</td><td>Thai</td><td>(cp874)</td></tr>
<tr><td>Latin</td><td>(cp1252, Latin1)</td><td>MacRoman</td><td>(cp10000, Mac, Roman)</td></tr>
<tr><td>Latin2</td><td>(cp1250)</td><td>MacLatin2</td><td>(cp10029)</td></tr>
<tr><td>Cyrillic</td><td>(cp1251,&nbsp;Russian)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</td><td>MacCyrillic</td><td>(cp10007)</td></tr>
<tr><td>Greek</td><td>(cp1253)</td><td>MacGreek</td><td>(cp10006)</td></tr>
<tr><td>Turkish</td><td>(cp1254)</td><td>MacTurkish</td><td>(cp10081)</td></tr>
<tr><td>Hebrew</td><td>(cp1255)</td><td>MacRomanian</td><td>(cp10010)</td></tr>
<tr><td>Arabic</td><td>(cp1256)</td><td>MacIceland</td><td>(cp10079)</td></tr>
<tr><td>Baltic</td><td>(cp1257)</td><td>MacCroatian</td><td>(cp10082)</td></tr>
<tr><td>Vietnam</td><td>(cp1258)</td></tr>
</table></blockquote>

More specific details are given below about how character coding is
handled for EXIF, IPTC, XMP, PNG, ID3, PDF, QuickTime, MIE and
Vorbis information:</blockquote>

<blockquote><b>EXIF</b>: Most textual information in EXIF is stored in ASCII
format, and ExifTool does not convert these tags.  However it is not uncommon
for applications to write UTF&#8209;8 or other encodings where ASCII is
expected, and ExifTool will quite happily read/write any encoding without
conversion.  For a few EXIF tags (UserComment, GPSProcessingMethod and
GPSAreaInformation) the stored text may be encoded either in ASCII, Unicode
(UCS-2) or JIS.  When reading these tags, Unicode and JIS are converted to the
character set specified by the <code>-charset</code> or <code>-L</code> option,
or to UTF&#8209;8 by default.  Other encodings are not converted.  When
writing, text is stored as ASCII unless the string contains special characters,
in which case it is converted from the specified character set and stored as
Unicode.  ExifTool writes Unicode in native EXIF byte ordering by default, but
this may be changed by setting the ExifUnicodeByteOrder tag (see the
<a href="TagNames/Extra.html">Extra Tags</a> documentation).  The EXIF "XP" tags
(XPTitle, XPComment, etc) are always stored as little-endian Unicode, and are
read and written using the specified character set.</blockquote>

<blockquote><b>IPTC</b><span class='sm'><sup>&dagger;</sup></span>: The
value of the IPTC:CodedCharacterSet tag determines how the internal IPTC string
values are interpreted.  If CodedCharacterSet exists and has a value of
"<code>UTF8</code>" (or "<code>ESC&nbsp;%&nbsp;G</code>") then string values are
assumed to be stored as UTF&#8209;8, otherwise Windows Latin1 (cp1252) coding is
assumed by default, but this can be changed with "<code>-charset
iptc=CHARSET</code>".  When reading, these strings are converted to UTF&#8209;8
by default, or to the character set specified by the <code>-charset</code> or
<code>-L</code> option.  When writing, the inverse conversions are performed. 
No conversion is done if the internal (IPTC) and external (ExifTool) character
sets are the same.  Note that ISO 2022 character set shifting is not supported.
Instead, a warning is issued and the string is not converted if an ISO 2022
shift code is encountered.  See the
<a href="http://www.iptc.org/std/IIM/4.1/specification/IIMV4.1.pdf">IPTC IIM
specification</a> for more information about IPTC character coding.</blockquote>

<blockquote>ExifTool may be used to convert IPTC values to a different internal
encoding.  To do this, all IPTC tags must be rewritten along with the desired
value of CodedCharacterSet.  For example, the following command changes the
internal IPTC encoding to UTF&#8209;8:
<pre>exiftool -tagsfromfile @ -iptc:all -codedcharacterset=utf8 a.jpg
</pre>and this command changes it back from UTF&#8209;8 to Windows Latin1 (cp1252):
<pre>exiftool -tagsfromfile @ -iptc:all -codedcharacterset= a.jpg
</pre>or this command changes it back from UTF&#8209;8 to Windows Latin2 (cp1250):
<pre>exiftool -tagsfromfile @ -iptc:all -codedcharacterset= -charset iptc=latin2 a.jpg
</pre>But note that unless UTF&#8209;8 is used, applications have no reliable
way to determine the IPTC character encoding.</blockquote>

<blockquote class='sm'><sup>&dagger;</sup> <span class=lt>Refers to the older
<a href="http://www.iptc.org/site/News_Exchange_Formats/IIM/">IPTC IIM</a> format.
The more recent
<a href="http://iptc.cms.apa.at/site/Photo_Metadata/IPTC_Core_&amp;_Extension/">IPTC
Core and Extension specifications</a> actually use the XMP format (see below).</span>
</blockquote>

<blockquote><b>XMP</b>: Exiftool reads XMP encoded as UTF&#8209;8, UTF&#8209;16
or UTF&#8209;32, and converts them all to UTF&#8209;8 internally.  Also, all XML
character entity references and numeric character references are converted. 
When writing, ExifTool always encodes XMP as UTF&#8209;8, converting the
following 5 characters to XML character references: <code>&amp; &lt; &gt; &#39;
&quot;</code>. By default no further conversion is performed, however the
<code>-charset</code> or <code>-L</code> option may be used used to convert
text to/from a specified character set when reading/writing.</blockquote>

<blockquote><b>PNG</b>: <a href="TagNames/PNG.html#TextualData">PNG TextualData
tags</a> are stored as tEXt, zTXt and iTXt chunks in PNG images.  The tEXt and
zTXt chunks use ISO 8859-1 encoding, while iTXt uses UTF&#8209;8.  When reading,
ExifTool converts all PNG textual data to the character set specified by the
<code>-charset</code> or <code>-L</code> option, or to UTF&#8209;8 by default.
When writing, ExifTool generates a tEXt chunk (or zTXt with the <code>-z</code>
option) if the text doesn't contain special characters or if Latin encoding is
specified (<code>-L</code> or <code>-charset latin</code>); otherwise an iTXt
chunk is used and the text is converted from the specified character set and
stored as UTF&#8209;8.</blockquote>

<blockquote><b>ID3</b>: The ID3v1 specification officially supports only ISO
8859&#8209;1 encoding (a subset of Windows Latin1), although some applications
may incorrectly use other character sets.  By default ExifTool converts ID3v1
text from Latin to the character set specified by the <code>-charset</code> or
<code>-L</code> option, or to UTF&#8209;8 by default.  However, the internal
ID3v1 charset may be specified with "<code>-charset id3=CHARSET</code>".  The
encoding for ID3v2 information is stored in the file, so ExifTool converts
ID3v2 text from this encoding to the character set specified by
<code>-charset</code> or <code>-L</code>, or to UTF&#8209;8 by default. ExifTool
does not currently write ID3 information.</blockquote>

<blockquote><b>PDF</b>: PDF text strings are stored in either PDFDocEncoding
(similar to Windows Latin1) or Unicode (UCS&#8209;2).  When reading, ExifTool
converts to the character set specified by the <code>-charset</code> or
<code>-L</code> option, or to UTF&#8209;8 by default.  When writing, ExifTool
encodes input text from the specified character set as Unicode only if the
string contains special characters, otherwise PDFDocEncoding is
used.</blockquote>

<blockquote><b>Photoshop</b>: Some Photoshop resource names are stored as
Pascal strings with unknown encoding.  By default, ExifTool assumes MacRoman
encoding and converts this to UTF&#8209;8, but the internal and external
character sets may be specified with <code>-charset Photoshop=CHARSET</code>
and <code>-charset CHARSET</code> respectively.</blockquote>

<blockquote><b>QuickTime</b>: QuickTime text strings may be stored in a variety
of poorly document formats.  ExifTool does its best to decode these according
to the <code>-charset</code> option setting.</blockquote>

<blockquote><b>MIE</b>: MIE strings are stored as either UTF&#8209;8 or ISO
8859&#8209;1. When reading, UTF&#8209;8 strings are converted according to
the <code>-charset</code> or <code>-L</code> option, and ISO 8859&#8209;1
strings are never converted.  When writing, input strings are converted from
the specified character set to UTF&#8209;8.  The resulting strings are stored as
UTF&#8209;8 if they contain multi-byte UTF&#8209;8 character sequences,
otherwise they are stored as ISO 8859&#8209;1.</blockquote>

<blockquote><b>Vorbis:</b> Vorbis comments are stored as UTF&#8209;8,
and are converted to the character set specified by <code>-charset</code> or
<code>-L</code> when reading.</blockquote>

<a name="Q11"></a>
<p>11. <b>"My user-defined tags don't work"</b></p>

<blockquote>
For examples of how to add user-defined tags, see the
<a href="config.html">ExifTool_config</a> file in the ExifTool distribution.
It may be useful to activate this file as a test before trying to implement
your own config file.  To activate this file, copy it to your <b>HOME</b>
directory then rename it to "<code>.ExifTool_config</code>".
<blockquote class=lt><b>Note:</b> The config file must be renamed at the
command line because neither the Windows nor Mac GUI allow a file name to
begin with a "<code>.</code>".  To do this in Windows, run "cmd.exe" and type
the following (pressing <i>RETURN</i> at the end of each line):
<pre>cd %HOMEPATH%
rename ExifTool_config .ExifTool_config
</pre>
or on a Mac, open the "Terminal" application (from the /Applications/Utilities
folder) and type this command then press <i>RETURN</i>:
<pre>mv ExifTool_config .ExifTool_config
</pre></blockquote>

With the sample config file installed, you should be able to write the example
tags.  A command like this:
<pre>exiftool -v2 -NewXMPxmpTag=test <i>FILE</i></pre>
should print this as the first line of its output:
<pre>Writing XMP-xmp:NewXMPxmpTag
</pre>
If this doesn't work, the most common problem is that the
"<code>.ExifTool_config</code>" configuration file isn't getting loaded.  In
this case, there are a few things you can try:
<ol>
<li>Make sure the config file name is correct.  It must be
"<code>.ExifTool_config</code>" (note the leading "<code>.</code>", and the
capital "<code>T</code>").</li>
<li>Set either the <b>HOME</b> or the <b>EXIFTOOL_HOME</b> environment variable
to the name of the directory where you put your "<code>.ExifTool_config</code>"
file.</li>
<li>Put the config file in the same directory as the exiftool script.  (Also, be
sure the config filename starts with a dot!  See the note above for help
renaming the config file.)</li>
<li>If you can't get the config file to load automatically, you can try loading
it manually with the exiftool <code>-config <i>CFGFILE</i></code> option. (Note:
This must be the first option on the command line.)  This allows loading
of a config file with any name.</li>
</ol>
</blockquote>

<blockquote>If necessary, you can verify that ExifTool is loading your config
file by adding the following line to your file:

<pre>print "LOADED!\n";
</pre>

If you see a "<code>LOADED!</code>" message when you run exiftool, but your new
tags still don't work, make sure you are using the proper tag name and that the
file you are writing can support this type of information.</blockquote>

<blockquote><b>Programmers</b>: To specify the config file directory from within
a Perl script when using the ExifTool API, set the <b>EXIFTOOL_HOME</b>
environment variable before loading the ExifTool module:
<pre>BEGIN { $ENV{EXIFTOOL_HOME} = '/config_file_directory' }
use Image::ExifTool;
</pre>
Also see the <a href="ExifTool.html#Config">Configuration section of the
ExifTool API documentation</a> for techniques to use a config file with another
name, or to disable the config file feature.
</blockquote>

<a name="Q12"></a>
<p>12. <b>"How do I export information from exiftool to a database?"</b></p>

<blockquote>
It is often easiest to export information formatted as  a tab-delimited or
comma-separated list of values using the exiftool <code>-T</code> or
<code>-csv</code> option.  As well, the <code>-r</code> option is useful for
recursing through all images in a hierarchy of directories.  For example:

<pre>exiftool -T -r -filename -exposuremode -ISO t/images &gt; out.txt
</pre></blockquote>

<blockquote>This command recursively processes all images in the "<code>t/images</code>"
directory, extracting FileName, ExposureMode and ISO tags, and writing the
output to a CSV-format file called "<code>out.txt</code>". After the command has
executed, "<code>out.txt</code>" will look something like this:

<pre>Canon.jpg       Manual  100
Casio.jpg       -       64
Nikon.jpg       -       100
OlympusE1.jpg   Auto    400
</pre>

With the <code>-csv</code> option, the output also includes a header line
containing the tag names, as well as a first column labelled "SourceFile":

<pre>SourceFile,FileName,ExposureMode,ISO
t/images/Canon.jpg,Canon.jpg,Manual,100
t/images/Casio.jpg,Casio.jpg,,64
t/images/Nikon.jpg,Nikon.jpg,,100
t/images/OlympusE1.jpg,OlympusE1.jpg,Auto,400
</pre>

It should be possible to import these files directly into most database
applications.  On the command line, any list of tag names may be used, and any
number of file or directory names may be specified. (Hint: If your command line
starts to get too long, you may want to look into using the <code>-@</code>
option and/or the <a href="index.html#shortcut">ShortCut</a> feature).  The
<code>-csv</code> option functions properly event if no tags are specified on
the command line (in this case all tags are exported in alphabetical order and
any missing entries are padded with empty strings, or dashes with the
<code>-f</code> option).  However, this can not be done with the <code>-T</code>
option because the columns of information are not arranged and padded as with
the <code>-csv</code> output.</blockquote>

<blockquote>In Windows, a .BAT file containing the exiftool command may be used
to give drag and drop functionality.  Dropping a folder on the following .BAT
file will create "out.csv" in the folder:

<pre>echo "FileName&lt;tab&gt;Aperture&lt;tab&gt;ISO" &gt; %1\out.csv
exiftool -T -r -filename -aperture -ISO %1 &gt;&gt; %1\out.csv
</pre>

where "<code>&lt;tab&gt;</code>" in the "<code>echo</code>" command indicates a
tab character.  This "<code>echo</code>" command was included to add column
headings to the output.
</blockquote>

<blockquote>Other possible export formats include RDF/XML (with the the
<code>-X</code> option), or JSON (with the <code>-j</code> option).  These
methods allow transfer of more complex data sets (including structured
information with the <code>-struct</code> option), but require that the
importing software supports these formats.</blockquote>

<blockquote>Finally, the <code>-p</code> option may be used to generate any
arbitrary output format.  For example, the following format file
(let's call it "<code>my.fmt</code>") may be used to emulate a CSV-formatted
output:

<pre>#[HEAD]FileName, Aperture, ISO
$filename, $aperture, $iso
</pre>

with a command like this:

<pre>exiftool -f -r -p my.fmt t/images &gt; out.csv
</pre>

Alternatively, the <code>-p</code> option may be used with a format string instead
of a file name.  The following command has the same effect as above except that
the row of headings is not printed (Note: Use single quotes as below on Mac/Linux,
or double quotes instead on Windows):

<pre>exiftool -f -r -p '$filename, $aperture, $iso' t/images &gt; out.csv
</pre>

With the <code>-f</code> option, the value of any missing tag is printed as a
dash.  Without this option, missing tags generate a minor warning and the
line in the <code>-p</code> output is not printed.  The <code>-m</code> option
may be used to ignore minor warnings, which causes these lines to be printed
with an empty value for missing tags.</blockquote>

<blockquote>
See the <code>-p</code> option in the <a href="exiftool_pod.html">application
documentation</a> for more information about this feature.
</blockquote>

<blockquote><b>Note:</b>  Information may be <b>imported</b> from CSV or JSON files for
writing to images by specifying an input file name with the <code>-csv</code> or
<code>-j</code> option.  See the <a href="exiftool_pod.html">exiftool
application documentation</a> for more details.</blockquote>

<a name="Q13"></a>
<p>13. <b>"Why is my file smaller after I use ExifTool to write information?"</b></p>

<blockquote>
There are various specific reasons why this can happen, but the general answer
is:  When ExifTool writes an image, the meta information may be restructured in
such a way that it takes less space than in the original file.</blockquote>

<blockquote>For instance, the EXIF/TIFF standard allows for blocks of
unreferenced data to exist in an image.  Some digital cameras write JPEG or
TIFF-based RAW files which contain large blocks of unused data, usually filled
with binary zeros.  The reason for this could be to simplify camera algorithms
by allowing variable-sized information to be written at fixed offsets in the
output image. When ExifTool rewrites an image it does not copy these unused
blocks.  This can result in a significant reduction in file size for some
images.  <i>[The <code>-htmlDump</code> option may be used to view the file
structure if you are interested in seeing these unused data blocks -- use a
command like "<code>exiftool -htmlDump a.jpg &gt; out.html</code>", then open
<code>out.html</code> in your web browser.]</i>
</blockquote>

<blockquote>Also, the size of an XMP record may easily shrink or grow when it is
rewritten, even if no meta information is changed.  This is partly due to the
fact that the XMP specification recommends a few KB of padding at the end of the
record (ExifTool adds 2424 bytes by default), and partly due to the flexibility
of the XMP format which allows the information to be written in various styles,
some of which are more compact than others.
</blockquote>

<blockquote>You may also notice that the values of some "offset" tags (like
ThumbnailOffset and PreviewImageStart) may change when the file is rewritten. 
This is normal, and simply indicates that the associated data is now stored at a
different position within the file.</blockquote>

<blockquote>ExifTool does not modify the image data itself, so editing a file is
"lossless" as far as the image is concerned.</blockquote>

<a name="Q14"></a>
<p>14. <b>"What format do I use for writing GPS coordinates?"</b></p>

<blockquote>ExifTool is very flexible in the formats allowed for entering GPS
coordinates.  Any string containing between 1 and 3 floating point numbers is
valid.  The numbers represent degrees, (and optionally) minutes and
seconds.</blockquote>

<blockquote>For EXIF GPS coordinates, the reference direction is specified
separately with the EXIF:GPSLatitudeRef or EXIF:GPSLongitudeRef
tag.</blockquote>

<blockquote>For XMP GPS coordinates, the reference direction is specified within
the XMP:GPSLatitude or XMP:GPSLongitude value, with west longitudes and south
latitudes being specified either by negative coordinate values or by ending the
string with "<code>W</code>" or "<code>S</code>". </blockquote>

<blockquote>Here are some examples of equivalent ways to specify a GPS
latitude in both EXIF and XMP:

<pre>exiftool -exif:gpslatitude="42 30 0.00" -exif:gpslatituderef=S a.jpg
exiftool -exif:gpslatitude="42 deg 30.00 min" -exif:gpslatituderef=S a.jpg
exiftool -exif:gpslatitude=42.5 -exif:gpslatituderef=S a.jpg

exiftool -xmp:gpslatitude="42 30 0.00 S" a.jpg
exiftool -xmp:gpslatitude=42.50S a.jpg
exiftool -xmp:gpslatitude=-42.5 a.jpg
</pre>

Similar styles may be used for longitude.  ExifTool will convert any of these
coordinate styles to the proper format for the specific tag used.
</blockquote>

<a name="Q15"></a>
<p>15. <b>"I get MakerNote warnings or errors when reading or writing information"</b></p>

<blockquote>Problems like this may be caused by image editing software which
doesn't properly update offsets in the MakerNotes when rewriting an image. In
many cases, ExifTool will detect this type of problem and issue a warning like
this:

<pre>Warning: [minor] Possibly incorrect maker notes offsets (fix by -340?)
</pre>

(Be aware that if multiple warnings occur, the <code>-a</code> option must be
used so see them all, since by default only one warning is displayed per file.)
If this warning occurs, you can use the <code>-F</code> option to attempt to fix
the problem.  When writing, <code>-F</code> applies a permanent correction to
the maker notes.  Note that some Makernote information may be lost permanently
if the proper correction is not applied when writing images with this
problem.</blockquote>

<blockquote>Any error that occurs while writing will prevent the file from being
written.  However, most Makernote errors are designated as <b>minor</b>, which
allows them to be ignored by using the <code>-m</code> option.  For example:

<pre>Error: [minor] Bad format (65535) for MakerNotes entry 17
</pre>

Using <code>-m</code> will downgrade the minor error to a warning, allowing the
file to be written, but some Makernote information may be lost when ignoring
certain types of errors like this.
</blockquote>

<a name="Q16"></a>
<p>16. <b>"Why doesn't ExifTool rename my AVI files?"</b></p>

<blockquote>By default, ExifTool only processes <u>writable file
types</u><span class='sm'><sup>&dagger;</sup></span> when <u>any
tag</u><span class='sm'><sup>&Dagger;</sup></span> is being written and a
directory name is specified on the command line.  To force exiftool to process
other files, they must either be listed on the command line by name, or be
specified using the <code>-ext</code> option, something like this:

<pre>exiftool -ext AVI -ext JPG -d pics/%Y/%m "-directory&lt;dateTimeOriginal" DIR
</pre>

When a single <code>-ext</code> option is used, only files of the specified type
are processed.  However, multiple <code>-ext</code> options may be used in the
same command (as in the example above) to process any number of different file
types.
</blockquote>

<blockquote class='sm'><sup>&dagger;</sup> <span class=lt>The
<code>-listwf</code> option may be used to list all writable file types.</span>
<br><sup>&Dagger;</sup> <span class=lt>This includes "pseudo" tags like
FileName, Directory and FileModifyDate.</span></blockquote>

<a name="Q17"></a>
<p>17. <b>"List-type tags do not behave as expected"</b></p>

<blockquote>Tags indicated by a plus sign (<code>+</code>) in the
<a href="TagNames/index.html">tag name documentation</a> are List-type tags.
Two examples of common List-type tags are
<a href="TagNames/IPTC.html#ApplicationRecord">IPTC:Keywords</a> and
<a href="TagNames/XMP.html#dc">XMP:Subject</a>.  These tags may contain multiple
items which are combined into a single string when reading.  (By default,
extracted list items are separated by a comma and a space, but the
<code>-sep</code> option may be used to change this.)  When writing, separate
items are assigned individually.  For example, the following command writes
three keywords to all writable files in directory <code>DIR</code>, replacing
any previously existing keywords:

<pre>exiftool -keywords=one -keywords=two -keywords=three DIR
</pre>

List items are assigned separately, NOT all together, because this would
represent a single keyword:

<pre>exiftool -keywords="one, two, three" test.jpg  <span class=blk>(WRONG!)</span>
</pre>

With exiftool version 7.56 or later, the <code>-sep</code> option may be used to
split values of list-type tags into separate items when writing.  For example,

<pre>exiftool -sep ", " -keywords="one, two, three" DIR
</pre>

will store three separate keywords, the same as the first example above. This
feature may also be used to split a tag value into separate items if it was
originally stored incorrectly as a single string:

<pre>exiftool -sep ", " -tagsfromfile @ -keywords test.jpg
</pre>

However, sometimes it is desirable to have list items which contain a comma, and
this is allowed:

<pre>exiftool -contributor="Harvey, Phil" -contributor="Marley, Bob" a.jpg
</pre>

But to distinguish these entries when extracting information, a different list
separator must be used.  For instance, the following command uses
"<code>//</code>" to separate list items,

<pre>exiftool -contributor -sep "//" a.jpg
</pre>

and produces an output like this:

<pre class=blk>Contributor  : Harvey, Phil//Marley, Bob
</pre>

Note that the above examples overwrite any values which already existed in the
original file for these tags.  Alternatively, "<code>+=</code>" or
"<code>-=</code> may be used to add to or remove items from an existing list:

<pre>exiftool -keywords+="add this" -keywords-="remove this" DIR
</pre>

In commands like this, new items are added to the list in place of the first
deleted item, or at the end of the list if no items were removed.</blockquote>

<blockquote>Note: Using "<code>=</code>" is equivalent to "<code>+=</code>" in
any command where the same tag is set with "<code>+=</code>" or
"<code>-=</code>" in another assignment.  (ie. existing items will be preserved
unless specifically deleted with "<code>-=</code>".)</blockquote>

<blockquote>To prevent duplication when adding new items, specific items can be
deleted then added back again in the same command.  For example, the following
command adds the keywords "one" and "two", ensuring that they are not duplicated
if they already existed in the keywords of an image:

<pre>exiftool -keywords-=one -keywords+=one -keywords-=two -keywords+=two DIR
</pre>

When copying list tags using the <code>-tagsFromFile</code> option, items are
copied individually to form proper lists.  However, it gets a bit tricky when
copying multiple tags to a single list tag:  Here, any assignment to a tag
overrides earlier assignments to the same tag in the command.  For instance,
this command

<pre>exiftool "-keywords&lt;filename" "-keywords&lt;comment" DIR
</pre>

writes only the Comment tag.  (Note that <code>-tagsFromFile @</code> is implied
by the "<code>&lt;</code>" operation in this command, causing tags to be copied
from the original file.)  This may seem strange, but it prevents duplicate items
from being added to a list when copying a group of tags from a file containing
duplicate information.  If you really want to add values from multiple tags, use
the <code>-addTagsFromFile</code> option instead:

<pre>exiftool -addTagsFromFile @ "-keywords&lt;filename" "-keywords&lt;comment" DIR
</pre>

Note that as with "<code>=</code>" in the first three examples above, the
"<code>&lt;</code>" operation of this command overwrites any Keywords that
existed previously in the original file.  To add to or remove from the existing
keywords, use "<code>+&lt;</code>" or "<code>-&lt;</code>".
</blockquote>

<a name="Q18"></a>
<p>18. <b>"Special characters don't display properly in my Windows console"</b></p>

<blockquote>The Windows cmd.exe console uses an MS-DOS encoding by default
(cp437 or something similar, depending on your region).  The exiftool
<code>-charset</code> option may be used to encode the exiftool output for a
specific Windows code page, which may help display some special characters, but
instead it may be better to switch the console to UTF&#8209;8 (the native
ExifTool character encoding). This is especially useful if you are using the
<code>-lang</code> option to translate exiftool output to another language.  To
change the the Windows console to UTF&#8209;8, follow these steps:

<ol><li>Run "cmd.exe" to open a Windows console (select "Run..." from the
Start menu and enter "cmd").</li>
<li>Change the font in the console Properties to any True Type font (ie. "TT
Lucida Console").</li>
<li>Type "<code>chcp 65001</code>" then press RETURN at the command prompt.</li>
</ol>

The console should now be able to display UTF&#8209;8 characters (cp65001).  But
note that the TT Lucida Console font shipped with Windows, at least my version,
may not be very complete, and doesn't seem to contain Japanese or Chinese
characters.</blockquote>

<blockquote>To permanently set the font, select "Save properties for future
windows" when changing the font Properties.  Also, you can automatically run
"<code>chcp 65001</code>" every time "cmd.exe" is launched by changing the
Windows Registry for the Command Processor: Run "regedit" and put "<code>chcp
65001</code>" into Data field for "HKEY_LOCAL_MACHINE\Software\Microsoft\Command
Processor\Autorun". (Unfortunately, I haven't been able to figure out how to
change the code page for exiftool when launched via the Windows GUI.  If anyone
can figure out how to do this, please let me know.)
</blockquote>

<blockquote>On some Windows systems, using UTF&#8209;8 doesn't seem to work. In
this case, a Windows character set may be the best alternative:  For instance,
for Windows Latin1 (cp1252) type "<code>chcp 1252</code>" in the console to
switch to cp1252, then run exiftool with "<code>-charset cp1252</code>" (or
<code>-L</code>).  This same technique can be used for other supported Windows
code pages.</blockquote>

<a name="Q19"></a>
<p>19. <b>"How do I change the format of an extracted tag value?"</b></p>

<blockquote>The exiftool application has built-in options which allow you to
disable print conversions (<code>-n</code>), escape special HTML characters
(<code>-E</code>), and change the date/time (<code>-d</code>) and GPS coordinate
(<code>-c</code>) formats, but sometimes more control is needed over the
formatting of a value.  In this case, user-defined Composite tags may be used to
define custom formatting on a per-tag basis.  Here is a basic config file
example to illustrate the idea:

<pre>%Image::ExifTool::UserDefined = (
   'Image::ExifTool::Composite' => {
       MyArtist => {
           Require => 'Artist',
           ValueConv => '$val =~ tr/ /_/; $val',
       },
   },
);
1; # end
</pre>

The above config file defines a new tag called "MyArtist" which takes its value
from the "Artist" tag after converting spaces to underlines. So, for example,
an Artist value of "Phil Harvey" yields a corresponding MyArtist value of
"Phil_Harvey".  The ValueConv string may be any valid Perl expression, and is
evaluated to obtain the value for the new tag.  In this expression,
<code>$val</code> represents the ValueConv value of the Require'd tag.
</blockquote>

<blockquote>To activate the config file, it must be named
"<code>.ExifTool_config</code>" and placed either in your home directory or in
the same directory as the exiftool application. Note that the file name begins
with a "<code>.</code>", so if you are in Windows or on a Mac you may need to
rename the file from the command line since the GUI might not like file names
beginning with a "<code>.</code>".</blockquote>

<blockquote>Often user-defined Composite tags are used to reformat values for
writing with a command-line argument like "<code>-DSTTAG&lt;MyArtist</code>"
(where <code>DSTTAG</code> is the name of any writable tag, even the original
Artist tag or the FileName).</blockquote>

<blockquote>User-defined Composite tags have many other features, including the
ability to combine the values of multiple tags.  See the
<a href="config.html">config file documentation</a> for more details about
user-defined tags, and lib/Image/ExifTool/README in the full distribution for a
complete description of ValueConv features.  Also, a
<a href="http://u88.n24.queensu.ca/exiftool/forum/index.php?action=search2&amp;search=code+userdefined">quick
search of the ExifTool forum</a> should reveal a number of user-defined tag
examples, and there are other good (and often more complex) examples which can
be found in the %Image::ExifTool::Exif::Composite hash of the
lib/Image/ExifTool/Exif.pm source code.
</blockquote>

<a name="Q20"></a>
<p>20. <b>"ExifTool won't write an image due to errors"</b></p>

<blockquote>Minor errors may be ignored using the <code>-m</code> option, but
sometimes there are more serious errors which can't be ignored.  ExifTool can be
used to fix these problems in JPEG images by deleting all metadata and
rebuilding it from scratch.  The command looks like this:

<pre>exiftool -all= -tagsfromfile @ -all:all -unsafe bad.jpg
</pre>

where "<code>bad.jpg</code>" is the name of the image that requires fixing. This
command deletes all metadata then copies all writable tags that can be extracted
from the original image to the same locations in the new image.  The
"<code>Unsafe</code>" tag is a <a href="TagNames/Shortcuts.html">shortcut</a>
for unsafe EXIF tags in JPEG images which are not normally copied.</blockquote>

<blockquote>After repairing an image like this you should be able to write to it
without errors, but note that some metadata from the original image may have
been lost in the process.</blockquote>

<blockquote>If there are also MakerNote problems in the file, you may want to
add the <code>-F</code> option to the command.  See <a href='#Q15'>FAQ 15</a>
for details.  For example, to rebuild the EXIF only and fix the MakerNote
offsets you could do this:

<pre>exiftool -exif:all= -tagsfromfile @ -exif:all -unsafe -thumbnailimage -F bad.jpg
</pre>

<b>Advanced</b>: The byte order of the newly created EXIF is set by the value of
the ExifByteOrder tag.  Since this tag does not belong to the EXIF group, it is
not copied with <code>-exif:all</code> above (but would be copied with
<code>-all:all</code> as in the first example).  If ExifByteOrder is not set
then the byte order is determined by the ordering of the MakerNotes if they are
copied, otherwise big-endian ("MM") byte order is used by default. 
ExifByteOrder may be set to a specific value to force a particular byte order
when creating new EXIF (ie. "<code>-ExifByteOrder=II</code>" for little-endian).
</blockquote>

<a name="Q21"></a>
<p>21. <b>"How do I read/write values containing newline characters?"</b></p>

<blockquote>When reading, by default exiftool converts all control characters to
"." to avoid messing up the output formatting, so newlines will appear as a "."
in the output.  The <code>-b</code> option may be used to bypass all output
formatting (except that a line-feed character is inserted between items in a
list), but this may not be appropriate when the values of many tags must be
extracted.  In this case, the formatted output (<code>-p</code>), JSON
(<code>-j</code>) and XML (<code>-X</code>) options provide alternative output
formats which preserve newlines in values.</blockquote>

<blockquote>When writing, there are a number of options:

<ol type='a'>
<li>In many shells, a newline may be inserted directly in the command
line:
<p>Bourne shells (press <i>RETURN</i> inside a quoted string)</p>
<pre>exiftool -comment="line 1
line 2" image.jpg
</pre>
<p>C shells (press "<code>\</code>" then <i>RETURN</i> inside a quoted string)</p>
<pre>exiftool -comment="line 1\
line 2" image.jpg
</pre>
<i class=lt>[Unfortunately the Windows cmd shell provides no method to get a
newline (CR/LF in Windows) into the command line.  A linefeed (LF) may be
inserted with CTRL-T, but I have found no way to insert a carriage return
(CR).]</i><br><br>
</li>
<li>Write the tag from the contents of a separate text file:
<pre>exiftool "-comment&lt;=file.txt" image.jpg
</pre></li>
<li>Use <code>$/</code> in a redirection expression (Note: Single quotes
must be used in Mac/Linux shells around arguments containing a dollar sign,
but double quotes are used instead in Windows):
<pre>exiftool '-comment&lt;line 1$/line 2' image.jpg
</pre></li>
<li>Use the <code>-E</code> option to allow HTML character entities (Note:
In Windows a newline is "<code>&amp;#xd;&amp;#xa;</code>" instead of just
"<code>&amp;#xa;</code>"):
<pre>exiftool -E "-comment=line 1&amp;#xa;line 2" image.jpg
</pre></li>
</ol>
</blockquote>

<a name="Q22"></a>
<p>22. <b>"In what order are command-line assignments applied when writing?"</b></p>

<blockquote>When writing, tag assignments on the command line are queued and
applied together as each target file is processed.  In general, assignments
later on the command line override earlier assignments, but there are
exceptions:
<ol><li>When writing list-type tags (ie. <code>-keywords=one</code>), new values
are accumulated rather than overriding earlier assignments.<br>&nbsp;</li>
<li>When copying values to list-type tags (ie.
<code>"-keywords&lt;filename"</code>), new values are accumulated only if
<code>-addTagsFromFile</code> is used, otherwise they override earlier
assigments if <code>-tagsFromFile</code> is used or implied.<br>&nbsp;</li>
<li>Tags copied with the <code>-tagsFromFile</code> option are assigned in order,
but after all other assignments, unless the <code>-tagsFromFile</code> argument
is a simple file name. (ie. Assignments are delayed if the
<code>-tagsFromFile</code> argument is <code>@</code> or contains
<code>%f</code>, <code>%e</code> or <code>%d</code>.)</li></ol>
Note: When copying tag values, adding to lists, or shifting date/time values,
the source value is always the original value found in the file, regardless of
any previous assignments.  For example, the following command sets Subject to
the original value of Title in the file (NOT to "test"):
<pre>exiftool -title=test "-subject&lt;title" a.jpg</pre></blockquote>

<a name="Q23"></a>
<p>23a. <b>"Why do I get '<code>0 image files updated</code>' when writing?"</b>, or<br>
23b. <b>"ExifTool doesn't write some tags to a file"</b></p>

<blockquote>There are two reasons why this may happen:

<ol><li>The value of the tag is not being set correctly.</li></ol>

This may be due to a tag value which can't be converted, in which case you
should warning like this (note: you may need to use the <code>-v3</code> option
to see the warning if other same-named tags are being set properly by the same
assignment):
<pre>Warning: Can't convert IFD0:Orientation (not in PrintConv)
</pre>
You get this warning if you write an invalid value to a tag which accepts only
specific values.  See the "Values" column in the appropriate table of the
<a href="TagNames/index.html">Tag Name documentation</a> for a list of valid
values for these types of tags.  The value conversion may also be bypassed with
the <code>-n</code> option, allowing numerical values to be written directly.
See <a href="#Q6">FAQ number 6</a> for more details.

<ol start="2"><li>The information type isn't supported by the format of the
target file.</li></ol>

Warnings are NOT generated when a tag isn't written because it is
normal that many tags can't be written when copying between files of different
formats.</blockquote>

<blockquote>Tags are not written if the format of the target file doesn't
support the specific type of meta information.  For example, CRW images do not
support EXIF or IPTC metdata.  Follow the links in the
<a href="index.html#supported">Supported File Types</a> table for an indication
of the tags supported by your file.  If the tags aren't supported for your file
type, then a <a href='metafiles.html'>metadata sidecar file</a> is an
alternative.</blockquote>

<blockquote>Also note that MakerNotes tags can not be created or deleted
individually, so they can only be written if they already exist in a
file.  The entire MakerNotes must be created or deleted as a block (see
<a href="#Q8">FAQ number 8</a> for details).</blockquote>

<hr>
<i>Last revised June 24, 2011</i>
<p class='lf'><a href="index.html">&lt;-- Back to ExifTool home page</a></p>
</body>
</html>