24-Bit zu 16-Farben-Raster

[es_91]

Idee gesucht!

Ich möchte eine Retro-App schreiben, bei der über einen ColorRequester eine Farbe eingegeben wird, deren herrlicher 24-Bit-Wert dann in einen alten, hässlichen Wert aus den 16 MS-DOS-Farben verfrachtet werden soll. Ich habe Spaß dran.

Wie kann man an Soetwas herangehen? Die Farben der Konsole sind zwar logisch, aber nicht gerade mathematisch brauchbar verteilt, genauer gesagt sehen sie so aus:

#0 Schwarz - RGB (0, 0, 0)
#1 Blau - RGB (0, 0, 127)
#2 Grün - RGB (0, 127, 0)
#3 Aqua - RGB (0, 127, 127)
#4 Rot - RGB (127, 0, 0)
#5 Violet - RGB (127, 0, 127)
#6 Gelb - RGB (127, 127, 0)
#7 Weiß - RGB (191, 191, 191)
#8 Grau - RGB (127, 127, 127)
#9 Hellblau - RGB (0, 0, 255)
#10 Hellgrün - RGB (0, 255, 0)
#11 Hell-Aqua - RGB (0, 255, 255)
#12 Hellrot - RGB (255, 0, 0)
#13 Hellviolet - RGB (255, 0, 255)
#14 Hellgelb - RGB (255, 255, 0)
#15 Leuchtweiß - RGB (255, 255, 255)

Wie ihr seht, sind die Farben nicht "proportional" verteilt. Mir fällt einfach keine Formel bzw. kein Weg ein, wie man so eine Umrechnung durchführen könnte!

Ich weiß, die Welt hat schon größere Probleme gesehen, aber Dieses hier finde ich recht interessant.

[CodeCommander]

~ DELETE ~

[Derren]

Wikipedia sagt:
Rot: 5 Bit
Grün: 6 Bit
Blau: 5 Bit

D,h, ich würde einfach einfach die 8 bit jeder Farbe auf 5 bzw 6 bit runter rechnen.

Jetzt kommt aber gleich wieder der Einwand von "professionelle Programmierer benutzen dafür aber vorgefertige, schnelle Algorithmen und statische Bibliotheken. Selber machen ist ein typischer Anfängerfehler"

[es_91]

Mhm, Leute, ich fürchte, wir haben da ein Missverständnis. Ich wollte ja nicht nach 16 Bit konvertieren (das währe ja mathematisch machbar), sondern in die 16 Farben von MS-DOS. Diese haben, so sehe ich es, keine mathematische Formel zur Grundlage, darum entzieht sich mir mittlerweile der Glaube an die Lösbarkeit meines Problems. Diese 16 Farben lassen sich nämlich nicht einfach durch eine Runterrechnung in 4 Bit-Farbe erhalten, sondern liegen "unregelmäßig verstreut" im Farbspektrum, nur das Raster 0-(63-)127-191-255 beachtend, dieses aber nicht gänzlich ausfüllend. (Um das gänzlich auszufüllen, bräuchte man nicht 16, sondern 4*4*4 = 64 Farben, also 6 Bit.)

[CodeCommander]

~ DELETE ~

[es_91]

CodeCommander,

die habe ich doch schon (siehe meinen ersten Post)!

/edit: Gut, ich habe mich ein Bisschen geirrt, die Werte liegen fast alle um eins höher, außer die 255er und die Null-Werte (also Blau - RGB(0, 0, 127) ist in Wirklichkeit RGB(0, 0, 128))

[CodeCommander]

~ DELETE ~

[es_91]

@essen_91

Komm Du mir mal nach Hause!

-----------

Mein Vorhaben: Da sind diese 16 Farben, die seit MS-DOS-Zeiten herumschwirren und offenbar anders aussehen, als wenn man eine 24-Bit-Bilddatei herunterrechnet (auf 4 Bit, dann, für 16 Farben).

Da die so anders als die einfache Herunterrechnung es ergeben würde sind fragte ich mich, wie man einen beliebigen Farbwert (24 Bit) einer möglichst passenden Farbe aus dem MS-DOS-Farbspektrum zuordnen kann.

Ich will ja, wenn der Nutzer eine Farbe auswählt (24 Bit), diese dann im 16-Farben-Modus darstellen. Das hat folgenden Vorteil: man klickt einfach irgendein gelb an und erhält später das "einzige" passende gelb aus der MS-DOS-Farbpalette. Das für meine App, die Präsentationen im Konsolenstil anzeigt. (Wer brauchst sowas? Ich. ^^ )

[es_91]

Oder irre ich mich?

Liegen die 16 MS-DOS-Farben doch genau da, wo sie sein sollten? Einmal schwarz*, einmal grau**, einmal weiß***, einmal leuchtweiß****... einmal jede Farbe und einfache Farbkombi mittelhell*****, einmal jede Farbe und einfache Farbkombi hell******...

*RGB (0, 0, 0)
**RGB (128, 128, 128)
***RGB (192, 192, 192)
****RGB (255, 255, 255)

*****z.B. RGB(128, 128, 0)
******z.B. RGB(255, 255, 0)

...liegen die Farben vielleicht doch gleichmäßig im 4-Bit-Raster?

Ich bin verwirrt.


/e:
Aber tanzt da nicht

RGB (192, 192, 192)

aus der Reihe? Das müsste dann doch nochmal RGB (128, 128, 128) sein, oder?

/e2:
Hm, ich scheine mich wirklich geirrt zu haben. Die 16 MS-DOS-Farben entsprechen ziemlich genau dem, was MS Paint macht, wenn es ein 24-Bit-Bild im 16-Farben-Modus speichert (ich gehe mal davon aus, dass MS Paint die Werte einfach runterrechnet, also [24Bit-Wert] / [2^6=64] = [4Bit-Wert])

Damit dürfte das Problem gelöst sein.

[alter Mann]

man könnte zum Beispiel den Abstand der einzelnen Farbanteile zu den vorgegebenen Farben berechnen und das Minimum nehmen :

Code: Alles auswählen

....
Dim ColourArray.i(15)
....
ColourArray(0) = RGB (0, 0, 0)
ColourArray(1) = RGB (0, 0, 127)
ColourArray(2) = RGB (0, 127, 0)
ColourArray(3) = RGB (0, 127, 127)
ColourArray(4) = RGB (127, 0, 0)
ColourArray(5) = RGB (127, 0, 127)
ColourArray(6) = RGB (127, 127, 0)
ColourArray(7) = RGB (191, 191, 191)
ColourArray(8) = RGB (127, 127, 127)
ColourArray(9) = RGB (0, 0, 255)
ColourArray(10) = RGB (0, 255, 0)
ColourArray(11) = RGB (0, 255, 255)
ColourArray(12) = RGB (255, 0, 0)
ColourArray(13) = RGB (255, 0, 255)
ColourArray(14) = RGB (255, 255, 0)
ColourArray(15) = RGB (255, 255, 255)
....
Procedure NextColour(Colour.i,ColourArray.i(1))
Protected Anz.i = ArraySize(ColourArray())
Protected i.i,Min.i=0
Protected ColMin.q=,R.q,G.q,B.q,ColAbst.q
ColMin=256*256*3
For i=0 To Anz
  R = Red(Colour)-Red(ColourArray(i))
  G = Green(Colour)-Green(ColourArray(i))
  B = Blue(Colour)-Blue(ColourArray(i))
  ColAbst = R*R+G*G+B*B
  If ColAbst<ColMin
    ColMin = ColAbst
    Min = i
  EndIf
Next i
ProcedureReturn Min
EndProcedure