Silent failure on change timestamp

[CameronD]

I have several images which refuse to update exif timestamps using the Tools->Change Timestamp menu.
Eventually I identified the cause, by running the same operation through exiftool from the command line.
Exiftool returns the error message:

Code: Select all

Error: Error reading StripOffsets data in IFD0 - filename

This is a known problem, where some other software creates invalid headers by retaining parameters specific to the original TIFF format.
The cause and a workaround is given in the exiftool forums.

The problem with XnViewMP is that it fails silently, instead of reporting an error message. The user has no evidence that the operation has failed.

A small example with the bad exif content is attached:

[xnview]

i can't reproduce, please send me the file?

[CameronD]

If you download the attached example, it still had the bad Exif header.
try "Change Timestamp" - you will see there is no DateDigitized assigned.
Try to assign some value, such as Date Taken, or current date.
Write.
Nothing changes.

[xnview]

i've tried to change 'Date taken' or 'Date modified' and it works

[CameronD]

That's weird. I was trying to add a new item DateDigitized rather than modify an existing one.
I have "Create Metadata if needed enabled" ticked - I think this is critical.

First, check that your test image still has the bad IFD0 contents:
The exiftool listing inside XnViewMP should show:

EXIF: Strip Offsets 5026

Curiously, when I select the EXIF tab on the same file, it shows
Strip Offsets 4996
I think this difference is simply an artifact of the fact that the value is invalid anyway. 4996 is the actual value stored, and 5026 is that number added to the jpeg header byte count.

exiftool 10.04
When run manually, exiftool gives:

Code: Select all

$ exiftool '-Exif:DateTimeOriginal=1983:03:19 15:00:00' example-bad-ifd0.jpg 
Error: Error reading StripOffsets data in IFD1 - example-bad-ifd0-2.jpg
    0 image files updated
    1 files weren't updated due to errors

It refers to an error in IFD1, but I think that is because IFD0:StripOffsets points into the middle of the IFD1:Thumbnail area.

XnViewMP x64 0.76.1 (Oct 23 2015), Win 7

• "Create Metadata if needed enabled" is ticked
• assign the Exif:CreateDate (DateDigitized) results in nothing happening.
• alter the Exif:ModifyDate results in nothing happening.
• Untick Create metadata if needed and then alter the Exif:ModifyDate results in: date changed!

XnViewMP 32-bit 0.76.1 (Oct 23 2015), Win 7
I have a separate installation on the same machine, with separate ini files, DB etc.
The result is the same as for 64-bit.

Xnview 2.33
I have tried the operation on the test file with this version of classic.
The DateDigitized value is greyed out, but ticked. When I assign a new value the Exif:Date Taken then it changes the date, but returns with the image file highlighted in bright red.

[xnview]

See Issue 758 for current status and details.

[helmut]

This problem is supposed to be fixed in XnView MP 0.79 or later. Could you please try and confirm the bug fix, CameronD?

[CameronD]

This problem is supposed to be fixed in XnView MP 0.79 or later. Could you please try and confirm the bug fix, CameronD?

Confirmed - the program now generates an error message and fails to modify the file.
This is appropriate action, as the user needs to try to understand the nature of the corruption in order to correct it.

For the record, I used the following exiftool command to overwrite the corrupted exif block:

Code: Select all

exiftool -exif:all= -tagsfromfile @ -exif:all -thumbnailimage -unsafe filename

[helmut]

Thank you for your confirming the bug fix, CameronD.

Closed