Author Topic: Gamma correction or simple Intensity correction per channel  (Read 1522 times)

Offline JonB256

  • Supporting Member
  • ******
  • Join Date: Mar 2013
  • Location: Granbury, Texas
  • Posts: 3,690
  • Kudos: 77
    • Granbury Christmas Lights
Gamma correction or simple Intensity correction per channel
« on: September 04, 2014, 01:21:38 PM »
I mentioned this in a Nutcracker thread but this is a better place (and in the uSC forum)

My problem late last year was the addition of two new TM1804 bullet pixel strings to an existing matrix.
The two new strings were noticeably brighter than the eight older strings. (all 10 were from Ray)

While it may be eventually possible in Nutcracker to control Gamma or color correct on a "per strand" basis, it occurs to me that a Firmware/Software addition to the Falcon 16 might be easier and make more sense.  I got the idea when I noticed that the PixLite16 E1.31 controller had a gamma correction choice for "some" pixel strings (12 bit chips). My TM1804 and TM1809 strings are 8 bit chips. :(

But, could the processor on the Falcon 16 support doing a Gamma or simple Brightness adjustment "on the fly" ??

In its simplest form, it could just "subtract" a value from each color value being sent to RGB.  Sure wouldn't be linear or color correct, but it could help with my brightness problem.

Offline Steve Gase

  • Supporting Member
  • ******
  • Join Date: Mar 2013
  • Location: Georgetown, TX (near Austin)
  • Posts: 1,037
  • Kudos: 5
    • WinterLightShow in Georgetown, TX
Re: Gamma correction or simple Intensity correction per channel
« Reply #1 on: September 04, 2014, 05:23:11 PM »
i can see why a hardware (firmware) solution is attractive -- it offers a fix not just for xlights/nutcracker but also LSP, HLS, or any other software solution out there...

But I personally think a software feature in xlights and/or FPP is more powerful -- it can be applied to all of the various hardware solutions available, and not all of those solutions are as agreeable as the falcon platform team.
http://WinterLightShow.com  |  110K channels, 50K lights  |  Nutcracker, Falcon, DLA, HolidayCoro

Offline David Pitts

  • Administrator
  • *****
  • Join Date: Mar 2013
  • Location: Falcon, CO
  • Posts: 3,670
  • Kudos: 63
Re: Gamma correction or simple Intensity correction per channel
« Reply #2 on: September 04, 2014, 06:08:37 PM »
Interesting idea. Would this feature be a scaling of the RGB channel data. It sounds like you want brightness control at the string level. Where gamma correction is something else. That is more related to making the lights look more linear using non linear gamma table.
PixelController, LLC
PixelController.com

Offline JonB256

  • Supporting Member
  • ******
  • Join Date: Mar 2013
  • Location: Granbury, Texas
  • Posts: 3,690
  • Kudos: 77
    • Granbury Christmas Lights
Re: Gamma correction or simple Intensity correction per channel
« Reply #3 on: September 04, 2014, 07:21:26 PM »
Interesting idea. Would this feature be a scaling of the RGB channel data. It sounds like you want brightness control at the string level. Where gamma correction is something else. That is more related to making the lights look more linear using non linear gamma table.

Well, David, that may depend on the programmer! :)  Gamma correction could definitely make strings of LED pixels more linear (since they are so non-linear). That's where the 8-bit (256 levels per color) weakness shows itself.

A few years back, I created a gamma table for my D-Light AC controllers. The DMX firmware allowed for up to 8 stored tables to be assigned to any of the 16 output channels (single color, 120vac lights). Pretty rough but still workable.

This request would be satisfied with a more simple brightness control, just to match my strings. Subtracting a value of 10 or 20 from the transmitted RGB would probably do it, though I know that would make them even more non-linear than they already are. I know from personal testing that dimming an LED from 255 down to 0 is very smooth. But dimming it from 235 to 0 (since there can't be a -20) would be less smooth.

I guess I'd like to kick the possibilities back and forth to find a best match between what is possible and what others might want. I fully agree with Steve Gase, but see this as an easier fix for my problem.

If it would help, the DMX Code for the D-Light AC-16 controllers with dimming tables is available. It was written for PIC controllers.




Offline David Pitts

  • Administrator
  • *****
  • Join Date: Mar 2013
  • Location: Falcon, CO
  • Posts: 3,670
  • Kudos: 63
Re: Gamma correction or simple Intensity correction per channel
« Reply #4 on: September 04, 2014, 08:08:00 PM »
The code is not necessary. I think it could be a 2015 task. Maybe. :)

