view release on metacpan or  search on metacpan

html/standards.html  view on Meta::CPAN

of absolute offsets.  This would have been a good idea if the IFD was stored as
the value of an UNDEFINED tag rather than referenced from a LONG offset. (If
done this way, the new information would have been preserved if the file was
rewritten by unaware software.) But as implemented it just adds to the pain of
parsing the file by requiring even more specialized code to be written in
support of the DNG 1.3 format.</p>

<p><b>A simple solution:</b></p>

<p>Sack the Adobe developers who were responsible for this, and use field type
13 (as recommended above for TIFF 6.0) and a standard TIFF IFD structure when
adding new IFD's in the future.</p>

<a name="EXIF"></a>
<h3>EXIF 2.3 <a class=ref href="#ref4">[4]</a></h3>

<p>The EXIF specification has been the standard for digital camera metadata for
many years, and while the digital camera technology has advanced significantly
in these years, the EXIF specification has not.  There are a number of
significant problems with the EXIF specification which have never been
addressed.</p>

<p>Some current problems with the EXIF specification are:</p>

<ol>
<li>Maker note data structure has no restrictions and is easily invalidated when
editing EXIF.</li>
<li>No facility for storing the time zone for date/time values. <i>[finally
added to Exif 2.31 spec.]</i></li>
<li>Very limited support for alternate character sets (essentially only the
UserComment tag has this feature).</li>
<li>No alternate language support.</li>
<li>Byte ordering for "Unicode" text strings, and the meaning of "Unicode"
itself is not clearly specified.</li>
<li>Mandatory tags are unnecessary and painful to implement.</li>
<li>ApertureValue and MaxApertureValue are stored as unsigned RATIONAL, which
means that lenses with F numbers faster than 1.0 (with equivalent APEX values of
less than zero) can not be represented.</li>
<li>MaxApertureValue is defined as "The smallest F number of the lens".  This
definition is unclear in the case of zoom lenses where the maximum aperture
varies across the zoom range.  Some manufacturers (Canon, Nikon, Sony) store the
maximum aperture at the specific focal length, but others (Olympus, Pentax)
store the absolute maximum aperture of the lens.</li>
<li>EXIF is not extensible, and is missing definitions for storing some
information that could be very useful to camera owners (eg. camera pitch/roll
angles, sensor temperature, face detection, auto-focus points, image
stabilization, flash exposure compensation, etc). <i>[Some of these tags
were added in the Exif 2.31 specification.]</i></li>
<li>0xffffffff in the numerator or denominator of some rational-value tags is
used to indicate an unknown or infinite value. This is completely unnecessary
and not supported by many applications because it requires extra tag-specific
logic to be implemented.</li>
<li>The total size of EXIF metadata in JPEG images is limited to 65527 bytes
or less.</li>
</ol>

<p><b>Simple solutions:</b></p>

<ol>
<li>Specify that maker note data must be self-contained (ie. must not exceed the
bounds of the maker note value data), and must be relocatable (ie. must not use
absolute offsets).  <i>[I would have suggested defining a new maker note tag
with field type 13 (IFD) which references a standard format IFD, but I am afraid
that no camera maker would ever jump on board with this suggestion now that they
have already been seduced by the dark side.]</i></li>
<li>Change the specification to allow an optional time zone of the format
"-05:00" to be appended to the date/time string values.</li>
<li>Change the specification to allow UTF-8 in ASCII-type values as recommended
by the MWG<a class=ref href="#ref5">[5]</a>.</li>
<li>No simple solution for this.  XMP<a class=ref href="#ref6">[6]</a>
is the only reasonable alternative if alternate language support is
required.</li>
<li>Specify that the Unicode byte order must be the same as the EXIF byte
ordering. (This is the only reasonable choice, but for some reason both
Microsoft and Apple seem to write Unicode using the native processor byte
ordering. regardless of the EXIF byte order.)  Also, it should be made clear
that by "Unicode" the EXIF specification actually means UCS-2, although updating
this to allow UTF-16 surrogate pairs may be a good idea.</li>
<li>Define reasonable fallback values for required tags which are missing.</li>
<li>Allow ApertureValue and MaxApertureValue to be stored as signed SRATIONAL.</li>
<li>Define whether MaxApertureValue is taken at the current focal length of
a zoom lens, or over the entire zoom range.</li>
<li>Expand the standard to include additional useful information available from
modern digital cameras.</li>
<li>Use a rational value of 1/0 to indicate infinity, and 0/0 to indicate an
unknown/undefined value.</li>
<li>Allow EXIF to span multiple JPEG segments.  Multiple consecutive EXIF
segments are simply concatenated into a single data block when reading. 
<i>[Apparently Adobe has been doing this for years<a class=ref href="#ref11">[11]</a>,
and this ability was added to ExifTool in version 10.97.]</i></li>
</ol>

<a name="PhotoInfo"></a>
<h3>Microsoft "OffsetSchema" Tag <a class=ref href="#ref7">[7]</a></h3>

<p>In February 2007 Microsoft proposed a new PhotoInfo tag called "OffsetSchema"
(hex. 0xEA1D, dec. 59933) in an attempt to patch a deficiency in the EXIF maker
note specification (see point 1 in EXIF 2.2 section above).  This tag represents
the offset difference between the original maker note location in the EXIF and
the new location after editing, and is designed to allow the maker note tag
values to be accessed after the location of the maker notes is changed by
editing the EXIF. <i>[Bless their little hearts for trying to improve this
situation, but while the idea is good the implementation is flawed and
ultimately unworkable.]</i></p>

<p>There are two main problems with the implementation, and the second is a show
stopper:</p>

<blockquote>1. For this new tag to be available to a single-pass metadata reader, it
must come <i>before</i> the maker note data (hex. 0x927C, dec. 37500).  But
since the EXIF/TIFF format specifies that tags must be stored in numerical
order, the maker note tag (hex. 0x927C) comes before the OffsetSchema tag
(hex. 0xEA1D).</blockquote>

<blockquote>2. The OffsetSchema tag will be invalidated by any software that
rewrites the EXIF and moves the maker notes without properly updating the tag.
In an ideal world all application developers would release an updated version
of their software which treats the OffsetSchema properly, and all users would
update to this new version.  But since this is the real world it just won't
happen, which makes the value of OffsetSchema unreliable.  Too bad, because this
wouldn't have been a problem if Microsoft had specified that the new tag