12-bit pixels now supported on the Sandevices E680 RGB pixel controllers

jstjohnz

Apprentice elf
Joined
Sep 19, 2010
Messages
97
Location
Indianapolis, IN
This is a project that I've been working on for some time, and I'm happy to announce that the TLS3001, a 12-bit RGB pixel, is now fully supported on the Sandevices E680/E681 series of RGB pixel controllers. Why is this important? Even though DMX channels are only 8-bits, having a total of 4,096 intensities available allows those 256 DMX values to be mapped to specific values in the 0-4095 range to produce a more natural dimming curve.

Those who have worked with LED lights in general, or RGB pixels in particular, have probably noticed that the dimming curve doesn't appear smooth to the eye. That's because our eye's response to light is very non-linear; small intensity changes at the low end are very noticeable, whereas the same intensity change at the high end would go unnoticed. So, to the human eye, a typical LED appears to dim very slowly at first, then abruptly towards the low end. The difference between full off (0 intensity) and an intensity level of 1, is a pretty big jump, but you'd probably never notice the difference between an intensity of 230 (90%) and 255 (full on)

That's where the extra dynamic range of the 12 bit pixels really shines. By implementing a mapping curve, also known as gamma correction, we can make the level changes at the low end be very small, then gradually increasing until they become much larger at the bright end of the curve. Then, to the eye, the dimming response of the pixel becomes much more natural, much more like the dimming we are used to with incandescent bulbs. If you have both incandescent lights and pixels in your display, the LEDs will more closely track the incandescents when dimming.

The second advantage has to do with displaying images, whether still, or motion, on a large array of pixels. The linear dimming curve of an uncorrected LED makes it very difficult to display accurate shades of brightness, so a lot of image detail can be washed out. By employing gamma correction at the pixel level, it allows images to be rendered with much more detail.

Finally, the extra resolution allows you to select a master dimming level at the controller, say 25%, 50%, 75% or 100% of full brightness, either to compensate for changes in ambient lighting, or to reduce power requirements and voltage drop.
 

fasteddy

I have C.L.A.P
Global moderator
Joined
Apr 26, 2010
Messages
6,648
Location
Albion Park NSW
This is excellent news as there are a great range of Pixel and module types available for the 3001 chip, Our options have now increased
 

TimW

Full time elf
Joined
Jun 15, 2010
Messages
168
Location
Melbourne
Nice work Jim. I had a lot of trouble around he low end of the 8 bit pixels last year. Very easy to make an image look 'white' on the grid with relatively low levels of R/G/B. Looking forward to getting stuck in to these to see how much better the results could be.
 

fasteddy

I have C.L.A.P
Global moderator
Joined
Apr 26, 2010
Messages
6,648
Location
Albion Park NSW
Jim,

Im wondering where we are able to get the updated firmware to enable the 3001 for the E680.
Looks like i have to now update the 1 pager for the E680 to add the new features.

Great work Jim
 

jstjohnz

Apprentice elf
Joined
Sep 19, 2010
Messages
97
Location
Indianapolis, IN
This link: 8_bit & 12_bit pixel comparison
is to a short video clip that shows an 8-bit pixel side-by-side with a 12-bit pixel while dimming. I now have user-selectable gamma correction to work with the 12-bit pixels.


@TimW: I had the same issue trying to display pictures and videos on a 2000 pixel array. Everything except very high-contrast images tended to look washed out. As of right now, the 3001 will be my pixel of choice going forward.

@Eddie: Should be maybe a week or so until it's ready for release. You should be able to do an update over your lan after I send you the files. The last day or so has been spent on setting up the gamma-correction to be a user-settable parameter. I was originally using a hard-coded gamma table that I calculated with an Excel spreadsheet, but I really wanted it to be adjustable. Took me a while to wrap my head around the math to get the gamma equation implemented on an integer-only CPU.
 

TimW

Full time elf
Joined
Jun 15, 2010
Messages
168
Location
Melbourne
Wow - that's a significant difference.
Did you try running the gamma correction on the 8 bit pixels? Is there any advantage to doing so?
 

jstjohnz

Apprentice elf
Joined
Sep 19, 2010
Messages
97
Location
Indianapolis, IN
@TimW:

