Re: [pygame] Proposed Module: Camera

["Nirav Patel" <olpc@xxxxxxxxxxxxxx>]

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 <renesd@xxxxxxxxx> 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 <olpc@xxxxxxxxxxxxxx> 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
>>
>