Geotag "Time is too far beyond track"

[ptdotme]

I've noticed the "-geotag" feature seems to be miscalculating something when applying a GPS track file to a folder of images.

As of v13.25 and v13.28, for example, I have a folder of 10 raw files where the final 3 are deemed "too far beyond track."  I've tested the the same images with the same track file with v13.10 and it works as expected.  For the first 7 files in the folder, the newer versions of exiftool seem to be geotagging photos ahead on the track of where they should be.

Sorry to post this on a Friday night.  I have a workaround (using 13.10) so absolutely no urgency is needed on this.  I'm running exiftool on macOS and have just noticed this change in behavior (-geotag has been working perfectly for me for years now).  I'd prefer not to publish my photos and GPS track file here but can provide them privately if needed.  Thanks!

[Phil Harvey]

This is possibly a byproduct of the change in version 13.18:

Feb. 3, 2025 - Version 13.18
  - Enhanced -geotag option to set Geotime from either SubSecDateTimeOriginal
    (preferentially) or DateTimeOriginal if not otherwise specified

It should probably still work as expected, even though you get a warning.  To mimic the previous behaviour, set "-geotime<datetimeoriginal#"

If this doesn't work, then you can send the files to me at philharvey66 at gmail.com and I'll take a look.

- Phil

[ptdotme]

