Tweaking Photoshop to Save your Metadata

Well, I learned something about Photoshop and metadata recently and thought I would share it with you. For some this little thing may be no big deal but if you're keen on preserving metadata across users and platforms, if providing lo-rez images for 3rd-party vendors or to scattered staff where the need to view metdata might be crucial, then this little tip may help.

Oh, and this predicated on the idea that you're using Photoshop in prepping images for the web.

If you "Save for the Web" in Photoshop (keyboard: Option+Command+Shift+S), on the right side of the large  dialog box, directly above the Color Table is a drop-down menu for metadata. I believe that by default it is set to "Copyright and Contact Info" but don't quote me on that. Anyway, whatever the setting I suggest you set this to "All." It will stay that way by default until you manually change it to something else.

If you don't make this adjustment then none of the metadata embedded in any image you run through this feature of PS4 will be saved. And that's a fact.

Forewarned is forearmed. (Click on the screenshot to enlarge.)

What's in a number? Calculating the size of your image library

Beginning with Mac OS 10.6 Apple's Finder now calculates the size of your drive (internal and external) a bit differently than it did before. The idea now, apparently, is to provide the user with a number that appears "more accurate" than it might have before, when in fact the size reported in previous versions of Mac OS X simply allowed for a cushion.

For example, on a 2-tb external drive, my older desktop (OS 10.5.8) reports the space remaining as 1.07 while my laptop (with 10.6.5) reports 1.18 remaining. But, both machines report the same number of bytes, however (790 billion and change).  (By the way, a Windows machine reports the drive size the same way as the older Mac OS X.)

While I can't reproduce the complex explanations for how drive sizes are calculated (nor would I want to), suffice it to say that when you see your drive listed in Snow Leopard it attempts to provide you with a reading that is more in line with the accurate byte calculation. That is, 790 gigs used (to represent the 790+ billion bytes).

Now, aren't you glad you asked?

Previewing problems in Bridge CS4?

If you're having problems previewing images in folders you've previously indexed in Adobe Bridge CS4 try this:


1. In Bridge go to Edit>Find (Command+F)
2. Select the folder where the problem seems to occur most often (alternatively select all your image folders)
3. In the search criteria drop-downs select "keywords" and then type in the broadest keyword in your library, one that might cover all your images (such as your name, if you tag all your images that way  for example)
4. Make sure to check BOTH Include all subfolders and Include Non-indexed files
4. Click find and then walk away. Depending on how large your image library is, this might take a while (or overnight).


We've have found that using this method is one way to "clean up" any re-indexing issues that might arise in Bridge's caching process after months of re-indexing folders.


There are, of course, no guarantees so be sure to keep any eye on your caching numbers in the Library.

Adobe Bridge CS4 Previewing problem

It's been over a year since our department started using a central image library and, with only 2 or 3  minor issues, the print and web teams have experienced few problems accessing the photos using Adobe Bridge CS4. All machines have undergone both initial and repeated reindexing have produced no unexpected anomalies. Recently, however, several machines have begun to experience problems in loading previews of several recently uploaded folders.

Remember, our image library consists of a series of folders (by date), each with a varying number of images inside (but rarely over 2k or more images). Typically, once a folder of photos is cached (or "indexed) in Bridge, the program creates a separate subfolder for the thumbnails and another subfolder for the previews, all within Bridge's cache folders. (Located in the user's Library on a Mac.)

Initial indexing/caching creates all the thumbnails and previews for that one folder. Subsequent "recaching/re-indexing" only adds any additional metadata that might have been modified since the initial caching -- new images are almost never added to folders within the library.

Now, to the issue.

Beginning several weeks ago -- the timing is, unfortunately, uncertain - I began experiencing a preview loading problem on both the benchmark machines. (Two Macs, one desktop one laptop that serve as the most accurate and up-to-date sources for accessing the library.) The problem was first noticed in the search results window: previews appeared pixelated in the preview window and often remained that way. In addition, when attempting to review (or use the slideshow) feature, the images would often remain pixelated for some seconds or not load at all.

At first I thought this was isolated and temporary. But I then learned that several others were experiencing the same problem. (Only Macs, though. The two Windows machines, not overly used but one kept up-to-date, seemed fine.)

Modifying the preview generating option in the Path Bar made a short-term difference on a couple of machines, but the option was already selected on a couple of other machines exhibiting the loading problem.

When I began investigating the caching behavior of the problem machines, it soon became clear that the problem was deeper. By examining the cache folders inside of the Library cache folder structure, I could see that previews were not being generated even when the folder(s) were reindexed. In fact, I even tried purging and rebuilding the cache for several folders and watched the preview cache folder. I could easily see that not all the previews were being built and indexed.

The question now is why is this happening? The corollary is why is this happening on just a few machines? All the machines, it should be noted, are of the same vintage, and of robust features, and sharing the same OS and software.

Odd error messages when modifying metadata

It's unknown what these messages mean exactly, other than they cause havoc if you're attempting to tag a large number of images at a time. You'll have to force quit Bridge since there's no other way to stop these messages from popping up without clicking on them one at a time. 


No pattern has been found, aside from perhaps they seem to be more prevalent with RAW files but that's not an absolute.


Any ideas?

Keywording tips

There is a great deal of chatter about keywords and how they can make archiving photos (and other digital assets) accessible. The simple fact is they can indeed make life infinitely more enjoyable for the digital archivist and searchable for the designer or writer. But -- and this is a BIG but - you have to follow a few simple rules.

Identify and clarify an initial keyword list. This is best done in conjunction with your team's designers and writers. Once identified, the list can be built upon and developed as needed.

Deciding is your keyword list for internal or external use.

Know your image environment. If you're working primarily in one field use the words most associated with that field. For example, if you're in higher education, chances are slim you will need to search using military-oriented keywords. "Academics" or "History" or "Student," yes, but probably not ""armor," "platoon," or "squad."

Keep the keyword list short, sweet and relevant. There are a few exceptions to this rule, however. For example, we have a number of "historical" images representing old academic programs no longer taught at JWU: "keypunch" and "office machines" to name just two. I've tagged those programs using relevant keywords although I am almost certain those search terms will never be used again.

Also, if I'm faced with tagging an image that doesn't reflect any of the previously identified keywords, add a new keyword. You can always go back later and modify it -- but if you don't identify the keyword up front you've lost the opportunity to tag that image or group of images accurately.

For more in-depth discussion of this often misunderstood and misapplied concept, visit Peter Krough's illuminating article in DPBestFlow online.

Adding Metadata - bugs and glitches

An ongoing problem -- one that has frustrated me from the very beginning of this project -- is the error message that continually crops up whenever I try to add, delete, or otherwise modify the metadata in an image or group of images in the library. (I began this discussion this in my previous post.)

Specifically, the problem usually occurs in the "Search results" window (but not always). What happens is, when I try and modify the metadata of an image or a group of images and will often (but not always) get an error message, saying that such-and-such image cannot be modified, no reason given. Furthermore, if you have selected a number of images to be modified, you have to manually click through each one. More frustration.

Much of the time the problem can be "worked around" by going to the specific folder where the images are located and modifying them there, rather than in the search results window. Clunky but it does work. Sometimes the problem arises when dealing with Camera RAW files (NEF has been a primary culprit here). as I noted in my previous post, one can simply convert RAW files to DNG and the problem goes away. Plus it lowers the overall file size and no sidecar XMP files to deal with.

If anyone has any ideas or thoughts about this, I'd love to hear them. And share them.