search

matiasdelellis / facerecognition

Nextcloud app that implement a basic facial recognition system.
GNU Affero General Public License v3.0
499 stars 45 forks source link

Able or how to view enable face recognition data/tags to be accessed/viewed globally? #555

Open KptnKMan opened 2 years ago

KptnKMan commented 2 years ago

PREFACE

First of all, I want to preface this by saying I think that this project is AMAZING! I'm trying to build an online album for my family, where photos can be viewed and aggregated and shared. I've been spending months testing different solutions, and this project coupled with NextCloud itself hits so many sweet spots, its ALMOST perfect.

I've been spending about a week getting the face recognition function working on a new docker install (On unraid 6.9.2), and it has been a real pain to get working, but I finally got everything working, added images and finally got them indexed and recognised/tagged. I think its great.

That being said...

I think that the workflow of face recognition data/tags being PER USER with no ability to share globally (That I can find), seems to undermine some the purpose of doing all of this. I say this understanding that my use case is not every use case and situation, and that some people may want this workflow and behaviour. Still, in a use case where a "group" or family is tagging pictures together, it seems to me that this would be quite important, especially as its stored in a central database.

So onto the issue template itself...

Expected behaviour

It would be great to have the ability to enable face recognition tags to be globally viewed. To be able to define who can tag names on photos globally would be "perfect world", but just being able to view would be great.

In a "perfect world", have the ability to set permission groups to:

  1. no permission to view or edit face global recognition tags/data (same as now where cannot see other users face tags).
  2. view global face recognition tags in read-only fashion.
  3. have full access to be able to set names and view/edit names globally tagged by others.
  4. have administrators have the ability to define this by groups.

Personally, at this time I would find it amazing just to be able to view other peoples tagged names, even if they cannot be edited, but a permission based nuanced approach would be chefs kiss.

I understand that this would bring issues around where the file is stored, but I have found the "hidden options" to tag photos in shared storage, and used them hoping that they could be viewed by different users, but alas no. So I would assume that only photos in shared storage locations would be able to have the tags shared.

Actual behaviour

At the moment, any user that tags a photo can view the name tags, and see them in the "Persons" sidebar, but this data is hidden to other users.

Steps to reproduce

  1. Setup a working instance.
  2. Setup face recognition fully based on the installation instructions.
  3. Login as "User A".
  4. Upload images to the instance as "User A", and wait for face recognition.
  5. Tag faces in the "Face Recognition" personal settings.
  6. Log out "User A" and login as "User B".
  7. Go to either the "Face Recognition" personal settings page, or "Persons" tab in sidebar.
  8. Facial recognition tags are missing.
  9. Logout "User B", login "User A" again.
  10. Go to either the "Face Recognition" personal settings page, or "Persons" tab in sidebar.
  11. Facial recognition tags are present.

Server configuration

dantefff commented 2 years ago

I second this feature request

guystreeter commented 2 years ago

Issues #413 and #377 seem to be the same as or part of this.

KptnKMan commented 2 years ago

@guystreeter I read through both of those issues/feature requests, and although they have some marginal overlap, I would say that I have tried to highlight the main points of the issue where they haven't. Such as:

These things would seem to be central to creating a meaningful use-case and implementation of this feature.

Something that concerns me more though, is the fact that the issues #413 and #377 seem to be 2 years old, without any indication that anything has or will be even considered beyond "it is something we hope to add in the future". Personally, I think this is a feature that would put this project head and shoulders above other similar projects.

I have great faith in this project, but I think maybe a trick is being missed here that could really be important. This and being able to add face tags manually, I don't see how these 2 features aren't high on development backlog.

Of course I'm saying this without understanding what the project workload is and dev pressures of course, I'm not privy to any of that. I've been trying to see from looking through the repo how I could contribute, but I don't know how without being an (very good) PHP developer.

teamfighter commented 2 years ago

+1 for this issue. Would love to see such features.

NathanAdhitya commented 2 years ago

