Using Capture One?

[Erik]

I'm evaluating the possibility of using Capture One for processing my RAW files. 

Does anyone have a recommend way of using it, especially in conjunction with IMatch?  I'm having a hard time figuring out whether its better to use Sessions or its own Catalog (been trying to use it a couple of days).  I'm guessing the Sessions would be better, but I'm confused by the folder setup and how to make this work with my existing file system.  I don't want to move my files around.  For the sake of versioning and IM management, I'd like to keep all versions and buddy files close to the originals.

Any hints?  I'm guessing as in anything there is really no one right answer, but it's nice to have a couple of starting points.

Thanks.

[Ferdinand]

I have CoP7 (I have most of the Windows converters) but I don't use it all that much, partly for the reasons implied by your question.

Re buddy files, I documented my settings here:  https://www.photools.com/community/index.php?topic=2407.0

I don't use its own catalog for much the same reason that I don't use the LR catalog.  The settings are stored in the catalog and not in sidecar files that can be seen by IMatch.  So if you rename, move, delete in IMatch you'll lose the connection with your CoP7 settings, and likewise if you do this in CoP7 then IMatch will lose the file (although you may be able to relocate).  I think LR catalogs have the same issue if you store settings in the catalog rather than XMP sidecars.  You should only use one DAM, and we know which one that is.   

So I use sessions, sort of.  I have created one session only that I store outside my image folder tree.  And when I want to edit a new folder I simply change the capture folder to the folder where the RAWs are locaed and the output folder to a subfolder, but always the same session.  The settings and cache images are kept in subfolders of the RAW folder, and so can be managed using buddy files. 

Using sessions this way means I can ignore them in practice.  But I dislike all the rubbish that CoP7 stores in sub-folders, so I really have to prefer its conversion to use it.

And CoP7 will write a blank label to the sidecar for RAW files without labels, which I need to clean up in IMatch - tedious.

There's also an issue with orphaned CoP7 sidecars if you delete files in IMatch - I may write a script to clean this up.

I'd be interested in any other tips.

[Menace]

I work only with Capture One and I love it, even it makes problems together with other DAM-Software. Here my strange workflow:

• Start C1 in Session Mode (allways the same session)
• Import from Card and renaming it to the date + original name
• Rating and Deleting the images - Part 1
• Working with the images and konvert it to a special folder (jpg)
• eleting the images which I don't want to keep as RAW - Part 2
• Moving the pictures in special folders (Date for private; biological folders for my images with species)
• Deleting the folder C1 made for importing
• Start IMatch - (Re)importing the RAW and the jpg folder
• Versioning
• Tagging
• Move jpg in the special directions/folders (Date for private; biological folders for my images with species)

This may the dumbest workflow, but it works for me, yet. But I don't care about the special sidecare-files from C1 (which remains, where C1 put it, so I can change it easily to other computers).

[Erik]

