I think Justin's suggestion of a buffer protocol implementation for copy-free reads and writes (at least as far as Python is concerned) would be pretty ideal, and would probably result in the most long-term flexibility. It may also be nice to add some convenience functions to allocate, fill, and return a NumPy array in one shot (if NumPy were detected), but that could also be done trivially in pure Python if the underlying protocol were implemented in OIIO.
-Nathan On Thu, Jul 2, 2015 at 2:36 PM, Jonathan Gibbs <[email protected]> wrote: > Yes, I think ideally for those of us using Numpy for image processing, it > would be great to get a numpy.ndarray representation of the data as > efficiently (with as few copies, maybe no copies) as possible. > > In my experience using Numpy is a great way to do quick one-off image > processing experiments without ending up with scripts which take forever to > run. I can't image doing much image processing with python without it. It > seems to be an upgrade over the built-in array in every way I've run into. > > But if you are just using OIIO to get image metadata, etc, then you won't > need it. > > --jono > > > On Thu, Jul 2, 2015 at 2:22 PM Justin Israel <[email protected]> > wrote: > >> I'm a user of the OIIO Python bindings, and I don't user NumPy at all, >> because my usage consists mainly of whole-image conversions, color >> transformations, inspecting metadata, etc. But I wonder, for the people >> that are using NumPy, are they expecting to actually receive numpy arrays >> so that they can directly operate on them? Is just using numpy internally >> as a non-copy transport covering the entire need? Because if the usage is >> just for an internal implementation detail, then maybe there are other >> options? >> >> >> http://eli.thegreenplace.net/2011/11/28/less-copies-in-python-with-the-buffer-protocol-and-memoryviews >> >> In my Go language bindings for OIIO >> <https://github.com/justinfx/openimageigo>, I actually do something >> similar here, where for something like the GetFloatPixels() >> <https://github.com/justinfx/openimageigo/blob/master/imagebuf.go#L364> >> method, I allocate a buffer on the Go side, pass it into OIIO and up with a >> no-copy result. >> >> Maybe the buffer approach could be done in the Python bindings if the >> goal is to just do a copy-free transport of the data? Otherwise if people >> really expect to receive the NumPy data structures, then it makes sense to >> optionally include that as a build option. >> >> Justin >> >> >> On Fri, Jul 3, 2015 at 7:31 AM Nathan Rusch <[email protected]> >> wrote: >> >>> I would say #2 sounds the most ideal, even though it would require the >>> most development work on the OIIO side. While NumPy can be very useful >>> (and, as you alluded to, is likely in large use among the people who use >>> the OIIO Python bindings), I think requiring NumPy to build/use the >>> bindings is a step too far. There may be users who are interested in the >>> bindings purely for gathering metadata or otherwise inspecting images, with >>> no intention of ever manipulating image data. >>> >>> -Nathan >>> >>> On Thu, Jul 2, 2015 at 11:06 AM, Larry Gritz <[email protected]> wrote: >>> >>>> I spent some time recently digging into more efficient data transfer >>>> between OIIO and Python, and could use some feedback. >>>> >>>> Regarding NumPy... I would appreciate hearing which of the following >>>> sounds right to you: >>>> >>>> 1. Anybody who needs to use OIIO from Python almost certainly already >>>> uses NumPy as well, and even if they don't, it's no big deal to require it. >>>> >>>> 2. There are pros and cons to NumPy, it shouldn't be a hard >>>> requirement, but it would be great if OIIO auto-detected it and supported >>>> it more directly if present. >>>> >>>> 3. NumPy support is a distraction, ignore it. Even if I use NumPy, I >>>> prefer to do the numpy-to-array conversions myself on the Python side of >>>> things. >>>> >>>> 4. Something else (please explain). >>>> >>>> I'm a hardcore C++ programmer, but only occasionally work in Python, so >>>> I really have no independent opinions on this nor much understanding of how >>>> essential everybody considers NumPy to be. >>>> >>>> -- >>>> Larry Gritz >>>> [email protected] >>>> >>>> >>>> >>>> _______________________________________________ >>>> Oiio-dev mailing list >>>> [email protected] >>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>> >>> >>> _______________________________________________ >>> Oiio-dev mailing list >>> [email protected] >>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>> >> _______________________________________________ >> Oiio-dev mailing list >> [email protected] >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >> > > _______________________________________________ > Oiio-dev mailing list > [email protected] > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > >
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
