Lightroom 4 has lots of new big-ticket goodies, including a book module,
map module (with geoencoding!), soft proofing, more video support, and a new render engine that
takes the dramatic improvements in raw image conversion seen in the Lr2→Lr3 to the next leap. There are also many
small improvements sprinkled about.

Important note: the Lr4 public beta is a “beta” in the true
sense: take care to have a backup of any images you apply it to, and don't
expect that any work you do with it will carry forward to the real Lr4 when
it comes out. Use it to play around with and as a basis to provide feedback
(at Adobe's
Lr4 beta forums), but it's not intended to be used (or ready to be
used) in a production environment.

Lr4 and Plugins

Modern versions of my plugins should work
just fine in the Lr4 public beta.

Unlike the last major upgrade (Lr2→Lr3), there's not much new (yet?) for a plugin
developer like me. There was a ton of new stuff in Lr3 to occupy my time
(most of it came in Lr3's
second public beta), and the stress of it eventually overwhelmed
me, but in the end it caused me to make beneficial changes to my
habits. I'm still developing every day, but with more balance. That,
combined with a recentwillingness to walk instead
of take the car and I'm in pretty good shape, at my lowest weight in a
decade(88kg · 195lb · on my 6'4"
frame), but you don't want to hear about that, you want to hear
about Lightroom...

Lr4 and Geoencoding

The only Lr4-specific change in my plugins so far is in my Geoencoding-support
plugin: the silly kludge of “shadow data” that I had to come up with in
Lr1 is now gone because Lightroom's plugin infrastructure finally
allows me to update the “real” location data.

The Lr4 public beta does not allow you to upgrade an old catalog to Lr4,
so there's not yet a need to migrate old shadow data to real data, but I'll
build something to handle that before Lr4 proper is out.

I'm absolutely thrilled that Lr4's new Map Module allows
geoencoding, in a variety of ways no less (drop-n-drag on a map!), but I'm
not partial to how GPS-unit tracklogs are handled, so I'll probably
continue to use my plugin to geoencode with them. My plugin also includes a
bunch of other geoencoding-related support functions (enhanced reverse
geocoding, view locations in KML, etc.) so I expect the plugin to become
even more popular: the ease of the Map Module will bring more Lr users to
the geoencoding fold.

Lr4 and Plugin Registration

My plugins are free for everyone to use forever, without payment to me
or anyone else. However, I do encourageoptional
registration, which generally costs 1 cent in a PayPal fee. (If you
choose to register and choose to include more than PayPal's minimum as a
gift to me, PayPal will take its larger cut in fees, and if there's
anything left over for me, you have my gratitude.)

However, none of this has anything to do with the Lr4 public beta, since
registration is disabled in the public beta. But it does bring up a point
that will matter when Lr4.0 proper is released: the plugin registration
system that I came up with ties a registration to a Lightroom serial
number, but since a major-version upgrade of Lightroom involves a new
Lightroom serial number for Adobe, such an upgrade renders all my plugin
registrations invalid. That means that folks who want to register my
plugins must re-register them after an upgrade.

The hassle factor makes this really unfortunate, but in the end I hope
it's not too burdensome, with registrations being optional and 1-cent and
all. I'm sure I'll get flooded with messages by folks not understanding
what went wrong with their plugin registration, or those who do understand
it but don't like it. Let me offer my apologies up front.

Do have the details on how Tracklogs are managed. Can they be stored and/or combined to form a ‘master tracklog’ in Lightroom, or do they have to be individually loaded each time one is to be used? I have been looking for a good way to manage/merge my 100+ individual tracklog files for years, and I haven’t found a decent solution yet.

I haven’t spent much time with it and tracklogs (as I said, I wasn’t enamored with Lr’s tracklog handling), but I don’t understand what kind of workflow would need the management you speak of. Generally, I imagine that a tracklog is used to geoencode photos once you get home, then moved to the archive (and in my case, rarely ever touched again). Or are your tracklog needs not geoencoding related? —Jeffrey

— comment by
Keith
on
January 10th, 2012
at
3:26pmJST(7 years ago)
—
comment permalink

