There’s an interesting and wide-ranging interview with Peter Krogh at The Week in Photography – including a LOL moment when Peter disinters my “DAM as serial monogamy” quip (thanks Peter!).

Last year PhaseOne finally acquired – “liberated” may be a better word -  Expression Media from Microsoft and gave it back its old name, MediaPro. I say “finally” because they had tried to add the original iView MediaPro cataloguing program to their CaptureOne raw conversion products back in 2006, and also because in those five years the post processing and cataloguing landscape has been transformed with the introduction of two major programs that combine those once-separate activities. To give an idea of how completely things have changed, I remember announcing Microsoft’s takeover to a trade show at Manchester United’s stadium, and since 2006 oil money has transformed City from a long-running joke into a pumped-up monster which might no longer need to call in Channel 4′s Time Team archaeologists to find any trophies (oh for the Arab spring to sweep away Abu Dhabi’s feudal rulers – that would be so City). Of course, some things stay the same and after Sunday’s demolition of Abramovitch’s expensive toy, United are on the verge of the 19th league title and another European Cup. But the change in how photographers now manage and process their pictures is “massive”, and first Apple’s Mac-limited Aperture and then the continuing and apparently-irresistible rise of Adobe’s Lightroom make me wonder if there’s any space left for the old favourite. Still, the €50 upgrade from Expression Media may not be an Hernandez-style bargain but is about the right price. At €160 new, MediaPro looks overpriced – more like an Edin Dzeko?

A lot of the work appears cosmetic – a modern, gloomy-grey interface – and almost all the familiar features remain untouched. But

• I spotted that the Virtual Earth geotagging feature has been dropped, very quietly, and while I imagine it was Microsoft’s code it’s still a shame to lose one of the few positive things that Redmond did with the program (apart from eventually selling it on). Instead of geotagging within the app, you now have a menu command Window > View Location on Map which displays the first selected image in a Google Maps browser window (it’s little better than a script I think I once wrote!).
• One very welcome improvement is the lifting of the 128,000 file and 2Gb catalogue size limits. This was probably top of my list – back in 2006 when I met with Microsoft.
• When you “sync” or save metadata back to the pictures, you can now write  it to sidecar files. Creating sidecars was one of many features that the iView guys had begun and making them work effectively should have been low hanging fruit for Microsoft. Removing the odd limitation to output sidecars to one folder at a time means it’s easier to exchange metadata with C1 and other programs that rely on sidecars (it was always possible with DNGs, of course!). Sadly though, you still have to invoke the sync operation manually, and it still overwrites any Adobe Camera Raw metadata.
• A second change isn’t mentioned, and I may be wrong in imagining it, but importing speed seems to be enormously improved. Almost instantly I could scroll through thousands of freshly-imported raw files – when you’re used to Lightroom, it’s quite remarkable.

If you’re unfamiliar with the program, take a look at series of tutorials by Peter Krogh who has also written some thoughts here. I’ll add other links as/if they appear, but already there’s Why Separate is Better Than Integrated, a curious defence from Capture Integration of the decision to keep P1 and MediaPro as separate programs (maybe they should call themselves Capture Separately?). Take the alleged problem attributed to Lightroom’s integration where:

“the photographer is tethered to a laptop for instant review of the images by an on-site Art Director. During the shoot cataloging features are completely useless”

Unfortunately this is not fundamentally a result of these two functions being incompatible in a single program but simply of it being Adobe’s first attempt at tethering, and not getting every detail right. Lightroom certainly could, probably should, have an option to switch tethering so it’s limited to the second screen, leaving the main screen to be used as normal. Another example of how it’s merely a design/implementation detail is how there isn’t yet the ability to add an overlay during tethering – a lot of tethered work requires shooting to a magazine cover or other layout (vote here). One could also see it as a result of Adobe’s failure to respond to small studios’ needs for Lightroom to have multi-user capability. So again, nothing to do with separate or integrated!

“take for instance the needs of a Wedding Photographer who is creating/updating his collection of his best marketing materials. In this case the ability to deeply refine/adjust the image is moot.”