Is there any update to this feature yet? +1 I'd really something similar to this to be implemented. In a scenario where a central album exists which is shared among multiple users, having it accessed/viewed globally would do a drastic improvement in regards to QoL and performance.

EDIT: I just had a silly idea that I might try just for my own use. Take out the "user" part from the persons and images table.

KptnKMan commented 1 year ago

I've checked the linked issues and seen nothing, again, years later. Is anyone actually concerned with this issue, and is there any hope with actually getting anything implemented?

It also seems like development on this project has slowed down, is this even being worked on?

matiasdelellis commented 1 year ago

Hello everyone,

In 0.9.10 for nc25, add a command to create people's albums. This command is in response to issue #292, but also contributes to part of this report. Theoretically, once you sync an person album, you can share it with your loved ones..

Please, note that we work according to the nextcloud api and their applications. Although we would like it, we cannot do everything that our users expect (And that I personally would love to see it too) if we do not have the correct tools to do it.

I still have my doubts about this (what happens if two users share an album with the same name?). Don't know. Partly for this reason it is a separate command, and it does not work automatically

KptnKMan commented 1 year ago

Thanks for this response, updates, and reference to the other ticket. 😊 I wasn't aware of this particular functionality, but its a great way to share goups and pictures.

In terms of how to resolve the "two users share an album with the same name", then maybe perhaps there could be some prefix or postfix or user-specific UUID on the Album? This might not need to be a UI-visible ID, but maybe of the Album in the back-end, because personally I don't mind if 2 Albums are named "Family Pictures" on the front-end, if on the backend the albums are named "janet_family_pictures" and "andrew_family_pictures".

So perhaps this might solve the clashing of duplicates there, assuming a unique user cannot have duplicates within their own account?

Another option might be just to directly specify who shared it in the UI, like "Family Pictures [Janet]" and "Family Pictures [Andrew]" being the album names, with the "[UserName]" of the name being the UUID unique qualifier?

I dunno, I'm kinda spitballing here. I'm not sure how much work this would be to implement, and how viable it is.

Thanks again for the response. I do love this amazing project, and use it for my self-hosted family pictures project.

matiasdelellis commented 1 year ago

I wasn't aware of this particular functionality, but its a great way to share goups and pictures.

It is that it does not exist officially yet 😅 , this is for Nextcloud 25 that has not yet been released as stable. 🙈

In terms of how to resolve the "two users share an album with the same name", then maybe perhaps there could be some prefix or postfix or user-specific UUID on the Album? This might not need to be a UI-visible ID, but maybe of the Album in the back-end, because personally I don't mind if 2 Albums are named "Family Pictures" on the front-end, if on the backend the albums are named "janet_family_pictures" and "andrew_family_pictures".

So perhaps this might solve the clashing of duplicates there, assuming a unique user cannot have duplicates within their own account?

Another option might be just to directly specify who shared it in the UI, like "Family Pictures [Janet]" and "Family Pictures [Andrew]" being the album names, with the "[UserName]" of the name being the UUID unique qualifier?

It is not a technical question. Note that it's just a peculiar use of a nextcloud feature for which it wasn't intended. So, since NC25, this application allows you to create the album with people, however all the features you expect from it, we cannot control it.

For example I can not indicate that the album was created by an application, I cannot indicate that it should not be edited, and if you edit the album, the app has no way of knowing, and any changes you make will be reverted on the next run of the command.

There are many unresolved things.

KptnKMan commented 1 year ago

Oh I see, I know nothing about the Nextcloud API but that does sound like a complicated set of contraints to navigate (And I'm sure those examples are a drop in the sea).

Either way, I think you've achieved amazing things with this project and I genuinely hope that you can do more with it. I looked at a lot of projects for photo management, and THIS project coupled with Nextcloud makes it simply amazing. I honestly feel that this project is so close to greatness, but I work in IT myself (Experience from many years, and having my own successful IT consultancy company) and I sympathise that even simple things are not simple to implement.

I hope I can contribute one day, I've looked into some of the source of this project and its out of my remit for this moment, and the intrinsic knowledge you have of nextcloud APIs is something I'd have to work on as well.