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