BMP-Bild in VHDL lesen

Yann B. schrieb:
> aber
> mein Algorithmus funktioniert nicht richtig.

Ich kann da in deinem VHDL keinen Algorithmus erkennen. Es wird auch 
keine Datei gelesen.

Hänge doch mal die .BMP und die vollständige .VHD an.

moin,

ich könnte mich irren, aber soweit ich weiß werden die rohen Bild-Daten 
auf dem Kopf gespeichert. Also sie unterste Reihe steht dann oben und 
umgekehrt. das erste Byte 0x00 ist der Index für den Pixel gefolgt von 4 
Byte Bilddaten (Alpha-Transparent,R,G,B).

grüüßee (:

Micha W. schrieb:
> ich könnte mich irren, aber soweit ich weiß werden die rohen Bild-Daten
> auf dem Kopf gespeichert.

Also 0,0 ist wie üblich oben links in der Ecke.

Gustl B. schrieb:
> Micha W. schrieb:
>> ich könnte mich irren, aber soweit ich weiß werden die rohen Bild-Daten
>> auf dem Kopf gespeichert.
>
> Also 0,0 ist wie üblich oben links in der Ecke.

Okay, das Bild steht von den Zeilen aus gesehen auf dem Kopf. Also Daten 
von links nach rechts sind i.O. aber die oberste Zeile steht unten und 
die zweite als Vorletzte usw.

Und was ich jetzt erst sehe... Die Pixeldaten beschreiben ein Bild von 
nur 1x5 Pixeln.

Exakt. So ist das wirklich üblich. Ich weiß zwar nicht wieso, aber 
vermutlich vom klassischen Fernseher. Da wird das Bild von links nach 
rechts und von oben nach unten aufgebaut. Das erste Pixel ist also links 
oben. Bei VGA und dann auch bei den anderen Nachfolgern ist das genauso.

Das hat man dann auch für Bildformate übernommen und sogar 
Layoutsoftware macht das so. In Indesign ist die Ecke links oben vom 
"Papier" bei 0,0.

Micha W. schrieb:
> Die Pixeldaten beschreiben ein Bild von nur 1x5 Pixeln

Wieso?

Gustl B. schrieb:
> Micha W. schrieb:
>> Die Pixeldaten beschreiben ein Bild von nur 1x5 Pixeln
>
> Wieso?

Weil das 5x5 Byte sind - ich gehe von einem 32Bit-Bitmap aus.
1. Byte Index der Zeile - 2. Byte Alpha - 3./4./5. Byte R/G/B. Das ist 1 
Pixel.
5 Zeilen - also 1x5 Pixel.

Selbst wenn es ein 1 Bit-Bitmap ist so besteht jeder Pixel mit einem 
0-basiertem Index. Und das ist bei 0xFF wohl nicht der Fall :/

An den TO:
Schau Dir mal den Header deiner BMP an und guck, wie das BMP formatiert 
ist. Da gibt es einiges zu beachten.
https://de.wikipedia.org/wiki/Windows_Bitmap#Vor-_und_Nachteile

grüüßee (:

Gustl B. schrieb:
> Ich kann da in deinem VHDL keinen Algorithmus erkennen. Es wird auch
> keine Datei gelesen.
Mit dem Algorithmus meine einfach das Iterationsverfahren über (i,j), um 
die Lese-Adressen zu erzeugen.
> Hänge doch mal die .BMP und die vollständige .VHD an.
Unwichtig, weil das zu lesende Bild genau wie angehängt aussieht und von 
einem Flash-Speicher gelesen wird.

Micha W. schrieb:
> ich könnte mich irren, aber soweit ich weiß werden die rohen Bild-Daten
> auf dem Kopf gespeichert. Also sie unterste Reihe steht dann oben und
> umgekehrt. das erste Byte 0x00 ist der Index für den Pixel gefolgt von 4
> Byte Bilddaten (Alpha-Transparent,R,G,B).

So sieht doch das angehängte (unten stehende) Bild (BMP-Pixeldaten) aus. 
Ich habe mir einfach den Header gespart aber wie du siehst, fangen die 
Pixeldaten ab Index 54 an.

Was die Farbkomponenten (R,G,B) angeht, habe ich nicht für jedes Pixel 
das entsprechende Byte im Bild eingetragen, weil es um ein binäres Bild 
angeht, spricht R=G=B.

Micha W. schrieb:
> Und was ich jetzt erst sehe... Die Pixeldaten beschreiben ein Bild von
> nur 1x5 Pixeln.

Wo siehst du das?

Guck dir doch mal an: https://github.com/FoxExe/Image2Bitmap
Evtl. hilft das.

WOKO schrieb:
> was ich öfters ein und ausgelesen hab, ist ein GPM Bild. Das ist einfach
> mit Irfanview anzuzeigen bzw abzuspeichern

Nutze ich auch gern das Format, dann hat man den 8bit Aerger auch nicht. 
Ein Code Beispiel zur Inspiration findet sich hier:

https://gitlab.com/Elpra/drever-framework/drever/-/blob/master/src/drever/vhdl/data_handlers/image_data_pkg.vhd