Just as a lot of photographers think they have to go Mac, a lot think their web site has to be Flash-based because it stops people stealing their pictures. “Stops”, of course, has always been an exaggeration - someone could always do a screenshot or scavenge through the browser's cache folder. Flash only makes saving pictures less obvious and perhaps more time-consuming than it's worth.

But here's a handy Mac tip for you - try Apple's Safari browser, go to any photographer's Flash-based web site, and choose Safari's Window > Activity menu item. You get a nice little list of all the files which make up the current web page, including JPEGs called up by the Flash movie. Double click one and it opens in a separate browser window, ready to save to your hard drive. It's not much harder than saving pictures off an HTML gallery, is it? I've yet to find a photographer's Flash-based web site which has resisted this simple method - my own Flash-based pages included.

Fortunately Mac users are generally more honest than PC users, aren't they? Rafa Benitez fact or what? Safari is available for PC and is pushed suppository-style with iTunes and QuickTime updates.

It certainly makes me feel I've been rather complacent so far, but more generally it emphasizes that a photographer with a Flash-based web site really can't be any more lazy with deterrents than one with an HTML-based site.

As a bare minimum, it means embedding your copyright metadata in your pictures - which the thief would have to spend time removing, or leaves evidence of abuse. Better still, you want copyright information displayed on the picture itself, which helps deter theft via screen shot, Activity window, or browser cache. Lightroom's Web can add visual copyright marking, yet the feature is laughably-weak so the copyright cannot be positioned anywhere other than the image's bottom corner from where it can be easily cropped. Until noticing this Activity window, I thought my solution - putting the copyright into my Flash movie - was a much better defence, but now I'm nowhere near as confident.

As I stole a few of my own pictures using the Activity window, one thing I noticed was the lack of any embedded copyright metadata. This had all been present in the files I was uploading with the SlideShowPro Director plugin for Lightroom, but SSP Director was then generating a variety of sizes, as it should, and sending them to various Flash movies - stripped of their metadata. Yuck - if you were so concerned about file size, would you honestly use Flash in the first place? Secondly, I knew that my visual copyright marking was only in the Flash movie, fine for the main risk from screen shot theft, but no use against browser cache trawling, and now no defence against Safari's Activity window.

While I can implement this hack to preserve embedded metadata, the visual copyright issue is a tougher nut to crack. One could upload already-watermarked images to Director, but it's an extra step in what was an elegant process, and Director would then serve the pictures at various sizes and potentially introduce artefacts around the copyright pixels. Ideally SSP Director needs to do it on the fly.

The lack of copyright metadata makes me very nervous of recommending SSP Director until the default is changed or can be overridden in the SSP Director control panel. But one thing I like about SSP is that the guys both listen and respond….

Managing Photos in the Library Module of Adobe Photoshop Lightroom 2 is an entire chapter from Martin Evening's Lightroom 2 book, introducing Library's features and how to use them.

Here's a nice little touch for finding help on Lightroom matters with Firefox. Go to a topic in Adobe's Lightroom Community Help and up pops a little message asking if you want to add it to your search engines.

Update - if you don't want all that corporate trade marking, you can edit the search plugin, or take my edited xml file (zipped). The appropriate location is shown here.

Rob Boyer's All Things Photography blog includes Aperture tips and has also ventured into the dangerous waters of direct Aperture versus Lightroom comparisons. While overall Rob's about as fair and balanced in advocating Aperture as I am in preferring Lightroom, some judgements fall in Lightroom's favour. For instance, see his comparison of Aperture and Lightroom keywording:

[In Aperture] you can do crazy stuff like running scripts that smash the entire hierarchy into each of your images based on the specific keywords but that sort of defeats the purpose. Lightroom on the other hand will export the entire hierarchy for each specific keyword, but wait there's more, for each and every keyword Lightroom let's [sic] you specify whether or not to include the parent keywords and… whether to export it at all.

…Score a big win for Adobe Lightroom 2 versus Apple Aperture 2 when it comes to keyword functionality.

While I think his conclusion is right in this case, it shows a couple of dangers of such comparisons.

