Bug #636

Exiv2 corrupts certain NEF images when writing to them (digiKam bug 193228)

Added by Andreas Huggel about 8 years ago. Updated almost 8 years ago.

Status:ClosedStart date:22 May 2009
Priority:UrgentDue date:
Assignee:Andreas Huggel% Done:

100%

Category:tiff parser
Target version:0.18.2

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)

correct.NEF (6.45 MB) Andreas Huggel, 22 May 2009 07:17

corrupt.NEF (6.45 MB) Andreas Huggel, 23 May 2009 02:30


Related issues

Related to Exiv2 - Feature #620: Update Nikon makernotes Closed 14 Mar 2009

Associated revisions

Revision 1803
Added by Andreas Huggel about 8 years ago

#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.

History

#1 Updated by Andreas Huggel about 8 years ago

I can only reproduce this on the attached image. Other NEFs work fine.

#2 Updated by Andreas Huggel about 8 years ago

#3 Updated by Andreas Huggel about 8 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.)

#4 Updated by Andreas Huggel about 8 years ago

  • Priority changed from Immediate to Urgent

Reducing priority, since the "corrupt" images can be recovered.

#5 Updated by Andreas Huggel about 8 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".

#6 Updated by Andreas Huggel about 8 years ago

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.)

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.

#7 Updated by Andreas Huggel about 8 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.

#8 Updated by Andreas Huggel about 8 years ago

  • % Done changed from 0 to 100

#9 Updated by Andreas Huggel almost 8 years ago

  • Target version set to 0.18.2

#10 Updated by Andreas Huggel almost 8 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF

Redmine Appliance - Powered by TurnKey Linux