Schönen RGB Fader selber Programmieren

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

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

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

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

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.

Zitat von Pesi

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