Hi, No problem for the structure change. I think things are clearer that way - at least for all that is below the skloupe/ directory. As for the debate on whether skloupe (in French this sounds great btw) should be part of skimage, I think it should be the case, for the same arguments both of you used. I started looking at the code. Running edgedetector_demo.py, I have some issues with the slider window not updating the slider position. This also happens when I run example/widgets/slider_demo.py (I openned an issue on the github page). Stéfan you said I think from the start we assumed that we'd be building tools on Matplotlib and Qt. Is Qt the *required* backend, or do we stick to the matplotlib higher compatibility layer? Guillaume Le 18/03/2012 17:55, Stéfan van der Walt a écrit :

Hey, Tony

...

Possible Con ------------------------ Someone mentioned a while back that it would be a good idea to keep skimage focused on the basic toolset, and then a separate package could build off of it.

Counter-argument: This infrastructure (so far, at least) is fairly lightweight, and I imagine the biggest area of growth would be the plugins---most of which would just provide an interactive interface to skimage functions. This is the way I see it too: one of skimage's most important contributions is to provide an easily-accessible Python platform for building image processing solutions. This exactly means having good

On Fri, Mar 16, 2012 at 6:49 PM, Tony Yu<tsyu80@gmail.com> wrote: pipelines, good display, and all the tools needed to build a complete solution. Some of the algorithms may be obtained from elsewhere (e.g., opencv)--but even so, building a solution using those packages is currently still a pain. So, I see the construction of these basic tools and building blocks as a fundamental part of what we're trying to do.

...

Counter-argument: skimage would provide the simplest possible interface for adding interactivity (taking advantage of Matplotlib tools for plotting histograms, etc and its support for multiple gui toolkits). A separate project would be ideal for gui-toolkit--specific viewers (which could potentially be significantly fast) since it would likely take more code to do some of these things (I could be wrong about this). Also, I assume more people using skimage would know matplotlib over any specific backend. I think from the start we assumed that we'd be building tools on Matplotlib and Qt. If something better comes along, we should consider it--of course--but in the meantime it still seems like a reasonable choice. If the plugin infrastructure can be improved to make it easier to build external tools, I'm also all for that.

...

I'd like to come to some sort of consensus, if possible, so please---if you *any* opinions on this---let your voice be heard. I guess my opinion is obvious, but for the record: I'd love to include this work directly as part of skimage. But, if that's not to be, I still encourage it whole-heartedly!

Stéfan