our existing pixel access is intentionally slow & safe (since blender could free the image in a thread if we expose the memory directly).
so for numpy access I'm not sure its possible to do in a safe way (numpy does support some IIRC locking but Im not sure on details)... to answer your question - yes, it is possible... suggest bpy_types.py would have a something like this... |class Image(ID): | @property | def pixels_fast(self): | try: import numpy | except: ...fail... | return tricky_numpy_wrapper(self) alternately you can use ctypes to find the pointer and bundle with a script - since officially this wont be accepted *(dodgy but functional). as for pypy, they still dont do py3 or have a CAPI so we are a way off being able to use it for now. On Tue, Apr 24, 2012 at 8:52 AM, Alex Fraser <[email protected]> wrote: > ----- Original Message ----- >> From: "Campbell Barton" <[email protected]> >> >> clarifications... >> - numpy would be a python module available but not loaded on startup >> [...] >> drawbacks >> - numpy took a long time to upgrade to python3 (~3 years after py3 >> release), relying on numpy could be a drawback from upgrading python >> in the future, or moving to a different implementation (like pypy). > > I'm mostly interested in it as a way to speed up access to pixel data. To get > that, wouldn't we need to have a stronger dependency on it, so that > Image.pixels can return a numpy array? Also, given my interest in speed, I'd > like to keep the option to move to pypy open. Perhaps that conflicts with my > first point ;) > > Cheers, > Alex > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
