Schönen RGB Fader selber Programmieren

  • Ja hatte ich auch gedacht vielleicht 100 "schöne" Farben und dann Random(100) welche es wird. Denn einfach alle 3 Farbwerte Random, dann kommt häufig ne blöde Farbe bei raus, z.B. wenn alle Werte ziemlich gleich groß sind.
    Oder man müsste sich einen besseren Algorithmus ausdenken, z.B. das die zwei weiteren Zufallszahlen nur maximal 1/3 von der ersten sein können oder sowas.
    Das mit dem halben Kosinusverlauf weiß ich gerade noch nicht so ganz wie ich das umsetzten soll ?( die Geschwindigkeit des Timers mit einer Kosinusfunktion ändern? Oder was ganz anderes?


    wenn man einfach R, G und B per Zufall erzeugt, da meist irgendwelche Pastelltöne rauskommen..


    genau das habe ich auch festgestellt ;)


    mfg

  • Naja, wenn Du von Farbe A nach Farbe B fadest, dann macht man das anders, da wird nicht einfach irgendwas rauf- oder runtergezählt, sondern Zwischenwerte berechnet...


    sagen wir mal, Du fadest in 256 Schritten (S) von A nach B, dann ist der momentane Wert (also der der Helligkeit, sowohl für R wie auch B und G):


    M = A + (B-A) * S / 256


    Beispiel: Du fadest von 80 zu 150, bist gerade in der Mitte (S = 128 ) dann ist der momentane Wert:


    M = 80 + (150-80) * 128 / 256 = 115 - also genau der Mittelwert zwischen 80 und 150...


    Du zählst also pro Timer-Schritt den Wert S ein mal weiter, von 1 bis 256 - dann hast Du die Farbe B erreicht, die daraufhin zu A wird, und es gibt eine neue Farbe B...


    für das "Cosinus-Faden" o.ä. wird dann eben S nicht einfach stur hochgezählt, sondern wiederum über ne Tabelle/Funktion erzeugt - S ist also nicht 1, 2, 3, 4, 5, 6, usw. sondern z.B. eben 1, 2, 4, 8, ...


    EDIT: da kannst Du dann nicht mit Integer-Werten rechnen, sondern brauchst Variabeln mit Vorzeichen - weil B ja auch kleiner als A sein kann.. oder Du unterscheidest diesen Fall, das mache ich bei meiner Fade-Routine in asm für µC so - wenn B größer A, dann rechne ich wie oben, wenn B kleiner A, dann:


    M = A - (A - B) * S / 256

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

    2 Mal editiert, zuletzt von Pesi ()

  • Würde ich dann aber nicht auch ungerade Werte bekommen? Weil wenn Blau z.B. 35 ist und soll auf 100 macht eine Differenz von 65 die dann in 256 Schritten
    wäre pro Schritt 0,254 für Blau. Aber ich kann ja nur ganze Farbwerte senden. Oder sehe ich das jetzt total falsch ?( Denk ich mal das ich das tue ;)


    Aber ansonsten verstehe ich deine Formel.


    Und ich muss an dieser Stelle nochmal ein großes Lob an dich loswerden Pesi, dafür das du deine Freizeit opferst, um hier allen ausführlich auf ihre Fragen zu antworten
    und uns an deinem Wissen teilhaben lässt! Danke :thumbup::thumbup::thumbup:

  • Kein Problem, ich finde das hier ja auch interessant, und habe im Forum auch schon selbst viel gelernt, dadurch dass ich Posts gelesen habe, die andere geschrieben haben...


    ja, natürlich können da "krumme" Werte bei rauskommen, die werden aber "automatisch" gerundet (wenn Du nicht mit Fließkommazahlen rechnest) - ein Fade von 0 zu 255 geht dann natürlich 0, 1, 2, 3 usw., einer von 80 zu 150 z.B. 80, 80, 80, 81, 81, 81, 82, 82, 82, usw.


    das hat aber den Vorteil, dass ein fade immer gleich lang dauert, egal von welcher zu welcher Farbe - ich habe so ein billiges Chinesen-"Scannerpult", das nehme ich bei ganz kleinen Sachen für Scanner oder LED-PARs - das zählt einfach rauf oder runter, was dazu führt, dass ein Fade von A nach B schneller geht als der von B nach C, wenn A und B näher zusammen sind als B und C - dadurch werden die Scanner-Bewegungen irgendwie "eckig" und "unharmonisch" - bei den LED-PARs das Problem: es soll z.B. Orange (255/120/0) ausfaden - das Pult zählt dann einfach runter 254/119/0, 253/118/0, irgendwann ist es bei 135/0/0, 134/0/0 usw. - es ändert sich also die Farbe beim Faden, statt einfach Orange auszufaden, wird es erst rot, und dann fadet das aus...


    bei obiger Methode dauert der Fade von A nach B immer genau so lange wie der von B nach C, egal wie groß der Unterschied ist - und die Farben blenden auch "harmonischer" ineinander über...

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • Also normalerweise würde ich in Excel erstmal die Tabelle erzeugen (255 * cos(winkel) und diese Werte ganzzahlig machen.
    auf den µC in ein Feld übertragen und neben dem PWM Timer einen WWT "Wert-Wechsel-Timer" aufmachen.
    dem PWM Timer wird der gewünschte PWM Wert über eine Variable z.B. rot_PWM übergeben.
    Der WWT läuft also jetzt von 1 bis x durch das Feld mit den vorberechneten Werten und übergibt bei jedem Durchlauf den aktuellen Wert an rot_PWM.
    Wichtig ist, das der WWT deutlich langsamer läuft als der PWM Timer.


    Ich nehme alles zurück .. hab auf Antworten geklickt, ohne die zweite Seite gesehen zu haben! Sorry :S

  • Hm, zwischen 0 und 255 wird dann also linear gefaded? Sollte das Ergebnis dann nicht dazu verwendet werden den dem Auge angepassten Helligkeitswert in einer Tabelle nachzuschlagen? Oder wäre es möglich, diesen direkt zu berechnen?

  • Es wird (bei obiger Methode, ohne den zusätzlichen Cosinus) linear zwischen den 2 Werten gefadet - also dann natürlich auch von 0 bis 255, wenn A 0 ist und B 255...


    ebenso linear von 50 zu 80 oder 220 zu 170 oder was auch immer...


    das mit der Helligkeitskorrektur ist wieder ne hiervon getrennte Sache - die kann man dann bei der Ausgabe mit rein rechnen...


    erst mal hast Du eine Repräsentation, die Werte 0-255 stellen Helligkeiten dar, zwischen denen gefadet wird - einfach so per PWM ausgegeben, erscheint ein Fade von 0 nach 255 natürlich nicht linear


    aber "intern" in der Lichtsteuerung ist diese Repräsentation linear, da wird also davon ausgegangen, dass 128 "halbe Helligkeit" bedeutet - ob und wie das dann umgesetzt wird, ist eher Sache der angesteuerten Leuchte, da gibt's ja diverse, entweder einfach simpel 8-Bit-PWM oder 12 bis 16 Bit mit interner Korrektur oder wasauchimmer


    deswegen wird das normal auch nicht in der Lichtsteuerung korrigiert, wenn Du nun ne Leuchte anschließt, die diese Korrektur schon drin hat, dann passiert die ja doppelt, und es stimmt wieder nicht...


    hier, bei dieser Sache (Unreal hat ja so ne LED-Steuerung mit Arduino gebaut, die über den PC angesteuert wird) müsste die Korrektur dann im Arduino erfolgen, die SW am PC gibt aber lineare Werte aus, also die geht dann davon aus, dass 128 eben halbe Helligkeit bedeutet...


    wegen "direkt berechnen": Du hast doch selbst hier ne Formel vorgestellt... ;) - so wie's aussieht, läuft das einfach auf ne quadratische Funktion raus, auch bei Mikrocontroller.net wird inzwischen betont, dass es wohl doch kein Logarithmus ist...


    ich hatte mich ja früher schon mal mit sowas beschäftigt, da erschien mir der Wert von 0,33 (bei der Stevenschen Potenzfunktion) für das Helligkeitsempfinden auch zu niedrig, ich bin dann durch Versuche auch "eher auf ne Quadratfunktion" gekommen, einfach Quadrat nehmen wäre so "zwischen" der µC.net-Tabelle (* und meiner, sollte also schon auch gut funktionieren...


    (interessanter Weise gibt es in meinem gekauften Dimmer auch ne "quadratische Dimmerkurve", aber keine logarithmische...)


    *) der damals dort veröffentlichten, als noch die Rede von "logarithmischem Helligkeitsempfinden" war - k.A., ob sie mittlerweile auch die Tabelle angepasst haben...

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • Ich hab den Fader bisher immer in HSV gemacht, keine Ahnung ob der groß anders aussieht als der von Pesi beschriebene Regenbogenfader. Der Vorteil dabei ist wohl die normalisierende Formel von Neni, die ein "pumpen" der Helligkeit recht gut verhindert.


    @OT wegen falsch Einsortieren & Co: Schaut mal unter Forenstruktur. Hoffe es kommen ein paar konstrultive Vorschläge, denn das Thema ist mir auch ein Dorn im Auge.

  • das mit dem Cosinus meinst Du so, dass die Farbe sich praktisch erst langsam ändert, zwischen beiden Farben dann schnell, und kurz vor erreichen der Zielfarbe wieder langsam?

    Genau das meine ich.


    Zu den Pastelltönen: Ja, die bekommt man meistens. Es kommt halt darauf an, was man möchte. Ich finde die Pastelltöne gar nicht so schlecht. Aber man kann ja z.B. die genannten Maßnahmen ergreifen, um vollere Farben zu bekommen (oder z.B. maximal zwei kräftige Komponenten, die dritte dann nur schwach oder gar nicht vorhanden).