Browsing Posts tagged Lightroom plug-ins

Whatever you want

No comments

Lightroom’s SDK forum, never the busiest or most informative place on the net, has become a bit of a no-go zone lately as one particularly pungent forum member (let’s call him Borat) seems to feel the need to advertise his opinion on every topic. A period of  silence followed by modesty would probably make everyone, me included, appreciate Borat’s contributions for whatever they may be worth….

Despite this vuvuzela noise drowning any signals from the forum, I’d noticed a John Ellis posting there. I was curious because he seemed to know his way round Lua but I hadn’t heard of anything that he’d released – until yesterday when he announced his Any File plug-in:

Any File lets you import any type of file into a Lightroom 3 catalog and manage it just like a photo — PDFs, documents, spreadsheets, audio, etc. Typical uses include managing releases, invoices, notes, scans of old documents, audio tracks for slide shows, and avoiding all of the LR 3 limitations on video formats and video metadata.

I’d been wondering if anyone would do something like this. Frankly, it shouldn’t be necessary – Lightroom itself should allow the photographer to decide what type of files to catalogue, shouldn’t it?

Syncomatic’s original idea was to sync the metadata of files where their names are the same but they have different file types – for example, from 123.cr2 to 123.tif.

However, by default Lightroom adds -edit to the file suffix when it sends a file to Photoshop and plenty of photographers identify different versions of a picture by adding other suffixes to the file name. For example:

  • The original 100703_0123 Jones wedding.nef, 100703_0124 Jones wedding.nef, 100703_0125 Jones wedding.nef…
  • A version with Photoshop layers 100703_0123 Jones wedding Layered.nef …
  • A black and white version 100703_0123 Jones wedding BW.jpg …

Syncomatic 1.21 is released today at Photographer’s Toolbox and now handles these suffixes.

Tim Armes’s Lightroom plug-in site, Photographer’s Toolbox now has a blog to announce new plug-ins from Tim, me, and from Matt Dawson. There’s also a Twitter feed for quick announcements.

My latest plug-in Syncomatic is uploaded and available. Syncomatic is not a plug-in everyone will need but is designed for circumstances where you need to copy the metadata between two groups of files and can use the filenames to match up pairs of images. So imagine you have lots of raw files with metadata, and TIFs or JPEGs whose metadata should match the raw files from which they were created. Syncomatic simply runs through the two groups of pictures and makes the metadata of 1234.jpg the same as 1234.raw, makes 6789.jpg match 6789.raw….

Dossier de Presse is a Lightroom-WordPres plug-in from Luc Renambot:

I’m using WordPress with the NextGEN gallery plugin and I used to export my images to disk and then create a gallery and upload the images. They are (better) plugins to upload to WordPress, but I couldn’t find one that supported NextGEN gallery plugin. So I wrote my first Lightroom plugin, “Dossier de Presse“.

It allows you to export pictures directly to your WordPress blog. It supports NextGEN gallery and WordPress Media library. You can optionally create a post including the exported photos (the post is left in draft mode, so you can edit it later).

Locktastic is now available through Photographer’s Toolbox. This simple plug-in for Lightroom 2 or 3 is designed for photographers who lock or tag files while shooting events, and once they’re in Lightroom it marks those thumbnails with the red label.


I’m pleased to announce that Search Replace Transfer is now available for sale at Tim Armes’s site Photographer’s Toolbox.

Search Replace Transfer is a Lightroom 2 and 3 plug-in designed for bulk changes to text in Metadata Panel fields:

  1. Searches and replaces text like a word processor
  2. Appends text before or after existing text
  3. Transfers text between fields
  4. Transfers metadata from iView/Expression Media to 18 custom fields
  5. Audits title, caption and keyword entry

I’m already working on extending the plug-in:

  • Include the IPTC Extension fields (LR3 users only)
  • Presets and menus for frequently-used settings (eg filename to title)

Why Photographer’s Toolbox rather than here? Well, Tim is already using Photographer’s Toolbox to distribute his popular plug-ins LRTransporter, LRMogrify and LREnfuse, so we’re working alongside each other to make the site the obvious place to look for high quality plug-ins. Secondly, it means I can take advantage of his tried and tested licensing and distribution mechanism. That helps me offer trial versions of plug-ins, and provide the possibility for automatic updating of the plug-ins (based on code from Jeffrey Friedl). My other plug-ins will soon follow – probably Lockstatic, Syncomatic, and Open Directly in that order. And new ones too.

One of the less obvious changes between the beta and Lightroom 3 is the inclusion of the “IPTC Extensions“,the extra metadata fields agreed last year (specification here – PDF). Great to see Adobe’s keeping up with publicly-agreed standards rather than doing what the competitor does and pretending they don’t exist!

