Mailman 3 October 2011 - scikit-image

Renaming scikits.image to skimage
by Nelle Varoquaux 15 Oct '11

15 Oct '11

Hi all, I've worked on renaming scikits.image to skimage. Unfortunately, I have one test failing. I have no clue how to fix that, and would appreciate some help on that. You can have a look at the patch at : https://github.com/NelleV/scikits.image/compare/master...skimage I'm using numpy 1.6.1 and cython 0.15.1 ====================================================================== ERROR: test_project.test_homography ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/nelle/Projets/skimage/env/lib/python2.6/site-packages/nose-1.1.2-py2.6.egg/nose/case.py", line 197, in runTest self.test(*self.arg) File "/home/nelle/Projets/skimage/skimage/transform/tests/test_project.py", line 23, in test_homography x90 = homography(x, M, order=1) File "/home/nelle/Projets/skimage/skimage/transform/project.py", line 101, in homography mode=mode, order=order, cval=cval) File "/home/nelle/Projets/skimage/env/lib/python2.6/site-packages/scipy-0.9.0-py2.6-linux-i686.egg/scipy/ndimage/interpolation.py", line 298, in map_coordinates output, order, mode, cval, None, None) RuntimeError: data type not supported Thanks, Nelle

1 0

Pull request: morphology fix
by Tony Yu 15 Oct '11

15 Oct '11

I just submitted a pull request for a somewhat-subtle bug with some morphology operations: https://github.com/scikits-image/scikits.image/pull/62 Overly detailed explanation: Using a structuring element with one-or-both sides being even-numbered gives buggy output for morphological open/close and white/black tophat operations. These issues arise because even-numbered structuring elements (selems) aren't centered on a pixel. The dilate and erode operations are (correctly) defined so that they are symmetric (dilation on a white feature is exactly the opposite of erosion on an equivalent black feature). When chaining them (e.g. open() = dilate(erode())), however, this symmetry ends up shifting features. To fix this, one of the operations should be shifted. For example, if erosion is done with the selem shifted slightly to the lower-right, the dilation operation should shift the selem to the upper-left. This change prevents features from being shifted. The open/close operations aren't that bad: they just shift features. But, when calling white/black tophat operations, the shifting can lead to over/underflow of pixels. I've attached examples of the lena image after calling white tophat, both before and after the fix. The underflow should be apparent in the first image. Best, -Tony Example code: import os import numpy as np import matplotlib.pyplot as plt from scikits.image import data_dir from scikits.image.morphology import * lena = np.load(os.path.join(data_dir, 'lena_GRAY_U8.npy')) plt.imshow(greyscale_white_top_hat(lena, square(4))) plt.show()

1 0

Re: Skeletonization
by Neil Yager 15 Oct '11

15 Oct '11

> while the latter keeps only topology. Actually, on second thought, that's only true for this extreme example - both methods generally reflect size. I think you see what I mean though. Neil

1 0

Re: Skeletonization
by Neil Yager 15 Oct '11

15 Oct '11

Here are the outputs of the existing code for those examples: http://www.fjolad.com/ngy/img/leg_existing.png http://www.fjolad.com/ngy/img/text_existing.png Take note of the squiggles in the text example. A simple way to illustrate the difference is this example: http://www.fjolad.com/ngy/img/square_example.png As you can see, the results are very different. Once again, there are situations where both are useful. The former keeps an indication of size, while the latter keeps only topology. Neil

1 0

Re: Challenge: estimate a blurring kernel
by Neil Yager 15 Oct '11

15 Oct '11

The paper looks good, and I might take a look if I find the time. However, you have to keep in mind that this approach will only work when the point spread function is the same throughout the image. There are sources of blur where this will not work, such as viewing dynamic scenes. However, it should work well for camera shake during exposure. If only cameras stored accelerometer data in the image's meta-data which you could use to derive an initial estimate... Neil On Oct 13, 11:36 pm, Stéfan van der Walt <ste...(a)sun.ac.za> wrote: > Hi all, > > At a recent Adobe MAX conference, people went crazy over their > deblurring demo [1]. I want it in scikits-image! The authors were > even kind enough to leave us some clues as to how [2]. > > Who is up for the challenge? > > Stéfan > > [1]http://www.youtube.com/watch?v=xxjiQoTp864t > [2]http://people.csail.mit.edu/sparis/publi/2011/cvpr_radon/Cho_11_Blur_...

1 0

Re: Skeletonization
by Emmanuelle Gouillart 15 Oct '11

15 Oct '11

On Fri, Oct 14, 2011 at 01:10:43PM -0700, StÃ¯Â¿Â½fan van der Walt wrote: > 2011/10/14 StÃ¯Â¿Â½fan van der Walt <stefan(a)sun.ac.za>: > > Could you maybe show us the output of some examples using both > > algorithms? Ã¯Â¿Â½It would be nice to do a first round of visual comparison > > on some handwriting (text) and maybe something like the bone example > > in Gonzales & Woods: > > http://www.imageprocessingplace.com/DIP-3E/dip3e_book_images_downloads.htm > > (Chapter 11, image "leg_bone") > Here are those comparisons: > http://mentat.za.net/refer/skel1.png > http://mentat.za.net/refer/skel2.png I only see one output for each image: which one of the skeletonization algorithms did you use? Emma

