You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
1826 lines
91 KiB
1826 lines
91 KiB
<!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 }
|
|
.U { color: #c84 } /* unused data block */
|
|
.prog { padding: 0.5em; border: 1px solid gray; background: #fee }
|
|
-->
|
|
</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">ExifTool doesn't read/write properly</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 & 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 and image quality</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>
|
|
<li><a href="#Q24">Date/time gets reset to today</a></li>
|
|
<li><a href="#Q25">Image validation</a></li>
|
|
<li><a href="#Q26">Import from database</a></li>
|
|
<li><a href="#Q27">Windows .BAT file problems</a></li>
|
|
<li><a href="#Q28">Copying a shifted date/time</a></li>
|
|
<li><a href="#Q29">ARGFILE options</a></li>
|
|
<li><a href="#Q30">Extracting all metadata</a></li>
|
|
<li><a href="#Q31">Rewriting the entire file</a></li>
|
|
<li><a href="#Q32">Safely removing all metadata</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="https://exiftool.org/forum/">https://exiftool.org/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. These descriptions are in English
|
|
unless the <code>-lang</code> option is used to select another language. Note
|
|
that descriptions often contain spaces between words, but tag names never do.
|
|
Also, tag names are always English, regardless of the <code>-lang</code>
|
|
setting. To print the tag names instead instead of descriptions, use the
|
|
<code>-s</code> option when extracting information. eg)
|
|
<pre>exiftool -s image.jpg</pre>
|
|
Valid characters in tag names are <code>A-Z</code>, <code>a-z</code>,
|
|
<code>0-9</code>, <code>_</code> and <code>-</code>. See the
|
|
<a href="TagNames/index.html">tag name documentation</a> for a complete list of
|
|
available tag names.</blockquote>
|
|
|
|
<blockquote>Tag names may be optionally prefixed by a group name to specify a
|
|
particular information type or location. Use the <code>-g0</code>,
|
|
<code>-g1</code>, etc (or <code>-G0</code>, <code>-G1</code>, etc) options when
|
|
extracting information to see the corresponding group names. See the <a
|
|
href="index.html#groups">Tag Groups</a> section of the ExifTool home page for
|
|
more information. </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>First, make sure you are looking at the right information. Use
|
|
ExifTool with a command like this to extract all information from the file,
|
|
along with the location it was written:
|
|
|
|
<pre>exiftool -a -G1 -s c:\images\test.jpg</pre>
|
|
|
|
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>-s</code> shows the tag names instead of their descriptions.
|
|
(Substitute the path name of your file in place of
|
|
"<code>c:\images\test.jpg</code>".)</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 EXIF GPS tags because some may have been
|
|
suppressed by same-named tags in other groups. To be sure all EXIF GPS tags are
|
|
extracted, the <code>-a</code> option must be used:
|
|
|
|
<pre>exiftool -a -gps:all image.jpg</pre>
|
|
|
|
<i class=lt>[But note that GPS information may be stored in metadata formats
|
|
other than just EXIF, so restricting the command to the EXIF "GPS" group may
|
|
miss GPS information in other formats. The following command is better suited
|
|
to extract all GPS from a wide variety of file formats:]</i>
|
|
|
|
<pre>exiftool -a "-gps*" -ee video.mp4</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 (with the <code>-a</code> and <code>-G1</code> options) 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. eg.) "<code>-ExifIFD:DateTimeOriginal</code>"
|
|
</blockquote>
|
|
|
|
<blockquote>This problem may also occur if contradictory information exists in
|
|
different meta information formats within the same file. For example, often XMP
|
|
will be ignored if IPTC exists and the Photoshop:IPTCDigest does not agree with
|
|
the IPTC content. The
|
|
<a href="https://web.archive.org/web/20181006115950/http://www.metadataworkinggroup.org/specs/">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>
|
|
|
|
<blockquote>One final note: When writing, the <code>-v2</code> option may be
|
|
useful because it provides details about what ExifTool is writing, and where.
|
|
</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 by the camera and/or ExifTool. (You can
|
|
use the <code>-n</code> option to avoid rounding by ExifTool and show the full
|
|
value in decimal form.) 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.
|
|
<i class=lt>[The year must be 4 digits. Other fields are expected to be 2
|
|
digits, but a single digit is allowed if the subsequent character is a
|
|
non-digit.]</i> 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>"). This feature facilitates useful operations such as
|
|
setting date/time tags from a date embedded in the file name. For example, the
|
|
command
|
|
|
|
<pre>exiftool "-alldates<filename" c:\images</pre>
|
|
|
|
will set the common date/time tags from the file name for all images in the
|
|
directory "<code>c:\images</code>". This will work for any file name which
|
|
matches the above criteria (eg. "IMG_20110927_103000.jpg").
|
|
<i class=lt>[AllDates is a shortcut for 3 tag names: DateTimeOriginal,
|
|
CreateDate and ModifyDate. See the <a href="TagNames/Shortcuts.html">Shortcuts
|
|
Tags documentation</a> for more information.]</i></blockquote>
|
|
|
|
<blockquote>The <code>-d</code> option provides additional flexibility in
|
|
parsing strings when writing date/time tags with ExifTool 10.32 or later if
|
|
POSIX::strptime or Time::Piece is installed (use "<code>exiftool -ver -v</code>"
|
|
to check the installed packages). The format of the <code>-d</code> argument is
|
|
the same for reading and writing.</blockquote>
|
|
|
|
<blockquote>The <code>-n</code> option may be used to disable all of the
|
|
date/time reformatting when reading and writing which will allow otherwise
|
|
invalid date/time values to be written (eg. partial EXIF dates). The
|
|
reformatting may be disabled on a per-tag basis by adding "<code>#</code>"
|
|
to the tag name instead of using <code>-n</code></blockquote>
|
|
|
|
<blockquote><b>Special feature</b>: A value of "<code>now</code>" may be used to
|
|
represent the current time when writing any date/time tag. For example:
|
|
<pre>exiftool -xmp:dateTimeOriginal=now a.jpg</pre>
|
|
<i class=lt>[There is also a <a href="TagNames/Extra.html">Now tag</a> which may
|
|
be used for a similar purpose by copying its value to another tag, but copying
|
|
tags adds an extra read stage to the processing which is best avoided if
|
|
performance is an issue.]</i>
|
|
</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, eg)
|
|
<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></blockquote><blockquote class=prog>
|
|
<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 (BUT
|
|
NOTE THAT WITH PROPRIETARY RAW FORMATS THIS MAY DELETE INFORMATION THAT IS
|
|
NECESSARY FOR PROPER RENDERING OF THE IMAGE).
|
|
</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 CommonIFD0
|
|
<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>, or
|
|
<br>8c. <b>"I can't view a RAW image after changing the model tag"</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 (which, for a RAW image, may mean that the image
|
|
can no longer be properly rendered). 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. eg)
|
|
<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. Since maker note
|
|
tags may not be created individually, they must instead 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 general 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 family 1 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>
|
|
|
|
In this command, since no destination tag was specified, the destination is the
|
|
same as the source (ie. "<code>-all:all>all:all</code>"), so the information is
|
|
copied to the same family 1 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>all" dst.jpg
|
|
exiftool -tagsfromfile src.jpg "-all:all>all" dst.jpg
|
|
|
|
<span class='blk'># copy all tags, preserving family 1 group (destination group 'all')</span>
|
|
exiftool -tagsfromfile src.jpg -all:all dst.jpg
|
|
exiftool -tagsfromfile src.jpg "-all>all:all" dst.jpg
|
|
exiftool -tagsfromfile src.jpg "-all:all>all:all" dst.jpg
|
|
|
|
<span class='blk'># copy all tags to EXIF group (destination group 'exif')
|
|
# [the destination family 1 group is the preferred EXIF IFD]</span>
|
|
exiftool -tagsfromfile src.jpg "-all>exif:all" dst.jpg
|
|
exiftool -tagsfromfile src.jpg "-all:all>exif:all" dst.jpg
|
|
|
|
<span class='blk'># copy XMP tags to XMP group (destination group 'xmp')
|
|
# [the destination family 1 group is the preferred XMP namespace]</span>
|
|
exiftool -tagsfromfile src.jpg "-xmp:all" dst.jpg
|
|
exiftool -tagsfromfile src.jpg "-xmp:all>xmp:all" dst.jpg
|
|
|
|
<span class='blk'># copy XMP tags, preserving family 1 group (destination group 'all')</span>
|
|
exiftool -tagsfromfile src.jpg "-xmp:all>all:all" dst.jpg
|
|
|
|
<span class='blk'># copy XMP tags to preferred groups (no destination group)</span>
|
|
exiftool -tagsfromfile src.jpg "-xmp:all>all" dst.jpg
|
|
|
|
<span class='blk'># copy XMP tags to EXIF only (destination group 'exif')
|
|
# [the destination family 1 group is the preferred EXIF IFD]</span>
|
|
exiftool -tagsfromfile src.jpg "-xmp:all>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>
|
|
|
|
<blockquote>Certain types of meta information (such as EXIF, IPTC, XMP and
|
|
ICC_Profile) may also be <b>copied as a block</b>. This technique copies all
|
|
meta information, even if ExifTool doesn't have the ability to write some
|
|
individual tags contained in the block. For all block types except EXIF, the
|
|
metadata is copied byte-for-byte from the original image. With EXIF however,
|
|
the metadata may be restructured to ensure that it is self-contained. Also note
|
|
that EXIF may not be written as a block to TIFF-based file formats. Beware that
|
|
<b>any existing metadata</b> of this type in the destination file <b>will be
|
|
overwritten</b> by the new block.
|
|
|
|
<pre><span class='blk'># copy EXIF as a block between same-named JPG files in different directories</span>
|
|
exiftool -tagsfromfile SRCDIR/%f.%e -exif -ext jpg DSTDIR
|
|
|
|
<span class='blk'># copy XMP as a block from one file to another</span>
|
|
exiftool -tagsfromfile src.jpg -xmp dst.cr2
|
|
</pre></blockquote>
|
|
|
|
<a name="Q10"></a>
|
|
<p>10. <b>"How does ExifTool handle coded character sets?"</b></p>
|
|
|
|
<!-- vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv -->
|
|
<!-- NOTE: CHANGES TO FAQ 10 MUST ALSO BE REFLECTED IN ExifTool.pod! -->
|
|
|
|
<blockquote><i>[Also see <a href="#Q18">FAQ number 18</a> for help with
|
|
special characters in a Windows console.]</i></blockquote>
|
|
|
|
<blockquote>Certain meta information formats allow coded character sets other
|
|
than plain ASCII. When reading, most known encodings are converted to the
|
|
external character set according to the exiftool "<code>-charset CHARSET</code>"
|
|
or <code>-L</code> option, or to UTF‑8 by default. When writing, the
|
|
inverse conversion is performed. Alternatively, special characters may be
|
|
converted to/from HTML character entities with the <code>-E</code> option.
|
|
</blockquote>
|
|
|
|
<blockquote>A distinction is made between the <b>external</b> character set
|
|
visible to the ExifTool user, and the <b>internal</b> character used to store
|
|
text in the metadata of a file. These character sets may be specified
|
|
separately as follows:
|
|
<ol><li>The <b>external</b> character set for <b>tag values</b> passed to/from
|
|
ExifTool is UTF‑8 by default, but it may be changed through any of these
|
|
command-line options:
|
|
<blockquote><code>-charset CHARSET</code> or
|
|
<code>-charset exiftool=CHARSET</code> or <code>-L</code>
|
|
</blockquote>
|
|
The encoding of <b>file and directory names</b> (eg. the <i>FILE</i> argument on
|
|
the command line) is different. By default, these names are passed straight
|
|
through to the standard C I/O routines without recoding. On Mac/Linux these
|
|
routines expect UTF‑8, but on Windows they use the system code page (which
|
|
is dependent on your system settings). However, as of ExifTool 9.79, the
|
|
external filename encoding may be specified:
|
|
<blockquote><code>-charset filename=CHARSET</code></blockquote>
|
|
When this is done, file and directory names are converted from the specified
|
|
encoding to one appropriate for system I/O routines. In Windows, this also has
|
|
the effect of enabling Unicode filename support via the special Windows
|
|
wide-character I/O routines if the required Perl modules are available
|
|
(these are included in the Windows executable version of ExifTool). See
|
|
<a href="exiftool_pod.html#WINDOWS-UNICODE-FILE-NAMES">WINDOWS UNICODE FILE NAMES</a>
|
|
in the application documentation for more details.<br><br></li>
|
|
<li>The <b>internal</b> character set for strings stored in file metadata may be
|
|
specified for some metadata types:
|
|
<blockquote><code>-charset TYPE=CHARSET</code></blockquote>
|
|
(where <code>TYPE</code> is "<code>exif</code>", "<code>iptc</code>",
|
|
"<code>id3</code>", "<code>photoshop</code>", "<code>quicktime</code>" or
|
|
"<code>riff</code>")</li></ol>
|
|
|
|
Valid <code>CHARSET</code> values are (with aliases given in brackets, case is
|
|
not significant):
|
|
|
|
<blockquote><table class=clear>
|
|
<tr><td>UTF8</td><td>(cp65001, UTF‑8)</td><td>DOSLatinUS</td><td>(cp437)</td></tr>
|
|
<tr><td>Latin</td><td>(cp1252, Latin1)</td><td>DOSLatin1</td><td>(cp850)</td></tr>
|
|
<tr><td>Latin2</td><td>(cp1250)</td><td>DOSCyrillic</td><td>(cp866)</td></tr>
|
|
<tr><td>Cyrillic</td><td>(cp1251, Russian) </td><td>MacRoman</td><td>(cp10000, Mac, Roman)</td></tr>
|
|
<tr><td>Greek</td><td>(cp1253)</td><td>MacLatin2</td><td>(cp10029)</td></tr>
|
|
<tr><td>Turkish</td><td>(cp1254)</td><td>MacCyrillic</td><td>(cp10007)</td></tr>
|
|
<tr><td>Hebrew</td><td>(cp1255)</td><td>MacGreek</td><td>(cp10006)</td></tr>
|
|
<tr><td>Arabic</td><td>(cp1256)</td><td>MacTurkish</td><td>(cp10081)</td></tr>
|
|
<tr><td>Baltic</td><td>(cp1257)</td><td>MacRomanian</td><td>(cp10010)</td></tr>
|
|
<tr><td>Vietnam</td><td>(cp1258)</td><td>MacIceland</td><td>(cp10079)</td></tr>
|
|
<tr><td>Thai</td><td>(cp874)</td><td>MacCroatian</td><td>(cp10082)</td></tr>
|
|
</table></blockquote>
|
|
|
|
The <code>-L</code> option is equivalent to "<code>-charset Latin</code>",
|
|
"<code>-charset Latin1</code>" and "<code>-charset cp1252</code>".</blockquote>
|
|
|
|
<blockquote>Type-specific details are given below about the special character
|
|
handling for EXIF, IPTC, XMP, PNG, ID3, PDF, Photoshop, QuickTime, AIFF, RIFF,
|
|
MIE and Vorbis information:</blockquote>
|
|
|
|
<!-- NOTE: CHANGES TO FAQ 10 MUST ALSO BE REFLECTED IN ExifTool.pod! -->
|
|
|
|
<blockquote><a name="exif"><b>EXIF</b></a>: Most textual information in EXIF is
|
|
stored in ASCII format (called "string" in the
|
|
<a href="TagNames/EXIF.html">EXIF Tags documentation</a>). By default ExifTool
|
|
does not convert these strings. However, it is not uncommon for applications to
|
|
write UTF‑8 or other encodings where ASCII is expected. To deal with
|
|
these, ExifTool allows the internal EXIF string encoding to be specified with
|
|
"<code>-charset exif=CHARSET</code>", which causes EXIF string values to be
|
|
converted from the specified character set when reading, and stored with this
|
|
character set when writing. The
|
|
<a href="http://www.metadataworkinggroup.org/">MWG</a> recommends using
|
|
UTF‑8 encoding for EXIF strings, and in keeping with this the
|
|
"<code>-use mwg</code>" feature sets the default internal EXIF string encoding
|
|
to UTF‑8 (ie. "<code>-charset exif=utf8</code>"), but note that this will
|
|
have no effect unless the external encoding is also set to something other than
|
|
the default of UTF‑8.</blockquote>
|
|
|
|
<blockquote>A few EXIF tags (UserComment, GPSProcessingMethod and
|
|
GPSAreaInformation) support a designated internal text encoding, with values
|
|
stored as ASCII, Unicode (UCS‑2) or JIS. When reading these tags, ExifTool
|
|
converts Unicode and JIS to the external character set specified by the
|
|
<code>-charset</code> or <code>-L</code> option, or to UTF‑8 by default.
|
|
ASCII text is not converted. When writing, text is stored as ASCII unless the
|
|
string contains special characters, in which case it is converted from the
|
|
external character set (UTF‑8 by default), and stored as Unicode. ExifTool
|
|
writes Unicode in native EXIF byte ordering by default, but the byte order may
|
|
be specified by setting the ExifUnicodeByteOrder tag (see the
|
|
<a href="TagNames/Extra.html">Extra Tags documentation</a>).</blockquote>
|
|
|
|
<blockquote>The EXIF "XP" tags (XPTitle, XPComment, etc) are always stored
|
|
internally as little-endian Unicode (UCS‑2), and are read and written
|
|
using the specified external character set.</blockquote>
|
|
|
|
<!-- NOTE: CHANGES TO FAQ 10 MUST ALSO BE REFLECTED IN ExifTool.pod! -->
|
|
|
|
<blockquote><a name="iptc"><b>IPTC</b></a><span class='sm'><sup>†</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 % G</code>") then string values are
|
|
assumed to be stored as UTF‑8. Otherwise the internal IPTC encoding is
|
|
assumed to be Windows Latin1 (cp1252), but this can be changed with
|
|
"<code>-charset iptc=CHARSET</code>". When reading, these strings are converted
|
|
to UTF‑8 by default, or to the external 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‑8 (from Windows Latin1 unless
|
|
CodedCharacterSet was already "UTF8"):
|
|
<pre>exiftool -tagsfromfile @ -iptc:all -codedcharacterset=utf8 a.jpg
|
|
</pre>or from Windows Latin2 (cp1250) to UTF‑8:
|
|
<pre>exiftool -tagsfromfile @ -iptc:all -codedcharacterset=utf8 -charset iptc=latin2 a.jpg
|
|
</pre>and this command changes it back from UTF‑8 to Windows Latin1 (cp1252):
|
|
<pre>exiftool -tagsfromfile @ -iptc:all -codedcharacterset= a.jpg
|
|
</pre>or to Windows Latin2:
|
|
<pre>exiftool -tagsfromfile @ -iptc:all -codedcharacterset= -charset iptc=latin2 a.jpg
|
|
</pre>Note that unless CodedCharacterSet is UTF‑8, applications have no
|
|
reliable way to determine the IPTC character encoding. For this reason, it is
|
|
recommended that CodedCharacterSet be set to "<code>UTF8</code>" when creating
|
|
new IPTC.</blockquote>
|
|
|
|
<blockquote class='sm'><sup>†</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="https://iptc.org/standards/photo-metadata/iptc-standard/">IPTC
|
|
Photo Metadata Standard</a> actually uses the XMP format (see below).</span>
|
|
</blockquote>
|
|
|
|
<!-- NOTE: CHANGES TO FAQ 10 MUST ALSO BE REFLECTED IN ExifTool.pod! -->
|
|
|
|
<blockquote><a name="xmp"><b>XMP</b></a>: Exiftool reads XMP encoded as
|
|
UTF‑8, UTF‑16 or UTF‑32, and converts them all to UTF‑8
|
|
internally. Also, all XML character entity references and numeric character
|
|
references are converted. When writing, ExifTool always encodes XMP as
|
|
UTF‑8, converting the following 5 characters to XML character references:
|
|
<code>& < > ' "</code>. By default no further conversion is
|
|
performed, however the <code>-charset</code> or <code>-L</code> option may be
|
|
used to convert text to/from a specified external character set when
|
|
reading/writing.</blockquote>
|
|
|
|
<blockquote><a name="png"><b>PNG</b></a>:
|
|
<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‑8. When reading, ExifTool converts
|
|
all PNG textual data to the external character set specified by the
|
|
<code>-charset</code> or <code>-L</code> option, or to UTF‑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 external character
|
|
set and stored as UTF‑8.</blockquote>
|
|
|
|
<blockquote><a name="com"><b>JPEG Comment</b></a>: The encoding for the JPEG
|
|
Comment (COM segment) is not specified, so ExifTool reads/writes this text
|
|
without conversion.</blockquote>
|
|
|
|
<blockquote><a name="id3"><b>ID3</b></a>: The ID3v1 specification officially
|
|
supports only ISO 8859‑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 external character set specified by the
|
|
<code>-charset</code> or <code>-L</code> option, or to UTF‑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
|
|
external character set specified by <code>-charset</code> or <code>-L</code>, or
|
|
to UTF‑8 by default. ExifTool does not currently write ID3
|
|
information.</blockquote>
|
|
|
|
<blockquote><a name="pdf"><b>PDF</b></a>: PDF text strings are stored in either
|
|
PDFDocEncoding (similar to Windows Latin1) or Unicode (UCS‑2). When
|
|
reading, ExifTool converts to the external character set specified by the
|
|
<code>-charset</code> or <code>-L</code> option, or to UTF‑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><a name="photoshop"><b>Photoshop</b></a>: Some Photoshop resource
|
|
names are stored as Pascal strings with unknown encoding. By default, ExifTool
|
|
assumes MacRoman encoding and converts this to UTF‑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><a name="quicktime"><b>QuickTime</b></a>: QuickTime text strings may
|
|
be stored in a variety of poorly documented formats, and ExifTool does its best
|
|
to decode these according to the <code>-charset</code> option setting. For some
|
|
QuickTime strings where the internal encoding is not known, ExifTool assumes a
|
|
default encoding of MacRoman, but this may be changed with
|
|
"<code>-charset QuickTime=CHARSET</code>".</blockquote>
|
|
|
|
<blockquote><a name="aiff"><b>AIFF</b></a>: AIFF strings are assumed to be
|
|
stored in MacRoman, and are converted according to the <code>-charset</code>
|
|
option when reading. </blockquote>
|
|
|
|
<blockquote><a name="riff"><b>RIFF</b></a>: The internal encoding of RIFF
|
|
strings (eg. in AVI and WAV files) is assumed to be Latin unless otherwise
|
|
specified by the RIFF CSET chunk or the "<code>-charset RIFF=CHARSET</code>"
|
|
option. </blockquote>
|
|
|
|
<blockquote><a name="mie"><b>MIE</b></a>: MIE strings are stored as either
|
|
UTF‑8 or ISO 8859‑1. When reading, UTF‑8 strings are converted
|
|
according to the <code>-charset</code> or <code>-L</code> option, and ISO
|
|
8859‑1 strings are never converted. When writing, input strings are
|
|
converted from the specified character set to UTF‑8. The resulting
|
|
strings are stored as UTF‑8 if they contain multi-byte UTF‑8
|
|
character sequences, otherwise they are stored as ISO 8859‑1.</blockquote>
|
|
|
|
<blockquote><a name="vorbis"><b>Vorbis</b></a>: Vorbis comments are stored as
|
|
UTF‑8, and are converted to the character set specified by
|
|
<code>-charset</code> or <code>-L</code> when reading.</blockquote>
|
|
|
|
<blockquote class=prog>
|
|
<b>Programmers</b>: ExifTool returns all values as byte strings of encoded
|
|
characters. Perl wide characters are not used. The encoding is UTF‑8 by
|
|
default, but valid UTF‑8 can not be guaranteed for all values, so the
|
|
caller must validate the encoding if necessary. The encodings described above
|
|
are set by the various <a href="ExifTool.html#Charset">Charset options</a> of
|
|
the API.
|
|
<br><br><b>Note</b>: Some settings of the system PERL_UNICODE environment
|
|
variable may be incompatible with ExifTool's character handling.
|
|
</blockquote>
|
|
|
|
<!-- NOTE: CHANGES TO FAQ 10 MUST ALSO BE REFLECTED IN ExifTool.pod! -->
|
|
<!-- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -->
|
|
|
|
<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>ENTER</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 app. (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>Note that all tag names in the config file are <b>case
|
|
sensitive</b>. Specifically, the case must be correct for tag names in
|
|
Composite tag Require/Desire entries. Also note that XMP tag names are
|
|
generated automatically by capitalizing the tag ID unless the tag definition
|
|
contains a "Name" entry.</blockquote>
|
|
|
|
<blockquote class=prog><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><i>[See <a href="#Q26">FAQ number 26</a> for help with the reverse
|
|
-- importing metadata from a database.]</i></blockquote>
|
|
|
|
<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 > out.txt
|
|
</pre>
|
|
|
|
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 tab-delimited text 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>
|
|
|
|
One limitation of the <code>-T</code> option is that a list of tags to extract
|
|
must be specified. Otherwise, all information is extracted from each input
|
|
file, and the columns would contain values from random tags.</blockquote>
|
|
|
|
<blockquote> The <code>-csv</code> (comma separated values) option solves this
|
|
dilemma by pre-extracting information from all input files, then producing a
|
|
sorted list of available tag names as the first row of the output, and
|
|
organizing the information into columns for each tag. As well, a first column
|
|
labelled "SourceFile" is generated. These features make it practical to use the
|
|
<code>-csv</code> option for extracting all information from multiple images.
|
|
For example, this command:
|
|
|
|
<pre>exiftool -csv -r t/images > out.csv</pre>
|
|
|
|
gives an output like this:
|
|
|
|
<pre>SourceFile,AEBBracketValue,AELock,AFAreaHeight,AFAreaMode,AFAreas,[...]
|
|
t/images/Canon.jpg,0,,151,,,[...]
|
|
t/images/Casio.jpg,,,,,,[...]
|
|
t/images/Nikon.jpg,,,,Single Area,,[...]
|
|
t/images/OlympusE1.jpg,,Off,,,"Center (121,121)-(133,133)",[...]
|
|
</pre>
|
|
|
|
Note that the number of columns in the <code>-csv</code> output may be very
|
|
large if all information is extracted. Missing tags are indicated by empty
|
|
strings as in the example above, or by dashes if the <code>-f</code> option is
|
|
used.</blockquote>
|
|
|
|
<blockquote> 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).</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.txt" in the folder:
|
|
|
|
<pre>echo "FileName<tab>Aperture<tab>ISO" > %1\out.txt
|
|
exiftool -T -r -filename -aperture -ISO %1 >> %1\out.txt
|
|
</pre>
|
|
|
|
The "<code>echo</code>" command was included to add column headings to the
|
|
output. (The tab character in the echo command, indicated by
|
|
"<code><tab></code>", may be generated in Mac/Linux shells with CTRL-v
|
|
then TAB, or in a Windows cmd shell with TAB when cmd.exe is run with the
|
|
<code>/f:off</code> option to disable tab completion.)
|
|
</blockquote>
|
|
|
|
<blockquote>Other possible export formats include RDF/XML (with 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 > out.csv
|
|
</pre>
|
|
|
|
But note that any values containing commas, quotes or some other special
|
|
characters may mess up the CSV formatting. If this is a possibility, the
|
|
<code>-api filter</code> option may be added to the command to quote values
|
|
if necessary. For example:
|
|
|
|
<pre><span class='blk'># in a Windows CMD shell</span>
|
|
exiftool -api filter="$_ = qq{""""$_""""} if s/""/""""/g or /(^\s+|\s+$)/ or /[,\n\r]/" ...
|
|
|
|
<span class='blk'># in Mac/Linux</span>
|
|
exiftool -api filter='$_ = qq{"$_"} if s/"/""/g or /(^\s+|\s+$)/ or /[,\n\r]/' ...</pre>
|
|
|
|
The <code>-p</code> option argument may also be 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 > out.csv
|
|
</pre>
|
|
|
|
With the <code>-f</code> option, the value of any missing tag is printed as a
|
|
dash (or the value of the
|
|
<a href="ExifTool.html#MissingTagValue">API MissingTagValue option</a>, if set).
|
|
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>
|
|
|
|
<a name="Q13"></a>
|
|
<p>13a. <b>"Why is my file smaller after I use ExifTool to write information?"</b>, or
|
|
<br>13b. <b>"Why do some Offset tags change value when I write other tags?"</b>, or
|
|
<br>13c. <b>"How does editing a file with ExifTool affect image quality?"</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, or so that some
|
|
tags are stored at different offsets in the file.</blockquote>
|
|
|
|
<blockquote>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 > out.html</code>", then open
|
|
<code>out.html</code> in your web browser. Unused data blocks are
|
|
<span class=U>brown</span> in this output.]</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, but this padding is omitted if the
|
|
<code>-z</code> command-line option or the
|
|
<a href="ExifTool.html#Compact">API Compact</a> NoPadding setting is used), 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 (the
|
|
<code>-z</code> option and the <a href="ExifTool.html#Compact">API Compact</a>
|
|
settings also cause a more compact form to be written).</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 <b>editing a file
|
|
with ExifTool is "lossless" as far as the image is concerned</b>.</blockquote>
|
|
|
|
<a name="Q14"></a>
|
|
<p>14a. <b>"What format do I use for writing GPS coordinates?"</b>, or<br>
|
|
14b. <b>"How do I change the format of extracted 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 with any number of decimal places.</blockquote>
|
|
|
|
<blockquote>For EXIF GPS coordinates, the reference direction is specified
|
|
separately with the EXIF:GPSLatitudeRef or EXIF:GPSLongitudeRef tag.
|
|
GPSLatitudeRef may be written with a string containing "<code>N</code>",
|
|
"<code>North</code>", "<code>S</code>" or "<code>South</code>", or with a signed
|
|
coordinate value (positive for the northern hemisphere or negative for the
|
|
south). GPSLongitudeRef accepts similar values, but for E/East (positive) and
|
|
W/West (negative).</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>
|
|
|
|
<blockquote>ExifTool 12.22 and later allow combined lat/lon GPSCoordinates
|
|
values to be written to GPSLatitude and GPSLongitude, and the appropriate
|
|
latitude or longitude part will be pulled from the input string. Version 12.36
|
|
and later make Composite:GPSPosition writable, allowing EXIF GPS coorinates and
|
|
reference directions to be all writable via a single tag:
|
|
|
|
<pre><span class='blk'># write all 4 EXIF GPS tags (version 12.36 and later)</span>
|
|
exiftool -gpsposition="42 30 0.00 S, 33 15 0.00 W"
|
|
exiftool -gpsposition="-42.5, -33.25"</pre>
|
|
|
|
Version 12.44 and later make Composite:GPSLatitude/GPSLongitude writable,
|
|
allowing the separate EXIF coordinate and reference direction tags to be written
|
|
together. (Note that the Composite group must be specified here because these
|
|
tags are otherwise avoided when writing due to possible confusion when
|
|
attempting to write EXIF tags.)
|
|
|
|
<pre><span class='blk'># write EXIF:GPSLatitude and GPSLatitudeRef together (12.44 and later)</span>
|
|
exiftool -composite:gpslatitude="42 30 0.00 S" a.jpg
|
|
exiftool -composite:gpslatitude="-42.5" a.jpg</pre></blockquote>
|
|
|
|
<blockquote>When reading, by default ExifTool reports coordinates in the format
|
|
<pre>DDD deg MM' SS.SS"</pre>
|
|
where <code>DDD</code> is degrees, <code>MM</code> is minutes, and <code>SS.SS</code>
|
|
is seconds. The <code>-n</code> option may be used to change this to decimal
|
|
degrees, or any arbitrary format may be specified with the <code>-c</code>
|
|
command-line option (see the <a href="exiftool_pod.html">application documentation</a>),
|
|
or the <a href="ExifTool.html#CoordFormat">API CoordFormat option</a>.
|
|
</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. These
|
|
offsets are used as pointers to reference tag values and structures within the
|
|
metadata, and errors like this may lead to missing or incorrect values for some
|
|
MakerNotes tags. In many cases, ExifTool will detect this type of problem and
|
|
issue a warning like this when reading (or an error when writing):
|
|
|
|
<pre>Warning: [minor] Possibly incorrect maker notes offsets (fix by -340?)
|
|
</pre>
|
|
|
|
<i class=lt>[Be aware that if multiple warnings occur, the <code>-a</code>
|
|
option must be used to see them all, since by default only one warning is
|
|
displayed per file.]</i> </blockquote>
|
|
|
|
<blockquote>This is a particularly insidious problem that is sometimes difficult
|
|
for ExifTool to correct automagically, so it requires some operator
|
|
intervention. If this warning occurs, you have a few alternatives:</blockquote>
|
|
|
|
<blockquote>1) Use the <code>-F</code> option to allow ExifTool to attempt to
|
|
fix the incorrect offsets. If ExifTool was correct in its diagnosis, then this
|
|
option will fix the incorrect offsets. This is usually the appropriate choice
|
|
if this problem was caused by editing the image with other
|
|
software.</blockquote>
|
|
|
|
<blockquote>2) Use the <code>-m</code> option to ignore the warning (or downgrade
|
|
the error to a warning when writing). This causes ExifTool to honour the
|
|
existing maker note offsets, and may be the correct choice if images straight
|
|
out of the camera have this problem.</blockquote>
|
|
|
|
<blockquote>Often, the first choice (<code>-F</code>) is the right thing to do,
|
|
but this depends on many factors, so it is best to try both methods then compare
|
|
the resulting maker note information to see which works best for your
|
|
situation.</blockquote>
|
|
|
|
<blockquote>When writing, <code>-F</code> applies a permanent correction to the
|
|
maker notes. Note that <u>some MakerNote information may be lost permanently
|
|
if the proper correction is not applied when writing images with this
|
|
problem</u>.</blockquote>
|
|
|
|
<blockquote>3) The third alternative is to adjust the maker note offsets by a
|
|
specific amount. This is done by appending an integer to the <code>-F</code>
|
|
option. For example, with the warning above (where ExifTool suggests "fix by
|
|
-340?"), <code>-F</code> would be equivalent to <code>-F-340</code>. See the
|
|
<a href="exiftool_pod.html#F-OFFSET--fixBase">-F option documentation</a> for
|
|
more details. This advanced feature may require some technical knowledge about
|
|
the structure of EXIF information (and here, ExifTool's <code>-htmlDump</code>
|
|
feature may be very useful for visualizing this structure).</blockquote>
|
|
|
|
<blockquote>Other types of MakerNote errors may also 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 <u>some MakerNote information may be lost when ignoring
|
|
errors like this</u>.</blockquote>
|
|
|
|
<blockquote>You may also get one of these warnings when reading or writing a
|
|
file containing unknown maker notes:
|
|
|
|
<pre>Warning: [minor] Unrecognized MakerNotes
|
|
Warning: [minor] Maker notes could not be parsed</pre>
|
|
|
|
These warnings indicate that ExifTool didn't recognize the maker notes in a
|
|
file, so it couldn't extract any information from them when reading, or had to
|
|
copy the maker notes as a block when writing. If the maker notes contain
|
|
absolute offsets then this could result in corrupted makernote information when
|
|
writing, but this is very unlikely.</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>†</sup></span> when <u>any
|
|
tag</u><span class='sm'><sup>‡</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> or <code>-ext+</code> option, something
|
|
like this:
|
|
|
|
<pre><span class=blk># process AVI files in addition to other writable file types</span>
|
|
exiftool -ext+ AVI -d pics/%Y/%m "-directory<dateTimeOriginal" DIR
|
|
|
|
<span class=blk># process only AVI and JPG files</span>
|
|
exiftool -ext AVI -ext JPG -d pics/%Y/%m "-directory<dateTimeOriginal" DIR
|
|
</pre>
|
|
|
|
When <code>-ext</code> is used, only files with the specified extension(s) are
|
|
processed, however <code>-ext+</code> may be used to add to the list of normally
|
|
processed files (as in the first example above). Multiple <code>-ext</code> or
|
|
<code>-ext+</code> options may be used in the same command (as in the second
|
|
example above) to process any number of different file types, or
|
|
<code>-ext "*"</code> may be used to process files with any extension (or none at all).
|
|
</blockquote>
|
|
|
|
<blockquote class='sm'><sup>†</sup> <span class=lt>The
|
|
<code>-listwf</code> option may be used to list the extensions of all writable
|
|
file types, or see <a href="index.html#supported">here</a> for a table of
|
|
supported file types.</span>
|
|
<br><sup>‡</sup> <span class=lt>This includes "pseudo" tags like
|
|
FileName, Directory, FileModifyDate and FileCreateDate.</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 as above, NOT all together, because this
|
|
would represent a single keyword:
|
|
|
|
<pre>exiftool -keywords="one, two, three" test.jpg <i class=blk>(WRONG!)</i>
|
|
</pre>
|
|
|
|
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 or a different output format 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>
|
|
|
|
Alternatively, the <code>-j</code>, <code>-php</code> and <code>-X</code>
|
|
options use an output format which preserves the structure of a
|
|
list (if <code>-sep</code> is NOT used).</blockquote>
|
|
|
|
<blockquote>Note that the writing examples above overwrite any values which
|
|
already existed in the original file for these tags. Instead, to add or delete
|
|
items from an existing list, use "<code>+=</code>" or "<code>-=</code>" in place
|
|
of "<code>=</code>". For example:
|
|
|
|
<pre>exiftool -keywords+="add this" -keywords-="remove this" DIR
|
|
</pre>
|
|
|
|
With 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 List-type tag is set with "<code>+=</code>" or
|
|
"<code>-=</code>" in another assignment. (ie. existing items will be preserved
|
|
unless specifically deleted with "<code>-=</code>".) <i class=lt>[For non
|
|
List-type tags, "<code>+=</code>" has a different meaning, and is used to
|
|
increment numerical values or shift dates.]</i></blockquote>
|
|
|
|
<blockquote><a name="nodups"></a><b>To prevent duplication when adding new
|
|
items</b>, 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 <b>copying list tags</b> using the <code>-tagsFromFile</code> feature,
|
|
items are copied individually to form proper lists if the tag is copied directly
|
|
(note that <code>-tagsFromFile @</code> is implied by the "<code><</code>"
|
|
operation in this and the following commands, causing tags to be copied from the
|
|
original file):
|
|
|
|
<pre>exiftool "-keywords<subject" DIR</pre>
|
|
|
|
However, this is not the case if the tag is interpolated within a format string
|
|
(ie. has a leading "<code>$</code>" symbol), like this
|
|
|
|
<pre>exiftool "-keywords<$subject" DIR <i class=blk>(WRONG!)</i></pre>
|
|
|
|
but here the <code>-sep</code> option may be used to split the list back into
|
|
separate items:
|
|
|
|
<pre>exiftool "-keywords<$subject" -sep "//" DIR</pre>
|
|
|
|
Note there is a complication when <b>copying multiple tags to a single list</b>
|
|
tag: Here, any assignment to a tag overrides earlier assignments to the same
|
|
tag in the command. For instance, this command:
|
|
|
|
<pre>exiftool "-keywords<filename" "-keywords<comment" DIR <i class=blk>(WRONG!)</i>
|
|
</pre>
|
|
|
|
writes only the value from the Comment tag. 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. Alternatively, a leading <code>+</code>
|
|
may be added to accumulate queued items when
|
|
copying from multiple tags to a single list:
|
|
|
|
<pre>exiftool "-keywords<filename" "-+keywords<comment" DIR
|
|
</pre>
|
|
|
|
Note that as with "<code>=</code>" in the first three examples above, the
|
|
"<code><</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>+<</code>" or "<code>-<</code>".
|
|
</blockquote>
|
|
|
|
<blockquote>One final note: In rare cases when copying the contents of two other
|
|
tags into a single list, the resulting queued list values may contain duplicates
|
|
that would be written to the target file. There is an
|
|
<a href="ExifTool.html#NoDups">API NoDups option</a> which removes duplicates items
|
|
from list values that are queued for writing. For example,
|
|
|
|
<pre>exiftool -tagsfromfile a.jpg -subject -tagsfromfile b.jpg -+subject -api nodups c.jpg
|
|
</pre>
|
|
|
|
combines Subject items from a.jpg and b.jpg and writes them without duplicates
|
|
to c.jpg (overwriting any previous Subject in c.jpg).</blockquote>
|
|
|
|
<a name="Q18"></a>
|
|
<p>18a. <b>"Special characters don't display properly in my Windows console"</b>, or
|
|
<br>18b. <b>"I'm having problems with special characters on the Windows command line"</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‑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 Windows console to UTF‑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 (eg. "TT
|
|
Lucida Console").</li>
|
|
<li>Type "<code>chcp 65001</code>" then press ENTER at the command prompt.</li>
|
|
</ol>
|
|
|
|
The console should now be able to display UTF‑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>Note that Windows will <b>recode arguments on the command
|
|
line</b> from the current console code page to the system code page, so the
|
|
ExifTool <code>-charset</code> should be set to the system code page for
|
|
command-line arguments. However, this technique may yield unexpected results
|
|
since not all characters may be represented using the system code page. To get
|
|
around this limitation, arguments may be read from an ExifTool argument file
|
|
using the <code>-@</code> option. UTF‑8 encoding is recommended for the
|
|
argument file, and with this you would also set <code>-charset filename=utf8</code>
|
|
if using special characters in filename arguments within the file.</blockquote>
|
|
|
|
<blockquote>Another way to bypass the console/command-line encoding problems for
|
|
individual tag values is to extract/write to/from a separate text file and use a
|
|
UTF‑8 aware text editor to view/edit the text. For example:
|
|
|
|
<pre><span class=blk># extracting...</span>
|
|
exiftool image.jpg > out.txt
|
|
|
|
<span class=blk># writing...</span>
|
|
exiftool "-subject<=subject.txt" image.jpg</pre></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
|
|
display numeric values (<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...</blockquote>
|
|
|
|
<blockquote>The <code>-p</code> and <code>-tagsFromFile</code> options provide
|
|
an advanced translation feature that allows arbitrary Perl expressions to be
|
|
used to modify tag values. The basic syntax is this:
|
|
|
|
<pre>${TAG;EXPR}</pre>
|
|
|
|
where <code>TAG</code> is the tag name, and <code>EXPR</code> is a Perl
|
|
expression acting on the default input variable (<code>$_</code>), which is
|
|
initially the original value of the tag. For example, the following command
|
|
sets the FileName from Artist, translating spaces to underlines:
|
|
|
|
<pre>exiftool '-filename<${artist;tr/ /_/}.%e' image.jpg</pre>
|
|
|
|
(Note: Use single quotes as above in Mac/Linux, or double quotes instead
|
|
in Windows.)</blockquote>
|
|
|
|
<blockquote>Another technique is to create a user-defined Composite tag to do
|
|
the reformatting. Here is a basic config file that reformats the Artist tag to
|
|
provide a new MyArtist tag with the same character translation as the example
|
|
above:
|
|
|
|
<pre>%Image::ExifTool::UserDefined = (
|
|
'Image::ExifTool::Composite' => {
|
|
MyArtist => {
|
|
Require => 'Artist',
|
|
ValueConv => '$val =~ tr/ /_/; $val',
|
|
},
|
|
},
|
|
);
|
|
1; # end
|
|
</pre>
|
|
|
|
With this config file, 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>". <i class=lt>[An alternative is to load the
|
|
config file with the <code>-config</code> option -- see the
|
|
<a href="exiftool_pod.html#config-CFGFILE">application documentation</a>
|
|
for details.]</i></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="https://exiftool.org/forum/index.php?action=search2&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>20a. <b>"ExifTool won't write an image due to errors"</b>, or
|
|
<br>20b. <b>"How do I repair corrupted EXIF?"</b></p>
|
|
|
|
<blockquote>Minor errors may be ignored using the <code>-m</code> option
|
|
(<a href="#Q15">FAQ 15</a> discusses this with respect to MakerNote errors), but
|
|
sometimes there are more serious errors which can't be ignored. ExifTool may be
|
|
used to fix metadata 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 -icc_profile 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 updated 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. JPEG images
|
|
may also contain an ICC color profile which should be preserved. The
|
|
"<code>ICC_Profile</code>" tag is also marked as unsafe, but is not part of the
|
|
EXIF so it isn't covered by the "<code>Unsafe</code>" shortcut and must be
|
|
specified separately.</blockquote>
|
|
|
|
<blockquote>After repairing an image like this you should be able to write to it
|
|
without errors, but note that <u>some metadata from the original image may have
|
|
been lost in the process</u>.</blockquote>
|
|
|
|
<blockquote><b>Note</b>: ExifTool will not modify the JPEG image data, so if the
|
|
image itself is corrupted (eg. if you get a message saying "Not a valid JPEG"),
|
|
then ExifTool can not be used to repair the image. Also, ExifTool may not
|
|
be used like this to repair TIFF-based files or RAW files -- the risk of image
|
|
corruption is too great because the image is stored in the same IFD as the
|
|
metadata in these files.</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 (eg. "<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>), XML (<code>-X</code>) and PHP (<code>-php</code>) options
|
|
provide alternative output formats which preserve newlines in values.</blockquote>
|
|
|
|
<blockquote>Alternatively, the <a href="ExifTool.html#Filter">API Filter option</a>
|
|
may be used to apply an arbitrary filter to all extracted values. For example,
|
|
the following command changes newlines to "\n":
|
|
|
|
<pre>exiftool -api filter="s/\n/\\n/g" FILE</pre>
|
|
|
|
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>(Also, in Bourne shells the character sequence <code>$'\n'</code>
|
|
may be used for a newline.)</p>
|
|
<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>Use the <code>-ec</code> or <code>-E</code> option to allow C-style escape
|
|
sequences or HTML character entities (Note:
|
|
In Windows a newline is "<code>\r\n</code>" or "<code>&#xd;&#xa;</code>"
|
|
instead of just "<code>\n</code>" or "<code>&#xa;</code>"). For example,
|
|
using C-style escape sequences:
|
|
<pre>exiftool -ec "-comment=line 1\nline 2" image.jpg</pre>
|
|
or using HTML character entities:
|
|
<pre>exiftool -E "-comment=line 1&#xa;line 2" image.jpg</pre>
|
|
</li>
|
|
<li>Write the tag from the contents of a separate text file:
|
|
<pre>exiftool "-comment<=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. Also note that this technique
|
|
is slower since the implied <code>-tagsFromFile</code> adds an extra unnecessary
|
|
processing pass to read tags from the file, but most of this delay may be
|
|
avoided with the <code>-fast3</code> option.)
|
|
<pre>exiftool '-comment<line 1$/line 2' image.jpg
|
|
</pre></li>
|
|
<li>Use the "<code>#[CSTR]</code>" feature to allow C-style escape sequences
|
|
for a specific line in a <code>-@</code> argfile. For example, this command:
|
|
<pre>exiftool -@ test.args image.jpg</pre>
|
|
with this "test.args" file:
|
|
<pre>#[CSTR]-comment=line 1\nline 2</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 (ie. they are evaluated
|
|
left-to-right), but there are exceptions:
|
|
<ol><li>When writing list-type tags (eg. <code>-keywords=one</code>), new values
|
|
are accumulated rather than overriding earlier assignments.<br> </li>
|
|
<li>When copying values to list-type tags (eg.
|
|
<code>"-keywords<filename"</code>), subsequent copies to the same tag
|
|
override earlier operations with the exception that new values may be added to
|
|
the queued list if a leading <code>+</code> is added to the target tag name (eg.
|
|
<code>"-+keywords<filename"</code>).<br> </li>
|
|
<li>Tags copied with the <code>-tagsFromFile</code> option are assigned in
|
|
order, and all together at the point in the command line where the
|
|
<code>-tagsFromFile</code> option is located, regardless of whether these tags
|
|
are specified immediately after the <code>-tagsFromFile</code> option or later
|
|
on the command line. Remember that "<code>-tagsFromFile @</code>" is implied
|
|
unless another file is specified when redirecting information with arguments
|
|
like <code>"-DSTTAG<SRCTAG"</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<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 a few 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 metadata. See 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).
|
|
|
|
<ol start="3"><li>A time value is being shifted but the specified tag doesn't
|
|
exist.</li></ol>
|
|
|
|
For example, <code>-datetimeoriginal+=1</code> will have no effect unless
|
|
the DateTimeOriginal tag exists in the image.</blockquote>
|
|
|
|
<a name="Q24"></a>
|
|
<p>24. <b>"When I write a file the date/time gets reset to today's date"</b></p>
|
|
|
|
<blockquote>You should be aware of the difference between date/time values
|
|
stored in the metadata of the file itself and date/time values stored in the
|
|
filesystem (ie. in the disk directory information). A command like this may be
|
|
used to extract all date/time information with an indication of where it is
|
|
stored:
|
|
|
|
<pre>exiftool -time:all -a -G0:1 -s c:\images\test.jpg</pre>
|
|
|
|
and should give an output something like this:
|
|
|
|
<pre>[File:System] FileModifyDate : 2009:10:05 20:40:36-04:00
|
|
[File:System] FileAccessDate : 2009:10:07 09:22:12-04:00
|
|
[File:System] FileCreateDate : 2009:10:05 20:40:36-04:00
|
|
[EXIF:IFD0] ModifyDate : 2003:10:31 15:44:19
|
|
[EXIF:ExifIFD] DateTimeOriginal : 2003:10:31 15:44:19
|
|
[EXIF:ExifIFD] CreateDate : 2003:10:31 15:44:19</pre>
|
|
|
|
The <code>-G0:1</code> option causes the family 0 and 1 group names to be
|
|
reported in square brackets for each tag. Tags labelled "<b>File:System</b>"
|
|
are "<b>pseudo</b>" tags stored in the filesystem, while the others are real
|
|
tags stored in the metadata of the file.</blockquote>
|
|
|
|
<blockquote>ExifTool's <b>default behaviour is to set all filesystem times to
|
|
the current date/time when any "real" tag is written</b>, but the
|
|
<code>-P</code> option may be used to preserve the original FileModifyDate.
|
|
FileAccessDate represents the time the file was last accessed, and is set to the
|
|
current date/time whenever any software (including ExifTool) accesses the
|
|
file.</blockquote>
|
|
|
|
<blockquote>On systems where a filesystem creation date is maintained, ExifTool
|
|
also sets this to the current date/time when the file is edited. On Windows the
|
|
creation date is readable/writable through the FileCreateDate tag (see the
|
|
<a href="TagNames/Extra.html">Extra Tags documentation</a>), and is preserved
|
|
with the <code>-P</code> option. On MacOS, FileCreateDate is available but
|
|
extracted only if specified explicitly, and is writable only if "setfile" is
|
|
available. The <code>-P</code> option does not preserve the creation date when
|
|
editing a file on Mac systems, but the <code>-overwrite_original_in_place</code>
|
|
option may be used to preserve all Finder information including the creation
|
|
date, or the FileCreateDate may be copied back specifically (ie.
|
|
<code>-tagsfromfile @ -FileCreateDate</code>). On Linux, the file creation date
|
|
is not stored.</blockquote>
|
|
|
|
<blockquote>For example, commands like this act on common metadata tags, setting
|
|
the filesystem modification date/time to the current date/time:
|
|
|
|
<pre><span class='blk'># common metadata date/time tags are incremented by 1 hour, while
|
|
# FileModifyDate is set to the current date/time</span>
|
|
exiftool -alldates+=1 c:\images</pre>
|
|
|
|
<i class=lt>[The AllDates tag is a shortcut which represents the 3 common
|
|
metadata date/time tags: DateTimeOriginal, CreateDate and
|
|
ModifyDate.]</i></blockquote>
|
|
|
|
<blockquote>However, FileModifyDate may be preserved with the <code>-P</code>
|
|
option:
|
|
|
|
<pre><span class='blk'># FileModifyDate is not changed</span>
|
|
exiftool -alldates+=1 -P c:\images</pre>
|
|
|
|
ExifTool also allows FileModifyDate to be written, which provides full control
|
|
over the filesystem modification date/time when writing:
|
|
|
|
<pre><span class='blk'># FileModifyDate is incremented by 1 hour</span>
|
|
exiftool -alldates+=1 -filemodifydate+=1 c:\images
|
|
|
|
<span class='blk'># FileModifyDate is set from the value of DateTimeOriginal
|
|
# (before DateTimeOriginal is incremented by 1 hour)</span>
|
|
exiftool -alldates+=1 "-filemodifydate<datetimeoriginal" c:\images
|
|
</pre></blockquote>
|
|
|
|
<a name="Q25"></a>
|
|
<p>25. <b>"Can ExifTool be used as an image validator?"</b></p>
|
|
|
|
<blockquote>ExifTool is not designed as an image validator but it does have a
|
|
<code>-validate</code> feature which enables extra validation checks, mainly for
|
|
JPEG and TIFF-format images (officially released in version 10.97, May 2018,
|
|
but continually being improved). Here is an example command to apply these
|
|
validation checks to a JPEG image:
|
|
|
|
<pre>exiftool -validate -warning -error -a test.jpg</pre>
|
|
|
|
Note there are other packages specifically designed for file validation, for
|
|
example: <a href="https://github.com/openpreserve/jhove">JHOVE</a>.</blockquote>
|
|
|
|
<a name="Q26"></a>
|
|
<p>26. <b>"How do I import information from a database?"</b></p>
|
|
|
|
<blockquote><i>[See <a href="#Q12">FAQ number 12</a> for help with the reverse
|
|
-- exporting metadata to a database.]</i></blockquote>
|
|
|
|
<blockquote>ExifTool has the ability to import metadata from CSV and JSON format
|
|
database files for writing to output image files. For example, the following
|
|
commands use imported metadata to write to all image files in a directory.
|
|
|
|
<pre><span class='blk'># import from CSV file</span>
|
|
exiftool -csv="c:\Users\Phil\test.csv" "c:\Users\Phil\Images"
|
|
|
|
<span class='blk'># import from JSON file</span>
|
|
exiftool -json="c:\Users\Phil\test.json" "c:\Users\Phil\Images"</pre>
|
|
|
|
For the above commands, the input CSV or JSON file must have the same format as
|
|
the output from these commands:
|
|
|
|
<pre><span class='blk'># export to CSV file</span>
|
|
exiftool -csv "c:\Users\Phil\Images" > "c:\Users\Phil\test.csv"
|
|
|
|
<span class='blk'># export to JSON file</span>
|
|
exiftool -json "c:\Users\Phil\Images" > "c:\Users\Phil\test.json"</pre>
|
|
|
|
Specifically, the first row of the CSV file must contain the tag names.
|
|
The first column must be a special "SourceFile" column, containing the names of
|
|
the associated image files, with paths specified in the same way as on the
|
|
command line. The JSON file contains similar entries, but is not structured in
|
|
row/column format.</blockquote>
|
|
|
|
<blockquote>For each image file specified on the command line, all tags for the
|
|
database entry with the corresponding SourceFile name are written (with the
|
|
exception of the FileName and Directory tags, which are ignored). A special
|
|
SourceFile name of "*" may be used to match any image file. A warning is issued
|
|
and nothing is written if a specified file does not match any SourceFile entry
|
|
in the database.</blockquote>
|
|
|
|
<blockquote>Tag names may be prefixed by a group name to write to a specific
|
|
group (using the same format as when <code>-G</code> or <code>-G1</code> is
|
|
added to the export command). To delete a tag, set the tag value to "-" (or the
|
|
<a href="ExifTool.html#MissingTagValue">MissingTagValue</a> if this API option
|
|
was used) and use the <code>-f</code> option when importing. Tags with an empty
|
|
value are ignored in a CSV import, or set to an empty string in a JSON import
|
|
(unless <code>-f</code> is used and the
|
|
<a href="ExifTool.html#MissingTagValue">API MissingTagValue option</a> is set to
|
|
an empty string, in which case the tag is deleted).</blockquote>
|
|
|
|
<blockquote>See the <code>-csv</code> or <code>-j</code> option in the
|
|
<a href="exiftool_pod.html#input_output_text_formatting">application documentation</a>
|
|
for more details.</blockquote>
|
|
|
|
<a name="Q27"></a>
|
|
<p>27. <b>"My ExifTool command doesn't work from a Windows .BAT file"</b></p>
|
|
|
|
<blockquote>In a Windows .BAT file the "<code>%</code>" character is
|
|
significant, so all "<code>%</code>" characters in ExifTool commands must be
|
|
changed to "<code>%%</code>". For example, this command line:
|
|
|
|
<pre>exiftool "-FileName<CreateDate" -d "%Y%m%d_%H%M%S.%%e" image.jpg</pre>
|
|
|
|
must be changed to this in a .BAT file:
|
|
|
|
<pre>exiftool "-FileName<CreateDate" -d "%%Y%%m%%d_%%H%%M%%S.%%%%e" image.jpg</pre>
|
|
</blockquote>
|
|
|
|
<a name="Q28"></a>
|
|
<p>28. <b>"How do I copy a shifted date/time value?"</b></p>
|
|
|
|
<blockquote>The <code>-TAG+=</code> and <code>-TAG-=</code> arguments always act
|
|
on the <b>existing</b> tag value, so they can not be used to shift a <b>new</b>
|
|
tag value without running a second command. For example, this is <b>wrong</b>
|
|
because the copy operation is superseded by the shift, and the result is that
|
|
the existing DateTimeOriginal is shifted back by two hours:
|
|
|
|
<pre>exiftool "-datetimeoriginal<filemodifydate" -datetimeoriginal-=2 image.jpg <i class=blk>(WRONG!)</i>
|
|
</pre>
|
|
|
|
The <code>-globalTimeShift</code> option fills this niche -- it shifts all
|
|
date/time tags by the specified amount when reading or copying, allowing a
|
|
shifted date/time value to be copied to another tag. So this is the proper
|
|
technique for shifting a date/time value when copying:
|
|
|
|
<pre>exiftool "-datetimeoriginal<filemodifydate" -globaltimeshift -2 image.jpg</pre>
|
|
|
|
An alternative is to use the ShiftTime function of the
|
|
<a href="exiftool_pod.html#Advanced-formatting-feature">advanced formatting feature</a>:
|
|
|
|
<pre>exiftool '-datetimeoriginal<${filemodifydate;ShiftTime("-2")}' image.jpg</pre>
|
|
|
|
(Note: Swap the single and double quotes when running this command under Windows.)
|
|
</blockquote><blockquote class=prog>
|
|
<b>Programmers</b>: Here are the equivalent ExifTool API function calls:
|
|
<pre><span class='blk'># using the GlobalTimeShift option</span>
|
|
$exiftool->Options(GlobalTimeShift => '-2');
|
|
$exifTool->SetNewValuesFromFile($src, 'datetimeoriginal<filemodifydate');
|
|
|
|
<span class='blk'># using ShiftTime in an advanced formatting expression</span>
|
|
$exifTool->SetNewValuesFromFile($src, 'datetimeoriginal<${filemodifydate;ShiftTime("-2")}');</pre>
|
|
</blockquote>
|
|
|
|
<a name="Q29"></a>
|
|
<p>29. <b>"My options don't work in a <code>-@</code> ARGFILE"</b></p>
|
|
|
|
<blockquote>The ExifTool application has the ability to read options from an
|
|
ARGFILE using the <code>-@</code> option. The parsing of these arguments is
|
|
different from the command line. Arguments in this file are separated by
|
|
newline characters instead of spaces. Also, arguments should not be quoted.
|
|
For example, on the command line you may have:
|
|
|
|
<pre>-d "%Y:%m:%d %H:%M:%S"</pre>
|
|
|
|
but in an ARGFILE, this should be
|
|
|
|
<pre>-d
|
|
%Y:%m:%d %H:%M:%S</pre></blockquote>
|
|
|
|
<a name="Q30"></a>
|
|
<p>30. <b>"How do I extract absolutely all metadata from a file?"</b></p>
|
|
|
|
<blockquote>By default, duplicate tags, unknown tags, embedded tags, and System
|
|
tags that require external utilities are not extracted. The main reason for
|
|
this is performance; extracting these tags will significantly increase
|
|
processing time for some files. The following command extracts everything
|
|
possible with ExifTool:
|
|
|
|
<pre>exiftool -ee3 -U -G3:1 -api requestall=3 -api largefilesupport FILE</pre>
|
|
|
|
(The <code>-G3:1</code> option is included in the above command only to give an
|
|
indication of where the metadata was stored.)</blockquote>
|
|
|
|
<a name="Q31"></a>
|
|
<p>31. <b>"Why does ExifTool rewrite the entire file when I am only changing one small thing?"</b></p>
|
|
|
|
<blockquote>Generally it is possible in theory to edit existing fixed-length tags without having to rewrite an entire file, but ExifTool doesn't do this for 3 reasons:
|
|
|
|
<ol>
|
|
<li>The algorithm to do this would be completely different than the more general
|
|
and powerful case where you want to be able to add/delete tags and/or write
|
|
values with different lengths. Plus, implementing this feature would be a lot
|
|
of work, and it would only be useful in certain situations.</li>
|
|
<li>Some file formats (like MP4) allow metadata to be written at the beginning
|
|
or the end of a file. Writing it at the end of the file could avoid the need to
|
|
rewrite the entire starting section, but metadata is more useful at the start of
|
|
a file because then other programs (especially ones that stream the file over
|
|
the internet) don't have to read through the entire file to find the metadata.
|
|
Also, some software won't read metadata that comes at the end of a file
|
|
(probably for this reason).</li>
|
|
<li>ExifTool is designed to allow files to be read/written via pipes, which are
|
|
not seekable, so in-place editing is not possible with these files and again,
|
|
like 1, two completely different algorithms would be required.</li>
|
|
</ol></blockquote>
|
|
|
|
<a name="Q32"></a>
|
|
<p>32. <b>"How do I safely delete all metadata from a file?"</b></p>
|
|
|
|
<blockquote>First of all, all metadata shouldn't be removed from some file types
|
|
(such as RAW images) because this information is necessary for display of the
|
|
image. JPEG is the most popular image format and most suited to erasing all
|
|
metadata because the image and metadata are well separated in this format.
|
|
However, even with JPEG images care should be taken because the metadata
|
|
may contain color space information which should be maintained to preserve the
|
|
color rendition.</blockquote>
|
|
|
|
<blockquote>Here is a command that may be used to safely delete all metadata
|
|
from .JPG images in a directory:
|
|
|
|
<pre>exiftool -ext jpg -all= --icc_profile:all -tagsfromfile @ -colorspacetags DIR</pre>
|
|
|
|
This command deletes all metadata except the ICC Profile if it exists, then
|
|
copies back any EXIF color space tags (adding any mandatory EXIF tags using
|
|
default values if necessary).
|
|
</blockquote>
|
|
|
|
<hr>
|
|
<i>Last revised Jun 12, 2023</i>
|
|
<p class='lf'><a href="index.html"><-- Back to ExifTool home page</a></p>
|
|
</body>
|
|
</html>
|