Back during the Lightroom 2 days (circa early 2009), I spent some intense weeks writing a really great plugin, allowing a user to create custom image metadata fields on the fly. If a user suddenly decides that he wants an extra metadata field to describe the weather for a shot, or the flash setup, or a model's name, or whatever, just a few clicks in a plugin dialog and voilà, it would appear with the standard image metadata alongside each photo. I really wanted this for my own use, and I knew lots of folks would be jazzed about it as well.

Unfortunately, I eventually noticed an incompatibility with how Lightroom sometimes loads plugins. I spent much energy trying everything I could think of to dance around the issue. I'm pretty good at this kind of thing because I routinely push Lightroom's plugin infrastructure well beyond what it was designed for. In a twisted way, this is part of the fun of Lightroom plugin development for me, to come up with “creative” ways to get things done and make my photo workflow easier.

But in this case, back in 2009, it beat me, and with great reluctance I abandoned the plugin.

Nikon D3 + Voigtländer 125mm f/2.5 — ¹/640 sec, f/4, ISO 200 — map & image data — nearby photos
Dedication To The Shot
( this shot )
photo by Paul Barr

(I'm populating this narcissistic post with various shots of me that I've accumulated from friends I go out shooting with, mostly by Paul on his visits to Kyoto.)

Over the years I've kept an eye out for a change in Lightroom plugin infrastructure that would happen to allow the plugin to work, but it's never come. (To be clear, I can't blame Adobe because, again, I'm pushing things well beyond the design envelope). But on a whim last night, perhaps in an effort to avoid actually having to address the hundreds of request-for-help emails that have accumulated recently, I pulled the old plugin carcass from my archive and gave it a try.

It still didn't work, but I expected that.

Nikon D3 + Voigtländer 125mm f/2.5 — ¹/1600 sec, f/8, ISO 1600 — map & image data — nearby photos
Squished Nose
happens every time the camera is in landscape mode
photo by Paul Barr

But even though Lightroom's plugin-infrastructure tools have not improved in this particular area, they have definitely improved here and there in other areas, so I gave it another try. Combined with perhaps a bit more ingenuity under my belt this time, after a few hours of hacking around, I figured out a way to make it work!

Woo-hoo!

Nikon D3 + Nikkor 24-70mm f/2.8 @ 70mm — ¹/200 sec, f/4, ISO 1600 — map & image data — nearby photos
Just Rewards!
the beer she was pulling was for me
photo by Paul Barr

Getting the custom-metadata plugin working was great news, but also dreadful news.

It's great because now I can use this plugin for myself. It works. It does what I need. My workflow will be better because of it.

It's dreadful because I know others would find it useful, so I feel a strong desire to release the plugin, and that would take a lot more work. I'd have to bullet-proof the thing. I'd have to write up docs and FAQs and make screenshots. I'd have to add all kinds of things to the plugin that I don't personally need, but I'm sure others will ask for (and in some cases, demand). Some of those things (such as the ability to transfer the custom metadata when exporting or merging catalogs) pose serious complications whose potential solutions are all among the “dammed if you do, dammed if you don't” can't-please-everyone genre that will certainly, no matter what, generate complaints and requests.

E-P2 — ¹/640 sec, ISO 100 — map & image data — nearby photos
Futzing With the Polarizer Filter
"Why can't Nikon design a lens hood that incorporates access to a filter? They must all be idiots!"
photo by Nicolas Joannin

So in the end, I will spend a ridiculous amount of time doing all this, resulting in yet another incessant flow of request-for-help mails that fill my inbox and increase my stress. That sounds like a complaint, and I suppose it is, but I choose this hobby freely because I like most aspects of it. I just need to be smart about how I handle the stressful aspects of it, lest I let it drive me into another stress breakdown.

I went to bed last night trying to decide whether I want to even try to release it. Do I want to accept the burden of stress that inevitably comes with it? If so, can I do anything now to decrease the amount of stress generated later?

Nikon D3 + Voigtländer 125mm f/2.5 — ¹/200 sec, f/4, ISO 800 — map & image data — nearby photos
Taking A Rest
while on the outing that produced this post and this post.
photo by Paul Barr

