Re: pygame error unable to reset window for OpenGL context

weakref WeakKeyDictionary machinery.

Re: weakref WeakKeyDictionary machinery.

And why are you asking us?  This is the pygame mailing list, last I
checked, and a quick search of the code suggests that pygame doesn't
use either Weak*Dictionary.

On 6/1/08, Gabriel Hasbun <gastomaster@...> wrote:
> Hello I searched the whole web for good examples on weakref module's
> WeakKeyDictionary, but have found none, All I find is the Python Docs
> explanations, and some examples which actually doesn't explain how the
> mechanism of key reference removal works:
>
> import weakref
> class Tracking:
>     _instances_dict = weakref.WeakValueDictionary(  )
>     _num_generated = 0
>     def _ _init_ _(self):
>         Tracking._num_generated += 1
>         Tracking._instances_dict[Tracking._num_generated] = self
>     def instances(  ): return _instances_dict.values(  )
>     instances = staticmethod(instances)
>
>
>
>

PyDay #2

Re: BUG: pygame.image.save(screen) with pyopengl 3.x Re: PyOpenGL Screenshots

hi,

I fixed this on the weekend.  I stopped using pyopengl to get
glReadPixels (since pyopengl 3.x broke the glReadPixels API), and
instead loaded the gl functions dynamically with C.

Committed revision 1261.

You can get auto-built binaries for windows/mac osx here if needed:
http://thorbrian.com/pygame/builds.php

cheers,

On Wed, May 7, 2008 at 2:47 PM, René Dudfield <renesd@...> wrote:
> Added a bug to the subject.
>
> cu,
>
> On Wed, May 7, 2008 at 2:44 PM, René Dudfield <renesd@...> wrote:
>> looks like pyopengl 3.x returns a numpy array now instead of a string
>>  by default... which breaks pygame.image.save on gl with pyopengl 3.x.
>>
>>  Here's a work around screenshot function for gl.
>>
>>
>>  def save_screen(screen, filename):
>>
>>     def readScreen(x, y, width, height):
>>         """ Read in the screen information in the area specified """
>>         glFinish()
>>         glPixelStorei(GL_PACK_ALIGNMENT, 4)
>>         glPixelStorei(GL_PACK_ROW_LENGTH, 0)
>>         glPixelStorei(GL_PACK_SKIP_ROWS, 0)
>>         glPixelStorei(GL_PACK_SKIP_PIXELS, 0)
>>
>>         data = glReadPixels(x, y, width, height, GL_RGB, GL_UNSIGNED_BYTE)
>>         if hasattr(data, "tostring"):
>>             data = data.tostring()
>>
>>         return data
>>     def saveImageData(width, height, data, filename):
>>         """ Save image data """
>>         surface = pygame.image.fromstring(data, (width, height), 'RGB', 1)
>>         pygame.image.save(surface, filename)
>>
>>     data = readScreen(0,0, screen.get_width(), screen.get_height())
>>     saveImageData(screen.get_width(), screen.get_height(), data, filename)
>>
>>
>>
>>
>>
>>  On Wed, May 7, 2008 at 2:27 PM, René Dudfield <renesd@...> wrote:
>>  > hi,
>>  >
>>  >  glReadPixels, make a surface, then use pygame.image.save()
>>  >
>>  >  Then use ffmpeg, or vlc etc to make a movie out of still frames.
>>  >
>>  >  cheers,
>>  >
>>
>

RE: BUG: pygame.image.save(screen) with pyopengl 3.x Re: PyOpenGL Screenshots

Hi,

pygame.image.save() of gl Surfaces is still a problem on windows, causing
segfaults.

I commited a test called image__save_gl_surface_test.py 

cheers.

-----Original Message-----
From: owner-pygame-users@...
[mailto:owner-pygame-users@...] On
Behalf Of René Dudfield
Sent: Monday, June 02, 2008 12:35 PM
To: pygame-users@...
Subject: Re: BUG: pygame.image.save(screen) with pyopengl 3.x Re: [pygame]
PyOpenGL Screenshots

hi,

I fixed this on the weekend.  I stopped using pyopengl to get
glReadPixels (since pyopengl 3.x broke the glReadPixels API), and
instead loaded the gl functions dynamically with C.

Committed revision 1261.

You can get auto-built binaries for windows/mac osx here if needed:
http://thorbrian.com/pygame/builds.php

cheers,

