Mailman 3 November 2009 - scikit-image

Re: Trace path
by Zachary Pincus 22 Nov '09

22 Nov '09

> Assuming it's not easy to cast the input array to the float32 type, > because I'm guessing it will be called with int arrays if not > explicitly stated, can I suggest changing the documentation like: > > costs : (M, N) ndarray of float32 This limitation might just be due to my relative inexperience with cython... Would it be better to have two identical functions, one which takes int costs and one with float costs (and then maybe a python wrapper function that selects between the two), or to write it so that it casts to float internally? For that matter, is there a "safe cast" function that would, say, upcast ints to float32, but would complain about trying to cast float64s to float32? Or just better to document and let the user deal with the constraint? > Also, can I suggest a returns section like this: > > Returns > ------- > tuple : (costs, paths) > ``costs`` is an (M, N) ndarray of float32 of cumulative > costs from the starting point > ``paths`` is a list of paths where each path is a list > of ``(x, y)`` positions ordered from the start to each > end point Thanks for helping get this in shape, Gary and Stéfan! Zach

2 1

Re: Trace path
by Stéfan van der Walt 22 Nov '09

22 Nov '09

Hey Gary 2009/11/22 Gary Ruben <gary.ruben(a)gmail.com>: > Assuming it's not easy to cast the input array to the float32 type, > because I'm guessing it will be called with int arrays if not > explicitly stated, can I suggest changing the documentation like: Sure, would you provide a patch, then I'll pull it from your github branch. Thanks Stéfan

1 0

Trace path
by Stéfan van der Walt 22 Nov '09

22 Nov '09

Hi all, Zachary posted code on scipy-dev to trace a shortest path through an image, given specified start and end points. With the shortest path algorithm already in scikits.image.graph, it would be possible to fix either the start or the end points, but not both. Zach's algorithm uses an iterative approach to achieve this goal. I'd be glad for any review comments. The code is here: http://github.com/stefanv/scikits.image/tree/master/scikits/image/graph Cheers Stéfan

2 1

Morphological operators merged
by Stéfan van der Walt 20 Nov '09

20 Nov '09

Hi all, I merged Damian's morphology branch, which is now available as scikits.image.morphology. The code is here: http://github.com/stefanv/scikits.image/tree/master/scikits/image/morpholog… Regards Stéfan

1 0

ANN: scikits.image v0.2
by Stéfan van der Walt 15 Nov '09

15 Nov '09

I'm glad to announce the second release of `scikits.image`, a collection of image processing routines for SciPy. On top of bug-fixes and improved documentation, the following changes/additions were made: - A new IO plugin infrastructure so that commands like 'imshow' are available via multiple backends (PIL, matplotlib, QT4, etc.) - ImageCollections (for cached loading of multiple images) and MultiImage (for working with multi-layered images) - More complete OpenCV wrappers - A graphical image viewer (also installed as a script `scivi`), that allows colour adjustments - Shortest path algorithm For version 0.3, we aim to - Incorporate some of the code offered by the Broad institute - Implement acquisition (grabbing images from cameras) and intrinsic camera calibration - Add real time video and camera display with processing - Improve filtering code - Add morphological operations More information is available at: http://stefanv.github.com/scikits.image/ Regards Stéfan

3 10

some new updates
by Chris Colbert 11 Nov '09

11 Nov '09

Hey Everyone, I've pushed some changes to my master branch on github which yields a 30x speed improvement for the colormixer on large images. I did it by implementing a LUT for the conversion operations (something I should have done from the beginning). Thanks to Guy Kloss for giving me the idea! If you have time, please check it out and give it a reaming. I'm still looking for an efficient way to make a LUT for HSV manipulations, any ideas are welcome! Cheers! Chris

1 0

Re: Pending release of 0.3
by Chris Colbert 11 Nov '09

11 Nov '09

Holger, DId you find that you needed the mutex even with the GIL? Chris On Tue, Nov 10, 2009 at 9:48 PM, SirVer <sirver(a)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/pydc1… > > 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...(a)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...(a)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...(a)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...(a)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...(a)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...(a)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...(a)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...(a)sun.ac.za>: >> >> >> >> >> >>> 2009/11/5 Chris Colbert <sccolb...(a)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

2 4

Re: Pending release of 0.3
by Chris Colbert 10 Nov '09

10 Nov '09

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 <sirver(a)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...(a)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...(a)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...(a)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...(a)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...(a)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...(a)sun.ac.za>: >> >> >> >> >>> 2009/11/5 Chris Colbert <sccolb...(a)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 >

2 1

Re: Pending release of 0.3
by Chris Colbert 10 Nov '09

10 Nov '09

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(a)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...(a)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://mai… >> >> >> >> On Thu, Nov 5, 2009 at 5:14 PM, SirVer <sir...(a)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...(a)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...(a)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...(a)sun.ac.za>: >> >> >> >>> 2009/11/5 Chris Colbert <sccolb...(a)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

2 1

Re: Pending release of 0.3
by Stéfan van der Walt 10 Nov '09

10 Nov '09

Hi Holger I'd suggest that we create a new sub-module for the purpose of acquisition, and propagate it with all the necessary tools. The gui can be a stand-alone script outside the library (we may install it with the library as an executable, but it won't be importable under, say, scikits.image.gui). By separating the script from the library, we also stand a better chance of developing an easily re-usable API in the library itself. In the back of my head, this is where I thought the plugin framework could slot in handy (this is just a suggestion): Re-usable components from the GUI may be factored into a plugin, so that others may also make use of them. For example, the 'opengl' plugin may provide 'imshow', that is based on your ImageDisplayWin. Here follows a fictional code snippet: User: import scikits.image.io as io io.use_plugin('opengl') ic = io.ImageCollection([img1, img2]) io.imshow(ic) # imshow based on StillImageDisplay Gui script: import scikits.image.io.plugins.opengl as opengl ld = opengl.LiveImageDisplay() ld.do_stuff() etc. The aim is to maximise code re-use and to break up code into units that can be tested more easily. We're all still getting to know the lay of the land here, but as soon as we start coding, I'm sure the use cases will become more clear. Regards Stéfan

2 1