Re: [pygame] Proposed Module: Camera

["Nirav Patel" <olpc@xxxxxxxxxxxxxx>]

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