On Wed, May 7, 2008 at 2:47 PM, René Dudfield <renesd@...> wrote:
> Added a bug to the subject.
>
> cu,
>
> On Wed, May 7, 2008 at 2:44 PM, René Dudfield <renesd@...> wrote:
>> looks like pyopengl 3.x returns a numpy array now instead of a string
>>  by default... which breaks pygame.image.save on gl with pyopengl 3.x.
>>
>>  Here's a work around screenshot function for gl.
>>
>>
>>  def save_screen(screen, filename):
>>
>>     def readScreen(x, y, width, height):
>>         """ Read in the screen information in the area specified """
>>         glFinish()
>>         glPixelStorei(GL_PACK_ALIGNMENT, 4)
>>         glPixelStorei(GL_PACK_ROW_LENGTH, 0)
>>         glPixelStorei(GL_PACK_SKIP_ROWS, 0)
>>         glPixelStorei(GL_PACK_SKIP_PIXELS, 0)
>>
>>         data = glReadPixels(x, y, width, height, GL_RGB,
GL_UNSIGNED_BYTE)
>>         if hasattr(data, "tostring"):
>>             data = data.tostring()
>>
>>         return data
>>     def saveImageData(width, height, data, filename):
>>         """ Save image data """
>>         surface = pygame.image.fromstring(data, (width, height), 'RGB',
1)
>>         pygame.image.save(surface, filename)
>>
>>     data = readScreen(0,0, screen.get_width(), screen.get_height())
>>     saveImageData(screen.get_width(), screen.get_height(), data,
filename)
>>
>>
>>
>>
>>
>>  On Wed, May 7, 2008 at 2:27 PM, René Dudfield <renesd@...> wrote:
>>  > hi,
>>  >
>>  >  glReadPixels, make a surface, then use pygame.image.save()
>>  >
>>  >  Then use ffmpeg, or vlc etc to make a movie out of still frames.
>>  >
>>  >  cheers,
>>  >
>>
>

[Bug] SVN 1272 on Windows

Pygame is segfaulting on Windows. Importing Pygame fails:

Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit 
(Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
 >>> import pygame
Fatal Python error: (pygame parachute) Segmentation Fault

Not very useful. When a Pygame application is run without a console the 
dialog box locates the fault in python.exe. Again not much help. I can 
only limit the problem to one of pixelarray.c, transform.c, image.c, 
draw.c, time.c, surface.c, font.c and imageext.c. These were all changed 
since the last working version of Pygame I compiled.

--

-- 
Lenard Lindstrom
<len-l@...>

Re: [Bug] SVN 1272 on Windows

hi,

have you included the new color.c in your Setup ?

On Tue, Jun 3, 2008 at 2:48 AM, Lenard Lindstrom <len-l@...> wrote:
> Pygame is segfaulting on Windows. Importing Pygame fails:
>
> Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)]
> on
> win32
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import pygame
> Fatal Python error: (pygame parachute) Segmentation Fault
>
>
> Not very useful. When a Pygame application is run without a console the
> dialog box locates the fault in python.exe. Again not much help. I can only
> limit the problem to one of pixelarray.c, transform.c, image.c, draw.c,
> time.c, surface.c, font.c and imageext.c. These were all changed since the
> last working version of Pygame I compiled.
>
> --
> Lenard Lindstrom
> <len-l@...>
>
>

Re: Proposed Module: Camera

Hello,
I haven't had internet access for a few days, so I didn't get this
message before I started coding.  Luckily, I ended up doing a lot of
the things you suggested.

I have written the camera as an object created with
camera.Camera(device, (width, height)), and with .start() which opens
and starts it, .get_image() which returns a Surface, and .close()
which stops and closes it.

Currently, I just have get_image blocking, though it is a simple
change to make it non blocking.  MMAP by nature uses buffers.  When
using it non blocking, the camera driver would return EAGAIN if there
is no buffer available yet.  I could just make it return the last
frame again on EAGAIN, though I'm not sure that is the best way.

For querying, I'm not sure what would be useful beyond knowing what
resolutions were supported, and as far as I know v4l2 drivers don't
really let you know that beyond a suggested resolution.  Right now,
the width, height you create the camera with is not necessarily the
width, height of the Surfaces being returned.

The code I'm working on is at http://git.n0r.org/?p=pygame-nrp;a=summary

As of the latest snapshot, it currently supports YUYV and RGB24
(though that is untested) cameras.  I've tested it so far with vivi
and the webcam in the OLPC XO.

Nirav

