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

[Michael Lissner <mlissner michaeljaylissner com>]

 Here's the result of my questioning a mailing list that has a ton of
camera-toting UX people. Sorry for the length, and I've snipped some personal
info. Hope it helps.

Michael Lissner

--------------------

Paul is right, about the problems of remembering, of using multiple
camera bodies, and the ease of adjusting times with Lightroom etc.
But the latter depends on knowing what you are adjusting TO, 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.

Maybe the ideal solution would be something that syncs to GMT -- aka
UT?  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.
GPS satellites broadcast a time signal:
http://www.ntp-time-server.com/ntp-server/ntp-server.htm.  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?



On Mon, Sep 6, 2010 at 9:25 PM, Paul wrote:

> > 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. 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. 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. Then again, changing the
> > time/date taken is trivially easy with any modern photo management software
> > (Lightroom, Aperture, etc)..
> >
> > 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...
>> >>
>> >> Michael Lissner
>> >> mlissner michaeljaylissner com
>> >>
>> >> 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.
>> >>
>> >> 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?
>>> >>> 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.
>>> >>> -Annette
>>> >>>
>>> >>> On 9/6/10 12:13 PM, Michael Lissner wrote:
>>> >>>
>>> >>> A project I'm peripherally involved in is talking about using 2D barcodes
>>> >>> to synchronize the time between a computer and a camera. The idea is this:
>>> >>>
>>> >>> 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.
>>> >>> 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
>>> >>> An android/iphone app provides a secondary method of providing the
>>> >>> barcodes to the camera
>>> >>>
>>> >>> 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.
>>> >>>
>>> >>> 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.
>>> >>>
>>> >>> Thoughts?
>>> >>>
>>> >>> Mike
>>> >>>
>>> >>> --
>>> >>>
>>> >>> Michael Lissner
>>> >>> mlissner michaeljaylissner com


Jan Girlich wrote on 09/07/2010 01:51 PM:
> Am 06.09.2010 21:00, schrieb Michael Lissner:
> >  This /is/ a really interesting train of thought, and as somebody that has spent
> > days (literally), trying to correctly adjust times on my camera, it's very
> > compelling to me. I worry though that the learning curve is too steep.
>
> That's right. But that's also true for processing RAW pictures, but some
> people want it ;) I think implementing it as an extension is the way to
> go so people who want it can actively choose to use it.
>
> Also, a good explanation for the user might be helpful. I imagine
> - a good helpfile
> - a wizard-like guidance for the first couple of times
>
> > I'm not sure people will understand why taking a picture of their computer would
> > somehow affect the timestamps on their photos, especially if they were taking a
> > picture of a barcode.
>
> As I said above, let's make it a pro-user extension then.
>
> > Maybe a thing that would make it more obvious would be to
> > have a screen where half of the picture was the current time (something that
> > makes sense to humans), and the other half was the barcode (for the computers).
>
> That's a good idea, but there is no need to sacrifice half the screen.
> Most 2D barcodes are usually square, so you have about 1/4 of the screen
> free anyway. Vertically, though, but big enough to show an help text and
> the encoded time.
>
> > I'm also concerned that I wouldn't use the feature because I wouldn't expect to
> > have my computer near me when I remembered to set the time on my camera, so
> > maybe a matching iPhone/Android app should be made?
>
> Well, I used a prototype (doesn't work with the 0.6.x line anymore) for
> a while and got used to it really quickly. And seriously: Never ever
> change your cameras timesetting at all. Leave it at UTC for every summer
> savings period or time zone. Local times should be derived from your GPS
> positions automatically. Saves you a lot of trouble.
>
> I really like the idea of an app so you can take a time correction
> picture where ever and whenver you want!
>
> > Another question I /know/ I'd have if I used this feature would be how the time
> > zone setting on my computer/phone would affect the time stamp on the
> > camera/photos.
>
> Not at all. How could it possibly do so?
>
> > I'm not an expert on EXIF, so I don't know whether JPEGs,
> > cameras, f-spot, nautilus, etc. support it, so I'd be worried that would be
> > messed up somehow. Again, maybe showing the time zone on the barcode screen (if
> > it's encoded) would make sense?
>
> You won't use timezones. This whole thing should only work in UTC to
> avoid tons of hassle. The local times should be derived in a second
> step, after the time correction, from the UTC times, the GPS data and a
> database with the time zones and summer saving times. Those information
> are freely available in the internet.
>
> The EXIF part is no problem. All you do is reading and writing the time
> in the header.
>
> > A mock up or sketch of how this would look would make things gel much more, I
> > think, though I'm terrible at making these things. I'll bounce this off some
> > people, and see if anybody has any ideas...
>
> I'll create a mockup. And some flowchart or similar to better explain
> how I imagine this to work.
>
> Cheers
> Jan