I've been too busy to post lately, working on, among other things, a followup to the Lightroom metadata-viewer preset builder of my last post (the followup being an application tentatively titled “Jeffrey's Lightroom Configuration Manager”).
Being busy doesn't attenuate the desire to share, so I'm dipping into my “blog about this someday” shoebox of photos, this time back to last August when we were visiting our (now former) place in California. We'd arrived in the middle of an oppressive heat wave, leading to some great shots of Anthony playing in the sprinklers that I posted at the time.
This post's photos are in the “appeals to me for some reason” category. Perhaps it's because I feel (hope) that they're universally enjoyable, being that there are no faces and they represent quintessentially young and carefree times. But then, maybe it's just me and they're boring to everyone else 🙂
Both the jumping and the Popsicle shots are from the preschool Anthony attended while we were there. Now that I think about it, I don't think I ever followed up to the Can anyone suggest a good preschool? question I asked when we arrived. We eventually found Primary Plus in Saratoga, and really liked it. The principal, Miss Heather, was very nice and accommodating, and we liked all the teachers. Anthony really liked his teacher, Miss Sandy.
Metadata Viewer Closeup
As I noted in my previous post, three weeks after having been officially announced, Adobe has released Lightroom Version 1.0 (a free 30-day trial can be downloaded from Adobe's Lightroom page).
Especially considering it's only a “Version 1” product, Lightroom offers a lot of things that can be customized. The subject of this post is the list of image metadata shown by the Metadata Panel in Library mode.
The metadata panel can show much more for an image than anyone's likely to want to see at one time — over 100 items, such as its filename, the latitude/longitude where it was taken, the shutter speed, a caption, etc.— the volume of which can quickly overwhelm.
To whittle down the information to a smaller set of items, the metadata panel comes with a number of presets (Default, All, EXIF, IPTC, Minimal, and Quick Describe), each showing a different subset of the possible items. (Perhaps surprisingly, the “All” preset does not show all items — more on this later.)
Lightroom also has metadata presets, which include settings such as “Copyright is 'Jeffrey Friedl', City is 'Kyoto',” etc., that can be applied to images to add to or change their metadata. This post is not about those; it's about the which-items-should-be-shown viewer presets.
Because there are so many items the metadata panel might show, chances are small that any of the presets actually shows the list of metadata items you wish to see while hiding the ones that would be clutter to you.
Luckily, you can create your own presets.
Unfortunately, because Lightroom is indeed a 1.0 product, it doesn't actually include a way to create and edit your own presets.
Luckily, I pestered the Adobe engineers enough that they told me how to create metadata-viewer preset configuration files, and kindly gave me permission to share it.
So, I present Jeffrey's Lightroom Metadata-Viewer Preset Builder, a web application with a mouthful of a name that allows you to create your own presets, complete with self-titled headers and line separators.
Obligatory disclaimer: Custom metadata-viewer presets, from this or any source, are not supported by Adobe. There are no guarantees that the presets you build for Lightroom Version 1.0 will be at all useful with later versions of Lightroom. In fact, there are no guarantees that they'll be useful with any version of Lightroom. “Use at your own risk.”
Okay, with that out of the way, here's a bird's-eye view of the application. The main work area is the lower half (the custom list and the menu).
To create your own presets....

The Menu
Choose from about 100 items
Select a current preset to use as a starting base, or choose from among one of the extras I've included (“None”, “All Supported Fields”, and my own daily-use preset).
Read the instructions, then press the “hide header” button to save more screen real-estate for the preset builder itself.
Create your preset, adding and removing items by checking them in the menu (seen at right), or adding headers and rules with the buttons at the top of the menu.
An example view of your custom preset is shown in the lower-left of the application, with fake metadata filled in from one of my images, just to give a sense of how it'll look in actual use.
In the custom list, you can drag items to reorder them, and you can drag them to the trash (the pink stripe at far the left) to remove them.
Once everything's as you like it, bring back the header by clicking the hide-header button again (which had become a show-header button) and enter a title for your preset. The title you choose here is what Lightroom shows in the drop-down list of presets (as shown at below), so choose a short but descriptive title.
Finally, press the “Generate Preset File” button.
After pressing the generate-preset button, you're presented with a page from which you can download a “.lrtemplate” file. You can also bookmark the page, and share its url with those you'd like to share your preset with; they can then download the same preset, or use yours as a basis from which to build their own. For example, here's the page for my main daily-use preset that includes the metadata items I normally want to see or edit.
Installation
Before installing the preset, you must first create a “Metadata Field Lists” directory in Lightroom's application support folder:
- Mac OS X:
- ~/Library/Application Support/Adobe/Lightroom/Metadata Field Lists/
- Windows XP:
- C:\Documents and Settings\username\Application Data\Adobe\Lightroom\Metadata Field Lists\
- Windows Vista:
- C:\Users\username\Application Data\Adobe\Lightroom\Metadata Field Lists\
There's a report that the vista location differs — see this alternate Vista install location.
Preset drop-down where your
preset title appears in Lightroom
(On Windows, you may have to visit the Folder Options dialog to allow the normally-hidden Application Data folder to be seen.)
Finally, drop the .....lrtemplate file you downloaded into the directory you just created, and start (or restart) Lightroom.
The left side of the header in the Library Mode's Metadata Panel likely says “Default” — click it to see your preset among those in the drop-down list.
General Notes
Here are some cautions about Lightroom's metadata viewer, whether with a custom preset or one of the standard ones:
The preset builder shows a very wide view of the Metadata viewer panel — perhaps wider than most people will want their Lightroom panels to be (since widening the panels takes away from the Grid/Loupe area). So, keep in mind that long data (e.g. lens information, camera make+model) may be too wide to actually fully appear in normal use.
Some items seem almost identical, but are really quite different. For example, both the “File Path” and the “Folder” items display the name of the folder that the file is in, but they differ in how they interact with the mouse: clicking on one brings up the file in Explorer/Finder, while the other switches Lightroom to viewing the images in that same folder (something I find much more useful).
The similarity among some of the items is one reason that the standard “All” preset really doesn't have all the items. It's also one reason that you'll want to take care when building your presets, so you'll get what you think you're getting.
As you move from image to image in your library, the metadata items missing from an image are not shown in the metadata panel unless they're editable.
For example, if the preset includes the copyright field, that field is shown even if the image has no copyright notice embedded in it (thus, letting you add one if you wish). However, if the preset includes the GPS-coordinates field, but the image is not geoencode, it's simply not shown in the viewer.
The metadata viewer simply reports metadata in the file (or in Lightroom's database about the file). For example, Lightroom could potentially compute a value for “Focal Length 35mm” (full-frame-35mm-camera effective focal length), but it reports it only if that Exif field is actually present in the image metadata.
(Actually, in Version 1.0, Lightroom doesn't display this particular field even if it is present in the image; I've submitted this bug to Adobe.)
Lightroom does not generally show metadata from the “Maker's Notes” section of metadata placed by many cameras. For example, Nikon cameras place the distance to the subject, if known, into the Exif “Subject Distance” field of JPG images it creates, but for NEF (raw) images, Nikon puts that data only into the Maker's Notes. Thus, Lightroom does show the subject-distance field for Nikon JPGs that have it, but not for Nikon NEFs that have it.
(On an odd but encouraging note, Lightroom does pick up the Lens information from Nikon raw files.)
You can use my Lightroom Configuration Manager to change the labels in the metadata panel, among other things.
My Tech-Related Photography Posts
- My Lightroom-to-iPad Workflow
- Lightroom Goodies (lots of plugins)
- Digital Image Color Spaces
- Online Exif (Image Data) Viewer
- Jeffrey's Autofocus Test Chart
- Photoshop Calendar-Template-Building Script
- How to Prepare Photos for an iPad
- A Qualitative Analysis of NEF Compression
- Tripod Stability Tests
more...
Colophon
I was very excited when I first got wind of Lightroom's support for custom metadata viewer presets, because the standard presets all had either too few items I wanted, or way too many items I didn't. I asked Adobe for more information with the suggestion that I could build a simple web tool to generate the preset files (implying that if they were easy for the average photographer to generate, Adobe wouldn't have to expend resources supporting a known-but-undocumented feature).
When I finally got technical detail in early February, I was joyful that it supported so much (including free ordering, rules, blank spacers, and headers), but I was also dismayed for the same reasons, because now I had to put my money where my mouth was and build a tool up to the task.
I've never been a huge fan of JavaScript, but I decided to jump in head first, choosing to give the Yahoo! User Interface Library a try based on its great reputation. Its documentation is geared more for reading from the start rather than jumping in and using as a reference, which I found a bit problematic (some people criticize my book for the same reason), but otherwise, it was extremely helpful.
Also very helpful were a couple of Firefox extensions, the most excellent Aardvark and mind-blowingly-supreme Firebug.
It was a lot of work just getting things to work in a first-class browser like Firefox, not to mention then getting it to work in IE. I hope you'll find that it was worth it.
Adobe Lightroom Version 1.0 was made public today, in line with the schedule previously announced. I eagerly downloaded and installed 30-day-free evaluation copies, one for my Mac, and one for my Windows box... (my Linux box is still Lightroom-free, unfortunately).
One nice thing about Lightroom is that the licence is for two computers, so you can buy one copy and use on both your Mac laptop and Windows desktop (for example, which is what I'm doing).
Over half a million people registered to try the free betas last year, and with the advances between October's “Beta 4.1” and today's “1.0”, I'm sure that many people will be extremely pleased.
Dichotomy of Functionality
Lightroom's feature set is a dichotomy. In one sense, it has so many features that I certainly can't claim to know even most of them, much less all. It has five main modules, with the main two being Library and Develop (used for sorting, filtering, touching up, and “developing” images — adjusting exposure, color, etc.). I spend 99% of my Lightroom time in these modules, but it also has Slideshow, Print, and Web modules (for making slideshow presentations, for printing, and for making web-based flash/html galleries). I've used the Print module occasionally (it's much nicer than Photoshop's), but only superficially. I've not really done anything but play with the other two modules.
So, I spend 99% of my time in Library and Develop, and they are exceptionally wonderful for working with images (JPG, raw, Tiff, PSD... doesn't matter). Whether I'm spending a lot of quality time on one image, or plowing through 500 new shots from one of Anthony's preschool events, Lightroom just seems right.
Nevertheless, as much as I know about these two modules (and as much as I get out of them, which is the important point), and despite having used one build of 1.0 or another for a month and a half, I know enough to know that there's still much more I don't know.
I certainly have a lot to look forward to as I spend more time with Lightroom.
On the other side of the dichotomy, Lightroom is a “Version 1” product, which has, like all Version 1 products, an immature feature set. Lightroom's is remarkably mature for its age, but people expecting Photoshop-like detail will be sorely disappointed.
Let's consider Photoshop for a moment: Photoshop 1.0 was released 16 years ago this month, and is currently in beta for Version 10 (that's a ten, not a one-point-oh without the point). That's a lot of development behind it, yet, it still doesn't do some of the most simple things I want to do when editing images. This is perhaps more of a reflection on me and my habits/wants than it is on Photoshop, but the point is that with as many people as there are on earth, try as you might, you can't please everyone.
Back to Lightroom, there are some areas where it is clearly lacking, and no one is more aware of this than the engineers at Adobe. In software development, the question is never “is this done?” because software is never done any more than Photoshop was “done” at, say, its Version 5, or Microsoft was “done” with Windows at its version 98. The question for releases is “is this good enough?” — good enough to be a usable product, worth its cost to the user.
Had Adobe waited for Lightroom to be done, it would never be released, so clearly, the question now for the potential user is “is Lightroom done enough for me?” If you tried the public betas and wished for dust-spot removal, you'll be happy to find it there, along with a clone tool to boot. But if you tried the public beta and bemoaned the poor sharpening and noise-reduction controls, you'll be only a bit encouraged to find that although NR has been split to separate Luminance and Color controls, it still falls woefully short of, say, what Noise Ninja does in Photoshop.
Some people will point to missing features that are important to them and cry loudly that Lightroom is horrible, that without such-and-such a feature it is nothing more than a toy, etc. I'm writing this post on the day Lightroom 1.0 is released as a preemptive strike against such generalizations, because so long as a potential buyer knows what they're getting, Lightroom is what it is, and it's up to each user to decide whether it's worth it to them. I know of some professional photographers who use Lightroom every day as part of their job, and I know of others who don't use it because it's missing something they require. To each their own.
If you have a digital camera and wonder whether Lightroom might be useful for you (and you have a Mac or a Windows computer), why not try it for the free month Adobe allows, and decide for yourself?
By the way, the strawberries so nicely arranged are Fumie's work, from the mini and somewhat impromptu party we had a month ago.
After publishing my writeup on Digital Image Color Spaces four months ago, I got into a discussion on color spaces and photo-hosting sites with one Chris MacAskill on a forum at Digital Photograph Review. I didn't realize it until today, but it turns out that this Chris MacAskill guy is the president of the popular SmugMug photo-hosting site.
Fast-forward a few months to earlier this week, and Chris posted his own comments on the Mac/OSX aspects of the issue. In just a few days, his post got over 100 comments, including some from the main players in this arena. I guess that's one benefit of, well, having your own popular photo-hosting site. 🙂
Chris left a comment on my color-space writeup pointing to his post, and as my response to him and his writeup got longer, I decided to just include it here in my blog as a post.....
|> I'd love it if together we could get some momentum for |> Apple to implement the easy fix that makes this right.
Wow, Chris, well, if it's momentum you wanted, I think you got it, considering that you got more comments on your post than I have pageviews on mine, I guess there's some benefit to being the head of a popular site like yours. 🙂
I see that even Dave Hyatt responded to your note, which is excellent. I wrote to him directly myself, but got no reply. He's someone who can actually do something at Apple.
One thing I got from the article and from the comments is that people seem to think that setting the monitor profile is a good way to address this situation. However, that's trying to cancel out one mistake with another.
The monitor profile is data that indicates how to convert device-independent color data into actual photons, and that data is necessarily dependent on the physical characteristics of the individual LCD or CRT. sRGB was designed to mimic the average such device (circa 10 years ago), but it would be a remarkable coincidence for any particular display's physical characteristics to actually match sRGB, so setting its profile to sRGB is correct only in a remarkablely coincidental situation.
The root of the OSX problem is that it makes a poor guess as to the color space of an unprofiled image, and so given that, how can it possibly hope to convert properly from the (misunderstood) device-independent color data of the image to the device-dependent data required of the display device? You can try to compensate by changing the monitor profile to something less accurate that seems to give nice results, but you can probably get the same effect by smearing an appropriately colored block of Jello™ in your eyes. Both seem effective in the short run, but are probably not good solutions. 🙂
The consensus among the comments on your post seems to be that the paramount importance is for colors to match across technologies.... images, flash, html/css, etc., and that such matching should take precedence over accurate color rendering. Clearly, the matching is important because, as you point out in your post's examples, not doing so can create a worse effect than coordinated-but-inaccurate colors.
However, what no one seems to mention is that the need for coordination tends to be restricted to, well, when it's needed, and that there are times when proper colors are clearly more important, such as when displaying the rich beauty of one's photographic work (such as on a web page with a colorless background, like your photo-hosting site does.)
I don't doubt the difficulty faced by Dave Hyatt at Apple, but here's a suggestion I've made before for OSX that goes a long way toward solving the issues in a way that is sensitive to the context: respect an image's color-space information if it's there, and if not, coordinate the color space with that of flash/css/whatever.
This might sound to be exactly like what OSX does now, but the big difference is that OSX currently ignores tagged color profiles. All digital cameras today (well, at least any I've ever heard of) mark the color space in the image metadata with a simple one-word note, rather than with a full-blown embedded color profile. The EXIF/DCF standards that cameras tend to adhere to currently allow sRGB and AdobeRGB to be noted this way. The benefit is that it takes only a few bytes, but the drawback is that no browser recognizes it, not even Safari.
May 2007 Update Much to my embarrassment, I've only just realized that Windows browsers do not default to sRGB, but rather, are unmanaged, and so they treat all images in the same sort-of-random, sort-of-close-to-sRGB way that Safari treats unprofiled images. As such, the next paragraph is wrong.
(Outside of OSX, it's not usually an issue because most cameras produce
only sRGB, and most browsers are on Windows which blindly assumes sRGB, and
hence it becomes an issue mostly for Safari and other OSX browsers).
The beauty of this approach is that it keeps color coordination among page components when needed (because web designers making mastheads and logos and stuff don't tag their images with color-space information), yet allows people who upload images from their point-n-shoot or pro-dSLR to expect them to be seen with the most accurate colors their audience's monitors can produce. It would even let SmugMug have color-managed thumbnails!
One would hope that in the future, Flash and such will all be properly color managed (and no one is waiting for this more than Dave, I'm sure 🙂), but until then, doesn't this seem like a reasonable compromise? You can then get proper colors where it matters most, and people can leave their monitors set with the profile that's most appropriate for the monitor and not to an artificial profile designed to cater to some specific misinterpreted content.
The next step, then, would get the folks in Redmond to respect color profiles.....but I won't be holding my breath!
Yesterday we went to some very old, semi-famous mochi shops in north-west Kyoto, near the Imamiya Shrine. We took the opportunity to walk around the shrine a bit, and in doing so, found a plum (I think) tree just starting to blossom. This was especially surprising because this part of the city is known to be generally colder than the main areas, by a non-trivial amount, so I would have expected it to be later than our area.
In any case, my first blossom-related post is quite a bit earlier this year than last year (April 8th) or the year before (April 7th).

Nikon D200 + Nikkor 17-55 f/2.8 @ 55mm — 1/1000 sec, f/2.8, ISO 250 — map & image data
Buds on a (Plum?) Tree

Nikon D200 + Nikkor 17-55 f/2.8 @ 55mm — 1/5000 sec, f/2.8, ISO 200 — map & image data
One of about three blossoms on the tree
Near the tree in question, Fumie watches Anthony running around and playing. I really like this shot..

Nikon D200 + Nikkor 17-55 f/2.8 @ 52mm — 1/125 sec, f/5.6, ISO 250 — map & image data
Watching Anthony Play
I'll continue to be really crushed with work for the next few days, but I'll post more pictures from the shrine area, and from the mochi shops, over the weekend.....