On Fri, May 30, 2008 at 3:06 PM, René Dudfield <renesd@...> wrote:
> hi,
>
> a few notes...
>
>> The basic plan is to use V4L2_MEMORY_MMAP, mmap() the image buffer,
>> and convert the image to RGB24 (if it isn't already) as a Surface.
>
> I like that idea.
>
>
> *- it needs multiple camera support.
>
> So make it create a camera object.
>
> For example:
> a_camera = camera.Camera(device, width, height)
>
> a_camera.get_image()
>
> *- you could try implementing your api with the opencv python wrapper.
> This way you could start adding tests early on.
>
>
> *- since many cameras are low frame rate, it would be nice if there
> were events emitted for things like FRAME_AVAILABLE.
>
> eg.  if a camera is 10fps then it'd be good if the get image call
> didn't block - so then the rest of the program can run faster.
>
> This could require buffering of frames.  Perhaps in a separate thread.
> Or maybe there could be a blocking call, and the rest is left up to the user.
>
> What do you think is a good way to handle blocking?
>
> Also I think some cameras require you to get the image data at a
> certain frequency... otherwise an internal buffer overflows or
> something.  This has been my experience with opencv anyway.
>
>
> *- Some way to query camera capabilities?
>
>
>
>
>
> On Tue, May 27, 2008 at 3:22 PM, Nirav Patel <olpc@...> wrote:
>> Hello all,
>>
>> I'd like to propose a pygame module to enable camera support.
>> Specifically, v4l2 support with the eventual possibility of v4l and
>> vfw.  I realise having only v4l2 to start with limits it to linux, but
>> its a start.  It will consist of the following functions.
>>
>> camera.open(device, width, height)
>> camera.start()
>> camera.getimage() returns Surface
>> camera.stop()
>> camera.close()
>>
>> The parameters for open are intentionally simple.  Similar to
>> libraries like OpenCV, it will negotiate with the v4l2 drivers to pick
>> an acceptable pixel format.  At least to start with, the supported
>> pixel formats would be the most common ones like RGB3 (RGB24), R444
>> (RGB444), YUYV, and others that people want.
>>
>> The basic plan is to use V4L2_MEMORY_MMAP, mmap() the image buffer,
>> and convert the image to RGB24 (if it isn't already) as a Surface.
>>
>> Nirav Patel
>>
>

Re: Proposed Module: Camera

Nice one :)

I'll try it out, and read your code when I get home... and hopefully
give you some feedback.

Have started on any unittests?

cu,

On Tue, Jun 3, 2008 at 10:27 AM, Nirav Patel <olpc@...> wrote:
> Hello,
> I haven't had internet access for a few days, so I didn't get this
> message before I started coding.  Luckily, I ended up doing a lot of
> the things you suggested.
>
> I have written the camera as an object created with
> camera.Camera(device, (width, height)), and with .start() which opens
> and starts it, .get_image() which returns a Surface, and .close()
> which stops and closes it.
>
> Currently, I just have get_image blocking, though it is a simple
> change to make it non blocking.  MMAP by nature uses buffers.  When
> using it non blocking, the camera driver would return EAGAIN if there
> is no buffer available yet.  I could just make it return the last
> frame again on EAGAIN, though I'm not sure that is the best way.
>
> For querying, I'm not sure what would be useful beyond knowing what
> resolutions were supported, and as far as I know v4l2 drivers don't
> really let you know that beyond a suggested resolution.  Right now,
> the width, height you create the camera with is not necessarily the
> width, height of the Surfaces being returned.
>
> The code I'm working on is at http://git.n0r.org/?p=pygame-nrp;a=summary
>
> As of the latest snapshot, it currently supports YUYV and RGB24
> (though that is untested) cameras.  I've tested it so far with vivi
> and the webcam in the OLPC XO.
>
> Nirav
>
> On Fri, May 30, 2008 at 3:06 PM, René Dudfield <renesd@...> wrote:
>> hi,
>>
>> a few notes...
>>
>>> The basic plan is to use V4L2_MEMORY_MMAP, mmap() the image buffer,
>>> and convert the image to RGB24 (if it isn't already) as a Surface.
>>
>> I like that idea.
>>
>>
>> *- it needs multiple camera support.
>>
>> So make it create a camera object.
>>
>> For example:
>> a_camera = camera.Camera(device, width, height)
>>
>> a_camera.get_image()
>>
>> *- you could try implementing your api with the opencv python wrapper.
>> This way you could start adding tests early on.
>>
>>
>> *- since many cameras are low frame rate, it would be nice if there
>> were events emitted for things like FRAME_AVAILABLE.
>>
>> eg.  if a camera is 10fps then it'd be good if the get image call
>> didn't block - so then the rest of the program can run faster.
>>
>> This could require buffering of frames.  Perhaps in a separate thread.
>> Or maybe there could be a blocking call, and the rest is left up to the user.
>>
>> What do you think is a good way to handle blocking?
>>
>> Also I think some cameras require you to get the image data at a
>> certain frequency... otherwise an internal buffer overflows or
>> something.  This has been my experience with opencv anyway.
>>
>>
>> *- Some way to query camera capabilities?
>>
>>
>>
>>
>>
>> On Tue, May 27, 2008 at 3:22 PM, Nirav Patel <olpc@...> wrote:
>>> Hello all,
>>>
>>> I'd like to propose a pygame module to enable camera support.
>>> Specifically, v4l2 support with the eventual possibility of v4l and
>>> vfw.  I realise having only v4l2 to start with limits it to linux, but
>>> its a start.  It will consist of the following functions.
>>>
>>> camera.open(device, width, height)
>>> camera.start()
>>> camera.getimage() returns Surface
>>> camera.stop()
>>> camera.close()
>>>
>>> The parameters for open are intentionally simple.  Similar to
>>> libraries like OpenCV, it will negotiate with the v4l2 drivers to pick
>>> an acceptable pixel format.  At least to start with, the supported
>>> pixel formats would be the most common ones like RGB3 (RGB24), R444
>>> (RGB444), YUYV, and others that people want.
>>>
>>> The basic plan is to use V4L2_MEMORY_MMAP, mmap() the image buffer,
>>> and convert the image to RGB24 (if it isn't already) as a Surface.
>>>
>>> Nirav Patel
>>>
>>
>