Gesichterkennung im Video-Stream

[Syrus]

Wäre es denn möglich, einen Trigger zu integrieren welcher die Gesichtserkennung anstößt damit diese nicht dauerhaft im Livestream arbeiten muss?

Wenn bei der Intercom jemand klingelt, dann wird der Trigger zu FaceStreamAI gesendet welche den LiveStream "ODER" das LastPicture auswerten könnte - danach per UDP oder MQTT das Result zum Miniserver

[normana]

LastPicture wäre von Loxone? Wenn das eine Url hat, geht das. Wie würde denn das Event von der Intercom aussehen? Kann man es irgendwo abgreifen? Offenbar hast du Erfahrung mit der Intercom gesammelt. Welche verwendest du denn? Die Intercom2?

[Syrus]

Intercom-2 hab ich!

Das Event von ver Intercom bezieht sich auf ein PlugIn von Loxberry (Intercom22Lox) > https://wiki.loxberry.de/plugins/intercom22lox/start

Somit hätte man das "LastPicture" und könnte es mit der URL vom Loxberry in die FaceStreamAI übergeben zur Auswertung, worauf per UDP/MQTT die Auswertung an Loxone übergeben wird!

Sie die mal den Link zum PlugIn an: https://wiki.loxberry.de/plugins/intercom22lox/start
Bzw. den SupportLink hier im Forum zum PlugIn, da stehen viele Infos drin über die Abwicklung: https://www.loxforum.com/forum/hardw...rauszubekommen

[normana]

Kann man denn das Video von der Intercom 2 nicht direkt abgreifen? Oder das letzte Foto?

[Syrus]

Der Videostream kann man direct abgreifen über folgende URL: http://USER:PASSWORD@IP.IP.IP.IP/mjpg/video.mjpg
Das mach ich auch bereits ... doch mein Verständniss ist hierzu, das "FaceStreamAI" kontinuirlich den Stream nach Gesichtern durchsucht - wobei mein Gedanke wäre, das mittels trigger das letzte Bild (oder ein Snapshot vom Videostream?) abgeholt & analysiert wird - danach Rückmeldung zu Loxone ...

Das letzte Bild nach dem Klingeln, kann man mit folgendem Script holen: https://github.com/markuslaube/loxon...ast-picture.sh

Wäre vielleicht eine Implementierung in den "FaceStreamAI" Tool möglich? Mit trigger und Rückmeldung?

[normana]

Generell ist alles möglich. Ich werde mal überlegen, wie man das integrieren kann. Ich arbeite ohnehin gerade an einer Pro-Version, die MQTT unterstützt, mit Alter -und Geschlechtserkennung sowie mit einer Methode, die prüft, ob es sich um eine echte Person handelt oder um ein Foto, damit man die Software auch für sicherheitskritsche Anwendungsfälle nutzen kann, wie beispielsweise Tür öffnen.
Zum Verständnis: Der Slider Face Recognition Interval gibt an, in welchem Zyklus der Frames die Gesichterkennung durchgeführt wird. D.h. wenn dort eine 60 steht, wird jeder sechzigste Frame genommen und darauf die Gesichterkennung angewendet. Wenn die Gesichterkennung abgelaufen ist, wird wieder 60 Frames gewartet. Also nicht kontinuierlich bzw. du hast die Kontrolle darüber, wie oft die Gesichtserkennung läuft. Im Übrigen ist diese auch unabhängig vom Stream. Die funktioniert also auch ohne, dass du den Stream irgendwo ausgibst. Das ist schon recht effizient gebaut.

[Syrus]

Schön zu hören, dass das Porjekt lebt - danke dafür!

Bezüglich Slider FaceRecognition: Auch wenn der User die Kontrolle über die Anzahl der Prüfungen behält: Dann sollte es lt. meiner Auffassung doch eine Verzögerung geben (wenn auch maginal!) sofern der Slider hochgesetzt wird, da ja die Anzahl der Frames abgewartet wird? Ich finde leider keine Daten zu den Anzahl der Frames der Kamera oder den Stream - aber ausgehen der Frames von 25/s und FaceRecognition = 60, würde ein maximale Verzögerung von 2,4 sec. auftreten bis zu einer Rückmeldung ...

Weiters: Der Stream wird 24/7 gestreamt und im Zyklus (Frames) "FaceRecognition" geprüft was eine höhere Leistung abfordert ... soviel zur Theorie. Sofern es eine Triggerfunktion gäbe auf den Stream oder auf ein Snapshot vom Stream, könnte direkt danach die Erkennung folgen, was auch eine Reduzierung der Rechenleistung zu Gute kommen würde!

