Forum: FPGA, VHDL & Co. Rechtecke in BMP-Datei in VHDL erkennen und bearbeiten


von Rayvin (Gast)


Lesenswert?

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.

von Bürovorsteher (Gast)


Lesenswert?

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.

von Samuel C. (neoexacun)


Lesenswert?

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
von Tim (Gast)


Lesenswert?

Schreibe zuerst deinen Algorithmus in C. Danach würde ich über VHDL 
nachdenken.

von Proggi (Gast)


Lesenswert?

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.

von M. Н. (Gast)


Lesenswert?

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

von Proggi (Gast)


Lesenswert?

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

von M. Н. (Gast)


Lesenswert?

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.

von Videomann (Gast)


Lesenswert?

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.

von michael_ (Gast)


Lesenswert?

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.

von J. S. (engineer) Benutzerseite


Lesenswert?

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
Noch kein Account? Hier anmelden.