Question Arduino implementation

[kasperkamperman]

I try to implement your code in Arduino, by storing the array in PROGMEM and using it to modify pixel values. I use FastLED so my updates are fast (about 1ms for noise, sending pixels and more)

Still I don't get the right effect, so I might still miss something. What happens in the two functions below?

#define fb2color(n,shiftin,shiftout) ((gammaTableDithered[ (n>>shiftin)&0xff ])<<shiftout)
#define adjustRGB(rgb)  (fb2color(rgb,16,0) | fb2color(rgb,8,8) | fb2color(rgb,0,16))

What does do parts fb2color(rgb,16,0) etc. do? Right now the gamma is not stable, but different colors get a different brightness. The primaries (r,b,g) are really bright the other colors not.

I ported your code to Arduino like below. I hope you can help.

for (int i=0; i <NUM_LEDS; i++)
{ 
     CRGB pixel = CHSV(hue,255,noise[i]);

     pixel.r = pgm_read_byte_near(gammaTable + (ditherFrame<<8) + (pixel.r));
     pixel.g = pgm_read_byte_near(gammaTable + (ditherFrame<<8) + (pixel.g));
     pixel.b = pgm_read_byte_near(gammaTable + (ditherFrame<<8) + (pixel.b));

     leds[i] = pixel;
}

ditherFrame++;
if(ditherFrame>15) ditherFrame = 0;

FastLED.show();

In this post on the FastLED support site I refer to your code:
https://plus.google.com/100115767703084101160/posts/483GAFbQJiL

[raplin]

Hiya,
Yes it's both gamma correction and temporal dithering in one; the sample code on here uses 16 sets of gamma-correction tables (although you can use supplied python file to generate e.g. 8 or 4 sets) - this relies on quite fast updates to work without flickering, I use 110hz (max rate for the 300-led strips I'm using) and a 16-page dither pattern still causes (very minor) flicker; you'd want to use the best tradeoff given your update rate. If you're updating at 60hz or less you'd definitely want only a 2 or 4 stage dither. It's totally worth doing the dithering on WS2812's because their brightness resolution is rather poor at the low end. The "fadecandy" code is similar and that uses 400hz update (meaning short WS2812 strips are necessary, 64leds max) and at that speed you get great results from dithering. The Teensy 3.1 is enormously faster than an Atmel AVR-based Arduino and it does all the LED output with DMA; I very much advocate using the Teensy, it's a monster compared to an AVR in every way (32 bit, more efficient CPU, much more ram/flash, more hardware, basically just 'better') and barely any more expensive. I'm not dissing the AVR, I've enjoyed it for years, but we live in the future now :-)
Anyway; if your WS2812 update rate is e.g. 30hz you should regenerate the dithering/gamma table to only be 2 stage (which will save you considerable memory also) or you'll get objectionable flickering. You will of course also lose resolution a low intensities, but them's the breaks.
To specifically answer your q: the 'fb2color' is just a macro; my LED data is stored in int32's (0RGB, 8 bits each) hence the macro is just extracting each 8-bit color component. On AVR this is inappropriate anyway b/c it's an 8-bit CPU; treating RGB as 0RGB 32-bit word will just be inefficient. On Teensy it's a good idea b/c it's a 32-bit cpu. LMK if any more q's

[kasperkamperman]

Thanks. I'm still figuring out why my effect dims when moving over the colorcircle, but probably some double gamma correction is going on.

I'll check you code on a Teensy as well (running Fadecandy right now). Fadecandy looks good, but I want something standalone. Is it possible (with your method) to get the same smooth effect? And do I need to modify then something (more bits dithering, 64 pixels for each output?).

[raplin]

Yes, my code and fadecandy are quite similar; there is a #define in my code header file for 8 or 16 channels of WS2812B's - the 8chan version is better tested. There's also a #define for number of LEDs on each strip - the less LEDs you have the faster the update will be (and hence the better the dithering will work); should be easy to set it to 64 leds per strip (or whatever you're using). In that case you may choose to regenerate the lookup table (with supplied python) for more dither bits. Generally 4bits of dither (16 sets of tables) gives quite good results; more than that may be unnecessary. My code is a little more efficient than fadecandy but on a Teensy3.1 the results should be similar.

[kasperkamperman]

Clear. Thanks!

On 20 September 2014 07:54, Richard Aplin notifications@github.com wrote:

Yes, my code and fadecandy are quite similar; there is a #define in my
code header file for 8 or 16 channels of WS2812B's - the 8chan version is
better tested. There's also a #define for number of LEDs on each strip -
the less LEDs you have the faster the update will be (and hence the better
the dithering will work); should be easy to set it to 64 leds per strip (or
whatever you're using). In that case you may choose to regenerate the
lookup table (with supplied python) for more dither bits. Generally 4bits
of dither (16 sets of tables) gives quite good results; more than that may
be unnecessary. My code is a little more efficient than fadecandy but on a
Teensy3.1 the results should be similar.

—
Reply to this email directly or view it on GitHub
#1 (comment).

[kasperkamperman]

How do you calculate the amount of bits with the update speed. For example if I reach 400Hz, how many can I handle then?
With an 8 bit table (luckily Teensy has a lot of memory) I notice a slight flicker (don't know if that due dithering or other reasons), so I was wondering if that isn't too much.

How does your dithering compare to Fadecandy? I've read that Fadecandy does internal processing in 16 bit and then uses those values with dithering in 8 bit. However in your case the input is 8 bit already.

[raplin]

The number of bits (i.e. number of different 255-entry tables) is something you pick based on your preference - but mainly based on the update rate. When showing low-brightness values (0-30) you may see some flickering; this is expected of course, you should adjust # bits to suit your application, the update rate you can achieve (mostly), and personal taste. Try seven bits, try eight, see what works best for you.
I use really long strings of LEDs (300 per channel) so I get ~110hz (fixed by the WS2812), which limits what you can do with no visible flicker.

Fadecandy; well, it's a matter of visual preference. Certainly she does a terrific job. I take an 8-bit (0888RGB) value - which is enough for me - and display it.
IMHO 8-bit is a reasonable amount of intensity resolution for a display that appears eye-linear (i.e. each step looks the same, but is in fact converted to more bits when displayed to account for the extreme non-linearity of the eye) but there's no denying that PC-graphics people frequently uses >8 bits. Whatever works best for you in a limited environment. My dithering is basically the same 'trick' as fadecandy, but we work within different constraints.

[kasperkamperman]

FastLED outputs both 0 and 1 as 0. So actually light output starts at 2. This is intended by the makers. See: FastLED/FastLED#86

Now a Python n00b question. Where do I add +1 to the output values in the table? At first I though I would remove -1 from this line gamma=pow(255,(n/256.0))-1, but then I get 12 rows instead of 16 when using 4 bits dithering.

Adding +1 in this line res+="\n\t"+(",".join([ "0x%x"%n for n in out])) after %n also seems to give an altered table.

Of course I can run the result through a program of myself (I use Processing), but if I can modify it in your script directly it would be nicer of course.

[raplin]

Checked in a special tweak ('finalAdjust' line 11) of gamma.py for you

[kasperkamperman]

Thanks!

[kasperkamperman]

I'm trying to implement a luminance curve in your script. See:
http://ledshield.wordpress.com/2012/11/13/led-brightness-to-your-eye-gamma-correction-no/

However I think I miss something (probably I don't get the inner workings of Python right). The curve is applied but the dithering not. All the rows are just equal.

I hope you would take a look. I run it in the Python mode of Processing, so it could be that some command are not standard support by Python (like the map and println). Although I don't think the error is because of that.

https://gist.github.com/kasperkamperman/e7a990d6af49f4cbed32

[raplin]

Kasper pointed out that it's not really gamma correction, it's luminous-response-correction, which is absolutely right

[raplin]

Just checked in CIE 1931 luminance instead of old logarithmic from http://forum.arduino.cc/index.php/topic,147810.0.html, just looking at the raw lookup table it's brighter at the low end; not tried on real LEDs yet, see what you think.

[raplin]

Thanks checked in that curve instead

On Mon, Oct 27, 2014 at 1:38 PM, kasperkamperman notifications@github.com
wrote:

I'm trying to implement a luminance curve in your script. See:

http://ledshield.wordpress.com/2012/11/13/led-brightness-to-your-eye-gamma-correction-no/

However I think I miss something (probably I don't get the inner workings
of Python right). The curve is applied but the dithering not. All the rows
are just equal.

I hope you would take a look. I run it in the Python mode of Processing,
so it could be that some command are not standard support by Python (like
the map and println). Although I don't think the error is because of that.

https://gist.github.com/kasperkamperman/e7a990d6af49f4cbed32

—
Reply to this email directly or view it on GitHub
#1 (comment).

[kasperkamperman]

Nice! Indeed it's brighter at the low end, but also brighter at the high end. You can make it less bright by not using the <8 formula. Then you would get a similar result at the low end as the gamma curve.

[kasperkamperman]

spellcheck: useRealLuminanceCalcuation > useRealLuminanceCalculation

Maybe the files and array can be named luminanceLUT instead of gamma (at least then it will be inline with your story).