Correcting Bad EXIF Date/Time Original

[jch2103]

Somehow, I've ended up with several hundred images where the EXIF Date/Time Original has been changed to 1980:07:01 12:00:00. (I haven't had any luck figuring out how this happened, as it appears almost random - only some images in some folders. In some cases, only the NEF file was affected, in others both NEF and JPG were changed.)

I've been able fix most of them by either updating using tags in a metadata panel or using the ExifTool Command Processor (for files where I'd previously used the date/time to set the image name). However, I still have some images that resist almost everything I've tried (XMP tags are updated, and also Exif::Main\36868\CreateDate\0, but not Exif::Main\36867\DateTimeOriginal\0). I know this is complicated because of the way Exiftool works in conjunction with the MWG rules. The only tool that works for certain is Commands/Image/Modify EXIF Date and Time... which has to be applied one image at a time to get the exact time written.

Am I missing an easier way to fix these files?

[Mario]

When mapping XMP to EXIF, ExifTool uses

-EXIF:DateTimeOriginal < XMP-photoshop:DateCreated

and this tag is filled by IMatch under the name "Date Subject Created"

[jch2103]

So if I understand the syntax correctly, Exiftool should use XMP-photoshop:DateCreated to fill EXIF:DateTimeOriginal.

In fact, this does work most of the time. I've been able to fix most of the odd/wrong dates, albeit with some work for these several hundred images.

However, I have (so far) about ten NEF images for which this doesn't work. That is, Exif::Main\36867\DateTimeOriginal\0 isn't being updated for these images. (I've tried all the forced scan methods on these images, but no success with the problem.) As long as the number of problem images doesn't increase too much as I continue my cleanup, I can deal with it using Commands/Image/etc.


I would really like to be able to figure out how this problem happened, though I don't have many clues to work from. The affected images were taken over the past decade, but with only a few images affected in any (random?) folders. Some of the affected files had to have been changed during the last year. I suppose the 1980:07:01 12:00:00 date is a clue of some kind, but it doesn't help me. Puzzling and annoying... (But I have no reason to think IMatch is involved in any way, except to provide a tool to fix the problems!)

[Mario]

You can open the ExifTool Output Panel (View > Panels > Output) and then trigger a write-back for one of the problem NEF files.
This not only shows us what IMatch is telling ExifTool to do but also if ExifTool reports any problems.

Maybe the NEF files have an embedded XMP record with different timestamps?

[jch2103]

You can open the ExifTool Output Panel (View > Panels > Output) and then trigger a write-back for one of the problem NEF files.

Maybe the NEF files have an embedded XMP record with different timestamps?

Thank you for the suggestion. The embedded XMP record was indeed the issue for those problem NEF files. Once I cleared that out, I was able to fix the dates using the same tag method as I used for the other affected images.

I wish I could figure out how this happened in the first place. As I noted before, the affected files a pretty random. In some cases it's either the NEF or JPG of a processed pair, in some cases just an isolated image here or there. The only commonality that's at all a hint is that many (but not most) of the images were processed via Lightroom to ID faces...

[Mario]

As far as I know, the only software ever embedded XMP in NEF files was Nikon Capture / NX.
This embedded XMP caused workflow issues when it contains different data for the same tag as the XMP sidecar file.

[jch2103]

As far as I know, the only software ever embedded XMP in NEF files was Nikon Capture / NX.
This embedded XMP caused workflow issues when it contains different data for the same tag as the XMP sidecar file.

Not a cause in my case, as I've never used Nikon Capture / NX. A mystery...

[Mario]

Some newer cameras write partial XMP data. Usually rating=0 (which causes another set of problems) and maybe a partial date.

[jch2103]

Some newer cameras write partial XMP data. Usually rating=0 (which causes another set of problems) and maybe a partial date.

One of my Nikons does that, but removing it is part of my regular workflow. In any event, my 'date' problem happened subsequent to when I downloaded/processed/organized/etc the images...

[Mario]

Well, now we know where it comes from and how to fix it.
Cleaning up image collections usually reveals such issues (I could write a book about this)...

[jch2103]

Well, now we know where it comes from and how to fix it.
Cleaning up image collections usually reveals such issues (I could write a book about this)...

Well, actually we know how to fix it, but not where it came from. What bothers me is that I still don't know how it could have happened, and why this particular date (it acts like some kind of epoch date, but I can't find any such dates that match what I encountered). I just need to add looking for this date (1980:07:01 12:00:00) to my QC list (complicated slightly by the fact that I have a number of scanned images assigned that same date/time).


At least IMatch makes it possible to catch these kind is issues and fix them!

[Aubrey]

One of my Nikons does that, but removing it is part of my regular workflow.

Which model of Nikon is giving this problem?

Thanks,
Aubrey.

[jch2103]

Which model of Nikon is giving this problem?

My Nikon 1 V3 (assigns an XMP Rating of 0 to all images); my D600 doesn't do that, nor did my old D90. I understand that some other (relatively recent) Nikons do it also. As I noted, part of my regular workflow for the V3 is to clear out XMP in the images immediately after I download them to the computer. Otherwise it's not possible to assign a Rating.


But this is separate from the issue I encountered with strange dates.

[Mario]

You could also configure the favor option for XMP for your file format in Edit > Preferences > Metadata 2 > File Formats.
But cleaning the partial record from the NEF/NRW is probably the better solution because it is compatible with all other applications.