matiasdelellis
commented
4 years ago Hi @muebau It's something I've also been thinking about a lot.
The application has been thinking about being able to handle several models, but today we prefer to focus on one. We select dlib models and so far we are happy. Another model will be HOG also using dlib/PDlib. But these were always thought within the same application.
Supporting external services may be questionable due of the needed to send the images to another server, and lose the security of our data and all the magic of Nextcloud. Believe me there are many paranoid people who think like that. haha.. š
That said, I personally do not dislike the proposal, whenever optional. But it will take a good time. First we must modulate some code, and really support several models.
As for the services you propose, at this stage I can accept the Detention.
About clustering, although it (Now chinese whispers clustering) is also under discussion, I do not expect to change it, and although it must be optimized, I prefer it to remain local.. Doing this part of an external service can complicate the application a lot.
About Different Models, I think this would be the biggest advantage, but always focusing on the faces. However, I consider the external model as an individual model. I imagine something like collabora code. and that the service will be configured beyond the nextcloud instance.
That said, I can accept a new model/service where to send an image (a PUT method) and return a json with faces, confidence and descriptor. But I tell you again, that we currently have no way of handling it correctly.
@stalker314314 If you want to comment.
About object detection I IMHO think it should be another application. š
muebau
stalker314314
burnoutberni
jokerigno
Hi, I planed to build a system/app like this and I am very happy to see this great app.
When I planed my app it was less coupled with Nextcloud as I am more in the detection part than in php. Nevertheless I could be great to separate the different parts anyway:
Different Parts for:
Detection If this would be a simple part with a well defined interface (eg. REST API) it would be very easy to "connect" it to the App by simply give it a endpoint URL. The work would be done in this "detection system" and could be on the same system (localhost) or on a more powerful "offloader" system. The use of "AI Sticks" like the Google Coral would be quite easy as it would only be an addition to the detection system and does not necessary interfere with the Nextcloud system.
Clustering This could be a different system with a REST API too. It could eg. use lots of RAM on a powerful machine.
Different Models Once the app is split in different parts there is no need to do "just" face detection alone. There could be a wide range of models for object detection or even face expression detection etc. The size of the app would be very small as the heavy part would be in the different detection systems. There would be no need to explain why the app does not work without an installation of some additional software (CLI etc.) as the REST APIs show the need of a additional detection part.
I see many advantages in this modularization approach:
simple offload to systems with GPU, TPU, compute sticks, more RAM, etc.
easier to see and understand the different parts
very extensible (eg. support for generic Tensorflow Lite Models for all kind of Attributes)
could be done in a batch procession (every night) fashion (the big machine would wake up for this)
could be installed on a RPi anyway and used with "localhost"
could be realized with simple docker containers including ready to use containers for GPU, TPU, compute sticks, etc.
could lead to a generic wrapper with REST API for AI stuff which would abstract the internal models (like Core ML, TF Lite)