On May 2, 2012, at 6:45 PM, Jeremy Selan wrote: > - Rather than basing the algorithm on ImageBufAlgo, we may want to expose a > version that processes raw pixels (i.e., ImageSpec*). We can *also* expose > an API for processing existing ImageBufs, but if it's simpler to expose a > version that processes pixels in a different underlying container it will > make sense to allow it. What I'm thinking of is how we can implement the > processing in a comp package such as nuke, which doesnt rely on imagebufalgo. > (Any while we could certainly construct one temporarily, there's no reason > to do so if not needed).
Actually, my suggestion is exactly the opposite. Let's keep all the ImageBufAlgo functionality accepting only ImageBuf's. But as a separate task, let's amend ImageBuf to have a variety that "wraps" a client-owned and managed buffer. ImageBuf already has the logic to have its pixels either backed by an ImageCache, or to have the whole image in an allocated buffer. We only need the very minor change to distinguish between whether the ImageBuf allocates and owns that buffer, or if it's passed in and belongs to the client. Everything else should just work -- I think that there's nothing in ImageBuf aside from the constructors and destructors that cares whether the memory holding the image is owned by the ImageBuf itself. I'd thought of this issue before, and am happy to do it myself ASAP. I can whip it out in no time. -- Larry Gritz l...@larrygritz.com _______________________________________________ Oiio-dev mailing list Oiio-dev@lists.openimageio.org http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
