Re: Time synchronization [was: GPS geotagging: first steps to implementation]

[Jan Girlich <vollkorn cryptobitch de>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Oooookay, let's go through this. Gonna be repetitive, but oh…

Am 11.09.2010 23:32, schrieb Michael Lissner:
> Paul is right, about the problems of remembering, of using multiple
> camera bodies

You can tell different camera bodies apart by the EXIF data of the
pictures. They include make, model and serial numbers. Also I would
recommend to do time correction only when importing pictures to f-spot
assuming you only import pictures of one camera at once.

> , and the ease of adjusting times with Lightroom etc.

Sorry, but I think adjusting times by calculating and entering a time
difference is a PIA.

> But the latter depends on knowing what you are adjusting TO

Always to UTC, saves you a load of trouble with time zones and summer
saving times but you can still display local times by supplying simple
information like the timezone the picture was shot in. With GPS data
this information can be retrieved automatically.

> , i.e., if
> I know my camera is set to PDT and I took those pictures in another
> time zone;  or if I know I took them at x time and the EXIF says y
> time.

Doesn't matter at all because you're calculating the time difference to
UTC and UTC is the same all over the world, no regards to summer saving
or anything else. So it doesn't matter at all what your camera is set to
as long as you don't change your cameras time setting and the time
difference is the same for all pictures.

My camera actually runs about three years, two months and ten hours
behind. No problem at all.

> Maybe the ideal solution would be something that syncs to GMT -- aka
> UT?

Coordinated Universal Time (UTC) is the term you're looking for. GMT and
UT (albeit the same) are outdated terms. And yes, it's the only sane
thing to do in my opinion.

> Then when I see whee my pictures were taken I can adjust the
> whole set by entering the place/time zone into LR, Flickr, whatever.

Exactly. And if you have GPS positions you can (automatically) correlate
with your pictures you can retrieve the time zone information
automatically and f-spot calculates the local time for you.

> GPS satellites broadcast a time signal:

Exacty, that's the basic principle GPS works on: time.

> Or: there
> are clocks that sync to the US atomic clock
> http://www.ntp-time-server.com/atomic-clock.htm -- might not work
> elsewhere but would work in US. Put a receiver in cameras?

There is a total of three radio time systems like this in the world and
devices which can handle all three of them. Mostly travel alarm clocks.
But there is no need for this because you can get the time from any
computer connected to the internet via NTP which is usually the case for
computers running f-spot and you can get timestamps from GPS data. Plus
radio receivers to be build into cameras is not a feasible solution.

>>> Having taken a lot of photographs across time zones and forgotten to change
>>> the time a number of times, I would agree with several of you -- the problem
>>> is remembering.

As I said before: Never change your camera time settings but instead add
time zone differences later. Then you only need to remember in which
time zone you took the pictures which is way easier to remember. Or use
GPS like explained above.

>>> If you can remember to fish out your barcode (or your
>>> charged smart phone), you can probably remember to change the time on your
>>> camera.

I suggest you only take one time correction photo for your whole
journey, never change your camera time setting and let your computer
calculate the local times later. See above.

>>> Given the variety of GPS-enabled models and add-ons out there, I
>>> also wonder how far away we are from all point and shoots and DSLRs being
>>> location-aware.
>>> One advantage to the system you describe would be syncing clocks across
>>> cameras  -- pros routinely shoot with multiple camera bodies and any
>>> disparity in the clocks can be frustrating in post.

Oh, yeah, it really is! One of the reasons I thought of this system.

>>> Then again, changing the
>>> time/date taken is trivially easy with any modern photo management software
>>> (Lightroom, Aperture, etc)..

Still a PIA if it has to be accurate by the second (done exactly this a
lot) and why not make it even easier?

>>> On Mon, Sep 6, 2010 at 9:11 PM, Michael Lissner
>>> <mlissner michaeljaylissner com> wrote:
>>>>>
>>>>> Yeah, the idea is to find something that works worldwide and also with
>>>>> your normal camera...seems like there ought to be a solution..

My solution works worldwide with any camera. All you need is a computer
with accurate time setting. This is where you get your time from.

>>>>> David wrote on 09/06/2010 03:57 PM:
>>>>>
>>>>> I would think something that read a public wireless - like the gps timing
>>>>> satellites - might be a more user-friendly solution.  Although I'm not
>>>>> up-to-date on the costs of those components.

I hardly doubt adding more hardware to this problem will help. All we
need is there we just need to use it the right way.

>>>>> On Mon, Sep 6, 2010 at 6:51 PM, Annette wrote:
>>>>>>>
>>>>>>> My first thought is that it sounds clunky, and unless I'm missing
>>>>>>> something here, you'd still have to set the time for the barcode generator.
>>>>>>> Aren't you just shifting the need to set the time to a different device?

Exactly right. You're shifting the time problem to a device you can
trust having the right time: your computer which is synchronized to an
atomic clock via NTP. Sounds good to me.

About the clunkyness: Why? All you do is go on a holiday/photoshoot/…,
shoot photos, get back home, take a picture of your computer screen and
import the photos from your camera. Done. You add one step to your
routine and remove adjusting the camera time or manual time correction
in post processing. If you add a reminder at import time people won't
even forget taking a picture of the barcode before importing.

>>>>>>> Moreover, depending on a user to photograph a barcode whenever they need a
>>>>>>> timestamp seems highly error prone. I think people would skip it or forget
>>>>>>> more often than not.

Well, this method is not meant to supply you with timestamps. It's meant
to correct a bunch of already existing timestamps of pictures at once.
If you forget it everything is as before and if you do it your
timestamps are accurate by the second. Nothing to loose here.

>>>>>>> Before you take some photos, or whenever you change time zones, you pull
>>>>>>> up a 2D barcode that encodes the current time, and take a picture of it.

Nope. You don't change time zones. Just gets you into trouble keeping
track. And you only take one photo of the barcode when importing.

>>>>>>> When you import your photos later, the program recognizes any picture
>>>>>>> with a barcode, and adjusts the time on all subsequent photos to that of the
>>>>>>> barcodes

As I said above. Do not change your camera time. Only one barcode photo
per import.

>>>>>>> An android/iphone app provides a secondary method of providing the
>>>>>>> barcodes to the camera

I wouldn't use a phone for displaying the barcode. Mobile phones are not
always accurate, but the time of the computer you import the pictures on
is, thanks to NTP.

>>>>>>> The advantage of this is that you never have to set the time on your
>>>>>>> camera again, the time zone data is adjusted for you properly, and the
>>>>>>> theory is that it's easier to deal with after the trip.

Exactly, so why were you confusing everyone by implying to take a lot of
barcode pictures and changing the camera time?

>>>>>>> To me, this idea seems to have potential, because I've struggled with
>>>>>>> this kind of thing many times, but I'm curious what others think about it,
>>>>>>> in terms of whether it's a crap idea, how to make it work, etc.

Hey, it's my idea, not crap. Genius! :P

Cheers
Jan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJMkpwvAAoJENNzD7MkeDIgtN0P/1HwbumquZmiQW2CM2uUahgq
JftOV3iUPkuvw9Z9fIHnV7wYJcIRYjjoCqwsmbMBjEfMvDBJumiSiLDodeafOYWW
HHpGn6GNMIInXDXS5/jUFlUfVfG5+M7uDDvWJs7u25qWoTj2rxqip7SdBIBLuyQk
lHHCp9/1MJLN47lGw3AE9RbiBFA4eDX9IRjNgFKbwDuQYynk5Ggpj3YbBQy0qwyl
NC3Il63GlH5ZTUnuoDmKMrZbq/E8A40xihnyh4s02nWo5K1HOiP1lX4Ke1qFgts4
Mb+WjXxTRbg5isD93WXl/6VDRuxn34weDnKa6GLS1ptTswySviYbKc8LQWC7N6Lk
3LjOmDcL9x6UIHoIIkPAEAWmkkvReZkUkRYu+4BcHc42+neHcky2DTOvPKFeCZlT
vIOL8uhHWmvmhGDzOffCRXPEiP38/fQNPlwrSEcvVHKoBviDWLqvpRoKeqeymxKw
Ud94Oc3g9SWpYNKHMpVwopEV5YcVYFRHRvaTENxvcZwMTZvwkNA4k3UIjZbIYdlL
qpf80NVohiPT6JYID7iQCvF78D0JMGRW0+PkR5IwWA+4cpFyM58Ir0XAXsNrqg0F
GXwg/nLLd/bYIMi6F5epFoqtAwcnTFlzSoMnoCFh/QVNzpOvuVVChhU3UVDBzUxl
uvUS6Ahhqe8nM4Um6F2g
=eU73
-----END PGP SIGNATURE-----