I did a test with sqrt blending (see: https://plus.google.com/+KasperKamperman/posts/jkACVWijSDN) and it’s indeed worth it. Blending from red to green is way nicer and brighter.
The code is linked below. I’ve used the build in Lib8tion functions sqrt16 and scale16by8: https://gist.github.com/kasperkamperman/b0d0d8058246d674dd01
@Mark_Kriegsman Is there already an implementation to make sqrt blended color palettes? You were talking about that in the last post. Is there a sqrt that you prefer that returns 16bit values? I came across different ones (http://stackoverflow.com/questions/1100090/looking-for-an-efficient-integer-square-root-algorithm-for-arm-thumb2).
Yeah, the quadratic blend is much prettier. I’ll be adding QUADRATICBLEND at some point.
I don’t have any 32-to16 sqrt handy myself. They’re all probably ok… and if not, a stopwatch will help decide which is best…
As a matter of interest, what was the time impact of using the more math intensive blend?
All my 'duinos are in projects currently so don’t have anything to compile to.
2232us vs. 11984ms for 255 leds on an Arduino UNO. So the impact is pretty big. It about 5 times as much, I remember that on a Teensy 3.0 the sqrt Blending took 2500us for 255 leds.
I’m trying to update the code for 32bit sqrt. I’ve tested the algorithms and the 32bit version is even faster (on a Teensy) then the 16bit version. It also works good… However I try to scale up my 8bit values to 16bit values, just as a test to implement it later in the colorpalette generation code (which works with 16bit).
When I scale it down later (>>8) I get a really dim output. Scaling it down with (>>4) gives kind of a good result, but I have no idea why (and it’s also not perfect). Probably I lose some precision on the road?
Anyone an idea why?
I solved it with help of Daniel on Gitter. Correct code now on gist: https://gist.github.com/kasperkamperman/b0d0d8058246d674dd01