Image-ExifTool

 view release on metacpan or  search on metacpan

html/idiosyncracies.html  view on Meta::CPAN

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

html/standards.html  view on Meta::CPAN

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

lib/Image/ExifTool/EXE.pm  view on Meta::CPAN

        #   4 int16u     cp       - Pages in file
        #   6 int16u     crlc     - Relocations
        #   8 int16u     cparhdr  - Size of header in paragraphs
        #  10 int16u     minalloc - Minimum extra paragraphs needed
        #  12 int16u     maxalloc - Maximum extra paragraphs needed
        #  14 int16u     ss       - Initial (relative) SS value
        #  16 int16u     sp       - Initial SP value
        #  18 int16u     csum     - Checksum
        #  20 int16u     ip       - Initial IP value
        #  22 int16u     cs       - Initial (relative) CS value
        #  24 int16u     lfarlc   - Address of relocation table
        #  26 int16u     ovno     - Overlay number
        #  28 int16u[4]  res      - Reserved words
        #  36 int16u     oemid    - OEM identifier (for oeminfo)
        #  38 int16u     oeminfo  - OEM info; oemid specific
        #  40 int16u[10] res2     - Reserved words
        #  60 int32u;    lfanew   - File address of new exe header
        SetByteOrder('II');
        my ($cblp, $cp, $lfarlc, $lfanew) = unpack('x2v2x18vx34V', $buff);
        my $fileSize = ($cp - ($cblp ? 1 : 0)) * 512 + $cblp;
        #(patch to accommodate observed 64-bit files)

lib/Image/ExifTool/Exif.pm  view on Meta::CPAN

        # (why does MicrosoftPhoto write "1c ea 00 00 00 08"?)
        RawConvInv => '$val=~s/^../\x1c\xea/s; $val',
    },
    0xea1d => {
        Name => 'OffsetSchema',
        Notes => "Microsoft's ill-conceived maker note offset difference",
        Protected => 1,
        Writable => 'int32s',
        # From the Microsoft documentation:
        #
        #     Any time the "Maker Note" is relocated by Windows, the Exif MakerNote
        #     tag (37500) is updated automatically to reference the new location. In
        #     addition, Windows records the offset (or difference) between the old and
        #     new locations in the Exif OffsetSchema tag (59933). If the "Maker Note"
        #     contains relative references, the developer can add the value in
        #     OffsetSchema to the original references to find the correct information.
        #
        # My recommendation is for other developers to ignore this tag because the
        # information it contains is unreliable. It will be wrong if the image has
        # been subsequently edited by another application that doesn't recognize the
        # new Microsoft tag.

lib/Image/ExifTool/Nikon.pm  view on Meta::CPAN

    },
);

my %flashGroupOptionsMode = (
    0 => 'TTL',
    1 => 'Manual',
    2 => 'Auto',
    3 => 'Off',
);

my %nefCompression = (   #28 relocated to MakerNotes_0x51 at offset x'0a (Z9)
    1 => 'Lossy (type 1)', # (older models)
    2 => 'Uncompressed', #JD - D100 (even though TIFF compression is set!)
    3 => 'Lossless',
    4 => 'Lossy (type 2)',
    5 => 'Striped packed 12 bits', #IB
    6 => 'Uncompressed (reduced to 12 bit)', #IB
    7 => 'Unpacked 12 bits', #IB (padded to 16)
    8 => 'Small', #IB
    9 => 'Packed 12 bits', #IB (2 pixels in 3 bytes)
    10 => 'Packed 14 bits', #28 (4 pixels in 7 bytes, eg. D6 uncompressed 14 bit)