Gav's Blog

I have just submitted the following feature request to Adobe. I think it would be fantastic to have the option to let Lightroom automatically manage all files and folders using the capture time metadata field. This approach doesn’t make sense to everyone, but for those that manage their files by date and time, I believe it makes good sense.

Update – amusingly, Adobe limit their submission form to 2000 characters, and mine was about 3600. So I split it in two!

*******Enhancement / FMR*********
Brief title for your desired feature:
Provide configuration option to allow Lightroom to automatically manage files and folders by date and time metadata.

How would you like the feature to work?
1. Lightroom Preferences. I believe there should be a preference option that allows LR to automatically manage all folders and files in a catalogue. In the preferences the user would be able to set the following policies that are applied to all images.

1a. Folder structure – determine the folder structure e.g. yyyy/yy-mm-dd/
1b. File name – determine file name e.g. yyyymmdd-hhmmss-n
1c. Manual or Automatic update – determine whether changes are made immediately when date/time metadata is adjusted (Automatic) or if a user-initiated refiling is undertaken only when the user manually starts the process (Manual). Recommended default should be Automatic (e.g. immediate) updates.
1d. Time field – probably want to default to capture time. Not sure if this approach is useful for other times.

2. When a user imports images using ‘automatic file management’ the file handling import option is greyed out, and indicates that it is being automatically managed and shows the file/folder naming structure selected in the preferences. All other relevant import options are made available.

3. When a user edits date/time information in any way, upon saving the metadata, the image filename, and if necessary the folder it is located in is adjusted to represent the new date/time metadata (Automatic). This results in immediate refiling of the photo when the date/time is adjusted. Otherwise, the image stays in the same location until such time as the user interactive tells Lightroom to refile all images based on their current capture date/time (Manual).

4. If the user opts to change the filing policy set in the preferences – Lightroom should support a complete refiling of the library. E.g. if the directory policy is changed from yyyy/yy-mm-dd/ to yyyy/mm/dd/ then Lightroom should prompt the user to restructure the whole library now under the new policy, and indicate that this may take some time depending on the size of the library

5. Provide an option to check and refile all images that are currently selected (whether in grid, or by folder). This would allow the user to force a manual refile immediately. This option should of course only be visible to users that have enabled automatic filing.

Why is this feature important to you?
I would like to avoid having to manage names and locations of files and folders. I would like to optionally configure Lightroom to fully manage the names and locations of all folders and files. As long as I can define a policy for how the folders and filenames are structured, I am not concerned about having full control over the filename and location. I would like the image metadata to determine where it is stored on the hard drive.

As Lightroom currently stands (v2.3) when the capture date/time is adjusted, the file retains the imported time (which is clearly incorrect) and possibly is stored in the wrong folder (if the time adjustment has been across midnight). This is particularly an issue with travel photos.

It would be very nice to have the option to have all this managed automatically and transparently by Lightroom. Of course this should be an opt-in process only, as it really makes sense for uses that manage their photos using date and time. Conceivably, it may be possible to have Lightroom manage files and folders using other forms of metadata automatically in future, but I believe date and time makes the most sense to start with.

Just filed this bug with Adobe. Hopefully they will fix it to provide better timezone adjust support. The current workaround is very unintuitive.

Update: Just to clarify, this is only about changing the second option (time zone adjust) in the adjust time dialog. There are a number of countries that work on 30m TZ offsets – Alaska, a number in South America, Middle East, the Pacific. There is a good table available on this page from the US Naval Observatory.

******BUG******
Concise problem statement:
Timezone adjustment does not support all timezones.

Steps to reproduce bug:
1. Attempt to adjust timezone by -7.5 hours (difference between New Zealand Daylight Time and Sri Lanka time)
2. Only 1 hour increments are available in the time zone adjust drop down combo.
3. Fail!

Results: It is not possible to adjust the timezone in half-hourly increments. After some Googling, I found a very unintuitive workaround that involves selecting the first photo, and adjusting it by the required amount. This is not intuitive enough, and as there are 30 minute timezones, I believe obvious and intuitive support for 30 minute timezones should be included.

Expected results: In addition to the hourly TZ adjustment combo box, there should be another combo to the right that allows selection of 30 minute TZ by selecting either :00 (default) or :30 that is applied in addition to the TZ hour adjustment. This would make it possible to adjust the time to 30 minute timezones (e.g. Sri Lanka and India) in an obvious and intuitive manner.

What seems like a lifetime ago, I wrote my initial thoughts on the Garmin Colorado after having owned it for a few weeks. Now I’d like to return and offer more definitive thoughts on it after nearly a year of fairly heavy use. In this time it has been with me on somewhere around 1000 cache hunts, and a few overseas trips – mostly to Australia, but also Singapore and Sri Lanka. Naturally, it has seen a fair bit of domestic usage in little ole New Zealand as well.

