C GLCD -> Logos

[Janiiix3]

Guten Morgen.

Habe da mal eine Frage an euch Grafikdisplay Experten.
Wie erstellt ihr eure Logos oder irgendwelche Bildchen, die ihr später mal auf einem Grafikdisplay darstellen wollt?

Oder muss ich jedes Pixel einzeln aufschreiben?

P.S

Angenehmen, kurzen Freitag

 

[LotadaC]

Sollen das sowas wie Sonderzeichen/Symbole werden, oder richtige (große) Grafiken?
Bei (ggf auch mehrzeiligen) Sonderzeichen kannst Du die wie solche definieren und verwenden.
Bei Graphiken brauchst Du die Bitmuster oder entsprechende Zeichenroutinen, die diese zzr Laufzeit in einem entsprechendem Zwischenspeicher erzeugen (ggf unter Berücksichtigung bereits vorhandener Inhalte).

 

[TommyB]

Wie das Bild wirklich generiert wird hängt davon ab was für ein Display es ist.
Vom Prinzip zeichnet man eben ein Bild in der geforderten Auflösung im Bildbearbeitungsprogramm deiner Wahl. Ggf. sollte man sich gleich schon an Limits halten (nur Schwarz/Weiß, x Graustufen, x Bit Farbe)…
Und dann muss das Bild halt umgewandelt werden. Wenn ich mich richtig erinner haben Bascom und LunaAVR dafür für einige LCD's Tools für. Bei den COLED's die ich nutze muss ich nur das Bitmap hoch schaufeln.

 

[Dirk]

Wenn ich mich richtig erinner haben Bascom und LunaAVR dafür für einige LCD's Tools für

Es gibt inzwischen viele Tools, die monochrome oder farbige Bilder in ein Array konvertieren.
Ich würde nach den Begriffen "picture convert avr arduino" suchen.

Vielleicht hilft dies schon weiter ...
http://en.radzio.dxp.pl/bitmap_converter/
http://manytools.org/hacker-tools/image-to-byte-array/

(Ich hatte selber mal etwas hier in das Forum gestellt, das Programm ist aber noch von vor 2000, generiert Assembler-Code, das entwickel ich aber nicht mehr weiter )

Dirk

 

[TommyB]

(Ich hatte selber mal etwas hier in das Forum gestellt, das Programm ist aber noch von vor 2000, generiert Assembler-Code, das entwickel ich aber nicht mehr weiter )

Willste etwa keine Bit(map)s mehr schubsen?

Ist aber auch ein komplexes Thema, speziell bei Farb Displays mit krummen Farb-Bit-Tiefen, dann ggf. noch Dithering… Viel Arbeit. Denkt man nicht dran.

 

[Janiiix3]

Das hört sich ja schon mal gut an. Danke für die Links @Dirk
Wieso nutzt man ausgerechnet das .bmp Format, was bringt dies für Vorteile mit sich?

 

[LotadaC]

Die sind verhältnismäßig einfach aufgebaut, insbesondere unkomprimiert. Gibt auch Konverter, die Tif oder so nutzen.

 

[TommyB]

Nicht nur verhältnismäßig. Eine Bitmap besteht im Wesentlichen nur aus 2 Teilen: Dem Header mit Informationen wie Breite, Höhe und Farbtiefe in Bits per Pixel, gefolgt von den reinen Bilddaten, unkomprimiert. Ein 24 Bit Bitmap (aka TrueColor) mit 8 x 8 px würde also 8 * 8 * 3 = 192 Bytes Daten belegen, in Monochrom (1 Bit per Pixel) 8 * 8 / 8 = 8 Bytes. + dem Header natürlich.

Auf dem PC eigentlich unkompliziert, weil zumindest das .Net Framework schon Encoder für .jpg, .png, … mit bringt, aber versuch das mal auf nem AVR. .png werden z. B. per gzip komprimiert, + weiteren Optimierungen. Da wäre so ein ATmega88 garantiert schon voll, nur für die Unterstützung des Dateiformates. Von der Verarbeitungszeit mal ganz zu schweigen
Nur mal so zum Vergleich: So eine .png optimal zu komprimieren (Stichwort OptiPNG) kann selbst auf einem 2.6GHz System mal locker > 10 Sekunden dauern.

 

[Janiiix3]

Ist ja auch immer eine Geschmackssache ob man ein Logo auf einem GLCD haben möchte oder nicht.
Mich hat es nur mal interessiert, wieso man ausgerechnet das Bitmap Format ausgewählt hat.

 

[TommyB]

Die Hardware arbeitet selbst fast ausschließlich (*) mit unkomprimierten Bilddaten. VRAM, hatten wir bei Char LCDs schon mal.
Es muss also nur geprüft werden ob das Bitmap passt (Auflösung, Bittiefe). Weg mit dem Header und ab damit in den Grafikspeicher, sonst ist nix zu tun (wie Dekomprimieren).

(*): Diese digitalen Fotorahmen mal ausgeschlossen