Mailman 3 November 2009 - scikit-image

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

Re: io.imshow(fancy=True) and the new color channel mixer!
by Stéfan van der Walt 04 Nov '09

04 Nov '09

Hi Holger 2009/11/4 SirVer <sirver(a)gmx.de>: > Also, while I agree that the plugin architecture is well layed out, I > feel that this is not a very pythonic way to do things. In Python, > stuff either works because you have everything installed or not. I do > not want to criticize before I completely understand the reason for > the plugin architecture. Could someone point me to the thread were it > was discussed? I don't think this is an accurate summary of "pythonic". Sometimes, it is impossible not to have differing behaviour depending on the OS, available libraries, etc. In our case, the plugin architecture made it possible for me to display images on my work machine (that only has GTK installed), or on my Mac (which only has Qt4 installed). Another well-known package that uses a similar architecture is matplotlib, with backends for GTK, OSX, PDF and so forth. One aspect of the scikit design that I'd like to preserve is a light list of dependencies. This means that someone who simply wants to run a filter should not have to install OpenCV, Qt, GTK, Cython, etc. Regards Stéfan

1 0

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

04 Nov '09

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

2 1

io.imshow(fancy=True) and the new color channel mixer!
by Chris Colbert 04 Nov '09

04 Nov '09

Hey Guys, I worked today on a couple of things. First, as you all know, we recently added imshow() plugins for pygtk and pyqt4 backends. The simple imshow() just pops open a window with the image, nothing more, nothing less. I've made the start of a "fancy" imshow for qt. its called via, imshow(img, fancy=True). Unlike a matplotlib style imshow, I'm wanting to be a little "cooler" :) Here is what works so far: In the status bar of the window, you get your cursor position, as well as the RGB pixels values of the image over point at which your mouse is hovering. To the right of the image are some sliders (Two groups of three for now, until i can figure out dropdown selector lists :) ). Each of these three groups controls the RGB channels of the new channel mixer (more on that in a bit). The first group performs "additive" mixing and the second group performs a "multiply" operation. I still need to add a button to save the state when you are done with an operation, and a revert button, labels yaddy yaddy yadda... it's just a prototype right now. Now, the new ColorMixer: I've implemented the start of a new ColorMixer in io/_plugins/util.py (the backend is _colormixer.pyx) which handles all of these nifty color space operations on the channels of you rgb uint8 numpy array. (sorry, no floating point for you!, its meant for display operations). Currently, it performs additive and multiply operations on any given channel. I will be adding brightness, contrast, and HSV functions in the coming days. Its meant to be a general util that can be used by any plugin. Just hook up your sliders and go! You can check out all this goodness at my github on the io branch. http://github.com/sccolbert/scikits.image/tree/io/scikits/image/io/ You'll have to manually build the _colormixer.pyx file cause I havent hooked in a setup.py yet. Cheers! Chris

3 3

Shortest Path algorithm
by Stéfan van der Walt 03 Nov '09

03 Nov '09

Hi all, Please review the Shortest Path functionality implemented in branch 'spath' of http://github.com/stefanv/scikits.image Thanks Stéfan

2 4

I/O Plugin infrastructure + wx/qt plugins
by Stéfan van der Walt 01 Nov '09

01 Nov '09

Hi all, Chris and I have been working towards a more complete plugin framework this afternoon. Please have a look at http://github.com/stefanv/scikits.image in the `io` branch to see what's been done so far. You may try the new qt or wx image display plugins as follows: import scikits.image.io as io import numpy as np io.load_plugin('qt') # or 'wx' io.imshow(np.random.random((200, 200)) All the plugins available may be queried with io.plugins() Regards Stéfan

2 1