15 Mar, 08

Well, now I’m up to LightRoom 1.3.1, and 1.4 has just been released, so it’s maybe worth going through this again, with the experience of a couple of trips.

Going away

I take a little notepad PC away with me, mostly for backup storage, but I sometimes do a bit of white balancing in the bedroom when I get back from diving.
I’ll setup a new folder for each trip.

So after each day’s diving, I’ll copy the Raw files from the camera (these are also backed up to DVD before the card’s cleared down) – into a folder called “Originals”.

I’ll then go into LightRoom and select “Import photos from disk”. On the “File Handling” dropdown, I’ll choose “Copy photos as Digital Negative (DNG) and Import”. I ‘ll check the “Organise .. Into one folder” box, and create a subdirectory called “Masters”.
I’ll also check the”Don’t import suspected duplicates” box, so that loads on subsequent days don’t overwrite what I’ve already done.

I’ll also set up a file naming conversion, and put the copyright in the Metadata, but that’s just for me.

Then we get into “triage”. Any tests / really blurry / full of backscatter shots are deleted (and deleted from disk) straight away, by right-clicking and selecting [Delete Photo].

I’ll then do some rough exposure / white balancing, and start identifying picks / rejects. These aren’t final or complete decisions.
I may assign a few keywords – typically the dive number.
Then I’ll head off to the restaurant / bar.

Home again …

When I get home, I copy the folder onto a removable / USB drive, plug it into my (more powerful) desktop PC and start work.

This is where I start keywording in earnest identifying any species I don’t recognise, as well as fine-tuning the exposure / white balancing / hue adjustments etc.
I’ll also work on any cropping that’s needed.

I’ll also review the “Picks”, and assign a rating.

• Photos flagged as “Picks” will be uploaded for printing (one way or another). This is done by clicking “Export”, and picking appropriate options. I’ll output these as maximum quality JPG, no resizing. sRGB colour space seems to minimise compatibility issues.
• “Picks” rated over 3-star will be exported for the website. Same method as above (I don’t use the LightRoom “Web” option at the moment), but constraining to 640 pixels / side.

Before the web pages are generated, I’ll have updated my logbook database so that the web pages can pick up the dive details.
With a smooth run, I can get the images up within a couple of weeks.

The theoretically unfortunate side of this process is that I’m going through two generations of JPG (… although it doesn’t actually seem to hurt too much). This is because LR is a bit limited at the moment in its watermarking and frame generation options – although I may be able to work around those at some stage, if I can get to grips with the Lua-based SDK. There are a few plugins starting to creep out …. I’ll still need to integrate the dive details, but that could happen on the server.

The second of these generations is introduced by JAlbum, which has been absolutely superb software – and the underlying basis for this site – for the last 4 years or so.

MuttzNutz – the new generation

However, the page layouts are fairly settled now, so I’ve been working on reworking my skin to generate php code, rather than the XHTML (which my current version generates) or the original HTML.
I’ll probably be writing more on this later, but as this site’s content is growing, I’m looking for more flexible ways to get to the images. So rather than just a linear record for each trip, I’d like users to be able to select by (for example) species, family or dive site. At the moment, a server-based XML or database solution seems to be the way to go, and SQL’s more in my comfort zone.
This is why I found WOS so exciting – developing php on the host would be so clunky as to be impractical.
I may need to write other bit’n’pieces – to synchronise a server database – which could complicate things a bit, but it should come together eventually …. I hope.

Another advantage of the php approach will be that I can hold just one central template for slides (and hopefully just one for indexes), which means that layout (and some content) changes can be implemented straight away, without needing to regenerate and upload almost 3,000 HTML pages.
This should make it easier to implement support for new technologies, accomodating – for example – mobile web or PicLens.

This entry was posted on Saturday, March 15th, 2008 at 1:53 am and is filed under Post-Processing. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.