[Bf-committers] Proposal: Canvas compositing

[Matt Ebb]

Hi Jeroen, I'm not keen on this proposal - it seems to mix two concepts and
does it in a bit of an odd way.

First concept is region of interest, or bounding box:

It should be possible to define regions of interest within which only the
contained pixels will be processed/output/etc. This can be used for things
like the oldskool preview window in blender's compositor to only update a
cropped subset of the pixels to speed things up while tweaking, but can also
include things like having different data windows and display windows (like
EXRs contain). Sometimes you'll want to render an EXR with overscan, so the
data window is larger than the display window, which lets you do things like
add distortion, camera shake, etc using the extra pixels around the edge of
the visible frame so there aren't edge artifacts.


The second concept is a matter of transforming nodes:

IMO this should really be implemented as a 3D transformation matrix per node
(better to use 3D to be future proof, even if only 2D is used atm). I'm
pretty sure most other good compositors do it this way as well.

All transform nodes should just be modifying that matrix, passing on a
reference to the original buffer, and not doing any processing of their own.
Rather, whenever real pixels are needed (for example, a blur) in the
function that retrieves the buffer (or tile) for the blur node, it should
then sample the original buffer once, using the current transform matrix.

This allows concatenation of transforms (as in Shake and Nuke), where you
can have as many different transform nodes one after the other like
rotate->shear->scale->translate->rotate, and it will only sample the image
once, to prevent deterioration in image quality.


There's a bit of info on these things here and in the nuke docs:
http://www.nukepedia.com/written-tutorials/10-tips-to-optimising-nuke-and-creating-efficient-workflows/

Matt



On Wed, Aug 3, 2011 at 1:27 AM, j.bakker at atmind.nl <j.bakker at atmind.nl>wrote:

> Hi all,
>
> Some of you might already know this, but I have done some effort in making
> canvas compositing working in Blender.
>
> I have made a draft-proposal to see where it should go to. I would like to
> have feedback on the user interface level. How can we make this usable to
> our users? How can we keep the render width/height settings in sync with
> the canvas width/height?
>
> In the current compositor the composite works on a by code defined
> coordinate system. This coordinate system (ImBuf x, y) cannot be changed or
> even used by the user. This proposal will open up this coordinate system
> and implement canvas compositing in Blender. This is possible as the
> compositor redesign project does not enforce a coordinate system and
> handles data/memory in a different way (no buffers).
>
> This will introduce 4 new concepts in the compositor
>
>  - Ordered List Item Canvas (being the existing background grid)
>  - Viewport (the camera that the compositor looks through, the area that
> will be the result of the composite)
>  - Positionable input nodes (data can be positioned/scaled/rotated on the
> canvas)
>  - Backdrop handles (interactive handles on the backdrop)
>
>
> The link below has to proposal including sample images and a (technical)
> video.
>
> http://ocl.atmind.nl/doku.php?id=design:proposal:compositor_canvas
>
> Happy Blending!
> Jeroen
>
> --------------------------------------------------------------------
> mail2web.com – Enhanced email for the mobile individual based on
> Microsoft®
> Exchange - http://link.mail2web.com/Personal/EnhancedEmail
>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>