![]() In order to really get all date/time meta information, those not contained in the IFD0 subtree have to be specified explicitly. Finally there’s the field FileModifyDate whose value doesn’t look at all like a date at first because it’s in unconverted Unix time format. So it appears that IFD1 holds the meta data for the thumbnail picture, a finding that’s confirmed by ExifTool’s man page. ![]() This is the only place where there’s any mention of the embedded thumbnail picture in the form of ThumbnailOffset and ThumbnailLength. IFD0 contains much more meta data than IFD1, including the sub-subtree ExifIFD that contains the two date fields DateTimeOriginal and CreateDate. This shows first of all two subtrees named IFD0 and IFD1, each of which contains a ModifyDate field. I shortened the output to give a clear view on the relevant data (camera data is also supplied in case all of this is model-dependent). While the File Modification Date/Time is easily explained as meta data stored outside the realm of the JPEG file but instead in the file system, why are there two occurrences of Modify Date? To find out let’s turn on the verbose output of ExifTool that yields a tree view. The parameter -a results in ExifTool printing all meta data out of which only the Date ones are extracted. ![]() Let’s first have a look at all the various dates stored in the JPEG file: $ exiftool -AllDates DSC01234.JPGĪll the dates? Well, apparently there’s more to it than that, as the following command reveals. This article exposes them to some length, so depending on how interested you are in those details you may or may not want to skip ahead to the solution offered at the end. Thankfully known offsets can be corrected with the help of Phil Harvey’s great piece of software ExifTool, however there are a few tricky details. Whether it’s seconds to a few minutes or whole hour increments due to a forgotten daylight savings time adjustment or travel beyond one timezone – there are situations when you want that time stored in the picture’s meta data to be precise. However (according to Phil Harvey), "The -globalTimeShift option is needed only when you want to copy a shifted date/time value to another tag.", such as a -geo tag.More than once I’ve found myself in a situation where I had happily taken pictures with my digital camera only to discover afterwards that the camera-internal clock was running fast or slow. Note, an earlier revision of this post suggested using the -globalTimeShift parameter, as in: exiftool -globalTimeShift -24 -time:all *.jpg You can also try adding to the -out file specification ( after making backups! ), the option -overwrite_original OR -overwrite_original_in_place, inserted directly after the call to exiftool. The -out specification gets inserted directly after the call to exiftool. newJPG.jpg or (in a new directory), with -out. You can combine the above code with an -out file specification, like -out. The above code works to subtract 24 hours according to this Forum comment (by Phil Harvey): ![]() Exiftool has an -alldates parameter: exiftool -alldates-=24 -filemodifydate-=24 -filecreatedate-=24 *.jpg ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |