RGBA expressions.

[Est]

Hi.

Thank you for releasing this library. I find it easy to use and very
useful.
I've just started using it in my application and the results so far
are great.

My question is about color + alpha expressions. My app is a video
compositor
and I'd like to use SeExpr to generate / manipulate RGBA images.

The obvious way would be to have two expressions, but I'd rather have
one.
Another option I tried is using an "output" variable $Ao and getting
its value like this:

if( expr.resolveLocalVar( "Ao"))
{
SeExprLocalVarRef *Ao = expr.getLocalVar( "Ao");
....
}

It works, but these functions are not part of the public interface so
it doesn't seem like a good idea to me.

What would be the best way to do it?

Thank you!

Est.

[brentb]

On Jun 1, 6:06 am, Est <ramen...@gmail.com> wrote:
> Thank you for releasing this library. I find it easy to use and very useful.
> I've just started using it in my application and the results so far are great.

Glad to hear it!

> My question is about color + alpha expressions. My app is a video compositor
> and I'd like to use SeExpr to generate / manipulate RGBA images.
>
> The obvious way would be to have two expressions, but I'd rather have one.
> Another option I tried is using an "output" variable $Ao and getting
> its value like this:
>
> if( expr.resolveLocalVar( "Ao"))
> {
> SeExprLocalVarRef *Ao = expr.getLocalVar( "Ao");
> ....
>
> }
>
> It works, but these functions are not part of the public interface so
> it doesn't seem like a good idea to me.

You're correct that the resolveLocalVar and getLocalVar methods are
not intended for public use. getLocalVar is harmless but you really
shouldn't be calling resolveLocalVar and you shouldn't need to; just
call getLocalVar straight away. Also, there's a similar
getLocalVars() method that is intended to be public and allows read-
only access to local variables after the expression has been
evaluated.

We've considered in the past extending the library to handle vec4's,
to do rgba processing among other things, and we're considering it
again along with the possibility of generalizing further (to things
like quaternions and matrices). We're open to suggestions.

Cheers,

Brent

[Est]

Thank you. I missed getLocalVars. I'll fix my code to use it.

I uploaded a screenshot of my current SeExpr integration work here:
https://picasaweb.google.com/lh/photo/RWMcOYcnYmC7FSOdkuTjXtZD6BzO0NT8YzGckvjrCSA?feat=directlink

I think that extending the library to use 4d vectors is a good idea,
or even vecN where N could be a compile time
option.

In my previous code, I was using boost variant.
It was something like this:

typedef boost::variant<float, Imath::V3f, Imath::Color4f> result_type;

and I had unary and binary visitors to apply functions and operators:

struct plus_visitor : public boost::static_visitor<result_type>
{
template <class T>
result_type operator()( const T& lhs, const T& rhs) const { return
lhs + rhs;}

template <class X, class Y>
result_type operator()( const X& lhs, const Y& rhs) const
{
assert( 0);
return result_type();
}
};

In my experience, adding a new type to the variant after the code is
written is not a lot of work.
Just an idea. I didn't get too far with it.

Est.

[Andrew Selle]

We have a branch of the library where we are experimenting with LLVM code gen. In that branch we allow expressions to generate arbitrary length vectors of floats. Since compilation would be on the fly, it would allow different expressions to have different return types. In the currently released implementation, having the expression nodes templatized on the dimensionality as you describe would probably be the way to go, because having different sized vectors dynamically being determined would likely slow the execution. On the other hand whatever size you choose to execute you may pay for computing larger vectors than you need for a given expression. 

Glad the integration is going well, looks very cool.

-Andy