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

Ready to tag 0.2: please give it a whirl
by Stéfan van der Walt 09 Nov '09

09 Nov '09

Hi all, After merging the 'io' branch, I am ready to tag 0.2 after some more testing (I accidentally called it 0.3 before). Would you please check out the master branch from http://github.com/stefanv/scikits.image and give it a good thrashing before we release? I've also updated the docs on github in preparation: http://stefanv.github.com/scikits.image - Chris, your io and threaded refactor have been merged. - Tony, your docs changes have been merged. - Ralf, your coverage changes have been merged. I'd love to merge the filter improvements too, if you're almost done with those. I added a skeleton for the User Guide (http://stefanv.github.com/scikits.image/user_guide.html). I think an introductory chapter to image processing with examples should be high on the agenda for the next round of development. Thanks! Stéfan

2 1

Aspect Ratio for the fancy imshow, need your opinions!
by Chris Colbert 07 Nov '09

07 Nov '09

Currently, the simple imshow(), just shows the image at its native size with no resizing possible. In the QT plugin version imshow(img, fancy=True), allows the image to be resized with the window to any aspect ratio. What is the preference of everyone here? Would you rather I leave it so it can be resized to any ratio (with the possibility of it not being the correct aspect ratio on launch, if it is very small, or very large). Or would you prefer that the aspect ratio be kept constant? Cheers, Chris

2 3

Fancy imshow and colormixer refactor complete + more functionality
by Chris Colbert 06 Nov '09

06 Nov '09

Hey Everyone, I think i've fixed all the problems I mentioned last night concerning the circular references, etc... In the process, I managed to speed up the widget quite a bit by getting rid of unnecessary fluff. I've also added gamma correction and sigmoidal gamma correction to the color mixer and the imshow widget. So if you all would be so kind, please grab it from my IO branch and give it a thrashing, and let me know if anything breaks. I'm gonna get working on fixing the aspect ratio, and usings holgers suggestion of being able to hide widgets... Cheers! Chris

1 0

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