Some of the fields could prove immediately useful, so for instance the Person Shown (which is where Aperture should have written some of its Faces data) can be used right away. You won’t need to pollute your keywords with the names of your nearest and dearest. However, the new panel does highlight a problem of the standard creating duplicate fields – in this case the British newsreader Katie Derham is a well known person, so her name would also belong as a keyword. In the case of the location fields, these will often be the same as the traditional IPTC locations. Given that it’ll take years for search engines and other programs to start using the Extensions, you may decide that putting much effort into them is overkill.

It may help if some of this duplicate data entry can be automated, and I’m on the verge of making my Search Replace Transfer plug-in available for purchase. The licensing code is finally integrated and it should be just a matter of days. Initially, the plug-in will not write to the IPTC Extension fields, but that shouldn’t take long to add. It’s a firm plan.

When I set up my Mac laptop, I remember they tried to get me to set up a .Mac account, what’s now called MobileMe. My first reaction – you’ve just taken my money and you’re trying to tie me up even more – certainly wasn’t meant as positively as Max Mosley might have uttered it, and my disinclination to lock myself into one company’s products and services has not grown any stronger with time – despite the laptop having been a good buy. So when an Aperture preference asks me to set up a MobileMe account, I’m immediately looking for the Cancel button. Not remotely interested.

Which is a long way of saying – I’ve not tried “Export to MobileMe Gallery” myself. But one Lightroom user I mentioned it to did try it and told me it was great, so it might interest you if you use Lightroom and are one of the millions (?) who do have MobileMe accounts. It’s by Vladimir Vinogradsky, one of the quieter or semi-detached members of the Lightroom plug-in developing community, and it apparently allows you to send images from Lightroom directly to MobileMe from your Mac – or Windows PC.

I’ve said before that I intend to introduce paid versions of my plug-ins, especially Search Replace Transfer which finds and replaces metadata text, and Open Directly which sends the selected files to other programs such as Nikon Capture NX. It’s just taken much longer than I’d hoped.

Rather than half-bake my own licensing mechanism, I’ll be using the Photographers Toolbox method which includes code written by Jeffrey Friedl. Unfortunately, Jeffrey’s far cleverer than me (he understands regex) and so my attempts to shoehorn his code into mine have only been successful in breaking my plug-ins. Rather like the reborn Buddhist golfer says, that’s almost certainly my fault and I take full responsibility, but I am about to have another real crack at figuring it all out.

As part of my own rehab process, I had been resisting the temptation (mixed with self-inflicted pain) of starting any new plug-ins until I have integrated the licensing code into those two plug-ins. I had hoped to force myself to sort things out before moving on. But I have just changed tack and instead I’m going to test the waters by adding licensing to the brand new, less complex plug-in which makes its first appearance here.

Syncomatic copies metadata between files whose names match, but which are of different file types. It’s one I’ve meant to write for a while, reproducing a tool that was handy in iView, but I finally got round to it after a client ran into some problems.

She had a large number of raw files in Lightroom and had then sent TIFs to her external retoucher. She then, before the TIFs came back, added a lot more metadata to the raw files and the challenge was to update the corresponding TIFs. That’s what Syncomatic does. Whenever there are matching pairs of files, it copies metadata from one file type to the other which you choose, so another usage example might be where you have pairs of raw and JPEG files and want their metadata to be synchronised.

While I hope there are clever features in the code, Syncomatic is more straightforward than my other plug-ins – if for no other reason than being created with more Lua experience in my locker. So this week I am going to get the licensing working with it, and other plug-ins should follow.

Incidentally, Syncomatic will be LR3 only.

I've not been in a great rush to update my plug-ins for the Lightroom 3 beta - the beta's not for real work, and changes to the SDK coding environment don't appear until much closer to the final release date. But in the past few days I have updated three plug-ins which didn't work in the beta because they used SDK features which Adobe are changing in LR3:

