Bildverarbeitung - Bewegung erkennen - HILFE!
-
TGGC schrieb:
@Sgt.: Bitte?
Vorne wird das "dunkle Auto" nur einen "Frame" lang sein, hinten länger...
Und das sich Heck und Front gleich schnell bewegen, ist auf einer Kurve (für einen seitlich stehenden Betrachter) auch nicht immer gegeben.
-
TGGC schrieb:
Etwas konkretes daraus zu machen, sollte deine Aufgabe sein. Ich weiss ehrlich gesagt nicht so ganz, was du noch von uns als Antworten erwartest?
Bye, TGGC
Ganz ehrlich, und bitte nicht böse sein, von euch eigentlich gar keine mehr. Ihr habt ja alle selbst gesagt, dass ihr da nicht so den plan von habt und ich fürchte, dass sich das tatsächlich zu ner sache für profis entwickelt.
Denn für uns ist klar wie wir das anstellen müssen, nur am algorithmus haperts halt.
-
Sgt. Nukem schrieb:
Vorne wird das "dunkle Auto" nur einen "Frame" lang sein, hinten länger...
Es gibt ja nur einen Frame. Und warum sollte es hinter länger sein? (bewegt es sich mit ~c?
Sgt. Nukem schrieb:
Und das sich Heck und Front gleich schnell bewegen, ist auf einer Kurve (für einen seitlich stehenden Betrachter) auch nicht immer gegeben.
Richtig. Nur haben Autobahnen wenige enge Kurven.
Bye, TGGC
-
TGGC schrieb:
Etwas konkretes daraus zu machen, sollte deine Aufgabe sein. Ich weiss ehrlich gesagt nicht so ganz, was du noch von uns als Antworten erwartest?
Für ihn ist doch glasklar wie er das anstellen muss ... nur der Algorithmus fehlt ihm noch. Ein echter Profi. :p
-
Wenn du nur Autos zählen willst, ist es doch relativ einfach. Setz ans Ende der Brücke einen "Sensor", den du programmierst. Sobald die Ausgangslage (Hintergrund) verschwindet (also verändert) zählst du plus 1, und wartest so lange bis der Hintergrund wieder erscheint. Das setzt natürlich eine halbwegs flüssige Bilderflut voraus!
Hast du denn einen Bildfluss oder ist er eher abgehackt?
Dann musst du andere Algorithmen ansetzen. Wie wäre es mit Entropieberechnung?
Wäre es nicht möglich daraus die Anzahl der Fahrzeuge zu errechnen, oder zumindestens zu schätzen?
-
TGGC schrieb:
Sgt. Nukem schrieb:
Vorne wird das "dunkle Auto" nur einen "Frame" lang sein, hinten länger...
Es gibt ja nur einen Frame. Und warum sollte es hinter länger sein? (bewegt es sich mit ~c?
Deswegen hatte ich Frame in Anführungszeichen... -> Ein Kameraschnappschuß wird aber nunmal nicht in unendlich kurzer Zeit gemacht (Belichtungszeit) -> Ich sagte ja schon: Bei hoher Verschlußzeit!!
[quote="TGGC]
Sgt. Nukem schrieb:
Und das sich Heck und Front gleich schnell bewegen, ist auf einer Kurve (für einen seitlich stehenden Betrachter) auch nicht immer gegeben.
Richtig. Nur haben Autobahnen wenige enge Kurven.[/quote]
Hab' ich auch nicht behauptet. Ich wollte nur Deine allgemeine Aussage relativieren...ºgrimmsenº
schrieb:c:\deltree windows
Wie soll das klappen!?? Ich habe kein "deltree"-Kommando auf dem Root von C.
Oder meintest Du etwa "C:\> deltree windows"... ??
P.S.: Man sollte schon wissen, über was man lästert...
-
-- gehört nicht zum Thema : An --
So sieht die Eingabezeile vor dem erlösenden Enter aus!
Man sollte schon wissen über was man lästert!
-- gehört nicht zum Thema : Aus --
-
ºgrimmsenº
schrieb:So sieht die Eingabezeile vor dem erlösenden Enter aus!
Wenn Du mit "erlösenden" "sich vom Windows befreien" meinst: Nö.
-
Sgt. Nukem schrieb:
TGGC schrieb:
Sgt. Nukem schrieb:
Und das sich Heck und Front gleich schnell bewegen, ist auf einer Kurve (für einen seitlich stehenden Betrachter) auch nicht immer gegeben.
Richtig. Nur haben Autobahnen wenige enge Kurven.
Hab' ich auch nicht behauptet. Ich wollte nur Deine allgemeine Aussage relativieren...
Ahso? Welche denn? Habe nichts in dieser Richtung behauptet.
Ich weiss nicht, was du mit deinem "hinten länger als vorne" hast, ist auf jeden Fall unerheblich.
Man stelle sich mal folgende Situation vor:
Man nimmt eine weisses Quadrat aus Pappe vor einer schwarzen Wand auf, das genau eine Pixel belegt. Unsere Kamera hat keine Blende usw. Ausserdem scheint ein konstantes direktionales Licht senkrecht zu dem Quadrat. Liegt das Quadrat nun genau auf einem Pixel, und bewegt sich nicht, so ist die Helligkeit des Pixel proportional zur Verschlusszeit. Ist ein Pixel nur zu einem Teil p ( 0 <= t <= 1 ) bedeckt, so ist die Helligkeit h= p * t * k (t ist die Zeit, k der Proportionaltätsfaktor). Ändert sich der Teil p nun ständig (Bewegung!), so muss man immer kleine Zeitschritte betrachten, was selbstverständig auf ein Integral führt: h= Integral von t0 bis t1 von h= p(t) * k dt. Wenn man nun einmal einen Blick darauf wirft so ist die Helligkeit von der Fläche unter p(t) abhängig jedoch nicht von dem konkreten Wert an p(t0) oder p(t1), daher kann man aus h auch nicht auf diese Werte schliessen. Man kann aus dem Pixel also nicht bestimmen was zu Beginn und zu Ende des Bildes war.Bye, TGGC
-
TGGC schrieb:
Sgt. Nukem schrieb:
TGGC schrieb:
Sgt. Nukem schrieb:
Und das sich Heck und Front gleich schnell bewegen, ist auf einer Kurve (für einen seitlich stehenden Betrachter) auch nicht immer gegeben.
Richtig. Nur haben Autobahnen wenige enge Kurven.
Hab' ich auch nicht behauptet. Ich wollte nur Deine allgemeine Aussage relativieren...
Ahso? Welche denn? Habe nichts in dieser Richtung behauptet.
Ich weiss nicht, was du mit deinem "hinten länger als vorne" hast, ist auf jeden Fall unerheblich.
Man stelle sich mal folgende Situation vor:
Man nimmt eine weisses Quadrat aus Pappe vor einer schwarzen Wand auf, das genau eine Pixel belegt. Unsere Kamera hat keine Blende usw. Ausserdem scheint ein konstantes direktionales Licht senkrecht zu dem Quadrat. Liegt das Quadrat nun genau auf einem Pixel, und bewegt sich nicht, so ist die Helligkeit des Pixel proportional zur Verschlusszeit. Ist ein Pixel nur zu einem Teil p ( 0 <= t <= 1 ) bedeckt, so ist die Helligkeit h= p * t * k (t ist die Zeit, k der Proportionaltätsfaktor). Ändert sich der Teil p nun ständig (Bewegung!), so muss man immer kleine Zeitschritte betrachten, was selbstverständig auf ein Integral führt: h= Integral von t0 bis t1 von h= p(t) * k dt. Wenn man nun einmal einen Blick darauf wirft so ist die Helligkeit von der Fläche unter p(t) abhängig jedoch nicht von dem konkreten Wert an p(t0) oder p(t1), daher kann man aus h auch nicht auf diese Werte schliessen. Man kann aus dem Pixel also nicht bestimmen was zu Beginn und zu Ende des Bildes war.Bye, TGGC
Wieso nicht?!
Man stelle sich mal folgende Situation vor:
Man hat 2 Pixel direkt nebeneinander, in einer beliebigen Farbe.
Jetzt belichtet man sie.
Je länger belichtet wird, umso intensiver erscheinen die Pixel (von schwarz nach weiß gehend).
Sie sind also beide gleich hell.
Während der Belichtung bewegen sich die Pixel aber nach rechts.
Der "vordere" Pixel erscheint jetzt wieder vor dem dunklen Hintergrund und färbt das belichtete Objekt quasi "wieder von neu". Der "hintere" Pixel liegt noch im schon vom "vorderen" Pixel belichteten Teil und fügt dort nur noch additiv "mehr Farbe" hinzu, erscheint also intensiver...
-
Weil ein einzelner Wert bei der Berechnung des Integrals keine Rolle spielt.
Die Pixel können sich nicht bewegen, nur die Objekte vor der Kamera. Beschreibe das mal genauer. Und beschreibe vor allem, wie du von dem Ergebnis auf die Bewegung der Objekte schliessen willst. Das ist der eigentliche Punkt, und dazu hast du noch überhaupt nichts gesagt.
Ok, noch ein Gedankenexperiment. Mache ein Bild, von einem fahrenden Auto von links nach rechts, mit v km/h. Das Auto ist um d cm verschmommen. Es gilt a = v*k. Nun lasse das Bild von rechts nach links mit v fahren, und mache ein Bild davon. Es ist einzusehen, das Auto wird wieder um d verschwimmen, und nicht plötzlich scharf erscheinen. Insgesamt, ist das Auto also um 2d verhschoben, was einer Gesamtgeschwindigkeit von 2v entspricht. Dies könnte man sich dadurch erklären, das sich nur die Beträge von v addieren, also die Richtung keine Rolle spielt.
Bye, TGGC
-
ºgrimmsenº
schrieb:Wenn du nur Autos zählen willst, ist es doch relativ einfach. Setz ans Ende der Brücke einen "Sensor", den du programmierst. Sobald die Ausgangslage (Hintergrund) verschwindet (also verändert) zählst du plus 1, und wartest so lange bis der Hintergrund wieder erscheint. Das setzt natürlich eine halbwegs flüssige Bilderflut voraus!
Hast du denn einen Bildfluss oder ist er eher abgehackt?
Dann musst du andere Algorithmen ansetzen. Wie wäre es mit Entropieberechnung?
Wäre es nicht möglich daraus die Anzahl der Fahrzeuge zu errechnen, oder zumindestens zu schätzen?Lies dir bitte erstmal alle anderen Beträge hier furch. Dann siehst du, dass es zwar mit einem Sensor wesentlich einfacher wäre aber auch, dass diese Lösung hier beim besten willen nicht gefragt ist...
-
Lies dir bitte mal meinen Post durch, dann siehst du, dass ich einen Sensor auf den Bildausschnitt und nicht an der Brücke gemeint habe. Das wäre zum Zählen die einfachste Methode, setzt aber ein flüssiges Video voraus. Ich vestehe nicht warum du dich gleich so angepisst fühlst. Wer Hilfe sucht kann auch einen anderen Ton an den Tag legen.
Warum willst du dir es denn so schwer machen? Hast du denn nun einen flüssigen Film, oder schiesst eure Kamera nur alle paar Sekunden ein Bild?
-
@ºgrimmsenº
Oh! Dann hab ich dich falsch verstanden!
Ich fühl mich nich angepisst. Es ist nur so, dass ich das hier schon mehrfach erklärt hab.
Wir haben in dem sinne keinen flüssigen Film. Die Kamera läuft zwar permanent, aber wir müssen uns die Bilder einzeln holen und verarbeiten. So kommen wir auf max. 10-15 Bilder pro Sekunde.
Und wir machen uns das so schwer, weil wir müssen. Wenns nach mir ginge hätten wir schon lange auf der Autobahn ne Leiterschleife liegen
-
TGGC schrieb:
Weil ein einzelner Wert bei der Berechnung des Integrals keine Rolle spielt.
Die Pixel können sich nicht bewegen, nur die Objekte vor der Kamera. Beschreibe das mal genauer. Und beschreibe vor allem, wie du von dem Ergebnis auf die Bewegung der Objekte schliessen willst. Das ist der eigentliche Punkt, und dazu hast du noch überhaupt nichts gesagt.
Tja, jemand müsste mal Bilder von fahrenden Fahrzeugen mit hoher Verschlußzeit machen...
TGGC schrieb:
Ok, noch ein Gedankenexperiment. Mache ein Bild, von einem fahrenden Auto von links nach rechts, mit v km/h. Das Auto ist um d cm verschmommen. Es gilt a = v*k. Nun lasse das Bild von rechts nach links mit v fahren, und mache ein Bild davon. Es ist einzusehen, das Auto wird wieder um d verschwimmen, und nicht plötzlich scharf erscheinen. Insgesamt, ist das Auto also um 2d verhschoben, was einer Gesamtgeschwindigkeit von 2v entspricht. Dies könnte man sich dadurch erklären, das sich nur die Beträge von v addieren, also die Richtung keine Rolle spielt.
Mhhh... versteh' nicht ganz, worauf Du hinaus willst...
-
Ich will darauf hinaus, das die Richtung der Bewegung (links nach rechts oder rechts nach links) für das Bild keine ROlle spielt sondern nur die Geschwindigkeit. Ergo kann aus dem Bild die Richtung nicht erkannt werden. Da du nicht ansatzweise zeigen kannst, wie das gehen kann, ist dies wohl auch korrekt.
Bye, TGGC
-
Naja, Du hast nicht ganz unrecht. Aber es gibt ja noch Zusatzinformationen auf dem Bild: Hintergrund und möglicherweise Autos, die sich in entgegengesetzter Richtung bewegen. Außerdem haben wir ja eine Bildfolge. Daraus kann man vielleicht auch etwas zusammensetzen. Ein Ansatzüunkt wären zumindest mal Differenzbilder. Man könnte zum Beispiel Immer 2 aufeinanderfolgende Bilder voneinander abziehen und dann vielleicht drei oder vier Stück dieser Differenzbilder miteinander mitteln und zwar: neustes Bild: Faktor 1/2, nächst älteres 1/3, nächst älteres 1/6. Dadurch müßten sich schlieren der Umrisse von den Fahrzeugen bilden, die in Bewegsungsrichtung an Intensität zunehmen.
Vielleicht könnte man die Differenzbilder noch etwas weichzeichen bzw. durch nen Filter schicken um Hintergrundkram rauszufiltern.MfG Jester
-
Kann es sein, das du den Thread gar nicht gelesen hast?
Bye, TGGC
-
Das ganze würde doch wesentlich besser funktionieren, wenn man statt einem "Sensor" (wie es grimmsen vorgeschlagen hat) mehrere in äquidistanten Abständen macht, die, wie gesagt, quer über die Fahrbahn verlaufen (natürlich nur virtuell gesehen). So denke ich würde das auch mit einem stockenden Bilderfluss funzen.
Falls ich dich richtig verstanden habe, erhöhen Autos beider Fahrtrichtungen deinen Zähler, oder? Dann müsste so also nicht einmal mehr eine Richtungsunterscheidung durchgeführt werden. Auch das Problem mit den Überlagerungen von Fahrzeugen in entgegengesetzter Richtung fällt so raus, da kein Fahrzeug so lang ist, dass es die ganze Bildschirmbreite nutzen würde und so mindestens ein "Sensor" die Lage richtig erfassen würde.
Als Messwert würde ich dann denjenigen "Sensor" heranziehen, der den größten Wert geliefert hat und vielleicht nach gleichzeitiger Beobachtung mit dem menschlichen Auge (und dessen richtiger Zählung) noch mit einem Korrekturfaktor 1.xxx multiplizieren, da wahrscheinlich auch den bestplaziertesten Sensor die ein oder andere Überlagerung täuschen würde.Hoffe, meine Überlegungen stimmen so weit...
cya,
FellaR
-
TGGC schrieb:
Ich will darauf hinaus, das die Richtung der Bewegung (links nach rechts oder rechts nach links) für das Bild keine ROlle spielt sondern nur die Geschwindigkeit. Ergo kann aus dem Bild die Richtung nicht erkannt werden. Da du nicht ansatzweise zeigen kannst, wie das gehen kann, ist dies wohl auch korrekt.
Doch. Es gibt ja noch eine Größe: Die Intensität der Pixel!