I did a while back, and my general impression was that it helped a bit but not nearly to the extent that it does with 12-bits. If I get a chance I will set it up again and make another video.
 

TimW

Full time elf
Joined
Jun 15, 2010
Messages
168
Location
Melbourne
Thanks Jim - the rationale behind my question being whether its worth retrofitting dimming curves to the 8 bit pixel drivers as well - even if its just to increase the linearity of the perceived fade.

I'm only asking the question rhetorically really. If I want to find out - maybe I should have a crack at coding it myself!
 

jstjohnz

Apprentice elf
Joined
Sep 19, 2010
Messages
97
Location
Indianapolis, IN
The easiest way to try it is to hard-code a 256-byte lookup table. That's what I was using initially. I used an excel spreadsheet to come up with the values, for an 8-bit table the formula is Y=(X/255)^G*255 where X is raw DMX value, G is gamma and Y is gamma-corrected DMX value.
 

Nath_From_NT

Apprentice elf
Joined
Aug 31, 2010
Messages
55
Location
Yarralin - NT
jstjohnz said:
The easiest way to try it is to hard-code a 256-byte lookup table. That's what I was using initially. I used an excel spreadsheet to come up with the values, for an 8-bit table the formula is Y=(X/255)^G*255 where X is raw DMX value, G is gamma and Y is gamma-corrected DMX value.

Yeah, what he said. :D
 

TimW

Full time elf
Joined
Jun 15, 2010
Messages
168
Location
Melbourne
jstjohnz said:
The easiest way to try it is to hard-code a 256-byte lookup table. That's what I was using initially. I used an excel spreadsheet to come up with the values, for an 8-bit table the formula is Y=(X/255)^G*255 where X is raw DMX value, G is gamma and Y is gamma-corrected DMX value.

Thanks. And then use trial and error to get the best G value?
 

jstjohnz

Apprentice elf
Joined
Sep 19, 2010
Messages
97
Location
Indianapolis, IN
For 8-bits I would suggest starting with 2.0. This is what I was using when I tested that:

gamma20 BYTE 0,0,0,0,0,0,0,0,0,0,0,0, 1,1,1,1,1,1,1,1,1, 2,2,2,2,2, 3,3,3,3,3, 4,4,4,4 '0-34
BYTE 5,5,5,5, 6,6,6, 7,7,7, 8,8,8, 9,9,9, 10,10, 11,11,11, 12,12, 13,13, 14,14, 15,15 '35-63
BYTE 16,16, 17,17, 18,18, 19,19, 20,20, 21, 22,22, 23,23, 24, 25,25, 26,26, 27 '64-84
BYTE 28,28, 29, 30,30, 31, 32, 33,33, 34, 35,35, 36, 37, 38,38, 39, 40, 41, 42,42 '85-105
BYTE 43,44,45,46,47,48,48,49,50,51,52,53,54,55,56,57,57, 58,59,60,61,62,63,64,65 '106-130
BYTE 66,67,68,69,70,72,73,74,75,76,77,78,79,80,81,83, 84,85,86,87,88,89, 91,92,93,94,95 '131-157
BYTE 97,98,99,100,102,103,104,106,107,108,109,111,112,113,115,116,117,119,120, 122,123 '158-178
BYTE 124,126,127,129,130,131,133,134,136,137,139,140,142,143,145,146,148,149,151,152 '179-198
BYTE 154,155,157,158,160,162,163,165, 166,168,170,171,173,175,176,178,180,181,183,185 '199-218
BYTE 186,188,190,192,193,195,197,199, 200,202,204,206,208,209, 211,213,215,217,218 '219-237
BYTE 220,222,224,226,228,230,232,234,235,237,239,241,243,245,247,249,251,253,255
 

TimW

Full time elf
Joined
Jun 15, 2010
Messages
168
Location
Melbourne
So.. 7.5 bits of actual control then ? :)

The inherent nonlinearity of it probably makes the relative resolution a bit hard to compare. There are steps on the the linear 8 bit scale that its very hard to see with the naked eye... so isnt' it already less than a true 8 bit resolution for practical purposes?
 
Top