Feature #574
Support "Adobe Makernote" in DNGPrivateData
0%
Description
From Gilles Caulier:
After playing and playing with Adobe DNG converter to tune my propers raw to DNG tool (http://www.digikam.org/drupal/node/373) , i have discovered than Adobe do not use Exif.Photo.MakerNote tags to host makernote byte array, but a new DNG tag named DNGPrivateData Look this page:
http://www.barrypearson.co.uk/articles/dng/safety.htm
...and this comment :
"The code change in ACR/DNG 3.1 that preserves private MakerNotes applies to all formats that store their private data using the Exif MakerNote format, which includes Pentax. These MakerNotes are often byte order or offset dependent, so what I'm doing to preserve this data safely is repackaging it into the DNGPrivateData tag. This repackaging stores the source file's byte order and the original file offset to the MakerNote, along with the MakerNote data itself. This allows an application that understands the MakerNote format for a particular camera to find the MakerNote data, along with the original byte order and file offset, and thus parse the MakerNote data correctly from the DNG file".
But the better is here :
http://www.barrypearson.co.uk/articles/dng/specification.htm
With these informations how to store makernotes in DNGPrivateData:
Storage of Makernote in DNGPrivateData
...
The DNGPrivateData generated by the DNG Converter, hence containing the original EXIF Makeernote, is:
1. Six bytes containing the zero-terminated string "Adobe". (The DNG specification calls for the DNGPrivateData tag to start with an ASCII string identifying the creator/format).
2. 4 bytes: an ASCII string ("MakN" for a Makernote), indicating what sort of data is being stored here. Note that this is not zero-terminated.
3. A four-byte count (number of data bytes following); this is the length of the original MakerNote data. (This is always in "most significant byte first" format).
4. 2 bytes: the byte-order indicator from the original file (the usual 'MM'/4D4D or 'II'/4949).
5. 4 bytes: the original file offset for the MakerNote tag data (stored according to the byte order given above).
6. The contents of the MakerNote tag. This is a simple byte-for-byte copy, with no modification.So, i will using this way in my converter to be fully compatible with Adobe tool.
This imply too that Exiv2 need to support this way to extract makernotes from DNG files...
Related issues
History
Updated by Andreas Huggel about 13 years ago
The new Exif.MakerNote.Offset tag is part of the fix for this but I'm not sure
yet to what extent this Adobe Makernote should be supported in Exiv2.
With the new tag, you can almost write such Adobe makernotes. I will
add the byte order in a similar way, still for 0.18. (Watch out, in
some cases the Exif data has a different byte order than the
makernote, you can't always simply take the byte order from the
image).
IMO they make a bad thing worse. I recommend that you boycott it and
don't write this tag. It is flawed in more than one way. (*)
Microsoft, in Vista, did something similar
( http://dev.robotbattle.com/bugs/view.php?id=543 ). It also doesn't
always work, but is still better than this Adobe tag. The irony is
that Adobe and Microsoft sit in the same metadata working group
( http://www.metadataworkinggroup.org/ ), who's declared goal is to
provide common specifications for seamless interoperability of digital
image metadata.
Andreas
(*)
1) It doesn't always work. For some cases it is still necessary to
know the makernote structure. Comment from Phil Harvey, ExifTool
author, on one of the pages you pointed me to: "The Olympus maker
notes contain pointers which reference information outside the
makernotes data block. This information (a few kB worth) is not copied
by the DNG converter [...]. To properly copy ORF maker notes, you need
to understand the structure".
2) It is unclear how to deal with cases which have a normal makernote
tag as well as this Adobe makernote.
3) It seems the Adobe makernote tag tries to provide all info that is
needed to read the makernote in one tag but it doesn't: In order to be
able to decode the makernote you also need to know what makernote it
is.
4) It's more complex than necessary. The M$ implementation to address
the same problem ("How to preserve makernote data if I don't know its
structure?") is simpler, doesn't suffer from issue 2) and doesn't
pretend to provide 3).
Updated by Andreas Huggel about 12 years ago
Updated by Andreas Huggel about 12 years ago
Decoding should be reasonably straightforward. Encoding is more interesting: If makernote tags decoded from this tag use the same groups as the native makernote tags (e.g., Exif.OlympusEq.SerialNumber, not something like Exif.DngOlympusEq.SerialNumber), then the question is whether they should be packed into a native makernote tag or a DNGPrivateData tag when writing. One idea is to decide based on the presence of a DNGPrivateData tag: If such a tag exists, pack makernote tags into that (and remove a native makernote if there is one), else, pack makernote tags into a native makernote as usual. That would make conversion between native and these DNG makernotes straightforward: Delete the DNGPrivateData tag to convert to a native makernote and add it (with any value) to convert native makernote tags into a DNG makernote.
(Using different group names would require a lot of additional configuration and make conversion difficult.)