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)
Yes, that's my theory. I already tried it, and unfortunately, "BGR" doesn't seem to be a valid argument to the function.
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?
I think it's because it returns a reference to already existing data in such a way that PyGame can use it, maybe?
On Sat, Jun 13, 2009 at 10:25 PM, Nirav Patel
<olpc@xxxxxxxxxxxxxx> wrote:
I don't know exactly how VideoCapture is implemented, but the camera
buffer is apparently in BGR color order and the pixels are in reverse
order.
Thus, you can't use it directly as a Surface. You could fix the
upsidedown image by using pygame.image.fromstring() with the last
argument as True. It would probably be faster than going through PIL,
but then once you switch R and B with Numpy, it'll be slower again.
It would only be worth it if you don't want PIL as a dependancy.
I'm going to need NumPy for image processing anyway, so it shouldn't be too bad. And yes, I don't want PIL as a dependency.
This is what I was trying originally. The code I provided is all set up. I just am having trouble implementing the reg/blue flip. After some failed attempts, I scrapped that section so people could add suggestions for what to put in-between lines 39 and 40 to fix the problem. Any thoughts there?
On Sat, Jun 13, 2009 at 10:40 PM, Nirav Patel
<olpc@xxxxxxxxxxxxxx> wrote:
Anyway, in general, it probably isn't worth the effort. Native
Windows camera support for pygame is coming eventually...
I know, but it would be nice to have something that works now. How soon is "eventually"?
Nirav
Thanks,