Digital Photo Archivist

Searchin in Bridge: Spotlight or Bridge's Search?

2012-01-25T10:30:00.000-05:00

Inspired by a recent online posting by Lone Digital Librarian (on our wikispaces discussion page) talking about the new Mac OS Lion and the potential search features in Spotlight, I ran a test using Snow Leopard (which is what I have on my Mac).

Assuming your image library is fully indexed in Bridge, here's what you might find. I navigated to the little Spotlight search box in the upper right corner of Bridge and typed in a word (and only one word), "classroom." A few minutes later I had my search results, and it wasn't pretty.

Now I had run tests using Spotlight early on in this project and knew that the search feature was weak to say the least. This time I learned something else, where the limitation rests. Apparently when you type in a word it searches for the word in filenames and keywords and will return those images tagged accordingly. This does not appear to be adjustable.

Oh, and if you type in a word followed by a comma and a second search criterion, Spotlight from within Bridge will search for that combination (i.e., word, comma, word). Not good either.

Lightroom or Bridge?

2012-01-24T11:24:00.000-05:00

Adob Photoshop guru Julieanne Kost discusses the pros and cons of using Bridge or Lightroom

Daminion archiving software

2012-01-20T15:52:00.000-05:00

I received an email the other day from Murat Korkmazov, the business development director of Daminion Software, an archiving program touted as being designed as a "low-cost alternative for the needs of the small team."

I visited the website and must say I was impressed with the ease of navigating the site and the robust set of features of the product were equally attractive. They also have a server version as well. Finally, the pricing seemed too good to be true -- with deep discounts for education departments.

OK, so did I download a demo and give it a test run?

Nope.

Unfortunately, Daminion is a Windows-only program, which seems a bit odd since most professional photographers I know and certainly most design departments in this neck of the woods run on and around Macs. But Daminion is a Russian company which might partially explain the Windows-only requirement -- due to cost and ease of acquisition, many computer users outside the US and Canada have come to rely on the cheapness and accessibility of PCs driven by Windows.

In any case, according to Murat they have no plans for producing a Mac version anytime soon.

Whatever the reason, it's too bad because this program looked pretty good -- the UI that I could see from the screen shots reminded me a bit of the old Expression Media 2 -- a wonderful catalog-driven archiving program now iterating under the name of Media Pro at Phase One. Plus it was loaded with a ton of features that just cried out to be tested.

I'm providing a link to the company's site -- or you can cut 'n paste the URL if you prefer: http://daminion.net/ in hopes that someone may test it out and let us know if this is a reasonable compromise between Bridge and a full blown DAM.

And best of luck to Murat and his colleagues in Stavropol, Russia.

Oh, and one final word: they do have offices in Seattle, WA and Vancouver, BC.

A window into Bridge's limits - or the corrupt cache issue, again

2012-01-17T18:03:00.004-05:00

Well, it happened again: the dreaded “Bridge has a problem reading the cache. Purge the central cache.”

This has now happened twice on the G5 tower (my primary benchmark machine). Both times the cache had reached nearly identical size: 44gb, 364k+ items. the first time and 43gb, 352k+ items the second time.

Although a pattern seems to be emerging, it should be noted that the third time this happened was on my Macbook Pro and the size was somewhat smaller: 40gb, 298k+ items.

While we can't determine what this means with any degree of certainty, it just might indicate what the top end limits are in using Bridge.

Still. . . it pays to watch your cache levels carefully and optimize as needed (command/control + K in Bridge preferences)

Discussion forum is up on wikispaces

2012-01-10T07:00:00.000-05:00

Just to the right of this post you'll notice a link to the new discussion forum on wikispaces. Once you click on the link and land on the forum just click on "Recent changes" on the left side bar menu and voila! We can continue our dialogue about image archiving solutions - please note that I'll still be posting here as well.

Let me know if you have problems accessing or posting.

Anyway, we'll give this go -- thanks for the idea "Anonymous" -- and see how well it works!

Which image archiving option to use? part 2

2012-01-08T09:29:00.001-05:00

In my last post I started reproducing a dialogue that began as a series of comments between myself and a reader but on an older post. The dilemma "Anonymous" raised, over which image archiving tool is the best, affects more than just the two of us and our respective organizations.

Any suggestions or comments you might have by all means jump into the conversation!

I have included the latest reply from Anonymous (January 6) as well as my response:

I've had some time to actually discuss a bigger picture of what's going to be needed with the department professionals and the list of needs has left me a bit concerned that we may need something made? Keep in mind this is a for-profit company. I'm not too certain about what product could achieve all of the following:

-Intranet systems for internal information use
-Simple template input portal for uploading, labeling, and tagging images.
-Database look ups for linked images across multiple programs (ex: inDesign)
-Simple search portal to narrow down images and permit more in the way of browsing capabilities.
-Use of multiple search terms for searching directly.
-A bulk file rename utility.
-There is also a want for something like an OPAC for use within the company to find both images and books within the company library.

Again, I'm not sure if something like Asset Bank or Portfolio Server can come up to this level of complex organization, mixed with the simplicity of input and search needed at this particular location.

It is also important to note that I am a staff of one for this particular function, with limited programming history and a Mac OS to work around.

Like you, I'm a staff of one with limited technical background and although I use both a PC and a Mac as benchmark machines to maintain the library, virtually everyone else with access to the library uses a Mac.

Looking over your bullet list above, I would have to say that, with a couple of possible exceptions, Bridge can pretty much accomplish all those tasks.

We use it on a network
Photo downloader is a handy little tool for importing and applying metadata templates to images straight from a camera or memory card
While it's not a database, Bridge can certainly search across various file formats -- if I understand you correctly
It's search features are pretty easy to use -- of course much depends upon the keywording and search strategies developed to access images in the library - I do agree that bridge has limitations here to be sure
Bridge's search features are quite robust and allow for multiple metadata searching
Bridge CS4 has a handy bulk renaming feature, which has been significantly enhanced in CS5
I'm a bit unclear here on exactly what you have in mind here -- but again, if the "book" is in a file format that can be tagged and if the item has been tagged properly, Bridge should be able to find it.

Of course, I want to emphasize again that Bridge has some very serious limitations. And those limitations are most readily experienced in setting up and maintaining a large image library.

Having said that, the key deciding factor for our organization -- and from conversations I had with other readers here I sense we're not alone -- the key factor is cost. Bridge is free (or nearly so). And there's also the learning curve: many designers, for us the most likely users of an image library, have some familiarity with the software already.

OK, so any thoughts?

Which image archive option to use?

2012-01-07T09:20:00.002-05:00

I've had a running conversation with a reader on one of my older blog posts about the dilemma we all face in trying to come up with the right option for creating and using a large image library. Since the issues raised touch at the very heart of what many of us are faced with, I thought I would share them.

January 4 Anonymous asked: In your opinion, would a product like Extensis Portfolio work as an extension of Adobe Bridge?

My response: On the face of it yes, Bridge can pretty much function as an extension of any database cataloging program.

Are you planning on sharing your image library among multiple users? If so, I believe Extensis Portfolio has a number of limitations in that regard -- they want multiple users to upgrade to their vastly more expensive Portfolio Server system I suppose).

Still, using a browser program like Bridge with a DB program like Portfolio in tandem should not be ruled out.

For example, I use Adobe Lightroom 3 as a file verification tool for our school's digital image library. But since no one else has the program we can't share catalogs -- which would be ideal, of course.

Anyway, you can use a program like Portfolio along with Bridge but I would suggest you test out the metadata copying and synching between the two programs. thoroughly before making any serious commitment.

Ultimately, though, I might suggest you go with one or the other and reduce your workflow while keeping your costs reasonable and making your life simpler.

Anonymous said: Well, I have a large volume of images (100,000+ with new ones daily/weekly) in a corporate setting where the images need to be accessible to over 20 people. We're working with macs, so I'm trying to find something simple that performs a better search than spotlight or the bridge program itself. I was considering Asset Bank as another option to work within our server, since we don't need to make the images accessible to clients or the public. These were the package options I'd seen. http://www.assetbank.co.uk/product/packages/  Third Light also looks like an option, but I'm a bit unsure where to go.