2 1

Re: How to construct a compare view on GitHub
by Emmanuelle Gouillart 15 Oct '11

15 Oct '11

Thanks, that's very useful! Emmanuelle On Fri, Oct 14, 2011 at 11:55:50AM -0700, StÃ¯Â¿Â½fan van der Walt wrote: > Hi all, > Neil's question earlier this week on how to best get your code > reviewed, reminded me that GitHub has this great thing called a > compare view. > 2011/10/13 StÃ¯Â¿Â½fan van der Walt <stefan(a)sun.ac.za>: > >> 3. github: I've never used git before, and I'm still getting used to > >> the terminology. What is the best way for someone to review my code? > >> I've now pushed it to a branch (neil_yager-skeletonize) in my repo > >> (NeilYager). If you were to test it out, would you fork it or pull it? > If you want someone to review code that you think is ready to be > included in the scikit, then do a PR (a pull request signals: let's > merge this!). If, however, you just want a review, you can just make > changes on a branch and then do a compare view on GitHub and send the > link to the mailing list. > To construct a compare view, go to your repository, then to the branch > list, and click "compare" next to your feature branch (see the first > attached screenshot). For example, here's the compare view between > the debian and master branch of the main repo: > https://github.com/scikits-image/scikits.image/compare/master...debian > Now, it often happens that you rebase one of your feature branches on > the master branch of the main repo, or that your own repository's > master branch falls behind. In this case, the compare view may > include a bunch of spurious commits. Fortunately, GitHub now allows > you to compare your changes against another repository. In the > compare view, click on the "master" button, and in the pop-up box type > "scikits-image:master" (see screenshot 2). This gives you something > like: > https://github.com/stefanv/scikits.image-1/compare/scikits-image:master...e… > Hope that's useful! > StÃ¯Â¿Â½fan

1 0

Re: Skeletonization
by Stéfan van der Walt 15 Oct '11

15 Oct '11

2011/10/14 Stéfan van der Walt <stefan(a)sun.ac.za>: > Could you maybe show us the output of some examples using both > algorithms? It would be nice to do a first round of visual comparison > on some handwriting (text) and maybe something like the bone example > in Gonzales & Woods: > > http://www.imageprocessingplace.com/DIP-3E/dip3e_book_images_downloads.htm > (Chapter 11, image "leg_bone") Here are those comparisons: http://mentat.za.net/refer/skel1.png http://mentat.za.net/refer/skel2.png Looks good! Stéfan

1 0

Re: Skeletonization
by Neil Yager 15 Oct '11

15 Oct '11

> > It would be very interesting to compare what you've done with the > skeletonization code already in progress. We tried to merge it just > before the release, but since it was part of another, massive patch, > it didn't make it. Have a look here: > > http://bit.ly/ski_skeleton > Interesting - that's a very nice implementation. It's actually faster than mine. However, it's tough to do a direct comparison because they are doing different things. The existing code is closer to a medial axis transform, while my implementation is a more generic thinning algorithm. What you prefer will depend on the application. I've included a document imaging example that is a black and white image of text characters (it is one of the unit tests). The existing code creates lots of spurs and wiggly lines, while my code creates smoother output, which is better for OCR. However, I'm sure there are applications where the opposite is true. There's a case to be made for including both. Once again, any feedback is welcome. Neil

2 1

How to construct a compare view on GitHub
by Stéfan van der Walt 15 Oct '11

15 Oct '11

Hi all, Neil's question earlier this week on how to best get your code reviewed, reminded me that GitHub has this great thing called a compare view. 2011/10/13 Stéfan van der Walt <stefan(a)sun.ac.za>: >> 3. github: I've never used git before, and I'm still getting used to >> the terminology. What is the best way for someone to review my code? >> I've now pushed it to a branch (neil_yager-skeletonize) in my repo >> (NeilYager). If you were to test it out, would you fork it or pull it? If you want someone to review code that you think is ready to be included in the scikit, then do a PR (a pull request signals: let's merge this!). If, however, you just want a review, you can just make changes on a branch and then do a compare view on GitHub and send the link to the mailing list. To construct a compare view, go to your repository, then to the branch list, and click "compare" next to your feature branch (see the first attached screenshot). For example, here's the compare view between the debian and master branch of the main repo: https://github.com/scikits-image/scikits.image/compare/master...debian Now, it often happens that you rebase one of your feature branches on the master branch of the main repo, or that your own repository's master branch falls behind. In this case, the compare view may include a bunch of spurious commits. Fortunately, GitHub now allows you to compare your changes against another repository. In the compare view, click on the "master" button, and in the pop-up box type "scikits-image:master" (see screenshot 2). This gives you something like: https://github.com/stefanv/scikits.image-1/compare/scikits-image:master...e… Hope that's useful! Stéfan

1 0