Mailman 3 December 2013 - scikit-image

Re: Better results with Canny/Hough for circular particles
by Dan Farmer Dec. 13, 2013

Dec. 13, 2013

Hi Adam, This can be the worst part of image processing, but I'm curious how much you played with the parameters to Canny? You probably know this, but canny already tries to close gaps (hysteresis thresholding). What you want to do is try to lower the low_threshold parameter (values above the high threshold value get initially labeled as edges, then it looks for pixels that are connected to edge pixels and whose value is > low_threshold to link the edges). An easy/basic way to get rid of small fragments would be to start with morphological erosion. -Dan On Fri, Dec 13, 2013 at 11:47 AM, Adam Hughes <hughesadam87(a)gmail.com> wrote: > Hi, > > I have several images of circular particles (see attached for an example) > and I've been experimenting with automatic routines to find edges. > > I've found that with Canny, I can get really nice edges, but the edges are > not always connected. Thus, when I do fill-binary, many of my particles are > not painted in due to slight breaks in the border returned by canny. Is > there an ideal way to fix this, either by connecting "almost" connected > canny edges? Additionally, what is the best way to filter out small > fragments and/or non-circular edges? > > I've attached an image of the canny outlines; you can see that I obviously > want to get rid some of the regions that aren't associated with any > particles. PS, the coloring of the outlines are based on the brightness of > the image at that point underneath it, which has been hidden. (Would be > happy to share the function if anyone wants it). > > Lastly, I tried adapting the circular hough transform example: > > http://scikit-image.org/docs/dev/auto_examples/plot_circular_elliptical_hou… > > But struggled with setting it up, due to a naive understanding of the > algorithm. Given that my image has thousands of particles, but I know > roughly the size distribution, would the circular hough transform be useful > to me? > > Thanks > > > -- > You received this message because you are subscribed to the Google Groups > "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to scikit-image+unsubscribe(a)googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out.

1 0

Better results with Canny/Hough for circular particles
by Adam Hughes Dec. 13, 2013

Dec. 13, 2013

Hi, I have several images of circular particles (see attached for an example) and I've been experimenting with automatic routines to find edges. I've found that with Canny, I can get really nice edges, but the edges are not always connected. Thus, when I do fill-binary, many of my particles are not painted in due to slight breaks in the border returned by canny. Is there an ideal way to fix this, either by connecting "almost" connected canny edges? Additionally, what is the best way to filter out small fragments and/or non-circular edges? I've attached an image of the canny outlines; you can see that I obviously want to get rid some of the regions that aren't associated with any particles. PS, the coloring of the outlines are based on the brightness of the image at that point underneath it, which has been hidden. (Would be happy to share the function if anyone wants it). Lastly, I tried adapting the circular hough transform example: http://scikit-image.org/docs/dev/auto_examples/plot_circular_elliptical_hou… But struggled with setting it up, due to a naive understanding of the algorithm. Given that my image has thousands of particles, but I know roughly the size distribution, would the circular hough transform be useful to me? Thanks

1 0

Re: Pattern drawing library ideas
by Adam Hughes Dec. 9, 2013

Dec. 9, 2013

