XMP Description not propagating to versions

[jch2103]

This is probably user error, but I'm finding in my NEF Versioning that XMP Description isn't propagating from nef to jpg versions despite the check mark being enabled in Versioning. Propagating XMP Keywords does work if enabled.
I've attached the log for a session where I made a change in XMP Description for one file; look for DSC_1042.

Below are the Link expressions I'm using.

NEF Buddy Files
^(_*{name})[+\-_]*[0-9|a-z]*\.(jpg|jpeg|dng|nef\.dxo|nef\.dop)$

NEF Versioning
^(_*{name})[+\-_]*[0-9|a-z]*([_|0-9|a-z])*\.(jpg|jpeg|psd|tif|tiff|dng)$

[Mario]

Open the ExifTool output panel and then to a propagation.
This shows the commands IMatch is sending to ExifTool.

[jch2103]

ExifTool output panel below. I don't understand the warnings, specifically why the .jpg file shows forward path slashes instead of back slashed.

These are ten year old files, so no telling what/how they've been handled.

ADMIN: Large block of data removed from the file and converted to an attachment.
Please don't include so much log data in your posts. It bloats and confuses the community search engine. Always use attachments. I know, that's harder to just using copy and paste.

[Mario]

ExiftTool copies data from
D:\John\Pictures\D90\2009_1115\DSC_1042.NEF to D:\John\Pictures\D90\2009_1115\DSC_1042_DxO_raw.jpg
It also tries to copy from D:\John\Pictures\D90\2009_1115\DSC_1042.XMP but there is no XMP file (hence the warning). Not a problem.

Then IMatch tells ExifTool to set the description:

-XMP-dc:Description-x-default=New Zealand pasture land on route from Auckland to Waitomo and then Lake Rotorua.
-XMP-tiff:ImageDescription-x-default=New Zealand pasture land on route from Auckland to Waitomo and then Lake Rotorua.
-XMP-exif:UserComment-x-default=New Zealand pasture land on route from Auckland to Waitomo and then Lake Rotorua.
-XMP:CreatorTool=photools.com IMatch 19.8.0.4 (Windows)

Which is probably why the propagation is not working. The description has not been set when you propagate.
What exactly are you doing, in which order. Had the master pending write-backs at the time etc....

[jch2103]

ExiftTool copies data from
D:\John\Pictures\D90\2009_1115\DSC_1042.NEF to D:\John\Pictures\D90\2009_1115\DSC_1042_DxO_raw.jpg
It also tries to copy from D:\John\Pictures\D90\2009_1115\DSC_1042.XMP but there is no XMP file (hence the warning). Not a problem.

Then IMatch tells ExifTool to set the description:
...
Which is probably why the propagation is not working. The description has not been set when you propagate.
What exactly are you doing, in which order. Had the master pending write-backs at the time etc....

Hmm. Except:
The XMP file does exist.
Yes, the description had been set in the NEF original: I had changed the Description (no other changes) via a metadata panel. That caused a yellow pen for the NEF indicating that there was a pending writeback. I clicked it, and got the ExifTool output in the earlier post. The metadata panel for the NEF was updated, but the metadata panel description in the jpg version didn't change. I'm confused.


After doing some further checking, I'm finding discrepancies in the 'description' tags in my jpg output files. After changing the description in the NEF original (to 'Dairy cows on a hill in the countryside near the Glowworm Caves."; i.e., deleting the word 'high' in the NEF), this is the ExifTool ECP List Metadata output for description tags in the jpg file:

[IFD0]          Image Description               : Dairy cows high on a hill in the countryside near the Glowworm Caves.
[ExifIFD]       User Comment                    : Dairy cows high on a hill in the countryside near the Glowworm Caves.
[XMP-dc]        Description                     : Dairy cows on a hill in the countryside near the Glowworm Caves.

So it seems that the relations versioning for 'XMP Description *' is making some but not all necessary changes in description metadata...

Next, I edited the jpg file by itself (to change Description to 'Dairy cows', and got this from ECP List Metadata:

[IFD0]          Image Description               : Dairy cows
[XMP-dc]        Description                     : Dairy cows
[ExifIFD]       User Comment                    : Dairy cows

Lastly, went back to the NEF original and changed the description to 'Cows'. This was the ECP List Metadata output from the jpg version:

[IFD0]          Image Description               : Dairy cows
[XMP-dc]        Description                     : Cows
[ExifIFD]       User Comment                    : Dairy cows

What is very confusing is that the Default metadata template tag for Description is described as 'XMP::dc\description\description\0' but the contents look like they're coming from a different tag (either '[IFD0]Image Description' or '[ExifIFD] User Comment').

Looks to me like some kind of bug in the versioning algorithm. For now, my safest route will be to make metadata changes to both NEF and jpg version files at the same time (i.e., avoid versioning propagation, at least for Description). 

[Mario]

On re-import certain descriptions in the image (EXIF user comment, IPTC caption, ...) will override the description in the XMP.
But that is taken care for usually when IMatch is synching the data during write-back.

I would need sample images, your detailed version settings etc. do reproduce this here.
Since I have already used up my "metadata problem debugging" time for this months, it may take a while until I can spend more time with this.

[jch2103]

On re-import certain descriptions in the image (EXIF user comment, IPTC caption, ...) will override the description in the XMP.
But that is taken care for usually when IMatch is synching the data during write-back.

I would need sample images, your detailed version settings etc. do reproduce this here.
Since I have already used up my "metadata problem debugging" time for this months, it may take a while until I can spend more time with this.

Understood. One of the great things about IMatch is the multiple options available to do things, so I have a workaround. I've created a separate bug report for this issue https://www.photools.com/community/index.php?topic=9337.msg65790#msg65790, referencing this post.