Lightroom v1.0 is finally announced. At $200 or under ?150 I feel the price is about right and am also pleased the licence isn't limited to one brand of computer (Tom Hogarty here).

Already people are posting v1 tutorials - see the wonderful Adjustment Painter - and I thought of doing one or two, but my book's out in a couple of months and I really don't feel like going over what already seems old ground, not here anyway. I have though been lucky enough to been working with beta 5 daily, so I thought that over the next few days I'd try to be a little more reflective while highlighting one or two features I really like.

Tutorials always risk focusing on detailed tactics rather than overall strategy, and that's particularly true of a program like Lightroom. Sure you need to know the tools, but when you're working with large numbers of pictures, you've got to lose the fine art one-off mentality that's appropriate for Photoshop. In Lightroom the best analogy is with humble spreadsheets and you've a grid of hundreds of records (pictures in OldSpeak) to manage and process - it's efficiency that matters. So unless you've time on your hands, try never to work on one image at a time.

This means using Library's Quick Develop as much as possible. That may be a surprise, especially if you fall into the trap of thinking QD is only “quick and dirty“. QD has two key uses - during evaluation to adjust pictures so they can be fairly compared, and then for processing many pictures so they are very close to their finished state. There will be times when you need a premature foray into Develop - for instance yesterday I accidentally underexposed a sequence by three stops and needed to see noise reduction's effect before I could decide whether to keep the pictures. But in general, develop your pictures in Quick Develop, until you can do no more or need a specific feature that is only available in Develop.

Keeping this focus on volume, my favourite Beta 5 feature is in Develop - Auto Sync mode. In Develop, the default process is to adjust one picture and then use the Sync button to copy the adjustments to the rest. That's not terribly efficient. So hold down the Ctrl/Cmd button and click the Sync button - it changes to read Auto Sync and Lightroom stays in this mode until you change it back (why???). What it means is that any Develop adjustments apply to all the images you've selected. Sure, every now and then I forget which items I have selected and apply adjustments to the wrong pictures. But that's no big deal - you have undo, and can flash the Filmstrip with the F6 key. And you either learn fast or are too slow-witted to benefit. Since this feature was introduced, it's the only way I work.

Update
Notice that holding down Alt/Opt + Ctrl/Cmd changes the button's display and switches you temporarily into Auto Sync mode, so you can use the mouse to change a slider setting. Ctrl/Cmd clicking the Sync button switches you “permanently” into that mode.

There's an interview with Lightroom's chief designer Mark Hamburg at Since1968.com:

The volume problem really hit home in the fall of 2003 when I did my first shoot of nearly 500 images in one day. The things we?d been experimenting with like light table simulations just fell apart in the face of that sort of volume.

Even after that, we kept resisting getting into hard core image management for quite a while because it would pretty obviously eat up everything else we wanted to do and we felt that Adobe had already explored image management with Photoshop Album. We capitulated eventually and it did indeed consume vast amounts of attention and resources and probably could have taken even more if they?d been available.

So that?s my partial defense for why it?s taken so long.

Funny. I've always felt processing and managing pixels were two sides of the same coin. Let's hope they get it right in the end.

Via Sean McCormack.

I'm not overwhelmed by Lightroom's web gallery generation module - behind the scenes it's overcomplicated to customize, for instance to add a shopping cart link. But I was a bit overrun with work when Adobe Media Gallery was published and have only just got to look at it:

Photoshop Elements and Lightroom ship with a single SWF file containing the gallery program, which users can customize extensively using the authoring interface in those programs. These programs produce XML files that the SWF parses to style the gallery and determine its content.

Essentially Lightroom's Flash output is an interface to this AMG component, and there's nothing at all to prevent you from generating the XML from another program such as Portfolio or iView, and using that data to power the Adobe Media Gallery's Flash movie.

The attached VB code is my first attempt for iView. It regenerates the group.xml file, and you will need two iView Convert Images settings files, and a little confidence in hacking my code.

It's completely unsupported, but let me know if you try it.

