exif date corrections

I noticed today that the creation date used by Gallery3 is off in a few places, sort of. It's pulling a creation date that is stamped on the file, but not the one in the photo's exif file properties. (From what I can tell, the creation date being used is the date it was uploaded to Gallery2--maybe the date the resize was created.)

I'm trying to force Gallery3 to use the exif creation date (that I can still see in exif software).

Any thoughts?

Okay, here's what I think is happening:

There are 3 dates related to the issue:
(1) The Metadata date, which appears to be the date the metadata was last modified.
(2) The Create date, for me, this is normally the date the gallery2 version of the image was created.
(3) The Modify date, which actually is holding the original capture date for the image.

The create date and modify dates are the opposite of what I thought they'd be, but I guess that part is accurate since it's auto created.

When I sort albums by "date captured," gallery is using the metadata date, which is incorrect; the editcreate module appears to be using the metadata date too.

Anyone able to recreate the issue? Anyone have a solution?

@undagiga: Thanks for the response!

I tried reimport the exif data several times already; didn't help.

I'm now thinking it definitely has something to do with the exif module itself; it seems to be pulling the dates, but not times for SOME photos--and that's what's messing with the sort.
The proper exif info is still viewable in all of my exif programs (including graphic suites).

Samples of what's happening:

For image 1:
<exif:DateTimeOriginal>2007-04-07T11:11:32-04:00</exif:DateTimeOriginal>
<exif:DateTimeDigitized>2007-04-07T11:11:32-04:00</exif:DateTimeDigitized>
<xmp:ModifyDate>2007-04-07T21:57:19-04:00</xmp:ModifyDate>
<xmp:CreateDate>2010-10-27T20:13:16-04:00</xmp:CreateDate>
<xmp:MetadataDate>2011-03-16T12:53:02-04:00</xmp:MetadataDate>
BUT the date used by the about_this_photo and editcaptured modules: Captured: Apr 7, 2007 00:00:00

For image 2:
<exif:DateTimeOriginal>2006-10-10T19:53-04:00</exif:DateTimeOriginal>
<exif:DateTimeDigitized>2006-10-10T19:53-04:00</exif:DateTimeDigitized>
<xmp:ModifyDate>2006-11-02T01:00:06-05:00</xmp:ModifyDate>
<xmp:CreateDate>2010-10-27T20:13:16-04:00</xmp:CreateDate>
<xmp:MetadataDate>2011-03-17T14:13:04-04:00</xmp:MetadataDate>
BUT the date used by the about this photo editcaptured modules: Captured: Oct 10, 2006 00:00:00

It's certainly odd. The code in "About this photo" to extract the EXIF date and time was actually written by Bharat, so I'd need to spend some time understanding and checking it. How did you produce the above samples, i.e. which program? Have you a small version of such an image that could be examined?

U-G

I agree that the problem is not with "About this photo", since it works for me in what I regard as a fairly standard setup. I don't think it's the EXIF module either, since I also edited mine to read in titles and more beside and it works for me. I suppose it could be your edits to the EXIF module. My best guess is that your software is storing this information in an unusual manner, which is why I'd need to see a small image with this problem that you are able to share. Perhaps you could also share your edited EXIF file.

U-G

I haven't even tried to upload this test image to my gallery, because I can see exactly what the problem is. Attached is a dump of all the metadata inside the file that was produced by a program called "ExifTool". (I can delete this file if you like, although it doesn't seem to contain any personal information, other than a person's name in a keyword which I've blanked out.) This shows that the main two EXIF time and date fields that Gallery3 would normally use are:

[ExifIFD]       36867 DateTimeOriginal                : 2007:04:07 00:00:00
[ExifIFD]       36868 CreateDate                      : 2007:04:07 00:00:00

So your own software is producing these fields. I can't imagine why. There are also other date and time fields in the image

[XMP-xmp]           - ModifyDate                      : 2011:03:20 09:50:10-04:00
[XMP-xmp]           - CreateDate                      : 2010:10:27 20:13:16-04:00
[XMP-xmp]           - MetadataDate                    : 2011:03:20 09:52:11-04:00
[XMP-exif]          - DateTimeOriginal                : 2007:04:07 11:50-04:00
[XMP-exif]          - DateTimeDigitized               : 2007:04:07 11:50-04:00

I really am surprised that the XMP fields are all so different. It probably doesn't matter for these purposes. The "Real" EXIF fields are the first two with 00:00:00 times. The last two [XMP-exif] fields presumably have the correct times, but these are only (or *should* only be) XMP copies of the "Real" EXIF fields that should have been put there by the camera.

So in the case of Gallery3, it is reading the "Real" Exif field correctly. The problem you will have to solve yourself is why are "Real" EXIF fields set to midnight. I see that you are using CS2 and therefore an old XMP toolkit. Some of those early XMP kits were buggy. In the absence of any other information that's where I'd suspect the problem is, but if it's only happening to some images processed by CS2 and not others, then it may be elsewhere in your workflow.

