Here is a screen shot : http://www.toonloop.com/?q=support
Since that shot, I added a GLSL chroma key. a 2009/4/20 Nirav Patel <[email protected]>: > Err, oops, I should have proofread that. It should state: > > camlist = camera.list_cameras() > if len(camlist) > 0: > cam = camera.Camera(camlist[0]) > > Just a caveat though. The way list_cameras is currently set up, it > will also detect v4l cameras, which are not actually supported. I > will most likely remove this feature before the 1.9 release. > > Nirav > > On Mon, Apr 20, 2009 at 11:04 AM, Nirav Patel <[email protected]> wrote: >> I'm not sure what it would be without seeing the error output, but >> there is a way around that. camera.list_cameras() will return a list >> of the cameras plugged into the computer. If the list is empty, you >> know it found no cameras. You could use it as follows: >> >> camlist = camera.list_cameras() >> if len(cameras) > 0: >> cam = camera.Camera(camlist[0]) >> >> Nirav >> >> On Mon, Apr 20, 2009 at 9:46 AM, Alexandre Quessy <[email protected]> >> wrote: >>> Hello René, >>> We save frames in lists. You can take a frame either by pressing space >>> bar, or using an intervalometer. (for timelapses) The right region of >>> the display shows the resulting animation in a loop. (for now) The >>> left region shows the current video input, plus an optional onion skin >>> of the last recorded frame. A screen shot will be online soon. >>> >>> By the way, there is an other bug. With V4L2, if there is no camera >>> plugged-in, sometimes, I get a null pointer error and it says "Pygame >>> parachute", or something. And then it crashes. I have heard it's v4l2 >>> that is a bit flaky, but that some higher-level wrapper, such as >>> Gstreamer, make sure things don't crash when using v4l2. Of course, >>> bugs are not reproducable when you need them.... (so that I could >>> copy-paste the output here) >>> >>> a >>> >>> >>> >>> 2009/4/19 René Dudfield <[email protected]>: >>>> looks pretty cool :) >>>> >>>> How does it work? >>>> >>>> I imagine you can take snapshots, and then do playbacks? Or can you do a >>>> video recording too? So in video mode, it'd take snapshots at a given >>>> frame >>>> rate. >>>> >>>> Are there any screen shots? >>>> >>>> >>>> >>>> >>>> On Sat, Apr 18, 2009 at 12:54 PM, Alexandre Quessy <[email protected]> >>>> wrote: >>>>> >>>>> Problem solved !! >>>>> Thanks a lot Nirav. >>>>> >>>>> If you want to try toonloop, you can checkout the code and run it. >>>>> The installation instructions for Ubuntu are in here : >>>>> http://code.google.com/p/toonloop/source/browse/trunk/doc/INSTALL.txt >>>>> >>>>> Try ./toonloop.py --help for startup flags, and press "h" while it is >>>>> running for instructions. >>>>> It needs a valid pygame camera, of course. >>>>> See http://toonloop.com for more informations. >>>>> We need beta testers too. And I think this is a wonderful application >>>>> of pygame.camera. >>>>> >>>>> a >>>>> >>>>> 2009/4/17 Nirav Patel <[email protected]>: >>>>> > Also, forgot to mention this, but thanks for using the camera module! >>>>> > It has yet to experience widespread use, so this kind of beta testing >>>>> > is great to get it ready for the next pygame release. >>>>> > >>>>> > Nirav >>>>> > >>>>> > On Fri, Apr 17, 2009 at 11:17 AM, Nirav Patel <[email protected]> >>>>> > wrote: >>>>> >> Ah yes, this seems to be a bug in both JPEG saving and in the camera >>>>> >> module. Fun stuff. >>>>> >> >>>>> >> The JPEG assumes that any 24 bit surface is going to be in the exact >>>>> >> color order that it expects. Which is fine, except that the default >>>>> >> color order for a 24 bit Surface is not that. >>>>> >> >>>>> >> This also led me to find a bug in the camera module though, where if >>>>> >> you are using a 24 bit surface, it will assume you want the default >>>>> >> color order, regardless of if you hand it a Surface to use that has a >>>>> >> different color order. >>>>> >> >>>>> >> I commited the one line fix for JPEG, which just does an additional >>>>> >> check to see if it needs to create a new surface or not. Please test >>>>> >> it if you can. The fix for the camera module may take longer, as I >>>>> >> need to rethink some assumptions, though in the vast majority of use >>>>> >> cases, users should not be effected. >>>>> >> >>>>> >> Nirav >>>>> >> >>>>> >> On Fri, Apr 17, 2009 at 9:48 AM, René Dudfield <[email protected]> >>>>> >> wrote: >>>>> >>> Hi, >>>>> >>> >>>>> >>> can you please let me know the result of: >>>>> >>> >>>>> >>> cam_surf = X >>>>> >>> normal_surf = pygame.Surface((1,1)) >>>>> >>> surfs = cam_surf, normal_surf >>>>> >>> >>>>> >>> for s in surfs: >>>>> >>> print s.get_losses(), s.get_masks(), s.get_shifts() >>>>> >>> >>>>> >>> I think maybe the jpeg saving code isn't respecting one of those. >>>>> >>> Actually... don't worry, I'm pretty sure that's the cause of it. >>>>> >>> Will fix >>>>> >>> soon. >>>>> >>> >>>>> >>> cheers, >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> On Fri, Apr 17, 2009 at 11:14 PM, Alexandre Quessy >>>>> >>> <[email protected]> >>>>> >>> wrote: >>>>> >>>> >>>>> >>>> Hello Pygame people, >>>>> >>>> This is my first post on this list, and more might follow since I am >>>>> >>>> using pygame for ToonLoop, a stop motion software. The new >>>>> >>>> pygame.camera module works for me and this is very good job. Thanks >>>>> >>>> for contributing that ! >>>>> >>>> >>>>> >>>> I think I found a bug ! Hopefully it is only my code that is wrong >>>>> >>>> and >>>>> >>>> this is easy to fix. >>>>> >>>> >>>>> >>>> When I save a Pygame surface that I obtained using pygame.camera to a >>>>> >>>> JPEG using pygame.image.save, the colors are messed up. It looks like >>>>> >>>> the red and blue channels are interchanged. Thus, maybe my surface is >>>>> >>>> RBG, whereas pygame.image expects RGB. A camera image doesn't contain >>>>> >>>> any alpha channel usually. >>>>> >>>> >>>>> >>>> When I display the surface as a pygame sprite the colors are OK. >>>>> >>>> When I display the surface as an OpenGL texture the colors are OK. >>>>> >>>> (using tostring(surface, "RGBX", True)) >>>>> >>>> When I save the surface as an other format such as PNG or BMP the >>>>> >>>> colors >>>>> >>>> are OK. >>>>> >>>> When I use a surface obtained by loading a JPG image, the colors are >>>>> >>>> OK. >>>>> >>>> The bug only occurs when I save a surface obtained using the >>>>> >>>> pygame.camera module. >>>>> >>>> It consistently happened on 3 Linux computers. >>>>> >>>> >>>>> >>>> I use Pygame compiled from today's SVN with Python 2.5.2 on Ubuntu >>>>> >>>> GNU/Linux 8.10 using a V4L2 device. (a WinTV card) >>>>> >>>> >>>>> >>>> A short code snippet to reproduce the bug: >>>>> >>>> http://rafb.net/p/gccaJG37.html >>>>> >>>> >>>>> >>>> A JPEG to see how the output looks like : >>>>> >>>> http://toonloop.com/static/tmp/image_color_test_out.jpg >>>>> >>>> A correct image in an other format to compare : >>>>> >>>> http://toonloop.com/static/tmp/image_color_test_out.png >>>>> >>>> >>>>> >>>> If you want to download the code and the test image I use : >>>>> >>>> http://toonloop.com/static/tmp/bug_color_jpeg.tar.gz >>>>> >>>> I also convert the colorbars.jpg files to surface and back to a JPG >>>>> >>>> file for comparison. It works flawlessly. >>>>> >>>> >>>>> >>>> -- >>>>> >>>> Alexandre Quessy >>>>> >>>> http://alexandre.quessy.net/ >>>>> >>> >>>>> >>> >>>>> >> >>>>> > >>>>> >>>>> >>>>> >>>>> -- >>>>> Alexandre Quessy >>>>> http://alexandre.quessy.net/ >>>> >>>> >>> >>> >>> >>> -- >>> Alexandre Quessy >>> http://alexandre.quessy.net/ >>> >> > -- Alexandre Quessy http://alexandre.quessy.net/
