Hallo, ich beschäftige mich gerade mit dem Aufbau von Bitmaps. Wenn ich ein Bitmap mit einer Farbtiefe von 8Bit habe, dann bedeutet das doch dass - die Farbtabelle maximal 256 Einträge hat ? - das Bild demnach 256 verschiedene Farben haben kann ? Wenn ich ein solches Bild erstellen möchte geht das mit Gimp ->Bild ->Modus ->Indiziert Dort kann ich das Bild auf 256 Farben begrenzen. Innerhalb des Bildes werden dann nur 256 verschieden Farben benutzt und in der Bitmap Datei wird für jeden Pixel lediglich ein Offset für die jeweilige Farbe in der Farbtabelle gespeichert. Der Einteag selbst in der Farbtabelle ist 4 Byte groß und hat je ein Byte für R, G und B. Demnach könnte jeder Farbwert der Farbtabelle - 24 Bit groß sein ? Wenn ich 16Bit Farben haben möchte (RGB565) - wie kann ich das im Gimp einstellen - wie nennt sich dieser Wert, Farbraum ?? Gruß Mick
Mick schrieb: > Wenn ich ein Bitmap mit einer Farbtiefe von 8Bit habe, dann bedeutet das > doch dass > - die Farbtabelle maximal 256 Einträge hat ? Nein. Die Farbtiefe impliziert nicht das Vorhandensein einer Farbtabelle. Die Bitmap kann z.B. eine Graustufenbitmap sein, bei der der gespeicherte Wert unmittelbar der Helligkeit entspricht; die Bitmap kann aber auch RRGGGBBB-codiert sein (zwei Bit für R und je drei für G und B). Wenn es eine Farbtabelle gibt, dann kann die nur 256 Einträge haben. Das ist korrekt. > - das Bild demnach 256 verschiedene Farben haben kann ? Ja. Die Anzahl der Farben, aus denen diese 256 gleichzeitig darstellbaren ausgesucht werden, kann natürlich deutlich größer sein. Die klassische VGA-Karte beispielsweise verwendete eine Farbtabelle mit 256 Einträgen à 18 Bit (je 6 pro Grundfarbe), damit waren 262144 verschiedene Farben möglich, von denen aber nur 256 gleichzeitig angezeigt werden konnten. BTW: Du plenkst. Keine Leerzeichen vor Satzzeichen.
Ok, danke für die Antworten. Wie kann ich z.B. in Gimp diesen Farbraum einstellen? Ich habe ein Bild welches ich mit 256 Farben abspeichern möchte. Allerdings sollen die Farben selbst 16Bit (RGB565) haben.
jemand schrieb: > Posterisieren? Im Prinzip genau das was ich gesucht habe. Ich möchte das Bild mit einem uC an ein LCD schicken. Dieses möchte die Farbwerte im RGB565 Format haben. Beim Posterisieren stelle ich wahrscheinlich den Wert für alle 3 Farben gleich ein. Ist dieses RGB565 Format ein Exot oder wie könnte ich das Bild mit Gimp erstellen?
Mick schrieb: > Ich möchte das Bild mit einem uC an ein LCD schicken. Dieses möchte die > Farbwerte im RGB565 Format haben. Warum aber dann nur 256 Farben, und warum eine Farbtabelle verwenden? Geht es um den Speicherbedarf, daß Du nicht mit 16 Bit pro Pixel arbeiten willst/kannst?
jemand schrieb: > Wie kommst du dann auf 256 Farben? Ich scheine den Zusammenhang einfach nicht zu verstehen. Mein LCD benötigt die Bilder im RGB565 Format. Das entspricht einem Farbraum von 16Bit. Außerdem möchte der uC Code eine Farbtiefe von 8Bit, also max. 256 verschiedene Farben. Wie kann ich in Gimp ein Bild erstellen was 256 verschiedene Farben mit je 16Bit (RGB565) beinhaltet?
Mick schrieb: > Mein LCD benötigt die Bilder im RGB565 Format. Das entspricht einem > Farbraum von 16Bit. Außerdem möchte der uC Code eine Farbtiefe von 8Bit, > also max. 256 verschiedene Farben Langsam. RGB565 hat eine FarbTIEFE von: 5 Bit für Rot, d.h. 2^5 = 32 Helligkeitsstufen für Rot. 6 Bit für Grün, d.h. 2^6 = 64 Helligkeitsstufen für Grün. 5 Bit für Blau, d.h. 2^5 = 32 Helligkeitsstufen für Blau. Zusammen ergibt das einen FarbRAUM von 16 Bit. Das macht 2^16 = 65536 verschiedene Farben. Eine FarbTIEFE von konsequent 8 Bit wäre dementsprechend RGB888 und somit ein FarbRAUM von 3 x 8 = 24 Bit. Das macht 2^24 = 16.777.216 verschiedene Farben.
jemand schrieb: > Eine FarbTIEFE von konsequent 8 Bit wäre dementsprechend RGB888 und > somit ein FarbRAUM von 3 x 8 = 24 Bit. Das macht 2^24 = 16.777.216 > verschiedene Farben. Ok, danke. Aber wie ist nun der Zusammenhang zu einer Bitmap mit Farbtabelle? Dort ist ja einmal die Rede von einem Bitwert für die Tabelle selbst, also wie groß die Tabelle ist und einem Bitwert für die Farbe. Dort wird immer von z.B. 8Bit (256 Farben gesprochen). Dieser Wert sagt ja im Prinzip nichts über die Farben selbst aus sondern nur über die Anzahl. Und woher weiß ich in einer solchen Bitmap mit Farbtabelle welche Farbtiefe verwendet wird. Bzw. kann diese im Gimp einstellen?
jemand schrieb: > Warum glaubst du eine Bitmap mit Farbtabelle zu benötigen? Gute Frage. Vermutlich braucht er sie nicht. Wenn der vom TO unverstandene C&P-Code (den er uns auch nicht bekannt gemacht hat) Bitmaps (im Sinne von MS-Bitmaps) verarbeitet, dann kann das nicht sein. Zwar unterstützen MS-Bitmaps durchaus 16Bit(565)-RGB, aber nicht "indiziert". Und indiziert wiederum gehen bei MS-Bitmaps zwar 1,4 und 8 Bits für den Index, aber die Farbtabelle muss (sofern überhaupt vorhanden, denn sie ist grundsätzlich optional, auch in allen indizierten Modi) immer im RGB32-Format sein, nix 16Bit im Allgemeinen oder 16Bit(565) im Besonderen. Und weil das alles so ist, wie es ist, wird auch keine übliche Software Bilder in dem vom TO als erforderlich angenommenen Format erstellen können. Ich würde dem TO empfehlen, seine Faulheit einfach mal abzustreifen und zu schauen, was die geklaute Software tatsächlich erwartet. Wenn er das erst einmal weiss, sollte es auch nicht schwerfallen, Gimp dazu zu bringen, genau das erwartete Format zu produzieren. Naja, jedenfalls, wenn es tatsächlich möglich ist im Rahmen der "normalen" Bitmapformate. Denn natürlich kann es sein, dass die unbekannte Software für das Zielsystem irgendwelche proprietäre Erweiterungen des Bitmap-Formats erwartet/verwendet. Das MS-Bitmap-Format hat viel Potential für solche Erweiterungen, selbst MS selber hat es mit solchen undokumentierten Erweiterungen benutzt, z.B. als Teil der AVI-Videos.
jemand schrieb: > Warum glaubst du eine Bitmap mit Farbtabelle zu benötigen? weil das display RGB565 will, er auf dem µC aber nur 8bit pro pixel will. Also braucht er eine Farbtabelle mit 8bit Index und RGB565 Werten. Gibts imho aber nicht. Man könnte auf dem µC von den RGB24 werten aus der Farbtabelle aber auch einfach die unteren 3, respektive 2, bits wegschmeißen.
Vlad T. schrieb: > weil das display RGB565 will, er auf dem µC aber nur 8bit pro pixel > will. Deswegen braucht er aber keine entsprechende Bitmap, sondern nur eine Lookup-Tabelle für die Ausgabe an das Display. Die Bitmap kann einfach geradeaus 8bit enthalten. Was er allerdings nicht gesagt hat, oder ich habe es übersehen, ist ob es immer die gleiche Tabelle ist oder bei jedem Bild anders sein soll. Und ob das Bild auf dem PC korrekt aussehen soll. Georg
c-hater schrieb: > aber die Farbtabelle muss (sofern überhaupt > vorhanden, denn sie ist grundsätzlich optional, auch in allen > indizierten Modi) immer im RGB32-Format sein Sorry, das muss natürlich richtig "RGB24" heißen. COLORTRIPLE...
Mick schrieb: > Wenn ich 16Bit Farben haben möchte (RGB565) > - wie kann ich das im Gimp einstellen > - wie nennt sich dieser Wert, Farbraum ?? Was willst Du genau machen? Die 256 aus den bei RGB565 möglichen Farben auswählen oder das gesamte Bild als RGB565 ohne Palette benutzen? Ich hätte übrigens einfach die 24-bittigen Paletteneinträge genommen und die bei RGB565 nicht benötigten Bits abgeschnitten. Das ist 'ne Fingerübung in Bitschieberei.
:
Bearbeitet durch User
Jim M. schrieb: > Ich hätte übrigens einfach die 24-bittigen Paletteneinträge genommen und > die bei RGB565 nicht benötigten Bits abgeschnitten Ja, ich auch, aber runden wäre besser als abschneiden - aber wahrscheinlich sieht man den Unterschied kaum. Also statt R div 32 besser (R+4) div 32. Georg
Georg schrieb: > Vlad T. schrieb: >> weil das display RGB565 will, er auf dem µC aber nur 8bit pro pixel >> will. > > Deswegen braucht er aber keine entsprechende Bitmap, sondern nur eine > Lookup-Tabelle für die Ausgabe an das Display. Die Bitmap kann einfach > geradeaus 8bit enthalten. Richtig, warum auch ein definiertes Dateiformat benutzen, wenn man selbst eins stricken kann und dann auch noch als Bonus ein Konvertierungstool schreiben darf. Georg schrieb: > Was er allerdings nicht gesagt hat, oder ich habe es übersehen, ist ob > es immer die gleiche Tabelle ist oder bei jedem Bild anders sein soll. > Und ob das Bild auf dem PC korrekt aussehen soll. Diese Probleme würden sich auch erübrigen, wenn man auf ein Standard-Index-Bitmap setzt. und die Farben auf dem µC "skaliert"
Vlad T. schrieb: > Richtig, warum auch ein definiertes Dateiformat benutzen Weil es das was er möchte nicht gibt? Wenn du kein Format konkret benennen kannst, das eine eingebette Lookuptable im RGB565 Format enthält, ist dein Beitrag nicht hilfreich, sondern bloss die übliche Stänkerei. Also Butter bei die Fische. Georg
Georg schrieb: > das eine eingebette Lookuptable im RGB565 Format > enthält, Warum nicht auf die Lookup-Tabelle verzichten, und gleich zwei Byte pro Pixel, ohne Lookup, speichern. Dann kann das Bild auch den vollen Farbumfang des LCDs ausnutzen, ohne künstliche Beschränkung auf 256 vorausgewählte Farben. Braucht natürlich mehr Platz. Ob der Flash-Speicher dafür zu knapp wird, oder ob das Bild z.B. sowieso von einer "unendlich großen" SD-Karte kommt, wissen wir nicht, dass muss der TE selber abwägen.
Angehängte Dateien:
-
RGB888.bmp
900 KB -
RGB565.bmp
600 KB -
RGB565_256colors.bmp
300 KB
Beispielbilder (Kleine Auflösung, damit die BMPs nicht gar so groß werden) RGB888 "original" RGB565 "16-Bit" RGB565_256colors: "indiziert, 256 Farben aus der RGB565-Palette" an den Wolkenrändern z.B. sieht man da schon einen starken Unterschied.
Georg schrieb: > Weil es das was er möchte nicht gibt? Wenn du kein Format konkret > benennen kannst, das eine eingebette Lookuptable im RGB565 Format > enthält, ist dein Beitrag nicht hilfreich, sondern bloss die übliche > Stänkerei. Also Butter bei die Fische. warum? die paar zusätzlichen Bits in der LUT machen den Braten auch nicht fett, wenn man unkomprimierte Bilder verwendet. Dafür hat man die Scherereien mit der Konvertierung nicht. An der Stelle, wo man die Pixeldaten dem Display serviert ist es ein leichtes die unteren Bits wegzuschmeißen (ob nun mit oder ohne vorherigem Runden). Was ist daran Stänkerei? Es gibt nicht viel simpler zu benutzende und verbreitere Formate als bmp.
Vlad T. schrieb: > Georg schrieb: >> Weil es das was er möchte nicht gibt? Wenn du kein Format konkret >> benennen kannst, das eine eingebette Lookuptable im RGB565 Format >> enthält, ist dein Beitrag nicht hilfreich, sondern bloss die übliche >> Stänkerei. Also Butter bei die Fische. > > warum? Weil du das Problem noch nicht begriffen hast. Das Problem ist, dass der OP ein Bildformat sucht, was exakt seine Bedürfnisse abdeckt und so verbreitet ist, dass es mit Standard-Software erstellbar ist. Du hast vorgeschlagen, eben kein solches Format zu verwenden. Damit bist du definitiv zu 100% am Thema vorbei. Ich habe dem TO wenigstens noch erklärt, dass es ein solches Format schlicht nicht gibt, jedenfalls nicht im Rahmen der MS-Bitmaps. Und auch nicht für Jpeg und auch nicht für Gif und auch nicht für Png, das möchte ich hier noch hinzufügen. > die paar zusätzlichen Bits in der LUT machen den Braten auch > nicht fett, wenn man unkomprimierte Bilder verwendet. Dafür hat man die > Scherereien mit der Konvertierung nicht. Das ist überhaupt nicht der Punkt. Natürlich ist wäre es für einen erfahrenen Programmierer überhaupt kein Problem, z.B. die RGB24-Farbtabelle des MS-BMP-Standardformats zur Laufzeit in eine 16Bit-RGB565-Farbtabelle zu überführen. Nur der TO kann das halt nicht, weil er nur Code aus dem Internet kopieren kann und auch das mangels hinreichender Kenntnisse nicht mal gut... > Was ist daran Stänkerei? Es gibt nicht viel simpler zu benutzende und > verbreitere Formate als bmp. Kaum. BMP ist wirklich sehr einfach gestrickt, da geht fast nix auch nur halbwegs verbreitetes drunter, was ich in den letzten 40 Jahren in Hinsicht auf Bildformate so gesehen habe. Und trotz des wirklich einfach Strickmusters ist BMP erstaunlich vielfältig, sogar schon in dem Teil, der offiziell dokumentiert ist, Aber das nur nebenbei. Der springende Punkt ist: Auch KEINES der vielen, angeblich simpler zu benutzenden und verbreiteteren Bildformate liefert genau die nötigen Features für den TO... Und noch ein Punkt: DU weisst das ganz offensichtlich nicht und bist auch zu blöd, es zu ergooglen... Und deswegen laberst du nur nutzlosen Bullshit. Genau darauf wollte Georg dich hinweisen, wobei er natürlich genau in Schwarze gehackt hat, nämlich deine offensichtliche vollständige Unfähigkeit, ein entsprechendes Format einfach nur konkret zu BENENNEN...
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.