I woke up without an answer, but as I helped prepare Anthony for school, I decided to at least give it a try, to prepare a version with ample caveats about data migration, and see how it went from there. If it became popular, I'd feel good about spending more energy to tackle the tough problems that remained, and if not, well, I just saved myself a lot of grief.

Nikon D3 + Nikkor 24-70mm f/2.8 @ 24mm — ¹/125 sec, f/2.8, ISO 3200 — map & image data — nearby photos
In a Friendly Frame of Mind
photo by Paul Barr

So it was with that frame of mind that I saw Anthony off to school, prepared a cup of coffee, and checked in on the computer. I found among my mail the notice of a gift from a Boston photographer who wanted to register one of my plugins. As per the “donationware” thing, he didn't have to send me anything at all to use my plugins, but he kindly chose to send $5. That was nice, but he also added this personal message to me:

Well, that's not a pleasant way to start the day.

Nikon D3 + Nikkor 24-70mm f/2.8 @ 38mm — ¹/50 sec, f/4, ISO 1600 — map & image data — nearby photos
Oh My!
Call the cops, someone was rude on the Internet!
photo by Paul Barr

Well, it certainly didn't put me in the nose-to-the-grindstone mood I would need to tackle the custom-metadata plugin.

Granted, the guy did send me a dollar for a previous version of Lightroom as recently as 2010, but I don't think this calls for words like “insidious” and “extortion”. I require nothing. I returned his $5 with a note that I wanted it only if it were a true gift. 'Cause that's, you know, how I roll.

I shouldn't have been surprised, based on the maturity of his initial comment, but his subsequent replies only went downhill from there. Sigh.

Nikon D3 + Nikkor 24-70mm f/2.8 @ 70mm — ¹/160 sec, f/5.6, ISO 400 — map & image data — nearby photos
Manners and Civility on the Internet
still looking
photo by Paul Barr

Anyway, I thought I'd vent a bit with this post to the sympathetic ear of the friendly audience who reads my blog. (Hi Mom.)

So, would anyone have interest in that kind of custom-metadata plugin?

Nikon D3 + Nikkor 24-70mm f/2.8 @ 35mm — ¹/200 sec, f/4, ISO 1600 — map & image data — nearby photos
“I'll Get Right On It”
photo by Paul Barr

Well, this is surprising: iOS does not seem to be color managed. At all.

This is a long and technical article. Here's the table of contents:

• Introduction
• Color Management
• Embedded Color-Profile Support
• Device-Specific Color Profiles
• The Curiously-Deficient “SpyderGallery” App
• What's Next
• One Last Caveat

Introduction

With all the talk these days about glorious color performance of the third-generation iPad screen, such as this article and this, I realized that my Lightroom-to-iPad workflow (presented in “Getting Photos from Lightroom to iPad: a Much Smoother Workflow”) neglected to consider color profiles. This is a huge oversight for someone like me who wrote an in-depth primer on digital-image color spaces six years ago.

So, I looked into how I might enhance my workflow along color-management lines, and discovered to my shock that iOS is not color managed. At all. I haven't found a single application, from Apple or anyone else, that is color managed. Even Datacolor's SpyderGallery app, which allows you to profile your iPad screen with a real hardware colorimeter, is not color managed.... it seems to be nothing more than a technically-incompetent placebo.

Color Management

If you're not familiar with what “color managed” means, my old primer on color spaces goes into great detail, but in short, digital images such as the JPGs you find everywhere are made up of numerical data that becomes a picture only when interpreted for display by the viewing application, such as your web browser in showing the images on this post. The display application can make assumptions about how to convert that numerical data to color, or it can be told explicitly by various notations within the file.

Of course, any assumptions may be wrong on an image-by-image basis, so it's always best if the display application uses the explicit notations if they're there, but some applications don't bother. An application is “color managed” if it uses the notations, and not color managed if it uses only assumptions.

(There's another facet of color management that deals with how those colors are then presented on any specific display device; I'll get to that later.)

So, why am I blue?

