Autor Beitrag
Tomac
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 113

Win XP
D6 Ent
BeitragVerfasst: 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
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 2889
Erhaltene Danke: 13

W2000, XP
D6E, BDS2006A, DevExpress
BeitragVerfasst: 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
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 1905

W98, XP
D7 PE, Lazarus, WinAVR
BeitragVerfasst: 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 :D
alzaimar
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 2889
Erhaltene Danke: 13

W2000, XP
D6E, BDS2006A, DevExpress
BeitragVerfasst: 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
ontopic starontopic starontopic starontopic starhalf ontopic starofftopic starofftopic starofftopic star
Beiträge: 450

WIN XP, SuSE 9.3
D3 Prof, D6 Pers, 2005 Pers
BeitragVerfasst: 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
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 33

WinXP SP2
Delphi 6 Personal ;) , C# (VS 2003 Prof.)
BeitragVerfasst: 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 Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 113

Win XP
D6 Ent
BeitragVerfasst: 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



BeitragVerfasst: 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



BeitragVerfasst: 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
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 1905

W98, XP
D7 PE, Lazarus, WinAVR
BeitragVerfasst: Fr 21.10.05 08:35 
Verstanden ja aber Code wäre mal interessant, ich kenn mich mit scanline nicht os aus :oops:
MadCyborg
Hält's aus hier
Beiträge: 14



BeitragVerfasst: 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...