[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [pygame] BUG: JPEG colors saving a pygame.camera surface
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 <olpc@xxxxxxxxxxxxxx>:
> 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 <olpc@xxxxxxxxxxxxxx> 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 <alexandre@xxxxxxxxxx> 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 <renesd@xxxxxxxxx>:
>>>> 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 <alexandre@xxxxxxxxxx>
>>>> 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 <olpc@xxxxxxxxxxxxxx>:
>>>>> > 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 <olpc@xxxxxxxxxxxxxx>
>>>>> > 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 <renesd@xxxxxxxxx>
>>>>> >> 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
>>>>> >>> <alexandre@xxxxxxxxxx>
>>>>> >>> 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/