Hallo, gibt es auch einen Font Generator der mir Fonts mit 2bpp erstellt (und diese als C-File ausgibt)? Bernd
Soll das 2bpp 2 bytes per pixel heißen oder was? P.s. wenn ja willst du bunte Schriften machen? Gruß ErgoProxy
2bpp (bit per pixel) - ich möchte gern zwei Graustufen darstellen. Der Epson Controller arbeitet im 2bpp Modus so, dass die 8Bit Schrift in 4Bit unterteilt wird. D.h. wenn beide 4Bit gleich sind (gleich gesetzt werden) bekommt man Schwarz, wenn nur die ersten 4Bit gesetzt sind ein helles Grau, wenn nur die höheren 4Bits (der 8Bits) gesetzt sind, erhält man ein dunkles Grau. Bei einer "normalen" 8Bit Schrift mit 1bpp werden jetzt gewisse Passagen bei den Buchstaben Grau dargestellt, da sich die lower und higher 4Bits nicht entsprechen. Das ist natürlich vom Lesen her nicht so schön / bzw. leserlich. Deshalb such ich entweder ein Programm, welches mir gleich eine schöne Schrift / Buchstaben mit 2bpp liefert oder ich muss die Buchstaben (wahrscheinlich) per Hand abändern, so dass alle Black/White dargestellt werden. Bernd
Versteh ich das richtig ? Zeile (4 bit) schwarz: 0xFF Zeile (4 bit) helles grau: 0x0F Zeile (4 bit) dunkles grau: 0xF0 Zeile (4 bit) weiß: 0x00 Ist das so codiert? Also 8 (MSB) und 4 ergebn zusammen einen Pixel ?
fast habs mir grad mal im Display selbst angeschaut... hab mich etwas vertan. 0x81 = 1000 0001 = 1.Pixel(10) 2.Pixel(00) 3.Pixel(00) 4.Pixel(01) es heißt zwar 2bpp im Datenblatt aber effektiv kann man nur 00 = weiß, 01 = grau und 11 = schwarz darstellen... Für mich (arbeite zum ersten Mal mit so einem Display) sehr komisch - aber so ist es auf jeden fall beim Epson Controller S1D13700) Bernd
Und du hast den "alten" Font Code in c? und im prinzip musst du doch nur beim Senden schauen ob das Bit vom Font, dass du senden willst, eins ist, dann schreibst du in einer Puffervariablen 2 einsen rein und so weiter und sendest dann diese 16bit anstelle der 8bit. z.b. Font: 0b10011000 -> 0b1100001111000000
1 | uint16_t umwandlung(uint8_t data) |
2 | {
|
3 | for(i=0;i<8;i++) |
4 | {
|
5 | uint16_t temp; |
6 | if(data & (1<<i) |
7 | {
|
8 | temp |= (1<<(2*i)) | (1<<(2*i+1); |
9 | }
|
10 | }
|
11 | return temp; |
12 | }
|
Da sollte (ich hab das eben grade getippt ^^) jetzt beim durchlaufen jedes Bit verdoppelt werden und das kannst du dann einfach senden. Gruß ErgoProxy
Gabs hier nicht mal die Möglichkeit Beiträge zu bearbeiten?! Da fehlt noch eine Klammer bei der if Anweisung und weiter unten noch eine bei der zweiten Temp zuweisung.
1 | uint16_t umwandlung(uint8_t data) |
2 | {
|
3 | for(i=0;i<8;i++) |
4 | {
|
5 | uint16_t temp; |
6 | if(data & (1<<i)) |
7 | {
|
8 | temp |= (1<<(2*i)) | (1<<(2*i+1)); |
9 | }
|
10 | }
|
11 | return temp; |
12 | }
|
So sollte es stimmen.
vielen Dank für dein C-Code. So funktioniert es! Habs grad mit einem einzelnen Buchstaben ausprobiert. Gibt es auch ein Programm mit dem man 2bpp Bilder als Bitmap erzeugen kann? Wie wird diese Graustufe im Bitmap (Hexwerte) dargestellt / codiert? So dass ich Bilder mit dieser einen Graustufe auf dem Display darstellen kann. Gruß Bernd
Schau mal an, was ImageMagick so drauf hat. Als Graymap passt vielleicht ein PGM oder ein MS-BMP mit 2 Bitplanes. In welchem Format liegen denn die Fonts vor? Evtl. binär einlesen, nach PGM oder PPM konvertieren mittels C und dann weiter zu den bebrauchten Formaten (PNG, BMP, ...) bzw. umgekehrt wenn's in die andere Richtung gebraucht wird.
>Als Graymap passt vielleicht ein PGM oder ein MS-BMP mit 2 Bitplanes.
hab mir das Fileformat mal angeschaut.. im Normalfall hat PGM P2 16
Graustufen (von 0 bis 15)und P5 (255 Graustufen)... aber mit zwei Planes
gibt es dass auch nicht.
Bernd
Hm du hast n Bitmap und davon die Rohdaten? Z.b. 255 Farben oder was weiß ich. Dann machst du das so, dass du alle Farben addierst und dann durch 3 teilst. Ist der Wert unter 1/3*255 dann setzt du dieses Pixel schwarz. Ist es über 2/3*255 dann setzt du es weiß und alles dazwischen setzt du grau. Wenn ich ehrlich bin ich hab mich mit dem Bitmap als Kontainer noch nicht ausreichend beschäftigt um da jetzt einen Quellcode zu schreiben aber im Prinzip ist er sehr einfach wenn man erstmal die Rohdaten also die einzelnen Pixelwerte hat. Da es mich eh interessiert schau ich mir gleich mal das BMP-Format an und schau ob ich da was machen kann. Wollte ich eh da ich grade ein S65 am Mega8 zum laufen bekommen hab und das einen etwas gewöhnungsbedürftiges Farbformat hat, das ich aus einem normalen BMP erstmal machen müsste. Gruß ErgoProxy
hab grad mal etwas am Kontrastregler gedreht und es sind tatsächlich 4 Grautöne. Das mit der Schrift passt aber trotzdem. 00 = weiß 01 = helles grau 10 = dunkles grau 11 = schwarz Wenn man das Bitmap mit 16 Graustufen abspeichert, müsste man es auf 4 Graustufen herunter-gecodet bekommen. Mit welchem Display / Controller arbeitest du zurzeit? Bernd
Da ich glaube das Format verstanden zu haben wer ich mal versuchen dir ein kleines Prog zu schreiben, dass die Daten in was für dich verständliches (ich meine dein Display ^^) umwandelt. Wie willst du dem Ding denn die Bitmap senden? Mit Header oder als Pixelrohdaten? Uns soll es von unten nach oben also letzte Zeile zuerst oder umgekehrt kodiert sein? Soll es das Zeilenende mit 0000 beibehalten und haben die Bilder immer eine feste größe, dass man den Header weglassen könnte? Oder soll ich alternativ einen eigenen Header einfügen mit den Daten: 2-BM(4Byte), Höhe in Pixeln (4Byte), Breite in Pixeln (4Byte) und dann die Rohdaten ohne Zeilenumbruch? Müsstest mir nur sagen, wie du es brauchst, da ich das bisher aber noch nie gemacht hab kann ich nicht versprechen, dass ich es hinbekomme ^^ ich sollte es aber schaffen. Gruß ErgoProxy Edit: In welchem Format liegen denn deine BMPs momentan vor? p.s keine Ahnung welcher Contoller in meinem S65 werkelt ich hab ein LPHxxxx hab den Code aus der Codesammlung verwendet. Problem ist halt nur das die Farben in 5-6-5 Bit codiert sind und nicht wie normal in 255-255-255.
einen Header vor den eigentlichen Rohdaten wäre super...
- Höhe, Breite in Pixel, Farbtiefe (1bbp oder 2bpp, oder 0bpp),
Startwert (wo die Daten beginnen sollen vom eigentlichen Bild), Endwert
(damit man das Bild auch umgekehrt darstellen kann)
Im Normalfall (default) soll das Bild links oben anfangen. Wenn die max.
Größe von 320x240 nicht erreicht werden, kann man 0x00 dranhängen ->
allerdings wäre dass dann durch den Start- und Endwert im Header
hinfällig.
>In welchem Format liegen denn deine BMPs momentan vor
speichere sie immer davor bereits als BMP (16 Graustufen = 4Bit) ab.
Dann ist die eigentliche konvertierung danach nicht so schwierig.
Bernd
Ich werd mal versuchen sowas zu schreiben, allerdings fände ich es lecihter wenn man vorher das Standartformat mit 24bit Farbtiefe verwendet und das dann runterrechnet. du musst ja trotzdem nur 4 Farben verwenden. Z.b. Schwarz, weiß, hell und dunkelblau. Nur dann ist es einfacher weil dann keine Farbtabelle im Header ist den ich dann auswerten muss usw ^^ Gruß ErgoProxy
Hi >Im Normalfall (default) soll das Bild links oben anfangen. Wenn die max. >Größe von 320x240 nicht erreicht werden, kann man 0x00 dranhängen... Bitte beachten: Die Daten werden in Bitmaps von unten nach oben gespeichert. Erstes Datenbyte ist links unten. MfG Spess
>Ich werd mal versuchen sowas zu schreiben, allerdings fände ich es >lecihter wenn man vorher das Standartformat mit 24bit Farbtiefe >verwendet und das dann runterrechnet. du musst ja trotzdem nur 4 Farben >verwenden. Z.b. Schwarz, weiß, hell und dunkelblau. Nur dann ist es >einfacher weil dann keine Farbtabelle im Header ist den ich dann >auswerten muss usw ^^ ok, das hab ich nicht bedacht....
Hi! Sobald du die Daten in einem einfachen Format (also z.B. BMP) vorliegen hast und für jeden Pixel den Helligkeitswert hast, kannst du ganz einfach auf 2bpp konvertieren. Am Besten natürlich im PC (weil die Arbeit dann nur 1x gemacht wird, und der uC die vorbereiteten Daten nur mehr verwenden braucht). Es kann aber auch der uC machen, es könnte aber etwas langsam sein. Aber wie macht man das? Einfach die 2 MSB verwenden. Angenommen du hast 8bpp (also 0..255), dann die 8-2 = 6 LSB entfernen. Also einfach "shr 6" oder in C ">> 6". Das entspricht einer Division durch 2^6 = 64. Und wenn du 0..255 durch 64 dividierst, hast du schön 0..3 (also 2bpp). Bei 4bpp (also 0..15) Graustufen einfach 4-2 = 2 LSB entfernen, also "shr 2". Dann brauchst nur noch das "rundherum", also die Daten für jeden Pixel aus dem Bild mit den tiefen Farben heraus lösen, und nach dem konvertieren sie ins Display zu schreiben. Am Einfachsten "pnmdepth" verwenden (siehe Manpage) aus dem NetPBM Packet. Das Fileformat für die "Portable Grey Maps" ist in der Manpage "pgm(5)" erkärt. Bye Hansi
So bin bald fertig damit ^^ sry das es so lange dauert aber ich hab fast ne Stunde gebraucht um herauszufinden warum einige wenige Bytes nicht so vom Filestream gelesen wurden wie sie sind... Wenn man einen StreamReader verwendet ... und nicht wie eigendlich logisch den §"$)"§IR BinaryReader ^^ mit dem es einwandfrei geht. Nuja jetzt gehts schonmal den Dateiheader fehlerfrei zu lesen. Jetzt muss ich nurnoch die Umwandlung und das Speichern schreiben. Gruß ErgoProxy
So ich habs fast fertig, allerdings schreibt es die Bilder immernoch von der untersten Zeile zur obersten. Header ist momentan 12Bit: Höhe(4bit), Breite(4Bit) und Farbtiefe(4Bit) alle drei little endian. Versuch das noch etwas zu kürzen. Liegt an der Länge von unsigned int, dass die so groß sind. Ich werde jetzt die ganzen Testteile aus dem Program entfernen und dann sollte es laufen... Es scheint sogar mit sehr großen BMPs klarzukommen. Da ich grade aber keine Lust mehr zu hatte, hat es keine graphische Ausgabe, des Ergebnisses, dass müsstest du mal testen. Momentan rechnet er einfach alle Farben zusammen: Alle Farben addiert <255 -> schwarz <255*2 -> dunkelgrau <255*3 -> hellgrau oder größer -> weiß Werde noch 4 Regler dranmachen, mit denen man das verändern kann. Wahrscheinlich lad ich das Programm aber erst morgen mittag hoch ^^ ich hab eigendich grade keine Lust mehr den Rest zu schreiben. Gruß ErgoProxy
bin auch bereits am Schreiben von so einem Programm (bis jetzt wird bitmap eingelesen und die Farbwerte von 24bit-Bitmaps werden in Luminanz umgewandelt) -> 000 - 063 entspricht weiß -> 064 - 127 entspricht hellem Grau -> 128 - 191 entspricht dunklem Grau -> 192 - 255 entspricht Schwarz Bernd
So hier mal wie versprochen die erste Version. Über rückmeldung würde mich mich freuen, besonders ob die Bitmaps stimmen ^^ ich hab es immernur im Hexeditor betrachtet und nicht in real ob alle Pixel an der richtigen stele und richtig konvertiert sind. Header ist gleichgeblieben: Höhe(4bit), Breite(4Bit) und Farbtiefe(4Bit) alle drei little endian. Dann kommen die Pixeldaten auswählbar: Vom Zeilenende nach oben(wie normale Bitmap) oder aber wie auf einem Blatt von oben links nach unten Rechts zeilenweise. Es wird nichts eingefügt, wenn die Zeile zuende ist und das 8-Bit Wort noch nicht voll ist. Außname ist das Ende der Datei hier wird der Überstand geschrieben, der noch zum vollen 8Bit Wort gefeht hat (mit 0en aufgefüllt) Gruß ErgoProxy, der sich jetzt mal an nem Leseprogram versucht, das den kram visuell darstellen kann ^^
werd ich mir gleich mal anschauen - mein Prog läuft mit der 24Bit Variante - muss aber noch diverse hilfsfunktionen etc. rausnehmen etc. Bernd
Hm also ich schau mir den kram grade nochmal an aber entweder ich hab bei der Umwandlung nen Fehler drinn oder in meinem Program zur Darstellung =/ Wär super wenn du mir sagen könntest ob es bei deinem Display geht^^. Dann wüsste ich zumindest, ob das Umwandlungsprogram geht. Gruß ErgoProxy
Wie du die Datei nennst ist dir überlassen, da es ja eine eigenkreation ist. Solange du sie auswertest, wie der header da oben sagt ist es keinerlei Problem. Gruß ErgoProxy
So habs zum laufen bekommen -... mehr oder weniger ... bei dem Program zum umwandeln stimmt etwas nicht mit dem Teil, der die Pixeldaten die Zeilen tauscht. D.h. Wenn man das Bitmap als "Zeilen von unten nach oben" speichert gehts mit dem anderen nicht. Der Reader geht jetzt auch aber die Funktion die ich zum zeichen verwende ist einfach viel zu lahm und CPU lastig, um damit größere Bilder darzustellen. Auch fehlt noch die Möglichkeit die falsch rum gedrehten BMPs richtig herum darzustellen. Werd mal die Probleme beim Konverter beseitigen und dann nochmal hochladen. Gruß ErgoProxy
aber wenn ich sie als xyz.c / .h. / .txt speicher - ist der Inhalt der Datei nicht korrekt.... anbei mal mein kleines (prog) - alles alpha-... Bernd
Willst du die Bilddaten denn als C-Code haben XD musst du doch sagen ^^ momentan macht der daraus einfach einen binären Filestream, der in einer Datei gespeichert wird, die man dann z.b. auf einer Speicherkarte lagern kann oder aber über die serielle Schnittstelle schicken kann. Gruß ErgoProxy Eddit: An was für einem µC hast du das eigendlich hängen, dass du die Bilder in einem Array in den Ram rein baust? Das wird ja schon sehr schnell unglaublich viel Speicher, der da weg ist.
ah ok, das erklärt das natürlich.... ja im Endeffekt soll das Programm ja den C-Code gleich liefern, so dass man ihn nur noch einbetten muss in das eigentliche Programm Edit: Die Bilder befinden sich nicht im RAM, sondern im externen Flash-Memory - als Controller verwend ich grad den LPC214 Bernd
So ich hab bei mir mal alle Fehler beseitigt (die ich gefunden hab ^^) und noch eine nach C-Array exportieren Funktion gebastelt. Allerdings muss man als "zwischenspeicher" über die Binärdatei gehen, die man mit dem normalen Converter erstellt. Der Viewer funktioniert jetzt auch richtig, wenn auch immernoch nur mit kleinen Dateien, da große wohl zuviel Auffwand darstellen. Werd mich wohl irgendwann mit DirektX dafür anfreunden müssen ^.^ Dabei ist noch ein Bild, das ich als Testbild verwendet habe. Erstaunlicherweise erkennt man es immernoch sehr gut als 2Bpp Bild. Habs also mal mit rein getan. Die ".gray" Dateien sind die umgewandelten Bilder, in 2Bpp. Die kann der Viewer lesen. Beim Viewer ist oben n Zoom regler. So ich muss jetzt erstmal n bisi weiterlernen ^^ wenn ich nix fürs Abi mach bringt mich meine Mutter um XD (p.s. Das ist NICHT ERNST gemeint^^) Gruß ErgoProxy
habs mir grad angeschaut... sind noch ein paar Fehler vorhanden.. 1. im C-file steht 2x Höhe (für Höhe als auch Breite) 2. die Werte im C-File passen noch nicht ganz. z.B. wird für Schwarz 254 statt 255 gesetzt. 3. damit man das Bild sofort erkennt, ob es richtig dargestellt wird, nicht alle Zahlen in einer Reihe schreiben, sondern pro Zeile immer nur die Zahlen / Pixel dieser Reihe. -> dann benötigt man gar kein Display etc. um sagen zu können, ob die Umwandlung erfolgreich war oder nicht. Zum Testen ganz einfache Bilder verwenden (wie dieses hier: http://www.cine4home.de/tests/dvd-player/DVI-Vergleich/Graustufen.jpg). Mein Programm funktioniert jetzt für 0, 1 und 2 Graustufen für den Epson controller (mehr Graustufen kann ich leider nicht darstellen auf dem Display). Gruß Bernd
Danke nochmal für das Feedback ^^ zum testen hab ich natürlich einfachere Bilder genommen ... Aber ich wollte halt testen obs auch mit sowas geht. Das mit der Höhe stimmt ^^ da hat sich ein copy/paste Fehler eingeschlichen und die Umwandlung ins c-File hab ich wenn ich ehrlich bin in 10 min geschrieben ^^ hätte auch nicht gedacht das sich da noch ein Fehler einmogelt. Nuja mal sehn was es für einer ist. Gruß ErgoProxy
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.