feat(web/server): merge faces

[alextran1502]

This PR adds the mechanism to merge faces and assets belonging to the faces for the Facial Recognition feature.

Screencast.from.2023-07-09.20-23-16.webm

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Ignored Deployment

Name	Status	Preview	Comments	Updated (UTC)
immich	⬜️ Ignored (Inspect)	Visit Preview		Jul 11, 2023 3:00am

[alextran1502]

@jrasm91, @uhthomas Open a PR for review of the backend part when I am starting to work on the FE

[uhthomas]

I haven't had the time to take a proper look at this, sorry. It looks mostly good, though there are a lot of individual SQL operations happening. I have a feeling a majority of this could be consolidated and would be both more performant and more clear.

[uhthomas]

I feel like this could probably be just one SQL query.

[jrasm91]

Personally I think the client can indicate the primary person. People are sorted by count so the web could always use the first named person to achieve the same thing. The server code would be a lot cleaner if it worked like that.

[ShinasShaji]

@jrasm91: Personally I think the client can indicate the primary person. People are sorted by count so the web could always use the first named person to achieve the same thing. The server code would be a lot cleaner if it worked like that.

Apologies for my unsolicited opinion, but I personally think there could be value in allowing users to customize the order of people in their people page - hence, I think abstracting away the merging logic to the server could have its benefits.

[jrasm91]

Apologies for my unsolicited opinion, but I personally think there could be value in allowing users to customize the order of people in their people page - hence, I think abstracting away the merging logic to the server could have its benefits.

The only difference between merging Person A into Person B opposed to merging Person B into Person A is:

• You keep Person A's name, instead of Person B.
• You keep Person A's thumbnail instead of Person B.

I don't see any advantage/benefit to adding a lot of complicated code in the server in order to automatically infer who's name and thumbnail you want to keep. Specifically by looking at asset counts. IMO it should be specified in the API request, by the client, and I think it would work fine if the web just used the first selected person or the left-most person with a name as the algorithm for that. The complexity server-side would be considerably simpler.

(even in the case the user got it wrong, the name and thumbnail can be easily changed after the merge too)

[ShinasShaji]

I don't see any advantage/benefit to adding a lot of complicated code in the server in order to automatically infer who's name and thumbnail you want to keep. Specifically by looking at asset counts. IMO it should be specified in the API request, by the client, and I think it would work fine if the web just used the first selected person or the left-most person with a name as the algorithm for that. The complexity server-side would be considerably simpler.

(even in the case the user got it wrong, the name and thumbnail can be easily changed after the merge too)

It seems I may have slightly misunderstood your intent in your previous comment, my apologies. I agree with not using asset counts to determine the 'original' person - it does seem like a lot of work for what could be, to be frank, a coin toss (determinism is always better though); it might as well be specified by the client.