Pending release of 0.3

[SirVer]

> 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.
It infact does. Chris, could you please point me at this discussion?
It is most relevant for my work.

Cheers,
Holger

> 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 <sccolb... 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 <sccolb... 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 <ste... at sun.ac.za>:
>
> >>> 2009/11/5 Chris Colbert <sccolb... 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