Re: [pygame] Proposed Module: Camera

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

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 <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
>>>
>>
>