Mailman 3 March 2012 - scikit-image

Re: Imshow and Linescan - first version
by Stéfan van der Walt March 17, 2012

March 17, 2012

On Fri, Mar 16, 2012 at 5:44 PM, Tony Yu <tsyu80(a)gmail.com> wrote: > And I'll move this into scikits-image org as soon as I know what name to put > it under. I'm not sure how I feel about `skloupe`---as always there's the > pronunciation issue. `skoupe`... that's a stretch. `sciloupe`? Based on > pypi, `loupe` is available (it turns out there's a django-loupe project), > but then there's the branding issue. `loupepy` or `louppy` (pyloupe is > taken)? Too cutesy, maybe. `pypeye` (python picture eyer---that's not a > word). Some bikeshedding would actually be welcome here. Well, skimage.viewer is still available :) And there it will also get installed everywhere skimage does; but you know all the pros and cons of maintaining a separate package already. Stéfan

1 0

Re: Imshow and Linescan - first version
by Tony Yu March 17, 2012

March 17, 2012

2012/3/16 Stéfan van der Walt <stefan(a)sun.ac.za> > Hey Tony > > On Fri, Mar 16, 2012 at 2:08 PM, Tony Yu <tsyu80(a)gmail.com> wrote: > > Here's an example plugin for using skimage's canny edge detector: > > > > > https://github.com/tonysyu/skloupe/blob/master/skloupe/plugins/edgedetector… > > Very cool! I also like the styled slider. > > The reason I asked about the repo is because I definitely want some of > this functionality to be available in skimage (a good viewer, editor, > etc.). You are, of course, welcome to create a loupe repo under the > scikits-image org (I think you have the necessary permissions); I just > want to think about how we can integrate this into the main package > most efficiently without introducing a dependency (and preferably > avoiding the pain of submodules). > > Stéfan > I agree: some of this functionality should be moved into skimage. I would, however, like to keep whatever's moved to be fairly small---maybe something that can fit into a single file. (I really don't think having a subdirectory in the io-plugins directory would be pretty.) My plan is to play around with the code for awhile before deciding which parts should be moved directly into skimage. And I'll move this into scikits-image org as soon as I know what name to put it under. I'm not sure how I feel about `skloupe`---as always there's the pronunciation issue. `skoupe`... that's a stretch. `sciloupe`? Based on pypi, `loupe` is available (it turns out there's a django-loupe project), but then there's the branding issue. `loupepy` or `louppy` (pyloupe is taken)? Too cutesy, maybe. `pypeye` (python picture eyer---that's not a word). Some bikeshedding <http://en.wikipedia.org/wiki/Bikeshedding> would actually be welcome here. -Tony

1 0

Re: Imshow and Linescan - first version
by Stéfan van der Walt March 16, 2012

March 16, 2012

Hey Tony On Fri, Mar 16, 2012 at 2:08 PM, Tony Yu <tsyu80(a)gmail.com> wrote: > Here's an example plugin for using skimage's canny edge detector: > > https://github.com/tonysyu/skloupe/blob/master/skloupe/plugins/edgedetector… Very cool! I also like the styled slider. The reason I asked about the repo is because I definitely want some of this functionality to be available in skimage (a good viewer, editor, etc.). You are, of course, welcome to create a loupe repo under the scikits-image org (I think you have the necessary permissions); I just want to think about how we can integrate this into the main package most efficiently without introducing a dependency (and preferably avoiding the pain of submodules). Stéfan

1 0

Re: Imshow and Linescan - first version
by Tony Yu March 16, 2012

March 16, 2012

On Fri, Mar 16, 2012 at 4:17 PM, Tony Yu <tsyu80(a)gmail.com> wrote: > > > 2012/3/16 Stéfan van der Walt <stefan(a)sun.ac.za> > >> Hi Tony >> >> On Fri, Mar 16, 2012 at 12:18 PM, Tony Yu <tsyu80(a)gmail.com> wrote: >> > Sorry to change things up while you're working on this, but I wanted to >> > split the viewer into different files; so, I've moved development to a >> repo >> > called `skloupe`: >> > >> > https://github.com/tonysyu/skloupe >> >> Out of curiosity, what is the motivation for developing this outside of >> skimage? >> >> Stéfan >> > > Mainly because it was getting messy. For example, I'm not sure how I feel > about putting subdirectories into the plugins directory. > > If this actually became a useful project, I think a good place for it > would in the scikits-image github account but in a separate repo. The > reason being that it could be quite large if there are a lot of plugins. > Even if it isn't, I'd like to play around with it outside of skimage so > that I don't have to switch between branches so often. > > If you think otherwise, then I'm happy to move it back into the main repo > after I've played around a bit in the sandbox. > > -Tony > Here's an example plugin for using skimage's canny edge detector: https://github.com/tonysyu/skloupe/blob/master/skloupe/plugins/edgedetector… and the demo script: https://github.com/tonysyu/skloupe/blob/master/examples/plugins/edgedetecto… -Tony

1 0

Re: Imshow and Linescan - first version
by Tony Yu March 16, 2012

March 16, 2012

2012/3/16 Stéfan van der Walt <stefan(a)sun.ac.za> > Hi Tony > > On Fri, Mar 16, 2012 at 12:18 PM, Tony Yu <tsyu80(a)gmail.com> wrote: > > Sorry to change things up while you're working on this, but I wanted to > > split the viewer into different files; so, I've moved development to a > repo > > called `skloupe`: > > > > https://github.com/tonysyu/skloupe > > Out of curiosity, what is the motivation for developing this outside of > skimage? > > Stéfan > Mainly because it was getting messy. For example, I'm not sure how I feel about putting subdirectories into the plugins directory. If this actually became a useful project, I think a good place for it would in the scikits-image github account but in a separate repo. The reason being that it could be quite large if there are a lot of plugins. Even if it isn't, I'd like to play around with it outside of skimage so that I don't have to switch between branches so often. If you think otherwise, then I'm happy to move it back into the main repo after I've played around a bit in the sandbox. -Tony

1 0

Re: Imshow and Linescan - first version
by Stéfan van der Walt March 16, 2012

March 16, 2012

Hi Tony On Fri, Mar 16, 2012 at 12:18 PM, Tony Yu <tsyu80(a)gmail.com> wrote: > Sorry to change things up while you're working on this, but I wanted to > split the viewer into different files; so, I've moved development to a repo > called `skloupe`: > > https://github.com/tonysyu/skloupe Out of curiosity, what is the motivation for developing this outside of skimage? Stéfan

1 0

Re: Imshow and Linescan - first version
by Guillaume Gay March 16, 2012

March 16, 2012

Hi Tony, This looks great. I was Le 10/03/2012 18:34, Tony Yu a écrit : > > > On Mon, Feb 27, 2012 at 4:13 AM, Guillaume Gay > <guillaume(a)mitotic-machine.org <mailto:guillaume@mitotic-machine.org>> > wrote: > > Le 26/02/2012 21:15, Stéfan van der Walt a écrit : > > On Sat, Feb 25, 2012 at 11:10 AM, Tony Yu<tsyu80(a)gmail.com > <mailto:tsyu80@gmail.com>> wrote: > > Plugin system > ------ > It might be nice to have some sort of plugin system for > the image viewer. > That way, tools like this could be implemented a bit more > easily and, also, > easily added to the viewer or ignored by the user. > > At the moment, we basically have a double-viewer implementation: > simply vs fancy. So we separate out > > imshow(x) and imshow(x, fancy=True) > > I thought one solution was to sub-class FigureCanvas, with extra > buttons, but from what I understand, it is not that easy to do > this at the platform independant level. > > But maybe adding arguments to the function call, for exemple > imshow(x, set_contrast=True, linescan=True) plus keyboard toggles > is enough? > > > Hey Guillaume, > > I'm still tossing around ideas for implementing some sort of > interactive viewer with pluggable tools. Based off your LineProfile > idea, I created the beginnings of a matplotlib image-viewer > <https://github.com/tonysyu/scikits-image/blob/mpl-fancy/skimage/io/_plugins…>, > which could have some sort of plugin system (not really implemented). > > I took a different approach than your original implementation: the > line-profile output shows up as a separate figure. I think it'd be > nice to have tools integrated into the image window, but I think this > will be really difficult to do well (specifically, resizing the figure > window and adjusting canvas area when connecting and disconnecting the > tool). Yes, I scratched my head on that, and I agree with you it is difficult and would certainly look really ugly (and buggy) most of the time. > Using multiple figures is easier, although a little more cumbersome > for the user. One advantage is that you can disconnect the tool just > by closing the tool's figure (this doesn't currently work for Qt4 > backends because of an MPL bug > <https://github.com/matplotlib/matplotlib/pull/716>). One thing I didn't figure out > > Right now, the LineProfile tool is just a test case: the main > components are an ImageWindow class and the Widget base class. I'd > like to test the architecture with some different use cases (e.g. > contrast-adjustment widget, mask editor, etc.) when I have the time. I > could see these classes changing dramatically after testing different > uses. I already have some ideas on the contrast setter, I'll try to work on that piece this week. > > Everything's in a single file at the moment, but the idea would be to > move the Widget subclasses to some sort of "widgets" directory. > > -Tony > > P.S. Guillaume: I couldn't figure out why > `img_zoomed`/`previous_axis`/`current_axis` were necessary, so I just > removed them. If there was some functionality that I missed, let me know. This was a - more or less effective I must confess - work around to return to the correct view after a reset() callback, once the image was zoomed in, because this was drawing the image back to it's full scale. Maybe with your implementation this is not needed, I'll investigate this. Guillaume > > > > > agree to an extent. Nevertheless, I think providing a > viewer that supplies > *an infrastructure* for creating GUI tools might be really > valuable. I > haven't really thought through what this plugin system > would look like, so > it may just be a pipe dream. > > This is a tricky problem (which set of tools to use, etc.)--but in > principle, it would be nice to have a few standard viewers, e.g., > image compare, image compare + parameter adjust, mask editor > (to build > custom filters, e.g.) and image inspector (like the one you and > Guillaume are working on). > > Stéfan > > What do you mean by mask editor? Something like a slider to adjust > a threshold with a superimposed mask? > > Guillaume > >

2 1

Re: [OT] pass a C callback function to a cythom module via python
by Stéfan van der Walt March 16, 2012

March 16, 2012

Hi Nadav On Mar 15, 2012 10:54 PM, "Nadav Horesh" <nadavh.horesh(a)gmail.com> wrote: > > I have the following: > A library of C function which is compiled into a dll > A cython module with a function that expects as a parameter a C callback function. > > My problem is how to make a python script to pass directly the address of a C function from the dll to the cython function. There's a Cython Enhancement Proposal for this, but it hasn't been implemented: http://wiki.cython.org/enhancements/nativecall So, I don't think there's a cleaner way, unfortunately. It's great that you found a workaround, though--many people have been struggling with this issue. Stéfan

1 0

[OT] pass a C callback function to a cythom module via python
by Nadav Horesh March 16, 2012

March 16, 2012

I have the following: - A library of C function which is compiled into a dll - A cython module with a function that expects as a parameter a C callback function. My problem is how to make a python script to pass directly the address of a C function from the dll to the cython function. example: -- C code --- float mul(float a, float b) { return a*b; } -- cython module -- ctypedef float c2f(float, float) def call_c(c2f fun, float x, float y): return fun(x, y) ---------------------- I can use ctypes as the follows, but the call goes through a python wrapper from ctypes import * import cython_module dll = cdll.LoadLibrary('./C_modile.so') mul = dll.mul mul.argtypes = [c_float, c_float] mul.restype = c_float cython_module.call_c(mul, c_float(3), c_float(2)) I found a work around by adding the following line to the C code: void* mulp = mul So the following line in the python module provides the address of the mul function: mull_addr = c_void_p.in_dll(dll, "mul") I am wondering if there is a friendly and simple(r) solution. Nadav.

1 0

[offtopic] how to get PyQT running for EPD?
by Michael Aye March 15, 2012

March 15, 2012

Sorry, for the offtopic question, but I am so interested in your fancy viewer and still haven't seen it yet, because I don't have a running pyqt. I got pyqt compiled with MacPorts on my Mac but am unsure how or if it would be working together with my EPD? Alternatively, can I force the MacPort compilation to use the EPD directly? If you like some answer points on stackoverflow, you could also answer my question there: http://stackoverflow.com/questions/9600474/how-can-i-link-macports-pyqt-to-… Best regards, Michael

2 1