It's okay and expected that I'm blue in the photo above, which originally was by Paul Barr of me from my previous post; I'll explain why in the next paragraph, which will then prepare us to understand when I present the real problem in the paragraphs that follow.

Embedded Color-Profile Support

The lead photo of this post uses raw color data that makes me look blue when interpreted with “common” assumptions about the data→color conversion process. In the copy above, I make sure that there are no notations about how to do the proper conversion (I stripped the “color profile” that would normally be embedded within the image file), so your browser has no choice but to guess, and for this test I made sure that the common guesses would produce an obviously-wonky result. (No comments, please, about how any photo of me is “obviously wonky” )

Now, let's look at exactly the same image, except that it does have an embedded color profile describing the exact data→color conversion process. This means that the next image will appear to you with generally proper colors (I'm pink, not blue) if your browser does not ignore the color profile. If it ignores it, instead opting to make assumptions, I'll look exactly the same blue as in the top image.

Am I Feeling Blue or Tickled Pink?
this is the main test image
if this version looks blue, your browser is not color managed

Did your browser pass the test?

When I first wrote my color-space primer six years ago, most browsers would fail, showing a blue me. Things are better today, especially on a Mac where all major browsers have been color managed for years.

On Windows, it's still a mixed bag. Firefox and Safari have been color managed for a long time, but Internet Explorer became color managed only last year with IE9, and Chrome and Opera are still not color managed and leave me blue. (In a twist of irony illustrating the Mac's general lead in this area, Microsoft's own Internet Explorer for the Mac, last updated nine years ago, is color managed and shows me in all my pink, er, glory. It took Microsoft another eight years to get around to doing the same thing for their own operating system's users.)

I won't go so far as to say that if you see a pink me, you're seeing accurate colors, because I have no idea whether your computer display is adjusted properly (or even at all!), but any kind of pink is a lot closer to accurate than blue.

Okay, so now try viewing this blog post on your iOS browser; the results will, I'm fairly certain, leave you feeling blue.

Obviously I can personally test only a small subset of devices and applications, but I have not found any — not even one — iOS application that displays the second image properly. You can save it to your camera roll and view it with any number of applications, including apps from such leaders as Apple and Adobe, and they all show me as blue because they all ass·u·me incorrectly, even though the color profile is right there in the image. Back in 2006, on the History of Color Mis-Management page of my color-space writeup, I called such applications “Color Stupid”, but in this day and age, such applications should probably be called something much worse, like “Color Moronic”, or “Color Leaves-Me-Dumbfounded”.

To make testing easy, here are three versions of the image presented in a convenient group, two as test “controls”, and one for the real test:

Control Image Always Correct

Test Image Pink or Blue?

Control Image Always Blue

I'd be curious to hear how these images display in various situations... what about Chrome on Android? Photoshop for iPad? If you try them, let me know the results in the comments below.

I created these test images with the intent that a lack of color management is exaggerated to the point of being obviously apparent. In the real world it can be subtle, but the practical effect is often a “washed out” image. You can see some real-world examples on the “Test Images” page of my color-space writeup.

( this photo has nothing to do with this post )

Not wanting an article where the only photo is of me, I'll take the liberty to sprinkle the rest of the article with random photos that have appeared on my blog during the past year, each with the “Funky RGB” color so that they're at least “interesting” when viewed in a non-color-manged browser. Clicking on them brings you to the article where they first appeared, presented there in a color space that should at least not look totally wonky when not color managed. (If your browser is color managed, it may be fun to look at this article with a non-managed browser.... some of these pics look pretty crazy that way.)

Okay, so back to iOS. It's surprising enough that iOS is not color managed, but the most egregious offender I've found is Datacolor's SpyderGallery app. If you can get by the vomit-inducing intro text (“If you could be a color, which one would you be?”), you'll find claims that users will “enjoy color corrected viewing of their photos” and that you “will no longer need to compromise color accuracy for the convenience of your iOS device.”

This is all fine and dandy if it were true, but the app is not color managed!

Device-Specific Color Profiles

