Mailman 3 December 2011 - scikit-image

Re: skeletonize question
by Stéfan van der Walt 13 Dec '11

13 Dec '11

On Mon, Dec 12, 2011 at 5:13 PM, Tony Yu <tsyu80(a)gmail.com> wrote: > > Strange: when I open "circles.png" using the matplotlib backend, I get a > float32 array (with the white pixels equal to 0.00392157). With the PIL > backend, I get a bool array (before your recent bug fix) or uint8 (after the > fix). Are you not having the same issue with matplotlib? While the bool type is fine (it's a black and white image), the pixel order was completely messed up; try to display it! In mpl, I see the same thing you do. It is because matplotlib assumes that all images with depth < 8 is 8-bit, and therefore returns 1/255 instead of 1. Filed here: https://github.com/matplotlib/matplotlib/pull/623 Cheers Stéfan

1 0

Re: io plugin issue (8bits 16bits)
by jip 13 Dec '11

13 Dec '11

Hi, I compared skimage.io on an other ubuntu box (10.10), with readmagick//mahotas for 8 bits and 12 bits images. The script and the image are joined. As you can see, displaying a 16 bits image yield a saturated image and the orientation is mirrored. When a 8 bit png image is loaded the three libs (sio, readmagick mahotas), no difference can be seen. Should I use a github version to fix that issue? Thanks JP

2 1

Re: skeletonize question
by Tony Yu 13 Dec '11

13 Dec '11

2011/12/12 Stéfan van der Walt <stefan(a)sun.ac.za> > Hi TJ > > On Mon, Dec 12, 2011 at 2:27 PM, karoyakani <tj.takei(a)gmail.com> wrote: > > I'm new to this mailing list. > > Welcome! We're glad to have you. > > > skimage version 0.4.2 has morphology.skeletonize() that works almost > > as good as Matlab bwmorph('thin'). > > We'd certainly love to remedy that... > > > However the output seems transposed when I tested a Matlab's example > > image 'circles.png': > > http://www.mathworks.com/help/toolbox/images/ref/bwmorph.html > > Is this a bug? > > In order to reproduce this bug, I've put a repo online with your code: > > https://github.com/stefanv/skimage_circles > > Here is the output I get: > > http://mentat.za.net/refer/skeletonize_compare.png > > (Before running the experiment, run fetch_data to download the matlab > test image; or just grab it by hand from their website. I don't know > what the license is, so I didn't want to put it in the repo directly.) > > I am glad you showed me this example, because it also pointed out a > problem with paletted image reading in PIL. I'm seriously considering > just making matplotlib our default backend (except that they also have > a PNG reading bug in older versions where images are flipped upside > down!). > > Regards > Stéfan Strange: when I open "circles.png" using the matplotlib backend, I get a float32 array (with the white pixels equal to 0.00392157). With the PIL backend, I get a bool array (before your recent bug fix) or uint8 (after the fix). Are you not having the same issue with matplotlib? -Tony

1 0

skeletonize question
by karoyakani 13 Dec '11

13 Dec '11

Hi, I'm new to this mailing list. skimage version 0.4.2 has morphology.skeletonize() that works almost as good as Matlab bwmorph('thin'). However the output seems transposed when I tested a Matlab's example image 'circles.png': http://www.mathworks.com/help/toolbox/images/ref/bwmorph.html Is this a bug? ######## import numpy as np from scipy import ndimage from scipy.io import loadmat from skimage.morphology import skeletonize import matplotlib.pyplot as plt # test image from Matlab bwmorph('skel') demo bw = loadmat('circles.mat')['BW'] sk = skeletonize(bw) plt.figure() plt.imshow(bw+sk.transpose(), cmap=plt.cm.gray, interpolation='nearest') plt.show() ######## Thanks, - TJ

2 1

Re: Measure and graph subpackages
by Stéfan van der Walt 11 Dec '11

11 Dec '11

On Dec 11, 2011 10:26 AM, "Tony Yu" <tsyu80(a)gmail.com> wrote: > > On Sun, Dec 11, 2011 at 12:46 PM, Zachary Pincus <zachary.pincus(a)yale.edu> wrote: >> >> Stéfan may be able to amplify, but IIRC he has some other code to put into measure that should more clearly differentiate the two sub-modules. Right now it's correct that both the content in 'measure' (marching-squares contour-finding) and in 'graph' (Dijkstra's algorithm on a lattice) are both about tracing paths through pixel arrays, albeit in very different contexts. So it might not be bad to re-organize. >> >> But contour-finding is not a graph operation, so such a re-org should be more than putting that code in the 'graph' package. > > Oh, I meant the other way around: getting the minimum-cost path seems like something you measure in an image. (Sort of.) That was under the assumption that nothing else was planned for the graph package. I was thinking of putting things like graph cuts in there, but placing an emphasis on the way a function is implemented rather than what it does may be the wrong approach. E.g., we don't put image filters in the Fourier submodule. What can go in there is maybe graph handling utilities for other functions. So, where would a good home for shortest path be? We'll keep a link to the original location for backward compatibility too. Cheers Stéfan

1 0

Re: Measure and graph subpackages
by Zachary Pincus 11 Dec '11

11 Dec '11

Stéfan may be able to amplify, but IIRC he has some other code to put into measure that should more clearly differentiate the two sub-modules. Right now it's correct that both the content in 'measure' (marching-squares contour-finding) and in 'graph' (Dijkstra's algorithm on a lattice) are both about tracing paths through pixel arrays, albeit in very different contexts. So it might not be bad to re-organize. But contour-finding is not a graph operation, so such a re-org should be more than putting that code in the 'graph' package. Zach On Dec 11, 2011, at 11:13 AM, Tony Yu wrote: > I don't know anything about graph theory, but from my (naive) perspective, it seems that the graph subpackage should be part of the measure subpackage. Is this correct? > > -Tony

2 1

Measure and graph subpackages
by Tony Yu 11 Dec '11

11 Dec '11

I don't know anything about graph theory, but from my (naive) perspective, it seems that the graph subpackage should be part of the measure subpackage. Is this correct? -Tony

1 0

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

10 Dec '11

On Fri, Dec 9, 2011 at 2:24 AM, Thouis Jones <thouis.jones(a)curie.fr> wrote: > While we're on the subject of measuring objects... > > You might consider supporting overlapping segmentations, using an ijk > (ij=position, k=label) scheme. Thanks, that's exactly the kind of design input we need. Stéfan

1 0

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

10 Dec '11

On Fri, Dec 9, 2011 at 3:04 PM, Tony Yu <tsyu80(a)gmail.com> wrote: > Putting thresholding in filter is a little strange to me (for some reason). > But if there's no other suggestions, I'm fine with it. It's not perfect... any other suggestions anyone?

1 0

Re: New module for thresholding
by Tony Yu 10 Dec '11

10 Dec '11

2011/12/9 Stéfan van der Walt <stefan(a)sun.ac.za> > 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 > I like the idea of an "exposure" module, and it definitely has a clear meaning, unlike "levels". Putting thresholding in filter is a little strange to me (for some reason). But if there's no other suggestions, I'm fine with it. -Tony

1 0