Ok so I've left the TIF behind now and focusing on the RAW (ORF). Some issues persist:
1. My custom profile still does not clear any values permanently (but I have suspicion this is a global issue and not related to the file, perhaps I'll leave it for now and create a separate support case for it).
2. Still cannot change any values for the camera lens, except for temporarily (if I do a Option + Command + S the old values comes back, even after I saved the file).
3. I keep getting old keywords imported, and added to the Miscellaneous category. I clean those out, remove the old XMP sidecar and save the file. The new XMP sidecar does not contain the Miscellanous reference. However, if I then run the "Option + Command + S" all the old keywords come back, both to PSu and the XMP sidecar. So certainly they are embedded in the RAW itself.
This is all pointing towards (please correct me if I'm wrong) faulty XMP data embedded in the RAW, and worse with no possibility to correct it in PSu. I will look into if perhaps this can be stripped completely, using EXIF Pilot or similar.
Question about "Details" section
Re: Question about "Details" section
Unless the image file doesn't support XML or you have the sidecar option set then the XML will be in the image file itself. See the top section of the Sync settings in the config file for the various ways of storing XML.
Geoff Mather (G8DHE)
Re: Question about "Details" section
I apologize for joining this late, but I just saw Hert's post on versioning vs. stacking:
Stacking is a relatively new feature and, as I understand it, different from versioning. I believe the original concept was:
Versions = same image, but different versions, e.g., the original raw file, perhaps a jpg for emailing, a TIFF for printing, etc.
Stacks = different images that belong together, e.g., a panorama, a focus stack...
Now, I use versioning a lot, essentially all my images are versioned. I rarely uses stacking at all.
What always did irritate me a little:
Keywords are always automatically assigned to all images in a version set. XMP metadata not. So, you can assign different ratings and color labels to different images within one version set, and you can assign a different headline, a different description, etc. to these images - even though, logically they are one and the same image, i.e.: versions.
There is a registry hack to enable that ratings and color labels are also assigned automatically to all images in a version set. But the other metadata (XMP) can be different across the different images that are all part of one version set.
This, I always found counterintuitive. Why treat versions of the same image differently when it comes to applying metadata to them?
One reason that I have heard, but found little convincing:
Versions can be images derived from the original, but not identical. Say a crop of an image now only shows one person in an image that previously would show two different ones. Thus, one might to change the title of that derivative image. However, if I assign "person A" and "person B" as a keyword to one of the images, the whole stack gets labeled that way, even the photo that (after the crop) no longer shows "person B"...
Anyway - I thought it might be helpful to clarify here, why there may be perceived metadata discrepancies in your images. The half-baked XMP from other tools is a huge problem and Capture One is particularly notorious for that. Best, if there is an option to not let other tools touch your metadata at all. But many programs will inadvertently mess up metadata, even if they are configured not to do that.
Still - I thought I'd mention that, particularly when it comes to versions, metadata discrepancies will almost happen by default. Personally, I consider this a design flaw and I wish I would not have to cascade metadata. Even though I try to very diligently and regularly cascade the metadata across my version sets, I still very regular come across files that are members of the same version set, but contain different metadata. It is something that I learned to live with and easily remedied by regularly cascading from the main to all subversions.
There is one important aspect of this, perhaps quite useful in the context of the original post: if other tools mess up your metadata, you can bring these images in again as versions and cascade the undamaged metadata back into these files from the main version that still has the original, undamaged metadata. I use that a lot. This is actually very useful. When developing raw files in external editors and XMP gets messed up by these tools. I set the edited image as a version of the original and then cascade the metadata from the original to the derivative and "voilá" - metadata fixed.
Since Hert mentioned the option to cascade metadata between images of a version set, I thought I chime in, because I am using that a lot.I hoped others would chime in because I think you need the cascade metadata feature that is part of Stacking or Versioning (I prefer stacking over versioning). I never use metadata cascading for my workflow but I know others do.
Stacking is a relatively new feature and, as I understand it, different from versioning. I believe the original concept was:
Versions = same image, but different versions, e.g., the original raw file, perhaps a jpg for emailing, a TIFF for printing, etc.
Stacks = different images that belong together, e.g., a panorama, a focus stack...
Now, I use versioning a lot, essentially all my images are versioned. I rarely uses stacking at all.
What always did irritate me a little:
Keywords are always automatically assigned to all images in a version set. XMP metadata not. So, you can assign different ratings and color labels to different images within one version set, and you can assign a different headline, a different description, etc. to these images - even though, logically they are one and the same image, i.e.: versions.
There is a registry hack to enable that ratings and color labels are also assigned automatically to all images in a version set. But the other metadata (XMP) can be different across the different images that are all part of one version set.
This, I always found counterintuitive. Why treat versions of the same image differently when it comes to applying metadata to them?
One reason that I have heard, but found little convincing:
Versions can be images derived from the original, but not identical. Say a crop of an image now only shows one person in an image that previously would show two different ones. Thus, one might to change the title of that derivative image. However, if I assign "person A" and "person B" as a keyword to one of the images, the whole stack gets labeled that way, even the photo that (after the crop) no longer shows "person B"...
Anyway - I thought it might be helpful to clarify here, why there may be perceived metadata discrepancies in your images. The half-baked XMP from other tools is a huge problem and Capture One is particularly notorious for that. Best, if there is an option to not let other tools touch your metadata at all. But many programs will inadvertently mess up metadata, even if they are configured not to do that.
Still - I thought I'd mention that, particularly when it comes to versions, metadata discrepancies will almost happen by default. Personally, I consider this a design flaw and I wish I would not have to cascade metadata. Even though I try to very diligently and regularly cascade the metadata across my version sets, I still very regular come across files that are members of the same version set, but contain different metadata. It is something that I learned to live with and easily remedied by regularly cascading from the main to all subversions.
There is one important aspect of this, perhaps quite useful in the context of the original post: if other tools mess up your metadata, you can bring these images in again as versions and cascade the undamaged metadata back into these files from the main version that still has the original, undamaged metadata. I use that a lot. This is actually very useful. When developing raw files in external editors and XMP gets messed up by these tools. I set the edited image as a version of the original and then cascade the metadata from the original to the derivative and "voilá" - metadata fixed.
Re: Question about "Details" section
As it turns out.... I think I do see the issue...
Start with NEF (or any raw file) imported into PSU
Use editing tool (C1) to create JPG
Use "Verify Folder > Quick"; JPG is found
PSU reports " File Not in Catalog [ 1 ]"
In PSU dialog; select "Start processing"
File is imported onto catalog... but the Meta data is not there...
Next step
Right click image
Metadata > Convert Metadata to XMP
... all is right with the world...
Is there a way to have the "Metadata > Convert Metadata to XMP" be part of the "Files Not in catalog > start Processing" routine?
Start with NEF (or any raw file) imported into PSU
Use editing tool (C1) to create JPG
Use "Verify Folder > Quick"; JPG is found
PSU reports " File Not in Catalog [ 1 ]"
In PSU dialog; select "Start processing"
File is imported onto catalog... but the Meta data is not there...
Next step
Right click image
Metadata > Convert Metadata to XMP
... all is right with the world...
Is there a way to have the "Metadata > Convert Metadata to XMP" be part of the "Files Not in catalog > start Processing" routine?