mikrocontroller.net

Forum: FPGA, VHDL & Co. Bildfusion an monitor


Autor: Bill Lates (Firma: Mann) (billates)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Floh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Deine Mittelwertberechnung in Zeile 42.
:-)

Autor: Hellseher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wo kann das Problem sein?
Wahrscheinlich hast du einen Fehler gemacht

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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?

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was macht dein Fusion-Algorithmus? Deine Fehleranalyse ist extrem 
schwach und erlaubt nicht mal annaeherungsweise irgendwelche 
Vorschlaege.

Code posten!

Autor: Bill Lates (Firma: Mann) (billates)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Morin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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ß.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> bei Abweichungen ein-re-sync einleitet
Das geht aber nur, wenn du die Kameras von aussen triggern kannst.

Autor: Bill Lates (Firma: Mann) (billates)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Morin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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 ;)

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bill Lates (Firma: Mann) (billates)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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... ;-)

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.