Calculation of brightness

[Paul Barnett]

I've been playing with different ways to display activity on a LED strip, and started looking at the actual calculation of brightness.   I don't know the history or evolution of the calculation, but I'll simply describe what I've found.

This is the calculation in update_lights:

    brightness = matrix - mean + (std * 0.5)

    brightness = (brightness / (std * 1.25)) * (1.0 - (attenuate_pct / 100.0))

    brightness = clip(brightness, 0.0, 1.0)

For this discussion, attenuation is not enabled, so that's not a factor.

In practice, this effectively clips brightness to a very narrow range.  I think it would be easier to understand if I use actual numbers:

mean = 10

std = 2

If the actual value for this interval is 9 or less, the brightness will be 0.0 (off)

If the value is 11.5 or higher, the brightness will be 1.0 (maximum)

Between these two values, it will increase at a linear rate.

The net effect: only values between -0.5SD and +0.75SD will result in any variation in brightness.  Everything outside this range will clip to 0.0 or 1.0.

To understand the effect, here's a bell curve that explains how a normal distribution of numbers will fall within the SD thresholds:

If you have difficulty reading the image, here's the direct link:  https://www.mathsisfun.com/data/images/normal-distrubution-large.gif

The graph doesn't show 0.75SD, but -0.5SD to +0.75SD will encompass only 46.48% of a normal distribution of random values.

I realize that a particular music track is unlikely to be normally distributed, but this appears to impose a significant limitation on range of brightness, and skew it a bit to the "higher" side of the mean.

I've tried this calculation:

    SD = 1.0

    brightness = matrix - mean + (std * SD)

    brightness = (brightness / (std * SD * 2.0)) * (1.0 - (attenuate_pct / 100.0))

    brightness = clip(brightness, 0.0, 1.0)

With this code and the same mean/std, a value of 8.0 and below yields a brightness of 0.0, and a value of 12.0 and above yields a a brightness of 1.0.  This encompasses 68.27% of a normal distribution.  

I got better results, but I'm sure it's subjective, per the viewer and the music track.  But, even SD=0.75 looked better to me, because quieter portions of the track displayed some light activity where it was completely dark with the original calculation.

So, my suggestion is to "recenter" the calculation, so that brightness for a channel is varied from -xSD to +xSD -- whatever x may be.  And, I'll also suggest making x (the standard deviation) a configurable parameter, and default it to 0.75 to retain almost the same behavior.

[Todd Giles]

It is definitely subjective - the range of -0.5SD and +0.75SD came from me subjectively playing music with my lights on my house until I thought the 2 or 3 songs I was most interested looked good ;)

I'm happy with your suggestion, in particular making the SD param configurable and we can start with it centered.  If I (or others) subjectively would like to go back to an un-centered brightness calculation we could add and SD_low SD_high param to allow people to tune it as they'd like.

Given the per-song overrides, having this type of control would be nice.

--
http://www.lightshowpi.org/
---
You received this message because you are subscribed to the Google Groups "LightShow Pi Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lightshowpi-d...@googlegroups.com.
To post to this group, send email to lightsh...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lightshowpi-dev/42cccf6c-6e4f-4297-8032-97af86946202%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Paul Barnett]

Are there per-song overrides now?  Is it something in the playlist, or something yet to be implemented?

On Tuesday, February 9, 2016 at 2:25:49 PM UTC-6, Todd Giles wrote:

[edited]

[Todd Giles]

Yes there are, at least in the master branch.  See https://bitbucket.org/togiles/lightshowpi/issues/6/allow-for-per-song-configuration-overrides for more details.

To view this discussion on the web visit https://groups.google.com/d/msgid/lightshowpi-dev/e5bc6a18-0afe-4520-83b1-18cc5a0c003f%40googlegroups.com.

[Tom Enos]

So something like

    brightness = matrix - mean + (std * sd_low)

    brightness = (brightness / (std * sd_hight)) * (1.0 - (attenuate_pct / 100.0))

Except read from the config and/or the per song config.

 

sd_low defaults to 1 and sd_high defaults to 2?

Or did I over simplify it and mix things up?

[Paul Barnett]

No, it would be:

    brightness = matrix - mean + (std * sd_low)

    brightness = (brightness / (std * (sd_low + sd_high)) .....

And the defaults that would maintain exactly the same behavior as currently implemented:

    sd_low = 0.5

    sd_high = 0.75

Todd, check my math -- I think I got it right.....

[Paul Barnett]

A correction, the second line is missing a trailing parentheses:

       brightness = (brightness / (std * (sd_low + sd_high))) .....

[Todd Giles]

Paul - yes this last one is correct.

To view this discussion on the web visit https://groups.google.com/d/msgid/lightshowpi-dev/e145181f-f1ba-43bd-8046-d375364e062b%40googlegroups.com.

[Tom Enos]

Paul, if you need any help adding it to the custom config let me know.

[Paul Barnett]

Thanks, Tom.  Writing the code should be relatively easy.  But, I will probably need some help getting it checked into the master branch.

[Tom Slick]

Not a problem.  I can walk you through from git clone to git push

To view this discussion on the web visit https://groups.google.com/d/msgid/lightshowpi-dev/eff93153-083e-434b-9e7c-dac96e749150%40googlegroups.com.

[Paul Barnett]

Tom, I've been out of the country, and dealing with some other projects at home... but finally am coming back to this.

Can you send me a "cheat sheet" of the basic things I need to do?  I can probably skip forking/branching, so I think it's:

git clone (of master branch)

code/test changes

git add (files that have changed)

git commit

git push

I think that creates a branch for my changes, which aren't merged into the master branch until someone has reviewed them.

There may be some steps needed before the push to fetch from the central repository and sync it before I push, depending on whether anyone else has made changes.

[Tom Enos]

First you will need to fork the repo on bitbucket.    

navigate to https://bitbucket.org/togiles/lightshowpi/overview    

then click fork on the left side bar menu.

follow the prompts and you will have your fork to work on    

Next you will want to clone your fork to your local machine    

git clone (url from the top of your forks overview page)

Then the rest is as you stated.

code, test

git add

git commit

git push

then you will need to create a pull request from your fork back to Todd's repo.  It will then be reviewed, if changes are needed then you make the changes and push the commits to your repo, they are automatically added to the pull request so you don't need to create a new one.   

[Paul Barnett]

Ah, so I need to create my own account on bitbucket.  

I was wondering if I need to do that.   Everything follows from that. :-)

Thanks!

You received this message because you are subscribed to a topic in the Google Groups "LightShow Pi Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/lightshowpi-dev/AnTC1nSBzUc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to lightshowpi-d...@googlegroups.com.

To post to this group, send email to lightsh...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lightshowpi-dev/f40fe9ea-ab13-4bfb-b5c6-480d5f6dba80%40googlegroups.com.

[Paul Barnett]

Todd, Tom, and anyone else that is interested......

I finally submitted a pull request for the configuration options to specify the standard deviation (low and high).  The options are supported in both the LightshowPi configuration file, and the per-song configuration files.

I've actually had the code done for a couple of weeks, but I wasn't able to take the time to test it completely until today.   I used the debugger to stop at the point of calculation in update_lights(), and confirmed the correct SD_low and SD_high were being used.

I'm about to depart for a short trip to visit my wife's family, but I'll be back the middle of next week.  Until then, I'll be receiving my email, but won't have access to anything else.  I'd take my RPi Zero, but I don't expect to have all the peripherals I need to actually use it!