Deriva colore led RGB

Ciao a tutti,
vi chiedo aiuto x un progetto che ho quasi finito. Mi mancano solo alcuni bug Fix e mi servirebbe gentilmente una mano da voi esperti…
Il progetto è una RGB lamp che ha le seguenti caratteristiche :
1 neopixel ring da 16 led
1 arduino uno
5 pulsanti adibiti alle funzioni Rosso, verde, blu, on_off, white
1 potenziometro per regolare l’intensità luminosa

IL primo problema che non riesco a risolvere è il seguente :

//Regolazione intensità Luminosa
void LedIntensityRegulation()
{
  unsigned int Temp = analogRead(Potenziometer);
  unsigned int PotValue;
  if (Temp < (Intensity - 15) || Temp > (Intensity + 15) && Temp != 0) {
    PotValue = map (Temp, 0, 1023, 1, 255);
    for (unsigned int n = 0; n < LedIndex; n++)
    {
      Colors[0] = (RGB.getPixelColor(n) >> 16);
      Colors[1] = (RGB.getPixelColor(n) >>  8);
      Colors[2] = (RGB.getPixelColor(n));
      unsigned int ColorMax = max(Colors[0], Colors[1]);
      ColorMax = max(ColorMax, Colors[2]);
      for (unsigned int i = 0; i < 3; i++)
      {
        Colors[i] = PotValue * Colors[i] / ColorMax;
      }
      RGB.setPixelColor(n, Colors[0], Colors[1], Colors[2]);
      RGB.show();
    }
    Intensity = Temp;
  }
}

in pratica succede che se il colore è un colore “puro” esempio (255,0,0) oppure (255,255,255) ma anche se è una mescolanza in ugual percentuale esempio (200,200,0) tutto funziona alla grande; mentre se il colore è una mescolanza casuale esempio (255,200,0) il colore mi va in deriva e tende sempre a al valore maggiore dei tre, se diverso da zero ovviamente.
Io ipotizzo sia una deriva che dipende dall’errore di troncamento che implica lavorare con i byte per i colori e la divisione della formula.

Mi sembra di aver spiegato decentemente bene la situazione ma se avete dubbi, chiedetemi e vi prego di aiutarmi a risolvere il problema.

Grazie,
Slauti

Dacci lo sketch completo
Grazie Ciao Uwe

Il codice è molto lungo, devo allegare un file .ino perche’ anche spezzato a meta’ eccede i 9000 caratteri.

RGB_Lamp_Neoring.ino (21.1 KB)

Ecco la simulazione completa del progetto esattamente come è nella mia configurazione reale!!!

Se premete il tasto col filo bianco, dopo che la lampada viene accesa (filo nero), esso cicla tra tre tonalità di bianco; Bianco bianco (254,254,254), bianco caldo(254,200,200) e bianco freddo (200,200,254) espressi come valori (RED,GREEN,BLU).

Il bianco "puro" come detto nel reply precedente, non ha problemi se andate ad aumentare o diminuire la luminosità....ma provate a fare un paio di volte su e giu col potenziometro nelle altre tonalità di bianco e vedrete che alla fine diventa o completamente Rosso o completamente Blu...

Vi prego, aiutatemi!

Mi pare che da regolamento non posso uppare il mio post, però io sono ancora bloccato e nessuno ha provato a ragionare con me una possibile soluzione..
Da ieri ho cambiato libreria e adesso uso la fastLED che sembra più performante a livello di funzioni e matematica interna... Devo rivedere l'intero codice
Ma nessuno ha mai fatto una lampada rgb e si è trovato di fronte gli stessi problemi?

Prima di tutto devi tenere presente una cosa, parlando di led RGB ... e cioe' che NON EMETTONO ASSOLUTAMENTE luce "bianca" ... emettono 3 diverse lunghezze d'onda, appunto rosso, verde e blu, che poi IL NOSTRO OCCHIO "interpreta" come bianco, se sono ben bilanciate e diffuse insieme ...

Per cui, sara' si possibile "simulare" la luce bianca (o per essere piu corretti, una combinazione dei tre colori che il nostro occhio poi "vede" come bianco), ma non e' possibile simulare perfettamente tutte le "sfumature" (temperature di colore) della luce bianca, perche' mancano diverse "sezioni" dello spettro ... per cui alcune di queste sfumature ti usciranno per forza con una o l'altra dominante rispetto al bianco vero e proprio, specie al di fuori del cosiddetto "bianco puro" ...

Etemenanki:
Prima di tutto devi tenere presente una cosa, parlando di led RGB ... e cioe' che NON EMETTONO ASSOLUTAMENTE luce "bianca" ... emettono 3 diverse lunghezze d'onda, appunto rosso, verde e blu, che poi IL NOSTRO OCCHIO "interpreta" come bianco, se sono ben bilanciate e diffuse insieme ...

