Never fear, there is finally a solution. Well, the beginning of a solution. A solution in the early stages of beta testing, but a solution nonetheless, and it doesn’t involve uninstalling Lightroom and eating more cheesecake. Although you are welcome to eat more cheesecake anyway if that’s your thing.

No, friends, what I’m talking about is Knobroom. What is Knobroom? Knobroom is a plug-in for Lightroom written by Jarno Heikkinen. Now hold on, I know what you’re going to ask: “What is that picture to the right?” It’s a good question. That is a Behringer B-Control Rotary BCR2000 32-channel MIDI encoder panel.

Oh, you want to know what Knobroom does! You haven’t guessed yet? Knobroom connects the sliders in Lightroom to MIDI control channels. MIDI stands for Musical Instrument Digital Interface and is essentially the standard by which electronic instruments communicate with one another (and with computers). The Behringer shown on the right is just one example of a MIDI control panel that would commonly be used to control volume, pan, vibrato, loudness, and other such attributes in music software.

Of course, it’s just a USB device that communicates through the well-documented MIDI protocol, so Jarno wrote a plug-in that takes that information and allows you to say “when knob 1 is turned, change the exposure slider.” This allows you to move settings up and down with the knobs without having to move the mouse or even have the appropriate panels in the develop module open.

How cool is that?!

I’m seriously considering the purchase of a Behringer BCR2000 as that is the model Max Edin used in his demonstration video, which sort of proves that it works. There are some issues and the software is in a beta stage of development so you have to expect some bumps in the road, but it looks very promising.

Read more on Max Edin’s blog: Using Hardware Controllers with Lightroom. Check out the Knobroom home page for more of the gritty details.

Well, that’s coming to an end.

What you’re about to read is a totally inclusive, top-to-bottom, front-to-back workflow for organizing, sorting, and managing your digital photos using Adobe Photoshop Lightroom. Similar techniques will, I’m sure, apply to Apple Aperture, though all keyboard shortcuts and terminology will be Lightroom-specific.

For the record, I use Lightroom on a Mac and chose it because of Adobe’s openness to beta testing and feedback from the photography community, which I believe has made Lightroom the best tool for the job. Let’s get to it.

Organizing Files on Disk

First, why? Why organize your files on disk when Lightroom is such an apt cataloging tool? Why add another layer of complexity to your photo import workflow when Lightroom can just “take care of it,” assuring you that each RAW file is placed in a location appropriate to its metadata?

Because that’s totally wrong, that’s why. Lightroom is an amazing cataloging and organizational tool, but what if you couldn’t use it? What if your catalog, and its backup, and the backup’s backup, got destroyed? Or what if your operating system was in some state of utter bedlam, preventing you from opening Lightroom at all? Or what if you brought your external drive full of photos with you on a trip and found out that Lightroom on your laptop wouldn’t work?

Applying at least some moderate level of organization to your physical RAW files will make finding them that much easier if you ever have to do so without the aid of Lightroom. Surely not an eventuality we all hope for, but one that we should nonetheless plan for.

My Method

There are an infinite number of ways to organize your RAW files on disk, but I don’t have an infinite amount of time (and neither do you) so I will only tell you how I do it.

1. My top-level folder is called “Photography,” then
2. Within that folder there are three folders for the main categories of my work, “Events,” “Places,” and “Portraits.”
   1. Events contains folders named for each event and those folders contain the photos.
   2. Portraits contains folders usually of models’ names, and those folders contain photos. If I have done more than one shoot with a model, there are folders by date for those.
   3. Places, however, contains a geographical hierarchy like “United States,” then “California,” then “Death Valley NP,” and
      1. As with portraits, if I’ve been to a location more than once, there are folders by date.

I know that list might be a little bit complicated to absorb, so go ahead and re-read it if you want to. The basic idea is to have your major categories represented as folders on your hard drive such that you can locate, at the very least, the group of photos you’re looking for in the event you can’t use your catalog for it.

Enlisting Lightroom’s Help

You can get Lightroom to help you build this structure. Let me tell you what I would do if I were importing photos from a location shoot that I did in a place I had never photographed before.

