Pending release of 0.3

[Chris Colbert]

Hey Holger,


Are you able to feed your display widget with images from within a
python loop in the interactive shell?

ie:

while True:
    img = grab_new_image()
    display.new_image(img)


The issue I am having with this PyOS_InputHook, is that for me, that
type of loop never lets the interpreter idle (even with a sleep()
call) and thus the PyOS_InputHook never gets called, and the gui never
updates.

How do you feed images to your widget?

Cheers,

Chris
On Fri, Nov 6, 2009 at 11:24 AM, SirVer <sirver at gmx.de> wrote:
>
> Hi Chris,
>
> thanks for the links! It made for some interesting reading; i wasn't
> aware of the System Hook. But I just investigated and my Widget works
> just fine in a pure python session as long as a QApplication object
> has been created before. So there is no problem here, it will work
> fine now in ipython -qt4thread and will continue to work in future
> ipython and also in vanilla python as long as QApplication(sys.argv)
> has been called before the window is created (which is mandatory for
> all QT4 Applications). So no problem here.
>
> I now try to come to a conclusion to this thread. I didn't mean to
> start a lengthy discussion of how things should be done differently, I
> only want to have direction how to implement this. I try to summarize
> my thoughts:
>
> * I am often in need to display images from a camera and annotate them
> with some output from algorithms (for example mark detected balls in
> my ping pong roboters images in red). For this I've written the code
> that can be found in my gui branch.
> * I feel that this use case is quite different from the idea of the
> imshow() plugin. I also feel that more people than me could profit
> from this functionality as I use it ATM.
> * I feel that this is hard to pull off with a plugin like
> architecture, because the annotation part will be different for all
> backends and all individual uses. En plus, this is more a Library kind
> of functionality, not a enduser kind like imshow().
> * My solution works for me and uses PyQt and PyOpenGL. My experiments
> showed me that this is the only combination that offers the drawing
> speed I want. I understand that other approaches could be possible or
> feasible, but I also think that for use cases like mine, this is a
> very common approach; especially since annotating in OpenGL is so easy
> to do with PyQt4.
> * Please let me state again that I do not plan to corrupt or change
> the imshow() plugin architecture which I really like. I am just of the
> opinion that something else is needed for my use case.
>
> Now, please note that these are my opinions and thought and not really
> subject to discussion. What I now really need is a design decision by
> the architect of scikit.image; which I assume to be you, stefan:
>
> How should I contribute this code? In which module should it go or is
> this not a direction that scikit.image should evolve in (I'd
> understand that and instead bring this code into my pydc1394 library
> were it would also fit).
>
> Cheers,
> Holger
>
>
>
> On 5 Nov., 17:33, Chris Colbert <sccolb... at gmail.com> wrote:
>> 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.htmlhttp://mail.scipy.org/pipermail/ipython-dev/2009-February/004905.htmlhttp://mail.python.org/pipermail/python-dev/2005-November/057954.html
>>
>>
>>
>> On Thu, Nov 5, 2009 at 5:14 PM, SirVer <sir... 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