Again, unfortunately not! Look at one very common way Aperture fans explain their preferences over Lightroom – they can be doing any task, such as creating a portfolio, and quickly make adjustments without needing to go into another of those nasty un-Maclike modules. Or think how often people demand Adobe merge the Library and Develop workspaces. The trouble is, a lot of photographers do have 5 second attention spans and no matter how much Lightroom’s modular design steers them in the direction of working methodically and efficiently, they don’t want to complete one task before moving onto another. “Creatives” do jump about.

I doubt we’ll ever get close to 2006/2007′s promise of “one ring to rule them all” where the whole photographic workflow would take place in one environment, but separating managing and post processing is like pulling apart the two supporting pillars of a modern, efficient workflow. If you do use CaptureOne, it makes sense.

As a final point, Aperture seems stuck in its niche and no longer the “Photoshop killer” that so spurred Adobe on, Lightroom increasingly appears to be growing organically and without the need for continuing major investment, and at the same time the excitement seems elsewhere – Adobe can’t take the risk of not putting enormous energy into creating solutions that either run on, or create content for iPads (other tablets exist). Now, more than any point in the past 5 years, I’d love there to be real competition to Lightroom.

CaptureTime to Exif is my latest Lightroom 3 plug-in. Essentially it’s an in-Lightroom interface for Exiftool:

1. Initially it was for Lightroom users whose catalogue contains scanned images and who wanted to make the scans’ Date Time Original EXIF field correspond to when the pictures were originally taken rather than when they were scanned. But people said they wanted to add the camera model, or the aperture details from their tatty old notebooks….
2. So the plug-in also lets you write other EXIF and IPTC information. One idea was to add extra boxes for specific fields, but I could never please everyone – not without a lot of work. I’m also hesitant to make writing EXIF so easy that it’ll attract people who should be kept away from it for their own good, and I reckon those who know about such stuff would appreciate a “bare back” style. So I’ve chosen to add a simple box for you to enter your own Exiftool arguments, whatever you want, at your own risk.
3. You can save complicated command line arguments as presets.
4. There’s a preview of the command line which can be copied to a batch file and tested in Shell/Terminal. Add the -k option and the Exiftool window will remain open, letting you track down any errors in the command line.
5. The plug-in will write directly to TIF, PSD, JPEG, and DNG file formats, but I have disabled the ability to write to proprietary raw formats.
6. If you really want to write to proprietary raw formats, the plug-in uses Lightroom’s log feature to generate a batch file which you can quickly edit and run in Shell/Terminal.
7. One little touch is the “incremental time stamp” which adds a second to each image in the batch – so later you can sort images by capture time even if the file names don’t help.

Capture Time to Exif will soon be on Photographers Toolbo. It’s important to begin by using Ctrl/CmdS to save any Lightroom metadata back to the files, and after running the plug-in Library > Read Metadata will update the catalogue.

Of course, if it all sounds like mumbo jumbo, then the plug-in won’t be for you and you can happily leave command lines well alone!

Take a look at two excellent articles by David Riecks – The Top 12 Myths about Embedded Photo Metadata and Why Embedded Photo Metadata Won’t Help Your SEO (at least without some help) :

There have been several recent articles, such as “The Definitive Guide to SEO for Images: 6 Steps to Image-Ranking Success” by Stephen Chapman, and “How To Add Embedded Meta Data To Your Images For Relevant Image Search” from NateBal, that recommend adding embedded information to the images on your website in order to enhance your SEO (Search Engine Optimization). While the idea certainly has merit, and I’m all for encouraging the practice of added embedded metadata to increase findability and protect intellectual property, there is one hitch to what they propose. That hitch is that while it is possible for automated search bots to be configured to read the embedded photo metadata embedded in digital images, there is no evidence to suggest that the search engines are currently doing this; nor is there any evidence that it will help with the SEO for your images or your website — at least not without some additional work.

That’s some hole in the SEO advice, don’t you think?

I know David tried pretty hard to make comments on those blogs. Maybe their moderators deemed his posts were too lengthy, or too densely-worded, but I’ve little doubt they were proper and polite ways of “calling BS”. And people wonder why SEO has a “negative stigma”?