1. Open the import dialog and choose the photos I want to import from the thumbnail view.
2. Choose “Copy Photos To A New Location And Add To Catalog.”
3. Browse for the correct geographical folder. I usually use the browse dialog to create the folders I need along the way. For example, I might browse into “Places,” then “United States,” and then I may have to create a folder for “Massachusetts,” and then another within that for “Boston.” There is a “Make New Folder” or “Make Folder” button in the dialog (in Windows and OS X, respectively).
4. In the future, if I already have the state folder created, I may simply select that and check off the box next to “Put in subfolder” and type the city or location name in there. That’s completely up to you.
5. If you want to organize the photos by date within the folder you’ve selected (and this precludes using the “subfolder” option above), select “Organize: By Date” and Lightroom will create a subfolder for each date in your import (by the photo’s created date).

A quick side-note: this is the time to select your metadata preset and choose some basic keywords to apply to all the photos you’re importing. This article isn’t really about keywording, but that won’t stop me from giving you orders: keyword your photos. That is all.

Awesome! Now all of your RAW files are organized in a coherent way on your hard drive. But you still have thousands of new photos that you just imported and unless you’re Ansel Adams they’re not all keepers. Actually, even if you were Ansel Adams, they still wouldn’t all be keepers. So what you need to is treat your catalog like an emergency room.

Treat Your Catalog Like an Emergency Room

What I’m talking about is triage.

tri • age n.

1. The determination of priorities for action in an emergency.
2. Sweeping through your photos and separating the good from the bad.

Obviously the second definition is not exactly Miriam Webster material, but… I reserve the right to exercise my creative liberty.

Anyway, the idea is to prioritize photos by their quality so you can spend more time sorting through the really good ones and less time staring at the really bad ones. Doctors do this in emergency situations to make sure that patients who most need care get it first, to maximize the survival rate. For a doctor, determining priority among patients can be a real challenge, and prioritizing your photos can be tricky, too.

Luckily, Lightroom gives us some very helpful tools that come to our aid in this situation. You probably already know of them. They are:

1. Flags (picks and rejects)
2. Ratings (on a scale from one star to five)
3. Labels (colors)

Any given photo can have a flag (picked or rejected), a rating (one through five stars), and a color label, although all three attributes are optional. By default, a photo has no flag, no rating, and no color label.

With two possible flags, five possible ratings, and five possible color labels, that’s a whopping 50 potential categorizations a photo could fall into (if you use all three attributes)! So how can you best put these attributes to use to streamline your workflow?

I don’t know. But I can tell you how I use them.

My Method

The very high-level outline of my process goes something like this:

1. Eliminate rejects (using the reject flag, “X” on the keyboard)
2. Mark potential keepers (using the pick flag, “P” on the keyboard)
3. Light, experimental development to test the viability of the keepers
4. Un-flag bad picks (if development doesn’t work out; that’s “U” on the keyboard)
5. Complete development
   1. Label completed images ready to go to the gallery in green (green for gallery, get it?)
   2. Label experimental or fun images that will go to Flickr in blue (no mnemonic device for that one, I have a Post-It note on my monitor to remind me)

I then I use either the Export to Photoshelter or Jeffrey’s Export to Flickr plugins within Lightroom to send the images where they need to go.

You may notice that I don’t use star ratings at all. I used to use star ratings to differentiate between images to throw away, edit, or which had been completed, but since the advent of flagging and color labels I find that star ratings provide more specificity than I need. There are only rare occasions when I have a few photos that are very similar where I might use star ratings to indicate which ones I like more, just so I can remember later when I come back to them, but that isn’t part of my everyday workflow.

You’re Done!

You have absorbed my entire workflow and read all of my suggestions for using Lightroom’s sorting and cataloging tools. I hope that this helps you to keep your images in order!

That is the question.

Whether ‘tis nobler in the mind to wrangle the proprietary formats of your camera manufacturer, or to take arms against a sea of sidecar files, and by opposing, end them…

But enough pseudo-Shakespeare for one post.

There has been some chatter on the Interwebs lately concerning the DNG format: there are quality and archival concerns, whether it’s worth converting one’s entire library to the format, what the benefits might be, and whether one ought to care. Today, I weigh in. For what it’s worth.

Coincidentally, I’ve used the same post title as Matt Kloskowski did in his take on the subject on Lightroom Killer Tips. Matt didn’t add a pseudo-Hamlet line, though, so I feel like I’ve done the headline proud.

After the break, a complete rundown on DNG; trust me, it’s going to be technical and editorial.

What Is DNG?

Skip this section if you already know what DNG is, or read it if you want to know what I think DNG is.

