Neue RGB Palette für den C64: PALette

Es gibt 116 Antworten in diesem Thema, welches 18.632 mal aufgerufen wurde. Der letzte Beitrag (2. Oktober 2025 um 13:23) ist von Tobias.

  • Pepto über Bitte melde dich an, um diesen Link zu sehen.:

    "[...]While fairly accurate for its time and an improvement to what was available previously, I wasn't ultimately satisfied with how some colors looked, when using higher saturation. I had a hard time getting stable read-outs on the vectorscope originally, as it was very picky about signals not following specs precisely. In retrospect I think, that maybe the hanover bars might have leaked into my measurements, which could explain the slightly phase-shifted nature of the inaccuracy.[...]"
    :nixwiss::oob:

    Auf echten C64 sah das doch garantiert auf jedem Gerät ein wenig anders aus.

    Es gibt (bei den Farbtönen sehr kleine) Unterschiede zwischen gewissen Chip-Revisionen, weil CBM da mal was geändert (Helligkeiten nach 6569R1) bzw. nachgebessert (Farben bei 8565R2) hat. Der Rest sind noch kleinere Unterschiede durch Toleranzen. In wieweit sich PAL und NTSC unterscheiden, konnte ich bisher mangels NTSC-Hardware nicht beleuchten. Technisch gesehen gibt es aber eigentlich keinen Grund für (gewollte) Unterschiede.
    Wenn es (nicht nur in der durch Pepto verzerrten Erinnerung) anders ausgesehen hat oder aussieht, dann durch den TV/Monitor und ganz besonders, wie den jemand eingestellt hat/te. Von Graustufen bis CPC ist das alles drin. :)

    Also zumindest in dem Gif gefällt mir Pepto am besten.

    Es geht hier nicht ums gefallen, sondern was der C64 real ausspuckt. :)


    Viele sagen, mit Pepto "kommen Hauttöne am besten rüber".
    Ich hab das jetzt schon an mehreren neutral eingestellten CRT-Monitoren/TVs gecheckt, das hellrot ist nirgends so blass und bräunlich dreckig. Bilder, die derart 'nach Pepto' gepixelt sind, sehen auf realer Hardware aus wie Sonnenbrand.:tits::emojiSmiley-91:
    Das deckt sich mit den Messungen und Erkenntnissen, die in die PALetten eingeflossen sind.

    Die hohe Sättigung der anderen Paletten fällt mir aber auf.

    Die sind nicht hoch gesättigt, sondern Pepto ist 3D: dark, dirty and dead.

    Schau Dir mal Bilder mit dieser Palette an:

    Bitte melde dich an, um diesen Link zu sehen.

    und halte da PALette nebendran. Dann kommt Dir die PALette wieder so blass vor wie Pepto. Es ist immer eine Frage der Relation.

    Bitte melde dich an, um diesen Link zu sehen. ist in vielen Belangen falsch:

    Helligkeiten: (DARK)

    Es gibt keine magic 32 Luma-Schritte. Die Helligkeiten Y' werden durch Widerstände als Spannungsteiler erzeugt. In der ersten Revision gibt's 5 Helliheitsstufen, danach konnten die Widerstände miteinander kombiniert werden, daher gibt es hier 9 Helligkeiten. Die Pepto Basiswerte treffen diese Werte zwar recht gut, aber nicht exakt.
    Mit der unnötigen und falschen Gammakorrektur wird die Pepto-Palette schlussendlich sehr dunkel. Colodore ist heller, z.B. bei gelb sogar zu hell, erklärt sich aber nicht wirklch zu diesen nicht-stringenten Anpassungen.

    Farbtöne: (DIRTY)
    Es gibt keine 16 magic Chroma-Schritte (vielleicht hatte Pepto bei Atari geschaut, da gibt es wirklich 15 Tortenstücke) . Die Farben werden durch Widerstandspaare im UV-"Diagramm" erzeugt (IQ bei NTSC). Es gibt hier 4 'Leitungen' (sin, -sin, cos, -cos). Die C64-Farben orientieren sich vom Farbton her an den "reinen" Farben, die man vom Bitte melde dich an, um diesen Link zu sehen. (und Bitte melde dich an, um diesen Link zu sehen.) kennt. Nur magenta wurde aus mir bisher unbekannten Gründen leicht anders von CBM festgelegt (Standard: 61°, CBM :53° (= 20° YIQ)). Für orange und braun gibt es keine "Referenz" im Farbbalkenbild.
    Durch die künstliche Aufteilung in gleich große Tortenstücke liegen die meisten Farbtöne bei Pepto sichtbar daneben. Colodore hält an den Tortenstücken fest, verdreht aber den Tortenring zur Einteilung und macht manche Stücke größer, manche kleiner. Ohne zu klären, warum. Weil es einfach keine Torte gibt.:nixwiss:

    Sättigung: (DEAD)
    CBM hat beim VIC-II (und TED) die Farbamplitude bei allen Farben gleich dem Wert des Bitte melde dich an, um diesen Link zu sehen. festgelegt. Bei dem relativ dunklen braun passt dieser YUV-konforme Wert nicht in den sRGB Bitte melde dich an, um diesen Link zu sehen.. Pepto hat daher folgerichtig die Farbamplitude bei braun soweit reduziert, dass man braun für sRGB umrechnen kann. Leider hat er die Farbamplitude bei allen anderen Farben ebenso reduziert, wodurch die Farben extrem blass geraten sind.

    Dann lieber Sonnenbrand...:tits::emojiSmiley-91:

    Jeder darf die Farben an seinem Monitor oder Emulator einstellen, wie er will. Aber das ist dann halt nicht 'Standard'.

  • dass so manch andere alternative Palette noch "falscher" ist, mit Farbtönen, die noch nie ein Mensch zuvor von einem echten C64 gesehen hat und mit vertauschten Helligkeiten, damit auch wirklich keine Farbrampe mehr funktioniert

    Schlimmer geht immer. :)

  • In wieweit sich PAL und NTSC unterscheiden, konnte ich bisher mangels NTSC-Hardware nicht beleuchten. Technisch gesehen gibt es aber eigentlich keinen Grund für (gewollte) Unterschiede.

    Meinst du im VIC oder die Standards? Bei den Standards gibts deutliche Unterschiede, z.B. verwenden beide unterschiedliche Farben für die R/G/B-Primaries.

    10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    20 forj=1to5:printchr$(rnd(1)*16+70);:next
    30 printint(rnd(1)*328)-217

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Bilder, die derart 'nach Pepto' gepixelt sind, sehen auf realer Hardware aus wie Sonnenbrand. :tits: :emojiSmiley-91:

    Das ist eben Teil des Problems. Der Künstler meint, er macht ein Bild für den C64, aber in Wirklichkeit pixelt er für ein fiktives System.

  • Schau Dir mal Bilder mit dieser Palette an:

    Bitte melde dich an, um diesen Link zu sehen.

    SQL-ERROR: INSERT INTO conversion (`status`, `date`, `filename`, `filetype`, `ip`, `host`) VALUES ('0', '2024-02-23 11:32:24', ...
    >> Field 'debug' doesn't have a default value

    Jeder darf die Farben an seinem Monitor oder Emulator einstellen, wie er will

    Meinen Vice habe ich auch entsprechend was runtergeregelt, damit es meinem Geschmack/ meiner Erinnerung entspricht.
    Und natürlich könnte ich mir daraus meine eigenen sRGB-Farben ziehen und für mich als Palette benutzen. Die wäre dann aber wieder mit keinem Konverter oder sonstwas kompatibel, also lasse ich das sein und beschränke mich auf eine Standard-Palette. Von den 3 Bildern im GIF gefällt mir Pepto am besten, weil mir die Gesamt-Sättigung wichtiger als die Feinheiten sind.


    Nur als Erklärung, warum ich gerne Pepto nutze, auch wenn es genauere Paletten gibt.

  • SQL-ERROR: INSERT INTO conversion (`status`, `date`, `filename`, `filetype`, `ip`, `host`) VALUES ('0', '2024-02-23 11:32:24', ...
    >> Field 'debug' doesn't have a default value

    Ja, die Seite scheint wohl nicht mehr zu funktionieren. Schade. Ich hab die Palette von dort gespeichert, im angehängten Bild ganz rechts zu sehen. Welche Variante gefällt Dir dort am besten?

    damit es meinem Geschmack/ meiner Erinnerung entspricht.

    Das sei Dir gegönnt. :)

    Die wäre dann aber wieder mit keinem Konverter oder sonstwas kompatibel

    Zum Glück unterstützen immer mehr Emulatoren und Konverter

    genauere Paletten

    :)


  • Hallo Tobias,

    vielen Dank erstmal für die ganze Arbeit.

    Weil ich an meinen eigenen Tools baue, bin ich gerade interessiert an deiner Palette.

    Nach dem Lesen des Threads frage mich, ob du diese v2 Palette mit all diesen Detail-Korrekturen schon erstellt hast, bzw. ob es ein neues Zip-Archiv dazu gibt, die du hier anhängen könntest.

    Ich habe hier nur das v1 Archiv gefunden.

    Gruß,

    Wanja

  • Hi Wanja,

    diese v2 Palette

    eine v2 gibt es bisher nicht. Nur in Teilen eine v1r, bei der ein kleiner Bug bei der R-Berechnungsformel behoben ist.

    Das findest Du neben einigen Monochrom-Speilereien hier:
    Bitte melde dich an, um diesen Link zu sehen.

    mit all diesen Detail-Korrekturen

    Auf welche Korrekturen beziehst Du Dich?

    meinen eigenen Tools baue

    Darf man fragen, welche das sind und wofür Du die nutzen möchtest? ;)


    vielen Dank erstmal für die ganze Arbeit.

    Gerne. An der Entstehung haben mehrere Personen Anteil. Besodners mathop ist mmer wieder eine hilfreiiche Allzweckwaffe. :)

    MfG Tobias

  • Zitat

    Das findest Du neben einigen Monochrom-Speilereien hier:

    Bitte melde dich an, um diesen Link zu sehen.

    Ja, die Datei habe ich mir schon runter geladen (und eingebaut), danke.

    Zitat

    Auf welche Korrekturen beziehst Du Dich?

    Du hattest bemerkt, dass einerseits der r-Wert etwas daneben lag, ich las etwas über einen Unterschied von Standard 601 für digitale Videosysteme und YCbCr, für YUV bei analogem Video ist BT.470.
    Außerdem, dass du PAL und sRGB gleich behandelt hattest, weswegen es eine kleine Abweichung gab (war das der R-Wert?).

    Zitat
    Bitte melde dich an, um diesen Link zu sehen. meinen eigenen Tools baue

    Darf man fragen, welche das sind und wofür Du die nutzen möchtest?

    Natürlich.
    Ich arbeite schon seit ein paar Jahren an einer Java-Library, um eigene Grafik-Konverter zu schreiben, die eines schönen Tages Open Source werden soll. Noch ist das Projekt privat.


    Im Prinzip will ich schon seit ewig eine Demo programmieren, in der ich ein paar Videos konvertiere und bin über den Video-Konverter abgeschweift und das hat ne Eigendynamik entwickelt. Open Source ist für den Zeitraum nach dem Demo angepeilt, weil ich haufenweise Beispiele aus der Library in dem Demo verwende.

    Es würde jetzt den Thread sprengen, aber im Prinzip habe ich haufenweise Bausteine, um beim Konvertieren verschiedene Paletten (Colodore, Pepto, nun C64 PALette V1), Dithering-Algorithmen (Floyd-Steinberg, Atkinson, Stucki, Jarvis-Judice-Ninke, Burkes, Sierra, verschiedene Ordered-Dither-Muster) und Farbdistanzen nach verschiedenen Metriken in verschiedenen Farbräumen (Euklidische Distanz, bzw. gewichtete Euklidische Distanz im RGB-Farbraum, Hunter LAB, CIE79, CIE94 bzgl. Grafik oder Textilien, CMC l:C 11, CMC L:C 21, CIEDE 2000, DIN99b, DIN99o) zu kombinieren.
    Außerdem habe ich sowas, wie Farbmixer in verschiedenen Farbräumen, z.B. wenn man Interlace-Farben sucht und es gibt ein paar Spielereien, wie die Möglichkeit ein Bild mit dem Median-Cut, Octree oder NeuQuant Algorithmus zu quantisiere, um es auf eine bestimmte Anzahl Farben zu reduzieren. Das kann für einen Grafiker hilfreich sein, wenn er die jeweiligen Farben mit einem Muster füllen will.

    Dazu gibt es halt auch Unterstützung für verschiedenen Grafik-Formate, wie FLI, Hires FLI, Koala, Hires (zweifarbig oder Farbig) Charset-Screen (oder Charset+Screen+Colorram), Multicolor und Hires Bitmaps, Sprite-Extraktion, etc.

    Das Ganze ist eigentlich nicht dafür gedacht, wie Godot, ein Grafikbearbeitung/Konverter zu sein, sondern dafür da, Bausteine zu haben, mit dem man sich eigene Konverter zusammen bastelt kann, z.B. wenn du ein Demo hast und du hast ein Bild, was in ein Koala gewandelt werden soll, aber die Farben Braun und Orange müssen bei Multicolor immer im "01"-Bit sitzen und sollen nie auf eine 10 oder 11 Bitkombination fallen. Oder: du hast eine Sammlung D64 Images und du willst ein Programm schreiben, um alle Amica-Paint Bilder zu extrahieren und als png in ein Verzeichnis zu pumpen. Oder du hast ein Directory voll mit 2x2 charsets und ein Programm schreiben, mit dem du für jeden Charset eine png-Vorschau erstellt, etc.

    Das kann alles schon ziemlich viel, ist aber noch weit weg davor Release-Qualität zu haben.

    Aber ich möchte den Thread hier nicht entgleisen lassen, zumal es noch ein privates Projekt ist, deswegen genug davon.

    Ich habe in den Docs schon einen Link auf diesen Thread gelegt, eine Liste aller Mitwirkenden würde ich auch gerne im Sourcecode hinterlegen, falls das gewünscht ist. Klarnamen und/oder auf CSDB-bekannte Nicknamen wären hilfreich.

    Gruß,

    Wanja

  • Hallo Wanja! (Lange nichts gehört von dir!) :)


    Meinen Namen und auch Bitte melde dich an, um diesen Link zu sehen. kannst du gerne erwähnen, natürlich! Bin gespannt auf dein Projekt!

    Arndt

    GoDot C64 Image Processing
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Hallo Wanja! (Lange nichts gehört von dir!) :)


    Meinen Namen und auch Bitte melde dich an, um diesen Link zu sehen. kannst du gerne erwähnen, natürlich! Bin gespannt auf dein Projekt!

    Arndt

    Hallo Arndt!

    Dass ich deinen Namen in dem Thread gesehen habe, hat mich irgendwie überhaupt nicht überrascht.

    Gut zu wissen, dass es dich noch gibt.

    Gruß,

    -Wanja-

  • Dass ich deinen Namen in dem Thread gesehen habe, hat mich irgendwie überhaupt nicht überrascht.

    Hehe... :smile:

    Bitte melde dich an, um diesen Link zu sehen. wird dich auch interessieren!

    Arndt

    GoDot C64 Image Processing
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Du hattest bemerkt, dass einerseits der r-Wert etwas daneben lag,

    Ja, ein Typo in der Formel:

    Und: tatsächlich kleiner Fehler in R. :sonicht: 1.14 statt 1.114. UPS

    einen Unterschied von Standard 601 für digitale Videosysteme und YCbCr

    Damit kam unseen an, nicht ich. :)
    Digital ist am C64 Signal nichts.
    Für micht ist die Referenz immer ein YUV-Modell, darauf basiert PALette. Die Umrechung in sRGB ist ein notwendiges Übel.
    Für Konverter empfehle ich ausdrücklich, mit den YUV-Werten als Basis zu arbeiten. Diese kann man das jeweils möglichst verlustfrei in den Farbraum wandeln, der für die Konvertierung benutzt werden soll, oder miteinander verrechnen (s.u.).

    Außerdem, dass du PAL und sRGB gleich behandelt hattest, weswegen es eine kleine Abweichung gab (war das der R-Wert?).

    Nein, das mit dem R-Anteil siehe oben: Typo.

    Ich behandle PAL und sRGB hpstl. dahingehend gleich, dass sie nahezu die gleichen Systemgammas haben. In Pepto wurden die Farben wegen einer falschen und unnötigen Gammakorrektur total dunkel berechnet. In Colodore wird das zu hellen Tönen auf einmal wieder überkorrigiert, ohne Erläuterung.

    Wenn man es ganz genau nehmen will, kann man die sRGB-Werte auch mit den in Bereichen minimal abweichenden Gammawerten korrigieren und auch für die Primaries korrigieren. Dahingehend wird von mit erstmal lange nichts kommen, da ich hier noch NTSC C64, die 264er Reihe auf dem Tisch habe, die noch gemessen werden wollen. ;) Wenn Du bei einer 100% korrekten Farbraumumwandlung unterstützen magst gerne. ;)
    Auch den C64 will ich nochmal angehen. Das betrifft dann aber evtl. Verfeinerungen der YUV-Werte, nicht eine genauerer Umrechung in sRGB.

    nicht dafür gedacht, wie Godot, ein Grafikbearbeitung/Konverter zu sein, sondern dafür da, Bausteine zu haben, mit dem man sich eigene Konverter zusammen bastelt kann

    Neue Konvertierer sind immer willkommen, wenn ich mir da aber selbst was basteln muss, bin ich raus. :)

    Mittlerweile bieten schon einige Konvertierer die Unterstützung vom PALette an.

    z.B. wenn man Interlace-Farben sucht

    Das kann man wunderbar mit den Werten in PALette berechnen. Einfach die YUV-Werte miteinander verrechnen. Da die PALette in PAL für odd und even separat vorliegt, kann man wunderbar die PAL-Mix Farben (gleich/ähnlich helle Farbpaare) berechnen, abhängig davon, welche Farbe in welcher Zeile "sitzt". ;)

    Interlace und PAL-Mix Berechungen werden sicher auch mal veröffentlicht. Bisher hab ich das nur intern für mich. Arndt hat seine IFLI-Palette auch so berechnet.

    mfg Tobias