Thanks for the responses, especially in how you use the Sessions.  I am aware of the buddy file issue (if it's an issue)... I only say that as it seems most raw converters have this buddy file issue.

I'm mostly checking my options out because I've never been the hugest fan of the output from LR, but at the time I switched to it, it had a few features that no other RAW conversion software had (local edits were the primary of these).  Then I got used to its workflow, and stuck with it.  However, with my Pentax camera, I'm seeing a lot of people switching to Capture One because they get better results faster.  I'm not convinced it'll be worth my effort.  I do have a lot of plugins that work nicely with LR that I think get me to an end point well enough.

Anyway.  The one thing I like with LR is that it can be made to store its development information in the XMP record for a file.  This sounds like the big difference compared to Capture One that in its catalog mode keeps development information in the database.  The session mode seems to allow sidecar files (Ferdinand's Buddy File Settings elsewhere), which I imagine serve the purpose the XMP data for LR does.  Silkypix and RawTherapee do something similar with data in sidecar files outside the typical Metadata.

In LR, I'm comfortable with it because as long as development data is in the XMP, LR will read it in even after a file has been moved around.  What you do lose are the step by step process that got there... the history that is stored in the database.  I'm actually mostly fine with that.  You can also lose things if you use the snapshots or virtual copies, but I almost never do that.  If I do, that is when I definitely output a JPG or Tiff file to create a permanent record.  Other than that, I don't use LR's library for much other than browsing and its collections.  I can search for keywords, use labels, use smart collections, etc.  I also use it to upload items to my Smugmug account through its plugin.

It seems that Capture One's catalog can do a lot of the same, but unlike LR, if an image moves and the connection in its database is lost, so will the edits. 

Just writing all this makes me think I should just stick with LR.  I dislike that these programs all think they need to have a catalog. 

[Ferdinand]

Just writing all this makes me think I should just stick with LR.  I dislike that these programs all think they need to have a catalog.

If that were the case then we wouldn't use LR either, since you can't avoid its catalog at all.  The LR and CoP7 catalogs are fairly similar if you store your edit settings inside the catalog, and neither are consistent with using a DAM like IMatch.  The advantage of the LR catalog over the CoP7 one is that with LR you can tell it to store its settings external to the database.  But you can do that with CoP7 sessions, so they are broadly similar to a LR database with settings stored in sidecars, and either can work with IMatch 5 like this.

I'm not opposed to sidecars.  I want a RAW converter than doesn't store its settings in a proprietary database and I don't want the RAW file changed, so that must mean sidecars.  But a number of the approaches used by different converters cause problems in my view:
.  The Adobe approach combines basic metadata and edit settings in the one file, and that causes problems for IMatch when reading these files.
.  Adobe also has a nasty habit of wiping the edit settings of any other converter that has the temerity to store its settings in the XMP file (e.g. Photo Ninja).
.  Bibble5 and Aftershot use confusing names for their sidecars (file.nef.xmp), when it's an XML file but not a real XMP file.  Ditto for Darktable I understand.
.  I don't like programs that store their settings etc in subfolders.  I can ignore sidecars in the same folder as the RAW, but I find additional folders to be a real clutter. Photo Ninja does this because it has to store a duplicate sidecar in case the original copy is wiped by LR - I think they would have been better off using their own sidecar extension, like DxO and Bibble4, instead of using the XMP + backup.  Silkypix used sidecars in sub-folders last I looked.  But CoP7 is the worst offender in my view, because it uses multiple folders several levels down and stores cache files in these sub-folders.  Cache files should be purgeable.

So my complaint against CoP7 is not that they use sidecars - this is good - but that they create a labyrinth of sub-folders containing multiple buddy files per RAW file.

[Erik]

Your complaints I think are all reasonable and ones I notice.  I used to use SilkyPix quite a bit, and it does use the subfolder approach.  I don't totally hate that as my workflow keeps everything at one level, so I know that subfolders are generally extra files I don't need.  It does look ugly.  Not ever using Capture One before the past week or two scared me because of all those extra folders (let alone your buddy file definitions that demonstrate that it goes levels down) and the wonder of how Capture One keeps up with it all.

I've always liked Raw Therapee because it does keep buddy files in the same folder as the original.

Since I took to LR, I've pretty much quit using all other converters.  Thus, I haven't really had the bad experiences of having it strip out metadata from something like Photo Ninja.  I haven't even tried that converter.  I've had it strip out of the info from my Metadata.  It makes me think that LR isn't so much stripping data out but rather only saving a very specific set of data and negligently removing in the process.  As Adobe and big corporations always do, they like to think they know what's best and give little options.  I feel happy that LR even gives the option of saving to the XMP files.

Ultimately, we all have to live with what the software does to some extent.  Built in catalogs seem to becoming more and more common.  They're really a marketing tool to be useful enough that once you're hooked you won't want to leave because your RAW editor is no longer just a RAW editor but your DAM, too.

I'm guessing that most of the users here know this, but that's not a majority of the overall photography community. 

Ultimately, the one thing I do like now with LR's catalog is that at least I now I can use it as a sort of read-only DB (if I ignorantly dismiss LR writing develop settings and my choice to change labels within it) in conjunction with IM.  Of course that is all thanks to Mario not Adobe.    The caveat is that the interface between the two catalogs is far from seemless, but I don't think anything ever will be.

[Photon]

I worked intensively with C1 (Capture One), but due to a very weak support of DNG files from some camera models I had to return back to Lightroom.

The one thing I also disliked heavily with C1 was the big pile of subfolders and files polluting my image folder structure. But I realized a very good solution for Imatch and all other tools. This solution will separate the image folder completely from the C1 files and folders.  However the method is a little bit complex and does require the powerful DOS command MKLINK.

I posted the solution 2012 in the PhaseOne forum with topic "Separated C1 working directory" and URL: http://forum.phaseone.com/en/viewtopic.php?t=12276. May be it does not make sense to copy all this in the Photool forum now, but in case of need for further discussion we might maintain updates here. I am using the symbolic links with windows heavily for all kind of applications to overcome a couple of their limitations regarding installation path, drive letter, disk location, ...

The method worked perfect and with IMatch it was even possible to move files to different directories without problems for C1. There is one key requirement, that ALL image files in ALL image folder need different file names. But this should be no problem for serious Imatch user, who use normally date, time and a unique number for all image files.

One important point I did not check yet with IMatch is the independent definition of the three processes "move/rename/delete", where the C1 buddy files are affected too. Is it possible to include buddy files for "rename" and "delete" but exclude them for "move"? This was possible and very useful with Idimager (R.I.P.), because a move of image file does not require moving buddy file when the same symbolic link is existing in the target directory (of course a very special case).

Regards, Martin

[Erik]

Based on your message, I see where you are going.  I've used the MKLINK command in Windows to move user document folders out of my SSD drive since most document type files don't necessarily benefit from that type of location.

But, it seems like it is a bit of an extreme thing unless one really was invested in using C1 or believe it is so far above and beyond the alternatives that it is worthwhile.  It may be, too.  I'll find out eventually.