Hi Zach, This is more-or-less what I designed pygarrayimage and wxglvideo for, and it uses Pyglet to display the live image data as textures. That was (and I guess still is) the fastest way to get image data to the video card.
Anyhow, the core pyglet/numpy array bridge is pygarrayimage, which I'd be happy if this eventually ended up in pyglet: http://code.astraw.com/projects/motmot/wiki/pygarrayimage One feature that I think would be nice to add to the wxglvideo would be some controls such as brightness and gain on the video display. This could be achieved using pixel shaders so that the GPU did all the work. -Andrew Zachrahan wrote: > Hello all, > > Thanks for the help with setting up pyglet windows in background > threads. The next step to my microscope-control workspace is to pull > images from the camera and put them onscreen as fast as possible, > using as little processor as possible (the proc will be in use for > other things, like auto-focus, etc.) > > Here are the basics of the system: > - Camera produces down 16-bit grey-scale images, of arbitrary size > (from 128x128 to 1300x1030). > - I'll probably convert the pixels to 8-bit using some brightness/ > contrast/gamma function via numpy. (Or would doing this in OpenGL be > possible/better?) > - I'll need to draw the image in a window, using an arbitrary zoom > factor (with 1:1 giving camera pixels = display pixels) and an > arbitrary window size. > - Some times, the camera will be giving 30+ FPS (with small images), > at other times, the camera will be off, and the only image updates > needed will be when the window needs a redraw (or the user zooms in). > > Obviously, I'd like to handle the zooming on the video card, and > anything else I can. I assume that the fastest way to go is to upload > the pixels as a texture of Luminance-type pixels, and then use texture- > mapping to go from the image pixels to screen pixels with the required > zoom and viewport onto the image. > > However, I could alternately use glDrawPixels and glPixelZoom to > handle this, and deal with choosing the right image region to show > elsewhere. Or, I could use the pyglet sprite class to handle > translation and zooming. > > Any suggestions here? > > Also, given that much of the time, there will be no new image input, > is there a way to not re-draw the window unless it needs it? (E.g. > part of the window has been occluded and needs a redraw?) Since > windows are double-buffered on OS X, and will likely be foreground > anyway, it seems a bit wasteful to blit new pixels to the screen every > cycle if nothing's changed on the display... Though perhaps that's not > the case. > > > Thanks again for everyone's help and suggestions, > > Zach > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en -~----------~----~----~----~------~----~------~--~---
