Farben nach R,G,B umwandeln in 4-stell. hex-code?

**Moppi** · 10.09.2018, 15:57

Ich guck mal, ob noch ein Fehler drin ist.

Hier mal die Hin-Rechnung:

Code:

r=255, g=102, b=78

r=11111111, g=01100110, b=01001110

muss ergeben: 11111 011001 01001 = 64297

rgb =  ((rot/8)*2048) | ((grün/4)*32) | (blau/8);

rgb     = 11111 000000 00000 
        | 00000 011001 00000 
        | 00000 000000 01001
        --------------------
          11111 011001 01001

        = 64297

und das Ganze zurück:

Code:

rgb = 64297;

rot = (rgb/2048)*8;     =>      11111000   => 248
grün = (rgb&2016)/8;    =>      01100100   => 100
blau = (rgb&31)*8;      =>      01001000   => 72

So weit ich das sehe, ist das richtig so, wenn ich die Bitmuster vergleiche.

Mit den Werten Rot=248, Grün=100 und Blau=72 müsste das Hin und Zurück dann stimmen.
Auf die Originalwerte kann man nicht kommen, weil man 24Bit-Farbe auf 16Bit-Farbe komprimiert, das ist verlustbehaftet - die unteren Bits gehen hier verloren und können nicht rekonstruiert werden. 16Bit-Farben haben einen kleineren Farbraum als 24Bit-Farben.

Allerdings benötigt man für diese Berechnungen:

Code:

rot = (rgb/2048)*8; ... etc.

16 Bit. Die Berechnung muss mit 16 Bit stattfinden und dann am Ende könnte man auf 8 Bit umwandeln, weil im Ergebnis nur noch die unteren 8 Bit der Berechnung belegt sind.

Ich denke Dein Problem liegt hier:

Code:

R = (uint8_t)(color16 / 2048)*8;

sieht für mich so aus, als ob die gesamte Berechnung mit 8 Bit durchgeführt werden soll(!?).

Eventuell so besser (ohne jede Gewähr):

Code:

(uint8_t) R = (color16 / 2048)*8;

Weiß ich aber nicht, weil ich diese sprachspezifischen Sachen hier nicht gut so kenne. Aber ich denke, Du weißt, was ich meine.

Oder mach es so:

Code:

int R = (color16 / 2048)*8;

Die obersten 8 Bit sind nach erfolgter Berechnung sowieso nicht belegt. Normalerweise switcht man auch zwischen den Datentypen nicht so oft hin und her. Das dürfte Zeit kosten, wenn aus 16 Bit-Operanden 8 Bit-Operanden gemacht werden und umgekehrt. Da sind bestimmt unnütze Operationen, die der Compiler für Dich einbaut. Ich würde es bei den Datentypen für die Farben immer bei 16 Bit belassen. Vielleicht kann man das später aus Platzgründen optimieren, aber erst mal sollte man schauen, dass es funktioniert.