People: Matching unrecognized faces has become very slow #2182
Comments
lastzero
added
help wanted
|
I have the same issue. Just imported 30'000 photos with ~450 new faces, and it's a real crawl to do anything. The whole page just freezes up. Haven't check the logs yet though. |
|
Hello @cassava @hulmgulm @l8gravely :) I am currently looking into this issue... more information would be helpful to provide you with a solution:
Thank you for taking the time to answer these questions, I really appreciate it. Sorry if you have already posted it somewhere! |
|
Hi @lastzero, I've set the following config option I started using PhotoPrism Oct 22nd and updated instantly, each time a new image was available. I think, that this issue started around beginning of February but I'm not sure about that. At the beginning, I was using an existing MySQL instance for PhotoPrism, until I ran into upgrade issues and you dropped MySQL support. Then I migrated to MariaDB (database dump and import) and am using version 10.7.3 now. I'm using "--innodb-buffer-pool-size=1G" there. Two weeks after I started this thread, I decided to start nearly from scratch and truncated subject, markers and faces tables and let PhotoPrism do a rescan of the images. At the beginning, it worked like a charm, but soon the issues started to come up again. It does not happen on all face assignments, but at maybe 75%. Currently, it takes about 3 minutes to get these faces saved. I wrote a tool, which displays me all faces of a given subj_uid, face_id or subj_name. While I noticed one or two wrong assignments (which I corrected in the UI), the other faces are correct. This is a part of the most recent log: time="2022-03-28T18:10:43Z" level=debug msg="faces: can merge MDCNKKHLDGZKYRCJZ7EDZYBBZTUXSTF4 with 5XY4C5KHJVHP2XACPRPXND57H5CCKRA5, subject jr7kdtd3u8khnpo5, dist 0.023031" I reviewed all of the mentioned faces as well as the subject and they're all of my oldest daughter. One thing I have to mention is, that I have many Asian friends and in the beginning it happened a lot that PhotoPrism was assigning the same person to completely different faces (e.g. middle aged male to 10 year old girl). I corrected all of these assignments. Besides truncating the three tables mentioned above, I did only make changes to the data with PhotoPrism UI. Maybe this helps, or maybe you can tell me what more I can do, e.g. finding the faces which prevent PhotoPrism from merging them. Thank you! |
|
I wonder if part of my problem is that I'm indexing and searching for photos of my kids, from ages 0 to 19, so they all get assigned to one kid, but the faces are radically different as the kid gets older. Or not radically to my eye, but obviously quite a bit different. It would be great is there were some better tools to dump what the DB thinks is out there, since with my 70.000+ pictures, it is slow at times, and not really obvious what's going on. I'm using the default docker-compose.yml file, though I do pull it at points and reload it. So I'm using the default Mysql/mariadb setup (not sure which honestly) and I did try tweaking the memory size of the DB to see if that would improve things. But it's not clear where the slowdown is, if it's in the DB, or in the core code. Can we turn on slow query logs maybe? Or could we get the logging to start putting some time stamps at the start and end of the update transaction so we can get an idea of what's going on here? |
|
We developed and tested face recognition assuming the default 15 minute background worker interval, so it is completely untested with very long intervals and not designed for that. The worker makes sure that the faces get properly clustered/optimized in the background so that the number doesn't get too large to process. The first/next time it runs, it will cause a high server load until all faces, people, and related photos have been updated. The longer you wait, the more CPU is needed and the longer it takes. 30000s is about 8 hours if I calculated it correctly, which generally won't cause any problems (except for less frequently updated photo titles) unless you use face recognition very actively - especially by manually assigning names to many non-clustered faces or correcting wrong matches. Even our old Core i3 server (running multiple instances and lots of other services simultaneously) rarely has a high CPU load. Maybe on the first day, when lots of faces had to be optimized and clustered, I don't remember any irregularities - but was also too busy to check the system parameters, to be honest. From our User Manual at https://docs.photoprism.app/user-guide/organize/people/:
Also note that while PhotoPrism can be installed on most consumer NAS devices, such hardware generally does not provide an ideal user experience for compute-intensive applications such as machine learning and face clustering: https://docs.photoprism.app/getting-started/troubleshooting/performance/#server-cpu |
|
@l8gravely Did you manually tag a lot of individual faces, i.e. not just the "new faces" clusters you see under "People"? That starts to cause performance issues after a while, as it creates lots of small clusters internally. Maybe an acceptable mitigation for now regarding this would be to skip the "optimize faces" background job if nothing changed during the last execution of that job, and nothing was edited/added by the user. I'm thinking of a really simple implementation with just an in-memory "changed" flag that isn't even persisted over restarts. It should avoid pointless CPU waste when you don't touch your instance for days. |
|
>>>> "Simon" == Simon Rettberg ***@***.***> writes:
Simon> @l8gravely Did you manually tag a lot of individual faces,
Simon> i.e. not just the "new faces" clusters you see under "People"?
Simon> That starts to cause performance issues after a while, as it
Simon> creates lots of small clusters internally.
Not really, I've just been going through the new faces group and
fixing up things where it has mis-classified people, or grouped them
wrong.
Simon> Maybe an acceptable mitigation for now regarding this would be
Simon> to skip the "optimize faces" background job if nothing changed
Simon> during the last execution of that job, and nothing was edited/
Simon> added by the user. I'm thinking of a really simple
Simon> implementation with just an in-memory "changed" flag that isn't
Simon> even persisted over restarts. It should avoid pointless CPU
Simon> waste when you don't touch your instance for days.
But the performance slowdown is when you are making changes. I don't
mind if there's background optimization, though maybe it should be
only during midnight to six am (for example) and only when the load on
the system is under some other value.
Right now my main PhotoPrisim host (the data is readonly on an NFS
volume) is just sitting there pretty much idle. Now would be a good
time to do optimizations. But once people do interactive work, it
should stop/cancel/pause any background work to make the interactive
experience better.
Is there any way to get a measurement of the number and size of
clusters associated with a name?
And as a side note, it might be a good option to show the number of
un-categorized photos for each unknown person in the new people page.
That would help me target which ones need the most update work. Small
groups aren't a problem, but big groups would be.
Hard to know though, since I don't have a good feel for how the code
is structured and more importantly, how to debug a docker
application.
John
|
Did you check if it is only slow while the background job is running? If you set the worker interval to 8 hours and wait until the CPU is idle, is assignment still slow?
To see the number of faces per person: You can then query the individual faces of a subject from the Especially in @hulmgulm 's case, if you want to check whether specific SQL statements are responsible for the hangs you have – 3 minutes sounds excessive – try enabling slow query logging in MariaDB with a reasonable setting for slow query time (3+ seconds). |
|
Hi @lastzero, thanks for taking the time to look at this! Here's my setup:
The problem was there already when I was assigning the first faces. Loading tagged people is fast, as soon as I switch to "new", then it slows down significantly |
|
Ok, after playing around a little more in the People/New tab, I found the following:
|
|
>>>> "Simon" == Simon Rettberg ***@***.***> writes:
Simon> But the performance slowdown is when you are making changes. I don't mind if there's
Simon> background optimization, though maybe it should be only during midnight to six am (for
Simon> example) and only when the load on the system is under some other value.
Simon> Did you check if it is only slow while the background job is
Simon> running? If you set the worker interval to 8 hours and wait
Simon> until the CPU is idle, is assignment still slow?
Nope, I haven't. What's the process for making these changes since I
don't see anything in the docker-compose.yml file.
Simon> Is there any way to get a measurement of the number and
Simon> size of clusters associated with a name?
Simon> To see the number of faces per person:
Simon> SELECT subj_uid, subj_name, Count(*) AS facecount FROM subjects
Simon> LEFT JOIN faces USING (subj_uid) GROUP BY subj_uid ORDER BY
Simon> facecount DESC;
Ok, so I need to fire up a docker shell to get access into the DBs,
etc. Still working to wrap my brain around docker and debugging. New
tricks, old dog. :-)
Simon> You can then query the individual faces of a subject from the
Simon> faces table, which has columns like collision_radius and
Simon> sample_radius. I thought it would be cool to visualize all the
Simon> faces as a 2D or 3D point cloud to see if that helps
Simon> identifying potentially problematic faces, but it seems a face
Simon> is described through 512 floats, and after reading a paper on
Simon> how to reduce higher-dimensional data for visualization I
Simon> decided to give up on this idea. :)
I think just listing on the new faces page the number of pictures
associated with each face would be a good indication of where to spend
time classifying people. I've got 70,000 pictures and around 270
people tagged.
Hmm... another interesting statistic would be to see how many pictures
have un-tagged faces in them, vs the count of pictures with tagged,
etc.
Sorta like a heat-map, showing the number of faces in a photo, and
also the number of unrecognized faces in that photo as well. The idea
would be to allow people to find the low-hanging fruit of faces to
categorized, or group photos with some found, but mostly
un-categorized faces.
Simon> Especially in @hulmgulm 's case, if you want to check whether
Simon> specific SQL statements are responsible for the hangs you have
Simon> – 3 minutes sounds excessive – try enabling slow query logging
Simon> in MariaDB with a reasonable setting for slow query time (3+
Simon> seconds).
More info as I get it.
John
|
It's
Yeah, not the biggest fan of docker either in that regard, but it's not that much harder once you get used to it. For simple debugging the |
Sounds like there are no thumbnails yet (face crops from thumbnails), so they are rendered on demand. That would explain why already named people are much faster. Did you delete any, reorganize your library somehow, or is it possible they got lost somehow?
Did you mention somewhere what database you are using? |
|
So I've been poking at my setup to try and figure out why it's slow.
Now that I know how I can login to the mysql container and run some
queries (note! It would be nice to add that info to the
docker-compose.yml file!) I've been poking around at things to try and
figure out what's up.
So the error I get is:
photoprism_1 | time="2022-04-01T13:36:24Z" level=warning msg="faces:
XNXGZMWQFYTSG6CKIZSHMH6MR7IM3YMV has ambiguous subject
jr24slh3m9fhqeqs"
photoprism_1 | time="2022-04-01T13:36:38Z" level=warning msg="faces:
failed removing merged clusters for subject jr24slh3m9fhqeqs"
And doing the query:
SELECT subj_uid,subj_name FROM subjects WHERE subj_uid =
'jr24slh3m9fhqeqs';
has been good, because it pointed me to a person who had a
mis-classified picture in his grouping. So I cleared that out and
re-assigned the face to the correct person.
But now I think that face A (the problem one) is probably also in
person B's grouping, but now I have to dig through 500+ photos to
figure it out.
So I think in this case, it would really help to do better logging
with more info. The id's aren't really useful for searching, and
since these logs aren't exposed to the outside world, or no more
exposed than any other data on this setup, we should try to make the
logging include the names so that people can find and make updates
more quickly.
So here's a shot of the kinds of log entries I see, and notice how
that time stamp starts at 14:00:10, but doesn't complete until
14:02:39, which is 1:39 to make a single update!
photoprism_1 | time="2022-04-01T14:00:10Z" level=warning msg="faces:
failed removing merged clusters for subject jr24slh3m9fhqeqs"
photoprism_1 | time="2022-04-01T14:00:40Z" level=warning msg="faces:
FZRAZRMFZE2ZYNDIFMVMDUTC57GQYUWD has ambiguous subject
jr24slh3m9fhqeqs"
photoprism_1 | time="2022-04-01T14:00:57Z" level=warning msg="faces:
failed removing merged clusters for subject jr24slh3m9fhqeqs"
photoprism_1 | time="2022-04-01T14:00:57Z" level=warning msg="faces:
FZRAZRMFZE2ZYNDIFMVMDUTC57GQYUWD has ambiguous subject
jr24slh3m9fhqeqs"
photoprism_1 | time="2022-04-01T14:01:12Z" level=warning msg="faces:
failed removing merged clusters for subject jr24slh3m9fhqeqs"
photoprism_1 | time="2022-04-01T14:01:12Z" level=warning msg="faces:
FZRAZRMFZE2ZYNDIFMVMDUTC57GQYUWD has ambiguous subject
jr24slh3m9fhqeqs"
photoprism_1 | time="2022-04-01T14:01:25Z" level=warning msg="faces:
failed removing merged clusters for subject jr24slh3m9fhqeqs"
photoprism_1 | time="2022-04-01T14:01:25Z" level=warning msg="faces:
FZRAZRMFZE2ZYNDIFMVMDUTC57GQYUWD has ambiguous subject
jr24slh3m9fhqeqs"
photoprism_1 | time="2022-04-01T14:01:39Z" level=warning msg="faces:
failed removing merged clusters for subject jr24slh3m9fhqeqs"
photoprism_1 | time="2022-04-01T14:01:39Z" level=warning msg="faces:
FZRAZRMFZE2ZYNDIFMVMDUTC57GQYUWD has ambiguous subject
jr24slh3m9fhqeqs"
photoprism_1 | time="2022-04-01T14:01:55Z" level=warning msg="faces:
failed removing merged clusters for subject jr24slh3m9fhqeqs"
photoprism_1 | time="2022-04-01T14:01:55Z" level=warning msg="faces:
FZRAZRMFZE2ZYNDIFMVMDUTC57GQYUWD has ambiguous subject
jr24slh3m9fhqeqs"
photoprism_1 | time="2022-04-01T14:02:08Z" level=warning msg="faces:
failed removing merged clusters for subject jr24slh3m9fhqeqs"
photoprism_1 | time="2022-04-01T14:02:08Z" level=warning msg="faces:
FZRAZRMFZE2ZYNDIFMVMDUTC57GQYUWD has ambiguous subject
jr24slh3m9fhqeqs"
photoprism_1 | time="2022-04-01T14:02:23Z" level=warning msg="faces:
failed removing merged clusters for subject jr24slh3m9fhqeqs"
photoprism_1 | time="2022-04-01T14:02:23Z" level=warning msg="faces:
FZRAZRMFZE2ZYNDIFMVMDUTC57GQYUWD has ambiguous subject
jr24slh3m9fhqeqs"
photoprism_1 | time="2022-04-01T14:02:39Z" level=warning msg="faces:
failed removing merged clusters for subject jr24slh3m9fhqeqs"
photoprism_1 | time="2022-04-01T14:02:39Z" level=info msg="faces:
merged 32 clusters"
photoprism_1 | time="2022-04-01T14:02:39Z" level=info msg="changes
successfully saved"
Hmm... I just tried doing a search for:
faces:FZRAZRMFZE2ZYNDIFMVMDUTC57GQYUWD but I got a whole mix of random
(to me) photos which didn't have any real relation to each other, and
which didn't really have any matched people.
So having some way to narrow down searches to what PhotoPrism
considers a group of faces so I can find and fix the problem would be
great.
John
|
May help improve rendering performance on slow devices. Feedback welcome!
That's why faces that our current model often confuses - like those of children - should/can not be automatically matched: After users repeatedly commented that this was not a problem for them, the protection was later disabled to a large extend When a person's face changes, it's generally not a problem, since it's possible to have more than one matching face. But if the face can't be distinguished, that's a big problem, since it consumes CPU time without producing useful matches - which we may observe here to some extent. It's probably a mix if different issues. |
Adds two unofficial env variables so advanced users can experiment: 1. PHOTOPRISM_FACE_KIDS_DIST=0.6950 (range: 0.1-1.5, -1 to disable) 2. PHOTOPRISM_FACE_IGNORE_DIST=0.86 (range: 0.1-1.5, -1 to disable)
|
>>>> "Michael" == Michael Mayer ***@***.***> writes:
Michael> I wonder if part of my problem is that I'm indexing and searching for photos of my kids, from
Michael> ages 0 to 19, so they all get assigned to one kid, but the faces are radically different as
Michael> the kid gets older.
Michael> That's why faces that our current model often confuses - like those of children - should/can not
Michael> be automatically matched:
Michael> * #1587
Michael> After users repeatedly commented that this was not a problem for them, the protection was later
Michael> disabled to a large extend
Michael> * People: Further reduce radius of unsuitable faces embeddings f4845f7
Michael> When a person's face changes, it's generally not a problem,
Michael> since it's possible to have more than one matching face. But
Michael> if the face can't be distinguished, that's a big problem,
Michael> since it consumes CPU time without producing useful matches -
Michael> which we may observe here to some extent. It's probably a mix
Michael> if different issues.
I'm defintely seeing something like this issue, because my system is
burning CPU time every time I make an edit, which really slows things
down.
I've been wondering if there should be a timeout, once you spend more
than five seconds of wall time, abort trying to find more matches and
get the user response time back up. Even five seconds might be too
much.
What's frustrating for me is watching the blue line zoom across the
screen, then basically stop for 30, 60 or 90 seconds at the end. So
logging the start and end times of different phases would be great, so
it would become more obvious where the time is being spent, and then
those areas should be the focus of more work for larger groupings.
And in regards to kid's changing over time, would it make sense to
have some way to specify that you are labeling a photo of a kid, and
then to do the grouping internally by the year given on the photo meta
data?
Right now I'm experimenting with doing "Name, YYYY" with the year of
the photo to try and get grouping to work better. It's a total hack,
but it might be a simple way to trick the classifier.
I'm also running on an old old Intel Core2 Quad Q6600 at 2.4ghz, with
DDR2 1200 memory. So it's *not* a speed daemon by any stretch.
Is there a better way for me to run the system with better logging so
I can file better reports on how things look?
John
|
|
@l8gravely The latest commit shows the real name in (most?) subject related logs. Didn't have much time to test manually, but the automated tests are all green. So it SHOULD work. Also added a cache, which should help performance. |
|
>>>> "Michael" == Michael Mayer ***@***.***> writes:
Michael> @l8gravely The latest commit shows the real name in (most?)
Michael> subject related logs. Didn't have much time to test manually,
Michael> but the automated tests are all green. So it SHOULD
Michael> work. Also added a cache, which should help performance.
Sweet! Thanks for doing this! I just restarted with
PHOTOPRISM_DEBUG: "true"
and I'm seeing more info. And I think I've just got two or there
mis-classified images slowing things down somewhere. Is there any way
to map the "has ambiguous subject <string>" to a file name?
photoprism_1 | time="2022-04-03T22:15:27Z" level=warning msg="faces:
77MJQSVKOT3PVTK73563WGRN46TFZQEF has ambiguous subject
jr24slh3m9fhqeqs"
photoprism_1 | time="2022-04-03T22:15:44Z" level=warning msg="faces:
failed removing merged clusters for subject jr24slh3m9fhqeqs"
photoprism_1 | time="2022-04-03T22:15:44Z" level=debug msg="faces:
can merge MT6XQCA4WNZELLCGWS7YE52SFBTFMNLW with
ZNQ4KJW5BJFN4TVKHLAG4BGOEHKJ4ULJ, subject jr24slh3m9fhqeqs, dist
0.195644"
photoprism_1 | time="2022-04-03T22:15:44Z" level=debug msg="faces:
can merge MT6XQCA4WNZELLCGWS7YE52SFBTFMNLW with
77MJQSVKOT3PVTK73563WGRN46TFZQEF, subject jr24slh3m9fhqeqs, dist
0.097822"
You've already given me the hints on doing the mysql query to find the
name associated with the 'jr24s...', but I haven't figured out the
best to get the other data.
Should I just totally delete all mentions of that person? It's only
~40 pictures assigned to that name, and I don't mind missing them. Or
re-doing them later.
Is the merging of faces and such single threaded? Would it make
things faster if you used multiple threads maybe? Just a thought. I
haven't quite got my head wrapped around debugging and building docker
images and such. I'm sure I could start making patches once I get
comfortable. Well... patches to make the logging more useful, maybe
not the core code. Heh.
Cheers!
John
P.S. And I *really* do appreciate all you're doing here, this is
fantastic software and I'm happy to keep supporting you.
|
Since caching all subject data proved too complex in the time available, this implementation uses a simple key/value lookup table to cache subject names and perform backward searches by uid.
|
Since caching all subject data proved too complex in the time available, the new implementation uses a simple key/value lookup table to cache subject names and perform backward searches by UID. Next, I take another look at the face merge function. |
This commit also fixes of other potential issues and improves logging.
lastzero
changed the title
lastzero
added
bug
|
>>>> "Michael" == Michael Mayer ***@***.***> writes:
Michael> Started a new preview build for you! Note that we will be
Michael> traveling until after Easter, so feedback may be slow. Any
Michael> help with testing these changes is greatly appreciated.
Thanks for all this work! I'll pull down the test instance and see
how it works.
|
|
>>>> "John" == John Stoffel ***@***.***> writes:
>>>> "Michael" == Michael Mayer ***@***.***> writes:
Michael> Started a new preview build for you! Note that we will be
Michael> traveling until after Easter, so feedback may be slow. Any
Michael> help with testing these changes is greatly appreciated.
John> Thanks for all this work! I'll pull down the test instance and
John> see how it works.
So I pulled it down, but haven't actually built a docker image yet.
But I've improved my performance by finding the name with all the
problems, then I went and deleted that name from all pictures in the
collection. So now updates are much faster, because I don't have
conflicting facial clusters?
Hard to say.
I'll work on getting the latest image you posted up and running. I
think I can just copy the mysql DBs between instances, since I
*really* don't want to lose all my work classifying images. But maybe
not.
I really need a new, faster computer though, this one stuggles. LOL!
John
|
|
A few days back, I reset the automatic scan interval to the default be removing the configuration. Now the nearly 24/7 100% were back. After a few days, I had the impression, that it does not take 3 minutes anymore to save a face but less. I also noticed, that for low quality or too small faces, the issue did not occur.
I just updated to that build (photoprism/photoprism:preview) and I don't see any issues anymore. I tagged now about 50 faces and the updates happend within seconds. No errors/warnings in the logs. Whatever you changed, looks like it fixed the issues I was encountering. |
|
THank you. This is a big improvement and gives a decent hint on where the problems might be. It may be worth to document that the information is only logged with the |
|
One more question please. How should the below be read/understood ? It says person name conflicts with face XXX subject |
|
@rickysarraf Could you try again with these changes? I've started a new preview build for testing, available soon. |
Hello @lastzero With the latest changes, I now get: |
|
This is because a face ID is referenced that apparently no longer exists. Have you tried the |
graciousgrey
added
released
|
>>>> "Michael" == Michael Mayer ***@***.***> writes:
Michael> @rickysarraf Could you try again with these changes? I've
Michael> started a new preview build for testing, available soon.
I have to say that once I deleted an entire user's associated
pictures, it got a bit faster. So far most updates seem to be running
quicker. But the real problem I feel is that this person had a
mis-classified picture in another person's grouping.
So that's where I think the tools could be better, and if PhotoPrism
itself could notice:
1. Hey, updates are taking 2x longer than before,
2. And I'm seeing conflicts or overlaps in faces,
3. So maybe report them and offer a way to compare the pictures of two
people side by side to help find conflicts?
If there was a way I could group/sort pictures by similarity, that would
be awesome.
But I'm going to try and upgrade to the preview version and see how
that works for me.
|
|
Well, right now we're working on multi-user and security, so don't expect any improvements in facial recognition. I'm not an octopus developing with 8 keyboards and computers at the same time, and I don't know who else would work on it!? 🤔 |
|
@lastzero facial recognition is one of the most important features in my opinion. I for example paid to support you just because of this single individual feature. Reading this here after searching for a way to speed up the very annoying slowdown makes me sad. |
|
Would you please be so kind to check the follow up issue before publicly coming to conclusions? Do you have any idea how much we work and how large our team is? May I ask what you do for a living and how much you earn? Possibly, that makes us sad too. |
|
$25 one time. How many developers are we supposed to hire from this, Martin? |
|
What has my company to do with my private pictures of my family? |
|
That's all you have to say after publicly posting an unfounded rant? Did you even understand what I wrote above? |
|
The only person behaving improperly is you. I have only communicated that in my personal opinion, this is an important feature. I've been using this software for only a few days, made an initial payment to you to support the project, and I'm being personally attacked here. Please explain to me why someone who just tried your software and even paid immediately should pay more just because he owns a company? I am happy to pay for software, and my behavior has clearly shown this. Sorry I gave the honest feedback that this feature is the only reason for me personally to support it. Without the fsce detection, I can use any other software. |
|
Let me help you: if you are as rich as it seems, and this is as important as you say, surely you could support us more than with the minimum amount so that we can grow our team and do all the things you think we should do. It's not like we don't want to do that. Also, it might help to communicate a little more politely in public. PhotoPrism is the result of hard work and is anything but sad. |
|
If you just read above again, you'll find that I'm just unhappy that you guys aren't making any improvements to facial recognition at this time according to your own writing. Here is what you wrote: "don't expect any improvements in facial recognition" and this is sad. Expressing my sadness over this statement is certainly not a rant. What is the point of the statement "if you are as rich as it seems"? What does that have to do with anything? Do you ask your other sponsors how much money they have? Do sponsors who support you have to sponsor you depending on their wealth or income? I myself write and release open source hardware and software that I need in my private time for my personal hobbies. Never in my life would I think of snorting at someone who supports one of my projects in such a misguided way or even think of using his financial background as a justification. |
|
Please check the issue I have linked above. We are working on it. Edit: We just did not have any resources at that time, which was last year. Read more carefully before coming to conclusions. |
|
We kindly ask you to use GitHub Discussions or any of our other community forums next time instead of commenting your personal opinion in GitHub Issues. Thank you very much! ❤️ |
@hulmgulm Can you share with me the source for that tool? I'm trying to improve the clustering on my own set of photos. |
Discussed in #2022
Originally posted by hulmgulm February 8, 2022
Hi,
assigning unrecognized faces got awfully slow since the last release (or the second last, I'm not sure about that). It takes now more than two minutes until I can assign the next face. From looking at the logs, it looks like there are some issues with the data:
2022-02-08 20:16:40 INFO änderungen erfolgreich gespeichert
2022-02-08 20:16:40 INFO faces: merged 77 clusters
2022-02-08 20:16:39 WARN faces: failed removing merged clusters for subject jr1e4i93ltym0svq
2022-02-08 20:16:31 WARN faces: SAF7A54HA4RCJ2UYGKND7SFCJCJEG62B has ambiguous subject jr1e4i93ltym0svq
2022-02-08 20:16:27 WARN faces: failed removing merged clusters for subject jr1e4i93ltym0svq
2022-02-08 20:16:19 WARN faces: SAF7A54HA4RCJ2UYGKND7SFCJCJEG62B has ambiguous subject jr1e4i93ltym0svq
2022-02-08 20:16:15 WARN faces: failed removing merged clusters for subject jr1e4i93ltym0svq
2022-02-08 20:16:07 WARN faces: SAF7A54HA4RCJ2UYGKND7SFCJCJEG62B has ambiguous subject jr1e4i93ltym0svq
2022-02-08 20:16:03 WARN faces: failed removing merged clusters for subject jr1e4i93ltym0svq
2022-02-08 20:15:55 WARN faces: SAF7A54HA4RCJ2UYGKND7SFCJCJEG62B has ambiguous subject jr1e4i93ltym0svq
2022-02-08 20:15:51 WARN faces: failed removing merged clusters for subject jr1e4i93ltym0svq
2022-02-08 20:15:43 WARN faces: SAF7A54HA4RCJ2UYGKND7SFCJCJEG62B has ambiguous subject jr1e4i93ltym0svq
2022-02-08 20:15:39 WARN faces: failed removing merged clusters for subject jr1e4i93ltym0svq
2022-02-08 20:15:31 WARN faces: SAF7A54HA4RCJ2UYGKND7SFCJCJEG62B has ambiguous subject jr1e4i93ltym0svq
2022-02-08 20:15:28 WARN faces: failed removing merged clusters for subject jr1e4i93ltym0svq
2022-02-08 20:15:19 WARN faces: SAF7A54HA4RCJ2UYGKND7SFCJCJEG62B has ambiguous subject jr1e4i93ltym0svq
2022-02-08 20:15:16 WARN faces: failed removing merged clusters for subject jr1e4i93ltym0svq
2022-02-08 20:15:07 WARN faces: SAF7A54HA4RCJ2UYGKND7SFCJCJEG62B has ambiguous subject jr1e4i93ltym0svq
2022-02-08 20:15:04 WARN faces: failed removing merged clusters for subject jr1e4i93ltym0svq
2022-02-08 20:14:55 WARN faces: SAF7A54HA4RCJ2UYGKND7SFCJCJEG62B has ambiguous subject jr1e4i93ltym0svq
2022-02-08 20:14:52 WARN faces: failed removing merged clusters for subject jr1e4i93ltym0svq
2022-02-08 20:14:43 WARN faces: SAF7A54HA4RCJ2UYGKND7SFCJCJEG62B has ambiguous subject jr1e4i93ltym0svq
2022-02-08 20:14:40 WARN faces: failed removing merged clusters for subject jr1e4i93ltym0svq
2022-02-08 20:14:31 WARN faces: SAF7A54HA4RCJ2UYGKND7SFCJCJEG62B has ambiguous subject jr1e4i93ltym0svq
It's always the same warning. How do I resolve this issue? Can I do something in the UI or is there something else like an SQL query I can execute (I'm familiar with that)?
I don't want to drop my data, because I spent weeks assigning all faces in my >100k photos.
Thank you!
Andreas
The text was updated successfully, but these errors were encountered: