Writing changes removes colour label

Stefanjan · November 30, 2022, 02:29:53 PM

Puzzled. I have 3 files:
Master CR3
Version jpeg
Version AFPHOTO

I change the label to green on the master. Both Versions change label to green.
Click pencil on master to write changes back, master and versions no longer have green label.

Would appreciate a hint as to what might cause this behaviour.

Mario · November 30, 2022, 02:34:46 PM

Sounds like a conflict in metadata to me.

Run the Metadata Analyst on the Master and use the GREEN button to copy the results.
Does the master have embedded XMP data perhaps? It should not.

Check the ExifTool output panel for warnings reported by ExifTool.

I assume you click the pen on the master when you write back?

Do all the files resist in the same folder?

Stefanjan · December 01, 2022, 05:35:16 PM

Quote from: Mario on November 30, 2022, 02:34:46 PMRun the Metadata Analyst on the Master and use the GREEN button to copy the results.
Does the master have embedded XMP data perhaps? It should not.

Check the ExifTool output panel for warnings reported by ExifTool.

I assume you click the pen on the master when you write back?

Do all the files resist in the same folder?

See Metadata Analyst result below

I clicked the pen on the master to write back
All the files are in the same folder

Metadata Analyst Results. Version 2021.18.4. 12/1/2022 4:32:13 PM
File analyzed: E:\Current Photos\2022\2022-11-30 ¦ Theo\2022-11-30 ¦ CR7_00089075.CR3
Errors: 0
Warnings: 23

Warning: [System] File has unwritten metadata (pending write-back).<br/>The metadata loaded from the image and the data in the database may not match.
Warning: [Metadata] Warnings: 'FileName encoding not specified'
Warning: [GPS] Date missing.
Warning: [GPS] Time missing.
Warning: [GPS] Latitude missing.
Warning: [GPS] Latitude Ref missing.
Warning: [GPS] Longitude missing.
Warning: [GPS] Longitude Ref missing.
Warning: [GPS] Altitude missing.
Warning: [XMP] Embedded XMP record (Unknown) and XMP sidecar file (Image::ExifTool 12.49) found.
Warning: [XMP] Embedded XMP rating is 0.
Warning: [XMP] [ExifIFD]:DateTimeOriginal not mapped to [XMP-exif]:DateTimeOriginal (embedded).
Warning: [XMP] [ExifIFD]:DateTimeOriginal not mapped to [XMP-exif]:DateTimeOriginal (sidecar).
Warning: [XMP] [ExifIFD]:CreateDate not mapped to [XMP-xmp]:CreateDate (embedded).
Warning: [XMP] [ExifIFD]:CreateDate not mapped to [XMP-xmp]:CreateDate (sidecar).
Warning: [XMP] [ExifIFD]:DateTimeOriginal not mapped to [XMP-photoshop]:DateCreated (embedded).
Warning: [XMP] [ExifIFD]:DateTimeOriginal not mapped to [XMP-photoshop]:DateCreated (sidecar).
Warning: [XMP] [IFD0]:Copyright not mapped to [XMP-dc]:Rights (embedded).
Warning: [XMP] [IFD0]:Copyright not mapped to [XMP-dc]:Rights (sidecar).
Warning: [XMP] [IFD0]:Orientation not mapped to [XMP-tiff]:Orientation (embedded).
Warning: [XMP] [ExifIFD]:UserComment not mapped to [XMP-dc]:Description (embedded).
Warning: [XMP] [ExifIFD]:UserComment not mapped to [XMP-dc]:Description (sidecar).
Warning: [Detailed Validation] FileName encoding not specified

Mario · December 01, 2022, 06:02:02 PM

The RAW has an embedded XMP record. It should not.
Use the The ExifTool Command Processor with the "Delete XMP Metadata" preset to remove it. Then retry.
The rating is hard-coded 0, but that should only affect the rating, normally. I have never seen the label being removed.

You can also upload all 3 files to your cloud space and post a link or send it to @@support (with a link back to this topic). Having the actual files causing the problem avoids a lot of guessing.

