Re: Pending release of 0.3

11 Nov 2009


      Hi,
...
I meant, do you have a QT call that is writing to a python variable?
I do not. I am unsure if QT is killing the thread (because it is a
child of the window) upon window close using the stop() function. This
could have been the reason to add the mutex in the first place.
If you feel bad about the mutex, just remove it and see how it goes. I
assume it is save and portable to use it as i did.

Cheers,
Holger
...
On Wed, Nov 11, 2009 at 10:41 AM, Chris Colbert <sccolb...@gmail.com> wrote:
...
right, but the gil ensures that only one piece of python code is
executing at a time.
...
Perhaps I missed it, did have a qt call that right to a python variable?
...
On Wed, Nov 11, 2009 at 10:39 AM, SirVer <sir...@gmx.de> wrote:
...
...
Hi Chris,
...
...
...
DId you find that you needed the mutex even with the GIL?
Yes I did. The GIL doesn't prevent deadlocks in all cases since we
have no guarantee
when python does a context switch. Shared variables (that can be
written in both threads) still
need protection by something. I am pretty sure it is needed at this
point.
...
...
Cheers
Holger
...
...
...
Chris
...
...
...
On Tue, Nov 10, 2009 at 9:48 PM, SirVer <sir...@gmx.de> wrote:
...
...
...
...
Chris,
...
...
...
...
I forget to point you to a working example in my pydc code. Sorry for
that:
...
...
...
...
http://bazaar.launchpad.net/%7Esirver/pydc1394/trunk/annotate/head%3A...
...
...
...
...
That's pretty much all knowledge I have about real time acquistion &
display with PyQt & PyOpenGL.
...
...
...
...
Cheers,
Holger
...
...
...
...
On 10 Nov., 12:08, Chris Colbert <sccolb...@gmail.com> wrote:
...
Holger,
...
...
...
...
...
#2 looks a lot like what I cooked up over here. (#1 always segaults
for me, but i could be doing it wrong.)
I tried the Qthread both with a while loop and a QTimer. I think i
like the timer better...
...
...
...
...
...
At least I know i'm heading in the right direction.
...
...
...
...
...
Cheers,
...
...
...
...
...
Chris!
...
...
...
...
...
On Tue, Nov 10, 2009 at 10:49 AM, SirVer <sir...@gmx.de> wrote:
...
...
...
...
...
> Hi Chris,
...
...
...
...
...
>> 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.
> This can't work as you said. PyOS_InputHook is never called. I doesn't
> work in ipython -q4thread either
> because the thread switch doesn't seem to occure. There are two ways
> to do it
> 1) either call PyOS_InputHook yourself.
> 2) acquire your images in another thread.
...
...
...
...
...
> I always use 2) since my image acquisition always takes place
> continously in the background. This is also a way were
> PyQT really shines (It also works with wxWidgets that way, but it
> hurts a bit).
...
...
...
...
...
> so your above example would look a bit like that (not tested, just
> written down like that):
...
...
...
...
...
> class WorkerThread(QThread):
>   def __init__(self, display):
>      self.connect(self, SIGNAL("newImage"), self.display.newImage)
>      # Keep a copy of display around so that the C object doesn't get
> deleted
>      self.display = display
...
...
...
...
...
>   def run(self):
>      while True:
>         img = grab_new_image()
>         self.emit(SIGNAL("newImage"), img)
...
...
...
...
...
> def acquire_images(display):
>   t = WorkerThread(display)
>   t.start()
...
...
...
...
...
> This example should work from the interactive shell provided you
> created a QApplication object so that Qt4 has the PyOS_InputHook
> acquired. Just call acquire_images(display).
...
...
...
...
...
> Cheers,
> Holger
...
...
...
...
...
>> Cheers,
...
...
...
...
...
>> Chris
...
...
...
...
...
>> On Fri, Nov 6, 2009 at 11:24 AM, SirVer <sir...@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...@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...
...
...
...
...
...
>> >> On Thu, Nov 5, 2009 at 5:14 PM, SirVer <sir...@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...@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...@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....
Erfahren Sie mehr »