DNG is the “Digital Negative” format, spearheaded by Adobe. It is an “open” format, and a “standard” in some sense, though not an official ISO standard (yet). When we say that the format is “open,” we mean that the precise contents of a DNG file, its byte offsets, containers, methods of generating and reading the files, and so forth, are publicly available. This is not the case with any other RAW file format out there. The ability to read and write manufacturers’ RAW files (e.g. Canon, Nikon, et al.) is either licensed from the manufacturer or reverse-engineered.

Adobe created the standard out of, apparently, a desire to “universalize” (if you will) the ubiquitous RAW file formats that all manufacturers have created for themselves, and to introduce a truly interoperable format that any software or hardware maker could employ without 1) wrangling many different formats at once, or 2) singling out particular users of particular products¹.

The DNG format is based on many existing standards owned by prestigious “standards development organizations” (or SDOs), some of which you’ve probably heard of; they go by the names TIFF, JPEG, XMP, IPTC, ICC, CIE, and ZIP, to name a few. So, although the DNG format itself hasn’t been embraced by an SDO such as the International Standards Organization (ISO), it comprises previously standardized formats and is only a snippet of red tape away from being SDO-backed.

You can read a lot of nitty gritty on the format itself explained by Barry Pearson on his DNG Specification page.

Why Would You Want to Use DNG?

There are three main reasons that are generally cited:

• Archivability (future-proof-ness, if you want)
• Interoperability (openness, we like to say)
• Efficiency (YMMV, more on this later)

Archivability (which I’m pretty sure isn’t even a word) means that fifty years from now, when Canon owns the world and Nikon is completely extinct (har har), flying cars are a reality, and everyone has an army of robotic servants, your DNG files will still be supportable by manufacturers of hardware and software alike, because no secrets about it have been kept from the public.

“[I]f Nikon decides to not support my raw files one day, there’s some 15 year old in his room that’ll code up a raw conversion program in his sleep.”
—Matt Kloskowski

Does this claim hold water? I don’t know, you can download free software right now that can read the Photoshop version 3.0 format, which is already decades old, so it seems to me that if the ability to parse a format is out there (even if it was obtained semi-legally or with much effort by third-parties), it will be difficult to lose it. Moreover, a format such as Canon DNG or Nikon NEF will likely remain supported by anyone you care about, or, as Matt Kloskowski put it, “…there’s some 15 year old in his room that’ll code up a raw conversion program in his sleep.” So I am not worried about losing access to my RAW image data.

Interoperability means the ability for you to take the same file and use it in many different places. Of course whether this is an advantage to you or not depends on the places where you want to be able to use your RAW files. For me, Lightroom is the only program on my entire computer that ever sees a RAW file. I suppose if I round-trip through Photoshop, Lightroom is going to pass the CR2 through Camera Raw, but we’re talking about two closely-integrated Adobe applications there; whatever formats one supports, the other is sure to. Photomatix is going to see TIFFs, on the web you’ll see JPEGs, etc.

So why does interoperability matter? Adobe’s point in creating DNG is that it may matter in the future. If Great New Software X decides they can’t support your camera’s RAW format, and if you’ve converted it to DNG already, well, problem solved. Because Great New Software X will certainly support DNG given that the format is completely open and drop-dead simple (not to mention free) to implement, you have a much better chance of being able to drop your existing DNG images into any new, shiny tool.

“I actually tried ZIP compression in prototype versions of DNG, but the compression ratio was much better using lossless JPEG.”—Thomas Knoll

Okay, what about efficiency? This is where things get kind of cool. The Adobe DNG format stores the actual pixel image data in what is called Huffmann lossless JPEG format. What that means is that DNG files can sometimes be as much as 20% more efficient at storing image data on disk than a comparable RAW format, thus DNG files may be as much as 20% smaller. Lossless JPEG is completely pristine; there is no image-altering compression done, so the data is totally preserved, albeit compacted. The Huffmann algorithm for this compression happens to be more efficient than ZIP when there are more than 8 bits of data per channel (RAW is 12 or 16), so the Huffmann algorithm was used.

But here comes the kicker… Canon’s RAW (CR2) format already uses Huffmann lossless JPEG for its internal image data storage. So if you shoot Canon RAW, you will see no increase in data compression, since the data is stored in exactly the same way already. If you shoot in Nikon RAW (NEF), you will immediately see a 20% decrease in file size and no change in image quality.

