Timing issue
leszekp
Just tried out GPicSync (0.95) for the first time, and after getting
through some minor timing problems, it works really well - thanks for
making it available. Here's the trouble I had with it:
- My time zone is Arizona (UTC -7, no daylight savings). My camera is
set to record at that local time.
- My GPS records track points at the UTC time, seven hours ahead of
local time. And there's no way to set it to record the tracks at local
time (Garmin 60Cx).
- I took a walk on May 11 starting at about 18:30 local time, taking
pictures and logging a track. The picture times were recorded as
having occurred at local time on May 11th, while the GPS track times
were recorded as having occurred at UTC, seven hours later, on May
12th.
- I ran GPicSync, setting the UTC offset at -7, with a time difference
of 120 seconds, and "Dates must match" checked. I then selected the
folder with the pictures, and the correct GPX file, and hit
"Synchronise".
- GPicSync told me that there was no track point at this picture date,
and didn't sync any of the pictures.
- If I unchecked the "Dates must match" box, the time difference given
was enormous (86400 seconds, the number of seconds in a day).
- If I put 17 hours in for the UTC Offset (-7 + 24), and kept the
"Dates must match" box unchecked, GPicSync was able to sync the
photos, but gave the error message "Warning: Picture date 2007-05-11
and track point date 2007-05-12 are different ! "
- I tried using the "Local time correction" option, but that didn't
fix the problem.
So I think that the program is subtracting the UTC differential
correctly, but isn't compensating for the change in date if the date
you take the pictures is already tomorrow in UTC. I think this should
be easy to fix.
Also, it's great that you have the option to backup the pictures, but
would it be possible to append "_original" to the filename and not the
extension? In other words, write the backup to 1.jpg as
1_original.jpg, not 1.jpg_original? The way it works now, you have to
manually change the jpg_original extension to jpg in order to be able
to open the backup image.
Other than those two minor issues, the program works great. Thanks
again.
Leszek Pawlowicz
francois schnell
I'm aware of this particular case which is briefly mentioned in the
GettingStarted page where I also encourage people to use the
"universal way" to set the GPS (it gives lots of advantages, see
below).
I'll make the necessary changes and tests soon (I need to make few
changes in the way the sync is structured to perform date operations).
"""
1) Set your GPSr and camera
Two possibilities here.
a) Universal way (preferred)
If you didn't change its setting, your GPSr records the track log with
the GMT time (Greenwich Meridian Time) also know as UTC (Universal
Time Co-ordinated). Set the time of your camera to GMT. You can see
actual the GMT time at the bottom of this webpage (be precise at the
second level):
http://wwp.greenwichmeantime.com/
Setting your camera to GMT is the prefer way since you won't have any
problems for summer/winter time or when you travel through time zones.
You also don't need to give the UTC offset each time you use GPicSync
since it is at 0 by default.
Also check set the camera date if necessary.
b) Local way
Set the local time precisely to the same local time indicated by the
GPSr. Also check the camera date if necessary (avoid to use "date must
match" option in this mode for early morning or late evening pictures
with important UTC Offset).
On some GPS it is possible to set the recording track log time to the
local time of your country. In this case you won't need to indicate an
UTC offset latter to GPIcSync and it also works well in all
situations.
""""
I'll also see soon for renaming the backup files (for now it is
renamed automatically by the Exiftool library I'm using).
Thanks
francois
Blomberg
don't. I'll have to look into this more.
I'm also in Arizona and have a garmin 60csx. I'll run a test later
today.
francois schnell
Ive now made made some changes to the code but I would like some data
to test it.
Could you send me a track and two pictures which typically didn't work
before in the case explained by leszekp.
Thanks!
francois
--
Francois Schnell
http://francois.schnell.free.fr
leszekp
I have sent you the GPX track and three pictures from the set I've
been working with.
I had thought of setting the camera time to UTC, but remembering to
switch from local to UTC and back increases the odds of getting things
wrong. I think it makes more sense to modify the program to handle the
issue.
I'd actually prefer to have my GPS do tracks and waypoints using local
time instead of UTC, but I can't seem to find a way to set my Garmin
60Cx to record tracks in local time instead of UTC. If anyone knows if
this is possible, I'd like to hear it.
Leszek
On May 13, 11:32 am, "francois schnell" <francois.schn...@gmail.com>
wrote:
> Hello leszekp and Bloomberg,
>
> Ive now made made some changes to the code but I would like some data
> to test it.
>
> Could you send me a track and two pictures which typically didn't work
> before in the case explained by leszekp.
>
> Thanks!
>
> francois
>
francois schnell
>
> I have sent you the GPX track and three pictures from the set I've
> been working with.
Great, thanks for the data !
>
> I had thought of setting the camera time to UTC, but remembering to
> switch from local to UTC and back increases the odds of getting things
> wrong. *I think it makes more sense to modify the program to handle the
> issue*.
>
Sure that's why I said in the previous post:
"""
Ive now made made some changes to the code but I would like some data
to test it.
"""
Nevertheless if your concern is :
""" remembering to switch from local to UTC and back increases the
odds of getting things wrong. """
I would argue that the UTC way is better for this in my opinion:
- Your GPS already record in UTC
- You won't have any timezone problem when you travel in your country or abroad
- You won't have to go back and forth about daylight saving schemes
- You won't have to fill the UTC offset field each time
In fact once you set the camera to UTC there should be no more "back
and forth".
Nevertheless I do understand some people prefer to use local time in
all cases, after all it's very natural and that's a very good
argument. :)
Concerning your data it worked fine with "dates must match" on my tests.
You can find a temporary build below and I would appreciate if some
people can make some tests and tell me if they encounter problems (I
had to make lots of change in synchronization part the code). in
particular if anyone has some data in "early morning" with "important"
positive UTC offset it would be great.
The latest temporary build:
http://francois.schnell.free.fr/gpicsync/temp/
Thanks!
francois
leszekp
>
> I would argue that the UTC way is better for this in my opinion:
>
> - Your GPS already record in UTC
> - You won't have any timezone problem when you travel in your country or abroad
> - You won't have to go back and forth about daylight saving schemes
> - You won't have to fill the UTC offset field each time
Well, if I lived in a timezone as close to UTC as yours, I'd probably
agree :). I haven't traveled more than an hour out of my timezone in
years, so I never bother to re-set my watches or camera time. Arizona
is also one of the few states in the United States that doesn't go on
daylight savings, the theory being that in Phoenix, the earlier the
sun goes down, the earlier the temperature will start to drop below
40C (no that's not a mistype).
I've installed and run the latest version of your program using a
larger set of photographs, and it worked perfectly with the offset at
-7 and the Dates box checked. Thanks!