I've verified the SubSecDateTimeOriginal and DateTimeOriginal timestamps look as expected in my CR3 files, so I'd expect -geotag to tag the images with roughly the same location in both v13.10 and v13.25.  The newer versions are tagging the first few photos as if they were shot many minutes later (but it's hard to tell) and then running out of track before the final few photos.  Since the GPX track timestamps continue for a few minutes after the last photo, none of the photos should be "too far beyond track."

Code Select Expand

======== /Volumes/.../R5PT5013.CR3
SubSecDateTimeOriginal          : 2025:04:23 08:44:26.96-08:00
DateTimeOriginal                : 2025:04:23 08:44:26
...
======== /Volumes/.../R5PT5262.CR3
SubSecDateTimeOriginal          : 2025:04:23 09:45:50.27-08:00
DateTimeOriginal                : 2025:04:23 09:45:50

v13.25 output:

Code Select Expand

Warning: [minor] Invalid VignettingCorrUnknown1 data - /Volumes/.../R5PT5262.CR3
Warning: [minor] Invalid VignettingCorrUnknown1 data - /Volumes/.../R5PT5113.CR3
Warning: [minor] Invalid VignettingCorrUnknown1 data - /Volumes/.../R5PT5017.CR3
...
    1 directories scanned
    7 image files updated
    3 image files unchanged
v13.28 output:

Code Select Expand

Warning: Time is too far beyond track in File:Geotime (ValueConvInv) - /Volumes/.../R5PT5262.CR3
Warning: Time is too far beyond track in File:Geotime (ValueConvInv) - /Volumes/.../R5PT5192.CR3
Warning: Time is too far beyond track in File:Geotime (ValueConvInv) - /Volumes/.../R5PT5257.CR3
    1 directories scanned
    7 image files updated
    3 image files unchanged
The "-geotime<datetimeoriginal#" workaround did work, but since I'd expect it to work either way, so I've sent my example files.  Thanks for getting back to me so quickly.

[StarGeek]

What is the exact command you are using. Because when I geotag an image, there is no difference between 13.10 and 13.28 data.

Example. The last time stamp in the GPX file is 2013-01-28T23:48:52.000Z, and the DateTimeOriginal and OffsetTimeOriginal are set to the correct time for my time zone, -08:00 for that date.

Code Select Expand

C:\>exiftool -time:all --system:all -G1 -a -s Y:\!temp\x\y\1.jpg Y:\!temp\x\y\2.jpg
======== Y:/!temp/x/y/1.jpg
[ExifIFD]       DateTimeOriginal                : 2013:01:28 15:48:52
[ExifIFD]       OffsetTimeOriginal              : -08:00
[Composite]     SubSecDateTimeOriginal          : 2013:01:28 15:48:52-08:00
======== Y:/!temp/x/y/2.jpg
[ExifIFD]       DateTimeOriginal                : 2013:01:28 15:48:52
[ExifIFD]       OffsetTimeOriginal              : -08:00
[Composite]     SubSecDateTimeOriginal          : 2013:01:28 15:48:52-08:00
    2 image files read

C:\>exiftool -P -overwrite_original -geotag 2013-01-28_152504.gpx Y:\!temp\x\y\1.jpg
    1 image files updated

C:\>exiftool_13.10 -P -overwrite_original -geotag 2013-01-28_152504.gpx Y:\!temp\x\y\2.jpg
    1 image files updated

C:\>exiftool -G1 -a -s -gps* -n  Y:\!temp\x\y\1.jpg -diff Y:\!temp\x\y\2.jpg
======== diff < Y:/!temp/x/y/1.jpg > Y:\!temp\x\y\2.jpg
(no metadata differences)

[ptdotme]

for v13.10 (works as expected):

Code Select Expand

/Volumes/.../Image-ExifTool-13.10/exiftool  -ext "*" --ext xmp --ext DS_Store -preserve -overwrite_original -geotag "${HOME}/Desktop/SafariDLs/RK_gpx _2025-04-23_0818.gpx" /Volumes/SamsungEvo4TB/import-2025-04-23

for v13.25:

Code Select Expand

exiftool -ext "*" --ext xmp --ext DS_Store -preserve -overwrite_original -geotag "${HOME}/Desktop/SafariDLs/RK_gpx _2025-04-23_0818.gpx" /Volumes/SamsungEvo4TB/import-2025-04-23
exiftool -ver
13.25

for v13.28:

Code Select Expand

/Volumes/.../Image-ExifTool-13.28/exiftool  -ext "*" --ext xmp --ext DS_Store -preserve -overwrite_original -geotag "${HOME}/Desktop/SafariDLs/RK_gpx _2025-04-23_0818.gpx" /Volumes/SamsungEvo4TB/import-2025-04-23

This happened last week with a different set of CR3 files after upgrading exiftool (where the final image in the folder wasn't geotagged) and I fixed it manually.  I made my post after noticing this happen again with a different set of CR3 files.  Before I upgraded from v13.10 it had always worked as expected for me with several different Canon mirrorless cameras and GPX track files downloaded from Runkeeper.

[StarGeek]

I don't see anything really different in that command compared to mine at the basic level. I thought maybe the fact that they are CR3 files might change things, because a few CR3 time stamps are handled differently, but that shouldn't apply to the DateTimeOriginal tag.

So I'm out of ideas.

[Phil Harvey]

I haven't received any files, but I may have all I need to figure out what is going on if you show me the output of this command for one of the CR3 files:

exiftool -a -G1 -s -time:all FILE

Actually, having just the files won't tell the whole story.  I also need to know your system time zone which will be given in the output from the above command.

- Phil

[ptdotme]

Sorry about the files email, it must have been flagged as spam.

I'm betting the problem is due to timezones.  I'm on the US west coast in PDT (UTC -7 hours) but after the most recent time change I set my camera to the correct time instead of toggling the "daylight savings time" option.  As a result, my CR3s have the correct DateTimeOriginal but have the wrong UTC -8 hours timezone (as seen in my SubSecDateTimeOriginal examples above).

I'll try to rewrite the timezones in my CR3s tomorrow and see if they work properly with -geotag after that.

In case it's useful, here's the -time:all output for one of the bad CR3 files:

Code Select Expand

exiftool -a -G1 -s -time:all /Volumes/.../R5PT5013.CR3
[System]        FileModifyDate                  : 2025:04:23 08:44:28-07:00
[System]        FileAccessDate                  : 2025:04:26 20:58:34-07:00
[System]        FileInodeChangeDate             : 2025:04:26 07:05:41-07:00
[IFD0]          ModifyDate                      : 2025:04:23 08:44:26
[ExifIFD]       DateTimeOriginal                : 2025:04:23 08:44:26
[ExifIFD]       CreateDate                      : 2025:04:23 08:44:26
[ExifIFD]       OffsetTime                      : -08:00
[ExifIFD]       OffsetTimeOriginal              : -08:00
[ExifIFD]       OffsetTimeDigitized             : -08:00
[ExifIFD]       SubSecTime                      : 96
[ExifIFD]       SubSecTimeOriginal              : 96
[ExifIFD]       SubSecTimeDigitized             : 96
[Canon]         TimeZone                        : -08:00
[Canon]         TimeZoneCity                    : Los Angeles
[Canon]         DaylightSavings                 : Off
[QuickTime]     CreateDate                      : 2025:04:23 09:44:26-07:00
[QuickTime]     ModifyDate                      : 2025:04:23 09:44:26-07:00
[Track1]        TrackCreateDate                 : 2025:04:23 09:44:26-07:00
[Track1]        TrackModifyDate                 : 2025:04:23 09:44:26-07:00
[Track1]        MediaCreateDate                 : 2025:04:23 09:44:26-07:00
[Track1]        MediaModifyDate                 : 2025:04:23 09:44:26-07:00
[Track2]        TrackCreateDate                 : 2025:04:23 09:44:26-07:00
[Track2]        TrackModifyDate                 : 2025:04:23 09:44:26-07:00
[Track2]        MediaCreateDate                 : 2025:04:23 09:44:26-07:00
[Track2]        MediaModifyDate                 : 2025:04:23 09:44:26-07:00
[Track3]        TrackCreateDate                 : 2025:04:23 09:44:26-07:00
[Track3]        TrackModifyDate                 : 2025:04:23 09:44:26-07:00
[Track3]        MediaCreateDate                 : 2025:04:23 09:44:26-07:00
[Track3]        MediaModifyDate                 : 2025:04:23 09:44:26-07:00
[Track4]        TrackCreateDate                 : 2025:04:23 09:44:26-07:00
[Track4]        TrackModifyDate                 : 2025:04:23 09:44:26-07:00
[Track4]        MediaCreateDate                 : 2025:04:23 09:44:26-07:00
[Track4]        MediaModifyDate                 : 2025:04:23 09:44:26-07:00
[Track4]        TimeStamp                       : 2025:04:23 08:44:26.96
[Composite]     SubSecCreateDate                : 2025:04:23 08:44:26.96-08:00
[Composite]     SubSecDateTimeOriginal          : 2025:04:23 08:44:26.96-08:00
[Composite]     SubSecModifyDate                : 2025:04:23 08:44:26.96-08:00


[Phil Harvey]

Yes, that's the difference.  The time zone is set incorrectly for SubSecDateTimeOriginal.  So the best option here is to use "-geotime<datetimeoriginal#" to use the system time zone instead.

Note that all of the QuickTime date/time tags are now incorrect as well.

But I don't think I would recommend rewriting the CR3's to try to fix this since the work-around is fairly simple and the repercussions of getting it wrong could be severe.

- Phil

P.S. I did find your mail in the Junk folder.

[ptdotme]

Excellent, thanks for your help!