Hello, Guest the thread was called907 times and contains 34 replays

last post from Retrofan at the

"Optimale" Farbpalette für Retro-Systeme/Games

  • Dies ist eine Art Spin-off vom Neuer Retro-Computer im 8-Bit Style Thread. Ich habe für mich entschieden, den Themenbereich nur noch rein theoretisch/hypothetisch zu betrachten und keine Realisierung jedweder Art in Betracht zu ziehen. Wer aus dem Thread Inspirationen für eigene Hardware oder Emulatoren ziehen will, kann das gerne tun – für mich ist das Nachdenken und Diskutieren über das Thema der eigentlich Zweck – der Weg ist also das Ziel.


    Ein Teilaspekt eines Retro- oder Home-Computers ist seine Farbdarstellung. Üblicherweise lief und läuft das über Farbpaletten, da für eine sog. Echtfarbdarstellung (8 Bit je Kanal) der Speicherplatz fehlt(e). Wenn man heutzutage einen Homecomputer im alten Stil (oder Spiele mit ähnlicher Anmutung) entwickeln will, ist neben dem Speicherplatz aber auch die spezifische Anmutung ein Grund dafür, auf eine reduzierte Farbpalette zu setzen. Da heutzutage nicht wirklich die Hardware die Einschränkungen vorgibt (bzw. man immer eine "Hardware" erfinden kann, die den Wünschen und Anforderungen entspricht), muss man sich Gedanken darüber machen, wie viele Farben denn die Palette enthalten soll – und natürlich im Anschluss, welche.


    Typische Paletten aus den 80ern umfassen 8, 16, 64, 128, 256 oder sogar 4096 Farben. Bei 8 Farben war es üblich, neben schwarz und weiß, einfach rot, grün und blau (RGB) und deren Komplementär-Farben (cyan, gelb und magenta) zu wählen. Schon waren 8 (recht knallige) Farb-Plätze belegt. Bei 16 Farben wurde man dann teils schon "kreativer". Bei CGA und dem ZX Spectrum hat man einfach die ersten 8 Farben in dunkler wiederholt (Sonderbehandlung für manche Farben), beim C64 wurden die zusätzlichen Farben wahrscheinlich eher nach Wirkung, Nützlichkeit und Geschmack ausgewählt.


    RGBI_4bits_palette.png


    Bei mehr als 16 Farben wurden sie grundsätzlich mathematisch generiert und nicht manuell ausgewählt. Dafür kamen entweder die TV-Farbräume von NTSC und PAL (vereinfacht gesagt: YUV) in Betracht oder (später) RGB. Beliebt war es, eine Grundpalette von 16 Farben in 8 Helligkeits-Stufen durchzugehen, so z.B. beim Commodore C16 (TED) und beim Atari VCS.



    Das sind beim TED schön viele Farben (16 x 8 = 128 (- 7 x schwarz)), allerdings ist hier meiner Meinung nach viel Potential verschenkt worden, da (neben 8 Schwarztönen) viele Farben (z.B. im mittleren Grün- und dunklen Blau-Bereich) kaum unterscheidbar sind. Andere Farben können beim Pixeln trotzdem noch fehlen (ich könnte mir das im Braun-Bereich vorstellen). Klar, bei so vielen Farben muss man sie berechnen und kann sie nicht mehr per Hand und Auge "picken". Aber hier hat man das Gefühl, dass 2/3 der Farben nutzlos sind und es zudem fehlende Farben gibt (und das bei 121 Farben). Natürlich kann so eine Palette mehr als die 16-Farben-Palette des C64 – aber sie "unterperformt" gegenüber den theoretischen Möglichkeiten.


    Ein weiteres Manko solcher Paletten: Im Bereich von geringer Sättigung, also bei den hellsten und dunkelsten Farbtönen (nah bei weiß und schwarz) kann unser Auge Farben nur schlecht auseinanderhalten, während das im hochgesättigten Bereich relativ einfach ist. Diese Paletten verteilen aber die Farben gleichmäßig, egal wie gesättigt sie sind. Im ganz hellen und dunklen Bereich würden aber weniger Farben ausreichen – die Farb-Plätze könnte man an anderer Stelle besser nutzen.


    Und eine letzte Schwachstelle: Man findet hier keine Farben zu gut gesättigten, die weniger gesättigt – aber nicht heller oder dunkler – sind.


    Ich weiß natürlich, dass es damals technische Beschränkungen gab und man Farben (beim C64, Apple II oder VCS) nicht einfach mal ganz locker aus der sRGB-Palette aussuchen konnte, sondern teils analog erzeugen musste. Aber ich will ja auch gar nicht unsere Altvorderen dissen, sondern mir Gedanken machen, wie man es HEUTE anders und besser machen könnte. Wir haben heute andere Möglichkeiten – und wenn man heute eine Palette zusammenstellen will, sollte man die meines Erachtens nutzen, um keine Farben zu verschenken und sie möglichst gut im darstellbaren Farbraum zu verteilen.


    Was ist nun gedanklicher Ansatz, den ich hier zeigen und diskutieren möchte?


    Ich stelle mir vor, dass man in einem Farbraum die Farben dreidimensional "auswählt" (nach Vorgaben berechnen lässt). Das kann man natürlich im RGB-Farbraum tun (und wurde auch schon getan, z.B. beim Amstrad CPC oder 64/256-Farb-Paletten) oder man wählt einen Farbraum, der nach menschlichen Farbseh-Fähigkeiten gewichtet ist – das wäre dann (vereinfacht gesagt) Lab (auch L*a*b* oder CIELAB). Der Vorteil bei Lab ist, dass man bei Farben mit gleichen Abstand diesen auch gleich weit empfindet. Bei RGB ist es so, dass z.B. im Grünbereich viele Farben vom menschlichen Auge gar nicht unterschieden werden können, während es bei gleichem Abstand in anderen Farbbereichen möglich ist. Und mir geht es ja darum, mit einer möglichst kleinen Palette möglichst viele Anwendungs-Szenarien abzudecken und nicht doch wieder 5 Töne in der Palette mit Farben zu verschwenden, die niemand wirklich benötigt bzw. kaum unterschieden kann. Je kleiner die Palette ist, desto wichtiger kann dieser Punkt sein.



    Der Lab-Farbraum deckt "alle" Farben ab und ist damit automatisch größer als jeder geräteabhängige Farbraum (wie z.B. sRGB). Er wird üblicherweise für jegliche Farb-Umwandlungen von einem Farbraum in einen anderen als Zwischenstation verwendet, z.B. wenn ein Betriebssystem oder eine Software von sRGB in CMYK oder Adobe RGB umrechnen will. Lab arbeitet mit dem Gegenfarben-Modell, es gibt also zwei Farbachsen: Rot-grün und Blau-gelb. Die Dritte Achse definiert die Helligkeit zwischen weiß und schwarz. Idealisiert bildet der Raum eine art Kugel.


    Aber wie suche ich nun eine bestimmte Anzahl von Farben darin aus? Zum einen möchte ich am Ende Farben haben, die auf (vielen guten) Sichtgeräten darstellbar sind. Da hat man sich ja als Referenz-Standard vor Jahren schon auf sRGB eingeschossen. Viele moderne Monitore und TVs können sRGB (zumindest annähernd) vollständig darstellen. Also würde ich als Basis für Berechnungen im Lab-Farbraum eine kleinere "Kugel-Schicht" wählen, die vollständig innerhalb des sRGB-Farbraums liegt. Und innerhalb dieses Raums sollte man dann versuchen, möglichst "gleichmäßig" eine gewünschte Anzahl von Farben zu definieren. Mein aktueller Ansatz sieht folgendermaßen aus:



    Der hier gezeigte Raum ist ein Lab-Unterfarbraum, der innerhalb der sRGB-Möglichkeiten liegt. Die Nord-Süd-Achse deckt alle Helligkeiten ab und je näher man der Achse kommt, desto weniger Sättigung ist vorhanden. Direkt auf der Achse liegen die Grau-Töne. Ich zeige hier auf der "Nordhalbkugel" eine Möglichkeit, wie man 32 Farben "auswählen" könnte (die schwarzen, runden Punkte zeigen Farben, die Rauten Grautöne an). Jede Halbkugel teile ich in 4 "Schichten" ein (8 für die ganze Kugel), wobei die Extrem-Schichten im Norden und Süden jeweils nur eine Farbe enthalten (Schwarz und weiß). Die weiteren Schichten enthalten unterschiedlich viele Farben in 1 bis 2 "Umlaufbahnen". In der Nähe der "kräftigen Farben" liegen sehr viele Farbpunkte, bei den weniger gesättigten weniger (da ohnehin vom menschlichen Auge schlechter unterscheidbar). Die jeweiligen Anzahlen sind der Grafik zu entnehmen. Auf der Südhalbkugel würde man genauso verfahren, sodass am Ende 64 Farben herauskämen.


    Mit der Anzahl der Schichten, Kreise und Punkte je Kreis habe ich natürlich versucht, auf Computer-typische Werte zu kommen. Insgesamt sind es hier 64 Farben in 8 Helligkeitsstufen und mit 8 Grautönen (inkl. schwarz und weiß). Auf dem Äußeren Kreis mit dem größten Durchmesser liegen 8 Farben im 45°-Abstand, zu den Extremen hin werden es immer weniger.


    Wenn man jetzt experimentieren wollte, was die Verteilung (Schichten-Zahl, Abstände, Anzahl der Kreise je Schicht und Anzahl der Punkte je Kreis) und die Anzahl der Ziel-Farben angeht, müsste man das ganze natürlich "in Software gießen" und sich dann mit unterschiedlichen Parametern Ergebnis-Paletten ausspucken lassen. Wenn jemand Spaß daran haben sollte, fände ich das natürlich klasse.


    Das Ganze ist, wie gesagt, erstmal nur eine Theorie. Sollte sie wirklich zielführend sein, könnte man damit unterschiedlich große Paletten berechnen lassen und diese für zukünftige Retro-Computer (eine Commander X16-Alternative oder was auch immer) oder Pixel-Spiele/Engines im Retro-Style einsetzen.


    List of software palettes

    List of color palettes

    List of 8-bit computer hardware graphics

    List of monochrome and RGB color formats

  • Die ganz kleinen Paletten haben Rücksicht auf die technischen Möglichkeiten genommen, überhaupt Farben aus dem System zu prügeln. Die Beschränkung des Amiga auf 4Bit je Kanal würde ich auch hier einordnen.


    Die größeren Paletten nehmen in meinen Augen mehr Rücksicht auf Speicher. Hier sehe ich die 15/16-Bit-Paletten aus der 486er-Zeit, oder was sonst noch so über die einfach generierten 256 Farben hinausgeht.


    Deine Wunsch-Palette braucht keine technische Rücksicht, eine Beschränkung auf eine Anzahl Farben reicht Dir.

    Für den Zweck würde ich eine reihe von Bildern zusammenkopieren und daraus dann eine Palette in Lab erstellen lassen. Mehr Haut, mehr Himmel, mehr Grauverläufe reintun, weniger Laub und anderes detailliertes Zeug, das Quantisierungsfehler leichter verzeiht.


    Wenn es mathematisch schöner werden soll, dann würde ich die Auswahl der Farbtöne auf die andere Seite des Farbraums spiegeln und L leicht verändern.

  • Für den Zweck würde ich eine reihe von Bildern zusammenkopieren und daraus dann eine Palette in Lab erstellen lassen.

    Ich glaube nicht, dass das funktioniert. Nur weil eine Farbe besonders viel vorkommt, muss man sie noch lange nicht durch besonders viele Farben in der Palette repräsentieren. Und wenn einem das Vorkommen egal ist, kann man auch einfach wieder sagen: "Alle" Farben. Außerdem hängt dann alles davon ab, wie ich die Auswahl der Bilder gewichte. Zu viele Portraits erzeugt zu viele Hauttöne, zu viel Landschaft zu viel grün, zu viel Architektur zu viel grau. Mit solchen Problemen haben heutige Big Data KI-Systeme zu kämpfen.


    Zudem: Das würde für Foto-Konvertierungen gut funktionieren – aber was ist, wenn ich gar keine Fotos konvertieren will? Business-Charts? 8-Bit-Games? Wieviel Business-Folien soll ich in den Sample-Fotostapel untermischen?


    Wie gesagt, ich glaube, nicht zielführend für den Zweck.

  • Ich glaube nicht, dass das funktioniert. Nur weil eine Farbe besonders viel vorkommt, muss man sie noch lange nicht durch besonders viele Farben in der Palette repräsentieren.

    Du hast Lab vorgeschlagen, weil es im Sinne der Wahrnehmung Farben "gerechter" beurteilt.

    Ich habe Elemente vorgeschlagen, die in Fotos am ehesten Probleme mit Banding und Farbverschiebungen haben und daher bevorzugt werden sollten.

    Wie gesagt, ich glaube, nicht zielführend für den Zweck.

    Du willst möglichst viele Szenarien abdecken, möglichst wenig unnütze bzw ähnliche Farben haben - Aber Nachteile bei Fotos sind akzeptabel?

  • Du willst möglichst viele Szenarien abdecken, möglichst wenig unnütze bzw ähnliche Farben haben - Aber Nachteile bei Fotos sind akzeptabel?

    Niemand weiß, ob die Farb-Auswahl für Fotos nachteilig wäre. Das könnten erst Versuche herausfinden. Außerdem sollen solche Paletten stärker den Pixeler, der Stunden und Tage in seine Werke investiert und nach tollen Color-Ramps sucht, unterstützen als den, der in 10 Sekunden ein Foto konvertieren will.


    Natürlich sollen auch Fotos umsetzbar sein (so wie das auf dem C64 besser geht als auf dem Specci) aber die Farben wären nicht vor allem dafür da. Aber gerade auch für Fotos (oder z.B. blasse Hintergründe in Parallax-Games) wären in der zu erwartenden Palette auch wenig-gesättigte Farben im Mittelton-Bereich vorhanden (und sehr dunkle Farben für Übergänge zu schwarz) – ein Tatbestand, der auf wenige andere (kleine) Paletten zutrifft. Außerdem wären in so einer Palette keine RGB-Extremwerte drin, also reines RGB-grün, -blau oder -cyan, die für Fotos kaum hilfreich wären und auch sonst eher für Augenschmerzen sorgen, als dass sie hilfreich wären.


    Wie gesagt, dein Ansatz ist wenig akademisch und wird zu nichts führen – außer zu Paletten, mit denen man vielleicht erträglich gut die Bilder konvertieren kann, die in der Datenbank waren. Und nichts kann verhindern, dass bestimmte Farben unnötig oft vorkommen und andere kaum. Damit sind wir keinen Schritt weiter.


    Aber davon ab: Mein Ansinnen war, über Details meines Konzeptes zu sprechen – also z.B. Verfahren bzgl. der Verteilung der Farben im Farbraum bzw. Gamut – und nicht über komplett andere Ideen und Verfahren. Farbe ist ein weites Feld und es gibt sicherlich dutzende von Ideen und Ansätzen. Nur muss man die nicht alle in einem Thread besprechen.


    Das ist mal wieder typisch Forum: Einer sagt "ich würde gerne über gelb sprechen" und der nächste dann "Och, gelb finde ich doof, rot ist doch viel toller ..." ;)

  • Na, dann will ich Dich mal nicht weiter dabei stören

    Ich fände es besser, wenn du im Rahmen meines Vorschlags und des vorgegebenen Themas mit darüber nachdenken und diskutieren würdest. Ich wollte dich nicht grundsätzlich ruhig stellen – ich möchte nur off-topic Geposte verhindern, welches zu nichts führt – außer weg vom roten Faden.


    Nochmal zu deinem Vorschlag, um zu zeigen, dass ich mich nicht grundsätzlich dagegen sperren will (sondern (neben OT) inhaltliche Gründe habe, ihn für nicht zielführend zu halten):


    Mangels Zeit, eine große Fotodatenbank aufzubauen (meine eigene wäre wahrscheinlich zu Macro-Fotografie-lastig) habe ich einfach mal 4 random Fotos aus unterschiedlichen Bereichen in eines gepackt, damit mir Photoshop daraus eine Palette generiert (indizierte Farbe, Palette lokal, perzeptiv). Das ist ja im Prinzip, was du vorschlägst, nur in sehr klein. Zusammen mit einer sehr kleinen Palette kann man das Problem aber veranschaulichen.



    Jetzt kann man natürlich die Datenbank auf Millionen von Fotos aufblasen und eigene Routinen nach häufig verwendeten Farben suchen lassen. Letztendlich passiert aber das gleiche: Häufig/viel vorkommende Farben werden bevorzugt gewählt, selten genutzte sind unterrepräsentiert (wenn es anders wäre, könnte man sich die Erhebung gleich sparen und einfach gleichmäßig im Farbraum die Farben verteilen). Das bedeutet aber im Umkehrschluss nicht, dass selten vorkommende Farben nicht auch wichtig für andere Zwecke sein können. Egal, wie groß die Probe ist, wird wahrscheinlich in einer kleinen Palette kein richtig schönes Rot gefunden werden (und reine Grautöne nur per Zufall) – außer die Probe enthält ganz viele Bilder von roten Rosen und Blut oder ich wähle die Palette so groß, dass es passt. Trotzdem kann man daraus nicht schließen, dass z.B. rot unwichtiger wäre (z.B. für Warnhinweise) als andere Farben und man in einer Palette, die z.B. auch für Games geeignet sein soll, darauf verzichten kann.


    Und mit einer anderen Fotodatenbank (z.B. einer mit stärkeren Beteiligung asiatischer oder afrikanischer Fotos mit deren Geschmack) werden sicherlich andere "optimale" Farben gefunden. Das ist einfach keine stabile und universelle Basis, sondern eher so ein "wir suchen eine Anzahl zufälliger Farben, die mäßig gesättigt sind".


    Das soll es zum OT aber auch gewesen sein – ich würde gerne über meinen Vorschlag zu einer gleichmäßigen Farbverteilung im Lab-Farbraum reden.

  • Eine Alternative zu meinen relativ frei positionierten Schichten könnte es sein, Tetraeder in der Kugel zu verteilen bzw. eine Kugel damit anzunähern. Die 4 Tetraeder-Ecken sind ja alle gleich weit von einander entfernt und wenn man die Ecken als Paletten-Farben nimmt, müsste man so die Verteilung auch recht gleichmäßig hinbekommen.



    Hier ist ein Tetraeder in einer Kugel (= 4 Farben auf der Hülle) – mit einer größeren Anzahl kleinerer Tetraeder sollte sich der Raum mit Farbpositionen (Ecken) füllen lassen. Zumindest kann so niemand behaupten, die Farben hätten nicht die gleichen Abstände zueinander. Mathe ist aber zu lange her, als dass ich sowas berechnen könnte. ;)

  • Entschuldige bitte, seit C beurteile ich wählerischer, wo sich Diskussionen lohnen.


    Also dass ein Farbmodell auf Gegenfarben basiert heisst nicht, dass deswegen der Farbraum kugelförmig ist. YCbCr basiert ja auch auf Gegenfarben, aber im Prinzip ist das nur ein anderes Koordinaten-System im RGB-Würfel. Zur Ausgabe hast Du ein Gerät mit sRGB ausgewählt, bei ICCView kannst Du Dir schnell eine 3D-Ansicht von sRGB innerhalb von Lab geben lassen. Mit ein bisschen guten Willen kann man darin noch einen zerknautschten RGB-Würfel erkennen. Wobei die L-Achse imho doppelt so lang sein sollte.


    Das macht es nicht einfacher, darin Punkte gleichmäßig zu verteilen und dabei irgendeiner Art nachvollziehbarer Logik ähnlich dem Kugelmodell zu folgen. Ich glaube, ich würde eher zu dicht gepackten Kugeln greifen, eine Achse an L entlanglaufen lassen und ansonsten drehen, scheren und vergrößern, bis sRGB mit der richtigen Anzahl Farben gefüllt ist.


    Für das Kugelmodell fallen mir 2 Wege ein:

    - den sRGB-Blob ausgehend von Mittelgrau verzerren, bis er in eine Kugel passt. Dann ist aber die Eigenschaft von Lab dahin, dass der Abstand der Farben der Wahrnehmung entsprechen soll.

    - Oder man könnte eine kleinere Kugel nehmen, die ganz OK in sRGB reinpasst. Mit doppelt langer L-Achse dürfte das nicht ganz so schlimm aussehen.
    Wenn die Kugel ein bisschen was übersteht, dann kann man das ja wie bei Farbraumumwandlungen üblich behandeln.
    Andererseits wird aber auch was von sRGB über die Kugel drüberstehen.
    Es trifft ausgerechnet die vollen RGB-Farben, das ist sehr schade, denn das verkleinert den Farbraum.
    Du kannst ja alles mögliche Additiv auf dem Monitor mischen, aber nicht den Farbraum verlassen, auch mit Farbmischungen kommen die fehlenden Farben nicht zurück.


    Sagen wir mal, die 8 vollen RGB-Farben müssen rein, und der Rest wird aus der Kugel gewählt.

    Was ich auch noch haben würde: 50% Grau, sowohl optisch als auch im linearen RGB.


    Was ich an Deiner Kugel sehe:
    - Farben lassen sich super mischen, weil sie gleiche Helligkeit haben. Aber viele der Mischungen sind Grau, was eh schon da ist. Vielleicht die Ringe besser auf 5 oder 7 Farben basieren lassen? Die Kugelpackung hat aber glaub ich das gleiche Problem.

    - Mischen tun sich die Farben in linearem RGB. Ich bin nicht sicher, ob man diese Mischungen einfach in Lab berechnen kann, ich denke aber nicht. Die Mischungen werden also nicht so schön symmetrisch in der Kugel landen (und auch nicht so ganz exakt Grau ergeben)

    - Die alten VIC-Farben hatten ja weniger Helligkeiten. Die neue Palette mit mehr Helligkeiten scheint mir nützlicher. Darum würde ich die Grauen Punkte beibehalten, ansonsten die Scheiben aber kippen.


    Da werden dann aber am Ende grad wegen der gleichmäßigen Verteilung viele komische Farben wie Mint oder Lachs drin sein, die man im wahren Leben nicht so sehr braucht.

    Und die 8 Farben aus dem Schnellschuß mit den Fotos sehen besser aus als die 16 des Speccy.

  • Als "moderne", absichtlich reduzierte Palette gibts ja den Pico-8.
    Der hat 16 Farben, mit etwas "Beschiss" wohl deren auch 32.

    Ich finde die Farben zu bombonartig, sehen aus wie aus ner Marketingabteilung für IRGENDWAS. Starbucks mit Apple vielleicht.


    Welchen Farbraum soll denn das imaginäre Retrogerät nutzen/darstellen können?

    Da Retro, wäre ich für YUV. Was nicht heißt, dass man zur Farbfindung nicht Lab nehmen sollte. Nur müsste man da eben im Hinterkopf behalten, dass man nicht den kompletten Lab-Farbraum hernehmen darf für eine "Gleichverteilung".


    Hast Du schon ne Vorstellung über die Farbanzahl?

    Zum von Hand pixeln sind weniger denke ich besser. Und falls die Farben ohne Kachel-Restiktionen angzeigt werden sollen, muss man auch die bpp für die imaginäre Speicherbegrenzung der Bitmap berücksichtigen.


    Soll es etwas CBM-ähnliches (irgendwie "kompatibel") werden oder komplett frei?

    Ich finde die Frage spannend, wie man zu Zeiten (statt) des C128 einen etwas verbesserten und kompatiblen VIC-III hätte machen können. So ne Art Mischung aus VICs, TED und 80-Zeichen-Text-Fähigkeit.

    Beim VIC-I sind die Farben und Helligkeiten eher so, wie sie die Farben "natürlich" haben. Beim VIC-II wurden sie dann mit konstanter Farbamplitude appliziert und festen Helligkeitsstufen. Beim TED sind (mir) aktuell noch die Farbamplutuden unbekannt.

    Warum das alles damals so gemacht wurde, werden heutzutage warscheinlich nichtmal mehr die Macher von damals wissen. Ich hab mir da jetzt schon zwei oder drei (lange) Videos zu angeschaut und was die da teilweise erzählen, stimmt einfach nicht, wenn man sich die Chips und Signale anschaut. Sie waren damals vielleicht eher Projektmanager als die, die sich um die Details gekümmert haben und nach bald 50 Jahren vergisst man schon so einiges.


    Zur Implementierung? Sollte auch bedacht werden, wie man das damals auf dem Chip hätte generieren können?

    Warum die Farben bei den VICs (und sicher auch beim TED) so sind wie sie sind, "sieht" man ja auf dem Chip. Das war einfach eine Frage, wieviel Widerstände bzw. Widerstandsarrays man auf dem Chip platzieren wollte oder konnte.


    Zum Zweck. Soll das Gerät reale Bilder gut anzeigen können oder ist es für Games gedacht?

    Bei ersterem wäre Hoogos statistischer Ansatz wohl nicht ungeeignet, wenn es dann um mit wenige Farben generierte virtuelle Welten geht, vielleicht nicht.


    mfg Tobias

  • Also dass ein Farbmodell auf Gegenfarben basiert heisst nicht, dass deswegen der Farbraum kugelförmig ist.

    Das würde ich so auch nicht behaupten wollen. Es ist nur so, dass Lab in den schematischen Darstellungen öfters als Kugel, RGB als Würfel dargestellt wird. Das hat natürlich meine Vorstellung beeinflusst, bzw. ich sah keinen Grund, von den üblichen Darstellungen abzuweichen.


    Oder man könnte eine kleinere Kugel nehmen, die ganz OK in sRGB reinpasst. Mit doppelt langer L-Achse dürfte das nicht ganz so schlimm aussehen.

    So in der Art hatte ich mir das vorgestellt. Versuchsweise könnte man vielleicht auch erst bei der Berechnung der Schichten diese jeweils an den sRGB-Gamut heranführen. Dann hätte man am Ende keine Kugel, sondern einen verzerrten rundlichen Blob – der aber mehr vom sRGB-Farbraum nutzt. Wobei es gut sein kann, dass das nur das Finden von extrem gesättigten RGB-Farben unterstützt – die man ja gerade in den Ecken des "Würfels" vorfindet.


    Sagen wir mal, die 8 vollen RGB-Farben müssen rein, und der Rest wird aus der Kugel gewählt.

    Nein, die müssen meines Erachtens nicht sein. Ich finde, dem C64 hat es in der Praxis nicht geschadet, dass seine Farben weit weg von RGB-Extremen liegen (auch wenn da Farben rot, grün und blau heißen) – während der CPC mit seinen reinen RGB-Farben vor allem für knallbunte Arcade-Darstellungen geeignet ist, für Fotos hingegen kaum.


    Aber viele der Mischungen sind Grau, was eh schon da ist.

    Bei typischen Retro-Auflösungen kannst du nicht einfach die reinen RGB-Töne mit neutraleren mischen, um Zwischentöne zu erhalten. RGB-Muster ergeben weder auf dem C64 noch auf dem CPC irgendwas wie grau. Auch auf einem modernen Retro-Rechner oder einem Retro-Game würde man wohl eher nicht auf Farbmischungen per Dither setzen, schon alleine, weil heutige Display größer und schärfer darstellen. Ohne künstliche Tricks, wie Scanlines und Blur mischt sich da gar nichts mehr.


    Und die 8 Farben aus dem Schnellschuß mit den Fotos sehen besser aus als die 16 des Speccy.

    Mag sein – aber pixle damit mal ein Feuerwehr-Auto. ;)


    Die neue Palette mit mehr Helligkeiten scheint mir nützlicher.

    Wenn man bei meinem Modell mehr Helligkeiten haben will, könnte man die weniger gesättigten inneren Ringe zwischen die anderen schieben. Dann hätte man statt 8 Helligkeiten schon 12. Oder man teilt die äußeren Ringe von bspw. 8 Farben auf 2x4 mit Versatz auf der Helligkeitsachse auf. Da ließe sich schon was machen.


    Was mir bei identischen Helligkeitswerten zwischen Farben gut gefällt, ist, dass ich Color-Ramps relativ problemlos austauschen kann, indem ich mich um die Helligkeits-Achse drehe. Aus einem Rot-orange-gelb-Verlauf kann ich problemlos einen Blau-hellblau-cyan-Verlauf machen, ohne dass mir der (wie beim C64) in der Helligkeit verrutscht.

  • Als "moderne", absichtlich reduzierte Palette gibts ja den Pico-8. [...] Ich finde die Farben zu bombonartig

    Bei der extrem niedrigen Auflösung des Picos macht es durchaus Sinn, kräftige Farben zu wählen. Mischen per Dither kann man da nichts, Übergänge kann man weitgehend vergessen. Da wird sehr plakativ gearbeitet – Gesicht ist rosa oder gelb, Hose ist blau, Rasen ist grün, fertig. Und bei 16 Farben definiert man die üblicherweise per Hand – da wird nichts berechnet worden sein. Mir geht es aber eher um eine Berechnungs-Vorschrift, mit der man größere optimierte Paletten ab 32 Farben ermitteln können soll. Wobei es natürlich Spaß machen würde, so einen Algorithmus auch auf kleinere Paletten zu hetzen, um seine Wirksamkeit zu testen.


    Welchen Farbraum soll denn das imaginäre Retrogerät nutzen/darstellen können?

    Da Retro, wäre ich für YUV. Was nicht heißt, dass man zur Farbfindung nicht Lab nehmen sollte.

    YUV macht heutzutage wenig Sinn, weil PAL und NTSC quasi ausgestorben sind. Heutige Monitore werden üblicherweise mit RGB-Informationen beschickt, Betriebssysteme arbeiten mit RGB-Farben. Letztendlich muss also ohnehin alles RGB werden. Daher wollte ich in Lab rechnen und in (s)RGB wandeln – da noch einen Zwischenschritt über YUV zu gehen, macht aus meiner Sicht keinen Sinn. Dadurch werden die Farben nicht schöner.


    Hast Du schon ne Vorstellung über die Farbanzahl?

    Irgendwas über 16, weil ich 16 als Grenze für handoptimierte Farbpaletten ansehe. So ab 32 fängt man an, faul zu werden und mit Abwandlungen der ersten 16 zu hantieren.


    Soll es etwas CBM-ähnliches (irgendwie "kompatibel") werden oder komplett frei?

    Komplett frei. Wobei man natürlich von den Altvorderen lernen darf. Die C64-Palette ist z.B. aufgrund ihrer dezent gesättigten Farben recht gut für natürliche Darstellungen geeignet – besser zumindest als Apple II, CPC und Specci. Das ist ein Grund, weswegen ich in berechneten Paletten gerne auch schwach gesättigte Farben haben möchte und nicht nur Knallfarben an den Rändern des RGB-Raums.


    Zur Implementierung? Sollte auch bedacht werden, wie man das damals auf dem Chip hätte generieren können?

    Warum die Farben bei den VICs (und sicher auch beim TED) so sind wie sie sind, "sieht" man ja auf dem Chip. Das war einfach eine Frage, wieviel Widerstände bzw. Widerstandsarrays man auf dem Chip platzieren wollte oder konnte.

    Nein, eine Simulation analoger Schaltungen stelle ich mir nicht vor. Ich sagte ja, dass mir bewusst ist, dass die Leute damals mit ganz anderen Herausforderungen konfrontiert waren als wir heute. Und wenn ich heute glaube, eine bessere Farbpalette generieren zu können, als Entwickler vor 40 Jahren, dann hat das nichts damit zu tun, dass ich ihre Arbeit nicht bewundere. Nur muss ich eben heutzutage nicht das NTSC-Signal "quälen" (Apple II) oder Windungen auf dem Chip anlegen, um Farben zu erzeugen. Ich kann mir einfach welche aus dem sRGB-Potpourri aussuchen. Aber das möchte ich halt möglichst geschickt machen.


    Soll das Gerät reale Bilder gut anzeigen können oder ist es für Games gedacht?

    Der Einsatzzweck wäre am Ehesten das, was man damals™ auf Homecomputern und Konsolen gemacht hat. Also tendenziell Games. Was aber nicht heißen muss, dass man innerhalb von Games nicht auch mal "realistisch aussehende" Bilder sehen möchte – man denke an Strip Poker! ;)


    Mag sein – aber pixle damit mal ein Feuerwehr-Auto

    Bilder

    Ich sagte: Pixeln! Wenn groß Feuerwehr draufsteht, funktioniert es sogar in schwarzweiß ;)

  • Ich hatte mir auch mal Gedanken gemacht, welche 16 Farben man haben muesste, um moeglichst viel abzudecken, und bin dabei zu dem folgenden Ergebnis gekommen:



    Im Grunde sind das alle Primaer- und Komplementaerfarben, also das was der Spectrum oder CGA/EGA auch kann (rechte Spalte), und das ganze nochmal in dunkler, allerdings mit der Ausnahme, dass Dunkelrot zu braun wird und Dunkelgelb zu Orange. Und Weiss zu schwarz. Und es gibt 2 Graustufen.


    Natuerlich sieht die Palette nicht "schoen" aus, d.h. man koennte jetzt davon ausgehend eine Palette zusammenstellen, die etwas weniger gesaettigte Varianten bietet, z.B. sowas:


        


    Oder sogar so:



    Aber das wurde jetzt auch nie bis ins Extrem verfeinert. War nur mal ein Ansatz.


    Letztendlich gehen damit mit Sicherheit so Dinge wie Farbverlaeufe und Co weniger gut, und es ist halt doch noch insgesamt eine recht "bunte" Palette - das kann jetzt Vorteile aber auch Nachteile haben.

  • Ich hatte mir auch mal Gedanken gemacht, welche 16 Farben man haben muesste, um moeglichst viel abzudecken

    Ja, wie gesagt – so arbeitet man üblicherweise bei 16 Farben: Man handoptimiert, was das Zeug hält.


    Mir geht es aber um Paletten, die man nicht mehr händisch zusammensuchen will. Und wo übliche Verfahren (alles nochmal in anderen Helligkeiten) scheitern, weil sie Potential verschenken.

  • Naja das Problem bei "generierten" Paletten ist ja oftmals, dass man da nach irgendwelchen Regeln und Schemen vorgeht. Diese gehen aber vermutlich an der Farbwahrnehmung vorbei und gehen mehr so in technische Richtung, z.B. FF und 7F und Co. Vermutlich muesste man etwas finden was einen typischen Farbkreis oder ein typisches Farbspektrum abdeckt, aber da kenne ich mich zu wenig aus und bin zu wenig mathematisch begabt um da etwas generieren zu koennen.

  • Diese gehen aber vermutlich an der Farbwahrnehmung vorbei und gehen mehr so in technische Richtung, z.B. FF und 7F und Co.

    Die hier angedachte Paletten-Generierungs-Vorschrift eben nicht. Das ist ja der Witz. Bisher wurden generische Paletten sehr einfach erzeugt (wie von mir beschrieben), damit will ich brechen und mich am Sehempfinden orientieren (daher Lab). Das soll über die Verfahren gut unterscheidbare Farben erzeugen, die nützlich anzuwenden sind und nichts verschenken.

  • Ich habe den Eindruck, dass eine verbissene, zwanghaft-theoretisierende Diskussion über eine ideale Palette sich einfach zu weit entfernt von der Grund-Triebfeder, warum wir Retro betreiben: Es soll in erster Linie Spaß machen. Wir wollen kein Curriculum für eine Retro-Universität erstellen.


    Leute, die Spaß daran haben, Retro-Paletten zu erstellen, die tummeln sich beispielsweise hier:

    https://lospec.com/palette-list


    Dort kann man sich 294 Paletten mit 16 Farben ansehen mit Beispiel-Bildern. Die Leute haben das einfach aus Spaß an der Freude gemacht, nehme ich an.