06 Nov '09

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(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

Histograms added to Fancy Imshow and ColorMixer
by Chris Colbert 06 Nov '09

06 Nov '09

Hey All, I've added preliminary Histogramming to the fancy imshow QT widget. In the process I added a fast Naive histogrammer to the ColorMixer for use in this widget. Unfortunately, I'm now suffering from circular references during window instantiation. I'm gonna need to refactor the code a bit because QT likes to fire off event before with main window has finished intializing. Everything still works, it just throws a few exceptions while the window is intializing. At any rate, you can, you can check out the code from my IO branch on git. And here is a screenshot to wet your appetite: http://therealstevencolbert.com/dump/histograms.png Cheers! Chris

3 2

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

05 Nov '09

On Thu, Nov 5, 2009 at 3:44 PM, SirVer <sirver(a)gmx.de> wrote: > > > > On 5 Nov., 15:27, Chris Colbert <sccolb...(a)gmail.com> wrote: >> On Thu, Nov 5, 2009 at 3:16 PM, SirVer <sir...(a)gmx.de> wrote: >> >> > Hi, >> >> > On 4 Nov., 15:04, Stéfan van der Walt <ste...(a)sun.ac.za> wrote: >> >> 2009/11/4 SirVer <sir...(a)gmx.de>: >> >> >> > Stefan, concerning my GUI branch: >> >> > I played around with pyqt and QImages and they just couldn't deliver >> >> > what I needed: Speed. >> >> >> I'd like to see some benchmarks that support this, because it should >> >> be the cost of 2 python calls + whatever time the GUI uses. QImage is >> >> fast when loading directly from a numpy array. I'm not sure, with the >> >> copying that you have to do into a texture, that OpenGL can do any >> >> better. >> > I did some benchmarks, but unfortunately I do not have the code >> > around. I created QImages and painted them directly in PyQt. It was >> > reasonable fast, but I couldn't reach the performance I have with a >> > QGLWidget which delivers easily 300fps or 60fps in 12 different >> > windows. I'd rather not hack this again since this issue is somewhat >> > settled for me and I'd prefer spending my coding time on other itches >> > I have. >> >> > I still think that PyQt is a much bigger dependency then PyOpenGL - >> > and even so: both are optional and only needed when GUI stuff in real >> > time should be performed. >> >> I think you're not really grasping the idea of "plugin" > Well, I understood the principle of plugin quite well; BUT the plugin > architecture does not allow real time display of images right now. It > won't be possible to implement it that way. > AND there are users who will need this and might need it in image > processing tasks. The question here is just if and if yes how to > implement this. I meant that you make the claim that QT is a heavy dependency, when in fact its not a dependency at all unless the individual wants to use the qt plugins. The scikit, and all it's image process, still function without having QT installed. 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. > > If my code and my attempts are not to be included in scikit.image, so > be it. I will continue to use it anyway; i just think they are useful > and WANT to contribute them to the public. > >> >> >> >> > Cheers, >> > Holger >> >> >> Regards >> >> Stéfan

3 6

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

05 Nov '09

Hi Holger 2009/11/5 SirVer <sirver(a)gmx.de>: > I still think that PyQt is a much bigger dependency then PyOpenGL - > and even so: both are optional and only needed when GUI stuff in real > time should be performed. I see the PyOpenGL wrappers nowadays use ctypes, so they can be installed without compiling anything (good!). The reason I suggested Pyglet is because it gives you a higher-level abstraction on things such as textures and windows, and allows you to skirt the PyQt dependency, if you'd want to. As for the implementation of a realtime display, I'd be glad to work with you to remove any hinderances that prevent the use of the plugin framework. If it is a fundamental limitation, I'd be glad if we could discuss that to get a better idea of your needs. Regards Stéfan

2 1

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

05 Nov '09

On Thu, Nov 5, 2009 at 3:16 PM, SirVer <sirver(a)gmx.de> wrote: > > Hi, > > > On 4 Nov., 15:04, Stéfan van der Walt <ste...(a)sun.ac.za> wrote: >> 2009/11/4 SirVer <sir...(a)gmx.de>: >> >> > Stefan, concerning my GUI branch: >> > I played around with pyqt and QImages and they just couldn't deliver >> > what I needed: Speed. >> >> I'd like to see some benchmarks that support this, because it should >> be the cost of 2 python calls + whatever time the GUI uses. QImage is >> fast when loading directly from a numpy array. I'm not sure, with the >> copying that you have to do into a texture, that OpenGL can do any >> better. > I did some benchmarks, but unfortunately I do not have the code > around. I created QImages and painted them directly in PyQt. It was > reasonable fast, but I couldn't reach the performance I have with a > QGLWidget which delivers easily 300fps or 60fps in 12 different > windows. I'd rather not hack this again since this issue is somewhat > settled for me and I'd prefer spending my coding time on other itches > I have. > > I still think that PyQt is a much bigger dependency then PyOpenGL - > and even so: both are optional and only needed when GUI stuff in real > time should be performed. I think you're not really grasping the idea of "plugin" > Cheers, > Holger > > >> >> Regards >> Stéfan

2 1

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

05 Nov '09

2009/11/4 SirVer <sirver(a)gmx.de>: > Stefan, concerning my GUI branch: > I played around with pyqt and QImages and they just couldn't deliver > what I needed: Speed. I'd like to see some benchmarks that support this, because it should be the cost of 2 python calls + whatever time the GUI uses. QImage is fast when loading directly from a numpy array. I'm not sure, with the copying that you have to do into a texture, that OpenGL can do any better. Regards Stéfan

2 1

Re: OpenCV 2 or 1
by Chris Colbert 05 Nov '09

05 Nov '09

Im all for a big glaring "OpenCV >= 2.0 required if you want to use opencv extensions" On Wed, Nov 4, 2009 at 1:57 PM, SirVer <sirver(a)gmx.de> wrote: > > A __version__ function in the future is little help to distinguish > between OCV 1 and OCV 2. BUT the current case is not bearable; for > example the test suite can not be run when you have OpenCV 1 > installed, because OpenCV errors always result in a coredump because > of their braindumped I-do-my-own-Exceptions-In-C-Which-Are-Uncatchable > Stuff. That is, as soon as the opencv tests run, the whole python > process is KILLED by opencv throwing an exception because I expects an > array of 1x5 instead of 1x4. (Note that the same is true if we do > stuff vice-versa: making version 1 a dependency and the user has 2 > installed). > > The only REAL solutions I see for this mess is to either > a) decide which version to build against at build time using IFDEFs. > Which is ugly and not easy to pull off and makes OpenCV a hard build > time dependency. On plus we would have to ship binary versions linked > against OCV1 and OCV2. Ugly code, Ugly distribution, hard to > implement. > b) Determine at run time if the user has OpenCV 1 installed and ABORT > then in a pythonic fashion. I know of no portable way to pull this > off; one could only check for relative positions of functions in the > binaries or so. Nice code, nice distribution, very hard to implement. > c) Rip the parts that we need from the OpenCV source code (if > licensing allows that) and build our own subset of the functionality > into scikit.image. No dependency on the OpenCV anymore, no cranky > void* pointer passing around, no strange exceptions that are > uncatchable. Heaven on earth. Downside: a lot of work. Upside: We > really would provide the image processing capabilities. > > What do others think? Personally, I always wanted to have a better > designed Image Library with a smaller, but well tested subset of > ImageProcessing Algos that are really useful. > > >> Goodluck with getting that done though. I doubt we will see a new >> OpenCV release for awhile... and people will be using 2.0 for a long >> time to come... > No wonder; hacking OpenCV code is as ugly as coding can get. > > Cheers, > Holger > >> >> 2009/11/4 Stéfan van der Walt <ste...(a)sun.ac.za>: >> >> >> >> >> >> > 2009/11/4 Chris Colbert <sccolb...(a)gmail.com>: >> >> >> OpenCV has a ___version___ header file. >> >> > We can only access that if it exposed as a function, though, so maybe >> > they can help us out. >> >> > Cheers >> > Stéfan

