Capture One sessions and iMatch buddy files

[tokumeino]

Hi, I've used the search feature, and I've looked at the help files, without success. So let me ask here.

When working with Capture One sessions, buddy files are not in the same folder as the original, but in subfolders. Can iMatch handle that when renaming, moving... ?

Typically, the folder structure will be :

Main Folder (folder)
- IMG1.RAW
- IMG2.RAW
- Capture One (folder)
- - Cache (folder)
- - Settings131 (folder)
- - - IMG1.RAW.cos
- - - IMG1.RAW.cof
- - - IMG2.RAW.cos
- - - IMG2.RAW.cof

(buddy files are inside the Settings131 folder)

I want to do all the "Library" work with iMatch and all the edit work with COP, whith develop settings stored in buddy files and not in a messy CapturOne database, which would make things more difficult (if not impossible) in case of renames, moves ...

[Mario]

Yes. IMatch can deal (to some extent) with buddy files in sub-folders. Just setup your relations accordingly.

search for capture one buddy with the community search engine for some pointers.

[tokumeino]

Actually, it seems to work. I used to make a tiny mistake that prevented the thing to work. Just for the record, I tried to mimic the existing REGEX to create a new special "Capture One" relation rule for buddy files :

- Master expression : \.(dng|rw2|orf|nef|nrw|arw|raf|cr2|crw|pef|tif|jpg)$ so as to capture whatever file I'm likely to develop with COP
- Replacement expression : ^_*// (same black magic)
- Link expression : ^(_*{name}).*\.(cof|cop|cos|com)$ (here, the expression is tailored to ADD one of the buddy files type

And don't forget to let search down 3 levels (only 2 to exclude Cache files). It seems to work for renaming but the thing will require further testing.

[thrinn]

When working with Capture One sessions, buddy files are not in the same folder as the original, but in subfolders. Can iMatch handle that when renaming, moving... ?

IMatch can handle buddy files in sub folders. This help topic may be useful: File Relations: Buddy Files

There is also a related post you might want to read because C1 insists on creating "double extensions": Instead of having a buddy file 123.cof for a given 123.RAW, it will be 123.RAW.cof. Not really a problem, but must be taken into account when creating the file link expressions.

[tokumeino]

Thanks. Following a description of all possible sidecar files in Capture One (https://support.captureone.com/hc/en-us/articles/360002862137-Session-Sidecar-files), I've ended with these expressions (top to bottom in the dialog) :

• \.(dng|pef|arw|rw2|orf|cr2|cr3|raf|nef|tif|jpg|png|mp4|m4v|mov|avi|mpeg|mpg|ts|mts|mkv)$
• ^_*//
• ^(_*{filename}).*\.(cof|cop|cot|comask|cos|icm)$ (link expression)

Using {filename} instead of {name} is the file name including its extension.

Following what I can understand from the iMatch link you provide, I've put this rule below the regular rules per raw extension, so as to link buddy files of buddy files as well (such as dng conversions of raw files). I consider this as more general and flexible than the following proposition : https://www.photools.com/community/index.php?topic=10274.msg73468#msg73468

I've not tested that but I'm quite confident.

Feature request : buddy files and versions management is really a killer feature of iMatch. And I fully understand Mario's choice of letting people write their own RegExp to tackle special needs. However, there are many users of softwares such as Capture One, OnOne or a few others. It would be nice to provide out of the box rules for iMatch new adopters. I can understand RegExp so tailoring one for my needs was not that difficult, but I'msure it can intimidating for some. That is important, I think, because it is a core requirement for a smooth interoperation with editing softwares.

[Mario]

We have a dedicated board for feature requests. FRs in a normal post like this will be forgotten in a week.

It would be nice to provide out of the box rules for iMatch new adopters

We tried this many years ago. There are even examples in the help.
But, frankly, Capture One is the only RAW processor which produces such a mess of sidecar files and spreads them all over the place. They really should put a bit of work into that.

I have never used C1 and I don't recall a C1 user posting here such overly complex buddy file relations. For example, .ICM are color profiles. Where do these come from? Why do you need to manage 6 or more different buddy files for a simple RAW file? All these sound to me like proprietary files only useful for your RAW processor. You should keep them outside the folders you manage in your DAM. DAM is about archival, not about tracking temporary work files while you still work on your images.

Your file relation setup may slow down IMatch big time, too. Considering so many files as masters (even JPEG and TIFF files!) will not only affect all operations, but most likely will also cause issues if you manage anything other that your RAW files in IMatch. It is generally bad form to make files both masters and versions, which seems inevitable with your complex setup covering even JPEG and TIFF files as masters. This is not to be used as a shotgun, more like a scalpel. I would give this a rethink. Use only the RAW files for which you really need to manage buddy files.

I had opened a thread years ago, asking users for typical buddy files they use. Most that came up was:

\.ext
^{name}\.buddy_ext$

or, in complex cases,

\.ext
^{name}\.(buddy_ext,other_buddy_ext)$

(The replacement is needed only in very specific cases to fix broken file naming schemes).

And that's all textbook and covered in the IMatch help at length.
Setting up 5 or 10 profiles for Capture (for different RAW formats) will pollute the list and probably confuse users more than help them. And there were different buddy setups from different C1 users...nothing really deterministic. Seems to depend on the C1 workflow and version. And making a catch all rule for all potential file formats C1 supports, and all buddy files it may splash all over the disk would do no good and could cause performance problems or even damage - if the wrong files are processed as buddy files.

As always, feel free to open a FR. I can always add an extra paragraph in the help, explaining about the C1 mess and potential recipes to handle it.

[Jingo]

The real question is.. why would you WANT all these RAW editor sidecar files in your Image management database?  I mean, I use C1 for RAW editing only... export a finished file to a new directory and import that to IMatch.  If you want to keep you RAW+finished image(s) together, then use versioning.  But, I'm not sure why you need to keep C1 specific sidecar files: .cof/.comask (Focus Mask info), .cop (Cache Preview info), .cot (Thumbnail file), .cos (adjustment info) and .icm (custom ICC profile) in your DB?  They offer nothing to IMatch....

Again, just curious. 

[tokumeino]

Since COP catalogue sucks (othewise I wouldn't need iMatch), I find more natural to make only edits with CO, and sessions are the way for that. But sessions (sorry @Mario, not my fault) produce buddy files for everything, as documented in the link above, even .icm files, apparently (even if I've never seen one actually, just in the documentation).

@Jingo : when you rename or move RAW files and/or versions, if you don't use CO's sidecar files but the database instead, then you have to do this within CO, right ? If you do it in iMatch, you'll loose all edits (if you rename, you'd need to relocate every file individually and if you just move, then you relocate folders one by one). The issue is that when doing so, even if you forbid CO to write XMP files, then XMP will lose information such as face regions, for instance (this was actually one of the first tests I've performed because I'm aware about CO's weakness with metadata). So, I want to rename/move while preserving even complex metadata, and keep my edits as well. So I'm forced to do it within CO, and so I need to tackle the indigest COP buddy files. And no, "don't rename or move" is not a solution I agree that all the CO mess doesn't help iMatch, but they are necessary for CO itself, not to lose edits while moving/renaming files within iMatch.

@Mario : by using the search tool, it appears that there are people coming to the same type of rule as mine: https://www.photools.com/community/index.php?topic=2407.0 The simple samples you provide are OK for editors such as Darktable, OnOne or others which simply put one sidecar file in the same folder as the master. But they won't work at all with CO. As you tell, RegExp are fine to be flexible despite the geeky approach. If at the end, you can only use them for straightforward schemes... 

At the end, I have only one typical rule for every RAW file and video format I have, plus this only one more complex rule wich tackles all the Capture One think with only one rule.

[tokumeino]

As always, feel free to open a FR. I can always add an extra paragraph in the help, explaining about the C1 mess and potential recipes to handle it.

What is a FR ?

[Mario]

Feature Request. See https://www.photools.com/community/index.php?board=12.0

[Jingo]

Since COP catalogue sucks (othewise I wouldn't need iMatch), I find more natural to make only edits with CO, and sessions are the way for that. But sessions (sorry @Mario, not my fault) produce buddy files for everything, as documented in the link above, even .icm files, apparently (even if I've never seen one actually, just in the documentation).

@Jingo : when you rename or move RAW files and/or versions, if you don't use CO's sidecar files but the database instead, then you have to do this within CO, right ? If you do it in iMatch, you'll loose all edits (if you rename, you'd need to relocate every file individually and if you just move, then you relocate folders one by one). The issue is that when doing so, even if you forbid CO to write XMP files, then XMP will lose information such as face regions, for instance (this was actually one of the first tests I've performed because I'm aware about CO's weakness with metadata). So, I want to rename/move while preserving even complex metadata, and keep my edits as well. So I'm forced to do it within CO, and so I need to tackle the indigest COP buddy files. And no, "don't rename or move" is not a solution I agree that all the CO mess doesn't help iMatch, but they are necessary for CO itself, not to lose edits while moving/renaming files within iMatch.

Funny how we all differ - I use a C1 catalog for my images/edits to AVOID sidecar files but don't use any other C1 features other than their fantastic RAW editing.... all metadata is handled in IMatch of course. 

I export finished JPG's from C1 and import them into my IMatch DB and only then manipulate the metadata/filenames/etc those JPG's using IMatch.  If I want to do something additional with the original RAW file, it is simple to use the C1 catalog to access that image, make tweaks, export an add'l JPG and then import to IMatch and version them together.  For me, the RAW files are my negatives and only exist for developing purposes... once developed, my JPG's are my prints and are used to view, share, catalog, etc.  But - everyone has different workflows of course...

[graham1]

Funny how we all differ - I use a C1 catalog for my images/edits to AVOID sidecar files but don't use any other C1 features other than their fantastic RAW editing.... all metadata is handled in IMatch of course.

Yes, I agree.  C1's catalogue is absolutely hopeless as a catalogue or for keywording.  I am fed up with Lightroom as well.  But RAW files have to be processed somewhere. 

One big advantage of using Lightroom's or C1's catalogue is that the develop settings are kept in their catalogue.  They are retrievable or capable of being copied to other images without the need to create (or retain) an intermediate TIFF (or other format) file.  If each edit needed an intermediate TIFF to recall the develop settings, the storage requirements would soon get completely out of hand, cheap though disk capacity has become.  I process in C1 or Lightroom, export the JPG file to where I need it, upload it, then delete it.  The process settings are still in Lightroom or C1 in the catalogue if I need to recreate the export file, at the cost of a few KB, instead of tens or even hundreds of MB per file.  All of the keywording/metadata can still be maintained in IMatch, and it is then easy to avoid the clutter of C1 session files as well.

Graham

[Carlo Didier]

I export finished JPG's from C1 and import them into my IMatch DB and only then manipulate the metadata/filenames/etc those JPG's using IMatch.  If I want to do something additional with the original RAW file, it is simple to use the C1 catalog to access that image, make tweaks, export an add'l JPG and then import to IMatch and version them together.  For me, the RAW files are my negatives and only exist for developing purposes... once developed, my JPG's are my prints and are used to view, share, catalog, etc.  But - everyone has different workflows of course...

What I'd love to have is a way to start C1 with a file name as parameter so it would open its catalog right at that file (provided it is in the C1 catalog). I can do that with Adobe Bridge, which is very handy. If I want to go back to Bridge to re-edit a raw file, I can call Bridge from iMatch with the full file name as a parameter. Can't do that with C1 ...

[Jingo]

I export finished JPG's from C1 and import them into my IMatch DB and only then manipulate the metadata/filenames/etc those JPG's using IMatch.  If I want to do something additional with the original RAW file, it is simple to use the C1 catalog to access that image, make tweaks, export an add'l JPG and then import to IMatch and version them together.  For me, the RAW files are my negatives and only exist for developing purposes... once developed, my JPG's are my prints and are used to view, share, catalog, etc.  But - everyone has different workflows of course...

What I'd love to have is a way to start C1 with a file name as parameter so it would open its catalog right at that file (provided it is in the C1 catalog). I can do that with Adobe Bridge, which is very handy. If I want to go back to Bridge to re-edit a raw file, I can call Bridge from iMatch with the full file name as a parameter. Can't do that with C1 ...

There are a number of command line parameters you can pass to C1.. but none that let you do what you wish to.  Personally, I "get around" this by keeping my RAW and processed filenames and directory paths identical - just on different drives.  If I have JPG in IMatch called: D500-04-10-P410020.jpg in the V:\2020\2020-04 folder... then I know the same file is located in my P:\2020\2020-04 folder as D500-04-10-P410020.NEF.  So, I just open my C1 catalog and dive into the timeline to find it quickly... not as easy and just highlighting a photo in IMatch and running a shortcut to get right there.. but easy enough.

[Carlo Didier]

There are a number of command line parameters you can pass to C1.. but none that let you do what you wish to.  Personally, I "get around" this by keeping my RAW and processed filenames and directory paths identical - just on different drives.  If I have JPG in IMatch called: D500-04-10-P410020.jpg in the V:\2020\2020-04 folder... then I know the same file is located in my P:\2020\2020-04 folder as D500-04-10-P410020.NEF.  So, I just open my C1 catalog and dive into the timeline to find it quickly... not as easy and just highlighting a photo in IMatch and running a shortcut to get right there.. but easy enough.

I also know exactly where the raw file is. But it annoys me to have to manually browse to the same place in C1. Maybe I can control C1 with an automation tool like AutoIt.
It's so easy with Bridge. My button in iMatch calls Bridge with the selected file and I just have to enter Ctrl-R to get it into the raw editor.

[thrinn]

There are a number of command line parameters you can pass to C1

Do you know of any reference on these command line parameters? I was not able to find any documentation on it.

[Jingo]

There are a number of command line parameters you can pass to C1

Do you know of any reference on these command line parameters? I was not able to find any documentation on it.

Was from an older post but I checked and my older version of C1 still has these right click options enabled - even with C1 v20

https://webcache.googleusercontent.com/search?q=cache:can1ENaindwJ:https://forum.phaseone.com/En/viewtopic.php%3Ff%3D76%26t%3D37520+&cd=1&hl=en&ct=clnk&gl=us

[thrinn]

Thank you!

[Jingo]

Thank you!

You bet!