Offline JonB256

  • Supporting Member
  • ******
  • Join Date: Mar 2013
  • Location: Granbury, Texas
  • Posts: 3,690
  • Kudos: 77
    • Granbury Christmas Lights
Re: Gamma correction or simple Intensity correction per channel
« Reply #5 on: September 04, 2014, 08:34:24 PM »
I understand. I can wait. Truly a wish list item (not Wish Liszt)

Offline CaptainMurdoch

  • Administrator
  • *****
  • Join Date: Sep 2013
  • Location: Washington
  • Posts: 7,859
  • Kudos: 140
Re: Gamma correction or simple Intensity correction per channel
« Reply #6 on: September 04, 2014, 09:01:07 PM »
One of the items I have considered for my FPP TODO list is having a sort of sequence pre-processor.  This would be in-line, it wouldn't be anything that a user had to do to enable it.  The concept would be that we would store a cached copy of the processed sequence file after we applied things like channel remaps, etc. to it.  Then, the next time we went to play it, if the original had not changed, we would just use the cached pre-processed file instead of having to apply the same remaps.  Gamma or brightness correction could be one of these pre-processing actions.  We'd need to clear the cache on daemon restarts or potentially just certain settings changes, but it would save a bit of CPU time when playing the same sequence over and over.  I prefer to pre-process rather than burning CPU cycles doing the same action over and over every time we play a sequence and then essentially throwing away the work.

When we had the technicolor issues last year, I think it was Steve who wrote a perl script to apply this type of brightness pre-processing to a sequence file so we could run our technicolor strings at a lower brightness to try to prolong their life.
-
Chris

Offline Daweeze

  • Newbie
  • *
  • Join Date: Aug 2016
  • Location:
  • Posts: 2
  • Kudos: 0
Re: Gamma correction or simple Intensity correction per channel
« Reply #7 on: August 28, 2016, 08:09:05 PM »
Dave,

So I started playing with my new F16v2-R last night and wow...what a great controller.  I have a couple of props that I had made that have different pixel types (square nodes and rectangle modules).  I am using the virtual string option which is amazing.  This allowed me to flip the RGB to GRB once I hit the 23rd pixel where the WS2801 rectangle modules in the string begin.  Next I started to sequence some tests in LOR and that's where the frustration began.  The two different node types though WS2801 show color representations in a very different way.  Not that they are tremendously far off but they need color correction for sure.  With that said, I looked for a gamma correction option which led to this old thread.  It would be amazing if we could get something like the following:


Primary RGB Color Test:


Red
Green
Blue


Secondary RGB Color Test


Cyan
Magenta
Yellow


Tertiary RGB Color Test


Azure
Violet
Rose
Orange
Chartreuse
Spring Green


The String based (or in this case Virtual String as well) would be very helpful.  For instance, in LOR, I use the value 255,128,0 for orange which shows nicely as orange on the screen in the sequencer but is extremely yellow based on my pixel output.  Instead I have to use 255,32,0 which is an amazing orange on the pixels but in the sequencer is almost completely red and misleading.  This leads me to have to create custom colors for standard color needs to correct the output as well as the sequencer colors themselves really do not give a representation of the intended color.


If Gamma offset could be added to the String/Virtual Strings, then standard colors could be used in the sequencer and represented properly on the pixels.  Also, we could color correct our pixels outside of the sequencer at each level by just using test mode on the controller!


LOR apparently added it to their PixCon16 controller so it is a feature on modern controllers in use.  I attached a pic of the settings example they are using to adjust the gamma settings.  What do you think?


Thanks for the amazing controller!!!


-Travis


Offline zwiller

  • Falcon Beta Team
  • **
  • Join Date: Mar 2013
  • Location: Sandusky, OH
  • Posts: 872
  • Kudos: 11
Re: Gamma correction or simple Intensity correction per channel
« Reply #8 on: December 09, 2016, 05:36:36 AM »
If this is not difficult to do, some basic correction would be a good idea.  Everything coming out of china is all over the place.  Something to possibly explore in 2017. 
Sam

Last year's video: https://vimeo.com/150560653

 

Back to top