Bildverarbeitung - Bewegung erkennen - HILFE!
-
º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!
-
Sgt. Nukem schrieb:
Doch. Es gibt ja noch eine Größe: Die Intensität der Pixel!
Na dann sag, wie es gehen soll. Es geht nicht.
-
Fellar schrieb:
Falls ich dich richtig verstanden habe, erhöhen Autos beider Fahrtrichtungen deinen Zähler, oder?
Fast richtig! Wir müssen beide Fahrtrichtungen getrennt zählen und analysieren!
Aber ich hab das Gefühl, dass wir der Sache allmälich ein bisschen näher kommen!!!
-
Wenn jeder Zähler nur 70% der Autos erkennt (wegen Überdeckung), dann ist die Maximalzahl doch auch nur 70%?
-
jo ich meine ist ja alles gut und schön...aber ich seh irgendwie nur eine spur auf dem bild...irgendwie...
tschööö
-
TGGC schrieb:
Sgt. Nukem schrieb:
Doch. Es gibt ja noch eine Größe: Die Intensität der Pixel!
Na dann sag, wie es gehen soll. Es geht nicht.
Hab' ich doch schon. Das Heck wirkt intensiver, da es schon durch die Vorgänger-Pixel "dunkler" bzw. "heller" erscheint.
P.S.: Falls ihr das echt hinbekommt, würd' ich mir gerne das fertige Projekt nochmal ansehen.
Die Vorbedingungen waren jedenfalls angsteinflößend...
-
Sgt. Nukem schrieb:
Falls ihr das echt hinbekommt, würd' ich mir gerne das fertige Projekt nochmal ansehen.
Das soll kein Problem sein! Das Ergebnis wird ja auch im Internet zu bestaunen sein (also Anzahl kfz/min, Verkehrsanalyse, Statistik etc.)
Sgt. Nukem schrieb:
Die Vorbedingungen waren jedenfalls angsteinflößend...
Es geht! Das einzige wirkliche Problem ist halt der heir gesuchte Algorithmus. Der Rest ist "pillepalle" *g*
-
Fast richtig! Wir müssen beide Fahrtrichtungen getrennt zählen und analysieren!
Gut, dann wird die Sache noch ein wenig schwieriger. Wie hoch ist denn in etwa die Framerate? Hoch genug, dass ein Auto den "Sensor" in zügiger Vorbeifahrt mehr als einmal aktiviert?
Ich denk auch, dass alles, was auf eine Formenerkennung/Pixelabgleich etc. hinausläuft bei dem gelieferten Bild sinnlos ist.