Hmm, from my (admittedly limited) experience of codecs and video files
during the development of the new movie module, it looks like a few things
are wrong. The red and green channels are coming out in the buffer in the
opposite order to what the Surface format expects them. I only have Linux,
but have you tried changing the mode from RGB to BGR? I ask because of this
line:
im = Image.fromstring('RGB', (width, height), buffer, 'raw', 'BGR', 0,
-1)
leads me to realize that the format coming out of vidcap.pyd is in BGR
format, not RGB format like the Surfaces expect. Looking at the
documentation for the Image.fromstring method, it says that putting a -1 at
the end flips the image. Then looking at pygame.image.fromstring:
http://www.pygame.org/docs/ref/image.html#pygame.image.fromstring there is a
flipped boolean. Use it. ;)
It does seem strange that frombuffer doesn't have a flipped argument, and
I'm not sure why. Anyone else able to add some insight?
-Tyler
On Sat, Jun 13, 2009 at 9:35 PM, Ian Mallett <[email protected]> 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.pytakes
> 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
>
--
Visit my blog at http://oddco.ca/zeroth/zblog