One is that it's easy to have misconceptions about how people actually use “the other” program's better features. Lightroom's keywording is so very flexible that a lot of people are led to abuse its power, exploiting the feature to add keywords which do not describe the image. So I've heard plenty of cases of people including workflow-related keywords like “not done”, “developed”, “final”, or including stock agency names as not-to-export keywords. Worse still is when they're encouraged to exploit Lightroom's keywording in this way without always understanding that it is a workaround for proper database and cataloguing features. While the keyword-abusive approach can certainly be made to work, sooner or later someone forgets to tick that do-not-export box, there's a need to exchange metadata with another app, or the export flag is misread by a bug in a new version's upgrade process. Suddenly you've got private keywords, custom metadata, getting into files exported from the system, and your filters and smart collections are picking up items with “workflow keywords” when they're supposed to target proper, descriptive keywords. Isn't any workaround always destined to be a dead end?

Rob's post is also a great example of the dangers of considering a single feature in isolation, because while Lightroom's keywording may well be better than Aperture's, the feature's flexibility allows Adobe to get away with failing - unlike Aperture - to include a proper custom field feature, which is where custom metadata really belongs.

Launching a Flash site has always been a background project – it’s not as if I’m unhappy with the current site – and it’s pretty easy to find a reason to keep it in the garage and keep tinkering away. Learning ActionScript3 was the latest reason for such delay, but I’ve convinced myself it was probably the right move. Just like that Iraqi reporter didn’t target Dumbo Bush with old sandals but chose his latest genuine Timberlands, it would feel a shame to launch an ActionScript 2 version. Even now, when I feel I’ve cracked ActionScript 3, I’m sure I’ll find other reasons for delay – that light at the end of the tunnel could always be a fast-approaching train.

Still, intense beavering-away does sometimes deliver fruits ready for public display. I already had some Flash-based galleries on this site, all based on SlideShowPro and ActionScript 2. They were all powered by Director, SlideShowPro’s online content management system, and adding new images was a simple matter of running a Lightroom export and choosing which album to target.

I had a couple of less-edifying but more-visual reasons for switching these to ActionScript 3. A big one was that with a single line of ActionScript 3 you can make a Flash movie colour managed – see John Nack’s post (for this to be visible, the visitor has to be using a colour-managed browser and the Flash Player 10).

Secondly, I liked the look of SlideShowPro’s new ThumbGrid component. It’s a $24 add-on to the SlideShowPro Flash component, replacing the built-in navigation, and it is only for ActionScript 3. See how it works here.

The only regret about not launching the fabled Flash site has been its stubbornly-constipating effect on putting new pictures online. So for an example of ActionScript 3 + colour management + ThumbGrid, see the mostly-new American Civil War gallery.

Let's say you have a bunch of raw files adjusted with Adobe Camera Raw, and you want to make a load of JPEGs. It's not a novel nor a difficult task - Lightroom's export function is designed for the job, or if you're using Bridge you might reach for the Image Processor which runs the files through Photoshop. Another Bridge-based solution would be to open all the raw files in Adobe Camera Raw, select them all and hit the Save button.

In each case, your poor computer is having to create the JPEGs by processing all that raw image data. But because it is doing so, you can at least be sure that the JPEG output does reflect all your Camera Raw adjustments.

