Autor |
Beitrag |
Tomac
      
Beiträge: 113
Win XP
D6 Ent
|
Verfasst: Di 18.10.05 13:05
Hallo!
Ich muss für ein Projekt einen Algorithmus für eine Webcam entwickeln. Das ganze soll so funktionieren, dass sobald sich etwas vor der Webcam bewegt, diese die Bewegung erkennt und sofort darauf reagiert (vorerst mal a Meldung ausgeben).
I hätte mir überlegt, ständig die einzelnen Pixel zu überprüfen und wenn die Anzahl der ungleichen Pixel einen gewissen Grezwert übersteigt wird eine Bewegung erkann. Doch irgendwie zweifle ich noch an der Effizienz davon.
Irgendwelche ideen wie man das besser machen könnte?
Vielen Dank
Tomac
|
|
alzaimar
      
Beiträge: 2889
Erhaltene Danke: 13
W2000, XP
D6E, BDS2006A, DevExpress
|
Verfasst: Di 18.10.05 13:12
Besser ja, aber nicht so simpel. Denn eigentlich brauchst Du eine Mustererkennung, die Hintergründe wegrechnet. Es könnte sich ja im Hintergrund ein Baum befinden...
Ich denke, bei Dir ist das nicht der Fall... Also würd ich mal mit deiner Lösung (und nimm TBitmap.Scanline!) und dem Grenzwert rumexperimentieren.
_________________ Na denn, dann. Bis dann, denn.
|
|
digi_c
      
Beiträge: 1905
W98, XP
D7 PE, Lazarus, WinAVR
|
Verfasst: Di 18.10.05 14:07
[search]Die Frage ist was du haben willst:
1.DAS etwas passiert
2.oder WAS da passiert
zu 1.
Das ist denke ich noch ganz gut mit deiner Methode möglich und mit Scanline auch einigermaßen schnell machbar. Tolleranzen kann man da auch schnell einbauen.
Eine andere Möglichkeit wäre über das verknüpfen des Bildes vorher mit dem Bild nachher so das nur die Differenzpixel übrigbleiben und die dann zählen(glaube XOR wäre das, musst mal mit einem Ebenenfähigen Grafikprogramm ausprobieren)
zu 2.
Schwiieeeerig
Auf der CeBit habe ich gesehen das dabei das Vorgehen mit den Differnzbildern gemacht wird um die Eingangsdaten zu reduzieren und dann aus einem neuen Differenzbild Bewegungsvektoren gebildet werden.
Das ist aber alles höhere Mathematik
Da gibts aber schon Software für 
|
|
alzaimar
      
Beiträge: 2889
Erhaltene Danke: 13
W2000, XP
D6E, BDS2006A, DevExpress
|
Verfasst: Di 18.10.05 14:12
Ich kenne Forschungsarbeiten, die es schaffen, eine Person, die durch den Raum geht von einer Person, die dahiner am Tisch sitzt, zu unterscheiden. Während der Sesselpf***er keinen Alarm auslöst, weil er sich nur ein wenig bewegt, Wird die Person, die sich fortbewegt, doch tatsächlich erkannt, und zwar gleich mit Gesichtserkennung und so
Da es eine Forschungsarbeit ist, die so das Maximale darstellt, was sich derzeit machen lässt, solltest Du die XOR-Gesichte mal weiterverfolgen. Du wirst staunen, was man mit einer Konvertierung auf kleinere Farbtiefen (bis zu schwarz/weiss), einer Reduzierung der Auflösung und etwas Schmalz so alles erkennen lässt... Das sind ganz einfache Routinen bzw. Aufrufe, aber das Resultat ist dann schon erststaunlich.
_________________ Na denn, dann. Bis dann, denn.
|
|
hallo
      
Beiträge: 450
WIN XP, SuSE 9.3
D3 Prof, D6 Pers, 2005 Pers
|
Verfasst: Di 18.10.05 14:50
Ich hab auch schonmal sowas gebraucht. Nur hab ich ein Problem gehabt: Er hat zwar größere Veränderungen erkannt, nur das Bildrauschen war zu stark => Fehlalarm.
Die Methode:
Einige Pixelfarben ermitteln, und diese zusammenzählen. Dann kommt man auf einen Wert. Dann hab ich sie mit dem anderen Wert verglichen. Da aber nie etwas richtiges rauskam und das Bild zu schlecht war, hab ich es dann bisher aufgegeben.
Auf so einem Tag der offenen Tür hab ich einige Roboter gesehen, die mit 360° Sicht Fußball oder sowas ähliches spielen.
Da hatte aber auch der Ball eine andere Farbe als die umgebung. Und da wurde soviel ich weiß auch die Form des Balles mit berücksichtigt.
Bei Menschen ist das schon schwerer. Aber wenn du einen einfarbigen nicht strukturierten Hintergrund hast ist es einfacher!
_________________ Der beste je Programmierte Trojaner: Windows XP
Wäre es nicht adequat, den Usus heterogener Termini zu minimieren?
|
|
mg80s
      
