Capture One C1 v.9 users please

[Stephen]

Any people here using version 9 on a Mac?

Just returned from a test and the files still have meta data problems. NassauBoy reported recently that everything was fine with his Nikon files (do not know whether manufacturer is relevant).

C1 vers. 7 and vers. 8 problem was probably that it wrote or changed the ExifVersion field, which most likely nobody needs, but PSu DOES need it. After editing a C1 file, PSu shows either ONLY the Lens Information OR if (by jumping through hoops) you stack the new file with the original (then unstack if you don't use stacking), you can recover all fields from the PSu database EXCEPT the Lens Information. That is the way I finally left it, while waiting for version 9, which appears to be unchanged!

Feedback from other C1 v.9 users would be appreciated. Please state which OS and which camera you use.

[Larry56]

I have the same problem in Windows 10 and C1 v9. I've been using Canon 5D Mark iii and it happens with any lens I use.

[Stephen]

Thanks, Larry. Please tell C1. I guess they will not view it as a problem if they don't get a lot of complaints.

Tests show that if I load the same file in:
Aperture
Iridient Developer
Photoshop Elements (therefore probably the same with Photoshop)
Mac Preview
ExifTool
then I can find everything. It is just PSu that cannot see it, because the data has been transposed.

[OldRadioGuy]

Stephen, using Olympus E-M1 raw files on a Windows 10 system.

A raw file converted to a TIF with C1-9 sent back to PSu shows virtually all of the EXIF data to be missing (in PSu). However, the same is true with a TIF from an Olympus ORF raw file processed in PictureCode's Photo Ninja 1.3.0.

When those TIFs are viewed in Zoner Photo Studio 18, the data is shown to be present.

Bob

[Larry56]

Stephen, I have had rather lengthy conversations with C1 tech support but they say they are doing it correctly and it's not a bug in C1. I don't expect to see any changes from them.

[Stephen]

I have had rather lengthy conversations with C1 tech support but they say they are doing it correctly and it's not a bug in C1. I don't expect to see any changes from them.

They might think that they are doing things right but they are still (i) moving data around and (ii) destroying the rest. Some software can cope with (i) but PSu cannot. Nothing can help (ii).

[PhilBurton]

Stephen, I have had rather lengthy conversations with C1 tech support but they say they are doing it correctly and it's not a bug in C1. I don't expect to see any changes from them.

This may be a long-shot idea, but here goes. My guess here is that the developers over at C1 have an inflated view of their own competence, and simply don't respect an "ordinary user." So what if, what if, Hert sent them an email. This would be developer-to-developer, and that message might get a better hearing.

IF, IF, IF Hert agrees to this, you would need to completely document the issues with screenshots and even write the email for Hert.

Now of course this is just my own idea, to be perfectly clear.

Phil

[Stephen]

Stephen, I have had rather lengthy conversations with C1 tech support but they say they are doing it correctly and it's not a bug in C1. I don't expect to see any changes from them.

My guess here is that the developers over at C1 have an inflated view of their own competence, and simply don't respect an "ordinary user." So what if, Hert sent them an email. This would be developer-to-developer, and that message might get a better hearing.
Phil

Thanks, a good idea. Hert might just do this as there are more C1 users in this forum now. Also, there is a large number of Aperture users (some using C1) looking for a good DAM solution, so it could be good business for PSu.

[fbungarz]

Stepen,
are you actually sure that the fault is with C1?

I would recommend checking the metadata with an independent third tool that shows you all the metadata tags that both PSu and C1 actually write to the files. I am experiencing a bit of a mess of metadata recently, quite possibly inherited from IDI and not necessarily caused by PSu. I only noticed it, because I have checked the files with ExifTool. PSu shows the files to contain the same metadata, but according to ExifTool the metadata is actually NOT the same. I am not saying that PSu is necessarily to blame, it could be that this was caused by IDi or even when I migrated from IDI to PSu.

Working with different software packages that all touch your metadata is always bound to be tricky. It might very well be that C1 is to blame - after all their principal focus is not image management, but raw development. But who knows who is really to blame if something gets "lost in translation"...

In my experience Hert has always been extremely attentive to metadata issues. When there was a bug with how IDI wrote metadata it got fixed quickly. (even recently he quickly updated the CSV metadata import script, which is really not part of the core of PSu).

Still after my migration to PSu it now seems that my files "carry a bit of a metadata heritage" from many years of metadata being written to them. It seemed the way how IDI wrote the data to these files over the years has resulted in quite a few inconsistencies. I would have had certainly no way to be able to even notice these inconsistencies had I not checked with ExifTool. I have just sent Hert an email, hoping this can be resolved. It would be good if the same metadata inconsistencies that you experience with PSu and C1 can be resolved. But, as Phil points out, it needs to be really well documented what is really going on. ExifTool might be rather helpful to check what metadata tags are actually written both by PSu and C1.

Cheers,
Frank

[Stephen]

are you actually sure that the fault is with C1?

I don't know where the problems lie, but if C1 is causing the problems, some applications can live with that. See above.

I am using an application called pyexiftoolgui to check what is happening, but NEVER to manually modify the data.

On a sample file modified in C1-ver. 9.:
(i) One clear change is that the exif column of the tool shows the ExifVersion as 0220, whereas the xmp column shows ExifVersion 0221.
(ii) I can say that C1 is removing all of the maker notes, which might be automatically caused by changing one field of data.

Just about to leave for a new test with the Sony version of C1.

[fbungarz]

I am using an application called pyexiftoolgui

OK that is simply another GUI based on Phil Harvey's ExifTool. For checking independently, which data are there that'll do.
Good luck figuring out the culprit...

[vlad]

In my experience Hert has always been extremely attentive to metadata issues.

That's my impression too. I can only hope that Hert continues to show the same level of attention.

When there was a bug with how IDI wrote metadata it got fixed quickly.

Generally, as a user, I expect bug reports involving metadata handling (and, especially, metadata integrity) to be treated as high priority. Everything's groovy, as long as this happens.

I don't know where the problems lie, but if C1 is causing the problems, some applications can live with that.

Without knowing anything else about C1, this statement alone would make me wary of the chances to persuade the C1 developer that there's something intriniscally wrong in the way C1 handles metadata.

[Larry56]

C1 removes some maker notes and thus clears lens information when processed to jpg. In my conversation with C1 they said they were following standards that metadata information should be in only one area and so they were following standards and I should talk to the developer of PSu. They never did answer my question why processed files from Lightroom nor Dxo did not remove the lens information and PSu did not have any problems showing the data.

I have no idea about "standards" nor what exactly PSu does when I have to Convert Metadata to XMP after using C1. That type of information goes way past me but my belief is that C1 is not really interested in fixing it as they don't think they are doing anything wrong.

There are other issues with C1 one of which is they do not follow color label conventions. They ignore existing label assignment and replace with "No Label" in processed files. In PSu those show as gray in color. When I reported it as a bug they replied, in summary, that they weren't going to do anything about it. Again LR and Dxo keep color labels where C1 doesn't. Note too that it's not that they clear the label field, they actually replace it with "No Label" as the color.

I like a number of things about C1 but don't use it much because of the extra work to replace information I find useful.

[fbungarz]

Hi Larry,
what you write about C1 sounds pretty scary. Looks like they are completely ignorant/arrogant about how their metadata handling affects other software.

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, then do the adjustments to that version in C1 and afterwards use PSu to cascade the metadata back into the version that was just messed up by PSu. Would that work? You could even assign a custom placeholder called P1 to these versions...
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.
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.
Else, this could be a possible workflow:

(1) Main version -> convert metadata to XMP = migrates all data that needs to be preserved to XMP.
(2) Make a copy of the Main Version and assign it to placeholder "C1 version"
(3) Adjust the "C1 version" in C1 = consequence is some metadata get deleted/corrupted
(4) Back in PSu cascade from Main Version (with intact XMP that also contains other converted metadata) to the C1 Version
(5) Data should now be back in C1 Version again...


Just thinking out loud

Frank

[Larry56]

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.

The C1 processed is missing the lens information and I know I can copy it from the existing RAW or if I have another jpg I can copy from there. I then have to change color label and do without some missing medatada such as metering mode.

In a test I just did, a camera generated jpg had the lens information in both aux and exifEX in the XMP as well as Lens and Lens Model in the XMP in Exiftool. After processing in C1 the information is still shown. However when loaded in PSu it does not display the camera information nor the ISO, f-stop, ss, or focal length. It does display the lens information.

After converting to XMP in PSu everything displays except the lens information.

I know that PSu modifies the metadata because when I look at it after conversion to XMP some information is missing but I don't know which fields PSu reads for display purposes.

This is all way over my head....