What specifically do you dislike about LR4’s tracklog handling? Is it something they could fix in time for final release? I expect you’ve probably told them, but I’d be curious since I’ll be evaluating geotagging more carefully soon. (And I’ll be delighted to bid adieu to shadow data, too.) Thanks for all your work with this plug-in over the years — it’s really been useful to me.

You should give it a try and offer your feedback to Adobe without being tainted by the details of my opinion. Maybe it’s just that I’m so used to using my plugin, and it’s so easy to geoencode from tracklogs with it, that I’m just not interested in switching. I’m most excited about using the Map Module for search, browsing, and discovery. As for what Adobe might do for the final release, I’m not privy to their plans, and anyone who is can’t say. —Jeffrey

— comment by
Boris
on
January 10th, 2012
at
9:35pmJST(7 years ago)
—
comment permalink

Thanks for the feedback, Jeffrey. To elaborate a bit on my situation (since it is atypical to be sure):

I got fascinated with the idea of geo-encoding photos in 2007 after first coming across some projects online. I was especially impressed by some maps people had done where a tracklog was overlaid on Google Earth, and photos were plotted along the path where they were taken. For example, one may be a tracklog of a long hike, with scattered photos along the way, that could be blown up by clicking on them. So around that time, I purchased a GPS tracker of my own and started learning about how the proces worked – how the tracklogs were stored, what data they contained, how they were encoded into photos, and methods for doing so. You can see a bit of my research here: http://www.flickr.com/help/forum/en-us/60721/

Over the years, I have kept tracklogs of nearly all of my vacations, from all corners of the globe. My tracklogs typically ran on for days at a time (at 5-second intervals). Since the file sizes were manageable, I didn’t really think of the consequences of amassing so much data. Because I was often limited when I could perform backups, I ended up with many partially-overlapping tracks. Some long trips would require multiple logs, while some logs would encompass multiple trips. Without any sort of database tool to manage the files, they just started cluttering folders on various computers in my home. Once I adopted Lightroom I finally managed to get my scattered photos under control, and collected my various tracklog files into one folder (~100 of them).

I have toyed around with several tools for applying geodata to my photos, but after much investigation and an encounter with data loss, I am paranoid about using anything outside of my process. In the end, I backed out of my attempts to geo-encode my workflow entirely until it was finally incorporated into Lightroom (I was very disappointed when it didn’t show up in LR3). So now here I am, still creating tracklogs, and trying not to make such a mess of them as I did in the past. But I’m still looking for a way to at least merge all of these scattered files into a comprehensive ‘master’ tracklog, from which I can select shorter time periods for individual trips. I would like to keep this tracklog data for its own sake as well as use it for geo-encoding my photos.

BTW, I absolutely love your work, Jeffrey. Both photographically and technologically. I always take a moment to browse your posts when they come through my Reader in the morning – they are so beautiful and interesting. I’m impressed that you are able to keep coming up with fresh ideas, and process so many so quickly! I tend to get stuck when processing photos, and rarely do they make it all the way to my online collections. I would do well to follow your example. Also, I am grateful to you for your work on creating plugins and your posts explaining various technical aspects of digital photography. I have always had ‘trust issues’ when it comes to software, and learning more about how the process works is very helpful. Now that I am back in school as a CS major, I hope to follow this example with my own projects. Keep up the great work!

Your situation seems exactly typical, except that you haven’t been doing anything with your tracklogs and so that processing awaits. In Lr2/3/4 you can use my geoencoding-support plugin to geoencode your files, or in Lr4 (the real one once it comes out) use Lightroom’s built-in support… I don’t see the problem. You don’t need all 100 tracklogs to geoencode each image… just the one that applies to it. I’m not sure how it works with Lr4, but with mine you can load multiple tracklogs and apply to large groups of images at a time. Once that’s done, you don’t need the tracklogs anymore, except as backup, or to play with separately, such as the photos-over-tracklog thing in Google Earth (which you can generate with my plugin, however the images had been geoencoded). In your description I see no need for a “master” tracklog, nor much difference than my situation… —Jeffrey

— comment by
Keith
on
January 10th, 2012
at
11:30pmJST(7 years ago)
—
comment permalink

The release of LR4 would seem to be an excellent time to adopt a ‘minimum’ donation for plug-ins, (perhaps something less the current average donation.) I know you do it for love and not money, but your time is valuable, and the plug-ins are valuable to us. My $.02. Paul

