SeExpr curve and ccurve color bug

Software Natron
1

While working with the curve and ccurve functions in the SeExpr and SeExprSimple nodes I have found that it is impossible to pass any variables to the color vectors of the curve/ccurve functions; however if I define the exact same colors inside of the curve/ccurve it self they function properly. This makes it impossible to pass user parameters or variables defined in the SeExpr Code them selves.

Here is a simple example:

This does not work In SeExpr:
---------------Node------
No. of Color Params: 1
color1= r:1.0 g:1.0 b:0.0 (should be yellow)

----------------RGB Script-------
$pat = noise(10*$u,10*$v);
$out = ccurve($pat,
0.0, $color1, 4,
0.5, [0.5, 0.0, 0.0], 4);
$out
— end node —

however, this does work:
This does work In SeExpr:
---------------Node------
No. of Color Params: 0

----------------RGB Script-------
$pat = noise(10*$u,10*$v);
$out = ccurve($pat,
0.0, [1.0, 1.0, 0.0], 4,
0.5, [0.5, 0.0, 0.0], 4);
$out
— end node —

More over if one tries to define the color inside of the RGB script it also fails, but now if the quantity of nod parameters is changed the defined color jumps around randomly, sometimes working and other times even throwing a NaN error:

This does not work In SeExpr:
---------------Node------
No. of Color Params: 1 <—[Scrubbing the quantity causes $mycol to generate a random
color from a group of potential color including NaN!]
color1= r:1.0 g:1.0 b:0.0 (should be yellow)

----------------RGB Script-------
$mycol = [1.0, 1.0, 0.0];
$pat = noise(10*$u,10*$v);
$out = ccurve($pat,
0.000, $mycol, 4,
0.590, [0.333, 0.000, 0.000], 4);
$out
— end node —

2

Probably an SeExpr bug… however this workaround seems to work:

$pat = noise(10*$u,10*$v);
$out = ccurve($pat,
0.0, [$color1[0],$color1[1],$color1[2]], 4,
0.5, [0.5, 0.0, 0.0], 4);
$out

Can you confirm?

3

And actually, it’s a limitation from SeExpr: the curve values cannot be variables: I'm using SeExpr in Natron and Curve() doesn't work as expected. · Issue #37 · wdas/SeExpr · GitHub

4

I just checked that code, and I get no Red with any of the node values; however, Green and Blue work perfectly.

I wondered if this might be a limitation of SeExpr it self. sad to see it, because I did some tests and curve and ccurve operate much, much faster than building the same thing with mix nodes

5

Another solution that seems to work: does the color interpolation afterwards:

$pat = noise(10*$u,10*$v);
$a = curve($pat, 0.0, 0.0, 4, 0.5, 1.0, 4);

$color1 * (1-$a) + [0.5,0,0]*$a
1 Like
6

That last code works perfectly for all channels and 1 color, now I’ll have to see if it will work with more than a 2 point curve, because ultimately that is where starts overtaking stacked mix nodes.

7

What about using a python expression for the script, that would include the color values as constants in the SeExpr script?

8

Set the RGB script to that (multi-line) python expression:

ret = """$pat = noise(10*$u,10*$v);
$out = ccurve($pat,
0.0, [{0},{1},{2}], 4,
0.5, [0.5, 0.0, 0.0], 4);
$out
""".format(thisNode.color1.get()[0],thisNode.color1.get()[1],thisNode.color1.get()[2])
9

Actually, despite initially throwing an error this seems to work, and has me thinking of some other potential work arounds I want to investigate.
Thank you. =)

10

Okay, WOW!!! I just tested that out on a much more elaborate version to see if it would work with multiple colors and variables, and other than the initial error it works for EVERYTHING! Not only that, but it seems to be 100% animatable, and it saves and when reloads the expression doesn’t throw and error and functions 100% correctly. So while this is only an initial test if Natron can do something with SeExpr that is supposedly broken in the original package then I think Both You and Natron earned a Mega Major Brownie Point.