TLS3001 pixels & stip

[Beacy]

At the Melbourne mini we were shown a display on gamma correction and the huge effects it has in the ability to display true colours and the incredible difference it makes when fading in and out. I believe that ability to do this is within the settings of the various software that pixel controllers use.


BUT to get the effect and results of this you need 12 bit or higher pixels/strip which many of us don't use as the 2811 & 2801 I believe is 8 bit.


Has anyone used the TLS3001 pixels or strip if so would be interested in some feed back and the pros & cons of the TLS3001 or any other alternatives as the 12bit plus chips will make a huge difference in displays from a fading in and out perspective

 

[fasteddy]

At the Melbourne mini we were shown a display on gamma correction and the huge effects it has in the ability to display true colours and the incredible difference it makes when fading in and out. I believe that ability to do this is within the settings of the various software that pixel controllers use.


BUT to get the effect and results of this you need 12 bit or higher pixels/strip which many of us don't use as the 2811 & 2801 I believe is 8 bit.


Has anyone used the TLS3001 pixels or strip if so would be interested in some feed back and the pros & cons of the TLS3001 or any other alternatives as the 12bit plus chips will make a huge difference in displays from a fading in and out perspective

If your willing to pay the extra cost for something that really wont be noticed by your audience. Its not a TV screen its a Christmas display/show so it goes down to if you percieve this important enough to spend the extra money compared to using 2811.

The issue is you need to be able to use something that can have dimming curves or else its a waste because the refreah rate data stream between the computer and the controllers (DMX, E1.31) is only 8 bit anyway.

 

[charleskerr]

You can definitely implement some nice log dimming curves to match the eye response with the 12 bit pixels (using the 8 bit intensity values in the DMX stream). We did it in our first controllers we designed, and it does make a nice response.


In theory, one could do the same with 8 bit curves, if one limited themselves to 100 intensity values (which is really adequate if you do some measurements on what you actually perceive given the linear curves of 8 bit).


As for the cost for the benefit, only the consumer/user can make that decision.

 

[Skunberg]

There are several people using them over at DIYC. And several threads on using them.

Brian

 

[ecbailey]

The demonstration at the mini was very convincing and certainly would be noticeable for things like Pixel Matrixes.


Has anybody found any vendors for 3001 pixels aside from Advatek Lights?

 

[ltay13]

You could do it using dimming curves but it would be a bit tedious to fill out 256 different values with the 12 bit equivalent. Something we briefly spoke about at the mini is that it actually an industry standard formula in IT for storing data more efficiently and then displaying it correctly on the monitor/TV etc.


So my point with that is you really don't actually want lookup tables, you just want to set a single gamma correction variable (2.2 is the industry standard). As for noticing it in a display, you're correct that people watching it probably won't notice the difference in the colours (although it is noticeable when compared side by side), but the effect that it has just on dimming up and down is extremely noticeable - even on standard LED strings not RGB/Pixel (we are about to implement in our Dumb RGB/Standard DC controller for instance).


It is one of those things that is hard to really appreciate it until you see it which is why I did a demo at the mini.


Also about the 8 bit data stream between PC and network controller - it isn't actually restricting data off the PC into an 8 bit stream. Pictures/colours are usually stored like that in the PC itself as well (with the inverse of gamma correction applied first) because that is all the bit depth you need to get a quality image when the display that views it gamma corrects before showing the image. All displays that you would ever look at automatically gamma correct everything you see otherwise things on a computer/TV would look terrible.

 

[charleskerr]

I dont know, with a light meter, and then some calculations, some software programming to automate the measurements/calculations, it didn't seem to hard to make a nice lookup table (not that tedious) to match the string.


I wouldn't say a lookup table is a bad way to do it. Perhaps the correction value is "cleaner" for general purpose, but since I know what strings I have, matching them to a lookup isn't that hard.

 

[jstjohnz]

