BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
Many parts of the compositor are unnecessarily complicated. This patch
aims at reducing the complexity of writing nodes and making the code
more transparent.
== Separating Nodes and Operations ==
Currently these are both mixed in the same graph, even though they have
very different purposes and are used at distinct stages in the
compositing process. The patch introduces dedicated graph classes for
nodes and for operations.
This removes the need for a lot of special case checks (isOperation etc.)
and explicit type casts. It simplifies the code since it becomes clear
at every stage what type of node we are dealing with. The compiler can
use static typing to avoid common bugs from mixing up these types and
fewer runtime sanity checks are needed.
== Simplified Node Conversion ==
Converting nodes to operations was previously based on "relinking", i.e.
nodes would start with by mirroring links in the Blender DNA node trees,
then add operations and redirect these links to them. This was very hard
to follow in many cases and required a lot of attention to avoid invalid
states.
Now there is a helper class called the NodeConverter, which is passed to
nodes and implements a much simpler API for this process. Nodes can add
operations and explicit connections as before, but defining "external"
links to the inputs/outputs of the original node now uses mapping
instead of directly modifying link data. Input data (node graph) and
result (operations graph) are cleanly separated.
== Removed Redundant Data Structures ==
A few redundant data structures have been removed, notably the
SocketConnection. These are only needed temporarily during graph
construction. For executing the compositor operations it is perfectly
sufficient to store only the direct input link pointers. A common
pointer indirection is avoided this way (which might also give a little
performance improvement).
== Avoid virtual recursive functions ==
Recursive virtual functions are evil. They are very hard to follow
during debugging. At least in the parts this patch is concerned with
these functions have been replaced by a non-virtual recursive core
function (which might then call virtual non-recursive functions if
needed). See for example NodeOperationBuilder::group_operations.
- Fixed issues with calculating matte with balance != 0.5
It used to be used concave combination of minimal and maximal
channel values which could be inpredictable.
Use concave combination of two non-major channels sorted
by their index, so such combination would always use the same
coefficients for particular non-major channels.
- Added despill balance slider which defines balance between
non-major channels used for calculating average of two
colors. Difference between average value and pixel value of
major screen channel defines amount of despill. Balance of
0.5 gives the same behavior as it was before this slider
was added.
---
svn merge -r48678:48679 -r48789:48790 ^/branches/soc-2011-tomato
Separate X and Y passes of blurring like it's done for flat
gaussian blur. This reduces computing difficulty from size^2
to 2*size without any visual changes in matte.
Merge keying node from tomato branch into trunk.
It was considered stable and helpful by Mango team and it'll help
studio pipeline, because nodes would stop disappearing when opening
files in current trunk.
Full information about keying nodes could be found there:
http://wiki.blender.org/index.php/User:Nazg-gul/Keying
- Replace FastGaussian blur with GaussianBokeh blur which should give better results.
- Changes a bit formula of saturation which in some cases gives better result.
Also included (commented out) original formula which was also checked by Brecht
and which gave better result in some other cases.
- Made clipping white/black temporal dependent, so hopefully it wouldn't destroy
gradients on edges.
First node is called Keying Screen (Add -> Matte -> Keying Screen) and it's
aimed to resolve issues with gradients on green screens by producing image
with gradient which is later used as an input for screen color in keying nodes.
This node gets motion tracks from given movie clip and trackign object and uses
them to define color and position of points of gradient: for position marker's
position on current frame is sued, for color average color of pattern area is
used.
Gradient is calculating in the following way:
- On first step voronoi diagram is creating for given tracks.
- On second step triangulation of this diagram happens by connecting sites
to edges which defines area this site belongs to.
- On third step gradient filling of this triangles happens. One of triangle
vertices is colored with average track color, two rest vertoces are colored
with average color between two neighbor sites. Current pixel's color in
triangle is calculating as linear combination of vertices colors and
barycentric coordinates of this pixel.
This node is implemented for both tile and legacy compositor systems.
Second node is basically a combination of several existing nodes to make keying
more straighforward and reduce spagetti mess in the compositor, but it also
ships some fresh approaches calculating matte which seems to be working better
for not actually green screens.
This node supports:
- Chroma preblur
- Dispilling
- Clip white/black
- Dilate/Erode
- Matte post blur
This node doesn't support chroma pre-blur for legacy compositor (yet).
There're still lots of stuff to be improved here, but this nodes night already
be used i think.
Some details might be found on this wiki page:
http://wiki.blender.org/index.php/User:Nazg-gul/Keying
This patch also contains some currently unused code from color math module, but
it was used for tests and might be used for tests in the future. Think it's ok
to have it in branch at least.
