Mailman 3 February 2012 - scikit-image

Re: GUI tools and upsizing
by Tony Yu 15 Feb '12

15 Feb '12

2012/2/14 Stéfan van der Walt <stefan(a)sun.ac.za> > Hey Neil > > On Mon, Feb 13, 2012 at 8:44 PM, Neil Yager <yager.neil(a)gmail.com> wrote: > > 1. One thing that I think would be very useful is some simple > > interactive tools for examining with images. For example, 2 simple > > additions to the basic matplotlib's imshow would be to show the pixel > > intensity of the current mouse location (it already shows the x, y > > coordinates). Also, it would be nice to be able to click at 2 points > > and display the profile of intensities between them. Would adding > > functionality like this cause too many compatibility issues, or be > > moving too far away from skimage's core strength? > > Not at all! Would you like to update the fancy viewer? It already > does most of what you want: > > from skimage import io, data > io.use_plugin('qt') > io.imshow(data.camera(), fancy=True) > This is strange: imshow (with or without "fancy") isn't working for me with the qt backend. Or actually, imread_qt isn't working for me (see traceback below; also imshow works if I force skimage to use a different imread, although the window disappears immediately). I'm not really sure how to debug a MemoryError. What's weird is that I'm certain I've used the fancy viewer since the addition of imread_qt (July 2011). I updated (Py)Qt but that didn't help. -Tony python(34737,0x7fff70b93cc0) malloc: *** mmap(size=140734799798272) failed (error co de=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug Traceback (most recent call last): File "qtshow.py", line 9, in <module> io.imshow(data.camera(), fancy=True) File "/Users/Tony/python/devel/skimage/skimage/data/__init__.py", line 34, in came ra return load("camera.png") File "/Users/Tony/python/devel/skimage/skimage/data/__init__.py", line 27, in load return imread(_os.path.join(data_dir, f)) File "/Users/Tony/python/devel/skimage/skimage/io/_io.py", line 72, in imread img = call_plugin('imread', fname, plugin=plugin, **plugin_args) File "/Users/Tony/python/devel/skimage/skimage/io/_plugins/plugin.py", line 88, in call return func(*args, **kwargs) File "/Users/Tony/python/devel/skimage/skimage/io/_plugins/qt_plugin.py", line 102 , in imread_qt img = np.array(arrayptr) MemoryError

1 0

Re: GUI tools and upsizing
by Neil Yager 14 Feb '12

14 Feb '12

Great - thanks guys. That fancy viewer is much better than what I've been using. I'll look into extending its functionality even further. Neil

1 0

Re: GUI tools and upsizing
by Stéfan van der Walt 14 Feb '12

14 Feb '12

