"Picture Converter 1bpp" Tool zum erzeugen von Bitmapgrafiken für monochrome LC-Displays

[Erik (Gast)]

Ich beschäftige mich häufig mit Mikrocontroller + LC-Displays und habe 
damals kein passendes Programm zum erzeugen von Bitmap/Array-Grafiken 
gefunden. Deshalb habe ich mir ein eigenes kleines Tool geschrieben. 
Sicherlich gibt es mittlerweile einige Programme die genau das tun was 
ich will aber egal… Vielleicht hilft es ja einem von euch weiter. 
Feedback nehme ich gern an…

Die Homepage zu diesem Tool ist übrigens 
http://www.embedded-tools.de.vu/



Hier die Kurzbeschreibung zum Programm:

Der "Picture Converter 1bpp" ist ein nützliches Tool zum schnellen und 
einfachen Erstellen von Bitmapgrafiken für monochrome LC-Displays.

Erzeug aus einer beliebigen Bilddatei (jpg,gif,tif,png,bmp, etc...) eine 
Bitmap mit einer Farbtiefe von 1 Bit.

Schwarzschattierungen werden mittels Floyd-Steinberg Dithering Verfahren 
ermittelt. Die Auflösung (zerren/strecken) des Zielbildes kann angepasst 
werden.

Zusätzliche Funktionen: Drehen und Spiegeln

Verlustfreie Speicherung in den Formate: bmp, tif und png

Export in #include - fähiges C-Header-File für verschiedene Compiler, 
Grafikcontroller und Mikrocontroller.

In "datei.h" stehen die Bitmapdaten als Array und der Angabe von Breite 
und Höhe in Pixeln. Jede Zeile in "datei.h" enthält eine Zeile der 
Bitmap. Die ersten Arrayeinträge verweise per Präprozessor auf die 
Angaben zur 1. Bildbreite und 2. Bildhöhe (ACHTUNG: wenn dieser Wert 
größer 255 ist ein Eintrag 2byte groß, sonst 1byte). Die erste volle 
Zeile des Array enthält die oberste Zeile der Bitmap. Das erste Byte ist 
links oben in der Bitmap. D7 des Bytes ist das erste Pixel. Diese 
Aufteilung eignet sich z.B. für T6963 und SED1335 Controller.

Dateien für KS108, SED1520 und SPLC0501C Controller können mit 
vertikaler Orientierung erzeugt werden. Ein Byte enthält dann 8 Pixel 
vertikal angeordnet. D7 des Bytes ist das oberste Pixel. Eine Zeile im 
C-Code besteht aus einem Streifen/Spalte von 8 Pixeln Höhe. In der 
Readme ist Implementierungsbeispiel für den ATMEGA128 mit KS108 
angegeben.

[holger (Gast)]

Mal abgesehen davon das mir wohl einige *.DDLs zum ausführen
des Programms fehlen:

>C-FILE-HEADER:

>In datei.h stehen die Bitmapdaten als Array und
>der Angabe von Breite und >Höhe in Pixeln.

In datei.h gehören die Bitmap Daten nicht rein.
Das muss in eine datei.c. Wird datei.h von zwei
unabhängigen *.c Dateien per include eingebunden
hagelt es Fehlermeldungen spätestens beim linken.

[Nils S. (kruemeltee)]

>Wird datei.h von zwei
>unabhängigen *.c Dateien per include eingebunden
>hagelt es Fehlermeldungen spätestens beim linken.
Quatsch.

#ifndef _BITMAP_
#define _BITMAP_

daten

#endif

[Erik (Gast)]

>Mal abgesehen davon das mir wohl einige *.DDLs zum ausführen
>des Programms fehlen:

Das .net Framework 4.0 muss installiert sein.

>In datei.h gehören die Bitmap Daten nicht rein.

Das ist bewusst so gemacht um mir 2 Klicks beim hinzufügen der Dateien 
im AVR Studio zu sparen. Wie Nils S. schon geschrieben hat sollte durch

