Think I bumped into an issue with how blend is working between two colors.

Think I bumped into an issue with how blend is working between two colors. Was trying to set up a simple tween between LEDs to make animations that are very slow smoother. Essentially if we can run at 200fps but we’re only moving an LED every 10th frame then this would calculate the current frame and the next frame and blend between them over the 10 frames. Its simple but makes slow sweeps and things look way smoother.

Anyway I set this up by calculating a previous frame and a next frame buffer and then using the blend command to get the in between frames which I then pass to my LED array. I got some weird flickering, especially on the dimmer end of a sweep tail so I did some investigating and found that the blend function is returning some strange values.

I’m using FastLED 3.1 on an arduino duemilanove/leonardo using the old arduino 1.0.6 IDE. I’ll pastebin the testing sketch I’m using as well as some of the Serial output below.

http://pastebin.com/vVFrJxz6 - Test Sketch

http://pastebin.com/RMKSeV8p - Blend data

http://pastebin.com/PfHmStF8 - Blend data 2

http://pastebin.com/PTgy3bgs - Blend data 3

I’ve highlighted some of the anomalies in the data, but heres a summary.

-When Blue channel is blending from 100 to 100 (no change) it goes down to 99 for the entire 0-255 blend range.

-At blend point 128 all the values will round up it seems, then at 129 they will be one point lower so we have a slight bright hiccup.

  • When blending from 3 to 1 in the Red channel the values went to 0 for part of the range and this seems common whenever lower numbers are blended.

Looks like there are just some rounding issues in the calculations or possible just artifacts of doing this kind of division in single byte precision. Would be interested if any one else can confirm this or if there is a better more reliable way to blend between two LED color buffers without this kind of artifacting.

Thanks, I’ll take a look at it this evening and let you know!

So the artifacts you’re seeing are exactly what you suspected: small rounding and loss of precision due to heavy use of 8-bit integer math.

I have some updates in the queue for the blend functions and as part of that I’ll see if I can also make small corrections to these.

I definitely appreciate this question/ bug report and all the concrete data!

Great, I look forward to updates for the blend function to see if they sort this for me and in the meantime I’ll prob. just roll my own higher precision blend function since I’ve got the extra cycles available.

I think that’s the right call in this case: burn a few extra CPU cycles to make the effect just right looking.