But it is not quick, and it is a pain when Lightroom or Bridge has already done the hard work of updating thumbnails and previews (particularly when you think that Lightroom now updates Bridge's Camera Raw cache).

A new option is Bridge Export to JPEG (it's called BridgeExportToJpegCS4), a script by Adobe's David Franzen which he has significantly extended for Bridge CS4, adding presets, metadata and colour profile options. Its beauty is that, rather than reprocessing the raw images, the script uses the previews which Bridge has already rendered and stored in its cache. So, if you already have updated thumbnails and previews, it's light years quicker than the other options.

Not long ago I almost linked to Micah Walter's Inside Aperture article Seeing RED. He's now doing more video and is having problems managing the new file types:

What would save my day would be Aperture. If only Aperture supported AVCHD (and many of the other tapeless formats) I could import my AVCHD card just like I do with my DSLR. It could import any stills from my HD camera, as well as all of my native clips. It could allow me to preview my clips, maybe even set in and out markers and I could select a batch of clips and still frames to send off to Final Cut Pro for production. Final Cut could be responsible for converting the clips to QuickTime format (or not) and everything would just be in one place in an Aperture project.

Can't recall why I didn't link to it - probably because he is explicitly talking about "proper" digital video - but now it's worth comparing with Sean MacCormack's post Video and Lightroom:

In these days of convergence, where 2 of the newest DSLRS offer HD video recording capabilities (albeit basic), and almost every compact has some kind of video mode, I'd like to see Lightroom support Video. At minimum, I'd like it to import the video with my images. Preferably, I'd like to be able to playback the video and perhaps add basic metadata (copyright, keywords etc). I have no expectations of being able to edit video, or even work on colour, brightness etc. I just want to have my video managed with my images.

What we're seeing is the start of a battle for the soul of Aperture and Lightroom. Yes, I know that sounds almost as ludicrously-hyped as the Strictly Come Dancing judge saying John "the dancing pig" Sergeant had made the show a laughing stock, but both Aperture and Lightroom users fall into two distinct camps over this issue. On the one side are those who only see the Aperture and Lightroom as Photoshop substitutes for the DSLR era. And on the other are photographers who need a tool for photographers - which need not be limited to photographs.

I have negligible interest in video - photography's decisive moment satisfies me much more than video's hoovering-up process - but I've always been very much in the latter camp. As part of photography-centred projects and tasks, I might have PDFs such as contact sheets or layouts, Word documents such as correspondence or invoices, sound clips to include in the DVD of a wedding shoot, while it's crazy that Lightroom can send to Photoshop HDR merging yet be unwilling to manage the 32 bit output files.

I'm very much a believer in database-powered applications for managing picture collections, so the solution isn't Bridge, much-improved though it is, as it remains a Windows Explorer or Finder with knobs on, which can only ever tell you where files happen to be now, not where they should be. So I've always wanted Lightroom to be an iView with raw processing, not a narrowly-pretty face for Adobe Camera Raw.

I'm not sure if proper video and the convergence issue are a pair of Trojan horses (these are the days of Boris says teach yobs Latin and Greek and Obama's classical oratory) or perhaps they are twin battering rams? Either way, wheel them up, now please.

Update - 5-6 comments were lost during my web site changeover. They were both pro and against.

A quick pointer to Image Doctors podcast for November 13th which is on Lightroom 2.0 and is essentially a 45 minute interview with Tom Hogarty, Lightroom's Product Manager.

You can see one of the presenter's Yosemite pictures here - most aren't as artificial-looking as this one though.

I've had ProShow Producer for a year and intended to use it to prepare a multimedia slide show of a wedding I recently shot at Cliveden. And just in the nick of time, there's now a ProShow Plug-in for Lightroom. It's another export plug-in - these things are beginning to pile up, aren't they?

As Proshow is still Windows-only, surprisingly, here's a screenshot so Mac users know roughly what the plug-in does (I often hear Mac converts who miss ProShow). You set a range of ProShow parameters such as transition style, and titles, captions and copyright information from the catalogue's metadata. Lightroom then generates JPEGs, and starts up ProShow with the slideshow built. You can then add other features and edit the show before burning it to DVD, Blu-ray, Flash, YouTube, iPod, Blackberry….

It seems pretty neat. As I'd like to do something fancy for the wedding, I'll be giving it a severe test over the next week or so.

One annoyance of Photoshop/Bridge CS4 is that it won't read any existing custom File Info panels. These let File Info display XMP metadata from other applications such as iView or Expression Media, and they were written in a text file format which was reasonably easy to create and edit. In CS4 though, the panels are Flash-based and at first glance it looks like you would need to buy Flex Builder for the job. Uh-oh, not another solution for developers who need paying, rather than users who know what they need and might hack their way there?

I don't really have the energy or interest to learn Flex, certainly not ahead of current efforts to learn ActionScript 3 for my Flash site, Lua for some Lightroom ideas, or ahead of getting my beauty sleep (I don't need too much of that). But look at Gunar Penikis's last paragraph here:

Hey guys relax. CS4 does not support reading CS3 panels - the reason for this is that the old format is pretty crufty and the energy would be better spent on building a really flexible UI. So we chose Flex (Flash) to base the panels on. The SDK is available at: http://www.adobe.com/devnet/xmp/

