[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [pygame] colorspace and other vision functions, where do they belong?
- To: pygame-users@xxxxxxxx
- Subject: Re: [pygame] colorspace and other vision functions, where do they belong?
- From: "René Dudfield" <renesd@xxxxxxxxx>
- Date: Sun, 29 Jun 2008 13:38:02 +1000
- Delivered-to: archiver@xxxxxxxx
- Delivered-to: pygame-users-outgoing@xxxxxxxx
- Delivered-to: pygame-users@xxxxxxxx
- Delivery-date: Sat, 28 Jun 2008 23:38:07 -0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=T263oYRK+m4BmeDKosmfsKLZvczX+XHB0TliF/pPozE=; b=iGuR1xgFcwofN3ZSX8nsgjUw9x5EJA1/SMhV4OedH1TAI7qnDIkMHlQv206w6qm9g8 ET7UQnlOW+MGtJZSWcTGBIfJ0ltKhYn2c3bm/uBM7sxjYDdJjW1NCEqzY8pZG+X/CwPJ TtAKUUEN2aTNoRltLwj6gijcWfy7zsVI9jnvc=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=YERk2SaDrP12zujPDL6nEKYhH3UlKSUlLR/GxwzVtqZhrasbDC8TpCVHIQshRm48KK 7nATvPEmFQt+27yNJOzU3XaqCWV+YiwAocSmkqNJ0eg8hbhinCKoj4HVsxj0YTD2gFf+ BC24za4ilvVBy+EC883K05YMeokk0daY4Kn9g=
- In-reply-to: <a7215bb70806261837h3de7fc7fx32bfd2090187ed40@xxxxxxxxxxxxxx>
- References: <a7215bb70806261837h3de7fc7fx32bfd2090187ed40@xxxxxxxxxxxxxx>
- Reply-to: pygame-users@xxxxxxxx
- Sender: owner-pygame-users@xxxxxxxx
hi,
nice work.
I think the colorspace stuff should go in the color module too. What
do you think Marcus? The main difference is that the Color type works
on one pixel at a time -- whereas the colorspace function would work
on a surface at a time.
I think the optical flow stuff could go in transform for now, and we
can decide where it goes finally in the pygame 1.9 release. I think
at that stage we will have a better idea of what the functions are and
where they can go.
here's some todo's for the camera module:
- unittests
- separate out v4l2 specific stuff.
- camera.c
- camera_v4l2.c camera_quicktime.c camera_directshow.c ... etc
- keep python wrappers separate from C code.
- we are doing this separation for all stuff in pygame 1.9.
- at the moment pygame doesn't follow this for all
functionality, but mostly non-python-wrapping code is kept separate.
- So the C stuff can be used outside of the CPython wrappers.
- eg, the PyCameraObject stuff should be kept separate.
- rgb_to_hsv24 (PyCameraObject* self, const void* src, void* dst)
- rgb_to_hsv24 (CameraObject* self, const void* src, void* dst)
- Probably have a separate camera structure which
PyCameraObject refers to.
- enumerating available cameras.
- get a list of cameras that are available to initialise.
- like how the joystick module can return what joysticks are available.
cheers,
On Fri, Jun 27, 2008 at 11:37 AM, Nirav Patel <olpc@xxxxxxxxxxxxxx> wrote:
> Hello all,
>
> I've added support for outputting different colorspaces from the
> camera, and a Mask.get_centroid() to my pygame branch:
> http://git.n0r.org/?p=pygame-nrp;a=summary
>
> With the functions I'm writing now, I'm not sure what modules they
> would belong in, or if they should be in a new module. The functions
> are things like converting the colorspace of a whole Surface, and
> computing optical flow between two surfaces. It makes sense that the
> colorspace stuff would go in the color module, except that that module
> is currently just for the Color class. Optical flow could go in
> transform, but it's not really a transform (though neither is
> threshold, which is in it).
>
> The colorspaces function would basically be as follows:
>
> colorspace(Surface, colorspace, colorspace) returns Surface, where the
> starting and ending colorspace is "RGB" "YUV" or "HSV".
>
> Nirav
>