Kamera-Archive

[rdeckard]

Ich habe heute erstmals das Kamera-Archiv eingeschaltet. (Früher wusste ich nur, wie man es anlegt, aber nicht wie man es abfüllt. Nachdem ich nun doch schon selber einen kleinen LBS programmiert habe, bin ich mit dem Logikeditor schon bisschen vertrauter...hehe)

Habe einen Oszillator verwendet und zurzeit mal 4 Kamera-Archive verbunden. Leider habe ich am Anfang die ms als Sekunden interpretiert, d.h. ich hatte viel zu kurze Abstände und habe nun in paar Minuten schon mehrere Hundert Bilder (pro Archiv) gespeichert. (Habs jetzt geändert auf 1 Min.)

Wie bekomme ich diese "Test-Bilder" am einfachsten wieder aus dem Archiv raus? Einfach die Archive löschen, neu anlegen und wieder verbinden? Eine "Leeren"-Funktion in der Verwaltung gibt es ja glaub nicht? (und einzeln über den Befehl "Kamera-Archiv: Bild entfernen" möchte ich auch nicht.)

Und was mir hier auch noch aufgefallen ist...die Reihenfolge der Archive ist halt das gleiche Problem wie bei den anderen Listen. Wäre jetzt nicht so tragisch. Leider verwendet er aber auch in der Kameras-Funktion diese Reihenfolge. Und dort würde man beim Sichten der Kameras schon lieber die Reihenfolge haben, wie die Kameras benennt wurden. (Meist vermutlich Kamera 1, 2, 3 etc.)

Klar, wenn ich die Archive lösche, dann könnte ich sie grad in der richtigen Reihenfolge wieder erstellen. Dann wäre das Problem (und das mit dem Inhalt) gelöst. ;-)

[gaert]

Leeren kannst Du das Archiv mit einem Befehl (oder per mySQL natürlich):

Bildschirmfoto 2016-03-01 um 20.47.18.png


Die Sortierung ist wie sie ist Ich habe eher nicht vor dies flexibel zu implementieren - der eine will's so, der andere so...

[rdeckard]

Oh, dass "alle Kamerabilder entfernen(!)" habe ich gar nicht gesehen...

Bei mir sieht übrigens die Kamera-Übersicht so aus:
Cam_archiv1.png

Obwohl ich eigentlich alle 4 Kameras (eine ist zurzeit offline) minütlich aufzeichnen lasse, sie die Bilder leider nicht schön untereinander. Das vergrössert den horizontalen Platzbedarf (Scrollen) natürlich ungemein. Klar, er speichert vermutlich ein Timestamp und das ist viel genauer als die sekündliche Anzeige und somit gibts halt zufällige Verschiebungen.
Könnte man dies evtl. irgendwie auf eine Sekunde angleichen?

So sieht der LBS dazu aus:
Cam_archiv2.png

(Verwende noch 1.18)

[gaert]

Die Darstellung IST doch auf Sekunden gerastert... Das "Problem" sind eher Deine Kameras, die offenbar unterschiedlich schnell auf das Polling reagieren. Bei mir sieht's so aus - sofern die Ereignisse "synchron" innerhalb einer Sekunde stattgefunden haben:
Bildschirmfoto 2016-03-01 um 22.30.14.png


Bei Dir sieht man's doch ganz gut: Kamera 4 und 3 sind übereinander - aus dem Rahmen fällt nur die Kamera 1. Was soll EDOMI jetzt daran ändern?

[rdeckard]

Also da hätte ich schon paar Ideen... (Nicht ganz ernst gemeint, weil du sicher wichtigeres zu tun hast)

Die Ausgangslage ist ja relativ klar (rein aus Usersicht): Man hat mehrere Kameras und möchte die archivierten Bilder SYNCHRONISIERT anzeigen. Deshalb hat man ja diese schöne Timeline-Ansicht, damit man alle Kamerabilder zeitgleich untereinander sieht (und vergleichen kann).
Das ist die Erwartungshaltung.
Alle Bilder werden jetzt in meinem Fall mit dem gleichen Oszillator jede Minute gespeichert. Mehr kann ich als User nicht dazu beitragen, dass die Bilder zeitgleich gespeichert werden.
Jetzt kommt dein Aspekt: Die Kameras sind schuld, da diese nicht gleich schnell reagieren. OK, das mag stimmen, aber das kann ich nicht ändern und wird wohl immer bei einer gewissen Anzahl Kameras der Fall sein. Niemand kann vermutlich technisch garantieren, dass ein IP-Cam-Request über das Netz zeitgleich eintrifft.

Wäre ich jetzt Entwickler (und bitte jetzt nicht als Kritik verstehen!), so müsste ich auf der Software-Seite eine Lösung finden, wie diese Bilder synchron gespeichert oder zumindest angezeigt werden. Dass die einzelnen Bilder nicht in der gleichen ms (oder Sek.) aufgenommen wurden, spielt ja vermutlich in der Realität keine grosse Rolle. Es geht um die Anzeige untereinander.
Eine Lösung wäre evtl., dass man einzelne Kamera-Archive einer Gruppe zuweisen könnte und dann die Gruppe zum Speichern angesprochen wird. Sobald ein Kamera-Befehl auf eine Gruppe bezogen ist, könnte dann Edomi für alle Kamera-Archive dieser Gruppe jeweils den exakt gleichen Timestamp für das Bild verwenden (egal, wann das Bild effektiv aufgenommen wurde). Damit wäre zumindest in der Timeline eine synchrone Darstellung gewährleistet.