Note that you don't have to buy Flex Builder but it does make life easier.

Most importantly there is a sample in the SDK call “Generic Panel”. This is a panel designed specifically to read an external XML file of properties and display them - similar to the way the old File Info worked. Since it is XML based you can use your favourite freeware XML editor to build your panel with. The XML format is pretty simple, especially if you are used to the old panel layout language.

Adobe have been very smart with this Generic Panel. It's a compiled SWF file, so you don't need Flash or Flex, and you just have to know your way around XMP namespaces and be happy editing XML. It's not a lot more than copying namespaces and field names from File Info's Advanced panel, and pasting them into the properties.xml file using an XML editor such as something like MS XML Notepad:

In the above example I'm calling Expression Media's namespace, and then defining a File Info text box which displays the Catalog Sets metadata. If you're familiar with this type of thing, it's pretty easy stuff, and you'll just need the File Info SDK at the bottom of this page.

I've put online my CS4 File Info panel for Expression Media metadata (donationware). And here it is, showing a panel which combines metadata which one would typically add in Lightroom, such as the keywords, and Expression Media metadata such as the Catalog Sets or custom fields.

UPDATE:
On PC, put the panel in C:Document and SettingsusernameApplication DataAdobeXMPCustom File Info Panels2.0panels.
On Mac, put the panel into the Mac's Library/ApplicationData/Adobe/XMP/Custom File Info Panels/2.0/panels/, not in the user's Library area /Users/username/ApplicationData…. There's a bug somewhere - in the panel, in Bridge, or in the documentation.

One last thought is that Flash/Flex does enable much fancier and more powerful panels. I can imagine it's possible, for example, to access the Google Maps API and display a map inside the Bridge or Photoshop File Info panel (update: yes we can). Whether anyone will take advantage of this change, only time will tell.

Tom Hogarty updates the what pros use for raw file conversion comparison. Both Lightroom and Aperture increase their share, Lightroom leaping 50% on 2007 and Aperture a respectable 36%. Among Mac users only, Aperture’s share is static though, indicating the overall increase is due to people shifting to the Mac.

Of course, using one of the newer generation tools doesn’t mean you don’t use Photoshop as well, and there’s only a small drop there. These stats, though don’t reflect how much people are using each application, and wouldn’t it be interesting if one could gather similar stats which reflected time spent working with each program, or even the numbers or proportion of images? You’d have to expect Photoshop usage would be impacted much more. So, just after the release of CS4, I’m sure a lot of people are wondering CS4: What’s in it for Photographers?.

One CS4 feature I really like is content aware scaling. It’s a thing of genius, letting you squeeze an image into a layout, squashing the image areas with less detail and yet protecting those where there is important detail. I’ve slightly overdone this example, but you can see how the car is barely affected by compressing the image into a more square format. The feature’s very easy to use, and perhaps some would find it hard to imagine when they would use it, but for others it’s going to be a very popular feature indeed.

The picture’s from Sunday’s London Brighton Veteran Car Run. Taken at 7am on a dark, wet November morning, it was shot on the Nikon D700, handheld, and with the ISO set to Auto. In this case, ISO 1800 gave me 1/200 second at f7.1 – I’ve plenty of usable images at ISO 3200 too.

I was asked recently for a few reasons why I still use Expression Media (I still call it iView) rather than depending entirely on Lightroom, so in descending order, here goes:

