Hallo zusammen, in einem Embedded-Projekt brauche ich für ein LCD 12bit RGB-Daten, die jeweils rechtsbündig in einem 16bit Wort stehen, also 0b0000bbbbggggrrrr. Ich hab jetzt einige Stunden mit Suchen und Testen von Konvertern verbracht, aber nichts passendes gefunden. Ich vermute, dass ich bloß die richtigen Suchbegriffe nicht drauf habe... Hat vielleicht jemand einen Tip für mich?
frage dich erstmal WAS du konvertieren willst wenn du RGB daten hast die nicht 12 bit sind .. dann bau sie um zu 12 bit .. is genau 1 zeile Code ..
Nu ja, ich denke, das ich schon klar geschrieben habe, was ich suche, nämlich einen Konverter für Grafikdaten, der 12bit RGB im beschriebenen Format ausgeben kann. Und ich denke auch, dass ich, wenn ich einen Konverter suche, der das beschriebene Format ausgeben kann, erstmal jedes beliebige Eingabeformat akzeptiere. Bitmap-Format sind da natürlicherweise bevorzugt, aber nicht unbedingt...
weg schrieb: > Nu ja, ich denke, das ich schon klar geschrieben habe, was ich suche, > nämlich einen Konverter für Grafikdaten, der 12bit RGB im beschriebenen > Format ausgeben kann. > > Und ich denke auch, dass ich, wenn ich einen Konverter suche, der das > beschriebene Format ausgeben kann, erstmal jedes beliebige Eingabeformat > akzeptiere. Bitmap-Format sind da natürlicherweise bevorzugt, aber nicht > unbedingt... das einzige was du brauchst sind binäre schiebeoperationen..mehr nicht die frage ist daher nur wieviel bit/kanal dein eingangssignel hat, da dies ggf erst normiert werden muss in deinem beispiel haben die ausgangsdaten pro kanal 4bit.. dh. wenn die eingangsignale jeweils 4 bit haben wäre das die lösung.. 12bitresult = (b << 8) | (g << 4) | r;
> Nu ja, ich denke, das ich schon klar geschrieben habe, was ich suche Na das war jetzt aber ein Scherz, oder ? > Eingabeformat akzeptiere. Bitmap-Format ICH hätte bei dem Konverter an einen 3-Kanal A/D-Wandler-Chip mit 12 bit und 50Msps gedacht, und nicht an SOFTWARE.
Sorry. aber "genau 1 zeile code" und Andis "Lösung" nützen mir gar nichts. Ich kann - und darf - in der Anwendung selber nicht mehr wandeln. Also meine Anzeigedaten müssen 0xb0000bbbbggggrrrr sein, und so liegen sie in einem 32pin Flash-PROM, das fertig programmiert in meine Hardware eingesteckt wird. Das Problem ist nun, dass ich dem Kunden klar sagen können muss, wie er seine Anzeigedaten aufzubereiten hat, so dass ich am wenigsten Arbeit damit habe. Dazu muss ich vor allem irgendwein Tool für die Bitmap-Wandlung nennen können...
Die Frage ist doch von wo kommst Du und wo willst Du hin. Das sehe ich noch nicht. Das Ziel sind wohl ein 16Bit Wort mit den 12Bit RGB informationen in den unteren zwölf Bit. Ok, das kann ich noch verstehen. Das mit dem Flash-PROM, speziell die Information "32-Pin" kann ich nicht zuordnen. Wo Du hinwillst ist zumindest grob verstanden. Aber woher kommst Du, wie genau sehen die Eingangsinformationen aus, möglicherweise sind dies die Ausgänge des Flash-PROMs, aber das kann man hier und jetzt nur raten. Bitte stell' die Frage präziser, dann gibt es auch weniger Antworten in der Form "machs in 1 Zeile Code" oder ähnliches. Schaltplan oder Skizze wär gut. Was für'n LCD? Was für'n PROM ? Was'n für Kunde? Nein, war nur Spaß!
So wie ichs verstanden habe, hat er seine Daten im Prom liegen. Nehmen wir mal an, das Prom hat 16 bit, die Grafikdaten haben aber 12 bit, das heisst, wenn er nicht jeweils 4 Bit/Pixel verschwenden will, muss er sich was einfallen lassen, wie er die übrigen 4 bits zwischenspeichert und aus den jeweils letzten zwei 16 bit words das aktuelle 14 bit word zusammenbastelt hab ichs verständlich geschrieben?
Also ich hab dich so verstanden, dass dein Kunde ein Bild hat, das dann auf dem LCD dargestellt werden soll. Dazu werden die (konvertierten) Daten in eine Datei geschrieben und auf den Flash-PROM geschrieben, der dann in die Zielhardware eingesetz wird. Diese kann nicht verändert werden und liest für jedes Pixel 16 Bit aus, bei denen die letzten 12 Bit die RGB-Werte sein sollen. In dem Fall würde ich zu 24Bit-Bitmap greifen. Dort kannst du mit jeder Programmiersprache recht einfach die 8Bit-Werte der einzelnen Farben je Pixel auslesen, auf jeweils 4Bit kürzen und dann zusammen mit den vier führenden Nullen nacheinander in eine Datei schreiben. Wenn das wirklich die von dir gemeinte Verwendung ist, kann man dir den "Konverter" in ein paar Minuten zusammenstricken.
Er will, dass WIR ihm eine Software nennen, die eine beliebige Bilddatei (vorzugsweise Bitmaps) in einer, nennen wirs mal "12 in 16bit"-Codierung abspeichert. Damit ER das seinem KUNDEN verkaufen kann.
ach zur H*lle, ich glaub ich weiss was er meint. Er braucht ein Grafikprogramm, mit dem er seine Grafiken in irgendein komisches 12 bit format umwandeln kann. also GIMP, Imagemagick, Photoshop.... in der Reihenfolge; da müsste doch ein Programm dabei sein, welches das kann? Da er uns sonst keine Informationen geliefert hat, schein er selbst nicht genau zu wissen, was er eigentlich will
@Später: Das Ziel hast Du richtig verstanden, und mit "32pin PROM" meinte ich so ein bytewide Parallel-Flash bis 512KB ala *29*040. Wo ich herkomme, kann ich dabei nicht konkret sagen, weil ich keine Ahnung habe, womit der Kunde die Bitmaps, die ich anzeigen soll, generiert. Ich weiß nur, dass er keinen Adobe Photoshop hat, und deswegen mein Format nicht direkt erzeugen kann. Es wäre schon nützlich, wenn ich irgendein Konvertierungstool anraten könnte.
Ich glaube, so allmählich kriegen wir es zusammen. Also ich hänge am letzten Ende, und muss zwischen einer Hardware, die 12bit RGB, wie beschrieben, in 16bit Wörtern erwartet, und dem Kunden vermitteln, der die auszugebende Grafik mit einem der üblichen Windows-Tools generiert, die alle kein generisches 12bit RGB-Format kennen. Und jetzt komme mir bitte keiner mit GIMP. Das kann auch nur 8bit-gestaffelte Formate.
Guten Abend, ich verstehe nicht wie Du auf 12bit kommst. Imho sind Farben üblicherweise 3x8 bit kodiert. siehe Farbtabelle:http://www.farb-tabelle.de/de/farbtabelle.htm Also z.B. X11 Farbe / Farbname RGB Hex AliceBlue 240,248,255 F0F8F Dein Kunde wird Dir also seine Bitmap in diesem Format liefern. Wenn das LCD, das Du Deinem Kunden verkaufen willst, ein anderes Farbformat verlangt, so ist das erstmal Dein Problem bzw. ein Problem des LCD Herstellers. Du solltest Dich also an den wenden und ihn fragen wie Du am besten standardmßig formatierte Farben in das Format des Displays wandelst. Grüße Christoph
Tut mir leid, wenn ich mich wirklich so missverständlich ausgedrückt habe... Also, noch einmal, ich habe eine LCD-Hardware, die ihre Farben als 12-in-16bit RGB abbildet wie beschriebem, und ein 29x parallel PROM zum speichern. Und was ich brauche, ist eigentlich nur ein Tool, das irgendeines der üblichen byte-orientierten Bitmapformate in 4-4-4bit RGB umwandelt, das ich direkt ins 29er Flash brennen kann. Ich hatte gehofft, hier wüsste jemand eines, das frei verfügbar ist. Ich meine, einen Adobe Photoshop oder so will ich dazu nicht erst kaufen müssen. Und der Kunde wäre darob auch nicht erfreut. Gruß weg
@weg: beim besten willen, ich schnall's auch nicht. ich habe zwar schon viele male von dir gelesen, was du schlussendlich haben willst, aber ich weiss bis jetzt noch nicht woher und wie die daten daherkommen. ????? -> 0b0000bbbbggggrrrr und solange man nicht weiss, wie die quelle der daten aussieht, kann man keinen konverter bauen (sollte einleuchten).
weg schrieb: > Und was ich brauche, ist eigentlich nur ein Tool, das irgendeines der > üblichen byte-orientierten Bitmapformate in 4-4-4bit RGB umwandelt, das > ich direkt ins 29er Flash brennen kann. > > Ich hatte gehofft, hier wüsste jemand eines, das frei verfügbar ist. Ich > meine, einen Adobe Photoshop oder so will ich dazu nicht erst kaufen > müssen. Und der Kunde wäre darob auch nicht erfreut. a) Bild mit einem beliebigen Converterprogramm in das (binäre) PPM-Format umwandeln. (Gimp, Imagemagick, you name it) b) kleines (z.B. Python-) Skript schreiben, dass das PPM einliest und im gewünschten Rohformat ausgibt. Das ist vielleicht ein 10-Zeiler. c) resultierende Datei ins Flash bringen. Das sollte eigentlich kein Ding sein. Viele Grüße, Simon
Simon Budig schrieb: > b) kleines (z.B. Python-) Skript schreiben, dass das PPM einliest und im > gewünschten Rohformat ausgibt. Das ist vielleicht ein 10-Zeiler. Argh. Manchmal bin ich auch zu doof. Ich hätte einfach ins Bett gehen sollen. Aber was solls:
1 | #!/usr/bin/env python
|
2 | from sys import stdin as i, stdout as o |
3 | n=[ord(c)>>4 for c in list(i.read().split(None,3)[-1][4:])] |
4 | o.write("".join(["%c%c"%(b,(g<<4)|r) for r,g,b in zip(n[::3],n[1::3],n[2::3])])) |
Ok, es gehört eigentlich in einen obfuscated python contest und arbeitet nur mit binären 8-bit/Channel PPMs, aber es hat nur 4 Zeilen! ;-) Verwendung ohne Gewehr, aber mit Ein- und Ausgabe über stdin/stdout. Viele Grüße, Simon
Ich habe vorhin meine Lösung gefunden: eine Delphi-Source namens bmptotxt. Wie der Name andeutet, wird eine .bmp in eine .txt mit den RGB-Daten umgewandelt. Da muss ich jetzt nur noch ein bisschen an der Ausgabe fummeln. Sorry nochmal, dass irgendwie nicht so recht rüberkam, was ich wollte. Gruß weg
Ich hab aus dem bmptotxt jetzt mein BmpToAsm gemacht, dessen Output so aussieht: ; file is ..._24bpp.bmp ; image is 320x240 pixels ; output pixel format is 4:4:4:4 0:B:G:R ; bytes are twice the pixels + 8 .dw 0x5808, 0x0002 ; bytes .dw 0x140, 0x0F0 ; width, height ; R 141 148 114 ... ; G 159 161 117 ... ; B 17 21 21 ... .db 0xA9,0x01,0xA9,0x01,0x77,0x01,... Den kann ich mit ziemlich vielen Assemblern einfach includen, um mir den Flash-Inhalt zusammenzubauen, in der Form: .include "bitmap1.rgb12.asm .include "bitmap2.rgb12.asm Ich gebe den Code gerne weiter. Bei Interesse bitte hier melden. Gru0 weg
Ja. Damit bin ich am freiesten, was meine Möglichkeiten zur einfachen Änderung und Intergration in die Tool-Chain angeht. Gruß weg
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.