Per cui, sara' si possibile "simulare" la luce bianca (o per essere piu corretti, una combinazione dei tre colori che il nostro occhio poi "vede" come bianco), ma non e' possibile simulare perfettamente tutte le "sfumature" (temperature di colore) della luce bianca, perche' mancano diverse "sezioni" dello spettro ... per cui alcune di queste sfumature ti usciranno per forza con una o l'altra dominante rispetto al bianco vero e proprio, specie al di fuori del cosiddetto "bianco puro" ...

Ciao Etemenanki ,
grazie per la risposta.
Quello che dici è vero e non l'ho messo in discussione. La terminologia "bianco puro" era solo per far capire cosa intendevo al lettore che non ha il mio progetto sotto mano, tutto qua. Sicuramente "bianco" e anche "puro" è usato in maniera impropria. Ma queste sono cose da manuale di illuminotecnica.

La mia domanda riguarda la gestione del codice di fade, che mi dovrebbe permettere di ridurre la luminosità con qualsiasi mescolanza di R, G e B, senza cambiare le proporzioni del colore!

Se per fade intendi il pilotaggio effettuato in PWM dei tre canali, tieni presente che hai "solo" 255 step per il possibile valore ... e se il valore dei tre canali non e' uno un multiplo dell'altro, o uguali, la variazione non potra' essere regolare comunque, perche' non ammette decimali o frazioni ...

Intendo dire, ad esempio ... se parti con R=100 e B=200 (consideriamo solo 2 colori, con 3 il problema semplicemente si moltiplica ;)), ok, ogni 2 punti di B cambia un punto di R (o l'opposto) ed il fading e' regolare ... ma se R=150 e B=200 ? ... non puoi cambiare 1.5 punti di R ogni 2 di B, ne tantomeno 1.3periodico punti di B ogni punto di R, quindi o "scali" i calcoli delle rampe in virgola mobile "arrotondando" poi ad interi nel pilotaggio delle uscite, e ti rimane un pilotaggio non regolare (probabilmente i "salti" non saranno molto evidenti, comunque ci saranno), o lavori solo con interi, ma alla fine qualche deriva da qualche parte la accumuli ...

Giusto come idea ...

Etemenanki:
Se per fade intendi il pilotaggio effettuato in PWM dei tre canali, tieni presente che hai "solo" 255 step per il possibile valore ... e se il valore dei tre canali non e' uno un multiplo dell'altro, o uguali, la variazione non potra' essere regolare comunque, perche' non ammette decimali o frazioni ...

Intendo dire, ad esempio ... se parti con R=100 e B=200 (consideriamo solo 2 colori, con 3 il problema semplicemente si moltiplica ;)), ok, ogni 2 punti di B cambia un punto di R (o l'opposto) ed il fading e' regolare ... ma se R=150 e B=200 ? ... non puoi cambiare 1.5 punti di R ogni 2 di B, ne tantomeno 1.3periodico punti di B ogni punto di R, quindi o "scali" i calcoli delle rampe in virgola mobile "arrotondando" poi ad interi nel pilotaggio delle uscite, e ti rimane un pilotaggio non regolare (probabilmente i "salti" non saranno molto evidenti, comunque ci saranno), o lavori solo con interi, ma alla fine qualche deriva da qualche parte la accumuli ...

Giusto come idea ...

Infatti....
quindi concordi con me che probabilmente il problema deriva da troncamenti di decimali durante la formula di moltiplicazione, come scritto nel primo post ?
Se cosi' è; credo di aver fatto bene a passare dalla libreria originale neopixel.h alla fastLED.h che ha funzioni dedicate anche a questi casi da quanto ho potuto leggere nella wiki.

Grazie 1000 per le risposte.

Per variare la luminosità di un qualsiasi colore, mantenendo il colore, forse è meglio lavorare in modalità HSV invece che RGB, così tra l'altro è possibile anche variare solo la saturazione mantenendo colore e luminosità.

Googlando si trovano diversi algoritmi di conversione RGB --> HSV --> RGB.

A tutto questo si dovrebbe anche apportare una correzione dipendente dall'occhio e dal tipo specifico di LED, ma non so se si può fare senza appositi strumenti.

Claudio_F:
Per variare la luminosità di un qualsiasi colore, mantenendo il colore, forse è meglio lavorare in modalità HSV invece che RGB, così tra l'altro è possibile anche variare solo la saturazione mantenendo colore e luminosità.

Googlando si trovano diversi algoritmi di conversione RGB --> HSV --> RGB.

A tutto questo si dovrebbe anche apportare una correzione dipendente dall'occhio e dal tipo specifico di LED, ma non so se si può fare senza appositi strumenti.

Ciao Claudio,
grazie per il tuo contributo!
Effettivamente credo che tu abbia ragione!!! Credo che questo possa essere la soluzione corretta al mio problema iniziale!! Non me ne intendo affatto di spazi di colore e HSV, ho iniziato a capire il funzionamento proprio cercando di capire come funziona la libreria FasLED.h, ma visto che i valori sono convertibili, credo che possa funzionare.
Ho trovato le formule di conversione e un tool per la simulazione qui!

Grazie ancora, perche' sono convinto che questa sia la dritta giusta !!!!!!

http://www.rapidtables.com/convert/color/rgb-to-hsv.htm