For non-Canon shooters, that’s probably the most compelling reason to convert to DNG right now, which I should point out Lightroom can do automatically for you at import time. You’ve seen the option, right? There are a couple of ways to convert to DNG in Lightroom, and there are three of them explained on TheLightroomLab.com.

Sidecars Aren’t Just for Kids

No, seriously, most motorcycle sidecars could definitely seat an adult…

Joking aside, what we’re talking about are metadata “sidecar” files, typically named something like IMG_0195.xmp and so-called because they are saved alongside your original RAW image files, like the sidecar on a motorcycle. Sidecar files have been around since the invention of metadata and metadata libraries. The XMP format for storing image metadata in a sidecar file was developed by (guess who…) Adobe. XMP is necessary because the metadata support within RAW file formats and other imaging formats may comprise only a subset of what, for example, Lightroom is able to save and search.

Certain formats such as PSD, TIFF, and JPEG have pretty flexible metadata support in them already. DNG is no different. The “sidecar bonus” of the DNG format is that when you’re using DNG, you don’t need sidecars.

But who does, anyway? The fact is, Lightroom stores all of your image metadata in its own catalog. This is done 1) to make it quickly searchable and editable, and 2) to centralize it. If you want to write metadata to disk for certain files (or the whole catalog), then Lightroom will decide, based on the source format of each image, whether to save it directly into the file or to create an XMP sidecar file.

The purpose of XMP is to give your image metadata a place to live when the image file itself can’t accommodate it. So why would you need this ability? Two reasons. (Assuming your RAW files are in NEF, CR2, or similar; non-DNG).

1. If you share images with other people who use Lightroom and you want them to be able to see what you have done in the Develop module, as well as the IPTC tags, you will need to send them XMP sidecar files. This is preferable to sending your entire Lightroom catalog or creating a new one to house only the images you are sending.
2. In the event of a catastrophic disaster where your Lightroom catalog backups are corrupted, you can restore 95% of your data using the source RAW image files and associated XMP sidecar files. What you would lose is virtual copies, your history, and any collections. All edits and other settings are stored in the XMP files.

There are some major caveats here, though.

1. When you’re sharing images, you can always export them to DNG, which makes XMP unnecessary.
2. In the event of a catastrophic disaster, you’ll only have XMP files if you’ve previously selected batches of images within Lightroom and triggered the “Export Metadata to Files” function. Presumably you would carry out this procedure on images you have finished editing as part of your backup strategy. For the record, I do not do this.

Conclusions

So where does this leave us as far as DNG goes? Should we all run back to our computers right now and convert our whole libraries to DNG format? Once again, here are the major advertised benefits of the DNG format:

1. Archival (future-proof)
2. Interoperable (widely compatible)
3. Efficient (storage-wise, at least)
4. All-inclusive (obsoletes XMP sidecars)

It seems to me that the “archival” and “interoperable” characteristics of the format are bonuses, and as a supporter of free and open standards, I tip my hat to Adobe simply on principle. These characteristics don’t, however, increase the immediate convenience or reliability of my workflow, nor do I think the archival nature of the DNG format will have a measurable impact on my workflow in the coming years.

Since I am a Canon shooter, my Canon RAW (CR2) files already compress image data using the same Huffmann lossless JPEG system that DNG does, so I get no benefit there. If you use Nikon, et al., you may see an immediate storage benefit from converting your library to DNG.

Perhaps the most compelling reason to convert your library to DNG, or to start using DNG for your imports going forward, is the fact that DNG files are capable of storing all Lightroom-specific metadata directly within themselves, without the use of XMP sidecar files. If you are diligent in writing metadata to the files when you are through editing them, those files then fully encapsulate all the work that you’ve done, in one place, suitable for backup.

Even in the event that you lost your Lightroom catalog, you could still restore the final, edited versions of the images (which is where all of your hard work goes, after all), as well as tags and other helpful metadata. The only things you’d lose are virtual copies, history (of limited long-term utility, anyway), and collections (which can be rebuilt without nearly as much work as re-developing all your images).

To DNG or not to DNG? I think I will.

1. Like yours, for example.

Adobe has finally released the first upgrade package for Photoshop Lightroom, which brings us to version 1.1. I say “finally” because this upgrade introduces at least one feature that we hoped against hope would be in the first release, the ability to merge libraries, among other enhancements.

