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 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"