Thanks for the advice guys! Josh, that makes sense, thanks. I will implement that suggestion, and thanks for explaining rr and cc. Stefan, thanks! I will still share some example notebooks down the road, but keep the library separate from skimage. If there are any new particle types that might make sense to be added to skimage.draw, then i'd be happy to share at that time. On Friday, December 6, 2013 7:07:57 PM UTC-5, Adam Hughes wrote: > > Hi everyone, > > My colleague Evelyn and I have been using scikit image's draw utilities to > generate test data for modeling particle distributions on optical fibers > (ie the SEM images I sent a few weeks ago). We are doing this to test some > new models for nanoparticle cluster fitting that we've developed. > > In working on this, we believe we've come up with a general framework for > drawing 2D particle ensembles in skimage. One could envision using it to > do something like: > > Step 0: Generate a blank canvas of resolution 1024 x 768 > Step 1: Add circles of average radius 5 pixels until 30% of the image > is covered. > - Arrange these randomly vs. equally spaced on a grid > etc... > Step 2: Add an "cluster" of particles to this image. Paint only the > clusters red. > Step 3: Run an optimization that maximizes the inter-particle spacing. > Step 4: Make all the particles smaller than a certain area green. > Step 5: Try watershedding > etc... > > By generating the sample images in skimage, we wouldn't have to break out > of the python workflow to make our test data. > > We believe that we've come up with some abstractions that would allow for > such an toolset. This includes defining a abstract class for different > particle shapes, and then wrapping skimage.draw() functions as a class > method. Before we get invested in this, I had a few questions: > > 1. Is this something that, if executed well, would be of interest to > incorporate into scikit image? If so, I will start working on it as a > branch; otherwise, we'll just use skimage as a dependency. I'd image it > would either be a submodule of skimage.draw(), something like > skimage.draw.ensemble() or draw.psuedodata()... > > 2. Is anyone aware of a pre-existing tooset/library (preferrably in > Python) that's built for this? And if so, is that library compatible to > skimage? > > 3. When a user runs skimage.draw.circle(), it returns *rr* and *cc*, > what are these? Is cc the "chain code"? > > One caveat: our design plan is object oriented. We thought that the best > way to have an image with several particles would require a *Particle*class to add enough metadata to the returns of scikit.draw() so that > particles could indivually be tracked, isolated and manipulated. The > ensemble would be created on a *Canvas* class (better name? *TestImage*?), > which is responsible for storing an ensemble of Particles, as well as all > the drawing and organization of the ensemble. For example, a circle would > have attributes X, Y, R, which are then passed to a draw() method that > called skimage.circle(). In this way, one could track particle positions, > manipulate and redraw(). Would something like this clash with skimage's > basic design paradigms? If so we, maybe it would best to keep this toolkit > out of skimage. > > PS, is anyone else working on this, or interested? > > Thanks >

1 0

exposure.equalize_adapthist() problem
by Simon Filhol Dec. 9, 2013

Dec. 9, 2013

Hi, after reinstalling, updating the skimage package version 0.9.x , I cannot get the function equalize_adapthist() to work like the example on the scikit-image webpage. from skimage import exposure, data img = data.moon() img_adapteq = exposure.equalize_adapthist(img, clip_limit=0.03) the following error is returned in the console: >>> img_adapteq = exposure.equalize_adapthist(img, clip_limit=0.03) Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'module' object has no attribute 'equalize_adapthist' Would you have any insight into which problem I am running? Thanks

2 1

Re: match_template confidence > 3 ?
by Johannes Schönberger Dec. 9, 2013

Dec. 9, 2013

See https://github.com/scikit-image/scikit-image/pull/847. Can you please test if this fixes your issues? Am 08.12.2013 um 03:22 schrieb Stéfan van der Walt <stefan(a)sun.ac.za>: > On Sat, Dec 7, 2013 at 9:02 AM, Tony Yu <tsyu80(a)gmail.com> wrote: >> Unfortunately, I'm not sure what the problem is here. You're correct in >> thinking that values shouldn't be outside of [-1, 1], but as your code >> demonstrates, there are apparently inputs that break the current >> implementation. I've played around with isolating a small test image, but I >> haven't had much luck. > > I've filed an issue with a minimal code snippet here: > > https://github.com/scikit-image/scikit-image/issues/845 > > Stéfan > > -- > You received this message because you are subscribed to the Google Groups "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe(a)googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out.

1 0

Re: match_template confidence > 3 ?
by Stéfan van der Walt Dec. 8, 2013

Dec. 8, 2013

On Sat, Dec 7, 2013 at 9:02 AM, Tony Yu <tsyu80(a)gmail.com> wrote: > Unfortunately, I'm not sure what the problem is here. You're correct in > thinking that values shouldn't be outside of [-1, 1], but as your code > demonstrates, there are apparently inputs that break the current > implementation. I've played around with isolating a small test image, but I > haven't had much luck. I've filed an issue with a minimal code snippet here: https://github.com/scikit-image/scikit-image/issues/845 Stéfan

