Guten Tag beisammen! Mein Ziel ist es mit VHDL eine BMP-datei einzulesen, und dann dasselbe Bild mit einigen Farbveränderungen und Formveränderungen auszugeben. Um genau zu sein soll Blau in Rot umgewandelt werden und alle (vollständigen) Rechtecke sollen mit Kreuzen versehen werden. Als kompletter Neuling in dem Gebiet war ich erst komplett überfordert, doch nachdem ich mich nun mit dem BMP format auseinander gesetzt habe, fand ich das Farbproblem relativ einfach lösbar. zmd in der Theorie. Dabei hat mir vorallem diese Seite ungemein geholfen https://vhdlwhiz.com/read-bmp-file/ Jedoch bin ich mit der Rechteck-erkennung ansatzlos überfragt. Deswegen hoff ich hier vllt auf Tipps wie ich so ein Programm schreiben könnte, bzw Links zu einer hilfreichen Quelle. ps. Dafür habe ich ein vorgegebenes Bild, das heißt die Werte wie Größe usw. sind mir bekannt, aber das Programm muss natürlich auch bei kleinen Veränderungen des Bildes (mehr Rechtecke oder blaue Bereiche) funktionieren.
Da fehlen einige wenige Zwischenschritte. Wenn du dein Problem vllt in einem Blockschaltbild darstellen könntest? Als alter Sack bin ich mit so großen Gedankensprüngen maßlos überfordert.
Gibt es ein Beispielbild? Welche Eigenschaften haben die Rechtecke? Wieviele Rechtecke gibt es? Wie sind diese im Bild verteilt? Wie ist der Rest des Bildes strukturiert? Soll das nachher synthetisierbar sein oder im Simulator laufen? Wie kommt das Bild rein? Wie soll es raus? Genug Speicher für Puffern vorhanden oder muss gestreamt werden?
:
Bearbeitet durch User
Wozu wird das in VHDL gemacht? Sicher, um es mal in Echtzeit laufen lassen zu können, nehme ich an. Mit "Read-BMP" wird man da aber nicht weit kommen. Wahrscheinlich wird wieder ein FPGA vergewaltigt indem man ihm einen SoftCore mit OS verpasst und dann ein Dateisystem reinbrutzelt, damit man von SD-Karte Bilder verunstalten kann. Sicher eine Semesteraufgabe eines Fachgruppenbetreuers an einem Bätschel-Institut. Es gibt keine seriöse Anwendung, wo "Blau in Rot umgewandelt werden" muss. Das könnte man auch durch tauschen der Pins am VGA-Stecker erreichen.
Hallo, ich würde mir (zumindest vorerst) BMP in VHDL sparen und mittles ffmpeg o.ä. die Bilder in RAW Format RGB888 oder ähnliches konvertieren. Dann ist das Einlesen der Datei deutlich angenehmer. Ausgegen dann auch wieder als RGB RAW und zurückkonvertieren. Speicherplatz sollte für die 2 Bilder ja auf dem Rechner reichen... Damit nimmst du schonmal den BMP Codec aus der Kette. BMP ist zwar einfach, aber auch nur unnötiger Aufwand. Für die Rechteckerkennung gibt es dann verschiedene Ansätze. Man könnte das Bild erstmal in Grauwerte konvertieren und dann über einen Sobelfilter 2 dimensional eine Kantendetektion machen. Je nachdem wie gut die Rechtecke definiert sind, kann man dann die Rechtecke bspw. über Korellation suchen. Sollten in dem Bild noch Verzerrungen sein, bspw, durch 3D Verkippung, wird das Ganze etwas schwieriger. Bei solchen Algos habe ich aber jetzt auch nicht wirklich viel Ahnung. Da können dir bestimmt andere weiterhelfen. Das Vertauschen der Farben hat aber ansich nichts mit BMP zu tun, oder? Das BMP format ist ja nur das Testvehikel um Bilder in und aus der Simulation zu bekommen. Hoffe ich zumindest für dich... In den Pixeldaten dann R mit B zu tauschen sollte man dann auch nach dem 4. Bier noch hinbekommen
M. H. schrieb: > Für die Rechteckerkennung gibt es dann verschiedene Ansätze. Man könnte > das Bild erstmal in Grauwerte konvertieren und dann über einen > Sobelfilter 2 dimensional eine Kantendetektion machen. da siehst du Kanten, wo keine sind. Das muss im kompletten Farbraum passieren
Proggi schrieb: > M. H. schrieb: >> Für die Rechteckerkennung gibt es dann verschiedene Ansätze. Man könnte >> das Bild erstmal in Grauwerte konvertieren und dann über einen >> Sobelfilter 2 dimensional eine Kantendetektion machen. > > da siehst du Kanten, wo keine sind. Das muss im kompletten Farbraum > passieren Da hast du wohl recht. Wie gesagt, ich kenne mich zwar in einigen Gebieten sehr gut aus. Aber Bildverarbeitung gehört definitiv nicht dazu. Ich war schon froh, als ich für mein Ambi-light halbwegs die Farben aus HDMI-Datenstrom fischen konnte. Dem TO würde ich allerdings empfehlen, die Alogrithmik erstmal am PC zu entwickeln. Das ist deutlich schmerzfreier, als direkt mit einer gepipelinten performanten Logik anzufangen. in SW gibt es auch einige schöne frameworks, die einem da erstmal die Arbeit abnehmen. OpenCV wäre da das Stichwort. Wenn das ganze in SW tut, kann man dann die Algorithmik in Logik gießen.
M. H. schrieb: > Dem TO würde ich allerdings empfehlen, die Alogrithmik erstmal am PC zu > entwickeln. Das ist deutlich schmerzfreier, als direkt mit einer > gepipelinten performanten Logik anzufangen. Allerdings gibt es einige Sachen, die man am PC nicht machen kann, schon wegen der Performance. Lohnend ist ein Simulator, der HW-unterstützt arbeiten kann. Oder man macht es komplett in Software z.B. MATLAB und lässt sich von compiliertem C++ auf Grafikkarten unterstützen.
Videomann schrieb: > Allerdings gibt es einige Sachen, die man am PC nicht machen kann, schon > wegen der Performance. Quatsch. Man sollte sich erst mal Photoshop ansehen. Eine Farbe in eine Ebene nehmen und dort die Farbe ändern ist nun nicht das Problem. Es gibt da massig Plug-In. Aber Rechtecke mit Kreuzchen versehen, es gibt da Grenzen.
michael_ schrieb: > an sollte sich erst mal Photoshop ansehen. Eigentlich keine schlechte Idee. Aber: > Eine Farbe in eine Ebene nehmen und dort die Farbe ändern ist nun nicht > das Problem. Die Farben sind dort nur indirekt authentisch, wenn man den Monitor kalibriert, um sie optisch zu verifizieren und das eingehende Bild zu beurteilen. Tut man das nicht, kann man es auch anonym über die Farbwerte machen. > Es gibt da massig Plug-In. Es gibt sogar die Möglichkeit, eine eigene Matrix zu nutzen, um seine Bildverarbeitung zu testen. Allerdings gibt es dort ein Auflösungsproblem mit den einstellbaren Werten (nur ganzzahlig) und die Größe ist ebenfalls begrenzt. Damit kann man hoch aufgelöste Bilder nicht mehr bearbeiten, weil eine Kante mehrere Pixel überstreicht. Videomann schrieb: > Oder man macht es komplett in Software z.B. MATLAB und > lässt sich von compiliertem C++ auf Grafikkarten unterstützen. Alles eine Frage des Aufwands. Es kann auch sinnvoll sein, den Softwareansatz zu überspringen und gleich ins FPGA zu gehen. Der Aufwand, einen Filter zu instanziieren ist ja nun so groß nicht. Mehr Arbeit macht es, ihn zu parametrieren und zu steuern - also Zusammenhänge von eingehendem Bild zum zu produzierenden Bild zu finden. Hat man das beieinander, kann man durch Überdrehen und Dynamikkompression richtig schöne Kunstbilder schaffen: http://engineer.bplaced.net/img_1_colsens_a/fpga_color_processor_3.jpg
Bitte 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.