Update - didn't realize that the script wasn't displaying correctly, so here it is: Adobe_gallery_maker.vbs

The other day I posted about being able to examine the Lightroom database using the open source SQLite Database Browser. Well, according to Fazal Majid, Aperture uses the same underlying database….

Find the Aperture library, right click it and select “Show package contents”. The application data seems to be a folder structure with a large number of files, most of which are actually xml. There's also a file called “Library.apdb”, and this is the Aperture database.

Two thoughts:

1) So both Lightroom and Aperture databases are open and accessible via ODBC. Now, while I don't like the look of data blobs, but what's to stop someone figuring out how to pass settings between the two?

2) How long should we make do with cataloguing databases whose underlying databases are closed?

There's a new Lightroom podcast at George Jardine's iDisk (look for “1127 Podcast - Phil Clevenger and Mark Hamburg”) which initially focusses on the programs interface design. A little on the bland side - you'd hardly base a design on anything other than a “content is king” mantra - but it's interesting enough as it develops and digresses. Since using Aperture, I like Lightroom even more and the interface is a big part of that. I'm not sure about the designer Phil Clevenger's experience, but I've always felt Lightroom's look and feel is very reminiscent of Macromedia's Dreamweaver. And having used the latter for nearly 10 years, for me that's no bad thing.

“Version 1 is about where you stake your claim, version 2 is where you get it right.”

SQLite Database Browser is a browser utility for databases written in SQLite… such as Lightroom. Right now it's very basic, but it's a really easy way to open and examine Lightroom's tables, though I'd only use it if you're the sort of person who reads confirmation dialog boxes asking if you want to delete a table or record. Built on top of QuickTime, it's also cross platform.

Lightroom Podcast 24 is definitely worth listening to. Three of the main guys behind Photoshop and Lightroom, Zelman Stern, Thomas Knoll and Mark Hamburg, discuss the development of Lightroom and ACR 4, and if you listen carefully you'll hear you a lot about what may well be in Lightroom version 1….

Find it at George Jardine's iDisk or by searching for Lightroom in iTunes.

Inside Aperture blog contributor James Duncan Davidson writes on his own blog about Aperture vs Lightroom RAW Conversion:

Does this mean that Aperture is off my system? Heck no. I'm not tossing 31,000+ images at Lightroom anytime soon. Aperture kicks Lightroom's butt at organization and management. And Aperture has done a great job with generating screen-based images for display. But, Lightroom kicks Aperture's butt at rendering RAW for printing at large sizes?at least some images. With others, Aperture holds its own just fine. At least right now with Aperture 1.5.1 and Lightroom Beta 4.1.

Having loaded the Aperture trial on my Mac over the weekend, I'll post my own thoughts soon. And I will be fair to Aperture, honest.

So, the news is out about what iView is going to be called by “beauty makes us think better” Microsoft:

Expression Media is a professional digital asset management tool to visually catalog and organize all of a creative professional?s digital assets for effortless retrieval and presentation. Expression Media is due to be released in Spring 2007 and will retail for $299. Expression Media will be a free upgrade for registered users of iView MediaPro 3.

$299 for new users - now, that's a bit steep. It'll have to have some seriously-good new features. After all, I bet $299's what Lightroom will cost, and it processes pictures too.

Most interesting is that Microsoft are positioning iView with a set of tools aimed at the web and design communities, not at photographers. It clearly makes sense to attempt to gain more of the web design market - Visual Studio is fine for connecting to back end databases but isn't how you'd want to design a site's front end. So iView will be part of a suite with “Expression Web… a professional design tool to create modern, standards-based sites which deliver superior quality on the Web.” Of course, being standards-based is like being for motherhood and apple pie - luckily for Microsoft there are lots of standards out there. Apparently an upgrade for users of the execrable Frontpage, it sounds like Expression Web is yet another sad charge uphill into Dreamweaver's guns….

Also in the suite is what sounds like a Flash authoring tool, “Expression Blend … the professional design tool to create engaging web-connected experiences for Windows.” Eek. Web-connected experiences? The other product “Expression Design is a professional illustration and graphic design tool that lets you build compelling elements for both Web and desktop application user interfaces” looks like a vector drawing program whose clear description is blissfully untouched by expensive marketing guff.

