1

When using Phil Harvey's Exiftool version 12.31 on Windows, the DateTimeOriginal field is returning numbers, which seems to be an HEX value, but it's too big to make any sense. As a DEC value it doesn't make any sense either, so I'm thinking that maybe it is a tuple of some sort, but I don't know how to parse it (shouldn't it be parsed by Exiftool?).

Here is the link to the original image.

> exiftool -DateTimeOriginal "DSC02102.JPG"
Date/Time Original              : 50 48 50 49 58 49 50 58 48 55 32 49 53 58 53 53 58 50 52 0

Somehow Windows can get the correct date and time (2021-12-07 15:55), so I don't think the file metadata is corrupt.

How can I use Exiftool to get the correct date and time?

Adrián Carreño
  • 13
  • 2

1 Answers1

1

This is exiftool FAQ #3. Because you haven't included the -G (-groupNames) option and the -a (-duplicates) option, you aren't seeing all the data. When you include those options you'll see this

C:\>exiftool -G1 -a -s -DateTimeOriginal Y:\!temp\aa\bbb\DSC02102.JPG
[ExifIFD]       DateTimeOriginal                : 2021:12:07 15:55:24
[IFD0]          DateTimeOriginal                : 50 48 50 49 58 49 50 58 48 55 32 49 53 58 53 53 58 50 52 0

As you can see, there is more than one DateTimeOriginal tag in the file. The standard place for that tag is in the ExifIFD subgroup of the EXIF block and that has the correct value, which is why Windows can read it. The second DateTimeOriginal in the IFD0 subgroup is out of place. If you convert each number in the second tag to the ASCII character, you'll see that it holds the same value as the correct DateTimeOriginal tag, just in hex values.

Another useful exiftool command would be to validate the file to see what problems exist

C:\>exiftool -g1 -a -s -warning -validate Y:\!temp\aa\bbb\DSC02102.JPG
---- ExifTool ----
Warning                         : [minor] Possibly incorrect maker notes offsets (fix by 4088?)
Warning                         : [minor] Suspicious MakerNotes offset for Tag9401
Warning                         : [minor] Non-standard ExifIFD tag 0xea1c Padding
Warning                         : [minor] Non-standard ExifIFD tag 0xea1d OffsetSchema
Warning                         : Non-standard format (int32s) for GPS 0x0005 GPSAltitudeRef
Warning                         : Wrong IFD for 0x9003 DateTimeOriginal (should be ExifIFD not IFD0)
Warning                         : Non-standard format (int8u) for IFD0 0x9003 DateTimeOriginal
Warning                         : [minor] Invalid date/time format for EXIF:DateTimeOriginal
Warning                         : Wrong IFD for 0x9004 CreateDate (should be ExifIFD not IFD0)
Warning                         : Non-standard format (int8u) for IFD0 0x9004 CreateDate
Warning                         : [minor] Invalid date/time format for EXIF:CreateDate
Warning                         : [minor] Non-standard IFD0 tag 0xea1c Padding
Warning                         : Missing required JPEG ExifIFD tag 0xa001 ColorSpace
Validate                        : 13 Warnings (7 minor)

You can remove the incorrect tag with this command
exiftool -IFD0:DateTimeOriginal= file.jpg

To extract just the correct tag, you would have to specify the subgroup
exfitool -ExifIFD:DateTimeOriginal file.jpg

StarGeek
  • 4,948
  • 2
  • 19
  • 30
  • Looking at the metadata for that file, it appears that there are two programs that have edited that file, QBase 3D and PPK Geotag. One of these may be the program that is incorrectly editing the file. It seems unlikely that the data is incorrect when it comes directly out of the camera. – StarGeek Dec 10 '21 at 16:44
  • It also appears that there is an incorrect `CreateDate` tag. You would remove it in the same way you would remove the `DateTimeOriginal` tag. – StarGeek Dec 10 '21 at 16:51
  • Looking further at the file by adding the `-v3` option and the warnings generated, the incorrect tags are being saved as 20 8 bit unsigned integers (`int8u[20]`) instead of the `string[20]` it's supposed to be. Exiftool appears to be the one converting the integers to hex. I've linked the file on the exiftool forums so the author can take a close look at the file and decide if he needs to do anything about this. – StarGeek Dec 10 '21 at 16:58
  • you're correct, there are 2 programs that edited the file, and QBase 3D is the one used to inject the GPS coordinates in the file, bot now I see it did more than that. By using the flags you pointed, I was able to find the correct data, and also I noticed duplicates for several other fields. Now I will have to find a workaround in my code to work with this kind of files and detect which tag has the correct data. – Adrián Carreño Dec 10 '21 at 18:46
  • [Here's a post](https://exiftool.org/forum/index.php?topic=13100.msg70823#msg70823) where exiftool's author comments upon the problem. – StarGeek Dec 10 '21 at 19:19