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

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

On Thu, Jul 10, 2008 at 12:42 PM, Nirav Patel <olpc@xxxxxxxxxxxxxx> wrote:
> René,
>
> Before you pull them into 1.8.1, I'm not sure about
> transform.threshold().  There was code that I left out that supported
> having two input Surfaces, but which wasn't documented in the API.  It
> isn't a difficult thing to add back in, but I wasn't sure if it was
> something previously implemented and then taken out of the API, or
> partially implemented and not yet in the API, or something.
>
> If I do add it back in, should I modify the documentation to reflect
> that it exists?  Would it then be a feature addition that should be
> held off until 1.9?
>

ah, ok.  It's a fairly complicated function signature, that can do a
number of different things.

yeah, if you could add it back, that would be good.  There are tests
there for that function... I hope they cover everything, but not sure.
 I'll have to have a look later.

Are you talking about this part?
"Or it can be used to just count the number of pixels within the
threshold if you set change_return to False. "

That's also useful for things like your average_color thing.  So you
can see how much of the surface is close to red for example -- without
writing to the destination surface.

Yeah, some better documentation of it would be nice too :)



> I do plan on writing unit tests for the things I've written, but I'm
> not sure how to do it for the camera modules, since so much of it
> depends on the specific camera hardware, some of which I don't
> actually have.
>

I think there are a couple of ways to do it...

1.mock objects/null drivers.  So instead of using real hardware, you
code can make code which pretends to be the hardware.  I don't think
you have to do it at the v4l level, but maybe that can give you some
ideas.

This can be made easier by overriding methods.  eg, subclass your
object, and replace the get_raw function, with a mock one.


2. functional tests... assume the hardware is present, and figure out
some automated tests you can do.

Also you can unittest just parts that are easy to test.  eg, the
colorspace conversion stuff.

3. manual inspection... nicholas is going to work on a test framework
for this... but up until now we just use example programs and look at
them.  These are useful when there's no other possible way to test
things... but obviously not as good as automated tests.



> Nirav
>
> On Thu, Jul 10, 2008 at 11:29 AM, René Dudfield <renesd@xxxxxxxxx> wrote:
>> 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,
>>
>