Pending release of 0.3

[Chris Colbert]

Holger,

There is nothing stopping you from making a pyopengl plugin. Or even
modifying your current gui to fit within the plugin framework.

However, i'm afraid that your current gui may rely on ipython
-q4thread, which is now deprecated (big mailing list discussion on
this). So that may throw a wrench in the video portion of it, unless
we can figure out this pyos_input hook thing.

But as my previous example shows, its definately possible to fit it
within the plugin framework.

Cheers!

Chris

On Thu, Nov 5, 2009 at 4:56 PM, Chris Colbert <sccolbert at gmail.com> wrote:
> So while i havent yet been able to get the pyos_inputhook thing sorted
> out, I did time a couple loops.
>
> For a decent sized image, we can easily get 60fps update rates, and
> thats including the time for the numpy operations:
>
> In [5]: img = io.imread('/home/brucewayne/Pictures/failboat_4.jpg')
>
> In [6]: img.shape
> Out[6]: (503, 790, 3)
>
> In [7]: win = io.imshow(img, updateable=True)
>
> In [8]: def test(img, win):
>   ...:     for i in range(30):
>   ...:         img[:] += 1
>   ...:         win.update()
>   ...:
>   ...:
>
> In [9]: %timeit test(img, win)
> 1 loops, best of 3: 564 ms per loop
>
>
> one thing to note, I bypassed the prepare_for_display() method that we
> usually call to make sure an array is contiguous, of the right dtype,
> etc...
> I assume if someone wants video, they can prepare the arrays themselves.
>
> This behavior can also be changed by the plugin writer. For this
> example, i simply took the easy route and subclassed ImageWindow
>
> Cheers,
>
> Chris
>
>
> On Thu, Nov 5, 2009 at 4:24 PM, Chris Colbert <sccolbert at gmail.com> wrote:
>> I was just testing out something along these lines, but I run into the
>> problem of the the python interpreter not considering time.sleep() as
>> idle time, thus, it never calls PyOS_InputHook inside of for-loops. So
>> i'm not quite sure how to get video  feed to run interactively without
>> hacking out something like ipython -whatever thread.
>>
>> Mind you, this is not a problem with the plugin architecture, its a
>> problem with the python interpreter...
>>
>> but maybe i can ctypes into the os_hook and call it at the end of a
>> loop.... <evil grin>
>>
>> 2009/11/5 Stéfan van der Walt <stefan at sun.ac.za>:
>>>
>>> 2009/11/5 Chris Colbert <sccolbert at gmail.com>:
>>>> Further, these imshow() type widgets are primarily meant to be used
>>>> from the interactive interpreter, an environment not best suited for
>>>> real time image acquisition and display. that said, the plugin
>>>> archiceture can most certainly be used in the method you speak of. You
>>>> just simply have your imshow() function return the window object, and
>>>> implement an update() or similar method that the consumer can call to
>>>> update the image.
>>>
>>> This could even be accomplished using 'imshow' only.  The
>>> WindowManager keeps track of the single window produced, and 'imshow'
>>> simply grabs that window and updates its current content.  I'd be
>>> surprised if we couldn't pump out a large number of frames-per-second
>>> that way.
>>>
>>> Stéfan
>>>
>>
>