• By far the biggest reason is to manage in a single place all files related to photographic projects. For me, like very many photographers, that isn't just photos, but might easily include sound clips from wedding shoots, PDF contact sheets, the odd ProShow presentation, as well as any correspondence. Ideally Lightroom should control all these file types, but it doesn't, yet.
• iView's very much faster generating large numbers of JPEGs for emailing or for making a web gallery of a whole shoot. This is because it uses the Lightroom-adjusted preview in the DNG, while Lightroom needlessly reprocesses the raw data.
• I depend on custom fields for recording who's featured in my re-enactment pictures and finding them quickly, and for grouping frames shot for stitching or HDR. While the LR2 SDK does now let you add custom fields, it's too new and undeveloped, and you can't read/write the metadata to/from images. iView does this, so any TIF made from a DNG automatically inherits the original's custom metadata, making it easy to marry up a stitched panorama to the component frames, for example.
• I greatly prefer the flexibility of iView's low tech HTML templates to Lightroom's Lua-based ones.
• iView has scripting using widely-known languages which I can quickly use to copy IPTC location information over to keywords, for example, or to search and replace within captions (eg for typos). It gives me the flexibility to write a simple script in a text editor, or in a well-established development and debugging tool such as Microsoft's VB editors or Apple's Script Editor. Lightroom's comparatively-obscure Lua is an inhuman programmer's language wrapped in layers of nested functions, has little documentation written for non-programmers, gives indecipherable error messages, has no development tool more helpful than a text editor - and in any case has restricted access to metadata. For me, end user access to scripting is one badge which makes a program a professional tool, and it should be present from day 1.
• Using beta versions of Lightroom, and testing them more brutally than may be wise, I want a rock solid DAM base.

There is a huge value in one application combining file management, adjustment, and output. I'm a big user of LR2's smart collections which can automatically group new pictures meeting a wide range of criteria. Migrating to a wholly Flash-based web site, I'm using Lightroom's SlideShowPro export. And maybe the SDK may offer a way forward for my custom metadata. Even though I'm unsure what I want to do about types of files which Lightroom can't import, the balance is certainly shifting and I'm relying more on LR as months go by.

I recently saw a wedding book some friends had created using Photobox. They wouldn’t claim to be computer-savvy, but they’d done a great job and were able to give copies to close family. It should be just that easy, shouldn’t it, and I am more than a little frustrated that Lightroom still doesn’t have a book layout tool. No doubt it will come, even if only via an Export plug-in.

Anyway, putting together a book of my Sealed Knot pictures earlier this year in InDesign, one big irritant was displaying text next to the pictures. I couldn’t bring myself to retype or cut and paste the captions, knowing the images contained the metadata added in iView, Lightroom or Photoshop, and I don’t think it was my inexperience with InDesign. As it was, I got distracted, but next time I have a crack at it, here’s an InDesign script which pulls XMP metadata from an image and places it below the picture. Now I wonder if that could be launched from an Export plug-in….

Also a little link to Gunar Penikis’s blog and a post on the new XMP SDK. There seems to be more scripting access to XMP, and also the latest way to customize the File Info panels.

Over at the McCreate site (which first adorned the web as Aperture Professional Users Network, soon dropped the word “Professional”, and then dropped the rest) John Omvik does a lengthy comparison of Aperture 2.1 vs Lightroom 2.0 – Different Approaches to Local Image Corrections:

So Which Method is Best?

Both methods offer advantages and disadvantages for local corrections. After working with both I have to say that I am very impressed with the speed and flexibility the Adobe solution offers. I like the open plug-in concept from Apple, but feel that the implementation leaves much to be desired, especially as it relates to the rest of the non-destructive workflow.

My ideal solution would be a plug-in architecture that would allow for 3rd party plug-ins to be integrated in the processing pipeline offering the extensibility of Aperture with the speed and non-destructive functionality of Lightroom.

Pravda extolling the virtues of capitalism? But these are days when the Russkies are oil rich capitalists and the Yanks are merrily nationalizing the banking system….

Lightroom 2 lets you send a panorama's component frames directly to Photoshop, but they're sent full size. Unless you really want a massive full size stitch, that slows down Photoshop's panorama processing. Instead, Martin Evening has done a video showing a method which gets round this. Initially Lightroom sends the files to Photoshop as layers of a single document. You resize this document to the size you want, and then run the panorama stitching on the smaller file.

While Martin emphasizes its value for matching processing time to your intended output size, the technique should be most valuable when you're simply proofing a panorama. After all, sometimes you need to test with a different panorama rendering method, or in other cases the panorama just doesn't turn out as well as you had hoped. This technique means you can simply reduce the image size, maybe even the bit depth, and can always Undo and try an alternative rendering method.

The second tip is equally ingenious and a far more intelligent use of Develop Presets than all those canned looks that some people love to collect. If you are experimenting with LR2's alternative Camera Profiles, Sean McCormack suggests “you want to preview them to see what suits. Well, changing them in Camera Calibration will let you see them, but it's a bit tedious. The obvious answer is much easier than you might expect: Create a batch of Presets!” Read more