#ifndef _BITMAP_

 die Mehrfacheinbindung ausgeschlossen sein.

[Simon K. (simon)]

Erik schrieb:
>>In datei.h gehören die Bitmap Daten nicht rein.
>
> Das ist bewusst so gemacht um mir 2 Klicks beim hinzufügen der Dateien
> im AVR Studio zu sparen. Wie Nils S. schon geschrieben hat sollte durch
>

#ifndef _BITMAP_

 die Mehrfacheinbindung ausgeschlossen sein.

So einfach ist das nicht!

1. Funktioniert das nur, wenn das Bitmap-Array static deklariert ist und
2. Hat man dann für jedes Einbinden der .h Datei ein einzelnes 
Bitmap-Array inkludiert. Das heißt 5 mal (in 5 verschiedenen .c Dateien) 
inkludiert -> Die gleiche Bitmap ist 5 mal im Speicher vorhanden.

Hintergrund:
Das #ifndef ist eine Preprozessor Anweisung. Das heißt, die Anweisungen 
werden vor dem eigentlichen Kompiliervorgang gestartet. Jede .c Datei 
wird aber einzeln kompiliert. Beim Kompilieren einer "datei2.c", weiß 
der Compiler nicht, dass er "datei1.c" schon kompiliert hat. Demnach 
weiß er auch nicht, dass das Define  BITMAP  in "datei1.c" schon 
abgearbeitet wurde. Demnach inkludiert er wieder die .h Datei.

Erst nach dem einzelnen Kompilieren aller .c Dateien kommt der Linker 
und fügt alle erzeugten Objekt-Dateien zusammen. Und hier merkt der 
Linker: Nanu, ich habe ja 5 mal das Objekt "BitmapArray[x][y]" (o.ä.) in 
5 verschiedenen Dateien vorliegen.
-> Fehler.

Deshalb kommt das Array immer in die .c Datei und eine extern-Definition 
in die .h Datei, die dann von mehreren Orten inkludiert werden kann.

[Läubi .. (laeubi)]

Wobei die Diskussion recht müßig ist, einmal wird man vermutlich nicht 
in fünf Modulen auf die Grafik zugreifen wollen, und andererseits hält 
einen ja niemand davon ab sich das schnell zurechtzukopieren wenn man 
dann doch diesen Anwendungsfall hat.

[Simon K. (simon)]

Läubi .. schrieb:
> Wobei die Diskussion recht müßig ist, einmal wird man vermutlich *nicht*
> in fünf Modulen auf die Grafik zugreifen wollen, und andererseits hält
> einen ja niemand davon ab sich das schnell zurechtzukopieren wenn man
> dann doch diesen Anwendungsfall hat.

Auf der anderen Seite eignen sich unerfahrene Leute sowas an, und 
eröffnen dann einen neuen Thread hier im Forum und fragen, warum sich 
der Quellcode nicht kompilieren lässt.

[Erik (Gast)]

>1. Funktioniert das nur, wenn das Bitmap-Array static deklariert ist und
>2. Hat man dann für jedes Einbinden der .h Datei ein einzelnes
>Bitmap-Array inkludiert. Das heißt 5 mal (in 5 verschiedenen .c Dateien)
>inkludiert -> Die gleiche Bitmap ist 5 mal im Speicher vorhanden.

>Und hier merkt der Linker: Nanu, ich habe ja 5 mal das Objekt "BitmapArray[x][y]" 
>(o.ä.) in 5 verschiedenen Dateien vorliegen.

Das stimmt natürlich... In meinen Programmen nutzte ich meist nur eine 
.c Datei die Bitmaps für Menüs aus einer "icon.h" lädt. Demnach spielt 
das keine Rolle. ABER wer auf eine Bitmap aus mehreren c-Dateien 
zugreifen will, der muss das Array in ein c-File umkopieren.

