[Bf-committers] Proposal: Blender OpenCL compositor

[François T.]

I guess he is talking of algorithm where the entire buffer needs to be
evaluated before processing the pixels. Like knowing which is going to be
the Max Luma value in your buffer to divide all your pixels by this value.
(very simple example, but just for the case) or something like Retinex
algorithm, which recontrast localy based on value from the entire buffer, if
you only have tiles and some part of the image at the process time, that
would be an issue.
But even with that I don't understand why it would be a problem. as I
understand it, only the node itself does the tile, but the I/O of each nodes
is full buffers right ?
I don't know how this works exactly, but I can understand his fear about it,
but again, I'm pretty sure we are not the first compositor node doing tile
base right :) ?



2011/1/22 Jeroen Bakker <j.bakker at atmind.nl>

> On 01/21/2011 04:14 PM, Aurel W. wrote:
> > You are talking about things such as convolution with a defined kernel
> > size. There are other operations and a compositor truly transforms an
> > image to another image and not pixels to pixels etc. If it's
> > implemented in such a naive way, the compositor will be very limited.
> > I got a very bad feeling about this....
> >
> > Ok, let's normalize an image with a tile based approach,... uh damn
> it....
> Aurel, don't worry on that. Tile based is that the output is part of a
> tile. But the input data can be the whole or a part of the image. On the
> technical side there will be some issues to overcome (mostly device
> memory related). Btw there are possibilities when you need every image
> pixel as input to use a intermediate to reduce memory need. I did this
> already in the defocus node.
>
> Please help me to determine the case when a whole output image is
> needed. IMO input is readonly and output is writeonly. I don't see the
> need atm to support whole output images in a 'per output pixel'
> approach. And every 'per input pixel' approach can be written by a 'per
> output pixel' approach. In the current nodes the two approaches are mixed.
>
> Jeroen
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
____________________
François Tarlier
www.francois-tarlier.com
www.linkedin.com/in/francoistarlier