Übersetzte Zusammenfassung und Kommentar
Ich beziehe mich in diesem Text auf eine Untersuchung von Philip “Pepto” Timmermann zu der Erzeugung der C64-Farben durch den VIC-II Chip, veröffentlicht (im Internet) um 1999 (der Artikel ist nicht datiert, aber ein angehängter Brief, der sich auf den Artikel bezieht und die Erkenntnisse weitgehend bestätigt, ist vom 27.9.1999). Der Text wird als Preview bezeichnet und sollte ab 2001 weitergeführt werden, was aber wohl bis heute (Anfang 2010) nicht geschehen ist.
Link zum Originaltext: www.pepto.de/projects/colorvic
Los geht’s:
Der Artikel beschreibt als erstes die Problematik, die C64-Farben auf heutigen Computersystemen korrekt zu simulieren und dass es eine Vielzahl von verschiedenen Farbpaletten gibt, die allesamt zu keinen optimalen Ergebnissen kommen. Timmermann erklärt, dass die Farbpalette 16 Farben in 9 Helligkeiten (late VIC-II luma) umfasst und dass sie im YUV-Farbraum (PAL-TV-Norm) erzeugt wird.
Die Helligkeit: Wenn man die mittels Oszilloskop gemessenen Helligkeiten (Y) der Farben in 8 Bit darstellen möchte, dann erhält man folgende Werte: 0, 64, 80, 96, 120, 128, 159, 191, 255.
Die Farbe: Timmermann hat das Chroma-Signal (U/V) mit einem Vektorskope gemessen und festgestellt, dass alle C64-Farben auf einem perfekten Kreis um den Kreuzungspunkt von U und V liegen und somit exakt die selbe Sättigung aufweisen. Deshalb gibt es keine Differenzen zwischen den U- und V-Koordinaten, sondern man hat nur einen Wert. Die Winkel sind perfekt teilbar durch 22,5° (ein Viertel von 90°).
Nun kennt man Y, U und V und kann sie in den RGB-Farbraum konvertieren, nur muss man herausfinden, welche Sättigung maximal möglich ist, ohne ungültige RGB-Farben zu bekommen. Da Braun die “Peak”-Farbe der C64-Palette ist (ihre Umrechnung zu RGB erzeugt als erstes einen negativen Blau-Wert), gibt sie den maximalen Sättigungsgrad vor. Mittels Näherungsverfahren kommt Timmermann auf einen Wert von ca. 34. Man sollte aber bedenken, dass Monitore/TVs Clipping betreiben (also zu hohe Werte abschneiden), wenn Werte “out of Gammut”, also außerhalb der Darstellungsmöglichkeiten liegen.
Timmermann geht davon aus, dass die von ihm berechneten, normalisierten Farben, denen entsprechen, die man auf einem Monitor/TV sieht, dessen Farbe, Helligkeit und Kontrast in Normalstellung stehen (bei Commodore-Monitoren haben die Regler einen Einrastpunkt für die “Normal”-Stellung). Wenn man eine höher gesättigte Palette erhalten möchte, soll man seine Berechnungen mit größeren Werten (vor der Gamma-Korrektur) durchführen. Er erwähnt noch, dass der damals neue C64-Emulator “CCS64 2.0 Beta” die Werte für Kontrast, Helligkeit, Sättigung und Gamma “on the fly” mittels seiner Berechnungen verändern kann.
Timmermann berechnet nun die YUV-Farbwerte der C64-Farben. Ich mache das hier beispielhaft für die Farbe rot:
Winkel = 5 x (360° : 16) | Y = 10 x (255 : 32) | U = Peak x Cos(Winkel) | V = Peak x Sin(Winkel)
Winkel = 112,5° | Y = 79,6875 | U = -13,01434923670814368 | V = +31,41941843272073796
Danach brechnet er nach folgender Formel die RGB-Farben:
R = Y + 1,140 x V | G = Y – 0,396 x U – 0,581 x V | B = Y + 2,029 x U
R = 116 | G = 67 | B = 53
Erst nach den Umrechnungen zu RGB und allen Korrekturen/Manipulationen soll die Gamma-Korrektur erfolgen. Timmermann ist sich bzgl. der von ihm verwendeten Gamma-Werte nicht ganz sicher. Er definiert den Gamma-Wert vom C64-Monitor als 2,5 (obwohl er für PAL laut ihm offiziell bei 2,8 liegt) und den Gamma-Wert des Zielsystems bei 2,2 (PC-Norm, Macs verwendeten bislang 1,8). Die Gamma-Korrektur erfolgt mit der Formel: R, G und B-Wert jeweils hoch 1,136 (2,5 : 2,2) und danach das Ergebnis auf 8-Bit-Werte proportional strecken.
Zum Schluss zeigt Timmermann einige Bilder, die zum Vergleich jeweils mit seiner errechneten und der original CCS64-Farbpalette erzeugt wurden und listet die Hex-Werte der 16 C64-Farben für die Nutzung in eigenen Programmen auf:
000000 | FFFFFF | 68372B | 70A4B2 | 6F3D86 | 588D43 | 352879 | B8C76F
6F4F25 | 433900 | 9A6759 | 444444 | 6C6C6C | 9AD284 | 6C5EB5 | 959595
Abgeschlossen wird die Veröffentlichung durch einen Brief von Bob Yannes (Mitentwickler des VIC-II), der kurz über die Unterschiede von PAL (YUV) und NTSC (YIQ) eingeht und weitgehend die Erkenntnisse von Timmermann bestätigt, mit der Ausnahme, dass sie die Auswahl der Farben nicht wirklich so wissenschaftlich betrieben hätten, sondern, nachdem sie die Möglichkeit hatten, beliebige Farben zu erzeugen, ganz einfach den Geschmack hätten entscheiden lassen. Um Platz auf dem Chip zu sparen, hätten sie bei einigen Farben dann einfach die auf dem Farbkreis gegenüberliegende gewählt, da sie sich so bestimmte Werte teilen konnten. Zum Schluss erwähnt Yannes noch, dass es durchaus Toleranzen gab, was die Farbdarstellung einzelner Rechner anbelangte.
Kommentar
Was die Messwert-Erfassung von Timmermann angeht, gibt es wohl kaum Widerspruch. Auch seine Erkenntnisse und Berechnungen möchten wir nicht anzweifeln.
Jetzt habe ich aber das Problem, dass die so definierten Farben weder in den Emus (ohne Verwendung einer PAL-Emulation) noch auf den Screenshots im Netz so aussehen, wie ich sie von meinen C64-Modellen zuhause kenne. Im Zusammenspiel der 16 Farben zueinander stimmen die Pepto-Farben besser als jede optisch erzeugte Palette aber sie wirken insgesamt zu wenig gesättigt, zu schmutzig, zu dunkel.
Nun wollte ich feststellen, ob es sich bei mir um einen Einzelfall handelt oder ob bei anderen Personen und Geräten auch die Farben stark abweichen.
ALeX und ich haben daraufhin einen Test gestartet, der ermitteln soll, wie Personen die C64-Farben wahrnehmen und ihnen hilft, möglichst ähnliche Farben auf dem Zielsystem zu finden. Hierzu wird ein Testbild auf dem C64 gezeigt und das gleiche Bild in einem Java-Programm auf dem Zielsystem. in diesem Programm kann man nun mittels verschiedener Farbregler jede Farbe so einstellen, dass sie (vor allem im Vergleich zu den anderen Farben) der Darstellung auf dem C64 entspricht.
Näheres dazu kann man in zwei weiteren Blog-Einträgen lesen: Zum einen gibt es eine allgemeine Einführung zu unserer Projektidee und zum anderen gibt es eine detailierte Anleitung, wie man am Projekt teilnimmt und seine eigene Farbtabelle bestimmt.
Also erstmal ein paar Anmerkungen zu Historie der Pepto-Palette. Ich war ja der erste, der damals ne einigermaßen brauchbare Palette entwickelte, einfach nur weil ich sowohl die von c64s als auch von ccs64 (VICE gab’s damals noch nicht) als grausam empfunden habe. Das war so pi mal daumen, langjährige Erfanrungswerte und Vergleich mit meinem c64 neben dem PC monitor – also recht ähnlich, wie ihr das macht mit euren Community Colors. Worauf ich auch geachtet habe ist, dass bei meiner Palette nach umwandlung in Graustufen (also nicht einfach sättigung runterdrehen, obwohl das wahrscheinlich rückblickend unter kenntnis des YUV-Farbmodells, von dem ich damals noch gar nix wusste richtiger gewesen wäre) die farbpaare denselben Grauwert hatten.
Heute find ich die Palette total übersättigt, aber heute hab ich ein ganz anderes Betriebssystem, nen anderen Monitor und ne andere Grafikkarte.
Aber zurück zur Pepto-Geschichte: Pepto war damals oft im IRC und hat mich mal angelabert, weil er wusste, dass ich auch sehr an einer korrekten Palette interessiert bin. Ich weiss nicht mehr genau wie der Kontakt dann zustandekam, aber Homecat (Andi B.), ein Commodore-Freund hier in der Nähe, kannte einen mit nem Vektorskop. Der hat dann alle 16 Farben gemessen und ich hab das dann digitalisiert und dem Pepto geschickt, der das dann ausgewertet und in RGB umgewandelt hat.
Die Pepto-Palette ist nicht perfekt (ich persönlich fand das hellgrün immer viel zu gelb!), aber wie ihr schon schreibt ist das gute daran, dass die Verhältnisse der Farben zueinander korrekt sind. Dabei darf man auch nicht vergessen, dass wir an 1084 & Co auch meistens nie die Regler in den Originalstellungen belassen haben… Helligkeit und oftmals Sättigung waren meistens etwas verstärkt!
Zu eurem Testbild-Java-Applet: v.l.n.r.: Joe/WD: Courtesy of Soviet Turn disk pic, DeeKay/Crest: Irgendeine Hajime Sorayama Robotertussi, Giana Sisters und Valsary/Elysium: Snout.
Hab ich jetzt was gewonnen? ;-D Und warum habt ihr mein schönes SHIF-Hiresbild so in die Multicolorpixel-Breite gezogen? <:-)
Hi DeeKay, schön dass du dich auf diese Seite verirrt hast. Warum ich dein Bild verzerrt habe? Weil ich es mit doppelt breiten Pixeln für unser FLI-Testbild benötigte und es da weniger auf die Ästhetik ankommt als vielmehr darum, möglichst gängige Farbverläufe darzustellen, damit man man die Farbabstände besser beurteilen und einstellen kann. Ich hoffe, du verzeihst mir, dass ich für unser Testbild ein wenig geräubert habe.
jein, speziell beim konvertieren ist es sinnvoller das originalbild (möglichst in echtzeit mit vorschau) in punkto kontrast/sättigung zu tweaken und dann für die eigentliche konvertierung die palette von pepto zu nehmen. (man will ja das das konvertierte bild möglichst bei allen nacher gut aussieht). und wenn man “falschfarben” mappen will (also farben so mappen will das sie nicht originalgetreu, sondern “am besten” für das jeweilige bild, aussehen) muss man eh für jedes bild eine eigene palette machen.
Ich denke, dass viele Wege nach Rom führen. Natürlich muss man grundsätzlich das zu konvertierende Bild vernünftig aussuchen und evtl. auch optimieren (Kontrast etc.). Man kann sich aber viel Bastelei am Original sparen, wenn der Konverter “vieles richtig” macht. Mit “tweaken” des Bildes Unzulänglichkeiten der Konvertierung auszugleichen, halte ich für wenig sinnvoll. Zum Konvertieren der Farben verwende ich lieber eine Palette, die dem gesehen Bild auf einer üblichen C64/Monitor-Kombination ähnlich ist, als die technische Pepto-Palette, die ja auch wieder (z.B. in VICE PAL-Simulation) getweakt wird, um eine möglichst (zum Original) ähnliche Darstellung hinzubekommen.