Adds full frame implementation to Anti-Aliasing, Defocus, Denoise,
Despeckle, Dilate/Erode, Directional Blur, Filter, Inpaint and
Vector Blur nodes. The other nodes in "Filter" sub-menu are
submitted separately.
Part of T88150.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D12219
Current sampling methods have off by one issues on full frame:
- Bilinear sampling do not fully sample bottom and left image border,
creating edges.
- Single elem buffers are not sampled at all when they should be
at least on the borders to smooth edges.
- EWA filtering is partially implemented on `ReadBufferOperation`, it
needs to be moved to `MemoryBuffer` on full frame.
In order to not affect tiled implementation, this commit creates
specific sampling methods for full frame needs.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D12164
Adds full frame implementation to "Bokeh Image" node, "Track Position"
node, `SetVectorOperation` and `MovieClipAttribute`.
The other nodes in "Input" submenu are implemented separately.
`MovieClipAttribute` needs resolution to calculate its constant value, it can't be constant folded,
which requires it to be a `ConstantOperation`. Now `ConstantOperation` contemplate this case
and any operation that is always constant without depending on inputs should implement it.
If in the future an operation needs to get an input constant element during
`determineResolution` it must first determine its input resolution.
The nodes have no functional changes.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D12090
Adds full frame implementation to this node operations.
No functional changes.
Includes a new operation method `init_data` used to initialize any data
needed after operations are linked and resolutions determined.
Once tiled implementation is removed `initExecution` may be renamed
to `init_rendering` and `init_data` to `init_execution`.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D11944
Currently we mostly iterate buffer areas using x/y loops or through
utility methods extending from base classes.
To simplify code in simple operations this commit adds wrappers for
specifying buffer areas and their iterators for raw buffers with any
element stride:
- BufferRange: Specifies a range of contiguous buffer elements from a
given element index.
- BufferRangeIterator: Iterates elements in a BufferRange.
- BufferArea: Specifies a rectangle area of elements in a 2D buffer.
- BufferAreaIterator: Iterates elements in a BufferArea.
- BuffersIterator: Simultaneously iterates an area of elements in an
output buffer and any number of input buffers.
- BuffersIteratorBuilder: Helper for building BuffersIterator adding
buffers one by one.
For iterating areas coordinates it adds `XRange` and `YRange` methods
that return `IndexRange`.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D11882
Not causing issues in current master because all buffer areas are at
(0, 0) position and `Extend` is not used. But areas may be at any
position in future developments and it will crash.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D11784
Adds full frame implementation to Image node operations.
Mostly refactored into buffer utility methods for reuse in other
operations.
No functional changes.
1.8x faster than tiled fallback.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D11559
This patch fixes many minor spelling mistakes, all in comments or
console output. Mostly contractions like can't, won't, don't, its/it's,
etc.
Differential Revision: https://developer.blender.org/D11663
Reviewed by Harley Acheson
These variables and methods should make it easier to loop through buffers elements/pixels. They take into account single element buffers.
Single element buffers can be used for set operations to reduce memory usage.
Usage example: P2078
Reviewed By: #compositing, jbakker
Differential Revision: https://developer.blender.org/D11015
SocketReader was added as an easier to understand interface on top of
the NodeOperation. It was implemented as a base class of the
NodeOperation and adds an additional hierarchy level.
Ths change replaces the abstract class with a typedef. In the end we
want to remove the typedef but will wait for some new nodes before doing
so.
This replaces header include guards with `#pragma once`.
A couple of include guards are not removed yet (e.g. `__RNA_TYPES_H__`),
because they are used in other places.
This patch has been generated by P1561 followed by `make format`.
Differential Revision: https://developer.blender.org/D8466
Surrounding includes with an 'extern "C"' block is not necessary anymore.
Also that made it harder to add any C++ code to some headers, or include headers
that have "optional" C++ code like `MEM_guardedalloc.h`.
I tested compilation on linux and windows (and got help from @LazyDodo).
If this still breaks compilation due to some linker error, the header containing
the symbol in question is probably missing an 'extern "C"' block.
Differential Revision: https://developer.blender.org/D7653
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.
Basically filtering was happening twice, first time by applying weights of EWA
filter itself and then by applying subpixel offset while reading pixel values.
This was a regression caused by attempts to fix T42844 and there were
some red-herrings which lead me to the wrong way to fix it. It's some
deeper issue than just interpolation offset, it's mainly how the node
resolution is being mapped to each other.
It could be actually a part of canvas awareness project..
Different interpolation methods in compositor could lead to 0.5 pixel offset in
final renders. This is because of some inconsistency in integer coordinates
which might mean pixel corner or pixel center.
Should be all fine now.
The compostor used a fixed size of 4 floats to hold pixel data. this
patch will select size of a pixel based on its type.
It uses 1 float for Value, 3 float for vector and 4 floats for color
data types.
When benchmarking on shots (opening shot of caminandes) we get a
reduction of memory of 30% and a tiny speedup as less data
transformations needs to take place (but these are negligable.
More information of the patch can be found on
https://developer.blender.org/D627 and
http://wiki.blender.org/index.php/Dev:Ref/Proposals/Compositor2014_p1.1_TD
Developers: jbakker & mdewanchand
Thanks for Sergey for his indept review.
