On Fri, Jul 20, 2012 at 4:22 PM, Larry Gritz <[email protected]> wrote: > Well, there's the crux of it. ImageBuf and its command-line wrapper > oiiotool are really meant for simple utility purposes -- for example, > if you just want to write a shell script that loops over images and > does a quick "over" comp, resize, and format conversion, say. Neither > is designed to be the core of an industrial strength node-based > compositor (for which you would specifically NOT want to compute > intermediate IB's for each operation at all, but rather turn the loops > inside out and essentially evaluate the whole node graph for each > output pixel, yielding a single output that doesn't need buffering and > has minimal memory allocation or copying).
Right. (You might want to get even more sophistocated in the presence of spatial filtering operations, and cache tiles of intermediate nodes of the graph? If I remember correctly this is the kind of thing that GEGL is aiming at.) > So, in short, I think we're not worried about what a compositing > package for huge node graphs would need, since channel operations are > the least of their architectural problems when it comes to IB's. +1 from me. It's simple to implement and avoids the cross product of features problem that would bloat up the interface. I reckon it will give people just enough flexibility without making things ugly. ~Chris _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
