- 12V Akku mit 280 Ah bauen         
Ergebnis 1 bis 7 von 7

Thema: Aufbau Bascom Grafik-Dateien (.bgc)

  1. #1
    Erfahrener Benutzer Robotik Einstein Avatar von Jaecko
    Registriert seit
    16.10.2006
    Ort
    Lkr. Rottal/Inn
    Alter
    42
    Beiträge
    2.009

    Aufbau Bascom Grafik-Dateien (.bgc)

    Anzeige

    Powerstation Test
    Moin.

    Ich bin auf der Suche nach ner Art "Protokoll", wie die Bascom-Grafiken aufgebaut sind; so dass ich also recht einfach die Grösse + Farbinformation der einzelnen Pixel rauslesen kann.

    Ich hab vor, Grafiken auf einer SD-Karte abzulegen, um diese dann je nach Bedarf auf nem Display anzuzeigen. Der µC soll die Datei von einer SD-Karte lesen, anaylsieren und deren Inhalt dann auf dem Display darstellen. Auslesen sowie Darstellen von Informationen auf dem LCD klappt schon. Was jetzt noch fehlt ist eben die Interpretation des Dateiinhalts.

    Was ich mit nem Hexeditor bisher gefunden hab, ist, dass zuerst anscheinend die Abmessungen X*Y jeweils als Word kommen, danach die Farbinformation mit jeweils 4 Byte pro Pixel (Anscheinend je ein Byte für R, G, B sowie als "Füllbyte" 0x00).

    Hat hier jemand noch genaueres?

    mfG


    PS: Ich geh mal davon aus, dass die Interpretation einer "echten" Bitmap (.bmp) etwas komplexer sein dürfte?
    #ifndef MfG
    #define MfG

  2. #2
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    16.02.2006
    Beiträge
    1.113
    Hallo Jaecko,
    mit so was habe ich auch gerade angefangen.
    Wo kommt denn der Dateityp .bgc her, ich kenne nur .bgf. Ist der neu?
    Ich bin noch auf 1.11.9.0, weil ich im Moment kein Risiko eingehen will.
    Windows Bitmaps sind im Wiki gut beschrieben

    http://de.wikipedia.org/wiki/Windows_Bitmap

    Was für ein Display benutzt du denn? Ich habe so ein 1,5" von Display3000, das ich mit 256 Farben betreibe.
    Dabei wird nur die Höhe und Breite vorne weg angegeben, danach kommen direkt je ein Byte pro Bildpunkt.
    Ich versuche gerade, eine Windows Bitmap mit 256 Farben in dieses Format zu konvertieren und dann auf SD Karte abzuspeichern.

    Gruß

    Rolf

  3. #3
    Erfahrener Benutzer Robotik Einstein Avatar von Jaecko
    Registriert seit
    16.10.2006
    Ort
    Lkr. Rottal/Inn
    Alter
    42
    Beiträge
    2.009
    Es gibt bei Bascom bzw. der Herstellerseite zum Download diesen Bitmap-Converter. Der spuckt die konvertieren Bitmaps als .bgc aus.
    Glaub, dass die bgc und bgf im Prinzip das Gleiche sind (c = Color?), zumindest funktionieren die in der Hilfe für bgf angegebenen Befehle problemlos mit den bgc.

    Als Display verwend ich zur Zeit noch eins aus nem Nokia 6100; dürften ebenfalls 1,5" sein. Farbtiefe ist dort das 5:6:5-Format, also pro Pixel 16 Bit.

    Wenn ich "irgendwann" mal nen passenden Stecker find, soll mal ein altes 12" 640x480 aus nem Laptop herhalten. Datenblatt zur Ansteuerung liegt schon da und wäre an sich auch machbar.
    #ifndef MfG
    #define MfG

  4. #4
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    16.02.2006
    Beiträge
    1.113
    Das Nokia 6100 ist doch im Prinzip das gleiche wie das Display3000.
    Du hast drei Farbmodi: 256, 4096 oder 256K Farben. Bisher habe ich immer den 256 Modus benutzt, weil er schneller und weniger Speicher braucht.
    Die höhere Farbauflösung brauchte ich bisher nicht.
    Speicher ist mit der SD Karte dann kein Problem mehr, aber die Geschwindigkeit.
    Um ein komplettes Image von der SD zu laden, muss ich 32 Sektoren lesen, ansonsten wären es 64.
    Wenn du den Converter von MSC benutzt, dann werden die Daten im RLE Format abgespeichert. Die Beschreibung findest du hier:
    http://de.wikipedia.org/wiki/Laufl%C3%A4ngenkodierung

    Gruß

    Rolf

  5. #5
    Erfahrener Benutzer Robotik Einstein Avatar von Jaecko
    Registriert seit
    16.10.2006
    Ort
    Lkr. Rottal/Inn
    Alter
    42
    Beiträge
    2.009
    Also das RLE-Verfahren hab ich mir mal angeschaut, sieht eigentlich ganz logisch aus.

    Nur wenn ichs jetz an dem Beispiel versuch, hackts noch...
    Im Anhang das Original-Bild (als gif, bmps mag das Forum hier ned)...
    und hier der Hex-Dump der zugehörigen bgc:

    0D 18 38 01 00 AA 2C 00 1C AA 01 1C 00 AA 13 00
    1C AA 03 1C 00 AA 11 00 1C AA 05 1C 00 AA 0F 00
    1C AA 07 1C 00 AA 0D 00 1C AA 09 1C 00 AA 0B 00
    1C AA 0B 1C 00 AA 09 00 1C AA 0D 1C 00 AA 07 00
    1C AA 0F 1C 00 AA 05 00 1C AA 11 1C 00 AA 03 00
    1C AA 13 1C 00 AA 01 00 1C AA 15 1C 00 AA 18 00

    Also aus den ersten beiden Bytes hol ich hier die Info, dass das Bild wohl 13x24 Pixel gross ist (was auch stimmt).
    Nur wie gehören die Bytes da jetzt zusammen?
    "AA 2C" heisst wohl ne Wiederholung 44-fach. Aber wo ist da die Farbe versteckt?
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken winamp_vol10.gif  
    #ifndef MfG
    #define MfG

  6. #6
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    16.02.2006
    Beiträge
    1.113
    Schau mal in der Hilfe unter Tools Graphic Converter oder Suche nach RLE, dann findest du die Kompressionsmethode:

    The RLE method used is : byte value, AA(hex), repeats.

    So a sequence of 5, AA, 10 means that a byte with the value of 5 must be repeated 16 times (hex notation used)

    Dass AA ist wohl eine Art Trennzeichen, also bedeutet

    00 AA 2C Wert (Farbe) 0 44 mal.

  7. #7
    Erfahrener Benutzer Robotik Einstein Avatar von Jaecko
    Registriert seit
    16.10.2006
    Ort
    Lkr. Rottal/Inn
    Alter
    42
    Beiträge
    2.009
    Ha... glaub jetz hab ichs:

    0D 18 38 01: Bildgrösse 0D x 18 (= 13x24)... was das 38 01 heisst, weiss ich noch nicht
    00 AA 2C 00: Farbe 00, + 2C Wiederholungen
    1C AA 01 1C: Farbe 1C, + 01 Wiederholungen
    00 AA 13 00: Farbe 00 + 13 Wiederholungen
    ...

    Dass da dann aber nicht gleich AA 2D 00 steht?...
    Naja. Hauptsache so klappts.

    Wobei ich auch grad gefunden hab, dass der Converter die Dateien auch unkomprimiert speichern kann; also jedes Byte ein Pixel. Glaub, dass ich das dann so mach; erspart mir einiges an Rechnerei. Und in Sachen Speicherplatz kann man auf ner SD-Karte eh rumwutzen. Die Bearbeitungszeit ist da eh Nebensache. Darf ruhig mal 1-2 sec. dauern.
    #ifndef MfG
    #define MfG

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

Solar Speicher und Akkus Tests