On Sat, Jan 22, 2011 at 8:11 PM, Aurel W. <[email protected]> wrote: > I also realize that the argument "it would work with the current > compositor" is a strong argument. But I got some problems with that. > First of all I think that a compositor should be in principal be able > to support all image processing operations.
On the contrary, I think the compositor should be designed and optimised for its purpose, compositing CGI/vfx imagery. It doesn't need to be a completely generalised image processing system, it just needs to do what it's intended for, well. So far I've seen a mostly theoretical objections here, but I think it's important to keep focused on enabling people to produce shots. > But back to the simple issue with operations, which need full buffer > access. I agree that this could be still done with tiling, because you > can simply compute all input tiles and just access those when > computing one single output tile. Or rather the tiles that are necessary at any given time. In the case of the Normalize node for example (which is mostly useless for animated sequences, as are any tone mapping operators that work in a similar way), it would be possible to retrieve each tile one by one in a pre-process, read and store the statistical information, and then apply that per tile or even per pixel. > In terms of memory usage, caching, etc. if we assume that only > reasonable sized buffers are used, let's say up to 64MB, I also don't > see the strong benefits in using tiles rather than buffers, which hold > the entire image. The benefits are lower memory usage, and better/easier parallelisation. _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
