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 ImageOut
On Jul 2, 2015, at 2:22 PM, Justin Israel 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 e
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
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
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 re
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
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 ca
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
st
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
