Mailman 3 December 2011 - scikit-image

12 bits tif image issue with skimage 0.5dev
by jip 10 Dec '11

10 Dec '11

Dear all, I update skimage to 0.5 dev on my ubuntu box. ipython startup gives: Imported NumPy 1.3.0, SciPy 0.7.2, Matplotlib 0.99.3 + guidata 1.2.5, guiqwt 2.0.8.1 Type "scientific" for more details. >>> import skimage >>> skimage.version <module 'skimage.version' from '/usr/local/lib/python2.6/dist-packages/scikits_image-0.5dev-py2.6-linux-i686.egg/skimage/version.pyc'> A 12 bits tif image when loaded with skimage do not behave like the same image loaded with an other library (readmagick, mahotas), as shown above. When a 8 bits png image is loaded, the differences (orientation, saturation) vanish. In a previous message Neil Yager said that the issue was fixed<https://groups.google.com/forum/#%21topic/scikits-image/JSvqMzOgTEE>. What should I do to fix the problem on my machine? Thank you. Jean-Patrick

2 2

Re: New module for thresholding
by Stéfan van der Walt 09 Dec '11

09 Dec '11

On Fri, Dec 9, 2011 at 12:42 PM, Tony Yu <tsyu80(a)gmail.com> wrote: > It doesn't really make sense to add a separate thresholding module, so where > should I put this thresholding function? Another place it could fit is in the filter sub-module, since it is just a per-pixel operation. You also mentioned histogram equalisation, but that we may want to put in an "exposure" module, along with things like dynamic range imaging etc. Stéfan

1 0

New module for thresholding
by Tony Yu 09 Dec '11

09 Dec '11

This came up in a pull request to add thresholding<https://github.com/scikits-image/scikits-image/pull/98>to skimage, but I thought it'd be good to move the discussion to the mailing list. It doesn't really make sense to add a separate thresholding module, so where should I put this thresholding function? My proposal is to add a "levels" module and put thresholding there. Then, for example, we could add some functions to adjust contrast/brightness/gamma. Someone suggested a histogram equalization function, which would also fit in a levels module. On the other hand, "levels" is often used by photo-editing programs to denote a specific tool for adjusting color/intensity levels. Thoughts/ideas? -Tony

1 0

Re: Feature requests for 0.5
by Thouis Jones 09 Dec '11

09 Dec '11

2011/12/9 Stéfan van der Walt <stefan(a)sun.ac.za>: > We'll probably borrow heavily from cpmath where we can. Since you > have a lot of experience with this stuff, your feedback is appreciated > (because, in the end, it would be great if you guys could actually use > these tools!). That's certainly our hope, as well. We'd like to be able to trim down CP as well as take advantage of a more widely deployed and therefore (hopefully) better-tested codebase. While we're on the subject of measuring objects... You might consider supporting overlapping segmentations, using an ijk (ij=position, k=label) scheme. This has started to become necessary for many of our experiments, and we're starting down the road of making all the feature measurements compatible with this labeling scheme. This is the sort of thing to add earlier rather than later, though I think Lee has some code to wrap a feature measurement function in the non-overlapping style to make it ijk-compatible (by looping over noninteracting sets of labels in the ijk matrix). Ray

1 0

Re: Feature requests for 0.5
by Stéfan van der Walt 09 Dec '11

09 Dec '11

On Thu, Dec 8, 2011 at 2:17 AM, Thouis Jones <thouis.jones(a)curie.fr> wrote: > From the bio corner of the world, I would suggest nearly everything here: > http://murphylab.cbi.cmu.edu/services/SLF/ Thanks, Ray. For my own future reference, here's the actual list: http://murphylab.web.cmu.edu/services/SLF/features.html Luckily, many of these are easy to compute once the object has been isolated (a one or two-liner) in NumPy. So we just have to define a standard API to calculate features, something like: feature(values, positions) Around that, we can then build an additional layer that handles them per labeled object, e.g. each(feature, labeled_image) We'll probably borrow heavily from cpmath where we can. Since you have a lot of experience with this stuff, your feedback is appreciated (because, in the end, it would be great if you guys could actually use these tools!). Cheers Stéfan

1 0

Re: Feature requests for 0.5
by Emmanuelle Gouillart 09 Dec '11

09 Dec '11

