Hallo mal wieder :) Hat vielleicht jemand mal eine RGB Fading Steuerung proprammiert.? Das würde mich mal sehr interessieren...Sollte jemand einen Code dafür in C haben, bitte lasst mich mal ein Blick drauf werfen ;) danke. MfG
08flyer schrieb: > RGB Fading Steuerung Kannst du das genauer spezifizieren? Eine Art rainbow-LED?
:
Bearbeitet durch User
Was genau verstehst du unter RGB-Fading. Die Sache ist nämlich die, dass man selbstverständlich zwischen 2 RGB-Datensätzen hin und her faden kann. Aber eigentlich liefert das Zwischenfarben, die nicht so wirklich dem entsprechen, was man nach landläufiger Meinung unter einem "Farbübergang" versteht. Das liegt daran, dass es bei RGB keinen dezidierten Parameter gibt, der dem Konzept einer "Farbe" entspricht. Daher werden derartige Farbüberblendungen normalerweise nicht im RGB-Raum gemacht sondern in einem anderen Farbschema, zb. HLS und dann die Zwischenstufen einzeln nach RGB transformiert. Alternativ kann man sich auch ein einfaches RGB Schema zurecht legen, welches den Farbraum Rot->Grün->Blau->Rot in zb 360 Werten abbildet und näherungsweise einen Farbkreis ergibt, in dem man wiederrum relativ leicht zwischen 2 Farben überblenden kann. Das stimmt zwar nicht wirklich und ist einem HLS Zwischenschritt unterlegen, allerdings ist das auch nur theoretisch, da die meist verwendeten RGB LED sowieso nicht kalibriert sind und sich die theoretische Farbe auch nur angenähert aus den RGB Werten ergibt. Denn welches Rot ist den schon das richtige Rot? Für normale Farbübergänge, die entlang eines Farbkreises ein Rot in ein Grün überblenden sollen reicht diese genäherte Version vollkommen aus.
:
Bearbeitet durch User
Den Code finde ich nicht mehr, wahrscheinlich auf der externen HDD die ich zu Hause habe. Ich weiß aber noch dass ich mich an dieser Site orientiert habe: http://www.ulrichradig.de/home/index.php/projekte/hsv-to-rgb-led
08flyer schrieb: > Hat vielleicht jemand mal eine RGB Fading Steuerung proprammiert.? Soetwas? http://www.ulrichradig.de/home/index.php/avr/dmx-led-strip
Karl Heinz schrieb: > Alternativ kann man sich auch ein einfaches RGB Schema zurecht legen, > welches den Farbraum Rot->Grün->Blau->Rot in zb 360 Werten abbildet und > näherungsweise einen Farbkreis ergibt, in dem man wiederrum relativ > leicht zwischen 2 Farben überblenden kann. Das stimmt zwar nicht > wirklich und ist einem HLS Zwischenschritt unterlegen, allerdings ist > das auch nur theoretisch, da die meist verwendeten RGB LED sowieso nicht > kalibriert sind und sich die theoretische Farbe auch nur angenähert aus > den RGB Werten ergibt. Denn welches Rot ist den schon das richtige Rot? > Für normale Farbübergänge, die entlang eines Farbkreises ein Rot in ein > Grün überblenden sollen reicht diese genäherte Version vollkommen aus. der meinung bin ich auch, dass es so vollkommen ausreicht. so genau muss es ja nicht sein :) und gibt es dafür auch schon fertige codes.?
08flyer schrieb: > der meinung bin ich auch, dass es so vollkommen ausreicht. so genau muss > es ja nicht sein :) Das ist dann nicht weiter schwer. Mehr als lineare Interpolation zwischen 2 Werten muss man dazu nicht können. (siehe Bild) Man teilt sich den 360 Farbkreis in 6 Abschnitte auf. In jedem Abschnitt wird irgendeiner der 3 Farbkanäle auf bzw. abgedimmt. Kennt man also die Farbnummer seiner Farbe, dann kann man ganz leicht bestimmen, wie die zugehörigen RGB Werte sind. Beim Wert 0, den ich mal willkürlich als Rot angenommen habe, hat man also Rot. Mit steigenden Nummern kommt immer mehr Grün dazu, bis Grün zu 100% aufgedreht ist. Man ist also bei der 60 angelangt und die Farbe, die man jetzt sieht (na ja, mehr oder weniger) ist Gelb. Bei einem Farbwert von 30 wäre also Rot immer noch bei 100% während Grün bei lediglich 50% dahin dümpelt. Blau ist dabei die ganze Zeit bei 0. Der nächste Abschnitt ist der Übergang Gelb nach Grün, bei dem Grün auf 100% bleibt, während Rot linear abnimmt (Blau ist die ganze Zeit auf 0). Und so geht es weiter. In jedem der 6 Abschnitte wird eine der 3 Farben von 0 bis zu 100% aufgezogen bzw. von 100% bis auf 0 runtergezogen. und das wars dann auch schon. Nach allen 6 Abschnitten, die ich recht willkürlich mit jeweils 60 Einheiten angenommen habe, landet man wieder bei Rot. die 60, bzw. die 360 für einmal rundum sind recht willkürlich und stammen einfach nur daher, dass ein Kreis 360° hat. Aber im Grunde kann man das alles auch mit anderen Zahlen machen. Insbesondere mit Zahlen, die man dann komplett ohne lineare INterpolation mehr oder weniger direkt als PWM Werte benutzen kann. Schreib dir eine Funktion, der du die Farbnummer 0 bis 359 übergibst und die dir die zugehörigen RGB Werte ausrechnet. Ist nicht weiter schwer
1 | void toRGB( uint16_t color, uint8_t* red, uint8_t* green, uint8_t* blue) |
2 | {
|
3 | if( color <= 60 ) |
4 | {
|
5 | *red = 255; |
6 | *green = interpolate( color, 0, 255 ); |
7 | *blue = 0; |
8 | }
|
9 | |
10 | else if( color <= 120 ) |
11 | {
|
12 | *red = interpolate( color - 60, 255, 0 ); |
13 | *green = 255; |
14 | *blue = 0; |
15 | }
|
16 | |
17 | else if( color <= 180 ) |
18 | {
|
19 | *red = 0; |
20 | *green = 255; |
21 | *blue = interpolate( color - 120, 0, 255 ); |
22 | }
|
23 | |
24 | ....
|
Die Funktion interpolate musst du natürlich noch schreiben. Sie macht nichts anderes als eine Zahl im Bereich 0 bis 59 auf die jeweils angegebene Gerade umzumappen. Aber das ist nicht weiter schwer. Ist einfach nur eine lineare Gleichung, die auf die 60 Intervallbreite abgestimmt ist.
1 | uint8_t interpolate( uint16_t value, uint8_t intervallStartValue, uint8_t intervallEndValue ) |
2 | {
|
3 | ....
|
4 | }
|
:
Bearbeitet durch User
Karl Heinz schrieb: > Aber das ist nicht weiter schwer. > Ist einfach nur eine lineare Gleichung, die auf die 60 Intervallbreite > abgestimmt ist. Dann wäre es doch viel einfacher, den Kreis auf 6*256=1536 aufzuteilen. Für die Farben könnte man sich dann jede Skalierung sparen. Schlimmstenfalls braucht man eine Subtraktion.
Mike schrieb: > Karl Heinz schrieb: >> Aber das ist nicht weiter schwer. >> Ist einfach nur eine lineare Gleichung, die auf die 60 Intervallbreite >> abgestimmt ist. > > Dann wäre es doch viel einfacher, den Kreis auf 6*256=1536 aufzuteilen. Naürlich. Aber es ist ja nicht mein Projekt. Ein bischen 'Entwicklungsarbeit' und Gehirnschmalz muss er schon auch selbst investieren.
:
Bearbeitet durch User
Etwas sehr ähnliches machen auch beim Wordclock Projekt, insofern könnte sich ein Blick in die Quellen lohnen. Diese sind auch kommentiert ;)</Eigenwerbung>. Mit freundlichen Grüßen, Karol Babioch [1]: https://github.com/Wordclock/firmware/blob/master/src/color.c
Hallo, Karl Heinz, ich befürchte, wer nicht "source code für RGB Steuerung" in Google eingeben kann und deswegen auch nicht eine der "ungefähr 205.000 Ergebnisse" (laut Google) findet, von denen das erste gleich auf einen Thread mit zig Varianten hier auf mikrocontroller.net verweist, der wird sich nicht wirklich die Mühe machen wollen, auch nur irgendetwas an "Entwicklungsarbeit" hineinzustecken... War aber gut erklärt, eventuell machst Du ja einen Artikel daraus? (kurze Suche hat weder HSV noch RGB-Fader bei den Artikeln gefunden). Schöne Grüße, Martin
Martin L. schrieb: > Hallo, > > Karl Heinz, ich befürchte, wer nicht "source code für RGB Steuerung" in > Google eingeben kann und deswegen auch nicht eine der "ungefähr 205.000 > Ergebnisse" (laut Google) findet, von denen das erste gleich auf einen > Thread mit zig Varianten hier auf mikrocontroller.net verweist, der wird > sich nicht wirklich die Mühe machen wollen, auch nur irgendetwas an > "Entwicklungsarbeit" hineinzustecken... Das mag sein. Trotzdem gehe ich mehr und mehr dazu über, je nach Schwierigkeitsgrad keine Komplettlösungen mehr anzubieten, sondern nur noch den Weg dorthin in unterschiedlicher Detailierung aufzuzeigen. So hab ich mir meine Sporen verdient, so haben es andere gemacht und ich denke, das das ein gangbarer Weg ist, wenn nicht sogar der einzige. Ja man muss zum Teil auch für sich das Rad neu erfinden. Nicht um danach ein Rad zu haben, sondern um zu lernen wie man Räder macht. Bei Dingen, von denen ich denke, dass sie in der Tat schwierig umzusetzen sind, gehe ich auch schon mal weiter. Aber ich möchte mehr in die Richtung, eine mögliche Idee aufzuzeigen und die Leute dazu zu bringen, auch wirklich ihr Projekt selbst zu programmieren. Kann jemand das nicht, dann hat er eben Pech. Vor dem Wollen kommt immer noch das Können. > War aber gut erklärt, eventuell machst Du ja einen Artikel daraus? > (kurze Suche hat weder HSV noch RGB-Fader bei den Artikeln gefunden). Echt? (Ich hab nicht gesucht) Es müssten ein paar Forenbeiträge existieren, in denen genau diese Methodik vorkommt. Zum Teil auch mit genau demselben Diagramm :-)
Karl Heinz schrieb: > Ist einfach nur eine lineare Gleichung, die auf die 60 Intervallbreite > abgestimmt ist. Wäre es nicht besser die Rampen logarithmisch zu machen, da das Auge ja logarithmisch sieht. Ich habe damals eine Lookup Table verwendet (LED-Fading).
:
Bearbeitet durch User
Karl Heinz schrieb: > Man teilt sich den 360 Farbkreis in 6 Abschnitte auf. [...] Ich mache es noch einfacher: Nehmen wir an, ich hätte 64 PWM-Stufen für jede Farbe - angepasst an das menschliche Auge. Nehmen wir noch zusätzliche an, ich hätte eine Timer-ISR, die 128 mal pro Sekunde aufgerufen wird. Wenn man nun vom RGB-Wert (besser: PWM-Index: 0 bis 63)) F1 = (10, 63, 40) auf den Wert F2 = (33, 10, 45) faden will, berechnet man erstmal die 3 Differenzen: DiffR = 23 (rot) DiffG = -53 (grün) DiffB = 5 (gelb) Soll nun die Fading-Zeit z.B. 1 Sekunde betragen, dann muss Rot innerhalb von einer Sekunde 23 Schritte, Grün 53 Schritte und Blau 5 Schritte durchlaufen. Also teilen wir die 128 Aufrufe pro Sekunde durch die Anzahl der Schritte: 128 / 23 = 5 (Integerdivision) 128 / 53 = 2 128 / 5 = 25 Wenn wir jetzt 3 Zähler in der ISR verwenden (für R, G und B), dann müssen wir bei Rot immer bis 5 zählen, bis wir R um eine Stufe erhöhen, bei Grün bis 2 zählen, bis wir G um eine Stufe erniedrigen usw. Das geht soweit, bis wir den gewünschten Zielwert F2 erreicht haben. Da alle 3 Zähler simultan in der ISR laufen, erreichen wir dadurch auch ein "zeitgleiches" Faden aller 3 Farben, wobei diese 3 Farben unterschiedliche lange "Strecken" (mit verschiedener Geschwindigkeit) zurücklegen müssen, bis sie ihren Endwert erreicht haben. Je öfter die Aufrufe der Timer-ISR geschehen (128 war nur ein Beispiel), desto genauer wird die Geschichte. Ich benutze diese Methode bei meiner Equinox-Uhr (60 ATTinys) und bin mit den Ergebnissen mehr als zufrieden.
:
Bearbeitet durch Moderator
Max H. schrieb: > Karl Heinz schrieb: >> Ist einfach nur eine lineare Gleichung, die auf die 60 Intervallbreite >> abgestimmt ist. > Wäre es nicht besser die Rampen logarithmisch zu machen, da das Auge ja > logarithmisch sieht. Jein. Mein bevorzugter Ansatz ist, daß das Software-Modul zur LED- Helligkeitssteuerung die Gammakorrektur intern macht. Auf der Schnitt- stelle zum Rest (RGB-Rampengenerator, HSV->RGB Wandler, etc.) sind die Werte dann linear. Ein linearer Sweep erzeugt dann eine als linear wahrgenommene Helligkeitsänderung. Wie man das dann intern umsetzt, ist wieder eine andere Frage. Aber da 255 Helligkeitsstufen i.d.R. vollkommen ausreichen, bietet sich eine Tabelle natürlich an. In der https://www.mikrocontroller.net/forum/codesammlung gibts von mir auch ein RGB-Moodlight. Mit Skript zum Generieren der Gammatabelle. XL
Axel Schwenke schrieb: > Aber da > 255 Helligkeitsstufen i.d.R. vollkommen ausreichen, Wobei man in der Praxis nur wirklich 255 Helligskeitsstufen hat. Mit einer 8 Bit PWM schafft man realistisch gesehen nicht mehr als 32 oder 64 Stufen. Oder hast du da irgendwelche Tricks, die ich noch nicht kenne ;). Mit freundlichen Grüßen, Karol Babioch
Max H. schrieb: > Karl Heinz schrieb: >> Ist einfach nur eine lineare Gleichung, die auf die 60 Intervallbreite >> abgestimmt ist. > Wäre es nicht besser die Rampen logarithmisch zu machen, da das Auge ja > logarithmisch sieht. Ich habe damals eine Lookup Table verwendet > (LED-Fading). Kann man natürlich auch. Allerdings hab ich auch bei meinen Versuchen gemacht, dass das alles recht akademisch ist, da RGB Led keineswegs die idealen 'Farberzeuger' sind. Steuere ich eine RGB LED mit 255,255,255 an, dann sollte da eigentlich weiß rauskommen, in der PRaxis (bei meinen LED) haben die aber alle einen unterschiedlichen Farbstich. Die einen ins rote, die anderen ins blaue. Die Frage ist auch immer, was will man eigentlich machen. Stelle ich mir die Farben sowieso per Hand ein, dann interessiert es im Grunde nicht wirklich, ob ich da jetzt am Drehencoder noch 5 Tacken weiter drehen muss oder nicht. Ich seh ja die Zahlenwerte sowieso nicht und drehe so lange bis es mir gefällt. Genauso beim Fading: Ob das Gelb im Fading-Verlauf jetzt wirklich ein sauberes Gelb ist oder doch einen leichten Braunstich hat, wird niemand merken, wenn es im Farbverlauf von Rot auf Cyan als Zwischenstufe auftritt. Baue ich ein Ambilight, bei dem sich das Bild am Fernseher in den LED-Farben wiederspiegelt, dann ist die Sache natürlich anders. Da bin ich dann selbstverständlich daran interessiert, dass die wahrgenommenen Farben tatsächlich denen entsprechen, die im Bild zu sehen sind.
:
Bearbeitet durch User
Frank M. schrieb: > Je öfter die Aufrufe der Timer-ISR geschehen (128 war nur ein Beispiel), > desto genauer wird die Geschichte. Ich benutze diese Methode bei meiner > Equinox-Uhr (60 ATTinys) und bin mit den Ergebnissen mehr als zufrieden. Mit wie vielen Aufrufen arbeitest du denn, wenn man fragen darf? Mit freundlichen Grüßen, Karol Babioch
Karol Babioch schrieb: > Frank M. schrieb: >> Je öfter die Aufrufe der Timer-ISR geschehen (128 war nur ein Beispiel), >> desto genauer wird die Geschichte. Ich benutze diese Methode bei meiner >> Equinox-Uhr (60 ATTinys) und bin mit den Ergebnissen mehr als zufrieden. > > Mit wie vielen Aufrufen arbeitest du denn, wenn man fragen darf? Es sind 3906 Aufrufe (statt 128 wie im obigen Beispiel) pro Sekunde. Die krumme Zahl kommt zustande, weil ich diese ISR zusätzlich nutze, um die Hardware-8-Bit-PWMs (ATTiny85) softwaremäßig auf drei 12-Bit-PWMs hochzuschrauben. Aber nur jedes zweite Mal werden die RGB-Indices hoch- bzw. runtergezählt, d.h. das Fading hat eine Aufrufrate von 1953 pro Sekunde. Bei RGB-Indexwerten von 0-63 erhält man bei der oben erwähnten Division schon ziemlich genaue Zählwerte - auch wenn die Fadingzeit mal nur eine Zehntel- statt ganze Sekunde dauern soll. Tatsächlich rechne ich dort in 10tel-Sekunden Einheiten. Aber das gehört nicht unbedingt hierher ;-)
:
Bearbeitet durch Moderator
Hallo, zum Thema Linearisierung durch Logarithmierung ist noch zu sagen, dass die vorgestellte Methode erhebliche Helligkeitsschwankungen aufweist, wobei die Grundfarben (rot, grün, blau) dunkler und die Mischfarben (gelb, cyan, magenta) jeweils bis zu doppelt so hell sind. Möchte man also ein wirklich gleichmäßiges durchlaufen des Farbkreises erreichen muss man also entweder eine echte HSV-RGB-Wandlung machen oder aber die vorgestellte Kurve entsprechend anpassen. Das sieht dann eher so aus wie im Anhang, wobei natürlich gelb, cyan und magenta nicht so hell dargestell werden, wie sie an sich könnten. Schöne Grüße, Martin
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.