1 0

Re: Pattern drawing library ideas
by Stéfan van der Walt Dec. 8, 2013

Dec. 8, 2013

Hi, Adam On Sat, Dec 7, 2013 at 2:07 AM, Adam Hughes <hughesadam87(a)gmail.com> wrote: > 1. Is this something that, if executed well, would be of interest to > incorporate into scikit image? If so, I will start working on it as a > branch; otherwise, we'll just use skimage as a dependency. I'd image it > would either be a submodule of skimage.draw(), something like > skimage.draw.ensemble() or draw.psuedodata()... > > 2. Is anyone aware of a pre-existing tooset/library (preferrably in Python) > that's built for this? And if so, is that library compatible to skimage? What you are building reminds me a bit of a scenegraph. You are probably better off using a library like Matplotlib for rendering anything remotely involved. In `skimage` we provide a very basic drawing API with the explicit goal of manipulating images (arrays) directly, but it is not meant as an advanced canvas. I reckon that you will develop some low-level primitives as you go along, and those would fit well into `skimage.draw`. Regards Stéfan

1 0

Re: Pattern drawing library ideas
by Josh Warner Dec. 8, 2013

Dec. 8, 2013

Hi Adam, I'll briefly answer question #3: `rr` and `cc` from `skimage.draw.circle()` correspond to indices of image pixels within the circle. They are meant to be used to do something to all values in that circle, e.g. set all values in that circle to one with `im[rr, cc] = 1`. I don't know of anyone else doing what you propose. We do strive for functional interfaces *where possible*, but what you describe certainly appears suited to an object-oriented framework. Given my above answer I think you want to track and monitor your *Particle*s *prior* to calling `skimage.draw`. The tweak I would make is not to draw anything at all until an output is requested, then batch up all of the circles/objects and have them drawn at that time. Before that point every *Particle* would exist in a much more compact state, probably just center coordinates and radius, and this will be both better and more precise to deal with when repositioning or otherwise tweaking things. Regards, Josh On Friday, December 6, 2013 6:07:57 PM UTC-6, Adam Hughes wrote: > > Hi everyone, > > My colleague Evelyn and I have been using scikit image's draw utilities to > generate test data for modeling particle distributions on optical fibers > (ie the SEM images I sent a few weeks ago). We are doing this to test some > new models for nanoparticle cluster fitting that we've developed. > > In working on this, we believe we've come up with a general framework for > drawing 2D particle ensembles in skimage. One could envision using it to > do something like: > > Step 0: Generate a blank canvas of resolution 1024 x 768 > Step 1: Add circles of average radius 5 pixels until 30% of the image > is covered. > - Arrange these randomly vs. equally spaced on a grid > etc... > Step 2: Add an "cluster" of particles to this image. Paint only the > clusters red. > Step 3: Run an optimization that maximizes the inter-particle spacing. > Step 4: Make all the particles smaller than a certain area green. > Step 5: Try watershedding > etc... > > By generating the sample images in skimage, we wouldn't have to break out > of the python workflow to make our test data. > > We believe that we've come up with some abstractions that would allow for > such an toolset. This includes defining a abstract class for different > particle shapes, and then wrapping skimage.draw() functions as a class > method. Before we get invested in this, I had a few questions: > > 1. Is this something that, if executed well, would be of interest to > incorporate into scikit image? If so, I will start working on it as a > branch; otherwise, we'll just use skimage as a dependency. I'd image it > would either be a submodule of skimage.draw(), something like > skimage.draw.ensemble() or draw.psuedodata()... > > 2. Is anyone aware of a pre-existing tooset/library (preferrably in > Python) that's built for this? And if so, is that library compatible to > skimage? > > 3. When a user runs skimage.draw.circle(), it returns *rr* and *cc*, > what are these? Is cc the "chain code"? > > One caveat: our design plan is object oriented. We thought that the best > way to have an image with several particles would require a *Particle*class to add enough metadata to the returns of scikit.draw() so that > particles could indivually be tracked, isolated and manipulated. The > ensemble would be created on a *Canvas* class (better name? *TestImage*?), > which is responsible for storing an ensemble of Particles, as well as all > the drawing and organization of the ensemble. For example, a circle would > have attributes X, Y, R, which are then passed to a draw() method that > called skimage.circle(). In this way, one could track particle positions, > manipulate and redraw(). Would something like this clash with skimage's > basic design paradigms? If so we, maybe it would best to keep this toolkit > out of skimage. > > PS, is anyone else working on this, or interested? > > Thanks >

