[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] colorspace and other vision functions, where do they belong?



Nice work Nirav!

I'll pull your performance improvements to the existing functions into
the 1.8.1 release.

At some point it would be good to make unittests for the new stuff you've done?

cheers,



On Thu, Jul 10, 2008 at 12:15 PM, Nirav Patel <olpc@xxxxxxxxxxxxxx> wrote:
> For now, I have placed the colorspace conversion stuff in the camera
> module, as it reuses a few of the functions in it.  I'm trying to
> isolate the camera module for now, since it should stay optional.
>
> Since the last time I posted to this list, I've written the following functions:
>
> camera.colorspace(Surface, format, Surface = None) returns Surface
> Converts the input RGB surface to a YUV or HSV surface.  This is
> useful for two reasons.  It allows you to have both RGB for display
> and YUV or HSV for processing versions of each frame captured.  It
> also allows you to make each captured frame smaller before doing the
> cpu intensive RGB -> YUV or HSV.
>
> transform.average_color(Surface, Rect = None) returns Color
> Another thing that doesn't necessarily belong in transform, but is
> there until we can find a better place for it.  It computes the
> average color of a region of a Surface or the whole Surface.  This is
> useful for computer vision in that a threshold for transform.threshold
> can be picked based upon the color of an area.  For example, there is
> a box overlaid upon frames being captured by the camera, and the user
> is asked to hold up an object so that the box on screen is full of it,
> and then click the mouse.  transform.average_color would then find the
> average color within the box and threshold around it to track the
> object.
>
> mask.connected_component() returns Mask
> It returns the Mask of the largest connected component in a Mask.  In
> testing performance, this function is at least twice as fast as
> mask.get_bounding_boxes in most cases.  Of course, the two functions
> do different things, so its not an apples to apples comparison.
>
> I've also modified some existing pygame functions:
>
> transform.threshold()
> I've modified threshold to increase it's performance.  The biggest
> change is manually using bit masks and shifts for each color rather
> than calling SDL_GetRGBA.  This alone accounted for a 2x increase in
> speed in the function.  I also changed it to increment a pointer,
> though the improvement there is negligable on modern computers.
>
> mask.from_surface()
> The same changes as with threshold.  When using per pixel alphas, it
> is now twice as fast because of avoiding SDL_GetRGBA.  Again,
> incrementing a pointer instead of doing surf->pixels + y*surf->pitch +
> x results in a small performance increase.
>
> Next up, I'm going to implement René's suggestion of being able to
> detect available cameras.
>
> Nirav
>
> On Sun, Jun 29, 2008 at 12:38 PM, René Dudfield <renesd@xxxxxxxxx> wrote:
>> 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,
>>
>>
>>
>>
>