font editor 2bpp

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

>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....

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

als welches Format muss ich es denn abspeichern?

Bernd

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

Blöder Dateianhang ^^

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

hier die aktuelle Version (immer noch alpha)

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