Thanks for the feedback and links, everybody. My inclination is toward #2 -- merely recognizing that NumPy is present, and when it is, exposing just a few additional Python calls that let you directly pass NumPY ndarray back and forth to OIIO (in addition to the current set of methods that work with regular 'array'). But there's no rush, I think this is a "when I get time and/or enough people ask for it" kind of project.
On 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, I actually do something similar here, > where for something like the GetFloatPixels() 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 -- Larry Gritz [email protected]
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