Das alles recht effizient gebaut ist, bezweifle ich nicht - im Gegenteil, alles gut - tolle Arbeit! Doch meine Auffassung dazu ist das immer ein Stream läuft welcher vielleicht nicht dauerhaft notwendig wäre, wenn zum Beispiel in der Nacht keiner an der Intercom läutet (in diesme Beispiel!)


Oder verstehe ich generell das System falsch bezüglich Stream <> Auswertung <> Rückmeldung? (Dann Entschuldige ich mich hierfür)




Meine Theorie würde vorsehen:

Möglichkeit in FaceStreamAI zum switchen zwischen Stream/Auswertung oder SnapShot/Auswertung:

Beispiel: Klingeln an der Intercom > Trigger an FaceStreamAI > FaceStreamAI macht ein Snapshot oder ein Bild wird übergeben > FaceStreamAI wertet Gesichtserkennung aus > FaceStreamAI gibt Rückmeldung ob "erkannt" oder "nicht" per UDP/MQTT

[normana]

Das mit der Verzögerung hast du richtig erkannt. Das ist naturgemäß so. Der Ansatz mit einem Trigger wäre daher schon resourcenschonender. So wie du sagst: Auswahl zwischen Interval-Recognition und Trigger-Recognition. Der Ansatz war tatsächlich schon geplant. Da genügt es aber die bereitgestellte Stream-URL eben dann nicht permanent abzugreifen und interval-mäßig auszuwerten sondern erst wenn der Trigger kommt. Und dann wieder stoppen wenn x-Sekunden lang kein Gesicht erkannt wurde. Das ist dann natürlich hochgradig effizient. Du verstehst das generell richtig.

[normana]

Wäre der Ansatz in Deinem Sinne?

[Syrus]

Ja, das wär Klasse wenn man dies so bewerkstelligen könnte ;-)

[myknack]

Spannendes Projekt … +1 für den Trigger

[Labmaster]

Könnte man den Erkennungsprozess leistungsoptimiert auf z.B. eine Edge TPU auslagern, so wie man es z.B. mit Frigate machen kann ?

[normana]

Ja. technisch geht das. Aktuell bin ich nur gerade stark mit anderen Themen beschäftigt.

[Labmaster]

Frigate verwendet für die Objekt Erkennung auch Trigger und zwar z.B. die Bewegung.
Es wird als erst mal immer zyklisch eine Bewegungserkennung ausgeführt welche vom Rechenaufwand sehr gering ist und dann erst wird davon abhängig eine Objekt Erkennung getriggert

[PatrickG]

Hallo zusammen

Ich hätte grosses Interesse daran, wenn das Projekt wieder etwas Schwung bekommen würde, es scheint ja derzeit ein wenig eingeschlafen zu sein.
Die Möglichkeit eines Event-Triggers und die Unterstützung von Coral auf dem Synology-System wären aus meiner Sicht extrem spannend.

Leider reichen meine Programmierkenntnisse nicht über das Niveau eines Script-Kiddies hinaus, daher könnte ich das Projekt höchstens finanziell unterstützen.
Daher meine Frage: Wäre das für euch ein Anreiz, hier noch etwas weiterzumachen?

[normana]

Hallo, ja wir werden die Arbeit daran wieder aufnehmen. Tatsächlich wurden zwei anderen Projekten (u.a. SonoX) Vorrang gegeben. Bis zum Jahresende soll es eine Pro-Version (kostenpflichtig) geben, die die u.a. Event-Trigger unterstützen wird.

[sagos]

Sie können die SIP intercom Akuvox E16c verwenden, die die gleiche Funktion wie die intercom loxone erfüllt und nur noch die Gesichtserkennung unterstützt, was ein Auslöser für das Loxone sein kann

[BastyJuice]

Dann muss aber eine neue Hardware gekauft werden.

[sagos]

Ich habe es nur zur Information gesagt, vielleicht wird es für jemanden nützlich sein) Ihr Projekt ist sehr gut, ich werde es testen. Vielen Dank für Ihre Arbeit

[BastyJuice]

Hey zusammen

Ich hatte heute Zeit und Lust, FaceStream.AI zu Forken und möchte das Ergebnis gerne mit euch teilen!

Original ist das Projekt von Norman Albusberger, aber ich habe es erweitert, damit es nahtlos mit Loxone funktioniert.

https://github.com/BastyJuice/FaceStream.AI

