Image Previews and the Cache
Image previews are now so commonplace that we don’t think about them. Even folders in Mac OS X and Windows can automatically generate thumbnail previews of images. But each preview has to be generated by something. Mac OS X and Windows can display previews because the operating systems have added the ability to read formats such as JPEG natively. Bridge has the same ability for the raw formats it supports.
Generating Image Previews and Thumbnails. Standard image formats such as JPEG already exist as RGB files, so they display quickly and easily. But as we mentioned earlier, raw is not a single format but varies by camera, so a program or operating system that wants to display a new camera’s raw format must add support for that specific format. In addition, a raw file hasn’t yet been converted to RGB, so it takes longer to display it. To speed up display of raw files and reduce the chance that the file can’t be displayed because a program doesn’t read the format, a preview image can be associated with a raw file.
An embedded preview image is saved with the file by the camera. This is how you can see the images on the LCD at the back of your camera or in a program such as Adobe Photo Downloader. The preview represents the default rendering of the camera, and depending on how you set your camera, it may not be at full resolution. Unfortunately, as soon as you make any adjustment to a raw file, the built-in preview is immediately out of date. For this reason, raw editors such as Camera Raw can generate an updated preview. Bridge does it by using the Camera Raw engine.
This all seems reasonable: You get a camera-embedded preview right away, and Bridge always retrieves the latest Camera Raw rendering so that thumbnails are kept up to date. Bridge has traditionally made it a priority to keep previews and thumbnails current, starting at import. However, there is a flaw: The time it takes to display a thumbnail, when multiplied by the hundreds of images that can be downloaded from a single shoot, slowed down many photographers, who noticed that other programs could display thumbnails faster. The reason was that the other programs used the camera-generated thumbnails for initial display, so that photographers could immediately start sorting and ranking images.
If initial display speed is a concern for you, you can make Bridge CS4 prefer the previews generated by the camera by turning on the first button on the right side of the Path bar (see Figure 5-76). It’s grouped with another button that provides options for generating updated previews. This gives you the best of both worlds: You can see camera previews for initial speed, then later have Bridge generate up-to-date previews for accuracy. If you aren’t in a rush, we recommend using Bridge-generated previews so that you’re always looking at the true current state of your images. Speed and quality are also affected by the Do Not Process Files Larger Than value in the Thumbnails pane of the Bridge Preferences dialog; lower the value to increase speed or raise the value to increase quality.
Figure 5-76 Preview controls on the Path bar
Controlling Preview Sizes. The previews you see in the Preview panel, in Full Screen Preview, or in Slide Show are generated on demand. If you’ll soon be doing a lot of work with large preview images or the loupe, you may want Bridge to generate them up front. One way to do this is to click the second icon in the group at the right of the Path bar (see Figure 5-76) and choose Generate 100% Previews so that when you view a file, Bridge generates a full-size preview at that time.
The Preview Cache. Bridge stores image previews in a cache on your computer and will seem slow when you view images for which a cache hasn’t been built yet. As you edit raw files, Bridge updates the previews so that they accurately represent all of the adjustments you’ve made.
The Bridge cache holds the image thumbnails and previews, custom sort order, and—for file types that can’t store metadata either in the file itself or in a sidecar XMP file—label and rating information. For raw files, only the thumbnails, previews, and custom sort order are stored uniquely in the Bridge cache, but since the thumbnails and previews take some time to generate, they’re pretty important. You can control how the cache works in the Cache pane of the Preferences dialog.
You can let Bridge keep its cache only in a single, central location, determined by the Location preference (see Figure 5-77), or you can have Bridge use decentralized caches, which are stored in each folder you browse with Bridge. The decentralized caches contain only the information about the items in that folder. Turn on the Automatically Export Caches to Folders When Possible check box to enable that option. To manually generate cache files for a folder, open the folder and choose Tools > Cache > Build and Export Cache.
Figure 5-77 The Cache preferences in Bridge
The only advantage offered by using a centralized cache is simplicity—you know where all your cache files are. The significant disadvantages of the centralized cache are
- If you move or rename a folder outside Bridge, the connection to the cache files is lost.
- When you burn a folder full of images to a CD or DVD, you first have to go through the extra step of exporting the cache. If you don’t, the recipient of the CD or DVD has to take the time to recache the folder, rebuilding thumbnails and previews, and any custom sort order is lost. By the way, the “When Possible” part of the Automatically Export Caches to Folders When Possible preference refers to the fact that you can’t create new cache files on a read-only volume, such as a DVD; cache updates can happen only in the Bridge centralized cache.
Using decentralized caches avoids both problems. The cache files are written directly into the folder to which they pertain and travel with the folder even when it’s renamed or moved. But note that if Bridge for some reason can’t write a decentralized cache (the volume may be read-only or mounted on a server), it writes to the central cache instead.
The only real downside to using decentralized caches is that every folder that Bridge has opened ends up with two additional files, named .BridgeCache and .BridgeCacheT (the T is for Thumbnails). By default, Bridge hides these files, but you can see them by choosing View > Show Hidden Files. In Windows, it depends on whether you’ve set your Folder Options to display hidden and system files. If all this file management makes you nervous, by all means use the centralized cache. Otherwise, it’s well worth suffering the small inconvenience to obtain the benefits of decentralized caching. (And besides, it’s often useful to be able to see the cache files so that you can check that they’re present and up to date.)
For Cache Size, we recommend the default size or larger, unless you are running very low on disk space or have a small hard disk, such as in a notebook. The Compact Cache button optimizes the cache, which can be good to do periodically. The Purge Cache button causes Bridge to rebuild thumbnails from scratch, which can help when thumbnails don’t seem to reflect the actual contents of files.
Pay Me Now or Pay Me Later. The common thread throughout the thumbnail and preview options is the trade-off between resources and responsiveness. If you go for maximum quality, turning on the options that build a large cache of thumbnails and high-resolution previews in advance, Bridge will go to work building previews as you browse folders and images. Keep in mind, though, that generating high-quality previews and thumbnails essentially generates high-quality JPEG copies of all your images; your CPU will be busy and your preview cache will fill up fast. You can run into performance problems if you are low on disk space or if you have an aging, low-end, or single-core processor that isn’t up to the task of generating those previews while you try to do other things. If you don’t have fast equipment and lots of disk space, you may have to defer high-quality rendering, keep your cache sizes small, and expect Bridge to hesitate somewhat when you ask for a high-resolution display. It all goes back to what we said in Chapter 1: For Photoshop (and Bridge), it’s worth it to have current hardware.