First, if you have Lightroom and it hasn’t already popped up and told you to download the upgrade, you should seriously click over there and do that.

When I went out to Yosemite National Park and Santa Cruz, I brought my laptop with Lightroom on it. Because my home Lightroom library (now called a catalog in v1.1 and also in the rest of this post) is tied to photos saved in certain places on my home network and also because it’s gigantic, I started a fresh new catalog on my laptop. It was great to be able to use Lightroom to import the RAW files, do some work on them, see which ones were going to work out, even edit a few to completion while on the road.

However, upon returning home, I had two Lightroom catalogs. Lightroom has always supported switching between catalogs, which is nice, but never merging them. That feature was supposed to have been in the 1.0 release, but the developers decided it wasn’t up to snuff, so they nixed it until it was more fleshed out. I was very excited to see the new options available in version 1.1 for importing photos from one catalog into another, satisfying my every desire. Last night I imported all of my Yosemite and Santa Cruz photos into my primary catalog, which took a good ten minutes to process on my older G4, but I now have a nice, solid, unified catalog.

As a workflow tool, it’s excellent to be able to create a new catalog on, say, your laptop, take it where you’re going, do what you need to do, and then be able to merge that into your home catalog when you return. Did I mention that the “import from another catalog” feature imports only the photos you select and puts them where you want them (or leaves them where they are), just like importing from anywhere else? They thought of everything.

There are a variety of other new features, including a really slick “spray can” tool (replacing the rubber stamp) within the Library module that allows you to “spray” photos with keywords, ratings, flags, labels, develop presets, metadata presets, or rotations. As soon as I saw it I actually giggled a little bit. Out loud. I’m a huge nerd.

To see what else is new and review known issues, read the Lightroom 1.1 release notes (pdf).

It’s never as simple as it sounds.

What Is Bit Depth?

If you already know what bit depth is all about, you can skip this section. Without getting into too much technical detail, bit depth describes how many colors (or shades of gray) an image is capable of storing (for the sake of simplicity, I will be discussing grayscale images in this article). Eight bits of color depth means that an eight-digit binary number is available to store the value of each pixel in the image¹. With eight digits in binary you can count up to 255. Including zero, that gives you 256 available shades of gray for each pixel in an 8-bit grayscale image. Zero is black and 255 is white. Making sense?

As you might predict, a 16-bit image gives you a 16-digit binary number to store your pixel information. With a 16-digit binary number, you can count up to 65,535! Including zero, that gives you 65,536 shades of gray to work with. Clearly there are immediate theoretical advantages to using 16 bits of color depth in photography.

The Case for More Depth

If all cameras captured images with eight bits of depth, there would be no debate; converting from an 8-bit image to a 16-bit image doesn’t do much for you, as I’ve casually proven in a few tests (which I won’t bore you with). However, cameras that capture in RAW format (which includes basically all DSLR cameras today), capture about 12 bits per pixel of data².

The savvy among you will already have thought, But 99% of printers today can only output eight bits, so who cares! You are correct.

But you’re also wrong.

The trick to this bit depth discussion is that you don’t need the extra bits to print your image. In fact, if you took pristine photos in 8-bit JPEG and printed them without ever touching a pixel, you’d be fine; you’d lose nothing. But I suspect most of you are photographers and you know that post-processing is increasingly important, if not necessary. It is for the editing that you need more bits. Let me explain why.

The Bit Crusher (aka Photoshop)

When I was discussing histograms, I mentioned in passing that making changes using e.g. levels or curves causes Photoshop (or the editor of your choice) to expand or compress the range of tones in the image, redistributing their values.

That sounds a lot more complicated than it is, which is why I like to use illustrations. Below, you will see a very subtle gradient that proceeds from a gray value of 90 on the left to 160 on the right. As you should be able to tell, there is no pure black and no pure white in this image.

In the 8-bit space, if I use levels to expand the tonal range of the image, you will see that a lot of dithering and banding occurs. What Photoshop is doing, very simply, is making the gradient start at a pixel value of zero and end at a pixel value of 255. The values of the intermediate pixels are then redistributed.

If you look closely at the image below you will see that the results aren’t too great, and it’s because there are a limited number of gray tones to choose from when averaging out the intermediate pixel values.

Here is the center area of the above image scaled by 300% so you can see exactly what’s going on.