Hey Neil On Mon, Feb 13, 2012 at 8:44 PM, Neil Yager <yager.neil(a)gmail.com> wrote: > 1. One thing that I think would be very useful is some simple > interactive tools for examining with images. For example, 2 simple > additions to the basic matplotlib's imshow would be to show the pixel > intensity of the current mouse location (it already shows the x, y > coordinates). Also, it would be nice to be able to click at 2 points > and display the profile of intensities between them. Would adding > functionality like this cause too many compatibility issues, or be > moving too far away from skimage's core strength? Not at all! Would you like to update the fancy viewer? It already does most of what you want: from skimage import io, data io.use_plugin('qt') io.imshow(data.camera(), fancy=True) > 2. I'm currently working with large images and it often useful to work > with down-sampled versions. A quick way to do this is using views: > > im_small = im[::4, ::4] > > Is there a quick way to do the inverse? i.e. something like: > > im_big = im[::0.25, ::0.25] Emmanuelle's suggestion (to use ndimage.zoom) is the right one. We should probably write a wrapper around our fast_homography code, though, because it yields better results (fewer boundary effects, it's a bit faster). Here's a start: import numpy as np from skimage import transform, img_as_float def zoom(image, s): H = np.array([[s, 0, 0], [0, s, 0], [0, 0, 1]]) output_shape = np.ceil(np.array(image.shape) * s) image = img_as_float(image) return transform.fast_homography(image, H, output_shape=output_shape) Stéfan

1 0

Re: GUI tools and upsizing
by Emmanuelle Gouillart 14 Feb '12

14 Feb '12

Hi Neil, just answering quickly to your second question (someone will still have to answer the first one!). > 2. I'm currently working with large images and it often useful to work > with down-sampled versions. A quick way to do this is using views: > im_small = im[::4, ::4] > Is there a quick way to do the inverse? i.e. something like: > im_big = im[::0.25, ::0.25] > At the moment I'm just resizing the image, which has more overhead. > Anything I'm missing? I use scipy.ndimage.zoom for this purpose. Cheers, Emmanuelle

1 0

GUI tools and upsizing
by Neil Yager 13 Feb '12

13 Feb '12

Hi everyone, Two questions: 1. One thing that I think would be very useful is some simple interactive tools for examining with images. For example, 2 simple additions to the basic matplotlib's imshow would be to show the pixel intensity of the current mouse location (it already shows the x, y coordinates). Also, it would be nice to be able to click at 2 points and display the profile of intensities between them. Would adding functionality like this cause too many compatibility issues, or be moving too far away from skimage's core strength? 2. I'm currently working with large images and it often useful to work with down-sampled versions. A quick way to do this is using views: im_small = im[::4, ::4] Is there a quick way to do the inverse? i.e. something like: im_big = im[::0.25, ::0.25] At the moment I'm just resizing the image, which has more overhead. Anything I'm missing? Cheers, Neil

1 0

Re: random walker segmentation / blob detection
by Emmanuelle Gouillart 13 Feb '12

13 Feb '12

Hi Ray, this segmentation algorithm with supervised learning really seems great! I wonder whether we could have a similar algorithm in skimage. ilastik.org is down at the moment, so I can't check their license. But there is a random forest classifier in scikit-learn that we could re-use. A difficult point is the in-painting of pixels on the image; could anyone give hints about technical solutions to do this? Cheers, Emmanuelle On Thu, Feb 09, 2012 at 01:06:57PM +0100, Thouis Jones wrote: > On Thu, Feb 9, 2012 at 11:44, Michael Aye <kmichael.aye(a)gmail.com> wrote: > > ilastik does not seem to have a programmatic interface, is that right? > > I can't do it via GUI's, my end goal is to find features programmatically in > > possibly thousands of images... > It has a scripting interface (command line) for batch processing. I > have talked to them about adding a client/server mode using zmq, but > it's not yet started. > Ray

2 1

dependencies: numpy, matplotlib
by Emmanuelle Gouillart 13 Feb '12

13 Feb '12

> That's a very valid point. And since it's so little effort to remain > 1.5 compatible, there seems little reason not to. > I'm the guilty party that suggested the use of a numpy 1.6 call in the > converter functions--sorry about that! Chris has kindly made a PR to > address the issue. And it works like a charm, as I just tested with my "old" ;-) set-up (numpy 1.5). Build and tests work fine, the doc builds well, just perfect! I saw that you've already merged the PR, but I wanted to confirm that it works fine for me. Thanks Chris, you rock! > So, let's talk about Matplotlib--can we use version 1 yet? If not, I > suggest that we at least copy over 'subplots', because this function > makes it so much easier to build clean examples. I think Matplotlib is a smaller issue, since it's only used to build the doc (am I wrong?), that is, more a developer's than a user's job. And Matplotlib 1.0.1 is packaged for the latest ubuntu. There is always the risk that people download an example, try to execute it and are annoyed by the error they get if they have an older version of matplotlib. If people start complaining, then we might copy over matplotlib's subplots and call skimage.subplots. But I think that this wouldn't discourage new users, contrary to installation problems. Maybe a sentence in the user guide on how to adapt examples for matplotlib < 1.0 could help, too. So my opinion is, yes, we could use version 1 now. Cheers, Emmanuelle

1 0

Re: Error when building from git
by Zachary Pincus 13 Feb '12

13 Feb '12

Hi Guillaume, Sorry for the trouble with the FreeImage loading -- I'm glad you got it straightened out. As Stéfan mentioned, we're trying to get this a lot smoother, and it should be soon! Please let me know if you have any other problems with FreeImage. I should also mention (as you're doing microscopy and may need to get at image metadata from time to time, as I do) that I recently added that capability to the freeimage wrappers. See e.g.: https://github.com/scikits-image/scikits-image/blob/master/skimage/io/_plug… >> Also, I just ran into another problem with freeimage... > [...] >> >> After some investigation, I found that I had to link /usr/lib/ >> libfreeimage.so.3 with /usr/lib/libfreeimage.so to pass the plugin >> test: > > I just discovered this myself earlier this week. Zachary Pincus has > been working on better library location (on Windows mainly), so we should have > that sorted out soon. Would you mind creating an issue on GitHub in > the mean time, so that we don't lose track of it? > https://github.com/scikits-image/scikits-image/pull/134 This should fix the above problem and a host of others. A mechanism for auto-downloading a freeimage library on Win/Mac is still in progress... I'm not sure how to best integrate that with the distutils, but here's what I have for a start: https://github.com/zachrahan/scikits-image/tree/freeimage-install-libs https://github.com/zachrahan/freeimage-sharedlib Zach

3 5

Re: Error when building from git
by Emmanuelle Gouillart 13 Feb '12

13 Feb '12

Hi StÃ¯Â¿Â½fan, > I understand the challenges of running on an older platform, but I > also wonder: if a user can recompile scikits-image, what's stopping > them from also building the latest (stable) numpy? Well, it's just one more pain in the neck to build another package. And if you have to build numpy, (I think) you also have to build your own matplotlib, scipy, etc. Which is even a greater pain. What's more, a large fraction of users want to use the packages installed by their IT managers, who like to have one standard version of all packages. People using Python(x,y) on Windows, for example, would have a hard time building all the packages. I think the example given by JÃ¯Â¿Â½rÃ¯Â¿Â½me is a good one: he works in a big institute where people might be interested in using skimage, but users typically don't install their own packages. That said, we can of course tell people to install an older version skimage. However, I have the impression that an important part of the added value of new releases are in the algorithms/functions that the release provides, rather than in using newer numpy functionalities. This is by all means a biased point of view, since I've been more busy with the former point. > I certainly have > the expectation that software should run with the available stable > versions of dependencies on the date of release. That said, any > benefit we can get with little effort is worth it, and there's no > reason to purposefully make it harder for users than need be. So > please, keep the PRs coming for backwards compatibility, as long as > they are not too disruptive. OK, I'll try to :-D. Cheers, Emmanuelle

2 1

Re: Error when building from git
by Guillaume Gay 13 Feb '12

13 Feb '12

Giving a humble user side perspective here... I think Stéfan is right: if I use the git repository for skimage, I shall expect that it depends on the latest versions of the dependencies, and not complain about lack of compatibility with the packaged version of numpy, for example. Yet ... somehow I felt I could use the latest version of skimage (because there would be for example the latest algorithms implemented) without having to reconsider my whole python environment, notably because I am not 100% sure the rest of my code won't suffer. Said otherwise numpy is at the root of lots of stuff I'm doing, and skimage is closer to the tip. Pushing this a lot, you could say: the user shall be ready to compile the latest linux kernel, as they are cloning skimage from git.... I guess the equilibrium here is hard to catch. Guillaume Le 11/02/2012 23:26, Stéfan van der Walt a écrit : > 2012/2/11 Jérôme Kieffer<google(a)terre-adelie.org>: >> PS: We are currently deploying debian6 (squeeze) at work which should >> be the reference until end 2013 (at least!) so putting dependency on a >> too-recent numpy will prevent skimage to be deployed on the beamline. > I guess the point I was trying to make is that nobody expects SciPy 12 > to work with NumPy 1.5, since they are released at different times. > If you install scikits-image 0.4, released when NumPy 1.5 was stable, > you'll get 1.5 compatibility. The problem only comes in when you > require the latest functionality--in which case upgrading the package > + dependencies seems completely reasonable. > > If we focus on getting scikits-image packaged in the different > distros, these problems should more-or-less go away, since people will > do "apt-get install python-skimage" and be happy with whichever > version is provided. > > Stéfan >

1 0