Re: [pygame] Proposed Module: Camera

["René Dudfield" <renesd@xxxxxxxxx>]

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