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/
