Moin, Im Prinzip kenne ich mich da schon aus, ich habe mein eigenes Tool das mir automatisch BMPs in einem Ordner in RGB8,RGB565 oder RGB24 Image Binärdatei oder uint8_t,uint16_t oder uint32_t ".c" umwandelt.. Bitshifting etc. alles selbst umgesetzt und funktioniert Prima. Ich versuche gerade einen Antialiasing Font als Graustufen-BMP via Java in ein RGB565 umzuwandeln. Da scheint es allerdings ein Genauigkeitsproblem zu geben da die Aliasing Graustufen zu farbigen Schatten oder schwarzen Pixeln werden und eher eckig unschön aussehen. Das müsste aber ein grundlegendes Problem sein von dem man aber nirgendswo lesen kann. Wahrscheinlich reichen die hier möglichen Graustufen im RGB565 nicht ganz für die Darstellung aus. Das müssten 32 mögliche Graustufen im RGB555 sein indem man das 6te Bit im Grünbereich ignoriert. Wie könnte man das am besten umgehen? Ich hätte jetzt gedacht das man halt bei den Pixeln auf Graustufe prüft, intern als RGB555 rechnet und die Graustufen von 256 auf 32 direkt umwandelt. Wo ist mein Denkfehler?
Das ist sicher Display- und Blickwinkel Abhängig. Eventuell hilft es nichtlinear über eine Tabelle umzurechnen.
Philipp K. schrieb: > Wahrscheinlich reichen die hier möglichen Graustufen im RGB565 nicht > ganz für die Darstellung aus. Das müssten 32 mögliche Graustufen im > RGB555 sein indem man das 6te Bit im Grünbereich ignoriert. So ist es. > Wie könnte man das am besten umgehen? Es gibt drei Möglichkeiten: 1) Man toleriert einen leichten Grünstich. Der Trick ist hier, das niederwertigste grüne Bit mit zu nutzen und so wenigstens auf 64 Stufen zu kommen. Nachteil ist halt eben der unweigerlich entstehende leichte Grünstich. 2) Dithering. Der Trick hier ist, Zwischenstufen durch Neben-/Übereinandersetzen von Pixeln der real möglichen Nachbarfarben umzusetzen. Der Nachteil ist hier die verringerte räumliche Auflösung. Je besser man die Zielfarbe erreicht, desto geringer ist die räumliche Auflösung. Ich hänge im Anhang mal ein Beispiel für das Dithering von Farben in einer 2x2-Matrix an (also räumliche Auflösung nur ein Viertel) (8.8.8 Bit Original, 4.4.4 Bit durch dummes Abschneiden, 4.4.4 Bit Dithered und eine Auschnittvergrößerung der geditherten Variante). Natürlich funktioniert das Prinzip genauso für Graustufen. Bloß nicht ganz so gut, weil es davon halt erheblich weniger gibt als es Farben gibt. 3) Kombination aus 1 und 2.
Johannes S. schrieb: > Eventuell hilft es nichtlinear über eine Tabelle umzurechnen. Danke, ich werde das Quellimage wohl auf 32 Farben reduzieren damit müssten die Graustufen schonmal direkt Matchen. c-hater schrieb: > So ist es. Komisch das das nirgends Thema ist. Immerhin werden mit den gängigen Methoden Graustufen falsch konvertiert. Das benötigt theoretisch einen extra Schritt. > Es gibt drei Möglichkeiten: Ich werde da mal schauen.. das ist ja nur ein Antialiasing um eine kleine weiße Schrift auf einem 65k RA8875 TFT anzuzeigen, leider erkennt man jede Macke durch die großen Pixel. Ich werde versuchen ein Antialiasing mit den echten vorhandenen Graustufen im RGB565 umzusetzen. Somit Brauch ich dann nicht mehr umrechnen und die Qualität des Aliasings müsste ausreichen. Danke für die ausführliche Antwort.
PhilippK_59 schrieb: > Komisch das das nirgends Thema ist. Immerhin werden mit den gängigen > Methoden Graustufen falsch konvertiert. Nein. Sie werden halt "bestmöglich" konvertiert. Siehe dazu wieder die Anhänge. Und bedenke: das ist für nur 12 Bit/Pixel, du hast 15. Also einen um den Faktor 2 größeren "monochrom-Farbraum". Wenn man das Grün-LSB hinzunimmt, sogar einen um den Faktor 4 größeren (mit dem Nachteil des leichten Grünstichs). > Das benötigt theoretisch einen > extra Schritt. Nur wenn man sich für einen besseren Algorithmus, wie eben z.B. Dithering entscheidet. Dann muss man halt dithern.
> einen Antialiasing Font als Graustufen-BMP via Java > in ein RGB565 umzuwandeln. Da scheint es allerdings ein > Genauigkeitsproblem zu geben da die Aliasing Graustufen > zu farbigen Schatten oder schwarzen Pixeln werden Sicher, dass dein Font-Renderer nicht im Subpixel-Modus arbeitet?
foobar schrieb: > Sicher, dass dein Font-Renderer nicht im Subpixel-Modus arbeitet? Ich habe schonmal das erste Problem gefunden.. es ist wohl ClearType, das schon gewisse Graustufen vorraussetzt. Ich habe aus Einfachheit einfach die Antialiasing Funktion im "LCD-Font-Converter" genutzt und dann in Graustufen umgewandelt. (Zu einfach gedacht) ich fand halt das ein gute Schrift mit 22x36 Pixeln in Monospace auf einem 64k Display schon hochwertig aussehen müsste, mit einem bisschen Antialiasing in Graustufen sollte das auch machbar sein. c-hater schrieb: > Nein. Sie werden halt "bestmöglich" konvertiert. Ich meine halt nur das man bei Graustufen bessere Annäherungen anstatt dem bitshiften hinbekommt. Auf meinem Display fällt das sofort auf, die Weiße auf Schwarze Schrift sieht irgendwie "dreckig" aus. Welches aber behoben wäre wenn man halt die Graustufen unter sich annähert. Kann mich da auch vertun das es am Ende ein ganz anderes Problem ist. Das Display hat soviel Kristallklaren Kontrast das die Pixel des Antialiasing sofort auffallen. Das gute Dithern.. ja kenne ich noch vom C64 damals :D
Philipp_K59 schrieb: > Ich meine halt nur das man bei Graustufen bessere Annäherungen anstatt > dem bitshiften hinbekommt. Das geht nur durch Tricksen, es sind halt nicht mehr Bits im Targetdevice verfügbar, wo sollen da mehr (echte) Graustufen herkommen? Drei Varianten für das Tricksen habe ich ja schon vorgestellt, eine "weitere" Möglichkeit wäre sowas ähnliches wie das im Thread erwähnte Subpixel-Rendering von Font-Engines. Ist aber im Prinzip auch nur die Erweiterung von Variante 1 meiner Aufzählung. Da wurde ja schon ein leichter Grünstich akzeptiert. Wenn man auch etwas stärkere und andere Farbstiche zuläßt, geht in dieser Richtung noch mehr. Neigt aber stark dazu, deutlich sichtbare bunte Artefakte zu erzeugen, insbesondere natürlich auf Zielgeräten mit geringer Pixeldichte. Ist deshalb wenig empfehlenswert. Aber du kannst es ja gerne ausprobieren. Ich vermute: hast du schon. Denn das, was du im Ursprungsposting dieses Threads beschreibst, hört sich verdächtig stark nach genau dem an, was bei diesem Ansatz rauskommt... > Das gute Dithern.. ja kenne ich noch vom C64 damals Ja, die wußten halt damals auch schon, wie man das Problem am besten umgeht, wenn man weder hohe Farbauflösung noch hohe Pixeldichte hat...
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.