Bitmap in 16Bit Farbwert-Vektor zerlegen (Programm)

Ich habe so einen Konverter für mein S65 Lib programmiert, in Delphi. 
Normalerweise macht diese Konvertierung das Betriebsystem per API 
Funktionen, zumindestens stehen unter MS Windows ausreichend Funktionen 
zu verfügung. Wenn jetzt noch dieses API ordentlich objektorientiert 
gekapselt ist, so wie in Delphi üblich, dann beschränkt sich diese 
Konvertierung auf maxiumal 5 Zeilen Source, nämlich Lade Bitmap/JPEG/PCX 
et.,pp. in ein TBitmap Objekt, setze Pixelformat dieser Bitmap auf 
16Bit, und speicher oder exportiere diese Daten.

Gruß Hagen

ähm, je nach Modus werden beim Export die Daten in einem bestimmten 
Format gespeichert.

RAW angehackt bedeutet in den exportieren Daten sind nur die 16 Bit 
Pixel/Farben gespeichert. Immer 2 Bytes bilden diesen Pixel.

RAW nicht angehackt, und es wird in ein spezielles Bitmapformat 
exportiert. Davon gibts insgesamt 4 Formate

-einfarbig, also Bitmap ist komplett einfarbig, dann wird nur 
Breite/Höhte/BBP und Hintergrundfarbe exportiert, man zeichnet dann mit 
FillRect() diese Bitmap in der GLCD

- monochrom, eg. zweifarbig. Wiederum wird ein Header gespeichert und 
danach die Pixeldaten in einem speziellen RLE Format

- mehr als 2 aber weniger als 2^15+1 Farben, dann wieder ein header und 
dansh die Pixeldaten codiert in einem speziellen Format. Zuerst immer 
ein BPP Bits großer Index in eine Farbtabelle die vor den eigentlichen 
Pixeldaten gespeichert wird. Dann solange 0 Bits wie man mit der 
aktuellen Farbe Pixel zeichnen soll (von links nach rechts und oben nach 
unten) Sobald  ein 1-Bit gelesen wird folgt diesem ein neuer Index in 
die Farbtabelle. Angenommen die Bitmap hat 256 unterschiedliche Farben, 
dann ist BPP=8 = 8 Bits pr o Farbindex. Nach dem Standardheader folgt 
also eine sortierte Tabelle mit maximal 256x 16 Bit Farbwerten. Danach 
folgt der Pixelbitstream wie oben beschrieben

- 16 Bit Vollfrabbitmap, wie das RAW Format aber diesesmal mit dedm 
Standardheader davor

Alles dient nur einem Zweck: Komprimierung der Daten. Bei gut farbigen 
Bitmaps kommt man so auf eine Komprimierung auf mindestens 50% zum 
Original, oft sogar bis auf 20%.

Suche hier in der CodeLib den S65 Thread, dort habe ich das Format 
nochmal ausführlicher beschrieben. Du kannst mir auch eine PN schicken 
und meine S65 Lib Source per EMail bekommen.

Die exportierten Dateien benutzen also immer das Byteformat, die 
Interpretation dieser Daten hängt also vom verwendetet Datenormat ab und 
das wird ermittelt über den BPP Wert im Header. Der Header besteht aus 
den ersten par Bytes, dürfte auch in der Datei beschrieben sein.
Würde man das nicht so machen, und Byte/Word Daten so speichern (also 
als *.h Datei) dann könnten diese Daten nicht an Wordgrenze ausgerichtet 
sein. Dann würde deer Compiler von sich aus 0 Bytes zwischenschieben.

Gruß Hagen

ja so ist es, die Breite und Höhe der Bitmap steht dann in der Datei 
aber nicht in den Daten selber. Diese RAW Option habe ich erst später 
nachimplementiert eben für solche Anforderungen wie die deinen.

Gruß hagen