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.
Oder z.b. ob so etwas realistisch ist (nur Video skalieren): http://www.youtube.com/watch?v=xhKsigNKxQ0
Hoi, gehen tut das ;) Schau dir das mal an: http://thomaspfeifer.net/fpga_dsp_bildverarbeitung.htm Zur eigentlichen Umsetzung steht wenig... LG
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
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.