recognize
recognize copied to clipboard
nextcloud
Renaming persons to already existing name, makes the previous person class disappear
Which version of recognize are you using?
3.5.0
Enabled Modes
Face recognition
TensorFlow mode
WASM mode
Which Nextcloud version do you have installed?
25.0.3
Which Operating system do you have installed?
Ubuntu Server 22.04
Which Docker container are you using to run Nextcloud? (if applicable)
NC AIO
How much RAM does your server have?
16GiB
What processor Architecture does your CPU have?
x86_64
Describe the Bug
In the Pictures or Memories App go to People Tab and click on a group/class of pictures (here named class A) (classified into one class by the AI). Rename it to e.g. my-person-1. Do the same for another class (here class B), so also rename it to my-person-1. The class A (the collection of images) will disappear and not be visible at all anymore on the peoples page. Only the collection of images from class B will be visible and have the name my-person-1.
I guess this error is related to recognize, since the pictures and memories app only provide an interface for this functionality, or am I wrong?
I guess this is a quite severe bug, since I lost many hours of classification work this way, since a whole class, containing many pictures, disappeared.
Expected Behavior
Both classes (collection of images) will have the same name or they will be automatically grouped into one class.
To Reproduce
See above.
Debug log
Not found anything useful in the nextcloud logs. But I guess, there is just no mechanism to catch the case, that the name already exists.
see #408 -- will be fixed in Nextcloud 25.0.4
Will that fix also apply to the Memories app or would @pulsejet need to port it over?
And are the clusters gone for good? How could I retrieve them possibly?
would @pulsejet need to port it over?
Good question. I don't know how memories handles this situation.
And are the clusters gone for good?
Yeah, they're gone :( Sorry
Good question. I don't know how memories handles this situation.
I mainly use memories and have had it happen recently - so it seems the handling isnt too different between Photos and Memories in that regard.
Yeah, they're gone :( Sorry
So would I have to run occ recognize:reset-face-clusters?
So would I have to run occ recognize:reset-face-clusters?
Removing a cluster also removes its associated face detections, so a simple reclustering won't be enough. You'll need to classify faces again :S
Sorry, I do not get it. I thought reset-face-clusters means that all clusters are removed (no persons anymore) and one has to run classify anyway afterward to cluster faces again. Is that step necessary, or can I only run classify again. This way, I could keep all my manually sorted persons and only new pictures would get added again.
If reset-face-clusters is needed, would there be another way of manipulating the database, such that I can only "reset" the pictures that got unclustered with this bug, without having to reset all clusters?
Thanks a lot :)
There are two steps in creating face recognition: 1. Recognizing faces and 2. grouping them into groups of faces that show the same person. reset-face-clusters removes all groups, but doesn't remove the faces. Rerunning classify without reset-face-clusters will not detect new faces in files for which some faces already already exist, for performance reasons, hence in your case skipping some faces that you'd want to have later for grouping. There's no way to only readd those faces that were lost, I'm afraid, because we don't know in which files they were found. So we need to classify all files and that only works properly if we have removed all detected faces beforehand to avoid skipping some files that we already have faces for. I hope that makes sense.
I think I have the same problem when given a face group a name in Memories. When I give a group a name that already exits the first group of faces disappears. I don't no if I have to report it here or in the issue list of Memories (too).
- NC: 30.0.4
- Recognize: 8.2.0
- Memories: 7.4.1
Edit: And is there a way to get the old groups of faces back?
Ugh this just happened to me too. I'm glad I only just started using this, because I would have been extremely frustrated. Still, days of waiting for face recognition to finish wasted. This bug is huge and should be trivial to prevent.
nextcloud 31.0.7 memories 7.6.1 recognize 9.0.3
@ManiacDC Can you try making the change proposed in https://github.com/nextcloud/recognize/pull/1317 on your instance to check whether it fixes this bug?
@marcelklehr It did not work... did I need to restart the server after applying the change?
@marcelklehr I'm using memories, and they use this code. Looks like it would be unaffected by your change? https://github.com/pulsejet/memories/blob/40a73f6541af65f3daf1d172879c564ce02a23da/src/services/dav/face.ts#L136
Looks like maybe moveFile needs to be overridden?
@ManiacDC You may need to restart the server for the change to take effect, yes, that depends on your setup.
Looks like it would be unaffected by your change? Looks like maybe moveFile needs to be overridden?
The moveFile function sends a WebDAV MOVE request via HTTP to the webserver which determines that the parent directory of the source and the target of the move is the same and then resorts to just renaming the face cluster using the setName method, which realizes that a cluster with that name already exists and then throws a Forbidden exception. In theory at least. :D
Ah I see.
I just restarted my server and tried again, unfortunately it still blew away the original.
@marcelklehr I've been looking at the move code for tree too and I'm not seeing an issue with your logic, but obviously something isn't working lol.
Interestingly enough, move has an overwrite option that defaults to 'T'. If it's set to 'F', it should not overwrite.
Ahhh... found it: https://github.com/sabre-io/dav/blob/58be83aae10a244372f113b63624c48034378094/lib/DAV/CorePlugin.php#L586
Sabre/DAV will DELETE the target if it exists before executing the Move. Oops. So the implementation seems like it has to be client side? That's... not optimal.
edit: You could use a plugin and look for the beforeMove event :(
Ah, yes indeed. That's some weird behavior but it's also in the WebDAV spec. I have implemented a check in the plugin to throw if the target exists. 👍 Thanks for having a look!