I replied: Like you we also have a large image library ( more than 153K photos) shared by 16 workstations (all but two Macs).

Regarding the options noted, comparing Bridge to either Assetbank or Third Light is a bit like comparing apples to dirigibles: Bridge is a simple straightforward browser program while other two are mega-expensive, server-based systems (like Portfolio Server) and frankly way out of our price range. Like you, we just need to share among the tight department so keeping our costs down is primary right now.

In fact, that's what drove us to initially test out the viability and reliability of Bridge in the first place: it's free, or rather it comes with Adobe's Creative Suite of programs used by all our designers and writers. And, while it's a space hog (for the cache), slow to search sometimes (OK, most of the time), we have found it does work nonetheless.

But I'd be curious to hear more about what you decide to do -- and I'm sure there are others who pop by here every so often who might be keen on hearing about how to resolve your nagging dilemma.

To be continued. . .

iMatch software

2011-12-31T08:45:00.000-05:00

I recently received an email from a reader who has been using a program called iMatch -- a tool designed for both professionals and amateurs alike seeking to organize and archive a large image library.

While the program looks like it has real potential for its intended market, I'm not convinced that its limited networking capabilities would justify the shift from the "free" Bridge software. I'd be curious to know if anyone has had experience using this program on a relatively sophisticated network.

For more information you can find out more online at: http://www.photools.com/.

Adobe Lightroom 3's Bad English and Dubious Message

2011-11-22T12:00:00.000-05:00

If you've visited this blog before you know that I'm a proponent of using Adobe Bridge as an inexpensive means of organizing and archiving a large image library. However, you might also recall that I use Adobe Lightroom as a way of verifying the files I've organized and uploaded to our server through Bridge (and as a way of perhaps anticipating the future direction of our organization).

Now, you'd think that with the gazillions of dollars Adobe makes they could hire people who code their programs with proper English -- but that nuisance aside, this is an error message that is simply pregnant with danger:

Here's where things can get a bit hazy if not downright confusing. The important thing here is to know which of the two settings is the newest -- if you choose wrong you could lose a fair amount of hard work not to mention the metadata.

Just be careful.

Guide to Using Bridge Workbook now available!

2011-11-14T08:43:00.001-05:00

At long last I've finally proofed and published my little workbook on using Adobe Bridge to build and maintain a large image library.

Based on more than two years' worth of experience in building and maintain an image library of more than 140,000 photos shared and accessed by 18 users, this workbook is short but sweet with lots of room for you to jot down your own ideas as you review mine.

Any comments, suggestions or criticism would be most welcome and will likely make their way into the next version.

It's available from www.lulu.com.

Thanks for the support!

Adobe Drive 3 - a hint of the future?

2011-11-13T08:45:00.000-05:00

I suppose this post is really for CS5 users. While I’m only testing CS5 on my personal machine – our organization has no immediate plans to upgrade form CS4 to CS5 anytime soon -- what little I’ve learned so far leads me to the tentative conclusion that this is little tool is worth a serious look.

Two caveats right up front:

1. As I said, this is for CS5 users only
2. This only seems to work if your image library sits in a box with a url

If you answer yes to both of these then Adobe Drive is something that, on the face of it, appears to solve at least a couple of issues: versioning and offline work.

One has to wonder if Adobe is angling to provide something resembling a full blown DAM but without the horrendous cost.

For more information you can stop by Adobe TV and check out the handy little intro tutorial by Terry White: http://tv.adobe.com/watch/adobe-evangelists-terry-white/adobe-drive-3/

Drive 3 appears to be free - for a download: http://www.adobe.com/products/adobedrive.html

Beware remapping Bridge on your PC

2011-11-02T09:29:00.004-04:00

If you're on a PC and for some reason you have mapped to your image library server twice and get confused about which drive letter you're updating/reindexing, you need to stop, identify the more valuable of the two drives and delete the lesser of the two mapped drive letters. But you're still OK.

This problem doesn't seem to be an issue with Macs.

If, however, you have to remap to the image library the bad news is you will have to begin indexing all over again.

Sorry. Se vrais.

Recursive shmusrive

2011-10-27T18:00:00.000-04:00

Although we use Bridge CS4 for our image library at work, I have recently upgraded my personal computer to Bridge CS5 to see what all the fuss was about. First off, there is no significant change between 4 and 5 and I see little reason to upgrade, particularly when you consider you will have to completely reindex your image library (and of course eventually purge your old CS4 cache to save space).

The Bridge interface is basically the same between versions 4 and 5, although now you can use what's called the MiniBridge which is a scaled-down version of the program sitting open while you're in Photoshop. Nice but not terrific.

One thing I have noticed -- and so far it's only happened on my desktop machine -- is an odd behavior that is both curious and frustrating. When I'm in an existing folder and want to (1) create a new subfolder or (2) change the name of the existing folder, I often (but not always) got the following message:

As I noted earlier, this happens at random, with no apparent pattern -- and it doesn't happen all the time, which makes it curious. What's frustrating is that while this message is onscreen you can't do anything else in Bridge.

Any ideas?

Cache problem on Bridge CS4

2011-09-19T09:29:00.000-04:00

As digital photo librarian one of my tasks is to keep Bridge on my four machines constantly indexed and updated: three have admin level and one a simple user level. I call these my benchmark machines since they are the ones by which I measure all the other users' machines in the department. Typically, they the most accurate and up-to-date for searching; they include two PCs and two Macs.

Back in July of this year, Bridge on one of my two benchmark Macs displayed the feared "purge the central cache" message:

There is no workaround and no alternative but to purge the central cache and completely reindex the machine from scratch.

Last Friday the same thing happened to my other benchmark Mac, a laptop.

And no, we don't know why this happens: the cache size remains at normal levels:44 gbs with 380k+ items (July) and 40 gbs with 306k+ items (September). No unusual activity at the server end and so far no one else in the department has experienced this problem. Of course, that last observation leads me to suspect that it does have something to do with cache size but this remains far from clear. and anyway, I've had a cache as large as 55 gbs on my laptop with no problems.

Oh and one other thing I've learned recently: Apple's Time Machine does not back up Bridge's caching system -- in fact it doesn't back up the User library's cache folder at all. Curious, eh?

"Error writing metadata to file"

2011-09-05T15:25:00.002-04:00

I've talked about this problem early on in this blog since it started happening soon after the library went live some two years ago. And while it's not as catastrophic as a corrupted or damaged cache, it is still annoying and sometimes downright aggravating. I want to revisit the issue now because I've noticed a pattern of sorts and can't figure out what that means (if anything). Anyway, my hope is that someone reading this may have figured out what the problem is and how to fix it:

Here's what happens:

I go into a folder of images in our library on the server and select a block of images to modify the metadata.
I make the metadata change(s), typically in either keywords or the description field.
Bridge begins to modify the files -- note that my files are usually sorted by filename (lowest to highest number) but Bridge commences its "retagging" from highest to lowest.
It's at this point that Bridge appears to stall and soon brings up the above-noted error message on the first file; I click OK and the same thing happens with the next file; I click OK and then Bridge is off and running tagging all the remaining files just fine without any intervening error messages.
I then go back to retag the files that Bridge refused to tag, one-by-one, and the updating works just fine -- no error message.

The frustrating aspect of all this if you are trying to modify a large block of images and the error message keeps repeating there is no way out of the cycle other than to force quit Bridge (no "escape" if you will).

Oh and by the way if I attempt to modify the metadata in the search results window instead of the actual folder, more often than not I'll get the error message far more frequently and across more images in the selected group.

The problem has occurred

with various file formats (but typically with JPG since those make up the bulk of our library)
with few if any additional programs open (no pattern noticed)

I've noticed this on two benchmark (fully indexed) Macs:

a desktop running Leopard 10.5.8 and
a laptop running SNow Leopard 10.6.8
no, I haven't tried tested to see whether it occurs on a PC

