Image-ExifTool
view release on metacpan or search on metacpan
html/idiosyncracies.html view on Meta::CPAN
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Maker Note Idio(t)syncrasies</title>
<link rel=stylesheet type='text/css' href='style.css' title='Style'>
</head>
<body>
<h1 class='up'>Maker Note Idio(t)syncrasies</h1>
<p>It really is surprising how stupid some (...many, ...most?) manufacturers
seem to be when it comes to writing what should be a fairly simple file
format.</p>
<p>One positive thing is that most manufacturers seem to have standardized on an
EXIF-like IFD (Image File Directory) structure for their maker notes. But many
problems arise because of a fundamental design flaw in the EXIF/TIFF format.
Values longer than 4 bytes are stored at a location referenced by an offset from
an absolute position in the file (where offset 0 is the start of the EXIF/TIFF
information).</p>
<p>The difficulty is that these offsets must be recalculated when a file is
rewritten, but in general this is not possible (particularly for the maker
notes) because the format of all information is not known. Some manufacturers
have attempted to avoid this problem using offsets which are relative to the
start of the maker note IFD instead of the usual start of EXIF. This is a good
idea if implemented properly, but this is not done consistently. (And some
manufacturers are not even consistent about how the offsets are calculated from
one camera model to the next!)</p>
<blockquote><font size='-1'><b>Technical aside:</b>
<br>If EXIF were designed properly, all offsets would
be relative to 4 bytes after the end of the IFD, which is the normal position
for values to be stored, and all value data for the IFD would be stored in a
block at this location. If this was done, an entire IFD could be relocated
easily without causing problems.</font></blockquote>
<p>Below is a list of idiosyncrasies in files written by the digital cameras or
software from various manufacturers. Many of these quirks relate to the offset
problem mentioned above.</p>
<hr>
<p><a name="Canon"><b>Canon:</b></a> The 350D (firmware 1.0.1) gets the size of the thumbnail image
wrong and reports it to be 10 bytes too long. This can cause the reported
thumbnail image data to run off the end of the APP1 segment. A bug in version
1.0.4 of the 40D firmware causes it to write a maker note entry count that is
one greater than it should be.</p>
<p><a name="Casio"><b>Casio:</b></a> The preview image is referenced by two different offsets (the
PreviewImage tag plus a PreviewImageStart/PreviewImageLength pair). Also, the
offset for the PrintIM information is relative to the start of the IFD entry
even though other offsets aren't.</p>
<p><a name="Concord"><b>Concord:</b></a> Some models write PrintIM information with an entry-based
offset like Casio.</p>
<p><a name="GE"><b>General Electric:</b></a> A number of GE cameras store zero offsets for some
maker note tags (possibly to indicate that the tags do not exist), and other
offsets are 12 bytes too high for some models (like the A1230, E1035 and G2).
</p>
<p><a name="HP"><b>Hewlett-Packard:</b></a> The PhotoSmart 720 (one of the few HP models to use
EXIF-format maker notes) uses a format code of 5 (rational64u) for tag 0x0204,
but stores a rational32u value. Other models show about as much standardization
as the Kodak point-and-shoot lineup. Also, some models (C945, M22, M23, R507,
R607, R707, R717, R725, R727, R817, R818, R827, R927 and R960) write the EXIF
ComponentsConfiguration incorrectly as ASCII characters (like the Leica M8 and
M9).</p>
<p><a name="Kodak"><b>Kodak:</b></a> Professional DCS Photo Desk software writes a cyclical EXIF
directory such that the InteropIFD pointer points back to IFD0.
Point-and-shoot models show little standardization in maker note format.
Some models with IFD-format maker notes store incorrect count values for
a number of tags (this is particularly nasty), and may contain blank IFD
entries which are filled with 0xff's (not zeros like other makes).</p>
<p><a name="Konica"><b>Konica:</b></a> The KD-300Z writes all maker notes offsets relative to the
start of the individual IFD entry.</p>
<p><a name="Kyocera"><b>Kyocera:</b></a> A number of models write all maker notes offsets relative
to the start of the individual IFD entry.</p>
<p><a name="Leica"><b>Leica:</b></a> Leica is hands-down the most inconsistent
company when it comes to writing makernote information. Various models use
different signatures and different bases for the offsets for the maker notes. As
well as this, they do a number of really peculiar things with in their
metadata.</p>
<p>The M8 and M9 write the EXIF ComponentsConfiguration value in
ASCII instead of binary. The M8 writes EXIF ExposureCompensation and
ShutterSpeedValue incorrectly as a unsigned rationals when they should be
signed. This leads to crazy values like "+65536" for small negative exposure
compensations, and "0 s" for long exposure times. (NOTE: These are all EXIF
idiosyncrasies since the values are in the standard EXIF, not the maker
( run in 0.491 second using v1.01-cache-2.11-cpan-71847e10f99 )