On Wed, Aug 24, 2011 at 10:55 PM, Lenard Lindstrom <len-l@xxxxxxxxx
<mailto: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,