Gecko [ fernandoquevedodop.com ]

Name	Size	Permission
TagNames	[ DIR ]	drwxr-xr-x
ExifTool.html	127.58 KB	-rw-r--r--
MIE1.1-20070121.pdf	125.73 KB	-rw-r--r--
Shift.html	8.64 KB	-rw-r--r--
ancient_history.html	484.67 KB	-rw-r--r--
canon_raw.html	24.78 KB	-rw-r--r--
commentary.html	16.6 KB	-rw-r--r--
config.html	18.76 KB	-rw-r--r--
data_members.html	15.82 KB	-rw-r--r--
exiftool_pod.html	154.57 KB	-rw-r--r--
faq.html	86.68 KB	-rw-r--r--
filename.html	20.1 KB	-rw-r--r--
geotag.html	32.45 KB	-rw-r--r--
history.html	14 KB	-rw-r--r--
htmldump.html	39.47 KB	-rw-r--r--
idiosyncracies.html	16.5 KB	-rw-r--r--
index.html	128.39 KB	-rw-r--r--
install.html	13.67 KB	-rw-r--r--
metafiles.html	15.92 KB	-rw-r--r--
mistakes.html	7.47 KB	-rw-r--r--
overview.png	23.19 KB	-rw-r--r--
standards.html	16.42 KB	-rw-r--r--
struct.html	18.99 KB	-rw-r--r--
style.css	1.15 KB	-rw-r--r--
under.html	8.8 KB	-rw-r--r--
verbose.html	8.11 KB	-rw-r--r--
writing.html	13.08 KB	-rw-r--r--

Code Editor : idiosyncracies.html

<!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>

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.

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).

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!)

<blockquote>Technical aside:
 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.</blockquote>

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.

<hr>

<a name="Canon">Canon:</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.

<a name="Casio">Casio:</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.

<a name="Concord">Concord:</a> Some models write PrintIM information with an entry-based
offset like Casio.

<a name="GE">General Electric:</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).

<a name="HP">Hewlett-Packard:</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).

<a name="Kodak">Kodak:</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).

<a name="Konica">Konica:</a> The KD-300Z writes all maker notes offsets relative to the
start of the individual IFD entry.

<a name="Kyocera">Kyocera:</a> A number of models write all maker notes offsets relative
to the start of the individual IFD entry.

<a name="Leica">Leica:</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.

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
notes.) In DNG images, the M8 uses maker note offsets relative to the
start of the maker notes in JPEG images (very reasonable), but relative to
the end of the maker note header in DNG images. I think this was a mistake
because this is changed in M9 DNG images to be the same as JPEG images.

2010-02-20: The Leica S2 maker note format is the MOST idiotic I have seen, and has the
following peculiarities:

<ul>
<li>It is stored as a trailer after the JPEG EOI (but referenced from a pointer
inside the APP1 EXIF segment).</li>
<li>Most of the offsets in this MakerNote IFD are relative to the start of the
file instead of the EXIF TIFF header (which is particularly cruel because they
are broken if other software simply adds a leading JFIF segment, but there is no
simple way to detect that this has happened. Normally this could be detected by
analyzing the pointers, but this doesn't work here because all of the unused
data in the Leica maker notes make normal pointer assumptions impossible).</li>
<li>The PreviewImage offset is relative to the start of the MakerNote data
(which is MUCH more reasonable, but using two different offset bases in the same
directory is yet another level of idiocy).</li>
<li>In DNG images the maker notes use an absolute base offset. Yet again
different from the M8 and M9. Consistency isn't Leica's strong suit.</li>
</ul>

2013-07-27: Strike that. The most idiotic award now goes to the Leica M (Typ 240), which
adds these quirks (firmware 1.1.0.2):

<ul>
<li>Tag 0x0301 has the same offset as the PreviewImage in the maker note IFD,
although it looks like the data for this tag probably comes after the
PreviewImage.</li>
<li>Tag 0x0302 has an invalid offset (0xffffffff).</li>
</ul>

2015-09-03: OK, I give up on Leica. The new Leica S (Typ 007) attains a new level of
stupidity by storing the preview image in the JPG file using a completely
nonsensical technique (in IFD2 of the EXIF segment, with the data being stored
outside the EXIF segment after the JPEG EOI), as well as various other brainless
blunders. [@Leica: Try reading the MPF specification.]

