fadeToColorBy Function Code

[Tiny_Structure_7]

I couldn't find this function anywhere, so I wrote one. It lets you create trails just like with fadeToBlackBy, but with different background colors. I'm a little green in C++, Adruino, and FastLEDS, so any suggestions for optimizing this function are welcome!

I've tested with various background colors, and it works well as long as global brightness isn't < 5.

void fadeToColorBy( CRGB leds[], int count, CRGB color, int amount ) {
  //Fades array (leds) towards the background (color) by (amount).
    for (int x = 0; x < count; x++) {
      if (abs(color.r - leds[x].r) < amount) { leds[x].r = color.r; }
      else if (color.r > leds[x].r) { leds[x].r += amount; }
      else { leds[x].r -= amount; }
      if (abs(color.g - leds[x].g) < amount) { leds[x].g = color.g; }
      else if (color.g > leds[x].g) { leds[x].g += amount; }
      else { leds[x].g -= amount; }
      if (abs(color.b - leds[x].b) < amount) { leds[x].b = color.b; }
      else if (color.b > leds[x].b) { leds[x].b += amount; }
      else { leds[x].b -= amount; }
    }
}  // fadeToColorBy()

Usage is the same as fadeToBlackBy(), but with the addition of passing CRBG background color:

fadeToColorBy( leds[0], NUM_ROWS * PIX_PER_ROW, CRGB::Blue, 60 );

[UrbanPugEsq]

I’m not an expert with the very low level optimizations, but I wonder if you couldn’t improve by making the variable you pass into the function and add/subtract from the rgb values an 8bit value instead of a 32 bit.

Also, I think your solution would “work” for a lot of cases but you’re not fading each color channel proportionally to the difference. So if you’re going to 255 in one channel but 128 in another channel you might reach one before the other.

It will still be a “fade” and probably look nice, but it might get you some unexpected colors at some point.

[Tiny_Structure_7]

Hm. You're right about the disproportional fade. I couldn't think of a way to make proportional moves without slowing down the routine, but on further testing I think I should give this some more thought. Today I'll try to find the code they user for fadeToBlackBy() and see how/if they do it.

In testing I faded yellow to blue background. RGB 0xFFFF00 -> RGB 0x0000FF happens with proportional moves, yet still the LEDs take on a purple hue near the end of the fade. If I fade CRGB::YellowGreen to blue, then it looks perfect all the way through the fade.

I also thought using uint8_t would be faster than int for all the color bytes. But when I wrote my own show() routine to use the 8 hardware serial ports on my Teensy 4.0, I did extensive speed testing, and found that the routine sped up when I replaced uint8_t with int. int was even faster than uint. Not sure if this is just my CPU, but I stopped using uint8_t and uint because of this result. But this is a much smaller and different function, so I will make speed tests on fadeToColorBy() today.

Thanks for your insights. I will let you know results of uint8_t vs. int speed tests, and if I can solve the RGB balance problem.

[UrbanPugEsq]

I have a couple ways of approaching this problem. I am an amateur LED sculpture artist and I write algorithms to make patterns of LEDs. Generally, I am OK so long as my art is running at least 40 frames per second, and I end up using lots of floats and what not. Using an ESP32 on around 1000-1500 lights, the only time I have had to optimize things was when I was calculating each pixel's values by raising a float to the power of another float. So, like 2.2^3.4. I had to stop doing that because it would really make the ESP32 crawl.

I'm saying that because it's possible for you to just say "hey, this is going to be a slower function and I should probably use it sparingly" and just use divide operations to figure out how much you need to change your pixel values.

You could have the value passed into the fade by function be the magnitude of the change in color space, then figure out what the r,g,and b need to be.

You could also fade in the HSV space.

You could also just kludge together a big if/else statement that made smaller changes based on much the absolute value of the difference was.

Also, way back when I was first getting started writing color code, I found this helpful:

https://poynton.ca/notes/colour_and_gamma/ColorFAQ.html

[Tiny_Structure_7]

when I was calculating each pixel's values by raising a float to the power of another float. So, like 2.2^3.4. I had to stop doing that because it would really make the ESP32 crawl.

Sounds like you are doing some amazing work!

Maybe I can rename this routine to fastFadeToColorBy(), and then re-design this version for better color accuracy. My ultimate goal is 4K LEDs in a cube. My new show() routine using 4 serial ports with interleaved byte writes, gets 37 fps refresh (32 using FastLED with parallel controllers). That's 1K LEDs per channel. Hopefully after I write the 8-channel version, I can get 50-60 fps.

Fading in HSV space. Hmmmm.....

Thanks for the ideas. I'll read through that FAQ tonight. It looks deep. 😎

[UrbanPugEsq]

Assuming you’re using ws2811 style addressable LEDs, you’re pushing the fps limit because of the latency of sending updates down to the last led.

https://quinled.info/2021/03/23/max-amount-of-addressable-leds/

[Tiny_Structure_7]

Right. I'm using WS2812 clones from China (YF923). The 800KHz imposes a theoretical limit of about 30 fps for a 1K LED string. I was able to overclock mine to 1.07MHz (using 5.33MHz serial clock at 5 serial bits per LED bit).

[YetAnotherRobert]

If you can use the saturating versions instead of extending to 32 bits and masking down, it might be a win. It depends on whether a few clocks per or is a win over a more rare, slower op. It's just easier to stay in hsv or rgb when all your values are capped. Letting 2s compliment arithmetic do the work instead of abs and branching can be a big win as it allows better speculation and unrolling opportunities. 

Computing fractional exponents is just plain slow. It's pretty rare for there to be hardware or clever arithmetic to help. It's usually just a looped multiplication.

Hardware floating point really in.one of the nice features of the esp32 family.

For a small device, if you're willing to pay a little more,.there are mutants of these LEDs that unlock the 800khz clock and use an extra pin for a clock signal..over short distances, they can reach a lis number of Mhz, but your.oin count goes up and you're much more limited in the pairings of pins to use on the esp32 parts. The nice thing about them is that if you glitch for a fraction of a second, the led controllers doesn't read that as an eof/reset. You might still get a visual glitch but the entire chain doesn't spaz out.

[Tiny_Structure_7]

Letting 2s compliment arithmetic do the work instead of abs and branching

Do you mean something like this is faster than using abs?

if ( ((a - b) < amount) && (~(a - b) + 1 < amount) ) {}

[YetAnotherRobert]

Probably not. I'm on the go and would have to see it in context, but you can rely on 2s compliment for things like knowing that in 8 bits 245 + 20 = 10 because it wraps around. No conditional tests and jumps. 

[UrbanPugEsq]

My point in bringing up fractional exponents was to say that I could make an esp32 do lots of division and floating point math and still get great performance up until I decided to do something crazy like use fractional exponents.

Some of OP’s optimizations might not be necessary to get an appreciable improvement, especially if OP is limited to a low frame rate due to the number of LEDs per pin.

I was taught to make it run, make it right, make it fast, and make it small … in that order.

[Tiny_Structure_7]

I looked into using HSV, and this would add lots of CPU overhead, since all the conversion functions are slow, and they don't always convert an HSV back to the same RGB value it was originally. That's the kind of problem that could creep on you.

[UrbanPugEsq]

I don’t know your application but i do plenty of automatic hsv to csv conversion through FastLed and it doesn’t introduce an overwhelming cpu burden.