|
Anzeige
|
Bildformat mit 3Bit Farbtiefe?
Gast
#3091011
Hallo Zusammen Ich wollte mich mal erkundigen, ob jemand ein Bildformat kent, was es auch mit einer 3Bit Farbtiefe gibt? Also sowas wie .bmp mit 16 Farben einfach nur mit 8. Gibt es das überhaupt? Gruss
Gast
#3091015
GIF. GIF arbeitet mit einer Farbpalette und 8-Bit-Indices darin, kann also 256 unterschiedliche Farbwerte aus einer 2^24-Bit-Auswahl anzeigen (oder 255 Farbwerte, wenn Transparenz gewünscht ist). Das ist es also nicht. IFF/ILBM vom Amiga ILBM steht für InterLeavedBitMaps, d.h. Du hast eine Anzahl monochromer Bitmaps, wobei die erste Bitmap immer nur die LSB der resultierenden Farbwerte speichert, die nächste Bitmap Bit 1 des Farbwertes etc etc. Der Amiga konnte bis zu 6 solcher Bitmaps übereinander legen. So funktionierte die Hardware dort. Die heute üblichen "chunky bitmaps", bei der alle Bits eines Farbwertes nebeneinander lieben, gab es in der originalen Hardware nicht. fchk
Gast
#3091053
Hallo Frank Danke für deinen Hinweis. Gibt es unter Windows ein Programm, mit welchem man diese Files (IFF/ILBM) darstellen oder sogar editieren kann? Editieren ist eher nebensächlich aber die Darstellung wäre schon wichtig. Ein Konverter liesse sich vermutlich noch finden.. Gruss Paintshop, Irfanview etc.
Gast
#3091068
Rufus Τ. Firefly schrieb: > GIF arbeitet mit einer Farbpalette und 8-Bit-Indices darin, kann also > 256 unterschiedliche Farbwerte aus einer 2^24-Bit-Auswahl anzeigen (oder > 255 Farbwerte, wenn Transparenz gewünscht ist). > > Das ist es also nicht. Die Farbpalette bei GIF kann 2^N Einträge mit N=1..8 gross sein. Siehe auch http://www.w3.org/Graphics/GIF/spec-gif89a.txt, 18. Logical Screen Descriptor. Die Farbtiefe ist an Offset 11 der GIF Datei kodiert.
Gast
#3091076
Mac schrieb: > Die Farbtiefe ist an Offset 11 der GIF Datei kodiert. Wirklich? Lese ich das falsch oder ist bei Offset 11 eine 00 zu lesen? Gruss
Angehängte Dateien:
Gast
#3091078
Falk Brunner schrieb: > Paintshop, Irfanview etc. Danke für den Hinweis. Wenn es mit dem GIF nicht klappt, greife ich auf das Exoten-Format zurück! Gruss
Gast
#3091089
Verzeihung, das 11-te byte (welches natürlich an Offset 10 liegt). Bei dir F7. Electronics'nStuff schrieb: > Also sowas wie .bmp mit 16 Farben einfach nur mit 8. Laut Spezifikation kann .bmp beliebige "bits per pixel", im BITMAPINFOHEADER steht: http://en.wikipedia.org/wiki/BMP_file_format
Man muss ja keinen "typical value" nehmen. :-) Allerdings sind Zeichenprogramme nicht immer darauf ausgelegt, jeden nur denkbar möglichen Fall aus der Spezifikation zu unterstützen. Außerdem darf man auf keinen Fall sagen, was man eigentlich bezwecken will, denn ansonsten könnten einem die Leute besser helfen. Das darf nicht sein. ;-)
Gast
#3091121
Mark Brandis schrieb: > Laut Spezifikation kann .bmp beliebige "bits per pixel", im > BITMAPINFOHEADER steht: Ich fürchte, der Wikipedia Artikel ist nicht die Spezifikation. MSDN ist da eindeutig: http://msdn.microsoft.com/en-us/library/windows/desktop/dd183376(v=vs.85).aspx Nur die Werte 0,1,4,8,16,24,32 sind erlaubt und die haben dann auch bestimmte, festgelegte Bedeutungen.
Angehängte Dateien:
Gast
#3091123
Ach ja, das Bild oben hat 8 Farben, daher steht im header an Offset 10 eine 0xc2. Das bedeutet, die globale Fabrtabelle ist (0xc2 & 7)+1 = 3 bits = 2^3 Einträge lang.
Gast
#3091136
Mark Brandis schrieb: > Außerdem darf man auf keinen Fall sagen, was man eigentlich bezwecken > will, denn ansonsten könnten einem die Leute besser helfen. Das darf > nicht sein. ;-) Naja, ist eig. kein Geheimnis ich will einfach ein Bild mit 8 Farben darstellen (R, G, B nur on/off). @Mac Danke für deine Hilfe, aber so ganz blicke ich ehrlich gesagt noch nicht durch :S Ich habe dir mal ein Beispielbild hochgeladen. Wenn ich das File im Texteditor öffne, so lese ich an F7 eine "33". Auf deiner verlinkten Homepage (http://www.w3.org/Graphics/GIF/spec-gif89a.txt) finde ich unter Color Resolution den Text (siehe Anhang). Und für mich passt das nicht so richtig zusammen? Also laut dem Text wird die Information so codiert: Genutzte Farben = 2^n-1 Wobei das n die Information ist. Jetzt lese ich da eine 33 wie passt das zusammen? Resp. wie kommst du auf C2? Blicke ehrlich gesagt noch nicht ganz durch. Gruss
Angehängte Dateien:
Mag sein. Dann ist die Implementierung wohl der Standard - ist ja nicht ungewöhnlich bei Microsoft ;) Im Endeffekt hält einen aber niemand davon ab, ein Programm zu schreiben, welches .bmp Dateien mit 3 Bit Farbtiefe lesen/schreiben kann.
Gast
#3091143
Mark Brandis schrieb: > Im Endeffekt hält einen aber niemand davon ab, ein Programm zu > schreiben, welches .bmp Dateien mit 3 Bit Farbtiefe lesen/schreiben > kann. Naja, das wollte ich eigentlich vermeiden, da es einfach zu viel Aufwand ist. Dann nutze von >= 8 möglichen Farben eben nur 8? Willst du das für ein UC oder PC oder Website oder ... Wenn du eh weist, das immer 3 bit ein Pixel sind und immer RGB, wozu braucht man dafür ein spezielles "Dateiformat"?
Gast
#3091153
Mark Brandis schrieb: > Dann nutze von >= 8 möglichen Farben eben nur 8? Der Gedanke kam mir auch schon, das ist aber eigentlich keine Option, da ich ein eindeutiges File will ohne zusätzliche (in diesem Fall unnütze) Information(-en). Einfach ein File, was die Infos etwa so abspeichert: Pixel: 123 Rot: 1 Grün: 0 Blau: 1 Wenn ich nun ein File habe, was mir das Zeug z.B. so abspeichert: Pixel: 123 Rot: 156 Grün: 24 Blau: 255 Dann muss ich erst mal interpretieren, was ich ehrlich gesagt vermeiden will. Gruss
Gast
#3091158
Läubi .. schrieb: > Willst du das für ein UC oder PC oder Website oder ... Wenn du eh weist, > das immer 3 bit ein Pixel sind und immer RGB, wozu braucht man dafür ein > spezielles "Dateiformat"? Naja es handelt sich gewissermassen um eine Matrix, auf welcher das Zeug dann dargestellt werden soll. Diese hat leider nur eine Farbtiefe vno 3 Bit (R, G, und B jeweils ein/aus). Ich will gerne möglichst einfach die Daten für die Matrix gewinnen, deshalb wäre ein File, was mir die Infos schon quasi "lesebereit" abspeichert einfach ideal. Andere Lösungen wären natürlich auch möglich, das war einfach die komfortabelste Lösung, die mir eingefallen ist. Es sollen nämlich nachher einfach die Files übertragen werden und fertig. Wenn ich jetzt z.B. ein JPEG habe, wird das einfach konvertiert in ein GIF, mit meiner Auflösung und meiner Farbtiefe und dann kann ich das einfach so übertragen ohne mir grösser Gedanken machen zu müssen. Gruss
Gast
#3091159
> Einfach ein File, was die Infos etwa so abspeichert: > Pixel: 123 > Rot: 1 > Grün: 0 > Blau: 1 Wozu die ganze Diskussion? Mach es doch einfach so!
Gast
#3091163
Pigpan schrieb: > Wozu die ganze Diskussion? Mach es doch einfach so! Will ich ja :) Aber nicht von Hand! Nimm BMP mit 4Bit/Pixel und Farbpalette und fertig. Das ist Standard.
Gast
#3091170
Falk Brunner schrieb: > Nimm BMP mit 4Bit/Pixel und Farbpalette und fertig. Das ist Standard. Dann muss ich aber die Daten auch wieder irgendwie anpassen. Wäre sicher eine Lösung, wenn ich das mit dem GIF nicht hinkriege.
Gast
#3091191
"ColorResolution" sagt nur, wieviele Bits plus 1 pro Farbe die Originalpalette hatte, bevor das Bild in den GIF Kodierer gegeben wurde (also 8 Bit pro Farbe). SizeOfGlobalColorTable sagt wiederum, dass in der Farbtabelle 2^(7+1)=256 Einträge sind. Electronics'nStuff schrieb: > Falk Brunner schrieb: >> Nimm BMP mit 4Bit/Pixel und Farbpalette und fertig. Das ist Standard. > > Dann muss ich aber die Daten auch wieder irgendwie anpassen. Wäre sicher > eine Lösung, wenn ich das mit dem GIF nicht hinkriege. Das ist im Gif im Grunde auch nicht anders. Es beruht darauf, dass die Pixel ein Verweis in eine Farbpalette sind. Und wenn es dort nur 8 Einträge gibt, dann gibt es eben nur 8 Einträge. Was da damit allerdings hast: Du hast ein GIF-File, bei dem in den Pixeldaten nur Bytes mit Werten von 0 bis 8 vorkommen können, was manche als 'nicht sehr effektiv' ansehen würden. Als die Welt hauptsächlich nur GIF benutzt hat, hat man das so gemacht, weil die LZW Kompression dann die Redundanz rausgeholt hat. Was blieb war aber immer noch das Problem, dass man ein Malprogramm brauchte, dem man gezielt sagen kann, auf wieviele und welche Farben man das Bild beim Speichern reduzieren will.
Gast
#3091216
>>Will ich ja :) >>Aber nicht von Hand! Der Thread dauert schon 2 Stunden. In der Zeit hätte man es von Hand schon locker programmiert.
Gast
#3091283
PittyJ schrieb: > Der Thread dauert schon 2 Stunden. > In der Zeit hätte man es von Hand schon locker programmiert. Wenn man weiss wie, bestimmt. Mac schrieb: > "ColorResolution" sagt nur, wieviele Bits plus 1 pro Farbe die > Originalpalette hatte, bevor das Bild in den GIF Kodierer gegeben > wurde (also 8 Bit pro Farbe). SizeOfGlobalColorTable sagt wiederum, dass > in der Farbtabelle 2^(7+1)=256 Einträge sind. Ach jetzt habe ich das verstanden! Vielen Dank für deine Geduld und guten Erklärungen. Vllt. kannst du das ja mal kurz ausprobieren.. wenn ich das Beispielbild hier anpassen will (also den Eintrag auf Offste 0A ändere auf C2) wie in deinem Beispiel, so ist die Datei nicht mehr lesbar? Dein File kann ich allerdings normal in z.B. Paint betrachten. Kannst du dir vorstellen, woran das liegt? Karl Heinz Buchegger schrieb: > Du hast ein GIF-File, bei dem in den Pixeldaten nur Bytes mit Werten von > 0 bis 8 vorkommen können, was manche als 'nicht sehr effektiv' ansehen > würden. Sehr effektiv ist es wahrscheinlich nicht, aber es entspricht meinen Wünschen :) Gruss
Angehängte Dateien:
Gast
#3091305
> Einfach ein File, was die Infos etwa so abspeichert: > Pixel: 123 > Rot: 1 > Grün: 0 > Blau: 1 So ist es aber nicht. Sondern es sagt "Pixel 128 hat Farbindexwert 5 und dazu steht in der Farbtabelle > Rot: 156 > Grün: 24 > Blau: 255 > Dann muss ich erst mal interpretieren Musst du. Ja und ? 4 bit BMP Format ohne Kompression wäre (zu?) einfach.
Gast
#3091336
Also wenn ich das richtig verstehe..
Wenn ich ein GIF File habe, dann habe ich nachher irgendeine Tabelle in
welcher ich bei meiner Auflösung (256 x 60) 15'360 Werte zwischen 0-7
bekomme? Also etwa so:
Pixel 1: 1
Pixel 2: 5
Pixel 3: 7
Pixel 4: 0
.
.
.
Dagegen steht das 4-Bit BMP File, bei welchem ich pro Pixel Je einen
2-Bit Wert für jede Farbe habe also quasi so:
Pixel 1: ROT: 00
GRUEN: 01
BLAU: 10
Pixel 2: ROT: 10
GRUEN: 00
BLAU: 01
Pixel 3: ROT: 10
GRUEN: 00
BLAU: 10
.
.
.
Bei dieser Variante wird wohl der Wert pro Farbe nie grösser als Binär
10?
Stimmt meine Vorstellung ca.?
Gruss
Electronics'nStuff schrieb: > Will ich ja :) > Aber nicht von Hand! Dann nimm dir den Beitrag "Grafikkonverter Tool für AVR/Mikrocontroller (BMP2C, BMP2ASM, BMP2BASCOM)" zur Hand, der kann dein Bild in einer Menge Formate lesen und das ganze dann auch als Binär mit 3bit/Pixel abspeichern (sollte zumindest, ist jetzt nicht das meistgetestete Feature), oder halt als C Files, wie auch immer du das auf die Matrix bringen willst kann das ein Vorteil sein.
Gast
#3091373
Sehr nützliches Tool wie mir scheint! Danke für den Tipp, das sehe ich mir genauer an.
Gast
#3091392
Ja, das Programm kann eigentlich so ziemlich alles was ich brauche. Vielen Dank, das hilft mir wirklich sehr! Gruss
Gast
#3091474
Also, falls sich jemand in Zukunft dafür interessiert (und einfach der Vollständigkeit halber).. Ich habe jetzt auf eine 4-Bit BMP zurückgegriffen, die sehr einfach aufgebaut ist. Ab dem Offset 118 (0x76) in dem File finden sich die Informationen. Und zwar so: Offset 118 : 1, 2 119 : 2, 3 120 : 4, 5 121 : 5, 6 122 : 7, 8 123 : 9, 10 Pixel: _____________ 1| 2| 3| 4| 5| 6| 7| 8| 9|10| _____________ Wobei die einzelnen Zahlen hier in meinem Beispiel je ein halbes Byte (4-Bit) sind. Die 1 Beispielsweise ist ein Wert zwischen 0 und F oder 0000 und 1111 Das entscheidende: Will man nur 8 Farben benutzen, so ist das MSB dieses halben Bytes komplett irrelevant. Die Farbtabelle sieht dann so aus: Rot: 1001 Grün: 1010 Blau: 1100 Gelb: 1011 Türkis: 1110 Pink: 1101 Schwarz: 0000 Weiss: 1111 Die Codierung ist also wirklich sehr einfach und von daher gut geeignet. Gruss Antwort schreiben |
Anzeige
|
