spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

du hast also eine ausgangsfarbe und willst die SNES-farbe haben? ein bisschen genauer beschreiben bitte

Du willst 24 Bit auf SNES mappen? Das könnte in der Tat kniffelig werden, denn du bräuchtest dafür eine Tabelle mit 256³ Keys, die auf 256 Values mapped. Dass das technisch zu viel ist ist offensichtlich. Mal ganz davon abgesehen, dass so eine Tabelle irgendwie erstellt werden müsste. Mit reiner Rechen-Vorschrift wird es jedenfalls vermutlich nicht gehen.
Vielleicht habe ich auch falsch verstanden, was genau du vor hast?

Wo genau liegt das Problem einfach die Grafiken nur in den entsprechenden Farben zu machen!?
Ansonsten werfe ich mal die Idee in den Raum deine Farben z.B. in den HSV Farbraum zu transformieren. Dort kann man vielleich einfacher die nächstgelegene Tabellenfarbe bestimmen, evtl. kann man sogar einfach eine LUT definieren...

Zitat von »Schorsch«

Naja von einer LUT hat BlueCobold ja auch schon gesprochen, aber wie auch er schon sagte werden das einfach zu viele Keys.

Naja, so wie ich dich verstanden habe fällt es in RGB schwer die Farben klar zu trennen. Was du willst ist im Prinzip jede beliebige RGB Farbe auf die "näheste" Farbe aus der Palette zu mappen. Das kannst du z.B. machen indem du einfach den euklidischen Abstand deiner Farbe zu allen Palettenfarben berechnest und dann die näheste Palettenfarbe nimmst. Natürlich ist das sehr einfach aber nicht wirklich die unbedingt beste Lösung. Wenn du für alle möglichen inputs einen Eintrag in einer LUT willst dann wird das natürlich ziemlich groß (64MB nur für die LUT) aber wenn man bedenkt dass aktuelle Grafikkarten über 512MB VRAM und mehr verfügen ist dieser einfachste evtl. sogar auch ein gangbarer Weg. Abgesehen davon kannst du den Lookup aufspalten in Farbe->Palettenindex + Palettenindex->Farbe und brauchst dann nurmehr 16MB + 1KB. Mein Vorschlag basiert jedenfalls auf der Vermutung dass du in einem anderen Farbraum (z.B. HSV oder CIE L*a*b) genau das evtl. gerade nicht machen musst. Vielleicht kannst du z.B. in HSV die Farben klarer trennen und dann z.B. eine 3D Texture mit weitaus geringerer Größe als 256³ (bereits 128³ braucht schon nurmehr 8MB bzw. 2MB + 1KB und wäre damit wohl schon sehr praktikabel) und Nearest Neighbour Filtering verwenden um ganze quaderförmige Bereiche des Input Farbraumes auf eine Farbe zu mappen. Ist wie gesagt eben nurmal eine Idee, ka inwiefern das wirklich was bringt. Wenn du dann z.B. auch noch Dithering willst wirds natürlich nochmal um einiges komplexer. Aber machbar ist es sicher.

Zitat von »dot«

Wenn du für alle möglichen inputs einen Eintrag in einer LUT willst dann wird das natürlich ziemlich groß (64MB nur für die LUT) .

Wie kommst du denn auf 64MB?

256*256*256*4 Bytes = 64MB wenn ich mich nicht verrechnet hab. Das ist natürlich schon sehr groß aber technisch machbar ist es definitiv

Und wieso *4?

Weil wir ein RGB Triplet auf einen RGBA Wert mappen wollen!? Natürlich könnte man ein nur RGB Format für die LUT wählen nur wär ich mir nicht so sicher ob die Grafikkarte wegen Alignment etc. nicht so oder so 4 Bytes pro Voxel macht wie bei 2D Texturen normalerweise auch...