Capture One Catalog

I feel compelled to write down my thoughts about Capture One Catalog. As much as I love Capture One Session, I am appalled by Capture One Catalog.

I have 25 years of experience in Data Management Systems, not in image management, but in large industrial data acquisition and management systems. So I have a Data Management view on the Catalog. And this is what I want for my own image collection.

Currently Capture One Catalog just does not work. I know it seems to work during webinars, but I know how easy it is to demo toy catalogs and hide the real issues (I have experience 😊 ). A large image catalog in Capture One just-does-not-work. I have several big issues reported and hopefully they will be addressed, but I am afraid that Catalog is not a priority.

Apart from being extremely buggy, I think Capture One Catalog is not taking the right approach. I was using MediaPro before and I was kind of amazed when CO started to include Catalog functionality. I think that was a wrong decision, but I can live with that as long as it is executed properly. I like MediaPro much better as an interface, but its file structure makes it hard to handle large catalogs. MediaPro looks like a Catalog, Capture One Catalog is just a glorified image editor and tagger.
From my experience it is always better to have separate, smaller programs on a solid common data structure, rather that making big monolithic software applications. These last are more difficult to design properly and tend to be more buggy. But I know some people disagree.....

For me, Catalogs by definition are large, so no use to look at small catalogs.

Lets look at the workflow from a Data Management perspective:

1. Data is generated and acquired under the ownership of some department. This department is responsible for the quality control and some basic processing. For images this would be a photographer and Capture One Session. Discard the junk (cf. remove invalid data) and process the rest. After this stage this data is archived and kept forever. It may be reprocessed if new techniques become available, but the raw data stays as it is, forever. This is completely analogous with Images and Sessions.

2. Now data needs to be consolidated, i.e. shared with other departments and maybe rolled up to higher levels in the corporate hierarchy. For this only validated and processed data should be used. Usually a selection is made of a certain subset of the data. Too much detail is not usefull for other departments. For images that is analogous to importing from the Session a selected subset of images into a Catalog. Currently CO can not do that. It imports the whole session. It should have an interface allowing selective import. It could be as simple a selecting from a smart album. Almost all my sessions have a smart album called "Selected Images".

3. There should be a way to organize the imports in the Catalog, e.g. by department and acquistion date. In the case of Images, by Session and acquisition date for example. The CO Catalog tree with albums, projects and groups would be great for that, if it worked................. But it does not work. Organize sessions in groups and projects and the next time you open the Catalog the order can have changed and groups break apart. Albums literally fall out of their groups and are placed at random in the tree. You manually rearrange them again and next time you open, again they break up randomly.

4. Consolidated data is never edited by departments other than the department that acquired the data. They are the owner of the data. This should be the same for images. Images should NOT be edited in the Catalog, they should always be edited in the Session and refreshed. That way we keep the data consistent. Now we can be a bit flexible on that. I know some people would like to edit images on the fly in the Catalog and have a less purist view than me. That is fine, but i would like there to be a switch disallowing image edits in the Catalog. I need to be able to enforce consistency.

5. Editing of tags and keywords in the Catalog is perfectly fine in my view. While we usually start keywording in the Session, it is expected to have to add additional keywords in the Catalog, since we are working in a wider context(local vs global keywording).

6. There should be a working "refresh Session" operation. When images have been updated in the Session these updates should go into the Catalog. Image edits done in the Catalog should NEVER go back to the Session, because then we end up with a big mess sooner or later. The refresh session functionality is currently implicit in the Import session (i.e. re-import), but it is very messy. It needs cleaning up. It would be "nice to have" a history of updates to the catalog. I am not in favor of automatic refresh, but a comparison option finding discrepancies between Catalog and Session content would be nice.

7. It is perfectly fine to have multiple Catalogs, e.g. Vacation Images, Work Images, 5 star images, etc. But they should all source from the same sessions (see point 2).

8. Data Management Catalogs always have extensive Select, Report and Export functionality. That functionality is for the most part already existing in Capture One Catalog. Improvements are always possible, but I think the priority should be on the Catalog creation and structure first. No point is selecting and exporting from a Catalog where you can not even get the data in properly.

Unfortunately Capture One Session and Catalog closely are tied together (no open interfaces). So either they both work, or I need to look for an alternative for both. But I really want to stay with Capture One Sessions. So please fix the Catalog.

Jozef Dassen

Robert Edwards

August 10, 2016 09:26

Hi Josef,

Thanks for your knowledgeable post. I especially agree with point 8.:

8. Data Management Catalogs always have extensive Select, Report and Export functionality. That functionality is for the most part already existing in Capture One Catalog. Improvements are always possible, but I think the priority should be on the Catalog creation and structure first. No point is selecting and exporting from a Catalog where you can not even get the data in properly.

Media Pro has a long history of this. The original developers had backgrounds in databases and one of it's past alpha testers has a similar work history to yours.

A decade ago digital photographers would typically require two or three apps in their workflow:

Image browser to download and review photos

Raw processors to adjust and convert images

Catalog app to, well catalog

For photographers this a kluge. The photography market wants a Swiss Army Knife: the interface and single app workflow that Apple Aperture, Adobe Lightroom, Phase One Capture One offer. Of course these apps all fall well short of the mark compared to dedicated DAM apps. However it seems photographers don't want true digital asset management any more than they want to learn Excel.

SFA

August 10, 2016 12:28

Just a note to mention there is a parallel thread running in the Windows section.

It might be better to combine them into one entry under the Image Processing and Workflow section.

I imagine there may well be some constraints in operation related to differences in operating systems and a desire to make as much common code as possible no matter what the OS may be but the observations as written up are not OS specific so a Image Processing and Workflow posting would seem to be more appropriate.

Grant

George Barron

August 10, 2016 13:29

I am NOT a database expert. In fact, I know nothing about them. But in my ignorance I will disagree with several of the OP's points in relation to DAM.

First, I have not and will not consider a multiprogram approach to digital photography. It is too often a slow and clunky process. It may allow for superior features in the individual programs but I have not found that worth the difficulties involved. To me, it is inelegant. ( I'm talking about daily typical workflow. For special needs and circumstances I use multiple programs and plugins all the time.)

Second, I think that the ideal, compromise, if you will, was Aperture. Its library system was robust enough for the vast majority of pros and hobbyists and could even be shared over networks. So in my opinion, Aperture has set the standard. Granted, it began to lag significantly in editing features but this was effectively due to Apple abandoning the program long before they had announced it.

Third, I want to be able to do EVERYTHING at the catalog level. To me, this is where CO lags a bit. For instance, I cannot completely delete an image from within a User Collection. This is also part of the reason I gave up on LR. It behaves like a collection of small programs. You stay in LR but when you need to go from your grid of images to make adjustments you are essentially 'switching' over to the "Develop" part of the program. This too is clunky, slow and unnecessary. Again, I see Aperture as the gold standard in this regard.

Finally, just my little niggle with the User Collection is that a Project should be able to contain images, not just albums of images. In other words, if I want a Project called 'Birds' I want to put all my bird pictures there regardless of whether or not they are in an album. This is just a scaled down approach (analogy) of what the User Collection is to the overall CO Catalog structure anyway. This is also, no surprise, how you could organize things in Aperture...and LR I think.

I agree that CO's catalog system needs a lot of work. And maybe for some professionals it needs better integration between Sessions and Catalogs, but for the expanding market of former Aperture users who do not like LR, a robust User Collection is going to be more important and being able to work from within that Collection in a seamless fashion is going to be expected by the end user and potential CO buyers.

Comments