Hallo, wie bereits erwähnt versuche ich das folgende Display anzusteuern: http://www.buydisplay.com/default/tft-5-inch-lcd-display-module-w-controller-board-serial-i2c-ra8875 Es sind im Beispiel Code einige Bilder im internen Flash abgelegt, die ich auch korrekt anzeigen kann. Jetzt versuche ich mir eigene BMP-Dateien anzeigen zu lassen. Ich jage zum Beispiel ein 20 x 20 Bitmap File durch den Converter und lasse es anzeigen. Das BMP File zeigt (bzw. soll zeigen) einen rot - grünen - rot - blau - rot Streifen. Auf dem Display angezeigt wird jedoch ein blau - braun - blau - grün - blauer Streifen. Das 20 x 20 Pixel Format ist hingegen korrekt. Woran könnte die falsche Farb-Konvertierung liegen??? Wie gesagt, die Beispiel Bilder aus dem Sample Code werden korrekt angezeigt. Habe auch schon verschiedene Converter ausprobiert, da ich ursprünglich dachte, dass der Fehler beim Konvertieren passiert. Mittlerweile glaube ich aber, dass es an den Displayeinstellungen liegen müßte. Bedankt im Voraus!
BMP ist nicht gleich BMP. Welche Farbtiefe hat Deine BMP-Datei, welche haben die "funktionierenden"?
HMMM, ich konvertiere mit 16 Bit Farbtiefe. Also das BMP-Bild an sich hat eine Farbtiefe von 24 Bit und ich hau es in den Converter von Microchip mit 16 Bit Farbtiefe. Ein Bild mit 40 x 40 Pixel ergibt dann ein Array von 3200 Elementen mit jeweils 8 Bit. Die Bilder die ich aus dem Example Code anzeigen kann sind beispielsweise 112 x 140 Pixel und haben 31360 Elemente a 8 Bit. Vermutlich doch ein Fehler in der Konvertierung?
Die Frage wäre ob die du die Farben auch im Richtigen Bitformat umrechnest: 24Bit BMP = R(8) + G(8) + B(8) 16Bit Display = R(5) + G(6) + B(5) (je nach Display ggf. auch anders)
@Irgendwer: Das ist interessant und vermutlich liegt hier der Hund begraben. Habe mal genau in dem Datasheet des Display Controllers nachgeschaut (RA8875). Ich nutze den 16-Bit Data Bus MCU mit 65K Colors. In diesem Mode ist nach Datasheet das RGB Format in der Tat: R(5), G(6), B(5) wie genau kann ich jetzt die von Dir angesprochene Umrechnung von R(8), G(8), B(8) durchführen??? Das ist mir noch nicht ganz klar! Einfacher wäre vermutlich das BMP direkt in 16 Bit abzuspeichern, aber der andere Weg ist mir deutlich lieber. Meine Funktion zum Zeichen sieht bis jetzt in etwa so aus:
1 | void bmp_picture_left_right_top_down(unsigned char *bmp_pic, unsigned int size) |
2 | for(i=0;i<size;i++) |
3 | {
|
4 | LCD_DataWrite(*bmp_pic); |
5 | *bmp_pic++; |
6 | }
|
Mit LCD_DataWrite(*bmp_pic); grieft er jetzt ja folgich auf die falschen Bit Kombinationen zu! Wie genau kann ich die Umrechnung vornehmen?
Ich habe jetzt einen Konverter gefunden (GIMP) mit dessen Hilfe man ein Bild genau in dem Format 16Bit Display = R(5) + G(6) + B(5) abspeichern kann. Dieses Bild konvertiere ich dann mit 16 Bit und lasse es mit der obigen Funktion bmp_picture auf dem Display ausgeben und die Farben sind immer noch vertauscht. Wie kann das sein?? Jeglicher Input willkommen. Danke.
Lisa schrieb: > Wie kann das sein?? > Jeglicher Input willkommen. Danke. evtl.: http://de.wikipedia.org/wiki/Byte-Reihenfolge oder ein MSB LSB "Problem"? auch BMP ist != BMP da war noch was mit Windoofs vs. OS/2 http://de.wikipedia.org/wiki/Windows_Bitmap
Joachim B. schrieb: > oder ein MSB LSB "Problem"? Wahrscheinlich, wenn rot als blau ausgegeben wird: RGB -> BGR. Georg
Mach dir doch das Leben einfacher: Erzeuge ein einfarbig rotes Bild und konvertiere es. Dann sieh dir die Ausgabe an. Nun weißt du, wo die roten Bits gelandet sind und kannst deine Ausgabe anpassen. Anschließend das Gleiche noch einmal mit Blau und Grün und du bist fertig.
Georg G. schrieb: > Mach dir doch das Leben einfacher: Erzeuge ein einfarbig rotes > Bild und > konvertiere es. Dann sieh dir die Ausgabe an. Nun weißt du, wo die roten > Bits gelandet sind und kannst deine Ausgabe anpassen. Anschließend das > Gleiche noch einmal mit Blau und Grün und du bist fertig. Danke Georg. Ich blicke nicht mehr ganz durch. Habe deinen Rat befolgt. Aus Blau -> Blau Aus rot -> beige (oder brau, gelb) Aus grün -> eine Mischung aus Violett und braun Das Blau scheint genau die richtige Farbe zu sein. Es scheint aber auch nicht eine bloße Vertauschung zwischen Rot und Grün zu sein
Angehängte Dateien:
-
Color_Table_Entry.PNG
56 KB
Was mich wundert ist, dass der Graphics Converter von Microchip genau in das richtige Format bei 16 Bit konvertieren sollte -> R(5), G(6), B(5) siehe Anhang!
Lisa schrieb: > Aus Blau -> Blau > Aus rot -> beige (oder brau, gelb) > Aus grün -> eine Mischung aus Violett und braun also wenn bei grün was violettes raus kommt ist ja wieder irgendwie blau mit drin evl stimmt ja weder die Bitrichtung (LSB->MSB) noch die Zuordnung H-/L-Byte. Kannst du nicht mal ein paar Daten von Hand erzeugen, oder in einer Schleife mal die 16-bit als konstannten Wert ausgeben?
1 | for (i=0;i<100;i++) { |
2 | LCD_DataWrite(h_byte); |
3 | LCD_DataWrite(l_byte); |
4 | }
|
Rot
grün blau
h_byte 0b11111000 0b00000111 0b00000000
l_byte 0b00000000 0b11100000 0b00011111
Sascha
Überprüfe mal den offset des-bmp-headers. Ein falscher offset kann auch zu Farbverschiebungen führen.
Hallo zusammen, vielen Dank für die ganzen Antworten. Das Problem hat sich mittlerweile erledigt. Danke sehr.
Ich habe mir wie empfohlen erst einmal manuell versucht ein blaues Kästchen zu zeichnen in dem oben angegebenen 16 Bit Format: R(5) + G(6) + B(5) also Sende 0b00000000 und dann Sende 0b00011111 Dies ergibt einen blauen Pixel. Dann habe ich mir einen blaues Bitmap gezeichnet und dieses mit zig verschiedenen Konvertern so lange konvertiert bis ich ein Array der Form:
1 | unsigned short Array[] = {0b00000000, 0b00011111, 0b00000000, 0b00011111, 0b00000000, 0b00011111, 0b00000000, 0b00011111, ...} |
Schließlich habe ich einen Konverter gefunden, der in das gewünschte Format konvertiert. Jetzt lassen sich die BMP Bilder richtig anzeigen
Steef schrieb: > Schließlich habe ich einen Konverter gefunden Es wäre sicher einfacher gewesen den selbst zu programmieren. Georg
Steef schrieb: > Schließlich habe ich einen Konverter gefunden... Ja - das scheint seit einigen Jahren der aktuelle Zeitgeist zu sein. Bloß nichts mehr selber machen, nichts mehr selber verstehen, nichts mehr selber können. Dabei ist das Ganze doch so strunz-einfach: /**************************** wandelt rgb nach color565 um ****************************/ word RgbToColor (byte r, byte g, byte b) { word w, c; w = (b << 8) & 0xF800; c = (g << 3) & 0x07E0; r = r >> 3; w = w | c | r; return(w); } /**************************** wandelt color565 nach rgb um ****************************/ COLOR ColorToRGB (word color565) { COLOR E; E.b = (color565 >> 8) & 0xF8; /* linksbündig */ E.g = (color565 >> 3) & 0xFC; E.r = (color565 << 3) & 0xF8; return E; } Aber ganz offensichtlich ist sowas für die heutige Ingenieurs-Generation bereits unzumutbar. W.S.
W.S. schrieb: > Dabei ist das Ganze doch so strunz-einfach: > /**************************** > wandelt rgb nach color565 um > ****************************/ > word RgbToColor (byte r, byte g, byte b) ..... danke dafür, sieht aus als wenn ich das grad am Adafruit TFT brauchen könnte Ich habe mir das noch nicht genau angesehen aber es sind da auch 16 Bit und eine Vollfarbe war 0xF800 (ein alter Ing der nicht gerade Profiprogger ist, aber fürs Nötigste reicht es) W.S. schrieb: > Aber ganz offensichtlich ist sowas für die heutige Ingenieurs-Generation > bereits unzumutbar. nun ja manche haben auch anderes zu tun als Nebenkriegsschauplätze aufzutun ;-) Wenn ich mich um jedes Byte persönlich kümmern würde wäre ich nur an Nebenkriegsschauplätzen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.