hello, I tried out your camera code on my linux laptop... nice work!
I also tried Michaels demo - quite fun indeed! not just for kids either... A couple of notes... You could supply a surface to get_image() cam.get_image(destination_surface) Much like the transform.scale, and a few other functions do. This means that you don't need to keep allocating memory each time - which turns out to save a lot of time. I'ved modified your camera.c file: http://rene.f0o.com/~rene/stuff/camera.c also modified Michaels demo to reuse the surface: http://rene.f0o.com/~rene/stuff/camera.py cheers, On Mon, Jun 9, 2008 at 10:53 AM, Nirav Patel <[EMAIL PROTECTED]> wrote: > The latest code at http://git.n0r.org/?p=pygame-nrp;a=summary has > Camera.query_image() which returns true or false depending on if there > is a frame ready to take. I know this isn't really the same as > non-blocking access, but the end result is similar without having to > add Camera to Event (keeping it an optional module) and keeping it > simple to use. It doesn't appear to work with vivi, but I think > that's an intentional vivi thing. > > I also added RGB565 support, but I either have the colors wrong, or > the RGB565 mode on the OV7670 in the XO isn't actually RGB565. > > I'm going to try to debug RGB565 and add a few formats like YUV420 and > Bayer RGB. That should cover almost all webcams around, but if anyone > has camera that needs something else, its easy to add. My next step > is going to be to working on some functions that would be useful for > computer vision purposes. > > Nirav > > On Tue, Jun 3, 2008 at 9:27 AM, Nirav Patel <[EMAIL PROTECTED]> wrote: >> Hello, >> I haven't had internet access for a few days, so I didn't get this >> message before I started coding. Luckily, I ended up doing a lot of >> the things you suggested. >> >> I have written the camera as an object created with >> camera.Camera(device, (width, height)), and with .start() which opens >> and starts it, .get_image() which returns a Surface, and .close() >> which stops and closes it. >> >> Currently, I just have get_image blocking, though it is a simple >> change to make it non blocking. MMAP by nature uses buffers. When >> using it non blocking, the camera driver would return EAGAIN if there >> is no buffer available yet. I could just make it return the last >> frame again on EAGAIN, though I'm not sure that is the best way. >> >> For querying, I'm not sure what would be useful beyond knowing what >> resolutions were supported, and as far as I know v4l2 drivers don't >> really let you know that beyond a suggested resolution. Right now, >> the width, height you create the camera with is not necessarily the >> width, height of the Surfaces being returned. >> >> The code I'm working on is at http://git.n0r.org/?p=pygame-nrp;a=summary >> >> As of the latest snapshot, it currently supports YUYV and RGB24 >> (though that is untested) cameras. I've tested it so far with vivi >> and the webcam in the OLPC XO. >> >> Nirav >> >> On Fri, May 30, 2008 at 3:06 PM, René Dudfield <[EMAIL PROTECTED]> wrote: >>> hi, >>> >>> a few notes... >>> >>>> The basic plan is to use V4L2_MEMORY_MMAP, mmap() the image buffer, >>>> and convert the image to RGB24 (if it isn't already) as a Surface. >>> >>> I like that idea. >>> >>> >>> *- it needs multiple camera support. >>> >>> So make it create a camera object. >>> >>> For example: >>> a_camera = camera.Camera(device, width, height) >>> >>> a_camera.get_image() >>> >>> *- you could try implementing your api with the opencv python wrapper. >>> This way you could start adding tests early on. >>> >>> >>> *- since many cameras are low frame rate, it would be nice if there >>> were events emitted for things like FRAME_AVAILABLE. >>> >>> eg. if a camera is 10fps then it'd be good if the get image call >>> didn't block - so then the rest of the program can run faster. >>> >>> This could require buffering of frames. Perhaps in a separate thread. >>> Or maybe there could be a blocking call, and the rest is left up to the >>> user. >>> >>> What do you think is a good way to handle blocking? >>> >>> Also I think some cameras require you to get the image data at a >>> certain frequency... otherwise an internal buffer overflows or >>> something. This has been my experience with opencv anyway. >>> >>> >>> *- Some way to query camera capabilities? >>> >>> >>> >>> >>> >>> On Tue, May 27, 2008 at 3:22 PM, Nirav Patel <[EMAIL PROTECTED]> wrote: >>>> Hello all, >>>> >>>> I'd like to propose a pygame module to enable camera support. >>>> Specifically, v4l2 support with the eventual possibility of v4l and >>>> vfw. I realise having only v4l2 to start with limits it to linux, but >>>> its a start. It will consist of the following functions. >>>> >>>> camera.open(device, width, height) >>>> camera.start() >>>> camera.getimage() returns Surface >>>> camera.stop() >>>> camera.close() >>>> >>>> The parameters for open are intentionally simple. Similar to >>>> libraries like OpenCV, it will negotiate with the v4l2 drivers to pick >>>> an acceptable pixel format. At least to start with, the supported >>>> pixel formats would be the most common ones like RGB3 (RGB24), R444 >>>> (RGB444), YUYV, and others that people want. >>>> >>>> The basic plan is to use V4L2_MEMORY_MMAP, mmap() the image buffer, >>>> and convert the image to RGB24 (if it isn't already) as a Surface. >>>> >>>> Nirav Patel >>>> >>> >> >