Adobe Bridge and an image library - a case study

2011-08-24T08:05:00.000-04:00

Every so often I get pinged with an email from someone seeking answers to one of life’s greatest puzzles: “How can Adobe Bridge help me build and maintain a large image library?” (Where’s Einstein or Darwin when you really need them, eh?)

Such queries always come from individuals who are serious, determined and totally perplexed by the task facing them: creating and maintaining a large photo library on the cheap. And such was the case with H____. With her permission I post our email conversation here, as a way of sharing her rather daunting predicament with those of you quite likely facing the same set of concerns. I should say that subsequently we had a long phone conversation that explored several follow-up points in greater depth.

“I have avidly been following your blog,” she wrote last week, “in which you describe the way in which you detail arranging a shared library via Adobe Bridge. I am doing a similar thing, but on a smaller scale and am reaching out to you for some guidance. I have a pretty good idea of what I am doing, but as I read your blog I recognized that there are certain pitfalls that I want to avoid and be prepared for - specifically with the cache and ensuring that all files maintain their metadata.”

In my follow-up email I asked six questions, to which she quickly replied:

How many individuals will be using Bridge? Bridge is going to be used by a handful of people - but with potential to be searched by more in the future. There is also the hope that people unfamiliar with Bridge or CS software would be able to search for images through spotlight (we’re all on Macs ).
What version of Bridge do you have? We are using Adobe Bridge CS5.
How many images do you have? The images right now are less than 10,000 but growing daily - I am aware of the limitations of Bridge - and at some point I am sure that a more robust and secure DAM system will be put in place - this system is to carry them over and make the workflow more manageable until then.
Do you have a keywording strategy in place? We have outlined a master keyword list. I consulted with those who have to use and search for photos daily, and their preference is simplicity and less is more - it will be imported into Bridge and modified as needed - however in testing it has proven to be a bit conflicting. I am in the midst of figuring that out - also the "Bridge Search" in the upper right hand corner is letting me down as it is not invoking hierarchy and will only allow a one-word search.
Is there an IT dept involved? IT is not involved....
Do you have a metadata gatekeeping policy? The gatekeeping policy will be more solid as the system comes to fruition - but in general only the people sourcing and dealing with images daily would be able to make adjustments- right now that is only 2 or 3 people.

Use these questions and compare your answers to the ones above.

As a postscript, I should note that one of the really crucial issues in this particular exchange concerns question no. 4: I wish that Adobe would remove that little search box in the upper right corner of the UI. It looks so much like the Mac finder and is too tempting to use. Bridge’s real strength lies in its incredibly robust search features accessed from “Edit>Find” from the main menu or “Command/Control+F” from the keyboard.

Otherwise, H____ is right on track. She has a solid plan in place, a good process in motion and a firm grasp of the strengths and weaknesses of Adobe Bridge.

Do you?

"Bridge encountered a problem. . . "

2011-07-15T10:17:00.000-04:00

The moment we've all dreaded has arrived this morning. I turned on my computer, launched Bridge and straightaway saw this on my screen:

"Bridge encountered a problem and is unable to read the cache. Please try purging the central cache in Cache Preferences to correct the situation."

Before taking any action, however, I wanted to review my cache size: (User>Library>Cache>Adobe>BridgeCS4). I soon discovered that it consumed 44 gigabytes of space and contained slightly more than 364,000 items. Since the maximum number of items allowed is 500,000, that didn't seem too extreme. However, I did notice that there were more than 1200 cached folders in the 256 thumb folder but more than 1300 folders in the 1024 preview folder. (Even though the image library contains only a fraction of that number of folders, I use Bridge for moving files/folders around and prepping images for their eventual migration to the photo library.)

The difference between the two numbers seemed a bit odd since both folders should be the exact same size. I wonder if the cache crashed simply because of the number of folders of cached items.

Whatever the root cause, this event reminded me of the importance of tracking Bridge's cache size -- and it would probably be wise to occasionally run the Optimize Cache in Preferences as well:

Bridge>Preferences>Cache>Optimize Cache.

Have you experienced similar problems?

Expression Media 2 now Media Pro 1 and Photoshop User Trashes Bridge

2011-07-07T09:41:00.000-04:00

Expression Media 2 is gone, replaced by a totally redesigned program called Media Pro 1 -- and with it any support for the older program as well. Phase One, who purchased EM2 from Microsoft last year, is selling an upgrade to the photo cataloging program for $59 for EM2 users ($69 for iView users). There can little doubt now that the "new" program is designed to integrate with the company's powerful Capture One RAW converter and image editing tool. A good deal for Phase One users and certainly a smart move from a corporate perspective to be sure -- but what about the rest of us?

I suspect future versions will quietly integrate into the Capture One system, eventually serving as their version of Adobe's Bridge product (but catalog-based, not browser-based). It just makes sense, after all. But if you don't use the entire package, well. . . .

Any thoughts?

So, the alternatives to Bridge get fewer and fewer.

And to top it off, in the latest issue of Photoshop User magazine (published by the National Association of Photoshop Professionals), under "NAPP Community," is a short note pointing the reader to www.photoshopuser.com where they will find "100 Ways Adobe Lightroom Kicks Bridge A$$ for Photographers." Think I'm joking? Check it out, with video tutorials no less.

Where is this leading, I wonder?

Using Adobe Lightroom 2 to catalog our library: backstory

2011-05-13T15:44:00.001-04:00

While we have no immediate plans to migrate away from using Adobe Bridge CS4 to manage and maintain our image library, as I've noted in an earlier post we must be prepared for that eventuality. Bridge is not and has never been designed to allow easy access to such an enormous image library. That is has worked so far is a testament to the possibilities under the program (hint, hint Adobe) and to the willingness of our designers and writers to stay on top of reindexing their cache folders so that they may effectively search the image library.

OK, so why Lightroom? As I have said earlier, I tested Expression Media 2 last year and found it a very nice interface but have serious concerns about its future. Extensis Portfolio is too rigidly structured and allows little flexibility: one user, three-user or enterprise-level configurations. I have experienced problems with their importing metadata from Adobe as well.

So, I tested importing our library into Lightroom 2 (1) to give me a complete visual record of what we have in the image library, (2) to allow me to work offline on tagging modifying image metadata and (3) to test whether a catalog-based system would work for us.

I should also say that setting permissions is, for us, the key selling point in any program. Working with our IT department we created a two-tiered permissions system for our present library: myself and three others on the team have admin access to the library, that is we can add, delete and modify files and metadata; everyone else who has access to the system can only read the files and in order to manipulate images must copy the files to their own machine.

Whether we can maintain the dual level of access to the library with a catalog-based system like we presently have with Bridge remains to be seen and tested.

Another consideration to bear in mind is that Lightroom 2 cannot import CMYK files -- but this problem has, I'm informed, been resolved in Lightroom 3. I'll soon be able to confirm this since I'm planning to upgrade to LR3 this next week.

Confusion at Phase One about Expression Media 2?

2011-04-29T08:35:00.000-04:00

I just posted this on Peter Krough's DAM forum:

I had a disturbing conversation with one of the sales people at Phase One yesterday regarding EM2.

Backstory: I had called earlier in the day and left a voicemail at their generic sales number in the US explaining that i was looking for updated information on the future of EM2. I explained I was the digital photo librarian for a large university in New England and that we had been using Bridge CS4 for nearly two years to archive and share our large image library (140k+ photos among 18 workstations) and I felt the time was running out on using Bridge. After researching catalog software -- and spending no little amount of time with the DAM Book and here on the various fora -- I had tested EM2 on my own image archive last year and found it a very impressive tool indeed.

Unfortunately, the person from Phase One who called me back left me with the distinct impression that there is uncertainty underlying the future of the software. I had heard from an acquaintance here on my team that he suspected they were going to integrate EM2 into their Capture One software system -- which does make some sense I grant you.