It is possible to achieve a similar result with 8-bit pixels. The approach is similar to what LOR does to get 128 dimming levels using 5-bit 6803s. By slightly varying the pixel intensity on every refresh pass, you can effectively extend the number of intensity bits. For example, to use the 6803s as 7-bit pixels, you use the 5 high-order bits as the base intensity value, then use the 2 low-order bits to determine when to add an extra bit.
Example: Desired 7-bit intensity = 0000001, base intensity (5 MS bits) is 0, now use the 1 LS bits (01) to transmit an actual intensity value of 00001 to the pixl every 4th refresh. A 10 value of the 2 LS bits would mean you send intensity 1 every other time, etc. If the refresh rate is fast enough the eye sees this as having effectively 128 dimming steps instead of 32.
With 8-bit pixels, you use a similar scheme. In my case I have a gamma lookup table that returns 12 bit values, originally for use with the TLS3001. With 8-bit pixels you do the gamma table lookup, then discard the 2 LS bits keeping a 10-bit result. The MS 8 bits becomes the base intensity value, and the 2 LS bits are used for the dithering, in other words they determine which refresh passes get bumped up by 1 bit. The effect is an effective 10-bit pixel, and the improvement in the dimming characteristic is very noticeable on the low end.
This is only workable if the basic refresh rate is high enough to keep the dithering invisible.

 

[fasteddy]

It is possible to achieve a similar result with 8-bit pixels. The approach is similar to what LOR does to get 128 dimming levels using 5-bit 6803s. By slightly varying the pixel intensity on every refresh pass, you can effectively extend the number of intensity bits. For example, to use the 6803s as 7-bit pixels, you use the 5 high-order bits as the base intensity value, then use the 2 low-order bits to determine when to add an extra bit.
Example: Desired 7-bit intensity = 0000001, base intensity (5 MS bits) is 0, now use the 1 LS bits (01) to transmit an actual intensity value of 00001 to the pixl every 4th refresh. A 10 value of the 2 LS bits would mean you send intensity 1 every other time, etc. If the refresh rate is fast enough the eye sees this as having effectively 128 dimming steps instead of 32.
With 8-bit pixels, you use a similar scheme. In my case I have a gamma lookup table that returns 12 bit values, originally for use with the TLS3001. With 8-bit pixels you do the gamma table lookup, then discard the 2 LS bits keeping a 10-bit result. The MS 8 bits becomes the base intensity value, and the 2 LS bits are used for the dithering, in other words they determine which refresh passes get bumped up by 1 bit. The effect is an effective 10-bit pixel, and the improvement in the dimming characteristic is very noticeable on the low end.
This is only workable if the basic refresh rate is high enough to keep the dithering invisible.

But the limitation to this is that you cant connect up as many pixels together due to the bandwidth needed to do this. This is why the LOR CCR will only allow you one strip and any further strips connected will reduce the dimming steps and increase the pixel grouping. So i would expect that doing this for a 8 bit chip will have some trade off but for many this should not be an issue if they are not connecting too many pixels together.

 

[battle79]

Thinking a lookup table that give 64 visually spaced steps (ie gamma corrected), spaced over the 256 steps of an 8 bit 2811 would more than do for me.

I don't really think I need all the 256 steps in an 8 bit chip. If I get better low end dimming I could live with only 64 apparent steps.

Now to find out if Ed and his P2's could support this function.

Cheers,
Rowan

 

[jstjohnz]

It is possible to achieve a similar result with 8-bit pixels. The approach is similar to what LOR does to get 128 dimming levels using 5-bit 6803s. By slightly varying the pixel intensity on every refresh pass, you can effectively extend the number of intensity bits. For example, to use the 6803s as 7-bit pixels, you use the 5 high-order bits as the base intensity value, then use the 2 low-order bits to determine when to add an extra bit.
Example: Desired 7-bit intensity = 0000001, base intensity (5 MS bits) is 0, now use the 1 LS bits (01) to transmit an actual intensity value of 00001 to the pixl every 4th refresh. A 10 value of the 2 LS bits would mean you send intensity 1 every other time, etc. If the refresh rate is fast enough the eye sees this as having effectively 128 dimming steps instead of 32.
With 8-bit pixels, you use a similar scheme. In my case I have a gamma lookup table that returns 12 bit values, originally for use with the TLS3001. With 8-bit pixels you do the gamma table lookup, then discard the 2 LS bits keeping a 10-bit result. The MS 8 bits becomes the base intensity value, and the 2 LS bits are used for the dithering, in other words they determine which refresh passes get bumped up by 1 bit. The effect is an effective 10-bit pixel, and the improvement in the dimming characteristic is very noticeable on the low end.
This is only workable if the basic refresh rate is high enough to keep the dithering invisible.

