FastLED analog out - Farbkorrektur?

Hallo in die Runde,

ich nutze für mein Lampennetzwerk die FastLED- Library... nun habe ich die LEDs je nach Lampe unterschiedlich beschaltet, so dass die Farben leicht von einander abweichen. Gibt es eine Funktion mit der ich die Farben korrigieren kann?

Es gibt nur eine globale Farbkorrektur.

Einzelne Leuchtmittel musst Du von Hand korrigieren.

Dies tust Du, indem Du die Anteile der Grundfarben reduzierst, bis weiß auch weiß aussieht.

[ edit: SPOILER - BULLSHIT! ]

Vor dem Aufruf von FastLED.show() würde z.B.

leds[120].g %= 127;

den Grün-Anteil der 121. Led auf die Hälfte reduzieren.

Gruß, H.

Bevor jemand verwirrt wird:

Vor dem Aufruf von FastLED.show() würde z.B.

leds[ 120 ].g %= 127;

den Grün-Anteil der 121. Led auf die Hälfte reduzieren.

ist natürlich Unsinn in mehrfacher Hinsicht.

  1. %127 lässt die Werte 0 .. 126 unverändert und reduziert die Werte 127 .. 254 um genau 127
    ( oder meintest du "auf den halben Bereich begrenzen")

  2. mit so krummen Werten verleitet man den Compiler dazu, das tatsächlich durch eine aufwendige Division zu machen.
    Halbieren geht mit /2 oder >>1
    Auf den halben Bereich begrenzen geht mit & 0x7F

  3. x %= 127 macht die Operation bei mehrfachem Aufruf mehrfach.
    Das ist hier nicht schlimm, da die Werte eh im Bereich 0 .. 126 unverändert bleiben.
    Wenn tatsächlich halbiert wird, sollte man schauen, dass diese Operation nur einmal gemacht wird, nachdem die Variable ihren noch zu korrigierenden Wert erhalten hat.

