Maybe later this week I’ll wheel out the new LR3-friendly version of my Search, Replace and Transfer plug-in. There’s still a bit of testing to do though because I’ve had to find ways to work around LR3′s database access change – when your plug-in’s dialog box provides immediate feedback, you’ve a bit of a problem when the database returns values out-of-sync with it. It rather invalidates the term “dialogue”. I’ve also taken the opportunity to streamline some of the code, improve the layout, and add some new features. One is shown by this screenshot – instead of lengthy drop-down lists, separate dialog boxes make target fields easy to select. But it also shows another change – 16 custom fields.

I’ve never hidden my disappointment that custom fields are not available to users through Lightroom’s interface, as they are with Aperture, iView, Portfolio…. And I don’t think keywords are the right place for entering workflow or internal terms – only last week someone told me he had sent pictures to Alamy with “Getty” as a keyword. Correcting the omission of custom metadata is a much bigger task however than Adobe abolishing the obscenity “grayscale”. I never thought the Berlin Wall would fall either.

Plug-ins based on custom metadata are now trickling out, and it’s important that people are extremely cautious about their use. You’re taking quite a risk with your metadata.

This thought arose answering a forum question about whether one plug-in could access custom metadata entered through another plug-in. As far as I can tell, that’s not currently possible*. But it would be handy in many ordinary circumstances – eg to copy the caption or a date into a custom field.

*Update – it does work and it would have helped if I’d put the field name in quotes rather than treating it as a variable before getting on my hind legs:

getData = photo:getPropertyForPlugin(“”, ‘jbMissing’ )

But my advice about extreme caution is more because I’m approaching from a DAM perspective and am more worried about the longer term viability of custom metadata. Let’s say I released a plug-in based around custom fields and users entered metadata which had some value to them – whether that’s just input time or business data like a client or agency account number. Now move on a few months, LR3 comes out, and the plug-in no longer works – I’ve disappeared, driven mad by SDK changes, or you’re unwilling to pay my extortionate plug-in upgrade fee. At worst, it’s a mafioso’s charter.

And what now happens to that valuable metadata of yours? The data is still safely in the database but is effectively lost. You can’t read it because the original plug-in’s unavailable, Adobe’s built-in “All” Plugin Metadata panel only shows data from enabled plug-ins, and it’s not even in the XMP either. You’re stuffed – unless you’re resourceful enough to reverse engineer chunks of the plug-in. Assuming that I encrypted my plug-in’s code, that means you’re going to have to dig around the SQL to figure out my plug-in’s ID and its field names. That’s one barrier in your way. Then you can create a plug-in to rescue your custom data. Easy eh? And you’ve got to hope to hell that my plug-in didn’t encrypt or obscure the values you entered.

For me what this shows is

1) You’re taking a big risk if you store valuable custom metadata via a Lightroom plug-in – if you wouldn’t be able to sort it out yourself, should you do it?
2) You should ensure any plug-in with custom metadata stores its field definitions in unencrypted files
3) The All Plug-in Metadata panel needs to show all plug-in metadata
4) The SDK should allow you to read (write?) custom metadata from other plug-ins
5) Custom fields should be mapped to XMP