Big Note works in LR3, while I'll soon be making an announcement about how to buy Search Replace Transfer.

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(“uk.co.beardsworth.missing”, ‘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

I rarely feel the need to edit a raw file in Nikon Capture, and I don't find much advantage from doing so. In my case, it's an admission of defeat as I should be able to do all I want in Lightroom. For others I suspect it's a somewhat dubious faith in the camera makers' secret sauces.

plug-inWhatever the reason for wanting to open a raw file in another converter, it's still irritating that Lightroom's Edit With command doesn't let you do so directly. You're forced to go to the raw file(s) in Explorer/Finder, and then launch it in Nikon Capture. Drag and drop, if Adobe made it work on your OS, is of little use if you're working in full screen mode. And if you want to send files from different folders, you have to open each one in turn. Alternatively, you can use Export, choose original format, and specify the converter as the post processing step. This plug-in eliminates those contortions.

While the original motivation behind Open Directly was that it was for these rare times when I do want to use Nikon Capture, “clunk clunk” went my thought processes and the plug-in morphed into sending files to any raw converter, so you could specify DPP, PhaseOne or whatever.

But why just raw converters? The plug-in is sending a command line to the operating system, which means one can invoke other applications too. Here one editor is set to Mac's Mail application. In this case it generates one email per file and attaches the original. Assuming you do want to send originals, now there's no need to create export versions. HoudahGeo, Geosetter, or Expression Media work equally well with this plug-in.

This version expires on 7th April2010, after which there will be a paid version (and if I don't get online ordering set up by then, I'll just upload an updated version with another free month).

No, I’m not going to write any tutorials, but Sean suggested writing some thoughts on learning Lua for Lightroom….

Getting this far with Lua has been a real struggle. I am not a trained programmer like Jeffrey Friedl. I know no C, C++, Cocoa etc, so I don’t know if Lua is easy for people with such a background (though it heartened me when he described Lua as “horrid”). But I do have a lot of experience of the various flavours of Microsoft VB and VBA, and of JavaScript, PHP, AppleScript, ActionScript 2 and 3, and other useful technologies like XML, SQL etc, all self taught. That brings a confidence that things should be possible, but it barely overcomes the why the bloody hell should I add features that should have been there in the first place? So over the last year the effort has been pretty sporadic, learning a certain amount, achieving something vaguely interesting, and then finding something else to do with my time.

I’ve always liked Microsoft’s approach to scripting professional applications – the Office suite being the prime example. There’s an assumption that you’ve got to enable the end users to do it themselves. In Cubicleland you don’t want to wait for the IT guys to write that code to automate your budgeting spreadsheet or interface with the MRP system. Bringing in a programmer means jumping through authorisation hoops, and inevitably you’ll find yourself left with something you can’t tweak as you perceive the task has nuances you hadn’t anticipated. Rely on self-interest and provide a user-friendly language and tools, and the end user should be able to do the job. That’s how I began going off the rails.

In InDesign and Photoshop, Adobe provide the perfect triangle of scripting languages, VB+JS+AS, so you can automate and streamline your work. Integration with the non-Adobe world is enabled with two platform specific languages, while cross-platform functionality is there for an Adobe-centric workflow. Imagine how great that would be for Lightroom. Someone somewhere would make Photoshop do something like apply NoiseWare or other noise reduction to a batch of images with different settings for differing ISOs. Or say you wanted to bring into Lightroom all that metadata originally entered in Aperture or that is now in the Excel data exported by some other DAM. Again, one VB or JS or AS script could do the job, and if the coding hits a problem there would be a world of experience and existing code and examples that even an ex-accountant could adapt.

Lua by comparison is a niche language, and what documentation exists is written for programmers. You have to write the code in glorified text editors rather than helpful development environments such as Microsoft’s VB IDE, and when there’s a syntax error it’s in gobbledegook that’s only intelligible once you have enough experience not to have made the mistake in the first place. Lightroom’s SDK is also mainly targeted at the developer, provides just half a dozen examples, and you can no longer learn by taking apart others’ plug-ins because everyone’s now encrypting them.

But Lua is not going away, and after a load of grumbling I usually snap (and funnily enough, as I added that link I realised that I’m wearing my Mt St Helens t shirt).

So what I’ve been doing over the last year is attacking Lua every so often. Little and often. You also need to approach from a number of directions until the penny drops. Once you’ve got the SDK, I would suggest customizing a copy of the web template. As it’s in Lua, it will get you familiar with the syntax and structure. It also has HTML and CSS elements, so you’re not totally on foreign territory, and you can focus your efforts on producing something you can use. In my case I just adapted the built-in web template so my online contact sheets have star ratings to help draw attention to the best images (as if they won’t do so themselves!).

Second, look at customizing the FTP client that’s provided in the SDK. That exposes you to how export plug-ins work, and also to the way the Plug-In Manager works.

The third area of the SDK is custom metadata, and again there’s an example which you need to tear apart and put back together again. Here you can add new fields to the catalogue, new metadata panels, Library Filter columns, and Smart Collection criteria. This area is where I’ve spent most of my real effort, and it typifies something I dislike about Lua – that you need to proceed by trial and error. Change a line, reload the plug-in, see if you’ve broken anything, hope the error message is remotely decipherable, and then see if it still does what it’s supposed to do. Only then is the SDK documentation and attempt to marry up its descriptions to what you think you’ve just done.

That’s not the only reason I keep both the SDK PDF and the API html open all the time – it’s also so you can see what else is in the toolbox. For example, while writing the last few days’ plughini I noticed that you can code the progress bar. While that’s off the critical path for now, sometimes the really hard bit is realising that something can be done. So look at others’ plugins, and note what is possible.

So a lot of of the learning process is about taking apart a series of substantially-discrete components. Adding custom fields, reading and writing fields, calling dialog boxes, accessing operating system properties…. All in a language that glories in making itself doubly obscure by calling arrays “tables” and forcing you to define that each line of code as a “row”. It’s a bit like building your own car – put the effort into learning to make the bodywork, tyres, leather seats etc, and eventually the experience coalesces and you can bolt together something that’s roadworthy. For those who know Trainspotting, and perhaps another volcanic analogy lurks here, it’s all a bit like Renton getting his fix.