1 0

match_template confidence > 3 ?
by Jon Schull Dec. 7, 2013

Dec. 7, 2013

Greetings, we're using SciKit template_matching and getting confidence values > 3. Does that make sense? A simple example with test images is attached. Thanks for the fine work! import numpy, sys from skimage import data from skimage import io from skimage.feature import match_template def containsLikelyhood(needleLoc, haystackLoc): haystack = data.imread(haystackLoc, as_grey=True) needle = data.imread(needleLoc, as_grey=True) greyLoc = match_template(haystack, needle) ij = numpy.unravel_index(numpy.argmax(greyLoc), greyLoc.shape) x, y = ij[::-1] height, width = needle.shape return greyLoc[y][x], (x, y, width, height) if __name__ == "__main__": print containsLikelyhood("locatedStar.PNG", "screenshot.PNG")

2 1

Pattern drawing library ideas
by Adam Hughes Dec. 7, 2013

Dec. 7, 2013

Hi everyone, My colleague Evelyn and I have been using scikit image's draw utilities to generate test data for modeling particle distributions on optical fibers (ie the SEM images I sent a few weeks ago). We are doing this to test some new models for nanoparticle cluster fitting that we've developed. In working on this, we believe we've come up with a general framework for drawing 2D particle ensembles in skimage. One could envision using it to do something like: Step 0: Generate a blank canvas of resolution 1024 x 768 Step 1: Add circles of average radius 5 pixels until 30% of the image is covered. - Arrange these randomly vs. equally spaced on a grid etc... Step 2: Add an "cluster" of particles to this image. Paint only the clusters red. Step 3: Run an optimization that maximizes the inter-particle spacing. Step 4: Make all the particles smaller than a certain area green. Step 5: Try watershedding etc... By generating the sample images in skimage, we wouldn't have to break out of the python workflow to make our test data. We believe that we've come up with some abstractions that would allow for such an toolset. This includes defining a abstract class for different particle shapes, and then wrapping skimage.draw() functions as a class method. Before we get invested in this, I had a few questions: 1. Is this something that, if executed well, would be of interest to incorporate into scikit image? If so, I will start working on it as a branch; otherwise, we'll just use skimage as a dependency. I'd image it would either be a submodule of skimage.draw(), something like skimage.draw.ensemble() or draw.psuedodata()... 2. Is anyone aware of a pre-existing tooset/library (preferrably in Python) that's built for this? And if so, is that library compatible to skimage? 3. When a user runs skimage.draw.circle(), it returns *rr* and *cc*, what are these? Is cc the "chain code"? One caveat: our design plan is object oriented. We thought that the best way to have an image with several particles would require a *Particle*class to add enough metadata to the returns of scikit.draw() so that particles could indivually be tracked, isolated and manipulated. The ensemble would be created on a *Canvas* class (better name? *TestImage*?), which is responsible for storing an ensemble of Particles, as well as all the drawing and organization of the ensemble. For example, a circle would have attributes X, Y, R, which are then passed to a draw() method that called skimage.circle(). In this way, one could track particle positions, manipulate and redraw(). Would something like this clash with skimage's basic design paradigms? If so we, maybe it would best to keep this toolkit out of skimage. PS, is anyone else working on this, or interested? Thanks

1 0

Re: Problem with Transform.SimilarityTransform
by Jean K Dec. 6, 2013

Dec. 6, 2013

