[Bf-compositor] a proposal for this list

Sat Nov 2 16:25:41 CET 2013

I'm very happy to see so many people interested in discussing about the
compositor!
As Jeroen said it's very important to set a wiki page where all the
relevant issue raised in this list are kept updated and managed in a
consistent way.
If Sebastian would lead this role I'm very happy to endorse him because I
think he has the right attitude and skills to do it! :)

Another advice I would suggest is to keep threads easily recognizable
setting one topic each so we don't have to surf though dozen of mail to
find the answer or the question we are looking for.
If you don't mind Seb I'd like you would split all the interesting topic
you put in your previous mail into as many threads as the topics are.

If you all agree would be even cooler if we can set a convention in the
thread naming so we can easily recognize the content.

As I can see the topic could be:

- enhancement
- new feature

we can set a sort of prefix like [enh] and [feat] what do you think of this
idea?

I also think in the wiki page we should set both list to keep things
clearer and to have more people that could get involved as dev... (I
imagine if someone who wants to jump in the compositor development should
start with a standalone node instead of trying to solve problem that only
Jeroen can handle efficiently)

>From an user point of view I think priority has to go to tasks that prevent
us to fully use the blender compositor (and canvas limits as well as
complete recalculation of the node tree really are)  but I imagine that
some issues aren't just related to the compositor itself and the developers
should help us understand the complexity behind and what can really be done
so we can discuss further trying to keep at an high level the usability as
well ...  :)

2013/11/2 blenderleo <blenderleo at gmx.de>

>  @Sebastian:
> caching the nodes would probably also fix the undo issue.
>
> Am 02.11.2013 13:20, schrieb Lukas Tönne:
>
> 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
>>
>>
>
>
> _______________________________________________
> Bf-compositor mailing listBf-compositor at blender.orghttp://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
e-mail   f.paglia.80 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-compositor/attachments/20131102/480bf217/attachment-0001.htm 