hallo leute, ich kann Videosignale von 2 verschiedenen Kameras mit einem FPGA Board an einem Monitor je nacheinander anzeigen lassen. Wenn ich die beide fusioniert mit der Mittelwert Berechnung von Jedem Pixel, erschient keine Bilder mehr auf dem Dysplay(Bidschirm) wo kann das Problem sein? Danke
> ich kann Videosignale von 2 verschiedenen Kameras mit einem FPGA Board > an einem Monitor je nacheinander anzeigen lassen. Das ist nicht wieter schwierig. > Wenn ich die beide > fusioniert mit der Mittelwert Berechnung von Jedem Pixel Wie hast du die Kameras synchronisiert? Oder wandelst du nur die Signale und addierst sie zusammen?
Was macht dein Fusion-Algorithmus? Deine Fehleranalyse ist extrem schwach und erlaubt nicht mal annaeherungsweise irgendwelche Vorschlaege. Code posten!
@matthias: mein fusionalgorithmus ist nur einige Zeile: pixelclk 27 MHz Pixelwert Kam1 = ycam1 Pixelwert Kam2 = ycam2 fusionPixelwert = (ycam1 + ycam2)/2 VGA Clk = 27 Mhz VGA = fusionPixelwert @Miller ich wandele die Signale und addiere, sollte ich die kameras synchronisieren? Thanks
Ja natürlich, sonst mittelst Du die SynchSignale weg :-) Beide Datenströme in zwei getrennte Wechselbuffer schreiben (-> 4 Buffer), dann Punktweise mitteln. Die Wechselbuffer sind nötig, weil die Kameras unterschiedliche Takte haben werden und die Bilder nicht zeitgleich fertig sind - zudem die eine etwas mehr Bilder produzieren kann. Und: Neue Synchsignale erzeugen.
> Beide Datenströme in zwei getrennte Wechselbuffer schreiben (-> 4 > Buffer), dann Punktweise mitteln. Die Wechselbuffer sind nötig, weil die > Kameras unterschiedliche Takte haben werden und die Bilder nicht > zeitgleich fertig sind - zudem die eine etwas mehr Bilder produzieren > kann. > > Und: Neue Synchsignale erzeugen. Ich unterbiete das: 1 einzelner Buffer. Mit dem Signal aus Kamera 1 wird dieser Buffer geschrieben; alte Bilder werden Pixelweise durch neue ersetzt. Mit dem Signal aus Kamera 2 wird der Buffer gelesen und der gelesene Wert mit dem Pixelwert aus Kamera 2 gemittelt. Daraus ergibt sich auch direkt das Synchro-Signal für den Monitor.
>> ich wandele die Signale und addiere, Ja, das war mein Verdacht... :-o >> sollte ich die kameras synchronisieren? Das wäre für deinen FPGA-Algorithmus das einfachste. Aber du wirst die Kameras nicht auf Pixelebene synchron bekommen. Denn das müssten sie sein. Das bisher waren Kinderspielereien, jetzt wirds erst so richtig kompliziert. Denn du musst: 1. das Signal beider Kameras einlesen 2. darin den Sync erkennen 3. nach dem Sync die Daten in zwei Puffern ablegen 4. ein neues Timing erzeugen 5. entsprechend diesem Timing die Puffer wieder auslesen und ausgeben. > Beide Datenströme in zwei getrennte Wechselbuffer schreiben Ich würde sagen, das ist für ein simples Kamerasignal, das wieder auf einem Bildschirm ausgegeben wird, nicht nötig. Wenn da mal ab und ein der Lesezeiger den Schreibzeiger überholt und deshalb ein Halbbild ein wenig versaut ist, dürfte das nicht auffallen. Diese Wechselpuffergeschichte würde ich für eine 2. Stufe aufheben... EDIT: > Ich unterbiete das: 1 einzelner Buffer. Morin hat recht, so habe ich das seinerzeit auch gelöst... ;-) Und der Vorteil ist, dass das Timing nicht neu erzeugt werden muß.
also die Syncs sollte man nach moeglichkeit nicht neu erzeugen sondern die ansteuerung der Kameras entsprechend veraendern dass beide bilder uebereinander liegen. Wir machen den Kram gerade auch hier. Allerdings haben wir getrennte syncs und video signale. Ich hab ein block gebaut der beide syncs miteinander vergleicht und bei Abweichungen ein-re-sync einleitet, um beide videos wieder ueber einander zu schieben. Das funktioniert super. Der vorteil ist, dass in den fusion-algorithmus beide video signale reingehen, aber nur ein sync. Richtig spassig wird das uebrigens, wenn beide Video signale verschiedene aufloesungen und frame rates haben, aber auch dann ist es hinzukriegen. Aber beruhige dich damit, dass wir hier mit mehreren VHDL menschen schon laenger daran sitzen, das ordentlich hinzubekommen. Merke: Die Loesung des Problems ist nur das Ende des eigentlichen Spasses :)
> bei Abweichungen ein-re-sync einleitet
Das geht aber nur, wenn du die Kameras von aussen triggern kannst.
Vielen Dank an alle für die Hinweise und Antworte also ich versuche wie sie gesagt haben und werde mich sobald ich ein Ergebnis habe zurückmelden
Lothar Miller schrieb: >> bei Abweichungen ein-re-sync einleitet > Das geht aber nur, wenn du die Kameras von aussen triggern kannst. Das ist in der Tat wahr! Wir koennen bzw. muessen die Sensoren selber ansteuern, wenn man nur das fertige Kamerabild bekommt muss man leider doch mit Puffern arbeiten
> Richtig spassig wird das uebrigens, wenn beide Video signale > verschiedene aufloesungen und frame rates haben, aber auch dann ist es > hinzukriegen. Aber beruhige dich damit, dass wir hier mit mehreren VHDL > menschen schon laenger daran sitzen, das ordentlich hinzubekommen. Ohne das jetzt schonmal selbst gemacht zu haben: Verschiedene Frame Rates sollten eher harmlos sein, solange die Kameras keine Bilder aufnehmen, die sich halbwegs synchron zum Bildsignal verändern (z.B. Monitor filmen). Da würden sich dann, wie Lothar schon erwähnt hat, ab und an die Lese-/Schreibzeiger überholen, ohne dass man es sieht. Verschiedene Auflösungen sind schwieriger, da könnte man z.B. für jeden Pixel der 2. Kamera mehrere Pixel aus dem Buffer auslesen und entsprechend resamplen. Habe aber wie gesagt noch keine praktische Erfahrung damit ;)
Morin schrieb: > Ohne das jetzt schonmal selbst gemacht zu haben: Verschiedene Frame > Rates sollten eher harmlos sein, solange die Kameras keine Bilder > aufnehmen, die sich halbwegs synchron zum Bildsignal verändern (z.B. > Monitor filmen). Da würden sich dann, wie Lothar schon erwähnt hat, ab > und an die Lese-/Schreibzeiger überholen, ohne dass man es sieht. Naja, ueberleg dir mal folgendes: Ein sensor mit 30 fps, ein sensor mit 25 fps. Versuch mal, beide Signale uebereinander zu fusionieren. Waehrend sensor 1 z.B. in seiner letzten aktiven Bild-linie ist, ist Sensor 2 noch irgendwo im letzten drittel (keine Lust das jetzt genau auszurechnen, geht ums Prinzip :) ). Dass heisst, der aktuelle Pixel beider Signale ist bezueglich seiner Position nicht der selbe. Wenn du beide Videos nur stur uebereinander legst, ist das noch einigermassen hinzubekommen. Wenn dein Fusion Algorithmus aber mehr macht als nur 2 pixel-werte miteinander zu mitteln, du also z.B. edge detection, motion tracking, Bildvergleiche oder du sonst irgendwelche Berechnungen aus der digitalen Fusionierung holen willst, dann sollten die Framerates 100% gleich sein, ansonsten bufferst du dich tot. Und warum sollte man sonst digital fusionieren, wenn man keine Berechnungen machen will? Wenn man nur 2 Videos uebereinander legt, ist optische einkopplung IMMER besser, allein schon wegen der Aufloesung, des Delays, Lichtverhaeltnisse, Kontrast etc. etc. > Verschiedene Auflösungen sind schwieriger, da könnte man z.B. für jeden > Pixel der 2. Kamera mehrere Pixel aus dem Buffer auslesen und > entsprechend resamplen. > Upscaling ist z.B. von QVGA (320x256) nach SXGA (1280x1024) extrem einfach, das ist einfach jeden QVGA pixel in einen 4x4 block darstellen und das mittels filter glaetten. Aber da gibt es so viele Moeglichkeiten wie Pixel und man muss seinen Favoriten nach den Anforderungen des Systems auswaehlen, unter umstaenden auch mehrere koppeln. Aber das ist ja gerad der Vorteil eines FPGAs, man kann so breit rechnen wie man will.
Hallo Leute ich bin gerade dabei die beiden Kamera signale zu synchronisieren. Meine frage ist Meine Auflösung ist 640 x480 Um die erste Kamerabilder anzuzeigen mein VGA_CLK = TD1_CLK = 27 MHz Um die zweite Kamerabilder anzuzeigen mein VGA_CLK = TD2_CLK = 27 MHz jetzt nach der fusion von beiden Kamerabilder welche Clock sollte mein VGA erhalten??? Ich habe mit TD1_Clk oder TD2_CLK probiert aber Bild flackert ständig was meint ihr?
Bill Lates schrieb: > ich bin gerade dabei die beiden Kamera signale zu synchronisieren. Wie machst du das? > welche Clock sollte mein VGA erhalten??? Den, der synchron zu deinem neu berechneten Bild ist. Und im Endeffekt werden das auch 27MHz sein... > Ich habe mit TD1_Clk oder TD2_CLK probiert aber Bild flackert ständig Was hast du mit den Sync-Signalen gemacht? Hast du gelesen, was hier schon geschrieben wurde? Das hier wird nicht funktionieren: >>>> mein fusionalgorithmus ist nur einige Zeile...
>> Ich unterbiete das: 1 einzelner Buffer. >Morin hat recht, so habe ich das seinerzeit auch gelöst... ;-) >Und der Vorteil ist, dass das Timing nicht neu erzeugt werden muß. Nö, geht nicht, wenn die Kameras unterschiedliche Bildraten haben und das haben sie, da sie unsychrioniest laufen. Wie willst Du 25,0 und 25,001 Bilder je Sekunde in den Griff bekommen? Das geht nur durch Verwerfen eines Bildes und dann hast du irgendwann mal einen Sprung. Das reicht zwar zum Angucken, nicht aber zum Verarbeiten des Bildes, wenn man z.B. Geschwindigkeiten erkennen will. >Ein sensor mit 30 fps, ein sensor mit 25 fps. Versuch mal, beide >Signale uebereinander zu fusionieren. Das fällt dann wenigstens sofort auf und sieht so aus wie manche amerikanischen Spielfilme im deutschen TV, wo jedes 6. Bild fehlt. Wenn man es sauber machen will, braucht man eine pixelweise Interpolation = Entjitterung auf Daten- und auch Bildebene. Ergo einen entsprechenden Speicher für einige Bilder. Die Frage ist, ob man das zum Schauen braucht. Morins Lösung sieht einfacher aus, leistet aber nicht dasselbe. Meine Lösung mit buffern auf Signalebene löst zumindest schon mal das Problem, daß das Bild der zweiten Kamera nicht mit dem Jitter der ersten Kamera zusätzlich verdödelt wird. Die Lösungen sind also nicht gleichwertig! > Und warum sollte man sonst digital fusionieren, wenn man keine > Berechnungen machen will? Dess frach isch misch nämlisch aach, wie der Hesse sagt. Daher meine obige Überlegung mit dem Bildpuffer. Ich habe sowas in meinem Audioprojekt schon gemacht, da geht es halt nicht um bildframes, sondern audio frames, die alle FAST gleich lang, FAST gleich schnell und FAST die selbe Tonhöhe haben. Wenn man da konventionell sampelt und Informationen verwirft, gibt es Mus statt Musik.
> Wie willst Du 25,0 und 25,001 Bilder je Sekunde in den Griff bekommen? Eines der Kamerabilder wird in einen Puffer geschrieben. Und von dort mit der jeweils anderen Kamerafrequenz ausgelesen. Bei halbwegs statischen Bildern fällt es kaum auf, wenn der Lesepointer den Schreibpointer jedesmal irgendwo mitten im Bild überholt, und so das halbe alte und das halbe neue Bild der zweiten Kamera dargestellt wird. > Das geht nur durch Verwerfen eines Bildes und dann hast du > irgendwann mal einen Sprung. Der Sprung ist quasi einkalkuliert und passiert garantiert mitten in jedem Bild. Denn der Puffer hält also kein statisches Bild, sondern ein dynamisches, das während des Auslesens überschrieben wird. > Die Lösungen sind also nicht gleichwertig! Nein, aber (zumindest für den Anfang) ist die Ein-Puffer Lösung vergleichsweise simpel zu realisieren. > Ich habe sowas in meinem Audioprojekt schon gemacht, da geht es halt > nicht um bildframes, sondern audio frames, die alle FAST gleich lang, > FAST gleich schnell und FAST die selbe Tonhöhe haben. Das Auge ist (verglichen mit dem Ohr) wesentlich fehlertoleranter... ;-)
Das Auge ja, aber trotzdem hat man ein verwurstetes Bild. Wenn es um Bildauswertung geht, ist da alles zu Ende. >Schreibpointer jedesmal irgendwo mitten im Bild überholt, und so das >halbe alte und das halbe neue Bild Das ist noch schlimmer, als ein Bildsprung, denn ein fehlendes Bild kann noch ersetzt werden, indem man die Bildraten misst und die in den Bildern erkannten Objektgeschwindigkeiten korrigiert. So bleibt einem dies Aufgabe auch noch - man hat nur noch ein weiteres kaputtes Bild. Wie gesagt: Diese simplen lösungen reichen nur zum Angucken
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.