So what happens if you have 16 bits? To find out, I created a 16-bit image exactly the same size as the ones above, drew an identical gradient, and performed the same levels adjustment (numerically, to be sure it was done precisely the same way). Because Photoshop has 256 times more gray values to choose from when redistributing the intermediate pixels, the gradient still looks pretty nice. In order to show you the result, I had to save it as an 8-bit JPEG, but as you can see below, converting to eight bits after doing the edit produces a noticeably better result.

Again, here is the middle section of the above image scaled to 300%.

I have racked my brain for a couple of days trying to come up with a lucid explanation for why editing in 16 bits and converting to eight produces a better result than editing in eight bits directly, but I’m no mathematician and regardless of the mechanics behind it, this workflow obviously delivers.

Putting 16 Bits to Good Use

$random:right$

I spent a good deal of time putting this article together and building these examples, and I think I’ve proven almost without a shadow of a doubt that editing in a 16-bit space is noticeably beneficial. So you would probably think that I have a hard drive full of 16-bit Photoshop files, but you’d be wrong.

As I hope I have demonstrated in the examples above, 8-bit files are most vulnerable to what I call “broad tonal changes,” which describes levels, curves, or any adjustment that expands or compresses your tonal range. These are the types of edits that would cause your 8-bit histogram to be divided into many separate lines, as I showed in my histograms article. For that reason, those types of edits should be performed in the largest bit depth possible within your workflow to prevent banding and aliasing.

I like to make my broad tonal changes with the Develop module within Lightroom while the file is still a native 12-bit RAW. Once the histogram is compressed or expanded to my satisfaction, I will drop it into an 8-bit PSD for local edits if I have to, and save it that way. If, somewhere down the line, 16-bit printing becomes the norm, I can always re-process those files as 16-bit PSDs and print them. Somehow, though, I think I’ll be on to bigger and better things by then. One can hope, at least, right?

$random:left$

The 8-bit versus 16-bit debate is one steeped in personal preference, and somehow has mutated into a rather divisive topic. I hope I’ve shown that no matter what your workflow preferences may be, you can benefit from the flexibility of 16-bit editing without filling your hard drives or waiting for your computer to crunch huge files.

I’d love to hear about your personal workflow preferences, too. Just leave a comment or drop me an e-mail!

1. In a color image, eight bits are used to store each of the red, green, and blue values for each pixel, which is why you sometimes see images referred to as “24-bit.” An 8-bit color image and a 24-bit color image are the same thing.
2. That means 12 bits each for red, green, and blue per pixel, roughly, but the specifics of different sensors and the exact math is not important for this discussion.

You have a bunch of pretty photos; shouldn’t they have pretty names?

I always name my photographs. Even if the names are sometimes trite or clichéd, I think that any photo that has worked its way into the gallery deserves a name. When I put photos into my gallery, I like to name the files themselves with the name of the photograph so that the URLs are pretty. It makes more sense to see a URL like /Places/Chicago/MillenniumPark.jpg.html than something ugly like /plc/chg-il/chg-mp-01.jpg, don’t you think?

One thing I hate is to do things more than once. Isn’t that why we have computers? “So,” I thought to myself, “if I’m going to enter the names of the photos into the Title field of their metadata anyway,” which I do, “shouldn’t I be able to read that out somehow and name the file with it?” Yes, yes I can. This is because I am a nerd. It is this power that I will give you today. Nerd power.

Getting the Programs

First, you’re going to need a working installation of MacPorts. In my previous article I explained how to get that working, so go over that part again if you need to. I will assume you have it installed, even if you didn’t install the ports I talked about last time.

Now install a program called exiv2, which is a terminal utility for reading Exif and other data out of (primarily) JPEG files. Installing it should be as easy as opening up your terminal program of choice and typing:

Remember, you’re only typing the part after the dollar sign. You will probably be prompted for your password and then it’ll run off and download things and install them for you. Once it’s done, make sure it worked by running the program:

It should look more or less like that. If you get a -bash: exiv2: command not found error, that’s not good, so you should look back at what MacPorts told you during the installation to find out what went wrong. Now that you have exiv2 installed, you can use it to read information out of files. Here is what the basic output of exiv2 looks like if you don’t specify any extra options:

