News:

IMatch 2025 is Available.
And it is awesome! See IMatch 2025 - What's New? for everything important.

Main Menu

[BBD] Import and tag: XMP-iptcExt] PersonInImage

Started by Uwe, January 11, 2025, 10:31:33 AM

Previous topic - Next topic

Uwe

Hello,
I am currently importing about 200000 files into Imatch. All files have the tag in the metadata (either directly or in the xmp sidecar file): [XMP-iptcExt] Person In Image filled with content.  However, the yellow pencil is activated for each file, indicating that unwritten metadata is present. This is exactly the tag: [XMP-iptcExt] Person In Image. The import writes the tag to the DB and also displays it in the panel (see screenshots). DB and tag in the metadata of the file therefore match from my point of view and there should therefore be no reason to update 200000 files.
Best regards, Uwe

Translated with DeepL.com (free version)

IMatch_2023_PersonInImage_01.jpgIMatch_2023_PersonInImage_02.jpg IMatch_2023_PersonInImage_03.jpg

Mario

This behavior is by design.
This is just how this is implemented. There are no special cases for PersonInImage and the entire metadata handling in IMatch is mind-boggingly complex already. 

I'm sure this is not the only tag that is changed, there are also digests (checksums) and metadata timestamps involved/created/updated when files are imported.

hluxem

QuoteI'm sure this is not the only tag that is changed,
I never liked this behavior, doesn't make sense to me to write back something which has not changed.

QuoteI'm sure this is not the only tag that is changed,
I just did a fast check, duplicated 10 pictures and imported them. Only images with Persons need write back and only the [XMP-iptcExt] Person In Image tag is listed.
I actually did cancel the write back queue for files I knew they hadn't changed. (Probably not recommended by Mario :>))

Maybe when Imatch 2025 is out and running smoothly you can revisit this as I believe this happens only with the Person tags.

Heiner

Mario

#3
This is really, really complicated. Tons of side-effects, sequence of operations, asynchronous processing of metadata, XMP face regions, links to person creation, all updating metadata is an undetermined sequence for performance reasons.

During file import, faces may be found for the face regions or not. Links must be created or not, depending on user options...

Franky, I have invested so much time (days of work!) because of Uwe's demands regarding PersonInImage, I think enough is enough for now.

I have no problem spending days of work in my spare time to work on features beneficial for many users. Much less so on features only one user or less than a handful need.

Maybe several hours or probably even days of work to prevent PersonInImage to become marked in all possible situations of existing face regions, link settings, PersonInImage options and existing metadata in the file.

I guess this is a "behavior by design".

Feel free to add a feature request so I can see how many users are really affected by this.

Adding a file to a database and the only tag that is marked as pending is PersonInImage happens most likely only under one condition: The file was already in an IMatch database and IMatch has written and synchronized all metadata, digests and mapped between all standards so the metadata is clean and complete. Else there will always be some timestamps or other tags to write back.

Which is exactly the situation you produced by duplicating images in a database. I doubt this really happens in the wild (often).