It was no secret that it was on the way, but my friend Peter Krogh’s The DAM Book has now been listed on Amazon US and Amazon UK. The original book was immediately unusual in its cover not being emblazoned with “Photoshop CS2″ or focussing on the image processing side of the pixel mountain. Peter rightly saw that the management and safeguarding of digital photos was digital photography’s dangerously-neglected aspect, and this understanding of the real needs meant the book’s shelf life extended across software release cycles and remained applicable after entirely new programs were introduced. But even long-lasting underlying principles eventually need dusting off, and this new version of the book is a complete rewrite. Thanks Peter for asking me to tech edit a couple of chapters – I look forward to my signed copy!

And now for some of my own reflections… (or alternatively). When you look back at the the original book, it offered a solution containing four main strands – Bridge, iView, Photoshop, and DNG tying it all together and letting you see the adjusted raw data in any other program. I had already adopted the same sort of workflow before the original book came out, and my first contact with Peter was when he noticed something I’d posted about DNG in a forum. In fact, around the time he must have begun his book for O’Reilly, my UK publishers had turned down my similar book proposal as they thought their US partners – O’Reilly – simply wouldn’t be interested in the topic….

So I was already very much in agreement with his approach then, and it’s interesting to consider how things have changed over 4-5 years. For the better? Well, I’m not so sure. In Lightroom and Aperture we do have a pair of new and significant cataloguing programs which combine processing with DAM, but extensible XMP’s promise of portable metadata remains unfulfilled by them (Aperture can’t even read sidecar files) and the idea of a DAM program limited to camera-originated file types is now challenged – if it was ever valid – by our having three DSLRs that can output video too.

Have things changed for the worse then? No, not that either – the old four-legged solution still works fine, Bridge CS4 is a big leap forward (for example), Adobe have maintained parity and let you do the same adjustments either in Lightroom or the Camera Raw dialog (perhaps surprisingly when they could have introduced more product differentiation here), while iView’s still there in its Microsoft Expression Media guise and still shows your DNGs’ adjusted appearance. Bigger raw files keep piling up, Nikon and Canon still fail to offer DNG as an option, still offer in-camera settings that only make sense if you use their own raw converters and which you never have time to set when you’re busy snapping, and otherwise-excellent programs like Capture One still insist on new file formats (at least for now only their medium format back customers are being offered this delightful suppository).

But we will continue to cope – all this still hasn’t overwhelmed the fingers in the dyke of yet-bigger hard drives, multi processor cores, and all that the extra RAM – and we’re still successfully finding yet more comforting ways to slow computers down to our thinking speed. Maybe “different” is all we can ever expect, and success in DAM is still being there, still holding back the flood (the version on Fripp’s Exposure LP is even better).

It’s not specifically a Lightroom thing, and I say the same about Aperture and Expression Media 2. And I am a bit out on a limb here in holding these opinions. But I find hierarchical keywords to be an utter pain, and not worth the effort. No matter how much I try, I always end up with what should be child keywords also appearing again at the top level, for instance when I re-import a picture that’s been processed in another app. Or a child keyword will find itself duplicated in more than one hierarchy, usually because I’ve changed the hierarchy at some point and done Save As in Photoshop, or changed it on my laptop and then brought files over to the main PC.

The trouble is that I think we’re trying to make HKs do two things:

• boost keyword data entry
• speed up finding your pictures

So I’ve gone back to a flat keyword list, and switched effort from maintaining a hierarchy 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.

When you think about finding pictures, I don’t see a hierarchy as helpful enough to overcome the inconsistencies I described earlier, so I focus on smart collections. For example, I might have a Collection Set for weddings, which contains a two line SC for “keywords contains weddings” and “keywords contains candid”, and similar ones for other aspects of the wedding. My flat “candid” keyword therefore exists once in my catalogue and independently of the HK parent (in this case “weddings”) which first caused me to add it to the catalogue – if I subsequently add “candid” to a bit of street photography, that picture won’t find itself grouped with weddings and I won’t need “candid” under two HK parents.

It’s worth saying I only build these SCs for groupings when I do actually need them, but I find this a better use of time than building a hierarchical structure in mere expectation of needing the grouping. 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 your 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.

When you have a library of many thousands of pictures, querying or searching is clearly a very important feature. And you’ve got to be able to save those search criteria – after all, each time you narrow down your catalogue to find certain pictures, it’s a fair bet that you may want to find the same pictures again before too long. The more efficiently you find those pictures, the more time you’ll have for perfecting them. So two of the biggest and most welcome changes in Lightroom 2′s Library are the iTunes-style Filter panel (below), which replaces the old disc-thrashing Metadata Browser, and the introduction of Smart Collections.

