I *think* you can convert between the two without creating any copies python (I think it's possible because both array and numpy.ndarray implement the python buffer interface, but I may be wrong). I didn't spend a ton of time looking at it and was ok with eating the cost of the copy if it made one.
In the end, The advantages I've found to using numpy really come if you have to write something like an out of order channel shuffle/rewrite and don't want to risk up/down casting the image data. You need to process it technically but not actually change anything in the image. Maybe I'm missing a clever trick with either OIIO or the python array type, but since NumPy has easy methods to change the "view" of the underlying data it makes it easy to reconstitute things while keeping stride lengths sensible if your image has mixed channel bit depths. Hopefully that makes sense. I'm speaking mainly from dealing with mixed channel bit depth exrs so it may not apply across the board. 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
