Hallo, ich wuerde gerne ein jpg Bild mit einem Spartan 3 FPGA (Xilinx) dekodieren. Dabei kann angenommen werden, dass das jpg Bild bereits im RAM vom FPGA vorliegt. Die dekodierten Pixel Informationen werden wieder ins RAM zurueckgeschrieben. Ich bin dankbar um jeden Loesungsansatz fuer das Problem. Dabei soll die einfache Implementierung im Vordergrund stehen. Notwendige Bibliotheken sollten wenn moeglich bereits vorhanden sein. Meine bisherigen Ideen: 1) jpg IP core. Problem: Bisher habe ich keinen frei verfuegbaren und bereits fertig abgeschlossenen (d.h. kein beta code) Core gefunden. 2) Microblaze mit normaler jpg bibliothek Probleme: + Gibt es bereits angepasste jpg bibliotheken? + Ist das mit dem Microblaze ueberhaupt sinnvoll? Besten Dank fuer alle Anregungen!! Nik
Ob der Ansatz mit einem Softcore sinnvoll ist, hängt davon ab, wie oft bzw. schnell Du dein Bild dekodieren willst. Der Vorteil ist, das die Algorithmen im Netz verfügbar sind (in C) und schnell und direkt umgesetzt werden können. Als IP Core kostet es halt Geld oder Zeit und passt möglicherweise nicht direkt an Deinen Speicher. Duke
Du kannst auch einen Mittelweg nehmen. Ein Softcore steuert die Dekomprimierung, aber oft nötige+aufwendige Rechenschritte sind als spezieller Maschinencode verfügbar, und als "Zusatzhardware" im FPGA.
Ich habe auch als erstes an einen "Mittelweg" gedacht. Erstmal alles in Software, und dann solange die Geschwindigkeit nicht ausreicht, Teile in die Hardware verlagern (Huffman-Decoder, Floating Point Rechnerei, ...). Aber immer schön so, dass der Datenflußteil in Hardware, der Kontrollflußteil in Software erledigt wird, damit holst du am meisten Geschwindigkeit pro FPGA-Fläche raus.
Die Dekodierung muss nicht sehr schnell erfolgen. Das ganze ist fuer einen "digitalen Bilderrahmen" gedacht. So <2sec waere gut. Daher erscheint mir der Ansatz mit dem Softcore ganz vernuenftig. Ich hab nur kein Gefuehl dafuer, wieviel Aufwand notwendig ist um eine bestehende jpg bibliothek fuer einen softcore anzupassen (z.B. microblaze)?! Wer hat so etwas schon einmal gemacht? Gruesse und Danke fuer die Tipps! Nik
@ Nik (Gast) >Die Dekodierung muss nicht sehr schnell erfolgen. Das ganze ist fuer >einen "digitalen Bilderrahmen" gedacht. So <2sec waere gut. Na dann nimm doch einfach BMP. Duckundwech Falk
Falls du ein 10MPixel JPG Bild direkt von einer SD Karte dekodieren willst, dann wirst du <2s nicht mit einem Softcore schaffen (außer du optimierst die Routinen so, dass der Dekoder nicht die volle Auflösung dekodiert. Keine Ahnung ob sowas überhaupt geht, aber irgendwie kann man da bestimmt was machen). Selbst ein PC mit >2GHz braucht dazu braucht dazu fast 1s. Und als ganz grober Vergleich: Ein 640x480 jpg von SD Karte dekodieren braucht auf einem mit 40MHz getakteten dsPIC (16bit RISC) mit Festkommaroutinen etwa 5-10s je nach Kompression.
@ Benedikt K. (benedikt) >Falls du ein 10MPixel JPG Bild direkt von einer SD Karte dekodieren >willst, Ob das auf einem digitalen Bilderrahmen sinnvoll ist? Die haben doch eher so SVGA Auflösung, oder? Da reicht, man glaubt es kaum, weniger als 1 MPixel. Und um nochmal auf BMP zurück zu kommen. Das meinte ich schon ein wenig ernst. Einfach BMP und dann per ZIP komprimieren. Oder PNG direkt nehmen. MFG Falk
Falk Brunner wrote: >>Falls du ein 10MPixel JPG Bild direkt von einer SD Karte dekodieren >>willst, > > Ob das auf einem digitalen Bilderrahmen sinnvoll ist? Naja, das macht jeder digitale Bilderrahmen. Die Auflösung wird dann entsprechend runtergerechnet. Der Sinn davon ist, dass man die SD Karte von der Digicam direkt einstecken kann, ohne alle Bilder voher in ein passendes Format konvertieren zu müssen. Ich hatte selbst mal versucht sowas zu bauen (mit einem dsPIC als JPEG Dekoder, einem S1D13504 LCD Controller und einem 800x600 Notebook TFT. Es lief prinzipiell, nur das Laden eines Bildes direkt von der Digicam dauerte bis zu 15 Minuten je nach Auflösung und Kompression...
Hallo, bmp vs. jpg: Dem Argument von Benedikt K. stimme ich voll zu. Es waere schoen, wenn ich jpg Bilder (von der Digi Cam, von Freunden, etc.) auf die Karte kopieren und von dort direkt abspielen koennte. Das Downsampling auf z.B. 640x480 wird dann beim laden des Bildes erledigt. >Und um nochmal auf BMP zurück zu kommen. Das meinte ich schon ein wenig >ernst. Falls das mit dem jpg dekomprimieren nicht klappt, werde ich auf alle faelle die bmp loesung nehmen. ist halt etwas weniger komfortabel.
@Benedikt K. >Ich hatte selbst mal versucht sowas zu bauen (mit einem dsPIC als JPEG >Dekoder, einem S1D13504 LCD Controller und einem 800x600 Notebook TFT. >Es lief prinzipiell, nur das Laden eines Bildes direkt von der Digicam >dauerte bis zu 15 Minuten je nach Auflösung und Kompression... Welche jpg library hast du denn verwendet? Was muss man dabei anpassen? Ich denke zumindest die Funktionen fuer das Laden der Daten (z.B. von der SD Karte), mussten an deine HW angepasst werden, richtig?
Ich hab die Lib von Microchip: http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2680&dDocName=en536519 Die kann man recht einfach anpassen: Microchip verwendet ein virtuelles Dateisystem im Flash auf das mit ein paar Befehlen zugegriffen wird. Die muss man durch die entsprechenden eigenen Funktionen ersetzen.
> Ich hatte selbst mal versucht sowas zu bauen (mit einem dsPIC als JPEG > Dekoder, einem S1D13504 LCD Controller und einem 800x600 Notebook TFT. > Es lief prinzipiell, nur das Laden eines Bildes direkt von der Digicam > dauerte bis zu 15 Minuten je nach Auflösung und Kompression... Zum dsPIC kann ich jetzt nichts sagen, aber für einen FPGA kommt mir die Zeit auf jeden Fall zu lange vor. Ein moderner PC braucht nicht mehr als 100 ms zum dekodieren eines JPEG (wahrscheinlich noch sehr viel weniger, aber rechnen wir mal vorsichtig). Ein FPGA ist mit ca. 1/50 der modernen CPU getaktet, aber der Datenpfad ist nicht auf JPEGs optimiert, d.h. abgesehen vom Takt bekommt man mit einem FPGA mindestens denselben Durchsatz. Das wären dann gaaaanz(!) vorsichtig gerechnet immer noch weniger als 5 Sekunden. Mit einem optimierten Datenpfad vermute ich eher auch um die 100ms.
> Ein FPGA ist mit ca. 1/50 der modernen CPU getaktet, aber der Datenpfad ist nicht auf JPEGs > optimiert Nachtrag: Das sollte natürlich heißen "der Datenpfad der CPU ist nicht auf JPEGs optimiert"
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.