Gary,
This is a bit complicated.
The iPhone writes out XMP for its HDR gain map (which BTW is not packetized as is required when embedding XMP). This is not supposed to be "normal" XMP for storing IPTC type of data. This XMP is also not "tied" to the "main" image for HEIC (as you may be aware of there are multiple images in an HEIC file, but only one is the "main" image).
PM used to get tripped-up by this HDR XMP and update IPTC etc in there. This was not correct. So we fixed this a while back (last year?) to add a new XMP block and tie it to the main image (and of course packetize it). But since we had this previous bug, I made it so PM would at least try to retain any IPTC/XMP that was written by older versions in the HDR XMP, but it ignores the HDR gain map XMP.
So I think what is happening is that PM is picking up the XMP you added in Photos app, but this is also not tied to the main image, so PM doesn't update it, but it at least carries forward the APPLETITLE and AppleCaption and AppleKey values. It doesn't carry forward any HDR metadata. So now there are 3 XMP blocks.
The use of the "-G" option in exiftool is a red herring because it appears to group all 3 XMP blocks together. For example, only the HDR XMP block has HDR XMP.
However you did find what may appear to be a "bug". When we added support for the Plus Data Mining field, this is a bit unusual because it has no "undefined" value. It has an "unspecified" setting. Our UI is a popup menu and this is default value if the original XMP has no data mining value. So when PM writes out the XMP, it adds the "unspecified" value. This isn't technically incorrect - you didn't specify your choice for data mining. We could potentially prevent PM from adding this in, but it isn't a "bad" thing, right? If you don't specify this, then AI engines can use your photos for training (for example).
I need to dig into how Apple is actually adding their XMP in Photos. It may be incorrectly not tied to the main image. And furthermore, it could be that LR classic also has a problem. But since Preview app on Mac doesn't show PM's metadata either, it could be that both LR and Preview have a "bug". The "bug" could be that they find all these XMP blocks, but only pay attention to the first one (written by Photos not HDR) and ignore any further XMP (that PM writes). I think PM will use the last XMP block by default (this can be changed in IPTC/XMP prefs). I don't know until I debug which I can't do right now.
In any case, this is the actual XMP that PM is writing out.
<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="XMP Core 5.6.0">
<rdf:RDF xmlns:rdf="
http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about=""
xmlns:dc="
http://purl.org/dc/elements/1.1/"
xmlns:photoshop="
http://ns.adobe.com/photoshop/1.0/"
xmlns:xmp="
http://ns.adobe.com/xap/1.0/"
xmlns:plus="
http://ns.useplus.org/ldf/xmp/1.0/"
xmlns:exif="
http://ns.adobe.com/exif/1.0/"
xmlns:photomechanic="
http://ns.camerabits.com/photomechanic/1.0/"
xmlns:aux="
http://ns.adobe.com/exif/1.0/aux/"
photoshop:DateCreated="2024-10-27T09:54:47-04:00"
xmp:CreateDate="2024-10-27T09:54:47-04:00"
xmp:Rating="0"
plus:DataMining="
http://ns.useplus.org/ldf/vocab/DMI-UNSPECIFIED"
exif:GPSLatitude="40,35.169N"
exif:GPSLongitude="75,22.533W"
exif:GPSAltitudeRef="0"
exif:GPSAltitude="1461/10"
photomechanic:ColorClass="0"
photomechanic:Tagged="False"
photomechanic:Prefs="0:0:0:002684"
photomechanic:PMVersion="2024.8.7765"
aux:ImageNumber="2684">
<dc:subject>
<rdf:Bag>
<rdf:li>PM6KeyWord</rdf:li>
</rdf:Bag>
</dc:subject>
<dc:description>
<rdf:Alt>
<rdf:li xml:lang="x-default">PM6Description</rdf:li>
</rdf:Alt>
</dc:description>
<dc:title>
<rdf:Alt>
<rdf:li xml:lang="x-default">PM6Title</rdf:li>
</rdf:Alt>
</dc:title>
</rdf:Description>
</rdf:RDF>
</x:xmpmeta>
Hope that helps for now until I have time to do more digging...
--dennis