Great, thanks! On Wednesday, 4 December 2013 15:54:39 UTC, Johannes Schönberger wrote: > > The implementation of the null space solver and especially the > normalization is indeed not suitable for this special case. I'll quickly > fix it in the coming days... > > Am 04.12.2013 um 13:16 schrieb "Jean K" <jean.k...(a)gmail.com <javascript:> > >: > > Hi everyone, > > I'm currently trying to use skleanr.Transform.SimilarityTransform to > remove scaling translation and rotation from one set of points to align it > to the other. > However, if I centre the sets around the origin first, there seems to be > frequently a problem (which doesn't occur if the points are all positives), > the output being NaN. > > I tried to write a small reproducible code: > In [77]: > > #I fixed the seed here for reproducibility but this happens often > > np.random.seed(4) > > > > #Two random set of points > > a = np.random.randn(10, 2) > > b = np.random.randn(10, 2) > > > > # Center the points arount the origin > > a -= np.mean(a, axis=0)[np.newaxis, :] > > b -= np.mean(b, axis=0)[np.newaxis, :] > > > > tform = SimilarityTransform() > > tform.estimate(a, b) > > tform(a) > > Out[77]: > > array([[ nan, nan], > [ nan, nan], > [ nan, nan], > [ nan, nan], > [ nan, nan], > [ nan, nan], > [ nan, nan], > [ nan, nan], > [ nan, nan], > [ nan, nan]]) > > > Note that if I don't centre the point there is no problem: > > In [89]: > > #I fixed the seed here for reproducibility but this happens often > > np.random.seed(4) > > > > #Two random set of points > > a = np.random.randn(10, 2) > > b = np.random.randn(10, 2) > > > > # Center the points arount the origin > > #a -= np.mean(a, axis=0)[np.newaxis, :] > > #b -= np.mean(b, axis=0)[np.newaxis, :] > > > > tform = SimilarityTransform() > > tform.estimate(a, b) > > tform(a) > > Out[89]: > > array([[ 3.76870886, -0.35152078], > [ 1.83453334, -1.25080725], > [ 5.42428044, -4.30088121], > [ 2.51364241, -1.00154154], > [ 6.14244682, -2.71511189], > [ 5.37956586, -0.65190768], > [ 4.5752074 , -0.19039746], > [ 1.96968262, -1.99729896], > [ 1.47865106, 0.59493455], > [ 5.39473376, -0.31125435]]) > > > Sometime it also tells me that the *SVD doesn't converge*. > > Any idea what is going on? > > > Thanks, > > > Jean > > -- > You received this message because you are subscribed to the Google Groups > "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to scikit-image...(a)googlegroups.com <javascript:>. > For more options, visit https://groups.google.com/groups/opt_out. > >

1 0

img_as_float is confounding me
by Scott Classen Dec. 5, 2013

Dec. 5, 2013

I have four 2D numpy arrays. 100x100, 200x200, 300x300, 400x400 I want to use pyramid_reduce on the 200x200, 300x300, and 400x400 arrays to downsample them to 100x100 arrays, then add them all together. The arrays are in a list and I'm looping through the list (looping code left out for clarity) calculating binned images for each one: g.binned = img_as_float(g.cropped)# no reducing here, just converting to scikit compatable float…I hope. g.binned = pyramid_reduce(img_as_float(g.cropped), downscale=2) g.binned = pyramid_reduce(img_as_float(g.cropped), downscale=3) g.binned = pyramid_reduce(img_as_float(g.cropped), downscale=4) The g.cropped input arrays originated from numpy arrays with dtype=float64 I then print some useful information about my 4 arrays: array data type: float64 shape: (100, 100) nanmax: 777.0 array data type: float64 shape: (100, 100) nanmax: 1.0 array data type: float64 shape: (100, 100) nanmax: 1.0 array data type: float64 shape: (100, 100) nanmax: 1.0 I'm curious why the g.binned array from g.binned = img_as_float(g.cropped)has not been scaled to 0,1? The others which have been through the pyramid_reduce function have apparently been scaled, but maybe not by the img_as_float routine, but by pyramid_reduce? I then add the arrays tmp_image = list[0].binned + list[1].binned + list[2].binned + list[3].binned However, because the first array has not been properly scaled to 0,1 I get an error when I run the tmp_image through img_as_uint so I can write out my binary image file: Traceback (most recent call last): File "./test.py", line 318, in <module> image_to_write = img_as_uint(tmp_image) File "/sw/lib/python2.7/site-packages/skimage/util/dtype.py", line 310, in img_as_uint return convert(image, np.uint16, force_copy) File "/sw/lib/python2.7/site-packages/skimage/util/dtype.py", line 191, in convert raise ValueError("Images of type float must be between -1 and 1.") ValueError: Images of type float must be between -1 and 1. Any advice would be most appreciated.

3 2

Fwd: Ureka 1.0 is now available
by James Turner Dec. 4, 2013

Dec. 4, 2013

Hi everyone, I thought you might be interested to know that Scikit-image 0.9.3 is now included in Ureka, our distribution of Python and IRAF software for astronomy, which has just come out of beta today. Ureka is rather astronomy-orientated (including some "legacy" stuff) so won't be everyone's installation method of choice, but the rest of you might at least like to know where your work is ending up :-). While I'm at it, you might be interested to keep an eye on AstroPy (http://www.astropy.org/), which has been developing rapidly and recently came out with a v0.3 release; it certainly has some room for overlap with Scikit-image. Cheers, James. -------- Original Message -------- Subject: [AstroPy] Ureka 1.0 is now available Date: Wed, 4 Dec 2013 18:13:33 +0000 From: Christine Slocum <cslocum(a)stsci.edu> To: AstroPy(a)scipy.org <AstroPy(a)scipy.org> STScI and Gemini are announcing the release of Ureka 1.0. Improvements (with respect to beta 6): - test for completeness of OS library dependencies - many installation improvements - expanded documentation - support for Ubuntu 13.10, Fedora 19, and OS X Mavericks (10.9) - menu shortcuts on Linux - optional support for MySQL and PostgreSQL - bundled Fortran run-time library is always used to avoid conflict with OS version(s) Updated packages: - Gemini IRAF 1.12 - virtualenv (1.10.1) - SciPy (0.13.0) - wheel (0.22.0) - scikit-image (0.9.3) - Pillow (2.2.1) - CFITSIO (3350) - scikit-learn (0.14.1) - Tornado (3.1.1) - setuptools (1.3) - NumPy (1.8.0) - stsci.distutils (0.3.2) - astropy (0.3) - d2to1 (0.2.11) - PyParsing (2.0.1) New packages: - PyKE (2.4.0) - Six (1.4.1) - PyTZ (2013.8) - kapteyn (2.2.1b17) - BeautifulSoup (3.2.1) - mechanize (0.2.5) - jsonschema (2.1.0) - numexpr (2.2.2) - Dateutil (2.2) - mock (1.0.1) Ureka is a binary packaging installer for common astronomical software (primarily for the UV/Optical/IR community). The goals of the Ureka installer are to: 1) minimize the number of actions needed to install all the different software components. We are seeking a "one button install" (it's not quite one button, but not far from it). 2) permit installation without requiring system privileges. 3) make installs as problem-free as possible for the great majority of users. 4) allow users to install their own software (particularly Python-based) within this framework, or update versions of software within the framework. 5) permit different Ureka installations to coexist and to easily switch between them. 6) enable installing different versions of the same software package under a particular Ureka installation. 7) support Macs and most popular Linux variants. Ureka does not use LD_LIBRARY_PATH (or its Mac equivalent), nor require PYTHONPATH, minimizing the possibility of affecting existing software after installation or use. Should conflicts nevertheless arise, Ureka can easily be disabled temporarily or enabled only in specific terminal windows. Keep in mind that no installation system is completely foolproof (that's very nearly impossible to achieve). In particular, when users update or add software to the Ureka framework, they increase the risk of breaking something, but we feel that is an option that users should have as long as they understand the possible risks. This release includes IRAF 2.16 and associated packages for IRAF, DS9, and a fairly full suite of Python scientific software packages (e.g., numpy, scipy, and matplotlib). The full listing of included software can be found at this link: http://ssb.stsci.edu/ureka/1.0/docs/components.html Ureka can be downloaded from: http://ssb.stsci.edu/ureka/ (choose "1.0"). Installation and usage instructions can be found on the same web page. Please send questions or feedback to help(a)stsci.edu. _______________________________________________ AstroPy mailing list AstroPy(a)scipy.org http://mail.scipy.org/mailman/listinfo/astropy

1 0

Re: Problem with Transform.SimilarityTransform
by Johannes Schönberger Dec. 4, 2013

Dec. 4, 2013

The implementation of the null space solver and especially the normalization is indeed not suitable for this special case. I'll quickly fix it in the coming days... > Am 04.12.2013 um 13:16 schrieb "Jean K" <jean.kossaifi(a)gmail.com>: > > Hi everyone, > > I'm currently trying to use skleanr.Transform.SimilarityTransform to remove scaling translation and rotation from one set of points to align it to the other. > However, if I centre the sets around the origin first, there seems to be frequently a problem (which doesn't occur if the points are all positives), the output being NaN. > > I tried to write a small reproducible code: > In [77]: > > #I fixed the seed here for reproducibility but this happens often > np.random.seed(4) > > #Two random set of points > a = np.random.randn(10, 2) > b = np.random.randn(10, 2) > > # Center the points arount the origin > a -= np.mean(a, axis=0)[np.newaxis, :] > b -= np.mean(b, axis=0)[np.newaxis, :] > > tform = SimilarityTransform() > tform.estimate(a, b) > tform(a) > Out[77]: > array([[ nan, nan], > [ nan, nan], > [ nan, nan], > [ nan, nan], > [ nan, nan], > [ nan, nan], > [ nan, nan], > [ nan, nan], > [ nan, nan], > [ nan, nan]]) > > Note that if I don't centre the point there is no problem: > In [89]: > > #I fixed the seed here for reproducibility but this happens often > np.random.seed(4) > > #Two random set of points > a = np.random.randn(10, 2) > b = np.random.randn(10, 2) > > # Center the points arount the origin > #a -= np.mean(a, axis=0)[np.newaxis, :] > #b -= np.mean(b, axis=0)[np.newaxis, :] > > tform = SimilarityTransform() > tform.estimate(a, b) > tform(a) > Out[89]: > array([[ 3.76870886, -0.35152078], > [ 1.83453334, -1.25080725], > [ 5.42428044, -4.30088121], > [ 2.51364241, -1.00154154], > [ 6.14244682, -2.71511189], > [ 5.37956586, -0.65190768], > [ 4.5752074 , -0.19039746], > [ 1.96968262, -1.99729896], > [ 1.47865106, 0.59493455], > [ 5.39473376, -0.31125435]]) > > Sometime it also tells me that the SVD doesn't converge. > Any idea what is going on? > > Thanks, > > Jean > -- > You received this message because you are subscribed to the Google Groups "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe(a)googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out.

1 0

Problem with Transform.SimilarityTransform
by Jean K Dec. 4, 2013

Dec. 4, 2013

Hi everyone, I'm currently trying to use skleanr.Transform.SimilarityTransform to remove scaling translation and rotation from one set of points to align it to the other. However, if I centre the sets around the origin first, there seems to be frequently a problem (which doesn't occur if the points are all positives), the output being NaN. I tried to write a small reproducible code: In [77]: #I fixed the seed here for reproducibility but this happens often np.random.seed(4) #Two random set of points a = np.random.randn(10, 2) b = np.random.randn(10, 2) # Center the points arount the origin a -= np.mean(a, axis=0)[np.newaxis, :] b -= np.mean(b, axis=0)[np.newaxis, :] tform = SimilarityTransform() tform.estimate(a, b) tform(a) Out[77]: array([[ nan, nan], [ nan, nan], [ nan, nan], [ nan, nan], [ nan, nan], [ nan, nan], [ nan, nan], [ nan, nan], [ nan, nan], [ nan, nan]]) Note that if I don't centre the point there is no problem: In [89]: #I fixed the seed here for reproducibility but this happens often np.random.seed(4) #Two random set of points a = np.random.randn(10, 2) b = np.random.randn(10, 2) # Center the points arount the origin #a -= np.mean(a, axis=0)[np.newaxis, :] #b -= np.mean(b, axis=0)[np.newaxis, :] tform = SimilarityTransform() tform.estimate(a, b) tform(a) Out[89]: array([[ 3.76870886, -0.35152078], [ 1.83453334, -1.25080725], [ 5.42428044, -4.30088121], [ 2.51364241, -1.00154154], [ 6.14244682, -2.71511189], [ 5.37956586, -0.65190768], [ 4.5752074 , -0.19039746], [ 1.96968262, -1.99729896], [ 1.47865106, 0.59493455], [ 5.39473376, -0.31125435]]) Sometime it also tells me that the *SVD doesn't converge*. Any idea what is going on? Thanks, Jean

1 0

Re: Segfault with phase unwrap code
by Johannes Schönberger Dec. 4, 2013

Dec. 4, 2013

Tony I’m experiencing the same problems on OS X. See https://github.com/scikit-image/scikit-image/issues/835 Johannes Am 03.12.2013 um 05:52 schrieb Tony Yu <tsyu80(a)gmail.com>: > I'm getting a segfault when running the phase unwrap example and tests. I assume this issue is system dependent since Travis isn't raising a fuss. > > Can someone with a similar setup reproduce the issue? > > $ gcc -v > Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/c++/4.2.1 > Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) > Target: x86_64-apple-darwin13.0.0 > Thread model: posix > > Thanks, > -Tony > > -- > You received this message because you are subscribed to the Google Groups "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe(a)googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out.

2 1

Segfault with phase unwrap code
by Tony Yu Dec. 3, 2013

Dec. 3, 2013

I'm getting a segfault when running the phase unwrap example and tests. I assume this issue is system dependent since Travis isn't raising a fuss. Can someone with a similar setup reproduce the issue? $ gcc -v Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/c++/4.2.1 Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) Target: x86_64-apple-darwin13.0.0 Thread model: posix Thanks, -Tony

