Re: [pygame] VideoCapture, PIL, and PyGame

[Nirav Patel <olpc@xxxxxxxxxxxxxx>]

It has to happen at some point.  Changing the Surface shifts and masks
makes it happen at blit time, reversing the string or writing a C
function, earlier.  Certainly, either removes the PIL dependency.

The issue is then picking the faster way.  I think string reversal in
Python is probably slower than doing transform.flip() and moving bytes
during the blit, but it would be an easy thing to benchmark.

Nirav

On Sun, Jun 14, 2009 at 9:57 PM, Forrest Voight<voights@xxxxxxxxx> wrote:
> Why not just reverse the string in order to do the BGR->RGB
> conversion? This will also vertically and horizontally flip it, so
> you'll just need to horizontally flip it.
>
> On Sun, Jun 14, 2009 at 2:25 AM, René Dudfield<renesd@xxxxxxxxx> wrote:
>> hi,
>>
>> take a look at svn pygame.  There is an implementation of
>> pygame.camera which uses the VideoCapture module.
>>
>> cheers,
>>
>>
>>
>> On Sun, Jun 14, 2009 at 2:35 PM, Ian Mallett<geometrian@xxxxxxxxx> wrote:
>>> Hi,
>>>
>>> So, I'm trying to get VideoCapture working with PyGame.  I've modified the
>>> standard VideoCapture.py file to make it simpler and easier to read.  I've
>>> attached it as well as my program, main.py.
>>>
>>> VideoCapture.py defines a class Device.  Device has two functions that I'm
>>> concerned with: .getBuffer(), which returns (string_data,width,height), and
>>> .getImage(), which returns a PIL image made with .getBuffer().
>>>
>>> I'm trying to get a PyGame surface from all this.  Every code sample I've
>>> seen converts the PIL image (returned from .getImage()) back into a string,
>>> and then makes a PyGame image with pygame.image.frombuffer(...):
>>> im = Camera.getImage()
>>> image = pygame.image.frombuffer(im.tostring(), im.size, im.mode)
>>>
>>> Though this works nicely, it seems terribly inefficient--VideoCapture.py
>>> takes the data as a string from .getBuffer(), and makes a PIL image.  The
>>> main, main.py, must then change this PIL image back into a string again, and
>>> then make a PyGame surface from that.  (Basically:
>>> STRING->PIL->STRING->PYGAME).  This setup doesn't fly realtime.  Moreover,
>>> it requires an extra dependency, PIL.
>>>
>>> So, I tried just converting the original string from .getBuffer() directly
>>> into a PyGame surface.  (Basically: STRING->PYGAME):
>>> data = Camera.getBuffer()
>>> image = pygame.image.frombuffer(data[0],(data[1],data[2]),"RGB")
>>>
>>> But this has problems.  It doesn't crash, but the image is upsidedown and
>>> the red and blue color channels appear to be flopped.  I tried fixing it
>>> with surfarray, which didn't work.  Then I tried finding what was wrong, and
>>> got inconsistent results.
>>>
>>> How can I get the second method (method 2: STRING->PYGAME) to look like the
>>> first method (method 1: STRING->PIL->STRING->PYGAME)?  main.py lets you
>>> switch back and forth (press 1 for method 1, 2 for method 2).
>>>
>>> Ian
>>>
>>
>