Und dann würde ich sagen ist beides bei "analog out" nicht anwendbar, oder? (und selbstverständlich habe ich je Lampe und Steuerung nur einen Kreis RGB- LEDs.... nur eben bei jeder Lampe eine andere Anzahl und eine andere elektrische Beschaltung...

Ich verwende 10W- RGB- Leds die bei blau und grün ca. 9V und bei rot ca. 6V bei Nennstrom benötigen... Bei den größeren Lampen habe ich 36V Spannungsquellen und schalte entsprechend 6 rote bzw. 4 grüne und 4 blau jeweils in Reihe, um möglichst effizient arbeiten zu können... Es gibt aber auch Lampen wo ich nur eine solche LED habe, da auch gleich mit 9V arbeite und bei rot eben 3V zum Heizen eines Widerstandes nehme... :wink:

funktioniert alles- die Ströme sind auch alle im Soll- also nix wo ich jetzt was ändern will...

nur passen die Farben nicht zu 100%- so, dass ich quasi eine Kalibrierung vornehmen möchte...

@michael_x: Den “Unsinn in mehrfacher Hinsicht” muss ich entschieden zurückweisen.

Bitte mal kurz hier den Absatz “Dimming and Brightening Colors” nachlesen. Danke.

  1. %127 lässt die Werte 0 … 126 unverändert und reduziert die Werte 127 … 254 um genau 127
    ( oder meintest du “auf den halben Bereich begrenzen”)

Unsinn! :wink: Das ist die Kurzform von

leds[120].g = scale8( leds[120].g, 127);

Eine lineare Skalierung.

Anders ausgedrückt:

You can also express this the other way: that you want to dim the pixel to 75% of its current brightness. 75% = 192/256. There are two ways to write this, both of which will do the same thing. The first uses the %= operator; the rationale here is that you’re setting the new color to “a percentage” of its previous value

Aber nscale8 verändert (skaliert proportional) r, g und b zugleich (arbeitet am CRGB - reduziert die Gesamthelligkeit unter Beibehaltung der Farbe). Wollen wir nicht. Wir wollen einzelne Farbkanäle skalieren.

Deshalb so, wie von mir beschrieben.

Wenn tatsächlich halbiert wird, sollte man schauen, dass diese Operation nur einmal gemacht wird, nachdem die Variable ihren noch zu korrigierenden Wert erhalten hat.

Mein Beispiel mit der (fast) Halbierung war bescheuert gewählt, das geht natürlich mit Bitschieben schneller.

Ja, die Korrektur darf nur einmal gemacht werden - und zwar direkt vor dem Schreiben der LEDs. Wie von mir beschrieben.

Und dann würde ich sagen ist beides bei “analog out” nicht anwendbar, oder?

Doch, das ist genau so anwendbar, sonst hätte ich es Dir nicht geschrieben.

nur passen die Farben nicht zu 100%- so, dass ich quasi eine Kalibrierung vornehmen möchte…

Glaub´ mir, ich habe Dein Problem vollständig verstanden. Du musst bei LED(Gruppen) die Grundfarben runterskalieren, um alle RGB-Sets auf eine gleiche Farbtemperatur zu bringen.

Schreibe Dir Schleifen für die betreffenden LEDs und dimme die Einzelfarben runter.

leds[i].r = scale8( leds[i].r, red_correction);
leds[i].g = scale8( leds[i].g, green_correction);
leds[i].b = scale8( leds[i].b, blue_correction);

Der correction Wert gibt in 1/256 Schritten an, wieviel der Grundhelligkeit erhalten bleibt.

Und dieser Code macht exakt das Gleiche, wie

BULLSHIT:

leds[i].r %= red_correction;
leds[i].g %= green_correction;
leds[i].b %= blue_correction;

Gruß, H.

aaaaaaaaaaaaaaahhhhhhhhhh....... jetzt hab ich es verstanden....

ich setze das die Tage mal um und gebe Rückmeldung....

Im Moment kämpfe ich noch mit anderen Themen bei meinen Lampen... :smiley:

bei einer will ich neben den RGBs auch einen Neo- Pixel- Streifen ansteuern.... mit Farbeverlauf.... außen soll die Farbe der RGB- LEDs sein- in der Mitte was anderes... also mit dem Effekt will ich mal anfangen... eigentlich würde ich da auch gern einen "Vorhang" aufgehen lassen, bzw. wieder schließen... also soll mit dunklen und hellen Mustern Falten simmuliert werden- die halbwegs flüßig zur Seite fahren- sich dort die Helligkeit etwas verstärkt- in der Mitte soll dann schwarz sein....

Bitte mal kurz hier den Absatz “Dimming and Brightening Colors” nachlesen. Danke.

Danke.

Ich nehme fast alles zurück. ( Bis auf das Detail, wo du mir zustimmst, und weiter unten… )

Ein schönes Beispiel, wie übel toll man mit Operator-Überladen tricksen kann.
Wenn man -wie ich- denkt, eine Farbe wären drei Zahlen für RGB und .g wäre eine davon, mit der man rechnen könnte, hat man eben Pech.

Klar ist dies

int i = 100; // byte wäre auch nicht besser
i %= 127; // immer noch 100

Unsinn, es hat nur nicht viel mit einem CRGB Objekt zu tun.

Was bei

CRGB myColor = CRGB::DeepPink;
myColor %= 127;

passiert, kann keiner wissen, der es nicht selbst erfunden oder zumindest die Doku gelesen hat.

Aber was bei
[b]myColor.r %= 127;[/b] passiert, ist wieder eine andere Sache.
Wie ruft das wohl die Zauberfunktion scale8(byte, byte); aus scale.h auf?

(Ich war sehr verblüfft, dass von dir so ein Unsinn kommt dir so ein Irrtum unterläuft)

hm.... was mach ich nun in dem Dialog zwischen euch? :wink:

Aber was bei
myColor.r %= 127; passiert, ist wieder eine andere Sache, wo du nochmal dein schönes Beispiel überarbeiten solltest...

(Ich war sehr verblüfft, dass von dir so ein Unsinn kommt dir so ein Irrtum unterläuft)

Ok, Asche auf mein Haupt, CRGB myColor.r ist ein uint8_t und verhält sich somit, wie von Dir vorhergesagt.

Daher ist mein Vorschlag zutreffend als Unsinn zu bezeichnen.

Funktionierend ist nur und ausschließlich diese Variante:

leds[i].r = scale8( leds[i].r, red_correction);
leds[i].g = scale8( leds[i].g, green_correction);
leds[i].b = scale8( leds[i].b, blue_correction);

Danke und Gruß,

Helmuth

hm… was mach ich nun in dem Dialog zwischen euch? :wink:

Einfach weiter aufmerksam mitlesen.

hm.... was mach ich nun in dem Dialog zwischen euch? :wink:

Schau dir die FastLED Library an. Da gibt es zig tolle Möglichkeiten mit den Farben zu spielen.
Und im Zweifelsfall ist Helmuth natürlich einfach kompetent, wenn du Fragen hast.

macht weiter... ich lese mit... ich glaub so lerne ich einiges....

MaHa76:
macht weiter… ich lese mit… ich glaub so lerne ich einiges…

Zu spät, sie sind fertig! Aber ich lese aus genau diesem Grund gerne in diesem Forum mit!

MaHa76:
hm… was mach ich nun in dem Dialog zwischen euch? :wink:

Das hier als Quintessenz zur Korrektur verwenden:

leds[i].r = scale8( leds[i].r, red_correction);
leds[i].g = scale8( leds[i].g, green_correction);
leds[i].b = scale8( leds[i].b, blue_correction);

Danke schön.....

fehlt nur noch ein Tipp für den "Vorhang" .... :slight_smile:

MaHa76:
fehlt nur noch ein Tipp für den "Vorhang" .... :slight_smile:

Eine Animation in leds1, die zweite in leds2 unabhängig voneinander berechnen und dann mit einer "Wischblende" den Vorhang öffnen. Du darfst gerne bei FastLED Library- strukturiertes Vorgehen bei genauen Vorstellungen spicken. Die Felder leds1 und leds2 heißen da anders und die Wischblende läuft von oben nach unten oder umgekehrt.

OK- danke, das schaue ich mir mal an...

Ich habs bisher wenn ich eine einfache Animation entwurfen haben eine Tabelle gemacht und da dann den zeitlichen Verlauf skizziert, bis ich ein Muster erkannt habe, was ich in einer Formel abbilden konnte- also z.b. bei einem Farbverlauf...

für komplexe Muster reicht das nicht- aber vielleicht hilft mir dein link. :slight_smile:

Was hat die FastLED Bibliothek mit analogout zu tun?

MaHa76:
Ich verwende 10W- RGB- Leds die bei blau und grün ca. 9V und bei rot ca. 6V bei Nennstrom benötigen... Bei den größeren Lampen habe ich 36V Spannungsquellen und schalte entsprechend 6 rote bzw. 4 grüne und 4 blau jeweils in Reihe, um möglichst effizient arbeiten zu können... Es gibt aber auch Lampen wo ich nur eine solche LED habe, da auch gleich mit 9V arbeite und bei rot eben 3V zum Heizen eines Widerstandes nehme... :wink:

funktioniert alles- die Ströme sind auch alle im Soll- also nix wo ich jetzt was ändern will...

nur passen die Farben nicht zu 100%- so, dass ich quasi eine Kalibrierung vornehmen möchte...

LED müssen mit Konstantstrom gespeist werden, nicht mit Konstantspannung. Wenn Du eine Switching-Stromquelle nimmst wie für LeistungsLED üblich dann hast Du keine hohen Verluste. Wenn diese KSQ dann einen PWM-Eingang hat dann kannst Du die Helligkeit auch regeln.

Wie ist Deine Schaltung??

Grüße Uwe

Gruß, H.

ok, Danke
FastLED kann auch auf die PWM-Ausgänge ausgeben.

Grüße Uwe

Indirekt, man kann die RGB Daten abgreifen und damit machen, was man will, z.B. sie via analogWrite an PWM Pins senden.

Noch eine Anmerkung zur Farbkorrektur: Wenn man das nicht 100x kompilieren will, bis man die richtigen Korrekturwerte gefunden hat, empfiehlt es sich, irgendein Userinterface zu bauen. Der serielle Monitor oder eine IR Fernbedienung gehen gut.

So, dass man alle 3 Korrekturwerte für ein RGB Set zur Laufzeit nach oben und unten variieren kann.

Ich würde mit Gelb als Vergleichsfarbe anfangen. Referenzled diese Farbe anzeigen lassen und an der zu korrigierenden nur an Rot und Grün drehen, bis es passt. Danach Weiss. Dann nur noch blau korrigieren.

Falls das zu korrigierende Blau nicht hell genug ist (also das Ergebnis zu gelblich aussieht, obwohl Blau mit maximaler Helligkeit leuchtet) wieder einen Schritt zurück auf Gelb - Rot und Grün absenken (Helligkeit verringern, während das Mischungsverhältnis gleich bleibt). Erneut testen, ob Blau jetzt hell genug ist, damit die beiden Weiß identisch aussehen. U.s.w.

Wenn es passt, die gleiche Prozedur mit dem nächsten RGB Set. Immer die gleiche Referenzled verwenden, sonst addieren sich die Fehler, d.h. benachbarte Sets sehen okay aus, aber das erste nicht so, wie das letzte.

Ich habs bisher wenn ich eine einfache Animation entwurfen haben eine Tabelle gemacht und da dann den zeitlichen Verlauf skizziert, bis ich ein Muster erkannt habe, was ich in einer Formel abbilden konnte- also z.b. bei einem Farbverlauf...

Das ist ein guter Ansatz. Ich glaube, ich habe in meinem Leben schon mehrere m² Karopapier mit Pattern vollgekritzelt. Das hilft, um einerseits genau zu verstehen, was man eigentlich vorhat und andererseits, um Zykliken und Zusammenhänge zu erkennen, die man in Formeln ausdrücken kann.

Grüße, H.