That's really exciting to hear! Such a wrapper will make all the existing ImageBufAlgorithms more useful as well.
If it's easy to add generically in the future, there's really no rush to add it now. We can certainly wait until later in the summer. It's just great to know it's possible to extend it in this manner. -- Jeremy On Wed, May 2, 2012 at 11:40 PM, Larry Gritz <l...@larrygritz.com> wrote: > > > 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 >
_______________________________________________ Oiio-dev mailing list Oiio-dev@lists.openimageio.org http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