Beiträge: 33
WinXP SP2
Delphi 6 Personal ;) , C# (VS 2003 Prof.)
|
Verfasst: Mi 19.10.05 10:19
Ich hatte auch mal eine Bewegungserkennung gebaut, die lief nach dem einfachen Prinzip des Pixelvergleichs von Bild A und Bild B, allerdings mit ein paar kleinen "Optimierungen", das ganze war allerdings in C++, daher weiss ich nicht infern es sich perfomant übertragen lässt.
Ich habe Video-Ströme entgegengenommen, die ein Byte-Array waren, dabei waren jeweils 3Byte ein Pixel (1.:R, 2.:G, 3.:B) und dann Breite*Höhe diese 3Bytes.
Nun habe ich first of all nur jedes 5te Pixel überhaupt verglichen, da sich Bewegungen (je nach Anwendung) meist in größeren Bereichen abspielen und zudem nur den roten Farbanteil verglichen. War dann eine Toleranz überschritten, wurde es markiert (was allerdings blöd aussieht, wenn man nur jedes 5te Pixel untersucht  )
Das hatte ne ziemlich gute Performance, glaube knapp 20-30ms pro Frame.
|
|
Tomac 
      
Beiträge: 113
Win XP
D6 Ent
|
Verfasst: Mi 19.10.05 16:30
also erstmal danke für eure antworten.
es geht dabei wirklich nur darum dass man erkennt OB sich was bewegt, was genau passiert is egal, hauptsache die kamera erkennt dass sich was tut.
Die Idee mit den Videoströmen hört sich mal ganz gut an, also das mit dem Byte-Array, werd mal schaun ob ich daraus was machen kann.
Vielen Dank an alle
|
|
drasir
Hält's aus hier
Beiträge: 15
|
Verfasst: Do 20.10.05 23:20
Hab mich auch schonmal rein gedanklich mit dem Thema befasst.
Kann leider nichtmehr sagen ob ich das irgendwo gelesen habe oder ob es wirklich meine Idee war,
aber ich dachte man macht am besten zwei Bilder bzw. betrachtet das aktuelle und das jeweilige davor
und verwendet dann auf die Bilder eine XOR Operation. Somit bekommt man nurnoch die Pixel die nicht übereinstimmen..
|
|
MadCyborg
Hält's aus hier
Beiträge: 14
|
Verfasst: Do 20.10.05 23:22
hi,
ich habe grade sowas programmiert.
dabei habe ich mit scanline alle pixel verglichen, dabei aber noch keinen schwellwert verwendet. um das bildrauschen als alarm-quelle auszuschließen, lasse ich einen pixel nur dann als geänderten zu, wenn alle nachbarn und nachbars-nachbarn auch als änderung registriert wurden. --> was sich ändert muss mindestens 5x5 pixel auf dem bild einnehmen.
bei einem stillstehenden bild habe ich bei 352x288 Pixeln nur noch 5-15 gültige änderungen durch bildrauschen. da braucht man halt nur noch nen schwellwert zu benutzen.
ich hoffe das is halbwegs verständlich...
|
|
digi_c
      
Beiträge: 1905
W98, XP
D7 PE, Lazarus, WinAVR
|
Verfasst: Fr 21.10.05 08:35
Verstanden ja aber Code wäre mal interessant, ich kenn mich mit scanline nicht os aus 
|
|
MadCyborg
Hält's aus hier
Beiträge: 14
|
Verfasst: Fr 21.10.05 18:28
zu scanline gibts hier im forum eigentlich mehr als genug beispiele, die man einfach nur kopieren muss...
btt: habs in meinem vorigen post vergessen, aber alzaimar erwähnte es bereits:
es bringt sehr viel geschwindigtkeit, wenn man die datenmenge reduziert, ich benutze wie gesagt 352x288 Pixel statt der 640x480 die meine cam liefert. die farbtiefe habe ich direkt mal auf 8 bit gesetzt. ich habe gerade eben mal mit 24 bit probiert, da bin ich von 20-50 ms pro bild auf 170-200ms runter (oder hoch, wie mans nimmt  ).
€\wenn irgendjemand meinen quelltext sehen will kann ich den posten...nur is der alles andere als hübsch, und jeder profi wird was zu verbessern haben...kommentiert ist er auch nur rar...
|
|
|