3 9

Build requirements
by Tony S Yu 05 Nov '09

05 Nov '09

Hi, I tried running scikits.image on Python 2.5 and noticed that Python 2.6 is required. (I got some errors for enhanced property decorators, which were introduced in 2.6.) I'm not arguing against this requirement, but this error made me think it'd be nice to have a list of requirements. I've added a "doc" branch with a requirements list. I don't really know the internals of the scikit, so the list is pretty rough. On a side note, I'm curious about the overlap of functionality in the opencv module and scipy.ndimage. Since scipy is already required, is there an advantage to using the duplicated functions in scikits.opencv? (Most of the functions in that module have no ndimage counterpart, but I'm curious about the ones that do.) Similarly, some of the filters provided by CellProfiler (listed as suggested code to adapt on the "How to contribute" page) have counterparts in scipy.ndimage. Cheers, -Tony

3 4

Updates to fancy imshow widget and ColorMixer
by Chris Colbert 04 Nov '09

04 Nov '09

Hey Everyone, I've made some improvements to the fancy imshow widget and the ColorMixer. The ColorMixer now supports a brightness function. And the fancy imshow widget now includes labeled sliders, a function selector combo box, a commit button and a revert button. Basically, changes will persist between combo-box selections, only if you commit changes. Otherwise, the image is reverted to the most recent commit state. The revert button does a hard reset to the very original image. Please grab everything from my io branch and give it a run through. I think the next thing I will add is hsv support and a histogram under the image. Let me know what else you want! Thanks! Chris

2 2

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

04 Nov '09

