[Bf-compositor] Extending some node functions to VSE

Thu May 22 11:25:12 CEST 2014

My answers are inlined


2014-05-22 11:11 GMT+02:00 David McSween <3pointedit at gmail.com>:

> What I meant by limitations of using nodes in single strips is... you
> could not easily send source image through a node tree to affect other
> strips.
>
> But I see that you are suggesting a sort of meta-node strip(?), that uses
> VSE channels as sources.
>

Right


>  Is a channel considered an input node or an individual strip?
>
The whole channel is used as input


> Does a channel only become active when a strip occupies it?
>
> As soon as a strip even  1 frm long is added to a channel it becomes
eligible as an input source


> The timeline metaphor is much easier to grasp for time-related changes to
> media, relative to each other. I really wish there was an efficient way to
> send these decisions to the compositor...
>
> It would be a big improvement for me too! :)


>
> On Thu, May 22, 2014 at 6:16 PM, Francesco Paglia <f.paglia.80 at gmail.com>wrote:
>
>> IMHO a strip contain a node tree where you can use as input other strips
>> embedded in the timeline as well as extra elements imported or generated
>> directly in the node tree (like a renderlayer of a scene or an image or a
>> text)
>>
>> To give you some reference you can take a look at the compositing system
>> of the "ancient" AVID DS or latest version of Lightworks...
>> As you can see there strips are added in the compositor node tree and
>> treated as inputs.
>>
>> The DS approach differ from the lightworks one and both are efficient in
>> their own way:
>> DS define a subtimeline with all the strips embedded
>> Lightworks reads directly the original timeline
>>
>> In both cases you get an input node for each layer (doesn't matter how
>> many clips are involved per track) that I find really useful
>> I do prefer the subtimeline solution of DS because it locks all the
>> strips to the local timeline and if you change your edit you wont loose the
>> link between them.
>>
>> I don't understand completely what you mean with the constrains and
>> limitation of the single strip because in any way you get strips with alpha
>> and opacity and you can blend them with all the method allowed by the
>> software
>>
>>
>>
>> 2014-05-22 10:00 GMT+02:00 David McSween <3pointedit at gmail.com>:
>>
>> Could you explain the concept of - converting strips to "compositing
>>> containters"
>>>
>>> Does this mean that:
>>> 1. a proxy of the strip appears in the compositor (and it's
>>> result/output in the VSE)
>>> or that
>>> 2. the VSE strip contains a mini node tree in the VSE.
>>>
>>> The first idea allows for multiple strip interaction, where the strips
>>> are concurrent in the timeline. for example chromakeying action over
>>> background.
>>> The second idea seems to constrain node effects to a single strip?
>>>
>>> Thanks for the interest.
>>> David
>>>
>>>
>>> On Thu, May 22, 2014 at 5:37 PM, Francesco Paglia <f.paglia.80 at gmail.com
>>> > wrote:
>>>
>>>> +1
>>>> As I see some node functionalities have been imported in the VSE but
>>>> the design (as is now) shows a lack of possibilities and doesn't look very
>>>> efficient.
>>>> Probably we have to wait until compositor becomes unlinked from the
>>>> renderlayer  system.
>>>> But imagine the power we gain in this way simply converting strips to
>>>> "compositing containters"...
>>>>
>>>>
>>>>
>>>> 2014-05-22 7:08 GMT+02:00 David McSween <3pointedit at gmail.com>:
>>>>
>>>>> This is slightly off topic, but I wonder if it is possible to extend
>>>>> the function of VSE strip modifiers to use compositor nodes?
>>>>>
>>>>> That is allow re-using simple 'node code' like blur, to alter strip
>>>>> frames in the VSE.
>>>>>
>>>>> We already have Curves and Color Corrector as well as Masks.
>>>>>
>>>>> I propose simply adding 'discreet task' modifiers but also wonder if
>>>>> you can realistically port a compositor node tree into a VSE strip as a
>>>>> frame modifier?
>>>>>
>>>>> One of the most annoying deficiencies in the VSE currently is the lack
>>>>> of Blur filters.
>>>>>
>>>>> Thanks for your consideration.
>>>>> David McSween
>>>>>
>>>>> _______________________________________________
>>>>> Bf-compositor mailing list
>>>>> Bf-compositor at blender.org
>>>>> http://lists.blender.org/mailman/listinfo/bf-compositor
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Francesco Paglia
>>>> Vfx and Production Supervisor
>>>>
>>>> mobile  +39 347.82.12.473
>>>> e-mail   f.paglia.80 at gmail.com
>>>>
>>>>
>>>> _______________________________________________
>>>> Bf-compositor mailing list
>>>> Bf-compositor at blender.org
>>>> http://lists.blender.org/mailman/listinfo/bf-compositor
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Bf-compositor mailing list
>>> Bf-compositor at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-compositor
>>>
>>>
>>
>>
>> --
>> Francesco Paglia
>> Vfx and Production Supervisor
>>
>> mobile  +39 347.82.12.473
>> e-mail   f.paglia.80 at gmail.com
>>
>>
>> _______________________________________________
>> Bf-compositor mailing list
>> Bf-compositor at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-compositor
>>
>>
>
> _______________________________________________
> Bf-compositor mailing list
> Bf-compositor at blender.org
> http://lists.blender.org/mailman/listinfo/bf-compositor
>
>


-- 
Francesco Paglia
Vfx and Production Supervisor

mobile  +39 347.82.12.473
e-mail   f.paglia.80 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-compositor/attachments/20140522/227e0f50/attachment-0001.htm