RGB565 Graustufen

[Philipp K. (philipp_k59)]

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?

[Johannes S. (Gast)]

Das ist sicher Display- und Blickwinkel Abhängig. Eventuell hilft es 
nichtlinear über eine Tabelle umzurechnen.

[c-hater (Gast)]

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.

[PhilippK_59 (Gast)]

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.

[c-hater (Gast)]

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.

[foobar (Gast)]

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

[Philipp_K59 (Gast)]

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

[c-hater (Gast)]

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