But where is the photography part of the suite?

As I said when Microsoft took over iView, by the time we're able to decide whether the takeover was a good thing, we'd already be using Lightroom in any case. On the other hand, what part of “free upgrade” don't I understand / like?

Maybe next week I’ll have a bit of time to try out Aperture, Apple’s Mac-limited raw processing and picture management program, but I enjoyed reading this thread Improving Aperture.

Yes, it was me suggesting they make it run on PC, but wouldn’t that be an interesting response to Lightroom when it’s finally released?

Apple's Aperture may still be Mac-limited but with Lightroom looming Apple have decided to provide a 30 day trial. Now how hard was that? Anyway, now I've also got a Mac there's no excuse other than time pressure for trying it.

Helpfully O'Reilly have launched an Inside Aperture blog with handy advice on spending another $1000 or more so the program doesn't run sluggishly on your new Mac. Oh well, but let's keep an open mind….

Michael Reichmann is brewing a storm in a teacup about Hasselblad's decision to make their latest body only take Hasselblad digital backs. It has sparked quite a fuss in the site's forum, and one poster ejaculates:

It looks like they (Hasselblad) are simply trying to knock down the competition while locking in their customer base. Nothing new in that; sort of reminds you of Microsoft and Adobe.

Apple would never do such a thing, would they? Of course it's just the usual Mac-blinded brand religious nonsense. But it set me thinking - what would be the impact on Adobe and Lightroom if Apple decided to make their Mac-limited Aperture available for the PC?

Lightroom beta 4 came out earlier this week - see Ian Lyons's notes. It has made great strides in what the raw converter can do, and features like Vibrance and Fill Light take the program well beyond Adobe Camera Raw. But if you're trying it, take a good hard look at what happens when you import files by “Copy files to Lightroom Library”.

This option copies the images to a special folder defined as the “managed space”. The images are shown in shoots, which correspond to subfolders of the managed space. So move a file in Lightroom from one shoot to another, and the file itself moves between subfolders of the managed space. It makes me wonder why they don't just call these shoots “managed folders”….

While this sounds neat, it only really works if you want to keep your files in that area of your system, and never want to move any of the files that are logged “by reference” in Lightroom's library. Doesn't sound so good now, does it? Save them where we want or you're on your own. “Adobe iTunes”?

Even where the managed space concept does work well, importing a “binder” of Lightroom work from another computer, it's a mystery why the program doesn't ask you where you want to store the files and then import them to the Lightroom library “by reference”. Instead, they are marooned in the managed space and you then can't move them elsewhere on your system.

It's as if Adobe have moved too far out of their image processing comfort zone to see that the managed space concept is the antithesis of what everyone most liked about Lightroom when it was announced last January. And isn?t it ironic that their Mac-limited competitor adds import by reference on the very day Adobe launch beta 4?

Test this area now - and tell Adobe what you think.

OK, I am being mischievous by even suggesting Apple add to Aperture an “export to Lightroom” feature. And I wonder if anyone would ever find it worthwhile to map one metadata driven editor's XMP to another's sidecar format, or even one day use scripting to pass at least some data between Aperture and Lightroom.

My point is about the vulnerability to lock in of our intellectual property in such programs. This includes for example the assignment to thousands of pictures of white balance values and other low level editing metadata, but it could also cover higher level metadata such as editing steps that are much more program-specific.

