recognize icon indicating copy to clipboard operation
recognize copied to clipboard

Import XMP face regions

Open ericnotthered opened this issue 2 years ago • 1 comments
trafficstars

Describe the feature you'd like to request

I have a large number of images (tens of thousands) that I have tagged with face regions. This has involved countless hours using automated tools (such as Adobe Lightroom, Digikam, Picasa, etc) and performing manual adjustments, additions and corrections.

I would like to be able to import existing XMP face regions from these images into Recognize.

Note that one could leverage these existing regions to facilitate training for Recognize.

Describe the solution you'd like

A command line and/or UI function would import existing XMF face regions into the Recognize database, and run training for each of the individuals and their associated regions.

MVP

  • Import MWG XMP face regions (used by all of the above common tools), overwriting any existing face regions.

Possible Extended Features:

  • Merge XMP regions with existing face regions by name. Imported duplicate face regions in a given image can be either ignored or can replace the existing region (user option).
  • Re-import changed XMP region information and update corresponding image information in Recognize.
  • Support other face region standards.
  • Specify name or names of persons to import

Describe alternatives you've considered

Re-tagging faces using Recognize: This is very undesirable, as it wastes a tremendous amount of prior work, as well as wasting valuable verified face correlations.

ericnotthered avatar Mar 21 '23 21:03 ericnotthered

I love the MVP for this. I wonder if a job could be created to pre-load or correct the cluster for any data found in metadata. For instance, lets say recognize identified a face in picture1 and another face in picture2, and during clustering it decided those two faces were in different clusters. Maybe the job could look at the potentially/hopefully overlapping face regions in those photos and see that they are tagged with the same name and correct the clustering. This might involve adding the names from the XMP metadata into the oc_recognize_face_clusters table.

Conversly, if recognize finds faces in picture1 and picture2 and decides they are the same person/cluster, then upon scanning the XMP it finds those faces named different things, that should be a really big hint NOT to cluster those two faces.

Even if the names themselves from the XMP weren't preserved, just using those as hints to get better at clustering would be a huge improvement. This could provide a way for someone to influence recognize to understand that two faces were or were not the same. If recognize makes clustering mistakes, a person could open digikam, tag the mistaken person in that photo manually, and then re-run clustering. Eventually hopefully updating those names in XMP could be built into Nextcloud somewhere, but initially if the images had to be edited externally I think this could still be a big win.

Fundamentally this conversation is similar to the one in #83. In my opinion, ideally the metadata should live inside the image (or an XMP sidecar). That way users can move their images and their associated metadata to other apps. The databases inside Nextcloud would be a reflection of the trusted metadata extracted from the images, and any extra metadata needed for display/sorting purposes inside Nextcloud/Recognize. I feel like READING the metadata is the first step, writing it could come later. Basically, in the ideal situation face metadata would operate just like GPS metadata, and creation date metadata. For the most part people assume those data types live with the pictures and are transportable between apps. Hopefully one day we get there with face metadata also.

rhatguy avatar Mar 23 '23 15:03 rhatguy