Ich weiss nicht, wo die Bilder genau gespeichert werden. Filebasierend oder direkt in der DB. Evtl. könnte man ja in der DB nebst dem effektiven Erstellungs/Speicherdatum noch ein zusätzliches "Anzeigedatum" führen, welches dann für die Timeline verwendet würde.

Ich hab das jetzt nicht zu Ende gedacht, ist nur so spontan eine Idee.

Aber wie schon erwähnt. Würdest du eine reine Kamera-Überwachungssoftware programmieren, so müsstest du solche Sachen sicher implementieren. In Edomi ist diese Kamera-Timeline aber "nur" eine Nebenfunktion. Zumindest eine sehr sinnvolle Nebenfunktion.

Ich kann damit leben, wie es jetzt ist, weil ich vielleicht dann eh mal auf eine externe Software ausweiche. Falls du aber irgendwann mal etwas Zeit und Lust hast, diese Timeline zu optimieren, dann bin ich dir sicher nicht böse.

[gaert]

Und was wäre wenn ich als User genau das Gegenteil erwarte? Nämlich die korrekte zeitliche Zuordnung einer Bildes...?

ich finde es total logisch, dass die Bilder so eingeordnet werden wie sie aufgenommen wurden. Wenn die Kamera eine Latenz von 2 Sekunden hat, ist das Bild schließlich 2 Sekunden alt... Deine Argumentation ist irgendwie nicht ganz logisch

[rdeckard]

Für mich ist sie sehr logisch...
Aber lassen wirs...es gibt wichtigeres. (Und sonst kannst ja mal eine User-Abstimmung machen, um zu sehen, ob ich der einzige bin.)

[gaert]

Na klar - sonst würdest Du ja nicht Deine Wünsche äußern

Aber im Ernst: Ist folgende Sichtweise nicht irgendwie logischer?
Die Logik in Deinem Fall fordert die Kamera z.B. um 12:00:00 auf ein Bild zu liefern (zwecks Archivierung). Die Kamera antwortet aber erst um 12:00:02 mit einem Bild. Das Bild ist also von 12:00:02 (in der Realität). Warum sollte es nun in der Timeline um 12:00:00 angezeigt werden?! Das würde doch nicht korrekt sein - denn das Bild ist ja 2 Sekunden "jünger"...

Einzig Deinem Vorschlag 2 Datumswerte zu speichern kann ich gedanklich folgen (Datum der Anforderung und tatsächliches Bild-Datum). Aber ist das nicht ein wenig "overkill"?

Würdest du eine reine Kamera-Überwachungssoftware programmieren, so müsstest du solche Sachen sicher implementieren.

Ganz im Gegenteil! Gerade bei einer Überwachungssoftware interessiert doch das REELLE Aufnahmedatum des Bildes - nicht das theoretisch gewünschte

[rdeckard]

Ganz einfach: Weil ich in der Timeline alle Kameras untereinander vergleichen möchte. Was ist zu einem bestimmten Zeitpunkt passiert? Die Kameras zeigen dann unterschiedliche Blickwinkel der gleichen Situation. Ob jetzt ein Bild 1-2 Sek. früher/später als in der Realität angezeigt wird, spielt hier keine so grosse Rolle.
Und es wird sich ja eh nur um max. paar Sekunden Latenz (wenn überhaupt) handeln. Somit ist mir die klare Übersicht weit wichtiger, als die sekundengenaue Archivierung.
Angenommen, man hätte 10 Kameras, dann wäre die Timeline ja relativ fragmentiert, weil immer wieder mal eine Kamera früher oder später speichert. Und sonst wäre halt alles schön untereinander, was das visuelle Erfassen eines "Vorfalls" beim durchscrollen sicher erleichtert.

Vielleicht bin ich mir aber auch nur die Timeline eines Schnittprogrammes gewohnt, wo man ja im Multicam-Betrieb auch alles synchron angezeigt bekommt.

[gaert]

Ich verstehe Dich ja durchaus Nur ist dies nicht so trivial umzusetzen, weil nicht logisch... Dir reicht 1 Sekunde (vielleicht auch 2) als Raster - andere wollen's vielleicht ganz präzise oder nur stündlich...

Es wäre nicht sonderlich schwierig, ein individuelles Raster zu implementieren. Nur wie wäre dann die Timeline (Legende) unterteilt? Und was passiert, wenn innerhalb 1 Sekunde 2 oder 3 Bilder vorliegen? Und so weiter... Daher ist der aktuelle Ansatz m.E. logisch und eindeutig.

Dein Schnittprogramm hat einen entscheidenden Unterschied: Es handelt sich um Videos... Das Raster ist hier i.d.R. 1 Frame - und dies natürlich ebenfalls über alle Videos gleichermaßen. In EDOMI ist das Raster eben 1 Sekunde (bzw. auch weniger - siehe Einstellung "präzise") - und wenn quasi 1 "Frame" fehlt, dann fehlt er

[woda]

Evtl. kleinen Fehler beim Bearbeiten der Archive mit dem LBS18000010 gefunden.
Wenn ich aus einem Kameraarchiv einen Eintrag entferne, wird das Archivstatus-KO nicht entsprechend um 1 verringert.
Nach einer erneuten Aktivierung des Projektes stimmt das Status KO.

[gaert]

Guck' ich mir mal an - Danke für den Hinweis!

Beim Start (und täglich um Mitternacht) werden die Archive aufgeräumt und das entsprechende Status-KO gesetzt, insofern schlüssig