Re: [pygame] colorspace and other vision functions, where do they belong?
Ok, I added support for the second surface and documentation for it. It is in the latest revision in my repo. http://git.n0r.org/?p=pygame-nrp;a=summary On Thu, Jul 10, 2008 at 1:17 PM, René Dudfield <[EMAIL PROTECTED]> wrote: > On Thu, Jul 10, 2008 at 1:43 PM, Nirav Patel <[EMAIL PROTECTED]> wrote: >> This would suggest that the function should be: >> pygame.transform.threshold(DestSurface, Surface, color, threshold = >> (0,0,0,0), diff_color = (0,0,0,0), change_return = True, Surface = >> None): return num_threshold_pixels > > ah yes, that thresholds between two surfaces... definitely a bug in > the docs and tests. >
Re: [pygame] colorspace and other vision functions, where do they belong?
On Thu, Jul 10, 2008 at 1:43 PM, Nirav Patel <[EMAIL PROTECTED]> wrote: > This would suggest that the function should be: > pygame.transform.threshold(DestSurface, Surface, color, threshold = > (0,0,0,0), diff_color = (0,0,0,0), change_return = True, Surface = > None): return num_threshold_pixels ah yes, that thresholds between two surfaces... definitely a bug in the docs and tests.
Re: [pygame] colorspace and other vision functions, where do they belong?
On Thu, Jul 10, 2008 at 11:59 AM, René Dudfield <[EMAIL PROTECTED]> wrote: > On Thu, Jul 10, 2008 at 12:42 PM, Nirav Patel <[EMAIL PROTECTED]> wrote: > > 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 :) According to the documentation, the function is as follows: pygame.transform.threshold(DestSurface, Surface, color, threshold = (0,0,0,0), diff_color = (0,0,0,0), change_return = True): return num_threshold_pixels However, the arguements it actually parses are: if (!PyArg_ParseTuple (arg, "O!O!O|OOiO!", &PySurface_Type, &surfobj, &PySurface_Type, &surfobj2, &rgba_obj_color, &rgba_obj_threshold, &rgba_obj_diff_color, &change_return, &PySurface_Type, &surfobj3)) This would suggest that the function should be: pygame.transform.threshold(DestSurface, Surface, color, threshold = (0,0,0,0), diff_color = (0,0,0,0), change_return = True, Surface = None): return num_threshold_pixels The way the function was written, when given the optional third surface, it would use the colors in that rather than the "color" specified in the function to check against. As far as I can tell, this isn't tested or documented anywhere, it just exists in the code. It does seem like a useful thing to have though, so I'll write it back into my version of it and document it. > 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. There is a mock driver, vivi, that I've been testing with. This can be used for most of the testing, but not all of it, since it only supports YUYV. It could then not be used to test RGB24, RGB444, YUV420, or SBGGR8, and also some parts of colorspace conversion from those pixelformats to RGB, YUV, and HSV. There is also the trouble that being sure its working correctly depends on human inspection for things like, do the colors look ok, is there tearing going on, is part of the image cut off, etc. I can do automated testing on a lot of it though, like making sure the size of the Surfaces returned are what I expect and so on.
Re: [pygame] colorspace and other vision functions, where do they belong?
On Thu, Jul 10, 2008 at 12:42 PM, Nirav Patel <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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, >> >
Re: [pygame] colorspace and other vision functions, where do they belong?
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? 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. Nirav On Thu, Jul 10, 2008 at 11:29 AM, René Dudfield <[EMAIL PROTECTED]> 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, >
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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, >> >> >> >> >
Re: [pygame] colorspace and other vision functions, where do they belong?
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 <[EMAIL PROTECTED]> 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, > > > >
Re: [pygame] run_tests.py subprocess mode and Build Page extensions
Lenard, I will commit your change, thanks. I must admit I took that recipe and used it without knowing exactly how it worked much the same way I would use a library. How does the async Popen recipe look to you? I'm starting to wonder at the wisdom of using recipes. That was from ActiveState Python CookBook. I put in one test for it but.. if ret_code is None: proc.kill() Should we make it try a few times upon failure? If it fails would there be much chance of killing it in the immediate future? What situations would cause a failure? It might even make sense to move that kill functionality into the async_sub.Popen method read_async(). read_async(time_out=10, kill=True) Ciao. I tried the updated run_tests and it works. Killed python interpreters disappear. Thanks for the changes. I do suggest some modifications to Popen.kill though. First, the win32api functions raise Python exceptions on Windows errors rather than use return values. Second, handles should be closed. Here is my version: def kill(self): """kill function for Win32""" try: handle = win32api.OpenProcess(1, 0, self.pid) try: win32api.TerminateProcess(handle, 0) finally: win32api.CloseHandle(handle) except win32api.error: return False return True
Re: [pygame] run_tests.py subprocess mode and Build Page extensions
I tried the updated run_tests and it works. Killed python interpreters
disappear. Thanks for the changes.
I do suggest some modifications to Popen.kill though. First, the
win32api functions raise Python exceptions on Windows errors rather than
use return values. Second, handles should be closed. Here is my version:
def kill(self):
"""kill function for Win32"""
try:
handle = win32api.OpenProcess(1, 0, self.pid)
try:
win32api.TerminateProcess(handle, 0)
finally:
win32api.CloseHandle(handle)
except win32api.error:
return False
return True
Lenard
Nicholas Dudfield wrote:
I'm not sure... but if it works without we can cut it huh? I was under
the impression that unless you ran a shell as intermediary you had to
use absolute paths for everything(I thought that using shell would
provide the env) but it seems I was on crack.
>> And if anything hangs it can still be killed by Process Viewer.
I was more thinking more for the automated build page, where a
"client" could be left for days without supervision.
A single process os.kill using TerminateProcess would then work if
there was no intermediary shell huh? If shell = 0 it won't start the
(shell) cmd.exe or command.com etc first?
..
OK, I just tried and indeed it thats what happens using shell=0. I
used process explorer and run_tests.py only creates python.exe
children. No process tree == win98 happiness.
.
I removed the taskkill, pskill os.kill() hack and replaced it with a
method on the async Popen object. If not windows, it uses os.kill()
if subprocess.mswindows:
def kill(self):
"""kill function for Win32"""
handle = win32api.OpenProcess(1, 0, self.pid)
return (0 != win32api.TerminateProcess(handle, 0))
So, we should now be good for win98+ and *nix ?
Thanks for your help Lenard.
Lenard Lindstrom wrote:
This is not a big issue. I don't think there is anything like a
process tree in Windows 98. And if anything hangs it can still be
killed by Process Viewer. The timeout works, so that is all that
really matters. Just out of curiosity though, why use a shell as an
intermediary. Why isn't the Python interpreter executed directly in
the subprocess?
>>> cmd = 'python -c "print \\"Hello.\\""'
>>> print cmd
python -c "print \"Hello.\""
>>> import subprocess
>>> out = open('C:/windows/desktop/stdout.txt', 'w')
>>> s = subprocess.Popen(cmd, stdout=out)
>>> s.wait()
0
>>> out.close()
>>> print open('C:/windows/desktop/stdout.txt').read()
Hello.
Lenard
Nicholas Dudfield wrote:
Lenard,
Weird, XP? Vista? I'm on XP SP3
By passing an env = {} to the Popen constructor temporarily to
remove PATH from the environment it fails my end.
D:\Nick\PyGame\trunk>run_tests.py -s
No way of killing unruly processes. Try installing sysinternals
pskill and placi
ng on %PATH%.
I found a recipe for TerminateProcess, but it didn't kill child
processes so it would stop the run_tests from hanging but on mine at
least, python would call cmd which would in turn call python. It
would only kill cmd.exe, leaving python to run rampant.
cmd
pythonrun_tests.py
cmdpython
_test.py
But yeah, we really need it to be consistent however it works. It
would be nice if it would kill process trees also.
You are more than welcome to make any changes.
To run a test_suite with a test that "while True: pass"
$ run_tests.py -s -f infinite_loop
I have been meaning to add that to the run_tests test.
Cheers
Lenard Lindstrom wrote:
Hi,
I tried running the tests in subprocess mode an everything passed.
Great, except I didn't have either pskill or taskkill installed.
When checking for the programs Popen.wait() always returned 0, even
when the program was not found. So it incorrectly assumed I had
pskill installed (first in the list). Anyway, since pywin32 is
already required, why not do the TerminateProcess system call
directly, making pskill or taskkill unnecessary. If interested I
can making the necessary changes to async_sub.py.
Re: [pygame] The gsoc physics module, bug fixing?
Hi Peter, Thanks for your careful attention to my works :-) I use OpenGL just for testing physics algorithms in C because this's no need for python wrapper, I can focus more on finishing algorithms first. Of course, finally, this testing method will be abandoned, which means glut is no need to link. Currently I start with some works about python wrapping, and I finished some codes and extended some basic functions for python wrapping. The python test file "test1.py" is being under test, and there are some bugs in python wrapping. I plan to publish my work to the community when these basic works have been done. Best wishes Zhang Fan Peter Gebauer <[EMAIL PROTECTED]> 写道： Hi guys! I noticed a lot has happened, but very little communication here, is everything going alright? :) There's a new test1.py suggesting there would be Python side testing available, but I keep getting ImportError: ./build/lib.linux-x86_64-2.5/physics.so: undefined symbol: glutBitmap9By15 when trying to import the physics module. Is it necessary to link glut (or whatever is needed) to test? Or should I just hold my horses and settle down for a while longer? /Peter On 2008-06-29 (Sun) 15:30, Marcus von Appen wrote: > On, Sun Jun 29, 2008, Peter Gebauer wrote: > > > Hi Zhang and others! > > [Python wrapper issues] > > The wrapper implementation is not really started yet, so it's a bit > early. In order to keep argument parsing flexible, I'd recommend using > METH_VARARGS and PyArg_ParseTuple() instead of the _0, ... macros. This > let's one easily enhance anything without the need to change too much > code. Additionally you can let the parser handle argument checking > without the need to deal with ex- or implicit object conversions. > > Regards > Marcus - 雅虎邮箱，您的终生邮箱！
Re: [pygame] The gsoc physics module, bug fixing?
On, Wed Jul 09, 2008, Peter Gebauer wrote: > Hi guys! > > I noticed a lot has happened, but very little communication here, is > everything going alright? :) > There's a new test1.py suggesting there would be Python side testing > available, but I keep getting > > ImportError: ./build/lib.linux-x86_64-2.5/physics.so: undefined symbol: > glutBitmap9By15 Just noticed that myself. > when trying to import the physics module. > > Is it necessary to link glut (or whatever is needed) to test? Or should I > just hold my horses and settle down for a while longer? It should not use OpenGL in any way, so I guess that this one sneaked in somehow. Feel free to test and do whatever you want with the code. I'll discuss the further proceeding for the Python wrapper with Zhang Fan today, so that we have some rough timeline for it and can start testing anything using Python. Regards Marcus pgpdvkY7I5Ua1.pgp Description: PGP signature
Re: [pygame] The gsoc physics module, bug fixing?
Hi guys! I noticed a lot has happened, but very little communication here, is everything going alright? :) There's a new test1.py suggesting there would be Python side testing available, but I keep getting ImportError: ./build/lib.linux-x86_64-2.5/physics.so: undefined symbol: glutBitmap9By15 when trying to import the physics module. Is it necessary to link glut (or whatever is needed) to test? Or should I just hold my horses and settle down for a while longer? /Peter On 2008-06-29 (Sun) 15:30, Marcus von Appen wrote: > On, Sun Jun 29, 2008, Peter Gebauer wrote: > > > Hi Zhang and others! > > [Python wrapper issues] > > The wrapper implementation is not really started yet, so it's a bit > early. In order to keep argument parsing flexible, I'd recommend using > METH_VARARGS and PyArg_ParseTuple() instead of the _0, ... macros. This > let's one easily enhance anything without the need to change too much > code. Additionally you can let the parser handle argument checking > without the need to deal with ex- or implicit object conversions. > > Regards > Marcus