<a name="Minolta">Minolta:</a> An obvious bug in the firmware of the Z2 writes an incorrect
offset for the 'MinoltaCameraSettings2' information -- it writes the offset of
the offset itself instead of the offset of the value (hahaha!). Other
offsets are correct.

<a name="Nikon">Nikon:</a> D2H NEF files have huge blocks with all zero data (3.7 MB in
my test file!).

<a name="Olympus">Olympus:</a> The E-1 and E-300 have subdirectories in the maker notes, but
not only does the data size of these subdirectories exclude the subdirectory
value data, but also it is 2 bytes too small for the directory information
itself (doh! -- they forgot to include the entry count). Similarly, the stored
size of the maker note data block is too small for many models, which results
in a loss of data if the maker notes are copied as a block when an image is
rewritten.

<a name="Pentax">Pentax:</a> The Optio 330 uses an offset for the PrintIM information which
is relative to the start of the IFD entry (hmmm, like some Casio models...). 
Also, preview image offsets in the maker notes are given relative to the EXIF
base rather than the maker note base (like all other maker notes offsets).

The Optio 550, 555, 33WR and 43WR all specify a PrintIM directory at a the
same offset of 0x29a with length 40 bytes, but the only PrintIM information in
the file is nowhere near that offset and is 128 bytes long. Also for these
models, tag 0x002e has a constant value of 0x6a6 even though its position
changes. Finally, all of these models plus the Optio WP waste many kilobytes of
space in each image with large unused data blocks in the EXIF information.

The Optio 330RS and 430RS double reference the preview image information.

Note that the worst problems are with the Optio 230, 330, and 430, which
carry the Asahi brand name.

<a name="Photoshop">Photoshop and Nikon Capture:</a> Both of these packages write TIFF IPTC
information as 'int32u' (or 'LONG'). This is wrong
(<a href="http://www.awaresystems.be/imaging/tiff/tifftags/iptc.html">see
reference</a>). Nikon Capture goes one step further and simply ignores IPTC
that is written correctly as 'undef' or 'int8u'. (So for compatibility,
ExifTool also writes this incorrectly as 'int32u'.) Photoshop completely
deletes the maker notes when an image is edited.

<a name="Ricoh">Ricoh:</a> There is an IFD subdirectory in the Ricoh maker notes of both the
Caplio RR30 and RR1. The RR30 uses standard EXIF offsets (relative to the start
of the EXIF data), but for the RR1 the offsets are relative to the start of the
subdirectory. The G700 uses MPF offsets relative to the start of the file,
instead of the start of the MPF segment as per the MPF spec. The HX15 uses
a standard EXIF maker note structure, but there are 2 extra padding bytes
between the IFD entry count and the 1st IFD entry. The HZ15 and Pentax XG-1 (by
Ricoh) both have an extra 2 bytes after the IFD entry counts. All value offsets
are erroneously 0 for the HZ15, and there are other problems with the offsets
stored by the XG-1.

<a name="Rollei">Rollei:</a> The DK4010 writes all maker notes offsets relative to the
start of the individual IFD entry.

<a name="Sanyo">Sanyo:</a> The offsets written in the maker notes of the J1, J2, J3, S1,
S3 and S4 have very little to do with reality. Apparently the Sanyo
programmers have no understanding of the concept of an IFD offset.

<a name="Skanhex">Skanhex:</a> With some Skanhex models (SX-210Z3, SX-330Z3, SX3300,
SX410Z3), the 264-byte makernotes block contains no useful information, and
overlaps values from the ExifIFD. For these models there is also a large block
(typically 1195 bytes) of unreferenced information in the EXIF data immediately
following the IteropIFD. This block begins with the character sequence
"SKANH\0", and contains exactly the same information in all 20 of my sample
images that contain this block (except for a variable amount of padding at the
end with 0xff bytes). These quirks also affect some Gateway, Jenoptik, Medion,
Samsung and Yakumo models built by Skanhex.

<a name="Toshiba">Toshiba:</a> The PDR-3310 writes all maker notes offsets relative to the
start of the individual IFD entry. (very similar to Konica KD-300Z)

<hr><a name="raw"></a>
<h2>RAW file Idiosyncrasies</h2>

<a name="MinoltaMRW">Minolta MRW:</a> The A200 stores the thumbnail image offset in IFD0
relative to the start of file, while all other offsets are relative to the start
of the TIFF header, which is 48 bytes into the file. Also, the A200 stores the
StripOffsets and the StripByteCounts values in the wrong byte order.

