Just to clarify, I think the get_hw_capabilities function is very useful and will merge it in soon, but I'm not sure about automatic software flipping.
Nirav On Sun, May 10, 2009 at 11:22 AM, Nirav Patel <[email protected]> wrote: > This is certainly a good idea. The issue is that controls are often > very poorly implemented in camera drivers. Some drivers do support > hardware flipping but don't respond to VIDIOC_QUERYCTRL, while some > return true to a VIDIOC_S_CTRL while not actually doing the flip that > they were told to do. I have yet to come across a case of responding > false to VIDIO_S_CTRL while still doing the flip, but it is not > unfathomable. I think having automatic software flipping could cause > as many problems as it fixes. > > The solution I was hoping people would go for would be for pygame > apps/games that use the camera to have options somewhere, commandline, > keyboard, or otherwise, that would allow the user to say whether or > not to flip it in software, as seeing the image is the only way to > guarantee the correct behavior. > > That is just my opinion though, what does everyone else think? > > Nirav > > On Sun, May 10, 2009 at 9:31 AM, <[email protected]> wrote: >> Hi, >> >> I was testing the camera module and was a bit disappointed to find that my >> camera >> doesn't support flipping via Camera.set_controls(). >> I thought that it would be a good idea if these basic settings should work >> whether >> the camera supports them or not. So I set out to write a patch which >> implements >> this. >> >> The patch does three things: >> 1) it exposes a C-API for transform.flip() >> 2) it adds a new field "filter" to the camera object. When the user calls >> set_controls() and the camera doesn't support h/vflip then it sets a flag in >> the >> filter variable. when Camera.get_image() is called and the flag is set the >> surface >> returned from the camera is passed through transform.flip() to get the >> desired >> result. >> 3) adds a new public method Camera.get_hw_capabilities() which returns a >> tuple >> (hflip, vflip) containing booleans so signal if the camera device supports >> flipping. >> >> caveat: >> the transform.flip() function doesn't perform the flip in-place but rather >> returns a new surface. therefor the software filter so far only works when >> creating >> a new surface in the get_image() call (i.e. "new_surf = cam.get_image()" and >> not >> "cam.get_image(screen)") >> >> I tried to design this in an extensible way so that one can use the "filter" >> variable to later add other filters like color inversion. >> >> >> regards, >> Lorenz >> >