Although Sunday’s annual Borrowdale Shepherd’s Meet had been cancelled, I knew the fell run was still happening. A book I’d been given last Christmas contained Patrick Ward‘s great wide-angle photo of the nearby Wasdale fell run, and I wanted to exploit the combination of the D700 and my 17-35mm f2.8 lens in a similar way. Wide angle shooting is the D700’s biggest plus for me so far (funny how easily you can forget what wide really means).

These blokes, some young and others in their 70s, race up to the top of Borrowdale‘s 750m / 2500ft Dale Head fell and the fastest ones are back in Rosthwaite village in just about 45 minutes. A “fell”, if you’re wondering is the Lake District word for the hills, and is of Norwegian Viking origin. So, like the word “dale” for a valley or “thwaite” for a clearing, the names reveal the region’s settlement history – nearby Keswick’s kaese is from the Norse for cheese and the wick indicating a farm.

I already knew the route and chose a spot just above a gate where I knew the runners would have to pass – it took us 45 minutes to get up there – and where I would be able to scoop up the runners and the valley.

The previous day, at a Sealed Knot battle, I had played with the D700’s focus tracking, leaving the focus mode on Continuous and the focus area on Auto – “the camera automatically detects the subject”, says the manual. The D200 had a similar feature which I never found very effective, but during the battle I let the D700 identify a fast-moving subject and track it across the frame. It was one of those bloody hell, it’s really doing it, road-to-Damascus moments. So I decided to try it for real with the fell run, and it worked like a dream, snapping focus onto the runner and tracking him perfectly. Previously I would have worked in 3 phases – focus, recompose, shoot – but now the camera was allowing me to compose and shoot when the subject had reached where I wanted him to be in the frame. As a result, I got loads of these shots of the runners on the way up and then leaping over a gully on the way down.

Another D700 aspect is that I think the camera has an Auto ISO mode somewhere. If so, I didn’t use it, and these pictures were mostly taken at ISO 800, with some at 400, and others at 500 or 640. In other words I was always thinking about the ISO as well as the aperture/shutter speed combination for enough depth of field to show where they were running while also freezing the action (in this case generally f7.1 and speeds over 1/500). Just as the D700 handled the focussing and let me concentrate on composition and timing my shot, the quality of the D700’s higher ISO captures make me wonder if I should have chosen Auto ISO and eliminated one leg of the ISO/aperture/speed triangle. Scary perhaps, but certainly not absurd.

As an experiment, I’m displaying the pictures here using SlideShowPro. As usual, they were processed in Lightroom and I then used File > Export and the Lightroom to SlideShowPro Director plug-in to upload them directly to a new SSP Director album. The beauty of this solution is that it’s quick, a few clicks, and I can use the images for multiple purposes – SSP Director holds the images at full size and generates the output size on demand. Here I display the pictures in this post, inserting an IFRAME with a web page which calls up that album in a Flash movie (that page is PHP and accepts the album code as a variable). Alternatively, SSP Director could supply different-sized images for my existing web galleries and also for my Flash site. If my Flash site scaled images to fit the user’s screen size, SSP Director would automatically handle that for me, caching the pictures on the server via ImageMagick or GD. Hopefully that’s an interesting detail – at least for some of this blog’s readers! In short, it’s a very efficient Lightroom-web workflow and not as complex as it might sound.

It’s not specifically a Lightroom thing, and I say the same about Aperture and Expression Media 2. And I admit that I am a bit out on a limb here in holding these opinions….. But I find hierarchical keywords to be an utter pain, and simply not worth the effort.

It doesn’t matter how much I try, how disciplined my working practices, how well I understand Lightroom. The trouble with hierarchical keywords is I always end up with child keywords somehow re-appearing at the top level. This can happen, for instance, when I re-import a picture that’s been processed in another app. Or I notice that a group of child keywords has managed to become duplicated in more than one part of the hierarchy. Usually this is because I’ve done something like change the hierarchy at some point and imported an older file, or more often that I changed the hierarchy on my laptop and then brought files over to the main PC. Whatever I do, something always screws up my neat, logical structure.

