Thanks for the bug report!

This is weird, I thought these sort of completely missing functions would've
already been dealt a few months ago when we did a comparison to PyQt.

I'm prioritizing this P... 2.

IMO the better suggestion was about the signature:

QImage.scanLine(line, lambda)

There's just a problem, what argument this lambda should get?
If we use QRgba the function will be as slow as setPixel/getPixel method.

PyQt4 returns a sip.voidptr object which is near useless too.

(In reply to comment #2)
> IMO the better suggestion was about the signature:
> 
> QImage.scanLine(line, lambda)
> 
> There's just a problem, what argument this lambda should get?
> If we use QRgba the function will be as slow as setPixel/getPixel method.

Would a tuple or something be faster? Or something from ctypes?

Otherwise (but that is most likely overkill) there could be an easy way to
specify the per-pixel operation as C function and call that "on the C level" -
even if that might involve compiling some C code as Python extension module.

We could pass a str object in the lambda e get a str object back, still much
slower than the C++ version because in Python this operation involves memory
allocation for the str object and the copy of the str returned by the lambda to
the uchar pointer returned by scanLine, despite of this detail, this method is
at least generic enough to be used by any image format.

(In reply to comment #4)
> We could pass a str object in the lambda e get a str object back, still much
> slower than the C++ version because in Python this operation involves memory
> allocation for the str object and the copy of the str returned by the lambda to
> the uchar pointer returned by scanLine, despite of this detail, this method is
> at least generic enough to be used by any image format.

Sounds good to me, as long as it's faster than getPixel/setPixel. So the Python
code has to be alignment- and format-aware (e.g. RGB32) and deal with that, but
just the string gets manipulated? Would an iterable (one char per get) as input
and a generator as output (returning each char modified) work faster there
instead of allocating and copying the memory at once, or is that slower,
because of all the switches between "Python land" and "C++ land" when iterators
and generators are used?

By the way: A specific use case that I can think of is "desaturate an image and
make it lighter", just in case you need something to test it with.

One char per get represent 4 loop iterations per pixel, so it's very slow
indeed due to various context switches and object creation/destruction per
iteration.

Even with the string approach this still slow, because strings are immutable
objects in python, so when you are processing the line probably you will create
N strings before you get the final result, when N is the image width. :-/

(In reply to comment #6)
> Even with the string approach this still slow, because strings are immutable
> objects in python, so when you are processing the line probably you will create
> N strings before you get the final result, when N is the image width. :-/

Would the string approach still be significantly faster than the
getPixel/setPixel method?

(In reply to comment #7)
> Would the string approach still be significantly faster than the
> getPixel/setPixel method?

I think only a benchmark would answer that question.

Matti, would you lower the bug priority until we achieve a resonable solution
for the problem?

P3 or P4, I'm not sure...

(In reply to comment #9)
> Matti, would you lower the bug priority until we achieve a resonable solution
> for the problem?
> 
> P3 or P4, I'm not sure...

OK - I'll make it P4 for now. I'll increase the priority right away once
there's a clear plan for this. So, keep the discussion alive. :-)

I've just made a related comment on bug 565. Numpy already provides efficient
mechanisms for working with exactly this sort of data, and my team has deployed
solutions with PyQt using such a mechanism. (We create a QImage from a Numpy
array to begin with, so we don't need scanLine, but for image manipulation
applications it would be convenient.)

To achieve feature parity with PyQt regarding QImage manipulation would require
implementing something analogous to sip.voidptr that supports the Python buffer
interface or wraps other objects that do.

To avoid completely missing other functionality, I'd suggest documenting all of
the `remove=` methods in the typesystem, categorizing them into ones where the
functionality is already covered by a different mechanism (and document that
mechanism) vs methods that are simply not implemented yet. Stubbing out missing
methods would help people who need that functionality be able to implement it
without figuring out the whole typesystem machinery.

What about making QImage implement the buffer protocol?
bits() and scanLine could use PyBuffer_FromReadWriteMemory to return a Python
buffer.

What do you think?

(In reply to comment #12)
> What about making QImage implement the buffer protocol?
> bits() and scanLine could use PyBuffer_FromReadWriteMemory to return a Python
> buffer.
> 
> What do you think?

Is there any case where the internal memory for an image is reallocated? That
would invalidate an object returned from, e.g., bits(), and either silently
stop working or write to freed memory depending on how the memory management
works. To make the QImage _itself_ implement the buffer protocol could avoid
that case for bits(), but scanLine() would be tricky.

(bits() is a misnomer; you're really accessing the bytes.)

A test case for this whole interface would be a resizeable interactive demo
(e.g., Qt's scribble demo) where the image is altered in-place by numpy.
Ideally it would even work on Python 2.6 :)

(In reply to comment #13)
> (In reply to comment #12)
> > What about making QImage implement the buffer protocol?
> > bits() and scanLine could use PyBuffer_FromReadWriteMemory to return a Python
> > buffer.
> > 
> > What do you think?
> 
> Is there any case where the internal memory for an image is reallocated? That
> would invalidate an object returned from, e.g., bits(), and either silently
> stop working or write to freed memory depending on how the memory management
> works. To make the QImage _itself_ implement the buffer protocol could avoid
> that case for bits(), but scanLine() would be tricky.

I did the following:

The constructors accepts any object that implements the buffer protocol, when
you use these constructors you need to keep the buffer alive for the lifetime
of the QImage like C++ do, in other words it doesn't copy the image data.

bits and scanLine also returns buffer objects "without" copying any data, I
wrote the quotes because when you call bits() or scanLine() PySide will call
the non-const version of those methods causing QImage will detach (see QImage
docs). To avoid this memory copy you must call constBits() or constScanLine()

I'll do the merge request soon, the merge will also fix bug 566, if you have
any suggestion the time is now. =]

> (bits() is a misnomer; you're really accessing the bytes.)
> 
> A test case for this whole interface would be a resizeable interactive demo
> (e.g., Qt's scribble demo) where the image is altered in-place by numpy.
> Ideally it would even work on Python 2.6 :)

(In reply to comment #14)
> The constructors accepts any object that implements the buffer protocol

Old or new buffer protocol (or both)?

> I'll do the merge request soon, the merge will also fix bug 566, if you have
> any suggestion the time is now. =]

Excellent! I don't need bits() or scanLine() so I can't speak to whether that
behavior is appropriate, but constructing from buffer-protocol objects like
numpy arrays is great news.

Old, because we need to support python 2.5, Maemo still using it :-/.

Fixed in commit:
pyside/2a4391902406552815140f4ebe078f9f7e9a955c

scanLine(), constScanLine(), bits() and constBits() returns memory buffers.

released on beta 5