[Bf-committers] Proposal: Blender OpenCL compositor

[Aurel W.]

Another question, I am concerned with.

What do you mean with "tiles" in the context of the compositor. That a
node just processes patches/tiles of an image, so the basic entity,
which is processed becomes a tile or even a single pixel?

I hope it's commonly realized that a compositing node always has to
process an entire image globally and output an entire image. The
processing of each pixel depends on every other pixel in the entire
image not just in tiles or on the very one input pixel. It's really
that simple, a node can be expressed by a function f(image)->image and
not f(tile)->tile or f(pixel)->pixel.

Please remember this when doing any design of the new system,
otherwise things will be heavily screwed up.

aurel

On 21 January 2011 08:37, Jeroen Bakker <j.bakker at atmind.nl> wrote:
> On 01/21/2011 12:10 AM, Matt Ebb wrote:
>> I say this not to be negative, but because there is a lot of room for
>> functional improvement in blender's compositor, and if it is to be
>> re-coded, it should be done with an eye to workflow and future
>> abilities, not just from a purely techno-centric perspective.
> I don't see it as negative. Also I don't think that I am (cap)able to
> implement all these functional wishes/changes. They need to be thinked
> about by users/developers together. I also don't think it is good to do
> all this work we discussed in a single project. There will be a
> separation of technology and functionality. First should concentrate in
> implementing a kernel (stable ground), that is capable of our 'future'
> wishes/changes/capabilities. And secondly we need to implement the more
> functional/workflow part.
>
> The first part needs to know the directions of the second part (vision).
> This vision should be clear upfront, but not in details.
>
> Jeroen
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>