Dev:Ref/Proposals/Compositor

Compositor Enhancement Proposals

This page is made to collect requests and proposals from both the former compositor request wiki page as well as the new bf-compositor mailing list, where artists and users discuss what has to be done to improve the compositor in Blender. A lot of proposals and feature requests are overlapping. The plan is to try to merge and combine them on this page into single topics, outlining the underlying problem and show different solutions. These proposals will be ordered and ranked by importance and feasibility so that the developers get a better idea what to work on and how to proceed with development. This should make it easier to get a clearer vision of what's needed and of what's possible and at the same time make the whole developing and decision making process more transparent and open to the community.

Performance

Smarter node updating

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.

Thumbnail previews

state: implemented date: December 2013

Get rid of thumbnail previews, or at least make them collapsed by default. Their benefit is questionable, they take up too much space in the composite layout, and suck performance.

Requirements

• When an user adds a (non input category) node to a compositor tree, the preview of that node is invisible by default.
• When an user adds a input category node to a compositor tree, the preview of that node is visible by default.
• Previews visibility of all nodes can be switched as you normally would.
• All node categories have their own themed color (also non compositor categories). These colors can be set in the user-preferences

Keep buffers

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. Probably 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.

Preview Compositing at lower resolution

To check the overall result of the compositing often 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.

Cache Node

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 might be rather doable would be to have a cache node. You could drag it between any noodle, and that output would be cached 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. But that's just an idea.

Functionality

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.

Better Samplling

The current sampling has some issues. For example the plane track node makes images quite blurry. In discussions during Blender Conference 2013 Jeroen Bakker mentioned that eventually the entire sampling system needed some work. Note: Lukas Toenne has started to work on sampling of the plane track node. Troy Sobotka sent a link to the mailing list about Cubic B-Spline Scaling. Might be worth investigating! http://wiki.blender.org/index.php/User:Sobotka/Cubic_B-Spline_Scaling_Algorithm

Masks

Not everyone is happy about the current S-Curves in the Mask Editor. Some people would rather have regular Bezier Curves for masking, to have better control over the control points.

Note: Sergey has already started to work on this. There is also another Coder, Christopher Barrett, who has started to work on this. He has even created a branch for it: http://goodspiritgraphics.com/software/products/zorro/ Apparently he has already contacted Sergey, so maybe there can be some combined efforts.

Mask Editing

No matter if we use S-Curves or Beziers, there is one thing that could improve masking a lot: The ability to control the size of a control point by click&drag.

Currently, if you create curve control points by ctrl-clicking, they will all have the same size. But most of the time, you need different sizes to create a better shape of your roto-mask. So you'd have to first create the mask, and then go and adjust the size of the control points. But it would be much nicer, if you could ctrl-click to add a curve point, keep the mouse pressed, and by the amount of dragging with pressed mouse button control the size of the point. You can see it in action in Antony Riakiotakis' video about his GSoC2013 at minute 7:50: http://www.youtube.com/watch?feature=player_detailpage&list=UUuGg52XgHydPp9tGtQfwoZQ&v=t5jkcSIvGis#t=471

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.

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.

Roto Workflow

Currently the Roto-workflow is still a bit clunky. One idea would be 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 this is probably a bigger issues, and maybe can be discussed separately.

Animation 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.

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.

^^ this is something ive hankered after for a long time - or the ability to push a VSE strip into a comp noodle - is there a way we can make multiple comp noodles in a single scene to send either strips or VSE channels to?

New Nodes

Apply LUT node

The user tamerlan311 has worked one a node to quickly apply LookUpTables for color correction. Here's a screenshot: http://cs425127.vk.me/v425127915/3a26/IGZOF3t3tVM.jpg

And a link to the patch:

https://gitorious.org/blenderprojects/blender-applylut-node/commit/c689e976debc1a13ea1a005cd8fd1a257110b0b4

This seems to be a very useful node, even though we already have color management in Blender. Would be worth investigating how and why this could be implemented into Blender.

Compositor technical proposal

A technical design has been created (March 2014) to solve most of these issues.

Dev:Ref/Proposals/Compositor2014