Hallo pylon,
offensichtlich habe ich mich immer noch unklar ausgedrückt. Deine Anmerkungen sind alle zutreffend, helfen jedoch noch nicht weiter.
Alle Effekte, die ich bisher geschrieben habe, funktionieren in einem Array: CRGB leds[NUM_LEDS]
Alle Effekte basieren auf der Addition von Farben verschiedener Pixel, z.B.
leds[i] += leds[i + 1];
Was passiert bei der Addition? Das Ergebnis wird heller. Dabei entstehen schöne Mischfarben - aber nur, wenn das Ergebnis "im Rahmen bleibt". Addiert man z.B. sattes gelb zu sattem cyan (weil die nebeneinanderliegenden Pixel gerade zufällig so aussehen) ist das Ergebnis weiß. Soweit kein Problem für diesen einen Pixel, aber:
Diese Additionen laufen in mehreren Iterationen - also werden immer mehr Pixel weiß. Weiß + x = weiß. Bis zu einem gewissen Punkt ist das ok - so lange noch Stuktur/Form im entstehenden Muster erkennbar ist - aber anschließend werden immer mehr und schließlich alle Pixel weiß.
Das gilt es zu verhindern.
Momentan mache ich das, indem ich vor/nach der Addition die betreffenden Pixel ein wenig runterdimme. Und genau das ist ein schmaler Grat. Dimme ich zu viel, "geht Farbe verloren" und das Ergebnis wird zu dunkel. Dimme ich zu wenig, driftet das Ergebnis immer mehr in Richtung weiß.
Wenn diese Balance von Hand eingestellt ist, ist alles schön - füge ich aber z.B. einen weiteren Emitter hinzu, muss ich das Ausmaß der Dimmung erneut anpassen, da plötzlich "mehr Farbe" auf dem Screen ist.
Hinter "durchschnittliche Helligkeit" (bright) feststellen steckt die Idee, dass sich viele weiße Pixel in einem relativ hohen bright Wert wiederspiegeln. Und mein Ansatz ist, in Abhängigkeit von bright (vor/nach dem addieren) mehr oder weniger stark runterzuskalieren, um in Abhängigkeit vom momentanen Bildinhalt und dem zu erwartenden Ergebnis nach der nächsten Addition dynamisch gegenzusteuern - so, dass das Ergebnis nicht zu dunkel (schwache Farben) und nicht zu hell (weiß) wird.
Und dieses Problem erinnerte mich an die Lagestabilisierung des Quadrocopters - wo es auch darum geht, verschiedene unvorhersehbare und wechselwirkende Einflüsse auszugleichen und einen relativ stabilen Gesamtzustand des Systems herbeizuführen.
Jetzt nachvollziehbar?
Gruß Helmuth
P.S. Ich bin mir jedoch nicht sicher, ob die Kenntnis des bright Werts allein hinreichend für die Lösung des Problems ist.
edit: Wenn bright 255 ist, ist auf jeden Fall etwas schiefgelaufen. Wenn bright mal kurz 0 wird, macht das nichts, weil die (pulsierenden) Emitter in Kürze "neue Farben säen".
Soll das heissen, Du möchtest mit der Funktion sicherstellen, dass der ermittelte Wert "bright" nach der Ausführung einen konstanten Wert hat?
Nein, ich möchte einerseits sicherstellen, dass er nicht oder nur kurz 255 erreicht und andererseits nur kurzfristig (z.B.) < 50 wird. Die Untergrenze muss man wohl je nach Effekt festlegen. Wahrscheinlich muss man bright zusätzlich im Zeitverlauf beobachten und je nach Anstiegs-/Abfallgeschwindigkeit gröber oder feiner gegensteuern.
Aber wenn ich mir ansehe, was die Leute hier für Probleme haben, die passenden Parameter für eine PID Regelung zu ermitteln, befürchte ich, dass das das Problem der Handarbeit auch nur verschiebt. Wobei mich grundsätzlich ein leicht schwingendes System nicht wirkich stören würde.