[Feature Request] Allow choosing primary photo for person

[meichthys]

Currently there is no way to choose which photo shows up as the primary 'cover photo' for a person. It would be nice to select one of the photos to use.

[chadsell]

Yes please! Not only would this be good for when, say, the default photo isn't very flattering, but also: I have had it happen that the photo automatically selected as the cover photo is not the correct person to represent the rest of the cluster. It would be very awkward for the cover photo of my sister's cluster to show an image of my wife!

[meichthys]

It would be very awkward for the cover photo of my sister's cluster to show an image of my wife!

In this scenario you could just remove the offending photo from the person since the detection is obviously wrong (even though your sister may be in the photo)

You can enable squares around faces to see which face is being compared.

[chadsell]

I did that, actually. I went through and moved any mis-clustered photos to the correct person, and still when I was done I had two clusters with cover photos that didn't match the person that the cluster was for. It stayed like that for around a day or so before I ended up migrating my photos and files to a new user for completely unrelated reasons. After the migration, Recognize re-scanned everything, and this time the cover photos were correct. But if I hadn't done that, I have no idea if the issue would have resolved, and just assumed it probably wouldn't.

[pulsejet]

@chadsell the previews are cached by the browser for 24 hours.

[chadsell]

Ah, that makes sense. I guess I would have found that out if I didn't have to reset my profile!

[g3n35i5]

@pulsejet I'd love to implement this feature but after spending a few hours digging in the backend, I really don't know how to proceed since I'm not familiar with php at all. If you could give me some hints on how to implement this feature in the backend, I could give it a try.

These a my thoughts on the implementation so far:

• UI button is located in the person image view (see screenshot below)
• Is there an existing database table/column to store this information? If not, do we need a new table or can we add a column to an existing table?
  • There is no need for a history of the cover images selected for a person in my opinion. So a dedicated table for this with a mapping (user id, image id, face rectangle, timestamp) is too much
• Implementation must be backwards compatible. If a person doesn't have a manually selected cover image, the current implementation must be used
• If the cover image is being deleted or it is removed from a person, the entry must be deleted from the database as well

[pulsejet]

You're on the right track.

• Is there an existing database table/column to store this information? If not, do we need a new table or can we add a column to an existing table?

There isn't, which is the main problem. We use various backends for clusters

1. Faces from Recognize
2. Faces from Face Recognition
3. Albums from Photos
4. Tags from server

Ideally these backends themselves should implement a column in their table that maintains the cover image. This way there is complete interoperability with other Nextcloud apps. For example, this would ensure that the cover image in Photos is the same as Memories for faces and albums.

Unfortunately, I don't see the cover implementation happening any time soon in the backends. So one way to move forward here would be to have a dedicated memories_cluster_cover table that maps the cover of a cluster to an object ID. In the case of faces, the object ID would map to the detection ID and for others it would map to the file ID. The table might look like

+--------------+-------+------------+-----------+
| cluster_type | user  | cluster_id | object_id |
+--------------+-------+------------+-----------+
| albums       | admin |         25 |     52332 |
| albums       | admin |         52 |      2343 |
| albums       | user1 |         52 |      3242 |
| recognize    | admin |         41 |      3233 |
+--------------+-------+------------+-----------+

Note that the above structure allows a JOIN in the main cluster list query itself, making it magnitudes more efficient than the current mechanism.

• There is no need for a history of the cover images selected for a person in my opinion. So a dedicated table for this with a mapping (user id, image id, face rectangle, timestamp) is too much

I agree there's no need for a history. But it is a bit more nuanced in certain cases when sharing is involved. For example,

1. Multiple users can see an album (e.g. say album 52 above)
2. Can each user set a cover photo? Or does the album have only one cover photo shared by everyone?
3. In case the cover is shared, who sets it? Anyone? The owner?
4. Or a mixture of the two, e.g. fallback to what the owner sets but allow each user to set a cover for themselves.

Of course, for this particular issue, this won't be an issue since face detections are not shared but per-user.

• Implementation must be backwards compatible. If a person doesn't have a manually selected cover image, the current implementation must be used

Correct. The current scoring mechanism is quite complex and CPU-heavy, so this will open up the possibility to set up a periodic cron job to assign covers instead. This way we don't need to do this on-demand.

• If the cover image is being deleted or it is removed from a person, the entry must be deleted from the database as well

Another pain point. The only "correct" way to do this is to listen to hooks from the individual backends (assuming such hooks even exist). But this might be too much maintenance overhead, so I don't mind checking this on-demand. It might be possible to write a single query to check the existence of multiple cover images in their individual clusters, following which we can invalidate anything that isn't right. If such a query is possible, then it is reasonable to perform this every time the cluster list is fetched (but of course, we can't do this if one query is required per-cluster).

[pulsejet]

Implemented with #1071