das oben schon erwähnte imagemagick hat auch eine annotate-Funktion, welche dafür verwendbar ist. Wenn also dies tool ohnehin eingesetzt wird, ließe sich das verbinden
wegen stream-Verarbeitung (bzw. Standbilder aus streams) sicher komfortabler ist gstreamer. Dort gibt es für “selbstvergebenen” timecode (also keine externe Stringenz wie bei SMPTE-timecode) die Funktionen clockoverlay und timeoverlay. Beide lassen sich umfangreich konfigurieren (timeoverlay, clockoverlay )
gstreamer für RaspberryPi kennt als Kameraquelle rpicamsrc (rpicamsrc), und diese wiederum hat eine property annotation-mode, nicht ganz so flexibel wie timeoverlay, aber immerhin lassen sich auch date und time auswählen
source und sink müssen natürlich für das Zielsystem angepaßt werden. Für webcams unter Linux ist source dann meist v4l2src (oder libcamerasrc oder eben die rpicamsrc); für die Senke werdet ihr sicher filesink verwenden wollen.
Läuft der Timecode aus Datum und Uhrzeit dann klaglos bei den Einzelbildern einer Zeitrafferaufnahme immer mit?
Also ist beim anhalten des Films dann immer die korrekte Zeit im Standbild enthalten?
Oder kann es durch Stromausfälle und andere technische Probleme dann dazu kommen, dass die falsche Zeit im Standbild angezeigt wird?
Mein Gefühl ist, dass die richtige Wahl für uns eine Python-App wird, die regelmäßige Fotoaufnahmen durch picamera2 macht, und sie als Numpy-Arrays durch PIL und OpenCV verwaltet, und als sogenannte Daemon-Process läuft. Ich werde meinen Quellcode in ein paar Tage per Github teilen.
picamera2 erlaubt uns, Einstellungen wie Autofokus, HDR usw. gelegentlich zu verwalten, die vorher nur durch die libcamera Command-Line-Tool erreichbar waren, und wenn wir die Bilder nativ als Numpy-Daten verwalten, haben wir dann komplette Freiheit in Dingen wie Timestamps.
Eigentlich, aus Sicht der zukünftigen KI-Trainings, finde ich es am besten, statt den Bildern irgendwie zu verändern, ein schwarzes Informationsband hinzuzufügen, mit Annotationen wie Timestamp, BOBCam-Nummer. (Vielleicht auch andere Messwerte wie Temperatur, wenn wir die in der Zukunft auch erfassen werden.) Damit können wir, wenn es Zeit ist, ein KI-Modell zu trainieren, die Informationsbänder automatisch und ohne Mühe abschneiden.
gstreamer wäre vielversprechend, wenn wir eine Live-Kamera-Funktion über http einbauen wollten; es klingt theoretisch gut, aber dafür brauchten wir ständige Beleuchtung, was nicht so gut für die Bienen (oder den Stromverbrauch) wäre.
Ich habe es trotzdem vor, einen einfachen Webserver in die App einzubauen, damit man das letzte Bild von den eigenen Nistboxen über das lokale Netzwerk oder eine VPN / Meshnetzwerk-Lösung wie Nebula beobachten kann. Das ist natürlich ein bisschen weiter entfernt; zuerst möchte ich die Python-App mit der Erkennung von Bildänderungen fertig haben und teilen.
Hallo Hartmut,
Die Raspberry Pi 3 hat keinen Real-Time-Clock-Akku, also kann ohne Stromversorgung die Uhrzeit nicht folgen. Das ist für uns jedoch kein wirkliches Problem, weil alle Nistboxen einen Internetzugang haben, und die Pis ihre Uhren beim Start über das Internet synchronisieren. Also als die ersten Bilder gemacht werden, ist die Uhrzeit schon idealerweise korrekt.
picamera2 kannte ich bisher nicht, das sieht ja wirklich aus wie eine ausgewachsene Bibliothek. Sie haben ja sogar ein Beispiel für ein overlay per cv2.putText() in ihrer doku! ,)
Mein gstreamer-Vorschlag kam nur, da ich nicht wußte, welche sw die Bildverarbeitung-Objekte und -primitives zur Verfügung stellt. Aber mit PIL in Python und erst recht OpenCV hast Du alles Wünschenswerte bereits in der Hand. Und wenn Du dann noch die Bilddaten als arrays in NumPy verarbeiten willst… sehr schön, dann kann ich da nichts mehr helfen! :)
gstreamer kann auch mit stills umgehen, wenngleich das wirklich nicht dessen Hauptdomäne und es deshalb etwas umständlich ist; egal, ist hier erstmal abgewählt.
“Idealerweise” (:
Das kann tricky werden: so ein ntpd braucht auch mal länger, bis nach einer aufgebauten (Weitverkehrs-)Netzwerkverbidung der daemon die Referenz-Uhr(en) erfolgreich erreichen und die Systemzeit setzen konnte; im schnellsten Fall hat der access router für den RasPi einen ntpd sowie dessen server und propagiert das per DHCP seinen lokalen clients. Das kann man aber erstmal nicht voraussetzen.
Ich sehe zwei Möglichkeiten, etwas wie “1970-01-01” (oder so) zu vermeiden:
ntpd (resp. chrony) beherrscht hotplug-events. dbus im RasPi-Debian z.B. kann events wie ‘time steps’ oder stratum-Änderungen bedienen, sowas kannst Du per python zur Bedingung machen, die Systemzeit davon zu stellen. - So macht OpenWRT das z.B per shell: https://github.com/openwrt/packages/blob/master/net/ntpd/files/ntpd.hotplug-helper
Außerdem ist je nach distro entweder ntpd oder chronyd der Kandidat. - Es gibt ein panic-override (-g), wenn mehr als 1000 Sekunden offset sind, das (sowie einiges die Systemzeit betreffend) braucht root-Rechte.
Wir müssen zuerst noch Hardware-nahe Probleme lösen. Von den 6 Kameras, die ich in der letzten Woche nach Hannover gebracht habe, funktioniert eine nicht mehr.
Ausserdem haben wir nur von Direns Kamera Bilder von Wildbienenbrut, Hartmuts Kamera hatte nur Schlafgäste, meine hatte keinen Besuch. Da können wir noch nicht viel auswerten und eine KI trainieren.
Trotzdem können wir überlegen, wie wir noch bessere Bilder hinbekommen und ob wir noch mehr aus der Raspicam herauskitzeln können. Vor allem, ob es sich lohnt, in die IR-Beleuchtung zu investieren. Die Bilder werden nie so wie die mit gelben Licht. Erst wenn man häufig Bilder macht, kann das gelbe Licht stören. Wenn man z.B. Bewegungen erkennen will, ist die geringere Auflösung der IR-Aufnahmen ein Problem.
Das Zeitproblem ist nicht da, da die Kamera stabil mit Wlan verbunden ist, sonst kann man auch keine Bilder in die NextClout senden. Die Zeit ist also immer aktuell, da sorgt des PiOs schon dafür.
Inzwischen habe ich einmal reihum bei alle vier Nisthilfen (#3, #4, #1 und #2) mehrfach die CO2-Konzentrationen gemessen. Hinweis: Der flache H-MF Stapel zwischen den Nisthilfen #3 und #4 ist in die CO2-Betrachtungen nicht eingebunden.
Im folgenden Diagramm sind die Ergebnisse zusammengefasst. Der längste Balken zeigt die schon berichteten CO2-Werte der Röhrchen-Nisthilfe aus dem Graphen weiter oben vom 28.04.2025. Am Balkenende ist das Gewicht des jeweiligen Nestinhalts vermerkt.
Zur Steigerung der Empfindlichkeit habe ich die Öffnung am Messbehälter reduziert und dann für 8 Stunden eine Nachtmessung durchgeführt. Die MIN/MAX-Werte dieser Nachtmessung mit teiloffenem Messbehälter sind im Balken-Diagramm gelb-grün dargestellt.
Trotz der um Mitternacht eher niedrigen Temperaturen (MW=10,19 °C) gibt es mit teiloffenem Messbehälter ein deutliches Nutzsignal für die CO2-Detektion (MW=992 ppm). Zu berücksichtigen ist allerdings, dass unter den gegebenen Bedingungen ca. 320g Nestinhalt verfügbar war. D.h. aber auch, bei meinen beiden Brettchen-Stapel (#4, ‚#1) halte ich eine CO2-Detektion, bei den derzeit geringen Nestinhalten und mit teiloffenem Messbehälter, so nicht für zielführend.
hier auch noch mal ein Update von meiner Nistmöglichkeit.
Die Ameisen hatten ja einiges an Verwüstung angerichtet. Schließlich hat mir Ute ungereinigte Schafswolle zugeschickt. Außerdem hatte ich inzwischen Zeit eine neue Halterung zu schweißen, die hoffentlich Ameisensicher ist.
