EXIF Time (Date_Time Original) Mismatch between .CRW and .THM

[Archive]

[Originally posted by delenca on 2006-01-18 21:42:47-08]

  Hi,

  Just tried this program for the 1st time. Great program. Someone just built a front-end script for EXIFTool in IMatch and I found an odd "bug" (which may have nothing to do with EXIFTool itself):

  When I extract (or copy) the Date_Time Original EXIF field from a .CRW file to a
daughter file (i.e. a .jpg missing EXIF), I end up finding that the Time attribute of the Date_TimeOriginal reported by IMatch for the .CRW file and that of the .jpg file are off my 1 second! This mismatch breaks a versioning script I have in IMatch. Any idea/guesses as to what could be going on?
 
  Thanks,
  Alex

[Archive]

[Originally posted by exiftool on 2006-01-19 00:19:04-08]

Hmmm.  I can't reproduce this problem.  It is likely a round-off problem somewhere.  In the CRW image, the date/time is stored as the number of seconds since Jan 1, 1970, so converting it to a string may be subject to round-off errors.  You say that the IMatch times are off by one second, but are the ExifTool times off? Here is the test I ran (on a few different CRW files):

Code:

> exiftool a.jpg -datetimeoriginal
> exiftool a.jpg -tagsfromfile a.crw -datetimeoriginal
    1 image files updated
> exiftool a.crw a.jpg -datetimeoriginal -a -G1
======== a.crw
[CanonRaw]      Shooting Date/Time              : 2003:11:24 19:13:20
======== a.jpg
[ExifIFD]       Shooting Date/Time              : 2003:11:24 19:13:20
    2 image files read

So this same test doesn't get the time right for you?

[Archive]

[Originally posted by delenca on 2006-01-19 19:30:40-08]

  Sorry, let me rephrase - I don't mean to imply that there's a bug in ExifTool. I was hoping you'd have some insight on why different Raw converters generate files with different timestamps since you know the .CRW/THM file format well. You mention a rounding off error. That could be. Just for the record, I used exiftool to report on the various timestamps of jpgs generated by different programs:

Code:

C:\temp\test\exiftool>exiftool.pl 20051224_5247.CRW 20051224_5247-dACR.jpg 20051
224_5247-dDPP.JPG 20051224_5247-dRSP.jpg 20051224_5247-dZB.JPG 20051224_5247-dIm
t.jpg -datetimeoriginal -a -G1
======== 20051224_5247.CRW
[CanonRaw]      Shooting Date/Time              : 2005:12:24 17:50:28
======== 20051224_5247-dACR.jpg
[XMP-exif]      Date Time Original              : 2005:12:24 17:50:28-05:00
[ExifIFD]       Shooting Date/Time              : 2005:12:24 17:50:28
======== 20051224_5247-dDPP.JPG
[ExifIFD]       Shooting Date/Time              : 2005:12:24 17:50:28
======== 20051224_5247-dRSP.jpg
[ExifIFD]       Shooting Date/Time              : 2005:12:24 17:50:29
======== 20051224_5247-dZB.JPG
[ExifIFD]       Shooting Date/Time              : 2005:12:24 17:50:29
======== 20051224_5247-dImt.jpg
[ExifIFD]       Shooting Date/Time              : 2005:12:24 17:50:29
    6 image files read

where the suffix -dxxx stands for "developed" by xxx program, where ACR=Adobe Acrobat Raw, DPP=Canon DPP, RSP=Raw Shooters Pro, ZP=Canon's Zoom Browser and Imt=IMatch (which I think uses the same Canon libraries as ZB)

 Depressing that a value that should be pretty much unchanging (creation time stamp) shows such variability across programs. Rounding off error? Or are the different programs looking at different things for their info? (i.e. perhaps some are looking at the .CRW for timestamp while the other takes it from .THM??). And notice how two programs from Canon (DPP and ZB) give different numbers... May seem like a trivial thing but it breaks something else I was trying to do. Oh well. Thanks for looking into it and sorry for the rant! (I also posed a similar question on the IMatch forum).

  -Alex

