On Jul 2, 2015, at 2:22 PM, Justin Israel <justinisrael at gmail.com> 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 <nathanrusch at
gmail.com> 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 <lg at larrygritz.com>
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
> lg at larrygritz.com
>
>
>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-dev at lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-dev at lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
> _______________________________________________
> Oiio-dev mailing list
> Oiio-dev at lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
A lot has already been said, but I wanted to give my preference towards
a memoryview solution. Then, whether it is Numpy, Blaze or whatever
array-style container you want to use, these just need to implement a
conversion from memoryview. Numpy does it automatically via
numpy.asarray I reckon.
Ghis
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