Let's step back a bit to first look at the other facet of “color managed” that I mentioned earlier. Above we talked about how colors are derived from an image file, and about how a color profile — a device-independent color profile — can be used to accurately guide the conversion process to come up with the proper conceptual idea of “color” for each pixel. The flip side is the facet of how those conceptual colors are actually presented on each specific display device.

We've all seen the banks of TV screens at the electronics store showing the same program, but with wildly different looks.... each TV seems to have its own tint or richness or brightness, etc. The same goes for our display devices (computer monitors, tablet screens, etc.), and a properly color-managed application will adjust on the fly for the characteristics of the device(s) it's displaying on.

In order to properly adjust for each specific display device, the application must know the answer to the question: "When I think I'm sending such-and-such a color to the display device, what color actually shows up on screen?". The answer is unique to each device, and changes even from day to day with any particular device. The answer changes every time you adjust the device video settings (brightness, contrast, tint, etc.), and the answer even changes over time as the display warms up after first being turned on in the morning.

The only reasonable way to answer the question is to “profile” the device with specialized hardware. This hardware includes a light sensor temporarily placed over the display device, then a profiling app is run that floods the sensor with a wide range of colors, allowing the app to compare the color it thinks it's sending with the color actually measured by the sensor. By calculating the difference, a “device-dependent color profile” can be created that instructs applications how to modify color data on the fly for that one specific monitor.

Now, as I said, this changes over time, so the device profile that I create today for my monitor (after it has warmed up, of course) will not be useful for you and your monitor, even if you have the same make and model, and it will likely fade out of accuracy as even for my own monitor as it ages. And it becomes immediately invalid if I make any adjustments to the monitor brightness setting, etc. But if I leave my monitor settings alone, it'll be fine for me for a while... I tend to reprofile several times a year, though serious folks do it weekly or even daily.

All that about “mine not valid for you” does apply to an iPad as well... the display characteristics of two iPads are in theory different... but from what I hear, the production is very reliable and all iPads of the same generation have very, very similar display characteristics, so a single “generic first-generation iPad” profile can likely be used by everyone with an iPad 1 with great success. This is where I failed in my original Lightroom-to-iPad workflow, something I intend to correct in a followup, soon.

Still, despite the apparent lack of a need for per-device calibration, some folks wanting the absolute last measure of quality in their photo display may want to create a hardware profile for their specific iPad. This desire meshes very nicely with the desire of colorimeter manufacturers to sell more product, and so voila, we have Datacolor's SpyderGallery app.

The Curiously-Deficient “SpyderGallery” App

It's important to understand what this app claims to offer. It's saying “use specialized hardware we sell you to measure the exact color output of your specific iPad, so that when displaying your photos with our app, we won't have to make assumptions about how your iPad displays color, we will know.” This is coming from a company that makes hardware colorimeters, so it's only natural to trust that they're experts in this area and understand the issues involved, and that when they offer a solution, it can actually do what it claims.

When I first saw this, it made me wonder what the assumptions were to begin with. I hadn't thought deeply about it, but I would have thought that iOS would contain generic device-dependent color profiles for the various iPads, iPhones, and iPod Touches that iOS runs on. The profiles are not very large, and there aren't that many iDevices, so it seems to be a no-brainer to include them all. If this is the case, hardware profiling like in SpyderGallery would be of minimal use because, at best, it could try to adjust for any subtle difference between the rock-solid average iPad and each user's specific iPad. Not really much point to that, but it wouldn't hurt.

But it turns out that SpyderGallery is not color managed in the first sense we talked about in the top half of this post: even if the images contain their own color profile — specific instructions on how to convert from the numerical data to conceptual color — SpyderGallery ignores it. The app may have stopped making assumptions about the display hardware, but it's still making assumptions about the original image data in the first place. This is moronic beyond belief. It's as if they're a tailor with cutting-edge facilities to make garments to the tightest of specifications, but insist on creating your shirt based on the average human size instead of your specific measurements.

In short, Datacolor's SpyderGallery is, it seems to me, just a meaningless placebo.