Test: What happens if you shoot a small jpg in your camera an upload it direct to your gallery3 install from the memory card without any other software touching it? It has the correct time, right? If so, then the problem is somewhere in your workflow between camera and upload.

U-G

Okay, first, again many thanks @undagiga for helping with this; the fact that you saw the times zeroed out was surprising because I'm not seeing that at all; so I've ben looking around and trying to figure it out.

In case anyone is interested, I'm including a good bit of references, but not all because they're fairly redundant.

WHAT I'VE LEARNED SO FAR: There is, in fact a "bug" with Adobe products and exif, sort of.

There are 2 sets of data in all photos (theoretically): exif and xmp. The xmp data is apparently supposed to override the exif data. That's why none of my software showed me the problem; newer software tends to read in the xmp (that includes the xmp) and basically ignore the exif (unless the xmp is missing for some reason). The dumb part (at least to me) is that even when reading the xmp, the data is still also reported in the exif field--leading me to believe that the exif is actually being reported, when it's not. (It seems like most cameras record exif; most newer software moves that info to the xmp.)

For xmp, the date, time (including seconds), and time zone are required; for exif, the seconds are optional. This is where Adobe (kind of) has a bug; most Adobe products will drop the seconds under some conditions. I can't figure them all out, but I know that is whenever the photo was taken exactly on the minute; the photo would have had "00" for seconds, so Adobe just drops it. That, evidently, causes problems with some software, if the software isn't reading xmp; the result is that the entire time field gets zeroed out because the seconds are missing. That's what Gallery3 is doing. (This explains almost all of my photos with this problem; it's a bit strange, but I seem to have a knack for taking photos exactly on the minute.) Sample discussions on the issue: http://forums.adobe.com/message/2953763 and http://www.elementsvillage.com/forums/archive/index.php/t-49556.html and http://community.acdsee.com/forums/topic/display-of-quotexif-versionquot

For the other images, the seconds seem to get lost when something happens during the save from some programs, but there is no general consensus on exactly what conditions make it happen.

I say that it's "sort of" a bug because, although it causes problems, it is within the scope of exif specifications. http://www.kodak.com/global/plugins/acrobat/en/service/digCam/exifStandard2.pdf and http://partners.adobe.com/public/developer/en/xmp/sdk/XMPspecification.pdf

Any program reading exif info should be able to cope with photos that don't have seconds because the seconds field is optional; that is obviously not happening with a bunch of exif readers that are reading the entire time as 00:00:00. The ultimate course will likely be dictated by the camera manufacturers, I guess, but it SEEMS from searching around that xmp is shifting to prominence.

I don't know how many people this affects, so I'm not sure if anyone wants to put time into a "fix" (and I'm not really sure how to do it myself). The easiest solution would be to insert "00" into the seconds field for any photo that doesn't have seconds pre-defined. A better solution would be to use the xmp date/times when they're available. This would also correct issues for all of the people that have problems with the times and/or time zones being off. (xmp data considers time zones and daylight savings times; exif doesn't)

NEXT STEPS: I'm looking at these sites, but really a designer, not a programmer, so I may or may not end up posting a solution, but the goal is to read in xmp date/time when it's present and read in exif date/time only when there's no xmp.
http://stackoverflow.com/questions/1578169/how-can-i-read-xmp-data-from-a-jpg-with-php
http://xmpphptoolkit.sourceforge.net/
http://photography-on-the.net/ee/beta/cs_xmp_to_exif.php
http://www.ozhiker.com/electronics/pjmt/index.html
http://forums.adobe.com/thread/418350?decorator=print&displayFullThread=true
http://forums.adobe.com/message/3059281

Sort of related: http://www.flickr.com/groups/adobe_lightroom/discuss/72157605515141640/

This image was done with CS4, not CS2, but you'd get the same result with CS3 and CS5 too.
Yes, almost all of the photographs were actually taken exactly on the minute; therefore, zero seconds.
The exif spec doesn't require seconds in that field; seconds are required (along with date, timezone, etc) in the xmp field.

Exif and xmp will not necessarily ever be in absolute agreement because the spec requires exif to be in local time (and makes seconds optional), whereas the xmp must maintain the original time and include seconds, etc. It's just happenstance that most people's local time is within the original timezone (or they just didn't bother to change the setting in the camera itself to account for whatever timezone they were actually in).

It's not just Adobe's view; the xmp generally overrides exif in most newer graphics software, precisely because it's more specific. More annoying is that other software (not just Adobe) reads in the date fine. Because of that, there's no real way for me to know if Adobe is wiping the seconds (which isn't a big deal) and some software ignores times when there are no seconds recorded, or if Adobe is wiping the entire timestamp. Only way to be 100% certain is to take a photo, wipe the seconds from the exif datetimeoriginal, and see what happens when uploaded to Gallery3 or read by exiftool.

It's explained better in the spec documents above (and discussed on a few of the other links).

Bug or not, I'll likely just (later) work on a script to read in the xmp data (much, much later though, because it sometimes takes me a while to get programs/scripts working).