Mailman 3 December 2013 - scikit-image

Re: match_template confidence > 3 ?
by Stéfan van der Walt 07 Dec '13

07 Dec '13

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 07 Dec '13

07 Dec '13

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 07 Dec '13

07 Dec '13

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 06 Dec '13

06 Dec '13

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 06 Dec '13

06 Dec '13

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 06 Dec '13

06 Dec '13

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 04 Dec '13

04 Dec '13

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 04 Dec '13

04 Dec '13

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 04 Dec '13

04 Dec '13

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 04 Dec '13

04 Dec '13

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