…and shrink that enormous Capture One catalog file
» Scroll to step-by-step instructions
One of the most pleasant surprises of going 100% Adobe-free has been the switch to Phase One’s Capture One. It has long been a favorite among pros, but I have to admit that I overlooked it at first after being seduced by the slicker marketing and shinier interfaces of some other self-described Lightroom alternatives. None of those proved to be — or show any real progress towards ever being — a complete replacement for Adobe Lightroom, at least not for many professional photographers.
Capture One Pro 11, on the other hand, is an excellent Adobe Lightroom alternative. Capture One is faster, has more powerful tools (including layers), and does not require a subscription! If only Phase One’s marketing reach matched that of Adobe’s (or Luminar’s for that matter), more photographers might learn that they’ve had a wonderful Lightroom alternative just waiting for them all along.
Update November 29, 2018
Capture One 12 is here and it’s the best pro-level Lightroom alternative on the market.
I do have one issue, however, with the configuration options of Capture One. Although it is simple enough to import images into Capture One while keeping those big RAW files on my external RAID, the preview and thumbnail images that Capture One creates can only be stored in the catalog file itself, which is actually a macOS package. This is not unlike Apple’s Photos app, and it makes sense for smaller catalogs.
However, the size of the preview files is not trivial. For a large library, the catalog file can reach many gigabytes, even while the database file itself is only a few hundred megabytes. I would much rather store those preview files on the external SSD that I reserve specifically for caches. That way I don’t waste precious space on my internal SSD, and I can exclude that drive from my various backup services. There’s not much point wasting bandwidth and storage space by constantly backing up new preview files that can always be recreated if lost, and, in my particular case, the catalog file size had surpassed the single file size limit for syncing with iCloud Drive, which is a critical part of my workflow.
I was unable to find an answer in the Capture One user forum, but I eventually, and accidentally, stumbled on a solution while testing the command. For whatever reason, Capture One creates a standalone database file when exporting a backup and separates out the preview image cache into its own directory.
It occurred to me that this database file was the same type as that found within the contents of the default catalog package, which led to the following 10-step procedure to move the cache to an external drive.
1 Find the location of the Capture One catalog file in the Finder. The default path is Pictures ▸ Capture One Catalog ▸ Capture One Catalog.cocatalog.
2 Right click on the catalog file (extension .cocatalog), which is actually a package.
3 Select . This will reveal a .cocatalogdb file, along with various directories, including Cache and possibly Adjustments. You may also see Originals if you have opted to store photos inside the catalog, although that would negate the space savings of storing the preview files in a separate location!
4 Copy the .cocatalogdb file (along with the Adjustments and Originals folders, if they exist) to the directory where you would like to keep your new database file. An easy way to do this is to select the files/directories and press Command-C. Click the back arrow in the top left corner of the Finder window to exit the package. If you want to keep your new catalog database file in the same directory as the original catalog package, just press Command-V to paste right there, or navigate to another location and paste the files there. Personally, I choose to store my Capture One Catalog in a directory that syncs with iCloud.
5 Copy just the Cache directory to the drive where you want to store all of your preview images. In my case, I keep the cache in a folder named Capture One on an external SSD.
6 Delete the Cache directory that you just copied (the one in the same folder as the .cocatalogdb file).
7 Here’s where the magic happens. Use the Terminal to create a symbolic link, also known as a symlink or soft link, in the location of the Cache folder you just deleted. This symlink will point to your external cache in a way that is transparent to Capture One. To do this, enter the following at the command line prompt, replacing the first path with the location of your external cache directory and the second path with the original location. Note the backslash escape characters before the spaces.
ln -s /Volumes/My\ External\ Drive/Capture One/Cache /Users/username/Pictures/Capture\ One\ Catalog/Cache
Hint: You can drag a directory from the Finder into the Terminal window to paste in the path.
8 Double-click your new, nice and slim .cocatalogdb file to launch Capture One. Et voila! Your catalog should load exactly as before.
9 If everything is cool (and all photos are backed up as always!), you can delete the original, bulky .cocatalog file.
10 I can’t end at step 9! So go take some pictures!
wow. This is pretty awesome. I found while searching for info about why my C1 catalog file was getting HUGE even though I don’t keep my originals inside the catalog. The only other suggestion that anyone seems to have come up with is using sessions instead catalogs, but then what’s the point of even using a DAM?
You’re welcome, Chris!
I agree about sessions. Capture One was originally designed around individual capture sessions, hence the name, and I’m sure sessions continue to make sense for many photographers’ workflows. Not mine. I definitely prefer a catalog/library structure. Catalogs are a relatively new feature of Capture One, and I’m sure the reason they were added was to make Capture One a full-fledged DAM and proper Lightroom alternative. They succeeded!
But switching to sessions wouldn’t solve the problem anyway… It’s true that sessions store the preview cache as a separate, visible directory as opposed to hidden inside a package, but that’s only half the issue. There is still no option to store the preview image cache anywhere other than alongside the catalog database. So even with sessions, you would have to use the symlink trick to store the preview images on a different drive, except that you would have to repeat the procedure for every session!
This is good for people who have just a catalog. I started out using just a catalog but didn’t like that all my edits were only stored in one place. So I decided to use sessions and then import the session in using file>import session. So I could have two copies of the edits and not store them in one place
That makes sense. It can’t hurt to use redundant systems from the outset. Personally, I don’t worry much about keeping all the edit data in a single file, because, within an hour of any change, the file has been backed up to 3 places (and gets periodically archived to a 4th).