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/ >