But the limitation to this is that you cant connect up as many pixels together due to the bandwidth needed to do this. This is why the LOR CCR will only allow you one strip and any further strips connected will reduce the dimming steps and increase the pixel grouping. So i would expect that doing this for a 8 bit chip will have some trade off but for many this should not be an issue if they are not connecting too many pixels together.

I'm not sure what the limitation may be re the CCR controller, but the 6803s, like most 4-wire pixels, are capable of a very fast refresh rate, more than fast enough to work with a very long string. But yes, the feasibility of this approach ultimately depends on the available refresh rate which in turn depends on the pixel type and string length.

 

[jstjohnz]

Thinking a lookup table that give 64 visually spaced steps (ie gamma corrected), spaced over the 256 steps of an 8 bit 2811 would more than do for me.

I don't really think I need all the 256 steps in an 8 bit chip. If I get better low end dimming I could live with only 64 apparent steps.

Now to find out if Ed and his P2's could support this function.

Cheers,
Rowan

The problem is that at the low end you can't improve the dimming response without some means to expand the pixel's intensity range beyond 8 bits. A DMX value of 1 coming in will still be a DMX value of 1 going out to the pixel, and the result will be a jump from off to 1/256th total brightness. The same for the next several steps, so the area you need the most correction with isn't getting any correction. It's only at the high end that you'l be skipping some of the visually imperceptible DMX steps.

 

[fasteddy]

It is possible to achieve a similar result with 8-bit pixels. The approach is similar to what LOR does to get 128 dimming levels using 5-bit 6803s. By slightly varying the pixel intensity on every refresh pass, you can effectively extend the number of intensity bits. For example, to use the 6803s as 7-bit pixels, you use the 5 high-order bits as the base intensity value, then use the 2 low-order bits to determine when to add an extra bit.
Example: Desired 7-bit intensity = 0000001, base intensity (5 MS bits) is 0, now use the 1 LS bits (01) to transmit an actual intensity value of 00001 to the pixl every 4th refresh. A 10 value of the 2 LS bits would mean you send intensity 1 every other time, etc. If the refresh rate is fast enough the eye sees this as having effectively 128 dimming steps instead of 32.
With 8-bit pixels, you use a similar scheme. In my case I have a gamma lookup table that returns 12 bit values, originally for use with the TLS3001. With 8-bit pixels you do the gamma table lookup, then discard the 2 LS bits keeping a 10-bit result. The MS 8 bits becomes the base intensity value, and the 2 LS bits are used for the dithering, in other words they determine which refresh passes get bumped up by 1 bit. The effect is an effective 10-bit pixel, and the improvement in the dimming characteristic is very noticeable on the low end.
This is only workable if the basic refresh rate is high enough to keep the dithering invisible.

But the limitation to this is that you cant connect up as many pixels together due to the bandwidth needed to do this. This is why the LOR CCR will only allow you one strip and any further strips connected will reduce the dimming steps and increase the pixel grouping. So i would expect that doing this for a 8 bit chip will have some trade off but for many this should not be an issue if they are not connecting too many pixels together.

I'm not sure what the limitation may be re the CCR controller, but the 6803s, like most 4-wire pixels, are capable of a very fast refresh rate, more than fast enough to work with a very long string. But yes, the feasibility of this approach ultimately depends on the available refresh rate which in turn depends on the pixel type and string length.

With the CCR controllers there are limitations when additional strips are connected due to data badwidth. But as you have said the 6803 takes very little data especially when you compare it to a 3001, but for some reason the CCR has this limitation. part of it may be the type of processor being used in the CCR controller.