There is definitely something wrong with CopyToBuffer. I've done a bit more testing and it looks like it may be reusing the first pixel values on a line for all the pixels on that line. Probably something needs to be incremented somewhere that isn't. I'll try to get it fixed but in the meantime Chris's workaround looks like a good approach.
What the second print statement shows is not what was in the "arr" array
but rather that all slots are zero except that all entries arr[i,j,3]
are 1. So even before attempting to write into the memory map, I
apparently don't know what I'm doing.
This is on Windows, using wxPython 2.9 with 64-bit Python 2.7.
There is definitely something wrong with CopyToBuffer. I've done a bit
more testing and it looks like it may be reusing the first pixel values
on a line for all the pixels on that line.
I'm not sure that's the problem. The code in wxPyCopyBitmapToBuffer,
for the wxBitmapBufferFormat_RGBA case, is mutiplying all three
components by the pixel's alpha value. In this case, I believe the
alpha value will be 0.
Since the code is just copying RGBA to RGBA, I would argue that the
premultiply step is simply wrong. It should be copying all 4 bytes
unconditionally and without modification.
···
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
There is definitely something wrong with CopyToBuffer. I've done a bit
more testing and it looks like it may be reusing the first pixel values
on a line for all the pixels on that line.
I'm not sure that's the problem.
It was. There was a missing "++p;" in each of the 24/32 bit cases for that buffer format.
The code in wxPyCopyBitmapToBuffer,
for the wxBitmapBufferFormat_RGBA case, is mutiplying all three
components by the pixel's alpha value. In this case, I believe the
alpha value will be 0.
Since the code is just copying RGBA to RGBA, I would argue that the
premultiply step is simply wrong. It should be copying all 4 bytes
unconditionally and without modification.
The unpremultiply is there because it is doing a premultiplication step for the opposite operation, copying a buffer to a bitmap. The idea is that the buffers would always be assumed to be in an unpremultiplied state for any platform whether copying to or copying from the buffer, and then the premultiplication is done for those platforms whose native 32-bit bitmap format requires it, but it is left alone otherwise. (See the implementation of the premultiply macros at the top of _bitmap.i for details.) Oh, and if alpha is zero then the unpremultiply macro does just copy the pixel value unchanged.
Bruce, CopyToBuffer for the other buffer formats should be working correctly if you want to try using one of them instead. Otherwise this fix will be in 2.9.5 when it is released and in Phoenix snapshots shortly.