PDA
View Full Version : Camera sync - timezone
glz
March 14th, 2006, 11:02 AM
I am looking at Downloader Pro and will get it just for it's filehandling stuff but I have a question about the camera syncronizing function .
The problem I have is that the timezone of a camera can't be different from the PC, but my cameras are on UTC while my PCs may be in any timezone. This to make sure I never have any problems with summer time or forgetts setting time when I move from one timezone ot another.
Is a drop-down for the camera timezone something that could make it's way into a future DP? Or a checkbox for 'Use UTC for camera timezone'? The later would be sufficient, as all people I know about that don't run local time in there cameras run them on UTC.
/glz
Chris Breeze
March 15th, 2006, 08:30 AM
I'm not sure that it's worth adding this. Surely the time a picture was taken only really makes sense if it is local time otherwise to work out the time of day a picture was taken you need to know the time zone and whether DST was in operation. I occasionally forget to change the time on my camera when I change timezone and when this happens I use BBPro's date/time adjust feature to correct it after downloading.
glz
May 11th, 2007, 06:19 PM
Hi,
I would expect this to be a more acute now that GPS tagging is added, given the fact that the GPS tags are in UTC.
/glz
metsfan
May 15th, 2007, 08:36 PM
I'd also like this feature. Here's my (planned) setup...
Keep my camera on UTC, always.
Use Downloader Pro to copy to from my card to my computer, and GPS tag.
Import into Lightroom.
My folder structure is set up by date... 2007\05\15 for today, for example. I use Lightroom to create that structure, not Download Pro. Since my camera is on UTC (and I'm in California), anything taken after 5PM is dated tomorrow, but I'd like it in a folder dated today. In Lightroom, I can make the timezone adjustment, but then I still have to move the images to the right folder.
Ideally, what I'd want is a popup dialog that comes up when I click Download that will ask me what offset from the camera time to use, and adjust the times appropriately. That way, when I import into Lightroom, it creates the folders the way I want. Also, by being a popup, it means I won't forget when I import (the same reason I leave my camera on UTC... I'll never remember to change it every time I travel.)
Chris Breeze
May 16th, 2007, 09:38 AM
It's an interesting suggestion but I don't think it is quite a simple as just applying an offset to the file timestamps from the camera. To do the job properly the timestamps of the files and the date/time in the shooting data would also need to be adjusted as the files are downloaded. In theory this would be possible but it is certainly not a trivial change.
metsfan
May 16th, 2007, 06:29 PM
It's an interesting suggestion but I don't think it is quite a simple as just applying an offset to the file timestamps from the camera. To do the job properly the timestamps of the files and the date/time in the shooting data would also need to be adjusted as the files are downloaded. In theory this would be possible but it is certainly not a trivial change.
That is what I want, though. Really, I'd like it to work like Lightroom's "Adjust Capture Time" feature, but happen before I do my import. It seems the way that feature works is it leaves the DateTimeDigitized alone, but changes DateTimeOriginal to the updated time. I don't know what it does with the timestamp on the file, but I'm not terribly concerned about that.
To be really cool, it could look at GPS data, figure out timezone (and DST) from the location, and adjust the DateTimeOriginal accordingly... but I don't expect that anytime soon. :)
Regardless, I'll probably but Downloader Pro after my trial is up. It just makes the GPS tagging so easy (w/Sony GPS-CS1, vs gpsbabel/gpsPhoto.pl).
keff
May 16th, 2007, 10:12 PM
I do hope that if any changes of this nature are added to DLPro, then that they be optional, and configurable before downloading.
To me, a vitally key feature of DLPro is that I can plug in a card in a pressure situation, and without any thinking, the files are downloaded as quickly as possible. I don't want any distracting popups that give me the slightest possibility of messing up a download. I am also concerned that increases to DLPro functionality will lead to larger (and slower) executables, and that the inherent increase in code complexity reduces the reliability of the code, and also its maintainability. DLPro shoukld be kept "lean and mean".
If I want to do any "fancy" stuff, that can be done after download, not part of the download.
Steve
Clive
May 16th, 2007, 10:53 PM
Exactly my thoughts, too.
DavidB
May 16th, 2007, 11:32 PM
This is turning into a significant exchange, with wider implications.
Firstly, I think that Chris is right to say that what is being requested is not trivial (and therefore, by implication, requires further thought). It's our data he's talking about, after all.
Secondly, I understand why the many users of DLP 2.0 who are making use of its geo-data handling capabilities might want it to recognise and use UTC timestamps. If this can be provided as an option, fine.
However, like keff and Clive, I believe that DL Pro's strongest suit is the level of idiot-proofing it provides. We all know that it is difficult to make things foolproof, because fools are so clever, but DL Pro has a damn good try. Speaking as a fully paid-up member of the Fools' Union, I need things to stay that way.
It does seem to me that there is a bit of a tendency to want DL Pro to function as a workflow management application like BB Pro, or to want everything done on download. In practice, even allowing that different people will need different work flows, I think that there is a good deal to be said for getting the original image files safely on to the hard drive without too much pre-processing, and then taking things from there.
SamDring
May 17th, 2007, 06:26 PM
In response to the last few topics (warnings) one of the first things I did with DLP was to use it to completely reorg all my old folders and file naming conventions i.e. using Downloader NOT to download:) . I have advocated this use many times since and am sure many others do it. This may be off beam but enhancements of the nature requested could be activated ONLY when source drive is not removable?
metsfan
May 17th, 2007, 06:27 PM
This is turning into a significant exchange, with wider implications.
Firstly, I think that Chris is right to say that what is being requested is not trivial (and therefore, by implication, requires further thought). It's our data he's talking about, after all.
Secondly, I understand why the many users of DLP 2.0 who are making use of its geo-data handling capabilities might want it to recognise and use UTC timestamps. If this can be provided as an option, fine.
However, like keff and Clive, I believe that DL Pro's strongest suit is the level of idiot-proofing it provides. We all know that it is difficult to make things foolproof, because fools are so clever, but DL Pro has a damn good try. Speaking as a fully paid-up member of the Fools' Union, I need things to stay that way.
It does seem to me that there is a bit of a tendency to want DL Pro to function as a workflow management application like BB Pro, or to want everything done on download. In practice, even allowing that different people will need different work flows, I think that there is a good deal to be said for getting the original image files safely on to the hard drive without too much pre-processing, and then taking things from there.
I agree with all this, and obviously wouldn't want it to force anything on anyone. It should be an option to use any of this, and probably off by default, of course.
I don't want everything to be done on download, but it seems like a lot of people probably use time/date for filenaming or folder structure, and it seems like a very useful thing to be able to fix before importing into any workflow tool. At this point I'm positive I'll be buying DLPro anyway, so this is just a "would be nice" feature request.
DavidB
May 17th, 2007, 09:58 PM
I agree with all this, and obviously wouldn't want it to force anything on anyone. It should be an option to use any of this, and probably off by default, of course.
This is now, I think, common ground, and that's good.
I don't want everything to be done on download, but it seems like a lot of people probably use time/date for filenaming or folder structure, and it seems like a very useful thing to be able to fix before importing into any workflow tool. At this point I'm positive I'll be buying DLPro anyway, so this is just a "would be nice" feature request.
One of the things I have learned from the discussions about DL Pro 2.0's geo-data handling capabilities is that the accuracy of timestamps is quite significant. BB Pro actually provides a really powerful tool for adjusting image timestamps, which (like Clive, for instance) I find really useful when dealing with multi camera shoots. I find that things like this need to be handled methodically (because DB=fool), so it pays me to keep the initial download simple. Other people's mileage will vary.
One way of reducing pressure is, as SamDring says, to use the DL Pro capability to 're-download' images. This allows you to deal with the handling of geo-data at a later stage, when, for example, you have fixed any dodgy timestamps. You wouldn't necessarily do this every time, but the capability can be a life-saver when things get uncomfortably complex.
That said, I agree that your feature request is reasonable in itself, and it may be significant that Chris describes it as 'interesting'!
jtk
May 18th, 2007, 01:33 PM
Hello,
before I looked at DL I had a look at OziPhotoTools and I liked the way they correct the time. You take a picture of the GPS-Screen of your PDA or so where the time of the GPS is shown and in OziPhotoTools you load the pic in a time-correcting-window where also the Exif-time of the file is shown and so you can easily correct it for the download.
(Excuse my bad English, I'm German)
Greetings
Thomas
Powered by vBulletin™ Version 4.1.2 Copyright © 2011 vBulletin Solutions, Inc. All rights reserved.