Bug #636
Exiv2 corrupts certain NEF images when writing to them (digiKam bug 193228)
100%
Description
Writing an IPTC keyword (probably any tag will do) to a NEF image can result in a corrupt NEF image.
Exiv2 will still read the metadata of the resulting image, but ufraw won't display it anymore.
To reproduce, run the following command on the attached file:
$ exiv2 -v -M'set Iptc.Application2.Keywords DigiKam Test' correct.NEF
This bug was originally reported by Christian Ide as digiKam bug 193228
Sample pictures courtesy of Christian Ide
correct.NEF is a picture taken with a Nikon D70s and edited with Nikon ViewNX 1.3
corrupt.NEF is the result of adding metadata to correct.NEF using digiKam (exiv2)
Files
Related issues
Associated revisions
History
Updated by Andreas Huggel over 12 years ago
I can only reproduce this on the attached image. Other NEFs work fine.
Updated by Andreas Huggel over 12 years ago
The good news is that the image is not corrupted: all thumbnails can be extracted and the primary image data is identical to that in the correct image.
correct.NEF is written using little-endian (II) byte order.
corrupt.NEF also uses little-endian byte-order, except for the makernote, which is in big-endian (MM) byte order.
(and all my other NEF samples are MM)
Re-writing corrupt.NEF so that it only uses little-endian byte-order results in an image which ufraw can display again.
The required change: Exiv2 should write Nikon3 makernotes using the same byte order as that of the rest of the image without changing the byte order. (It currently writes Nikon3 makernotes always using MM.)
Updated by Andreas Huggel over 12 years ago
- Priority changed from Immediate to Urgent
Reducing priority, since the "corrupt" images can be recovered.
Updated by Andreas Huggel over 12 years ago
Additional info from Dave Coffin:
"dcraw -w" fails because Exiv2 changed the MakerNote
byte order without byte-swapping the white balance in tag
0x97. You cannot reorder a TIFF tag of type 7 (undefined)
without knowing its internal structure. If it's encrypted,
you have to decrypt, shuffle bytes, then re-encrypt.
Nikon does this byte-swap correctly, so dcraw must
assume that data within a type-7 tag follows the MakerNote
byte order. Therefore dcraw cannot support Exiv2-corrupted
images.
Be very careful when fixing these images, because many
NEF files in my collection, never touched by Exiv2, have
big-endian MakerNotes. You should fix a file only if
"dcraw -i -v" shows nonsense values for "Camera multipliers".
Updated by Andreas Huggel over 12 years ago
The required change: Exiv2 should write Nikon3 makernotes
using the same byte order as that of the rest of the imagewithout changing the byte order. (It currently writes Nikon3 makernotes always using MM.)
Another idea: Make Exif.MakerNote.ByteOrder writable, i.e., write the makernote using the byteorder specified by this tag. (Of course only if the given makernote has its own byte order setting.) This achieves the above plus lets users set the makernote byte order if they want. For the time being (until #620 is done) that could be used to fix the corrupted NEF images.
Updated by Andreas Huggel over 12 years ago
- Status changed from Assigned to Resolved
The issue is fixed with r1803.
If you have Exiv2-corrupted NEF images as a result of this bug, you can fix them. Such an image shows the following symptoms:
- has metadata edited with Exiv2 0.18 or 0.18.1
- isn't properly displayed in ufraw with the Camera WB setting, however, is ok with other white balance settings
- the value of Exif.MakerNote.ByteOrder is MM and the byte order of the image itself is II (i.e., II in the first 2 bytes of the file)
To fix an image corrupted due to this bug, get r1803 and run this command:
$ exiv2 -M'set Exif.MakerNote.ByteOrder II' corrupt.NEF
This will change the makernote byte order back to little-endian and until #620 is done, it won't byte-swap the whitebalance tag, so that the result is correct again.
#636: Do not change makernote byte order unless requested. By default, use the same byte order as that of the image (for new makernote metadata). Right now, the only makernote that has its own byte order is Nikon3. Also added missing padding to IPTC binary data for Exif.Image.IPTCNAA.