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.

Converting RAW to DNG - an absolute necessity now

Back in April I posted a discussion of the rationale for converting proprietary RAW files to DNG. Now, it appears I'm going to have to do just that.

It's not space that's the issue but the wonky relationship between Bridge CS4 and some of the RAW file formats, particularly Nikon's NEF. For some weeks now I've been unable to update the metadata in NEF files; I would continually get an error message when I attempted to update a group of files -- and, if this has ever happened to you you know what a serious hassle this is. On several occasions, when I tried to update a large group of files I would have to force quit Bridge since it wanted to show an error message for each file and each message had to be closed out manually. Not a pretty picture when you're trying to update 608 files. And this seemed to happen with each and every NEF file I was working on.

But this problem does NOT occur when working with DNG RAW files.

So, in addition to reducing overall file size (and consequently space concerns), I now have cleaner files. Or will have.

Since there are more than 8k RAW files in our central library I'll be at this for a while, to be sure. But I suspect it will be time well spent in not only making accessibility and searchability that more effective but also paving the way for archiving these image files for years to come.

JWU Central Image Library using Bridge CS4 is still working

It's going on nearly a year now since we created a central image library using only Adobe Bridge CS4 and so far, so good. There have been a few issues to be sure -- trying to modify metadata in the search results window is frequently of the more exasperating and seemingly irresolvable.

Right now we have more than 130,000 images -- still images only -- in the central library, which is accessible to our designers and writers.

There is, of course, the ongoing challenge of keeping up with re-caching (re-indexing) each machine. In other words, every time metadata is modified or added to any existing image in any folder, that folder has to be "re-cached" in order for the new metadata to be searchable.

This can be a challenge to be sure but is certainly not an overwhelming one. Each week I keep a running log of the folders where image metadata has been modified and the following Monday I send out an email noting those folders that need re-caching. It's then up to the designers and writers to make sure their machines are up-to-date.

If someone leaves on vacation or, as happened recently in our office someone is out on maternity leave, I make a point of re-caching that particular machine myself.

It's really that simple.

Next: Using the Collections Panel will streamline your workflow.

Using DNG File conversion to maintain control over Image Library Size

Out of more than 110,000 photos in our image library nearly 8,600 are Camera RAW files (NEF, CR2, DCR, RAF primarily). Although they make up less than 8% of the total number of files, they account for more than 12% of the total space taken up on the drive (68 gigabytes out of 526 gigs of space occupied by the library).

The challenge is how to preserve the integrity and optimize the size of the library, reduce the multiple file formats and standardize the image files, while acquiring the best quality images for use over the coming years.

Camera RAW files are the obvious answer but the file space these would require prohibit our organization from using RAW files.

Adobe's DNG file format system is widely touted as achieving smaller RAW files while protecting the integrity of the image data -- unlike with jpgs.

Moreover, DNG files also combine the metadata into the image itself unlike RAW files which use the sidecar method of storing xmp information, and the problem with sidecar files is you risk loss of that data if the sidecar file becomes separated from the image file.

Recently I undertook a series of in-house tests using 30 random camera RAW images from a variety of different RAW formats. Bridge's built-in DNG converter made the process simple and easy.

Results:

Orig RAW: 30 images (238.5 mb)
DNG convert: 30 images (181.8 mb) - with no loss of information

Moreover, the DNGs open up just like a camera RAW file in PS CS4.

Several options are now available:

All contract photographers would be required to send the "keeper" RAW files on disk, and we convert to JPG for uploading to the library (thus keeping the library at a reasonable size). If a larger, more robust copy of that image is needed, the metadata in the JPG will direct the designers to the specific disk where they can find the RAW file. (Professional digital photographers shoot predominantly in Camera RAW in any event.)

Another scenario would be to request that all contract photographers convert their final images to DNG instead of jpg before sending them to us. This would require no additional steps on their part, since they convert the images to something after color correcting, reviewing, etc. And we get the added benefit of the BEST quality image. Of course, the photographer could send us the RAW files and we can convert in-house. With Adobe's PS and Bridge the process is quick and easy, and we can even add our own metadata information during the conversion process.

Lastly, the photographer could send us BOTH the RAW and JPG files, since DSLRs today are capable of shooting images in both formats at the same time. No conversion is needed -- however this does not take into account those files that were color-corrected.