PL5.2.0.4732 mishandling of 'dc' only metadata and losing 'Artist' metadata

BHAYT · April 19, 2022, 9:29am

In another post I finally discovered that PL5 will handle keywords placed in a JPG successfully after my original complaints back in February 2021 in my first PL5 Beta test post!

PL5 will still not detect any real time changes made to the metadata by ExifPro which manages to make those changes without causing the ‘Date last modified’ timestamp to change! Other software does detect in real-time so their detection mechanisms seem to be that bit more sensitive. This particular issue has bugged me from the beginning and still does because of tests where changes simply haven’t been detected successfully by PL5.

However, the good news appeared to be that another fault whereby after a ‘Read from Image’ command successfully imported the ExifPro set metadata into PL5, PL5 would then not be able to make changes to that metadata nor export the JPG!

In the latest release that issue no longer appeared to be a problem so that I could update all the ‘Family’ photos I have been tagging since 2003 - Hooray!

But on checking the images I re-discovered an old issue (I reported about a year ago) and discovered a new one which may well exist in another post (a simple search did not locate it but …).

The problems are:-

The keywords set by ExifPro are placed in the xmp ‘dc’ fields but PL5’s obsession with the hierarchical keys means that it sets the data in the ‘hr’ fields as well! No simple metadata handling software even knows that the ‘hr’ keys exist so any deletions from the keyword data made by those programs will result in no apparent change in PL5.
PL5 appears to have lost my ‘Artist’ data added when ACDSee imported the photos from the SD card!

Outcome:

If a non-‘hr’ aware program deletes the ‘dc’ keywords then PL5 and any other software which is prepared to accept simple ‘hr’ keywords with no ‘dc’ counterpart will also consider that the keywords are still present! Deletion from within PL5 removes both but both should not be there in the first place!!

PL5 should not propagate simple ‘dc’ only keys to the ‘hr’ fields, it may well break the guidelines but in my simplistic brain it is simply wrong and creates way more problems than it ever solves - so why do it???

The loss of the ‘Artist’ field is …???

Hope this post is short enough and too the point.

PS Now I need to recover the data from the backup copies and wait until PL5 actually handles simple keywords and the ‘Artist’ properly!

Additional comparison between before and after PL5 processing:-

Joanna · April 19, 2022, 10:51am

This is more than likely due to ExifPro using the -preserve flag for its call to ExifTool. This is something I do in my own app but PL5 seems to pick up the change nonetheless.

Whether PL5 detects the change or not obviously depends open whether auto-sync is activated or not.

Well, any well behaved software should keep the xmp-dc:subject and lr:hierarchicalSubject tags synchronised.

If ExifPro allows for modification of the xmp-dc:subject tag without a corresponding modification of the lr:hierarchicalSubject tag, then it is ExifPro which is at fault.

Absolutely. But since, according to MWG guidelines, any keywords written to lr:hierarchicalSubject are required to be written xmp-dc:subject, any software should, at least, flag up the inconsistency, or even correct it by updating the xmp-dc:subject.

If keywords written to xmp-dc:subject have no hierarchical context, then they should not be written to lr:hierarchicalSubject. This is something PL5 insists on doing to exported files and which if not strictly wrong, as you say, can lead to external software getting its knickers in a knot.

BHAYT · April 19, 2022, 11:37am

PL5 has never detected it and still does not regardless of the AS(ON) setting! This is less of a problem with the ‘Read metadata from’ but still slightly annoying!

ExifPro, ACDsee, Bridge when configured the way I did my original PL5 Beta testing, Zoner etc. all change the ‘dc’ fields. When ExifPro or the other programs I have mentioned delete keywords from an image they only see and touch the ‘dc’ fields or whatever they do only results in the ‘dc’ fields being changed any ‘hr’ fields set remain as they were!

When I repeated the deletion test in Photo Mechanics deleting my wife’s name from an image where PL5 had added the ‘hr’ keys, i.e. the deletion was from an image with both the ‘dc’ and ‘hr’ keywords set (‘dc’ by ExifPro, ‘hr’ added by PL5), the result was the removal of the name from the ‘dc’ fields and the complete removal of the name and the ‘Family’ keyword from the ‘hr’ fields, i.e. PM left the image as I would have expected it should be left.

Photo Supreme showed no keywords at all in the image with only the ‘hr’ keywords “accidentally left” by the ExifPro delete. The ‘hr’ keywords should not be added by PL5 and then these anomalies would not exist or would not be exposed.

However, PM accepts the situation of only having ‘hr’ keywords and displays the image as having both keywords!!

From memory in previous tests with LR if it was presented with an image where PL5 had added ‘hr’ fields to the 'dc; fields that I then then deleted with Bridge (in my old Bridge configuration), LR would “regularise” the keywords and the image would have no keywords at all, i.e. ‘hr’ without corresponding ‘dc’ = no keywords at all.

As stated above some do some don’t! But it is PL5 that is creating the anomalies!

For both exported images and any images it touches during the processing of keywords, arguably compounded if AS(ON) because as soon as it reads a ‘dc’ only situation it will create the analogous ‘hr’ keys and write them straight to the image and the downward spiral into chaos begins that easily!!??

I have been moaning about this, even considering my lack of keyword knowledge, from my first post early last year when it simply didn’t make sense to my aged IT brain. Regardless of all the guidelines etc. the basic rule of programming “logic” applies, i.e. don’t mess (almost used a profanity there) with anything you don’t need to mess with because “there be dragons” or a large pile of …!!

And I still want my ‘Artist’ back!!

Egregius · April 19, 2022, 6:27pm

As I recall, on export PL5 won’t write “Artist” to the EXIF if the IPTC “Creator” field is populated. Is that what’s happening in your case with ACDSee?

BHAYT · April 19, 2022, 8:03pm

Greg (@Egregius) thank you for your post. I had been responding to another post lamenting the fact that PL5 didn’t like ExifPro when I thought I should check just in case I was maligning DxO and things seemed to work until I studied the results more carefully.

The 'Artist ’ has been in my import specs for various versions of ACDSee for years (the photos in question date from 2005) and these days it is typically ‘Artist’ and ‘Copyright’.

When I looked at the output from PIE as I prepared to have a “moan” about the ‘hr’ fields I realised the data was was missing from all the metadata of those photos that I had accessed with PL5. ACDSee was fine but looking at the Beyond Compare snapshots the data appears to have been put in the ‘Exif’ data by ACDSee way back when and was now missing.

Like an idiot I had used actual data which was now “bent out of shape” so I copied that to a test directory and replaced the “damaged” data with a copy from one of my USB backup drives, so I got a slightly dented ego and concern over what is actually going on.

I should repeat the test with more up-to-date imports to see what happens with the fields.

The answer is nothing in particular! ACDSee puts the data in the xmp and IPTC fields and PL5 finds them successfully and does not appear to do anything untoward with them, i.e. they are still in the metadata after PL5 adds the keyword metadata to the image (in both the ‘dc’ and the’ hr’ fields of course!)

The snapshot is a comparison between the first two photos in the directory with the first having been updated by PL5 with the “Testing” keyword!

This snapshot is a comparison between the original image and the exported image after the keyword “Testing” has been added.