Loxone Virtual Text Input Integration
– per konfigurierbarem HTTP GET wird der erkannte Personenname an eine virtuelle Texteingabe gesendet.

Test-Button in der GUI
– damit kannst du direkt aus der Oberfläche prüfen, ob dein Loxone-Texteingang korrekt reagiert (sendet FaceStream.AI als Testwert).

Manual Trigger (/trigger)
– Face Recognition kann manuell ausgelöst werden (z. B. durch einen HTTP-Call), mit Optionen wie Dauer, FPS-Limit und sofortigem Stopp bei Match.

Trigger-forced Notification
– beim Trigger wird garantiert mindestens eine Notification ausgelöst, wenn ein bekannter Name erkannt wird.

Optionaler Automatik-Modus
– du kannst die automatische Intervall-Erkennung ausschalten und nur noch manuell triggern lassen.

Clean-Up für Unknown Bilder
– alte Unknown_*.jpg Bilder unter /event-image/ können automatisch gelöscht werden, basierend auf einem konfigurierbaren Zeitraum.

Verbesserte GUI-Integration aller neuen Optionen
– übersichtlich und konfigurierbar direkt im Web-Interface.

Wenn ihr das Projekt mit Loxone verbinden wollt und Feedback habt oder Fragen — gerne hier im Thread 😊

Viele Grüße

[Grestorn]

Wow! Hast Du das am Laufen mit dem Loxone Interkom?

[BastyJuice]

Jup Deswegen habe ich es umgebaut

[BastyJuice]

Wenn es interessiert mit Intercom 2 sind folgende Settings am Besten. Ich nutze für die Integration Intercom22Lox und die von mir Implementierte Suspend Funktion ohne Face Recognition Interval

als Trigger folgende Settings nehmen /trigger?duration=10&fps=60&stop_on_match=1 ich mache das direkt am Präsenz Baustein der Tür so habe ich bereits die Person im Texteingang bevor Sie klingelt.

Ich beziehe mich dabei ausschließlich auf meinen Fork

[Fuxi]

Hallo, kann man daraus ein Synology Docker Image machen ?
Sorry,bin jetzt mal neu auf der Docker Front, muß mich erst mit dem Thema beschäftigen.

Danke

[BastyJuice]

Ja kannst du habe ich auch so bei mir

[Fuxi]

Blöde Frage aber wie mache ich aus deiner erweiterten Version ein Syn Docker Image ?
Sorry, Image machen ist einstweilen noch echt Neuland für mich.

Unter "Registrierung" im Container Manager ist nur das von Normana logischerweise.
Muss ich deines "irgendwie" hinzufügen oder ganz falscher Weg ?

[BastyJuice]

Das geht relative einfach mit Docker Desktop

git clone https://github.com/BastyJuice/FaceStream.AI
cd FaceStream.AI
docker build -t facestream-ai -f dockerfile .
docker save facestream-ai:latest -o facestream-ai.tar

Das Tar kannst du dann in der Synology im Container Manager Hochladen

[Fuxi]

Danke, werd mir das zeitnah anschauen, Vielen Dank !!

[BastyJuice]

Ich habe meinen Fork in den letzten Tagen intensiv überarbeitet und an vielen Stellen optimiert.

Der Fokus lag vor allem auf:

• Deutlich schnellere Trigger-Reaktion (keine alten Frames mehr, sofortige Verarbeitung)
• Verbesserte Erkennungsroutinen (bessere Trefferquote, weniger Fehldetections)
• Optimiertes Best-of-Verfahren für stabilere Face Recognition
• Bildverbesserung (z. B. gezielte CLAHE-Optimierung und Blur-Handling)
• Code-Qualität & Stabilität (Thread-Safety, obustere Pipelines)
• Saubereres Ressourcen-Handling (Queues, Cleanup, Logging)

Ergebnis: Schnellere Reaktionen, bessere Erkennung und insgesamt deutlich stabilerer Betrieb.

Der Fork entwickelt sich damit immer mehr in Richtung Low-Latency / Realtime Face Recognition Pipeline.

Ein kleiner Wermutstropfen bleibt allerdings:

Die Loxone Intercom GEN2 liefert unter bestimmten Lichtverhältnissen leider kein optimales Bild, was sich direkt auf die Erkennungsqualität auswirkt.
Im Vergleich dazu läuft das Setup mit einer Tapo C210 aktuell like a charm – hier sind die Ergebnisse deutlich stabiler und zuverlässiger.

Ich hoffe einfach mal auf eine Intercom GEN3 in Zukunft...