Capture One C1 v.9 users please

[vlad]

Hi Stephen,

Thanks for asking. Here is somebody who does not cascade!

Do I understand correctly that you don't use versions at all? Regardless of that, do you want to keep any metadata different between the RAW's and the JPG's?

I have no idea, but would it not be possible to either replace or merge the data from the xmp sidecar file into the i.e. jpeg just imported?

I guess you could frame that as a scenario of metadata cascading (not necessarily involving version sets, though). Anyway, that was my main suggestion: it would be possible, by writing and running a custom script to do that. (I also suggested a readily available workaround based on Export and Import CSV Data, but only as a first step, since it's a bit cumbersome.)

This might dictate a few steps before a RAW files 'leaves' PSu for editing, like a forced writing of data somewhere!
Then on re-import a check-box available with a clear label (and maybe pop-up) to explain who it's for and under which situations.

Sorry, I don't understand your suggestion.

[Stephen]

Hi Stephen,

Thanks for asking. Here is somebody who does not cascade!

Do I understand correctly that you don't use versions at all? Regardless of that, do you want to keep any metadata different between the RAW's and the JPG's?

I do not use versions. I keep the metadata between RAWs and JPG identical.

I have no idea, but would it not be possible to either replace or merge the data from the xmp sidecar file into the i.e. jpeg just imported?

I guess you could frame that as a scenario of metadata cascading (not necessarily involving version sets, though). Anyway, that was my main suggestion: it would be possible, by writing and running a custom script to do that. (I also suggested a readily available workaround based on Export and Import CSV Data, but only as a first step, since it's a bit cumbersome.)

That is what I understood you to mean The workaround would not be so good though.

This might dictate a few steps before a RAW files 'leaves' PSu for editing, like a forced writing of data somewhere!
Then on re-import a check-box available with a clear label (and maybe pop-up) to explain who it's for and under which situations.

Sorry, I don't understand your suggestion.

I basically mean that with a special script like that, the user would have to know - and remember - what they are doing, as it is powerful. Also, there is no "undo" button in PSU

[sanphotgn]

Stephen, the workaround is not difficult and provides/requires a level of control throughout the process so one is aware of the data being copied and where it is going. I have also entered a feature request in Mantis based on Mike's idea (found in this thread). That would allow one to copy and paste (the feature already exists, just needs to be expanded). Not efficient if you have hundreds at one time to do. But would be handy to have and make quick work when one only has a few at a time.

[Stephen]

I generally have dozens at at time, so still very tedious

[fbungarz]

Hi Stephen,

I do not use versions. I keep the metadata between RAWs and JPG identical.

Actually I very much doubt that this is possible without versioning and cascading.
Just a simple scenario:
You have a RAW and you have a JPG. Now you apply the color label "red" to the RAW file. That means it metadata just got modified. If the JPG was a version of the raw you could easily cascade the metadata down into the JPG. Else you have to manually apply the "red" label now to the JPG as well. Now, for a single file both are just one additional step. But as soon as you deal with thousands of files, I very much doubt even the most disciplined users will be able to make sure the data are consistent across the files that belong together (the originals and their derivatives).

May I ask why you are so strongly opposed to using versions for this task??? It seems to me that is exactly what versioning was designed for: keeping data in sync across several derivatives (= versions of the same file).

I generally have dozens at at time, so still very tedious

Yes, and therefore, in my opinion cascading down metadata (also the technical ones) makes perfect sense!

@Vlad:

(Side question:
Do all of you use version sets to group together images derived from the same shot? That may be the most common use case, but I could imagine someone using a version set to group together images of the same subject, taken with different cameras and/or lenses, and possibly at different times and with different settings. You wouldn't want blanket cascading in such a case, right?)

The fact that some users might use versioning for what it was not designed for is not a good argument against cascading technical metadata! In fact the example you mention is a case of stacking images, not versioning! But I guess the confusion is understandable because PSu never offered stacking as a feature.
I think the fact that actually some technical metadata are being cascaded in PSu might be evidence that this is in fact not a feature but a bug: IDI did offer the option to cascade all metadata (via direct file operation). That choice was removed in PSu and as a result now some technical metadata are apparently cascaded, while others are not. This inconsistency does not make sense to me.

Much more logical would be to again add a simple choice, currently the options are:
- cascade Image Details (XMP)
- cascade ratings
- cascade color labels
- cascade GEO coordinates

Why not simply add a fifth option?
- cascade all metadata (including technical camera data)

That would be MUCH more convenient for fixing metadata of a derivative file (= version) messed up by a third party program like C1. Much more straightforward, much more efficient than running XMP CSV Export and the XMP CSV Export script! .

Cheers,
Frank

[fbungarz]

PS: I think a scenario where technical metadata can inadvertently get corrupted is not so unusual at all. And being able to use PSu to fix that is something that in my opinion any good DAM sowftware should be capable of. Locking down technical metadata may be a good default strategy against accidentally corrupting metadata. It should not be an argument against options to fix/correct technical metadata that for whatever reason have become erroneous.

[Stephen]

Quite simply, all I need is a button which says:
"Take all the meta data from the RAW (or xmp) files with the same name as the group of files I have just marked and place it in those files."

File 001.jpg gets data from 001.raw or 001.xmp
File 002.jpg gets data from 002.raw or 002.xmp
Etc, etc.

*I will leave that to the experts to decide.

Is that so difficult?

[fbungarz]

Quite simply, all I need is a button which says:
"Take all the meta data from the RAW (or xmp) files with the same name as the group of files I have just marked and place it in those files."

Cascading would do exactly that IF it worked with technical metadata...

[Stephen]

It did not work the last that I tested something similar via stacking, although that might be different from the solution described here.

[Stephen]

I guess you could frame that as a scenario of metadata cascading (not necessarily involving version sets, though). Anyway, that was my main suggestion: it would be possible, by writing and running a custom script to do that.

Quite simply, all I need is a button which says:
"Take all the meta data from the RAW (or xmp) files with the same name as the group of files I have just marked and place it in those files."

File 001.jpg gets data from 001.raw or 001.xmp
File 002.jpg gets data from 002.raw or 002.xmp
Etc, etc.

@Vlad or anybody else.
Where could I turn to have a script made to do just that? Presumably that person would have to be familiar with PSu?

[fbungarz]

It did not work the last that I tested something similar via stacking, although that might be different from the solution described here.

It does not work, because in PSu [some] technical data are excluded from cascading.

[fbungarz]

@Vlad or anybody else.
Where could I turn to have a script made to do just that? Presumably that person would have to be familiar with PSu?

I doubt a script will do the trick, if "copy/paste" and "cascading" technical data are specifically excluded i n PSu. If someone wanted to program a script that copies and pastes technical metadata, that person would likely need to know how specifically to circumvent the current restrictions that PSu puts on these data. The script could not just call the copy/paste routines, it would have to be designed to copy data that currently apparently cannot be copied.

[vlad]

Just because the interface prevents the copying or cascading of technical metadata, it doesn't mean such custom functions couldn't be implemented via scripting. On the contrary, the CSV export and import functions, which work with any metadata (including technical fields), are strong indications that the copying of technical metadata could be programmatically implemented. At least, that would be my bet.

Where could I turn to have a script made to do just that? Presumably that person would have to be familiar with PSu?

Yes, Stephen, a PSu script writer needs to be familiar with both programming and PSu. In the past, I wrote a couple of custom scripts just to help some people here, on my own initiative; at the moment, I no longer have the time and motivation to do that for free, especially given the limiting factors. (The open API technical doc is minimal and PSu is not a development environment; testing and debugging a script is not always easy.)

If I will write additional scripts for my own needs or simply as a courtesy to other people, I will continue to share them (if they are of larger interest).

[Stephen]

I don't expect it to be free but if I contract anything to freelancer.com I receive 300 replies in my mailbox and still have problems finding the right person.