[Bf-committers] Proposal: Blender OpenCL compositor

[Martin Poirier]

Not all effects needs access to all of the buffer. A lot of them only need access to a neighbourhood around each pixels, for which a system of slightly overlapping tiles fits the problem.

Martin

--- On Fri, 1/21/11, Aurel W. <aurel.w at gmail.com> wrote:

> From: Aurel W. <aurel.w at gmail.com>
> Subject: Re: [Bf-committers] Proposal: Blender OpenCL compositor
> To: "bf-blender developers" <bf-committers at blender.org>
> Received: Friday, January 21, 2011, 3:31 AM
> 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
> >
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>