Users of metadata driven editors like Lightroom and Aperture should shout as loudly when we see encrypted or locked in editing metadata (IIRC the keywords hierarchy info in LR's XMP files) as we were about Nikon encrypting the WB. We also need open standards like we have with IPTC and XMP metadata. I may not know the meaning of the value you've put in that extensible XMP field, but I should be able to read it and have a fair chance to work it out and take at least some of my editing metadata elsewhere.

With metadata, whether it's informational or editing, you've always got to look at your future exit strategy. If you can't see a way to get just your keywords out of a program, should you ever have put them in it? How far should the same stricture apply to editing metadata?

If you're into Lightroom, keep an eye on Sean McCormack's Lightroom blog.

I'm trying to come up with a name for programs like Lightroom, Aperture, LightZone and Capture NX that use instructions to process images. We've referred to programs like Photoshop as bitmap editors, but there's no agreed name for this new field.

Peter Krogh has referred to the field “Metadata Imaging” and this seems snappy, but calling individual programs “Metadata Image Editors” doesn't do it for me. He also tried to start a debate and wrote of “metadata-based-editing” and of programs as being SISI, short for saved-instruction-set imaging.

But what's the noun? Calling them sissies isn't macho enough and while I tend to think of them as “stored instruction set editors”, I always feel happier with 3 letter acronyms too. So one I just came up with was Metadata Driven Editors - MDE's - and I rather like it despite dropping the “Imaging”.

Any views on these? Any more to throw into the mix?

Added a group of photos to the History section. They are from a day I spent with American Civil War re-enactors back in October 2004. Some were already on the site, but I've given them all a new treatment using Lightroom. Apart from making them b&w and adding a purplish selenium tone, I also darkened the corners by using Lightroom's vignetting control to increase rather than correct vignetting. This could of course have been done in Photoshop but not so quickly to nearly 200 images at a time. In Lightroom, I fine tuned one picture, saved the treatment as a Develop Preset, applied it to the rest, output them all to a private web site, then used Undo to restore the pictures' appearance to normal.

You can save my Brady effect preset in C:Documents and Settingsyour_usernameApplication DataAdobeLightroomDevelop Presets on Windows and in /Library/Adobe Lightroom/Develop Presets on the Mac. And people are already sharing Develop presets. But don't forget Lightroom's only a beta and Adobe are free to finalize the product without making such presets compatible with the finally-released program.

Working on multiple images will soon be the norm. Where that will leave single image editors, above all Photoshop, is something only time will reveal.

It's frustrating that the Lightroom beta only lets you work with one library, and that by default it's created in My Pictures. A quick workaround is to close Lightroom and cut and paste the library from My Pictures to wherever you want. Next time you open the program, it'll ask you where to find the library.

That solves the matter of where to store the library, but some of us “need” to have more than one library for different projects. Well, move your existing library as above, restart Lightroom and instead of finding the library's location, select create a new library and immediately close Lightroom. This creates a new blank library in the default location, so simply cut and paste it to where you want.

You can repeat this process to create multiple libraries. Double click the aglib file to force Lightroom to open it, or hold down the Alt key immediately after you double click the Lightroom icon - this launches the File Open dialog.

Isn't the Internet wonderful? Only a few minutes ago I posted about Marc's Rochkind's genius for revealing the Lightroom database structure. Add Christian Werner to the list - a minute after installing his SQLite ODBC driver I could examine the Lightroom tables in MS Access.

Marc Rochkind doesn't need his Wikipedia entry to show he's clearly a very smart guy. Not only is he developing ImageIngester, a sophisticated flash card downloader that backs up, verifies, adds metadata and logs the whole process, he's also figured out the Lightroom database structure:

For your reading pleasure, here's the output of the SQLite3 “.schema” command:

CREATE TABLE Adobe_AdditionalMetadata (
id_local INTEGER PRIMARY KEY,
id_global UNIQUE NOT NULL,
image INTEGER,….

I'll spare you any more of this script, and it's interesting enough for us pointy heads to imagine some of the program's future directions (after all, it is being developed dynamically - my way of saying they're making it up as they go along).

But the real point of Marc's revelation is this: as things stand, users will be able to automate all sorts of Lightroom tasks by writing directly to the database. For example, the program currently lacks the ability to do what iView calls Find Missing Files, but it would be relatively easy for a script to check that files are where the Lightroom database thinks they are. Equally, if you move files to a new drive, it would be possible to do the equivalent of iView's Reset Paths, updating the Lightroom database. We just have to keep our fingers crossed Adobe don't lock up the database