Capture One C1 v.9 users please

[Stephen]

Hi Larry, what you write about C1 sounds pretty scary. I wonder if a possibility might be to use PSu to fix the mess they make. An option could perhaps be to create an additional subversion of a file in PSu...

My workflow is the same as Larry's. We both 'export' RAWs to C1 and import a JPG to PSu. Without complicating the workflow any further, could the meta data from the original RAW, which is stored in PSu anyway, not be used to reconstruct the missing data when the processed JPG comes back from C1?
Users would have to be diligent and not expect any meta data / colour / rating changes made in C1 to be retained. I could certainly live with that.

If I remember correctly from my own trial of C1, it doesn't write raw adjustments of the files into the XMP, but generates some sort of C1 specific sidecar files? In that case having PSu overwrite the XMP that was messed up by C1 would not be a problem, would it? Cascading the metadata back into the file from the untouched main version should then work.

As far as I understand, the C1 specific 'sidecar' files, cos, cof, etc., contain only the adjustment information made when editing the RAW file.[/quote]

Of course we are talking about XMP only here. I am not entirely certain to which kind of metadata PSu's metadata operation "convert metadata to XMP" applies. I am pretty sure Exif and IPTC is included, but not so certain about Makernotes. So, if C1 messes with data are not migrated to XMP with "convert metadata to XMP", then this information may indeed irretrievably lost.

Not sure that I follow all of that but C1 definitely DOES trash the maker notes! I believe that happens because they change (possibly just) one field. Wikipedia says that changing a preceding field can trash all maker notes.

HOWEVER, if PSu has this data from the original RAW file, then perhaps it can reassembled?

Just thinking out loud

