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 ;)
http://www.youtube.com/watch?v=-Xu1swlwbgI&feature=related
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.
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
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 ;)
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.
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...)?
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
