[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Problem in PyGame.SurfArray



On Wed, Aug 24, 2011 at 10:55 PM, Lenard Lindstrom <len-l@xxxxxxxxx> wrote:
Hi,

Well no, the post 1.9.1 surfarray does not support float arrays. The NumPy code was rewritten in C to make the module more general and, hopefully, faster. I'm sorry if it breaks some code. That the previous, pure Python, version converted a NumPy array of floats into an integer array may have been an unintended side affect. It would certainly make no sense. NumPy differs from Numeric in that it defaults to a float array. So any NumPy array used with surfarray should be created with an explicit, integer, dtype. If float arrays are needed somewhere in the calculation then they can be converted to integer arrays with the astype() method, just as the 1.9.1 surfarray did.

I suppose astype() conversion call could be put back into surfarray, but I don't see the need. Implicit, undocumented, conversions can lead to surprises. It would also add an extra, unnecessary, step.

Lenard Lindstrom
Hi,

Well, good to know the origin of the problem.  Thank you for clarifying.

I'm personally going to disagree with the notion that the previous behavior didn't make sense.  A lot of data (especially modern graphics in general (OpenGL and Direct3D)) operates on floats.  This is how your GPU operates internally.  It also makes sense, because there are not 256 quanta of energy in the entire world--there's a huge dynamic range, and all of it can be much more finely grained than Uint8 allows.  The 0 to 255 integer representation is just a display convention for conventional monitors, and with HDR displays it will eventually go away.

As far as PyGame goes, it seems to me that constructing a surface from float data is quite logical; to me, a surface is just an encapsulation of data--and in this case the data was in floating point.  Of course, I know that, in SDL, the surface's internal representation is Uint8 for each channel, so clearly any conversion in PyGame would happen during a call like this.  I'd argue that because pygame.Surface is ultimately just a wrapper of graphics data designed to be easy to draw with, it should operate similarly to the screen itself, and therefore accept all sorts of graphics data.

Thanks,
Ian