Mailman 3 March 2012 - scikit-image

Re: Imshow and Linescan - first version
by Stéfan van der Walt 02 Mar '12

02 Mar '12

On Fri, Mar 2, 2012 at 10:11 AM, Dan Farmer <dfarmernv(a)gmail.com> wrote: > I think fancy depends on what plugin you have active. try > io.use_plugin('qt') before doing that. We should provide a catch-all for this situation that let's the user know what's going on, e.g. "The current I/O plugin does not have a fancy viewer." PRs welcome! Stéfan

1 0

Re: ANN: scikits-image v0.5
by Stéfan van der Walt 02 Mar '12

02 Mar '12

On Fri, Mar 2, 2012 at 7:47 AM, Tony Yu <tsyu80(a)gmail.com> wrote: > The file is a bit annoying when adding changes and even more so when > switching branches. (The make file behavior, I think, makes it a bit harder > to switch branches since `git stash` won't restore `version.py`) Yes, version.py is rather annoying. Here's a PR: https://github.com/scikits-image/scikits-image/pull/159 Stéfan

1 0

Re: [scikits-image] Restore previous io plugins (#152)
by Tony Yu 02 Mar '12

02 Mar '12

On Tue, Feb 28, 2012 at 12:20 AM, Tony Yu <tsyu80(a)gmail.com> wrote: > > > 2012/2/26 Stéfan van der Walt <stefan(a)sun.ac.za> > >> On Sun, Feb 26, 2012 at 12:25 PM, Christoph Gohlke <cjgohlke(a)gmail.com> >> wrote: >> > Instead of restoring the default plugins after each test module, maybe >> it >> > would be better/cleaner/safer for the tests to never change the default >> > plugins but to just load the plugin and explicitly specify the plugin in >> > each imread, imwrite, etc. function call? It seems there is currently >> no way >> > to load a plugin without making it the default. This could be achieved >> by >> > changing the use_plugin function to accept another option for the `kind` >> > parameter, e.g. an empty string, signaling that the plugin should only >> be >> > loaded. Probably too late for the 0.5 release. >> >> Ideally, the ``imread(..., plugin='fits')`` functionality should >> auto-load the FITS-plugin---I should see why this is not currently >> working, because it seems like a bug. >> >> Stéfan >> > > I just submitted PR #157<https://github.com/scikits-image/scikits-image/pull/157> to > address an error raised with non-loaded plugins. I'm not sure if this > addresses the issue you mention above, but it's related, at least. > > -Tony > Hmm, another issue: Using ``imshow(..., plugin='qt')`` doesn't behave correctly (even after the PR above) because the ``show()`` function still uses the default plugin (i.e. not necessarily the qt plugin), so the window opened by ``imshow`` just disappears. I don't have time to look at the code right now, but this seems like a more difficult issue to solve. -Tony

1 0

Re: sub modules missing?
by Michael Aye 02 Mar '12

02 Mar '12

On Friday, March 2, 2012 6:37:56 PM UTC+1, Michael Aye wrote: > > > > On Friday, March 2, 2012 6:12:24 PM UTC+1, Michael Aye wrote: >> >> In [48]: import skimage. >> skimage._osp skimage.util skimage.version >> >> In [48]: import skimage. >> >> and: >> >> In [46]: from skimage import exposure >> >> --------------------------------------------------------------------------- >> ImportError Traceback (most recent call >> last) >> /Users/maye/Dropbox/src/pymars/<ipython-input-46-fda3143d69ce> in >> <module>() >> ----> 1 from skimage import exposure >> >> ImportError: cannot import name exposure >> >> In [47]: skimage.__version__ >> Out[47]: '0.6dev' >> >> What happened here? >> Please help. >> >> > Not the most orthodox and efficient method but I guess I required some > clean-up somewhere from my previous 0.5dev build. I removed my git clone > and started from scratch. Then the 0.6dev works fine. > > With unorthodox and low efficiency I described my solution of removing the whole clone. ;)

1 1

sub modules missing?
by Michael Aye 02 Mar '12

02 Mar '12

In [48]: import skimage. skimage._osp skimage.util skimage.version In [48]: import skimage. and: In [46]: from skimage import exposure --------------------------------------------------------------------------- ImportError Traceback (most recent call last) /Users/maye/Dropbox/src/pymars/<ipython-input-46-fda3143d69ce> in <module>() ----> 1 from skimage import exposure ImportError: cannot import name exposure In [47]: skimage.__version__ Out[47]: '0.6dev' What happened here? Please help. Best regards, Michael

1 1

Re: ANN: scikits-image v0.5
by Tony Yu 02 Mar '12

02 Mar '12

2012/3/2 Stéfan van der Walt <stefan(a)sun.ac.za> > On Fri, Mar 2, 2012 at 6:54 AM, Michael Aye <kmichael.aye(a)gmail.com> > wrote: > > Can it be that you accidentally GIT-ted version.py, a file that > presumably > > is being created automatically? Or is there a reason for GITting it? > > The file should be checked in, and has the following contents: > > > https://github.com/scikits-image/scikits-image/blob/master/skimage/version.… > > Note the "unbuilt-dev" designation. > > Stéfan > I'm also a bit curious about why `version.py` needs to be tracked. I imagine it's used somewhere to tell the user why something doesn't work, but maybe that could be accomplished some other way? The file is a bit annoying when adding changes and even more so when switching branches. (The make file behavior, I think, makes it a bit harder to switch branches since `git stash` won't restore `version.py`) -Tony

1 0

Re: ANN: scikits-image v0.5
by Michael Aye 02 Mar '12

02 Mar '12

Can it be that you accidentally GIT-ted version.py, a file that presumably is being created automatically? Or is there a reason for GITting it? Regards, Michael On Monday, February 27, 2012 6:16:40 AM UTC+1, Stefan van der Walt wrote: > > Announcement: scikits-image 0.5 > =============================== > > We're happy to announce the 0.5 release of scikits-image, our image > processing > toolbox for SciPy. > > For more information, please visit our website > > http://scikits-image.org > > New Features > ------------ > - Consistent intensity rescaling and improved range conversion. > - Random walker segmentation. > - Harris corner detection. > - Otsu thresholding. > - Block views, window views and montage. > - Plugin for Christoph Golke's "tifffile". > - Peak detection. > - Improved FreeImage wrappers and meta-data reading. > - 8-neighbor and background labelling. > > ... along with updates to the documentation and website, and a number of > bug > fixes. > > Contributors to this release > ---------------------------- > * Andreas Mueller > * Brian Holt > * Christoph Gohlke > * Emmanuelle Gouillart > * Michael Aye > * Nelle Varoquaux > * Nicolas Pinto > * Nicolas Poilvert > * Pieter Holtzhausen > * Stefan van der Walt > * Tony S Yu > * Warren Weckesser > * Zachary Pincus > >

2 1

Re: RFC: Multiple backends + speedy looping
by Stéfan van der Walt 29 Feb '12

29 Feb '12

Hi Nadav On Wed, Feb 29, 2012 at 9:36 PM, Nadav Horesh <nadavh.horesh(a)gmail.com> wrote: > I am working on a simple frame work as a replacement for > ndimage.genereic_filter and numeric's neighbourhood iterator (I hope it > would be faster and easier to use). The goal of this PR is to support any backend (including, possibly, the one you are writing). I'd like to provide multiple implementations of some commonly used functions (convolution, e.g.), so that we can have a performance based series of fallbacks, such as GPU -> Cython -> Python. That way, algorithms can be run on any system, but will execute most rapidly on those supporting, say, OpenCL. Another advantage is that if, in the future, we write an even faster implementation, the benefit is immediately available to the user, without rewriting any code. Stéfan

1 0

Re: RFC: Multiple backends + speedy looping
by Nadav Horesh 29 Feb '12

29 Feb '12

I am working on a simple frame work as a replacement for ndimage.genereic_filter and numeric's neighbourhood iterator (I hope it would be faster and easier to use). Do you plan that the backend engine would fill this purpose? Nadav. בתאריך 1 במרץ 2012 01:13, מאת Stéfan van der Walt <stefan(a)sun.ac.za>: > Hello everyone, > > After the skimage 0.5 release, it's time to start planning the Next > Big Thing (TM). I hoped there would be a better solution by now, but > it seems that one of our main weak points is still that we cannot do > fast looping over images (e.g., filtering). > > We have multiple computing back-end support available as a pull > request from Pieter Holtzhausen's GSOC--the code is fairly simple to > understand, and doesn't complicate the framework more than necessary. > This will allow us to, when doing convolutions e.g., first try doing > it via OpenCL, and then to fall back to the CPU. We also have a full > testing framework in place, so that the output from different > back-ends are compared. > > Have a look at the code here: > > https://github.com/scikits-image/scikits-image/pull/14/files > > If you have a better solution or other alternatives in mind, please > let me know; I'm keen to explore this space further. > > Regards > Stéfan >

1 0