www.mikrocontroller.net

Forum: Digitale Signalverarbeitung / DSP 3D Video Warping


Autor: Sergey (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

kann mir jemand mit Erfahrung abschätzen, ob so etwas realistisch ist:
Mit einem FPGA/CPLD ein analoges Videobild in einen RAM einlesen,.
Einer oder mehrere dsPICs rechnen dann an dem Videobild herum und
der CPLD gibt den 2. Buffer wieder aus.

Was die Rechenoperationen angeht:
Ich plane anfangs z.b. um ein Bild zu rotieren mir die rotierten
Koordinaten auszurechnen und dann die Linien mittels Bresenham
zu ziehen. Bei Skalierung plane ich linear zu interpolieren.

Oder ich rotiere mittels 2-facher Verzerrung (Shear) und Skalierung.

Später - sollte das klappen - kann ich die dsPICs mit einer schnelleren
CPU ersetzen, die dann auch 3D und Warps berechnen kann.

Es soll in etwa so etwas werden, wobei ich mit "The first/second
generation digital video effects" einmal anfangen will, ohne Warps ;)

Youtube-Video "Microtime Impact Variable Image Transformer Digital Video Effects"

Glaubt ihr geht zumindest Skalierung mit einem dsPIC (40 MIPS)?
All das muss in Echtzeit geschehen, also der dsPIC muss vor
20 ms mit einem Halbbild fertig sein.

Autor: Sergey (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: B. G. (smarti)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hoi,

gehen tut das ;)

Schau dir das mal an: 
http://thomaspfeifer.net/fpga_dsp_bildverarbeitung.htm

Zur eigentlichen Umsetzung steht wenig...

LG

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mit einem CPLD kannst Du es vergessen -- ein FPGA muss her. Ich nehme 
an, Du möchtest nur PAL rotieren, oder? Denn bei HD sind Anforderungen 
sehr viel höher.
Wenn man es vernünftig machen möchte, dann sollten die Pixel auch noch 
interpoliert werden. Bei der Auflösung 720x288 (Halbbild) und bilinearen 
Interpolation hast Du ca. 830000 Speicherzugriffe (Random). Bei 50 
Frames und einem SRAM müsstest Du also bei ca 40 MHz mit jedem Takt ein 
Pixel lesen. Dazu kommt noch Overhead mit Double-Buffer und Co.

Wenn Du 2-Pass Rotation machen möchtest, wird es nicht unbedingt besser, 
habe jetzt nicht die genauen Zahlen im Kopf (kannst allerding 
Triliniear-Interpolation nehmen, weil Du die Pixel in Bursts lesen 
kannst)

Ich denke ein dsPIC mit 40 MIPS wird da nicht ausreichen (kenne die 
Architektur aber nicht). Es sei dem, Du verzichtest auf Interpolation -- 
das Bild sieht dann nicht so toll aus.

Ich selber habe mich damit beschäftigt, allerdings in HD und mit einem 
FPGA. Man kann unendlich Zeit darin versenken ;-)

Grüße,
Kest

Autor: Sergey (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Ja, ich möchte nur PAL aus einer analogen Quelle rotieren (dachte da an 
einen BT625 Video-ADC/DAC) Danke für die Antworten, und entschuldigt, 
dass ich noch ein Newbie auf DSP-Gebiet bin. Bezog sich das "ein FPGA 
muss her" auf die Speicherzugriffe? Denn ich will im FPGA/CPLD ja 
vorerst keine Mathematik machen, sondern quasi nur die 
Speicher-Ansteuerung.

Ich dachte da z.b. bei Rotation an mehrere dsPICs, wobei jeder nur 
einige Zeilen des Bildes berechnet. Zuerst die Koordinaten mittels der 
bekannten Rotation-Matrix bestimmen, dann eine bzw. mehrere Bildzeilen 
linear interpolieren, wobei auch eine "billige" Interpolation zwischen 
z.b. 2-4 Punkten ausreicht oder wenn es sein muss garkeine Interpolation 
(Pixel auslassen) und dann diese Linie auf den entspr. Koordinaten 
"bresenhamen".

Oder bezog sich deine Antwort darauf, dass der FPGA selbst die Rotation 
erledigt?

Jedenfalls habe ich ein unglaubliches Farb-Rotozoomer-Demo auf einem 
ATMEGA644 gesehen, da dachte ich, dass ein dsPIC das dann "locker" 
schaffen müsste, bzw. mehrere dsPICs parallel bei Texturen in 
PAL-Grösse.

Ansonsten sollten mehrere PIC32 mit 80 MIPS das erschlagen können... 
(denn die sind teilweise angeblich schneller als Cortex-M3s)

Entschuldigt diese Newbie-Fragen, aber bisher arbeitete ich mit max. 10 
MIPS MCUs und habe nur "billige" Video-Sachen gebaut (S/W Genlock 
Logo-Inserter, etc...) ohne viele Mathematik ;)

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey, Du musst Dich für nichts entschuldigen! :-)

Ja, ich dachte an ein FPGA, welches komplett die Bilder rotiert.

Mit mehreren dsPICs könnte es nur theoretisch gehen, praktisch musst Du 
trotzdem erstmal das Bild aufteilen und dann zu jedem dsPIC schicken. 
Diese müssen dann das berechnete wieder irgendwohin schreiben (und das 
gleichzeitig). So oder so bekommst Du Speicherbreiten-Problem. Du 
brauchst also ein SRAM wo mindestens 2 Bilder reinpassen -- ins eine 
Buffer wird geschrieben, aus dem anderen gelesen. Gelesen wird dabei 
random, d.h. dass es keine Bursts sein können, weil das Bild ja rotiert 
ist und Du für jedes Ausgangspixel ein (oder besser 4 für Interpolation) 
Eingangspixel lesen musst.

So oder so, Dein DSP muss schon etwas unter der Haube haben, um 
Live-Bilder zu rotieren. Bei statischen Bildern sieht es wiederum etwas 
anders aus, weil Du ja frei bist, wie Du das Bild im Speicher ablegst 
(dann kannst Du vielleicht mehrere Pixel auf Ein Mal aus dem Speicher 
lesen).

Ich habe mal mit einem FPGA HD Bilder rotiert. Ohne 4 Bänke SRAM ging 
das überhaupt nicht). Das FPGA hat bei 100 MHz hat fast mit jedem Takt 
ein Pixel berechnet. Aber wie ich schon sagte, bei "nur" PAL sieht die 
Sache anders aus.

Kest

p.s.: das Ganze fängt eigentlich schon damit an, dass Du nicht für jedes 
Pixel die Rotations-Matrix bestimmen kannst (so viel Zeit für sin und 
cos hast Du einfach nicht). Da musst Du Zwischenschritte vorberechnen.

Autor: Sergey (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Infos...  Noch 2 Fragen, wie muss der FPGA ca. 
dimensioniert sein (LUTs, Gates, ...) und hast du fertige 
Implementationen von Opencores verwendet oder alles selbst gemacht 
(CORDIC, etc...)?

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe alles selber gemacht.
Ich glaube, das war ein Altera 2C70, aber davon nur 10-15%. Am meisten 
hat die Interpolation gefressen und Farbraumkonvertierung (RGB-YPrPb).
Die Abschätzung der LUTs ist extrem schwierig, weil man nicht weiß, was 
noch so am FPGA hängt, in welcher Form die Videodaten reinkommen und so 
weiter. Das Ganze steht und fällt mit dem Speicher(durchsatz), alles 
andere ist (aus meiner heutigen Sicht) trivial ;-)

Grüße,
Kest

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]
  • [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.