Anyway, the fellow who called me -- horrible connection so I never did get his name right -- I asked if any future upgrade was planned and if so would it be free to existing users. At first he said, "The upgrade was supposed to have already happened," but then he backpedaled right away and said it was going to happen soon, and then probably pretty soon. . . I asked if it would be free to existing users and he said there would be a fee charged then right away he said it might be free but there would perhaps be some kind of charge. I asked about new features in the "upgrade" and he finally admitted that he didn't really know anything about the future of the product and very little about the product itself.

Finally, I inquired about notification for updates and he said "check back on the website from time-to-time."

Well, you get the picture.

None of this was very reassuring about the future of EM2 as a standalone and certainly not for multiple users.

Lightroom Collections: the Big Drawback

2011-04-24T09:38:00.003-04:00

Before discussing the nuts and bolts of using Lightroom 2 to catalog our photo library, I do want to mention one cautionary note about "collections."

While the ability to create collections or smart collections or "nested groupings" (a concept developed by Peter Krough in his superb DAM Book) is one of the most valuable features of Lightroom, sadly they cannot be shared between and among multiple users, not yet at any rate.

The important thing is that, as I understand it, catalogs can be shared among different users, and that's something we'll look into more closely in future postings.

A very brief review of cataloging software

2011-04-21T15:38:00.001-04:00

No matter how well Bridge works right now, at some point it will no longer do what we want and expect it to do -- of course, it shouldn't be doing it now but it does. And for that we should be thankful.

But someday the image library will have to migrate to a program specifically designed to manage a large collection of photos, probably a catalog-based, database software program that focuses on organizing and cataloging images and digital assets.

Adobe Lightroom, Apple's Aperture (Mac only), Expressions Media (Phase One) and Extensis Portfolio are four of the more well-known programs that also allow non-destructive image editing and offline workflow as well.

I should mention that hybrid programs such as Apple's iPhoto and Photoshop Elements both have cataloging and image adjustment features. However, iPhoto is Mac only and neither were really designed to handle the demands of large image libraries. iPhoto also lacks the more (much more) robust tagging, search and editing features required for anything other than the most basic of image collections.

