Nice one :) I'll try it out, and read your code when I get home... and hopefully give you some feedback.
Have started on any unittests? cu, On Tue, Jun 3, 2008 at 10: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 >>> >> >