I wrote to Datacolor to ask for comment, and got a fairly quick reply that implied that the app assumes all images are in the “sRGB” color space, which is the de facto standard for unprofiled images on the web. This was presented as a “recommendation”, which seems very strange, since if true, doing anything else would guarantee incorrect colors.

Possible Mitigation with iTunes?

As I wrote in my initial, now-obsolete first Lightroom-to-iPad writeup, iTunes does some very strange things to your photos in preparing them for the iPad, but it is color managed, at least on OSX, because it converts everything to the “sRGB” color space before shipping it off to the iPad. This is not exactly ideal, but in practice is probably not that big a deal one way or the other.

So, if the implication in Datacolor's response to me is true, that they assume every image is in the sRGB color space, it'll work just fine for photos that end up on your iPad via iTunes, and perhaps for other images as well. Like I said, that's all fine and dandy when the assumption works out, but considering that there's no need to make any assumptions in these cases, doing so is inexcusable for a company like Datacolor.

What's Next

Going forward, one can hope that iOS and its apps will become color managed. This is probably something Apple can address in one fell swoop with an iOS update, but since I'm not an iOS developer, I don't know the details. I suspect that lacking an iOS update on Apple's part, individual developers can work to make their apps color managed. Again, I don't know the details, but it wouldn't surprise me if lcms suddenly became a bit more popular.

There's also something we can do now in preparing our photos for the iPad.

Normally it's flat-out wrong to put a device-dependent color profile into a JPG image file, and in a classic case of “just enough knowledge to be dangerous”, any suggestion of doing so is a clear sign that someone has no clue what they're talking about. But I'm going to suggest it here.

I have created a device-dependent color profile for my specific iPad 1 (created, ironically, with a Spyder3 colorimeter from Datacolor), and I will use it when I export from Lightroom for my iPad. Currently it will be ignored by all apps I've tested (including the photo-viewing app I use), but since the image data is already exactly tailored to my device, the result should be as absolutely perfect as is possible to obtain. If iOS or my photo-viewing app suddenly becomes color managed, they'll use the color profile to realize that no conversion needs to be done, and I'll get the same perfect result.

Furthermore, if the iPad's build consistency is as solid as reported, the color profile I made for my iPad 1 will work very nicely for your iPad 1. But frankly, I don't trust that I have the skill and equipment to make the best “iPad 1” color profile possible, so before I update my Lightroom-to-iPad workflow article, I'm looking for a better source of profiles, perhaps one that can also provide profiles for the third-gen iPad and other iDevices as well. Any ideas?

One Last Caveat

I'll end this post with the admission that it seems so unlikely in this day and age that iOS is not color managed, and that the greater likelihood is that I'm simply making some stupid error, and that my complaints about iOS and SpyderGallery are undiluted ignorance on my part.

I'll be mortified and embarrassed if that's true, yet, somehow I hope it is. We'll see.

The End

The rest of this article is just more funky/pretty pictures, though which (funky or pretty) depends on whether your brwoser is color managed, and, of course, personal taste.

So I was going through the photos from last weekend's Kyoto Marathon （京都マラソン２０１２) and came across an out-of-focus shot that I'd normally just delete, but it had some kind of odd sense of space about it that I found somehow appealing, and wondered whether I couldn't use some funky processing to turn the lack of focus into an asset.

I don't know whether I succeeded, but the result is what you see above, something that vaguely reminded me of my memory of some Leroy Neiman Olympic paintings.

I don't use develop presets very often, but I saved the extreme develop settings used in this photo as a new preset, which I named “Funky Runners”. While there, I noticed the few other presets I had accumulated over the years, and gave them a try with this photo.

The most recent one was “Creamy Autumn Wow” from “Kyoto Fall-Color Preview With Impact: Impressionism in Lightroom”, but the result with this subject was less impactful than the name implies:

Nikon D700 + Nikkor 300mm f/2 — ¹/2500 sec, f/2, ISO 360 — full exif & map — nearby photos
With the “Creamy Autumn Wow” Preset
not really doing it for me

