Showing posts with label hardware. Show all posts
Showing posts with label hardware. Show all posts

Tuesday, March 27, 2012

What do you do with your camera clock time in relation to time zones?

Question

I live in the UK and spend most of my time here, apart from a short trip abroad once or sometimes twice a year.

This Sunday just gone we switched from GMT to BST, so our clocks went forward one hour. I updated my camera clock to match the new time, which is something I do every time the clocks change but someone said to me that this was a bad idea and that I should just leave it on GMT/UTC all year around. I guess this is partly due to GPS tracking (although I would normally use my iPhone which automatically updates it's time, so I need to sync my camera with my phone before I begin ideally).

I like the idea of updating my camera so it's on local time wherever I am in the world, but of course there is always the possibility of forgetting to do this. In the summer we are off on Honeymoon and will be in several different time zones, so the question is should I just make an effort to remember to update my clock time as I go, should I just leave it on GMT/UTC or is there a better way?

I am genuinely interested in what other photographers do to tackle this issue, especially with regard to travel and spending a few days at a time in different time zones.

I would also like to know how people handle the metadata when posting images online as the metadata could indicate a photo was taken on a different day due to a time zone mismatch. Also when reviewing photos I think it is often useful to know the times they were taken, especially with regard to sunset and sunrise, so knowing the accurate time can be important. Do you just have to manually work it out or is there considered to be a 'best practice' approach to dealing with this.

Very much looking forward to reading your responses.

Asked by Mark J P

Answer

I like to have date and times on photos reflect local times and date at the location.
Unlike another respondent, I like to be able to search for a photo tane "at out 3pm on the Thursady afternoon when I was in Xian" and, while there are other ways of cataloging and ordering, being able to search on local date and time is a bonus.

Travel from NZ involves long international flights (8-12 hours typical range unless going to Europe.)

I (try to remember to) change the camera date on the flight and change my wristwatch at the same time and take a before and after photo of the watch sequentially so I have a visual reference to the actual time of change in the photo stream.

Outbound from NZ the camera steps back in time so some photos will be out of time/date order. Majing the change early in the flight minimises the impact if I care. eg China is 5 hours behind NZ and is ~ 8-10-12 hours flight time (Hong-Kong / Shanghai / Beijing) depending also on route so the time impact on photo date-sort order is usually minimal.

In the past I used to assign a long file name prefix based on properly time ordered date.
Effecively YY MM DD HH SS in compressed form. It was useful but not so much so that I kept it going.

Related:

Fixing corrupted file date & time: Due to Microsoft's cavalier handling of file date & time format when copying from cameras to hdd you can find time offset by 12 hours and date by one day or both, on occasion. Confusing day and month is another sometime Microsoft specialty due to NZ using ddmmyy format as opposed to the usual US mmddyy format. Use of an EXIF to file date-time copying program fixs this. I use the excellent free jhead progran to do this.
Running "jhead -ft %1.jpg" in a [gasp!] DOS batch file will correct the date time to that shown in the EXIF for all files in a "folder". I believe that Microsoft Powertoys synch manager does this too but I have never tried it.

Travelling backup: I use the venerable and marvellous XXCOPY to incrementally copy in files from camera card to a netbook. When in tourist mode I carry the netbook everywhere and may download from camera card several times during the day. [Just because you are excessively paranoid about data loss it doesn't mean your cards won't fail :-)]. When XXCOPYing I change the archive attribute bit in the process, so that uncopied files can be identified, thus allowing an only-new files download incrementally AND leaving a backup copy on the camera card. I then copy from netbook to portable hard drive (possibly also during he day) and only then, if required, delete files on camera card. [On one journey I lost two of my 3 copies of photos (vanished with no clues, probably stolen) and still lost no photos.

Answered by Russell McMahon

Sunday, January 8, 2012

Is it normal for memory usage in Lightroom 3 to exceed 1.5GB, and what can I do about it?

Question

I'm currently running a 2008 unibody 15" MacBook Pro 2.53 with 320GB 5400 RPM hard drive and 4GB of system memory. I've upgraded to Snow Leopard and I'm running Lightroom 3 (64-bit).

I have two problems with my setup currently and I'm seeking recommendations on improving the situation:

  • memory usage during processing exceeds 1.5GB
  • time to move between images in Develop module is painfully slow

I've noticed that system memory usage typically goes up drastically during export to JPEG. Is this normal and how much memory is normal? It seems the larger the set of photos being exported, the greater the amount of memory is needed. I often find myself staring at Activity Monitor and shutting down all other applications to free up as much RAM as possible.

Then switching photos in the Develop module takes ages for me. I think this is a disk related issue so I'm thinking new larger 7200 RPM hard drive should sort that out. The current hard drive is a Hitachi 320GB 5400 RPM drive and it often seems to be the bottleneck when installing applications and writing data.

Any recommendations?

Answer

yes, that memory usage is normal converting to jpeg.

I"m finding 4Gig works fine. A few suggestions.

upgrade your drive to a 7200 drive. you're probably seeing I/O delays and a faster drive will help.

preferences->file handling, set the cache to a larger value. I use 25 gig.

optimize your catalog (under the file menu) every so often.

system performance will lag as your memory set grows. You can check /var/vm (using terminal):

[chuq-laptop:~] chuqui% cd /var/vm [chuq-laptop:/var/vm] chuqui% ls -l total 8912896 -rw------T 1 root wheel 4294967296 Aug 6 12:14 sleepimage -rw------- 1 root wheel 67108864 Aug 4 21:57 swapfile0 -rw------- 1 root wheel 67108864 Aug 7 16:57 swapfile1 -rw------- 1 root wheel 134217728 Aug 8 13:53 swapfile2 [chuq-laptop:/var/vm] chuqui%

if you see more than 3-4 swapfiles, you'll speed things up by rebooting and re-initalizing VM. If you haven't rebooted for a while, you may see 6-7 files especially if oyu've done a lot of image work, and that slows down the paging system (again, a 7200 RPM drive as your boot drive helps this as well...)

Mac hardware recommendations for Lightroom 3

Question

I'm currently running a 2008 unibody 15" MacBook Pro 2.53 with 320GB 5400 RPM hard drive and 4GB of system memory. I've upgraded to Snow Leopard and I'm running Lightroom 3 (64-bit).

I have two problems with my setup currently and I'm seeking recommendations on improving the situation:

  • memory usage during processing exceeds 1.5GB
  • time to move between images in Develop module is painfully slow

I've noticed that system memory usage typically goes up drastically during export to JPEG. Is this normal and how much memory is normal? It seems the larger the set of photos being exported, the greater the amount of memory is needed. I often find myself staring at Activity Monitor and shutting down all other applications to free up as much RAM as possible.

Then switching photos in the Develop module takes ages for me. I think this is a disk related issue so I'm thinking new larger 7200 RPM hard drive should sort that out. The current hard drive is a Hitachi 320GB 5400 RPM drive and it often seems to be the bottleneck when installing applications and writing data.

Any recommendations?

Answer

yes, that memory usage is normal converting to jpeg.

I"m finding 4Gig works fine. A few suggestions.

upgrade your drive to a 7200 drive. you're probably seeing I/O delays and a faster drive will help.

preferences->file handling, set the cache to a larger value. I use 25 gig.

optimize your catalog (under the file menu) every so often.

system performance will lag as your memory set grows. You can check /var/vm (using terminal):

[chuq-laptop:~] chuqui% cd /var/vm [chuq-laptop:/var/vm] chuqui% ls -l total 8912896 -rw------T 1 root wheel 4294967296 Aug 6 12:14 sleepimage -rw------- 1 root wheel 67108864 Aug 4 21:57 swapfile0 -rw------- 1 root wheel 67108864 Aug 7 16:57 swapfile1 -rw------- 1 root wheel 134217728 Aug 8 13:53 swapfile2 [chuq-laptop:/var/vm] chuqui%

if you see more than 3-4 swapfiles, you'll speed things up by rebooting and re-initalizing VM. If you haven't rebooted for a while, you may see 6-7 files especially if oyu've done a lot of image work, and that slows down the paging system (again, a 7200 RPM drive as your boot drive helps this as well...)

Are flashes really subject to a “use it or lose it” problem?

Question

I was just reading the manual that came with my new flash and stumbled over this warning:

14.3 Flash capacitor forming
The flash capacitor built into the flash unit undergoes physical change if the unit is not switched on for a prolonged period. For this reason it is necessary to switch the unit on for approximately 10 minutes at least once every three months.

WTF‽ Is this seriously a problem? How long does a flash have to site idle before it has issues?

What kind of issues would I see? slower recycle times? inability to recycle? Total failure to power on?

Answer

With electrolytic capacitors, disuse can cause slower discharge, and longer recycle times, which can be restored by firing and recycling the flash a few times.

If you don't use them for a long period, the non-conducting dialectric can break down to the point they will short circuit.

Periodically turning it on will charge the conductive plates and this will prevent the dialectric from breaking down.