I’m not going to spend any time going over what the Garmin Colorado is – there are plenty of articles on the net. I want to focus on the big pro’s and con’s associated with the Colorado. (Many of these comments may or may not also apply to the Oregon, I haven’t had enough hands on time with one to see what improvements they made from the Colorado.)

Made of Win
Win 1 – Stunning Maps. The screen and map display on the Colorado is absolutely gorgeous and blows away all of the previous generations of Garmin mapping handheld GPS units. The clarity of of the mapping display and the ability to clearly represent more layers at the same time is just great. I really struggle going back to older mapping units like the 60 series with far lower resolution and clarity in the maps.

Win 2 – USB Storage Device. Whilst it doesn’t sound like much, the change in metaphor for sending/receiving information from the GPS is a huge plus. You can accomplish most things purely by mounting the GPS as a USB device, and copying/deleting files from the GPS. No longer is it necessary to have Garmin GPS drivers to be able to communicate with the GPS. This is incredibly handy for travelling. If you prepare a whole lot of geocaching GPX files before you go, you can just store them on the device, and as you move around delete the active ones you are finished with, and store the others under a filename that the GPS won’t recognise e.g. use .bak or similar. Then, just rename the file from .gpx.bak to .gpx and next time you boot up, the GPS will load the new geocaches. This works the same for maps when travelling from country to country. If you have enough storage space to store multiple countries .img files from OpenStreetMap in the main memory, then as you move from one country to another, you can just rename/delete the old file, and rename the next country you’re heading to as the current gmapsupp.img – it works very well. Compare this with the alternative of either creating a massive gmapsupp file with all the countries you are travelling to, or having to take MapSource/RoadTrip with you and reloading maps as you go.

Win 3 – Paperless Caching (PC). The basic paperless caching functionality works pretty well. Two thousand caches is a far more reasonable limit than 500/1000 waypoints. The cache specific icons are great and make it so easy to see the types of caches at a glance on the map. The field notes work really well and speed up the logging of caches no end. It is very useful having the cache descriptions and logs, and we used this feature well on the road when figuring which caches to do next on a road trip.

Win 4 – Roller. What can I say, it is absolutely brilliant for zooming in and out on the maps.

Win 5 – Mount. The new mount connecter is very solid and works well on bikes and car dash mounts.

With that said, there are some areas where the Colorado let’s you down fairly significantly.

Epic Fail
Fail 1 – Archived Tracklogs. The 60 series had a near perfect means of archiving tracklogs. You could set it up to record to the SD card, and the unit would create a file for each day. Never, ever, did the GPS unit end up writing over already recorded tracklog data. Sadly, the same cannot be said for the Colorado. The archive track capability of the Colorado will only store 20 GPX files of approximately 1MB/5k trackpoints each before it will start overwriting the archived tracklogs. As a keen OpenStreetMap track logger, and also someone that wants to keep tracklogs from travel so that one day I can geotag some of my photos, I was livid the first time that I have found the Colorado was overwriting archived tracklogs. I really liked the 60 series handling where you could leave it going, and just trust that you come back and once every couple of months copy of all the archived tracks. Not so with the Colorado and it is one of my biggest frustrations. This means that archiving tracklogs becomes a hassle and a chore. This is such a big dealbreaker to me I am now considering what my next GPS is going to be. I want to be able to travel for weeks, have everything archived AND HAVE ABSOLUTELY NOTHING DELETED WITHOUT ASKING ME FIRST. Why can’t the system save tracklogs to the external SD card just like the 60/76 series do?

Fail 2 – Paperless Caching. Whilst PC has been extremely successful for traditional caches, there are many, many failures and oversights. Consider that earthcaches don’t have their own icon, and for some reason Garmin has seen fit to default them back to Traditional caches, when at a minimum they should be Virtuals. How hard is it really for Garmin to update the software to display them with their correct icons, or at the very least as a Virtual? Why, are all the child waypoints associated with a cache loaded as actual waypoints, rather than being linked to and accessible as part of the cache? All they do is take up the waypoint allocation, and they aren’t easily accessible from a cache description. Why does the list of nearest geocaches not show the cache type icon – instead you have to click through each cache to see what type it is.

