Hi, in der Codesammlung habe ich eine Testbench für BMP-Dateien hochgeladen. Schaut da mal rein! Beitrag "VHDL-BMP Read/Write" Habe selber oft für verschiedene Sachen verwendet (auch wenn alles nicht ausgereift ist, reicht aber meistens). Die Idee am Anfang war, verschiedene Image- und Videoformate lesen und beschreiben zu können. Vielleicht mache ich das noch (wenn ich nur Zeit hätte ;-)) Grüße, Kest
"Ohne dich persönlich anzugreifen: Wozu sollte der "Scheiß" gut sein?" Weißt du überhaupt was VHDL ist? Ich denke nicht... "was mich mehr interessieren wuerde, wieso hast du das gerade in VHDL geschrieben?" Wie sollte man es sonst in ModelSim laufen lassen!?
Arrggh. Hier treiben sich ja schon manchmal Vögel herum, das glaubt man garnicht. Schon mal was von Verifikation oder Testbench gehört? Einige Monate früher hätte ich das richtig gut brauchen können, so kommt es erstmal ins Archiv. Ich habe mir damals mit text I/O und Matlab geholfen.
@noname (Gast): der "Scheiß" ist manchmal nützlich, wenn man verschiedene Codecs mit ModelSIM simuliert, DVI in, DVI out, VGA, Video-Filter und so weiter und so fort... Man kann natürlich Vollversion von ModelSIM kaufen oder Codeveloper, sodaß man Cosimulation mit C/C++ oder anderen Sachen macht. Wie sagt man so schön: ein Bild sagt mehr als viele Wave-Ansichten in ModelSIM ;-) @Michael Niegl (bigmike47): Die Frage verstehe ich nicht ganz. Das ganze sollte mit ModelSIM funktionieren, weil ich viele FPGA-Designs mache. @all: mal angenommen, ich habe einen JPEG-Codec in VHDL geschrieben, wie simuliert man sowas? Klar, einzelne Entitys ist auch so möglich, aber wenn man das ganze Bild man anschauen möchte, dafür sollte meine Testbench da sein. Grüße, Kest
@ Kest Super danke!! das ist für mich ein etwas verspätetes Weihnachtsgeschenk ;) Endlich kann ich mal den Fehler in meiner Hough-Transformation effektiv suchen..
ich dachte du willst das rein fuer normale bildbearbeitungsoperationen am pc haben, u dann haette mich das schon sehr gewundert, warum man sowas ausgerechnet per vhdl u modelsim macht u wenn ich mich recht entsinne, steht im op nirgends, dass es unbedingt in modelsim laufen muss
@Michael Niegl (bigmike47): Sorry, dass ich mich missverständlich ausgedrückt habe. Ich dachte aus dem Betreff geht es hervor (und aus dem FPGA, VHDL & Co.-Forum, dass ich hier gepostet habe) Grüße, Kest
Danke! bei meinen Tests mit meinem PAL-Encoder hatte ich damals immer extra Bilder nach .RAW konvertiert. Das war aber auch ziemlich lästig und mittlerweile weiß ich das nicht mal mehr, mit welchem Programm ich das gemacht hab ... Das nächste mal werd ich dann deinen VHDL-Code verwenden :-) Mfg Thomas Pototschnig
Hallo Kest, das BMP-Package ist sehr gut, konnte es schon für meine Simulationen verwenden. Einziger Haken daran: Sobald ich Auflösungen verwende, deren Horizontale Pixelanzahl nicht durch 8 teilbar ist (z.B. 1366 x 768), erhalte ich falsche Daten. Dies hängt wahrscheinlich mit der Art und Weise zusammen, wie Du das Memory-Array ausliest. Gibt es eine "schnelle" Modifikation, um solche Auflösungen ebenfalls zu behandeln ? Gruß
Bist Du Dir sicher, dass das mit der Auflösung zu tun hat? Hast Du die Konstanten cMAX_X, xMAX_Y geändert (die sind maximal 1300), setze sie mal hoch. Grüße, Kest
Hallo, ja habe die Konstanten beide auf 2000 gesetzt. Bin mir eigentlich sicher. Habe eine kleine Auflösung testweise ausprobiert: 1366 x 14 (Fehler) Eine zweite Auflösung (1368 x 14) führt zu keinem Fehler. (1368 lässt sich durch 8 teilen). Gruß
(cBytesPerPixel=3) Ich mache folgendes: Initial rufe ich die Prozedur "ReadFile" auf, so dass das Array mit den Bilddaten des bmp-Files gefüllt ist. Danach lese ich pro Takt ein Pixel aus (mit Prozedur "GetPixel", ich habe in der Prozedur die Bytes vertauscht), und speichere die ausgelesenen 3 Bytes in ein ppm-File. Parallel dazu lese ich die gleiche Datei als ppm ein (hierzu habe ich einen eigenen Prozess geschrieben) und vergleiche mit jedem Takt die "ppm-Daten" mit den "bmp-Daten". Bei 1368 x 14 sind die Daten identisch, bei 1366 x 14 unterscheiden sich diese. Das so abgespeicherte ppm-Bild sieht bei 1366x14 entsprechend verzerrt aus. Gruß
Bist Du sicher, dass ppm richtig implementiert ist? Eigentlich ist BMP straight forward, also keine Magie. Deshalb kann ich mir nicht vorstellen, dass in der testbench was passiert. Probier mal nur mit BMP Dateien (Ein Bild auslesen, das andere neu schreiben). Dies sollte mit jeder Breite funktionieren. Ansonsten schick Deinen COde, vielleicht ist da der Wurm drin. Grüße, Kest
Hallo Kest, ich habe noch folgendes ausprobiert: Simuliert man das Beispiel-Testbench-File "sim_tb_bmpread" für "lena.bmp" mit 1368x768, so ist "lena_copy.bmp" ok. Wenn man hingegen "lena.bmp" auf 1366x768 verkleinert, so lässt sich "lena_copy.bmp" nicht öffnen. Auch wenn ich für meine eigene Simulation die Prozedur "WriteFile" nicht verwende, so könnte deine Beispiel-Simulation einen Hinweis auf mein Problem liefern. Grüße, Fpga4u
Auffällig ist, dass "lena_copy.bmp" für 1366x768 2KB kleiner ist als das Original.
Hallo, habe gerade mit Lena_1368x768 und 1366x768 ausprobiert, in beiden Fällen funktioniert bei mir alles so, wie gehabt. Die Bilder sind identisch (mit Originalen) Die Sache ist, dass sich die Bilder in ihren Formaten gar nicht unterscheiden dürfen/sollen! Der Header der BMP-Datei wird einfach in die neue Datei übertragen und gut ist. Ich fürchte, Du musst bei Dir noch weiter graben, woran das liegt. Mit ModelSIM 6.0 XE läuft bei mir alles problemlos (nach dem ich die maximale Auflösung auf 1500 gesetzt habe). Auf jeden Fall, melde Dich bitte, wenn Du die Lösung oder auch die Quelle des Problems gefunden hast. Grüße, Kest
Hallo, habe meine Simulation mit folgendem Simulatoren durchgeführt: Modelsim Lattice OEM Version 6.2g ModelsimDesigner PLUS 6.3a Diese sind auf einem ziemlich aktuellen Stand. Wie ich auf der Xilinx-Seite sehen konnte, ist der Xilinx-Simulator mittlerweile bei Version 6.3 Vielleicht kannst Du den mal installieren und schauen, ob du das fehlerhafte Verhalten nachvollziehen kannst. Grüße, Fpga4u
Nee, sorry, was neues installieren kommt zunächst nicht in Frage, da ich mit der Version viele Projekte mache und mir nicht unbedingt alles zerschiesen möchte. Ich glaube auch nicht, dass das an der Version liegt. Eher ein "Gedanken" Problem bzw allte Bibliotheken im Verzeichnis oder so. Lösche alles, erstell das Projekt neu und siehe weiter. Ich ändere die Größe von BMPs mit Irfanview, vielleicht kommt da was dazwischen? Kest
Habe gerade das Original "lena.bmp" mit IrfanView 3.98 auf 1366x768 geändert und neu simuliert, gleiches Ergebnis. Gruß, Fpga4u
Ich bin neugierig geworden und habe es gerade auch mal versucht. Ich habe Modelsim LE 6.2i verwendet um Dein Beispiel sim_tb_bmpread.vhd zu simulieren und habe das Gleiche wie fpga4u feststellen können. Die Datei ist 2kB kleiner und lässt sich nicht mehr mit der Windows-Bildvorschau öffnen. Mit Gimp, Irfanview und paint lässt es sich öffnen und man kann erkennen das oben rechts ein Teil der ersten Zeile schwarz ist.
Ich kann da nur vermuten: ich verwende durchgehend use ieee.std_logic_1164.all; use ieee.std_logic_arith.all; use IEEE.std_logic_unsigned.all; dies ist nicht unbedigt ratsam. Vielleicht sind die Bibliotheken anders oder es gibt einen Konflikt. Vielleicht liefert dann auch conv_std_logic_vector was anderes zurück. Oder, oder, oder... Leider habe ich jetzt keine Zeit da weiter zu graben, aber solltet ihr den Fehler finden, wäre es schön, wenn ihr es auch publik mach! Grüße, Kest
Interessante Parallelen: http://groups.google.com/group/comp.lang.vhdl/browse_thread/thread/cad904d2f759962f/1a1e03335cbf514a?lnk=gst&q=reading+bit_vector_file#1a1e03335cbf514a
Da habe ich wahrscheinlich rauskopiert ;-) Wieso sollte man das Rad neu erfinden? :-) Grüße, Kest
Kein Problem, ist ja legitim. Habe ein paare weitere Auflösungen ausprobiert. Für JEGLICHE Auflösungen, deren Zeilen-Pixelanzahl nicht durch 8 teilbar ist, wird "lena_copy.bmp" falsch. Zoomt man in die obere rechte Ecke des Bildes, so sieht man einen schwaren Streifen. Wenn man in IrfanView einen Hintergrund einstellt, der nicht schwarz ist, dann sieht man diesen Streifen auf Anhieb. Gruß, Fpga4u
Ich tippe mal auf das Adressierungsschema des Memory-Arrays (Prozedur "GetPixel")
Eine wirklich sehr nützliche sache, die mir sehr geholfen hat. Einen kleinen Bug hab ich jedoch noch entdeckt: getpixel (x,y,colordata); setpixel (x,y,colordata); kopiert nicht exakt einen Pixel, da x und y variablen sind, colordata aber ein signal, somit wird der aktuelle Pixel mit der farbe des letzten durchlaufs beschrieben. Deshalb ist in dem Beispiel das Bild um ein Pixel nach rechts verschoben. Umgehen kann man das, indem man x und y in ein signal wandelt. signal x2,y2 : integer; . . . getpixel (x,y,colordata); x2 <= x ; y2 <= y; setpixel (x2,y2,colordata);
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.