I am wondering how to correct for camera clock drift, but without changing the GPSDateTime tag.
The situation is that I am planning to rename images with the flowing format:
GPSDateTime_ABC_XYZ_OriginalFileName.ext, in which ABC identifies the photographer and XYZ identifies the camera. (I decided to keep the filename in order to deal with sub-second sequences and to help in case of disaster.) I would do this from the DateTimeOriginal tag since most images don't have GPS tags written, and I would need to adjust for local time zone since I keep my camera on home time.
However, I then realized that because some of the cameras in use have quite significant daily drift (around 1 s/d), I need to correct camera clock drift in order to ensure proper sequencing between several cameras in use over the same period. I was thinking that I could correct this by using a combination of -geosync to interpolate between two specified drift-corrected times, and -geotag=DATETIMEONLY. As I understand the documentation, for my images the interpolations would be based on DateTimeOriginal and GPSDateTime, though I'm not sure what happens when there is no GPSDateTime recorded.
However, I then became aware of another issue. On images taken on a smart phone the GPSDateTime is the time of the last GPS reading, and in general this differs from the DateTimeOriginal tag. I have found such smartphone GPS tags useful for creating track logs by inverse geotagging, and therefore I don't want to change the GPSDateTime recorded tag while I am correcting the drift on the DateTimeOriginal tag.
Is there a way of doing this, or have I missed something?
The -geotag feature has the ability to correct for camera clock drift. Read the Geosync (https://exiftool.org/geotag.html#geosync) section of the geotag page for details. Specifically, read under "Camera clock drift correction:" in that section. You would use two -geosync options to correct for a linear drift, or more if the drift is non-linear.
- Phil
Maybe I misread that section, but I got the impression that both the GPS time and the image time were interpolated. Is this correct?
I had in mind interpolating the image time, but not the GPS time.
However, my question is probably redundant because, as I belatedly realized, the case I had in mind, involving smartphone images with differing GPS and image timestamps aren't likely to be subject to clock drift.
Two interpolations are performed.
The camera clock drift is interpolated between the specified geosync points, and the corrected time is used to interpolate within the GPS track to find the position.
- Phil
Thanks for the clarification of clock drift correction, Phil.
The situation that led to my post arose from cell phone images in which the recorded GPSDateTime differs significantly from the image DateTimeOriginal. I now realize that in this case the GPSDateTime is actually the time of the last location estimate based on cell tower locations, and shouldn't be classed as a 'real' GPS location. However, it can be used with inverse geotagging to make a (crude) track log.
I understand that geotagging from this track log will overwrite the cell tower location data (recorded in the EXIF data), with interpolated values based on DateTimeOriginal (which on a cell phone would not be subject to clock drift).
Is this correct?
Quote from: e2b on October 19, 2019, 11:48:32 PM
I understand that geotagging from this track log will overwrite the cell tower location data (recorded in the EXIF data), with interpolated values based on DateTimeOriginal (which on a cell phone would not be subject to clock drift).
You could probably copy back the original GPS tags that you want to preserve when doing the geotagging. I haven't tried this, but should work.
- Phil
Thanks Phil.
After some reflection, I think it would better to save the track log created by inverse geotagging as a separate file (as is produced by a GPS data logger) and then overwrite the location data in the image EXIF data. I think it makes more sense to have the GPSDateTime and DateTimeOriginal the same, except for the time zone difference. But maybe I haven't thought it through sufficiently ...
Sounds reasonable.