entfernteste Farbe

Es gibt 56 Antworten in diesem Thema, welches 19.133 mal aufgerufen wurde. Der letzte Beitrag (2. August 2022 um 16:25) ist von muffi.

  • die 16*3 werte sind die 16 c64 farben.

    Sicher? Die Hexwerte sehen eher nach ZeHas Palette aus.

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • die 16*3 werte sind die 16 c64 farben.

    Sicher? Die Hexwerte sehen eher nach ZeHas Palette aus.

    Nee, das sind irgendwelche anderen Farben. Sehen auch von den Werten her teilweise recht knallig aus.

    - neue Spiele für den C64 -
    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.

  • die 16*3 werte sind die 16 c64 farben.

    Sicher? Die Hexwerte sehen eher nach ZeHas Palette aus.

    die 16*3 werte sind die 16 c64 farben.

    Sicher? Die Hexwerte sehen eher nach ZeHas Palette aus.

    Nee, das sind irgendwelche anderen Farben. Sehen auch von den Werten her teilweise recht knallig aus.

    Wie schön ich in den kommentar noch den link kopieren wollte das dann aber vergessen habe.

    das sind die werte von Bitte melde dich an, um diesen Link zu sehen.

    Wie gut oder schlecht das jetzt ist kannst du selbst entscheiden oder doch mit GoDot streiten :D

  • das sind die werte von Bitte melde dich an, um diesen Link zu sehen.

    Ich glaube, das muss mal jemand aktualisieren.

    Bitte melde dich an, um diesen Link zu sehen. | Meine Lieblings-Themen im Forum64:

    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. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.

  • Und irgendwo in Bitte melde dich an, um diesen Link zu sehen. wurden die C64-Farben nochmal (besser als von Pepto) durchgemessen und meines Wissens auch u.a. in Lab festgehalten.

    Nicht in Lab, sondern in YUV. ;)

    Und hier findet man das Ergebnis zusammengefasst:
    Bitte melde dich an, um diesen Link zu sehen.

    mfg Tobias

  • Nicht in Lab, sondern in YUV.

    Wenigstens vor dem "Abschneiden" durch den sRGB-Farbraum.

    Bitte melde dich an, um diesen Link zu sehen. | Meine Lieblings-Themen im Forum64:

    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. | Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.

  • Nicht in Lab, sondern in YUV.

    Wenigstens vor dem "Abschneiden" durch den sRGB-Farbraum.

    Ja, das war der Sinn.
    In YUV, der "natürlichen" Form. Danach kann man das in den gewünschten Farbraum umrechnnen für z.B. Näherungen/Konvertierungen usw.

    mfg Tobias

  • Für mich ist das C64 "rot" durch die (theoretisch) konstant festgelegten Farbamplituden und der niedrigen Helligkeit gefühlt am weitesten von einem knalligen RGB-rot weg. Zumindest ist das ne C64 Schwäche beim Konvertieren von Fotos.

    Wenn Du mit Deiner Farbe Farbabweichungen darstellen möchtest, brauchst Du ja Abstufungen. Dafür nimmt man oft einfach Graustufen.

    MfG Tobias

  • Ich verwende für Markierungen in C64-Screens meistens Orange oder das extremste RGB-Grün – die hauen immer sofort raus.

    Ja, Quietschgelb und Quietschgrün verwende ich auch in meinem Editor fürs Selektieren von Bereichen.

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

  • Falls da jemand mit spielen wollo, so hab ich das lustige blau ermittelt:

    Wäre wohl auch mein Ansatz, alle Farben zu durchlaufen und die Abstände zu allen C64-Farben zu prüfen.

    Wenn nur 1 Farbe gesucht wird, dann ist das imho die optimale Lösung.

    So, jetzt wird das ein bisschen akademisch, weitab der Praxis...


    Erster Ansatz: Die gefundene Farbe der Palette hinzufügen und das Ganze wiederholen. Das Hinzufügen zur Palette würde verhindern, dass als nächstes #2655CC oder Bitte melde dich an, um diesen Link zu sehen.... oder andere benachbarte Farben gefunden werden.
    Problem: Die Räume für die nächsten Farben werden unnötig schnell kleiner, jede weitere Farbe kommt den echten Farben näher. Eine Suche nach mehreren Farben gleichzeitig könnte bessere Lösungen liefern.

    Illustration dieses Algo in 2D:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Die 3 grünen Punkte sind die echten C64-Farben.

    Rot ist der erste Treffer, die Farbe, die am weitesten von den 3 Grünen entfernt ist.

    Blau ist am weitesten von den 4 vorigen Punkten entfernt,

    Magenta am weitesten von allen 5 vorigen.

    Bitte melde dich an, um diesen Anhang zu sehen.

    Die beiden gelben Punkte wären in einer Palette der schlechtesten 3 Farben besser, aber die werden so nicht gefunden.

    ------------------------------

    Bitte melde dich an, um diesen Link zu sehen. illustriert das schön in 3D. Alle gefundenen Punkte halten schön einen Mindestabstand voneinander ein.

    Mit den Links hier oder bei Bitte melde dich an, um diesen Link zu sehen. finden sich auch Algorithmen. Die scheinen aber auf zufälliges Verschieben und viele Versuche zu setzen. Die Ergebnisse sehen wüst aus, aber andererseits dürfte es nicht zu schwer sein, denen feste 16 Kugeln zu geben oder auf krumme Grenzen von Lab zu testen.

  • ich hab das mal gemacht, relativ simpel, ich betrachte den farbraum als ein linearen Raum mit den Achsen R G B je von 0 bis 255. Jetzt iteriere ich Durch alle Farben im Raum und bestimme die kürzeste Distanz zu allen der 16 C64 farben nach Bitte melde dich an, um diesen Link zu sehen..
    Anschließend nehme ich die Farbe mit der längsten kürzesten Länge, das wäre #2755CC

    Ich hab wegen der einfachen Vergleichbarkeit auch die Palette aus dem Wiki genommen.

    Ich hab allerdings 27ffcc statt 2755cc bekommen und mehrmals nachgerechnet: Die nächsten Farben sind Türkis, Grün, Hellblau mit Abstand 135.. Das überrascht mich, weil ja grad der Türkis/Hellgrün/Hellblau-Bereich eigentlich in der 64er-Palette gut abgedeckt ist.

    Bitte melde dich an, um diesen Anhang zu sehen.

  • Ich hab allerdings 27ffcc statt 2755cc bekommen und mehrmals nachgerechnet: Die nächsten Farben sind Türkis, Grün, Hellblau mit Abstand 135.. Das überrascht mich, weil ja grad der Türkis/Hellgrün/Hellblau-Bereich eigentlich in der 64er-Palette gut abgedeckt ist.

    Und psychovisuell hat der gemeine Mensch eher wenig Auflösung im blauen Bereich, oder? Also Lab u.ä. dürften wirklich besser geeignet für solche Spielereien sein als RGB, wie weiter oben erwähnt. =)

  • Ich hab allerdings 27ffcc statt 2755cc bekommen und mehrmals nachgerechnet: Die nächsten Farben sind Türkis, Grün, Hellblau mit Abstand 135.. Das überrascht mich, weil ja grad der Türkis/Hellgrün/Hellblau-Bereich eigentlich in der 64er-Palette gut abgedeckt ist.

    Und psychovisuell hat der gemeine Mensch eher wenig Auflösung im blauen Bereich, oder? Also Lab u.ä. dürften wirklich besser geeignet für solche Spielereien sein als RGB, wie weiter oben erwähnt. =)

    Falls es beim Herumexperimentieren hilft: Das "ColourTrans"-Modul von RISC OS hat das gute alte RGB-Modell benutzt und einfach die Differenzen bei R, G und B unterschiedlich gewichtet, wenn die Entfernung berechnet wurde.

    RISC OS 2 benutzte als Gewichte für R, G und B die Werte 2, 3 und 1.

    Bei RISC OS 3 wurde das zu 2, 4 und 1 geändert.

    Soll heißen:

    Farbdistanz = 3 * Rotdifferenz² + 4 * Gründifferenz² + 1 * Blaudifferenz²

    ...ist sicher nen Versuch wert.

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Und psychovisuell hat der gemeine Mensch eher wenig Auflösung im blauen Bereich, oder? Also Lab u.ä. dürften wirklich besser geeignet für solche Spielereien sein als RGB, wie weiter oben erwähnt.

    Im Moment ist eher die Frage, wo der Bug ist. Schorsch und ich benutzen die gleichen Farben und die gleiche Rechnung. Schorsch hat ein schmutziges Blau gefunden, und in der Gegend hätte ich grob abgeschätzt die schlechteste Farbe vermutet.

    Meine erste Abschätzung war:

    - 6 mittlere Farben RGB+CMY.

    - Dunkle Farben Braun, Orange => TürkisBlau hat da eine Lücke

    - Helle Farben Hellrot, Hellgrün, Hellblau => Eher gleichmäßig belegt

    - C64-Rot ist zu dunkel, Grün und Türkis zu hell => Lässt Platz in Dunkelblaugrün und nimmt Platz in HellTürkisGrün weg.

    Die un-C64igste Farbe hätte ich daher im DunkelGrünBlauTürkis vermutet, und ausgerechnet im HellTürkisGrün finde ich sie? Aber ich hab's jetzt Xmal nachgerechnet, das passt.

    Nächster Nachbar von Schorschs Farbe (39/85/204) ist Hellblau (0/136/255) mit ~82. Wobei es nur einen Nachbarn mit diesem Abstand gibt, was sehr für einen Bug dort spricht.

    RISC OS 2 benutzte als Gewichte für R, G und B die Werte 2, 3 und 1.

    Bei RISC OS 3 wurde das zu 2, 4 und 1 geändert.

    Das passt ja ganz OK zu den Werten, mit denen man das Y von YCrCb berechnet, nur mit kleinen Integern. Die Rotationen, die die in ihrer Matrix haben, dürften ja für die Abstandsberechnung keine Rolle spielen.

    Riscos hat mir 4Bit Input gerechnet? Imho müssen die doch trotzdem in 16Bit rechnen? Warum dann SO kleine Ints?

    ------------------------------------------------

    Ursprünglich ging es mir nicht so sehr um die optische Wahrnehmung als entfernteste Farbe, eher nur um eine rechnerisch schlechte Farbe in sRGB, aber es ist ein interessantes Thema geworden.

  • Bei RISC OS 3 wurde das zu 2, 4 und 1 geändert.


    Soll heißen:

    Farbdistanz = 3 * Rotdifferenz² + 4 * Gründifferenz² + 1 * Blaudifferenz²

    Gemeint ist natürlich

    Farbdistanz = 2 * Rotdifferenz² + 4 * Gründifferenz² + 1 * Blaudifferenz²

    ...war spät gestern. :whistling:

    Riscos hat mir 4Bit Input gerechnet?

    Nein, mit acht Bit. Die Video-Hardware hatte damals nur vier Bit pro Kanal, aber bei der API hat jemand mitgedacht und deshalb war die von Anfang an auf acht Bit pro Kanal ausgelegt.

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Im Moment ist eher die Frage, wo der Bug ist. Schorsch und ich benutzen die gleichen Farben und die gleiche Rechnung. Schorsch hat ein schmutziges Blau gefunden, und in der Gegend hätte ich grob abgeschätzt die schlechteste Farbe vermutet.

    Magst du dein Code in dem Raum werfen?
    Ich würd's gerne vergleichen, da muss ja was anderes passieren.

  • Nein, mit acht Bit. Die Video-Hardware hatte damals nur vier Bit pro Kanal, aber bei der API hat jemand mitgedacht und deshalb war die von Anfang an auf acht Bit pro Kanal ausgelegt.

    Dann müssen die imho intern eh mit 24 Bit rechnen, und dann hätten die die Faktoren noch was hochdrehen können.

    Magst du dein Code in dem Raum werfen?
    Ich würd's gerne vergleichen, da muss ja was anderes passieren.

    Ist C#, Konsolen-Projekt

    Der Output:

  • Die Farbtöne des C64 sind nach den NTSC/PAL gewählt und entsprechend relativ gleichmäßig (keine konstanten Winkel!) verteilt. Sie sind eben blasser und teilweise dunkler. Letzteres besonders nach der Umstellung von 5 auf 9 Helligkeiten.

    Ausnahmen bei der Verteilung der Farbtöne sind orange und braun, die zusätzlich zwischen gelb und rot liegen.

    Daher dürfte eine entfernte Farbe tendenziell eher gesättigt und hell sein.

    Ich hab hier nur mal die "reinen RGB" Farben gegenübergestellt. Ohne jetzt was zu rechnen, würde ich von diesen "reinen" Farben das RGB-rot auswählen.

    mfg Tobias

  • Nein, mit acht Bit. Die Video-Hardware hatte damals nur vier Bit pro Kanal, aber bei der API hat jemand mitgedacht und deshalb war die von Anfang an auf acht Bit pro Kanal ausgelegt.

    Dann müssen die imho intern eh mit 24 Bit rechnen, und dann hätten die die Faktoren noch was hochdrehen können.

    Magst du dein Code in dem Raum werfen?
    Ich würd's gerne vergleichen, da muss ja was anderes passieren.

    Ist C#, Konsolen-Projekt

    Der Output:

    Ich bin jetzt kein C# Muttersprachler, aber zumindest deine Berechnung ist identisch mit meiner, jetzt frag ich mich wo die unstimmigkeit her kommt (und wessen die richtige ist) das wurmt mich jetzt echt, da werd ich mir am Wochenende nochmal ein wenig zeit für nehmen