A very brief look at the bug would suggest this to be a duplicate of bug 489,
which has already been fixed in beta2. Once you get your hands to beta2
packages, could you please verify whether this is the case.

I'm leaving this UNCONFIRMED for now.

This does not seem to be fixed. The TypeError raised with wrong argument types
still only lists

PySide.QtGui.QImage()
PySide.QtGui.QImage(PySide.QtGui.QImage)
PySide.QtGui.QImage(PySide.QtCore.QSize, PySide.QtGui.QImage.Format)
PySide.QtGui.QImage(QString, str = None)
PySide.QtGui.QImage(int, int, PySide.QtGui.QImage.Format)

as valid constructors; trying a QImage(str, int, int, Format) set of arguments
gives

TypeError: PySide.QtGui.QImage(): too many arguments.

This suggests that bug 489 may not be truly fixed?

Note: I used the precompiled OS X binary pyside-1.0.0-beta1-qt47-py26apple.pkg
from http://developer.qt.nokia.com/wiki/PySideBinariesMacOSX .

To clarify: did you test this on beta1 or beta2? The bug is expected to occur
with beta1 but not on beta2, because bug 489 was only released in beta2.

I'm making this NEW in any case to not keep it in limbo forever. P3.

This appears to be incompletely fixed. In PyQt4 we are able to do:

    self.pixels = numpy.zeros((height, width, 4), dtype='uint8')
    self.img = QImage(self.pixels, width, height, QImage.Format_RGB32)

Then each time self.img is painted, it gets the new contents of self.pixels.
This is very important for performance since it removes the need to call
setPixel for each point for each frame, or even packing the image data into a
string and then having QImage unpack it.

Instead, PySide HEAD gives me:

TypeError: 'PySide.QtGui.QImage' called with wrong argument types:
  PySide.QtGui.QImage(numpy.ndarray, int, int, Format)
Supported signatures:
  PySide.QtGui.QImage()
  PySide.QtGui.QImage(PySide.QtGui.QImage)
  PySide.QtGui.QImage(PySide.QtCore.QSize, PySide.QtGui.QImage.Format)
  PySide.QtGui.QImage(QString, str = None)
  PySide.QtGui.QImage(uchar, int, int, PySide.QtGui.QImage.Format)
  PySide.QtGui.QImage(uchar, int, int, int, PySide.QtGui.QImage.Format)
  PySide.QtGui.QImage(int, int, PySide.QtGui.QImage.Format)

By comparison, when I force the PyQt version to fail (by passing `object()`
instead of self.pixels), I get:

TypeError: arguments did not match any overloaded call:
  QImage(): too many arguments
  QImage(QSize, QImage.Format): argument 1 has unexpected type 'object'
  QImage(int, int, QImage.Format): argument 1 has unexpected type 'object'
  QImage(str, int, int, QImage.Format): argument 1 has unexpected type 'object'
  QImage(sip.voidptr, int, int, QImage.Format): argument 1 has unexpected type
'object'
  QImage(str, int, int, int, QImage.Format): argument 1 has unexpected type
'object'
  QImage(sip.voidptr, int, int, int, QImage.Format): argument 1 has unexpected
type 'object'
  QImage(list-of-str): argument 1 has unexpected type 'object'
  QImage(QString, str format=None): argument 1 has unexpected type 'object'
  QImage(QImage): argument 1 has unexpected type 'object'
  QImage(QVariant): too many arguments

Notice that PyQt offers a 'voidptr' type, which accounts for both actual Python
strings and buffer-like things such as numpy arrays. The right solution for
both this bug and #566 would be to have a voidptr-like type that wraps things
with the Python buffer interface. When returning one from C++, it should
support the buffer interface on the Python side as well.

I'm working around this for now by making a new QImage(pixels.asstring(), ...)
for each frame, but that's a performance hit.

Hi Kenneth Arnold, I'm working on this bug right now, among with other QImage
issues like the lack of bits(), constBits(), scanLine() and constScanLine()
methods, i.e. all methods that return internal buffers.

The problem that the previous fix to QImage(uchar,...) constructor copies the
data isntead of using it as is like the QImage documentation says.

I think all can be solved using Python buffers, the only requirement are that
the memory pointed by the buffer must be contiguous, but it'll be fast,
flexible =].

Fixed in commit:
pyside/2a4391902406552815140f4ebe078f9f7e9a955c

The constructors now accepts any PyObject which implements the buffer protocol,
as the C++ and PyQt4 version the buffer must be alive during the life time of
QImage because QImage *does not* copy the image data.

released on beta 5