A little late to the party here, but let me put in a vote for options 1 or 2. 2 seems the most flexible.
One use case that is common (pretty sure) but currently requires the use of NumPy arrays is a proper interpretation of OpenEXR half-float data. At the moment, ImageInput.read_image and ImageOutput.write_image will return or expect to receive an array of full float values with half the number of channel values as are present in the image. Each float value is byte-wise concatenation of two half-float values. The NumPy calls used to unpack the half-floats returned by read_image and then to pack results in preparation for the write_image call follow the message. Given the prevalence of OpenEXR half-float data, it would be great to not have to manage this bit of packing and unpacking if NumPy was present at build time. HP Code from here: https://github.com/hpd/CLF/blob/master/python/aces/filterImageWithCLF.py#L86 # Create a numpy array of half-float pixels based on an array of # 'floats' read from OpenImageIO. # Each 4 byte 'float' is the binary equivalent of two packed 2-byte half-floats. def oiioFloatPixelsToNPHalfArray(width, height, channels, oiioFloats): npPixels = np.frombuffer(np.getbuffer(np.float32(oiioFloats)), dtype=np.float16) return npPixels # Create an array of 'floats' that OpenImageIO can use to write # to formats like OpenEXR that support half-float. Starting point # is a numpy array of half-float pixels. # Each 4 byte 'float' is the binary equivalent of two packed 2-byte half-floats. def npHalfArrayToOIIOFloatPixels(width, height, channels, npPixels): oiioFloatsArray = np.frombuffer(np.getbuffer(np.float16(npPixels)), dtype=np.float32) return oiioFloatsArray On Fri, Jul 3, 2015 at 11:00 AM, Larry Gritz <[email protected]> wrote: > 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 > <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 > > > -- > 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
