Re: Maker data

Hi Pavel,

Your mKRd chunk proposal has some problems:

1. The "Maker" string by itself is not useful.  Decoding of maker notes depends not only the maker, but also on the specific camera model, the camera firmware version, and perhaps other information contained in the Exif (such as the Exif byte ordering, which may be different from the maker notes).

2. Makernote data may begin with any byte value, not just "II" or "MM", so the eXIf definition of the Mode byte doesn't make sense for the maker notes.

But aside from these minor problems, the biggest issue is with breaking out Exif into separate chunks.  This would impose a significant burden on the encoding software and make preserving the original Exif information very difficult.  On the other hand, existing Exif implementations could easily read/write the eXIf chunk intact (although admittedly makernote data is not handled properly by many implementations).

The DNGPrivateData may contain makernotes that are very similar to Exif makernotes, but the DNG specification avoids some of the Exif pitfalls by including an identification string, by specifying that the byte ordering is independent of the containing file, and by madating that offsets are relative to the data start and must not point outside the data.  (Note that the DNG MakerNoteSafety tag is unnecessary because the DNGPrivateData is always safe to copy if these rules are followed.)

- Phil
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot