Videoanalyse (ähnlich wie Lichtschranke)

[Ilmug3]

Ich überlege mir, wie ich die Geschwindigkeit von Fahrzeugen auf einem Video analysieren kann.
Das Bild einer fest installierten Webcam beobachtet eine Ausfallstraße.
Ändert sich am Videobild ein definierter Bereich, startet ein Sekundenzähler, bis sich ein anderer Bereich des Videobildes ändert. Anhand der Zeit (im Sekundenbereich) und der Strecke, die zwischen den Bildpunkten in der Natur liegt, sollte sich die Geschwindigkeit ermitteln lassen. (nur annähern, wenn wenige Autos fahren, nicht gerichtsverwertbar, bei guter Beleuchtung, wenn das Auto nicht asphaltgrau ist, .....)

Was mir fehlt, ist eine Idee, wie ich im Millisekundenbereich einzelne oder wenige Pixel des Videobildes auf Helligkeits- /Farbschwankungen untersuchen kann.

Hat jemand einen Ansatz?

[nuclearping]

Die grundlegendste Antwort wäre hier wohl

Delphi-Quellcode:

TBitmap.ScanLine

. Das liefert dir einen Zeiger auf eine Bildzeile, wovon jeder Block (abhängig vom Pixelformat) die RGB- bzw. RGBA-Werte enthält.

[Medium]

Wenn die Straße gerade genug (waagerecht) auf dem Bild ausgerichtet ist, würde es ja sogar schon reichen eine einzelne Zeile zu betrachten. Das mittels Scanline ist problemlos im Millisekundenbereich abgefrühstückt.

[hathor]

Wenn die Bildfrequenz 50Hz ist, muss man nur alle 20 msec eine Analyse durchführen.

[dummzeuch]

Zitat:

Zitat von hathor (Beitrag 1324909)

Wenn die Bildfrequenz 50Hz ist, muss man nur alle 20 sec eine Analyse durchführen.

????

50 Hz sind 50 Bilder pro Sekunde, man muss also all 20 Millisekunden eine Bildanalyse durchfuehren.

[hathor]

Da war ein m verlorengegangen.
Übrigens:
Bei Dir ist ein e verlorengegangen.

[Ilmug3]

Danke für den Hinweis.
Erste Versuche habe ich jetzt schon gemacht.
Bildvergleich mit Scanline gibt gute Ergebnisse. Danke für den Tipp.
Meine Überlegung war weiterhin, einen kleinen Ausschnitt (30*30 Pixel) vom Desktop in die Anwendung zu kopieren
und dort mit dem hinterlegten Bild des Ausschnitts ohne Auto zu vergleichen.

Ich habe mich aus Faulheit für den Desktop entschieden. Dann muss ich mich nicht mit irgend welchen Videosstreams in Delphi rumschlagen,
sondern lasse den Stream im Browser anzeigen und kopiere es von dort in die Delphianwendung. Verschieben, darf man dann das Browserfenster natürlich nicht mehr.

Bedient habe ich mich bei diesen Codezeilen
_______________________________________
function GetScreenShot: TBitmap;
var
Desktop: HDC;
begin
Result := TBitmap.Create;
Desktop := GetDC(0);
try
try
Result.PixelFormat := pf32bit;
Result.Width := Screen.Width;
Result.Height := Screen.Height;
BitBlt(Result.Canvas.Handle, 0, 0, Result.Width, Result.Height, Desktop, 0, 0, SRCCOPY);
Result.Modified := True;
finally
ReleaseDC(0, Desktop);
end;
except
Result.Free;
Result := nil;
end;
end;


procedure TForm1.Button1Click(Sender: TObject);
begin
Image1.Picture.Bitmap := GetScreenShot;
end;
_______________________________

Leider scheint die Prozedur denn Speicher nicht ordentlich aufzuräumen,
denn nach einigen Sekunden (Scannrate 100ms) gehen mir die Ressourcen aus.
Die Probleme tauchen immer dort auf, wo man sie nicht vermutet :snowball:
Ich muss vielleicht noch etwas mit FreeAndNil arbeiten.
Das werde ich morgen testen.

[hathor]

Übersicht über Programme zur Videoanalyse


http://www.physik.uni-mainz.de/lehra...S/welcome.html
www.g-heinrichs.de/software/physik.htm
http://www.didaktik.physik.uni-due.de/viana/

https://wiki.delphigl.com/index.php/Timebased_Movement

[Medium]

Zitat:

Zitat von Ilmug3 (Beitrag 1324913)

Leider scheint die Prozedur denn Speicher nicht ordentlich aufzuräumen,
denn nach einigen Sekunden (Scannrate 100ms) gehen mir die Ressourcen aus.

Das ist einer der fiesen Fälle, wo eine Funktion eine Instanz als Result zurück gibt. Es gibt hier in der DP ein paar Diskussionen dazu, die sich damit befassen wer denn in so einem Fall nun für das Aufräumen dieser Instanz zuständig ist. Um den Code von GetScreenShot() nicht anfassen zu müssen, schlage ich folgende Lösung vor:

Code:

procedure TForm1.Button1Click(Sender: TObject);
var
  bmp: TBitmap;
begin
  bmp := GetScreenShot;
  if Assigned(bmp) then
  begin
    try
      Image1.Picture.Bitmap.Assign(bmp);
    finally
      bmp.Free;
    end;
  end;
end;

[Ilmug3]

Danke Medium.
Du hast meinen Sonntag gerettet.:cheer:
Das Aufräumen mit deinen Code funktioniert hervorragend.
Der Rest ist jetzt noch die übliche Fleißarbeit (hoffe und befürchte ich).

Beim nächsten unvorhergesehenen Problem melde ich mich ;-)

[Ilmug3]

Tja - so einfach wie Hänschen sich das vorstellt, ist es nicht.

Wenn das ganze auf dem Desktop läuft, sieht es wunderbar aus.
Da ist ja auch die Anzeige statisch und der Unterschied zwischen dem Referenzbild und dem beobachteten Bild ist bei 0%. Wenn sich etwas bewegt, schnellt der Wert sofort auf 50-100%.

Bei der Betrachtung eines Streams der Webcam hab ich schon im Normalfall eine Differenz bei 50-60% der Pixel (Bildrauschen). Wenn sich dann etwas durch den Erfassungsbereich bewegt, steigt der Wert um gerade mal 2-3%.

Schlimmer noch ist die grottige Framerate der Webcam. Schnelle Objekte springen manchmal direkt über den Erfassungsbereich hinweg ohne eine Reaktion auszulösen.
Ich glaube, ich gehe nochmals in die Planungsphase.

Aber Danke für die Tipps.
Dazugelernt habe ich in jedem Fall.

[Medium]

Zitat:

Zitat von Ilmug3 (Beitrag 1325095)

Tja - so einfach wie Hänschen sich das vorstellt, ist es nicht.

Eine der wichtigsten, universellen Weisheiten :spin:

Zitat:

Bei der Betrachtung eines Streams der Webcam hab ich schon im Normalfall eine Differenz bei 50-60% der Pixel (Bildrauschen). Wenn sich dann etwas durch den Erfassungsbereich bewegt, steigt der Wert um gerade mal 2-3%.

Ein erster möglicher Schritt wäre es, das Bild von der Cam zunächst durch einen milden Gauss-Filter zu jagen um alles ein wenig geschmeidiger zu machen.

Zitat:

Schlimmer noch ist die grottige Framerate der Webcam. Schnelle Objekte springen manchmal direkt über den Erfassungsbereich hinweg ohne eine Reaktion auszulösen.

Das ist leider ein weit größeres Problem, und ließe sich vermutlich nur mit einer besseren Cam (bzw. schnellerem Übertragungsweg, je nach dem was dir die Framerate versaut) zufriedenstellend lösen.

Nicht ganz unwichtig ist auch, wie du Farbunterschiede errechnest. Es kann z.B. schon hilfreich sein statt im RGB z.B. im YCC Farbraum zu arbeiten, da man dort mal damit spielen kann, ob eher Farb- oder eher Helligkeitsunterschiede zu gewichten sind.

Wie machst du das mit dem Referenzbild eigentlich? Weil da kommen dann ja noch so lustige Sachen wie Tageszeitabhängige Beleuchtung mit rein, vor allem abends auch die Lichtkegel der Autos, oder gar Straßenlaternen die zu einer komplett anderen Farbwiedergabe führen als Sonnenlicht.

[BUG]

Zitat:

Zitat von Medium (Beitrag 1325118)

Zitat:

Bei der Betrachtung eines Streams der Webcam hab ich schon im Normalfall eine Differenz bei 50-60% der Pixel (Bildrauschen). Wenn sich dann etwas durch den Erfassungsbereich bewegt, steigt der Wert um gerade mal 2-3%.

Ein erster möglicher Schritt wäre es, das Bild von der Cam zunächst durch einen milden Gauss-Filter zu jagen um alles ein wenig geschmeidiger zu machen.

Um die 2-3% wegzuglätten :angel2::mrgreen:

Du hast nicht erläutert, wie du den Vergleich nun machst. Zählst du die Pixel die nicht genau gleich sind? Das klingt definitiv nicht robust genug.

Abgesehen von der schlechten Framerate kannst du probieren, an der Kamera den Helligkeitsausgleich ausschalten und den Autofokus ausmachen.

[jfheins]

Ich würde dafür eine ordentliche Bildverarbeitung einsetzen. Beispielsweise OpenCV, dafür gibt es gute INterdaces zu Python, C++ und wohl auch C#.

Damit kannst du dann das Objekt in allen Bildern isolieren und die Position bestimmen. Wenn du nun die Kamera kalibrierst, oder ein selbstgebasteltes Mapping von Pixeln zu Metern einbaust, kannst du die Geschwindigkeit gut messen.

Das Problem mit "Zeit, bis der andere Pixel sich ändert" ist in der Regel, dass das Objekt sich in einem Frame viele Pixel bewegt. die Messung ist also ziemlich ungenau.
Falls das zu krass klingt: Eine Kamera zu kalibrieren ist wirklich nicht aufwändig, die druckst dir ein Punkt- oder Schachbrettmuster aus und machst 20 Bilder davon an verschiedenen Stellen.

Es gibt da vermutlich auch ein paar Videos, wie sows geht. Das hier habe ich auf die Schnelle gefunden: https://www.youtube.com/watch?v=66Pv5jnxUVI

[Perlsau]

Laßt mich mal versuche, das Problem technisch zu analysieren:

• In einem begrenzten Bereich des Videobildes soll die Dynamik von Bildänderungen festgehalten werden: Die Geschwindigkeit, mit der ein bewegter bewegter Gegenstand sich von A nach B bewegt, soll gemessen werden.
• Die reale Strecke ist bekannt, so daß man errechnen kann, wie viele Pixel beispielsweise 10 cm oder 1 m entsprechen.
• Die zu beobachtende Szene ist ausreichend gut ausgeleuchtet (was immer das genau bedeutet).
• Die Software, die die Einzelbilder analysiert, vergleicht immer das aktuelle Bild mit dem vorangegangenen.
• Zur Vereinfachung der Vergleiche werden die Bitmaps in 256 Graustufen umgewandelt.
• Da nicht das komplette Bitmap, sondern lediglich ein bestimmter Bereich beobachtet werden soll, wird der benötigte Bildausschnitt herauskopiert.
• Der eigentliche Vergleich läuft via Scanline und CompareMem, wobei die Anzahl der Fehler (= abweichenden Pixelfarben) einstellbar sein sollte und erst ab einer bestimmten Anzahl von Fehlern der Vergleich true zurückliefern sollte (Function IsMoving : Boolean; ).
• Um nun sowas wie eine Geschwindigkeit bestimmen zu können, wird der Bildbereich nach dem erstn Feststellen einer Farbänderung in Bewegungsrichtung reduziert: Kommt die Bewegung z.B. von rechts, wird der zu beobachtende Ausschnitt rechts um eine festgelegte Anzahl an Pixeln beschnitten.
• Die Ergebnisse werden in einem Array of SpeedMess (Zeitpunkt: TDateTime; Speed : Integer;) gespeichert; am Ende wird daraus die Geschwindigkeit berechnet und in Speed abgelegt. Beim ersten Eintrag enthält SpeedMess.Speed den Wert 0.
• Da die Geschwindigkeit sich von Meßpunkt zu Meßpunkt ändern kann, wird jede Geschwindigkeit separat berechnet und am Ende der Durchschnittwert ermittelt.
• Man könnte den Meß-Algorithmus so entwickeln, daß er Geschwindigkeiten mit allen denkbaren Vektoren zu messen erlaubt, also von rechts nach links ebenso wie von links nach rechts, von oben nach unten oder diagonal, falls das benötigt wird. So könnte man am Ende auch die Richtung ausgeben, in die sich das Objekt bewegt hat.

[Medium]

Oh Vorsicht. Sobald man Richtungserkennung haben will, kommen ungleich komplexere Themen wie Feature-Point-Extraction und/oder Objekterkennung mit ins Spiel. Das rein Anhand einer "Farbgrenze" zu machen ist das Gegenteil von Robust/Stabil. Bei der sugerierten unterirdischen Framerate ist das selbst mit den genannten Methoden noch extrem wackelig.

Beim Thema Geschwindigkeit sind wir ja eigentlich noch gar nicht. Es gilt zunächst mal überhaupt einigermaßen Verlässlich das Ereignis "Auto ist jetzt im Bild" zu ermitteln. (Bzw. irgend etwas, was nicht Asphaltfarben ist. Wobei noch zu bedenken ist, ob "Asphaltfarbe" ein Begriff ist, der von Tageszeit und/oder anderen Bedingungen losgelöst definierbar ist.) Vermutlich wäre am Ende wirklich ein Frame-by-Frame Vergleich besser als ein statisches Referenzbild. Dabei wird dann aber das Thema der Änderungsrate interessant, sprich sozusagen die Ableitung der absoluten Änderung. Erst wenn diese ausreichend groß wird kann man vermutlich von einem "Auto-ähnlichen Ereignis" reden. (Und da ist immer noch oberwichtig wie man "Änderung" errechnet. In Graustufen würde ich z.B. nicht konvertieren - warum sollte man sich wertvolle Infos zerbröseln, wenn man sie doch ohnehin bekommt? Es ist so ja schon schwer genug ein stabiles Verfahren dafür zu erstellen.)
All das aber auch erst nachdem man das Rauschen weggefiltert hat. Aber nicht zu viel! Plötzliches Einschalten von Straßenlaternen ist übrigens auch eine schnelle Änderung bei der die Ableitung groß werden dürfte. 100%ig wird man das vermutlich eh nicht in den Griff bekommen. Das geht nur, wenn man eine definierte konstante Beleuchtung garantieren kann, wie z.B. bei optischen Verfahren in der Industrie, wo Werkstücke in der Regel für sowas durch eine spezielle abgeschottete Box gefahren werden, in der immer die gleichen, bekannten Lichtverhältnisse vorherrschen.
Ja, natürlich gibt es Systeme wie Googles fahrerloses Auto, welches erstaunlich gut Dinge in seiner Umgebung klassifizieren kann. Hier stecken aber auch Mannjahrzehnte an Forschung und Entwicklung, sowie spezialisierte Hardware (mit einer ähnlichen Aufwandsstatistik) drin.


Eine auch nur ansatzweise brauchbare Geschwindigkeitsermittlung wird nachher sowieso wenn überhaupt nur dann gehen, wenn die Framerate um ein Vielfaches besser wird als "Oh, mein Auto ist soeben in voller Länge durch meinen Erfassungsbereich geflutscht". Je nach Abstand zum Auto sollten so 15-30fps eine absolute Untergrenze sein, wo man vielleicht, eventuell, mit viel Vorsicht einen Wert ermitteln kann, der zumindest etwa eine Größenordnung wiedergibt.

[Ilmug3]

Ups - hier tut sich ja noch was. Liegt es an den Feiertagen?

@Persau - du denkst zu große und professionell. Meine Überlegung war wirklich, nur einen winzigen (vllt 64 Pixel) Bereich zu beobachten und wenn sich dort etwas tut, die Zeit zu stoppen, bis sich in einem anderen Bereich des Bildes etwas tut. Mit der Zeitdifferenz und der Entfernung zwischen den Punkten in der Realität, könnte man die Geschwindigkeit ermitteln (dachte ich).

Das Rekalibrieren hätte man automatisch alle paar Minuten machen können.
Die ganze Geschichte war nicht gedacht über Tage ohne Aufsicht zu arbeiten.
Bisher hatte ich das von Hand mit der Stoppuhr und zwei Geländemarken gemacht.
Aber die Webcam ist auf jeden Fall ein Hinder- und Ärgernis
http://www.supra-electronics.com/typ...x_oid=1017&L=0

[Perlsau]

Zitat:

Zitat von Ilmug3 (Beitrag 1325257)

@Persau - du denkst zu große und professionell. Meine Überlegung war wirklich, nur einen winzigen (vllt 64 Pixel) Bereich zu beobachten und wenn sich dort etwas tut, die Zeit zu stoppen, bis sich in einem anderen Bereich des Bildes etwas tut. Mit der Zeitdifferenz und der Entfernung zwischen den Punkten in der Realität, könnte man die Geschwindigkeit ermitteln (dachte ich).

Diesen Einwand kann ich jetzt erstmal nicht nachvollziehen: Wo genau denke ich "zu groß" oder "zu professionell"? Ich hab lediglich versucht, ein übersichtliches Ablaufschema zu konzipieren. Sogar das mit dem kleinen Ausschnitt habe ich mit einbezogen. Und ja, man kann auch die Geschwindigkeit berechnen, auch das habe ich in das Konzept einfließen lassen. Worüber also "beschwerst" du dich jetzt? Ist so ein Konzept etwa unerwünscht? Dann entschuldige meinen unangebrachten Eifer und überlese es einfach.

Zitat:

Zitat von Ilmug3 (Beitrag 1325257)

Aber die Webcam ist auf jeden Fall ein Hinder- und Ärgernis
http://www.supra-electronics.com/typ...x_oid=1017&L=0

Selbstverständlich benötigst du auch entsprechende Hardware, die das leistet, was du von ihr erwartest. Ich benutze als Eingang für einen Bewegungsmelder z.B. eine dieser Mini-Kameras, die ich manchmal auch an meinem Heli- oder Quattrocopter befestige. Die Kameras gab's mal vor Jahren billig in Hongkong zu kaufen (Versandkosten höher als die Kamera, daher hab ich damals gleich mehrere bestellt), mit integriertem Akku und Steckplatz für eine Speicherkarte. In DE sind die zu teuer, und zum Glück hat der Zoll die durchgewunken, nachdem ich vor den Augen der Zollbehörde den Karton geöffnet hatte. Auch an der Mütze oder am Fahrrad liefert diese Kamera noch ausreichend Qualität. Mit Nachtaufnahmen wie bei deinem Modell kann ich natürlich nicht aufwarten. Wenn deine Kamera zu langsam ist, mußt du eben eine kaufen, die für deine Zwecke eine ausreichend hohe Bildfolge liefert.

[Ilmug3]

@Perlsau
Nicht böse sein. Ich habe es eher anerkennend gemeint. Zu viel Mühe, für mein kleines Problem.
Das ergab sich auch aus deinem achten Punkt: "Um nun sowas wie eine Geschwindigkeit bestimmen zu können, wird der Bildbereich nach dem erstn Feststellen einer Farbänderung in Bewegungsrichtung reduziert: Kommt die Bewegung z.B. von rechts, wird der zu beobachtende Ausschnitt rechts um eine festgelegte Anzahl an Pixeln beschnitten."
Das geht über mein Ziel Durchfahren von Start- und Zielpunkt deutlich hinaus - oder verstehe ich das falsch.

Ich habe versucht meine kleine Aufgabe mit Bordmitteln zu lösen und musste dabei erkennen,
dass Probleme auftauchen, wo ich sie nicht vermutet habe. Ob ich mir deshalb aber eine bessere
(wohl auch teurere Webcam) kaufe, bezweifle ich.

Ich wollte mir mit der Aufgabenstellung etwas die Zeitvertreiben (was auch gelungen ist).
Von der Lösung des Problems hängt nicht mein Leben ab.
Schöne Feiertage noch...

[Garfield]

Zunächst als Hinweis: Die Videoüberwachung öffentlicher Straßen mittels fest installierter Kamera ist illegal.

Ich verstehe nicht, warum hier die Zeitspanne gemessen werden soll, um die Geschwindigkeit zu ermitteln. Durch die fesgelegte Framerate werden Bilder in bestimmten Zeitabschnitten gefertigt. Also müsste man doch die zurückgelegte Strecke ermitteln. Sprich zuerst den Bereich kontrollieren, in welchem das Objekt zuerst auftauchen muss. Dann nach einer bestimmten Zeitspanne (Anzahl von Bildern) den Bereich, in welchem sich das Objekt dann befinden sollte. Daraus die zurückgelegte Strecke ermitteln und die Geschwindigkeit berechnen. :?

[Garfield]

Zitat:

Zitat von Ilmug3 (Beitrag 1325095)

Schlimmer noch ist die grottige Framerate der Webcam. ...

Die Framerate ist in der Regel von der Auflösung abhängig. Kleinere Auflösung höhere Framerate. Eventuell zwei Kameras verwenden. Eine mit geringerer Framerate, welche auch einen geringeren Erfassungsbereich haben kann, für die Erkennung der ersten Bewegung und die zweite macht dann zwei Bilder für die Auswertung.

[Medium]

Die Framerate kam ins Spiel, weil der TE beiläufig geäussert hatte dass sie so schlecht ist, dass ihm teilweise ganze Autos in voller Länge durch den Erfassungsbereich "hüpfen". Das muss Hardwareseitig (bzw. Netzwerkseitig) behoben werden. Nicht dran aufhängen.

[Garfield]

Richtig. Die Framerrate ist ein Hardwareproblem. Die PiCamera besitzt zum Beispiel einen Sensor OV5647. Bei dem ist angegeben:

QSXGA(2592x1944): 15 fps
1080p: 30 fps
960p: 45 fps
720p: 60 fps
VGA(640x480): 90 fps
QVGA(320x240): 120 fps


Ich sehe gerade, ich habe "Eine mit geringerer Framerate, ..." geschrieben. Richtig muss das " Eine mit geringerer Auflösung, ..." heißen.