Fail 3 – Lack of user-centric design. I’m not sure how Garmin tested the Colorado, but there are some silly design decisions that make no sense at all. When changing the location of a waypoint (e.g. editing the co-ordinates to enter a waypoint for a multicache) you can only see 10 of the 20 characters at any time. This makes it very frustrating when copying co-ordinates from a cache. The only way you can see them all at once is if you save the waypoint, then find it, and view the co-ordinates on the screen before selecting ‘Go’. This is an impractical solution. This is perhaps my most frustrating experiences, but there are others, and these point to a poorly designed interface that doesn’t appear to have any real thought around the development. How hard would it have been on the lat/long entry screen to have both the latitude and longitude visible at once? There is certainly enough screen real estate to support it.

So, what does this mean?
To me, I think there is something inherently flawed in Garmin’s design process. A number of these usability errors SHOULD have been picked during testing before release. One wonders if Garmin skimped on the end-user testing and rushed the Colorado to market. The Colorado has the feel of Windows Vista about it – some really nice new features, but some absolutely fundamental design errors that are real deal-breakers.

Don’t get me wrong, I’m not about to sell the Colorado and move back to a 60 or 76 series – I just couldn’t handle looking at the maps on one of them again, or losing the paperless caching. But, more than ever, my recent experience with losing archived tracklogs on the Colorado has got me thinking about the best approach to paperless caching and decent tracklogging – what is the next step.

Perhaps it is a fundamental mistake by me, thinking that I can have a single GPS that does everything I need it to. Even now, I still need my iPhone with caching details in addition to the Colorado. Perhaps I need to use a simple tracklogging GPS unit such as the Wintec G Rays 2 for logging tracks and not rely on the Colorado for this – it after all will automatically delete the archived data (which I don’t think is mentioned in the manual, just on the unofficial Colorado wiki).

The iPhone may end up being my saviour for paperless caching. Currently, we are tied to Garmin’s model and method of paperless caching on their units – you either use their approach, or you use another piece of hardware.

I’m starting to think that perhaps I can go the other way. Perhaps I should focus on looking for paperless caching capabilities in the iPhone. After all, all we need is something like GSAK/GPXSonar for iPhone, with an inbuilt map viewer that understands Garmin img map files, and that solution would likely blow away anything that Garmin could come up with (based on my 11 months with the Colorado). Sure, you could still use a basic eTrex high-sensitivity unit with caches loaded as POI’s, and take all the intelligent processing to a device capable of acting in an intelligent manner.

Garmin has had at least 12 months to improve the capabilities of the Colorado via software updates. All these issues, and hundreds more have been identified in the Garmin Coloroado wiki. Yet few have actually been resolved.

The core problem here comes down to Garmin being a hardware vendor, and they are still locked into the thinking that once the hardware is sold, only critical bugs will be fixed, and everything else will be left to the next generation of units – so you have to purchase new hardware to get a real upgrade.

This is in almost complete contrast to the Apple iPhone. With the iPhone, the software sees regular updates, and there have been some significant updates to old hardware. For example, the 1st generation iPhone and iPod touch were able to be upgraded to the v2 OS for either free or minimal fee, but the user received significant new capabilities. Come this June or July, even the original users of these devices will be able to upgrade to v3 of the OS and reap nearly all the benefits (yes, 1st gen. iPhones don’t have A-GPS, so the users will miss out on that – one of the reasons I didn’t get an iPhone until it had GPS).

On top if this, the iPhone allows developers to create competing applications. This means if you are so inclined, you can write a caching application if you choose. Whilst only geocaching.com will be able to have the tight integration with their website, I still believe there are possibilities for developers to deliver some stunning paperless geocaching applications that will blow away any capability that a hardware vendor such as Garmin appears to be capable of developing.

The software approach means that applications are sometimes updated every couple of months for existing users, and this is an area that Garmin has perhaps had their biggest fail. Garmin has failed to improve the utility in their existing units by fixing minor issues that the community have identified, and they are not releasing software updates as frequently as they should be. Any Garmin release generally addresses only a limited number of issues, especially when compared to the large number of outstanding issues identified by the user community.

This has perhaps been my big lesson with the Garmin Colorado. Garmin don’t appear capable of maintaining and improving unit capabilities once the product has been sold – certainly not when compared to iPhone updates. If Garmin keeps up like this, they are going to be made increasingly irrelevant by programmable devices like the Apple iPhone that will deliver extremely powerful paperless caching applications in spades.

The corollary, of course, is that if Garmin want to continue to deliver more complex and software-driven units to the market, they need to be far more responsive to the issues raised by the community, and provide more significant software updates.

The summary of course is that I’ll continue to use the Colorado – it is after all a sunk cost for me, and it does do some basic things pretty well. But am I seriously going to be keeping an eye out for alternative solutions that are more responsive to user feedback. I’m hoping that by sharing my experience with the Colorado, it will get you thinking about your choices more too.