The plugin system makes it extremely easy to make any kind of display plugin you want. You just have to provide at least two methods and shake hands with the window manager. your plugin must provide the following two functions: imshow(img, *arg, **kwarge) and __app_show() you must also "shake hands" with the window manager. A common occurance in the gui tookits is the windows opened from within functions during an interactive python session will be garbage collected after the function returns and they fall out of scope. Thus the window manager maintains a reference to the window until it is closed. Also, because the gui toolkits set PyOS_InputHook, we have to make sure that only one gui kit gets imported in a session (some kits will trample on other, but not vice-versa) so the window manager also implements a "gui lock" that you must acquire before using it or your gui kit: from util import window_manager window_manager.acquire('qt') #or 'gtk' or 'mybadassplugin' then evertime you create a window, register the main_window handle with the manager. window_manager.add_window(mynew_window) Then, make sure that mynew_window's destroy event, whatever that may be, makes a call to window_manager.remove_window(mynew_window) The window manager also implements a callback that can be set, that will be called when there are no more registered windows. This was necessary for non-interactive sessions, so you can kill the event loop. This is also the reason for __app_show(): You're plugin must also define an __app_show() method. When not running interactively (i.e. from a script), calls to imshow() will queue up windows, but without a gui mainloop running, they will never display. When a user calls show(), this calls your plugins __app_show() method, which should do two things: 1) register a callback with window_manager that will be called when all windows are closed and will cause the event loop to exit (this may not be required for some kits. i.e. PyQt4) 2) start the mainloop for the pygtk plugin, it looks like this: def __app_show(): On Wed, Nov 4, 2009 at 7:53 AM, SirVer <sirver(a)gmx.de> wrote: > > Hi Stefan, > > I do not know were I'm currently at. My gui branch is not merged to > master, so I guess you are unhappy with it. There is other development > based on the plugin architecture and we have now yet another image > viewer in pyqt. Still I feel that a full featured gui module could > lead to much more powerful image processing widgets than the plugin > system could. So I am unsure if and if yes how I should advance with > my gui & camcalib branch. > > Cheers, > Holger > > On 3 Nov., 22:40, Stéfan van der Walt <ste...(a)sun.ac.za> wrote: >> Hi all, >> >> I am planning to tag version 0.3 by the end of this week or early next >> week. Please let me know if there are any branches I should review >> before then. >> >> Happy hacking! >> Stéfan

3 4

OpenCV 2 or 1
by SirVer 04 Nov '09

04 Nov '09

Hi, currently the following test fails on my system: test_opencv_cv.TestCalibrateCamera2.test_cvCalibrateCamera2_Identity ... OpenCV ERROR: Bad argument (Distortion coefficients must be 4x1 or 1x4 floating-point matrix) in function cvCalibrateCamera2, cvcalibration.cpp(1350) This is a bit ironic, since it is a test that I initially wrote. The Problem is that the function cvCalibrateCamera2 now allocates an distortion array of size 1x5 while before it allocated a distortion array of 1x4. I guess that opencv2 uses 1x5 while opencv1 (the one i currently use) uses 1x4. The Problem (once again!) rises that we do not link against a particular version of the opencv but instead to our very own hotlinking when the lib is loaded. This leads to this obscure crash without any feedback to the user. Thus, I vote again for autodetection and proper linking against headers. OR, if this is too much trouble at least deny loading OpenCV 1 at run time, because we just can not be too sure what the problems are. Another point: generated c files in the repository are constantly comming up as changed or merge conflicts for me. What is the reason to keep .c files in the repository; i think it is fair to assume that python developers who have a c compiler installed will also have cython installed to generate the .c files. Holger

4 10

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

04 Nov '09

Hi Holger 2009/11/4 SirVer <sirver(a)gmx.de>: > I do not know were I'm currently at. My gui branch is not merged to > master, so I guess you are unhappy with it. There is other development > based on the plugin architecture and we have now yet another image > viewer in pyqt. Still I feel that a full featured gui module could > lead to much more powerful image processing widgets than the plugin > system could. So I am unsure if and if yes how I should advance with > my gui & camcalib branch. I'm sorry, I didn't mean to exclude you in any way: you were pretty quiet after our last email exchange, so Chris and I developed the architecture further. I still see a place for a higher-level GUI, although I'd be glad if you could explain your vision for such a module in more detail. To get back to your GUI branch: is the dependency on OpenGL really necessary? We saw in the meantime that QImage's can be created directly from numpy arrays, so that should give you the kind of display speed you need (yes, I know, I'm a bit allergic to new dependencies). If we do have to bring in OpenGL, I'm still of the opinion that we should avoid duplicating the work done by Pyglet. I am also still interested in combining the work you and Andrew Straw did to provide a good image acquisition module. Regards Stéfan

1 0