<a name="SonyARW">Sony ARW:</a> The maker notes of ARW images are not self-contained, so
some information is lost when the images are rewritten by other software
(including the Adobe DNG converter). The A100 with firmware 1.00 sets the high
word of the thumbnail image offset to zero, but it should sometimes be 0x0001.
(This problem is fixed for firmware 1.01.) Also with the A100, the
JpgFromRawLength stored in IFD0 may be wrong (although this value is also stored
in the MakerNotes and is correct here). As well, much information in these
images is encrypted, which complicates things somewhat. Even the Sony IDC
utility can't properly rewrite ARW files -- it corrupts the embedded MRW record
when used to edit ARW images. Even funnier: IDC v3.0 will crash when loading
some original A100 firmware 1.00 images, but no longer crashes if the images are
first edited with ExifTool (probably because ExifTool fixes the above mentioned
problems when it rewrites the image).

<a name="HasselbladFFF">Hasselblad FFF:</a> Many Hasselblad camera models
write TIFF-format FFF raw files which contain a double-referenced
reduced-resolution image that is referenced from both IFD0 and IFD1.Immediately
following the data for this image is an unreferenced data block that the
Hasselblad Phocus software uses for an updated preview to reflect the raw
development settings. This unreferenced data is lost if the FFF file is edited
using a TIFF-compatible algorithm, which results in the Phocus no longer
updating the preview when the settings are changed.

<a name="LeicaDNG">Leica DNG:</a> The makernote offsets for the M8 are relative to the start
of the makernote IFD in JPEG images, but relative to the start of the makernote
header (8 bytes earlier) in DNG images. [2009-09-09: This is fixed for the
M9 which has offsets relative to the start of the makernote header for both JPEG
and DNG.]

<a name="NikonNEF">Nikon NEF:</a> Aside from the encryption that Nikon uses to try to hide
some information in their maker notes, the NEF files in general seem fairly well
behaved. Even so, the Nikon Transfer utility (version 1.3) still manages to
corrupt some information in the 0th SubIFD when it is used to process NEF
images. (Beware that other Nikon utilities may have this same problem if they
use the same NEF writing routines.) But luckly the lost information isn't very
important. (Only a few tags from the embedded full-sized preview image are
lost: XResolution, YResolution and YCbCrPositioning.) Also, Nikon Transfer and
Nikon Capture both write an incorrect size for the maker notes, which could
cause loss of MakerNote information if the file is edited by other software (but
this isn't a problem with ExifTool, which will fix this type of problem
automatically when writing).

<a name="NikonNRW">Nikon NRW:</a> Nikon should have just called this NEF with a different
version number -- there should be no need to pollute the universe with zillions
of unnecessary file extensions. Oh right, they weren't smart enough to include
a file identifier containing a version number in their NEF images -- Doh! In
these images, CFAPattern2 is written incorrectly with UNDEFINED instead of BYTE
format.

<a name="PhaseOneIIQ">Phase One IIQ:</a> Many values are referenced from more than one location
in the TIFF structure of these images. For instance, the IFD0 strip data
actually exists within the MakerNotes data block. This is a poor design, and
leads to duplicated information when the image is rewritten.

<a name="RicohDNG">Ricoh DNG:</a> The GR Digital IV (firmware 1.14) stores an incorrect
length for the JPEG preview in SubIFD1.

<a name="SamsungSRW">Samsung SRW:</a> Yet another TIFF-based raw image with no proper file
identifier. In these images the thumbnail is stored inside a SubIFD of IFD1
instead of directly in IFD1 (dumb, dumb...). Also, the NX200 (firmware
NX200_011181) uses a base offset for the X/YResolution values that is different
from the PreviewImageStart pointer, both in the MakerNotes PreviewIFD. (Note
that the NX100 uses the same base for both, so this is certainly a firmware bug
for the NX200. [2012-06-21: This problem now also affects the EX1, NX20 and
WB2000] [2013-07-25: Add the NX2000 to this list])

<a name="GN120">2018-04-30: The Samsung EK-GN120</a> has many
problems in the makernote offsets. Most of the offsets are based on the start of
the maker notes, but the PreviewIFD is offset is wrong by 36 bytes, and some
offsets in the PreviewIFD are based on the start of the maker notes while others
are absolute. What a mess!

<hr>
Created Mar. 25, 2005
 Last revised Feb. 24, 2020
<a href="index.html">&lt;-- Back to ExifTool home page</a>
</body>
</html>

${this.title}

Code Editor : idiosyncracies.html