But wait, there’s no image name in there, only the filename! By default, exiv2 only prints out the Exif data, not any of the IPTC data, which is where things like the image’s creator, URL, title, etc., are stored. We can tell exiv2 to print out IPTC data by using the -pi switch. By the way, you can find out what else it can do by asking it for help with exiv2 --help.

Shelling out the Name!

You can see that this JPEG has been given a title (in the IPTC spec. they call it ObjectName), a couple of keywords, a byline (the creator’s name, usually), and a copyright notice. What we want is just the value of ObjectName. We can get this with a piece of shell scripting like so:

I’m not going to explain how this works; the fun of bash is looking up each command and figuring out how it all comes together. If you want to figure it out, I’m confident that you will. If not, that’s okay, you can still use it! Suffice it to say, that line should output only the title of the image, or nothing if there isn’t one. We need to save that into a little script so that it can be given a filename to work on and so it can check to make sure everything works the way it’s supposed to. To that end, here is the script:

Note: You may have to change the path to exiv2 in the part that starts EXIV= if MacPorts installed it in a different place than where it is on my system. In all likelihood it’s in the same place, but you can check by running which exiv2. Use the path printed by that command in your script.

This script takes the filename of your photograph as an argument and renames the file with that name. It also removes any non-alphanumeric characters from the title to make sure the filename will be valid. If you wanted to change spaces into hyphens instead of removing them or something else along those lines, you’d want to examine and alter the tr portion of the long command at the beginning.

Save that script into a file and make sure it’s executable by running chmod u+x yourscriptname, and you’re done!

Making a Droplet

Well, almost. Wouldn’t it be handy to be able to drag and drop a bunch of photos onto an icon and have this thing rename them all at once? You bet it would. We can easily make an AppleScript droplet that will do that, just like I showed you in the previous chapter! Here’s the code:

Hit Save As and make sure to select “application” as the type and also make sure that the “Startup Screen” option is unchecked. You really don’t want that one.

If all has gone according to plan, you should be able to drag photos onto the droplet and they should be renamed for you! Of course, they must have title information in the IPTC header; Lightroom calls the field Title and will export that data with your images automatically.

If you felt the urge, you could integrate these AppleScript commands into the post-processing script for Lightroom that I showed you how to set up in the previous chapter. I will leave that as a challenge for the adventurous reader.

Until next time, fellow photo-nerds.

In this series of articles, I will discuss the down and dirty mechanics of how I’ve automated a good deal of my workflow. I’ll probably continue to add chapters to this series as I figure out new methods, but hopefully you can start saving time right off the bat with some of these tips!

Today’s topic is exporting and watermarking.

For starters, I’m using a Mac and I’m using Adobe Lightroom 1.0. If you use different software or a different platform, a lot of this probably won’t work for you. If you manage to port some of my automation processes to a different platform or software package, please share with me!

What we’re going to do together right now is build an AppleScript application that acts as a droplet, which allows you to (as you might expect) drop image files onto it to watermark them. This droplet takes all of the overhead of Photoshop and the monotony of manual labor out of the watermarking process, which I think you will come to love as much as I do.

As a bonus, we can set up Adobe Lightroom to use this droplet as a post-processing filter (and I’ll show you how!), so the activity of applying a custom watermark to your images becomes tightly integrated into the activity of exporting from Lightroom. If you don’t have Lightroom, or don’t even like Lightroom, you can still use the AppleScript droplet to watermark a bunch of photos at once.

The first step is…

Building the Watermark

The first step in automating the watermark process is to have a watermark graphic you want to use. You will need a standalone graphic file that will work in any photo scenario. In other words, if your watermark uses transparency and the text is white, you probably won’t be able to read it if it’s applied to a very light photo.

For my watermark, I have gone with a very small and very controlled image, which I’ve named simply copyright.gif:

The only technical considerations when composing a watermark image are:

• It should be narrower than the smallest for-web image you will export, so that it isn’t cut off. I always export my images for this blog at 600 pixels wide, so I’m safe with this watermark (which is 310 pixels wide).
• It should be legible on any image, regardless of the image’s lightness or darkness. To solve this problem, I’ve used a black background. I experimented with different approaches and found this one to be the most reliable, even if not always the most attractive.

Now that we have a workable watermark image, it’s time to…

Install ImageMagick

ImageMagick is a command-line image manipulation suite originally developed in the Linux community. It’s free, powerful, and could serve you in more ways than watermarking, so let’s get this thing installed! The easiest way to install ImageMagick is through the package management system called MacPorts (formerly known as DarwinPorts).

