[Bf-compositor] a proposal for this list

Sat Nov 2 13:20:44 CET 2013

Sebastian: Could you create a few test files to demonstrate the sampling
issues?

On Sat, Nov 2, 2013 at 11:24 AM, Sebastian König
<koenig.sebastian at gmx.net>wrote:

> Hey all!
>
> Great to see this list as place for discussions about the compositor!
> Let’s form a Compositor Task-Force!
> From the talks with Jeroen and Monique at the Blender Conference I think
> we the users should first agree on what has to be fixed in the compositor
> and then give that list to the developers.
> So here is my list of things I would like to see fixed in the compositor.
> They are ordered by importance. Probably I forgot some things, but for the
> time being these are the things I would like to see fixed.
>
>
> *## Performance enhancement*
>
> 1. Be smarter about how to update nodes. Currently it feels as if the
> compositor would go over the entire node-tree and see what it has to do,
> even if all thumbnails and composite output are collapsed and there is only
> the viewer node connected to an image at the very start of the node tree.
>
> 2. Get rid of thumbnail previews, or at least make them collapsed by
> default.
> For me they have zero benefit, take up too much space in the composite
> layout, and suck performance. Just get rid of them!
>
> 3. Keep nodes in memory
> Related to the cache issue is that the compositor should be smarter when
> it comes to updates of node trees.
> It should detect what nodes have to be updated for the correct results and
> which nodes can be just kept in the buffer. I suppose this can be tricky
> memory-wise, but the current way of entirely re-calculating the whole
> node-tree just because of some change at the very end of it just sucks.
>
> 4. Lower resolutions for compositing.
> To check the overall result of the compositing you don't need to see the
> full resolution of composite. Having to render with different render
> dimensions however is a bit tedious. It would be nice to be able to set
> compositor to half or quarter resolutions to perform the composite. In the
> end you could then proceed to final resolution.
>
> 5. Cache Nodes
> For a lot of VFX compositing you cannot only composite for 1 frame, you
> have to see it in motion. Rendering out final sequences is a bit tedious
> and not an ideal solution. Therefore it would be great to have some kind of
> cache for playback.
> Something that I imagine to be rather easy to do would be to have a cache
> node. You could drag it between any noodle, and that output would be cache
> for a give frame range. It could be cached either in RAM or on some kind of
> temp folder on hard drive. That way you can pre-render several cache
> sequences to both have a playback available, but also to stop one node tree
> from having to calculate all the time.
> One state of the node is „locked“. It assumes to have a pre-rendered
> sequence in cache and won’t calculate the node tree that leads into it.
> Second state of the node is „record“. It will store any frame of the of
> the sequence in cache.
> Third state could be „passthrough“ or so, in case the cache node should
> just be ignored.
> What i think would be nice about this method is that you can define some
> kind of milestones in your node tree.
>
>
>
>
> *
> *
> *## Functionality*
>
> 1. Make all nodes relative
> We have some nodes that allow a relative setting  (blur size for example),
> while others only allow fixed pixel size (dilate erode). In practice that
> is really annoying because usually you start rendering and compositing at
> 50% and only for the final images you proceed to 100%. The compositor
> should have a unified setting for the size. Probably some thinking has to
> go into this, how to handle a pixel size setting, or if everything should
> be set in percentage, or, if you want to use pixels, if it should be
> relative pixels in relation to render dimensions.
>
> 2. Better sampling
> The current sampling sucks. For example the plane track node makes images
> incredibly blurry. I discussed that already with Jeroen at the Blender
> Conference, and apparently the entire sampling system has to be rewritten.
> But it would be worth it! :)
>
> 3. Masking
> Currently the Roto-workflow is still a bit clunky.
> Personally I would propose to merge clip-editor and uv/image editor.
> Because then we could do masking, tracking and painting of patches for
> compositing in 1 editor, which would be really nice.
> But I think this is a bigger issues, and maybe can be discussed
> separately.
>
> 4. Canvas
> The compositor is missing a better way to deal with different image
> dimensions. Arranging images and sequences freely on the canvas is
> important for compositing.
>
> 5. Overscan
> Related to the canvas topic is „overscan“ (hope it’s the right term), to
> allow rendering bigger than the final dimensions. That is needed for
> various things for example to be able to distort CG elements and composite
> them over footage with lens distortion.
>
>
>
> *## Wait, there’s more!*
> Apart from the already mentioned issues there are other things that could
> be improved, but are maybe not doable soon.
>
> 1. New way of animating of nodes
> The way we animate nodes is a bit crappy at the moment. It’s possible, but
> the way we can control the keyframes is not really nice. Maybe there could
> be some kind of NLA editor for compositing nodes, to easier drag around
> keyframe effects AND image sequences. See next topic.
>
> 2. Better way to deal with image sequences
> It is really annoying and tedious how we have to enter frame length and
> offset for movies and image sequences, if not everything starts at frame
> one. Could be controlled with some kind of composite NLA too? This could
> also touch the way to deal with length and start of image sequences and
> movie clips. But I suppose this is a bit complicated and maybe also not as
> super important.
>
>
>
> So, that’s it.
> I’m sure I forgot some things, but so far this is what I would like to see
> improved.
>
> Cheers!
>
> Sebastian
>
>
>
>
>
> On 2. November 2013 at 10:54:04, David McSween (3pointedit at gmail.com<//3pointedit at gmail.com>)
> wrote:
>
> I also wondered if it would be useful for fx work to have access to the
> open gl renders from 3d view? As a scene source just like BI or Cycles.
> There are some sorts of comp effects that would benefit from the speed of
> redraw, like distortion or mapping. To do matte painting work etc.
> On 2 Nov 2013 17:10, "Aditia A. Pratama" <aditia.ap at gmail.com> wrote:
>
>> This is my proposal for blender compositor
>>
>> 1. viewer cache and viewer proxy for realtime playback, movie clip editor
>> has this function
>>
>> 2. new canvas for compositing where we can translate/rotate/scale
>> directly in the canvas...more flexibility in the canvas.
>>
>> 3. ability to add comp to video sequence editor. We also can have
>> multiple composite in node editor...and calling them in video seq editor
>> for arranging and editing, it's like improving post-processing workflow.
>> On Nov 2, 2013 1:15 PM, "David McSween" <3pointedit at gmail.com> wrote:
>>
>>> Hey Francesco, most recently I was troubled by the odd image dimensions
>>> issue when trying to add or modify non-project sized assets. That is my
>>> over height image was cropped strangely when alpha overed. I gather from
>>> the Holywood presentation at bcon13 it is a long standing problem that
>>> isn't just a bug fix.
>>> David
>>> On 2 Nov 2013 15:56, "Francesco Paglia" <f.paglia.80 at gmail.com> wrote:
>>>
>>>> Hi all!
>>>> It's a great news to have this list focused on the compositor.
>>>> I don't really know which is the main intent of this list so let me
>>>> know if I'm wrong writing the next few line.
>>>> What if we post here about real production case demonstrating which are
>>>> our actual limits so we can discuss them with the module owner/s and figure
>>>> out how to address them?
>>>> There are many compositor in the community like Bartek Skorupa, Sean
>>>> Kennedy, Sebastian Konig, me and many others that I don't know or heard
>>>> about that I imagine they can share their thoughts.
>>>>
>>>> Could be possible to know which dev is reading this list since there
>>>> are more areas of blender involved since compositor is a made of nodes,
>>>> animations, compositing itself and render output?
>>>>
>>>> Hope to hear other subscribers opinion soon!
>>>> Ciao
>>>> Francesco
>>>>
>>>> --
>>>> Francesco Paglia
>>>> Vfx and Production Supervisor
>>>> 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
>>>
>>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> Bf-compositor mailing list
> Bf-compositor at blender.org
> http://lists.blender.org/mailman/listinfo/bf-compositor
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-compositor/attachments/20131102/3c089b42/attachment-0001.htm 