Stefanjan · December 02, 2022, 11:23:26 AM

Quote from: Mario on December 01, 2022, 06:02:02 PMYou can also upload all 3 files to your cloud space and post a link or send it to @@support (with a link back to this topic).

I've uploaded the files and emailed a link to Mario. Delete XMP Metadata did not solve the problem.

Mario · December 02, 2022, 06:41:33 PM

I have downloaded the sample files and placed them into a folder.
I created a new File Version rule with CR3 as the master and JPG/AFPHOTO as versions.
I enabled the options to propagate rating/label and "All IPTC Core/Ext" tags.

I set the rating of the CR3 to "Red".
The two versions also get a red label.
I click the pen to write back the CR3 master file. This also writes back the two versions.
All files receive the "Red" label.

For the JPEG file, the rating is embedded via the XMP record.
For the AFPHOTO and CR3 file, the red label is written to the XMP sidecar file.
OK.

I force a reload of the metadata for all 3 files.
The "Red" label remains.

What do you do different?
Especially your file relation rule (what do you propagate)?

What I find disturbing is your use of the ¦ symbol (broken vertical bar U+00A6) as part of the file name. This is a special Unicode character and using it in file names may cause issues on other platforms or certain applications. You also us the # in your file names, for extra measure. It should not affect IMatch, but since we're researching a problem...

Try to remove these characters (use plain alphanumerical characters) and see if this solves the problem.

stefanjan2 · December 03, 2022, 01:03:04 PM

After much experimenting I identified my fundamental error. The CR3 and AFPhoto files attempted to create an xmp file with the same name, as soon as I renamed the AFPhoto file the issue dissapeared:

CR7_00089075.CR3
CR7_00089075AF.afphoto
CR7_00089075#f.jpg

I guess when I was writing back to the CR3, when imatch got to updating the afphoto xmp it overwrote the changes in the CR3 xmp. I wonder why that did not happen when you tried.

I'm going to have to come up with a new naming convention. Currently my workflow is as follows:

Either:

Process in Photolab and export as a jpeg with #f suffix to indicate final jpeg.

or

Process in Photolab and then send to Affinity for further processing. Save as an Affinity file and export as a final jpeg. (In future I'll have to make sure my afphoto file has a different name to the RAW, maybe just leave the DXO suffix added by Photolab when sent to Affinity)

Mario · December 03, 2022, 01:23:32 PM

By definition (XMP standard), an XMP sidecar file belongs to all files with the same file name in the same folder.

When you write back, IMatch will:

- embed XMP into the JPEG file and update existing EXIF/GPS data in the JPEG to match the copies of that data in the XMP record.
- update/create an XMP file for the CR3 and AFPHOTO
- update existing EXIF/GPS data in the CR3 to match the copies of that data in the XMP record.

When you rename a file with an associated XMP in IMatch, IMatch does some intelligent things:

- it checks if there is another file with the same name as the XMP
- if there is none, it just renames the XMP to match the new file name
- otherwise it creates a copy of the XMP with the new file name

This way the link between the image you rename and the XMP will not break.

If you use other software or even Windows Explorer to rename your files, you need to take care for this yourself.
But doing so would be an easy way to shot yourself into your own foot.

'Special' workflows, file naming conventions, distribution of files across folders or disks are also ways to shot yourself into your own foot. Simple is better.

If you want to maintain separate XMP data for the CR3 and AFPHOTO file, keep them in separate folders.

David_H · December 03, 2022, 07:47:49 PM

Quote from: stefanjan2 on December 03, 2022, 01:03:04 PMProcess in Photolab and then send to Affinity for further processing. Save as an Affinity file and export as a final jpeg. (In future I'll have to make sure my afphoto file has a different name to the RAW, maybe just leave the DXO suffix added by Photolab when sent to Affinity)

set the 'Destination' in DxO to Custom Folder and the Path to something (don't use the picker) like Altered , Output or Processed or something, and when DxO creates the jpg, it'll be in a subfolder which your versioning rules can pick up easily.