Pop over to MacPorts and download the latest version. You install MacPorts in the same way you’d install any other Mac application: open the .dmg file, run the installer, wait a while, and there you have it. Now that MacPorts is installed, it’s time to delve into darker territories: the terminal. If you are unfamiliar with the terminal, don’t be too intimidated; I’ll show you exactly what to type.

Open up the terminal (the default Terminal application or your choice of replacement terminal) and make sure MacPorts is working properly:

Note that your prompt will look different than mine; the only part you need to type is port. Press return and, if everything has gone according to plan, you should see the default output of the port program:

Installing ImageMagick should be as simple as:

The sudo command allows you to run a program as the superuser, which is required in order to install things into locations within the OS X system folders (much the same as entering your password when running certain installer packages). You will be prompted for your password; enter it and press return. It will take some time to download the required files, decompress them, etc., etc. When it’s done, it will let you know. If you get any errors along the way, you will want to refer to the MacPorts website or search on the Internet for solutions; fixing MacPorts problems is too vast an area to cover in this article.

You can now confirm that ImageMagick is installed by trying to run one of its included tools, convert. Just type that in and see what happens:

A whole bunch of stuff should print out. Don’t worry about reading it. If you get an error message like -bash: convert: command not found then try closing and re-opening the terminal. If it doesn’t work after that, well, something must have gone wrong with the installation and you should try to figure out what that is. There are a lot of resources available through the MacPorts site and through The Google to help you out.

Now that we have ImageMagic set up, we need to write some…

AppleScript

I love AppleScript. What we’re going to do now is write a small script (or “droplet”) that opens images and places your watermark image on them. Here is the code:

Beware. I have broken up a couple of the lines to make it appear properly on the blog. The linebreak character, which should look like the upper right corner of a square, might not appear properly in your browser.

If you want, you can just download the script from my site. You should be able to open this file in Script Editor and change the paths to suit your environment (mostly change the path to your watermark file), and in fact, you must change this path or the script will not work. In the above code, /Users/airborne/Pictures/copyright.gif is the part you need to change.

I will now explain the code in greater detail for anyone interested. If you couldn’t care less how it works, skip the next couple of paragraphs. The first part, on open theObjects means that this script expects to be opened with files passed into it, either by dragging and dropping files onto its icon in the Finder, or by being triggered from Lightroom, et al. (Image Capture can also use post-import scripts and they work in precisely the same way). When the script runs, theObjects will be a list of files to do something with.

The following block (repeat with) is then repeated with each file that was passed in. The composite program included in ImageMagick is used to layer an image on top of another image, so we call that with the do shell script command, which basically simulates typing something into the terminal. The -compose Over option tells it to place the second image on top of the first, and -gravity southwest means to place it in the lower left corner. I then supply the paths to my copyright.gif and the POSIX path of each of the files opened by this script (the ones dropped onto its icon or passed in by Lightroom). If any of this is unclear, leave a comment.

If you are re-creating this script for yourself, just be sure to save it as an application. In the “save” dialog, you can choose a few different formats to save the script in, but only “application” will give it the ability to operate as a droplet (a program you can drop files onto).

Great, now let’s make it run automatically from Lightroom!

Configuring Lightroom

When you run the Export command from Lightroom, you are presented with a dialog box much like the one you see below. We are chiefly concerned with the option highlighted in this picture.

When you open that menu, you will want to choose “Go to Export Actions Folder Now” as shown below.

Note: disregard the “Watermark+Upload” option; that is a modified version of this Watermark script that also opens Transmit and uploads the photos to my website. I’ll cover that functionality in another article. See, AppleScript rules!

When you choose that option, the Export Actions folder will be revealed in the Finder and you can then place the Watermark script into it. Make sure it’s in the Export Actions folder and not in the Lightroom folder! If you cancel and re-open the Export dialog, you will now be able to select Watermark in the list. Exporting photos using that post-processing filter should now automatically apply your watermark image!

This has been a long-winded and very technical article. I realize that all of you are coming here with different levels of familiarity with the terminal, ImageMagick, AppleScript, etc., so I covered what I thought were the most important points. If you have any questions, just leave a comment and I’ll be glad to explain anything I left out.

Good luck and happy watermarking!

P.S. Learn even more about scripting in Automated Workflow II