"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

Zitat von GoDot

Die „Äquatorialschicht“ kommt aber doch nur einmal vor

Es gibt keine Äquatorschicht, wenn man 8 Schichten nimmt (wie von mir vorgeschlagen und gezeichnet).

Zitat von Hoogo

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.

Zitat von Hoogo

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

Zitat von Hoogo

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.

Zitat von Hoogo

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.

Zitat von Hoogo

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.

Zitat von Hoogo

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.

Zitat von Hoogo

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.

Zitat von Hoogo

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.

Zitat von Hoogo

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.

Zitat von Tobias

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.

Zitat von Tobias

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.

Zitat von Tobias

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.

Zitat von Tobias

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.

Zitat von Tobias

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.

Zitat von Tobias

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!

Zitat von Tobias

Zitat von Retrofan

Mag sein – aber pixle damit mal ein Feuerwehr-Auto

Bilder

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

Zitat von ZeHa

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.

Zitat von ZeHa

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.