I appreciate your words of encouragement, but a “minimum donation” is not a donation at all, it’s a “price”, and having a price on something makes it something someone “buys”, and if someone is buying something, they rightly feel entitled to support. I feel bad enough as it is with all the support requests I simply don’t have time to respond to, so I’d rather leave the plugins as free, because it also leaves me free to continue as I have. —Jeffrey

Jeffrey,you are right about the donation. If there will be a price set for your plugins, I would probably consider whether to buy them. I tested your SmugMug plugin and worked as I expected and it was a good reason to give you a small donation (in $ it is a small amount, for my conditions it is relatively high amount). Now I am following your blog which contains a lot of various information as well inspiration and now when there will be LR4 available, I consider a higher donation, not just because the plugin for SmugMug, but as well for other plugins and as well for your blog as I like it. Of course you will see it as a donation for your SmugMug plugin. Again thank you Jeffrey!
BTW the LR4 and fast preload data in DNG seems to me the best on LR4. The speed is just unbelievable.

— comment by
Boris
on
January 11th, 2012
at
6:38amJST(7 years ago)
—
comment permalink

Hi Jeffrey,

That is good news. So far I did not really use your plugin only for testing some bits, as I used geosetter (mainly trying to avoid shadow data).
But since shadow data are gone (or almost) I might go with your plugin.
One thing I would like to see is the image direction (not the movement direction computed from the tracklog) as more and more camera have electronic compass embedded.
another thing is to be able to set the altitude (which LR4 does not allow !!)
and a last thing would be to set the position of the photographied object. All this is already nicely implemented in geosetter.
Do you think you could provide it (though I guess this would mean some more shadow data 🙁 )
Thanks for the good work.
regards
Eric

The compass thing would be a bit troublesome, both because there’s no way to get at that data from within Lightroom (I’d have to launch a separate program to fetch it), and because I’m sure it’s not a standard data field, so each camera maker would have their own way of storing it. I didn’t realize that Lr4 doesn’t allow you to set the altitude… that’s a bit surprising. Definitely submit a feature request. And as for the position of the object being photographed, I don’t know of standard fields that would hold that on export, so I’m not sure what to do with the information (but again, definitely submit a feature request to Adobe to be able to set the image subject location, which then implies the angle). —Jeffrey

— comment by
Eric
on
January 11th, 2012
at
7:52pmJST(7 years ago)
—
comment permalink

On the subject of tracklog management, I would also like some sort of “manager” that could ingest all my tracks and be able to organize by location, date, aspects of the track (speed, altitude etc), show the track on a map and so on. While my logs are used mostly for photography, I’m not sure that it needs to be a LR-specific function. I’ve searched from time to time for any new software that is specifically for this but always come up empty. One function I REALLY want is some sort of track analysis app… point it to a track and it shows relevant stats about it. GPSVisualizer.com in conjunction with EveryTrail.com will give the sort of information I’m looking for but they only allow a small file size (which means no all-day 1-second interval tracks) plus the upload time required for what I guess is just gee-whiz info.

The features of LR4 look promising. I really like the Map Module but it does not do as much as your GPS Plugin. I suspect that I will continue to use your plugin alongside the Map Module. I will gladly re-register the plugins after LR4 comes out! Thanks for all the hard work!

Great to see Lightroom is starting to catch up to the level of feature provided by your plugins! Given the map module is a core component, it’s clear you’ve been on the right track all these years. Thanks for your work so far, and I’ll certainly be donating again once migration time comes.

Hi Jeffrey
thanks for the answer. As for the image direction, there is a standard field in the exif. I have a camera that uses that exif field. so i can read it out of the box using geosetter (which uses exiftool) and even correct it with geosetter since geosetter allows to set it or compute it from the subject location. I have seen image from another camera vendor that could also set the direction and I could see it in geosetter, so i start to be confident that camera vendor will all hopefully follow the standard.
regards

— comment by
Eric
on
January 12th, 2012
at
9:09amJST(7 years ago)
—
comment permalink

And the same goes for subject location : exif spec provide a standard field for that.
I have sent the requests
Eric