I also tried the first Lightroom develop preset I ever made, one that attempted to match the at-the-time-vogue look of Dave Hill's work, as seen here and here (the former from a post exactly four years ago today, on the annual Kyoto Higashiyama “Hanatoro” lightup event in my neighborhood, which is again going on this week, but sadly, I've had no time to visit).

Nikon D700 + Nikkor 300mm f/2 — ¹/2500 sec, f/2, ISO 360 — full exif & map — nearby photos
With the “Dave Hill Look” Preset
also not doing it for me

These misses just go to show that not all presets are appropriate for all images (though with the extreme nature of these, you wouldn't be faulted for thinking that they're not appropriate for any images, but I like their effects from time to time, in extreme moderation).

One of the “time to time” situations is the photo of mounted archer printed and framed in my office (as seen in “Dabbling in Some Fine-Art Printing for My Office”). The preset I used for that, named unoriginally as “Funky Archer”, produced this:

Nikon D700 + Nikkor 300mm f/2 — ¹/2500 sec, f/2, ISO 360 — full exif & map — nearby photos
With the “Funky Archer” Preset

Again, not interesting.

I know I could get “interesting” (though perhaps not “good”) with something from my tone-curve posts from a couple of years ago, either “Stupid Tone-Curve Tricks: A Half Dozen Develop Presets for Lightroom” or “Gettin’ Freaky With Lightroom Tone-Curve Presets”. There's much fodder in there for craziness, and not much for anything else, so I just picked one (“Notch Medium 8”) and then futzed with various brightness settings to come up with:

Nikon D700 + Nikkor 300mm f/2 — ¹/2500 sec, f/2, ISO 360 — full exif & map — nearby photos
“Notch Medium 8”
at least it's not boring

From the same posts...

Nikon D700 + Nikkor 300mm f/2 — ¹/2500 sec, f/2, ISO 360 — full exif & map — nearby photos
“Cliff Highlights 2”

Somewhere in the fun waste of time I spent on this last night (a needed diversion from plugin-related work, the crush of which has not yet subsided in the two weeks since Lightroom 4 was released) I apparently futzed around with a black-and-white version, because I found this in my catalog this morning:

Nikon D700 + Nikkor 300mm f/2 — ¹/2500 sec, f/2, ISO 360 — full exif & map — nearby photos
One Stab at a B&W

And finally, here's the original:

Nikon D700 + Nikkor 300mm f/2 — ¹/2500 sec, f/2, ISO 360 — full exif & map — nearby photos
Original
maybe some potential?

I've posted about “extreme” processing in Lightroom a few times over the years. Besides the various links referenced above, ones that come to mind include:

• Funky Joy With Adobe Lightroom
• Context for the Bamboo-and-Leaf Photo, and Some Crazy Post-Processing
• One More From Last Year’s Eikando Temple Fall Colors
• Freaky Raw Processing: From Sunset to Moonrise with Adobe Lightroom
• Serendipitous Fun with Adobe Lightroom
• Camo Duck in Black and White
• A Few Stylized Shots from Bunny Island
• Stark Tree
• Freaky “Artsy” Sharpening with Lightroom 1.1
• Two Sides of the Same Photo

Yet even after all that, it never ceases to amaze me just how much artistic latitude Lightroom affords... obviously way more than I can handle, but I find it fun.... in moderation.

If you've got Lightroom 4 and would like to see what you can come up with, here's “JF7_108110.dng”, a raw version of the original. I'd love to see whether anything good can come of this photo, or whether my first instinct to delete it was right.

Greater Kyoto

After a two-month public beta, Adobe has just released Lightroom 4.0.

It's not a free upgrade, but with the price now cut in half (upgrades are now $80), it's an easy decision.^*  There's a lot new if you're coming from Lr3, the most important likely being the new rendering engine. Laura Shoe has a post and video about what's new here, and Victoria Bampton's always exhaustive “what's new” list is here.

^* At just $80 for the upgrade, even from Lr1, it's an easy decision, but Adobe usually comps me a free copy, which is very nice, so if that holds true again, I won't even have to make that simple decision.

Lr4 and My Plugins