Both the Filter panel and Smart Collections let you filter down the catalogue to find a selection of pictures, and each lets you save and recall the criteria you used to find them. What’s less clear is which you should use and when. The answer, well my answer, might be a bit controversial…. Use Filters when you don’t know what you’re doing, use Smart Collections when you do.

Having been lucky enough to have been using both for a few months, I’ve happily settled down to using Smart Collections almost all the time, and visit the Filter panel only for quick filtering by star rating, flag, coloured label, or master/virtual (though more often than not, I’ll apply these quick filters through the Filmstrip). I do use the Filter panel’s Text section, but just once in a blue moon, and use its iTunes Metadata section so rarely I really wouldn’t miss it.

• While the Filter panel menu does let you save a preset including your criteria, after you’ve added a few presets you soon have a long and unhelpful list. On the other hand, you can work easily with a large number of Smart Collections, group them in multi-level families, and mix them with Dumb Collections too. A filter doesn’t remember any output settings, while a Collection stores the last Print, Slideshow or Web settings applied to it. Smart Collections let you organize and add structure to your catalogue.
• The Filter panel’s iTunes-style columns hang around when they’re no longer wanted. I’m always going back to folders and wondering why some pictures seem to be missing – and then realize it’s because the folder has remembered some filter applied last time I visited it (which might be months ago). Clearing filters each time you change folder is about as practical as locking interior house doors every time you change room. It’s a lot easier not to use them.
• I find Filter panel’s iTunes-style columns of more interest when you’re exploring a catalogue, hacking your way into unknown territory and discovering the way it’s laid out. You don’t have a clear aim in mind, and your search criteria are changing as you discover how you previously tagged your pictures (like slicing and dicing with Excel pivot tables or Cognos). But the thing is, I don’t normally need to explore my catalogue – I know, pretty well, what I want to find.

So while the Filter panel is fine for temporary filtering, chopping and change what rating or flag values are visible, Smart Collections are much better for ongoing needs to manage a catalogue and it makes sense to invest time learning their nuances and then applying them as ingeniously as possible.

The Workflow Smart Collection

As an example, here’s how I now manage new work. My objective is to see at a glance what’s been done and what I’ve got to do next. For instance, I want to be confident every picture has my copyright and know that I’ve added descriptive metadata like keywords. Likewise I want to be sure I’ve adjusted all the pictures without eyeballing the badges on a few hundred thumbnails, and I want the catalogue to help point out pictures which need special attention. In other words, I want to introduce some quality control.

• The key is a single Dumb Collection, called “0.00 Current work” into which I drag the pictures I want to process (the 0.00 is there to assist sorting).
• I then have a series of Smart Collections which mostly check for images containing “Current work” in the Collection name, and then target specific criteria. So 1.30 No Captions checks that those pictures in “Current work” have something in the caption field – here it’s zero so I’m happy. On the other hand, 1.40 No Copyright shows me that for some reason I’ve overlooked two pictures in “Current work”. I can see straight away if there’s any missing metadata in my shoot.
• You can, to a certain extent, apply the same technique to Develop adjustments too. The caveat’s because, unlike Aperture 2, unfortunately Lightroom 2 doesn’t let you target individual adjustments so a Smart Collection can’t identify for you any ISO1000+ images where the Luminance and Color Noise settings are less than certain values. But what you can do is what I’ve done – identify high ISO images and remind yourself that you might want to treat those pictures as a group. Anyway I’m sure we’ll catch up, probably before most Aperture users realize they have the feature.

That’s how it works. In practice, it’s very simple – after a weekend away, I clear out any existing items from this Collection and drag in the newest pictures. The Smart Collections recalculate automatically and I always can see what’s done and what needs attention.

If “Current work” has existing items which still need work, I can move them to another Dumb Collection “Last week’s work” so that my Smart Collections don’t pick them up.

