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.
Monday, August 30, 2010
Monday, April 5, 2010
Using DNG File conversion to maintain control over Image Library Size
Out of more than 110,000 photos in our image library nearly 8,600 are Camera RAW files (NEF, CR2, DCR, RAF primarily). Although they make up less than 8% of the total number of files, they account for more than 12% of the total space taken up on the drive (68 gigabytes out of 526 gigs of space occupied by the library).
The challenge is how to preserve the integrity and optimize the size of the library, reduce the multiple file formats and standardize the image files, while acquiring the best quality images for use over the coming years.
Camera RAW files are the obvious answer but the file space these would require prohibit our organization from using RAW files.
Adobe's DNG file format system is widely touted as achieving smaller RAW files while protecting the integrity of the image data -- unlike with jpgs.
Moreover, DNG files also combine the metadata into the image itself unlike RAW files which use the sidecar method of storing xmp information, and the problem with sidecar files is you risk loss of that data if the sidecar file becomes separated from the image file.
Recently I undertook a series of in-house tests using 30 random camera RAW images from a variety of different RAW formats. Bridge's built-in DNG converter made the process simple and easy.
Results:
Orig RAW: 30 images (238.5 mb)
DNG convert: 30 images (181.8 mb) - with no loss of information
Moreover, the DNGs open up just like a camera RAW file in PS CS4.
Several options are now available:
All contract photographers would be required to send the "keeper" RAW files on disk, and we convert to JPG for uploading to the library (thus keeping the library at a reasonable size). If a larger, more robust copy of that image is needed, the metadata in the JPG will direct the designers to the specific disk where they can find the RAW file. (Professional digital photographers shoot predominantly in Camera RAW in any event.)
Another scenario would be to request that all contract photographers convert their final images to DNG instead of jpg before sending them to us. This would require no additional steps on their part, since they convert the images to something after color correcting, reviewing, etc. And we get the added benefit of the BEST quality image. Of course, the photographer could send us the RAW files and we can convert in-house. With Adobe's PS and Bridge the process is quick and easy, and we can even add our own metadata information during the conversion process.
Lastly, the photographer could send us BOTH the RAW and JPG files, since DSLRs today are capable of shooting images in both formats at the same time. No conversion is needed -- however this does not take into account those files that were color-corrected.
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.
Sunday, March 28, 2010
Wednesday, March 24, 2010
Should you migrate from Adobe Bridge to a Digital Asset Management (DAM) Program?
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.
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.
Wednesday, March 17, 2010
Creating a Contact sheet or Web Gallery in Bridge
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
Questions, comments or suggestions? Feel free to contact me: steve.soper@jwu.edu
Tuesday, March 16, 2010
Working with Metadata and Keywords in Bridge CS4
Questions, comments or suggestions? Feel free to contact me: steve.soper@jwu.edu
Monday, March 15, 2010
Chris Orwig introduces the new interface for Bridge CS4
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
Questions, comments or suggestions? Feel free to contact me: steve.soper@jwu.edu
Subscribe to:
Posts (Atom)