So rather than continue banging my head against hierarchical keywords I’ve simply gone back to a flat keyword list – and I’m much happier that way.

The trouble is – I think we’re trying to make hierarchical keywords fight two very different battles:

• increasing the number of keywords per image
• speeding up finding our pictures

Deep down, I’m far from convinced you ever want to confuse data entry tools with how you may subsequently search for pictures.

Instead of putting any effort into maintaining a hierarchy, my attention is now turned to alternative ways of making keyword entry as efficient as I can. That means I now have many more keywords sets and metadata presets – the latter also include keywords so I can target all sorts of IPTC fields in one hit.

Finding pictures isn’t just a job for keywords, so I focus on collections and particularly on smart collections. For example, I might have a Collection Set for weddings, which contains criteria for “keywords contains weddings” and “keywords contains candid”, and similar ones for finding other aspects of the wedding. My flat “candid” keyword therefore exists once in my catalogue and is not a child of “weddings”, so if I subsequently add “candid” to a bit of street photography, that picture won’t find itself grouped with weddings and I won’t find “candid” under two or more parents.

It’s worth saying I only build these collections for groupings when I actually have a specific need. Surely this must be a better use of time than building a hierarchical keyword structure simply because one believes or convinces oneself that one day it will help you find pictures?  Another point is I also build SCs rather than using the Filter Panel because I feel that I have needed to look up a particular combination of keywords and other metadata, there’s a fair chance I’ll want to look them up again. So I may as well save the query as an SC and save myself time in future, and I can group SCs with any dumb collections which might relate to the pictures.

Another aspect is that a catalogue is rarely keyworded perfectly. In my own catalogue for example, older pictures of the Castlerigg stone circle in the Lake District might just have a single keyword “Lake District” and other info in the caption or title, while more recent pictures of the same subject would have many more keywords. Let’s say I then have a need to find these pictures. Searching in keywords for “Castlerigg stone circle” doesn’t give me all the pictures, while “Lake District” gives me too many. Using a SC means I can look for “keywords contains Castlerigg stone circle” or “caption contains Castlerigg” or “title contains Castlerigg”. So a SC returns more accurate results in many real world situations.

Ben Long reviews Silver Efex Pro and correctly points out one of its best features

The Black and White adjustment in Photoshop is very good because it allows you to make changes to specific color values in your image. The problem is that if you tell it to darken the blue tones in an image, every blue tone will be altered. Silver Efex scores over Photoshop?s built-in Black and White [JB: or Lightroom or Aperture] because it can alter tone and contrast of specific areas, based on color, but constrain the alteration using an automatically created mask.

You could achieve the same effects in Photoshop using multiple Black and White adjustment layers, each configured differently and constrained using hand-built masks.

That’s what I do, and I don’t find it too troublesome.

At the moment Silver Efex Pro’s probably the best b&w conversion and grain utility around, though its film & grain recipes don’t take account of differences resulting from choice of developer or your agitation method (you can create your own recipes if you’re really anal). It also costs $199 – even as someone who does a lot of b&w, I don’t think it’s good value for money. And if I wanted to emulate film, I’ve still got my old film camera (as well as a brand new toy).

One of the Lightroom developers, Troy Gaul, has put online the slides from a presentation he did on Lightroom's architecture. It has odd nuggets of info - for me the mention of a possible IDE written in Lua was most interesting. So if you're writing scripts or web engines, there's the promise of a debugging environment that's a bit more sophisticated than Windows Notepad….

Via

I'm not really into navel-gazing descriptions of workflow, or into fashion photography, but here's a pointer to Patrick Lavoie's thorough description of Digital Photography Workflow: Fashion Photography:

As a professional photo retoucher and digi-tech (digital assistant), my job is fairly simple yet stressful during a photo shoot. My job is to make sure everything is under control, backed up, and retouched before delivery. I work with many different fashion photographers, and all of them during the day rely on my expertise to create a workflow that works for them and for me - a workflow that is easy, reliable, and effective so the photographer can quickly see anything he needs to approve over my shoulder. The following is my workflow, the one that work for me and my client.

He's French-Canadian, so one's got to excuse the appearance of Lightroom being described as its “apparition”…. I don't think that's a comment on the ghost folder issue though.