If you want to try this out, you can build up such a Smart Collection structure yourself. Alternatively, save yourself a load of time by saving it from here or from my Lightroom downloads section. This zip file contains a small “Workflow” catalogue which you can import into your own working catalogue. Use File > Import as Catalog, point to my Workflow.lrcat file, and import the single JPEG file (which you can delete afterwards). This should import the Smart Collections in their groupings. They obviously took me a bit of time to get right, so you can always say “thanks” or “grazie” or “yeah buddy that’s f***ing cool” via my Amazon wish list.

After my recent post on the Windows-limited Geosetter, I thought I’d take a look at the Mac-limited HoudahGeo which Richard mentioned in his comment on that post. I’d first heard about it in Lightroom designer Eric Scouten’s post Geocoding Your Photos with Lightroom and HoudahGeo. It’s certainly not as well-featured as Geosetter, and nor for all the hoo-haa on Houdah’s site about Mac design principles is it any more elegant – except for one interesting aspect:

What this screenshot shows is one of the ways you can select images for applying GPS coordinates. It’s a sort of File Open dialog box, but it’s the inclusion of Lightroom catalogues that really caught my eye.

Unlike iDVD or other Apple applications which apparently, almost magically, use the Mac operating system to display the contents of iPhoto or Aperture libraries, it looks like HoudahGeo gets the images’ locations directly from Lightroom’s SQL databases and then displays their embedded thumbnails. While it would be nice to see the Lightroom-adjusted previews (which Marc Rochkind’s LRViewer can do), that’s not a must-have requirement. It also makes you think too, that either iLife integration via the OS is a little more mechanical than they make it sound, or thoughtful designers can readily replicate it, regardless of operating system.

For a while I’ve been playing around with GPS and geotagging. Without a real need, I’ve been happy just nibbling at it from various directions but for some reason in Italy I seemed to find time to try a bit of everything.

I’ve a little Garmin GPS unit that connects directly to the camera. After the wedding in Positano, I had time to look around the Amalfi coast and found a lovely location called Fiordo di Furore. Unfortunately the “fiordo” in its name means it’s a deep cove that’s well-sheltered from passing satellites. My other main location was Paestum with its Greek temples. Being in the midst of a mosquito-infested swamp (you should see my legs) it was much easier to gain a GPS signal and all should have been perfect for recording the coordinates directly into the image. But – and probably because it’s a very basic unit – the signal kept dropping. I really couldn’t be bothered checking the little GPS indicator on the camera each time I wanted to take a shot, and after a while I just disconnected it. So as usual I was left with a mixture of a few geotagged and many more untagged images.

Sure, I know I could always leave the GPS unit on as I wander around (and carry extra batteries), or I could capture various waypoints or whatever they’re called. With something to connect the GPS to the computer, I could download the tracklog, and use something like ImageIngester to merge the log data into the NEFs or DNGs. I’m sure this process would work, but it seems more trouble than it’s worth. So last week I hacked a tracklog in TextEdit, using the data recorded on a few Paestum frames, and applied it with ImageIngester. That worked, but satisfied my curiosity rather too easily.

What else have I tried? Well, over the weekend I also wrote a script for Bridge but found Adobe protects the EXIF fields – sensibly enough. I could have modified it to post coordinates to existing IPTC fields, but I don’t really agree in principle with hijacking and abusing fields. Another alternative was to modify the script to write GPS data to my own private tags until such time as there’s an agreed place for manual GPS entries, when I could probably copy the data over. But for now only Bridge, Photoshop, and Extensis Portfolio would have been able to read those tags – not Lightroom, Aperture, iView etc. And any of these methods would mean entering the GPS data manually. That was also the downfall of making yet another doomed effort at understanding the very thorough documentation behind Exiftool.

This seems so typical of my efforts with geotagging. I don’t find it worthwhile enough to record GPS automatically, or at least consistently, but adding the information afterwards, which should work better for me, has also seemed too half baked (Expression Media 2′s dragging and dropping onto a Virtual Earth map, which seemed so promising, is more a developer’s ugly proof of concept than a polished feature fit for release) or too Heath Robinson like Exiftool. But it was after I got home yesterday when I was trying to make sense of Exiftool that I noticed a link to a program that a few people have recommended – Geosetter.

Whoo. It’s rather good:

• A Google Earth window helps you identify where pictures were taken, and a button then applies the GPS coordinates to the image screenshot here.
• A particularly well-done feature is that you can choose by individual file type how Geosetter writes the information, so for raw files you can choose to write into the image itself or into a sidecar file, as I prefer, while for DNG I chose to write the data directly into the file.
• The other feature I really liked was Geosetter’s ability to get the location information from Google and fill in the IPTC fields, and it’s possible to copy those fields into the keywords too.

That done, you can drag images into Lightroom to initiate its import process or use Library’s Metadata > Read Metadata from File to update existing images.

But I feel I’ve only scratched the surface of what looks like a really good program – and all the more reason to install Windows on my Mac laptop.

What you’re seeing here has been squeezed for this screenshot – you can resize the thumbnail grid (middle left), the preview image (bottom left), and the map. The two temples shown in the picture are visible in the satellite image, and I’ve been lazy by saving the details as a favourite (the star) which applies to images shot within 250 metres (the blue circle).

By the way, in case this post makes you think I my time in Italy was only photos and metadata…. Paestum has its trashy tourist shops, but at the southern end of the map is a dairy farm La Fattoria del Casaro. They make mozzarella from their own buffalo herd and do lunch using products grown on the farm. Not being a meat eater, I didn’t try the salamis but I did try their scamorza, smoked mozzarella, which they sear and serve with olive oil and basil. It was everything I love about Italy – I even got to thank the buffaloes in person.

The Library module is significantly improved in Lightroom v1.0, though it remains somewhat less coherent than Develop. The big change is the Folders panel replacing the old Shoots. While the name was clever, Shoots were a horrid confusion of virtual sets with physical folders that threatened to repeat one of Aperture 1.0′s worst mistakes, so the change is very welcome.

The new Folders panel lets you see where files are actually located in your folder system, files and folders where you want them without leaving Lightroom, rename or delete them, and run checks for files that Lightroom can no longer find because you’ve moved in Explorer (solution: once files are catalogued in Lightroom, only move them to new folders using Lightroom). Those capabilities are a big step forward from Shoots which let you move files only if they were stored in its managed folder tree but left you high and dry if you stored them where you wanted.

The panel isn’t perfect – you can’t yet right click a folder and simply tell Lightroom to import its contents (solution: re-import the folder and LR will reject anything that is already registered and import the rest), let alone set it to update automatically, or see its disc space usage.

One real silliness, a “gotcha” no less, is that Lightroom refuses to import two pictures which are in the same folder and have names that are identical but with different extensions. That may be OK if you shoot raw+jpeg and only want to import the raw file, but if you save psd, tif and jpeg derivatives in the same folder as your raw files, you’re going to have to change your bad habits (solution: if you must mix them, stick them in a subfolder).

DAM is about certainty and removing risk, and I’m always nervous of entrusting control of my pictures to any v1.0 product. Since iView works perfectly well in conjunction with Lightroom, there’s a fair chance that I won’t use the Folders panel much at all until any potential problems have been ironed out. Nevertheless it is very important progress in a design area where there had been real potential for disaster.

Welcome though the Folders panel is, DAM is also about not falling into the trap of using folders to analyse your files. That’s what metadata is there for – you have keywords and other metadata, plus the Metadata Browser panel. And you need to start making extensive use of Collections… the subject of my next post.

As a frequent contributor to web forums on “digital asset management” software (cataloguing programs like Portfolio, iView and iMatch), you soon distinguish fellow travellers who’ve also thought a bit more deeply about the issues. One of those is Peter Krogh who dropped me a nice email yesterday.

Peter’s a Maryland-based advertising photographer and O’Reilly is just about to publish his The DAM Book: The Digital Asset Management for Photographers:

brings clarity to the often overwhelming task of managing digital photographs, with a solid plan and practical advice for fellow photographers on how to file, find, protect and re-use photographs.

Following a thorough overview of the DAM system and de-mystifications of metadata and digital archiving, Krogh focuses on best practices for digital photographers using Adobe Photoshop CS2. He explains how to use Adobe Bridge along with Camera Raw, the DNG file format and DAM software. He shows you how to cut down your image processing time, while simultaneously preparing images for a long-term archive.

18 months ago I suggested such a book to my publishers. Maybe I should have been more persuasive….
Q: How many writers does it take to change a bookstore’s lightbulb?
A: One to change it, but a line at the cash register saying “I should have done that”.