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