mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Bitmap in 16Bit Farbwert-Vektor zerlegen (Programm)


Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

um ein Bitmap auf meinem S65 Display darzustellen, bräuchte ich einen 
Konverter, der mir für jedes Pixel den Farbwert in einen Vektor ablegt.

Es gibt ein Programm, das BMPConvert heißt. Damit kann man das sehr gut 
machen.

Allerdings finde ich es nirgends mehr.

Kennt jemand ein Programm, was das auch kann ?
Oder hat vielleicht jemand sogar dieses Programm oder einen Link dafür ?

Bin für jede Hilfe dankbar.

MfG
Jürgen

Autor: Hagen Re (hagen)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

das Programm ist super.

Allerdings bekomme ich nur uint8 Datentypen !

Wo stelle ich denn 16Bit ein ?

Danke.

MfG
Jürgen

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ä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

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe leider keine Zeit die Libs durchzuarbeiten, da ich bisher 
selbst den Quellcode geschrieben habe und nichts ändern will. Das ist 
klar, dass die Formate bei verscheiedenen Implementierungen nicht ganz 
passen.

Ich brauche wirklich nur 172*132 16Bit Farbwerte in einem Array.

Sind immer zwei aufeinanderfolgende Bytes zusammengehörend, wenn ich den 
RAW hacken setze ?

z.B. 0xFF, 0xCC -> 0xFFCC als 16 Bit Farbwert ?

Danke für die Hilfe.

MfG
Jürgen

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.