Thanks for doing so. Infact this extra step is not necessary. You could stack the images on import (I don't - it's an extra step I don't need) and retrieve the camera exif data (not the maker notes) with the exception that Larry points out. EITHER you get the Lens Description and no more lens data or you can retrieve it, but then you lose the focal length. I personally need to know both lens description (was it a zoom 35-70?) AND which focal length was used. In any case the Lens Description can be added manually in PSu, but the focal length used CANNOT.

I could post screen shots but that function appears to have stopped once again.

This matter was discussed a year ago and I supplied IDimager with detailed files of camera RAW, RAW after importing into PSu, JPG leaving C1 and JPG after importing to PSu. That was with version 7 and version 8 showed similar results.

Frank, I am sure that this could be achieved within PSu.

[fbungarz]

I haven't tried your way but my workflow has been to import into PSu, select RAW file and open in C1 and process to jpg. Then back to PSu and Verify folders which is when the C1 processed file is added to PSu.

Larry & Stephen,
you should try this:

(1) Select the RAW - right click - metadata - convert metadata to xmp; that should convert all metadata, hopefully including the maker notes and Exif to XMP.
(2) Open the RAW in C1, do your adjustments and develop the JPG.
(3) Verify the folder in PSu with versioning enable to add the JPG as a subversion of the main RAW file.
(4) Cascade the metadata from the RAW main version to the JPG subversion (select the starred little tab in the upper right corner of the thumb, hit the arrow that pops out - cascade from this version to the version set.

If C1 did not modify the metadata of the RAW, but stores the adjustments in a sidecar file than the XMP in the RAW will remain intact and should be cascaded down to the JPG thus overwriting any corrupted XMP that C1 might have written to it.

If not add this to your workflow (after step 3 and before 4:

(4a) To make sure that tC1 has not touched the XMP of the RAW you could use PSU to re-write the XMP from its database to the RAW, overwriting any changes that C1 might have inadvertently done to the XMP of the RAW file.

Hope that works.
Cheers,
Frank

[Larry56]

Thanks for the suggestion Frank but it didn't work for me.

After cascading everything the processed jpg does not display the camera information, ISO, f-stop, s/s, or focal length although it does display the lens information. When selecting Convert to XMP the camera information and the other information shows but not the lens.

[PhilBurton]

I don't mean to be troll-ish here, but instead of "fixing" the C1 workflow, would anyone here in this thread consider an alternative? Say Lightroom?

Phil

[fbungarz]

After cascading everything the processed jpg does not display the camera information, ISO, f-stop, s/s, or focal length although it does display the lens information.

That seems odd. If PSu displays all that info for the RAW file, then it should be cascaded down to the JPG. Can you check if the info is displayed in the Advanced Section?

When selecting Convert to XMP the camera information and the other information shows but not the lens.

You mean you converted the metadata to XMP for the RAW file BEFORE cascading, righ? I guess that means that writing all that info into XMP worked for most of the data except the lens BEFORE the file was even touched by PSu. In that case that leaves two possibilities:
- this is a bug in PSu, where lens info is not migrated from Exif to XMP with "convert metadata"
- this is by design, because the lens data might be in a section of the metadata that cannot be converted to XMP...

Only Hert would know, perhaps you should file that in Mantis...

I don't mean to be troll-ish here, but instead of "fixing" the C1 workflow, would anyone here in this thread consider an alternative? Say Lightroom?

Personally I am using DxO, but I have evaluated Lightroom and C1. I think all three have advantages and disadvantages. In the end it comes down to personal preferences, but I can understand why people are reluctant to use Lightroom. Using PSu one can simply ignore the Lightroom database and ever so often simply delete it, but managing two databases (PSu and Lightroom) seems inconvenient. DxO and C1 can both be used without a database.

When it comes to raw adjustments in my opinion all three actually do quite good job and in the end it comes down to which tool feels most intuitive. I think DxO is unrivaled when it comes to lens correction, I also like that it offers some relatively decent presets. Helps when one needs to just do a quick job. C1 is probably on of the most powerful of the three, but I find it frankly a bit overwhelming. I think Lightroom is more intuitive.

So, if Larry and Stephen insist they cannot live without C1 but want to make sure all their metadata is preserved - then they are in a bind...

Cheers,
Frank

[Stephen]

@PhilBurton. Yes, with light room I will not need PSu either. However, C1 makes sense. It is one of the best converters and the company is married to Sony, which I use when traveling. It also supports high end cameras in the studio, like Phase One.

@Frank. I have forgotten the exact steps in my older test, but (as mentioned) you either get just the the Focal Length or Lens Description, but not both.
However, at that time I was not so concerned about the maker notes, but presumably they could be reconstructed too. Vlad (I think) made a suggestion, but it was squashed by others who wanted to see their pet themes prioritized.

After deciding against stacking, I was free to put the processed jpegs in a subfolder, which is cleaner. I did not like stacking and it causes an extra step to unstack again.

My goal is to reduce the number of steps.

Frank wrote:
"So, if Larry and Stephen insist they cannot live without C1 but want to make sure all their metadata is preserved - then they are in a bind..."

You make it sound like we the only ones Many new C1 users come from Aperture and realize that even the latest attempts at DAM functions in C1 v.9, leave them looking for a more powerful DAM. IMHO, there is a large market for PSu. I am continually amazed by the power behind the PSU machine and am surprised that it cannot handle a situation like this, but I don't think this market motivates the developer.

[Larry56]

It's not that I can't live without C1. In fact I rarely use it because of what it does to metadata. I primarily use Lightroom and Dxo (depending on my processing needs at the moment) as these don't cause the extra work to fix.

Part of the "problem" is I like PSu and everything should work around that. The sad fact is that both Lightroom and Dxo both show all the metadata even though PSu doesn't - either before or after Convert XMP. Why? I don't know.

[sanphotgn]

I don't have C1, but have been following the discussions. I thought a workaround had been figured out last fall or so, but I guess not. I thought Frank's idea would work. As I understand Frank's idea, take the RAW file metadata (which is what you want; totally visible in PSU) and overwrite (via cascading) the C1 .jpg metadata. Based on Larry56's recent post this doesn't work whether one Convert XMP the RAW file metadata or not. Did I read that right?

If the following has been discussed or tried, I apologize in advance: A copy and paste from the Details panel?

Highlight a RAW file, go to the Details Panel, go to the Profiles button at the top and click on Copy Details to Clipboard, select the items you want to copy. Highlight the C1 .jpg photo, go to the Profiles button at the top of the Details Panel and click on Paste Details from Clipboard.

Try it on a RAW file where the Convert XMP hasn't been used. Did it work? If not try it on a RAW file where the Convert XMP has been used.

[Stephen]

I don't have C1, but have been following the discussions. I thought a workaround had been figured out last fall or so, but I guess not.

No workaround has been found to date. You either get one part of the information or the other part, but not both!

[fbungarz]

After deciding against stacking, I was free to put the processed jpegs in a subfolder, which is cleaner. I did not like stacking and it causes an extra step to unstack again.

Hi Stephen -
just to clarify: I have not been talking about stacking, but versioning, two rather different things.
PSU no longer supports stacking. Stacking is assembling different images inside a stack. A good example is a panorama shot. You'd perhaps like to keep all images that you need stacked together so you know you can use them to make a panorama.
The concept of versioning is quite different. Versions are a set of different variations of one and the same image. A good example is your RAW version and the JPG that you developed from it using C1. Another example are the JPG+RAW pairs that many cameras shoot. They are essentially the same images though some people may also treat slightly different images, say a crop of the original a version of that file.
PSu I think is great, because it allows you to manage versions together. That is a huge time saver. Say you label your raw version as "landscape". The JPG then presumably also shows a landscape, right? If both files are versioned in PSu you will only have to assign that keyword once, because it will then automatically be applied to both.
In a stack of images, one image might show a castle, the next one the tree standing at the side of the castle and the next one the footpath through a sunflower field that surrounds that castle. Assigning the same keywords to all these images would not make any sense.

This also means, once you version your files there is no logical need to ever "un-version" them again. It is much easier ti manage them as part of the same version set. I am not sure about your workflow, but in my case I often discover that I might want to assign yet another keyword to a file, something I previously forgot. So, after I develop a RAW file I might still remember that I perhaps forgot to assign the keyword "landscape" to that file. If the JPG and RAW are versioned that is no big deal. If the JPG is one of many, many files in a subfolder, it takes time to look for that file...

Of course you can use PSu whichever way you like, but many aspects of the program are really very powerful. That is why I suggest to treat your JPG derivatives as subversions of the RAW. They are derivatives and as such in fact versions, even if you decided not to use PSu's option to treat them as such, instead simply keep them in subfolders.
For me such an approach simply goes against the logic of a database. I don't want to have to search through tons of folders to find a file. That is why I do the keywording in the first place...

Yes, with light room I will not need PSu either.

Actually I disagree again. I find lightroom's database capabilities rather poor. Even C1 has the option to manage files in a database. Both do not nearly come close to what PSu can do. I'D really put this exactly the other way round. I have no need for lightroom's database, because PSu does such a better job. And because PSu is so much better at databasing, it should be in fact a priority for Hert (and I am sure it is!) to serve customers, who are not satisfied with the poor database capabilities of C1 or lightroom...

Many new C1 users come from Aperture and realize that even the latest attempts at DAM functions in C1 v.9, leave them looking for a more powerful DAM.

That was clearly not my intention at all! Again I said it the other way round: someone who uses PSu has no need for the poor database capabilities of C1 or lightroom!

...but I don't think this market motivates the developer.

I think you are very much mistaken. Hert I am sure is much interested in offering a powerful database like PSu to customers not satisfied with the database in lightroom or C1. That is in fact exactly the market where PSu can perform.

@Larry -

The sad fact is that both Lightroom and Dxo both show all the metadata even though PSu doesn't - either before or after Convert XMP. Why? I don't know.

This is not true! I work with DxO and PSu. They work well together because DxO essentially does not mess with the metadata. It was another reason why I decided to go for DxO even though that program does not even have an automatic marker that flags images that have been adjusted but not yet developed into JPGs (a deficiency that I find very annoying!). Lightroom also works well with PSu, if you do never let it touch your metadata, which means you will have to ignore its database capabilities (what I would like to use is lightroom's face tagging, too bad that doesn't play nicely with PSu). C1 as far as I know is the only one of the three that as part of is raw adjustment messes up the metadata. For me that is definitely not worth it...

Based on Larry56's recent post this doesn't work whether one Convert XMP the RAW file metadata or not. Did I read that right?

I am actually much surprised this does not work. Like I wrote, converting all the metadata to XMP and cascading it into the subversions even after these were modified should update the metadata and thus be a way to preserve what C1 destroyed. If PSu does not cascade all XMP than this should definitely be filed as a bug in Mantis.
Copy - Paste would of course be another, even though a much more cumbersome option.

Cheers,
Frank

[fbungarz]

No workaround has been found to date. You either get one part of the information or the other part, but not both!

If the metadata is present as XMP in the RAW but cannot be cascaded down to the JPG derivative you should really file a bug in Mantis!

And then: at least Copy -Paste is always a workaround, though a rather cumbersome one...

[Stephen]

just to clarify: I have not been talking about stacking, but versioning, two rather different things.

Please substitute all my previous uses of the work stacking with the word versioning!

[Stephen]

...but I don't think this market motivates the developer.

I think you are very much mistaken. Hert I am sure is much interested in offering a powerful database like PSu to customers not satisfied with the database in lightroom or C1. That is in fact exactly the market where PSu can perform.

Many programs used downsteam from editing can read "the mess" created by C1, but PSu cannot!

[sanphotgn]

Recently a program I use was updated. Several updates enforced standards per the organizations that oversee them. Guess what? A ton of stuff broke for users, because application and content providers are ignoring the standards. (And similar to this situation, other applications exist, so users were saying but it works over there.) I don't know what is happening in this situation. Almost makes me want to download C1 and take a look.

If PSu does not cascade all XMP than this should definitely be filed as a bug in Mantis.

Yeah. Agreed. Why wouldn't it work? Unless it is merging and thus some things stay (the things you don't want) and some things aren't included (the things you want).

And then: at least Copy -Paste is always a workaround, though a rather cumbersome one...

I mentioned it in case no one has tried it. It might work. (It should work.) A couple of extra clicks and once you have chosen the selections you don't have to re-select if you don't use the feature for anything else.

Another variation of Frank's idea: Before bringing the C1 .jpg photo into PSU, delete all the metadata out of it.

[fbungarz]

Another variation of Frank's idea: Before bringing the C1 .jpg photo into PSU, delete all the metadata out of it.

Yes, you could easily do that in ExifTool...