(I'm moving this thread from http://code.google.com/p/pyglet/issues/detail?id=202 to email, which I find more conducive to conversation.)
Alex Holkner wrote > I doesn't implement the ImageData interface, despite subclassing it (the > format, pitch and data properties won't work as documented); this class > should probably be a direct subclass of AbstractImage. As submitted to the tracker, NumpyImage does in fact try to support the format and pitch properties as advertised for ImageData. What about them is different than the documentation? (I'm going by the docstrings in image/__init__.py -- please point me to better docs if I've missed them.) Any limitation in supported formats is an oversight on my part, not non-support. Furthermore, one can explicitly pass a format argument to the constructor if the default won't work. It is true that the format and pitch properties are read only - is that a problem? I agree that the data property doesn't work as advertised, but my motivation for this work is that I don't want the data to be copied to a string before going to OpenGL. I originally tried to implement this with the data property being the buffer object corresponding to a numpy array, which is closer in spirit to the data property being a string, but I abandoned this when trying to get ctypes to pass the pointer of the buffer object. I can revisit this -- are there any show-stoppers you see with the data property being either a buffer object or a string? > It looks good, but I'm not convinced this is going to be useful for many > people besides yourself. In particular, > it's not in pyglet's nature to fail if an optimal path can't be achieved (it > should fall back to copying, and non- > contiguous and arbitrary-format arrays should be supported). > As mentioned, my main motivation is to have a non-copy path from arbitrary data (numpy array as the container) to the video card. However, I'd be fine with an option and default setting such as "allows_copy=True" which, for my current use case, would always set to False. > The view_new_array() method seems awkward; why wouldn't the user create a new > NumpyImage and toss the old one? To avoid the overhead of creating a new OpenGL texture if you're displaying a new array of the same shape as the old one (e.g. digital image frames). > It seems to me that it would be useful to also provide functionality for > obtaining a numpy array from another > pyglet image (say, a texture, or the color buffer, for example). Agreed. Indeed it seems that's what Patrick Devine wants. > > I haven't been following the array interface discussion for a while, but if > the latest PIL and numpy support it, > is it possible to provide an image class that can make use of > __array_interface__ instead of supporting numpy > etc directly? I'm not sure what you're suggesting here. The numpy.asarray(arr) explicitly consumes this interface already. Are you suggesting something more/different? Certainly I have no objection to changing "numpy" to "ArrayInterface" or whatever. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en -~----------~----~----~----~------~----~------~--~---