[Archive]

[Originally posted by exiftool on 2006-01-19 20:25:55-08]

Thanks for being more specific.  Interesting.

Do your THM timestamps match your CRW timestamps (as reported by ExifTool)?  They match for all my samples.  If they match then the difference is due to round-off errors in converting the 4-byte integer to a date-time string, otherwise the difference is due to the location from which the software gets the timestamp.  I suspect the former.

I have seen differences in the outputs of Canon programs before (FVU, EVU, Image Browser, DPP), so that doesn't surprise me.  All their software doesn't use the same set of algorithms to decode meta information.  (But I haven't tried Zoom Browser yet -- it doesn't run on a Mac.)

If the times are consistently out by one second, you can fix them using the ExifTool time shift feature.  Other than that I can't help much except to suggest that you submit bug reports for the software that is doing the conversion incorrectly.

An interesting but (hopefully!) unrelated fact is that there was a leap second introduced at the end of 2005 to make Dec. 31 one second longer.  But this shouldn't be the source of the problem since the conversion routines shouldn't be correcting for leap seconds.

[Archive]

[Originally posted by delenca on 2006-01-20 02:52:16-08]

  Hmm. Surprising. They do NOT match.

Code:

C:\temp\test\exiftool>exiftool.pl 20051224_5247.CRW 20051224_5247.THM -datetimeo
riginal -a-G1
======== 20051224_5247.CRW
Shooting Date/Time              : 2005:12:24 17:50:28
======== 20051224_5247.THM
Shooting Date/Time              : 2005:12:24 17:50:29
    2 image files read

  So, to me, this means that the most likely explanation for the discrepancy is that different programs are grabbing the EXIF data from either one or the other file. It turns out that EXIFTool is grabbing the timestamp from the .CRW file. Now, why are they mismatched? Probably b/c the 300D writes Raw data slow enough that a certain % of times, the .THM file ends up getting written about a second later. Since not every file will have the same issue, this is not trivial to fix! (short of simply sticking to one program for all Raw Processing).

  -Alex

[Archive]

[Originally posted by exiftool on 2006-01-20 12:45:20-08]

So there's the answer.  Interesting that I own a 300D myself but have never noticed this problem -- probably because my workflow doesn't involve the .THM files.

Maybe this is the answer for you:  Just don't copy over the .THM files when you download the images.  Then the conversion software will be forced to use the .CRW information.  I'm pretty sure this should work with the Canon utilities, and with any luck it will also work with IMatch and Raw Shooter Pro.

[Archive]

[Originally posted by delenca on 2006-01-20 14:29:01-08]

  Wow. Interesting. So you learned something too! ;-) In any case, that is true - one idea is simply getting rid of the .THM files. I had religiously kept them b/c I was under the impression (as many people are) that only the .THM files carry EXIF information. That is clearly not true as I discovered through this little exercise with EXIFTool. On the other hand, I am pretty sure there might be negative consequences to throwing away .THM files, depending on what software you use - for instance RSP might only look for EXIF info in the THM file, and, if it doesn't find it, it will simply write a .jpg without EXIF. I could, of course, always copy over the EXIF info using EXIFTool, but that is a pain unless I script it very carefully to run everytime a .jpg is generated by any given tool.

  Another possibility I was considering last night is to synchronize the filestamps early on the work flow - for instance, I could force the EXIF timestamp of the THM onto the CRW or vice-versa, and thus abolish the mistmatch. This would be simpler to implement, in theory - I think I could even set it up so that Downloader Pro automatically launches a script (i.e. something involving EXIFTool) for this purpose once the files have been copied over. There might be consequences to the actual file timestamp (i.e. windows timestamp) - I would have to check on that.

  -Alex