1 0

Scipy India 2013, 13-15th Dec, IIT Bombay
by Ankit Agrawal Dec. 2, 2013

Dec. 2, 2013

Hi everyone, I wanted to know if someone is interested in attending the Scipy India Conference 2013 <http://scipy.in/2013/> which is going to be held during 13-15th December at IIT Bombay(my university). The last date for registration is 5th Dec. I am myself not sure whether I will be at my hometown or at the university during this period, but if someone is interested, I would very much like to attend. Hopefully, Chintak would be done with his endterms by then and can possibly meetup too. If anyone is interested and is registering for it, please let me know. Cheers, Ankit.

3 2

Re: Scipy India 2013, 13-15th Dec, IIT Bombay
by Ankit Agrawal Dec. 2, 2013

Dec. 2, 2013

Hi Jaidev, > I'll be going there, and there will be a few people from the Enthought > office here in Mumbai. That's great. I also see that you have submitted a proposal<http://scipy.in/2013/abstracts/>on Compressed Sensing, which I would be interested in attending. I will definitely catch up with you guys if I attend the conference. Thanks. Cheers, Ankit Agrawal, Communications and Signal Processing, IIT Bombay.

1 0

Re: scikit-image paper
by Tony Yu Dec. 1, 2013

Dec. 1, 2013

On Thu, Nov 21, 2013 at 12:30 AM, Stéfan van der Walt <stefan(a)sun.ac.za>wrote: > On Thu, Nov 21, 2013 at 6:39 AM, Tony Yu <tsyu80(a)gmail.com> wrote: > > Unfortunately, it's a no-go on mentioning the specific companies we've > > worked with, but its OK to say something like "Enthought, Inc uses > > scikit-image extensively in their consulting projects related to > geophysics > > and microscopy". > > That's great, thank you! Could I use [1] as a reference? > Oops, I forgot to reply to this. Yes, definitely. -Tony > Stéfan > > [1] Personal communications with Tony S Yu, <insert title> [or insert > other name here] > > -- > You received this message because you are subscribed to the Google Groups > "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to scikit-image+unsubscribe(a)googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. >

1 0