Bildverarbeitung - Bewegung erkennen - HILFE!
-
Sgt. Nukem schrieb:
Also ich find' schon.
Wie gesagt ist es nicht "verschwommen" genug...Und daß es einfach wäre, besonders algorithmisch, hab' ich ja auch nicht behauptet...
Egal wie verschwommen es nun ist, es ist überhaupt nicht möglich daraus die Bewegungsrichtung abzuleiten. Es gibt stets zwei Lösungen. Ich kann das gerne mal an einem Gedankenexperiment erläutern!
-
TGGC schrieb:
Sgt. Nukem schrieb:
Also ich find' schon.
Wie gesagt ist es nicht "verschwommen" genug...Und daß es einfach wäre, besonders algorithmisch, hab' ich ja auch nicht behauptet...
Egal wie verschwommen es nun ist, es ist überhaupt nicht möglich daraus die Bewegungsrichtung abzuleiten. Es gibt stets zwei Lösungen. Ich kann das gerne mal an einem Gedankenexperiment erläutern!
Wenn vorne und hinten gleich verschwimmen würden ja.
-
Sgt. Nukem schrieb:
Wenn vorne und hinten gleich verschwimmen würden ja.
Genau das wird passieren, solange sich Front und Heck mit der gleichen Geschwindigkeit bewegen.
Bye, TGGC
-
Hinten kommt stärker durch als vorne.
-
ähhmm... Leute.. Die Diskussion ist ja ganz interessant und ich wll auch nicht meckern, aber wir schweifen da etwas ab, kann das sein?
Wir brauchen einfachnur nen Algorithmus, um einen weissen Fleck auf dem einen Bild mit einem auf dem nächsten Bild zu vergleichen...
-
@Sgt.: Bitte?
@el Clio: "einfach nur" ist gut. Ich würde erstmal den Schwerpunkt der Flecken berechnen/ abschätzen, diese dann so übereinanderlegen un voneinander abziehen. Je weniger übrig bleibt, umso Ähnlicher waren sich die Flecken. Ich denke bei dieser konkreten Frage, lohnt sich evtl. auch eine Websuche.
Bye, TGGC
-
TGGC schrieb:
Ich denke bei dieser konkreten Frage, lohnt sich evtl. auch eine Websuche.
ne leider eben nicht. da gibts zwar ne menge, aber nix konkretes. es scheint auch ne menge leute im netz zu geben, die sowas können und machen (beruflich) aber die geben natürlich ihre algorithmen nich so einfach her.
-
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
-
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...