In der Regel finde ich es sinnvoll in "Schichten" die funktional 
strukturiert sind zu programmieren. Jede Schicht kennt nur Funktionen 
der darunterliegenden Schicht z.B. Treiber/Hardwareabstraktion <- 
Grafik/Textausgabe <- Nutzerinteraktion. Jede Schicht erhält eine 
c-Datei. Erst in der Letzten könne dann Bitmaps genutzt werden 
(einmaliger include). Das System wird somit immer weiter abstrahiert. 
Nachteilig ist allerdings, wenn man an diesen Konzept kategorisch 
festhält, das einige Funktionsaufrufe nur durch die Schichten 
weitergereicht werden, das verringert die Abarbeitungsgeschwindigkeit 
erhöht aber die Portierbarkeit auf wechselnde Hardware.

Ob dies nun sinnvoll ist oder nicht hängt natürlich stark vom Projekt 
ab.

[Stephan K. (dustpuppy)]

Hi,
warum den ganzen Aufwand? Jedes gute Bildverarbeitungsprogram kann das 
bereits. Das Bild einfach in "xbm" abspeichern/exportieren.
Dann bekommt man so eine Datei:

#define mein_bild_width 88
#define mein_bild_height 128
const unsigned char mein_bild_bits[] = {
   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x01,
   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80, 0x01, 0x00,
...
..
.

Hier einfach ein PROGMEM einfuegen:

#define mein_bild_width 88
#define mein_bild_height 128
const unsigned char mein_bild_bits[] PROGMEM = {
   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x01,
   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80, 0x01, 0x00,
...
..
.

Und dann das Ganze so anzeigen :

#include "mein_bild.xbm"

void glcd_XBM(const unsigned char *xbm, uint16_t x, uint16_t y, int w, int h)
{
  char D;
  for(uint16_t zeile=0 ; zeile < h ; zeile++)
  {
    for(uint16_t spalte=0 ; spalte<(w/8) ; spalte++)
    {
      for(int i=0;i<=7;i++)
      {
         D=pgm_read_byte(xbm+(zeile*w/8)+spalte);
         if(D & 1<<i)
         {
           glcd_pixel(x+i+(spalte*8),y+zeile,TRUE);
         }
         else if(!D)
         {
           glcd_pixel(x+i+(spalte*8),y+zeile,FALSE);
         }
       }
    }
  }
}

void main(void)
{
   glcd_XBM(mein_bild_bits, 0, 0, mein_bild_width, mein_bild_height);
}

Gruesse
Dusty

[Simon K. (simon)]

Aaah, wollte auch was dazu schreiben, mir ist aber xpm eingefallen. 
Das ist etwas unhandlicher. Aber ich wusste doch, dass ich das schon mal 
gesehen hab. xbm genau. IrfanView kann das auch AFAIK.

[Stephan K. (dustpuppy)]

Wer's etwas mehr haben will, nimmt das hier und uebergibt noch ob's 
transparent oder nicht und/oder invers sein soll. Die Modes koennen auch 
kombiniert werden, also z.b. INVERSE + TRANS.
Solid ist sehr viel schneller als transparent.

#define bit_get(p,m) ((p) & (m))
#define bit_set(p,m) ((p) |= (m))
#define bit_clear(p,m) ((p) &= ~(m))
#define bit_flip(p,m) ((p) ^= (m))
#define bit_write(c,p,m) (c ? bit_set(p,m) : bit_clear(p,m))
#define BIT(x) (0x01 << (x))
#define LONGBIT(x) ((unsigned long)0x00000001 << (x))

#define SOLID    0b1
#define TRANS    0b10
#define INVERSE    0b100

void glcd_XBM(const unsigned char *xbm, uint16_t x, uint16_t y, int w, int h, int mode)
{
  int D;
  for(uint16_t zeile=0 ; zeile < h ; zeile++)
  {
    for(uint16_t spalte=0 ; spalte<(w/8) ; spalte++)
    {
      for(int i=0;i<=7;i++)
      {
      D=bit_get(pgm_read_byte(xbm+(zeile*w/8)+spalte)),BIT(i));
      if(D)
      {
        if( ((mode & TRANS) && !(mode & INVERSE)) )
        {
          glcd_pixel(x+i+(spalte*8),y+zeile,TRUE);
        }
        else if( ((mode & SOLID) && !(mode & INVERSE)) )
        {
          glcd_pixel(x+i+(spalte*8),y+zeile,TRUE);
        }
        else if( ((mode & SOLID) && (mode & INVERSE)) )
        {
          glcd_pixel(x+i+(spalte*8),y+zeile,FALSE);
        }
      }
      else if(!D)
      {
        if( (mode & INVERSE) )
        {
          glcd_pixel(x+i+(spalte*8),y+zeile,TRUE);
        }
        else if( (mode & SOLID) && !(mode & INVERSE) )
        {
          glcd_pixel(x+i+(spalte*8),y+zeile,FALSE);
        }
      }
      }
    }
    }
}

Schon wieder Gruesse

Dusty

[Erik (Gast)]

> warum den ganzen Aufwand? Jedes gute Bildverarbeitungsprogram kann das
bereits.

Das ist richtig, mit "Gimp" kann man auch in .c oder .h exportieren. 
Viele Wege führen nach Rom.

>Solid ist sehr viel schneller als transparent

wenn's um Geschwindigkeit geht würde ich die Ausgabe blockweise(1Byte) 
machen und nicht pixelweise...

z.B.

void glcd_Bitmap(unsigned char * bmp, unsigned char x, unsigned char y)
{//Positionierung nur auf Koordinaten mit Teiler 8 möglich, sonst runden
//oder überscheidente Blöcken auslesen und im nichtüberdekenden Bereich "verodern"
  unsigned char i, j;
  unsigned char width = pgm_read_byte(bmp++);        // aus flash in sram wie breit (bmp[0])
    unsigned char height = pgm_read_byte(bmp++);        // aus flash in sram wie hoch (bmü(1)

  if((x + width) > GLCD_XPIXELS) width = GLCD_XPIXELS - x; //Bitmap abschneiden wenn außerhalb des Displays
   if((y + height) > GLCD_YPIXELS) height = GLCD_YPIXELS - y; //Bitmap abschneiden wenn außerhalb des Displays

  for(j = 0; j < (height/8)+1; j++)
      {
      glcdSetAddress(x,y + j);
      for(i = 0; i < width; i++) glcdDataWrite(pgm_read_byte(bmp++));
      }
}

dadurch ergibt sich aber folgendes Problem, je nachdem welchen 
Grafikcontroller eingesetzt wird ist die Orientierung eines Blocks 
entweder in x oder y Richtung. Dies kann man durch umschreiben der 
Ausgabefunktion korrigieren oder man lässt die Funktion wie sie ist 
nutzt mein Tool und verändert die Orientierung des Bitmaparry. --> 
Schlagwort: Portierbarkeit

[Stephan K. (dustpuppy)]

Man koennte das Blockproblem loesen, wie ich es hier gemacht habe. 
Beitrag "Font tool von Christian R. verbessert"

Gruesse

Dusty

[Erik .. (erik_mit_k)]

Hallo,
ist zwar schon eine Weile her ich habe aufgrund von verschiedenen 
Anfragen mein Progrämmchen  nochmal überarbeitet. Unter anderem habe ich 
die von euch gennannten Hinweise mit eingebaut (speziell c & h-file).
Hier die Änderungen im Detail:

- Anzeige der Vorschaufenstern verbessert (schärfere & skaliert)
- neues Format eingebunden: xbm - X BitMap
- das Bitfeld in c- bzw. h-Dateien kann jetzt als big oder little endian
- optionale Ausgabe der Bitmap als c-Datei für Bitfeld und h-Datei für 
include aus mehrern unabhängigen c-Dateien möglich
- Ausgabe der Bitmap als h-Datei inklusive Bitfeld weiterhin möglich

Wenn's interessiert viel Spaß damit;-)