For those of us in search of the holy grail of photo archiving, finding a resource that compares the wide variety of tools is scarce indeed. Fortunately, there is an excellent, albeit dated source on the Impulse Adventure website. There you can find a very helpful table comparing the various large- and small-scale programs. (You can also cut and paste this URL: http://www.impulseadventure.com/photo/flow-catalog-compare.html.)

For enterprise level collections (50k images on up) you would probably do well to consider cross-platform systems with robust cataloging features:

All have trial versions with varying restrictions. I did not include Canton's Cumulus or Extensis Portfolio Server 9 since they apply to Workgroup and Enterprise levels and have an entirely different pricing structure (read: expensive).

Of course, licensing for large numbers of users will drive the costs up no matter which catalog program you settle on.

Anyway, last year I tested Expression Media 2 and Portfolio 8.5 (single user) products. My primary criterion was discovering how many image files could one catalog handle before it slowed to a crawl or simply stopped working altogether. Our unique situation requires that users in our creative group be able to search as many images as quickly as possible. It's pointless to create 10, or 30 or 50 or more catalogs since searching requires searching across ALL images, and not just selected catalogs. And searching across catalogs is not possible.

That's the challenge.

I spent some time with Expression Media 2 (before it was sold to Phase One) and found its features robust and catalogs responsive. I liked it's easy to learn and easy to use interface. Cataloging was not a problem and searching within catalogs seemed to work fine. Please note I only catalogued a fraction of our image library, however. The process at the time was simply too tedious and time-consuming.

Portfolio 8.5 also has a nice interface but I found the cataloging of our large library incredibly slow and the catalogs it did produce were often unresponsive in searching. In earlier tests with Portfolio I was disappointed in the program's handling of xmp metadata, particularly keywords created in Adobe programs.

I have to admit that my tests were by no means systematic and I never did catalog the entire library so your experience may be different.

I am presently finishing cataloging our entire library using Adobe Lightroom 2 and my next series of posts will focus on the ongoing lessons from that experience.

If you have any questions or comments, don't hesitate to contact me: steve at steve soper dot com.

Have a great spring.

Smart Collections won't help reindexing

2011-04-08T15:58:00.000-04:00

If you have a large photo library and are sharing it from a central server/hard drive among other creative team members (and why else would you be here, right?) then you already know what a hassle it is to continually and constantly have to reindex your images.

In our case we have a fairly simple folder hierarchy of (right now) 61 folders of images, each containing between 1-3k image files. But new metadata is added frequently to images and so not a week goes by when at least several folders have to be reindexed in order for each machine to be able to effectively and accurately search the entire library. But reindexing is time-consuming and is affected by the variety of workflows within the department. So, naturally this results is a fairly long process for some team members.

As a consequence, I'm always on the lookout for some workaround that might expedite the reindexing process and thought I had struck pay dirt with Smart Collections (SC).

Here's what happened:

Last week, for no particular reason, the question popped into my head that since SCs seemed smart enough to update itself automatically when an image with specific search criteria was added to the library, did it do this on its own without any further attention from my part? The short answer, for you spoiler fans, is no.

Anyway, my first thought (prayer really) when working with a SC the other day was, "Hey, maybe I can use this as a workaround for continually reindexing!" I ran a quick test by creating a new smart collection, then added an image to the library with the same search criteria and went back to the SC to see if it updated automatically.

No such luck.

I had to go in and reindex the folder where the test image resided and then sure it popped up just fine in the SC.

Two other rather unpleasant side notes: (1) They don't like lots of photos -- my SCs take several minutes to load each and every time I launch it. And (2) when going from one to another (with large number of files in each) and back again the SC selected always takes a long time to load, leading me to believe that the SCs are not indexed of course and wondering how/where Bridge stores these beasts.

Ciao for now

Using Collections to Manage Search Results in Bridge CS4

2011-04-04T09:51:00.000-04:00

Using Bridge CS4 as the linchpin in our image library development has certainly made it much easier to both find and track specific images among more than 140,000 photos. But with our robust search and keywording strategy, searching can often produce many dozens or even hundreds (even thousands) of images.

The easiest way to manage such large searches -- particularly when you find yourself performing the same search again and again, is to create a collection out of the search results. And to make things easier, you can create a "smart" collection that will automatically update your collection when new images with specific metadata are added to the library.

To create a collection after you perform your search, select all the images you wish to use in the new collection.

Go to the collections panel and click either the "New Collection" or "New Smart Collection" icon at the bottom of the panel, give it a name and voila! That's it!

If you created a smart collection, each time an image or images are added to the library with the search criteria you used that image or those images will automatically be added to your collection.

Please note two important things:

collections cannot be shared
you must be connected to the image source to view the images in your collection (you cannot work offline)

Take care and good luck!

Image cataloging software: the browser approach

2011-03-30T05:52:00.002-04:00

There are few low-cost database digital asset management systems available today, and with the growing trend toward cloud computing and storage that number is likely to decrease in the years to come. Extensis Portfolio 8.5 (standalone), Adobe Lightroom 3, Apple Aperture 3 and Phase One EM2 are the only serious reasonably-priced DAM options available. But even those programs can become costly when you starting adding up the licensing fees for multiple users.

If you need to organize your organizations image collection and can't afford an enterprise-level digital asset management system or a catalog-based (i.e., database) program your best bet is a browser-driven program.

Perhaps the best known browser program is Adobe Bridge CS4 that ships with nearly all Adobe image editing and suite programs. Easy to set up and easy to use, Bridge is in some ways a more sophisticated "Finder" (for the Mac).

A stand-alone program, Bridge also possesses a very robust set of organizational tools. In fact, my browser of choice for the Johnson & Wales University image library is Bridge CS4. But Bridge is not, as we discussed in a previous entry, a cataloging program, and as a result has several important drawbacks, particularly non-accessibility offline and the need to continually update the local cache.

Bridge is ideal primarily for its ease of use, ubiquitous nature and of course cost (free). But it is, really, only a stopgap method for any large image collection. If you're using Bridge (like we are) you must start planning for the next phase in managing your image library. Given the nature of software Bridge will eventually reach its breaking point -- you need to be prepared for that eventuality.

Next: catalog or database software for image archiving.

Microsoft drops Expression Media 2 and Phase One picks it up

2011-03-21T15:55:00.001-04:00

Just in case you didn't get the word last year:

On May 25, 2010, Microsoft announced that Phase One had acquired Expression Media 2 (EM2); as of August 25 Phase One took full control of customer support for the product.

Phase One is widely known for their high-end digital camera systems, digital backs and digital photo software and their acquisition of EM2 provides them with a robust and competent digital asset management program.

As of this writing, Expression Media 2 upgrade is selling on Amazon for a little over 80 bucks and the full product is available on the Phase One website for $199 (Windows and Mac versions available).

Next: I'll talk a bit about the handful of low-cost DAM programs available today.

Tweaking Photoshop to Save your Metadata

2011-03-09T15:52:00.000-05:00

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

2010-11-30T11:41:00.000-05:00

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?

2010-11-24T11:22:00.002-05:00

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

2010-11-19T12:06:00.000-05:00

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

2010-10-19T11:10:00.000-04:00

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

2010-10-12T11:06:00.000-04:00

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 onlin e.

Adding Metadata - bugs and glitches

2010-10-01T16:38:00.000-04:00

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

2010-09-29T13:59:00.001-04:00

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

2010-08-30T10:48:00.000-04:00

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

2010-04-05T10:23:00.000-04:00

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.

Julieanne Kost on using Bridge to sweeten your workflow

2010-03-28T13:51:00.003-04:00

Should you migrate from Adobe Bridge to a Digital Asset Management (DAM) Program?

2010-03-24T13:40:00.000-04:00

By now most of you know the difference between a browser asset manager ("organizer" would be more accurate) and a catalog asset manager. A browser program such as Bridge is inexpensive and generally easy to use. Search features in Bridge are robust and seem to become even more so with each successive iteration of the program.

But there are serious limitations to a browser program:

Each user must fully index and continue reindexing their Bridge cache locally, and the larger the library the larger each machine’s cache. For example, the cache for JWU’s image library runs to more than 24 gigs -- and that's on each and every user's machine.

After months of fruitless searching the message boards at Adobe and the Internet generally, it seems safe to say that no one really knows exactly where or when Bridge’s cache limit would be reached. Or what would occur when that limit is crossed.

According to Adobe’s user guide for Version Cue and Bridge (May 2009), the cache can contain up to 500,000 items (or properties), although it is unclear what exactly constitutes an “item” – is it all files in the cache, including sidecar files? Does this number include the previews and thumbs, thus cutting the number of images by half?

Finally, what happens when the limit is reached? According to the user guide the oldest items will be removed to make way for the new – is there a message informing the user of this happening? What will happen to the indexing and reindexing process?

Obviously, sharing the library to more than a dozen or so trained users is a very difficult proposition.

Additionally, with a browser you cannot work offline but must be directly connected to the original image source.

If you are working with a a few thousand images shared by only a handful of users such concerns would most likely not be troubling -- particularly if your user-base and image-base would not grow appreciably in the future.

If, on the other hand, your user-base is likely to increase, or if your library has tens of thousands of images and will probably increase by thousands more each year, then an alternative approach to sharing and using a central image library must be given serious consideration.

One obvious choice is, of course, a mature digital asset management (DAM) system.

There are two basic types of DAM systems:

1. Software as a service (SaaS), also known as “hosted provider,” “cloud computing” or “Application Service Providers” (ASPs). All hardware and software reside on the site of the SaaS provider and access is granted through a client branded login page at a customer specific URL. Examples would include Honeycomb, North Plains, OpenText, and DigitalAssetManagement.

2. Installed software. Provides application software and various hardware components, but internal IT typically installs and supports the system in conjunction with the software provider or a third-party implementation team. One example: Cumulus by Canto

These systems have their relative strengths and weaknesses to be sure. The crucial thing to know is that both types of DAM provide incredibly robust features that allow digital assets to be widely shared, distributed and modified by large numbers of users in just about any location.

But there is a price to be paid, literally.

Unless your organization has budgeted thousands of dollars for an enterprise strength asset management system, you'll probably want to take a long hard look at a catalog program such as Expression media from Microsoft.

Next, catalog programs.

Creating a Contact sheet or Web Gallery in Bridge

2010-03-17T11:42:00.005-04:00

Photoshop evangelist Julieanne Kost of AdobeTV.com walks us through the new output features found in the output module in Bridge CS4. That's right, the old "Contact Sheet" command in Photoshop is gone, replaced by the incredibly user-friendly "Create a pdf" feature that allows quick and easy way to share a collection of images with a client.

Questions, comments or suggestions? Feel free to contact me: steve.soper@jwu.edu

Working with Metadata and Keywords in Bridge CS4

2010-03-16T11:35:00.001-04:00

Questions, comments or suggestions? Feel free to contact me: steve.soper@jwu.edu

Chris Orwig introduces the new interface for Bridge CS4

2010-03-15T07:19:00.001-04:00

Chris introduces the interface to Adobe Bridge and how to use the review mode to quickly scan through a large selection of images.

Questions, comments or suggestions? Feel free to contact me: steve.soper@jwu.edu

Introducing Adobe Bridge CS4

2010-03-12T11:38:00.001-05:00

Questions, comments or suggestions? Feel free to contact me: steve.soper@jwu.edu

Two concerns in using Bridge CS4 to maintain a central image library

2010-03-11T11:14:00.001-05:00

Using Bridge CS 4 as a tool for creating, maintaining and accessing a large central image library has worked for our organization. After much testing in the summer of 2009 and continual testing and updating of our search and keywording strategies the library remains stronger than ever.

However, there are two ongoing concerns that one should be aware of: exactly what is the top end limit for the cache and what will happen when that limit is reached.

It is widely known that you can adjust the number of "items" in Bridge's cache preferences from 10k to 500k. But exactly what does Adobe mean by an "item"?

Elsewhere they use the word "record" but generally the word item seems to be most favored. For example, is a RAW image file and its sidecar metadata file considered two items? Is each thumbnail and each preview a separate item?

If the answer is yes to both questions, then it is safe to assume that one camera RAW image could in fact be read by Bridge as four distinct items. It wouldn't take Bridge long to reach the maximum threshold of 500k.

Second, exactly what happens when Bridge reaches its maximum number of items?

According to Adobe's user guide (May 2009) for Bridge and Version Cue, "If the cache is near the defined limit (500,000 records) or the volume that contains the cache is too full, older cached items are removed when you exit Adobe Bridge."

Here, again, we are in murky waters. Note the use of both the maximum number of records or if "the cache is too full." Exactly what does the latter mean and how does it differ from the former?

I have yet to discover the answers to either question -- perhaps none exist, at least not an answer that would cover any and all possibilities.

Any ideas, comments or questions, please feel free to contact me: steve.soper@jwu.edu

Using Bridge CS4 as a Content Management System - video

2010-03-07T08:21:00.000-05:00

Update on using Adobe Bridge to access a Central Image Library

2010-02-02T06:42:00.003-05:00

It's been several months now since the central image library went live. The images in the library are searchable by more than a dozen writers and designers in our organization and I can report that so far, so good.

We now have probably 120,000 images in the library and I add more every week. This requires a cache in Bridge of more than 24 gigabytes but we haven't noticed any general inability to find images in any given search. Seaching can be slow at times, depending on the complexity of the criteria selected and the number of images returned in the search results.

Remember, we are on new ground here: Adobe claims there is a limit of around "500,000" items but this is rather vague. For example, exactly what constitutes an "item"? Does that refer to each and every file type (such as sidecar xmp files for camera raw images)? How does one monitor those numbers? Also, how much space does the cache need to consume before the machine begins to slow down altogether? We just don't know.

The one singular challenge -- and it is important, believe me -- is to ensure that everyone's machine is up-t0-date in its indexing. What I mean is, that anytime a modification is made to a file in a given folder in the central library -- say metadata is added as information about a selection of images comes to light -- then that folder must be re-indexed by each machine in order for those images to be "searchable."

Also, I would suggest routine purging and rebuilding of the caches. Ideally, one might want to physically go in and remove the old cache and start fresh every few months or so. But this is not always feasible.

Central image library update

2009-10-19T06:33:00.002-04:00

Aside from a few minor glitches the new central image library using Bridge seems to work. I try and add anywhere from 500-2000 images every week or so -- and my efforts at being systematic has worked so far. It's just a matter of communicating the new uploads and also any old folders that need "re-indexing."

And speaking of re-indexing, based on what I've seen so far, I urge each person in our department to develop a plan to continually re-index the library -- and that seems to have removed a few obstacles to fully successful searches so far.

We have seven designers, and four writers accessing and searching the library.

The one thing that will take time is for each person to develop his or her own searching strategy -- in other words, what variation of search criteria works best for any given search. This continues to evolve since we will undoubtedly be adding to and modifying the keyword list over the coming months.

Progress on Sharing Images in a Central Library using Bridge

2009-09-13T10:29:00.003-04:00

So far, so good pretty much sums it up. I've held two training sessions with one last one to be given this coming Tuesday -- by then everyone in my client's creative department will have at least had the introductory training session. So far three designers are online and have fully indexed the central library on their respective copies of Bridge; they seem to be searching across the library with no problems.

The remainder of the group's design teams, for both print and web will be indexed this week and searching the library.

I just added a new folder of more than 2k images this last Friday. After informing those designers who had already finished indexing they just went in and a few moments later had indexed the new set of image files -- again, no problem. So adding new folders of image files seems to present little if any challenge.

The next month or so will see virtually everyone in the creative services with access to the library. The next challenge will be fine tuning the keyword strategy.

Also, another ongoing set of issues surrounds the varying level of competency with computers, the specific OS and degrees of competence in picking up new software tools.

Important update on image file sharing!

2009-09-02T06:24:00.003-04:00

We are presently moving ahead with opening access to the new central image library to our designers and other members of the group.

My initial idea about copying the cache files to each machine' Bridge program is now dubious. I noticed on my second testing machine (a Mac Pro tower) that while on the face of it copying the cache files did indeed seem to expedite the process of indexing the many folders in the library, I observed that Bridge was creating a duplicate folder in both the 256 and 1024 (thumb and preview folders respectively) and also apparently duplicating the BridgeStor files as well.

Naturally this would double the already huge cache size.

Perhaps it was a phenomenon unique to that particular machine but at this point I don't have the time -- or the inclination -- to keep testing to see whether we can in fact share cache files.

We do know that once each member of the group accesses the library they can begin the process of indexing via their own machine/Bridge and ultimately be ready to search the library.

So, what I've opted to do is to simply provide the path to the new central library and then have each designer begin indexing the folders locally. This way it should keep the each person's cache clean -- or at least as clean as possible.

Sharing image files on a network using Adobe Bridge

2009-08-22T15:02:00.001-04:00

I believe that using Bridge to share image files on a network is possible. In fact, we're just about ready to golive with our image library on a network -- using Bridge as the browser.

Here's what I've discovered over the past several weeks of testing:

Trying to share a centralized cache is quite out of the question. But, as it turns out, it appears that one share cache files across multiple computers; providing these are Macs using CS4 of course. This is not the best alternative but short of going with a cataloging system -- not always an choice for some organizations -- this is perhaps the only option available.

2. I indexed our image library on my laptop, which took the better part of a day. Organizationally it consists of 56 folders, containing some 104,000 images for more than 434 gigabytes of space.

3. I then copied the cache (and all files) to an external hard drive.
What I copied was on the following path: user>library>caches>Adobe?Bridge CS4>Cache

4. I then went to a second computer -- networked to connect to the central image library drive -- and before launching Bridge I deleted the old cache file, and then copied the new cache file to the second computer. I then launched Bridge, navigated to the image library in the folders panel, clicked on several folders. One-by-one all the thumbs and previews loaded quickly and the metadata was right there as well, allowing for fairly quick and easy searching. And for us "searchability" is the KEY to having a central image library

5. To add mages -- and here's where ity gets a bit klunky -- I intend to add subsequent folders as new images come in to be cataloged. I will then inform the designers that a new folder has been uloaded to the library -- they already have the path -- and that they will need to index that folder to make the images "searchable.

Hopefully this will work on all our designers' machines as well. I'll know more by the end of next week.

BUT, there are a couple of things to consider:

1. Once a folder is indexed it cannot be moved nor can any of the files inside that folder be moved or manipulated in any way. For example, if you returned to a file to add additional metadata, then each user would have to reindex that particular folder on their local copy of Bridge. Having said that, it's not terribly difficult or challenging. In our case, since the image library is permanent once these folders are indexed and "accessed" on each machine that's it. It's the initial indexing that can take so much time.

2. Make sure that permissions are in place before you golive. In our situation just me and my director have read/write permissions. All others have read only. This allows anyone to pull an image out of the library and use it as they see fit once the copy is on their desktop of course. They simply cannot make any changes, additions or alternations in the existing folders and files ON THE LIBRARY DRIVE.

That's it for the moment.

Stay tuned.

Using Bridge to share an Image Library

2009-07-25T06:57:00.008-04:00

To recap the situation.

The goal is to share a large and growing library of more than 107,000 images among a small group of designers and editors.

I spent some three months creating the central library of some 434 gigabytes on a hard drive, which was then moved to a 2-terabyte mirrored RAID drive. It will remain there until the client migrates to a full-blown digital asset management system in 6 months or a year.

All the images are tagged with metadata and properly keyworded and can be readily and easily accessed by multiple users.

So what's the challenge now?

"Searchbility." That is, can multiple users search the library using the existing metadata and our keywording strategy.

The short answer is a (very) qualified "yes."

Very serious tip: indexing is the key to searchability and the cache is the key to indexing.

Recent tests have shown us that sharing one large central cache that would be regularly updated by the image librarian is NOT workable. Cache structures differ across platforms and across versions of Bridge. And it seems that Bridge enjoys the best performance with a local cache readily at hand.

The first time Bridge access a folder of images it creates the necessary metadata, thumbs and previews and stores all this information in the cache for future use. That way the next time you go to the folder, Bridge can easily find the metadata and there is little waiting around for the thumbs to load and they metadata is readily available to allow searching through the folder. If all the folders in a given "superfolder" have been indexed, then Bridge can quickly search across all the subfolders.

The root problem lies with Adobe’s indexing feature. Or rather it lies with Bridge trying to index not only hundreds but thousands (or tens of thousands) of image files at one time.

Now match this with existing folder structures. In our case I had originally created dozens of folders and subfolders. We had literally thousands of duplicate images that needed to be weeded out in the early phases of creating the library; and in Bridge it was not possible to move thousands of image files around without putting stress on the software.

With an image library of 10,000 images, for example, indexing does not present much a challenge.

But with tens of thousands of image files Bridge’s index ability is really put to the test.

Through a series of tests ran during the past week it became clear that Bridge's indexing threshold is somewhere between 2500 and 8000 images. Our fastest machines running the latest version of Bridge could simply not index 8250 images files; it ground to a halt at about 1400 -/+ remaining. Without more systematic testing we will never know where that exact threshold lies -- and may never know considering the variations that exist across platforms and versions.

Conclusion no. 1: Do NOT expect Bridge to index one large superfolder of images.

So that means you have to create some number of folders in the library. In our case the existing library has 31 top-level folders with probably three times as many subfolders.

But in ordeer to index all the images and metadata each user has to manually go in and index each folder/sub- and sub-sub-folder.

Not reasonable.

Conclusion no. 2: Create a new folder structure that is manageable and workable for the intermediate term.

But wait a minute, how does this solve the indexing issue?

For one thing it helps to streamline the existing folders so they are more easily indexable by each user. But – and here’s the good part. . .

Very, Very Important: Remember when we tried to share one central cache among multiple machines? We learned that didn't work, and in fact created quite an indexing mess. But you can share cache files across machines, at least among Macs at any rate, and this will make indexing much easier and faster for multiple users.

This is how it works:

1. Using the "main library cache" on the primary (image librarian's) machine, all the library files are indexed on this one machine, folder by folder.

2. Once indexed, the cache is copied over to a second machine.

3. Launch Bridge and navigate to a (previously unaccessed/unindexed) folder of images and the thumbs will load almost instantly and the metadata is readily available for searching.

4. Repeat on other machines.

Note: this has only been tested on Macs and only on CS4. I tried two sets of folders, one with 634 image files and another with 1500 files. The first folder of thumbs and metadata loaded almost at once; the second folder took a few seconds longer loading the thumbs.

While this does not completely resolve the indexing problem, it does appear to eliminate the need for each new machine to have to create all the thumbs, previews and metadata files from scratch. And the other users do NOT have to manually access each folder the first time to index all those files. That's a step forward for us.

But what happens when you add images to the library?

Our plan is simply to add new folders -- which we would have to do anyway from the librarian's end -- and then have the other users index those new folders regularly. It's another byte to add to the workflow but indexing smaller number of files (say a few hundred or so every week) is manageable.

Caution: Please bear in mind that this recommendation is still in the preliminary phase. We'll know if there are any serious limitations in the next next week or so as we try this for real life across several machines.

And we must always, always remember that Bridge is really not designed for any of what we are trying to do.

Thanks to the people on the Adobe message boards for bouncing ideas back and forth, and especially to Ramon Castaneda for clarifying the whole cache business.

And thanks to my colleague Mark Baker. Mark took an incredible amount of time away from his own pressing projects to help me work through these issues. He helped me take a more systematic approach to the problems and in particular to the testing. Thanks Mark.

Test 2: File handling

2009-07-22T06:33:00.000-04:00

OK, so we ruled out any possibility of multiple machines sharing a central cache. Next, we wanted to test how Bridge handled a very large number of files within one folder.

I created a test “Images” folder of 8250 image files, taking up 45+ gigabytes of space.

Machine 1 (PC/Bridge CS3)

Machine 2 (Mac/CS3)

Machine 4 (Mac tower/CS4)

Machine 4 (Mac lap/CS4)

Copying files within drive –

Machine 4. Copy files within library drive – 837 files/4.5 gigs:

Using Bridge copy/rename: “could not process some files” – failed to copy/rename

Using Bridge: “could not process some files” – failed to copy

Using Mac finder (drag and drop): 17 mins

Machine 1. Copy files within library drive -- smaller test of 202 files/800mb:

Using Bridge copy/rename: 17 mins

Using “window to window”: 4 mins

Conclusion: Move rather than copy files.

Performance within drive -

Machine 1. Navigated to image library and accessed “Images” folder – machine hung up at 40% indexing (-/+ 20 minutes) and stopped after 62 mins.

Clicked off onto another folder in library – which worked fine and loaded previews and metadata – and then clicked back on “Images” stalled again/hung up entire program after that.

Machine 2. Navigated to “Images” folder and Bridge loaded after 45 mins Bridge loaded only two image files with thumbs and metadata, all other previews remained blank. Progress wheel stopped but no files loaded.

Machine 1. Attempted to purge and then rebuild cache with the same result as Machine 2: loaded two images with thumbs and metadata but then stopped indexing.

Machine 3. Navigated to “Images” folder and it completed indexing in 15 mins – keyword indexing complete only by manually scrolling down through the image files.

Machine 4. Navigated to “Images” folder and it completed indexing in 18 mins – keyword indexing complete only by manually scrolling down through the image files.

Note: CS4 Preferences allow for adjustment of number of items stored in a given cache – CS3 on the PC does not -- further confusion here since one Mac/CS3 had a slider allowing for "smaller" to "larger" in the cache prefs but another Mac/CS# did NOT.

Conclusion: Significant disparity between CS3 and CS4 in accessing one folder with large number of image files.

Additionally, both late model Mac CS4 machines experienced a significant slow down for adding existing keywords/metadata to the last 1400 or so files of the "superfolder" of 8250 files.

Test 1: Accessibility

2009-07-19T06:22:00.002-04:00

In our search to learn what Bridge's limitations are as a browser, I ran a series of tests recently to see how the program handled our new central library. The new drive, a 2-terabyte mirrored RAID system presently holds a 434-gigabyte library of more than 107,000 image files.

First I tested Bridge's ability to access files using a centralized cache. Based on speculation in our office as well as discussions found online, we posted a central cache in the library itself and pointed the various machines to that one location.

1. On PC/CS3 I created a test image file, tagged it with a unique keyword and moved it into the “Working” folder on the library drive.

2. Placed cursor at root library level and ran search for unique keyword on new image: NO RESULTS. (Expected.)

3. Returned to “Working” folder to “index” the new image.

4. Back to top level and ran search again: NO RESULTS. (Unexpected.)

5. Back to “Working” folder and selected test image – noted metadata/keywords visible in the metadata panel in Bridge.

6. Back to top level and run search: NO RESULTS.

7. Back to “Working” and moved test file to “Hospitality” folder.

8. Back to top and run search: NO RESULTS. (Expected.)

9. Return to “Hospitality” and select image.

10. Run search at top level: NO RESULTS. (Unexpected.)

11. Run search of “Hospitality” keyword: NO RESULTS.

12. Return to “Hospitality” folder and attempted search: NO RESULTS.

13. Various search criteria attempts all produce NO RESULTS.

Repeated test on a Mac/CS3 and with a second PC/CS3 with the same results.

Attempted to repeat test on Mac laptop/CS4 – Bridge produced an error message stating that it could not see the cache it was originally pointed to and wanted to recreate a new LOCAL cache folder.

(Light bulb.)

1. Quit Bridge and disconnected from library drive.

2. Re-launched Bridge CS4 and let it build a new local cache.

3. Reconnected to library, and let it re-index a folder: it opened the thumbs almost immediately and indexed a 2.6 gig file of 564 images in 3-5 secs. I immediately commenced a search and it found the desired images in 4-6 secs.

Conclusion: Centralizing the cache to be shared by different versions of Bridge is a problem.

How/why remains unclear: online forum discussions lead me to believe CS3 and CS4 create different “types” of caches. Adobe has not confirmed.

In any case since each machine would have to be indexed on its own and continue its own indexing, having a central cache seems irrelevant and the benefits (?) don’t justify the potential risks

Using Adobe Bridge to share image files across a network

2009-07-18T07:40:00.003-04:00

Over the past several weeks I have found serious limitations using Adobe Bridge for sharing a centralized library of images. In all fairness, though, Bridge is really not designed to do what we are all want it to do.

Still, like many others on this forum Bridge is the tool of choice for creating a central image library and then organizing and tagging existing and new images. After a series of meetings with the other members of the Creative Services team I began the creation and organization phases in late March, finishing in early July.

But first the basics:

1. We're running a network of a half dozen machines using both Windows and Mac operating systems some with Bridge CS3, most with CS4.

2. The image library is made up more than 107,000 image files, taking up roughly 434 gigabytes on a 2-terabyte mirrored RAID system in our IT data center. (New images are being added nearly every day.)

3. Cataloging software is not an option and a move to a full-blown server-based DAM system is projected but details remains uncertain at the moment.

Lessons learned so far:

1. Creating a large library requires some form of initial or permanent folder structure in order to move files around easily and quickly -- and to permit accurate and effective metadata tagging. Attempting to move more than a few hundred image files at a time can be a challenge for Bridge and will require the peppiest of workstations.

2. Using the primary work machine I pointed all our machines toward a centralized cache files (including the camera raw cache files) as suggested in this forum: right in the library itself, in a specially designated file. I also use this to work on collections of images before placing them in their respective library folders.

Warning! We discovered what may be a serious issue here: a day after pointing our machines to a centralized cache each copy of Bridge could see thumbnails and see the metadata but they could not search using the metadata. Even when they could search, each time a machine opened Bridge and accessed the library the thumbs would load painfully slow. This is both CS 3 and CS4 across platforms.

3. BTW, sharing master keyword lists is a breeze in CS4: just go to keywords panel and export the list to the location of your choice. It creates a .txt file (on the Mac). You can change it like any other text file and then import it right back again. Importing is equally easy: just go to Keywords panel and click on Import. Navigate to the changed keyword list and that’s it.

4. The central problem with Bridge is that each machine needs to fully index the library the first time – you can already see how long that is going to take with tens of thousands of images.

Moreover, there is no effective way to update the library from one source (for example, from the image librarian’s machine) and have all the other copies of Bridge automatically update with the new images or modified images.

Remember! Every time you move a file or modify the metadata for a file each cache on each copy of Bridge needs to be updated. One senses this could easily become a logistical nightmare.

5. Next phase is to duplicate the library and push all the files into one large folder. This should achieve two goals:

a. This should allow for easy updated of each copy of Bridge.

b. All the image files can be renamed using an agreed-upon renaming convention. (Another issue is our image files have a wide variety of file names, many using unacceptable characters (asterisks, pound signs, ampersands) and with spaces, etc.

c. Then we test this across platforms and versions of Bridge.

I should say that as a freelance digital photographer I use Adobe Lightroom 2 for my own image library; however, my present client cannot/does not want to purchase multiple licenses for such an expensive program.

I have also tested Microsoft's Expressions Media 2 and have found this to be a reliable, inexpensive handy little program for creating catalogs as well as simple web galleries to share. And the cool thing is that MS distributes a cross-platform catalog reader for free!

Issue no. 614 - filename problems

2009-07-08T06:47:00.004-04:00

If you plan to move a large number of files across platforms it might be a good idea to ensure the image files and in particular their filenames carry with them no potential problems. We are in the process of moving the entire image library from its present location on an external hard drive to a new mirrored RAID server system and the wide variety of filenames seem to cause serious slowdowns in the migration process. In fact they seem to stop it altogether.

Part of this is probably the quirkiness in migrating from the Mac to a PC. But it should also be noted that many of the filenames used -- the images come from a large number of sources -- themselves have unusual and generally unacceptable characters (pound signs, ampersands, spaces, and even tildes).

Lesson learned: clean up the filenames prior to migration.

Hardware for less than $500?

2009-07-05T11:12:00.016-04:00

So, exactly what sort of "stuff" will you need to set up a digital asset management system? And how much is it going to cost?

1. Digitized photos
2. A computer
3. Cataloging software
4. A backup strategy

If you don't have the photos digitized then you'll have to either buy a scanner or have the images put on disk.

I'll assume you already have a computer. Ideally you would want a dedicated computer station for archiving photos -- particularly for very large collections. Moving hundreds or sometimes several thousand image files around at one time can tax an older machine; especially if it's bloated with games, lots of other software etc.

Aside from the computer the biggest cost is going to come from software and the backup system used to protect your image library. (Software will be discussed in our next episode.) In the ideal world a serious backup strategy centers 2+1:

a primary and a secondary external hard drive and a disk (CD or DVD)

However, backing up to CD is time-consuming and tedious and CD-Rs hold such a small amount of data. DVD-Rs are are a step upwards, but they, too, can easily be outpaced by the growth of your library. Blu-ray is the new disk standard -- each disk can hold up to ten times the amount of information on the average DVD-R and for the moment that makes for a sensible disk component in any backup system.

But for most amateurs and many professionals, a disk component is simply not a viable alternative. For cost reasons or time-management, most will rely on the external hard drive as the basis for a backup management program.

So, where does that leave us? In simple terms:

Scanner: $150
Hard drives, two 1-terabyte drives: $350

You can certainly spend less on a scanner but consider what you're scanning for. Also, if you have lots of slides and negatives that will also narrow your selection of available scanners -- and probably increase your cost as well. You'll want the best quality digital images so I'd rather err of spending a little too much than not enough.

The same is true of hard drives. Buy new, high-quality drives and get the largest size you can afford. Believe me you'll grow into them.

External hard drives are more reliable today than ever and their cost continues to fall. My suggestion is to get the largest pair of drives you can afford. And since many drives come with backup software as part of the purchase package, that's one less cost for you. Look for drives that have as many different types of connections as possible (3 or 4 is optimum but don't settle for just a single connection type.)

Also the drive costs noted above are for single drive systems, not for RAID or multiple drive configurations. (RAID stands for "redundant array of independent disks".) If you decide to boost your backup options through using a RAID mirrored then plan to increase your costs by half again as much.

For a larger image library and with a somewhat more generous budget, consider the following configuration:

scanner: $200
hard drives (on-site), 2+2-gigabyte RAID mirror: $800
blu-ray recorder: $300
blu-ray discs: $250 (cakebox of 50)
OR
hard drives (off-site, optional), 1-terabyte: $200

To find out more about RAID systems and whether it's right for you visit Wikipedia's in-depth discussion online.

Personally, I use both LaCie or OWC hard drives. No, they don't pay me to say that -- in fact they probably aren't even paying attention. Anyway, I've used LaCie for years and never had one fail yet -- and OWC is equally reliable. I like for their size and portability. Both come bundled with good backup software: LaCie bundles Genie and Intego backup; OWC bundles NovaStar for Windows and Prosoft's Data Backup for the Mac.

For example, right now I am using a pair of 500-gigabyte OWC "On-the-Go" drives for working and primary backup and then a 1-terabyte OWC desktop drive as a secondary backup drive for a client. Eventually we'll move their library to a 2-terabyte RAID-mirror system.

You can find LaCie online at: http://www.lacie.com/us/index.htm. And OWC can be found at: http://eshop.macsales.com/

Oh, and you can research and buy LaCie drives at OWC as well.

If you're the least paranoid -- and frankly you should be -- I'd recommend spending a bit more and using a desktop and portable off-site backup system. (Say in a safety deposit box or a basement.) We'll talk more of this later when we discuss "process" but you might consider using portable drives as a secondary backup.

OK, so that's the easy part.

Next week things get a bit harder as we dive into cataloging software. We'll also talk about using metadata and later we'll get to the really hard part: workflow and process.

So you say you want to organize your photos?

2009-06-28T10:32:00.001-04:00

Organizing your digital files is daunting to be sure but if do it now and do it right you will thank yourself in years to come. Believe me, I do this for a living and can't tell you how many times I wish there had been an easy handy dandy guide to help me steer clear of so many mistakes.

Maybe some of the lessons I learned from those mistakes will help you navigate safely and easily around the world of digital asset management. I'll also provide you with some links to valuable online resources and talk about a few of the more handy print references as well.

Whether you're a serious amateur seeking to organize all those family and travel photos or a professional who has been tasked with making sense of a corporate image collection, there are three basic components to any digital asset management (DAM) program: hardware, software and process. We'll talk about these each in turn.

But before we do anything I want you to get out a piece of paper or open a text editor and jot down the answers to the following three questions:

1. Why do I want to organize my photos?
2. How much time can I spend creating my image library?
3. How much money can I spend?

If you're planning to organize a personal photo collection, the necessary tools will probably cost about $500 to set up properly. You will also have to allocate the time necessary to learn any new software as well as the time to actually do the cataloging and tagging of your photos.

A large corporate collection might cost no more than $2000 to set up but the real cost there is maintenance. Corporate entities will most likely have a full time asset manager as part of their print and editorial departments.

Naturally the digital asset managing work-flow you develop will arise out of the what suits you and your needs, not what works for me or anyone else. It's your time and your money. I just want to help you spend them both wisely and efficiently.

The rest is up to you.

Enough twaddle -- let's talk hardware!

Bear with me for a moment

2009-06-21T14:56:00.001-04:00

I'm about to get my act together here -- there's lots of information to share so stay tuned!