My New Sequencer

[boarder3]

10 strings of 16 high up,down,up i cut 2 off so 48 pixels.

[JHinkle]

10 strings of 16 high up,down,up i cut 2 off so 48 pixels.

Please explain - I did not follow at all.

Joe

[boarder3]

ok figure 10 strings of 50 ge pixels. i cut off 2 pixels to give me 48 total per string. Just like the mega tree in video i go up 16 pixels high than go down than up. So one string does 3 strings or at least it looks like 3 string. So when its looks like i have 30 strings but is really 10 . It looks great and if we had a matrix editor we could do exactly what is done in the video.

[JHinkle]

May I ask the distance between pixels - 12 inches - that would give a little under a 16 ft tree - or are they closer together.

Thanks

[Slite]

How many strings on a mega-tree?

How many lights per string.

Joe

That's like asking "How long is a string?"

People are doint mega trees with lots of different numbers of strings and lights per strgin. Most use a multiple of 8 strings though, so 8, 16, 32, 64 are the most common values for number of strings.

As for lights per string, thats more dificult to specify. Since some use one string from top to bottom, some user strings that go bottom->top->bottom (loops back down). there are also examples of bottom->top->bottom->top (i.e one string doubles up as three strings)

And then it comes down to, how long is a string?

But "most" pixel strings are 25, 50, 75 or 100 pixels a string... You can however cut the to your own length as you go along.

[miw01]

Joe

smeighan is doing some interesting work on RGB Sequence building and has posted on this forum, link to his site is here

http://meighan.net/seqbuilder/index.php

Mike

[Zeph]

Joe,

There are two types of light curves which matter. They often get confused.

One is about matching incans and LEDs, ideally linearizing them.

1) LED light output is fairly linear with average current once you get above the minimum Vfwd it takes to conduct, but incandescents have more complex higher power curves with time delays.
2) If AC powered with equal size time slices, the time slices near then zero crossings conduct less power to the lights than time slices near the sine wave peaks. If DC powered, doesn't apply.

The other indpendent aspect is about the eye's perception, which tends to be ratiometric rather than linear (ie: it's more logarithmic, or exponential, depending on which end of the telescope you look down). This shows up even in PWM modulation of DC LEDs (eg: 2801 controlled constant current pixels), where LED brightness is actually pretty linear with pulse width - none of that incan high exponent curves, or AC phase issues.
3) Nevertheless, even with a very linear light, going from 3/255 to 4/255 is a notable jump while going from 203/255 to 204/255 brightness is invisible (even avoiding the extreme ends of the scale, that is).

As it turns out, the inherent non-linearities of the incans partially compensates for the eye's non-linearities (they don't really have the same curves, one being exponential and the other being a high order polynomial, but the curves at least bend in the same directions), while LEDs don't. They are all too linear! (once they are above Vfwd and conducting at least)

The same light curve (lookup table) can potentially be used to compensate for both factors (light source non-linearities and human eye perceptual non-linearities), but they are different concepts; it's easy to confuse or conflate them.

One common and simple approximation, which can be tweaked to some degree to help either problem, is gamma curves. Remarkably, one floating point parameter creating the curve can improve many situations. Obviously no single parameter curve can have the flexiblity of an arbitrary lookup table which can map anything to anything, tho.

RJ's the expert on linearizing a variety of incans and LEDs; I believe he used a light meter to measure actual output for various models and incorporated the empirical results into Lynx Express tables. On the other hand, Jim St Johns uses gamma curves on the e68x, where he's starting with nice linear DC PWM pixels and thus only sets out to compensate for the eye. Not just Vixen, but many photo editing programs allow you to create an arbitrary curve which is really a 256->256 lookup table (the curve may be constrained to being monotonic).

[Zeph]

I implementing Dimming Curves.

To me a dimming curve is a simple translation array - 256 in size; In the ouput stage - once an illumination value is acquired - it is used as an index into this array to acquire the illumination value the user really wants.

Each dimming curve will reside in its own XML file. The file name defines the intent of the dimming curve (example - RedLED, Incandesent, BlueLED, etc).
The dimming curve file can contain the complete 256 byte array - or only those values that deviate from the default - default being same value out ans in.

<dcv>200,235</dcv> .... this as an example of an entry int the dimming curve file - take incoming illumination value 200 and output it as 235.

Joe

I would not suggest the input,output pair style. The reason is that it's well designed to handle sparse exceptions, but less so for representing continuous curves. Basically, once you add one pair to the list, more than likely you will need to adjust everything above it or below it; the output=input default immediately ceases to make sense any more. With pairs, it's too easy to create gaps, or to double specify the output for the same input (yes, you can have first wins or last wins rules, but why even create the conflict in the first place?).

So the simplest approach is to expect a 256 bytes table, providing the output equivalents for the implicit input values of 0..255. Fill to 255 with the last value if there are less than 255 values. No table means output=input. There are no gaps, no double specifications, no redundancy.

A more complex approach would be to use pairs, but interpolate between them. So if you get 64,128 as the only pair, interpolate 0..64 inputs to 0..128, and then 65..255 to 129..255. Sort the pairs by input value, then interpolate. This allows a sparse set of points to approximate an arbitrary curve, again without gaps.

Zeph

[JHinkle]

Zeth:

Nice write up for those that may not understand what a dimming curve is attempting to do and all of the limitations / trade-offs that come with it.

Nice Job.

Joe

[JHinkle]

I've got Dimming Curves implemented.

Use them if you like or not at all.

Joe