The biggest change for all my Lightroom plugins is mostly under the hood, so you'll need new versions. Visit the plugin manager and “check for updates”. It's probably best to do this Lr3 before upgrading because the old versions might not even load in Lr4. (If you need to upgrade after, you can always do a manual upgrade by downloading the latest version of the plugin from the plugin's home page, unzipping, and replacing the old copy with the new.)

One big thing you'll notice is that plugins that had been registered in Lr2 or Lr3 are now no longer registered, an unfortunate side effect of how I designed my plugin registration system some years ago. If you want them to be registered, you'll have to register them again sometime in the next six weeks or so, though as before, you can do so with just 1 cent. Sorry for the hassles.

My Geoencoding Plugin

If you've been using my Geoencoding plugin, you'll be excited about the new Map Module in Lr4. The first time you bring up Lr4 with a recent version of the plugin, all the plugin's location data (its “shadow data”) is migrated over to Lr4's native data.

Personally, I've found that the Map Module is great for manual geoencoding, for browsing, and for searching, but I still prefer my plugin to geoencode from a tracklog. I find Lr's tracklog geoencoding difficult to understand, and it bothers me that it doesn't handle altitude. My plugin does.

The plugin also includes a bunch of stuff that'll be useful regardless of how photos get encoded, such as the ability to view mapped locations in a variety of online mapping services, or in Google Earth.

Upgrade Process: Have Patience

Especially if you have a large corpus of geoencoded photos, the first thing you'll want to is jump into the map module to play, and in this you will be greatly disappointed because Lightroom apparently has to do a lot of processing under the hood before it's ready.

When I upgraded my main catalog on my desktop machine (92,000 photos dating until last April when I switched to my laptop), I switched to the Map Module and got a spinning beach-ball for five solid minutes. Switching back to Library again beach-balled for a few minutes. But the biggest shock was checking the geoencoded photos: there should have been 50,000 or so, but Lightroom told me there were only 28,000:

My Photo World
sort of
I can now see at a glance that I geoencoded 14 photos incorrectly

Apparently, Lightroom needs to do something with each image under the hood before the transition from old plugin data to native Lightroom support takes effect in the Map Module and in the Library Grid Filter, and it's very slow. We're talking hours to handle the 22,000 photos that had been geoencoded with my plugin. It's not fun to wait, but even worse, Lightroom gives you no indication that it's still working and that the data it shows you is incomplete.

So, it's probably best at some point to open the Library Grid to “All Photographs”, select “GPS Data” in the metadata filter, and walk away to let Lightroom grind for a while.

Color Label Set

One more warning: if you use a custom Color Label Set (“Metadata > Color Label Set” is anything other than “Lightroom Default”), you may be very surprised to find that after the upgrade to Lr4 it has been reset to “Lightroom Default”. This can be a fairly major problem because when you assign color labels, you're actually assigning the label and not the color, and if the label set has been changed out from under you, you'll unknowingly be applying the wrong label.

So, be sure to check your color label set.

Plugin Support for Lightroom 2

Most of my plugins still work in Lightroom 2, but with the aggressive price lowering in Lr4, I expect most people who are still running Lr2 to move over, so going forward, I don't expect to put much more energy to continue to support Lr2 in my plugins.

Three and a half months ago, after a lot of research and Lightroom plugin development, I published the long writeup “How To Best Export Lightroom Images to an iPad, iPhone, Etc.”, about my Lightroom-to-iPad workflow at the time.

It's now completely out of date.

Most everything about my workflow has changed, all of it for the better. It's required months of development, a new Lightroom plugin (Collection Publisher) and major updates to my Crop for iPad plugin, but the result, unlike before, is something smooth and easy.

I'm still looking for the perfect photo-presentation app for my iPad, but my new workflow is ready for it when I find it.

The new writeup on my Lightroom-to-device workflow:

As before, the writeup itself was a lot of work, so I hope someone finds it useful.

I was never happy with the old tree publisher, but I'm quite happy with these two new ones. Combined with some big changes to my Crop for iPad plugin that I pushed recently, I've completely revamped my workflow to get a copy of my portfolio onto my iPad. I wrote at length about that in “Getting Photos from Lightroom to an iPad is a Lot Harder (to Do Well) Than You Think; Here’s How” just three months ago, but due to strangeness with iTunes and Apple's “Photos” app, the whole affair just felt kludgy and unsatisfying.

Fast forward to today and the workflow feels much better, and will be the subject of a new blog post soon. But first I had to release these plugins, so here we are.

Round about Lightroom 3.2, Adobe added support for intercepting “lightroom://” URLs, but have not documented it yet, so I'll do so here. It's particularly useful as part of an OAuth-authentication procedure.

What

You can have your plugin automatically respond to certain “lightroom://” URLs if they are formatted correctly, and if you add appropriate support to your plugin.

URL Form

After registering the appropriate handler in you plugin, as described below, the handler will be invoked when your system browser receives a URL of the form:

The “your.plugin.id” is the LrToolkitIdentifier in Info.lua. For example, the id for my Flickr plugin is “info.regex.lightroom.export.flickr2”, so it can be set to handle URLs such as:

etc.

How

Create a .lua file that returns a table along the lines:

return {
   URLHandler = function(url)
       -- The url string sometimes actually have a double quote as
       -- the first and last byte, so strip just in case.
       url = url:gsub('^"(.*)"$', "%1")

       -- Work with url here...

   end
}

Wrapping the function in a one-element table seems like an odd level of indirection, but that's how it works.

You then add a reference to that file in your Info.lua, as “URLHandler”. If the file is named “MyUrlHandler.lua”, for example, the reference in Info.lua would look like:

return {
   LrToolkitIdentifier = "info.regex.lightroom.export.flickr2",
   LrPluginName        = "jf Flickr",
   LrPluginInfoUrl     = "http://regex.info/blog/lightroom-goodies/flickr",

   LrSdkVersion        = 3.4,
   LrSdkMinimumVersion = 3.4,

   URLHandler = "MyUrlHandler.lua",
}

Within the URLHandler function, you can access parts of the URL (e.g. in an OAuth situation, the token) and stuff into global variables, and perhaps shut down a dialog that had been open by calling LrDialogs.stopModalWithResult(...).

That last bit seems to be unfortunately necessary... I've found that the handler is not properly invoked in some rare OS/browser combinations, so I feel that to cover all my bases, the plugin must open a dialog to tell the user to paste in their token; if the handler ends up working, the plugin can immediately shut down that dialog so the user is not bothered with it. Usually, that's exactly what happens, and it happens so quickly that the user never even sees the dialog.

I don't think Adobe's plugins do this, so maybe the problem has been on my end, but I thought I'd mention it because this is what my plugins do.

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.

Adobe's Lightroom-Journal announcement gives some details, but for a comprehensive list of changes, see Victoria Bampton's always-excellent “What's New” post. For tutorials, walkthroughs, and other coverage, see this long list of links maintained by Sean McCormack

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 recent willingness 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 encourage optional 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.

Continued here...

• Canon Powershot S100
• Fuji FinePix X10
• Leica V-LUX3
• Nikon 1 J
• Nikon 1 V1
• Panasonic Lumix DMC-GX1
• Ricoh GR Digital IV
• Samsung NX5
• Samsung NX2020
• Sony NEX-7

Details and download links available on the announcement at Adobe's Lightroom Journal blog.

It seems that the Lr3.6 beta that Adobe recently put out includes a new version (“Camera Standard v4”) for the Nikon D3, D700, and D300 that has been improved yet again. You can't blindly change from v3 to v4 because v3 is intended to be used with -0.5EV of exposure compensation in Lightroom, while v4 somehow gets around that. (I don't recall exactly why v3 required the exposure compensation, but I remember understanding that it was a problem that could not easily be solved in place, but perhaps with a code change in Lightroom 3.6, they can now handle it without requiring the artificial compensation adjustment).

In any case, v4 (and v3) are far superior to v2 and earlier, so if you have images from a D300, D700, or D3, I recommend upgrading when you can. (I don't know what other profiles might have been updated with Lr3.6, but I recall from the v3 post that the change at that time affected only profiles those three specific cameras, and not, for example for the D3s or D300s)