Pending release of 0.3

[Chris Colbert]

Here's a couple links on it Holger.

Hopefully the scipy links work for you (its the Ipython part of the
discussion). I cant get to them right now.

http://mail.scipy.org/pipermail/ipython-dev/2009-July/005256.html
http://mail.scipy.org/pipermail/ipython-dev/2009-February/004905.html
http://mail.python.org/pipermail/python-dev/2005-November/057954.html

On Thu, Nov 5, 2009 at 5:14 PM, SirVer <sirver at gmx.de> wrote:
>
>> 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