Last post by Mario - November 28, 2022, 07:01:25 PM
This is indeed a problem caused by Apple. The phone write an invalid XMP record, and this causes ExifTool to duplicate the XMP data during writing. See this thread in the ExifTool community for more details: https://exiftool.org/forum/index.php?topic=14218
There is not really something I can do from the IMatch side, not without risking causing issues for all other users who don't have to deal with iPhone 14 files with invalid XMP metadata.
This reminds me of the face regions some Apple phones write into the XMP, with both width and height always being 0. Apple software deals with this silently, but you run into trouble once you dare to leave the Apple world and open your images in another software which understands XMP face regions.
IMatch contains a work-around for this Apple bug. I see these files in the wild still today, so probably Apple has never fixed it. I don't have Apple products. But maybe you can tell them that the XMP this phone writes is non-standard and incomplete and will mess up workflows everywhere?
Axel creates smaller sized copies of his JPEG files to transport them. This is a quite unusual workflow. He requests a feature to tell IMatch to not use the smaller cache images when he has access to the original JPEG files. This is an unusual workflow and hence the request has no likes yet - except yours, probably for the wrong reasons. Unless you also force IMatch to create smaller versions of your JPEG files in the cache - but you did not tell us that yet so I don't know.
Axel has only about 600GB of original JPEG files. It would be cheaper for me to buy a 1TB USB stick and send it to him so he can take all his images with him when he travels. No need to use resized copies of his JPEG files in the cache, no copying of files, no need for the feature he has requested. A 1TB USB stick costs about 100US$, and for that sum I cannot design, develop, debug, test and document the feature he has requested. If not at least a couple of users have the same problem, this will not be implemented.
Last post by Mario - November 28, 2022, 11:14:43 AM
I have tried to reproduce this.
1. Under Edit > Preferences > Metadata I set "Import XMP Face Regions" and "Export Face Annotations to XMP" to "No". 2. For a JPEG file with a person I create a face annotation in Lightroom and let Lr write back the XMP data. 3. IMatch re-imports the file but does not create a face annotation. OK.
4. I change title, headline, rating and label in the Metadata Panel and write back. 5. The XMP face regions written by Lr remain untouched in the file. Verified with ExifTool. Nothing is removed. OK.
6. Switch IMatch back to the default values for XMP face region import/export. 7. Run Shift+Ctrl+F5 > Reload Metadata 8. IMatch now reads the XMP face region and creates a corresponding face annotation. 9. Person is automatically detected and assigned to the new face annotation.
From my end this looks as it is working perfectly. Anything different you do?
[XMP-x] XMP Toolkit : XMP Core 6.0.0 [XMP-semanticSegmentationMatte] Semantic Segmentation Matte Version: 65536 [XMP-apdi] Auxiliary Image Type : urn:com:apple:photo:2020:aux:semanticskymatte When I change the headline to "IMatch" and write back, the XMP record in the file is duplicated and the XMP headline tag exists twice afterwards. This appears to be an ExifTool issue.
When I first delete the existing XMP record using the ExifTool Command Processor preset "Delete XMP Metadata" (nothing of value is lost in this case) and then change metadata and let IMatch write back, the duplication does not happen! I can change metadata any number of times without metadata getting duplicated.
I assume that something in the partial XMP record written by Apple, in conjunction how IMatch writes metadata somehow confuses ExifTool in this case and causes the duplication.
I will report this in the ExifTool community and see what we can find out.
Tip: If you run the "Delete XMP Metadata" preset in the ECP on these files, IMatch works correctly afterwards and you can enter and write-back metadata.