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

[Michael Lissner <mlissner michaeljaylissner com>]

 Great response Jan.

I guess something I didn't understand about this was that the photos from the
camera remain in UTC at the end of this process. That seems strange to me
because while that's an accurate representation of the time, it's not a time
that's useful for people -- it gives the picture very little context. This might
be good for photographers, but as a normal camera user, I'd be annoyed if my
picture of the sunset had a timestamp of 6am (or similar), even if I knew there
was a good reason for it.

I also didn't realize that the barcode pictures could be taken at any time
before or after a series of pictures was taken. That's interesting, and makes me
think that there may be no need to take the barcode picture except for once per
camera, right? Then, F-Spot could identify the camera each time there was an
import, and forevermore make the needed correction? That would work so long as
the time on the camera didn't change along the way, which is most-likely
wouldn't, right?

Interesting stuff,

Mike


Jan Girlich wrote on 09/16/2010 03:37 PM:
> 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