On Thu, Dec 08, 2011 at 01:31:46AM -0800, StÃ¯Â¿Â½fan van der Walt wrote: > On Wed, Dec 7, 2011 at 9:10 PM, Emmanuelle Gouillart > <emmanuelle.gouillart(a)nsup.org> wrote: > > Regarding graph-cut segmentation, it's not exactly graph-cut, but I have > > some code (purely Python) implementing the random walker segmentation > > algorithm > > (http://cns.bu.edu/~lgrady/Random_Walker_Image_Segmentation.html). It's a > > very nice algorithm that overcomes some of the limitations of the > > watershed, and it can label more than two phases. So I could clean up > > this code a bit for skimage, I guess this could be my contribution to 0.5 > Thanks for the link; I haven't seen this method before. Does it > vectorize fairly well? The implementation that I use is based on solving a large sparse linear system, so there is no for loop or anything like this. Does this answer your question? > I wonder, if we start doing seeded segmentation, whether it might be > worth building a Qt or Matplotlib GUI along with it. I have other uses > for a "Paint" component too, such as modifying the FFT spectrum and > watching the changes in place (wouldn't FFT painting be fun? :). I've got mixed feelings about this. Having some interactive GUIs for adjusting parameters like for thresholding, or Canny filtering, would be great and save a lot of time. Sometimes I get quite frustrated when typing several commands in Ipython to test different parameters, whereas the algorithm is actually fast enough so that I could just move a handle and see the result. I asked Eric Jones during Scipy India if he could make a small example using traitsUI for interactive thresholding. The question is: should these interfaces go in skimage or elsewhere? If yes, we would have to make sure that this does not introduce additional dependencies (only optional ones). I think it's very important that skimage stays a toolkit, and a package that it is easy to depend on for other projects. Cheers, Emmanuelle

2 1

Re: scikits-image 0.4 release
by Stéfan van der Walt 09 Dec '11

09 Dec '11

On Thu, Dec 8, 2011 at 5:43 AM, Michael Aye <kmichael.aye(a)gmail.com> wrote: >> >> Please visit our examples gallery to see what we've been up to: >> >> http://scikits-image.org/docs/0.3/auto_examples/ >> > This should be http://scikits-image.org/docs/0.4/auto_examples/ > ,right? Ouch, well, that's embarrassing! I've sent updates to the scipy list. Thanks! Stéfan

1 0

Re: scikits-image 0.4 release
by Michael Aye 08 Dec '11

08 Dec '11

> > Please visit our examples gallery to see what we've been up to: > > http://scikits-image.org/docs/0.3/auto_examples/ > This should be http://scikits-image.org/docs/0.4/auto_examples/ ,right? Michael

1 0

Re: Feature requests for 0.5
by Thouis Jones 08 Dec '11

08 Dec '11

2011/12/8 Stéfan van der Walt <stefan(a)sun.ac.za>: > As for the different measures, I think we could benefit from having > some of those grouped together. Things like getting the area (after > labelling is trivial), but computing circularity etc. can get more > interesting. Do you know of a good list of such desired measurements? > Maybe also have a look at the MATLAB docs online to see what they > provide as a point of reference. >From the bio corner of the world, I would suggest nearly everything here: http://murphylab.cbi.cmu.edu/services/SLF/ Specific papers: http://murphylab.web.cmu.edu/publications/81-boland2001.pdf http://murphylab.web.cmu.edu/publications/87-murphy2002.pdf http://murphylab.cbi.cmu.edu/services/SLF/ Also see the table at the end of: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.33.9697 These are all for cells, but many of the features are generally useful, I think. Ray

1 0

Re: Feature requests for 0.5
by Emmanuelle Gouillart 08 Dec '11

08 Dec '11

> - An expansion of the user guide > - Completion of the Debian packaging > - Object convex hulls and > - Graph cut segmentation and/or tri-mapping Regarding graph-cut segmentation, it's not exactly graph-cut, but I have some code (purely Python) implementing the random walker segmentation algorithm (http://cns.bu.edu/~lgrady/Random_Walker_Image_Segmentation.html). It's a very nice algorithm that overcomes some of the limitations of the watershed, and it can label more than two phases. So I could clean up this code a bit for skimage, I guess this could be my contribution to 0.5 Emmanuelle

2 1